Re: FreeBSD 4.x EoL
On Thu, 19 Oct 2006, Paul Allen wrote: While possibly not advisable in the long term, I ran a 4.x postfix and cyrus server install on 6.x using compat4 for about six months without problems. The place where it gets tricky is updating the 4.x binaries, which requires a 4.x chroot, since I was running a native 6.x userland for everything else. I've now gotten over that, but it worked quite well and was extremely useful that I could avoid doing the upgrade all at once -- upgrade the OS first, let it settle, then upgrade the applications. The only issue I ran into was actually that the location of the Cyrus sasl unix domain socket had moved, and once I tracked that down, all was well (so not a FreeBSD nit, an application nit). Let me toss a bit of caution from experience regarding this: I too ran such 6.x system. It had a jailed FreeBSD 4.x userland (restored and modified from the original FreeBSD 4.x backups). Almost everything worked properly--but there were some strange vm related inconsistencies (exposed by a program rolling its own gc implementation and using mprotect and SEGV). Obviously this was an unusual case but it's unfortuantely proof that some things escape having the necessary compat lines in your kernel conf. Still I counted myself lucky. When you recompiled the application for 6.x, did the problem go away? I guess I wouldn't entirely preclude an application bug, a 4.x library bug, or a 6.x compat/non-compat bug being responsible. Since 6.x is a fairly major upgrade, there are significant changes in VM (which might well affect, for example, memory layout), etc, so it could well be that it triggered a bug in the GC. Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 4.x EoL
Nicolas Rachinsky wrote: Jim C. Nasby wrote: The issue I run into is that I use software raid (vinum in 4.11, gmirror in 6.x), and I don't know of any way to go from one to the other that doesn't involve wiping both drives at the same time. You can wipe one of the disks, create a gmirror with only one provider. Then you can copy the data. Afterwards you can wipe the second disk and add it to the gmirror. Or am I missing something? I can confirm that it works exactly as you described. Of course you should have a good backup in any case. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. In My Egoistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. -- Blair P. Houghton ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5 to 6
Randy Bush wrote: do folk actually successfully upgrade # uname -a FreeBSD psg.com 5.5-STABLE FreeBSD 5.5-STABLE #15: Sun Oct 1 18:41:24 GMT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PSG i386 to RELENG_6 *safely* on a many-user production system using the instructions in UPDATING? Worked fine for me, except that I had to rm -rf /usr/obj first which contained data from a previous RELENG_5 update. Without doing that I got compilation errors during the buildworld procedure. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. One of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs. -- Robert Firth ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSD/Linux slices like Solaris' Solstice DiskSuite
r00t_0101 [EMAIL PROTECTED] wrote: Does anyone know how to create a true slice on a BSD/Linux node. I know that Solaris uses Solstice DiskSuite or some type of volume management where you are able to reboot to a particular partition through command-line instead of manual reboot. So whith that said, my goal is to create multiple slices (FreeBSD, Linux 6.x, Linux 7.x, etc ...) where I could ssh into a node to be able to reboot into another partition based on my work environment. This would be useful due to working remotely with different environments. I'm not sure I understand your question correctly. Use the fdisk(8) utility to create slices on FreeBSD (you can also use sysinstall(8) if you prefer a gaily colored interface). To change the active slice to, say, the third one, use the command fdisk -a 3 /dev/yourdisk. That will request for confirmation interactively. To do it non-interactively (e.g. in a script), use echo a 3 | fdisk -f - /dev/ Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. A language that doesn't have everything is actually easier to program in than some that do. -- Dennis M. Ritchie ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS-UP: DEVFS fixes MFC for test [Was: Re: ps locks up on 6.2-PRERELEASE SMP]
On Fri, Oct 20, 2006 at 09:45:34AM +0900, Kazuaki ODA wrote: Kris Kennaway wrote: Yep, devfs as I suspected. Keep an eye on the commit logs for when kib@ merges his fix. Kris Thanks. I'll test again after the fix is merged into RELENG_6, and post the result. I plan to ask the re@ for MFC approval in the next week (hopefully, before the BETA-3). Aggregated patch against RELENG_6 is located at http://people.freebsd.org/~kib/devfs-RELENG_6.patch. I ask interested users to test the patch before the merge. pgpvz7Q0e67EK.pgp Description: PGP signature
Re: bug on BTX
Hi all, FYI, this change adds 32 bytes to btx leaving 139 bytes free, according to btxld(8). As you probably all know, and just as a reminder, size in boot2 is at a premium -- it can't go over 8192 bytes as this is the boot-sector limit in the BSD disk-label. Dominic Marks wrote: John Baldwin wrote: Hmm, are you willing to test a change that should fix that? If so, try http://people.freebsd.org/~jhb/patches/btx_crx.patch You'll need to do a 'make clean make make install' in /sys/boot after applying, and if the make install suceeeds, do a 'bsdlabel -B ad0s1' (replace ad0s1 with the actual slice you boot from). I think it should work (I think it was tested a while ago, but boot2 used to not fit, now it does though). Be warned though that if it doesn't work, you won't be able to boot from your disk. If that happens and you have a 6.x disc 1 lying around, you can boot into rescue mode and re-run 'bsdlabel' and move boot/loader.old to boot/loader on the root partition to get your system back. Ideally you'd try this on a system with data you don't care about (i.e., it's ok to just do a reinstall if it is hosed). It would be a good thing to solve the real mode problem, as it would enable FreeBSD to be booted from memory stick, USB CDROM, and within QEMU without resorting to the current workarounds e.g. using GRUB or skipping /boot/loader entirely to boot the kernel directly as I currently do in QEMU virtualization. It's pretty important in the big scheme of things as it helps to bring FreeBSD to a wider audience. Many people out there may well have run into this without Indeed I recently ran into this myself. Certain 1U machines which I acquired had problems booting from USB CDROM. I traced this back to the USB BIOS trying to LGDT and causing a general protection fault in vm86 mode. I worked around this by PXE booting them on a private VLAN with most helpful assistance from [EMAIL PROTECTED] The long term solution we've been discussing is to change btx to trampoline into real mode before invoking certain INTs. I've been doing some tests with QEMU and Etherboot; it looks like its PXE UNDI driver sets up the NIC interrupt vector *before* BTX is called; it does not call LIDT in any of its paths. Its PXE entry point does however call LGDT to enter protected mode which of course kills BTX stone dead as we're in vm86 mode at that point. Per my IRC discussions with jhb@ : given that BTX reflects the hardware interrupts, we shouldn't need to reprogram the AT-PICs; indeed GRUB does not. This was one of his concerns. We can probably get away with a simple trampoline a la GRUB providing the INTs invoked by BTX or LOADER don't attempt to rewrite or redirect interrupt vectors once we're up and running. If time permits I may try to make the changes to BTX myself, however, I am always happy to review patches and provide feedback with a view to getting the problem solved going forward. Best, BMS we encountered the same problem when trying to boot pxe the PCEngines/WRAP so if you need testers, i'm willing. danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSD/Linux slices like Solaris' Solstice DiskSuite
r00t_0101 [EMAIL PROTECTED] wrote: Does anyone know how to create a true slice on a BSD/Linux node. I know that Solaris uses Solstice DiskSuite or some type of volume management where you are able to reboot to a particular partition through command-line instead of manual reboot. So whith that said, my goal is to create multiple slices (FreeBSD, Linux 6.x, Linux 7.x, etc ...) where I could ssh into a node to be able to reboot into another partition based on my work environment. This would be useful due to working remotely with different environments. I'm not sure I understand your question correctly. Use the fdisk(8) utility to create slices on FreeBSD (you can also use sysinstall(8) if you prefer a gaily colored interface). To change the active slice to, say, the third one, use the command fdisk -a 3 /dev/yourdisk. That will request for confirmation interactively. To do it non-interactively (e.g. in a script), use echo a 3 | fdisk -f - /dev/ I use 'bsdlabel -s[1234] /dev/mydisk' all the time when changing between 'slices' danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Installing 6.1-R on Dell Powervault 745N
Lin Jui-Nan Eric wrote: Hi, On 10/19/06, Søren Schmidt [EMAIL PROTECTED] wrote: Nothing else that that it should work. I dont own any HW that uses this chip so I cannot test it out. The current support was done for the ARM port IIRC so things might be different on other systems. At any rate you definitly should try out 6.2-beta-something as 6.1 is getting old I have tried world kernel built yesterday (10/19), but the OS still can not recognize the hard disk. The dmesg and result of pciconf -lv: http://www.cs.nctu.edu.tw/~jnlin/cc/dmesg.log http://www.cs.nctu.edu.tw/~jnlin/cc/pciconf.log OK, I need the output from a verbose boot. That will tell if the disks are seen at all and just the attach phase is failing. I might have a few ideas depending on the outcome of that... -Søren ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Installing 6.1-R on Dell Powervault 745N
Hi, On 10/20/06, Søren Schmidt [EMAIL PROTECTED] wrote: OK, I need the output from a verbose boot. That will tell if the disks are seen at all and just the attach phase is failing. I might have a few ideas depending on the outcome of that... There is no message about ad0 shown in the boot procedure. Neither there is no message about failed device. How do I get the output from verbose boot? with digital camera? Best Regards, Eric ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
Bruce M. Simpson wrote: [...] Indeed I recently ran into this myself. Certain 1U machines which I acquired had problems booting from USB CDROM. I traced this back to the USB BIOS trying to LGDT and causing a general protection fault in vm86 mode. I worked around this by PXE booting them on a private VLAN with most helpful assistance from [EMAIL PROTECTED] I can confirm this problem. I can boot from DVD-RW in external enclosure (USB 2.0) on my desktop PC and few others I tested in the past, but can not boot any FreeBSD release on servers in collocation (from the same external DVD-RW). Tested with some Asus server boards and 1U Sun Fire X2100. But these machines can boot from another boot CD I have (Hirens Boot CD, RIP Linux, Ultimate Boot CD, OpenBSD) I'll be happy if this can be solved in some feature release of FreeBSD, because I managed many servers without internal CD/DVD drive. I do not understand this part of system well, but let me know if I can provide some more information about systems where I can boot well or where I can not boot FreeBSD from USB CD / DVD. Miroslav Lachman ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel ignores kenv comconsole_speed?
Am I doing something wrong, or is this a bug? (This is on a stable from yesterday.) I have -DS115200 in /boot.config, and boot and loader are happily using this speed. However, the kernel appears to be hardwired to 9600. After boot, it's still at 9600: # stty /dev/ttyd0 speed 9600 baud; lflags: -icanon -isig -iexten -echo iflags: -icrnl -ixon -ixany -imaxbel -brkint oflags: -opost cflags: cs8 -parenb clocal # sysctl machdep.conspeed machdep.conspeed: 9600 However, comconsole_speed is set correctly: # kenv comconsole_speed 115200 I've recompiled my kernel with options COMSPEED=115200, and that fixed the issue for now, but shouldn't the kernel pick up the console speed from the kenv instead of using the hard-coded value? Since machdep.conspeed is a sysctl, you can only change it after boot, which is kind of inconvenient... Stefan -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSD/Linux slices like Solaris' Solstice DiskSuite
Danny Braniss wrote: Oliver Fromme wrote: To change the active slice to, say, the third one, use the command fdisk -a 3 /dev/yourdisk. That will request for confirmation interactively. To do it non-interactively (e.g. in a script), use echo a 3 | fdisk -f - /dev/ I use 'bsdlabel -s[1234] /dev/mydisk' all the time when changing between 'slices' Uhm? What version of FreeBSD are you using? In RELENG_6 I only get the usage message when I try -s, and the manpage doesn't mention it either. Looking at the source, the getopt(3) string indeed contains s:, but the code never checks for it and falls through to the default case (which spits out the usage message and exits). Looks like a bug. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. C is quirky, flawed, and an enormous success. -- Dennis M. Ritchie. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS-UP: DEVFS fixes MFC for test [Was: Re: ps locks up on 6.2-PRERELEASE SMP]
Kostik Belousov wrote: On Fri, Oct 20, 2006 at 09:45:34AM +0900, Kazuaki ODA wrote: Kris Kennaway wrote: Yep, devfs as I suspected. Keep an eye on the commit logs for when kib@ merges his fix. Kris Thanks. I'll test again after the fix is merged into RELENG_6, and post the result. I plan to ask the re@ for MFC approval in the next week (hopefully, before the BETA-3). Aggregated patch against RELENG_6 is located at http://people.freebsd.org/~kib/devfs-RELENG_6.patch. I ask interested users to test the patch before the merge. This patch has fixed the problem I reported. I cannot reproduce it anymore. Thanks, -- Kazuaki ODA ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mountd changed?
On Mon, Oct 16, 2006 at 08:33:38AM +0200, Rink Springer wrote: I'll get this committed. Thanks for the report and patch! It has been committed to HEAD; Expect a MFC after a few days. Thanks! -- Rink P.W. Springer- http://rink.nu Patience is for those who cannot afford decent hardware.- Peter Koeleman pgpNXlSsY4L1j.pgp Description: PGP signature
Re: BSD/Linux slices like Solaris' Solstice DiskSuite
Danny Braniss wrote: Oliver Fromme wrote: To change the active slice to, say, the third one, use the command fdisk -a 3 /dev/yourdisk. That will request for confirmation interactively. To do it non-interactively (e.g. in a script), use echo a 3 | fdisk -f - /dev/ I use 'bsdlabel -s[1234] /dev/mydisk' all the time when changing between 'slices' Uhm? What version of FreeBSD are you using? In RELENG_6 I only get the usage message when I try -s, and the manpage doesn't mention it either. Looking at the source, the getopt(3) string indeed contains s:, but the code never checks for it and falls through to the default case (which spits out the usage message and exits). Looks like a bug. sorry!, it was before morning coffee, s/bsdlabel/boot0cfg/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSD/Linux slices like Solaris' Solstice DiskSuite
Danny Braniss wrote: sorry!, it was before morning coffee, s/bsdlabel/boot0cfg/ Ah, OK. Yes, that would also work, but only if you have the boot manager installed. (Strictly speaking it doesn't change the active slice, which will always be the FreeBSD slice, but it changes the slice that will be booted in turn by the boot manager). Hmm... I still wonder why there is s: in the getopt(3) string of bsdlabel(8). It seems to be a leftover from the boot1/boot2 stuff that was removed in r1.75 of bsdlabel.c. Maybe I should submit a PR. :-) Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired. -- Chris Torek ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/dev/bge if_bge.c if_bgereg.h
Am 10.10.2006 um 13:12 schrieb Stefan Bethke: Doug Ambrisko schrieb: ambrisko2006-09-09 03:36:57 UTC FreeBSD src repository Modified files: sys/dev/bge if_bge.c if_bgereg.h Log: Add support to bge(4) to not break IPMI support when the driver attaches to it. Do you have plans to MFC this in time for 6.2? Could I convince anyone to MFC this? We've been using this change on -stable for the past few weeks without any issues, and I'd rather avoid keeping too many local changes. Thanks, Stefan -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS: freeze during copy [ RESOLVED]
[EMAIL PROTECTED] wrote: Christopher Sean Hilton wrote: On Wed, 2006-09-27 at 16:37 -0400, Kris Kennaway wrote: and my luck has it such that i've not had a lockup since i added that extra debugging code into the kernel :-) or :-( depending on your view... Heisenbugs are great! :) Before I classified this as a Heisenbug I'd switch from NFS over UDP to NFS over TCP. The original poster also hasn't mentioned if he's using soft, or hard mounts or if he has the intr option on. Depending on how these options are tuned NFS lockups are normal. I used keep /usr/src mounted via NFS and do make buildworld/installworld on my laptop. The network was a switched lan and there were no firewalls. Very occasionally the build process would lockup. When I went to debug this a sage wizard suggested that the first step was to switch from UDP to TCP. As it turns out the problem was that the ne2000 driver on my laptop was loosing packets. With udp the means to detect this was weak to non-existant. Changing to TCP meant that not only could the kernel detect that a packet had gotten lost but it only had to resend that one packet, not the entire buffer. From that point on the build process worked flawlessly in fact I was able to extend the process to work between a local NFS server and a remote NFS client located 25 miles away at the other end of an IPsec tunnel. Bottom line: change to TCP and retest. NFS over UDP is very sensitive to packet loss. -- Chris yeah, your'ar right, NFS tcp would be propably better. My setup was using UDP with changing port, that's the reason why, as for me, the copy was freezed after somes bytes. But I still supprised by kernel freezing after a night, so that I've had to reboot the server. As 5.x's support will be stopped, I'd better to upgrade all to 6.1 ( NFS problems, openssl secure issues...) thanks a lot for all. luc, remember, use keep frags in your ipf, that could save your life. -- Richard VENNE www.dental-on-line.com Phone: 01 43 27 94 24 fax: 01 43 27 66 85 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: locked vnode / nfs... requires kill -9 in ddb
John Baldwin wrote at 10:44 -0400 on Oct 19, 2006: On Thursday 19 October 2006 06:04, Kostik Belousov wrote: On Wed, Oct 18, 2006 at 10:01:45AM -0600, John E Hein wrote: 6.2-PRERELEASE from 20061016 RELENG_6 sources. Locked vnodes 0xc6b7bdd0: tag nfs, type VDIR usecount 2, writecount 0, refcount 8 mountedhere 0 flags (VV_ROOT) v_object 0xc9d84108 ref 0 pages 0 lock type nfs: EXCL (count 1) by thread 0xc8adac00 (pid 50746) with 5 pending fileid 8 fsid 0x300ff06 50746 5 4 600 T+ sh . . dbdb trace 50746 Tracing pid 50746 tid 100231 td 0xc8adac00 sched_switch(c8adac00,0,2) at 0xc05ce0cb = sched_switch+0x173 mi_switch(2,0) at 0xc05c2b0a = mi_switch+0x1ba thread_suspend_check(1,c079e04c,c8adac00,c9206b80,1,...) at 0xc05c722d = thread_suspend_check+0x191 sleepq_catch_signals(c9206b80) at 0xc05db93f = sleepq_catch_signals+0x103 sleepq_wait_sig(c9206b80) at 0xc05dbd96 = sleepq_wait_sig+0xe msleep(c9206b80,c08a6a40,153,c0813379,0) at 0xc05c2652 = msleep+0x25a nfs_reply(c9206b80,0,c8adac00,4,c7ea7100,...) at 0xc06c33ac = nfs_reply+0x244 nfs_request(c6b7bdd0,c6ae2d00,1,c8adac00,c7815280,e8f3488c,e8f34890,e8f34894,c8adac00,e8f348a0) at 0xc06c40a5 = nfs_request+0x3c1 nfs_getattr(e8f348dc) at 0xc06c912b = nfs_getattr+0x11f VOP_GETATTR_APV(c086c700,e8f348dc) at 0xc07b260c = VOP_GETATTR_APV+0x38 nfsspec_access(e8f34a8c,c6bf7c94,0,e8f349a4,c060ca26,...) at 0xc06cebf1 = nfsspec_access+0x85 nfs_access(e8f34a8c) at 0xc06c8b7a = nfs_access+0x122 VOP_ACCESS_APV(c086c700,e8f34a8c) at 0xc07b25b0 = VOP_ACCESS_APV+0x38 nfs_lookup(e8f34b18) at 0xc06c96ff = nfs_lookup+0xd3 VOP_LOOKUP_APV(c086c700,e8f34b18) at 0xc07b22f7 = VOP_LOOKUP_APV+0x43 lookup(e8f34c00) at 0xc060ee79 = lookup+0x4c1 namei(e8f34c00) at 0xc060e71a = namei+0x39a kern_stat(c8adac00,806712c,0,e8f34c74) at 0xc061d3cd = kern_stat+0x35 stat(c8adac00,e8f34d04) at 0xc061d37b = stat+0x1b syscall(3b,3b,3b,1,80670ec,...) at 0xc07a9363 = syscall+0x2bf Xint0x80_syscall() at 0xc079456f = Xint0x80_syscall+0x1f --- syscall (188, FreeBSD ELF32, stat), eip = 0x28196477, esp = 0xbfbfdc1c, ebp = 0xbfbfdcb8 --- db kill 9 50746 db c The nfs_reply is sleeping with the PCATCH set. The question is why SIGTSTP does not cause msleep to return with EINTR. The problem is in thread_suspend_check(), not the sleepq code. It happened again (triggered by ctrl-z). INVARIANTS WITNESS provided no help. Is the problem in thread_suspend_check() known? MFC-able from HEAD? I see this diff. I'm not sure it will help, but is there any reason not to try it in 6 (David Xu CC'd since he made this change)? Index: kern_thread.c === RCS file: /base/FreeBSD-CVS/src/sys/kern/kern_thread.c,v retrieving revision 1.216.2.6 retrieving revision 1.235 diff -u -p -r1.216.2.6 -r1.235 --- kern_thread.c 2 Sep 2006 17:29:57 - 1.216.2.6 +++ kern_thread.c 28 Aug 2006 04:24:51 - 1.235 @@ -910,6 +926,10 @@ thread_suspend_check(int return_instead) (p-p_flag P_SINGLE_BOUNDARY) return_instead) return (ERESTART); + /* If thread will exit, flush its pending signals */ + if ((p-p_flag P_SINGLE_EXIT) (p-p_singlethread != td)) + sigqueue_flush(td-td_sigqueue); + mtx_lock_spin(sched_lock); thread_stopped(p); /* ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
[Charset ISO-8859-1 unsupported, filtering to ASCII...] On 10/19/06, Kris Kennaway [EMAIL PROTECTED] wrote: On Thu, Oct 19, 2006 at 02:18:13PM -0700, Jack Vogel wrote: The engineer in our test group has installed 6.2 BETA2 and attempted via a number of tests to reproduce this problem, the machine even shares the em interrupt with usb, and yet so far he has been unsuccessful. What tests is he running? He tried doing something Kip said reliably repro'd the issue, building a big source archive over NFS. Then he has been running a continuous NFS data back and forth copy since, that is still ongoing. Other suggestions? Jack Just out of curiosity, what sort of torture tests does Intel do, in general, on the em driver on FreeBSD? One thing that I've found which works wonders at exposing race conditions is the Smartbits bi-directional IP forwarding test. Put two NICs in a system, configure for it for IP forwarding, then connect the Smartbits to each port and run the SmartApps router test in bi-directional mode. At 64 bytes per frame, it will try to push 2.96 million packets/second through both ports simultaneously (1.48 million in each direction). Of course, you won't actually be able to forward all the traffic, but the interfaces (not to mention the OS) should continue running regardless. This test exercises both the RX and TX paths and generates hundreds of thousands of interrupts per second. You'd be amazed at the sort of things you can discover with it. The downside of course is that a Smartbits with gigE ports isn't cheap, but I'd be surprised if Intel didn't have one kicking around somewhere. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = adamw you're just BEGGING to face the moose = ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
On 10/20/06, Bill Paul [EMAIL PROTECTED] wrote: [Charset ISO-8859-1 unsupported, filtering to ASCII...] On 10/19/06, Kris Kennaway [EMAIL PROTECTED] wrote: On Thu, Oct 19, 2006 at 02:18:13PM -0700, Jack Vogel wrote: The engineer in our test group has installed 6.2 BETA2 and attempted via a number of tests to reproduce this problem, the machine even shares the em interrupt with usb, and yet so far he has been unsuccessful. What tests is he running? He tried doing something Kip said reliably repro'd the issue, building a big source archive over NFS. Then he has been running a continuous NFS data back and forth copy since, that is still ongoing. Other suggestions? Jack Just out of curiosity, what sort of torture tests does Intel do, in general, on the em driver on FreeBSD? One thing that I've found which works wonders at exposing race conditions is the Smartbits bi-directional IP forwarding test. Put two NICs in a system, configure for it for IP forwarding, then connect the Smartbits to each port and run the SmartApps router test in bi-directional mode. At 64 bytes per frame, it will try to push 2.96 million packets/second through both ports simultaneously (1.48 million in each direction). Of course, you won't actually be able to forward all the traffic, but the interfaces (not to mention the OS) should continue running regardless. This test exercises both the RX and TX paths and generates hundreds of thousands of interrupts per second. You'd be amazed at the sort of things you can discover with it. The downside of course is that a Smartbits with gigE ports isn't cheap, but I'd be surprised if Intel didn't have one kicking around somewhere. Oh sure, they have Smartbits and a host of other hardware, but remember that this group tests Windows, Linux, FreeBSD, and a number of special case stuff. And guess what gets the most attention uhuh it isnt us :) The good thing is I believe most of the same battery of tests that run on Linux also get run against FreeBSD, so its significant, but something like what you are talking about is probably only done when there's a problem being investigated. Also, its a different org in our division, I dont know the details of all the tests they run, but they provide me with a steady stream of bug reports so they ARE doing their job :) Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
Bill Paul wrote: [Charset ISO-8859-1 unsupported, filtering to ASCII...] On 10/19/06, Kris Kennaway [EMAIL PROTECTED] wrote: On Thu, Oct 19, 2006 at 02:18:13PM -0700, Jack Vogel wrote: The engineer in our test group has installed 6.2 BETA2 and attempted via a number of tests to reproduce this problem, the machine even shares the em interrupt with usb, and yet so far he has been unsuccessful. What tests is he running? He tried doing something Kip said reliably repro'd the issue, building a big source archive over NFS. Then he has been running a continuous NFS data back and forth copy since, that is still ongoing. Other suggestions? Jack Just out of curiosity, what sort of torture tests does Intel do, in general, on the em driver on FreeBSD? One thing that I've found which works wonders at exposing race conditions is the Smartbits bi-directional IP forwarding test. Put two NICs in a system, configure for it for IP forwarding, then connect the Smartbits to each port and run the SmartApps router test in bi-directional mode. At 64 bytes per frame, it will try to push 2.96 million packets/second through both ports simultaneously (1.48 million in each direction). Of course, you won't actually be able to forward all the traffic, but the interfaces (not to mention the OS) should continue running regardless. This test exercises both the RX and TX paths and generates hundreds of thousands of interrupts per second. You'd be amazed at the sort of things you can discover with it. The downside of course is that a Smartbits with gigE ports isn't cheap, but I'd be surprised if Intel didn't have one kicking around somewhere. -Bill This is exactly the test that Andre and I were running, though only in one direction (I think due to lack of hardware for a full test). Prior to the INTR_FAST change, the machine would live-lock. Now it survives, stays responsive, and drops packets as needed. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
On 10/20/06, Scott Long [EMAIL PROTECTED] wrote: Bill Paul wrote: [Charset ISO-8859-1 unsupported, filtering to ASCII...] On 10/19/06, Kris Kennaway [EMAIL PROTECTED] wrote: On Thu, Oct 19, 2006 at 02:18:13PM -0700, Jack Vogel wrote: The engineer in our test group has installed 6.2 BETA2 and attempted via a number of tests to reproduce this problem, the machine even shares the em interrupt with usb, and yet so far he has been unsuccessful. What tests is he running? He tried doing something Kip said reliably repro'd the issue, building a big source archive over NFS. Then he has been running a continuous NFS data back and forth copy since, that is still ongoing. Other suggestions? Jack Just out of curiosity, what sort of torture tests does Intel do, in general, on the em driver on FreeBSD? One thing that I've found which works wonders at exposing race conditions is the Smartbits bi-directional IP forwarding test. Put two NICs in a system, configure for it for IP forwarding, then connect the Smartbits to each port and run the SmartApps router test in bi-directional mode. At 64 bytes per frame, it will try to push 2.96 million packets/second through both ports simultaneously (1.48 million in each direction). Of course, you won't actually be able to forward all the traffic, but the interfaces (not to mention the OS) should continue running regardless. This test exercises both the RX and TX paths and generates hundreds of thousands of interrupts per second. You'd be amazed at the sort of things you can discover with it. The downside of course is that a Smartbits with gigE ports isn't cheap, but I'd be surprised if Intel didn't have one kicking around somewhere. -Bill This is exactly the test that Andre and I were running, though only in one direction (I think due to lack of hardware for a full test). Prior to the INTR_FAST change, the machine would live-lock. Now it survives, stays responsive, and drops packets as needed. I just checked with our group lead (John Ronciak) and he says I have a Smartbits available to me, so I'm gonna try and get this set up :) Thanks for the suggestion Bill. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bug on BTX
On Thursday 19 October 2006 22:06, Bruce M. Simpson wrote: Hi all, FYI, this change adds 32 bytes to btx leaving 139 bytes free, according to btxld(8). As you probably all know, and just as a reminder, size in boot2 is at a premium -- it can't go over 8192 bytes as this is the boot-sector limit in the BSD disk-label. My other changes trim btx by 48 bytes. I actually plan on MFC'ing this stuff into 6.2. We actually have 100+ free bytes in boot2 right now anyways. Per my IRC discussions with jhb@ : given that BTX reflects the hardware interrupts, we shouldn't need to reprogram the AT-PICs; indeed GRUB does not. This was one of his concerns. We can probably get away with a simple trampoline a la GRUB providing the INTs invoked by BTX or LOADER don't attempt to rewrite or redirect interrupt vectors once we're up and running. BTX currently uses different IDT offsets for the PICs, it puts them right next to each other instead of using 0x70-0x78 (IIRC) for the slave PIC. That can be adjusted though to make BTX use the same IDT offsets as the BIOS in which case we wouldn't have to touch the PIC at all. That would require a larger IDT though, and I'm not sure if the IDT is statically allocated in BTX (if so, it might result in a space problem), however reusing the BIOS IDT offsets would be preferable to re-programming the PICs on every mode switch. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: locked vnode / nfs... requires kill -9 in ddb
On Friday 20 October 2006 12:05, John E Hein wrote: John Baldwin wrote at 10:44 -0400 on Oct 19, 2006: On Thursday 19 October 2006 06:04, Kostik Belousov wrote: On Wed, Oct 18, 2006 at 10:01:45AM -0600, John E Hein wrote: 6.2-PRERELEASE from 20061016 RELENG_6 sources. Locked vnodes 0xc6b7bdd0: tag nfs, type VDIR usecount 2, writecount 0, refcount 8 mountedhere 0 flags (VV_ROOT) v_object 0xc9d84108 ref 0 pages 0 lock type nfs: EXCL (count 1) by thread 0xc8adac00 (pid 50746) with 5 pending fileid 8 fsid 0x300ff06 50746 5 4 600 T+ sh . . dbdb trace 50746 Tracing pid 50746 tid 100231 td 0xc8adac00 sched_switch(c8adac00,0,2) at 0xc05ce0cb = sched_switch+0x173 mi_switch(2,0) at 0xc05c2b0a = mi_switch+0x1ba thread_suspend_check(1,c079e04c,c8adac00,c9206b80,1,...) at 0xc05c722d = thread_suspend_check+0x191 sleepq_catch_signals(c9206b80) at 0xc05db93f = sleepq_catch_signals+0x103 sleepq_wait_sig(c9206b80) at 0xc05dbd96 = sleepq_wait_sig+0xe msleep(c9206b80,c08a6a40,153,c0813379,0) at 0xc05c2652 = msleep+0x25a nfs_reply(c9206b80,0,c8adac00,4,c7ea7100,...) at 0xc06c33ac = nfs_reply+0x244 nfs_request(c6b7bdd0,c6ae2d00,1,c8adac00,c7815280,e8f3488c,e8f34890,e8f34894,c8adac00,e8f348a0) at 0xc06c40a5 = nfs_request+0x3c1 nfs_getattr(e8f348dc) at 0xc06c912b = nfs_getattr+0x11f VOP_GETATTR_APV(c086c700,e8f348dc) at 0xc07b260c = VOP_GETATTR_APV+0x38 nfsspec_access(e8f34a8c,c6bf7c94,0,e8f349a4,c060ca26,...) at 0xc06cebf1 = nfsspec_access+0x85 nfs_access(e8f34a8c) at 0xc06c8b7a = nfs_access+0x122 VOP_ACCESS_APV(c086c700,e8f34a8c) at 0xc07b25b0 = VOP_ACCESS_APV+0x38 nfs_lookup(e8f34b18) at 0xc06c96ff = nfs_lookup+0xd3 VOP_LOOKUP_APV(c086c700,e8f34b18) at 0xc07b22f7 = VOP_LOOKUP_APV+0x43 lookup(e8f34c00) at 0xc060ee79 = lookup+0x4c1 namei(e8f34c00) at 0xc060e71a = namei+0x39a kern_stat(c8adac00,806712c,0,e8f34c74) at 0xc061d3cd = kern_stat+0x35 stat(c8adac00,e8f34d04) at 0xc061d37b = stat+0x1b syscall(3b,3b,3b,1,80670ec,...) at 0xc07a9363 = syscall+0x2bf Xint0x80_syscall() at 0xc079456f = Xint0x80_syscall+0x1f --- syscall (188, FreeBSD ELF32, stat), eip = 0x28196477, esp = 0xbfbfdc1c, ebp = 0xbfbfdcb8 --- db kill 9 50746 db c The nfs_reply is sleeping with the PCATCH set. The question is why SIGTSTP does not cause msleep to return with EINTR. The problem is in thread_suspend_check(), not the sleepq code. It happened again (triggered by ctrl-z). INVARIANTS WITNESS provided no help. Is the problem in thread_suspend_check() known? MFC-able from HEAD? I see this diff. I'm not sure it will help, but is there any reason not to try it in 6 (David Xu CC'd since he made this change)? Index: kern_thread.c === RCS file: /base/FreeBSD-CVS/src/sys/kern/kern_thread.c,v retrieving revision 1.216.2.6 retrieving revision 1.235 diff -u -p -r1.216.2.6 -r1.235 --- kern_thread.c 2 Sep 2006 17:29:57 - 1.216.2.6 +++ kern_thread.c 28 Aug 2006 04:24:51 - 1.235 @@ -910,6 +926,10 @@ thread_suspend_check(int return_instead) (p-p_flag P_SINGLE_BOUNDARY) return_instead) return (ERESTART); + /* If thread will exit, flush its pending signals */ + if ((p-p_flag P_SINGLE_EXIT) (p-p_singlethread != td)) + sigqueue_flush(td-td_sigqueue); + mtx_lock_spin(sched_lock); thread_stopped(p); /* This change is not applicable to 6.x. The bug is likely in both 6.x and HEAD in thread_suspend_check(). -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA C7 support
Oliver Fromme a écrit : Matthieu Michaud wrote: I rent a small server based on a VIA C7 on which I installed a 6.2-PRERELEASE as of today (see dmesg and kernconf attached). It runs fairly well but I wonder if it couldn't be faster. According to padlock(4) man page, crypto hardware support is available by adding padlock, crypto and cryptodev kernel options. I compiled it as modules. I haven't noticed difference between 'openssl speed' and 'openssl speed -engine padlock'. I attached results. I don't know if the openssl command really uses the padlock engine. I doubt it. But with scp the throughput doubles when padlock is enabled on my C3 Nehemiah. So it clearly helps scp. (FAST_IPSEC also benefits from it, but I don't use IPSEC so I don't have numbers.) some basic scp over large file showed it :) Finally, I tried to read 16M from /dev/random and /dev/urandom to look at RNG support. It reads at 2M/s on both device. Comparing to a P4 1.7G and P4 2.8G, it's few : they both performs around 14M/s on almost as recent kernel. There's a difference in quality: I doubt that those 16MB that you got in about one second on the P4 were really as random as the 2 MB that you got on the C7. Also take into account that you usually don't read that much data from /dev/random. Quality is much more important than speed. you are right. do you know an easy way to evaluate this quality ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VIA C7 support
Mike Tancsa a écrit : At 11:37 AM 10/12/2006, Oliver Fromme wrote: Matthieu Michaud wrote: I rent a small server based on a VIA C7 on which I installed a 6.2-PRERELEASE as of today (see dmesg and kernconf attached). It runs fairly well but I wonder if it couldn't be faster. According to padlock(4) man page, crypto hardware support is available by adding padlock, crypto and cryptodev kernel options. I compiled it as modules. I haven't noticed difference between 'openssl speed' and 'openssl speed -engine padlock'. I attached results. I don't know if the openssl command really uses the padlock engine. I doubt it. It will if you tell it to, but remember, its only AES that it will speed up. You wont see a difference in things like 3des etc. Just do the tests for aes Try something like openssl speed -evp aes-256-ecb -engine padlock vs openssl speed -evp aes-256-ecb -engine dynamic On a CPU: VIA C3 Nehemiah+RNG+AES (796.77-MHz 686-class CPU) I get type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256-ecb 37610.62k 142398.18k 389573.81k 678504.21k 868056.96k aes-256-ecb 4923.20k 5143.88k 5222.51k 5256.46k 5276.31k For comparison, here is the same test on a Celeron 2.6 and an AMD 3800 aes-256-ecb 39727.25k41359.33k42596.01k42919.64k 42940.31k aes-256-ecb 27408.65k32035.54k32623.81k32767.08k 32822.06k ok, now i see a difference. on my C7 running a recent 6.2 : aes-128-ecb 140283.57k 509427.16k 1340639.69k 2158707.04k 2626033.49k aes-128-ecb 16956.08k 17668.87k 17894.31k 17951.39k 17967.98k it might explain scp speedup. thanx for pointing it to me :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
Bill Paul wrote: [Charset ISO-8859-1 unsupported, filtering to ASCII...] On 10/19/06, Kris Kennaway [EMAIL PROTECTED] wrote: On Thu, Oct 19, 2006 at 02:18:13PM -0700, Jack Vogel wrote: The engineer in our test group has installed 6.2 BETA2 and attempted via a number of tests to reproduce this problem, the machine even shares the em interrupt with usb, and yet so far he has been unsuccessful. What tests is he running? He tried doing something Kip said reliably repro'd the issue, building a big source archive over NFS. Then he has been running a continuous NFS data back and forth copy since, that is still ongoing. Other suggestions? Jack Just out of curiosity, what sort of torture tests does Intel do, in general, on the em driver on FreeBSD? One thing that I've found which works wonders at exposing race conditions is the Smartbits bi-directional IP forwarding test. Put two NICs in a system, configure for it for IP forwarding, then connect the Smartbits to each port and run the SmartApps router test in bi-directional mode. At 64 bytes per frame, it will try to push 2.96 million packets/second through both ports simultaneously (1.48 million in each direction). Of course, you won't actually be able to forward all the traffic, but the interfaces (not to mention the OS) should continue running regardless. This test exercises both the RX and TX paths and generates hundreds of thousands of interrupts per second. You'd be amazed at the sort of things you can discover with it. The downside of course is that a Smartbits with gigE ports isn't cheap, but I'd be surprised if Intel didn't have one kicking around somewhere. -Bill This is exactly the test that Andre and I were running, though only in one direction (I think due to lack of hardware for a full test). Yes, but did you do it with a Smartbits though, or just with a couple of other FreeBSD machines? Unfortunately, a typical FreeBSD system on its own won't generate frames anywhere near fast enough to really torture test a gigE interface. At best you might hit around 20 to 30 frames/sec. A given Smartbits system doesn't need special hardware to run a bi-directional forwarding test. If you're using SmartApps, you just have to click the Bi-Directional checkbox on the main setup window. (At least, that's how it is with the ones at work.) Being able to flood the link with the Smartbits is also handy for provoking error conditions (RX overruns and TX underruns, mostly), which shows you how well (or not) the driver's error recovery works. In the past I considered creating a kernel module that would grab hold of a given interface and blast traffic through it with as little software overhead as possible (e.g. sending the same mbuf over and over) in order to create my own test system that could hopefully rival the Smartbits, but I never got around to it. I'm not sure that it's really possible without custom hardware though. Prior to the INTR_FAST change, the machine would live-lock. Now it survives, stays responsive, and drops packets as needed. The wide range of failures people seem to be reporting might mean that the driver code itself is not the issue, but that there's an interaction with some other part of the system. This means torture testing the driver itself might not be enough to provoke the problems. Unfortunately, nobody seems to have nailed down a good test case for any of these failures. I strongly suspect people are leaving out details which seem obvious and/or trivial to them, but which are critical to finding the problem. (Oh, I was using SCHED_ULE... was I not supposed to do that? Tee-hee. *curls finger in blonde hair*) Another thing that might be handy is improving the watchdog timeout message so that it dumps the state of the ICR and ICM registers (and maybe some other interesting driver and/or device state). The timeout implies no interrupts were delivered for a Long Time (tm). If the ICM register indicates interrupts have been masked, then that means em_intr_fast() was triggered by and interrupt and it scheduled work, but that work never executed. If that really is what happened, then I can understand the watchdog error occuring. If that's _not_ what happened, them something else is screwed up. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = adamw you're just BEGGING to face the moose = ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
Bill Paul wrote: Yes, but did you do it with a Smartbits though, or just with a couple of other FreeBSD machines? Unfortunately, a typical FreeBSD system on its own won't generate frames anywhere near fast enough to really torture test a gigE interface. At best you might hit around 20 to 30 frames/sec. Yes, it was some model of a Smartbits. A given Smartbits system doesn't need special hardware to run a bi-directional forwarding test. If you're using SmartApps, you just have to click the Bi-Directional checkbox on the main setup window. (At least, that's how it is with the ones at work.) Didn't know the details here. Being able to flood the link with the Smartbits is also handy for provoking error conditions (RX overruns and TX underruns, mostly), which shows you how well (or not) the driver's error recovery works. Yup, tested that =-) In the past I considered creating a kernel module that would grab hold of a given interface and blast traffic through it with as little software overhead as possible (e.g. sending the same mbuf over and over) in order to create my own test system that could hopefully rival the Smartbits, but I never got around to it. I'm not sure that it's really possible without custom hardware though. I tried this. It was too crude. Prior to the INTR_FAST change, the machine would live-lock. Now it survives, stays responsive, and drops packets as needed. The wide range of failures people seem to be reporting might mean that the driver code itself is not the issue, but that there's an interaction with some other part of the system. This means torture testing the driver itself might not be enough to provoke the problems. It's indeed a complex problem, but I haven't ruled out the driver. Shifting timing around in innocent ways seems to be the key. Unfortunately, nobody seems to have nailed down a good test case for any of these failures. I strongly suspect people are leaving out details which seem obvious and/or trivial to them, but which are critical to finding the problem. (Oh, I was using SCHED_ULE... was I not supposed to do that? Tee-hee. *curls finger in blonde hair*) The survey that Kris and I sent out specifically asked about ULE, as well as other 'deceptively obvious' attributes. Another thing that might be handy is improving the watchdog timeout message so that it dumps the state of the ICR and ICM registers (and maybe some other interesting driver and/or device state). The timeout implies no interrupts were delivered for a Long Time (tm). If the ICM register indicates interrupts have been masked, then that means em_intr_fast() was triggered by and interrupt and it scheduled work, but that work never executed. If that really is what happened, then I can understand the watchdog error occuring. If that's _not_ what happened, them something else is screwed up. Yes, instrumenting em_watchdog is on my TODO list, and will hopefully reveal a lot more information here. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
On 10/20/06, Bill Paul [EMAIL PROTECTED] wrote: This is exactly the test that Andre and I were running, though only in one direction (I think due to lack of hardware for a full test). Yes, but did you do it with a Smartbits though, or just with a couple of other FreeBSD machines? Unfortunately, a typical FreeBSD system on its own won't generate frames anywhere near fast enough to really torture test a gigE interface. At best you might hit around 20 to 30 frames/sec. A given Smartbits system doesn't need special hardware to run a bi-directional forwarding test. If you're using SmartApps, you just have to click the Bi-Directional checkbox on the main setup window. (At least, that's how it is with the ones at work.) Being able to flood the link with the Smartbits is also handy for provoking error conditions (RX overruns and TX underruns, mostly), which shows you how well (or not) the driver's error recovery works. In the past I considered creating a kernel module that would grab hold of a given interface and blast traffic through it with as little software overhead as possible (e.g. sending the same mbuf over and over) in order to create my own test system that could hopefully rival the Smartbits, but I never got around to it. I'm not sure that it's really possible without custom hardware though. Our Linux team has this, as far as I know its only been used by our internal test types though, I have not seen the code, but I take this as evidence that it IS doable :) Prior to the INTR_FAST change, the machine would live-lock. Now it survives, stays responsive, and drops packets as needed. The wide range of failures people seem to be reporting might mean that the driver code itself is not the issue, but that there's an interaction with some other part of the system. This means torture testing the driver itself might not be enough to provoke the problems. Unfortunately, nobody seems to have nailed down a good test case for any of these failures. I strongly suspect people are leaving out details which seem obvious and/or trivial to them, but which are critical to finding the problem. (Oh, I was using SCHED_ULE... was I not supposed to do that? Tee-hee. *curls finger in blonde hair*) Another thing that might be handy is improving the watchdog timeout message so that it dumps the state of the ICR and ICM registers (and maybe some other interesting driver and/or device state). The timeout implies no interrupts were delivered for a Long Time (tm). If the ICM register indicates interrupts have been masked, then that means em_intr_fast() was triggered by and interrupt and it scheduled work, but that work never executed. If that really is what happened, then I can understand the watchdog error occuring. If that's _not_ what happened, them something else is screwed up. Jesse Brandeburg just did an interesting hack for the Linux driver, I was considering trying to code an equivalent thing up for us. We have evidence that on some AMD based systems there are writebacks that get lost, since the TX cleanup relies on the DD being set you are hosed when this happens. What he did was make a cleanup routine that ONLY uses the head and tail pointers and NOT the done bit. Then, in the watchdog routine, if there is evidence of this problem it will switch the cleanup function pointer to this alternate clean code. At least one user that was having a problem has reported this solved it. It may be one of the issues hitting us as well. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
Just out of curiosity, what sort of torture tests does Intel do, in general, on the em driver on FreeBSD? One thing that I've found which works wonders at exposing race conditions is the Smartbits bi-directional IP forwarding test. Put two NICs in a system, configure for it for IP forwarding, then connect the Smartbits to each port and run the SmartApps router test in bi-directional mode. At 64 bytes per frame, it will try to push 2.96 million packets/second through both ports simultaneously (1.48 million in each direction). Of course, you won't actually be able to forward all the traffic, but the interfaces (not to mention the OS) should continue running regardless. This test exercises both the RX and TX paths and generates hundreds of thousands of interrupts per second. You'd be amazed at the sort of things you can discover with it. The downside of course is that a Smartbits with gigE ports isn't cheap, but I'd be surprised if Intel didn't have one kicking around somewhere. Oh sure, they have Smartbits and a host of other hardware, but remember that this group tests Windows, Linux, FreeBSD, and a number of special case stuff. And guess what gets the most attention uhuh it isnt us :) Yeah yeah, I know. The good thing is I believe most of the same battery of tests that run on Linux also get run against FreeBSD, Okay, but what are these tests? Inquiring minds really do want to know. :) so its significant, but something like what you are talking about is probably only done when there's a problem being investigated. Uhm. Well, in my VxWorks driver development process, the Smartbits bi-directional torture test is mandatory (except in cases where the hardware won't permit it, i.e. boards with only one ethernet port). I decided it should be so after encountering multiple pre-existing VxWorks drivers that I could clobber with a simple burst of UDP traffic from ttcp running on my office workstation. I would rather not have my own code make me look that foolish. (I look foolish for plenty of other reasons.) The amount of time needed to set up the test is trivial, assuming you've already got a test system up and running with your driver code, and it doesn't take that long to run. Of course, I'm biased since I've run the tests many times, and have easy access to the hardware and software. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = adamw you're just BEGGING to face the moose = ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Hard lock on 6.1-STABLE
It's taken me a while to narrow down what this is, but today I finally narrowed it all the way down. High network load on the system causes it to hard lock, nothing but pulling the plug will get any response. The network interface is nve on an Asus A8N-SLI. The magic bullet appears to be: bit torrent downloading/seeding at least two torrents. Doesn't matter what client your using. I've done this using Azureus and Ktorrent both. FTP'ing something (either direction) from the box. I've gone so far as to throttle the ftp client to 300K/s, and it will still do it. Things worth noting: I've narrowed this down by doing stupid things to try to make it crash, such as building world+3 or 4 other large things at once, moving large files between disks, etc. Many things have triggered this (NFS activity, etc) but the only common thread I found was network activity, since it's done this with and without NFS running (I wanted to eleminate NFS since it seems to be a bit unstable at the moment) doing a multitude of tasks. The network cable connecting this system to the switch is perfect. The switch rarely shows any collisions unless network load is high on this box, then the collision light will come on nearly constantly. dmesg: [EMAIL PROTECTED](~)# dmesg Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.1-STABLE #6: Sat Sep 2 04:56:20 CDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/Colossus Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (2010.31-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x20fb1 Stepping = 1 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x1SSE3 AMD Features=0xe2500800SYSCALL,NX,MMX+,FFXSR,LM,3DNow+,3DNow AMD Features2=0x3LAHF,CMP Cores per package: 2 real memory = 1073676288 (1023 MB) avail memory = 1037369344 (989 MB) ACPI APIC Table: Nvidia AWRDACPI FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 1.1 irqs 0-23 on motherboard acpi0: Nvidia AWRDACPI on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: memory at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 1.0 on pci0 isa0: ISA bus on isab0 pci0: serial bus, SMBus at device 1.1 (no driver attached) ohci0: OHCI (generic) USB controller mem 0xdb102000-0xdb102fff irq 21 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: OHCI (generic) USB controller on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 10 ports with 10 removable, self powered ehci0: NVIDIA nForce4 USB 2.0 controller mem 0xfeb0-0xfeb000ff irq 22 at device 2.1 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 4 ports each: usb0 usb1: NVIDIA nForce4 USB 2.0 controller on ehci0 usb1: USB revision 2.0 uhub1: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub1: 10 ports with 10 removable, self powered pcm0: nVidia nForce4 port 0xd400-0xd4ff,0xd800-0xd8ff mem 0xdb101000-0xdb101fff irq 23 at device 4.0 on pci0 pcm0: Avance Logic ALC850 AC97 Codec atapci0: nVidia nForce CK804 UDMA133 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 pcib1: ACPI PCI-PCI bridge at device 9.0 on pci0 pci5: ACPI PCI bus on pcib1 fwohci0: Texas Instruments TSB43AB22/A mem 0xdb004000-0xdb0047ff,0xdb00-0xdb003fff irq 16 at device 11.0 on pci5 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:d8:00:00:86:18:47 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 sbp0: SBP-2/SCSI over FireWire on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop = 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) nve0: NVIDIA nForce MCP9 Networking Adapter port 0xd000-0xd007 mem 0xdb10-0xdb100fff irq 21 at device 10.0 on pci0 nve0: Ethernet address 00:15:f2:7f:80:86 miibus0: MII bus on nve0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0:
Re: em network issues
[...] Another thing that might be handy is improving the watchdog timeout message so that it dumps the state of the ICR and ICM registers (and maybe some other interesting driver and/or device state). The timeout implies no interrupts were delivered for a Long Time (tm). If the ICM register indicates interrupts have been masked, then that means em_intr_fast() was triggered by and interrupt and it scheduled work, but that work never executed. If that really is what happened, then I can understand the watchdog error occuring. If that's _not_ what happened, them something else is screwed up. Jesse Brandeburg just did an interesting hack for the Linux driver, I was considering trying to code an equivalent thing up for us. We have evidence that on some AMD based systems there are writebacks that get lost, since the TX cleanup relies on the DD being set you are hosed when this happens. What he did was make a cleanup routine that ONLY uses the head and tail pointers and NOT the done bit. Then, in the watchdog routine, if there is evidence of this problem it will switch the cleanup function pointer to this alternate clean code. Oho, I didn't realize the 8254x had producer/consumer indexes like this. Hm. But the documentation for the Transmit Descriptor Head register says: Reading the transmit descriptor head to determine which buffers have been used (and can be returned to the memory pool) is not reliable. There's a similar notation for the Receive Descriptor Head register. I wonder what's unreliable about it. At least one user that was having a problem has reported this solved it. It may be one of the issues hitting us as well. Switching from testing the descriptor completion bits to using the consumer indexes should be pretty straightforward. It's worth a shot at any rate. -Bill -- = -Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu [EMAIL PROTECTED] | Wind River Systems = adamw you're just BEGGING to face the moose = ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: locked vnode / nfs... requires kill -9 in ddb
On Thursday 19 October 2006 18:04, Kostik Belousov wrote: The nfs_reply is sleeping with the PCATCH set. The question is why SIGTSTP does not cause msleep to return with EINTR. I have not been tracking the thread. but if the thread is sleeping with PCATCH, the SIGTSTP should cause the process to stop unless the signal is masked by sigprocmask or the signal has an action handler been set, this is a correct behavior. David Xu ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: locked vnode / nfs... requires kill -9 in ddb
On Saturday 21 October 2006 00:05, John E Hein wrote: The problem is in thread_suspend_check(), not the sleepq code. It happened again (triggered by ctrl-z). INVARIANTS WITNESS provided no help. Is the problem in thread_suspend_check() known? MFC-able from HEAD? I don't think thread_suspend_check itself has problem. I see this diff. I'm not sure it will help, but is there any reason not to try it in 6 (David Xu CC'd since he made this change)? Index: kern_thread.c === RCS file: /base/FreeBSD-CVS/src/sys/kern/kern_thread.c,v retrieving revision 1.216.2.6 retrieving revision 1.235 diff -u -p -r1.216.2.6 -r1.235 --- kern_thread.c 2 Sep 2006 17:29:57 - 1.216.2.6 +++ kern_thread.c 28 Aug 2006 04:24:51 - 1.235 @@ -910,6 +926,10 @@ thread_suspend_check(int return_instead) (p-p_flag P_SINGLE_BOUNDARY) return_instead) return (ERESTART); + /* If thread will exit, flush its pending signals */ + if ((p-p_flag P_SINGLE_EXIT) (p-p_singlethread != td)) + sigqueue_flush(td-td_sigqueue); + mtx_lock_spin(sched_lock); thread_stopped(p); /* This patch is only for -CURRENT, it is used to release memory occupied by signal queue which does not exist in -STABLE, it is only called when the process is exiting. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em network issues
On 10/20/06, Bill Paul [EMAIL PROTECTED] wrote: [...] Another thing that might be handy is improving the watchdog timeout message so that it dumps the state of the ICR and ICM registers (and maybe some other interesting driver and/or device state). The timeout implies no interrupts were delivered for a Long Time (tm). If the ICM register indicates interrupts have been masked, then that means em_intr_fast() was triggered by and interrupt and it scheduled work, but that work never executed. If that really is what happened, then I can understand the watchdog error occuring. If that's _not_ what happened, them something else is screwed up. Jesse Brandeburg just did an interesting hack for the Linux driver, I was considering trying to code an equivalent thing up for us. We have evidence that on some AMD based systems there are writebacks that get lost, since the TX cleanup relies on the DD being set you are hosed when this happens. What he did was make a cleanup routine that ONLY uses the head and tail pointers and NOT the done bit. Then, in the watchdog routine, if there is evidence of this problem it will switch the cleanup function pointer to this alternate clean code. Oho, I didn't realize the 8254x had producer/consumer indexes like this. Hm. But the documentation for the Transmit Descriptor Head register says: Reading the transmit descriptor head to determine which buffers have been used (and can be returned to the memory pool) is not reliable. There's a similar notation for the Receive Descriptor Head register. I wonder what's unreliable about it. At least one user that was having a problem has reported this solved it. It may be one of the issues hitting us as well. Switching from testing the descriptor completion bits to using the consumer indexes should be pretty straightforward. It's worth a shot at any rate. I have not yet looked at Jesse's code to see if he does anything fancy but there is one other driver that I know of on our hardware (and no its not for that so-called OS from Redmond) that has always done this so it must not be THAT unreliable. It just isnt using the full capability of the hardware, but if it works :) Jesse's code is supposed to be on our driver site on sourceforge, I just have been too busy to go look for it, but its public. BTW, I got a Smartbits unit in my cubicle today, got software installed and hardware almost there, not quite done yet. It sure can pump LOTS of packets though :) Will report results as I get them. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: locked vnode / nfs... requires kill -9 in ddb
On Sat, Oct 21, 2006 at 08:25:00AM +0800, David Xu wrote: On Thursday 19 October 2006 18:04, Kostik Belousov wrote: The nfs_reply is sleeping with the PCATCH set. The question is why SIGTSTP does not cause msleep to return with EINTR. I have not been tracking the thread. but if the thread is sleeping with PCATCH, the SIGTSTP should cause the process to stop unless the signal is masked by sigprocmask or the signal has an action handler been set, this is a correct behavior. David, as I understand the report, the following happens. The nfs mount point with intr option issued the request and waits for the reply. Some vnode locks are held while waiting. Code needs to catch the signals to abort the operation on user request. It uses msleep with PCATCH. The thread in question has td_locks 0. The SIGTSTP is delivered, and thread is stopped, while holding vnode lock. How this situation shall be handled ? Namely, how to sleep while having the ability to safely clean up on attempt of stopping ? Masking SIGTSTP is not the option, due to SIGSTOP having the same results and not being blockable. [Would it be right to stop the threads only on returning from kernel to user mode ?] pgpSWZ6fPc91w.pgp Description: PGP signature
