Re: Broken loader on 7.1-STABLE?
Hi All, Any body find a solution to this? I have run into the same problem as John Rushford, installing on a HP Compaq DX2300 Microtower. After a make kernel, I boot into single user mode and end up this: atkbd0: [ITHREAD] Timecounters tick every 1.000 msec I expect to see my disk, ad0 being detected at ata-master SATA150, instead, i get: Trying to mount root from ufs:/dev/ad0s1a Manual root filesystem specification: : Mount using filesystem e.g. ufs:da0s1a ? List valid disk boot devices Abort manual input -- Mike Of course, you might discount this possibility, but remember that one in a million chances happen 99% of the time. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
problem with "cold" hardware? [Was: panic in callout_reset: bad link in callwheel]
on 24/01/2009 13:00 Andriy Gapon said the following: [snip] > Additional info: > I recently added some new memory to this system. > The memory survived several passes of memtest86 before booting to > FreeBSD. It also survived one pass after the incident. > Still I wouldn't exclude a possibility of it being bad. I think that I established that the crash was because of hardware issue. I had another panic at a different place but with the similar diagnostics - bad pointer passed to a call. Fortunately, the second time the pointer was to a well-known long-lived object. So I was able to compare the bad pointer to an actual address. It turned out that a single bit was flipped. Then I realized that in both cases I saw panics after "very cold" boots, i.e. the system was powered down for more than 1 hour before the boot. So I performed memtest86 run again, this time also after a long power-off. And it reported lots of errors. I restarted memtest86 10 minutes later and then it could not find any errors in any tests. Previously I heard about problems with hardware running hot, but not with it being "cold". I put the word in quotes, because the system is in a room with normal room temperature. Any guesses what hardware part might be acting up like this? -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
HEADS UP: multi-IPv4/v6/no-IP jails merge to 7-STABLE ahead
Hi, I have a possible MFC candidate patch at: http://people.freebsd.org/~bz/20090128-02-jail7-mfc.diff to merge the multi-IPv4/v6/no-IP jails to 7-STABLE. My plan would be to do so during the weekend of 6-8th February 2009. In addition to what the patch says at the beginning (__FreeBSD_version bump), the patch also has the regenerated compat/freebsd32 sysctl stuff in it so that people can apply, compile and run it directly. For the merge this would be a second commit. For committers who want to review that I have done the merge right, it is an svn diff with mergeinfo included. For details about the patch, features, .. see the original commit message and follow-up a few days later (both in one post): http://lists.freebsd.org/pipermail/freebsd-jail/2008-December/000631.html Since then a few bug fixes went in, some older PRs were handled, ... Now is the time for you to try and review it for 7-STABLE, etc. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Mount cryptsetup-luks partition on 7.x?
Has anyone seen any information on accessing a common cryptsetup-luks container created on Fedora from FreeBSD 7.x? Are there any other cross-platform (linux/freebsd) strategies that might work better? -Nick ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
smp_tlb_shootdown bottleneck?
Hi. Sometimes I see much contention in smp_tlb_shootdown while running sysbench: sysbench --test=fileio --num-threads=8 --file-test-mode=rndrd --file-total-size=3G run kern.smp.cpus: 8 FreeBSD 7.1-R CPU: 0.8% user, 0.0% nice, 93.8% system, 0.0% interrupt, 5.4% idle Mem: 11M Active, 2873M Inact, 282M Wired, 8K Cache, 214M Buf, 765M Free Swap: 4096M Total, 4096M Free PID USERNAME PRI NICE SIZERES STATE C TIME WCPU COMMAND 810 root 1150 11568K 2408K RUN3 0:04 89.60% sysbench 810 root 1140 11568K 2408K CPU0 0 0:18 87.06% sysbench 810 root 1140 11568K 2408K CPU2 2 0:18 86.67% sysbench 810 root 1140 11568K 2408K CPU6 6 0:18 84.47% sysbench 810 root 1140 11568K 2408K CPU3 3 0:04 84.08% sysbench 810 root 1140 11568K 2408K CPU7 7 0:17 81.69% sysbench 810 root 1130 11568K 2408K CPU4 4 0:17 78.08% sysbench 810 root 1130 11568K 2408K CPU1 1 0:17 77.88% sysbench This high system load appears from time to time. Usually this sysbench test passed in a few seconds, and at this time it runs in more than 10 seconds. breaking to ddb while seen too much system load shows many sysbench threads waiting for a mutex in smp_tlb_shootdown: db> bt 100133 Tracing pid 810 tid 100133 td 0xff00032d56e0 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x378 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0x8074c912, rsp = 0xab79fff0, rbp = 0xb4acf6f0 --- smp_tlb_shootdown() at smp_tlb_shootdown+0x82 pmap_invalidate_range() at pmap_invalidate_range+0xae vfs_vmio_release() at vfs_vmio_release+0x120 getnewbuf() at getnewbuf+0x7be getblk() at getblk+0x308 cluster_read() at cluster_read+0xc5 ffs_read() at ffs_read+0x37d vn_read() at vn_read+0x17b dofileread() at dofileread+0xa1 kern_preadv() at kern_preadv+0x66 pread() at pread+0x58 syscall() at syscall+0x1ce Xfast_syscall() at Xfast_syscall+0xab --- syscall (475, FreeBSD ELF64, pread), rip = 0x800cf7b5c, rsp = 0x7eff8e78, rbp = 0x7eff8f60 --- db> bt 100132 Tracing pid 810 tid 100132 td 0xff00036426e0 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x378 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0x8048b49c, rsp = 0x80b564b0, rbp = 0xb4aca680 --- _mtx_lock_spin() at _mtx_lock_spin+0x6c _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x124 smp_tlb_shootdown() at smp_tlb_shootdown+0x58 pmap_invalidate_range() at pmap_invalidate_range+0xae vfs_vmio_release() at vfs_vmio_release+0x120 getnewbuf() at getnewbuf+0x7be getblk() at getblk+0x308 cluster_read() at cluster_read+0xc5 ffs_read() at ffs_read+0x37d vn_read() at vn_read+0x17b dofileread() at dofileread+0xa1 kern_preadv() at kern_preadv+0x66 pread() at pread+0x58 syscall() at syscall+0x1ce Xfast_syscall() at Xfast_syscall+0xab --- syscall (475, FreeBSD ELF64, pread), rip = 0x800cf7b5c, rsp = 0x7f1f9e78, rbp = 0x7f1f9f60 --- db> bt 100131 Tracing pid 810 tid 100131 td 0xff0003a75000 cpustop_handler() at cpustop_handler+0x40 ipi_nmi_handler() at ipi_nmi_handler+0x30 trap() at trap+0x378 nmi_calltrap() at nmi_calltrap+0x8 --- trap 0x13, rip = 0x8048b4a1, rsp = 0xab7a4ff0, rbp = 0xb4ac5680 --- _mtx_lock_spin() at _mtx_lock_spin+0x71 _mtx_lock_spin_flags() at _mtx_lock_spin_flags+0x124 smp_tlb_shootdown() at smp_tlb_shootdown+0x58 pmap_invalidate_range() at pmap_invalidate_range+0xae vfs_vmio_release() at vfs_vmio_release+0x120 getnewbuf() at getnewbuf+0x7be getblk() at getblk+0x308 cluster_read() at cluster_read+0xc5 ffs_read() at ffs_read+0x37d vn_read() at vn_read+0x17b dofileread() at dofileread+0xa1 kern_preadv() at kern_preadv+0x66 pread() at pread+0x58 syscall() at syscall+0x1ce Xfast_syscall() at Xfast_syscall+0xab --- syscall (475, FreeBSD ELF64, pread), rip = 0x800cf7b5c, rsp = 0x7f3fae78, rbp = 0x7f3faf60 --- Is that a normal behavior and if yes then how can I help with that? -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: multi-IPv4/v6/no-IP jails merge to 7-STABLE ahead
On Wed, 28 Jan 2009, Bjoern A. Zeeb wrote: Hi, I have a possible MFC candidate patch at: http://people.freebsd.org/~bz/20090128-02-jail7-mfc.diff to merge the multi-IPv4/v6/no-IP jails to 7-STABLE. My plan would be to do so during the weekend of 6-8th February 2009. In addition to what the patch says at the beginning (__FreeBSD_version bump), the patch also has the regenerated compat/freebsd32 sysctl stuff in it so that people can apply, compile and run it directly. For the merge this would be a second commit. For committers who want to review that I have done the merge right, it is an svn diff with mergeinfo included. For details about the patch, features, .. see the original commit message and follow-up a few days later (both in one post): http://lists.freebsd.org/pipermail/freebsd-jail/2008-December/000631.html Since then a few bug fixes went in, some older PRs were handled, ... Now is the time for you to try and review it for 7-STABLE, etc. One more thing that I had forgotten and was pointed at: sys/kern/kern_jail.c includes the __FBSDID() line. I just manually edited the patch to contain the proper CVS (not SVN) value. You may a) want to check that things apply cleanly and/or b) to sure to manually apply the hunk from the .rej. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Solved: Reproducible panic (page fault) in poll on 6.3-RELEASE-p4
Stef Walter wrote: > I have a kernel panic that I can consistently trigger. After a short > while (5 to 30 minutes) with a certain connection pattern of UDP openvpn > connections the server crashes. > > I have a crash dump, and stack trace. It seems td->td_selq has been > corrupted (see below). Solved, sorta. This was caused by a missing 'options SMP' on a multicore machine. Cheers, Stef ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problem with "cold" hardware? [Was: panic in callout_reset: bad link in callwheel]
Andriy Gapon wrote: Previously I heard about problems with hardware running hot, but not with it being "cold". I put the word in quotes, because the system is in a room with normal room temperature. Any guesses what hardware part might be acting up like this? Power supply. Give all the capacitors a visual check. Or you may be drawing too much power from your rated supply. - Andrew ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: problem with "cold" hardware? [Was: panic in callout_reset: bad link in callwheel]
On Thu, Jan 29, 2009 at 06:22:26AM +1100, Andrew Snow wrote: > Andriy Gapon wrote: > >Previously I heard about problems with hardware running hot, but not > >with it being "cold". I put the word in quotes, because the system is in > >a room with normal room temperature. > > > >Any guesses what hardware part might be acting up like this? > > Power supply. Give all the capacitors a visual check. Or you may be > drawing too much power from your rated supply. Another thing could be bad soldering of the memory slot. It might not have a full contact when at room temperature, but as it heats up by 10-20C inside the case it might expand and give full contact. This could apply to copper runs on the board, contact points from the board to the memory slot, contact from the slot to the memory. -- Regards, Ulf. - Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
jail: external and localhost distinction
Dear colleagues, am I right concluding that under FreeBSD jail there is no way to attach two processes to the same port of external interface address and localhost? I tried to move rather standard two-tier nginx(ip:80)+apache(127.1:80) scheme into a jail and on apache start got [Thu Jan 29 00:09:32 2009] [crit] (48)Address already in use: make_sock: could not bind to address 127.0.0.1 port 80 (this is under RELENG_7 if it's relevant) Any thoughts? Thanks in advance. -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: ma...@freebsd.org ] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru *** ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: jail: external and localhost distinction
Dmitry Morozovsky wrote: am I right concluding that under FreeBSD jail there is no way to attach two processes to the same port of external interface address and localhost? I tried to move rather standard two-tier nginx(ip:80)+apache(127.1:80) scheme into a jail and on apache start got In FreeBSD jails, the loopback interface doesn't exist - 127.0.0.1 is hardwired internally to point to the (external) jail IP. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: jail: external and localhost distinction
Dmitry Morozovsky wrote: > am I right concluding that under FreeBSD jail there is no way to attach two > processes to the same port of external interface address and localhost? It depends. Do those jailed processes have to communicate with each other, or only with the host system? If they do _not_ have to communicate with each other, it's easy. You have to put the second jail on a locahost IP address (not necessarily 172.1; you can create an alias on lo0 like 127.2 or similar). If they have to communicate with each other, it gets more complicated. If they need to communicate directly, you must put both jails on the same IP address, but then you cannot bind the processes to different IP addresses. Note that locahost is not handled specially within jails: If you try to bind a process to a localhost IP, it is forced to bind to the jail's IP instead. That's what is causing your error message: > [Thu Jan 29 00:09:32 2009] [crit] (48)Address already in use: make_sock: > could > not bind to address 127.0.0.1 port 80 If they do have to communicate with each other, but you need the jails to be on different IP addresses, there are several ways to solve the problem, but they all smell a bit like a dirty hack. One way (probably the easiest one) is to forward packets between the jails using IPFW "fwd" rules (or IPF ipnat "rdr" rules, or PF translation rules). Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd I suggested holding a "Python Object Oriented Programming Seminar", but the acronym was unpopular. -- Joseph Strout ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
How about a 5-foot pencil?
If you are unable to view this e-mail, please visit [1]http://www.greatbigstuff.com/dixon.html Motivate Children to Think BIG with this 5-foot replica pencil! [2][dixon_1.jpg] [3]CLICK HERE FOR MORE INFORMATION OR CALL 1-800-773-8832, EXT. 444 This giant pencil can even be personalized with a name or any motivational message. In spite of its large size, it can take up very little space leaning in a corner while still having a big visual impact. [4]GreatBigStuff.com offers a complete line of imaginative and creative products that add interest and enthusiasm to any décor. Please visit our [5]website to see our complete line of uniquely oversized versions of everyday objects. We are sending you this email because our vendor, Affordable Marketing Tools, has provided us your email address as someone that would be interested in home school related products or services. We apologize if this email is not welcomed by you. We ask that you click the link at the bottom of this message or reply with a note asking us to exclude you from future notices. This email is being sent from GreatBigStuff.com 128 Patriot Drive, Units 8-10 Middletown, DE 19709 Our phone number is 1-800-773-8832. -- - To be unsubscribed from the Motivate Kids! mailing list, simply click on the link below: [6]Unsubscribe sta...@freebsd.org References 1. http://www.greatbigstuff.com/dixon.html 2. http://www.greatbigstuff.com/dixon.html 3. http://www.greatbigstuff.com/dixon.html 4. http://www.greatbigstuff.com/ 5. http://www.greatbigstuff.com/ 6. http://www.greatbigstuff.com/cgi-bin/smpro2/s.pl?r=1&l=13&e=stable=:freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
RE: cheap usb ethernet
> hail, > > I need an usb ethernet, but found just one from aue and axe from 7.1 > hardware list. is there any apart from those there ? I looked on ebay > for > my search. > > thanks, > > matheus D-link's usb 2.0 ethernet devices work fine and are ~$30 : http://www.dlink.com/products/?pid=133 I realize d-link lists the price at closer to $40, but you can find online stores that sell it for less. --- Kevin K. Systems Administrator www.stardothosting.com/linux-vps-hosting ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
NFS writes calling FSYNC and ASYNC not consistent
Hello FreeBSD users, I am running into some performance problems with NFSv3/v4 mounts. I have a Sun X4540 running OpenSolaris 2008.11 with ZFS exporting NFS shares The NFS clients are a FreeBSD 6.3 32 bit, quad core xeon with 4GB ram and a FreeBSD 7.1 32bit with same hardware. The issue I am seeing, is that for certain file types, the FreeBSD NFS client will either issue an ASYNC write, or an FSYNC. However, NFSv3 and v4 both support "safe" ASYNC writes in the TCP versions of the protocol, so that should be the default. Issuing FSYNC's for every compete block transmitted adds substantial overhead and slows everything down. The two test files I have that can reproduce this data are a file created by 'dump' which is just binary data: $ file testbinery testbinery: data ASCII text file from a Maildir format: $ file ascittest ascittest: ASCII mail text My NFS mount command lines I have tried to get all data to ASYNC write: $ mount_nfs -3T -o async 192.168.0.19:/pdxfilu01/obsmtp /mnt/obsmtp/ $ mount_nfs -3T 192.168.0.19:/pdxfilu01/obsmtp /mnt/obsmtp/ $ mount_nfs -4TL 192.168.0.19:/pdxfilu01/obsmtp /mnt/obsmtp/ Here is an excerpt from a snoop from the binary data file: $ snoop rpc nfs obsmtp02.local -> pdxfilu01NFS C ACCESS3 FH=57D3 (read,lookup,modify,extend,delete,execute) pdxfilu01 -> obsmtp02.local NFS R ACCESS3 OK (read,modify,extend) obsmtp02.local -> pdxfilu01NFS C LOOKUP3 FH=BB85 testbinery pdxfilu01 -> obsmtp02.local NFS R LOOKUP3 OK FH=57D3 obsmtp02.local -> pdxfilu01NFS C ACCESS3 FH=57D3 (read,lookup,modify,extend,delete,execute) pdxfilu01 -> obsmtp02.local NFS R ACCESS3 OK (read,modify,extend) obsmtp02.local -> pdxfilu01NFS C SETATTR3 FH=57D3 pdxfilu01 -> obsmtp02.local NFS R SETATTR3 OK obsmtp02.local -> pdxfilu01NFS C WRITE3 FH=57D3 at 0 for 32768 (ASYNC) pdxfilu01 -> obsmtp02.local NFS R WRITE3 OK 32768 (ASYNC) obsmtp02.local -> pdxfilu01NFS C WRITE3 FH=57D3 at 582647808 for 32768 (ASYNC) pdxfilu01 -> obsmtp02.local NFS R WRITE3 OK 32768 (ASYNC) obsmtp02.local -> pdxfilu01NFS C WRITE3 FH=57D3 at 592871424 for 32768 (ASYNC) pdxfilu01 -> obsmtp02.local NFS R WRITE3 OK 32768 (ASYNC) obsmtp02.local -> pdxfilu01NFS C WRITE3 FH=57D3 at 605421568 for 32768 (ASYNC) pdxfilu01 -> obsmtp02.local NFS R WRITE3 OK 32768 (ASYNC) And on and on.. it will acheive near full wire-speed, about 110MB/sec during the copy Here is the same snoop, only copying the ASCII mail file: $ snoop rpc nfs obsmtp02.local -> pdxfilu01NFS C LOOKUP3 FH=BB85 ascittest pdxfilu01 -> obsmtp02.local NFS R LOOKUP3 No such file or directory obsmtp02.local -> pdxfilu01NFS C LOOKUP3 FH=BB85 ascittest pdxfilu01 -> obsmtp02.local NFS R LOOKUP3 No such file or directory obsmtp02.local -> pdxfilu01NFS C CREATE3 FH=BB85 (UNCHECKED) ascittest pdxfilu01 -> obsmtp02.local NFS R CREATE3 OK FH=69D3 obsmtp02.local -> pdxfilu01NFS C WRITE3 FH=69D3 at 0 for 32768 (FSYNC) pdxfilu01 -> obsmtp02.local NFS R WRITE3 OK 32768 (FSYNC) obsmtp02.local -> pdxfilu01NFS C WRITE3 FH=69D3 at 32768 for 32768 (FSYNC) pdxfilu01 -> obsmtp02.local NFS R WRITE3 OK 32768 (FSYNC) obsmtp02.local -> pdxfilu01NFS C WRITE3 FH=69D3 at 65536 for 32768 (FSYNC) pdxfilu01 -> obsmtp02.local NFS R WRITE3 OK 32768 (FSYNC) And so on. I've reproduced this with several files, and the only difference between tests is the file type. Is the FreeBSD NFS client requesting FSYNC or ASYNC depending on the file type/contents? If so, is there a tuneable setting to make all write ASYNC? Otherwise, FSYNC'ing for every block written over NFS will cause so many IOPS on the NFS server, that performance will degrade severely. Testing with an OpenSolaris 2008.11 client will issue ASYNC writes for any file type, if mounted with NFSv3 of NFSv4 (TCP). Any ideas? Thanks in advance! -- Brent Jones br...@servuhome.net ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
While this enabled the mouse (without HAL), it did nothing good about: a. The bogus keyboard scans. Everyone is talking about an xorg.conf The new X.org 7.4 upgrade hit me too: no keyboard & no mouse! Bummer. I found that if I simply added to /etc/rc.conf: hald_enable="YES" that things now work for me. Previously I never have had hald in my rc.conf. Hope this helps. Dan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
7.1 new install halts on BTX error
I upgraded my 7.0 system to 7.1-RELEASE with freebsd-update only to find that it no longer boots correctly, instead crashing with a BTX backtrace. If I break to the loader prompt and use 'ls /boot', I also get a backtrace. A new install of 7.1 on this hardware using a separate SCSI card and drive array also leads to a BTX backtrace. I have copied this below as the first (most repeatable) error and also included the other problems. A fresh install of 7.0 works fine. FreeSBIE 1.0, based on FreeBSD 5.3, also boots fine and will happily list the contents of the original drive's /boot in the loader, although refuses to load the kernel. The FreeBSD 7.1 install CD also boots and allows me to install over FTP. I have run into BTX problems on this machine before under -CURRENT (see http://lists.freebsd.org/pipermail/freebsd-current/2008-October/089460.html ). Dmesg from 7.0 in http://www.freebsd.org/cgi/query-pr.cgi?prp=125769-1-txt&n=/patch.txt A new install of 7.1-RELEASE on separate disks leads to this backtrace: int=000d err=1840 efl=00010207 eip=0511 eax=04551364 ebx= ecx=00495cae edx=00495cae esi=0009 edi=0001 ebp= esp=00495cae cs=002b ds=0033 es=0033fs=0033 gs=0033 ss=0033 cs:eip=17 00 00 00 00 00 00 0c-00 00 00 00 00 00 00 b9 ae 5c 49 00 00 00 00 b9-ae 5c 49 00 00 00 00 c8 ss:esp=43 18 3c 01 74 08 3c 04-0f 85 e4 00 00 00 0f b6 43 19 88 86 94 00 00 00-c7 46 30 00 00 00 00 3c BTX error on boot with the 7.0 partition that has been upgraded to 7.1: int=000d err= efl=00010a92 eip=0430 eax=ff4c ebx=6c94 ecx=0001 edx=0080 esi=0001 edi=9416 ebp= esp=0008f8b4 cs=002b ds=0033 es=002bfs=0033 gs=0033 ss=0033 cs:eip=6c 7f 94 48 00 00 00 00-0f af c1 47 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ss:eip=2b 00 00 00 33 00 00 00-00 0c 04 00 5f ad 08 04 00 00 00 00 0f 00 00 00-00 00 00 00 24 1c 06 00 BTX halted If I break to the loader prompt and try 'ls /boot', I get this backtrace: int=0006 err= efl=00010203 eip=00040c08 eax=00c6 ebx=0008 ecx=eb00 edx=00c6 esi=0004 edi=00c2 ebp= esp=0008f8b4 cs=002b ds=0033 es=002bfs=0033 gs=0033 ss=0033 cs:eip=8f 49 40 00 94 49 00 cb-00 00 04 00 00 00 fc 07 80 00 00 00 04 00 00 00-94 49 00 00 00 00 00 00 ss:eip=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 BTX halted Any thoughts or suggestions? I will stay on 7.0 for now but have a fairly large supply of spare drives so I can test new installs if required. Thanks, David Adam zanc...@ucc.gu.uwa.edu.au ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
Although the hald_enable in /etc/rc.conf worked, I noticed that a lot of other demons get running. I needed to add dbus_enable as well. That fix is too intrusive in my book. In any event Firefox is now broken and does not run at all. I backed out the /etc/rc.conf changes and generated an xorg.conf by calling Xorg -configure. I moved this to /etc/xorg.conf. Things were still broken until I added the recommended Option "AllowEmptyInput" "off" in the ServerLayout section of xorg.conf. Now I can use X again BUT... Firefox 3.0.5 is still broken. It has worked fine until this new Xorg. This 7.4 version of X.org is not ready for STABLE! Dan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
On Wed, 2009-01-28 at 21:11 -0700, Dan Allen wrote: > Although the hald_enable in /etc/rc.conf worked, I noticed that a lot > of other demons get running. I needed to add dbus_enable as well. > That fix is too intrusive in my book. > > In any event Firefox is now broken and does not run at all. > > I backed out the /etc/rc.conf changes and generated an xorg.conf by > calling Xorg -configure. I moved this to /etc/xorg.conf. Things were > still broken until I added the recommended > > Option "AllowEmptyInput" "off" > > in the ServerLayout section of xorg.conf. > > Now I can use X again BUT... Firefox 3.0.5 is still broken. It has > worked fine until this new Xorg. Firefox not working is one of the symptoms of a botched upgrade. If you ldd firefox-bin you will likely find that it is linked to both libxcb.so.1 and libxcb.so.2. This is not good, ensure that everything that depends on libxcb has been rebuilt. robert. > This 7.4 version of X.org is not ready for STABLE! > > Dan > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" signature.asc Description: This is a digitally signed message part
Re: Unhappy Xorg upgrade
,--- You/Dan (Wed, 28 Jan 2009 20:39:10 -0700) * | > While this enabled the mouse (without HAL), it did nothing good about: | > | >a. The bogus keyboard scans. You are quoting me and I need to clarify... | Everyone is talking about an xorg.conf | The new X.org 7.4 upgrade hit me too: no keyboard & no mouse! Bummer. | I found that if I simply added to /etc/rc.conf: |hald_enable="YES" | that things now work for me. | Previously I never have had hald in my rc.conf. | Hope this helps. `--* My worst case is not HAL-related: I had the same behavior with or without HAL, and the behaviour was, e.g.: * I press the keys "TAB q w" over an `xev' window and see the bogus key scan codes -- nothing related to the pressed keys. * In a moment the xev-monitoring xterm window shows a non-stopping flow of events, even though I am not touching anything on the computer. * With some combination of a few key presses over the `xterm' window, suddenly a long stream of `2's appears. Or `z'. Or something else, unrelated to the keys I had pressed. There has been nothing of this sort on my desktop, where I am typing this message -- so, I think I know how to configure X :-). On this desktop I am currently running this new X (installed it on Sunday) -- first I ran it with HAL, then today I switched to the HAL-less mode. I did complain about the garbage in my windows -- and it got me, there was so much of it: I switched to the HAL-less mode a few hours ago and so far it seems I have less of it. Another thing that I am certain about, is that in the HAL mode (I am not yet sure about the behavior in my current HAL-less mode), there is a dramatically higher mouse pointer captivity by some applications (e.g. `opera') -- it sometimes takes (took?) about 10 seconds after shifting a pointer into an xterm or Emacs to be able to produce any keyboard input. I did notice these things with the old X, but on a scale dramatically smaller. ,--- You/Dan (Wed, 28 Jan 2009 21:11:13 -0700) * | This 7.4 version of X.org is not ready for STABLE! `--* I hate to say this, but the new X (as exists in the current FreeBSD ports) sucks and gets in the way of work big time. -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
,--- You/Robert (Wed, 28 Jan 2009 23:16:11 -0500) * | > Now I can use X again BUT... Firefox 3.0.5 is still broken. It has =20 | > worked fine until this new Xorg. | | Firefox not working is one of the symptoms of a botched upgrade. If you | ldd firefox-bin you will likely find that it is linked to both | libxcb.so.1 and libxcb.so.2. This is not good, ensure that everything | that depends on libxcb has been rebuilt. FWIW, firefox3 works for me (just installed it on my desktop). -- Alex -- alex-goncha...@comcast.net -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unhappy Xorg upgrade
In article you wrote: > ,--- You/Robert (Wed, 28 Jan 2009 23:16:11 -0500) * > | > Now I can use X again BUT... Firefox 3.0.5 is still broken. It has =20 > | > worked fine until this new Xorg. > | > | Firefox not working is one of the symptoms of a botched upgrade. If you > | ldd firefox-bin you will likely find that it is linked to both > | libxcb.so.1 and libxcb.so.2. This is not good, ensure that everything > | that depends on libxcb has been rebuilt. > > FWIW, firefox3 works for me (just installed it on my desktop). I also have firefox3 working. Initially got bitten by not having "hald_enable" and "dbus_enable" in my /etc/rc.conf. Adding these made my mouse work. Got Nvidia's latest driver (180.25) to fix the dlopen: /usr/local/lib/xorg/modules//libwfb.so: Undefined symbol +"miZeroLineScreenIndex" problem. Thank you to Nvidia for the fast work. (-: Initially thought this upgrade was a mistake, until I found out about "hald_enable" and "dbus_enable". Upgrade would have be a lot easier if they were mentioned in /usr/ports/UPDATING. I would have found these knobs more quickly if mentioned in HALD(8). or if they had default values in /etc/rc/defaults/rc.conf. Did get a laugh out of HALD(8) telling me how to start and stop hald under Fedora. Found them by looking at the startup scripts in /usr/local/rc.d. My 7.4 xorg install now seems to be rock solid. (-; Larry -- Larry Baird| http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: l...@gta.com | TEL 407-380-0220, FAX 407-380-6080 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
