From guru at unixarea.de Sun Nov 1 07:26:24 2009 From: guru at unixarea.de (Matthias Apitz) Date: Sun Nov 1 07:26:31 2009 Subject: [kde-freebsd] after compiling x11/kde4 problems with /usr/local/bin/startkde (SOLVED) In-Reply-To: <20091030151754.GA5849@current.Sisis.de> References: <20091030151754.GA5849@current.Sisis.de> Message-ID: <20091101072629.GA2334@current.Sisis.de> El d?a Friday, October 30, 2009 a las 04:17:55PM +0100, Matthias Apitz escribi?: > > Hello, > > I have in a VM a 9-CURRENT and compiled/installed from the ports first > x11/kde3 (which worked fine) and now in addition x11/kde4 (which comes > up also fine). > > But, > > A start of KDE3 from ~/.xinitrc via exec /usr/local/bin/startkde > complains in the following code: > > # We set LD_BIND_NOW to increase the efficiency of kdeinit. > # kdeinit unsets this variable before loading applications. > LD_BIND_NOW=true start_kdeinit_wrapper --new-startup +kcminit_startup > if test $? -ne 0; then > # Startup error > echo 'startkde: Could not start kdeinit. Check your installation.' 1>&2 > xmessage -geometry 500x100 "Could not start kdeinit. Check your installation." > fi > > i.e. it brings up this xmessage box and in the log files I can see that > 'start_kdeinit_wrapper' SIGABORT's. The KDE desktop itself comes up > fine. This is, as I said, after compiling the port x11/kde4. The file > /usr/local/bin/start_kdeinit_wrapper is not touched by the port x11/kde4 > and neither the shared libs it is depending: > > $ ldd /usr/local/bin/start_kdeinit_wrapper > /usr/local/bin/start_kdeinit_wrapper: > libjpeg.so.10 => /usr/local/lib/libjpeg.so.10 (0x2808e000) > libc.so.7 => /lib/libc.so.7 (0x280c2000) > > What could cause this behaviour? Thanks +Cc: freebsd-current I digged into that deeper with the sources... start_kdeinit_wrapper -> start_kdeinit -> kdeinit is (on non-Linux) just an execvp(2) chain of the above three programs; on FreeBSD it would not even be necessary because non of them runs with setuid on execution. As mentioned, the three programs /usr/local/bin/start_kdeinit_wrapper /usr/local/bin/start_kdeinit /usr/local/bin/kdeinit have been compiled on -CURRENT r197801 and have been untouched and working since October, 16. On October 30, I compiled in addition the port x11/kde4, which does not touch the above programs and also not the shared libs used by them; after the installation of x11/kde4 the start_kdeinit_wrapper now aborts: $ /usr/local/bin/start_kdeinit_wrapper Abort trap: 6 it does not abort when you set # sysctl security.bsd.map_at_zero=1 security.bsd.map_at_zero: 0 -> 1 I think that security.bsd.map_at_zero was already 0 before compiling x11/kde4, i.e. no part of KDE4 changed this sysctl value; so it remains open, what caused this effect, but at least it is working again; Thx matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu From hselasky at c2i.net Sun Nov 1 09:06:54 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Nov 1 09:07:00 2009 Subject: Host OS (OS X 10.6.1) panic when booting 8.0-RC2 in VirtualBox 3.0.10 In-Reply-To: <31d643300910311306m6caa73cfi8930465e43773ff4@mail.gmail.com> References: <31d643300910311245r593326e1me8574bdff5198b51@mail.gmail.com> <31d643300910311306m6caa73cfi8930465e43773ff4@mail.gmail.com> Message-ID: <200911011008.06891.hselasky@c2i.net> On Saturday 31 October 2009 21:06:36 Matthias Rampke wrote: > On Sat, Oct 31, 2009 at 8:45 PM, Matthias Rampke > > wrote: > > Hello, > > > > I have been experiencing reproducible kernel panics in Mac OS X 10.6.1 > > when booting 8.0-RC1 and -RC2 (amd64) in a VirtualBox VM. > > > > I had a (mostly pristine) 7.2-RELEASE running in this VM and tried to > > upgrade to 8.0-RC2 with freebsd-update. > > This does not happen in a new, freshly installed VM. Now it hangs at > usbus initialization, but I suppose that's a different story (the > pains of using USB with VirtualBox, they never end). > > Any ideas what went wrong with the update? And if you turn off USB support in virtual box? --HPS From hselasky at c2i.net Sun Nov 1 09:41:50 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Nov 1 09:41:56 2009 Subject: Host OS (OS X 10.6.1) panic when booting 8.0-RC2 in VirtualBox 3.0.10 Message-ID: <200911011043.02614.hselasky@c2i.net> On Saturday 31 October 2009 21:06:36 Matthias Rampke wrote: > On Sat, Oct 31, 2009 at 8:45 PM, Matthias Rampke > > wrote: > > Hello, > > > > I have been experiencing reproducible kernel panics in Mac OS X 10.6.1 > > when booting 8.0-RC1 and -RC2 (amd64) in a VirtualBox VM. > > > > I had a (mostly pristine) 7.2-RELEASE running in this VM and tried to > > upgrade to 8.0-RC2 with freebsd-update. > > This does not happen in a new, freshly installed VM. Now it hangs at > usbus initialization, but I suppose that's a different story (the > pains of using USB with VirtualBox, they never end). > > Any ideas what went wrong with the update? Hi, I just booted FreeBSD 8.0 RC-2 the live ISO in Virtual box (3.0.8) on a MAC and I don't see any problems. Are you sure that the /boot/kernel/ is free from stale modules from FreeBSD 7.x ? --HPS From christof.schulze at gmx.com Sun Nov 1 09:58:26 2009 From: christof.schulze at gmx.com (Christof Schulze) Date: Sun Nov 1 09:58:34 2009 Subject: [patch] USB video support in KDE4 + sane + more under FreeBSD In-Reply-To: <200910111158.14692.hselasky@freebsd.org> References: <200910111158.14692.hselasky@freebsd.org> Message-ID: <200910251910.25269.christof.schulze@gmx.com> Am Sonntag 11 Oktober 2009 11:58:11 schrieb Hans Petter Selasky: > Hi, > > [USB webcam patches] Thank you Hans, it is good to see that there is some activity with webcams and FreeBSD as I did not get mine to run yet. I will give it a try as soon as possible Christof -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: This is a digitally signed message part. Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091101/fef6ff1d/attachment.pgp From rwatson at FreeBSD.org Sun Nov 1 10:32:25 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Nov 1 10:32:31 2009 Subject: [kde-freebsd] after compiling x11/kde4 problems with /usr/local/bin/startkde (SOLVED) In-Reply-To: <20091101072629.GA2334@current.Sisis.de> References: <20091030151754.GA5849@current.Sisis.de> <20091101072629.GA2334@current.Sisis.de> Message-ID: On Sun, 1 Nov 2009, Matthias Apitz wrote: >> i.e. it brings up this xmessage box and in the log files I can see that >> 'start_kdeinit_wrapper' SIGABORT's. The KDE desktop itself comes up fine. >> This is, as I said, after compiling the port x11/kde4. The file >> /usr/local/bin/start_kdeinit_wrapper is not touched by the port x11/kde4 >> and neither the shared libs it is depending: >> >> $ ldd /usr/local/bin/start_kdeinit_wrapper >> /usr/local/bin/start_kdeinit_wrapper: >> libjpeg.so.10 => /usr/local/lib/libjpeg.so.10 (0x2808e000) >> libc.so.7 => /lib/libc.so.7 (0x280c2000) Could you show us readelf -l /usr/local/bin/start_kdeinit_wrapper > it does not abort when you set > > # sysctl security.bsd.map_at_zero=1 > security.bsd.map_at_zero: 0 -> 1 > > I think that security.bsd.map_at_zero was already 0 before compiling > x11/kde4, i.e. no part of KDE4 changed this sysctl value; so it remains > open, what caused this effect, but at least it is working again; Could you confirm you are running with a userspace/kernel of at least r198203 (the date of the last PIE-related fix following a move to disallowing NULL mappings). Robert From guru at unixarea.de Sun Nov 1 10:39:29 2009 From: guru at unixarea.de (Matthias Apitz) Date: Sun Nov 1 10:39:36 2009 Subject: [kde-freebsd] after compiling x11/kde4 problems with /usr/local/bin/startkde (SOLVED) In-Reply-To: References: <20091030151754.GA5849@current.Sisis.de> <20091101072629.GA2334@current.Sisis.de> Message-ID: <20091101103934.GA3004@current.Sisis.de> El d?a Sunday, November 01, 2009 a las 10:32:24AM +0000, Robert Watson escribi?: > > On Sun, 1 Nov 2009, Matthias Apitz wrote: > > >>i.e. it brings up this xmessage box and in the log files I can see that > >>'start_kdeinit_wrapper' SIGABORT's. The KDE desktop itself comes up fine. > >>This is, as I said, after compiling the port x11/kde4. The file > >>/usr/local/bin/start_kdeinit_wrapper is not touched by the port x11/kde4 > >>and neither the shared libs it is depending: > >> > >>$ ldd /usr/local/bin/start_kdeinit_wrapper > >>/usr/local/bin/start_kdeinit_wrapper: > >> libjpeg.so.10 => /usr/local/lib/libjpeg.so.10 (0x2808e000) > >> libc.so.7 => /lib/libc.so.7 (0x280c2000) > > Could you show us readelf -l /usr/local/bin/start_kdeinit_wrapper Here we go: $ readelf -l /usr/local/bin/start_kdeinit_wrapper Elf file type is EXEC (Executable file) Entry point 0x8048480 There are 6 program headers, starting at offset 52 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align PHDR 0x000034 0x08048034 0x08048034 0x000c0 0x000c0 R E 0x4 INTERP 0x0000f4 0x080480f4 0x080480f4 0x00015 0x00015 R 0x1 [Requesting program interpreter: /libexec/ld-elf.so.1] LOAD 0x000000 0x08048000 0x08048000 0x006a8 0x006a8 R E 0x1000 LOAD 0x0006a8 0x080496a8 0x080496a8 0x00104 0x0010c RW 0x1000 DYNAMIC 0x0006b8 0x080496b8 0x080496b8 0x000c0 0x000c0 RW 0x4 NOTE 0x00010c 0x0804810c 0x0804810c 0x00018 0x00018 R 0x4 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_ r .rel.plt .init .plt .text .fini .rodata 03 .data .eh_frame .dynamic .ctors .dtors .jcr .got .bss 04 .dynamic 05 .note.ABI-tag > >it does not abort when you set > > > ># sysctl security.bsd.map_at_zero=1 > >security.bsd.map_at_zero: 0 -> 1 > > > >I think that security.bsd.map_at_zero was already 0 before compiling > >x11/kde4, i.e. no part of KDE4 changed this sysctl value; so it remains > >open, what caused this effect, but at least it is working again; > > Could you confirm you are running with a userspace/kernel of at least > r198203 (the date of the last PIE-related fix following a move to > disallowing NULL mappings). NAK, userland and kernel is: $ uname -a FreeBSD vm-azul.Sisis.de 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r197801: Mon Oct 12 13:33:32 CEST 2009 guru@vm-azul.Sisis.de:/usr/obj/usr/src/sys/GENERIC i386 Thx matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu From rwatson at FreeBSD.org Sun Nov 1 10:45:42 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Sun Nov 1 10:45:49 2009 Subject: [kde-freebsd] after compiling x11/kde4 problems with /usr/local/bin/startkde (SOLVED) In-Reply-To: <20091101103934.GA3004@current.Sisis.de> References: <20091030151754.GA5849@current.Sisis.de> <20091101072629.GA2334@current.Sisis.de> <20091101103934.GA3004@current.Sisis.de> Message-ID: On Sun, 1 Nov 2009, Matthias Apitz wrote: >> Could you confirm you are running with a userspace/kernel of at least >> r198203 (the date of the last PIE-related fix following a move to >> disallowing NULL mappings). > > NAK, userland and kernel is: > > $ uname -a FreeBSD vm-azul.Sisis.de 9.0-CURRENT FreeBSD 9.0-CURRENT #0 > r197801: Mon Oct 12 13:33:32 CEST 2009 > guru@vm-azul.Sisis.de:/usr/obj/usr/src/sys/GENERIC i386 Sounds like an upgrade should fix this -- if not, please let us know ASAP as it might be an issue for 8.0 as well. Robert From matthias.rampke at googlemail.com Sun Nov 1 11:44:35 2009 From: matthias.rampke at googlemail.com (Matthias Rampke) Date: Sun Nov 1 11:44:42 2009 Subject: Host OS (OS X 10.6.1) panic when booting 8.0-RC2 in VirtualBox 3.0.10 In-Reply-To: References: <31d643300910311245r593326e1me8574bdff5198b51@mail.gmail.com> <31d643300910311306m6caa73cfi8930465e43773ff4@mail.gmail.com> Message-ID: <31d643300911010344u680c1c4fj87d7654b12380af1@mail.gmail.com> On Sat, Oct 31, 2009 at 11:03 PM, Robert Watson wrote: > > I'd suggest > making a backup copy of the bad VM so that you can trigger it on demand > later. done. > >> This does not happen in a new, freshly installed VM. Now it hangs at usbus >> initialization, but I suppose that's a different story (the pains of using >> USB with VirtualBox, they never end). > > This, on the other hand, could be our bug; there's a new USB stack in 8.0. > ?I suggest creating a new thread for that issue with a usb-related subject > line to make sure the right folk see it. > > Robert > No need, the problem resolved itself by de- and reactivating USB in VBox (thanks HPS). This is definitely not a FreeBSD-related problem, I have been having problems accessing a specific USB drive from within VMs, both FreeBSD and OpenSolaris, and that one appears to have been the problem here as well. So, the current status is: The cleanly installed 8.0-RC2 works, the updated one not. So this is either my bad or the freebsd-update did something wrong. I'll try to find out what and keep you posted. thx for all the suggestions, M. -- Matthias Rampke +49 179 - 166 09 18 http://www.matthias-rampke.de/ From rwatson at freebsd.org Sun Nov 1 12:28:35 2009 From: rwatson at freebsd.org (Robert N. M. Watson) Date: Sun Nov 1 12:28:42 2009 Subject: Host OS (OS X 10.6.1) panic when booting 8.0-RC2 in VirtualBox 3.0.10 In-Reply-To: <31d643300911010344u680c1c4fj87d7654b12380af1@mail.gmail.com> References: <31d643300910311245r593326e1me8574bdff5198b51@mail.gmail.com> <31d643300910311306m6caa73cfi8930465e43773ff4@mail.gmail.com> <31d643300911010344u680c1c4fj87d7654b12380af1@mail.gmail.com> Message-ID: <3B6CC16F-DC7C-4D95-AC68-0B14C3741A30@freebsd.org> On 1 Nov 2009, at 11:44, Matthias Rampke wrote: > So, the current status is: The cleanly installed 8.0-RC2 works, the > updated one not. So this is either my bad or the freebsd-update did > something wrong. I'll try to find out what and keep you posted. If they're supposed to be the same binary kernel (check the version string/etc on early boot), then it might be worth simply doing md5 sums and seeing if they are the same (likewise loader binaries and kernel modules). Is there any chance you have non-base system kernel modules installed in /boot/modules or the like? Robert From guru at unixarea.de Sun Nov 1 13:08:23 2009 From: guru at unixarea.de (Matthias Apitz) Date: Sun Nov 1 13:08:30 2009 Subject: [kde-freebsd] after compiling x11/kde4 problems with /usr/local/bin/startkde (SOLVED) In-Reply-To: References: <20091030151754.GA5849@current.Sisis.de> <20091101072629.GA2334@current.Sisis.de> <20091101103934.GA3004@current.Sisis.de> Message-ID: <20091101130820.GA3658@current.Sisis.de> El d?a Sunday, November 01, 2009 a las 10:45:41AM +0000, Robert Watson escribi?: > > On Sun, 1 Nov 2009, Matthias Apitz wrote: > > >>Could you confirm you are running with a userspace/kernel of at least > >>r198203 (the date of the last PIE-related fix following a move to > >>disallowing NULL mappings). > > > >NAK, userland and kernel is: > > > >$ uname -a FreeBSD vm-azul.Sisis.de 9.0-CURRENT FreeBSD 9.0-CURRENT #0 > >r197801: Mon Oct 12 13:33:32 CEST 2009 > >guru@vm-azul.Sisis.de:/usr/obj/usr/src/sys/GENERIC i386 > > Sounds like an upgrade should fix this -- if not, please let us know ASAP > as it might be an issue for 8.0 as well. Robert, do you have an idea why this (with the same kernel/userland) only shows up after installing the port x11/kde4? matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu From kostikbel at gmail.com Sun Nov 1 13:13:39 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Nov 1 13:13:46 2009 Subject: [kde-freebsd] after compiling x11/kde4 problems with /usr/local/bin/startkde (SOLVED) In-Reply-To: <20091101130820.GA3658@current.Sisis.de> References: <20091030151754.GA5849@current.Sisis.de> <20091101072629.GA2334@current.Sisis.de> <20091101103934.GA3004@current.Sisis.de> <20091101130820.GA3658@current.Sisis.de> Message-ID: <20091101131334.GO2147@deviant.kiev.zoral.com.ua> On Sun, Nov 01, 2009 at 02:08:20PM +0100, Matthias Apitz wrote: > El d?a Sunday, November 01, 2009 a las 10:45:41AM +0000, Robert Watson escribi?: > > > > > On Sun, 1 Nov 2009, Matthias Apitz wrote: > > > > >>Could you confirm you are running with a userspace/kernel of at least > > >>r198203 (the date of the last PIE-related fix following a move to > > >>disallowing NULL mappings). > > > > > >NAK, userland and kernel is: > > > > > >$ uname -a FreeBSD vm-azul.Sisis.de 9.0-CURRENT FreeBSD 9.0-CURRENT #0 > > >r197801: Mon Oct 12 13:33:32 CEST 2009 > > >guru@vm-azul.Sisis.de:/usr/obj/usr/src/sys/GENERIC i386 > > > > Sounds like an upgrade should fix this -- if not, please let us know ASAP > > as it might be an issue for 8.0 as well. > > Robert, do you have an idea why this (with the same kernel/userland) > only shows up after installing the port x11/kde4? The only way to understand what happen there is to ktrace the whole process tree, and then look up execve(2) of which binary causes SIGABRT. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091101/92bd28b8/attachment.pgp From rwatson at FreeBSD.org Sun Nov 1 13:17:45 2009 From: rwatson at FreeBSD.org (Robert N. M. Watson) Date: Sun Nov 1 13:17:52 2009 Subject: [kde-freebsd] after compiling x11/kde4 problems with /usr/local/bin/startkde (SOLVED) In-Reply-To: <20091101130820.GA3658@current.Sisis.de> References: <20091030151754.GA5849@current.Sisis.de> <20091101072629.GA2334@current.Sisis.de> <20091101103934.GA3004@current.Sisis.de> <20091101130820.GA3658@current.Sisis.de> Message-ID: <8514BDB1-FB1B-4B7F-8050-ED01D446B07F@FreeBSD.org> On 1 Nov 2009, at 13:08, Matthias Apitz wrote: >>> $ uname -a FreeBSD vm-azul.Sisis.de 9.0-CURRENT FreeBSD 9.0- >>> CURRENT #0 >>> r197801: Mon Oct 12 13:33:32 CEST 2009 >>> guru@vm-azul.Sisis.de:/usr/obj/usr/src/sys/GENERIC i386 >> >> Sounds like an upgrade should fix this -- if not, please let us >> know ASAP >> as it might be an issue for 8.0 as well. > > Robert, do you have an idea why this (with the same kernel/userland) > only shows up after installing the port x11/kde4? KDE uses some pre-linking techniques to reduce startup time for applications; I'm not sure what the current version of the code does exactly, but it wouldn't surprise me if it involves PIE executables, which were known to have problems with our null-mapping prevention until recent bug fixes to rtld. If the problem goes away with an upgrade to a new userspace/kernel, I wouldn't worry too much about it. We added the null-mapping prevention a few weeks ago, and later discovered it interacted badly with bugs in our handling of PIE in- kernel and in rtld. Most likely (if the problem goes away with an upgrade), you just ended up with a bad combination of the two that was resolved. Robert From wgodfrey at ena.com Sun Nov 1 16:42:30 2009 From: wgodfrey at ena.com (Weldon Godfrey) Date: Sun Nov 1 17:15:34 2009 Subject: amd64/140067: [boot] 8.0-RC2 from ISO, after install, hangs on boot right before loader In-Reply-To: <200910290330.n9T3U1WZ055689@freefall.freebsd.org> References: Your message of Thu, 29 Oct 2009 03:28:50 GMT<200910290328.n9T3SoGC018607@www.freebsd.org> <200910290330.n9T3U1WZ055689@freefall.freebsd.org> Message-ID: I went ahead and tested booting 8.0-RC2 in the Dell with the Perc5/I and a spare 3ware card, it booted Ok, I swapped the computers around, this would mean I would try to boot with our 3ware controller and with our drive chasis attached and using the Perc5/I, it hung at "-" after boot manager again. I disconnected the drive chasis (we have two SAS chasis with a total of 24 drive). It booted. I had thought I tried this before bit this time it worked. I tried just attaching 1 chasis and 12 drives. It locked up at the "-" again I went into the 3ware controller and disabled the ability to boot from the 3ware card (we don't need to boot from it anyway), and with both chasis attached, it worked. We went ahead and went back to the computer with a PERC6/I controller and it worked with the 3ware BIOS set not able to boot. So it appears, that something has happened during the boot/loader process in 8.0-RC2 that doesn't like the 3ware controller advertising its drives as bootable. This ticket is attached to amd64 but that was my mistake. This problem happens pre-kernel. Let me know if someone can change the category of if you prefer for me to submit a new PR. Thanks!!! Weldon -----Original Message----- From: FreeBSD-gnats-submit@FreeBSD.org [mailto:FreeBSD-gnats-submit@FreeBSD.org] Sent: Wednesday, October 28, 2009 10:30 PM To: Weldon Godfrey Subject: Re: amd64/140067: [boot] 8.0-RC2 from ISO, after install, hangs on boot right before loader Thank you very much for your problem report. It has the internal identification `amd64/140067'. The individual assigned to look at your report is: freebsd-amd64. You can access the state of your problem report at any time via this link: http://www.freebsd.org/cgi/query-pr.cgi?pr=140067 >Category: amd64 >Responsible: freebsd-amd64 >Synopsis: [boot] 8.0-RC2 from ISO, after install, hangs on boot right before loader >Arrival-Date: Thu Oct 29 03:30:01 UTC 2009 From ben at wanderview.com Sun Nov 1 17:51:44 2009 From: ben at wanderview.com (Ben Kelly) Date: Sun Nov 1 17:51:50 2009 Subject: ifmcstat fails to build without KVM and with INET6 Message-ID: <92BA99AC-E038-44F4-A443-91FF5AA2968F@wanderview.com> Hello all, I'm having difficulty compiling a freshly updated checkout of head using WITHOUT_KVM src.conf. The error is in src/usr.sbin/ifmcstat/ ifmcstat.c. It appears the problem is due to the in6_ifinfo() function definition being incorrectly under an #ifdef WITH_KVM section. I was able to fix the problem with the attached patch. Just FYI in case anyone else hits this problem. - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: ifmcstat.patch Type: application/octet-stream Size: 1601 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091101/40848244/ifmcstat.obj From rmacklem at uoguelph.ca Sun Nov 1 21:53:38 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Sun Nov 1 21:53:46 2009 Subject: Help needed: TCP Wizards (was 8.0-RC1 NFS client timeout issue) Message-ID: I can now reproduce what I think others were seeing as slow reconnects when using NFSv3 over TCP against a server that disconnects inactive TCP connections. I have had some luck figuring out what is going on and can reproduce it fairly easily, but I really need help from someone who understands the FreeBSD TCP stack. Here's what happens when things break: - the krpc client does a reconnect like normal and the 3 way handshake works for the new socket. - the client sends an RPC on the new socket - at about the same time as this data send, the FreeBSD client sends a reset (yes, that's correct, an RST). --> not surprisingly, the server closes down the new connection and things get stuck until a timeout and another reconnect get things going again. This can be seen by the snoop trace that follows, with the RST at packet #18. (If there isn't a client->server RST packet generated by FreeBSD, the new connection works fine.) What do I know about this from printfs in the code: - It seems to happen when the new socket is at the same address as the old one. (Not a bug. Just happens that uma_zalloc() allocates the same memory as the old one that has been soclose()'d.) - It is timing related. If I add too many printfs, I can't reproduce the problem. My TCP is really rusty, but my theory is that some timer has been set by the FIN sent from the server for the old socket and it is still working on sending the RST when, somehow, the new socket and its tcp pcb get used for the send? Anyone out there able to help? (Please, please..) Here's a snoop trace of one of these (sorry about the long lines). You can see a successful reconnect, a Fin from the server disconnecting after 360sec and then the new connection being created with port#871. Then, at packet #18, there's that pesky RST!! --- snoop trace of FreeBSD-current client nfsv4-test mounted against a Solaris10 server called nfsv4-solaris. (The mount is the regular client, although that shouldn't matter, using NFSv3 over TCP.) 1 0.00000 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=864 Fin Ack=2981056244 Seq=3573648276 Len=0 Win=16588 Options= 2 0.00010 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=740 Syn Seq=729399224 Len=0 Win=65535 Options= 3 0.00054 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=864 S=2049 Rst Seq=2981056244 Len=0 Win=0 4 0.00055 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=740 S=2049 Syn Ack=729399225 Seq=38857223 Len=0 Win=49232 Options= 5 0.00086 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=740 Ack=38857224 Seq=729399225 Len=0 Win=8326 Options= 6 0.00104 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris NFS C FSSTAT3 FH=9D01 7 0.00180 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=740 S=2049 Ack=729399357 Seq=38857224 Len=0 Win=49100 Options= 8 0.00295 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca NFS R FSSTAT3 OK 9 0.10350 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=740 Ack=38857396 Seq=729399357 Len=0 Win=16588 Options= 10 360.00514 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=740 S=2049 Fin Ack=729399357 Seq=38857396 Len=0 Win=49232 Options= 11 360.00549 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=740 Rst Ack=38857397 Seq=729399357 Len=0 Win=0 12 360.00557 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=740 Rst Ack=38857397 Seq=729399357 Len=0 Win=0 13 360.00586 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=740 Ack=38857397 Seq=729399357 Len=0 Win=16588 Options= 14 360.00594 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=740 S=2049 Rst Seq=38857397 Len=0 Win=0 15 495.15000 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=871 Syn Seq=369106877 Len=0 Win=65535 Options= 16 495.15013 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=871 S=2049 Syn Ack=369106878 Seq=159825643 Len=0 Win=49232 Options= 17 495.15040 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=871 Ack=159825644 Seq=369106878 Len=0 Win=8326 Options= 18 495.15089 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=871 Rst Ack=159825644 Seq=369106878 Len=0 Win=0 19 495.15162 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris NFS C FSSTAT3 FH=9D01 20 495.15265 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=871 S=2049 Rst Seq=159825644 Len=0 Win=0 21 495.15305 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=883 Syn Seq=3875668538 Len=0 Win=65535 Options= 22 495.15322 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=883 S=2049 Syn Ack=3875668539 Seq=159964181 Len=0 Win=49232 Options= 23 495.15348 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=883 Ack=159964182 Seq=3875668539 Len=0 Win=8326 Options= 24 495.15368 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris NFS C FSSTAT3 FH=9D01 25 495.15374 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=883 Rst Ack=159964182 Seq=3875668539 Len=0 Win=0 26 495.15427 nfsv4-solaris -> nfsv4-test.cis.uoguelph.ca TCP D=883 S=2049 Ack=3875668671 Seq=159964182 Len=0 Win=49100 Options= 27 495.15457 nfsv4-test.cis.uoguelph.ca -> nfsv4-solaris TCP D=2049 S=883 Rst Ack=159964182 Seq=3875668671 Len=0 Win=0 From don at siad.net Mon Nov 2 01:04:23 2009 From: don at siad.net (Don L. Belcher) Date: Mon Nov 2 01:04:56 2009 Subject: bootstrap loader problem Message-ID: <4AEE296B.5040302@siad.net> New Dell 1737 laptop The following error occurs with versions 7.2 release and later this message is from 8 RC2. All versions tried with 7.1 release and earlier work fine, I tried 7.1, 7.2 and 6.4. I rebuilt 8 RC2 CD with "loader" from 7.1 release and the 8 RC2 comes up O.K. now. I have two questions: 1) is anybody familiar with this problem 2) is it ok to install 8 RC2 using the 7.1 "loader" BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard panic: free: guard1 fail @ 0xbb797074 from (diretory path to) common/console.c:94 --> Press a key (etc) From guru at unixarea.de Mon Nov 2 10:06:55 2009 From: guru at unixarea.de (Matthias Apitz) Date: Mon Nov 2 10:07:05 2009 Subject: [kde-freebsd] after compiling x11/kde4 problems with /usr/local/bin/startkde (SOLVED) In-Reply-To: References: <20091030151754.GA5849@current.Sisis.de> <20091101072629.GA2334@current.Sisis.de> <20091101103934.GA3004@current.Sisis.de> Message-ID: <20091102100655.GA2934@current.Sisis.de> El d?a Sunday, November 01, 2009 a las 10:45:41AM +0000, Robert Watson escribi?: > > On Sun, 1 Nov 2009, Matthias Apitz wrote: > > >>Could you confirm you are running with a userspace/kernel of at least > >>r198203 (the date of the last PIE-related fix following a move to > >>disallowing NULL mappings). > > > >NAK, userland and kernel is: > > > >$ uname -a FreeBSD vm-azul.Sisis.de 9.0-CURRENT FreeBSD 9.0-CURRENT #0 > >r197801: Mon Oct 12 13:33:32 CEST 2009 > >guru@vm-azul.Sisis.de:/usr/obj/usr/src/sys/GENERIC i386 > > Sounds like an upgrade should fix this -- if not, please let us know ASAP > as it might be an issue for 8.0 as well. Would this require as well to re-compile all my ~1200 ports or are there no changes in the ABI since r197801? matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ Vote NO to EU The Lisbon Treaty: http://www.no-means-no.eu From rwatson at FreeBSD.org Mon Nov 2 10:13:30 2009 From: rwatson at FreeBSD.org (Robert N. M. Watson) Date: Mon Nov 2 10:13:37 2009 Subject: [kde-freebsd] after compiling x11/kde4 problems with /usr/local/bin/startkde (SOLVED) In-Reply-To: <20091102100655.GA2934@current.Sisis.de> References: <20091030151754.GA5849@current.Sisis.de> <20091101072629.GA2334@current.Sisis.de> <20091101103934.GA3004@current.Sisis.de> <20091102100655.GA2934@current.Sisis.de> Message-ID: <570D2EEB-B09F-4B71-A1E8-2A1D760B0634@FreeBSD.org> On 2 Nov 2009, at 10:06, Matthias Apitz wrote: > El d?a Sunday, November 01, 2009 a las 10:45:41AM +0000, Robert > Watson escribi?: > >> >> On Sun, 1 Nov 2009, Matthias Apitz wrote: >> >>>> Could you confirm you are running with a userspace/kernel of at >>>> least >>>> r198203 (the date of the last PIE-related fix following a move to >>>> disallowing NULL mappings). >>> >>> NAK, userland and kernel is: >>> >>> $ uname -a FreeBSD vm-azul.Sisis.de 9.0-CURRENT FreeBSD 9.0- >>> CURRENT #0 >>> r197801: Mon Oct 12 13:33:32 CEST 2009 >>> guru@vm-azul.Sisis.de:/usr/obj/usr/src/sys/GENERIC i386 >> >> Sounds like an upgrade should fix this -- if not, please let us >> know ASAP >> as it might be an issue for 8.0 as well. > > Would this require as well to re-compile all my ~1200 ports or are > there > no changes in the ABI since r197801? I'm not aware of ABI changes, but that's always a risk when updating on the -CURRENT branch. Another approach would be to extract the relevant changes and apply them to your current source tree, but there are a fair number and you wouldn't want to miss any. I believe they're all to either the kernel or rtld. Robert From andy at neu.net Mon Nov 2 12:09:13 2009 From: andy at neu.net (AN) Date: Mon Nov 2 12:09:20 2009 Subject: amd64-9 packages Message-ID: According to: http://pointyhat.freebsd.org/errorlogs/packagestats.html there are no packages for amd64 9 current. FreeBSD package building statistics as of Mon Nov 2 11:45:02 UTC 2009 amd64-9 0 0 0 0 0 0 N N When can we expect these packages to be available? TIA From andy at neu.net Mon Nov 2 12:21:54 2009 From: andy at neu.net (AN) Date: Mon Nov 2 12:22:00 2009 Subject: amd64-9 packages In-Reply-To: References: Message-ID: On Mon, 2 Nov 2009, Remko Lodder wrote: > > You are asking port related things on a -current mailinglist. Perhaps you > should try ports@? > > On Nov 2, 2009, at 1:09 PM, AN wrote: > >> According to: http://pointyhat.freebsd.org/errorlogs/packagestats.html >> there are no packages for amd64 9 current. >> > > > -- > /"\ Best regards, | remko@FreeBSD.org > \ / Remko Lodder | remko@EFnet > X http://www.evilcoder.org/ | > / \ ASCII Ribbon Campaign | Against HTML Mail and News Thank you, sorry for the noise. From remko at elvandar.org Mon Nov 2 12:15:03 2009 From: remko at elvandar.org (Remko Lodder) Date: Mon Nov 2 12:36:17 2009 Subject: amd64-9 packages In-Reply-To: References: Message-ID: You are asking port related things on a -current mailinglist. Perhaps you should try ports@? On Nov 2, 2009, at 1:09 PM, AN wrote: > According to: http://pointyhat.freebsd.org/errorlogs/packagestats.html > there are no packages for amd64 9 current. > -- /"\ Best regards, | remko@FreeBSD.org \ / Remko Lodder | remko@EFnet X http://www.evilcoder.org/ | / \ ASCII Ribbon Campaign | Against HTML Mail and News From kamikaze at bsdforen.de Mon Nov 2 13:22:06 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Mon Nov 2 13:22:13 2009 Subject: mixer settings on 8.0-RC2 Message-ID: <4AEEDCFB.3060604@bsdforen.de> It appears that my 8.0-RC2 system (notebook) forgets its mixer settings with every reboot. FreeBSD mobileKamikaze.norad 8.0-RC2 FreeBSD 8.0-RC2 #0: Sat Oct 31 02:49:30 CET 2009 root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6510b-8 amd64 Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From des at des.no Mon Nov 2 13:30:49 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon Nov 2 13:30:55 2009 Subject: mixer settings on 8.0-RC2 In-Reply-To: <4AEEDCFB.3060604@bsdforen.de> (Dominic Fandrey's message of "Mon, 02 Nov 2009 14:22:03 +0100") References: <4AEEDCFB.3060604@bsdforen.de> Message-ID: <86fx8xm4u0.fsf@ds4.des.no> Dominic Fandrey writes: > It appears that my 8.0-RC2 system (notebook) forgets its mixer > settings with every reboot. Check the contents of /var/db/*-state. (if it were up to me, we'd store the mixer state in /var/db/mixer/$foo instead of /var/db/$foo-state) DES -- Dag-Erling Sm?rgrav - des@des.no From olivier at gid0.org Mon Nov 2 14:21:46 2009 From: olivier at gid0.org (Olivier Smedts) Date: Mon Nov 2 14:22:03 2009 Subject: mixer settings on 8.0-RC2 In-Reply-To: <86fx8xm4u0.fsf@ds4.des.no> References: <4AEEDCFB.3060604@bsdforen.de> <86fx8xm4u0.fsf@ds4.des.no> Message-ID: <367b2c980911020621o1ef34413ra07310e97b0dc982@mail.gmail.com> 2009/11/2 Dag-Erling Sm?rgrav : > Dominic Fandrey writes: >> It appears that my 8.0-RC2 system (notebook) forgets its mixer >> settings with every reboot. > > Check the contents of /var/db/*-state. Also, do you use a desktop environment with a mixer app which could interfere with the system mixer ? (like KMix for KDE) I had the same problem until I realized my mixer resets came from KMix) Cheers, Olivier > > (if it were up to me, we'd store the mixer state in /var/db/mixer/$foo > instead of /var/db/$foo-state) > > DES > -- > Dag-Erling Sm?rgrav - des@des.no > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From kamikaze at bsdforen.de Mon Nov 2 15:08:52 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Mon Nov 2 15:08:59 2009 Subject: mixer settings on 8.0-RC2 In-Reply-To: <367b2c980911020621o1ef34413ra07310e97b0dc982@mail.gmail.com> References: <4AEEDCFB.3060604@bsdforen.de> <86fx8xm4u0.fsf@ds4.des.no> <367b2c980911020621o1ef34413ra07310e97b0dc982@mail.gmail.com> Message-ID: <4AEEF601.9080801@bsdforen.de> Olivier Smedts wrote: > 2009/11/2 Dag-Erling Sm?rgrav : >> Dominic Fandrey writes: >>> It appears that my 8.0-RC2 system (notebook) forgets its mixer >>> settings with every reboot. >> Check the contents of /var/db/*-state. > > Also, do you use a desktop environment with a mixer app which could > interfere with the system mixer ? (like KMix for KDE) > I had the same problem until I realized my mixer resets came from KMix) Most definitely not. The only mixer application is /usr/sbin/mixer. # pkg_info -Ex mix sdl_mixer-1.2.8_2 From kamikaze at bsdforen.de Mon Nov 2 15:12:58 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Mon Nov 2 15:13:05 2009 Subject: mixer settings on 8.0-RC2 In-Reply-To: <86fx8xm4u0.fsf@ds4.des.no> References: <4AEEDCFB.3060604@bsdforen.de> <86fx8xm4u0.fsf@ds4.des.no> Message-ID: <4AEEF6F4.2080904@bsdforen.de> Dag-Erling Sm?rgrav wrote: > Dominic Fandrey writes: >> It appears that my 8.0-RC2 system (notebook) forgets its mixer >> settings with every reboot. > > Check the contents of /var/db/*-state. Thanks for the pointer. Is that updated during shutdown or every time the mixer settings are changed? The file is not in sync with my current mixer settings. > (if it were up to me, we'd store the mixer state in /var/db/mixer/$foo > instead of /var/db/$foo-state) Sounds sensible to me. Ever wrote a PR? Is there a manual page with in depth information? mixer(8) doesn't mention the mixerX-state files. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From gnemmi at gmail.com Mon Nov 2 15:56:52 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Mon Nov 2 15:58:15 2009 Subject: mixer settings on 8.0-RC2 In-Reply-To: <4AEEDCFB.3060604@bsdforen.de> References: <4AEEDCFB.3060604@bsdforen.de> Message-ID: <200911021356.43043.gnemmi@gmail.com> On Monday 02 November 2009 11:22:03 am Dominic Fandrey wrote: > It appears that my 8.0-RC2 system (notebook) forgets its mixer > settings with every reboot. > > FreeBSD mobileKamikaze.norad 8.0-RC2 FreeBSD 8.0-RC2 #0: Sat Oct 31 > 02:49:30 CET 2009 > root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6510 >b-8 amd64 > > Regards May I ask how are you setting them? Regards Gonzalo From matheus at eternamente.info Mon Nov 2 17:25:46 2009 From: matheus at eternamente.info (Nenhum_de_Nos) Date: Mon Nov 2 17:25:52 2009 Subject: status on usb/139598 Message-ID: <4480d94e7b5662b5a506e2d72bf75f8f.squirrel@cygnus.homeunix.com> hail, what's the status on this issue ? I wrote some bytes in this external usb hdd and now upgraded to 8.0-rc2, then I can't read them :( the other 7.2 box I have is in work, and I'm on vacation starting today :) no workarounds ? I must install a 7.2 to read it ? thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style From weldon at excelsusphoto.com Mon Nov 2 15:52:36 2009 From: weldon at excelsusphoto.com (Weldon S Godfrey 3) Date: Mon Nov 2 17:39:34 2009 Subject: FreeBSD 8.0 - network stack crashes? Message-ID: Up until yesterday, we have been running FreeBSD-CURRENT of 12/08. We started to see a couple months ago some very odd network behavior. Something happens to the stack that causes processes accessing the network to just hang. After the problem happens, usually (but not always), you can't ssh in. Always, you can't ssh or telnet out, and nothing can access the NFS shares on the server. You can ping everything from the server. You can't even do a route add, you can't ssh if you use just the IP address (although pinging with hostnames it doesn't have cached or in hosts table resolves). When you try to ssh out, do a route add from the box, the process just hangs. You can't control C it at all, it hangs forever. There is nothing in dmesg or messages to indicate an issue. I try to up/down the interfaces. In CURRENT-12/08, it may allow things to work for like 30s. We upgraded to 8.0-RC2 yesterday and, at first, the problem appeared to happen a lot more often. We expected that was related with the increase in network performance. At least in 8.0-RC2, I did see a large amount of input errors with netstat -in on the heavily loaded interface before it started the locking up behavior. I have replaced the ethernet cable and move ports. The Catalyst 3650 never records any errors. The problem would reoccur in about 5 minutes once our load kicked in this morning. One change in this upgrade, we switched from NFS v2 to v3. When we downgraded to the previous OS, we stayed at v3. The problem was just about as bad with v3 with the 12/08 OS We went back to RC2 with NFS v2 and appeared to stabilize to a degree. It ran for about an hour and a half and then the issue came up We are currently back to the 12/08 version using NFS2 and watching things. We are using a Dell PowerEdge 2950-iii, the problem happens when using the onboard nics using the bce driver and with an Intel card using the em driver I am hunting down any MTU/duplex/speed problems that could cause it (haven't found any so far). Of course, any problems on the network wouldn't (ideally) freak out the network stack on the server). I don't know how to troubleshoot this further on the server since I am not getting any problems indicated in logging, panics, cores, etc. Any help is appreciated. Thanks, Weldon From jh at sandstorm.net Mon Nov 2 19:22:39 2009 From: jh at sandstorm.net (John Hood) Date: Mon Nov 2 19:30:59 2009 Subject: gnome, automounting, and ataraid don't get along well Message-ID: <4AEF317B.8030200@sandstorm.net> [I sent this last week to freebsd-gnome and freebsd-current, but it didn't appear on freebsd-current.] I upgraded my desktop machine to 8.0-RC2 and 8.0-RELEASE packages recently. This machine uses an Intel chipset, ICH9R southbridge, and two SATA drives configured in a RAID1 with Intel's soft-RAID BIOS. ad10 and ad12 are automatically configured into an array by ataraid that shows up as ar0, which has FreeBSD installed in a typical UFS multi-partition setup. I'm using the GNOME desktop. At first glance, all appears to be happy. But when I run a software build that creates/mounts filesystem images with the md driver, I get an authentication dialog (at http://users.rcn.com/john70/auth.jpg ) which wants to mount something but doesn't say what. If I authenticate, gnome then proceeds to mount multiple devices in /dev/ufsid and/or partitions of ad12s1, ignoring the fact that that they're part of a RAID that's already mounted. (It seemed to ignore the md device, though.) I get this in syslog, suggesting that kernel & mount are unaware of the duplicate mounts: Oct 27 17:54:40 lister kernel: WARNING: /site was not properly dismounted Oct 27 17:54:40 lister kernel: /site: mount pending error: blocks 32 files 2 This obviously has big potential for filesystem corruption on any FreeBSD 8.0 system using GNOME and ataraid. Fortunately, I seem not to have lost any data. This also happens when attaching/detaching a USB drive. I didn't see any of this with FreeBSD 7.1, probably because automounting was broken or disabled there. I see several problems here. 1) the GNOME authentication dialog gives you no clue what it's trying to mount (when I saw it, I guessed it was GNOME's automounting wanting to play with the md device), and no clue that its caller will apply the authorization on six other mounts it has pending. 2) the devices in /dev/ufsid/ are associated with partitions on the adN drives, not for the RAID they're assembled into (not sure whether ata or ataraid or geom/glabel is responsible for this). I only see devices for one of the drives, but I think this is because the mirrored filesystems have the same UFS IDs on each drive and duplicates get disallowed/not-handled somewhere. 3) adN devices that are in an ATA raid are still visible in /dev and mountable. 4) GNOME isn't aware of any of this (should it be, or should the issue be handled in devfs & GEOM?) 5) There doesn't seem to be any tool to check or repair an ataraid mirror. For the moment, I've got the authentication disabled so the problem doesn't arise. If anyone wants to look at this, I'll be happy to help, otherwise I'll look at ataraid when I get a chance. --jh From wollman at hergotha.csail.mit.edu Mon Nov 2 20:37:51 2009 From: wollman at hergotha.csail.mit.edu (Garrett Wollman) Date: Mon Nov 2 21:13:51 2009 Subject: gnome, automounting, and ataraid don't get along well References: <4AEF317B.8030200@sandstorm.net> Message-ID: <200911022037.nA2Kbm43031296@hergotha.csail.mit.edu> In article <4AEF317B.8030200@sandstorm.net>, jh@sandstorm.net writes: >2) the devices in /dev/ufsid/ are associated with partitions on the adN >drives, not for the RAID they're assembled into (not sure whether ata or >ataraid or geom/glabel is responsible for this). This is a long-standing bug in ataraid. It should not be possible to open the individual members of a RAID set for writing, and the existence of the ataraid should spoil other consumers of the individual disk providers. (The same thing happens with regular UFS labels. I think the actual problem is that ataraid works behind GEOM's back, but doesn't withdraw the disk providers so GEOM thinks they are separate devices.) The only workaround that I have found is to disable the poor-man's-RAID and use gmirror instead. In general, having used both ataraid and gmirror systems since 5.x, my impression is that gmirror works better and is more manageable. -GAWollman From weldon at excelsusphoto.com Mon Nov 2 21:11:16 2009 From: weldon at excelsusphoto.com (Weldon S Godfrey 3) Date: Mon Nov 2 21:29:45 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: References: Message-ID: If memory serves me right, sometime around 10:52am, Weldon S Godfrey 3 told me: > > Up until yesterday, we have been running FreeBSD-CURRENT of 12/08. We started > to see a couple months ago some very odd network behavior. Something happens > to the stack that causes processes accessing the network to just hang. After > the problem happens, usually (but not always), you can't ssh in. Always, you > can't ssh or telnet out, and nothing can access the NFS shares on the server. > You can ping everything from the server. You can't even do a route add, you > can't ssh if you use just the IP address (although pinging with hostnames it > doesn't have cached or in hosts table resolves). When you try to ssh out, do > a route add from the box, the process just hangs. You can't control C it at > all, it hangs forever. There is nothing in dmesg or messages to indicate an > issue. I try to up/down the interfaces. In CURRENT-12/08, it may allow > things to work for like 30s. > > We upgraded to 8.0-RC2 yesterday and, at first, the problem appeared to happen > a lot more often. We expected that was related with the increase in network > performance. At least in 8.0-RC2, I did see a large amount of input errors > with netstat -in on the heavily loaded interface before it started the locking > up behavior. I have replaced the ethernet cable and move ports. The Catalyst > 3650 never records any errors. The problem would reoccur in about 5 minutes > once our load kicked in this morning. > > > One change in this upgrade, we switched from NFS v2 to v3. When we downgraded > to the previous OS, we stayed at v3. The problem was just about as bad with > v3 with the 12/08 OS > > We went back to RC2 with NFS v2 and appeared to stabilize to a degree. > It ran for about an hour and a half and then the issue came up > > We are currently back to the 12/08 version using NFS2 and watching things. > > We are using a Dell PowerEdge 2950-iii, the problem happens when using the > onboard nics using the bce driver and with an Intel card using the em driver > > I am hunting down any MTU/duplex/speed problems that could cause it (haven't > found any so far). Of course, any problems on the network wouldn't (ideally) > freak out the network stack on the server). I don't know how to troubleshoot > this further on the server since I am not getting any problems indicated in > logging, panics, cores, etc. > > Any help is appreciated. > I have swapped out the computer, switch, ethernet card, 3ware card. We are running on 8.0-CURRENT 12/08 that was what we where using with a lot less issues. No help. If it happens again, I am going to try to do a netif restart and routing restart. Although I believe I tried that at the begining and it did not help. From weldon at excelsusphoto.com Mon Nov 2 21:48:34 2009 From: weldon at excelsusphoto.com (Weldon S Godfrey 3) Date: Mon Nov 2 22:00:43 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: References: Message-ID: If memory serves me right, sometime around 4:11pm, Weldon S Godfrey 3 told me: > > > If memory serves me right, sometime around 10:52am, Weldon S Godfrey 3 told > me: > >> >> Up until yesterday, we have been running FreeBSD-CURRENT of 12/08. We >> started to see a couple months ago some very odd network behavior. Something >> happens to the stack that causes processes accessing the network to just >> hang. After the problem happens, usually (but not always), you can't ssh >> in. Always, you can't ssh or telnet out, and nothing can access the NFS >> shares on the server. You can ping everything from the server. You can't >> even do a route add, you can't ssh if you use just the IP address (although >> pinging with hostnames it doesn't have cached or in hosts table resolves). >> When you try to ssh out, do a route add from the box, the process just >> hangs. You can't control C it at all, it hangs forever. There is nothing >> in dmesg or messages to indicate an issue. I try to up/down the interfaces. >> In CURRENT-12/08, it may allow things to work for like 30s. >> >> We upgraded to 8.0-RC2 yesterday and, at first, the problem appeared to >> happen a lot more often. We expected that was related with the increase in >> network performance. At least in 8.0-RC2, I did see a large amount of input >> errors with netstat -in on the heavily loaded interface before it started >> the locking up behavior. I have replaced the ethernet cable and move ports. >> The Catalyst 3650 never records any errors. The problem would reoccur in >> about 5 minutes once our load kicked in this morning. >> >> >> One change in this upgrade, we switched from NFS v2 to v3. When we >> downgraded to the previous OS, we stayed at v3. The problem was just about >> as bad with v3 with the 12/08 OS >> >> We went back to RC2 with NFS v2 and appeared to stabilize to a degree. >> It ran for about an hour and a half and then the issue came up >> >> We are currently back to the 12/08 version using NFS2 and watching things. >> >> We are using a Dell PowerEdge 2950-iii, the problem happens when using the >> onboard nics using the bce driver and with an Intel card using the em driver >> >> I am hunting down any MTU/duplex/speed problems that could cause it (haven't >> found any so far). Of course, any problems on the network wouldn't >> (ideally) freak out the network stack on the server). I don't know how to >> troubleshoot this further on the server since I am not getting any problems >> indicated in logging, panics, cores, etc. >> >> Any help is appreciated. >> > > > I have swapped out the computer, switch, ethernet card, 3ware card. We are > running on 8.0-CURRENT 12/08 that was what we where using with a lot less > issues. No help. > > If it happens again, I am going to try to do a netif restart and routing > restart. Although I believe I tried that at the begining and it did not help. > BTW.. doing a netif / routing restart doesn't help From ivoras at freebsd.org Tue Nov 3 00:23:04 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Nov 3 00:23:27 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: References: Message-ID: Weldon S Godfrey 3 wrote: > I don't > know how to troubleshoot this further on the server since I am not > getting any problems indicated in logging, panics, cores, etc. If you have console access to the system, the generic advice would be to compile a kernel with the kernel debugger - options KDB and DDB (see http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html), enter the debugger, force a kernel dump file to be created (by entering "call doadump") and then proceed with post-mortem examination of the kernel at your leisure (e.g. from a remote ssh console, etc). See http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html for instructions on what information to collect. If you can provoke your problem with using WITNESS that would probably be great, but it will slow down your production machine noticeably. When WITNESS is enabled you might also get more information - such as LOR warnings, which you should also collect. Keep the dump file, someone might ask you for more information. Good luck! From alexbestms at math.uni-muenster.de Tue Nov 3 01:03:31 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Tue Nov 3 01:03:38 2009 Subject: 8.0-RC2 mangles msdosfs In-Reply-To: <4AEBFAA3.9020003@bsdforen.de> Message-ID: Dominic Fandrey schrieb am 2009-10-31: > Alexander Best wrote: > > i've experienced similar issues with msdosfs. it seems especially > > /sbin/fsck_msdosfs needs some updating. > > cheers. > > alex > Not only that, write access is really broken. looks like someone with really good fs/fat16/fat32 knowledge needs to take a look at this. seems fat16/fat32 quality has been steadily going down hill since releng_4 imo. i guess the freebsd-fs@ guys know about these problems but don't have the time to deal with it. most of them are probably working on zfs. good thing however that you posted a pr (kern/140134). hope somebody will step up and fix the msdosfs code. alex From weldon at excelsusphoto.com Tue Nov 3 01:02:12 2009 From: weldon at excelsusphoto.com (Weldon S Godfrey 3) Date: Tue Nov 3 02:42:58 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: References: Message-ID: If memory serves me right, sometime around Tomorrow, Ivan Voras told me: > Weldon S Godfrey 3 wrote: > >> I don't know how to troubleshoot this further on the server since I am not >> getting any problems indicated in logging, panics, cores, etc. > > If you have console access to the system, the generic advice would be to > compile a kernel with the kernel debugger - options KDB and DDB (see > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html), > enter the debugger, force a kernel dump file to be created (by entering "call > doadump") and then proceed with post-mortem examination of the kernel at your > leisure (e.g. from a remote ssh console, etc). > > See > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html > for instructions on what information to collect. > > If you can provoke your problem with using WITNESS that would probably be > great, but it will slow down your production machine noticeably. When WITNESS > is enabled you might also get more information - such as LOR warnings, which > you should also collect. > > Keep the dump file, someone might ask you for more information. > Thanks, I will work on trying to get a system with those enabled. Another thought that came to mind that this sounds like some sort of network buffer exhaustion. Is there anything to look for there? From linimon at lonesome.com Tue Nov 3 01:28:10 2009 From: linimon at lonesome.com (Mark Linimon) Date: Tue Nov 3 02:53:25 2009 Subject: 8.0-RC2 mangles msdosfs In-Reply-To: References: <4AEBFAA3.9020003@bsdforen.de> Message-ID: <20091103012810.GB31768@lonesome.com> On Tue, Nov 03, 2009 at 02:03:29AM +0100, Alexander Best wrote: > i guess the freebsd-fs@ guys know about these problems but don't have > the time to deal with it. most of them are probably working on zfs. AFAIK there are only a handful of people working on ZFS. We certainly need more people willing to work on filesystems code. In general it does have a large learning curve, so it's not as attractive as some of the other areas. That's probably why, as the kernel has undergone radical changes (e.g. for SMP) over time, that some of the fs code has not kept up. mcl From ianf at clue.co.za Tue Nov 3 05:46:54 2009 From: ianf at clue.co.za (Ian Freislich) Date: Tue Nov 3 05:47:02 2009 Subject: Believed fixed (was: Re: Another panic (during netisr?)) Message-ID: Robert Watson wrote: > Since debugging this went offline, the quick summary for the list > is: it looks like a race condition in the read-write locking for > tcbinfo in 8.x/9.x was responsible, and I've now committed a fix > to head and merged to stable/8 this morning. If this recurs with > the fix, please let me know, because that would mean we fixed the > wrong bug. :-) Since this I've not had a panic on our routers in the last 25 days. Before, it would panic about every 5 days with a corrupted stack. Ian -- Ian Freislich From kamikaze at bsdforen.de Tue Nov 3 07:07:31 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Tue Nov 3 07:07:37 2009 Subject: mixer settings on 8.0-RC2 In-Reply-To: <200911021356.43043.gnemmi@gmail.com> References: <4AEEDCFB.3060604@bsdforen.de> <200911021356.43043.gnemmi@gmail.com> Message-ID: <4AEFD6AE.6020906@bsdforen.de> Gonzalo Nemmi wrote: > On Monday 02 November 2009 11:22:03 am Dominic Fandrey wrote: >> It appears that my 8.0-RC2 system (notebook) forgets its mixer >> settings with every reboot. >> >> FreeBSD mobileKamikaze.norad 8.0-RC2 FreeBSD 8.0-RC2 #0: Sat Oct 31 >> 02:49:30 CET 2009 >> root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6510 >> b-8 amd64 >> >> Regards > > May I ask how are you setting them? > > Regards > Gonzalo With mixer(8). But now the settings are remembered. I suppose some evil app is to blame. But nothing apart from Skype comes to mind and I configured it not to touch the mixer settings. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From rwatson at FreeBSD.org Tue Nov 3 08:08:16 2009 From: rwatson at FreeBSD.org (Robert Watson) Date: Tue Nov 3 08:08:23 2009 Subject: Believed fixed (was: Re: Another panic (during netisr?)) In-Reply-To: References: Message-ID: On Tue, 3 Nov 2009, Ian Freislich wrote: > Robert Watson wrote: >> Since debugging this went offline, the quick summary for the list is: it >> looks like a race condition in the read-write locking for tcbinfo in >> 8.x/9.x was responsible, and I've now committed a fix to head and merged to >> stable/8 this morning. If this recurs with the fix, please let me know, >> because that would mean we fixed the wrong bug. :-) > > Since this I've not had a panic on our routers in the last 25 days. Before, > it would panic about every 5 days with a corrupted stack. Sounds good, thanks! Robert N M Watson Computer Laboratory University of Cambridge From hselasky at c2i.net Tue Nov 3 08:21:44 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Nov 3 08:21:51 2009 Subject: status on usb/139598 In-Reply-To: <4480d94e7b5662b5a506e2d72bf75f8f.squirrel@cygnus.homeunix.com> References: <4480d94e7b5662b5a506e2d72bf75f8f.squirrel@cygnus.homeunix.com> Message-ID: <200911030920.49134.hselasky@c2i.net> On Monday 02 November 2009 18:25:24 Nenhum_de_Nos wrote: > hail, > > what's the status on this issue ? > > I wrote some bytes in this external usb hdd and now upgraded to 8.0-rc2, > then I can't read them :( > > the other 7.2 box I have is in work, and I'm on vacation starting today :) > > no workarounds ? I must install a 7.2 to read it ? > > thanks, > > matheus Hi, There is no news, beside from: Please check that sys/dev/usb/controller/ehci.c is up to date with 9-current. --HPS From pieter at degoeje.nl Tue Nov 3 08:49:18 2009 From: pieter at degoeje.nl (Pieter de Goeje) Date: Tue Nov 3 08:49:25 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: References: Message-ID: <200911030937.11619.pieter@degoeje.nl> On Tuesday 03 November 2009 02:02:08 Weldon S Godfrey 3 wrote: > If memory serves me right, sometime around Tomorrow, Ivan Voras told me: > > > Weldon S Godfrey 3 wrote: > > > >> I don't know how to troubleshoot this further on the server since I am not > >> getting any problems indicated in logging, panics, cores, etc. > > > > If you have console access to the system, the generic advice would be to > > compile a kernel with the kernel debugger - options KDB and DDB (see > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-online-ddb.html), > > enter the debugger, force a kernel dump file to be created (by entering "call > > doadump") and then proceed with post-mortem examination of the kernel at your > > leisure (e.g. from a remote ssh console, etc). > > > > See > > http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html > > for instructions on what information to collect. > > > > If you can provoke your problem with using WITNESS that would probably be > > great, but it will slow down your production machine noticeably. When WITNESS > > is enabled you might also get more information - such as LOR warnings, which > > you should also collect. > > > > Keep the dump file, someone might ask you for more information. > > > > Thanks, I will work on trying to get a system with those enabled. > > Another thought that came to mind that this sounds like some sort of > network buffer exhaustion. Is there anything to look for there? Are you perhaps using em(4)? There was an mbuf leak in the driver, which was fixed recently. You can check mbuf usage with netstat -m. -- Pieter de Goeje From gavin at FreeBSD.org Tue Nov 3 09:52:58 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Nov 3 09:53:06 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: References: Message-ID: <1257185816.44755.29.camel@buffy.york.ac.uk> On Mon, 2009-11-02 at 10:52 -0500, Weldon S Godfrey 3 wrote: > Up until yesterday, we have been running FreeBSD-CURRENT of 12/08. We > started to see a couple months ago some very odd network behavior. > Something happens to the stack that causes processes accessing the network > to just hang. After the problem happens, usually (but not always), you > can't ssh in. Always, you can't ssh or telnet out, and nothing can access > the NFS shares on the server. You can ping everything from the server. > You can't even do a route add, you can't ssh if you use just the IP > address (although pinging with hostnames it doesn't have cached or in > hosts table resolves). When you try to ssh out, do a route add from the > box, the process just hangs. You can't control C it at all, it hangs > forever. There is nothing in dmesg or messages to indicate an issue. I > try to up/down the interfaces. In CURRENT-12/08, it may allow things to > work for like 30s. Some things that would be useful: - Does "arp -da" fix things? - What's the output of "netstat -m" while the networking is broken? - What does CTRL-T show for the hung SSH or route processes? - What does "procstat -kk" on the same processes show? - Does going to single user mode ("init 1" and killing off any leftover processes) cause the machine to start working again? If so, what's the output of "netstat -m" afterwards? If you look to be hitting some of the limits shown by "netstat -m", try logging the date, "netstat -m" and "vmstat -m" to a file every 30 seconds or similar so that we can see if it is a memory leak, and what may be leaking. Gavin From gavin at FreeBSD.org Tue Nov 3 10:11:07 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Nov 3 10:11:14 2009 Subject: aue0 detected as ue0 on 8.0-RC2 In-Reply-To: <5aaae08a0910311359v45cc9dc9h2826d8a29bfb5575@mail.gmail.com> References: <5aaae08a0910311359v45cc9dc9h2826d8a29bfb5575@mail.gmail.com> Message-ID: <1257243047.98619.8.camel@buffy.york.ac.uk> [freebsd-current cc'd, as that was where the thread started, but this probably belongs on -usb, replies should go there] On Sat, 2009-10-31 at 21:59 +0100, Rick van der Zwet wrote: > The first net interface of a aue(4) define used to be called aue0 > afaik. But is now called ue0 (declared in usb/net/usb_ethernet.c). (no > sign of ue(4) btw). > > I was looking in the UPDATING, man, mailinglists freebsd-usb@ and > freebsd-current@. But I could not find the reason why the naming > convention on this aue differs from the regular stuff, anybody? > > /Rick > > quick# dmesg | tail -8 > ugen1.3: at usbus1 > aue0: on usbus1 > miibus1: on aue0 > ukphy0: PHY 1 on miibus1 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on aue0 > ue0: Ethernet address: 00:00:e8:00:11:36 > ue0: link state changed to DOWN > > quick# ifconfig -l > bfe0 lo0 ue0 Hmm, this looks like a serious bug, possibly in the new USB subsystem (HPS CC'd). I've got an axe(4) device, which also does the same: ugen7.3: at usbus7 axe0: on usbus7 axe0: PHYADDR 0xe0:0x10 miibus1: on axe0 ukphy0: PHY 16 on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on axe0 ue0: Ethernet address: 00:50:b6:05:57:a7 ue0: link state changed to DOWN Gavin From gavin at FreeBSD.org Tue Nov 3 10:43:36 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Nov 3 10:43:42 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091031231545.493cee89@boiler.free.de> References: <20091031231545.493cee89@boiler.free.de> Message-ID: <1257244960.98619.36.camel@buffy.york.ac.uk> On Sat, 2009-10-31 at 23:15 +0100, Kai Gallasch wrote: > Hi. > > I installed 8.0RC2-amd64 on an 8-core opteron server a few days ago. > > When I try to do a make buildworld or make buildkernel the server > reboots without any message left in the logs. The same happens > when building bigger ports (for example ruby18 or perl58) > > With 8.0-RC2 debug flags and witness seem to be disabled in the > standard GENERIC kernel, so unfortunately it is not possible for me to > build a debug kernel without my server crashing.. First place I think I'd start id by running memtest86 on the machine overnight. This sounds like possible hardware issue to me, it would be good to see if we can confirm that that is the case. > Now my idea was to install the old 8.0-BETA4 and upgrade to RC2 through > makeworld + buildkernel (gdb+witness). But no luck. When trying to > upgrade to RC2 the 8.0-BETA4 also crashes. At least 8.0-BETA4 has debug > + witness active in the GENERIC kernel.. > > So below some debug output of 8.0-BETA4 crashing. Has a vfs/ffs LOR > problem with the BETA4 already been fixed? The debug output you included were just lock order reversals, and don't seem to be related to your crash. I think 8.0-BETA4 still had the debugger compiled in (you can test by pressing ctrl-alt-escape ion the console, if you do drop to the debugger, give the "c" command to continue). If the debugger is compiled in, then the spontaneous reboot without dropping to the debugger suggests even more that it may be hardware related. If you do get to the debugger, a copy of all of the messages on screen and the output of the "bt" command would be very useful. When you do your kernel recompile, please include full debugging, including WITNESS, INVARIANTS, KDB, DDB etc. FWIW, don't worry about building world now, a BETA4 world should work fine with a RC2 kernel. You may be able to get a kernel built even though it keeps crashing by clearing out /usr/obj to start with and then just repeating cd /usr/src && make buildkernel -DKERNFAST after every crash. > Does it make sense to send in a pr with the old 8.0-BETA4? It depends what the bug is to be honest. So far there isn't really enough information to determine the cause, and therefore there isn't really enough info for a PR. Gavin From hselasky at freebsd.org Tue Nov 3 11:04:17 2009 From: hselasky at freebsd.org (Hans Petter Selasky) Date: Tue Nov 3 11:04:29 2009 Subject: aue0 detected as ue0 on 8.0-RC2 In-Reply-To: <1257243047.98619.8.camel@buffy.york.ac.uk> References: <5aaae08a0910311359v45cc9dc9h2826d8a29bfb5575@mail.gmail.com> <1257243047.98619.8.camel@buffy.york.ac.uk> Message-ID: <200911031203.22103.hselasky@freebsd.org> On Tuesday 03 November 2009 11:10:47 Gavin Atkinson wrote: > [freebsd-current cc'd, as that was where the thread started, but this > probably belongs on -usb, replies should go there] > > On Sat, 2009-10-31 at 21:59 +0100, Rick van der Zwet wrote: > > The first net interface of a aue(4) define used to be called aue0 > > afaik. But is now called ue0 (declared in usb/net/usb_ethernet.c). (no > > sign of ue(4) btw). > > > > I was looking in the UPDATING, man, mailinglists freebsd-usb@ and > > freebsd-current@. But I could not find the reason why the naming > > convention on this aue differs from the regular stuff, anybody? > > > > /Rick > > > > quick# dmesg | tail -8 > > ugen1.3: at usbus1 > > aue0: on usbus1 > > miibus1: on aue0 > > ukphy0: PHY 1 on miibus1 > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > ue0: on aue0 > > ue0: Ethernet address: 00:00:e8:00:11:36 > > ue0: link state changed to DOWN > > > > quick# ifconfig -l > > bfe0 lo0 ue0 > > Hmm, this looks like a serious bug, possibly in the new USB subsystem > (HPS CC'd). > > I've got an axe(4) device, which also does the same: > > ugen7.3: at usbus7 > axe0: on usbus7 > axe0: PHYADDR 0xe0:0x10 > miibus1: on axe0 > ukphy0: PHY 16 on miibus1 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on axe0 > ue0: Ethernet address: 00:50:b6:05:57:a7 > ue0: link state changed to DOWN Hi, All USB ethernet adapters are now named ue0. You will get one axe0 event and one ue0 event. So there should be no problems regarding devd.conf . --HPS From hselasky at c2i.net Tue Nov 3 11:07:14 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Tue Nov 3 11:07:20 2009 Subject: aue0 detected as ue0 on 8.0-RC2 In-Reply-To: <200911031203.22103.hselasky@freebsd.org> References: <5aaae08a0910311359v45cc9dc9h2826d8a29bfb5575@mail.gmail.com> <1257243047.98619.8.camel@buffy.york.ac.uk> <200911031203.22103.hselasky@freebsd.org> Message-ID: <200911031206.19512.hselasky@c2i.net> On Tuesday 03 November 2009 12:03:21 Hans Petter Selasky wrote: > Hi, > > All USB ethernet adapters are now named ue0. You will get one axe0 event > and one ue0 event. So there should be no problems regarding devd.conf . > > --HPS s/ue0/ueN/ --HPS From moonlightakkiy at yahoo.ca Tue Nov 3 11:38:28 2009 From: moonlightakkiy at yahoo.ca (PseudoCylon) Date: Tue Nov 3 11:38:34 2009 Subject: Wireless usb + wep = no usbd_do_request Message-ID: <143477.23789.qm@web51804.mail.re2.yahoo.com> Hi, I'm porting a wireless usb driver (if_run) to freebsd current, and I got stuck. Once I "ifconfig wlan0 wepkey 1:0x... weptxkey 1" I cannot call usbd_do_request() any more. Even ifconfig didn't exit. Chipset supports h/w en/decryption, so cannot write keys on chip. (It works without encryption, by the way.) So, I tried the same thing on another device, linksys wusb54gc with if_rum. It worked fine, but about 3 to 4 min later. (Just left it alone.) It started giving error rum0: could not multi read MAC register: USB_ERR_TIMEOUT and rum0: device timeout when ifconfig wlan0 down, rum0: could not multi write MAC register: USB_ERR_TIMEOUT which means failed on usbd_do_request() (This could be totally different issue.) Any ideas, patches, or walkaround? More info #uname -a FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r198150M: Fri Oct 16 22:44:08 UTC 2009 amd64 ddb trace output 20+ minutes after "ifconfig wepkey" (using if_run) Tracing command ifconfig pid 1586 tid 100159 td 0xffffff000b3d3a80 sched_switch() at sched_switch+0x180 mi_switch() at mi_switch+0x21d sleepq_switch() at sleepq_switch+0x123 sleepq_wait() at sleepq_wait+0x4d _sleep() at _sleep+0x357 taskqueue_drain() at taskqueue_drain+0xc2 ieee80211_waitfor_parent() at ieee80211_waitfor_parent+0x3e ieee80211_ioctl() at ieee80211_ioctl+0x162 ifioctl() at ifioctl+0xde4 kern_ioctl() at kern_ioctl+0xc5 ioctl() at ioctl+0xfd syscall() at syscall+0x1af Xfast_syscall() at Xfast_syscall+0xe1 Also, sleep mutex became spin mutex. I get a panic panic: mtx_lock of spin mutex(null) It works fine before ifconfig wepkey. __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. From onemda at gmail.com Tue Nov 3 12:08:49 2009 From: onemda at gmail.com (Paul B Mahol) Date: Tue Nov 3 12:08:56 2009 Subject: Wireless usb + wep = no usbd_do_request In-Reply-To: <143477.23789.qm@web51804.mail.re2.yahoo.com> References: <143477.23789.qm@web51804.mail.re2.yahoo.com> Message-ID: <3a142e750911030408t25dd59b0rcda6eccd8c24c0c9@mail.gmail.com> On 11/3/09, PseudoCylon wrote: > Hi, > > I'm porting a wireless usb driver (if_run) to freebsd current, and I got > stuck. Once I "ifconfig wlan0 wepkey 1:0x... weptxkey 1" I cannot call > usbd_do_request() any more. Even ifconfig didn't exit. Chipset supports h/w > en/decryption, so cannot write keys on chip. (It works without encryption, > by the way.) > > So, I tried the same thing on another device, linksys wusb54gc with if_rum. > It worked fine, but about 3 to 4 min later. (Just left it alone.) It started > giving error > rum0: could not multi read MAC register: USB_ERR_TIMEOUT and > rum0: device timeout > when ifconfig wlan0 down, > rum0: could not multi write MAC register: USB_ERR_TIMEOUT > which means failed on usbd_do_request() (This could be totally different > issue.) I get this one multiple times after card got detached but vap was not manually destroyed. Recently I did not used if_rum more that 5 min I think(maybe in AP mode when I was testing hidden ssid ...) > Any ideas, patches, or walkaround? Make sure how locks are handled between net80211, usb and driver itself. > More info > #uname -a > FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r198150M: Fri Oct 16 22:44:08 > UTC 2009 amd64 > > ddb trace output 20+ minutes after "ifconfig wepkey" (using if_run) > Tracing command ifconfig pid 1586 tid 100159 td 0xffffff000b3d3a80 > sched_switch() at sched_switch+0x180 > mi_switch() at mi_switch+0x21d > sleepq_switch() at sleepq_switch+0x123 > sleepq_wait() at sleepq_wait+0x4d > _sleep() at _sleep+0x357 > taskqueue_drain() at taskqueue_drain+0xc2 > ieee80211_waitfor_parent() at ieee80211_waitfor_parent+0x3e > ieee80211_ioctl() at ieee80211_ioctl+0x162 > ifioctl() at ifioctl+0xde4 > kern_ioctl() at kern_ioctl+0xc5 > ioctl() at ioctl+0xfd > syscall() at syscall+0x1af > Xfast_syscall() at Xfast_syscall+0xe1 > > Also, sleep mutex became spin mutex. I get a panic > panic: mtx_lock of spin mutex(null) > It works fine before ifconfig wepkey. It is hard to tell without code example but wepkey works fine with if_rum last time I tried, note that if_rum have done encryption in software mode. From rpaulo at freebsd.org Tue Nov 3 12:14:39 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Tue Nov 3 12:14:46 2009 Subject: aue0 detected as ue0 on 8.0-RC2 In-Reply-To: <200911031203.22103.hselasky@freebsd.org> References: <5aaae08a0910311359v45cc9dc9h2826d8a29bfb5575@mail.gmail.com> <1257243047.98619.8.camel@buffy.york.ac.uk> <200911031203.22103.hselasky@freebsd.org> Message-ID: On 3 Nov 2009, at 11:03, Hans Petter Selasky wrote: > On Tuesday 03 November 2009 11:10:47 Gavin Atkinson wrote: >> [freebsd-current cc'd, as that was where the thread started, but this >> probably belongs on -usb, replies should go there] >> >> On Sat, 2009-10-31 at 21:59 +0100, Rick van der Zwet wrote: >>> The first net interface of a aue(4) define used to be called aue0 >>> afaik. But is now called ue0 (declared in usb/net/usb_ethernet.c). >>> (no >>> sign of ue(4) btw). >>> >>> I was looking in the UPDATING, man, mailinglists freebsd-usb@ and >>> freebsd-current@. But I could not find the reason why the naming >>> convention on this aue differs from the regular stuff, anybody? >>> >>> /Rick >>> >>> quick# dmesg | tail -8 >>> ugen1.3: at usbus1 >>> aue0: on usbus1 >>> miibus1: on aue0 >>> ukphy0: PHY 1 on miibus1 >>> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >>> ue0: on aue0 >>> ue0: Ethernet address: 00:00:e8:00:11:36 >>> ue0: link state changed to DOWN >>> >>> quick# ifconfig -l >>> bfe0 lo0 ue0 >> >> Hmm, this looks like a serious bug, possibly in the new USB subsystem >> (HPS CC'd). >> >> I've got an axe(4) device, which also does the same: >> >> ugen7.3: at usbus7 >> axe0: on usbus7 >> axe0: PHYADDR 0xe0:0x10 >> miibus1: on axe0 >> ukphy0: PHY 16 on miibus1 >> ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >> ue0: on axe0 >> ue0: Ethernet address: 00:50:b6:05:57:a7 >> ue0: link state changed to DOWN > > Hi, > > All USB ethernet adapters are now named ue0. You will get one axe0 > event and > one ue0 event. So there should be no problems regarding devd.conf . Fair enough, but this must be mentioned in src/UPDATING. -- Rui Paulo From gnemmi at gmail.com Tue Nov 3 12:45:09 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Nov 3 12:45:15 2009 Subject: mixer settings on 8.0-RC2 In-Reply-To: <4AEFD6AE.6020906@bsdforen.de> References: <4AEEDCFB.3060604@bsdforen.de> <200911021356.43043.gnemmi@gmail.com> <4AEFD6AE.6020906@bsdforen.de> Message-ID: <200911031045.03823.gnemmi@gmail.com> On Tuesday 03 November 2009 5:07:26 am Dominic Fandrey wrote: > Gonzalo Nemmi wrote: > > On Monday 02 November 2009 11:22:03 am Dominic Fandrey wrote: > >> It appears that my 8.0-RC2 system (notebook) forgets its mixer > >> settings with every reboot. > >> > >> FreeBSD mobileKamikaze.norad 8.0-RC2 FreeBSD 8.0-RC2 #0: Sat Oct > >> 31 02:49:30 CET 2009 > >> root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6 > >>510 b-8 amd64 > >> > >> Regards > > > > May I ask how are you setting them? > > > > Regards > > Gonzalo > > With mixer(8). But now the settings are remembered. > > I suppose some evil app is to blame. But nothing apart from Skype > comes to mind and I configured it not to touch the mixer settings. > > Regards Sorry but I have to ask ... have you tried configuring mixer settings as described in section 7.2.4 of the FreBSD handbook? That is to say: "The default values for the different mixer channels are hardcoded in the sourcecode of the pcm(4) driver. There are many different applications and daemons that allow you to set values for the mixer that are remembered between invocations, but this is not a clean solution. It is possible to set default mixer values at the driver level -- this is accomplished by defining the appropriate values in /boot/device.hints, e.g.: hint.pcm.0.vol="50" This will set the volume channel to a default value of 50 when the pcm(4) module is loaded." because that works for me :s Best Regards Gonzalo From des at des.no Tue Nov 3 12:45:33 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Nov 3 12:45:40 2009 Subject: mixer settings on 8.0-RC2 In-Reply-To: <4AEEF6F4.2080904@bsdforen.de> (Dominic Fandrey's message of "Mon, 02 Nov 2009 16:12:52 +0100") References: <4AEEDCFB.3060604@bsdforen.de> <86fx8xm4u0.fsf@ds4.des.no> <4AEEF6F4.2080904@bsdforen.de> Message-ID: <86r5sfn5eb.fsf@ds4.des.no> Dominic Fandrey writes: > Dag-Erling Sm?rgrav writes: > > Check the contents of /var/db/*-state. > Thanks for the pointer. Is that updated during shutdown or > every time the mixer settings are changed? During shutdown. > Sounds sensible to me. Ever wrote a PR? Not in about ten years... > Is there a manual page with in depth information? mixer(8) doesn't > mention the mixerX-state files. /etc/rc.d/mixer DES -- Dag-Erling Sm?rgrav - des@des.no From ivoras at freebsd.org Tue Nov 3 13:36:48 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Nov 3 13:36:56 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: References: <200911030937.11619.pieter@degoeje.nl> Message-ID: <9bbcef730911030536p5707fc2fg7228eb69b729b288@mail.gmail.com> 2009/11/3 Weldon S Godfrey 3 : > > > If memory serves me right, sometime around 9:37am, Pieter de Goeje told me: > >> Are you perhaps using em(4)? There was an mbuf leak in the driver, which >> was fixed recently. >> You can check mbuf usage with netstat -m. >> > > we are using onboard NICs on the Dell using the bce driver. ?We did try > several times to see if using an intel PCIexpress card using the em driver, > and we had the same symptoms. > > Could the bce driver have the same leak? It would be unlikely to pass unnoticed since Dells are common hardware... From weldon at excelsusphoto.com Tue Nov 3 13:32:26 2009 From: weldon at excelsusphoto.com (Weldon S Godfrey 3) Date: Tue Nov 3 14:09:58 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: <1257185816.44755.29.camel@buffy.york.ac.uk> References: <1257185816.44755.29.camel@buffy.york.ac.uk> Message-ID: If memory serves me right, sometime around Yesterday, Gavin Atkinson told me: Gavin, thank you A LOT for helping us with this, I have answered as much as I can from the most recent crash below. We did hit max mbufs. It is at 25Kclusters, which is the default. I have upped it to 32K because a rather old article mentioned that as the top end and I need to get into work so I am not trying to do this with a remote console to go higher. I have already set it to reboot next with 64K clusters. I already have kmem maxed to what is bootable (or at least at one time) in 8.0, 4GB, how high can I safely go? This is a NFS server running ZFS with sustained 5 min averages of 120-200Mb/s running as a store for a mail system. > Some things that would be useful: > > - Does "arp -da" fix things? no, it hangs like ssh, route add, etc > - What's the output of "netstat -m" while the networking is broken? Tue Nov 3 07:02:11 CST 2009 36971/2033/39004 mbufs in use (current/cache/total) 24869/731/25600/25600 mbuf clusters in use (current/cache/total/max) 24314/731 mbuf+clusters out of packet secondary zone in use (current/cache) 0/35/35/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 58980K/2110K/61091K bytes allocated to network (current/cache/total) 0/201276/90662 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines > - What does CTRL-T show for the hung SSH or route processes? of the arp: load: 0.01 cmd: arp 6144 [zonelimit] 0.00u 0.00s 0% 996k > - What does "procstat -kk" on the same processes show? sorry I couldn't get this to run this time, remote console issues > - Does going to single user mode ("init 1" and killing off any leftover > processes) cause the machine to start working again? If so, what's the > output of "netstat -m" afterwards? no, mbuf was still maxed out below is the last vmstat -m Type InUse MemUse HighUse Requests Size(s) ntfs_nthash 1 512K - 1 pfs_nodes 20 5K - 20 256 GEOM 262 52K - 4551 16,32,64,128,256,512,1024,2048 isadev 9 2K - 9 128 cdev 13 4K - 13 256 sigio 1 1K - 1 64 filedesc 127 64K - 6412 512,1024 kenv 75 11K - 80 16,32,64,128 kqueue 0 0K - 188 256,2048 proc-args 41 2K - 5647 16,32,64,128 scsi_cd 0 0K - 333 16 ithread 119 21K - 119 32,128,256 acpica 888 78K - 121045 16,32,64,128,256,512,1024 KTRACE 100 13K - 100 128 acpitask 0 0K - 1 64 linker 139 596K - 181 16,32,64,128,256,512,1024,2048 lockf 11 2K - 399 64,128 CAM dev queue 4 1K - 4 128 ip6ndp 5 1K - 5 64,128 temp 48 562K - 14544952 16,32,64,128,256,512,1024,2048,4096 devbuf 17105 36341K - 24988 16,32,64,128,512,1024,2048,4096 module 420 53K - 420 128 mtx_pool 1 8K - 1 osd 2 1K - 2 16 CAM queue 62 52K - 2211 16,32,64,128,256,512,1024,2048 subproc 562 722K - 6851 512,4096 proc 2 16K - 2 session 33 5K - 127 128 pgrp 37 5K - 190 128 cred 62 16K - 29192756 256 uidinfo 4 3K - 99 64,2048 plimit 17 5K - 910 256 acpisem 15 1K - 15 64 sysctltmp 0 0K - 13867 16,32,64,128,256,512,1024,2048,4096 sysctloid 5400 270K - 5782 16,32,64,128 sysctl 0 0K - 11423 16,32,64 callout 7 3584K - 7 umtx 780 98K - 780 128 p1003.1b 1 1K - 1 16 SWAP 2 3281K - 2 64 kbdmux 8 9K - 8 16,256,512,2048,4096 bus-sc 103 188K - 4558 16,32,64,128,256,512,1024,2048,4096 bus 1174 93K - 57792 16,32,64,128,256,512,1024 clist 54 7K - 54 128 devstat 32 65K - 32 32,4096 eventhandler 64 6K - 64 64,128 kobj 276 1104K - 387 4096 rman 144 18K - 601 16,32,128 mfibuf 3 21K - 12 32,256,512,2048,4096 sbuf 0 0K - 14350 16,32,64,128,256,512,1024,2048,4096 scsi_da 0 0K - 504 16 CAM SIM 4 1K - 4 256 stack 0 0K - 194 256 taskqueue 13 2K - 13 16,32,128 Unitno 11 1K - 4759 32,64 iov 0 0K - 1193 16,64,256,512 select 98 13K - 98 128 ioctlops 0 0K - 14716 16,32,64,128,256,512,1024,4096 msg 4 30K - 4 2048,4096 sem 4 8K - 4 512,1024,2048,4096 shm 1 16K - 1 tty 25 25K - 25 1024 pts 3 1K - 3 256 mbuf_tag 0 0K - 2 32 shmfd 1 8K - 1 CAM periph 54 14K - 371 16,32,64,128,256 pcb 28 157K - 148 16,32,128,1024,2048,4096 soname 5 1K - 18699 16,32,128 biobuf 4 8K - 6 2048 vfscache 1 1024K - 1 cl_savebuf 0 0K - 7 64,128 export_host 5 3K - 5 512 vfs_hash 1 512K - 1 vnodes 2 1K - 2 256 vnodemarker 0 0K - 4832 512 mount 222 15K - 807 16,32,64,128,256,1024 ata_generic 1 1K - 1 1024 BPF 4 1K - 4 128 ether_multi 22 2K - 24 16,32,64 ifaddr 54 14K - 54 32,64,128,256,512,4096 ifnet 5 9K - 5 256,2048 clone 5 20K - 5 4096 arpcom 3 1K - 3 16 routetbl 65 11K - 949 32,64,128,256,512 in_multi 3 1K - 3 64 sctp_iter 0 0K - 3 256 sctp_ifn 3 1K - 3 128 sctp_ifa 4 1K - 4 128 sctp_vrf 1 1K - 1 64 sctp_a_it 0 0K - 3 16 hostcache 1 28K - 1 acd_driver 1 2K - 1 2048 syncache 1 92K - 1 in6_multi 19 2K - 19 32,64,128 ip6_moptions 1 1K - 1 32 NFS FHA 13 3K - 18480347 64,2048 rpc 1381 716K - 82214178 32,64,128,256,512,2048 audit_evclass 168 6K - 205 32 newblk 1 1K - 1 512 inodedep 1 512K - 1 pagedep 1 128K - 1 ufs_dirhash 45 9K - 45 16,32,64,128,512 ufs_mount 3 11K - 3 512,2048 UMAHash 3 130K - 12 512,1024,2048,4096 acpidev 56 4K - 56 64 vm_pgdata 2 129K - 2 128 CAM XPT 589 369K - 2047 32,64,128,256,1024 io_apic 2 4K - 2 2048 pci_link 16 2K - 16 32,128 memdesc 1 4K - 1 4096 msi 3 1K - 3 128 nexusdev 3 1K - 3 16 entropy 1024 64K - 1024 64 twa_commands 2 104K - 101 256 atkbddev 2 1K - 2 64 UART 6 4K - 6 16,512,1024 USBHC 1 1K - 1 128 USBdev 30 11K - 30 16,32,64,128,256,512 USB 157 54K - 190 16,32,64,128,256,1024 DEVFS1 152 76K - 153 512 DEVFS3 165 42K - 167 256 DEVFS 16 1K - 17 16,128 solaris 822038 707024K - 235790398 16,32,64,128,256,512,1024,2048,4096 kstat_data 2 1K - 2 64 From bsam at ipt.ru Tue Nov 3 14:05:26 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Tue Nov 3 14:16:22 2009 Subject: [current] acroread: SIGSEGV Message-ID: <65275688@bb.ipt.ru> Hello List, print/acroread8 doesn't work for me at 9-CURRENT: ----- % uname -a FreeBSD host.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon Nov 2 15:15:13 MSK 2009 root@host.ipt.ru:/usr/obj/usr/src/sys/HOST % sysctl compat.linux compat.linux.oss_version: 198144 compat.linux.osrelease: 2.6.16 compat.linux.osname: Linux ------ Setting security.bsd.map_at_zero to 1 doesn't change anything. There is nothing at console/log files. Here is the tail of linux_kdump: ----- ... 78586 ld-2.9.so CALL linux_open(0x16fcd80,0,0x80d93000) 78586 ld-2.9.so NAMI "/compat/linux/var/db/fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" 78586 ld-2.9.so NAMI "/var/db/fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" 78586 ld-2.9.so RET linux_open JUSTRETURN 78586 ld-2.9.so CALL linux_open(0x16fcd80,0,0x80d93000) 78586 ld-2.9.so NAMI "/compat/linux/home/bsam/.fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" 78586 ld-2.9.so NAMI "/home/bsam/.fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" 78586 ld-2.9.so RET linux_open 4 78586 ld-2.9.so CALL linux_fstat64(0x4,0xbfbfcf8c,0x2e482ff4) 78586 ld-2.9.so RET linux_fstat64 0 78586 ld-2.9.so CALL read(0x4,0x16fe160,0x60) 78586 ld-2.9.so GIO fd 4 read 96 bytes "\^D\M-|\^B\M-|\^B\0\0\0`\0\0\0 \0\0\0P\0\0\0\0\0\0\0P\0\0\0\^[b\M-TJ/usr/local/lib/X11/fonts/encodings/large\0\0\0\0\0\0\0\0\0\0\ \0\0\0\0\0\0\^Q\0\0\0\0\0\0\000" 78586 ld-2.9.so RET read 96/0x60 78586 ld-2.9.so CALL close(0x4) 78586 ld-2.9.so RET close 0 78586 ld-2.9.so CALL linux_mmap2(0,0x25000,0x3,0x22,0xffffffff,0) 78586 ld-2.9.so RET linux_mmap2 833982464/0x31b59000 78586 ld-2.9.so PSIG SIGSEGV caught handler=0x83814b6 mask=0x0 code=0x0 78586 ld-2.9.so CALL linux_rt_sigaction(0x6,0xbfbfcbf0,0xbfbfcb64,0x8) 78586 ld-2.9.so RET linux_rt_sigaction 0 78586 ld-2.9.so CALL linux_exit_group(0x1) ----- -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From weldon at excelsusphoto.com Tue Nov 3 13:35:20 2009 From: weldon at excelsusphoto.com (Weldon S Godfrey 3) Date: Tue Nov 3 14:19:13 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: <200911030937.11619.pieter@degoeje.nl> References: <200911030937.11619.pieter@degoeje.nl> Message-ID: If memory serves me right, sometime around 9:37am, Pieter de Goeje told me: > Are you perhaps using em(4)? There was an mbuf leak in the driver, which was fixed recently. > You can check mbuf usage with netstat -m. > we are using onboard NICs on the Dell using the bce driver. We did try several times to see if using an intel PCIexpress card using the em driver, and we had the same symptoms. Could the bce driver have the same leak? Thanks! Weldon From amvandemore at gmail.com Tue Nov 3 14:18:53 2009 From: amvandemore at gmail.com (Adam Vande More) Date: Tue Nov 3 14:28:12 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: References: <1257185816.44755.29.camel@buffy.york.ac.uk> Message-ID: <6201873e0911030618u3984a7c1hc05331b0021f796f@mail.gmail.com> On Tue, Nov 3, 2009 at 7:32 AM, Weldon S Godfrey 3 wrote: > > > If memory serves me right, sometime around Yesterday, Gavin Atkinson told > me: > > Gavin, thank you A LOT for helping us with this, I have answered as much as > I can from the most recent crash below. We did hit max mbufs. It is at > 25Kclusters, which is the default. I have upped it to 32K because a rather > old article mentioned that as the top end and I need to get into work so I > am not trying to do this with a remote console to go higher. I have already > set it to reboot next with 64K clusters. I already have kmem maxed to what > is bootable (or at least at one time) in 8.0, 4GB, how high can I safely go? > This is a NFS server running ZFS with sustained 5 min averages of > 120-200Mb/s running as a store for a mail system. > > > Some things that would be useful: >> >> - Does "arp -da" fix things? >> > > no, it hangs like ssh, route add, etc > > > - What's the output of "netstat -m" while the networking is broken? >> > Tue Nov 3 07:02:11 CST 2009 > 36971/2033/39004 mbufs in use (current/cache/total) > 24869/731/25600/25600 mbuf clusters in use (current/cache/total/max) > 24314/731 mbuf+clusters out of packet secondary zone in use (current/cache) > 0/35/35/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 58980K/2110K/61091K bytes allocated to network (current/cache/total) > 0/201276/90662 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > > > > - What does CTRL-T show for the hung SSH or route processes? >> > > of the arp: > load: 0.01 cmd: arp 6144 [zonelimit] 0.00u 0.00s 0% 996k > > > - What does "procstat -kk" on the same processes show? >> > sorry I couldn't get this to run this time, remote console issues > > > - Does going to single user mode ("init 1" and killing off any leftover >> processes) cause the machine to start working again? If so, what's the >> output of "netstat -m" afterwards? >> > > no, mbuf was still maxed out > > > below is the last vmstat -m Type InUse MemUse HighUse Requests > Size(s) > ntfs_nthash 1 512K - 1 > pfs_nodes 20 5K - 20 256 > GEOM 262 52K - 4551 16,32,64,128,256,512,1024,2048 > isadev 9 2K - 9 128 > cdev 13 4K - 13 256 > sigio 1 1K - 1 64 > filedesc 127 64K - 6412 512,1024 > kenv 75 11K - 80 16,32,64,128 > kqueue 0 0K - 188 256,2048 > proc-args 41 2K - 5647 16,32,64,128 > scsi_cd 0 0K - 333 16 > ithread 119 21K - 119 32,128,256 > acpica 888 78K - 121045 16,32,64,128,256,512,1024 > KTRACE 100 13K - 100 128 > acpitask 0 0K - 1 64 > linker 139 596K - 181 16,32,64,128,256,512,1024,2048 > lockf 11 2K - 399 64,128 > CAM dev queue 4 1K - 4 128 > ip6ndp 5 1K - 5 64,128 > temp 48 562K - 14544952 > 16,32,64,128,256,512,1024,2048,4096 > devbuf 17105 36341K - 24988 16,32,64,128,512,1024,2048,4096 > module 420 53K - 420 128 > mtx_pool 1 8K - 1 > osd 2 1K - 2 16 > CAM queue 62 52K - 2211 16,32,64,128,256,512,1024,2048 > subproc 562 722K - 6851 512,4096 > proc 2 16K - 2 > session 33 5K - 127 128 > pgrp 37 5K - 190 128 > cred 62 16K - 29192756 256 > uidinfo 4 3K - 99 64,2048 > plimit 17 5K - 910 256 > acpisem 15 1K - 15 64 > sysctltmp 0 0K - 13867 > 16,32,64,128,256,512,1024,2048,4096 > sysctloid 5400 270K - 5782 16,32,64,128 > sysctl 0 0K - 11423 16,32,64 > callout 7 3584K - 7 > umtx 780 98K - 780 128 > p1003.1b 1 1K - 1 16 > SWAP 2 3281K - 2 64 > kbdmux 8 9K - 8 16,256,512,2048,4096 > bus-sc 103 188K - 4558 > 16,32,64,128,256,512,1024,2048,4096 > bus 1174 93K - 57792 16,32,64,128,256,512,1024 > clist 54 7K - 54 128 > devstat 32 65K - 32 32,4096 > eventhandler 64 6K - 64 64,128 > kobj 276 1104K - 387 4096 > rman 144 18K - 601 16,32,128 > mfibuf 3 21K - 12 32,256,512,2048,4096 > sbuf 0 0K - 14350 > 16,32,64,128,256,512,1024,2048,4096 > scsi_da 0 0K - 504 16 > CAM SIM 4 1K - 4 256 > stack 0 0K - 194 256 > taskqueue 13 2K - 13 16,32,128 > Unitno 11 1K - 4759 32,64 > iov 0 0K - 1193 16,64,256,512 > select 98 13K - 98 128 > ioctlops 0 0K - 14716 16,32,64,128,256,512,1024,4096 > msg 4 30K - 4 2048,4096 > sem 4 8K - 4 512,1024,2048,4096 > shm 1 16K - 1 > tty 25 25K - 25 1024 > pts 3 1K - 3 256 > mbuf_tag 0 0K - 2 32 > shmfd 1 8K - 1 > CAM periph 54 14K - 371 16,32,64,128,256 > pcb 28 157K - 148 16,32,128,1024,2048,4096 > soname 5 1K - 18699 16,32,128 > biobuf 4 8K - 6 2048 > vfscache 1 1024K - 1 > cl_savebuf 0 0K - 7 64,128 > export_host 5 3K - 5 512 > vfs_hash 1 512K - 1 > vnodes 2 1K - 2 256 > vnodemarker 0 0K - 4832 512 > mount 222 15K - 807 16,32,64,128,256,1024 > ata_generic 1 1K - 1 1024 > BPF 4 1K - 4 128 > ether_multi 22 2K - 24 16,32,64 > ifaddr 54 14K - 54 32,64,128,256,512,4096 > ifnet 5 9K - 5 256,2048 > clone 5 20K - 5 4096 > arpcom 3 1K - 3 16 > routetbl 65 11K - 949 32,64,128,256,512 > in_multi 3 1K - 3 64 > sctp_iter 0 0K - 3 256 > sctp_ifn 3 1K - 3 128 > sctp_ifa 4 1K - 4 128 > sctp_vrf 1 1K - 1 64 > sctp_a_it 0 0K - 3 16 > hostcache 1 28K - 1 > acd_driver 1 2K - 1 2048 > syncache 1 92K - 1 > in6_multi 19 2K - 19 32,64,128 > ip6_moptions 1 1K - 1 32 > NFS FHA 13 3K - 18480347 64,2048 > rpc 1381 716K - 82214178 32,64,128,256,512,2048 > audit_evclass 168 6K - 205 32 > newblk 1 1K - 1 512 > inodedep 1 512K - 1 > pagedep 1 128K - 1 > ufs_dirhash 45 9K - 45 16,32,64,128,512 > ufs_mount 3 11K - 3 512,2048 > UMAHash 3 130K - 12 512,1024,2048,4096 > acpidev 56 4K - 56 64 > vm_pgdata 2 129K - 2 128 > CAM XPT 589 369K - 2047 32,64,128,256,1024 > io_apic 2 4K - 2 2048 > pci_link 16 2K - 16 32,128 > memdesc 1 4K - 1 4096 > msi 3 1K - 3 128 > nexusdev 3 1K - 3 16 > entropy 1024 64K - 1024 64 > twa_commands 2 104K - 101 256 > atkbddev 2 1K - 2 64 > UART 6 4K - 6 16,512,1024 > USBHC 1 1K - 1 128 > USBdev 30 11K - 30 16,32,64,128,256,512 > USB 157 54K - 190 16,32,64,128,256,1024 > DEVFS1 152 76K - 153 512 > DEVFS3 165 42K - 167 256 > DEVFS 16 1K - 17 16,128 > solaris 822038 707024K - 235790398 > 16,32,64,128,256,512,1024,2048,4096 > kstat_data 2 1K - 2 64 > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > from man tuning: kern.ipc.nmbclusters may be adjusted to increase the number of network mbufs the system is willing to allocate. Each cluster represents approx- imately 2K of memory, so a value of 1024 represents 2M of kernel memory reserved for network buffers. You can do a simple calculation to figure out how many you need. If you have a web server which maxes out at 1000 simultaneous connections, and each connection eats a 16K receive and 16K send buffer, you need approximately 32MB worth of network buffers to deal with it. A good rule of thumb is to multiply by 2, so 32MBx2 = 64MB/2K = 32768. So for this case you would want to set kern.ipc.nmbclusters to 32768. We recommend values between 1024 and 4096 for machines with mod- erates amount of memory, and between 4096 and 32768 for machines with greater amounts of memory. Under no circumstances should you specify an arbitrarily high value for this parameter, it could lead to a boot-time crash. The -m option to netstat(1) may be used to observe network clus- ter use. Older versions of FreeBSD do not have this tunable and require that the kernel config(8) option NMBCLUSTERS be set instead. More and more programs are using the sendfile(2) system call to transmit files over the network. The kern.ipc.nsfbufs sysctl controls the number of file system buffers sendfile(2) is allowed to use to perform its work. This parameter nominally scales with kern.maxusers so you should not need to modify this parameter except under extreme circumstances. See the TUNING section in the sendfile(2) manual page for details. -- Adam Vande More From mailinglists at alchemy-networks.co.uk Tue Nov 3 14:28:56 2009 From: mailinglists at alchemy-networks.co.uk (Paul G Webster) Date: Tue Nov 3 14:45:09 2009 Subject: 8.0-RC2 mangles msdosfs In-Reply-To: <20091103012810.GB31768@lonesome.com> References: <4AEBFAA3.9020003@bsdforen.de> <20091103012810.GB31768@lonesome.com> Message-ID: As an example, this is a 1GB fat32 disk. da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 956MB (1957888 512 byte sectors: 64H 32S/T 956C) desktop1# ls /dev | grep da0~ desktop1# ls /dev | grep da0 da0 desktop1# fdisk /dev/da0 ******* Working on device /dev/da0 ******* parameters extracted from in-core disklabel are: cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl) parameters to be used for BIOS calculations are: cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 114 (0x72),(unknown) start 778135908, size 1141509631 (557377 Meg), flag 6f beg: cyl 357/ head 116/ sector 40; end: cyl 357/ head 32/ sector 45 The data for partition 2 is: sysid 101 (0x65),(Novell Netware/386 3.xx) start 168689522, size 1936028240 (945326 Meg), flag 69 beg: cyl 288/ head 115/ sector 43; end: cyl 367/ head 114/ sector 50 The data for partition 3 is: sysid 121 (0x79),(QNX4.x 3rd part) start 1869881465, size 1936028192 (945326 Meg), flag 73 beg: cyl 366/ head 32/ sector 33; end: cyl 357/ head 32/ sector 43 The data for partition 4 is: sysid 13 (0x0d),(unknown) start 0, size 3637226496 (1775989 Meg), flag 74 beg: cyl 372/ head 97/ sector 50; end: cyl 0/ head 10/ sector 0 desktop1# On Tue, 03 Nov 2009 01:28:10 -0000, Mark Linimon wrote: > On Tue, Nov 03, 2009 at 02:03:29AM +0100, Alexander Best wrote: >> i guess the freebsd-fs@ guys know about these problems but don't have >> the time to deal with it. most of them are probably working on zfs. > > AFAIK there are only a handful of people working on ZFS. > > We certainly need more people willing to work on filesystems code. In > general it does have a large learning curve, so it's not as attractive > as some of the other areas. That's probably why, as the kernel has > undergone radical changes (e.g. for SMP) over time, that some of the > fs code has not kept up. > > mcl > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From gavin at FreeBSD.org Tue Nov 3 15:13:55 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Nov 3 15:29:43 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: References: <1257185816.44755.29.camel@buffy.york.ac.uk> Message-ID: <1257261214.98619.92.camel@buffy.york.ac.uk> On Tue, 2009-11-03 at 08:32 -0500, Weldon S Godfrey 3 wrote: > > If memory serves me right, sometime around Yesterday, Gavin Atkinson told me: > > Gavin, thank you A LOT for helping us with this, I have answered as much > as I can from the most recent crash below. We did hit max mbufs. It is > at 25Kclusters, which is the default. I have upped it to 32K because a > rather old article mentioned that as the top end and I need to get into > work so I am not trying to do this with a remote console to go higher. I > have already set it to reboot next with 64K clusters. I already have kmem > maxed to what is bootable (or at least at one time) in 8.0, 4GB, how high > can I safely go? This is a NFS server running ZFS with sustained 5 min > averages of 120-200Mb/s running as a store for a mail system. > > > Some things that would be useful: > > > > - Does "arp -da" fix things? > > no, it hangs like ssh, route add, etc > > > - What's the output of "netstat -m" while the networking is broken? > Tue Nov 3 07:02:11 CST 2009 > 36971/2033/39004 mbufs in use (current/cache/total) > 24869/731/25600/25600 mbuf clusters in use (current/cache/total/max) > 24314/731 mbuf+clusters out of packet secondary zone in use > (current/cache) > 0/35/35/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 58980K/2110K/61091K bytes allocated to network (current/cache/total) > 0/201276/90662 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines OK, at least we've figured out what is going wrong then. As a workaround to get the machine to stay up longer, you should be able to set kern.ipc.nmbclusters=256000 in /boot/loader.conf -but hopefully we can resolve this soon. Firstly, what kernel was the above output from? And what network card are you using? In your initial post you mentioned testing both bce(4) and em(4) cards, be aware that em(4) had an issue that would cause exactly this issue, which was fixed with a commit on September 11th (r197093). Make sure your kernel is from after that date if you are using em(4). I guess it is also possible that bce(4) has the same issue, I'm not aware of any fixes to it recently. So, from here, I think the best thing would be to just use the em(4) NIC and an up-to-date kernel, and see if you can reproduce the issue. How important is this machine? If em(4) works, are you able to help debug the issues with the bce(4) driver? Thanks, Gavin From kostikbel at gmail.com Tue Nov 3 15:47:53 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Nov 3 15:51:36 2009 Subject: [current] acroread: SIGSEGV In-Reply-To: <65275688@bb.ipt.ru> References: <65275688@bb.ipt.ru> Message-ID: <20091103154747.GC2331@deviant.kiev.zoral.com.ua> On Tue, Nov 03, 2009 at 05:05:11PM +0300, Boris Samorodov wrote: > Hello List, > > print/acroread8 doesn't work for me at 9-CURRENT: > ----- > % uname -a > FreeBSD host.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon Nov 2 15:15:13 MSK 2009 root@host.ipt.ru:/usr/obj/usr/src/sys/HOST > % sysctl compat.linux > compat.linux.oss_version: 198144 > compat.linux.osrelease: 2.6.16 > compat.linux.osname: Linux > ------ > > Setting security.bsd.map_at_zero to 1 doesn't change anything. There is > nothing at console/log files. Here is the tail of linux_kdump: > ----- > ... > 78586 ld-2.9.so CALL linux_open(0x16fcd80,0,0x80d93000) > 78586 ld-2.9.so NAMI "/compat/linux/var/db/fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > 78586 ld-2.9.so NAMI "/var/db/fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > 78586 ld-2.9.so RET linux_open JUSTRETURN > 78586 ld-2.9.so CALL linux_open(0x16fcd80,0,0x80d93000) > 78586 ld-2.9.so NAMI "/compat/linux/home/bsam/.fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > 78586 ld-2.9.so NAMI "/home/bsam/.fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > 78586 ld-2.9.so RET linux_open 4 > 78586 ld-2.9.so CALL linux_fstat64(0x4,0xbfbfcf8c,0x2e482ff4) > 78586 ld-2.9.so RET linux_fstat64 0 > 78586 ld-2.9.so CALL read(0x4,0x16fe160,0x60) > 78586 ld-2.9.so GIO fd 4 read 96 bytes > "\^D\M-|\^B\M-|\^B\0\0\0`\0\0\0 \0\0\0P\0\0\0\0\0\0\0P\0\0\0\^[b\M-TJ/usr/local/lib/X11/fonts/encodings/large\0\0\0\0\0\0\0\0\0\0\ > \0\0\0\0\0\0\^Q\0\0\0\0\0\0\000" > 78586 ld-2.9.so RET read 96/0x60 > 78586 ld-2.9.so CALL close(0x4) > 78586 ld-2.9.so RET close 0 > 78586 ld-2.9.so CALL linux_mmap2(0,0x25000,0x3,0x22,0xffffffff,0) > 78586 ld-2.9.so RET linux_mmap2 833982464/0x31b59000 > 78586 ld-2.9.so PSIG SIGSEGV caught handler=0x83814b6 mask=0x0 code=0x0 > 78586 ld-2.9.so CALL linux_rt_sigaction(0x6,0xbfbfcbf0,0xbfbfcb64,0x8) > 78586 ld-2.9.so RET linux_rt_sigaction 0 > 78586 ld-2.9.so CALL linux_exit_group(0x1) It would be interesting to see which address faulted. If not, can you do search for a kernel revision that broke acroread ? Good starting points are r198507 and r198554. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091103/19c4923d/attachment.pgp From tom at tomjudge.com Tue Nov 3 15:52:25 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Nov 3 15:55:59 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: References: <200911030937.11619.pieter@degoeje.nl> Message-ID: <4AF05177.7030705@tomjudge.com> Weldon S Godfrey 3 wrote: > > > If memory serves me right, sometime around 9:37am, Pieter de Goeje told me: > >> Are you perhaps using em(4)? There was an mbuf leak in the driver, >> which was fixed recently. >> You can check mbuf usage with netstat -m. >> > > we are using onboard NICs on the Dell using the bce driver. We did try > several times to see if using an intel PCIexpress card using the em > driver, and we had the same symptoms. > > Could the bce driver have the same leak? The bce driver does not have a memory leak, it does however have a bug which causes memory fragmentation leading to denied mbuf allocation. There is a work around for this in current, you can get the patch like this: http://svn.freebsd.org/viewvc/base/head/ You need to put options BCE_JUMBO_HDRSPLIT In your kernel to enable the work arround. Tom From kamikaze at bsdforen.de Tue Nov 3 15:57:10 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Tue Nov 3 15:57:54 2009 Subject: mixer settings on 8.0-RC2 In-Reply-To: <200911031045.03823.gnemmi@gmail.com> References: <4AEEDCFB.3060604@bsdforen.de> <200911021356.43043.gnemmi@gmail.com> <4AEFD6AE.6020906@bsdforen.de> <200911031045.03823.gnemmi@gmail.com> Message-ID: <4AF052D4.8060401@bsdforen.de> Gonzalo Nemmi wrote: > On Tuesday 03 November 2009 5:07:26 am Dominic Fandrey wrote: >> Gonzalo Nemmi wrote: >>> On Monday 02 November 2009 11:22:03 am Dominic Fandrey wrote: >>>> It appears that my 8.0-RC2 system (notebook) forgets its mixer >>>> settings with every reboot. >>>> >>>> FreeBSD mobileKamikaze.norad 8.0-RC2 FreeBSD 8.0-RC2 #0: Sat Oct >>>> 31 02:49:30 CET 2009 >>>> root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6 >>>> 510 b-8 amd64 >>>> >>>> Regards >>> May I ask how are you setting them? >>> >>> Regards >>> Gonzalo >> With mixer(8). But now the settings are remembered. >> >> I suppose some evil app is to blame. But nothing apart from Skype >> comes to mind and I configured it not to touch the mixer settings. >> >> Regards > > Sorry but I have to ask ... have you tried configuring mixer settings as > described in section 7.2.4 of the FreBSD handbook? > > That is to say: > > "The default values for the different mixer channels are hardcoded in > the sourcecode of the pcm(4) driver. There are many different > applications and daemons that allow you to set values for the mixer > that are remembered between invocations, but this is not a clean > solution. ... Rather outdated in my opinion. Automatic mixer remembering without configuring anything has ever worked since I started using FreeBSD (i.e. 2005). From jhb at freebsd.org Tue Nov 3 16:08:11 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Nov 3 16:08:32 2009 Subject: bootstrap loader problem In-Reply-To: <4AEE296B.5040302@siad.net> References: <4AEE296B.5040302@siad.net> Message-ID: <200911031019.36362.jhb@freebsd.org> On Sunday 01 November 2009 7:35:55 pm Don L. Belcher wrote: > New Dell 1737 laptop > > The following error occurs with versions 7.2 release and later > this message is from 8 RC2. All versions tried with 7.1 release and > earlier work fine, I tried 7.1, 7.2 and 6.4. I rebuilt 8 RC2 CD with > "loader" > from 7.1 release and the 8 RC2 comes up O.K. now. > I have two questions: > 1) is anybody familiar with this problem > 2) is it ok to install 8 RC2 using the 7.1 "loader" > > BTX loader 1.00 BTX version is 1.02 > Consoles: internal video/keyboard > panic: free: guard1 fail @ 0xbb797074 from (diretory path to) > common/console.c:94 > --> Press a key (etc) I have not seen that before. Can you try compiling a loader on 8 that doesn't include GPT support? (cd /sys/boot; make LOADER_NO_GPT_SUPPORT=yes) A loader from 7.1 should work ok on 8.0. -- John Baldwin From pieter at degoeje.nl Tue Nov 3 16:46:34 2009 From: pieter at degoeje.nl (Pieter de Goeje) Date: Tue Nov 3 16:46:40 2009 Subject: mixer settings on 8.0-RC2 In-Reply-To: <4AF052D4.8060401@bsdforen.de> References: <4AEEDCFB.3060604@bsdforen.de> <200911031045.03823.gnemmi@gmail.com> <4AF052D4.8060401@bsdforen.de> Message-ID: <200911031746.31571.pieter@degoeje.nl> On Tuesday 03 November 2009 16:57:08 Dominic Fandrey wrote: > Gonzalo Nemmi wrote: > > On Tuesday 03 November 2009 5:07:26 am Dominic Fandrey wrote: > >> Gonzalo Nemmi wrote: > >>> On Monday 02 November 2009 11:22:03 am Dominic Fandrey wrote: > >>>> It appears that my 8.0-RC2 system (notebook) forgets its mixer > >>>> settings with every reboot. > >>>> > >>>> FreeBSD mobileKamikaze.norad 8.0-RC2 FreeBSD 8.0-RC2 #0: Sat Oct > >>>> 31 02:49:30 CET 2009 > >>>> root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6 > >>>> 510 b-8 amd64 > >>>> > >>>> Regards > >>> May I ask how are you setting them? > >>> > >>> Regards > >>> Gonzalo > >> With mixer(8). But now the settings are remembered. > >> > >> I suppose some evil app is to blame. But nothing apart from Skype > >> comes to mind and I configured it not to touch the mixer settings. > >> > >> Regards > > > > Sorry but I have to ask ... have you tried configuring mixer settings as > > described in section 7.2.4 of the FreBSD handbook? > > > > That is to say: > > > > "The default values for the different mixer channels are hardcoded in > > the sourcecode of the pcm(4) driver. There are many different > > applications and daemons that allow you to set values for the mixer > > that are remembered between invocations, but this is not a clean > > solution. ... > > Rather outdated in my opinion. Automatic mixer remembering without > configuring anything has ever worked since I started using FreeBSD > (i.e. 2005). Perhaps you are using reboot/halt instead of shutdown? Reboot and halt will not start the shutdown scripts. -- Pieter de Goeje From weldon at excelsusphoto.com Tue Nov 3 15:43:37 2009 From: weldon at excelsusphoto.com (Weldon S Godfrey 3) Date: Tue Nov 3 16:49:10 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: <1257261214.98619.92.camel@buffy.york.ac.uk> References: <1257185816.44755.29.camel@buffy.york.ac.uk> <1257261214.98619.92.camel@buffy.york.ac.uk> Message-ID: If memory serves me right, sometime around 3:13pm, Gavin Atkinson told me: > OK, at least we've figured out what is going wrong then. As a > workaround to get the machine to stay up longer, you should be able to > set kern.ipc.nmbclusters=256000 in /boot/loader.conf -but hopefully we > can resolve this soon. > > Firstly, what kernel was the above output from? And what network card > are you using? In your initial post you mentioned testing both bce(4) > and em(4) cards, be aware that em(4) had an issue that would cause > exactly this issue, which was fixed with a commit on September 11th > (r197093). Make sure your kernel is from after that date if you are > using em(4). I guess it is also possible that bce(4) has the same > issue, I'm not aware of any fixes to it recently. > > So, from here, I think the best thing would be to just use the em(4) NIC > and an up-to-date kernel, and see if you can reproduce the issue. > > How important is this machine? If em(4) works, are you able to help > debug the issues with the bce(4) driver? > > Thanks, > > Gavin > we used the em card only a few times, but each time we used it, the problem happened so we have been staying with the on board nics using the bce driver. Would leaving in the em card cause any issues, even if it isn't up? This output was from a kernel on 12/08. The issue really came up while we tried to swap to 8.0-RC2. We plan to swap back sometime in the near future. The same symptoms happened with RC2 so I am sure it is a kmem exhaustion. I am guessing v3 requires a lot more. When we switch, i'll change to using the em card. This machine is very important. I could set up an additional machine, but I don't have the ability to simulate the load nor have the large drive array attached. Thanks! Weldon From tom at tomjudge.com Tue Nov 3 16:54:47 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Nov 3 16:54:54 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: <4AF05177.7030705@tomjudge.com> References: <200911030937.11619.pieter@degoeje.nl> <4AF05177.7030705@tomjudge.com> Message-ID: <4AF06017.6000505@tomjudge.com> Tom Judge wrote: > Weldon S Godfrey 3 wrote: >> >> >> If memory serves me right, sometime around 9:37am, Pieter de Goeje >> told me: >> >>> Are you perhaps using em(4)? There was an mbuf leak in the driver, >>> which was fixed recently. >>> You can check mbuf usage with netstat -m. >>> >> >> we are using onboard NICs on the Dell using the bce driver. We did >> try several times to see if using an intel PCIexpress card using the >> em driver, and we had the same symptoms. >> >> Could the bce driver have the same leak? > > The bce driver does not have a memory leak, it does however have a bug > which causes memory fragmentation leading to denied mbuf allocation. > > > There is a work around for this in current, you can get the patch like > this: > > http://svn.freebsd.org/viewvc/base/head/ > That should be: svn diff -r 198319:198320 http://svn.freebsd.org/base/head > You need to put > > options BCE_JUMBO_HDRSPLIT > > In your kernel to enable the work arround. > > Tom > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From gavin at FreeBSD.org Tue Nov 3 17:02:34 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Nov 3 17:02:41 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: References: <1257185816.44755.29.camel@buffy.york.ac.uk> <1257261214.98619.92.camel@buffy.york.ac.uk> Message-ID: <1257267727.98619.111.camel@buffy.york.ac.uk> On Tue, 2009-11-03 at 10:43 -0500, Weldon S Godfrey 3 wrote: > This output was from a kernel on 12/08. The issue really came up while we > tried to swap to 8.0-RC2. We plan to swap back sometime in the near > future. The same symptoms happened with RC2 so I am sure it is a kmem > exhaustion. I am guessing v3 requires a lot more. When we switch, i'll > change to using the em card. Sorry, can you clarify: have you ever tested the em card with the 8.0-RC2 kernel? > This machine is very important. I could set up an additional machine, but > I don't have the ability to simulate the load nor have the large drive > array attached. OK, thanks. Gavin From atkin901 at yahoo.com Tue Nov 3 17:26:40 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Tue Nov 3 17:26:47 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091031231545.493cee89@boiler.free.de> References: <20091031231545.493cee89@boiler.free.de> Message-ID: Kai Gallasch wrote: > Hi. > > I installed 8.0RC2-amd64 on an 8-core opteron server a few days ago. > > When I try to do a make buildworld or make buildkernel the server > reboots without any message left in the logs. The same happens > when building bigger ports (for example ruby18 or perl58) > > With 8.0-RC2 debug flags and witness seem to be disabled in the > standard GENERIC kernel, so unfortunately it is not possible for me to > build a debug kernel without my server crashing.. > > Now my idea was to install the old 8.0-BETA4 and upgrade to RC2 through > makeworld + buildkernel (gdb+witness). But no luck. When trying to > upgrade to RC2 the 8.0-BETA4 also crashes. At least 8.0-BETA4 has debug > + witness active in the GENERIC kernel.. > > So below some debug output of 8.0-BETA4 crashing. Has a vfs/ffs LOR > problem with the BETA4 already been fixed? > > Does it make sense to send in a pr with the old 8.0-BETA4? > > BTW. I installed 7.2-STABLE on this same server and did a "make > buildworld" and "make buildkernel" which completed without any problem. > > Cheers, > --Kai > > > ----- make buildworld -j7 crash, freebsd 8.0-amd64-beta4 ----- Definitely try the usual memory testing, power supply testing, etc. I had a similar problem, but with a HP DL385G5 that has some sort of "memory issue," and it would just silently reboot (which turned out to be a machine check exception.) I could never finger the problem be it with bios, the actual memory, or the fact that there's only one 4 core cpu on a two socket board and only the associated memory bank filled. I did various memory swaps to no avail, it would run memtest86 all day with no errors, and in the end I just turned superpages off and it works . Like a champ. If vm.pmap.pg_ps_enabled is 1 in 8.0-rc2, you might try rebooting with vm.pmap.pg_ps_enabled="0" in /boot/loader.conf and try another buildworld. From ivoras at gmail.com Tue Nov 3 17:08:35 2009 From: ivoras at gmail.com (Ivan Voras) Date: Tue Nov 3 17:34:24 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: Message-ID: <9308879887.941738356@gmail.com> Something else just occured to me - do you use ipfw? -- Sent from my p1i mobile phone ------- Original message ------- > From: Weldon S Godfrey 3 > Cc: freebsd-current@freebsd.org, ivoras@freebsd.org > Sent: 3.11.'09, 14:35 > > > > If memory serves me right, sometime around 9:37am, Pieter de Goeje told > me: > >> Are you perhaps using em(4)? There was an mbuf leak in the driver, which >> was fixed recently. >> You can check mbuf usage with netstat -m. >> > > we are using onboard NICs on the Dell using the bce driver. We did try > several times to see if using an intel PCIexpress card using the em > driver, and we had the same symptoms. > > Could the bce driver have the same leak? > > Thanks! > > Weldon From gnemmi at gmail.com Tue Nov 3 17:34:17 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Nov 3 17:34:24 2009 Subject: mixer settings on 8.0-RC2 In-Reply-To: <200911031746.31571.pieter@degoeje.nl> References: <4AEEDCFB.3060604@bsdforen.de> <200911031045.03823.gnemmi@gmail.com> <4AF052D4.8060401@bsdforen.de> <200911031746.31571.pieter@degoeje.nl> Message-ID: <19e9a5dc0911030934r601a4f23w20b9f23b51752327@mail.gmail.com> On Tue, Nov 3, 2009 at 5:46 PM, Pieter de Goeje wrote: > On Tuesday 03 November 2009 16:57:08 Dominic Fandrey wrote: > > Gonzalo Nemmi wrote: > > > On Tuesday 03 November 2009 5:07:26 am Dominic Fandrey wrote: > > >> Gonzalo Nemmi wrote: > > >>> On Monday 02 November 2009 11:22:03 am Dominic Fandrey wrote: > > >>>> It appears that my 8.0-RC2 system (notebook) forgets its mixer > > >>>> settings with every reboot. > > >>>> > > >>>> FreeBSD mobileKamikaze.norad 8.0-RC2 FreeBSD 8.0-RC2 #0: Sat Oct > > >>>> 31 02:49:30 CET 2009 > > >>>> root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6 > > >>>> 510 b-8 amd64 > > >>>> > > >>>> Regards > > >>> May I ask how are you setting them? > > >>> > > >>> Regards > > >>> Gonzalo > > >> With mixer(8). But now the settings are remembered. > > >> > > >> I suppose some evil app is to blame. But nothing apart from Skype > > >> comes to mind and I configured it not to touch the mixer settings. > > >> > > >> Regards > > > > > > Sorry but I have to ask ... have you tried configuring mixer settings > as > > > described in section 7.2.4 of the FreBSD handbook? > > > > > > That is to say: > > > > > > "The default values for the different mixer channels are hardcoded in > > > the sourcecode of the pcm(4) driver. There are many different > > > applications and daemons that allow you to set values for the mixer > > > that are remembered between invocations, but this is not a clean > > > solution. ... > > > > Rather outdated in my opinion. Automatic mixer remembering without > > configuring anything has ever worked since I started using FreeBSD > > (i.e. 2005). > > Perhaps you are using reboot/halt instead of shutdown? > Reboot and halt will not start the shutdown scripts. > > -- > Pieter de Goeje > yup ... I use reboot or halt -p From alexbestms at math.uni-muenster.de Tue Nov 3 17:46:25 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Tue Nov 3 17:46:33 2009 Subject: 8.0-RC2 mangles msdosfs In-Reply-To: Message-ID: Paul G Webster schrieb am 2009-11-03: > As an example, this is a 1GB fat32 disk. > da0 at umass-sim0 bus 0 target 0 lun 0 > da0: Removable Direct Access SCSI-0 device > da0: 1.000MB/s transfers > da0: 956MB (1957888 512 byte sectors: 64H 32S/T 956C) > desktop1# ls /dev | grep da0~ > desktop1# ls /dev | grep da0 > da0 > desktop1# fdisk /dev/da0 > ******* Working on device /dev/da0 ******* > parameters extracted from in-core disklabel are: > cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl) > parameters to be used for BIOS calculations are: > cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl) > Media sector size is 512 > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 1 is: > sysid 114 (0x72),(unknown) > start 778135908, size 1141509631 (557377 Meg), flag 6f > beg: cyl 357/ head 116/ sector 40; > end: cyl 357/ head 32/ sector 45 > The data for partition 2 is: > sysid 101 (0x65),(Novell Netware/386 3.xx) > start 168689522, size 1936028240 (945326 Meg), flag 69 > beg: cyl 288/ head 115/ sector 43; > end: cyl 367/ head 114/ sector 50 > The data for partition 3 is: > sysid 121 (0x79),(QNX4.x 3rd part) > start 1869881465, size 1936028192 (945326 Meg), flag 73 > beg: cyl 366/ head 32/ sector 33; > end: cyl 357/ head 32/ sector 43 > The data for partition 4 is: > sysid 13 (0x0d),(unknown) > start 0, size 3637226496 (1775989 Meg), flag 74 > beg: cyl 372/ head 97/ sector 50; > end: cyl 0/ head 10/ sector 0 > desktop1# *lol* just tried this myself and my fdisk output looks just as bad as yours: ******* Working on device da0 ******* parameters extracted from in-core disklabel are: cylinders=242 heads=255 sectors/track=63 (16065 blks/cyl) parameters to be used for BIOS calculations are: cylinders=242 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 110 (0x6e),(unknown) start 1768187213, size 1701211749 (830669 Meg), flag 65 beg: cyl 357/ head 114/ sector 46; end: cyl 10/ head 255/ sector 13 The data for partition 2 is: sysid 255 (0xff),(Xenix bad blocks table) start 1953723749, size 980709985 (478862 Meg), flag 68 beg: cyl 370/ head 108/ sector 37; end: cyl 78/ head 13/ sector 10 The data for partition 3 is: sysid 116 (0x74),(unknown) start 1801683314, size 168652389 (82349 Meg), flag 20 beg: cyl 371/ head 84/ sector 33; end: cyl 100/ head 101/ sector 32 The data for partition 4 is: sysid 0 (0000),(unused) start 2885681152, size 54212 (26 Meg), flag 0 beg: cyl 0/ head 0/ sector 0; end: cyl 0/ head 0/ sector 0 `file -s /dev/da0` reports: /dev/da0: x86 boot sector, Microsoft Windows XP Bootloader (4.german) NTLDR, code offset 0x58, OEM-ID "MSDOS5.0", sectors/cluster 8, reserved sectors 38, Media descriptor 0xf8, heads 255, sectors 3903487 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 3805, serial number 0x88e88370, unlabeled `fdisk` in general seems to need some updates. this is the output if i call `fdisk` without any args: fdisk: mounted root fs resource doesn't match expectations (regexec returned 1) alex > On Tue, 03 Nov 2009 01:28:10 -0000, Mark Linimon > wrote: > >On Tue, Nov 03, 2009 at 02:03:29AM +0100, Alexander Best wrote: > >>i guess the freebsd-fs@ guys know about these problems but don't > >>have > >>the time to deal with it. most of them are probably working on > >>zfs. > >AFAIK there are only a handful of people working on ZFS. > >We certainly need more people willing to work on filesystems code. > >In > >general it does have a large learning curve, so it's not as > >attractive > >as some of the other areas. That's probably why, as the kernel has > >undergone radical changes (e.g. for SMP) over time, that some of the > >fs code has not kept up. > >mcl > >_______________________________________________ > >freebsd-current@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-current > >To unsubscribe, send any mail to > >"freebsd-current-unsubscribe@freebsd.org" > -- > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From pyunyh at gmail.com Tue Nov 3 17:55:40 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Tue Nov 3 17:55:51 2009 Subject: aue0 detected as ue0 on 8.0-RC2 In-Reply-To: <1257243047.98619.8.camel@buffy.york.ac.uk> References: <5aaae08a0910311359v45cc9dc9h2826d8a29bfb5575@mail.gmail.com> <1257243047.98619.8.camel@buffy.york.ac.uk> Message-ID: <20091103175501.GD1256@michelle.cdnetworks.com> On Tue, Nov 03, 2009 at 10:10:47AM +0000, Gavin Atkinson wrote: > [freebsd-current cc'd, as that was where the thread started, but this > probably belongs on -usb, replies should go there] > > On Sat, 2009-10-31 at 21:59 +0100, Rick van der Zwet wrote: > > The first net interface of a aue(4) define used to be called aue0 > > afaik. But is now called ue0 (declared in usb/net/usb_ethernet.c). (no > > sign of ue(4) btw). > > > > I was looking in the UPDATING, man, mailinglists freebsd-usb@ and > > freebsd-current@. But I could not find the reason why the naming > > convention on this aue differs from the regular stuff, anybody? > > > > /Rick > > > > quick# dmesg | tail -8 > > ugen1.3: at usbus1 > > aue0: on usbus1 > > miibus1: on aue0 > > ukphy0: PHY 1 on miibus1 > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > ue0: on aue0 > > ue0: Ethernet address: 00:00:e8:00:11:36 > > ue0: link state changed to DOWN > > > > quick# ifconfig -l > > bfe0 lo0 ue0 > > Hmm, this looks like a serious bug, possibly in the new USB subsystem > (HPS CC'd). > > I've got an axe(4) device, which also does the same: > > ugen7.3: at usbus7 > axe0: on usbus7 > axe0: PHYADDR 0xe0:0x10 > miibus1: on axe0 > ukphy0: PHY 16 on miibus1 > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on axe0 > ue0: Ethernet address: 00:50:b6:05:57:a7 > ue0: link state changed to DOWN > I'm not sure this is feature of new USB or bug. I don't have strong objections on current behavior but looks like I'm seeing Linux behavior. Traditionally all network interfaces used their own driver name. I think this change should be documented in UPDATING. > Gavin From rnoland at FreeBSD.org Tue Nov 3 18:01:22 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Tue Nov 3 18:01:30 2009 Subject: 8.0-RC2 mangles msdosfs In-Reply-To: References: Message-ID: <1257271265.18564.0.camel@balrog.2hip.net> On Tue, 2009-11-03 at 18:46 +0100, Alexander Best wrote: > Paul G Webster schrieb am 2009-11-03: > > As an example, this is a 1GB fat32 disk. > > > > da0 at umass-sim0 bus 0 target 0 lun 0 > > da0: Removable Direct Access SCSI-0 device > > da0: 1.000MB/s transfers > > da0: 956MB (1957888 512 byte sectors: 64H 32S/T 956C) > > desktop1# ls /dev | grep da0~ > > desktop1# ls /dev | grep da0 > > da0 > > desktop1# fdisk /dev/da0 > > ******* Working on device /dev/da0 ******* > > parameters extracted from in-core disklabel are: > > cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl) > > > parameters to be used for BIOS calculations are: > > cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl) > > > Media sector size is 512 > > Warning: BIOS sector numbering starts with sector 1 > > Information from DOS bootblock is: > > The data for partition 1 is: > > sysid 114 (0x72),(unknown) > > start 778135908, size 1141509631 (557377 Meg), flag 6f > > beg: cyl 357/ head 116/ sector 40; > > end: cyl 357/ head 32/ sector 45 > > The data for partition 2 is: > > sysid 101 (0x65),(Novell Netware/386 3.xx) > > start 168689522, size 1936028240 (945326 Meg), flag 69 > > beg: cyl 288/ head 115/ sector 43; > > end: cyl 367/ head 114/ sector 50 > > The data for partition 3 is: > > sysid 121 (0x79),(QNX4.x 3rd part) > > start 1869881465, size 1936028192 (945326 Meg), flag 73 > > beg: cyl 366/ head 32/ sector 33; > > end: cyl 357/ head 32/ sector 43 > > The data for partition 4 is: > > sysid 13 (0x0d),(unknown) > > start 0, size 3637226496 (1775989 Meg), flag 74 > > beg: cyl 372/ head 97/ sector 50; > > end: cyl 0/ head 10/ sector 0 > > desktop1# > > *lol* just tried this myself and my fdisk output looks just as bad as yours: > > ******* Working on device da0 ******* > parameters extracted from in-core disklabel are: > cylinders=242 heads=255 sectors/track=63 (16065 blks/cyl) > > parameters to be used for BIOS calculations are: > cylinders=242 heads=255 sectors/track=63 (16065 blks/cyl) > > Media sector size is 512 > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 1 is: > sysid 110 (0x6e),(unknown) > start 1768187213, size 1701211749 (830669 Meg), flag 65 > beg: cyl 357/ head 114/ sector 46; > end: cyl 10/ head 255/ sector 13 > The data for partition 2 is: > sysid 255 (0xff),(Xenix bad blocks table) > start 1953723749, size 980709985 (478862 Meg), flag 68 > beg: cyl 370/ head 108/ sector 37; > end: cyl 78/ head 13/ sector 10 > The data for partition 3 is: > sysid 116 (0x74),(unknown) > start 1801683314, size 168652389 (82349 Meg), flag 20 > beg: cyl 371/ head 84/ sector 33; > end: cyl 100/ head 101/ sector 32 > The data for partition 4 is: > sysid 0 (0000),(unused) > start 2885681152, size 54212 (26 Meg), flag 0 > beg: cyl 0/ head 0/ sector 0; > end: cyl 0/ head 0/ sector 0 > > `file -s /dev/da0` reports: > > /dev/da0: x86 boot sector, Microsoft Windows XP Bootloader (4.german) NTLDR, > code offset 0x58, OEM-ID "MSDOS5.0", sectors/cluster 8, reserved sectors 38, > Media descriptor 0xf8, heads 255, sectors 3903487 (volumes > 32 MB) , FAT (32 > bit), sectors/FAT 3805, serial number 0x88e88370, unlabeled > > `fdisk` in general seems to need some updates. this is the output if i call > `fdisk` without any args: The important question is what does "gpart show" say about these disks.... robert. > fdisk: mounted root fs resource doesn't match expectations (regexec returned > 1) > > alex > > > On Tue, 03 Nov 2009 01:28:10 -0000, Mark Linimon > > wrote: > > > >On Tue, Nov 03, 2009 at 02:03:29AM +0100, Alexander Best wrote: > > >>i guess the freebsd-fs@ guys know about these problems but don't > > >>have > > >>the time to deal with it. most of them are probably working on > > >>zfs. > > > >AFAIK there are only a handful of people working on ZFS. > > > >We certainly need more people willing to work on filesystems code. > > >In > > >general it does have a large learning curve, so it's not as > > >attractive > > >as some of the other areas. That's probably why, as the kernel has > > >undergone radical changes (e.g. for SMP) over time, that some of the > > >fs code has not kept up. > > > >mcl > > >_______________________________________________ > > >freebsd-current@freebsd.org mailing list > > >http://lists.freebsd.org/mailman/listinfo/freebsd-current > > >To unsubscribe, send any mail to > > >"freebsd-current-unsubscribe@freebsd.org" > > > > > -- > > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From weldon at excelsusphoto.com Tue Nov 3 17:16:04 2009 From: weldon at excelsusphoto.com (Weldon S Godfrey 3) Date: Tue Nov 3 18:11:26 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: <9308879887.941738356@gmail.com> References: <9308879887.941738356@gmail.com> Message-ID: If memory serves me right, sometime around 5:59pm, Ivan Voras told me: > Something else just occured to me - do you use ipfw? > > -- not on this server. Thanks, Weldon From weldon at excelsusphoto.com Tue Nov 3 17:19:36 2009 From: weldon at excelsusphoto.com (Weldon S Godfrey 3) Date: Tue Nov 3 18:11:33 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: <1257267727.98619.111.camel@buffy.york.ac.uk> References: <1257185816.44755.29.camel@buffy.york.ac.uk> <1257261214.98619.92.camel@buffy.york.ac.uk> <1257267727.98619.111.camel@buffy.york.ac.uk> Message-ID: If memory serves me right, sometime around 5:02pm, Gavin Atkinson told me: > On Tue, 2009-11-03 at 10:43 -0500, Weldon S Godfrey 3 wrote: >> This output was from a kernel on 12/08. The issue really came up while we >> tried to swap to 8.0-RC2. We plan to swap back sometime in the near >> future. The same symptoms happened with RC2 so I am sure it is a kmem >> exhaustion. I am guessing v3 requires a lot more. When we switch, i'll >> change to using the em card. > > Sorry, can you clarify: have you ever tested the em card with the > 8.0-RC2 kernel? > We briefly tried em card with RC2 but went back because it didn't help at the time. But we are planning to go back to RC2 soon and I also plan to use the em card instead. From weldon at excelsusphoto.com Tue Nov 3 17:36:21 2009 From: weldon at excelsusphoto.com (Weldon S Godfrey 3) Date: Tue Nov 3 18:11:39 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: References: <1257185816.44755.29.camel@buffy.york.ac.uk> <1257261214.98619.92.camel@buffy.york.ac.uk> Message-ID: If memory serves me right, sometime around 10:43am, Weldon S Godfrey 3 told me: > > > If memory serves me right, sometime around 3:13pm, Gavin Atkinson told me: > >> OK, at least we've figured out what is going wrong then. As a >> workaround to get the machine to stay up longer, you should be able to >> set kern.ipc.nmbclusters=256000 in /boot/loader.conf -but hopefully we >> can resolve this soon. >> I upped it to 256K. What I am trying to wrap my head around is how it was working somewhat for so long at 24K, but it got to near 65K before I rebooted it with the higher setting. Or did I reboot too early? Is there any cleanup that isn't triggered intil it reaches max nmbclusters? I am trying to see if anything on our network has changed to cause this to become cronic. From pieter at degoeje.nl Tue Nov 3 18:57:51 2009 From: pieter at degoeje.nl (Pieter de Goeje) Date: Tue Nov 3 18:57:58 2009 Subject: mixer settings on 8.0-RC2 In-Reply-To: <19e9a5dc0911030934r601a4f23w20b9f23b51752327@mail.gmail.com> References: <4AEEDCFB.3060604@bsdforen.de> <200911031746.31571.pieter@degoeje.nl> <19e9a5dc0911030934r601a4f23w20b9f23b51752327@mail.gmail.com> Message-ID: <200911031950.45797.pieter@degoeje.nl> On Tuesday 03 November 2009 18:34:14 Gonzalo Nemmi wrote: > On Tue, Nov 3, 2009 at 5:46 PM, Pieter de Goeje wrote: > > On Tuesday 03 November 2009 16:57:08 Dominic Fandrey wrote: > > > Gonzalo Nemmi wrote: > > > > On Tuesday 03 November 2009 5:07:26 am Dominic Fandrey wrote: > > > >> Gonzalo Nemmi wrote: > > > >>> On Monday 02 November 2009 11:22:03 am Dominic Fandrey wrote: > > > >>>> It appears that my 8.0-RC2 system (notebook) forgets its mixer > > > >>>> settings with every reboot. > > > >>>> > > > >>>> FreeBSD mobileKamikaze.norad 8.0-RC2 FreeBSD 8.0-RC2 #0: Sat Oct > > > >>>> 31 02:49:30 CET 2009 > > > >>>> root@mobileKamikaze.norad:/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6 > > > >>>> 510 b-8 amd64 > > > >>>> > > > >>>> Regards > > > >>> > > > >>> May I ask how are you setting them? > > > >>> > > > >>> Regards > > > >>> Gonzalo > > > >> > > > >> With mixer(8). But now the settings are remembered. > > > >> > > > >> I suppose some evil app is to blame. But nothing apart from Skype > > > >> comes to mind and I configured it not to touch the mixer settings. > > > >> > > > >> Regards > > > > > > > > Sorry but I have to ask ... have you tried configuring mixer settings > > > > as > > > > > > described in section 7.2.4 of the FreBSD handbook? > > > > > > > > That is to say: > > > > > > > > "The default values for the different mixer channels are hardcoded in > > > > the sourcecode of the pcm(4) driver. There are many different > > > > applications and daemons that allow you to set values for the mixer > > > > that are remembered between invocations, but this is not a clean > > > > solution. ... > > > > > > Rather outdated in my opinion. Automatic mixer remembering without > > > configuring anything has ever worked since I started using FreeBSD > > > (i.e. 2005). > > > > Perhaps you are using reboot/halt instead of shutdown? > > Reboot and halt will not start the shutdown scripts. > > > > -- > > Pieter de Goeje > > yup ... I use reboot or halt -p Well the obvious thing to try then is to use shutdown -r or -p instead... Does it work? - Pieter From mailinglists at alchemy-networks.co.uk Tue Nov 3 19:02:06 2009 From: mailinglists at alchemy-networks.co.uk (Paul G Webster) Date: Tue Nov 3 19:02:22 2009 Subject: 8.0-RC2 mangles msdosfs In-Reply-To: <1257271265.18564.0.camel@balrog.2hip.net> References: <1257271265.18564.0.camel@balrog.2hip.net> Message-ID: NOTE: I apologize to Mark Linimon he will get this message twice, I accidentally hit 'reply' instead of 'reply all' Here is the comedy, I just realized... This box is FreeBSD desktop1.yuno 7.2-RELEASE-p3 not 8-BETA2 I have to many desktops got a little confused between them. Incidentally the BETA2 box shows the exact same results ill get the gpart information as soon as I can. On Tue, 03 Nov 2009 18:01:05 -0000, Robert Noland wrote: > On Tue, 2009-11-03 at 18:46 +0100, Alexander Best wrote: >> Paul G Webster schrieb am 2009-11-03: >> > As an example, this is a 1GB fat32 disk. >> >> >> > da0 at umass-sim0 bus 0 target 0 lun 0 >> > da0: Removable Direct Access SCSI-0 device >> > da0: 1.000MB/s transfers >> > da0: 956MB (1957888 512 byte sectors: 64H 32S/T 956C) >> > desktop1# ls /dev | grep da0~ >> > desktop1# ls /dev | grep da0 >> > da0 >> > desktop1# fdisk /dev/da0 >> > ******* Working on device /dev/da0 ******* >> > parameters extracted from in-core disklabel are: >> > cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl) >> >> > parameters to be used for BIOS calculations are: >> > cylinders=956 heads=64 sectors/track=32 (2048 blks/cyl) >> >> > Media sector size is 512 >> > Warning: BIOS sector numbering starts with sector 1 >> > Information from DOS bootblock is: >> > The data for partition 1 is: >> > sysid 114 (0x72),(unknown) >> > start 778135908, size 1141509631 (557377 Meg), flag 6f >> > beg: cyl 357/ head 116/ sector 40; >> > end: cyl 357/ head 32/ sector 45 >> > The data for partition 2 is: >> > sysid 101 (0x65),(Novell Netware/386 3.xx) >> > start 168689522, size 1936028240 (945326 Meg), flag 69 >> > beg: cyl 288/ head 115/ sector 43; >> > end: cyl 367/ head 114/ sector 50 >> > The data for partition 3 is: >> > sysid 121 (0x79),(QNX4.x 3rd part) >> > start 1869881465, size 1936028192 (945326 Meg), flag 73 >> > beg: cyl 366/ head 32/ sector 33; >> > end: cyl 357/ head 32/ sector 43 >> > The data for partition 4 is: >> > sysid 13 (0x0d),(unknown) >> > start 0, size 3637226496 (1775989 Meg), flag 74 >> > beg: cyl 372/ head 97/ sector 50; >> > end: cyl 0/ head 10/ sector 0 >> > desktop1# >> >> *lol* just tried this myself and my fdisk output looks just as bad as >> yours: >> >> ******* Working on device da0 ******* >> parameters extracted from in-core disklabel are: >> cylinders=242 heads=255 sectors/track=63 (16065 blks/cyl) >> >> parameters to be used for BIOS calculations are: >> cylinders=242 heads=255 sectors/track=63 (16065 blks/cyl) >> >> Media sector size is 512 >> Warning: BIOS sector numbering starts with sector 1 >> Information from DOS bootblock is: >> The data for partition 1 is: >> sysid 110 (0x6e),(unknown) >> start 1768187213, size 1701211749 (830669 Meg), flag 65 >> beg: cyl 357/ head 114/ sector 46; >> end: cyl 10/ head 255/ sector 13 >> The data for partition 2 is: >> sysid 255 (0xff),(Xenix bad blocks table) >> start 1953723749, size 980709985 (478862 Meg), flag 68 >> beg: cyl 370/ head 108/ sector 37; >> end: cyl 78/ head 13/ sector 10 >> The data for partition 3 is: >> sysid 116 (0x74),(unknown) >> start 1801683314, size 168652389 (82349 Meg), flag 20 >> beg: cyl 371/ head 84/ sector 33; >> end: cyl 100/ head 101/ sector 32 >> The data for partition 4 is: >> sysid 0 (0000),(unused) >> start 2885681152, size 54212 (26 Meg), flag 0 >> beg: cyl 0/ head 0/ sector 0; >> end: cyl 0/ head 0/ sector 0 >> >> `file -s /dev/da0` reports: >> >> /dev/da0: x86 boot sector, Microsoft Windows XP Bootloader (4.german) >> NTLDR, >> code offset 0x58, OEM-ID "MSDOS5.0", sectors/cluster 8, reserved >> sectors 38, >> Media descriptor 0xf8, heads 255, sectors 3903487 (volumes > 32 MB) , >> FAT (32 >> bit), sectors/FAT 3805, serial number 0x88e88370, unlabeled >> >> `fdisk` in general seems to need some updates. this is the output if i >> call >> `fdisk` without any args: > > The important question is what does "gpart show" say about these > disks.... > > robert. > >> fdisk: mounted root fs resource doesn't match expectations (regexec >> returned >> 1) >> >> alex >> >> > On Tue, 03 Nov 2009 01:28:10 -0000, Mark Linimon >> > wrote: >> >> > >On Tue, Nov 03, 2009 at 02:03:29AM +0100, Alexander Best wrote: >> > >>i guess the freebsd-fs@ guys know about these problems but don't >> > >>have >> > >>the time to deal with it. most of them are probably working on >> > >>zfs. >> >> > >AFAIK there are only a handful of people working on ZFS. >> >> > >We certainly need more people willing to work on filesystems code. >> > >In >> > >general it does have a large learning curve, so it's not as >> > >attractive >> > >as some of the other areas. That's probably why, as the kernel has >> > >undergone radical changes (e.g. for SMP) over time, that some of the >> > >fs code has not kept up. >> >> > >mcl >> > >_______________________________________________ >> > >freebsd-current@freebsd.org mailing list >> > >http://lists.freebsd.org/mailman/listinfo/freebsd-current >> > >To unsubscribe, send any mail to >> > >"freebsd-current-unsubscribe@freebsd.org" >> >> >> >> > -- >> > Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ From thompsa at FreeBSD.org Tue Nov 3 21:07:33 2009 From: thompsa at FreeBSD.org (Andrew Thompson) Date: Tue Nov 3 21:07:42 2009 Subject: aue0 detected as ue0 on 8.0-RC2 In-Reply-To: <20091103175501.GD1256@michelle.cdnetworks.com> References: <5aaae08a0910311359v45cc9dc9h2826d8a29bfb5575@mail.gmail.com> <1257243047.98619.8.camel@buffy.york.ac.uk> <20091103175501.GD1256@michelle.cdnetworks.com> Message-ID: <20091103210725.GA33086@citylink.fud.org.nz> On Tue, Nov 03, 2009 at 09:55:01AM -0800, Pyun YongHyeon wrote: > On Tue, Nov 03, 2009 at 10:10:47AM +0000, Gavin Atkinson wrote: > > [freebsd-current cc'd, as that was where the thread started, but this > > Hmm, this looks like a serious bug, possibly in the new USB subsystem > > (HPS CC'd). > > > > I've got an axe(4) device, which also does the same: > > > > ugen7.3: at usbus7 > > axe0: on usbus7 > > axe0: PHYADDR 0xe0:0x10 > > miibus1: on axe0 > > ukphy0: PHY 16 on miibus1 > > ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > > ue0: on axe0 > > ue0: Ethernet address: 00:50:b6:05:57:a7 > > ue0: link state changed to DOWN > > > > I'm not sure this is feature of new USB or bug. I don't have strong > objections on current behavior but looks like I'm seeing Linux > behavior. Traditionally all network interfaces used their own > driver name. I think this change should be documented in UPDATING. I have added an UPDATING entry in 198859. Andrew From bsam at ipt.ru Tue Nov 3 21:37:11 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Tue Nov 3 21:37:19 2009 Subject: [current] acroread: SIGSEGV In-Reply-To: <20091103154747.GC2331@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Tue\, 3 Nov 2009 17\:47\:47 +0200") References: <65275688@bb.ipt.ru> <20091103154747.GC2331@deviant.kiev.zoral.com.ua> Message-ID: <77755531@h30.sp.ipt.ru> On Tue, 3 Nov 2009 17:47:47 +0200 Kostik Belousov wrote: > On Tue, Nov 03, 2009 at 05:05:11PM +0300, Boris Samorodov wrote: > > Hello List, > > > > print/acroread8 doesn't work for me at 9-CURRENT: > > ----- > > % uname -a > > FreeBSD host.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon Nov 2 15:15:13 MSK 2009 root@host.ipt.ru:/usr/obj/usr/src/sys/HOST > > % sysctl compat.linux > > compat.linux.oss_version: 198144 > > compat.linux.osrelease: 2.6.16 > > compat.linux.osname: Linux > > ------ > > > > Setting security.bsd.map_at_zero to 1 doesn't change anything. There is > > nothing at console/log files. Here is the tail of linux_kdump: > > ----- > > ... > > 78586 ld-2.9.so CALL linux_open(0x16fcd80,0,0x80d93000) > > 78586 ld-2.9.so NAMI "/compat/linux/var/db/fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > 78586 ld-2.9.so NAMI "/var/db/fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > 78586 ld-2.9.so RET linux_open JUSTRETURN > > 78586 ld-2.9.so CALL linux_open(0x16fcd80,0,0x80d93000) > > 78586 ld-2.9.so NAMI "/compat/linux/home/bsam/.fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > 78586 ld-2.9.so NAMI "/home/bsam/.fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > 78586 ld-2.9.so RET linux_open 4 > > 78586 ld-2.9.so CALL linux_fstat64(0x4,0xbfbfcf8c,0x2e482ff4) > > 78586 ld-2.9.so RET linux_fstat64 0 > > 78586 ld-2.9.so CALL read(0x4,0x16fe160,0x60) > > 78586 ld-2.9.so GIO fd 4 read 96 bytes > > "\^D\M-|\^B\M-|\^B\0\0\0`\0\0\0 \0\0\0P\0\0\0\0\0\0\0P\0\0\0\^[b\M-TJ/usr/local/lib/X11/fonts/encodings/large\0\0\0\0\0\0\0\0\0\0\ > > \0\0\0\0\0\0\^Q\0\0\0\0\0\0\000" > > 78586 ld-2.9.so RET read 96/0x60 > > 78586 ld-2.9.so CALL close(0x4) > > 78586 ld-2.9.so RET close 0 > > 78586 ld-2.9.so CALL linux_mmap2(0,0x25000,0x3,0x22,0xffffffff,0) > > 78586 ld-2.9.so RET linux_mmap2 833982464/0x31b59000 > > 78586 ld-2.9.so PSIG SIGSEGV caught handler=0x83814b6 mask=0x0 code=0x0 > > 78586 ld-2.9.so CALL linux_rt_sigaction(0x6,0xbfbfcbf0,0xbfbfcb64,0x8) > > 78586 ld-2.9.so RET linux_rt_sigaction 0 > > 78586 ld-2.9.so CALL linux_exit_group(0x1) > It would be interesting to see which address faulted. > If not, can you do search for a kernel revision that broke acroread ? > Good starting points are r198507 and r198554. Were those revisions MFCed to RELENG_8_0? I've got the same for 8.0: ----- % uname -a FreeBSD h30.sp.ipt.ru 8.0-RC2 FreeBSD 8.0-RC2 #0: Sun Nov 1 18:57:33 MSK 2009 root@h30.sp.ipt.ru:/usr/obj/usr/src/sys/IN DUS i386 ----- -- WBR, bsam From kostikbel at gmail.com Tue Nov 3 21:40:38 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Tue Nov 3 21:40:45 2009 Subject: [current] acroread: SIGSEGV In-Reply-To: <77755531@h30.sp.ipt.ru> References: <65275688@bb.ipt.ru> <20091103154747.GC2331@deviant.kiev.zoral.com.ua> <77755531@h30.sp.ipt.ru> Message-ID: <20091103214032.GF2331@deviant.kiev.zoral.com.ua> On Wed, Nov 04, 2009 at 12:37:08AM +0300, Boris Samorodov wrote: > On Tue, 3 Nov 2009 17:47:47 +0200 Kostik Belousov wrote: > > On Tue, Nov 03, 2009 at 05:05:11PM +0300, Boris Samorodov wrote: > > > Hello List, > > > > > > print/acroread8 doesn't work for me at 9-CURRENT: > > > ----- > > > % uname -a > > > FreeBSD host.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon Nov 2 15:15:13 MSK 2009 root@host.ipt.ru:/usr/obj/usr/src/sys/HOST > > > % sysctl compat.linux > > > compat.linux.oss_version: 198144 > > > compat.linux.osrelease: 2.6.16 > > > compat.linux.osname: Linux > > > ------ > > > > > > Setting security.bsd.map_at_zero to 1 doesn't change anything. There is > > > nothing at console/log files. Here is the tail of linux_kdump: > > > ----- > > > ... > > > 78586 ld-2.9.so CALL linux_open(0x16fcd80,0,0x80d93000) > > > 78586 ld-2.9.so NAMI "/compat/linux/var/db/fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > 78586 ld-2.9.so NAMI "/var/db/fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > 78586 ld-2.9.so RET linux_open JUSTRETURN > > > 78586 ld-2.9.so CALL linux_open(0x16fcd80,0,0x80d93000) > > > 78586 ld-2.9.so NAMI "/compat/linux/home/bsam/.fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > 78586 ld-2.9.so NAMI "/home/bsam/.fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > 78586 ld-2.9.so RET linux_open 4 > > > 78586 ld-2.9.so CALL linux_fstat64(0x4,0xbfbfcf8c,0x2e482ff4) > > > 78586 ld-2.9.so RET linux_fstat64 0 > > > 78586 ld-2.9.so CALL read(0x4,0x16fe160,0x60) > > > 78586 ld-2.9.so GIO fd 4 read 96 bytes > > > "\^D\M-|\^B\M-|\^B\0\0\0`\0\0\0 \0\0\0P\0\0\0\0\0\0\0P\0\0\0\^[b\M-TJ/usr/local/lib/X11/fonts/encodings/large\0\0\0\0\0\0\0\0\0\0\ > > > \0\0\0\0\0\0\^Q\0\0\0\0\0\0\000" > > > 78586 ld-2.9.so RET read 96/0x60 > > > 78586 ld-2.9.so CALL close(0x4) > > > 78586 ld-2.9.so RET close 0 > > > 78586 ld-2.9.so CALL linux_mmap2(0,0x25000,0x3,0x22,0xffffffff,0) > > > 78586 ld-2.9.so RET linux_mmap2 833982464/0x31b59000 > > > 78586 ld-2.9.so PSIG SIGSEGV caught handler=0x83814b6 mask=0x0 code=0x0 > > > 78586 ld-2.9.so CALL linux_rt_sigaction(0x6,0xbfbfcbf0,0xbfbfcb64,0x8) > > > 78586 ld-2.9.so RET linux_rt_sigaction 0 > > > 78586 ld-2.9.so CALL linux_exit_group(0x1) > > > It would be interesting to see which address faulted. > > If not, can you do search for a kernel revision that broke acroread ? > > Good starting points are r198507 and r198554. > > Were those revisions MFCed to RELENG_8_0? I've got the same for 8.0: > ----- > % uname -a > FreeBSD h30.sp.ipt.ru 8.0-RC2 FreeBSD 8.0-RC2 #0: Sun Nov 1 18:57:33 MSK 2009 root@h30.sp.ipt.ru:/usr/obj/usr/src/sys/IN > DUS i386 > ----- No. It might be easier to bisect on releng/8.0 then. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091103/a5198622/attachment.pgp From gnemmi at gmail.com Tue Nov 3 22:15:23 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Tue Nov 3 22:15:30 2009 Subject: mixer settings on 8.0-RC2 In-Reply-To: <200911031950.45797.pieter@degoeje.nl> References: <4AEEDCFB.3060604@bsdforen.de> <200911031746.31571.pieter@degoeje.nl> <19e9a5dc0911030934r601a4f23w20b9f23b51752327@mail.gmail.com> <200911031950.45797.pieter@degoeje.nl> Message-ID: <19e9a5dc0911031415g7fb14eb4h37e2ccd245fdd9cf@mail.gmail.com> On Tue, Nov 3, 2009 at 7:50 PM, Pieter de Goeje wrote: > On Tuesday 03 November 2009 18:34:14 Gonzalo Nemmi wrote: > > On Tue, Nov 3, 2009 at 5:46 PM, Pieter de Goeje > wrote: > > > On Tuesday 03 November 2009 16:57:08 Dominic Fandrey wrote: > > > > Gonzalo Nemmi wrote: > > > > > On Tuesday 03 November 2009 5:07:26 am Dominic Fandrey wrote: > > > > >> Gonzalo Nemmi wrote: > > > > >>> On Monday 02 November 2009 11:22:03 am Dominic Fandrey wrote: > > > > >>>> It appears that my 8.0-RC2 system (notebook) forgets its mixer > > > > >>>> settings with every reboot. > > > > >>>> > > > > >>>> FreeBSD mobileKamikaze.norad 8.0-RC2 FreeBSD 8.0-RC2 #0: Sat Oct > > > > >>>> 31 02:49:30 CET 2009 > > > > >>>> root@mobileKamikaze.norad > :/usr/obj/HP6510b-8/amd64/usr/src/sys/HP6 > > > > >>>> 510 b-8 amd64 > > > > >>>> > > > > >>>> Regards > > > > >>> > > > > >>> May I ask how are you setting them? > > > > >>> > > > > >>> Regards > > > > >>> Gonzalo > > > > >> > > > > >> With mixer(8). But now the settings are remembered. > > > > >> > > > > >> I suppose some evil app is to blame. But nothing apart from Skype > > > > >> comes to mind and I configured it not to touch the mixer settings. > > > > >> > > > > >> Regards > > > > > > > > > > Sorry but I have to ask ... have you tried configuring mixer > settings > > > > > > as > > > > > > > > described in section 7.2.4 of the FreBSD handbook? > > > > > > > > > > That is to say: > > > > > > > > > > "The default values for the different mixer channels are hardcoded > in > > > > > the sourcecode of the pcm(4) driver. There are many different > > > > > applications and daemons that allow you to set values for the mixer > > > > > that are remembered between invocations, but this is not a clean > > > > > solution. ... > > > > > > > > Rather outdated in my opinion. Automatic mixer remembering without > > > > configuring anything has ever worked since I started using FreeBSD > > > > (i.e. 2005). > > > > > > Perhaps you are using reboot/halt instead of shutdown? > > > Reboot and halt will not start the shutdown scripts. > > > > > > -- > > > Pieter de Goeje > > > > yup ... I use reboot or halt -p > > Well the obvious thing to try then is to use shutdown -r or -p instead... > Does > it work? > > - Pieter > That would be up to the OP .. I don?t have mixer problems as my mixer values are set as hints :D Best Regards Gonzalo From gavin.atkinson at ury.york.ac.uk Tue Nov 3 22:21:43 2009 From: gavin.atkinson at ury.york.ac.uk (Gavin Atkinson) Date: Tue Nov 3 22:21:49 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: <4AF06017.6000505@tomjudge.com> References: <200911030937.11619.pieter@degoeje.nl> <4AF05177.7030705@tomjudge.com> <4AF06017.6000505@tomjudge.com> Message-ID: <20091103221739.E75071@ury.york.ac.uk> On Tue, 3 Nov 2009, Tom Judge wrote: > Tom Judge wrote: >> Weldon S Godfrey 3 wrote: >>> we are using onboard NICs on the Dell using the bce driver. We did try >>> several times to see if using an intel PCIexpress card using the em >>> driver, and we had the same symptoms. >>> >>> Could the bce driver have the same leak? >> >> The bce driver does not have a memory leak, it does however have a bug >> which causes memory fragmentation leading to denied mbuf allocation. >> >> There is a work around for this in current, you can get the patch like >> this: >> >> http://svn.freebsd.org/viewvc/base/head/ >> > That should be: > > svn diff -r 198319:198320 http://svn.freebsd.org/base/head > >> You need to put >> >> options BCE_JUMBO_HDRSPLIT >> >> In your kernel to enable the work arround. Unless I'm missing something, these seem like they may be totally different bugs. The symptoms that Weldon S Godfrey has show the number of "mbuf clusters in use" rising to the point at which the limit is reached, whereas the thread on -stable where BCE_JUMBO_HDRSPLIT is recommended has the symptom of "requests for 9k jumbo clusters denied" increasing and the mbuf clusters not being anywhere near to the maximum. So, I think there may be some confusion here. Gavin From tom at tomjudge.com Tue Nov 3 22:29:05 2009 From: tom at tomjudge.com (Tom Judge) Date: Tue Nov 3 22:29:11 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: <20091103221739.E75071@ury.york.ac.uk> References: <200911030937.11619.pieter@degoeje.nl> <4AF05177.7030705@tomjudge.com> <4AF06017.6000505@tomjudge.com> <20091103221739.E75071@ury.york.ac.uk> Message-ID: <4AF0AE70.7030004@tomjudge.com> Gavin Atkinson wrote: > On Tue, 3 Nov 2009, Tom Judge wrote: >> Tom Judge wrote: >>> Weldon S Godfrey 3 wrote: >>>> we are using onboard NICs on the Dell using the bce driver. We did >>>> try several times to see if using an intel PCIexpress card using the >>>> em driver, and we had the same symptoms. >>>> >>>> Could the bce driver have the same leak? >>> >>> The bce driver does not have a memory leak, it does however have a >>> bug which causes memory fragmentation leading to denied mbuf allocation. >>> >>> There is a work around for this in current, you can get the patch >>> like this: >>> >>> http://svn.freebsd.org/viewvc/base/head/ >>> >> That should be: >> >> svn diff -r 198319:198320 http://svn.freebsd.org/base/head >> >>> You need to put >>> >>> options BCE_JUMBO_HDRSPLIT >>> >>> In your kernel to enable the work arround. > > Unless I'm missing something, these seem like they may be totally > different bugs. The symptoms that Weldon S Godfrey has show the number > of "mbuf clusters in use" rising to the point at which the limit is > reached, whereas the thread on -stable where BCE_JUMBO_HDRSPLIT is > recommended has the symptom of "requests for 9k jumbo clusters denied" > increasing and the mbuf clusters not being anywhere near to the maximum. > > So, I think there may be some confusion here. Jumbo frames are not in use what what I have read in the thread however there are denied requests for mbuf+clusters, so this could be the issue in the bce driver with standrad size frames. See: 0/201276/90662 requests for mbufs denied (mbufs/clusters/mbuf+clusters) I guess that there are 2 issues at work here, adding the bce patch should not cause any problems but may resolve the issue when using the bce driver. Is it not worth a try? Tom From gallasch at free.de Wed Nov 4 00:17:36 2009 From: gallasch at free.de (Kai Gallasch) Date: Wed Nov 4 00:17:43 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <1257244960.98619.36.camel@buffy.york.ac.uk> References: <20091031231545.493cee89@boiler.free.de> <1257244960.98619.36.camel@buffy.york.ac.uk> Message-ID: <20091104011716.768baae5@orwell.free.de> Am Tue, 03 Nov 2009 10:42:40 +0000 schrieb Gavin Atkinson : > On Sat, 2009-10-31 at 23:15 +0100, Kai Gallasch wrote: > > Hi. > > > > I installed 8.0RC2-amd64 on an 8-core opteron server a few days ago. > > > > When I try to do a make buildworld or make buildkernel the server > > reboots without any message left in the logs. The same happens > > when building bigger ports (for example ruby18 or perl58) > First place I think I'd start id by running memtest86 on the machine > overnight. This sounds like possible hardware issue to me, it would > be good to see if we can confirm that that is the case. I will do so tomorrow. Following actions I have already taken to rule out a hardware problem: - ran several passes with diagnostic software from the manufacturer - reset BIOS settings to default - upgraded BIOS to newest release - booted server from 2 year old backup BIOS - took out the only pair of RAM modules that was different from the rest of the modules - installed freebsd 7.2-STABLE on the server to repeat the kernel panic (no panic with 7.2) - installed 8.0-BETA4 (crash) Besides: The server was in production with 7.2 for some time, without showing any such problems. > > Now my idea was to install the old 8.0-BETA4 and upgrade to RC2 > > through makeworld + buildkernel (gdb+witness). But no luck. When > > trying to upgrade to RC2 the 8.0-BETA4 also crashes. At least > > 8.0-BETA4 has debug > > + witness active in the GENERIC kernel.. > > > > So below some debug output of 8.0-BETA4 crashing. Has a vfs/ffs LOR > > problem with the BETA4 already been fixed? > > The debug output you included were just lock order reversals, and > don't seem to be related to your crash. Sorry for causing possible confusion about this. I realized this after my mail was already out. > I think 8.0-BETA4 still had the debugger compiled in (you can test by > pressing ctrl-alt-escape ion the console, if you do drop to the > debugger, give the "c" command to continue). > > If the debugger is compiled in, then the spontaneous reboot without > dropping to the debugger suggests even more that it may be hardware > related. If you do get to the debugger, a copy of all of the messages > on screen and the output of the "bt" command would be very useful. > When you do your kernel recompile, please include full debugging, > including WITNESS, INVARIANTS, KDB, DDB etc. In the meantime I managed it to install a RELENG_8 world + GENERIC kernel with all debug options enabled on the crashing server. (mounted /usr/src and /usr/obj on another server running 8.0RC1 through NFS and did buildworld + buildkernel over there..) So now I have a debug kernel available with dumpev + dumpdir defined. Here are my latest findings on this issue: - Running a makeworld in about 80% leads to a server crash without the server writing a crashdump to dumpdir. The server just reboots.. - In about 20% of the cases makeworld gets stuck in a not terminating process that eats up 100% cpu. This process cannot be killed. When restarting makeworld the server then reboots again - It makes no difference doing makeworld -j1 or -j8, result is the same > It depends what the bug is to be honest. So far there isn't really > enough information to determine the cause, and therefore there isn't > really enough info for a PR. Mark Atkinson also commented on my mail and he gave the hint: "If vm.pmap.pg_ps_enabled is 1 in 8.0-rc2, you might try rebooting with c in /boot/loader.conf and try another buildworld." So I thought why not and just tried it - and surprise: Disabling vm.pmap.pg_ps_enabled=1 in loader.conf resolves my problem with 8.0RC2 crashing when doing a makeworld.. After successful buildworld and buildkernel I rebooted the server again with commented out vm.pmap.pg_ps_enabled=0 and the problem was there again. And then I disabled the option again in loader.conf, rebooted + make buildworld .. no problem. Seems to be deterministic. With vm.pmap.pg_ps_enabled=1 the server crashes without being able to write crashdumps to dumpdev. (at least on this specific Proliant DL385G2 server) --Kai. -- You need more time; and you probably always will. From moonlightakkiy at yahoo.ca Wed Nov 4 09:51:10 2009 From: moonlightakkiy at yahoo.ca (PseudoCylon) Date: Wed Nov 4 09:51:18 2009 Subject: Wireless usb + wep = no usbd_do_request In-Reply-To: <3a142e750911030408t25dd59b0rcda6eccd8c24c0c9@mail.gmail.com> References: <143477.23789.qm@web51804.mail.re2.yahoo.com> <3a142e750911030408t25dd59b0rcda6eccd8c24c0c9@mail.gmail.com> Message-ID: <950696.93705.qm@web51806.mail.re2.yahoo.com> ----- Original Message ---- > From: Paul B Mahol > To: PseudoCylon > Cc: freebsd-current@freebsd.org > Sent: Tue, November 3, 2009 5:08:47 AM > Subject: Re: Wireless usb + wep = no usbd_do_request > > On 11/3/09, PseudoCylon wrote: > > Hi, > > > > I'm porting a wireless usb driver (if_run) to freebsd current, and I got > > stuck. Once I "ifconfig wlan0 wepkey 1:0x... weptxkey 1" I cannot call > > usbd_do_request() any more. Even ifconfig didn't exit. Chipset supports h/w > > en/decryption, so cannot write keys on chip. (It works without encryption, > > by the way.) > > > > So, I tried the same thing on another device, linksys wusb54gc with if_rum. > > It worked fine, but about 3 to 4 min later. (Just left it alone.) It started > > giving error > > rum0: could not multi read MAC register: USB_ERR_TIMEOUT and > > rum0: device timeout > > when ifconfig wlan0 down, > > rum0: could not multi write MAC register: USB_ERR_TIMEOUT > > which means failed on usbd_do_request() (This could be totally different > > issue.) > > I get this one multiple times after card got detached but vap was not > manually destroyed. > Recently I did not used if_rum more that 5 min I think(maybe in AP > mode when I was testing hidden ssid ...) > > > Any ideas, patches, or walkaround? > > Make sure how locks are handled between net80211, usb and driver itself. Thanks for the reply. I think that's just simple lock problem, too. Just I don't know what it is. I tried IEEE80211_LOCK IEEE80211_NODE_LOCK IEEE80211_NODE_ITERATE_LOCK but I cannot lock or unlock them. (I can lock IF_LOCK.) I just get "panic: mtx_lock of spin mutex(null)" For example, IEEE80211_LOCK is sleep mutex, and I can use it in newstate() no problem, but I some how it becomes spin mutex in key_set(). Once I find what is over writing lock type, I can make it work. Wish me a luck. > > > More info > > #uname -a > > FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r198150M: Fri Oct 16 22:44:08 > > UTC 2009 amd64 > > > > ddb trace output 20+ minutes after "ifconfig wepkey" (using if_run) > > Tracing command ifconfig pid 1586 tid 100159 td 0xffffff000b3d3a80 > > sched_switch() at sched_switch+0x180 > > mi_switch() at mi_switch+0x21d > > sleepq_switch() at sleepq_switch+0x123 > > sleepq_wait() at sleepq_wait+0x4d > > _sleep() at _sleep+0x357 > > taskqueue_drain() at taskqueue_drain+0xc2 > > ieee80211_waitfor_parent() at ieee80211_waitfor_parent+0x3e > > ieee80211_ioctl() at ieee80211_ioctl+0x162 > > ifioctl() at ifioctl+0xde4 > > kern_ioctl() at kern_ioctl+0xc5 > > ioctl() at ioctl+0xfd > > syscall() at syscall+0x1af > > Xfast_syscall() at Xfast_syscall+0xe1 > > > > Also, sleep mutex became spin mutex. I get a panic > > panic: mtx_lock of spin mutex(null) > > It works fine before ifconfig wepkey. > > It is hard to tell without code example but wepkey works fine with > if_rum last time I tried, note that if_rum have done encryption in > software mode. __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. From serguey-grigoriev at yandex.ru Wed Nov 4 10:55:21 2009 From: serguey-grigoriev at yandex.ru (S.N.Grigoriev) Date: Wed Nov 4 10:55:55 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld Message-ID: <44591257331450@webmail38.yandex.ru> Hi list, I can confirm I've seen the same problem. After upgrading from 7-stable to 8.0-RC2 my machine just reboots during 'make buildworld' without diagnostics. But switching vm.pmap.pg_ps_enabled on/off does not work for me. My machine reboots every time I try to build world. I don't think I have a hardware problem: under 7-stable I can build world/kernel for both 7-stable and 8.0-RC2 without problems. -- Regards, S.Grigoriev. From onemda at gmail.com Wed Nov 4 12:40:27 2009 From: onemda at gmail.com (Paul B Mahol) Date: Wed Nov 4 12:40:34 2009 Subject: Wireless usb + wep = no usbd_do_request In-Reply-To: <950696.93705.qm@web51806.mail.re2.yahoo.com> References: <143477.23789.qm@web51804.mail.re2.yahoo.com> <3a142e750911030408t25dd59b0rcda6eccd8c24c0c9@mail.gmail.com> <950696.93705.qm@web51806.mail.re2.yahoo.com> Message-ID: <3a142e750911040440h294da813m4b392da9c1b6e692@mail.gmail.com> On 11/4/09, PseudoCylon wrote: > ----- Original Message ---- > >> From: Paul B Mahol >> To: PseudoCylon >> Cc: freebsd-current@freebsd.org >> Sent: Tue, November 3, 2009 5:08:47 AM >> Subject: Re: Wireless usb + wep = no usbd_do_request >> >> On 11/3/09, PseudoCylon wrote: >> > Hi, >> > >> > I'm porting a wireless usb driver (if_run) to freebsd current, and I got >> > stuck. Once I "ifconfig wlan0 wepkey 1:0x... weptxkey 1" I cannot call >> > usbd_do_request() any more. Even ifconfig didn't exit. Chipset supports >> > h/w >> > en/decryption, so cannot write keys on chip. (It works without >> > encryption, >> > by the way.) >> > >> > So, I tried the same thing on another device, linksys wusb54gc with >> > if_rum. >> > It worked fine, but about 3 to 4 min later. (Just left it alone.) It >> > started >> > giving error >> > rum0: could not multi read MAC register: USB_ERR_TIMEOUT and >> > rum0: device timeout >> > when ifconfig wlan0 down, >> > rum0: could not multi write MAC register: USB_ERR_TIMEOUT >> > which means failed on usbd_do_request() (This could be totally different >> > issue.) >> >> I get this one multiple times after card got detached but vap was not >> manually destroyed. >> Recently I did not used if_rum more that 5 min I think(maybe in AP >> mode when I was testing hidden ssid ...) >> >> > Any ideas, patches, or walkaround? >> >> Make sure how locks are handled between net80211, usb and driver itself. > > Thanks for the reply. > > I think that's just simple lock problem, too. Just I don't know what it is. > I tried > IEEE80211_LOCK > IEEE80211_NODE_LOCK > IEEE80211_NODE_ITERATE_LOCK > but I cannot lock or unlock them. (I can lock IF_LOCK.) I just get "panic: > mtx_lock of spin mutex(null)" For example, IEEE80211_LOCK is sleep mutex, > and I can use it in newstate() no problem, but I some how it becomes spin > mutex in key_set(). Once I find what is over writing lock type, I can make > it work. Wish me a luck. Look other freebsd usb drivers for example when un/lock is required, also you need to have you own driver lock - and you need to really know when to use it. From kamikaze at bsdforen.de Wed Nov 4 13:50:25 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Wed Nov 4 13:50:39 2009 Subject: 8.0-RC2 mangles msdosfs In-Reply-To: References: Message-ID: <4AF1869D.6090304@bsdforen.de> Alexander Best wrote: > Paul G Webster schrieb am 2009-11-03: > *lol* just tried this myself and my fdisk output looks just as bad as yours: I think funny fdisk output is not that much of a problem. I normally put a single file system on external drives and don't bother partitioning. This is also a common default for many portable audio players. Heavy file system corruption with every write operation really renders msdosfs completely unusable. Now, I've got to rip my CDs and DVDs under FreeBSD and reboot into Windows to copy music and videos onto my player. This is really annoying for such a trivial use case. And msdosfs is still the default file system for portable devices, so it's an important desktop use case. Even in the business world, where often restrictive networks render USB sticks the only acceptable method of transporting large chunks of data. What I wonder is - are there more people who witness file system corruption upon msdosfs writes (and don't forget that either newfs_msdos or fsck_msdosfs is broken as well, and that fsck_msdosfs certainly does not recognize cross-linked files). The impact is so horrid that I had to reformat my portable player (with Windows) and reinstall the firmware to get it back going. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From kamikaze at bsdforen.de Wed Nov 4 13:53:05 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Wed Nov 4 13:53:11 2009 Subject: 8.0-RC2 mangles msdosfs In-Reply-To: <20091103012810.GB31768@lonesome.com> References: <4AEBFAA3.9020003@bsdforen.de> <20091103012810.GB31768@lonesome.com> Message-ID: <4AF1873F.2060705@bsdforen.de> Mark Linimon wrote: > On Tue, Nov 03, 2009 at 02:03:29AM +0100, Alexander Best wrote: >> i guess the freebsd-fs@ guys know about these problems but don't have >> the time to deal with it. most of them are probably working on zfs. > > AFAIK there are only a handful of people working on ZFS. > > We certainly need more people willing to work on filesystems code. In > general it does have a large learning curve, so it's not as attractive > as some of the other areas. That's probably why, as the kernel has > undergone radical changes (e.g. for SMP) over time, that some of the > fs code has not kept up. Is there material, apart from the code, explaining the concepts behind the FreeBSD file system code? File systems are an interesting topic for anyone who likes to get into low level stuff. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From bsam at ipt.ru Wed Nov 4 14:19:12 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Wed Nov 4 14:19:20 2009 Subject: [current] acroread: SIGSEGV In-Reply-To: <20091103214032.GF2331@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Tue\, 3 Nov 2009 23\:40\:32 +0200") References: <65275688@bb.ipt.ru> <20091103154747.GC2331@deviant.kiev.zoral.com.ua> <77755531@h30.sp.ipt.ru> <20091103214032.GF2331@deviant.kiev.zoral.com.ua> Message-ID: <99188273@bb.ipt.ru> On Tue, 3 Nov 2009 23:40:32 +0200 Kostik Belousov wrote: > On Wed, Nov 04, 2009 at 12:37:08AM +0300, Boris Samorodov wrote: > > On Tue, 3 Nov 2009 17:47:47 +0200 Kostik Belousov wrote: > > > On Tue, Nov 03, 2009 at 05:05:11PM +0300, Boris Samorodov wrote: > > > > Hello List, > > > > > > > > print/acroread8 doesn't work for me at 9-CURRENT: > > > > ----- > > > > % uname -a > > > > FreeBSD host.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon Nov 2 15:15:13 MSK 2009 root@host.ipt.ru:/usr/obj/usr/src/sys/HOST > > > > % sysctl compat.linux > > > > compat.linux.oss_version: 198144 > > > > compat.linux.osrelease: 2.6.16 > > > > compat.linux.osname: Linux > > > > ------ > > > > > > > > Setting security.bsd.map_at_zero to 1 doesn't change anything. There is > > > > nothing at console/log files. Here is the tail of linux_kdump: > > > > ----- > > > > ... > > > > 78586 ld-2.9.so CALL linux_open(0x16fcd80,0,0x80d93000) > > > > 78586 ld-2.9.so NAMI "/compat/linux/var/db/fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > > 78586 ld-2.9.so NAMI "/var/db/fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > > 78586 ld-2.9.so RET linux_open JUSTRETURN > > > > 78586 ld-2.9.so CALL linux_open(0x16fcd80,0,0x80d93000) > > > > 78586 ld-2.9.so NAMI "/compat/linux/home/bsam/.fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > > 78586 ld-2.9.so NAMI "/home/bsam/.fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > > 78586 ld-2.9.so RET linux_open 4 > > > > 78586 ld-2.9.so CALL linux_fstat64(0x4,0xbfbfcf8c,0x2e482ff4) > > > > 78586 ld-2.9.so RET linux_fstat64 0 > > > > 78586 ld-2.9.so CALL read(0x4,0x16fe160,0x60) > > > > 78586 ld-2.9.so GIO fd 4 read 96 bytes > > > > "\^D\M-|\^B\M-|\^B\0\0\0`\0\0\0 \0\0\0P\0\0\0\0\0\0\0P\0\0\0\^[b\M-TJ/usr/local/lib/X11/fonts/encodings/large\0\0\0\0\0\0\0\0\0\0\ > > > > \0\0\0\0\0\0\^Q\0\0\0\0\0\0\000" > > > > 78586 ld-2.9.so RET read 96/0x60 > > > > 78586 ld-2.9.so CALL close(0x4) > > > > 78586 ld-2.9.so RET close 0 > > > > 78586 ld-2.9.so CALL linux_mmap2(0,0x25000,0x3,0x22,0xffffffff,0) > > > > 78586 ld-2.9.so RET linux_mmap2 833982464/0x31b59000 > > > > 78586 ld-2.9.so PSIG SIGSEGV caught handler=0x83814b6 mask=0x0 code=0x0 > > > > 78586 ld-2.9.so CALL linux_rt_sigaction(0x6,0xbfbfcbf0,0xbfbfcb64,0x8) > > > > 78586 ld-2.9.so RET linux_rt_sigaction 0 > > > > 78586 ld-2.9.so CALL linux_exit_group(0x1) > > > > > It would be interesting to see which address faulted. > > > If not, can you do search for a kernel revision that broke acroread ? > > > Good starting points are r198507 and r198554. > > > > Were those revisions MFCed to RELENG_8_0? I've got the same for 8.0: > > ----- > > % uname -a > > FreeBSD h30.sp.ipt.ru 8.0-RC2 FreeBSD 8.0-RC2 #0: Sun Nov 1 18:57:33 MSK 2009 root@h30.sp.ipt.ru:/usr/obj/usr/src/sys/IN > > DUS i386 > > ----- > No. > It might be easier to bisect on releng/8.0 then. OK, I've found out that acroread works at 8-RC1 as of 2009-10-04 (with security.bsd.map_at_zero=1): ----- h31% uname -a 16:24 pts/0 FreeBSD h31.sp.ipt.ru 8.0-RC1 FreeBSD 8.0-RC1 #1: Sun Oct 4 02:19:42 MSD 2009 bsam@h31.sp.ipt.ru:/usr/obj/usr/src/sys/SHURAM i386 h31% sysctl security.bsd.map_at_zero 16:24 pts/0 security.bsd.map_at_zero: 1 ----- Can you give me suspisiuos commits to RELENG_8 to test (I don't have time ATM to do bisect builds)? -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From des at des.no Wed Nov 4 15:24:02 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Nov 4 15:24:09 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091031231545.493cee89@boiler.free.de> (Kai Gallasch's message of "Sat, 31 Oct 2009 23:15:45 +0100") References: <20091031231545.493cee89@boiler.free.de> Message-ID: <867hu6gvou.fsf@ds4.des.no> Kai Gallasch writes: > I installed 8.0RC2-amd64 on an 8-core opteron server a few days ago. > > When I try to do a make buildworld or make buildkernel the server > reboots without any message left in the logs. The same happens > when building bigger ports (for example ruby18 or perl58) Could it be related to this? What's your CPUID? Author: attilio Date: Wed Nov 4 01:32:59 2009 New Revision: 198868 URL: http://svn.freebsd.org/changeset/base/198868 Log: Opteron rev E family of processor expose a bug where, in very rare ocassions, memory barriers semantic is not honoured by the hardware itself. As a result, some random breakage can happen in uninvestigable ways (for further explanation see at the content of the commit itself). As long as just a specific familly is bugged of an entire architecture is broken, a complete fix-up is impratical without harming to some extents the other correct cases. Considering that (and considering the frequency of the bug exposure) just print out a warning message if the affected machine is identified. Pointed out by: Samy Al Bahra Help on wordings by: jeff MFC: 3 days Modified: head/sys/amd64/amd64/identcpu.c head/sys/i386/i386/identcpu.c DES -- Dag-Erling Sm?rgrav - des@des.no From gallasch at free.de Wed Nov 4 15:36:24 2009 From: gallasch at free.de (Kai Gallasch) Date: Wed Nov 4 15:36:32 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <867hu6gvou.fsf@ds4.des.no> References: <20091031231545.493cee89@boiler.free.de> <867hu6gvou.fsf@ds4.des.no> Message-ID: <20091104163621.36943807@orwell.free.de> Am Wed, 04 Nov 2009 16:24:01 +0100 schrieb Dag-Erling Sm?rgrav : > Kai Gallasch writes: > > I installed 8.0RC2-amd64 on an 8-core opteron server a few days ago. > > > > When I try to do a make buildworld or make buildkernel the server > > reboots without any message left in the logs. The same happens > > when building bigger ports (for example ruby18 or perl58) > > Could it be related to this? What's your CPUID? Found this in dmesg. Is this the CPUID? "Id = 0x100f23" --Kai. CPU: Quad-Core AMD Opteron(tm) Processor 2352 (2100.09-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f23 Stepping = 3 Features=0x178bfbff Features2=0x802009 AMD Features=0xee400800 AMD Features2=0x7ff TSC: P-state invariant real memory = 21474836480 (20480 MB) avail memory = 20701110272 (19742 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 -- If it wasn't for the last minute, nothing would get done. From shuvaev at physik.uni-wuerzburg.de Wed Nov 4 15:40:50 2009 From: shuvaev at physik.uni-wuerzburg.de (Alexey Shuvaev) Date: Wed Nov 4 15:40:59 2009 Subject: 8.0-RC2 mangles msdosfs In-Reply-To: <4AF1869D.6090304@bsdforen.de> References: <4AF1869D.6090304@bsdforen.de> Message-ID: <20091104154044.GA96964@wep4035.physik.uni-wuerzburg.de> On Wed, Nov 04, 2009 at 02:50:21PM +0100, Dominic Fandrey wrote: > Alexander Best wrote: > > Paul G Webster schrieb am 2009-11-03: > > *lol* just tried this myself and my fdisk output looks just as bad as yours: > > I think funny fdisk output is not that much of a problem. > > [snip] > > What I wonder is - are there more people who witness file > system corruption upon msdosfs writes (and don't forget > that either newfs_msdos or fsck_msdosfs is broken as well, > and that fsck_msdosfs certainly does not recognize > cross-linked files). The impact is so horrid that I had > to reformat my portable player (with Windows) and reinstall > the firmware to get it back going. > The relative silence on the mailing list seems to show it is not the common problem... ~> uname -a FreeBSD wep4035 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r198671: Fri Oct 30 16:12:10 CET 2009 root@wep4035:/usr/obj/usr/src/sys/GENERIC amd64 ugen7.2: at usbus7 umass0: on usbus7 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:1:0:-1: Attached to scbus1 (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0 (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data) da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 7790MB (15954944 512 byte sectors: 255H 63S/T 993C) GEOM: da0: partition 1 does not start on a track boundary. GEOM: da0: partition 1 does not end on a track boundary. ~> gpart show da0 => 63 15954876 da0 MBR (7.6G) 63 8129 - free - (4.0M) 8192 15946752 1 !11 (7.6G) ~> df [snip] /dev/da0s1 7969344 6322272 1647072 79% /home/lexx/mnt ~> mount [snip] /dev/da0s1 on /home/lexx/mnt (msdosfs, local, nosuid, mounted by lexx) This is a microSD card in a USB adaptor. Haven't any problems with it up to date. However I use it more or less carefully by: - trying to use only ASCII characters for filenames (from "C" locale) and avoiding any characters that require escaping in the shell, - never ever detaching it without prior unmount - if it matters I have never run fsck_msdosfs on it. Just 0.02$, Alexey. From alteriks at gmail.com Wed Nov 4 16:47:50 2009 From: alteriks at gmail.com (alteriks@gmail.com) Date: Wed Nov 4 16:47:57 2009 Subject: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable " In-Reply-To: <4AE96CCA.2080501@buchlovice.org> References: <200910291044.21818.alteriks@gmail.com> <4AE96CCA.2080501@buchlovice.org> Message-ID: <200911041747.21514.alteriks@gmail.com> Yesterday I tried installing FreeBSD once more, twice to be frank. I downloaded amd64 8.0-RC2 checked md5 sum. First time I installed it on physical machine. I created script with commands pasted here: http://pastebin.com/f72813264 After that I executed: chroot /zroot mount -t devfs devfs /dev export DESTDIR="" cd /usr/src/sys/boot/ make obj make depend make cd i386/loader make install umount /dev passwd exit cp /boot/zfs/zpool.cache /zroot/boot/zfs/zpool.cache Finally I launched this script: http://pastebin.com/f1449f548 Restart gave me: >GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable I created virtual machine on linux kvm, and added three drives. After starting system boot loader failed to launch with same error. I tried to reinstall FreeBSD under kvm, but it didn't help. Anyone has succeed installing amd64 8.0-RC2 with raidz1 on gpt drives? From tinderbox at freebsd.org Wed Nov 4 17:03:43 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Nov 4 17:04:03 2009 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <200911041647.nA4GlMG0079172@freebsd-current.sentex.ca> TB --- 2009-11-04 16:20:23 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-04 16:20:23 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-11-04 16:20:23 - cleaning the object tree TB --- 2009-11-04 16:20:39 - cvsupping the source tree TB --- 2009-11-04 16:20:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-11-04 16:21:05 - building world TB --- 2009-11-04 16:21:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-04 16:21:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-04 16:21:05 - TARGET=powerpc TB --- 2009-11-04 16:21:05 - TARGET_ARCH=powerpc TB --- 2009-11-04 16:21:05 - TZ=UTC TB --- 2009-11-04 16:21:05 - __MAKE_CONF=/dev/null TB --- 2009-11-04 16:21:05 - cd /src TB --- 2009-11-04 16:21:05 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 4 16:21:07 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/scsi_cmdparse.c cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/../../sys/cam/scsi/scsi_all.c cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/../../sys/cam/scsi/scsi_da.c cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/../../sys/cam/scsi/scsi_sa.c cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/../../sys/cam/cam.c cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/../../sys/cam/ata/ata_all.c /src/lib/libcam/../../sys/cam/ata/ata_all.c:379: error: conflicting types for 'ata_pm_write_cmd' /src/lib/libcam/../../sys/cam/ata/ata_all.h:106: error: previous declaration of 'ata_pm_write_cmd' was here *** Error code 1 Stop in /src/lib/libcam. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-04 16:47:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-04 16:47:22 - ERROR: failed to build world TB --- 2009-11-04 16:47:22 - 1150.63 user 261.07 system 1618.67 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From tinderbox at freebsd.org Wed Nov 4 17:18:13 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Nov 4 17:18:30 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <200911041701.nA4H1mBr077792@freebsd-current.sentex.ca> TB --- 2009-11-04 16:37:54 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-04 16:37:54 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-11-04 16:37:54 - cleaning the object tree TB --- 2009-11-04 16:38:09 - cvsupping the source tree TB --- 2009-11-04 16:38:09 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-11-04 16:38:35 - building world TB --- 2009-11-04 16:38:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-04 16:38:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-04 16:38:35 - TARGET=sparc64 TB --- 2009-11-04 16:38:35 - TARGET_ARCH=sparc64 TB --- 2009-11-04 16:38:35 - TZ=UTC TB --- 2009-11-04 16:38:35 - __MAKE_CONF=/dev/null TB --- 2009-11-04 16:38:35 - cd /src TB --- 2009-11-04 16:38:35 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 4 16:38:36 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/scsi_cmdparse.c cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/../../sys/cam/scsi/scsi_all.c cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/../../sys/cam/scsi/scsi_da.c cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/../../sys/cam/scsi/scsi_sa.c cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/../../sys/cam/cam.c cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/../../sys/cam/ata/ata_all.c /src/lib/libcam/../../sys/cam/ata/ata_all.c:379: error: conflicting types for 'ata_pm_write_cmd' /src/lib/libcam/../../sys/cam/ata/ata_all.h:106: error: previous declaration of 'ata_pm_write_cmd' was here *** Error code 1 Stop in /src/lib/libcam. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-04 17:01:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-04 17:01:48 - ERROR: failed to build world TB --- 2009-11-04 17:01:48 - 1070.16 user 255.82 system 1433.70 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From tom at tomjudge.com Wed Nov 4 17:21:04 2009 From: tom at tomjudge.com (Tom Judge) Date: Wed Nov 4 17:21:13 2009 Subject: USB Attach Failures (USB_ERR_STALLED) In-Reply-To: <200910281723.17481.hselasky@c2i.net> References: <4AE85740.8010003@tomjudge.com> <200910281723.17481.hselasky@c2i.net> Message-ID: <4AF1B7BE.2010402@tomjudge.com> Hans Petter Selasky wrote: > On Wednesday 28 October 2009 15:37:52 Tom Judge wrote: >> Hi, >> >> As of yesterday (not yesterdays current) I have been having issues when >> booting my D630 on the dock and having the USB devices attach correctly, >> this was all working before the weekend and I have not changed >> anything. My src tree is at r197709. >> >> If I disconnect the usb keyboard and mouse then re attach them to the >> same ports on the dock they are detected correctly. >> >> Is this a known issue? >> >> Tom > > Hi, > > Your issue is possibly related to some recent BIOS USB handover patches. Try > disabling USB in the BIOS. Else I think Andrew has more details. > > --HPS > Sorry for the late follow up. I have not changed any settings or updated and this problem has magically gone away. For some reason it happened for 2/3 days and now it has stopped. Tom From tinderbox at freebsd.org Wed Nov 4 17:26:21 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Nov 4 17:26:29 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <200911041709.nA4H9saj002723@freebsd-current.sentex.ca> TB --- 2009-11-04 16:47:22 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-04 16:47:22 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-11-04 16:47:22 - cleaning the object tree TB --- 2009-11-04 16:47:34 - cvsupping the source tree TB --- 2009-11-04 16:47:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-11-04 16:47:59 - building world TB --- 2009-11-04 16:47:59 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-04 16:47:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-04 16:47:59 - TARGET=sun4v TB --- 2009-11-04 16:47:59 - TARGET_ARCH=sparc64 TB --- 2009-11-04 16:47:59 - TZ=UTC TB --- 2009-11-04 16:47:59 - __MAKE_CONF=/dev/null TB --- 2009-11-04 16:47:59 - cd /src TB --- 2009-11-04 16:47:59 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 4 16:47:59 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/scsi_cmdparse.c cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/../../sys/cam/scsi/scsi_all.c cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/../../sys/cam/scsi/scsi_da.c cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/../../sys/cam/scsi/scsi_sa.c cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/../../sys/cam/cam.c cc -O2 -pipe -I/src/lib/libcam -I/src/lib/libcam/../../sys -std=gnu99 -fstack-protector -c /src/lib/libcam/../../sys/cam/ata/ata_all.c /src/lib/libcam/../../sys/cam/ata/ata_all.c:379: error: conflicting types for 'ata_pm_write_cmd' /src/lib/libcam/../../sys/cam/ata/ata_all.h:106: error: previous declaration of 'ata_pm_write_cmd' was here *** Error code 1 Stop in /src/lib/libcam. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-04 17:09:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-04 17:09:54 - ERROR: failed to build world TB --- 2009-11-04 17:09:54 - 1060.71 user 245.90 system 1351.91 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From nwf at cs.jhu.edu Wed Nov 4 17:22:05 2009 From: nwf at cs.jhu.edu (Nathaniel W Filardo) Date: Wed Nov 4 17:28:11 2009 Subject: SATA disk error and hang until "atacontrol reinit" ? In-Reply-To: <20091029213929.GD19125@gradx.cs.jhu.edu> References: <20091029213929.GD19125@gradx.cs.jhu.edu> Message-ID: <20091104172203.GJ19125@gradx.cs.jhu.edu> As a follow up, I had this happen again, without rebooting after running "atacontrol reinit ata4". That worked a few times, but the interval between failed requests was very small... At some point, reiniting the channel simply said "no devices attached" and I went and bought a new disk, fearing the worst. Placing that on the channel, I attempted "atacontrol reinit" again and it still refused to see the new disk. I tested both the new and old disks with a different controller and they worked fine. On the suggestion of ##freebsd, I ran "atacontrol detach ata4" and "atacontrol attach ata4"; the former completed, the latter produced this (via serial console): hydra# atacontrol attach ata4 ata4: [ITHREAD] 60201-4533^[[2;2~Master: no device present Slave: no device present ast data access mmu miss t ra p: f cpuid = 0 which I assume really meant to be "trap: fast data access mmu miss". I amn't sure what that means, but I have this lovely multi-gig core file now... which is potentially of little utility since I get told "GDB can't read core files on this machine." but if somebody wants something out of it, just ask. In any case, I powered the machine off, put the old disk back, and rebooted and am now scrubbing the RAIDZ, but it sees the old disk just fine. Suggestions? --nwf; -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091104/62fe740b/attachment.pgp From kostikbel at gmail.com Wed Nov 4 17:29:43 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Wed Nov 4 17:29:50 2009 Subject: [current] acroread: SIGSEGV In-Reply-To: <99188273@bb.ipt.ru> References: <65275688@bb.ipt.ru> <20091103154747.GC2331@deviant.kiev.zoral.com.ua> <77755531@h30.sp.ipt.ru> <20091103214032.GF2331@deviant.kiev.zoral.com.ua> <99188273@bb.ipt.ru> Message-ID: <20091104172931.GI2331@deviant.kiev.zoral.com.ua> On Wed, Nov 04, 2009 at 05:19:10PM +0300, Boris Samorodov wrote: > On Tue, 3 Nov 2009 23:40:32 +0200 Kostik Belousov wrote: > > On Wed, Nov 04, 2009 at 12:37:08AM +0300, Boris Samorodov wrote: > > > On Tue, 3 Nov 2009 17:47:47 +0200 Kostik Belousov wrote: > > > > On Tue, Nov 03, 2009 at 05:05:11PM +0300, Boris Samorodov wrote: > > > > > Hello List, > > > > > > > > > > print/acroread8 doesn't work for me at 9-CURRENT: > > > > > ----- > > > > > % uname -a > > > > > FreeBSD host.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon Nov 2 15:15:13 MSK 2009 root@host.ipt.ru:/usr/obj/usr/src/sys/HOST > > > > > % sysctl compat.linux > > > > > compat.linux.oss_version: 198144 > > > > > compat.linux.osrelease: 2.6.16 > > > > > compat.linux.osname: Linux > > > > > ------ > > > > > > > > > > Setting security.bsd.map_at_zero to 1 doesn't change anything. There is > > > > > nothing at console/log files. Here is the tail of linux_kdump: > > > > > ----- > > > > > ... > > > > > 78586 ld-2.9.so CALL linux_open(0x16fcd80,0,0x80d93000) > > > > > 78586 ld-2.9.so NAMI "/compat/linux/var/db/fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > > > 78586 ld-2.9.so NAMI "/var/db/fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > > > 78586 ld-2.9.so RET linux_open JUSTRETURN > > > > > 78586 ld-2.9.so CALL linux_open(0x16fcd80,0,0x80d93000) > > > > > 78586 ld-2.9.so NAMI "/compat/linux/home/bsam/.fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > > > 78586 ld-2.9.so NAMI "/home/bsam/.fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > > > 78586 ld-2.9.so RET linux_open 4 > > > > > 78586 ld-2.9.so CALL linux_fstat64(0x4,0xbfbfcf8c,0x2e482ff4) > > > > > 78586 ld-2.9.so RET linux_fstat64 0 > > > > > 78586 ld-2.9.so CALL read(0x4,0x16fe160,0x60) > > > > > 78586 ld-2.9.so GIO fd 4 read 96 bytes > > > > > "\^D\M-|\^B\M-|\^B\0\0\0`\0\0\0 \0\0\0P\0\0\0\0\0\0\0P\0\0\0\^[b\M-TJ/usr/local/lib/X11/fonts/encodings/large\0\0\0\0\0\0\0\0\0\0\ > > > > > \0\0\0\0\0\0\^Q\0\0\0\0\0\0\000" > > > > > 78586 ld-2.9.so RET read 96/0x60 > > > > > 78586 ld-2.9.so CALL close(0x4) > > > > > 78586 ld-2.9.so RET close 0 > > > > > 78586 ld-2.9.so CALL linux_mmap2(0,0x25000,0x3,0x22,0xffffffff,0) > > > > > 78586 ld-2.9.so RET linux_mmap2 833982464/0x31b59000 > > > > > 78586 ld-2.9.so PSIG SIGSEGV caught handler=0x83814b6 mask=0x0 code=0x0 > > > > > 78586 ld-2.9.so CALL linux_rt_sigaction(0x6,0xbfbfcbf0,0xbfbfcb64,0x8) > > > > > 78586 ld-2.9.so RET linux_rt_sigaction 0 > > > > > 78586 ld-2.9.so CALL linux_exit_group(0x1) > > > > > > > It would be interesting to see which address faulted. > > > > If not, can you do search for a kernel revision that broke acroread ? > > > > Good starting points are r198507 and r198554. > > > > > > Were those revisions MFCed to RELENG_8_0? I've got the same for 8.0: > > > ----- > > > % uname -a > > > FreeBSD h30.sp.ipt.ru 8.0-RC2 FreeBSD 8.0-RC2 #0: Sun Nov 1 18:57:33 MSK 2009 root@h30.sp.ipt.ru:/usr/obj/usr/src/sys/IN > > > DUS i386 > > > ----- > > No. > > It might be easier to bisect on releng/8.0 then. > > OK, I've found out that acroread works at 8-RC1 as of 2009-10-04 > (with security.bsd.map_at_zero=1): > ----- > h31% uname -a 16:24 pts/0 > FreeBSD h31.sp.ipt.ru 8.0-RC1 FreeBSD 8.0-RC1 #1: Sun Oct 4 02:19:42 MSD 2009 bsam@h31.sp.ipt.ru:/usr/obj/usr/src/sys/SHURAM i386 > h31% sysctl security.bsd.map_at_zero 16:24 pts/0 > security.bsd.map_at_zero: 1 > ----- > > Can you give me suspisiuos commits to RELENG_8 to test (I don't have > time ATM to do bisect builds)? I do not have good guess. I would put a finger in the direction of the imgact_elf.c changes. But, since the issue appears at run-time, after the binary started, I doubt it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091104/2c90e225/attachment.pgp From hselasky at c2i.net Wed Nov 4 17:40:25 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Wed Nov 4 17:40:33 2009 Subject: USB Attach Failures (USB_ERR_STALLED) In-Reply-To: <4AF1B7BE.2010402@tomjudge.com> References: <4AE85740.8010003@tomjudge.com> <200910281723.17481.hselasky@c2i.net> <4AF1B7BE.2010402@tomjudge.com> Message-ID: <200911041839.25641.hselasky@c2i.net> On Wednesday 04 November 2009 18:19:58 Tom Judge wrote: > Sorry for the late follow up. > > I have not changed any settings or updated and this problem has > magically gone away. For some reason it happened for 2/3 days and now > it has stopped. > > > Tom Ok. No problem. --HPS From atkin901 at yahoo.com Wed Nov 4 21:32:03 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Wed Nov 4 21:32:13 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091104163621.36943807@orwell.free.de> References: <20091031231545.493cee89@boiler.free.de> <867hu6gvou.fsf@ds4.des.no> <20091104163621.36943807@orwell.free.de> Message-ID: <4AF1F2B7.5040803@yahoo.com> Kai Gallasch wrote: > Am Wed, 04 Nov 2009 16:24:01 +0100 > schrieb Dag-Erling Sm?rgrav : > >> Kai Gallasch writes: >>> I installed 8.0RC2-amd64 on an 8-core opteron server a few days ago. >>> >>> When I try to do a make buildworld or make buildkernel the server >>> reboots without any message left in the logs. The same happens >>> when building bigger ports (for example ruby18 or perl58) >> Could it be related to this? What's your CPUID? > > Found this in dmesg. Is this the CPUID? "Id = 0x100f23" That's generation 16 model 2 stepping 3. This errata only effects generation 0xe or 15. BTW, I have the same processor/stepping/Mhz in my system, but only a single physical processor. > --Kai. > > > CPU: Quad-Core AMD Opteron(tm) Processor 2352 (2100.09-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x100f23 Stepping = 3 > Features=0x178bfbff > Features2=0x802009 > AMD > Features=0xee400800 > AMD > Features2=0x7ff > TSC: P-state invariant real memory = 21474836480 (20480 MB) avail > memory = 20701110272 (19742 MB) ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 2 package(s) x 4 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > cpu4 (AP): APIC ID: 4 > cpu5 (AP): APIC ID: 5 > cpu6 (AP): APIC ID: 6 > cpu7 (AP): APIC ID: 7 > > From atkin901 at yahoo.com Wed Nov 4 21:35:06 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Wed Nov 4 21:35:12 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091104163621.36943807@orwell.free.de> References: <20091031231545.493cee89@boiler.free.de> <867hu6gvou.fsf@ds4.des.no> <20091104163621.36943807@orwell.free.de> Message-ID: Kai Gallasch wrote: > Am Wed, 04 Nov 2009 16:24:01 +0100 > schrieb Dag-Erling Sm?rgrav : > >> Kai Gallasch writes: >>> I installed 8.0RC2-amd64 on an 8-core opteron server a few days ago. >>> >>> When I try to do a make buildworld or make buildkernel the server >>> reboots without any message left in the logs. The same happens >>> when building bigger ports (for example ruby18 or perl58) >> Could it be related to this? What's your CPUID? > > Found this in dmesg. Is this the CPUID? "Id = 0x100f23" That's generation 16 (0xf) model 2, stepping 3. This errata apparently only effects gen 15 (0xe) and some pre-release -- never released to public (0xf). I have the same processor in my system btw. > > --Kai. > > > CPU: Quad-Core AMD Opteron(tm) Processor 2352 (2100.09-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x100f23 Stepping = 3 > Features=0x178bfbff > Features2=0x802009 > AMD > Features=0xee400800 > AMD > Features2=0x7ff > TSC: P-state invariant real memory = 21474836480 (20480 MB) avail > memory = 20701110272 (19742 MB) ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs > FreeBSD/SMP: 2 package(s) x 4 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > cpu2 (AP): APIC ID: 2 > cpu3 (AP): APIC ID: 3 > cpu4 (AP): APIC ID: 4 > cpu5 (AP): APIC ID: 5 > cpu6 (AP): APIC ID: 6 > cpu7 (AP): APIC ID: 7 > > From atkin901 at yahoo.com Wed Nov 4 21:46:15 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Wed Nov 4 21:46:21 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: References: <20091031231545.493cee89@boiler.free.de> <867hu6gvou.fsf@ds4.des.no> <20091104163621.36943807@orwell.free.de> Message-ID: Mark Atkinson wrote: > Kai Gallasch wrote: >> Am Wed, 04 Nov 2009 16:24:01 +0100 >> schrieb Dag-Erling Sm?rgrav : >> >>> Kai Gallasch writes: >>>> I installed 8.0RC2-amd64 on an 8-core opteron server a few days ago. >>>> >>>> When I try to do a make buildworld or make buildkernel the server >>>> reboots without any message left in the logs. The same happens >>>> when building bigger ports (for example ruby18 or perl58) >>> Could it be related to this? What's your CPUID? > >> Found this in dmesg. Is this the CPUID? "Id = 0x100f23" > > That's generation 16 (0xf) model 2, stepping 3. This errata apparently > only effects gen 15 (0xe) and some pre-release -- never released to > public (0xf). I have the same processor in my system btw. sorry for the double wrong posting. I see several webpages refer to 15 as f and 16 as f. usr/ports/misc/cpuid refers to it as 15. The pages referenced via the bugzilla entry in the commit refer to it as 0xf but between 32 and 63. Does the model 2 correctly put us in the range in the commit 0x20 and 0x3f? (i.e. stepping is included?) From gaijin.k at gmail.com Wed Nov 4 21:51:47 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Wed Nov 4 21:51:53 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <44591257331450@webmail38.yandex.ru> References: <44591257331450@webmail38.yandex.ru> Message-ID: <1257371499.1624.10.camel@RabbitsDen> On Wed, 2009-11-04 at 13:44 +0300, S.N.Grigoriev wrote: > Hi list, > > I can confirm I've seen the same problem. After upgrading from 7-stable > to 8.0-RC2 my machine just reboots during 'make buildworld' without > diagnostics. But switching vm.pmap.pg_ps_enabled on/off does not > work for me. My machine reboots every time I try to build world. > I don't think I have a hardware problem: under 7-stable I can build > world/kernel for both 7-stable and 8.0-RC2 without problems. > Is it by any chance possible that you have 'debug.debugger_on_panic' set to '0' and no valid dump device configured? -- Alexandre Kovalenko (????????? ?????????) From atkin901 at yahoo.com Wed Nov 4 22:37:18 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Wed Nov 4 22:37:26 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: References: <20091031231545.493cee89@boiler.free.de> <867hu6gvou.fsf@ds4.des.no> <20091104163621.36943807@orwell.free.de> Message-ID: Mark Atkinson wrote: > Mark Atkinson wrote: >> Kai Gallasch wrote: >>> Am Wed, 04 Nov 2009 16:24:01 +0100 >>> schrieb Dag-Erling Sm?rgrav : >>> >>>> Kai Gallasch writes: >>>>> I installed 8.0RC2-amd64 on an 8-core opteron server a few days ago. >>>>> >>>>> When I try to do a make buildworld or make buildkernel the server >>>>> reboots without any message left in the logs. The same happens >>>>> when building bigger ports (for example ruby18 or perl58) >>>> Could it be related to this? What's your CPUID? >>> Found this in dmesg. Is this the CPUID? "Id = 0x100f23" >> That's generation 16 (0xf) model 2, stepping 3. This errata apparently >> only effects gen 15 (0xe) and some pre-release -- never released to >> public (0xf). I have the same processor in my system btw. > > sorry for the double wrong posting. I see several webpages refer to 15 > as f and 16 as f. usr/ports/misc/cpuid refers to it as 15. > > The pages referenced via the bugzilla entry in the commit refer to it as > 0xf but between 32 and 63. Does the model 2 correctly put us in the > range in the commit 0x20 and 0x3f? (i.e. stepping is included?) I'll answer my own question, no: http://support.amd.com/us/Processor_TechDocs/25481.pdf Although the some of the posts in http://bugzilla.kernel.org/show_bug.cgi?id=11305 indicate any model < 0x40. Someone must have actually narrowed the range. From adrian at freebsd.org Wed Nov 4 23:47:26 2009 From: adrian at freebsd.org (Adrian Chadd) Date: Wed Nov 4 23:47:33 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: References: <20091031231545.493cee89@boiler.free.de> <867hu6gvou.fsf@ds4.des.no> <20091104163621.36943807@orwell.free.de> Message-ID: 2009/11/5 Mark Atkinson : > > I'll answer my own question, no: > > http://support.amd.com/us/Processor_TechDocs/25481.pdf > > Although the some of the posts in > > http://bugzilla.kernel.org/show_bug.cgi?id=11305 > > indicate any model < 0x40. ?Someone must have actually narrowed the range. Is there a FreeBSD PR or errata URL which can be linked to instead, complete with copies of the above in it? Adrian From joe at via.net Thu Nov 5 00:03:56 2009 From: joe at via.net (joe mcguckin) Date: Thu Nov 5 00:04:03 2009 Subject: What is the state of ZFS on FreeBSD? Message-ID: <17E3C299-725B-434E-805D-CA0C1EA9C8B9@via.net> I'm interested inb putting together a file server with lots of disk. What's the state of ZFS? Is it ready for production use? Thanks, Joe Joe McGuckin ViaNet Communications joe@via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax From alexbestms at math.uni-muenster.de Thu Nov 5 00:15:08 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Thu Nov 5 00:15:16 2009 Subject: What is the state of ZFS on FreeBSD? Message-ID: should be: http://www.freebsd.org/news/status/report-2009-04-2009-09.html#FreeBSD/ZFS alex From alexbestms at math.uni-muenster.de Thu Nov 5 00:16:54 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Thu Nov 5 00:17:02 2009 Subject: panic when mounting device >= 2 times Message-ID: any recent developments concerning this problem? here's the pr btw: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/139718 alex From quakelee at geekcn.org Thu Nov 5 03:34:42 2009 From: quakelee at geekcn.org (Chao Shin) Date: Thu Nov 5 03:34:49 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: <30F3E66A-4A69-46CE-96F4-44B4049722E2@samsco.org> References: <20091002150931.K35591@pooker.samsco.org> <200910031230.51044.hselasky@c2i.net> <200910031800.24896.hselasky@c2i.net> <30F3E66A-4A69-46CE-96F4-44B4049722E2@samsco.org> Message-ID: ? Sun, 04 Oct 2009 07:52:45 +0800?Scott Long ??: Hi all Is there any newer patch/workarounds available? > On Oct 3, 2009, at 12:51 PM, Marcel Moolenaar wrote: > >> >> On Oct 3, 2009, at 9:00 AM, Hans Petter Selasky wrote: >> >>> On Saturday 03 October 2009 17:05:35 Scott Long wrote: >>>> On Oct 3, 2009, at 4:30 AM, Hans Petter Selasky wrote: >>>>> On Saturday 03 October 2009 10:19:57 Scott Long wrote: >>>>>> config_intrhook system will sleep after all >>>>> >>>>> Then why do you need the intr hook callback? >>>> >>>> The config_intrhook lets you know that interrupts are enabled, the >>>> scheduler is running, and mountroot hasn't run yet. It provides a >>>> very convenient and standard way to do exactly what we want with USB >>>> enumeration. >>> >>> Hi, >>> >>> The root HUB attach and explore code is already running from a separate >>> thread, so won't that be superfluous? I mean, the HUB explore code for >>> any USB >>> HUB will not run until the scheduler is running anyway. >>> >>> In my opinion delaying the system until the boot disk is present is >>> just not >>> good. We should rather be event driven, so that every time a new disk >>> becomes >>> present it checks it for mountroot. >>> >>> while (1) { >>> if (mountroot is successful) >>> break; >>> if (ctrl+c is pressed) >>> manual_mountroot(); >>> printf("Waiting 1 second for root-disk to appear. Press CTRL+C to >>> abort.\n"); >>> sleep(1); >>> } >> >> Yes. >> >> The mount root code should keep a list of potential root devices to try >> and >> it should try a device as soon as it appears. The current approach to >> block >> the root mount simply because we want everything to be discovered >> before we >> try to mount the root is preventing fast boots -- such as when the root >> is >> a memory disk and you don't need to wait for anything... >> >> Put differently: it's rather odd to hold off the root mount when the >> root >> device is already present... >> >> An approach like this also allows one to indefinitely wait for the root >> device, which is a good feature to have... >> >> > > When /etc/rc tries to mount everything in the fstab, it'll fail the boot > if some of the devices haven't arrived in time. An argument can be made > for fixing that as well, but we're starting to get beyond on the scope > of fixing what is needed for 8.0-RELEASE. > > Scott > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" -- The Power to Serve From sziszi at bsd.hu Thu Nov 5 06:11:30 2009 From: sziszi at bsd.hu (Szilveszter Adam) Date: Thu Nov 5 06:11:37 2009 Subject: 8.0-RC2 mangles msdosfs In-Reply-To: <4AF1869D.6090304@bsdforen.de> References: <4AF1869D.6090304@bsdforen.de> Message-ID: <20091105061126.GA1839@baranyfelhocske.buza.adamsfamily.xx> Hello, On Wed, Nov 04, 2009 at 02:50:21PM +0100, Dominic Fandrey wrote: > What I wonder is - are there more people who witness file > system corruption upon msdosfs writes (and don't forget > that either newfs_msdos or fsck_msdosfs is broken as well, > and that fsck_msdosfs certainly does not recognize > cross-linked files). The impact is so horrid that I had > to reformat my portable player (with Windows) and reinstall > the firmware to get it back going. Well, this is of course only anecdotal, but I do not witness corruption with any of my USB-attached umass devices. (I no longer have a floppy drive, and I do not have a FAT partition on my HDD either, so I cannot test that). I am using 9.0-CURRENT, rev 198667 (but the problem did not show also on earlier revs) The devices that I use on and off: - Meizu M3 Music Card audio player - Cowon iaudio D2 audio player (According to user forums, this one is particularly sensitive to fs corruption) - various USB sticks, most notably a Kingston Data Traveller 4G (I believe) - Even the occasional memory stick, or SD card in card reader However, I must also state that I never used fsck_msdosfs in the last few years. Neither have I formatted any FAT file systems under FreeBSD for years. Also, I always unmount the devices before removing them. -- Regards: Szilveszter ADAM Budapest Hungary From artis.caune at gmail.com Thu Nov 5 06:47:25 2009 From: artis.caune at gmail.com (Artis Caune) Date: Thu Nov 5 06:47:32 2009 Subject: What is the state of ZFS on FreeBSD? In-Reply-To: <17E3C299-725B-434E-805D-CA0C1EA9C8B9@via.net> References: <17E3C299-725B-434E-805D-CA0C1EA9C8B9@via.net> Message-ID: <9e20d71e0911042247n216e9b02t7b317a55a9bbe131@mail.gmail.com> 2009/11/5 joe mcguckin : > I'm interested inb putting together a file server with lots of disk. > > What's the state of ZFS? Is it ready for production use? yes, please, see http://svn.freebsd.org/viewvc/base?view=revision&revision=197218 -- Artis Caune Everything should be made as simple as possible, but not simpler. From sfourman at gmail.com Thu Nov 5 08:19:26 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Thu Nov 5 08:19:33 2009 Subject: What is the state of ZFS on FreeBSD? In-Reply-To: <9e20d71e0911042247n216e9b02t7b317a55a9bbe131@mail.gmail.com> References: <17E3C299-725B-434E-805D-CA0C1EA9C8B9@via.net> <9e20d71e0911042247n216e9b02t7b317a55a9bbe131@mail.gmail.com> Message-ID: <11167f520911050019k17137f3q6e36614e2178b12d@mail.gmail.com> On Thu, Nov 5, 2009 at 12:47 AM, Artis Caune wrote: > 2009/11/5 joe mcguckin : >> I'm interested inb putting together a file server with lots of disk. >> >> What's the state of ZFS? Is it ready for production use? We are using it in production and have a 6TB RAIDZ on FreeBSD8 RC2 amd64 we are quite happy with the FreeBSD 8 setup. we tried it on FreeBSD 7.2 i386 and did not like it (we got a few panics) the only trouble we really had on FreeBSD8 is the sharenfs manpages are not updated. so we are using the classic /etc/exports instead of the zfs option. Sam Fourman Jr. Fourman Networks From hselasky at c2i.net Thu Nov 5 08:23:08 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Nov 5 08:23:15 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: References: <20091002150931.K35591@pooker.samsco.org> <30F3E66A-4A69-46CE-96F4-44B4049722E2@samsco.org> Message-ID: <200911050922.10205.hselasky@c2i.net> Hi, There is a newer patch in USB P4. The problem is when the /usr partition for example is not residing on the root disk, which is the only disk the code is waiting for. Then the patch will make the bootup fail. --HPS On Thursday 05 November 2009 04:34:33 Chao Shin wrote: > ? Sun, 04 Oct 2009 07:52:45 +0800?Scott Long ??: > > Hi all > > Is there any newer patch/workarounds available? > > > On Oct 3, 2009, at 12:51 PM, Marcel Moolenaar wrote: > >> On Oct 3, 2009, at 9:00 AM, Hans Petter Selasky wrote: > >>> On Saturday 03 October 2009 17:05:35 Scott Long wrote: > >>>> On Oct 3, 2009, at 4:30 AM, Hans Petter Selasky wrote: > >>>>> On Saturday 03 October 2009 10:19:57 Scott Long wrote: > >>>>>> config_intrhook system will sleep after all > >>>>> > >>>>> Then why do you need the intr hook callback? > >>>> > >>>> The config_intrhook lets you know that interrupts are enabled, the > >>>> scheduler is running, and mountroot hasn't run yet. It provides a > >>>> very convenient and standard way to do exactly what we want with USB > >>>> enumeration. > >>> > >>> Hi, > >>> > >>> The root HUB attach and explore code is already running from a separate > >>> thread, so won't that be superfluous? I mean, the HUB explore code for > >>> any USB > >>> HUB will not run until the scheduler is running anyway. > >>> > >>> In my opinion delaying the system until the boot disk is present is > >>> just not > >>> good. We should rather be event driven, so that every time a new disk > >>> becomes > >>> present it checks it for mountroot. > >>> > >>> while (1) { > >>> if (mountroot is successful) > >>> break; > >>> if (ctrl+c is pressed) > >>> manual_mountroot(); > >>> printf("Waiting 1 second for root-disk to appear. Press CTRL+C to > >>> abort.\n"); > >>> sleep(1); > >>> } > >> > >> Yes. > >> > >> The mount root code should keep a list of potential root devices to try > >> and > >> it should try a device as soon as it appears. The current approach to > >> block > >> the root mount simply because we want everything to be discovered > >> before we > >> try to mount the root is preventing fast boots -- such as when the root > >> is > >> a memory disk and you don't need to wait for anything... > >> > >> Put differently: it's rather odd to hold off the root mount when the > >> root > >> device is already present... > >> > >> An approach like this also allows one to indefinitely wait for the root > >> device, which is a good feature to have... > > > > When /etc/rc tries to mount everything in the fstab, it'll fail the boot > > if some of the devices haven't arrived in time. An argument can be made > > for fixing that as well, but we're starting to get beyond on the scope > > of fixing what is needed for 8.0-RELEASE. > > > > Scott > > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to > > "freebsd-current-unsubscribe@freebsd.org" From gerrit at pmp.uni-hannover.de Thu Nov 5 08:35:15 2009 From: gerrit at pmp.uni-hannover.de (Gerrit =?ISO-8859-1?Q?K=FChn?=) Date: Thu Nov 5 08:35:23 2009 Subject: zfs panic mounting fs after crash with RC2 Message-ID: <20091105091938.8a27caac.gerrit@pmp.uni-hannover.de> Hi, since I got no further reaction on this on -stable, I'm trying it here on -current as some discussion of RC2-issues seems to go on here, too. Any help is -of course- very much appreciated: Begin forwarded message: Date: Wed, 4 Nov 2009 09:29:00 +0100 From: Gerrit K?hn To: freebsd-stable@FreeBSD.ORG Cc: Subject: zfs panic mounting fs after crash with RC2 Hi, Yesterday I had the opportunity to play around with my yet-to-become new fileserver a bit more. Originally I had installed 7.2-R, which I upgraded to 8-0-RC2 yesterday. After that I upgraded my zpool consisting of 4 disks in raidz1 constallation to v13. Some time later I tried to use powerd which was obviously a bad idea: it crashed the machine immediately. I will give a separate report on that later as it is probably related to the hardware, which is a bit exotic (VIA VB8001 board with 64bit Via Nano processor). However, the worst thing for me is, that after rebooting from that crash, one of my zfs fs cannot be mounted anymore. As soon as I try to mount it I get a kernel panic. I can still access the properties (I made use of "canmount=noauto" for the first time :-), but I cannot do a snapshot of the fs (funny enough, zfs complains that the fs is busy, while in reality it is not even mounted - so how could it be busy?). I took a picture of the kernel panic and put it here (don't know if there is any useful information in it): The pool as such seems to be fine, all other fs in it can be mounted and used, only trying to mount tank/sys/var triggers this panic. Are there any suggestions what I could do to get my fs back? Please let me know if (and how) I can provide more debugging information. cu Gerrit From oliver at namp.de Thu Nov 5 10:51:38 2009 From: oliver at namp.de (Oliver Fakler) Date: Thu Nov 5 10:51:45 2009 Subject: What is the state of ZFS on FreeBSD? In-Reply-To: <11167f520911050019k17137f3q6e36614e2178b12d@mail.gmail.com> References: <17E3C299-725B-434E-805D-CA0C1EA9C8B9@via.net> <9e20d71e0911042247n216e9b02t7b317a55a9bbe131@mail.gmail.com> <11167f520911050019k17137f3q6e36614e2178b12d@mail.gmail.com> Message-ID: <4AF2AE34.6000009@namp.de> Hi, may you can give me a tip for the speed tuning. i tested 8 rc1 with a 3 tb raidz and samba on a 100 mbit network i got 4 mb/s which is quite slow i think. May you have a idea for me Greets Oliver Sam Fourman Jr. schrieb: > On Thu, Nov 5, 2009 at 12:47 AM, Artis Caune wrote: > >> 2009/11/5 joe mcguckin : >> >>> I'm interested inb putting together a file server with lots of disk. >>> >>> What's the state of ZFS? Is it ready for production use? >>> > > We are using it in production and have a 6TB RAIDZ on FreeBSD8 RC2 amd64 > we are quite happy with the FreeBSD 8 setup. > we tried it on FreeBSD 7.2 i386 and did not like it (we got a few panics) > > the only trouble we really had on FreeBSD8 is the sharenfs manpages > are not updated. > so we are using the classic /etc/exports instead of the zfs option. > > Sam Fourman Jr. > Fourman Networks > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From giovanni.trematerra at gmail.com Thu Nov 5 11:02:42 2009 From: giovanni.trematerra at gmail.com (Giovanni Trematerra) Date: Thu Nov 5 11:02:50 2009 Subject: [PATCH] AMD Opteron Rev. E hack Message-ID: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> Hi, I have a quick and dirty patch to address the problem as discussed on commit r198868 in svn-src-head@ I introduced BROKEN_OPTERON_E kernel option for i386/amd64 arch. The patch isn't tested yet, I only successfully compiled on i386. Can you let me know if the patch is on the right direction to resolve the issue? style(9) tips are welcomed. Thank you -- Giovanni Trematerra -------------- next part -------------- A non-text attachment was scrubbed... Name: opteronhack.diff Type: application/octet-stream Size: 4841 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091105/81fcdc41/opteronhack.obj From des at des.no Thu Nov 5 11:18:56 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Nov 5 11:19:03 2009 Subject: [PATCH] AMD Opteron Rev. E hack In-Reply-To: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> (Giovanni Trematerra's message of "Thu, 5 Nov 2009 12:02:39 +0100") References: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> Message-ID: <86k4y5fcde.fsf@ds4.des.no> Giovanni Trematerra writes: > I have a quick and dirty patch to address the problem as discussed on > commit r198868 in svn-src-head@ > I introduced BROKEN_OPTERON_E kernel option for i386/amd64 arch. > The patch isn't tested yet, I only successfully compiled on i386. > Can you let me know if the patch is on the right direction to resolve the issue? > style(9) tips are welcomed. We should probably call it OPTERON_E_LFENCE_HACK or something, cf. NO_F00F_HACK (which has the opposite semantics - the f00f hack is enabled by default, though at this point we should probably reverse it and just print a warning if we detect a vulnerable CPU), and the wording of those printfs needs work, but it looks OK overall. BTW, you should use the text/x-patch MIME type for patches, instead of application/octet-stream. DES -- Dag-Erling Sm?rgrav - des@des.no From kostikbel at gmail.com Thu Nov 5 11:28:41 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Nov 5 11:28:48 2009 Subject: [PATCH] AMD Opteron Rev. E hack In-Reply-To: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> References: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> Message-ID: <20091105112834.GR2331@deviant.kiev.zoral.com.ua> On Thu, Nov 05, 2009 at 12:02:39PM +0100, Giovanni Trematerra wrote: > Hi, > I have a quick and dirty patch to address the problem as discussed on > commit r198868 in svn-src-head@ > I introduced BROKEN_OPTERON_E kernel option for i386/amd64 arch. > The patch isn't tested yet, I only successfully compiled on i386. > Can you let me know if the patch is on the right direction to resolve the issue? > style(9) tips are welcomed. I think there is no much sense in printing that hack in unused; instead, you should print info when option is enabled and vulnerable CPU is detected. Aren't atomic_readandclear need the same workaround ? It would be much easier to read the patch if you generated it with analog of "svn diff -x -p" for your VCS. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091105/ea312f9b/attachment.pgp From des at des.no Thu Nov 5 11:52:04 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Nov 5 11:52:11 2009 Subject: [PATCH] AMD Opteron Rev. E hack In-Reply-To: <20091105112834.GR2331@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Thu, 5 Nov 2009 13:28:34 +0200") References: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> <20091105112834.GR2331@deviant.kiev.zoral.com.ua> Message-ID: <86fx8tfau7.fsf@ds4.des.no> Kostik Belousov writes: > I think there is no much sense in printing that hack in unused; > instead, you should print info when option is enabled and vulnerable > CPU is detected. We should *definitely* print a warninhg when a vulnerable CPU is detected and the option is *not* enabled. How do you justify not telling the user that you know the machine will crash as soon as he runs 'make buildworld' with a high -j value? DES -- Dag-Erling Sm?rgrav - des@des.no From kostikbel at gmail.com Thu Nov 5 12:00:42 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Nov 5 12:00:49 2009 Subject: [PATCH] AMD Opteron Rev. E hack In-Reply-To: <86fx8tfau7.fsf@ds4.des.no> References: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> <20091105112834.GR2331@deviant.kiev.zoral.com.ua> <86fx8tfau7.fsf@ds4.des.no> Message-ID: <20091105120034.GS2331@deviant.kiev.zoral.com.ua> On Thu, Nov 05, 2009 at 12:52:00PM +0100, Dag-Erling Sm??rgrav wrote: > Kostik Belousov writes: > > I think there is no much sense in printing that hack in unused; > > instead, you should print info when option is enabled and vulnerable > > CPU is detected. > > We should *definitely* print a warninhg when a vulnerable CPU is > detected and the option is *not* enabled. How do you justify not > telling the user that you know the machine will crash as soon as he runs > 'make buildworld' with a high -j value? We do not do this for other cpu bugs workarounds, why this should be different. Besides, there were no confirmed reports of this happening in field (I mean the bug manifestation, not make -j panicing or hanging machine :). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091105/a048e5f7/attachment.pgp From giovanni.trematerra at gmail.com Thu Nov 5 12:24:56 2009 From: giovanni.trematerra at gmail.com (Giovanni Trematerra) Date: Thu Nov 5 12:25:04 2009 Subject: [PATCH] AMD Opteron Rev. E hack In-Reply-To: <20091105112834.GR2331@deviant.kiev.zoral.com.ua> References: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> <20091105112834.GR2331@deviant.kiev.zoral.com.ua> Message-ID: <4e6cba830911050424y17ea8e7fmf5573b3a765eac27@mail.gmail.com> On Thu, Nov 5, 2009 at 12:28 PM, Kostik Belousov wrote: > > Aren't atomic_readandclear need the same workaround ? > I understood that the bug manifests itself only when lock instruction is used. atomic_readandclear doesn't use lock. I think i386/linux/linux_support.s and amd64/linux32/linux32_support.s need the work-around too. > It would be much easier to read the patch if you generated it > with analog of "svn diff -x -p" for your VCS. > I'm sorry, I'll do my best next time. -- Giovanni Trematerra From mdounin at mdounin.ru Thu Nov 5 12:30:31 2009 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu Nov 5 12:30:39 2009 Subject: [PATCH] AMD Opteron Rev. E hack In-Reply-To: <20091105120034.GS2331@deviant.kiev.zoral.com.ua> References: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> <20091105112834.GR2331@deviant.kiev.zoral.com.ua> <86fx8tfau7.fsf@ds4.des.no> <20091105120034.GS2331@deviant.kiev.zoral.com.ua> Message-ID: <20091105123028.GK1144@mdounin.ru> Hello! On Thu, Nov 05, 2009 at 02:00:34PM +0200, Kostik Belousov wrote: > On Thu, Nov 05, 2009 at 12:52:00PM +0100, Dag-Erling Sm??rgrav wrote: > > Kostik Belousov writes: > > > I think there is no much sense in printing that hack in unused; > > > instead, you should print info when option is enabled and vulnerable > > > CPU is detected. > > > > We should *definitely* print a warninhg when a vulnerable CPU is > > detected and the option is *not* enabled. How do you justify not > > telling the user that you know the machine will crash as soon as he runs > > 'make buildworld' with a high -j value? > > We do not do this for other cpu bugs workarounds, why this should be > different. Well, probably is't a good idea to do so? Something like NetBSD's sys/arch/x86/x86/errata.c seems to be right way to go. > Besides, there were no confirmed reports of this happening > in field (I mean the bug manifestation, not make -j panicing or hanging > machine :). http://bugs.mysql.com/bug.php?id=26081 Maxim Dounin From kostikbel at gmail.com Thu Nov 5 12:45:12 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Nov 5 12:45:33 2009 Subject: [PATCH] AMD Opteron Rev. E hack In-Reply-To: <4e6cba830911050424y17ea8e7fmf5573b3a765eac27@mail.gmail.com> References: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> <20091105112834.GR2331@deviant.kiev.zoral.com.ua> <4e6cba830911050424y17ea8e7fmf5573b3a765eac27@mail.gmail.com> Message-ID: <20091105124505.GT2331@deviant.kiev.zoral.com.ua> On Thu, Nov 05, 2009 at 01:24:53PM +0100, Giovanni Trematerra wrote: > On Thu, Nov 5, 2009 at 12:28 PM, Kostik Belousov wrote: > > > > > Aren't atomic_readandclear need the same workaround ? > > > > I understood that the bug manifests itself only when lock instruction is used. > atomic_readandclear doesn't use lock. xchgl uses lock implicitely: If a memory operand is referenced, the processor's locking protocol is automatically implemented for the duration of the exchange operation, regardless of the presence or absence of the LOCK prefix or of the value of the IOPL. > I think i386/linux/linux_support.s and amd64/linux32/linux32_support.s > need the work-around too. What about casuword32 ? It is actually unclear from the bug description whether we need it there. Description states "a locked instruction doesn't act as a read-acquire barrier if followed by a non-locked read-modify-write instruction." casuword32 for amd64, for instance, does movq immediately after cmpxchgl, that is a store op, not read-modify-store. So, does it need a workaround ? Similar stores are performed in linux32_support.s. atomic.h functions definitely need your workaround since they are inlined. Also, I remember that bind(8) provides its own atomic implementation. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091105/06d938f9/attachment.pgp From gaijin.k at gmail.com Thu Nov 5 13:01:09 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Thu Nov 5 13:01:15 2009 Subject: After sys/net80211 changes in r198931 laptop is no longer associating with AP Message-ID: <1257426023.1436.18.camel@RabbitsDen> It seems that 8.0 discussion is still going on on @current... if I should have posted this on @stable, please, feel free to chastise me as appropriate. After updating to r198831 my laptop no longer associates with either of two APs I have. Rolling back just 'sys/net80211' to r198443 fixes the problem. Working system: FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC1 FreeBSD 8.0-RC1 #0 r198443M: Sat Oct 24 14:03:30 EDT 2009 root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 Non-working system: FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC2 FreeBSD 8.0-RC2 #0 r198931: Wed Nov 4 20:56:16 EST 2009 root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 APs are is: SSID/MESH ID BSSID CHAN RATE S:N INT CAPS AP_SSID 00:1f:33:3b:xx:xx 3 54M -68:-96 100 EP RSN WPS WME AP_SSID 00:1f:90:cb:xx:xx 8 54M -73:-96 100 EPS RSN WPA ATH Relevant piece of wpa_supplicant.conf is: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel eapol_version=2 network={ ssid="AP_SSID" scan_ssid=1 priority=1 proto=WPA key_mgmt=WPA-PSK psk="Really secure something" } APs are set not to broadcast SSID, but enabling broadcast does not change much. Running wpa_supplicant with -d shows that it could not match AP_SSID. If there is anything else I can provide, please, let me know. -- Alexandre Kovalenko (????????? ?????????) From kamikaze at bsdforen.de Thu Nov 5 13:18:40 2009 From: kamikaze at bsdforen.de (Dominic Fandrey) Date: Thu Nov 5 13:18:47 2009 Subject: 8.0-RC2 mangles msdosfs In-Reply-To: <20091105061126.GA1839@baranyfelhocske.buza.adamsfamily.xx> References: <4AF1869D.6090304@bsdforen.de> <20091105061126.GA1839@baranyfelhocske.buza.adamsfamily.xx> Message-ID: <4AF2D0AA.2020809@bsdforen.de> Szilveszter Adam wrote: > Well, this is of course only anecdotal, but I do not witness corruption > with any of my USB-attached umass devices. A friend tried to reproduce my problem to no avail, so it appears to be a rare issue. But I also can produce the problems with with file system backed md devices, so it's not a USB issue. I've first run into it on RC1, so rebuilding is not a solution, either. > (I no longer have a floppy > drive, and I do not have a FAT partition on my HDD either, so I cannot > test that). I am using 9.0-CURRENT, rev 198667 (but the problem did not > show also on earlier revs) > > The devices that I use on and off: > > - Meizu M3 Music Card audio player > - Cowon iaudio D2 audio player (According to user forums, this one is > particularly sensitive to fs corruption) I'm using a Cowon S9. When I added a couple of new songs to the device, it complained about them to be corrupted (despite a proper umount). So I ran fsck_msdosfs, which found quite a number of problems and recopied the files. After turning the device back on I only got random coloured garbage on the screen, whenever I tried to access something. I booted Windows and chkdsk reported all these problems (cross-linked files and the like). But the player didn't recover until I reformatted the whole mess. > - various USB sticks, most notably a Kingston Data Traveller 4G (I > believe) > - Even the occasional memory stick, or SD card in card reader > > However, I must also state that I never used fsck_msdosfs in the last > few years. Neither have I formatted any FAT file systems under FreeBSD for > years. Also, I always unmount the devices before removing them. > So do I. This didn't safe me, though. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? From attilio at freebsd.org Thu Nov 5 13:52:06 2009 From: attilio at freebsd.org (Attilio Rao) Date: Thu Nov 5 13:52:12 2009 Subject: [PATCH] AMD Opteron Rev. E hack In-Reply-To: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> References: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> Message-ID: <3bbf2fe10911050552k3f9396feu8f4b9ed7a8dda81b@mail.gmail.com> 2009/11/5 Giovanni Trematerra : > Hi, > I have a quick and dirty patch to address the problem as discussed on > commit r198868 in svn-src-head@ > I introduced BROKEN_OPTERON_E kernel option for i386/amd64 arch. > The patch isn't tested yet, I only successfully compiled on i386. > Can you let me know if the patch is on the right direction to resolve the issue? > style(9) tips are welcomed. > diff -r 75d35d8e7fe1 sys/amd64/amd64/identcpu.c > --- a/sys/amd64/amd64/identcpu.c Thu Nov 05 11:18:35 2009 +0100 > +++ b/sys/amd64/amd64/identcpu.c Thu Nov 05 12:42:35 2009 +0100 > @@ -404,6 +404,10 @@ > > if (cpu_vendor_id == CPU_VENDOR_AMD) > print_AMD_info(); > +#if defined(BROKEN_OPTERON_E) > + else > + printf("BROKEN_OPTERON_E option in your kernel is useless with y > our CPU\n"); > +#endif > } > > void > @@ -620,10 +624,17 @@ > */ > if (CPUID_TO_FAMILY(cpu_id) == 0xf && CPUID_TO_MODEL(cpu_id) >= 0x20 && > CPUID_TO_MODEL(cpu_id) <= 0x3f) { > +#if !defined(BROKEN_OPTERON_E) > printf("WARNING: This architecture revision has known SMP " > "hardware bugs which may cause random instability\n"); > - printf("WARNING: For details see: " > - "http://bugzilla.kernel.org/show_bug.cgi?id=11305\n"); > +#else > + printf("WARNING: options BROKEN_OPTERON_E is in your kernel. " > + "Expect performance penalties\n"); > + else > + > + printf("WARNING: options BROKEN_OPTERON_E is useless with your C > PU." > + "Expect performance penalties\n"); > +#endif > } > } I would leave the whole logic within print_AMD_info() and not pollute external code and I would not print a string if the fix is in. > diff -r 75d35d8e7fe1 sys/amd64/include/atomic.h > --- a/sys/amd64/include/atomic.h Thu Nov 05 11:18:35 2009 +0100 > +++ b/sys/amd64/include/atomic.h Thu Nov 05 12:42:35 2009 +0100 > @@ -36,6 +36,14 @@ > #define wmb() __asm __volatile("sfence;" : : : "memory") > #define rmb() __asm __volatile("lfence;" : : : "memory") > > +#include "opt_cpu.h" > + > +#if defined(BROKEN_OPTERON_E) && (defined(SMP) || !defined(_KERNEL)) > + #define OPTERON_E_HACK() rmb() > +#else > + #define OPTERON_E_HACK() > +#endif > + > /* > * Various simple operations on memory, each of which is atomic in the > * presence of interrupts and multiple processors. > @@ -147,6 +155,8 @@ > "m" (*dst) /* 4 */ > : "memory"); > > + OPTERON_E_HACK(); > + > return (res); > } You need to override the whole barrier IMHO and not add this new stub. Attilio -- Peace can only be achieved by understanding - A. Einstein From attilio at freebsd.org Thu Nov 5 14:10:40 2009 From: attilio at freebsd.org (Attilio Rao) Date: Thu Nov 5 14:10:47 2009 Subject: [PATCH] AMD Opteron Rev. E hack In-Reply-To: <20091105124505.GT2331@deviant.kiev.zoral.com.ua> References: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> <20091105112834.GR2331@deviant.kiev.zoral.com.ua> <4e6cba830911050424y17ea8e7fmf5573b3a765eac27@mail.gmail.com> <20091105124505.GT2331@deviant.kiev.zoral.com.ua> Message-ID: <3bbf2fe10911050610p7d3bb0f4kb4446ea651aa7c93@mail.gmail.com> 2009/11/5 Kostik Belousov : > On Thu, Nov 05, 2009 at 01:24:53PM +0100, Giovanni Trematerra wrote: >> On Thu, Nov 5, 2009 at 12:28 PM, Kostik Belousov wrote: >> >> > >> > Aren't atomic_readandclear need the same workaround ? >> > >> >> I understood that the bug manifests itself only when lock instruction is used. >> atomic_readandclear doesn't use lock. > xchgl uses lock implicitely: > > If a memory operand is referenced, the processor's locking protocol is > automatically implemented for the duration of the exchange operation, > regardless of the presence or absence of the LOCK prefix or of the value > of the IOPL. > >> I think i386/linux/linux_support.s and amd64/linux32/linux32_support.s >> need the work-around too. > What about casuword32 ? > It is actually unclear from the bug description whether we need it there. > Description states "a locked instruction doesn't act as a read-acquire > barrier if followed by a non-locked read-modify-write instruction." > > casuword32 for amd64, for instance, does movq immediately after > cmpxchgl, that is a store op, not read-modify-store. So, does it need a > workaround ? Similar stores are performed in linux32_support.s. > > atomic.h functions definitely need your workaround since they are inlined. > > Also, I remember that bind(8) provides its own atomic implementation. However, that fix is not simple to got as one would think. Our atomics implementation on ia32 and amd64 assume rel/acq barriers aims for the same code but this problem introduces asymmetric behaviour between them. The good way to fix this is to offer an lfence on acq barriers and leave the other cases untouched, but this could be meaning re-structure out atomic.h a lot. I will try to think to a good way to do that when I have more available time. In the while the WARNING msg will do its job (I can still trimm the URL path however). Attilio -- Peace can only be achieved by understanding - A. Einstein From kostikbel at gmail.com Thu Nov 5 14:21:51 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Nov 5 14:21:57 2009 Subject: [PATCH] AMD Opteron Rev. E hack In-Reply-To: <3bbf2fe10911050610p7d3bb0f4kb4446ea651aa7c93@mail.gmail.com> References: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> <20091105112834.GR2331@deviant.kiev.zoral.com.ua> <4e6cba830911050424y17ea8e7fmf5573b3a765eac27@mail.gmail.com> <20091105124505.GT2331@deviant.kiev.zoral.com.ua> <3bbf2fe10911050610p7d3bb0f4kb4446ea651aa7c93@mail.gmail.com> Message-ID: <20091105142142.GV2331@deviant.kiev.zoral.com.ua> On Thu, Nov 05, 2009 at 03:10:38PM +0100, Attilio Rao wrote: > The good way to fix this is to offer an lfence on acq barriers and > leave the other cases untouched, but this could be meaning > re-structure out atomic.h a lot. I will try to think to a good way to > do that when I have more available time. > In the while the WARNING msg will do its job (I can still trimm the > URL path however). For 8.0, please strip URL at least. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091105/93174708/attachment.pgp From onemda at gmail.com Thu Nov 5 14:25:01 2009 From: onemda at gmail.com (Paul B Mahol) Date: Thu Nov 5 14:25:11 2009 Subject: After sys/net80211 changes in r198931 laptop is no longer associating with AP In-Reply-To: <1257426023.1436.18.camel@RabbitsDen> References: <1257426023.1436.18.camel@RabbitsDen> Message-ID: <3a142e750911050624q41a22ed5ud4f6919a2fac686e@mail.gmail.com> On 11/5/09, Alexandre "Sunny" Kovalenko wrote: > It seems that 8.0 discussion is still going on on @current... if I > should have posted this on @stable, please, feel free to chastise me as > appropriate. > > After updating to r198831 my laptop no longer associates with either of > two APs I have. Rolling back just 'sys/net80211' to r198443 fixes the > problem. > > Working system: > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC1 FreeBSD 8.0-RC1 #0 > r198443M: Sat Oct 24 14:03:30 EDT 2009 > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 > > Non-working system: > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC2 FreeBSD 8.0-RC2 #0 > r198931: Wed Nov 4 20:56:16 EST 2009 > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 > > APs are is: > SSID/MESH ID BSSID CHAN RATE S:N INT CAPS > AP_SSID 00:1f:33:3b:xx:xx 3 54M -68:-96 100 EP RSN WPS > WME > AP_SSID 00:1f:90:cb:xx:xx 8 54M -73:-96 100 EPS RSN WPA > ATH > > Relevant piece of wpa_supplicant.conf is: > > ctrl_interface=/var/run/wpa_supplicant > ctrl_interface_group=wheel > eapol_version=2 > > network={ > ssid="AP_SSID" > scan_ssid=1 > priority=1 > proto=WPA > key_mgmt=WPA-PSK > psk="Really secure something" > } > > APs are set not to broadcast SSID, but enabling broadcast does not > change much. > > Running wpa_supplicant with -d shows that it could not match AP_SSID. > > If there is anything else I can provide, please, let me know. What driver are you using? Looking into net80211 svn log for that time period I only see mesh hacks ... From gallasch at free.de Thu Nov 5 15:21:22 2009 From: gallasch at free.de (Kai Gallasch) Date: Thu Nov 5 15:21:29 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <1257244960.98619.36.camel@buffy.york.ac.uk> References: <20091031231545.493cee89@boiler.free.de> <1257244960.98619.36.camel@buffy.york.ac.uk> Message-ID: <20091105162118.1a5d8fa5@orwell.free.de> Am Tue, 03 Nov 2009 10:42:40 +0000 schrieb Gavin Atkinson : > On Sat, 2009-10-31 at 23:15 +0100, Kai Gallasch wrote: > > Hi. > > > > I installed 8.0RC2-amd64 on an 8-core opteron server a few days ago. > > > > When I try to do a make buildworld or make buildkernel the server > > reboots without any message left in the logs. The same happens > > when building bigger ports (for example ruby18 or perl58) > > > > With 8.0-RC2 debug flags and witness seem to be disabled in the > > standard GENERIC kernel, so unfortunately it is not possible for me > > to build a debug kernel without my server crashing.. > > First place I think I'd start id by running memtest86 on the machine > overnight. This sounds like possible hardware issue to me, it would > be good to see if we can confirm that that is the case. Gavin. memtest86 ran for 18 hours and showed no problem with RAM. --Kai. From rmacklem at uoguelph.ca Thu Nov 5 16:29:00 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Thu Nov 5 16:29:09 2009 Subject: Help needed: TCP Wizards (was 8.0-RC1 NFS client timeout issue) In-Reply-To: <4AF0B7DF.9030405@freebsd.org> References: <4AF0B7DF.9030405@freebsd.org> Message-ID: Rick Macklem wrote: > I can now reproduce what I think others were seeing as slow reconnects > when using NFSv3 over TCP against a server that disconnects inactive > TCP connections. I have had some luck figuring out what is going on > and can reproduce it fairly easily, but I really need help from someone > who understands the FreeBSD TCP stack. > Ok, I haven't made much progress on this, but here's what little I currently know about it. The problem occurs after a server has dropped an inactive TCP connection for an NFS over TCP mount (in my case a Solaris10 server). When the client does a new connection it, for some reason, sends a RST at almost exactly the same time as the first RPC request on the new TCP connection, causing the server to shut it down. Ok, things I now know don't affect this are: - doing the soshutdown(), soclose() on the old connection. I commented them out and it still happened. - Avoiding the sobind() on the new connection, done before the soconnect(). - Using a non-reserved port#. (The above tests shot down pretty well all the "theories" I could come up with.) The only thing I've found that avoids the problem: - putting a 2sec delay right before the soconnect() call. (A 1sec delay made it hard to reproduce and I've never reproduced it yet with a 2sec delay.) Not much of a fix, though. Now, here's where someone may be able to help? Grep'ng around, I found 4 places where the TCP stack called ip_output() (one in each of tcp_output.c, tcp_subr.c, tcp_timewait.c and tcp_syncache.c) and I put a printf like this just before them: if (flags & TH_RST) printf("sent a reset\n"); (The exact format varies for each, because of where the TCP header flags are and have different printf messages.) Now, the weird part is, that when the extraneous RST is sent to the server, I don't get any printf. (I do get a few of these, but at other times for what appear to be legitimate RSTs.) I can't see anywhere else that the TCP stack would send an RST and, so, I'm stuck w.r.t. figuring out what is sending them? Anyone know of another place the TCP stack would make the send happen? (Or is it queued earlier when I see the printf message, and then the send is "triggered" inside the ip layer when the first data is sent on the new connection?) rick, who is getting sick of looking at this:-) From giovanni.trematerra at gmail.com Thu Nov 5 16:35:18 2009 From: giovanni.trematerra at gmail.com (Giovanni Trematerra) Date: Thu Nov 5 16:35:24 2009 Subject: [PATCH] AMD Opteron Rev. E hack In-Reply-To: <3bbf2fe10911050610p7d3bb0f4kb4446ea651aa7c93@mail.gmail.com> References: <4e6cba830911050302k56bed35aj5ca9fa16379ab325@mail.gmail.com> <20091105112834.GR2331@deviant.kiev.zoral.com.ua> <4e6cba830911050424y17ea8e7fmf5573b3a765eac27@mail.gmail.com> <20091105124505.GT2331@deviant.kiev.zoral.com.ua> <3bbf2fe10911050610p7d3bb0f4kb4446ea651aa7c93@mail.gmail.com> Message-ID: <4e6cba830911050835uc04023ds91fef552788dfe73@mail.gmail.com> On Thu, Nov 5, 2009 at 3:10 PM, Attilio Rao wrote: > > The good way to fix this is to offer an lfence on acq barriers and > leave the other cases untouched, but this could be meaning > re-structure out atomic.h a lot. I will try to think to a good way to > do that when I have more available time. > In the while the WARNING msg will do its job (I can still trimm the > URL path however). > Well, That's not so easy to fix as I thought. Thanks Attilio to point me out. -- Gianni From serguey-grigoriev at yandex.ru Thu Nov 5 16:40:06 2009 From: serguey-grigoriev at yandex.ru (S.N.Grigoriev) Date: Thu Nov 5 16:40:21 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld Message-ID: <1031257439203@webmail57.yandex.ru> 04.11.09, 16:51, "Alexandre \"Sunny\" Kovalenko" wrote: > On Wed, 2009-11-04 at 13:44 +0300, S.N.Grigoriev wrote: > > Hi list, > > > > I can confirm I've seen the same problem. After upgrading from 7-stable > > to 8.0-RC2 my machine just reboots during 'make buildworld' without > > diagnostics. But switching vm.pmap.pg_ps_enabled on/off does not > > work for me. My machine reboots every time I try to build world. > > I don't think I have a hardware problem: under 7-stable I can build > > world/kernel for both 7-stable and 8.0-RC2 without problems. > > > Is it by any chance possible that you have 'debug.debugger_on_panic' set > to '0' and no valid dump device configured? Hi Alexandre, I've not found 'debug.debugger_on_panic' variable in 'sysctl -a' output. Where cat I find it? All my sysctl variables are set by default. -- Regards, S.Grigoriev. From uqs at spoerlein.net Thu Nov 5 16:58:56 2009 From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Thu Nov 5 16:59:05 2009 Subject: 8.0-RC2 mangles msdosfs In-Reply-To: <20091104154044.GA96964@wep4035.physik.uni-wuerzburg.de> References: <4AF1869D.6090304@bsdforen.de> <20091104154044.GA96964@wep4035.physik.uni-wuerzburg.de> Message-ID: <20091105165842.GC34407@acme.spoerlein.net> On Wed, 04.11.2009 at 16:40:44 +0100, Alexey Shuvaev wrote: > On Wed, Nov 04, 2009 at 02:50:21PM +0100, Dominic Fandrey wrote: > > Alexander Best wrote: > > > Paul G Webster schrieb am 2009-11-03: > > > *lol* just tried this myself and my fdisk output looks just as bad as yours: > > > > I think funny fdisk output is not that much of a problem. > > > > [snip] > > > > What I wonder is - are there more people who witness file > > system corruption upon msdosfs writes (and don't forget > > that either newfs_msdos or fsck_msdosfs is broken as well, > > and that fsck_msdosfs certainly does not recognize > > cross-linked files). The impact is so horrid that I had > > to reformat my portable player (with Windows) and reinstall > > the firmware to get it back going. > > > The relative silence on the mailing list seems to show it is not > the common problem... Indeed, on my main desktop, running 8.0something I regularly copy MP3/OGG files to a FAT16 (!) MP3-Player and albeit the copying is slow and produces "funny" dmesg output, I have yet to observe a corruption of the FS. Bye, Uli From fjwcash at gmail.com Thu Nov 5 17:21:29 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Thu Nov 5 17:21:36 2009 Subject: What is the state of ZFS on FreeBSD? In-Reply-To: <11167f520911050019k17137f3q6e36614e2178b12d@mail.gmail.com> References: <17E3C299-725B-434E-805D-CA0C1EA9C8B9@via.net> <9e20d71e0911042247n216e9b02t7b317a55a9bbe131@mail.gmail.com> <11167f520911050019k17137f3q6e36614e2178b12d@mail.gmail.com> Message-ID: On Thu, Nov 5, 2009 at 12:19 AM, Sam Fourman Jr. wrote: > On Thu, Nov 5, 2009 at 12:47 AM, Artis Caune wrote: >> 2009/11/5 joe mcguckin : >>> I'm interested inb putting together a file server with lots of disk. >>> >>> What's the state of ZFS? Is it ready for production use? > > We are using it in production and have a 6TB RAIDZ on FreeBSD8 RC2 amd64 > we are quite happy with the FreeBSD 8 setup. > we tried it on FreeBSD 7.2 i386 and did not like it (we got a few panics) > > the only trouble we really had on FreeBSD8 is the sharenfs manpages > are not updated. so we are using the classic /etc/exports instead of the zfs option. The syntax is the same. Anything you can put into /etc/exports you can put into the sharenfs property. In fact, behind the scenes, the sharenfs property is just copied into a private exports file, and the nfs daemon uses that in addition to /etc/exports. The man pages for ZFS are just dumps of the Solaris ones, so a lot of the info is not quite right for a FreeBSD system. -- Freddie Cash fjwcash@gmail.com From atkin901 at yahoo.com Thu Nov 5 17:43:26 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Thu Nov 5 17:43:34 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: References: <20091031231545.493cee89@boiler.free.de> <867hu6gvou.fsf@ds4.des.no> <20091104163621.36943807@orwell.free.de> Message-ID: Adrian Chadd wrote: > 2009/11/5 Mark Atkinson : > >> I'll answer my own question, no: >> >> http://support.amd.com/us/Processor_TechDocs/25481.pdf >> >> Although the some of the posts in >> >> http://bugzilla.kernel.org/show_bug.cgi?id=11305 >> >> indicate any model < 0x40. Someone must have actually narrowed the range. > > Is there a FreeBSD PR or errata URL which can be linked to instead, > complete with copies of the above in it? If you read the mysql related blog post on it: http://timetobleed.com/mysql-doesnt-always-suck-this-time-its-amd/ Someone in the comments suggests this is AMD errata 147 and quotes the text. I'll include a copy of the comment here below for the mail archives (and since urls tend to disappear). # silverjam The kernel bug: http://bugzilla.kernel.org/show_bug.cgi?id=11305 Which references an AMD "errata 147" from "Revision Guide for AMD Athlon? 64 and AMD Opteron? Processors." http://support.amd.com/us/Processor_TechDocs/25759.pdf Which says: """ Potential Violation of Read Ordering Rules Between Semaphore Operations and Unlocked Read-Modify-Write Instructions Description Under a highly specific set of internal timing circumstances, the memory read ordering between a semaphore operation and a subsequent read-modify-write instruction (an instruction that uses the same memory location as both a source and destination) may be incorrect and allow the read-modifywrite instruction to operate on the memory location ahead of the completion of the semaphore operation. The erratum will not occur if there is a LOCK prefix on the read-modify-write instruction. This erratum does not apply if the read-only value in MSRC001_1023h[33] is 1b. Potential Effect on System In the unlikely event that the condition described above occurs, the read-modify-write instruction (in the critical section) may operate on data that existed prior to the semaphore operation. This erratum can only occur in multiprocessor or multicore configurations. Suggested Workaround To provide a workaround for this unlikely event, software can perform any of the following actions for multiprocessor or multicore systems: ? Place a LFENCE instruction between the semaphore operation and any subsequent read-modifywrite instruction(s) in the critical section. ? Use a LOCK prefix with the read-modify-write instruction. ? Decompose the read-modify-write instruction into separate instructions. No workaround is necessary if software checks that MSRC001_1023h[33] is set on all processors that may execute the code. The value in MSRC001_1023h[33] may not be the same on all processors in a multi-processor system. Fix Planned: Yes """ From gary.jennejohn at freenet.de Thu Nov 5 17:49:28 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Thu Nov 5 17:49:35 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <1031257439203@webmail57.yandex.ru> References: <1031257439203@webmail57.yandex.ru> Message-ID: <20091105184925.16b55c43@ernst.jennejohn.org> On Thu, 05 Nov 2009 19:40:03 +0300 S.N.Grigoriev wrote: > > 04.11.09, 16:51, "Alexandre \"Sunny\" Kovalenko" > wrote: > > > On Wed, 2009-11-04 at 13:44 +0300, S.N.Grigoriev wrote: > > > Hi list, > > > > > > I can confirm I've seen the same problem. After upgrading from 7-stable > > > to 8.0-RC2 my machine just reboots during 'make buildworld' without > > > diagnostics. But switching vm.pmap.pg_ps_enabled on/off does not > > > work for me. My machine reboots every time I try to build world. > > > I don't think I have a hardware problem: under 7-stable I can build > > > world/kernel for both 7-stable and 8.0-RC2 without problems. > > > > > Is it by any chance possible that you have 'debug.debugger_on_panic' set > > to '0' and no valid dump device configured? > > Hi Alexandre, > > I've not found 'debug.debugger_on_panic' variable in 'sysctl -a' > output. Where cat I find it? All my sysctl variables are set by > default. Do you have "options DDB" in your kernel config file? --- Gary Jennejohn From serguey-grigoriev at yandex.ru Thu Nov 5 18:34:26 2009 From: serguey-grigoriev at yandex.ru (S.N.Grigoriev) Date: Thu Nov 5 18:34:56 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091105184925.16b55c43@ernst.jennejohn.org> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> Message-ID: <31221257446063@webmail71.yandex.ru> 05.11.09, 18:49, "Gary Jennejohn" : > On Thu, 05 Nov 2009 19:40:03 +0300 > S.N.Grigoriev wrote: > > > > 04.11.09, 16:51, "Alexandre \"Sunny\" Kovalenko" > > wrote: > > > > > On Wed, 2009-11-04 at 13:44 +0300, S.N.Grigoriev wrote: > > > > Hi list, > > > > > > > > I can confirm I've seen the same problem. After upgrading from 7-stable > > > > to 8.0-RC2 my machine just reboots during 'make buildworld' without > > > > diagnostics. But switching vm.pmap.pg_ps_enabled on/off does not > > > > work for me. My machine reboots every time I try to build world. > > > > I don't think I have a hardware problem: under 7-stable I can build > > > > world/kernel for both 7-stable and 8.0-RC2 without problems. > > > > > > > Is it by any chance possible that you have 'debug.debugger_on_panic' set > > > to '0' and no valid dump device configured? > > > > Hi Alexandre, > > > > I've not found 'debug.debugger_on_panic' variable in 'sysctl -a' > > output. Where cat I find it? All my sysctl variables are set by > > default. > Do you have "options DDB" in your kernel config file? > --- > Gary Jennejohn Hi Gary, my current kernel is GENERIC, so I don't have "options DDB". -- Regards, S.Grigoriev. From gaijin.k at gmail.com Thu Nov 5 19:01:41 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Thu Nov 5 19:01:47 2009 Subject: After sys/net80211 changes in r198931 laptop is no longer associating with AP In-Reply-To: <3a142e750911050624q41a22ed5ud4f6919a2fac686e@mail.gmail.com> References: <1257426023.1436.18.camel@RabbitsDen> <3a142e750911050624q41a22ed5ud4f6919a2fac686e@mail.gmail.com> Message-ID: On Thu, Nov 5, 2009 at 9:24 AM, Paul B Mahol wrote: > On 11/5/09, Alexandre "Sunny" Kovalenko wrote: > > It seems that 8.0 discussion is still going on on @current... if I > > should have posted this on @stable, please, feel free to chastise me as > > appropriate. > > > > After updating to r198831 my laptop no longer associates with either of > > two APs I have. Rolling back just 'sys/net80211' to r198443 fixes the > > problem. > > > > Working system: > > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC1 FreeBSD 8.0-RC1 #0 > > r198443M: Sat Oct 24 14:03:30 EDT 2009 > > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 > > > > Non-working system: > > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC2 FreeBSD 8.0-RC2 #0 > > r198931: Wed Nov 4 20:56:16 EST 2009 > > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 > > > > APs are is: > > SSID/MESH ID BSSID CHAN RATE S:N INT CAPS > > AP_SSID 00:1f:33:3b:xx:xx 3 54M -68:-96 100 EP RSN WPS > > WME > > AP_SSID 00:1f:90:cb:xx:xx 8 54M -73:-96 100 EPS RSN WPA > > ATH > > > > Relevant piece of wpa_supplicant.conf is: > > > > ctrl_interface=/var/run/wpa_supplicant > > ctrl_interface_group=wheel > > eapol_version=2 > > > > network={ > > ssid="AP_SSID" > > scan_ssid=1 > > priority=1 > > proto=WPA > > key_mgmt=WPA-PSK > > psk="Really secure something" > > } > > > > APs are set not to broadcast SSID, but enabling broadcast does not > > change much. > > > > Running wpa_supplicant with -d shows that it could not match AP_SSID. > > > > If there is anything else I can provide, please, let me know. > > What driver are you using? > Looking into net80211 svn log for that time period I only see mesh hacks > ... > I am using ath (I am away from my laptop ATM -- I could provide part number later today). I have seen mesh changes in there and that's when I gave up and posted -- I am not nearly enough qualified to figure out which ones could or could not impact normal operation. -- Alexandre "Sunny" Kovalenko. From serguey-grigoriev at yandex.ru Thu Nov 5 19:08:19 2009 From: serguey-grigoriev at yandex.ru (S.N.Grigoriev) Date: Thu Nov 5 19:08:31 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <4AF31D87.9000207@gmail.com> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <4AF31D87.9000207@gmail.com> Message-ID: <40521257448093@webmail75.yandex.ru> 05.11.09, 13:46, "Etienne Robillard" : > S.N.Grigoriev wrote: > > > > 05.11.09, 18:49, "Gary Jennejohn" : > > > >> On Thu, 05 Nov 2009 19:40:03 +0300 > >> S.N.Grigoriev wrote: > >>> 04.11.09, 16:51, "Alexandre \"Sunny\" Kovalenko" > >>> wrote: > >>> > >>>> On Wed, 2009-11-04 at 13:44 +0300, S.N.Grigoriev wrote: > >>>>> Hi list, > >>>>> > >>>>> I can confirm I've seen the same problem. After upgrading from 7-stable > >>>>> to 8.0-RC2 my machine just reboots during 'make buildworld' without > >>>>> diagnostics. But switching vm.pmap.pg_ps_enabled on/off does not > >>>>> work for me. My machine reboots every time I try to build world. > >>>>> I don't think I have a hardware problem: under 7-stable I can build > >>>>> world/kernel for both 7-stable and 8.0-RC2 without problems. > >>>>> > >>>> Is it by any chance possible that you have 'debug.debugger_on_panic' set > >>>> to '0' and no valid dump device configured? > >>> Hi Alexandre, > >>> > >>> I've not found 'debug.debugger_on_panic' variable in 'sysctl -a' > >>> output. Where cat I find it? All my sysctl variables are set by > >>> default. > >> Do you have "options DDB" in your kernel config file? > >> --- > >> Gary Jennejohn > > > > Hi Gary, > > > > my current kernel is GENERIC, so I don't have "options DDB". > I have RC2 with amd64 and buildworld/installworld runs fine. > Maybe you memory (ram) problems ? I had to remove one 512mb clib > in order to boot... ;-) > Hope this helps, > Etienne Hi Etienne, I think it is unlikely. I've done on this machine (under FreeBSD 7.1 and 7.2 and some Linux versions) very much compilations without issues. -- Regards, S.Grigoriev. From robillard.etienne at gmail.com Thu Nov 5 19:45:02 2009 From: robillard.etienne at gmail.com (Etienne Robillard) Date: Thu Nov 5 19:45:09 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <31221257446063@webmail71.yandex.ru> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> Message-ID: <4AF31D87.9000207@gmail.com> S.N.Grigoriev wrote: > > 05.11.09, 18:49, "Gary Jennejohn" : > >> On Thu, 05 Nov 2009 19:40:03 +0300 >> S.N.Grigoriev wrote: >>> 04.11.09, 16:51, "Alexandre \"Sunny\" Kovalenko" >>> wrote: >>> >>>> On Wed, 2009-11-04 at 13:44 +0300, S.N.Grigoriev wrote: >>>>> Hi list, >>>>> >>>>> I can confirm I've seen the same problem. After upgrading from 7-stable >>>>> to 8.0-RC2 my machine just reboots during 'make buildworld' without >>>>> diagnostics. But switching vm.pmap.pg_ps_enabled on/off does not >>>>> work for me. My machine reboots every time I try to build world. >>>>> I don't think I have a hardware problem: under 7-stable I can build >>>>> world/kernel for both 7-stable and 8.0-RC2 without problems. >>>>> >>>> Is it by any chance possible that you have 'debug.debugger_on_panic' set >>>> to '0' and no valid dump device configured? >>> Hi Alexandre, >>> >>> I've not found 'debug.debugger_on_panic' variable in 'sysctl -a' >>> output. Where cat I find it? All my sysctl variables are set by >>> default. >> Do you have "options DDB" in your kernel config file? >> --- >> Gary Jennejohn > > Hi Gary, > > my current kernel is GENERIC, so I don't have "options DDB". I have RC2 with amd64 and buildworld/installworld runs fine. Maybe you memory (ram) problems ? I had to remove one 512mb clib in order to boot... ;-) Hope this helps, Etienne -- Etienne Robillard Green Tea Hackers Club Blog: PGP Fingerprint: 178A BF04 23F0 2BF5 535D 4A57 FD53 FD31 98DC 4E57 From kraduk at googlemail.com Thu Nov 5 23:17:24 2009 From: kraduk at googlemail.com (krad) Date: Thu Nov 5 23:17:31 2009 Subject: What is the state of ZFS on FreeBSD? In-Reply-To: References: <17E3C299-725B-434E-805D-CA0C1EA9C8B9@via.net> <9e20d71e0911042247n216e9b02t7b317a55a9bbe131@mail.gmail.com> <11167f520911050019k17137f3q6e36614e2178b12d@mail.gmail.com> Message-ID: 2009/11/5 Freddie Cash > On Thu, Nov 5, 2009 at 12:19 AM, Sam Fourman Jr. > wrote: > > On Thu, Nov 5, 2009 at 12:47 AM, Artis Caune > wrote: > >> 2009/11/5 joe mcguckin : > >>> I'm interested inb putting together a file server with lots of disk. > >>> > >>> What's the state of ZFS? Is it ready for production use? > > > > We are using it in production and have a 6TB RAIDZ on FreeBSD8 RC2 amd64 > > we are quite happy with the FreeBSD 8 setup. > > we tried it on FreeBSD 7.2 i386 and did not like it (we got a few panics) > > > > the only trouble we really had on FreeBSD8 is the sharenfs manpages > > are not updated. so we are using the classic /etc/exports instead of the > zfs option. > > The syntax is the same. Anything you can put into /etc/exports you > can put into the sharenfs property. In fact, behind the scenes, the > sharenfs property is just copied into a private exports file, and the > nfs daemon uses that in addition to /etc/exports. > > The man pages for ZFS are just dumps of the Solaris ones, so a lot of > the info is not quite right for a FreeBSD system. > > -- > Freddie Cash > fjwcash@gmail.com > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > unless im missing something you have to do it the legacy way (root@carrera)-(23:13:05)-(~) 0 $ zfs set sharenfs=yes zdump/web (root@carrera)-(23:13:23)-(~) 0 $ showmount -e 127.0.0.1 Exports list on 127.0.0.1: /videos Everyone (root@carrera)-(23:13:26)-(~) 0 $ From fjwcash at gmail.com Thu Nov 5 23:33:26 2009 From: fjwcash at gmail.com (Freddie Cash) Date: Thu Nov 5 23:33:33 2009 Subject: What is the state of ZFS on FreeBSD? In-Reply-To: References: <17E3C299-725B-434E-805D-CA0C1EA9C8B9@via.net> <9e20d71e0911042247n216e9b02t7b317a55a9bbe131@mail.gmail.com> <11167f520911050019k17137f3q6e36614e2178b12d@mail.gmail.com> Message-ID: On Thu, Nov 5, 2009 at 3:17 PM, krad wrote: > 2009/11/5 Freddie Cash >> The syntax is the same. Anything you can put into /etc/exports you >> can put into the sharenfs property. In fact, behind the scenes, the >> sharenfs property is just copied into a private exports file, and the >> nfs daemon uses that in addition to /etc/exports. >> >> The man pages for ZFS are just dumps of the Solaris ones, so a lot of >> the info is not quite right for a FreeBSD system. > > unless im missing something you have to do it the legacy way > > (root@carrera)-(23:13:05)-(~) 0 > $ zfs set sharenfs=yes zdump/web > (root@carrera)-(23:13:23)-(~) 0 > $ showmount -e 127.0.0.1 > Exports list on 127.0.0.1: > /videos Everyone > (root@carrera)-(23:13:26)-(~) 0 > $ Put the settings you would normally put into /etc/exports into the sharenfs property: [fcash@megadrive ~]$ zfs get sharenfs storage/backup NAME PROPERTY VALUE SOURCE storage/backup sharenfs -maproot=root 192.168.0.12 local [fcash@megadrive ~]$ showmount -e Exports list on localhost: /storage/backup 192.168.0.12 -- Freddie Cash fjwcash@gmail.com From rpaulo at FreeBSD.org Thu Nov 5 23:49:13 2009 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Thu Nov 5 23:49:19 2009 Subject: Help needed: TCP Wizards (was 8.0-RC1 NFS client timeout issue) In-Reply-To: References: <4AF0B7DF.9030405@freebsd.org> Message-ID: <030A8229-9707-4F70-B4BE-584F1BF9ECEC@FreeBSD.org> On 5 Nov 2009, at 16:36, Rick Macklem wrote: > > > Rick Macklem wrote: >> I can now reproduce what I think others were seeing as slow >> reconnects >> when using NFSv3 over TCP against a server that disconnects inactive >> TCP connections. I have had some luck figuring out what is going on >> and can reproduce it fairly easily, but I really need help from >> someone >> who understands the FreeBSD TCP stack. >> > Ok, I haven't made much progress on this, but here's what little I > currently know about it. > > The problem occurs after a server has dropped an inactive TCP > connection > for an NFS over TCP mount (in my case a Solaris10 server). When the > client > does a new connection it, for some reason, sends a RST at almost > exactly > the same time as the first RPC request on the new TCP connection, > causing > the server to shut it down. > > Ok, things I now know don't affect this are: > - doing the soshutdown(), soclose() on the old connection. I commented > them out and it still happened. > - Avoiding the sobind() on the new connection, done before the > soconnect(). > - Using a non-reserved port#. > (The above tests shot down pretty well all the "theories" I could > come up > with.) > > The only thing I've found that avoids the problem: > - putting a 2sec delay right before the soconnect() call. (A 1sec > delay > made it hard to reproduce and I've never reproduced it yet with a > 2sec > delay.) > Not much of a fix, though. > > Now, here's where someone may be able to help? > > Grep'ng around, I found 4 places where the TCP stack called ip_output > () > (one in each of tcp_output.c, tcp_subr.c, tcp_timewait.c and > tcp_syncache.c) and I put a printf like this just before them: > if (flags & TH_RST) > printf("sent a reset\n"); > > (The exact format varies for each, because of where the TCP > header flags are and have different printf messages.) > > Now, the weird part is, that when the extraneous RST is sent to the > server, I don't get any printf. (I do get a few of these, but at other > times for what appear to be legitimate RSTs.) > > I can't see anywhere else that the TCP stack would send an RST and, > so, > I'm stuck w.r.t. figuring out what is sending them? > > Anyone know of another place the TCP stack would make the send happen? > (Or is it queued earlier when I see the printf message, and then the > send is "triggered" inside the ip layer when the first data is sent on > the new connection?) Are you running TSO? -- Rui Paulo From rpaulo at FreeBSD.org Fri Nov 6 00:40:13 2009 From: rpaulo at FreeBSD.org (Rui Paulo) Date: Fri Nov 6 00:40:20 2009 Subject: Help needed: TCP Wizards (was 8.0-RC1 NFS client timeout issue) In-Reply-To: References: <4AF0B7DF.9030405@freebsd.org> Message-ID: <912FE42D-F2A2-422B-8681-AE27CA428DD5@FreeBSD.org> On 5 Nov 2009, at 16:36, Rick Macklem wrote: > Rick Macklem wrote: >> I can now reproduce what I think others were seeing as slow >> reconnects >> when using NFSv3 over TCP against a server that disconnects inactive >> TCP connections. I have had some luck figuring out what is going on >> and can reproduce it fairly easily, but I really need help from >> someone >> who understands the FreeBSD TCP stack. >> > Ok, I haven't made much progress on this, but here's what little I > currently know about it. > > The problem occurs after a server has dropped an inactive TCP > connection > for an NFS over TCP mount (in my case a Solaris10 server). When the > client > does a new connection it, for some reason, sends a RST at almost > exactly > the same time as the first RPC request on the new TCP connection, > causing > the server to shut it down. > > Ok, things I now know don't affect this are: > - doing the soshutdown(), soclose() on the old connection. I commented > them out and it still happened. > - Avoiding the sobind() on the new connection, done before the > soconnect(). > - Using a non-reserved port#. > (The above tests shot down pretty well all the "theories" I could > come up > with.) > > The only thing I've found that avoids the problem: > - putting a 2sec delay right before the soconnect() call. (A 1sec > delay > made it hard to reproduce and I've never reproduced it yet with a 2sec > delay.) > Not much of a fix, though. > > Now, here's where someone may be able to help? > > Grep'ng around, I found 4 places where the TCP stack called ip_output > () > (one in each of tcp_output.c, tcp_subr.c, tcp_timewait.c and > tcp_syncache.c) and I put a printf like this just before them: > if (flags & TH_RST) > printf("sent a reset\n"); > > (The exact format varies for each, because of where the TCP > header flags are and have different printf messages.) > > Now, the weird part is, that when the extraneous RST is sent to the > server, I don't get any printf. (I do get a few of these, but at other > times for what appear to be legitimate RSTs.) > > I can't see anywhere else that the TCP stack would send an RST and, > so, > I'm stuck w.r.t. figuring out what is sending them? > > Anyone know of another place the TCP stack would make the send happen? > (Or is it queued earlier when I see the printf message, and then the > send is "triggered" inside the ip layer when the first data is sent on > the new connection?) > > rick, who is getting sick of looking at this:-) One option would be trying to calling ddb on top of ip_output() and checking the backtrace. -- Rui Paulo From bland at bbnest.net Fri Nov 6 04:52:55 2009 From: bland at bbnest.net (Alexander Nedotsukov) Date: Fri Nov 6 05:00:26 2009 Subject: umass problem. In-Reply-To: <202969100caf7f0bb8098572b0dad622@mail> References: <202969100caf7f0bb8098572b0dad622@mail> Message-ID: <20d8e6193795d83f9ffa30ab94bf86eb@mail> Well I do. This is a regression in EHCI driver introduced along the new usb stack. Please review patch attached. Thanks, Alexander. On Tue, 20 Oct 2009 10:53:36 +0900, Alexander Nedotsukov wrote: > Hi, > > I can reproduce this reliably with simple dd if=/dev/da0. At the end > external USB drive turns off the lights (tough it still spinning) and > system fall into the state where it is impossible to reboot it cleanly. I > can get drive back only after full power cycle (simple reboot is not > enough). Using same drive under moderate load seems mostly to work. It also > is used to work under 7.2. > > Anyone have an idea what this could be? -------------- next part -------------- A non-text attachment was scrubbed... Name: ehci-lostintr.patch Type: application/octet-stream Size: 3602 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091106/6f23d928/ehci-lostintr.obj From ianf at clue.co.za Fri Nov 6 08:40:27 2009 From: ianf at clue.co.za (Ian FREISLICH) Date: Fri Nov 6 08:40:37 2009 Subject: FreeBSD 8.0 - network stack crashes? In-Reply-To: References: <1257185816.44755.29.camel@buffy.york.ac.uk> <1257261214.98619.92.camel@buffy.york.ac.uk> Message-ID: Weldon S Godfrey 3 wrote: > >> OK, at least we've figured out what is going wrong then. As a > >> workaround to get the machine to stay up longer, you should be able to > >> set kern.ipc.nmbclusters=256000 in /boot/loader.conf -but hopefully we > >> can resolve this soon. > >> > > I upped it to 256K. What I am trying to wrap my head around is how it was > working somewhat for so long at 24K, but it got to near 65K before I > rebooted it with the higher setting. Or did I reboot too early? Is > there any cleanup that isn't triggered intil it reaches max nmbclusters? > I am trying to see if anything on our network has changed to cause this to > become cronic. We have a ngaios server which handles up to 5000 concurrent nsca daemons and connections which manifested a similar problem on a Dell R905 (4x4core AMD, 16GB RAM, bce). Setting the following in /boot/loader.conf sorted out the problem for us: kern.ipc.nmbclusters="131072" kern.maxusers="1024" mbuf usage is pretty static at: $ netstat -m 40165/16220/56385 mbufs in use (current/cache/total) 40154/10500/50654/131072 mbuf clusters in use (current/cache/total/max) 40154/3359 mbuf+clusters out of packet secondary zone in use (current/cache) 0/1493/1493/65536 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/32768 9k jumbo clusters in use (current/cache/total/max) 0/0/0/16384 16k jumbo clusters in use (current/cache/total/max) 90349K/31027K/121376K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 246 requests for I/O initiated by sendfile 0 calls to protocol drain routines Ian -- Ian Freislich From hselasky at c2i.net Fri Nov 6 08:49:43 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Nov 6 08:50:00 2009 Subject: umass problem. In-Reply-To: <20d8e6193795d83f9ffa30ab94bf86eb@mail> References: <202969100caf7f0bb8098572b0dad622@mail> <20d8e6193795d83f9ffa30ab94bf86eb@mail> Message-ID: <200911060948.45790.hselasky@c2i.net> On Friday 06 November 2009 05:52:48 Alexander Nedotsukov wrote: > Well I do. This is a regression in EHCI driver introduced along the new > usb stack. Please review patch attached. > > Thanks, > Alexander. Hi, Your patch looks good. I will go through it later today. One little issue. There is no callout_drain() call for the new callout. Look for existing callout_drain() calls for the pcd timer. --HPS From tinderbox at freebsd.org Fri Nov 6 09:14:36 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Nov 6 09:14:43 2009 Subject: [head tinderbox] failure on i386/i386 Message-ID: <200911060846.nA68kCbH073944@freebsd-current.sentex.ca> TB --- 2009-11-06 06:50:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-06 06:50:00 - starting HEAD tinderbox run for i386/i386 TB --- 2009-11-06 06:50:00 - cleaning the object tree TB --- 2009-11-06 06:50:27 - cvsupping the source tree TB --- 2009-11-06 06:50:27 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2009-11-06 06:56:28 - building world TB --- 2009-11-06 06:56:28 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 06:56:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 06:56:28 - TARGET=i386 TB --- 2009-11-06 06:56:28 - TARGET_ARCH=i386 TB --- 2009-11-06 06:56:28 - TZ=UTC TB --- 2009-11-06 06:56:28 - __MAKE_CONF=/dev/null TB --- 2009-11-06 06:56:28 - cd /src TB --- 2009-11-06 06:56:28 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 6 06:56:29 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Nov 6 07:55:06 UTC 2009 TB --- 2009-11-06 07:55:06 - generating LINT kernel config TB --- 2009-11-06 07:55:06 - cd /src/sys/i386/conf TB --- 2009-11-06 07:55:06 - /usr/bin/make -B LINT TB --- 2009-11-06 07:55:06 - building LINT kernel TB --- 2009-11-06 07:55:06 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 07:55:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 07:55:06 - TARGET=i386 TB --- 2009-11-06 07:55:06 - TARGET_ARCH=i386 TB --- 2009-11-06 07:55:06 - TZ=UTC TB --- 2009-11-06 07:55:06 - __MAKE_CONF=/dev/null TB --- 2009-11-06 07:55:06 - cd /src TB --- 2009-11-06 07:55:06 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 6 07:55:06 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Nov 6 08:19:50 UTC 2009 TB --- 2009-11-06 08:19:50 - building GENERIC kernel TB --- 2009-11-06 08:19:50 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 08:19:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 08:19:50 - TARGET=i386 TB --- 2009-11-06 08:19:50 - TARGET_ARCH=i386 TB --- 2009-11-06 08:19:50 - TZ=UTC TB --- 2009-11-06 08:19:50 - __MAKE_CONF=/dev/null TB --- 2009-11-06 08:19:50 - cd /src TB --- 2009-11-06 08:19:50 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Nov 6 08:19:50 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Nov 6 08:38:43 UTC 2009 TB --- 2009-11-06 08:38:43 - building PAE kernel TB --- 2009-11-06 08:38:43 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 08:38:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 08:38:43 - TARGET=i386 TB --- 2009-11-06 08:38:43 - TARGET_ARCH=i386 TB --- 2009-11-06 08:38:43 - TZ=UTC TB --- 2009-11-06 08:38:43 - __MAKE_CONF=/dev/null TB --- 2009-11-06 08:38:43 - cd /src TB --- 2009-11-06 08:38:43 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Fri Nov 6 08:38:43 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Fri Nov 6 08:43:39 UTC 2009 TB --- 2009-11-06 08:43:39 - building XEN kernel TB --- 2009-11-06 08:43:39 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 08:43:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 08:43:39 - TARGET=i386 TB --- 2009-11-06 08:43:39 - TARGET_ARCH=i386 TB --- 2009-11-06 08:43:39 - TZ=UTC TB --- 2009-11-06 08:43:39 - __MAKE_CONF=/dev/null TB --- 2009-11-06 08:43:39 - cd /src TB --- 2009-11-06 08:43:39 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Fri Nov 6 08:43:39 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] linking kernel.debug vga_pci.o(.text+0xbf3): In function `vga_pci_resume': /src/sys/dev/pci/vga_pci.c:189: undefined reference to `vidsw' vga_pci.o(.text+0xc3e):/src/sys/dev/pci/vga_pci.c:195: undefined reference to `vidsw' vga_pci.o(.text+0xd15): In function `vga_pci_suspend': /src/sys/dev/pci/vga_pci.c:140: undefined reference to `vidsw' vga_pci.o(.text+0xd81):/src/sys/dev/pci/vga_pci.c:148: undefined reference to `vidsw' vga_pci.o(.text+0xe1c):/src/sys/dev/pci/vga_pci.c:163: undefined reference to `vidsw' *** Error code 1 Stop in /obj/i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-06 08:46:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-06 08:46:10 - ERROR: failed to build XEN kernel TB --- 2009-11-06 08:46:10 - 5083.66 user 940.98 system 6970.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From gary.jennejohn at freenet.de Fri Nov 6 09:19:46 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Fri Nov 6 09:19:55 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <31221257446063@webmail71.yandex.ru> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> Message-ID: <20091106101943.5a763f43@ernst.jennejohn.org> On Thu, 05 Nov 2009 21:34:23 +0300 S.N.Grigoriev wrote: > > > 05.11.09, 18:49, "Gary Jennejohn" : > > > On Thu, 05 Nov 2009 19:40:03 +0300 > > S.N.Grigoriev wrote: > > > > > > 04.11.09, 16:51, "Alexandre \"Sunny\" Kovalenko" > > > wrote: > > > > > > > On Wed, 2009-11-04 at 13:44 +0300, S.N.Grigoriev wrote: > > > > > Hi list, > > > > > > > > > > I can confirm I've seen the same problem. After upgrading from 7-stable > > > > > to 8.0-RC2 my machine just reboots during 'make buildworld' without > > > > > diagnostics. But switching vm.pmap.pg_ps_enabled on/off does not > > > > > work for me. My machine reboots every time I try to build world. > > > > > I don't think I have a hardware problem: under 7-stable I can build > > > > > world/kernel for both 7-stable and 8.0-RC2 without problems. > > > > > > > > > Is it by any chance possible that you have 'debug.debugger_on_panic' set > > > > to '0' and no valid dump device configured? > > > > > > Hi Alexandre, > > > > > > I've not found 'debug.debugger_on_panic' variable in 'sysctl -a' > > > output. Where cat I find it? All my sysctl variables are set by > > > default. > > Do you have "options DDB" in your kernel config file? > > --- > > Gary Jennejohn > > Hi Gary, > > my current kernel is GENERIC, so I don't have "options DDB". > Well, you need that option to see the DDB (debug) sysctl's. --- Gary Jennejohn From tinderbox at freebsd.org Fri Nov 6 09:57:21 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Nov 6 09:57:27 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <200911060928.nA69SiY3092243@freebsd-current.sentex.ca> TB --- 2009-11-06 07:38:14 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-06 07:38:14 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-11-06 07:38:14 - cleaning the object tree TB --- 2009-11-06 07:38:30 - cvsupping the source tree TB --- 2009-11-06 07:38:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-11-06 07:39:17 - building world TB --- 2009-11-06 07:39:17 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 07:39:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 07:39:17 - TARGET=ia64 TB --- 2009-11-06 07:39:17 - TARGET_ARCH=ia64 TB --- 2009-11-06 07:39:17 - TZ=UTC TB --- 2009-11-06 07:39:17 - __MAKE_CONF=/dev/null TB --- 2009-11-06 07:39:17 - cd /src TB --- 2009-11-06 07:39:17 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 6 07:39:18 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Nov 6 08:55:46 UTC 2009 TB --- 2009-11-06 08:55:46 - generating LINT kernel config TB --- 2009-11-06 08:55:46 - cd /src/sys/ia64/conf TB --- 2009-11-06 08:55:46 - /usr/bin/make -B LINT TB --- 2009-11-06 08:55:46 - building LINT kernel TB --- 2009-11-06 08:55:46 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 08:55:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 08:55:46 - TARGET=ia64 TB --- 2009-11-06 08:55:46 - TARGET_ARCH=ia64 TB --- 2009-11-06 08:55:46 - TZ=UTC TB --- 2009-11-06 08:55:46 - __MAKE_CONF=/dev/null TB --- 2009-11-06 08:55:46 - cd /src TB --- 2009-11-06 08:55:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 6 08:55:46 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Nov 6 09:22:11 UTC 2009 TB --- 2009-11-06 09:22:11 - building GENERIC kernel TB --- 2009-11-06 09:22:11 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 09:22:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 09:22:11 - TARGET=ia64 TB --- 2009-11-06 09:22:11 - TARGET_ARCH=ia64 TB --- 2009-11-06 09:22:11 - TZ=UTC TB --- 2009-11-06 09:22:11 - __MAKE_CONF=/dev/null TB --- 2009-11-06 09:22:11 - cd /src TB --- 2009-11-06 09:22:11 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Nov 6 09:22:12 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] vga_pci.o(.text+0x1ad2): In function `vga_pci_resume': /src/sys/dev/pci/vga_pci.c:189: undefined reference to `vidsw' vga_pci.o(.text+0x1ae0):/src/sys/dev/pci/vga_pci.c:189: undefined reference to `vidsw' vga_pci.o(.text+0x1bc2):/src/sys/dev/pci/vga_pci.c:195: undefined reference to `vidsw' vga_pci.o(.text+0x1bd0):/src/sys/dev/pci/vga_pci.c:195: undefined reference to `vidsw' vga_pci.o(.text+0x1de2): In function `vga_pci_suspend': /src/sys/dev/pci/vga_pci.c:140: undefined reference to `vidsw' vga_pci.o(.text+0x1df0):/src/sys/dev/pci/vga_pci.c:140: more undefined references to `vidsw' follow *** Error code 1 Stop in /obj/ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-06 09:28:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-06 09:28:44 - ERROR: failed to build GENERIC kernel TB --- 2009-11-06 09:28:44 - 5290.95 user 780.90 system 6630.45 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From tinderbox at freebsd.org Fri Nov 6 10:49:40 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Nov 6 10:49:52 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <200911061020.nA6AKmJQ074518@freebsd-current.sentex.ca> TB --- 2009-11-06 09:15:28 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-06 09:15:28 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-11-06 09:15:28 - cleaning the object tree TB --- 2009-11-06 09:15:40 - cvsupping the source tree TB --- 2009-11-06 09:15:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-11-06 09:16:22 - building world TB --- 2009-11-06 09:16:22 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 09:16:22 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 09:16:22 - TARGET=sun4v TB --- 2009-11-06 09:16:22 - TARGET_ARCH=sparc64 TB --- 2009-11-06 09:16:22 - TZ=UTC TB --- 2009-11-06 09:16:22 - __MAKE_CONF=/dev/null TB --- 2009-11-06 09:16:22 - cd /src TB --- 2009-11-06 09:16:22 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 6 09:16:22 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Nov 6 10:09:50 UTC 2009 TB --- 2009-11-06 10:09:50 - generating LINT kernel config TB --- 2009-11-06 10:09:50 - cd /src/sys/sun4v/conf TB --- 2009-11-06 10:09:50 - /usr/bin/make -B LINT TB --- 2009-11-06 10:09:50 - building LINT kernel TB --- 2009-11-06 10:09:50 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 10:09:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 10:09:50 - TARGET=sun4v TB --- 2009-11-06 10:09:50 - TARGET_ARCH=sparc64 TB --- 2009-11-06 10:09:50 - TZ=UTC TB --- 2009-11-06 10:09:50 - __MAKE_CONF=/dev/null TB --- 2009-11-06 10:09:50 - cd /src TB --- 2009-11-06 10:09:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 6 10:09:50 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] : undefined reference to `vidsw' vga_pci.o(.text+0xe7c): In function `vga_pci_resume': : undefined reference to `vidsw' vga_pci.o(.text+0xe8c): In function `vga_pci_resume': : undefined reference to `vidsw' vga_pci.o(.text+0xedc): In function `vga_pci_resume': : undefined reference to `vidsw' vga_pci.o(.text+0xee4): more undefined references to `vidsw' follow *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-06 10:20:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-06 10:20:48 - ERROR: failed to build lint kernel TB --- 2009-11-06 10:20:48 - 3100.82 user 604.19 system 3920.05 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From gaijin.k at gmail.com Fri Nov 6 12:55:54 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Fri Nov 6 12:56:01 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <1031257439203@webmail57.yandex.ru> References: <1031257439203@webmail57.yandex.ru> Message-ID: <1257512151.1434.13.camel@RabbitsDen> On Thu, 2009-11-05 at 19:40 +0300, S.N.Grigoriev wrote: > 04.11.09, 16:51, "Alexandre \"Sunny\" Kovalenko" > wrote: > > > On Wed, 2009-11-04 at 13:44 +0300, S.N.Grigoriev wrote: > > > Hi list, > > > > > > I can confirm I've seen the same problem. After upgrading from 7-stable > > > to 8.0-RC2 my machine just reboots during 'make buildworld' without > > > diagnostics. But switching vm.pmap.pg_ps_enabled on/off does not > > > work for me. My machine reboots every time I try to build world. > > > I don't think I have a hardware problem: under 7-stable I can build > > > world/kernel for both 7-stable and 8.0-RC2 without problems. > > > > > Is it by any chance possible that you have 'debug.debugger_on_panic' set > > to '0' and no valid dump device configured? > > Hi Alexandre, > > I've not found 'debug.debugger_on_panic' variable in 'sysctl -a' > output. Where cat I find it? All my sysctl variables are set by > default. If your system does not have "option DDB", it would not have sysctl above, which might be just as well. Does savecore -v output makes sense? Where I am heading with all of that is the possibility that your system panic(9)'ed and saved no core, hence, looking like it just rebooted. -- Alexandre Kovalenko (????????? ?????????) From roberthuff at rcn.com Fri Nov 6 13:10:10 2009 From: roberthuff at rcn.com (Robert Huff) Date: Fri Nov 6 13:10:17 2009 Subject: What is the state of ZFS on FreeBSD? In-Reply-To: <9e20d71e0911042247n216e9b02t7b317a55a9bbe131@mail.gmail.com> References: <9e20d71e0911042247n216e9b02t7b317a55a9bbe131@mail.gmail.com> Message-ID: <19188.8189.660106.589512@jerusalem.litteratus.org> Artis Caune writes: > > I'm interested inb putting together a file server with lots of disk. > > > > What's the state of ZFS? Is it ready for production use? > > yes, please, see > http://svn.freebsd.org/viewvc/base?view=revision&revision=197218 I'd say it's a matter of individual risk tolerance and how well one knows ZFS. Reading questions@, current@, and hackers@, there are many people happily running ZFS. But it's also generating _at least_ 10x the queries and problems of ufs, ext?fs, ntfs/msdosfs, and nfs put together. Much of that is "Can I X?" or "How do I X?" ... and the rest isn't. My personal take: ZFS has been out there for less than five years (according to Wikipedia) and is still in the steep part of the development curve. I'll wait until it has a few more gigadays under its belt before betting the ranch. Robert Huff From attilio at freebsd.org Fri Nov 6 14:43:07 2009 From: attilio at freebsd.org (Attilio Rao) Date: Fri Nov 6 14:43:14 2009 Subject: [PATCH] Adding sysctl for errors statistics to ahd(4) Message-ID: <3bbf2fe10911060643g60079e31y7679b32dac670fd8@mail.gmail.com> This patch introduces some mechanisms for collecting informations on errors frequency and debugging (and relative sysctls for printing them out) for the ahd(4) driver: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/ahd/ahd-current2.diff The usage of array for sysctls is a bit too paranoid but it allows for further extendibility of the code and doesn't loose of cleaness. This code has been contributed back by Sandvine Incorporated with some cleanups. Please review. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From attilio at freebsd.org Fri Nov 6 15:13:00 2009 From: attilio at freebsd.org (Attilio Rao) Date: Fri Nov 6 15:13:07 2009 Subject: [PATCH] Boot-time entering prompt by typing "123" sequence rather than any button Message-ID: <3bbf2fe10911060712y46684f76sefe195a62083c15@mail.gmail.com> This patch adds the possibility to enter the prompt at boot time by typing the sequence of buttons "123" rather than a single button: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/boot123/boot123.diff This is useful in the cases where a serial console is likely going to be used which can carry on spourious character, leding to the prompt erroneously. This option is wrappered into the BOOT_PROMPT_123 option, in order to maintain the current POLA. This patch has been contributed back by Sandvine Incorporated. Please review. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From jhb at freebsd.org Fri Nov 6 15:51:08 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Nov 6 15:51:16 2009 Subject: [PATCH] Boot-time entering prompt by typing "123" sequence rather than any button In-Reply-To: <3bbf2fe10911060712y46684f76sefe195a62083c15@mail.gmail.com> References: <3bbf2fe10911060712y46684f76sefe195a62083c15@mail.gmail.com> Message-ID: <200911061050.50873.jhb@freebsd.org> On Friday 06 November 2009 10:12:59 am Attilio Rao wrote: > This patch adds the possibility to enter the prompt at boot time by > typing the sequence of buttons "123" rather than a single button: > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/boot123/boot123.diff > > This is useful in the cases where a serial console is likely going to > be used which can carry on spourious character, leding to the prompt > erroneously. > This option is wrappered into the BOOT_PROMPT_123 option, in order to > maintain the current POLA. > This patch has been contributed back by Sandvine Incorporated. > Please review. This seems a bit hackish, but the patch is fine on technical grounds. On machines where I have a serial console I tend to put "-Dh" in /boot.config (so I can choose an alternate loader if need be) and in that case boot2 would eat the extra input and pause during the boot process (I've had this happen occasionally). This patch wouldn't help with that case. Another suggestion made on IRC was to simply drain input at the start of boot2 or loader to avoid accepting early spurious input. This won't help if you are dealing with noisy serial lines that are just spewing random garbage during the boot process however. -- John Baldwin From serguey-grigoriev at yandex.ru Fri Nov 6 16:26:18 2009 From: serguey-grigoriev at yandex.ru (S.N.Grigoriev) Date: Fri Nov 6 16:26:26 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld Message-ID: <5761257524664@webmail58.yandex.ru> 06.11.09, 07:55, "Alexandre \"Sunny\" Kovalenko" : > On Thu, 2009-11-05 at 19:40 +0300, S.N.Grigoriev wrote: > > 04.11.09, 16:51, "Alexandre \"Sunny\" Kovalenko" > > wrote: > > > > > On Wed, 2009-11-04 at 13:44 +0300, S.N.Grigoriev wrote: > > > > Hi list, > > > > > > > > I can confirm I've seen the same problem. After upgrading from 7-stable > > > > to 8.0-RC2 my machine just reboots during 'make buildworld' without > > > > diagnostics. But switching vm.pmap.pg_ps_enabled on/off does not > > > > work for me. My machine reboots every time I try to build world. > > > > I don't think I have a hardware problem: under 7-stable I can build > > > > world/kernel for both 7-stable and 8.0-RC2 without problems. > > > > > > > Is it by any chance possible that you have 'debug.debugger_on_panic' set > > > to '0' and no valid dump device configured? > > > > Hi Alexandre, > > > > I've not found 'debug.debugger_on_panic' variable in 'sysctl -a' > > output. Where cat I find it? All my sysctl variables are set by > > default. > If your system does not have "option DDB", it would not have sysctl > above, which might be just as well. > Does savecore -v output makes sense? This is 'savecore -v' output on my machine: unable to open bounds file, using 0 checking for kernel dump on device /dev/ad8s1b mediasize = 4294967296 sectorsize = 512 magic mismatch on last dump header on /dev/ad8s1b savecore: no dumps found -- Regards, S.Grigoriev. From emaste at freebsd.org Fri Nov 6 16:41:56 2009 From: emaste at freebsd.org (Ed Maste) Date: Fri Nov 6 16:42:02 2009 Subject: [PATCH] Boot-time entering prompt by typing "123" sequence rather than any button In-Reply-To: <200911061050.50873.jhb@freebsd.org> References: <3bbf2fe10911060712y46684f76sefe195a62083c15@mail.gmail.com> <200911061050.50873.jhb@freebsd.org> Message-ID: <20091106162951.GA77255@sandvine.com> On Fri, Nov 06, 2009 at 10:50:50AM -0500, John Baldwin wrote: > On Friday 06 November 2009 10:12:59 am Attilio Rao wrote: > > This patch adds the possibility to enter the prompt at boot time by > > typing the sequence of buttons "123" rather than a single button: > > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/boot123/boot123.diff > > > > This is useful in the cases where a serial console is likely going to > > be used which can carry on spourious character, leding to the prompt > > erroneously. > > This option is wrappered into the BOOT_PROMPT_123 option, in order to > > maintain the current POLA. > > This patch has been contributed back by Sandvine Incorporated. > > Please review. > > This seems a bit hackish, but the patch is fine on technical grounds. On > machines where I have a serial console I tend to put "-Dh" in /boot.config > (so I can choose an alternate loader if need be) and in that case boot2 would > eat the extra input and pause during the boot process (I've had this happen > occasionally). This patch wouldn't help with that case. Another suggestion > made on IRC was to simply drain input at the start of boot2 or loader to > avoid accepting early spurious input. This won't help if you are dealing > with noisy serial lines that are just spewing random garbage during the boot > process however. In a specific case we encountered, an unterminated cable plugged into a serial port caused enough signal to be reflected to produce a lossy loopback. This is a similar case to the random garbage case you suggest. My first stage loader isn't using the serial console, it's only when loader(8) starts that it switches. -Ed From tinderbox at freebsd.org Fri Nov 6 19:26:53 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Nov 6 19:27:02 2009 Subject: [head tinderbox] failure on i386/i386 Message-ID: <200911061855.nA6ItQ5a040232@freebsd-current.sentex.ca> TB --- 2009-11-06 17:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-06 17:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2009-11-06 17:00:00 - cleaning the object tree TB --- 2009-11-06 17:00:29 - cvsupping the source tree TB --- 2009-11-06 17:00:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2009-11-06 17:06:08 - building world TB --- 2009-11-06 17:06:08 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 17:06:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 17:06:08 - TARGET=i386 TB --- 2009-11-06 17:06:08 - TARGET_ARCH=i386 TB --- 2009-11-06 17:06:08 - TZ=UTC TB --- 2009-11-06 17:06:08 - __MAKE_CONF=/dev/null TB --- 2009-11-06 17:06:08 - cd /src TB --- 2009-11-06 17:06:08 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 6 17:06:08 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Nov 6 18:04:51 UTC 2009 TB --- 2009-11-06 18:04:51 - generating LINT kernel config TB --- 2009-11-06 18:04:51 - cd /src/sys/i386/conf TB --- 2009-11-06 18:04:51 - /usr/bin/make -B LINT TB --- 2009-11-06 18:04:51 - building LINT kernel TB --- 2009-11-06 18:04:51 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 18:04:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 18:04:51 - TARGET=i386 TB --- 2009-11-06 18:04:51 - TARGET_ARCH=i386 TB --- 2009-11-06 18:04:51 - TZ=UTC TB --- 2009-11-06 18:04:51 - __MAKE_CONF=/dev/null TB --- 2009-11-06 18:04:51 - cd /src TB --- 2009-11-06 18:04:51 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 6 18:04:51 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Nov 6 18:28:58 UTC 2009 TB --- 2009-11-06 18:28:58 - building GENERIC kernel TB --- 2009-11-06 18:28:58 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 18:28:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 18:28:58 - TARGET=i386 TB --- 2009-11-06 18:28:58 - TARGET_ARCH=i386 TB --- 2009-11-06 18:28:58 - TZ=UTC TB --- 2009-11-06 18:28:58 - __MAKE_CONF=/dev/null TB --- 2009-11-06 18:28:58 - cd /src TB --- 2009-11-06 18:28:58 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Nov 6 18:28:59 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Nov 6 18:48:07 UTC 2009 TB --- 2009-11-06 18:48:07 - building PAE kernel TB --- 2009-11-06 18:48:07 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 18:48:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 18:48:07 - TARGET=i386 TB --- 2009-11-06 18:48:07 - TARGET_ARCH=i386 TB --- 2009-11-06 18:48:07 - TZ=UTC TB --- 2009-11-06 18:48:07 - __MAKE_CONF=/dev/null TB --- 2009-11-06 18:48:07 - cd /src TB --- 2009-11-06 18:48:07 - /usr/bin/make -B buildkernel KERNCONF=PAE >>> Kernel build for PAE started on Fri Nov 6 18:48:07 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for PAE completed on Fri Nov 6 18:52:53 UTC 2009 TB --- 2009-11-06 18:52:53 - building XEN kernel TB --- 2009-11-06 18:52:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 18:52:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 18:52:53 - TARGET=i386 TB --- 2009-11-06 18:52:53 - TARGET_ARCH=i386 TB --- 2009-11-06 18:52:53 - TZ=UTC TB --- 2009-11-06 18:52:53 - __MAKE_CONF=/dev/null TB --- 2009-11-06 18:52:53 - cd /src TB --- 2009-11-06 18:52:53 - /usr/bin/make -B buildkernel KERNCONF=XEN >>> Kernel build for XEN started on Fri Nov 6 18:52:53 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] linking kernel.debug vga_pci.o(.text+0xbf3): In function `vga_pci_resume': /src/sys/dev/pci/vga_pci.c:189: undefined reference to `vidsw' vga_pci.o(.text+0xc3e):/src/sys/dev/pci/vga_pci.c:195: undefined reference to `vidsw' vga_pci.o(.text+0xd15): In function `vga_pci_suspend': /src/sys/dev/pci/vga_pci.c:140: undefined reference to `vidsw' vga_pci.o(.text+0xd81):/src/sys/dev/pci/vga_pci.c:148: undefined reference to `vidsw' vga_pci.o(.text+0xe1c):/src/sys/dev/pci/vga_pci.c:163: undefined reference to `vidsw' *** Error code 1 Stop in /obj/i386/src/sys/XEN. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-06 18:55:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-06 18:55:26 - ERROR: failed to build XEN kernel TB --- 2009-11-06 18:55:26 - 5079.17 user 939.11 system 6926.51 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From jhb at freebsd.org Fri Nov 6 20:08:40 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Nov 6 20:08:58 2009 Subject: [PATCH] Remove if_watchdog use Message-ID: <200911061508.22482.jhb@freebsd.org> I have a patchset that converts all the remaining users of if_watchdog to using a private callout instead. In some cases the the driver already used a private timer to drive a stats timer and I merely hooked into that timer. In other cases a new callout needed to be added to the driver. Some drivers even abused the if_watchdog interface to provide a stats timer that fired every second. :) For a few drivers I also fixed other things such as busted locking, order-of-operations issues in detach, or just completely busted drivers (fea(4) and fpa(4) which share the pdq backend). Please test. Barring any major screaming and shouting I plan to commit this in a week or so and after that to work on removing the if_watchdog/if_timer stuff from the network stack. The patch is at http://www.FreeBSD.org/~jhb/patches/cleanup.patch Driver details: - an(4) - Locking fixes to not do silly things like drop the lock only to call a function that immediately reacquires the lock. Also removes recursive locking. - Hooks into the stat timer to drive the watchdog timer. - bwi(4), cm(4), ep(4), fatm(4), malo(4), mwl(4), vx(4) - Adds a new private timer to drive the watchdog timer. - ce(4), cp(4), ctau(4), cx(4), lmc(4) - These drivers have two modes, a netgraph mode and an ifnet mode. In the netgraph mode they used a private timer to drive the watchdog. In the ifnet mode they used if_watchdog. Now they just always use the private timer. - de(4) - This driver abused the watchdog interface to manage its once-a-second stat timer. It uses a callout to manage this now instead. - ed(4) - This driver used to provide a hook to allow individual attachments to provide a 'tick' event to be called from an optional stats timer. The stats timer only ran if the tick function pointer was non-NULL and the attachment's tick routine had to call callout_reset(), etc. Now the driver always schedules a stat timer and manages the callout_reset() internally. This timer is used to drive the watchdog and will also call the attachment's 'tick' handler if one is provided. - ixgb(4) - Uses callout_init_mtx() instead of callout_init(..., CALLOUT_MPSAFE). - Remove silly callout handling in a few places (cancelling the callout only to rescheduled it again immediately afterwards). - Hooks into the stat timer to drive the watchdog timer. - lge(4), nve(4), pcn(4) - Hooks into the stat timer to drive the watchdog timer. - my(4) - This driver used the watchdog timer both as a watchdog on transmit and auto-negotiation. To make this simpler and easier to understand I have split this out into two separate timers. One just manages the auto-neg side of things and one is a transmit watchdog. - fea(4), fpa(4) - These two drivers share a common backend, pdq, which was plagued with several issues. I'm quite confident no one has used these drivers in years since the are guaranteed to panic during attach. - Add real locking. Previously these drivers only acquired their lock in their interrupt handler or in the ioctl routine (but too broadly in the latter). No locking was used for the stack calling down into the driver via if_init() or if_start(), for device shutdown or detach. Also, the interrupt handler held the driver lock while calling if_input(). All this stuff should be fixed in the locking changes. - Really fix these drivers to handle if_alloc(). The front-end attachments were using if_initname() before the ifnet was allocated. Fix this by moving some of the duplicated logic from each driver into pdq_ifattach(). While here, make pdq_ifattach() return an error so that the driver just fails to attach if if_alloc() fails rather than panic'ing. - Adds a new private timer to drive the watchdog timer. - sn(4) - Use bus_*() rather than bus_space_*(). - Adds a new private timer to drive the watchdog timer. - Fixup detach. - ste(4), ti(4) - Adds a new private timer to drive the watchdog timer. - Fixup detach. - tl(4), wb(4) - Use bus_*() rather than bus_space_*(). - Hooks into the stat timer to drive the watchdog timer. - Fixup detach. - vge(4) - Overhaul the locking to avoid recursion and add missing locking in a few places. - Don't schedule a task to call vge_start() from contexts that are safe to call vge_start() directly. Just invoke the routine directly instead (this is what all of the other NIC drivers I am familiar with do). Note that vge(4) does not use an interrupt filter handler which is the primary reason some other drivers use tasks. - Adds a new private timer to drive the watchdog timer. - Use bus_*() rather than bus_space_*(). - Fixup detach. - netfront(4) - This doesn't actually implement a watchdog, it just sets if_watchdog to a non-existent function under '#ifdef notyet'. - admsw(4) - This driver is a bit special in that it has no locking at all, not even a poor attempt. :) It also appears to be for a specific MIPS board of some sort. - It has multiple ifnet's for multiple ports, but it only used if_timer and if_watchdog from the first ifnet. For this driver I added a single private timer to replace the if_timer use on the first ifnet. I marked the callout MPSAFE, but the driver really needs to have locking added at which point it could use callout_init_mtx(). -- John Baldwin From tinderbox at freebsd.org Fri Nov 6 20:09:26 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Nov 6 20:09:32 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <200911061937.nA6JbkgE058846@freebsd-current.sentex.ca> TB --- 2009-11-06 17:48:19 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-06 17:48:19 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-11-06 17:48:19 - cleaning the object tree TB --- 2009-11-06 17:48:33 - cvsupping the source tree TB --- 2009-11-06 17:48:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-11-06 17:49:04 - building world TB --- 2009-11-06 17:49:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 17:49:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 17:49:04 - TARGET=ia64 TB --- 2009-11-06 17:49:04 - TARGET_ARCH=ia64 TB --- 2009-11-06 17:49:04 - TZ=UTC TB --- 2009-11-06 17:49:04 - __MAKE_CONF=/dev/null TB --- 2009-11-06 17:49:04 - cd /src TB --- 2009-11-06 17:49:04 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 6 17:49:04 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Nov 6 19:04:54 UTC 2009 TB --- 2009-11-06 19:04:54 - generating LINT kernel config TB --- 2009-11-06 19:04:54 - cd /src/sys/ia64/conf TB --- 2009-11-06 19:04:54 - /usr/bin/make -B LINT TB --- 2009-11-06 19:04:54 - building LINT kernel TB --- 2009-11-06 19:04:54 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 19:04:54 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 19:04:54 - TARGET=ia64 TB --- 2009-11-06 19:04:54 - TARGET_ARCH=ia64 TB --- 2009-11-06 19:04:54 - TZ=UTC TB --- 2009-11-06 19:04:54 - __MAKE_CONF=/dev/null TB --- 2009-11-06 19:04:54 - cd /src TB --- 2009-11-06 19:04:54 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 6 19:04:54 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Nov 6 19:31:25 UTC 2009 TB --- 2009-11-06 19:31:25 - building GENERIC kernel TB --- 2009-11-06 19:31:25 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 19:31:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 19:31:25 - TARGET=ia64 TB --- 2009-11-06 19:31:25 - TARGET_ARCH=ia64 TB --- 2009-11-06 19:31:25 - TZ=UTC TB --- 2009-11-06 19:31:25 - __MAKE_CONF=/dev/null TB --- 2009-11-06 19:31:25 - cd /src TB --- 2009-11-06 19:31:25 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Nov 6 19:31:25 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] vga_pci.o(.text+0x1ad2): In function `vga_pci_resume': /src/sys/dev/pci/vga_pci.c:189: undefined reference to `vidsw' vga_pci.o(.text+0x1ae0):/src/sys/dev/pci/vga_pci.c:189: undefined reference to `vidsw' vga_pci.o(.text+0x1bc2):/src/sys/dev/pci/vga_pci.c:195: undefined reference to `vidsw' vga_pci.o(.text+0x1bd0):/src/sys/dev/pci/vga_pci.c:195: undefined reference to `vidsw' vga_pci.o(.text+0x1de2): In function `vga_pci_suspend': /src/sys/dev/pci/vga_pci.c:140: undefined reference to `vidsw' vga_pci.o(.text+0x1df0):/src/sys/dev/pci/vga_pci.c:140: more undefined references to `vidsw' follow *** Error code 1 Stop in /obj/ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-06 19:37:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-06 19:37:46 - ERROR: failed to build GENERIC kernel TB --- 2009-11-06 19:37:46 - 5286.66 user 776.19 system 6567.26 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From rmacklem at uoguelph.ca Fri Nov 6 20:23:12 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Fri Nov 6 20:23:19 2009 Subject: Help needed: TCP Wizards (was 8.0-RC1 NFS client timeout issue) In-Reply-To: <030A8229-9707-4F70-B4BE-584F1BF9ECEC@FreeBSD.org> References: <4AF0B7DF.9030405@freebsd.org> <030A8229-9707-4F70-B4BE-584F1BF9ECEC@FreeBSD.org> Message-ID: On Thu, 5 Nov 2009, Rui Paulo wrote: > > Are you running TSO? > Wow, I owe you a beer:-) That was the magic bullet... I'm a dinosaur, so when I first saw this, I thought of that wonderful time sharing front end to IBM mainframes I had the priviledge of using in the 70s. (There was also a TSO emulator in the early Unix releases, which set your terminal to the worst possible setting imaginable and introduced delays of seconds when you tried to do anything. It was pretty funny for those of us who had experienced the real thing.) Anyhow, I figured you probably didn't mean this so I grep'd around and found net.inet.tcp.tso, set it to 0 and...the problem went away. (I have gotten a RST for the new port# once since then, but it was in the middle of the 3way handshake instead of after it, so it didn't cause any grief, just another 3way handshake right away.) I have no idea if the problem is something generic w.r.t. TSO or specific to the Intel 82801BA/CAM and/or the fxp driver for it. (I checked and none of the other net cards I have lying around have TSO support, so I can't test this by replacing the net card/driver.) Does anyone know enough about TSO to know if the problem is net chip specific of generic to using it? Thanks for the help. I don't think I would have ever found that, rick From pyunyh at gmail.com Fri Nov 6 20:31:52 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Fri Nov 6 20:31:59 2009 Subject: Help needed: TCP Wizards (was 8.0-RC1 NFS client timeout issue) In-Reply-To: References: <4AF0B7DF.9030405@freebsd.org> <030A8229-9707-4F70-B4BE-584F1BF9ECEC@FreeBSD.org> Message-ID: <20091106203116.GZ1256@michelle.cdnetworks.com> On Fri, Nov 06, 2009 at 03:30:39PM -0500, Rick Macklem wrote: > > > On Thu, 5 Nov 2009, Rui Paulo wrote: > > > > >Are you running TSO? > > > Wow, I owe you a beer:-) That was the magic bullet... > > I'm a dinosaur, so when I first saw this, I thought of that wonderful > time sharing front end to IBM mainframes I had the priviledge of using > in the 70s. (There was also a TSO emulator in the early Unix releases, > which set your terminal to the worst possible setting imaginable and > introduced delays of seconds when you tried to do anything. It was > pretty funny for those of us who had experienced the real thing.) > > Anyhow, I figured you probably didn't mean this so I grep'd around > and found net.inet.tcp.tso, set it to 0 and...the problem went away. > (I have gotten a RST for the new port# once since then, but it was > in the middle of the 3way handshake instead of after it, so it didn't > cause any grief, just another 3way handshake right away.) > > I have no idea if the problem is something generic w.r.t. TSO or specific > to the Intel 82801BA/CAM and/or the fxp driver for it. (I checked and none fxp(4) has TSO support but I don't think 82801BA has TSO capability. Only i82550 and i82551 support TSO. You can check it with ifconfig if fxp(4) think the controller supports TSO. > of the other net cards I have lying around have TSO support, so I can't > test this by replacing the net card/driver.) > > Does anyone know enough about TSO to know if the problem is net chip > specific of generic to using it? > > Thanks for the help. I don't think I would have ever found that, rick > From tinderbox at freebsd.org Fri Nov 6 21:00:21 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Fri Nov 6 21:00:28 2009 Subject: [head tinderbox] failure on sparc64/sun4v Message-ID: <200911062028.nA6KSPWw036294@freebsd-current.sentex.ca> TB --- 2009-11-06 19:22:33 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-06 19:22:33 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-11-06 19:22:33 - cleaning the object tree TB --- 2009-11-06 19:22:44 - cvsupping the source tree TB --- 2009-11-06 19:22:44 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-11-06 19:23:55 - building world TB --- 2009-11-06 19:23:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 19:23:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 19:23:55 - TARGET=sun4v TB --- 2009-11-06 19:23:55 - TARGET_ARCH=sparc64 TB --- 2009-11-06 19:23:55 - TZ=UTC TB --- 2009-11-06 19:23:55 - __MAKE_CONF=/dev/null TB --- 2009-11-06 19:23:55 - cd /src TB --- 2009-11-06 19:23:55 - /usr/bin/make -B buildworld >>> World build started on Fri Nov 6 19:23:56 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Nov 6 20:17:25 UTC 2009 TB --- 2009-11-06 20:17:25 - generating LINT kernel config TB --- 2009-11-06 20:17:25 - cd /src/sys/sun4v/conf TB --- 2009-11-06 20:17:25 - /usr/bin/make -B LINT TB --- 2009-11-06 20:17:25 - building LINT kernel TB --- 2009-11-06 20:17:25 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-06 20:17:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-06 20:17:25 - TARGET=sun4v TB --- 2009-11-06 20:17:25 - TARGET_ARCH=sparc64 TB --- 2009-11-06 20:17:25 - TZ=UTC TB --- 2009-11-06 20:17:25 - __MAKE_CONF=/dev/null TB --- 2009-11-06 20:17:25 - cd /src TB --- 2009-11-06 20:17:25 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 6 20:17:25 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] : undefined reference to `vidsw' vga_pci.o(.text+0xe7c): In function `vga_pci_resume': : undefined reference to `vidsw' vga_pci.o(.text+0xe8c): In function `vga_pci_resume': : undefined reference to `vidsw' vga_pci.o(.text+0xedc): In function `vga_pci_resume': : undefined reference to `vidsw' vga_pci.o(.text+0xee4): more undefined references to `vidsw' follow *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-06 20:28:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-06 20:28:25 - ERROR: failed to build lint kernel TB --- 2009-11-06 20:28:25 - 3103.78 user 602.09 system 3952.77 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From konfer at mikulas.com Fri Nov 6 21:04:33 2009 From: konfer at mikulas.com (Jiri Mikulas) Date: Fri Nov 6 21:04:40 2009 Subject: arcmsr 1.20.00.16-91010 update Message-ID: <4AF48F5D.4020400@mikulas.com> Hello Would anybody merge and MFC bugfix for ARC-1200 in driver please? ftp://ftp.areca.com.tw/RaidCards/AP_Drivers/FreeBSD/DRIVER/SourceCode/arcmsr-freebsd-1.20.00.16-91010.zip There were bug (only for ARC-1200 model) in memory space overlaping with other drivers. I can provide closer comunication with Erich Chen from Areca, if needed. Please don't forget to update version string ARCMSR_DRIVER_VERSION in arcmsr.h (isn't included in this "FTP" version of arcmsr.h) Thanks for help Jiri From hselasky at c2i.net Sat Nov 7 00:08:09 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sat Nov 7 00:08:16 2009 Subject: umass problem. In-Reply-To: <20d8e6193795d83f9ffa30ab94bf86eb@mail> References: <202969100caf7f0bb8098572b0dad622@mail> <20d8e6193795d83f9ffa30ab94bf86eb@mail> Message-ID: <200911070109.28595.hselasky@c2i.net> On Friday 06 November 2009 05:52:48 Alexander Nedotsukov wrote: > Well I do. This is a regression in EHCI driver introduced along the new > usb stack. Please review patch attached. > > Thanks, > Alexander. > Hi, Your patch has been committed to USB P4 with some modifications. Please test! http://p4web.freebsd.org/chv.cgi?CH=170302 --HPS From oberman at es.net Sat Nov 7 02:34:13 2009 From: oberman at es.net (Kevin Oberman) Date: Sat Nov 7 02:34:49 2009 Subject: After sys/net80211 changes in r198931 laptop is no longer associating with AP In-Reply-To: Your message of "Thu, 05 Nov 2009 15:24:59 +0100." <3a142e750911050624q41a22ed5ud4f6919a2fac686e@mail.gmail.com> Message-ID: <20091107023410.940601CC0E@ptavv.es.net> > Date: Thu, 5 Nov 2009 15:24:59 +0100 > From: Paul B Mahol > Sender: owner-freebsd-current@freebsd.org > > On 11/5/09, Alexandre "Sunny" Kovalenko wrote: > > It seems that 8.0 discussion is still going on on @current... if I > > should have posted this on @stable, please, feel free to chastise me as > > appropriate. > > > > After updating to r198831 my laptop no longer associates with either of > > two APs I have. Rolling back just 'sys/net80211' to r198443 fixes the > > problem. > > > > Working system: > > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC1 FreeBSD 8.0-RC1 #0 > > r198443M: Sat Oct 24 14:03:30 EDT 2009 > > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 > > > > Non-working system: > > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC2 FreeBSD 8.0-RC2 #0 > > r198931: Wed Nov 4 20:56:16 EST 2009 > > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 > > > > APs are is: > > SSID/MESH ID BSSID CHAN RATE S:N INT CAPS > > AP_SSID 00:1f:33:3b:xx:xx 3 54M -68:-96 100 EP RSN WPS > > WME > > AP_SSID 00:1f:90:cb:xx:xx 8 54M -73:-96 100 EPS RSN WPA > > ATH > > > > Relevant piece of wpa_supplicant.conf is: > > > > ctrl_interface=/var/run/wpa_supplicant > > ctrl_interface_group=wheel > > eapol_version=2 > > > > network={ > > ssid="AP_SSID" > > scan_ssid=1 > > priority=1 > > proto=WPA > > key_mgmt=WPA-PSK > > psk="Really secure something" > > } > > > > APs are set not to broadcast SSID, but enabling broadcast does not > > change much. > > > > Running wpa_supplicant with -d shows that it could not match AP_SSID. > > > > If there is anything else I can provide, please, let me know. > > What driver are you using? > Looking into net80211 svn log for that time period I only see mesh hacks ... I am seeing exactly the same issue. Atheros 5212 with a non-broadcast SSID. Similar wpa_supplicant.conf including 'scan_ssid=1'. 'ifconfig wlan0' shows no ssid. Every time I boot my laptop at home, I need to enter 'ifconfig wlan0 ssid MySSID'. As soon as I do this, it immediately associates correctly. This was never a problem when I was running V7.0. Again, it only is an issue when I am associating with my non-broadcast SSID at home. When at work or traveling where the SSID is broadcast, wpa_supplicant works just fine. If I ever get more time, I'll try to run wpa_supplicant with gdb and see what is happenning, but I may not get a chance any time soon. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From rmacklem at uoguelph.ca Sat Nov 7 03:19:10 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Sat Nov 7 03:19:17 2009 Subject: Help needed: TCP Wizards (was 8.0-RC1 NFS client timeout issue) In-Reply-To: <030A8229-9707-4F70-B4BE-584F1BF9ECEC@FreeBSD.org> References: <4AF0B7DF.9030405@freebsd.org> <030A8229-9707-4F70-B4BE-584F1BF9ECEC@FreeBSD.org> Message-ID: On Thu, 5 Nov 2009, Rui Paulo wrote: > > Are you running TSO? > I spoke too soon the last time. It appears that the setting of net.inet.tcp.tso does not have any effect and that the Intel chip on this machine doesn't do TSO. (I tried swapping it for a 3C905 and the RSTs are showing up.) I guess it was just coincidence that the RSTs seemed to stop happening for a while after I flipped the sysctl. I think the problem is related to the fact that the server end has started to close down the connection (send a FIN), but the client doesn't do anything until an RPC shows up and then tried to do a new connection right after shutting down the old one. (Solaris10 generates RSTs on the old connection and it seems that somehow triggers one being sent to the server with the new port# instead of the old port#.) I'm about to try doing a soshutdown() at the time the server sends the FIN to the client, to see what effect that has. I still can't figure out where the pesky RST gets sent or I could get a stack trace at that point and see what is doing it. Having lottsa fun with it, rick From sam at freebsd.org Sat Nov 7 03:49:36 2009 From: sam at freebsd.org (Sam Leffler) Date: Sat Nov 7 03:49:43 2009 Subject: After sys/net80211 changes in r198931 laptop is no longer associating with AP In-Reply-To: <20091107023410.940601CC0E@ptavv.es.net> References: <20091107023410.940601CC0E@ptavv.es.net> Message-ID: <4AF4EE4D.70508@freebsd.org> Kevin Oberman wrote: >> Date: Thu, 5 Nov 2009 15:24:59 +0100 >> From: Paul B Mahol >> Sender: owner-freebsd-current@freebsd.org >> >> On 11/5/09, Alexandre "Sunny" Kovalenko wrote: >>> It seems that 8.0 discussion is still going on on @current... if I >>> should have posted this on @stable, please, feel free to chastise me as >>> appropriate. >>> >>> After updating to r198831 my laptop no longer associates with either of >>> two APs I have. Rolling back just 'sys/net80211' to r198443 fixes the >>> problem. >>> >>> Working system: >>> FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC1 FreeBSD 8.0-RC1 #0 >>> r198443M: Sat Oct 24 14:03:30 EDT 2009 >>> root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 >>> >>> Non-working system: >>> FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC2 FreeBSD 8.0-RC2 #0 >>> r198931: Wed Nov 4 20:56:16 EST 2009 >>> root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 >>> >>> APs are is: >>> SSID/MESH ID BSSID CHAN RATE S:N INT CAPS >>> AP_SSID 00:1f:33:3b:xx:xx 3 54M -68:-96 100 EP RSN WPS >>> WME >>> AP_SSID 00:1f:90:cb:xx:xx 8 54M -73:-96 100 EPS RSN WPA >>> ATH >>> >>> Relevant piece of wpa_supplicant.conf is: >>> >>> ctrl_interface=/var/run/wpa_supplicant >>> ctrl_interface_group=wheel >>> eapol_version=2 >>> >>> network={ >>> ssid="AP_SSID" >>> scan_ssid=1 >>> priority=1 >>> proto=WPA >>> key_mgmt=WPA-PSK >>> psk="Really secure something" >>> } >>> >>> APs are set not to broadcast SSID, but enabling broadcast does not >>> change much. >>> >>> Running wpa_supplicant with -d shows that it could not match AP_SSID. >>> >>> If there is anything else I can provide, please, let me know. >> What driver are you using? >> Looking into net80211 svn log for that time period I only see mesh hacks ... > > I am seeing exactly the same issue. Atheros 5212 with a non-broadcast > SSID. Similar wpa_supplicant.conf including 'scan_ssid=1'. 'ifconfig > wlan0' shows no ssid. Every time I boot my laptop at home, I need to > enter 'ifconfig wlan0 ssid MySSID'. As soon as I do this, it immediately > associates correctly. > > This was never a problem when I was running V7.0. Again, it only is an > issue when I am associating with my non-broadcast SSID at home. When at > work or traveling where the SSID is broadcast, wpa_supplicant works just > fine. > > If I ever get more time, I'll try to run wpa_supplicant with gdb and see > what is happenning, but I may not get a chance any time soon. I believe your problem is unrelated. I traced it to wpa_supplicant not doing the right thing--it doesn't pass the ssid's of ap into the code that issues scan requests so it's not possible for the 802.11 stack to send directed probe request frames (to elicit a response from the ap hiding it's ssid). You can verify this by sniffing packets during a scan. I have no idea why it works for you on 7.x as that code is woefully less capable than what's in 8.x. Fixing wpa_supplicant request architectural changes to the code. I can't recall if Jouni did this is in his devel branch. Sam From julian at elischer.org Sat Nov 7 04:57:24 2009 From: julian at elischer.org (Julian Elischer) Date: Sat Nov 7 04:57:31 2009 Subject: Help needed: TCP Wizards (was 8.0-RC1 NFS client timeout issue) In-Reply-To: References: <4AF0B7DF.9030405@freebsd.org> <030A8229-9707-4F70-B4BE-584F1BF9ECEC@FreeBSD.org> Message-ID: <4AF4FE32.5030501@elischer.org> Rick Macklem wrote: > > > On Thu, 5 Nov 2009, Rui Paulo wrote: > >> >> Are you running TSO? >> > I spoke too soon the last time. It appears that the setting of > net.inet.tcp.tso does not have any effect and that the Intel chip > on this machine doesn't do TSO. (I tried swapping it for a 3C905 and > the RSTs are showing up.) > > I guess it was just coincidence that the RSTs seemed to stop happening > for a while after I flipped the sysctl. > > I think the problem is related to the fact that the server end has > started to close down the connection (send a FIN), but the client > doesn't do anything until an RPC shows up and then tried to do a > new connection right after shutting down the old one. (Solaris10 > generates RSTs on the old connection and it seems that somehow > triggers one being sent to the server with the new port# instead > of the old port#.) > > I'm about to try doing a soshutdown() at the time the server sends > the FIN to the client, to see what effect that has. > > I still can't figure out where the pesky RST gets sent or I could > get a stack trace at that point and see what is doing it. > > Having lottsa fun with it, rick not as much fun as we are watching. :-) > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From oberman at es.net Sat Nov 7 05:26:12 2009 From: oberman at es.net (Kevin Oberman) Date: Sat Nov 7 05:26:20 2009 Subject: After sys/net80211 changes in r198931 laptop is no longer associating with AP In-Reply-To: Your message of "Fri, 06 Nov 2009 19:49:33 PST." <4AF4EE4D.70508@freebsd.org> Message-ID: <20091107052609.486B81CC0E@ptavv.es.net> > Date: Fri, 06 Nov 2009 19:49:33 -0800 > From: Sam Leffler > > Kevin Oberman wrote: > >> Date: Thu, 5 Nov 2009 15:24:59 +0100 > >> From: Paul B Mahol > >> Sender: owner-freebsd-current@freebsd.org > >> > >> On 11/5/09, Alexandre "Sunny" Kovalenko wrote: > >>> It seems that 8.0 discussion is still going on on @current... if I > >>> should have posted this on @stable, please, feel free to chastise me as > >>> appropriate. > >>> > >>> After updating to r198831 my laptop no longer associates with either of > >>> two APs I have. Rolling back just 'sys/net80211' to r198443 fixes the > >>> problem. > >>> > >>> Working system: > >>> FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC1 FreeBSD 8.0-RC1 #0 > >>> r198443M: Sat Oct 24 14:03:30 EDT 2009 > >>> root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 > >>> > >>> Non-working system: > >>> FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC2 FreeBSD 8.0-RC2 #0 > >>> r198931: Wed Nov 4 20:56:16 EST 2009 > >>> root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 > >>> > >>> APs are is: > >>> SSID/MESH ID BSSID CHAN RATE S:N INT CAPS > >>> AP_SSID 00:1f:33:3b:xx:xx 3 54M -68:-96 100 EP RSN WPS > >>> WME > >>> AP_SSID 00:1f:90:cb:xx:xx 8 54M -73:-96 100 EPS RSN WPA > >>> ATH > >>> > >>> Relevant piece of wpa_supplicant.conf is: > >>> > >>> ctrl_interface=/var/run/wpa_supplicant > >>> ctrl_interface_group=wheel > >>> eapol_version=2 > >>> > >>> network={ > >>> ssid="AP_SSID" > >>> scan_ssid=1 > >>> priority=1 > >>> proto=WPA > >>> key_mgmt=WPA-PSK > >>> psk="Really secure something" > >>> } > >>> > >>> APs are set not to broadcast SSID, but enabling broadcast does not > >>> change much. > >>> > >>> Running wpa_supplicant with -d shows that it could not match AP_SSID. > >>> > >>> If there is anything else I can provide, please, let me know. > >> What driver are you using? > >> Looking into net80211 svn log for that time period I only see mesh hacks ... > > > > I am seeing exactly the same issue. Atheros 5212 with a non-broadcast > > SSID. Similar wpa_supplicant.conf including 'scan_ssid=1'. 'ifconfig > > wlan0' shows no ssid. Every time I boot my laptop at home, I need to > > enter 'ifconfig wlan0 ssid MySSID'. As soon as I do this, it immediately > > associates correctly. > > > > This was never a problem when I was running V7.0. Again, it only is an > > issue when I am associating with my non-broadcast SSID at home. When at > > work or traveling where the SSID is broadcast, wpa_supplicant works just > > fine. > > > > If I ever get more time, I'll try to run wpa_supplicant with gdb and see > > what is happenning, but I may not get a chance any time soon. > > I believe your problem is unrelated. I traced it to wpa_supplicant not > doing the right thing--it doesn't pass the ssid's of ap into the code > that issues scan requests so it's not possible for the 802.11 stack to > send directed probe request frames (to elicit a response from the ap > hiding it's ssid). You can verify this by sniffing packets during a > scan. I have no idea why it works for you on 7.x as that code is > woefully less capable than what's in 8.x. > > Fixing wpa_supplicant request architectural changes to the code. I > can't recall if Jouni did this is in his devel branch. Yes, I guess so, although the symptoms are very similar, his worked on RC1 and failed on RC2. Mine has not worked since I moved from 7-Stable to head (before 8 was branched). Guess I'll have to keep kicking it or turn on broadcast on my AP. Thanks! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From serguey-grigoriev at yandex.ru Sat Nov 7 09:20:55 2009 From: serguey-grigoriev at yandex.ru (S.N.Grigoriev) Date: Sat Nov 7 09:21:01 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091106101943.5a763f43@ernst.jennejohn.org> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> Message-ID: <41361257585651@webmail39.yandex.ru> 06.11.09, 10:19, "Gary Jennejohn" wrote: > On Thu, 05 Nov 2009 21:34:23 +0300 > S.N.Grigoriev wrote: > > > > > > 05.11.09, 18:49, "Gary Jennejohn" : > > > > > On Thu, 05 Nov 2009 19:40:03 +0300 > > > S.N.Grigoriev wrote: > > > > > > > > 04.11.09, 16:51, "Alexandre \"Sunny\" Kovalenko" > > > > wrote: > > > > > > > > > On Wed, 2009-11-04 at 13:44 +0300, S.N.Grigoriev wrote: > > > > > > Hi list, > > > > > > > > > > > > I can confirm I've seen the same problem. After upgrading from 7-stable > > > > > > to 8.0-RC2 my machine just reboots during 'make buildworld' without > > > > > > diagnostics. But switching vm.pmap.pg_ps_enabled on/off does not > > > > > > work for me. My machine reboots every time I try to build world. > > > > > > I don't think I have a hardware problem: under 7-stable I can build > > > > > > world/kernel for both 7-stable and 8.0-RC2 without problems. > > > > > > > > > > > Is it by any chance possible that you have 'debug.debugger_on_panic' set > > > > > to '0' and no valid dump device configured? > > > > > > > > Hi Alexandre, > > > > > > > > I've not found 'debug.debugger_on_panic' variable in 'sysctl -a' > > > > output. Where cat I find it? All my sysctl variables are set by > > > > default. > > > Do you have "options DDB" in your kernel config file? > > > --- > > > Gary Jennejohn > > > > Hi Gary, > > > > my current kernel is GENERIC, so I don't have "options DDB". > > > Well, you need that option to see the DDB (debug) sysctl's. > --- I've recompiled the kernel with 'options DDB' (using 7-stable). The sysctl variable 'debug.debugger_on_panic' is now set to '1'. But I still have silent reboots every time I try to build world/kernel. 'savecore -v' reports: 'no dumps found'. What did I do incorrectly? -- Regards, S.Grigoriev. From fullermd at over-yonder.net Sat Nov 7 09:45:08 2009 From: fullermd at over-yonder.net (Matthew D. Fuller) Date: Sat Nov 7 09:45:15 2009 Subject: What is the state of ZFS on FreeBSD? In-Reply-To: <19188.8189.660106.589512@jerusalem.litteratus.org> References: <9e20d71e0911042247n216e9b02t7b317a55a9bbe131@mail.gmail.com> <19188.8189.660106.589512@jerusalem.litteratus.org> Message-ID: <20091107094506.GQ59090@over-yonder.net> On Fri, Nov 06, 2009 at 08:09:17AM -0500 I heard the voice of Robert Huff, and lo! it spake thus: > > I'll wait until it has a few more gigadays under its belt before > betting the ranch. A gigaday is 2.74 million years 8-} -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From gary.jennejohn at freenet.de Sat Nov 7 10:52:58 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Sat Nov 7 10:53:05 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <41361257585651@webmail39.yandex.ru> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> Message-ID: <20091107115256.3df62bc3@ernst.jennejohn.org> On Sat, 07 Nov 2009 12:20:51 +0300 S.N.Grigoriev wrote: > I've recompiled the kernel with 'options DDB' (using 7-stable). > The sysctl variable 'debug.debugger_on_panic' is now set to '1'. > But I still have silent reboots every time I try to build world/kernel. > 'savecore -v' reports: 'no dumps found'. What did I do incorrectly? > It could be that you also need "options KDB" for the kernel to enter ddb on panic, but I'm not 100% sure about that. Can't hurt to try it. Do you also have dumpdev defined in /etc/rc.conf? It's set to AUTO by default, but who knows whether that really works? --- Gary Jennejohn From bsam at ipt.ru Sat Nov 7 12:58:34 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Sat Nov 7 12:58:41 2009 Subject: [current] acroread: SIGSEGV In-Reply-To: <20091104172931.GI2331@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Wed\, 4 Nov 2009 19\:29\:31 +0200") References: <65275688@bb.ipt.ru> <20091103154747.GC2331@deviant.kiev.zoral.com.ua> <77755531@h30.sp.ipt.ru> <20091103214032.GF2331@deviant.kiev.zoral.com.ua> <99188273@bb.ipt.ru> <20091104172931.GI2331@deviant.kiev.zoral.com.ua> Message-ID: <20586408@bb.ipt.ru> On Wed, 4 Nov 2009 19:29:31 +0200 Kostik Belousov wrote: > On Wed, Nov 04, 2009 at 05:19:10PM +0300, Boris Samorodov wrote: > > On Tue, 3 Nov 2009 23:40:32 +0200 Kostik Belousov wrote: > > > On Wed, Nov 04, 2009 at 12:37:08AM +0300, Boris Samorodov wrote: > > > > On Tue, 3 Nov 2009 17:47:47 +0200 Kostik Belousov wrote: > > > > > On Tue, Nov 03, 2009 at 05:05:11PM +0300, Boris Samorodov wrote: > > > > > > Hello List, > > > > > > > > > > > > print/acroread8 doesn't work for me at 9-CURRENT: > > > > > > ----- > > > > > > % uname -a > > > > > > FreeBSD host.ipt.ru 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon Nov 2 15:15:13 MSK 2009 root@host.ipt.ru:/usr/obj/usr/src/sys/HOST > > > > > > % sysctl compat.linux > > > > > > compat.linux.oss_version: 198144 > > > > > > compat.linux.osrelease: 2.6.16 > > > > > > compat.linux.osname: Linux > > > > > > ------ > > > > > > > > > > > > Setting security.bsd.map_at_zero to 1 doesn't change anything. There is > > > > > > nothing at console/log files. Here is the tail of linux_kdump: > > > > > > ----- > > > > > > ... > > > > > > 78586 ld-2.9.so CALL linux_open(0x16fcd80,0,0x80d93000) > > > > > > 78586 ld-2.9.so NAMI "/compat/linux/var/db/fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > > > > 78586 ld-2.9.so NAMI "/var/db/fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > > > > 78586 ld-2.9.so RET linux_open JUSTRETURN > > > > > > 78586 ld-2.9.so CALL linux_open(0x16fcd80,0,0x80d93000) > > > > > > 78586 ld-2.9.so NAMI "/compat/linux/home/bsam/.fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > > > > 78586 ld-2.9.so NAMI "/home/bsam/.fontconfig/bde7b0a0234dc04d93e9475cbf44698a-x86.cache-2" > > > > > > 78586 ld-2.9.so RET linux_open 4 > > > > > > 78586 ld-2.9.so CALL linux_fstat64(0x4,0xbfbfcf8c,0x2e482ff4) > > > > > > 78586 ld-2.9.so RET linux_fstat64 0 > > > > > > 78586 ld-2.9.so CALL read(0x4,0x16fe160,0x60) > > > > > > 78586 ld-2.9.so GIO fd 4 read 96 bytes > > > > > > "\^D\M-|\^B\M-|\^B\0\0\0`\0\0\0 \0\0\0P\0\0\0\0\0\0\0P\0\0\0\^[b\M-TJ/usr/local/lib/X11/fonts/encodings/large\0\0\0\0\0\0\0\0\0\0\ > > > > > > \0\0\0\0\0\0\^Q\0\0\0\0\0\0\000" > > > > > > 78586 ld-2.9.so RET read 96/0x60 > > > > > > 78586 ld-2.9.so CALL close(0x4) > > > > > > 78586 ld-2.9.so RET close 0 > > > > > > 78586 ld-2.9.so CALL linux_mmap2(0,0x25000,0x3,0x22,0xffffffff,0) > > > > > > 78586 ld-2.9.so RET linux_mmap2 833982464/0x31b59000 > > > > > > 78586 ld-2.9.so PSIG SIGSEGV caught handler=0x83814b6 mask=0x0 code=0x0 > > > > > > 78586 ld-2.9.so CALL linux_rt_sigaction(0x6,0xbfbfcbf0,0xbfbfcb64,0x8) > > > > > > 78586 ld-2.9.so RET linux_rt_sigaction 0 > > > > > > 78586 ld-2.9.so CALL linux_exit_group(0x1) > > > > > > > > > It would be interesting to see which address faulted. > > > > > If not, can you do search for a kernel revision that broke acroread ? > > > > > Good starting points are r198507 and r198554. > > > > > > > > Were those revisions MFCed to RELENG_8_0? I've got the same for 8.0: > > > > ----- > > > > % uname -a > > > > FreeBSD h30.sp.ipt.ru 8.0-RC2 FreeBSD 8.0-RC2 #0: Sun Nov 1 18:57:33 MSK 2009 root@h30.sp.ipt.ru:/usr/obj/usr/src/sys/IN > > > > DUS i386 > > > > ----- > > > No. > > > It might be easier to bisect on releng/8.0 then. > > > > OK, I've found out that acroread works at 8-RC1 as of 2009-10-04 > > (with security.bsd.map_at_zero=1): > > ----- > > h31% uname -a 16:24 pts/0 > > FreeBSD h31.sp.ipt.ru 8.0-RC1 FreeBSD 8.0-RC1 #1: Sun Oct 4 02:19:42 MSD 2009 bsam@h31.sp.ipt.ru:/usr/obj/usr/src/sys/SHURAM i386 > > h31% sysctl security.bsd.map_at_zero 16:24 pts/0 > > security.bsd.map_at_zero: 1 > > ----- > > > > Can you give me suspisiuos commits to RELENG_8 to test (I don't have > > time ATM to do bisect builds)? > I do not have good guess. I would put a finger in the direction of the > imgact_elf.c changes. But, since the issue appears at run-time, after > the binary started, I doubt it. With the help from mezz@ it was found out that it's not a kernel but a new fontconfig (from marcurcom site) is to blame. Downgrading of fontconfig from 2.7.3 to 2.6.0 (from current ports tree) made acroread to work again. Seems not to be a kernel fault. Thanks for your help. -- WBR, Boris Samorodov (bsam) Research Engineer, http://www.ipt.ru Telephone & Internet SP FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From roberthuff at rcn.com Sat Nov 7 14:21:04 2009 From: roberthuff at rcn.com (Robert Huff) Date: Sat Nov 7 14:21:10 2009 Subject: What is the state of ZFS on FreeBSD? In-Reply-To: <20091107094506.GQ59090@over-yonder.net> References: <9e20d71e0911042247n216e9b02t7b317a55a9bbe131@mail.gmail.com> <19188.8189.660106.589512@jerusalem.litteratus.org> <20091107094506.GQ59090@over-yonder.net> Message-ID: <19189.33305.72539.876729@jerusalem.litteratus.org> Matthew D. Fuller writes: > On Fri, Nov 06, 2009 at 08:09:17AM -0500 I heard the voice of > Robert Huff, and lo! it spake thus: > > > > I'll wait until it has a few more gigadays under its belt before > > betting the ranch. > > A gigaday is 2.74 million years 8-} I didn't say "on a single amchine". Robert Huff From uqs at spoerlein.net Sat Nov 7 14:57:57 2009 From: uqs at spoerlein.net (Ulrich =?utf-8?B?U3DDtnJsZWlu?=) Date: Sat Nov 7 14:58:04 2009 Subject: Wanted: CVS repository before the SVN switch Message-ID: <20091107145754.GG34407@acme.spoerlein.net> Hi, current@ is probably the wrong place to ask, but I can't think of a better mailing list. What I'm looking for (and failed to secure myself) is a copy of the CVS repository (the ,v files) with the last non-subversion commit in it. Also, which revision number was the very first subversion commit? Thanks for any pointers! Uli From max at love2party.net Sat Nov 7 15:25:05 2009 From: max at love2party.net (Max Laier) Date: Sat Nov 7 15:25:12 2009 Subject: Wanted: CVS repository before the SVN switch In-Reply-To: <20091107145754.GG34407@acme.spoerlein.net> References: <20091107145754.GG34407@acme.spoerlein.net> Message-ID: <200911071625.01596.max@love2party.net> On Saturday 07 November 2009 15:57:54 Ulrich Sp?rlein wrote: > Hi, > > current@ is probably the wrong place to ask, but I can't think of a > better mailing list. > > What I'm looking for (and failed to secure myself) is a copy of the CVS > repository (the ,v files) with the last non-subversion commit in it. > Also, which revision number was the very first subversion commit? r179451 Date: Sat May 31 08:13:58 2008 There is a backup of the old ncvs repo on the FreeBSD infrastructure, but I'm not sure how to best make is available. Maybe somebody else can jump in. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From onemda at gmail.com Sat Nov 7 17:19:57 2009 From: onemda at gmail.com (Paul B Mahol) Date: Sat Nov 7 17:20:04 2009 Subject: After sys/net80211 changes in r198931 laptop is no longer associating with AP In-Reply-To: References: <1257426023.1436.18.camel@RabbitsDen> <3a142e750911050624q41a22ed5ud4f6919a2fac686e@mail.gmail.com> Message-ID: <3a142e750911070919s592980e1yfa420ea1d2654d52@mail.gmail.com> On 11/5/09, Alexandre "Sunny" Kovalenko wrote: > On Thu, Nov 5, 2009 at 9:24 AM, Paul B Mahol wrote: > >> On 11/5/09, Alexandre "Sunny" Kovalenko wrote: >> > It seems that 8.0 discussion is still going on on @current... if I >> > should have posted this on @stable, please, feel free to chastise me as >> > appropriate. >> > >> > After updating to r198831 my laptop no longer associates with either of >> > two APs I have. Rolling back just 'sys/net80211' to r198443 fixes the >> > problem. >> > >> > Working system: >> > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC1 FreeBSD 8.0-RC1 #0 >> > r198443M: Sat Oct 24 14:03:30 EDT 2009 >> > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 >> > >> > Non-working system: >> > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC2 FreeBSD 8.0-RC2 #0 >> > r198931: Wed Nov 4 20:56:16 EST 2009 >> > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 >> > >> > APs are is: >> > SSID/MESH ID BSSID CHAN RATE S:N INT CAPS >> > AP_SSID 00:1f:33:3b:xx:xx 3 54M -68:-96 100 EP RSN WPS >> > WME >> > AP_SSID 00:1f:90:cb:xx:xx 8 54M -73:-96 100 EPS RSN WPA >> > ATH >> > >> > Relevant piece of wpa_supplicant.conf is: >> > >> > ctrl_interface=/var/run/wpa_supplicant >> > ctrl_interface_group=wheel >> > eapol_version=2 >> > >> > network={ >> > ssid="AP_SSID" >> > scan_ssid=1 >> > priority=1 >> > proto=WPA >> > key_mgmt=WPA-PSK >> > psk="Really secure something" >> > } >> > >> > APs are set not to broadcast SSID, but enabling broadcast does not >> > change much. >> > >> > Running wpa_supplicant with -d shows that it could not match AP_SSID. >> > >> > If there is anything else I can provide, please, let me know. >> >> What driver are you using? >> Looking into net80211 svn log for that time period I only see mesh hacks >> ... >> > I am using ath (I am away from my laptop ATM -- I could provide part number > later today). > > I have seen mesh changes in there and that's when I gave up and posted -- I > am not > nearly enough qualified to figure out which ones could or could not impact > normal operation. You could track which commit introduced bug and/or use wlandebug and/or athdebug to see what is going on. From gaijin.k at gmail.com Sat Nov 7 17:45:08 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Sat Nov 7 17:45:16 2009 Subject: After sys/net80211 changes in r198931 laptop is no longer associating with AP In-Reply-To: <3a142e750911070919s592980e1yfa420ea1d2654d52@mail.gmail.com> References: <1257426023.1436.18.camel@RabbitsDen> <3a142e750911050624q41a22ed5ud4f6919a2fac686e@mail.gmail.com> <3a142e750911070919s592980e1yfa420ea1d2654d52@mail.gmail.com> Message-ID: <1257615903.1438.15.camel@RabbitsDen> On Sat, 2009-11-07 at 18:19 +0100, Paul B Mahol wrote: > On 11/5/09, Alexandre "Sunny" Kovalenko wrote: > > On Thu, Nov 5, 2009 at 9:24 AM, Paul B Mahol wrote: > > > >> On 11/5/09, Alexandre "Sunny" Kovalenko wrote: > >> > It seems that 8.0 discussion is still going on on @current... if I > >> > should have posted this on @stable, please, feel free to chastise me as > >> > appropriate. > >> > > >> > After updating to r198831 my laptop no longer associates with either of > >> > two APs I have. Rolling back just 'sys/net80211' to r198443 fixes the > >> > problem. > >> > > >> > Working system: > >> > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC1 FreeBSD 8.0-RC1 #0 > >> > r198443M: Sat Oct 24 14:03:30 EDT 2009 > >> > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 > >> > > >> > Non-working system: > >> > FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC2 FreeBSD 8.0-RC2 #0 > >> > r198931: Wed Nov 4 20:56:16 EST 2009 > >> > root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 > >> > > >> > APs are is: > >> > SSID/MESH ID BSSID CHAN RATE S:N INT CAPS > >> > AP_SSID 00:1f:33:3b:xx:xx 3 54M -68:-96 100 EP RSN WPS > >> > WME > >> > AP_SSID 00:1f:90:cb:xx:xx 8 54M -73:-96 100 EPS RSN WPA > >> > ATH > >> > > >> > Relevant piece of wpa_supplicant.conf is: > >> > > >> > ctrl_interface=/var/run/wpa_supplicant > >> > ctrl_interface_group=wheel > >> > eapol_version=2 > >> > > >> > network={ > >> > ssid="AP_SSID" > >> > scan_ssid=1 > >> > priority=1 > >> > proto=WPA > >> > key_mgmt=WPA-PSK > >> > psk="Really secure something" > >> > } > >> > > >> > APs are set not to broadcast SSID, but enabling broadcast does not > >> > change much. > >> > > >> > Running wpa_supplicant with -d shows that it could not match AP_SSID. > >> > > >> > If there is anything else I can provide, please, let me know. > >> > >> What driver are you using? > >> Looking into net80211 svn log for that time period I only see mesh hacks > >> ... > >> > > I am using ath (I am away from my laptop ATM -- I could provide part number > > later today). > > > > I have seen mesh changes in there and that's when I gave up and posted -- I > > am not > > nearly enough qualified to figure out which ones could or could not impact > > normal operation. > > You could track which commit introduced bug and/or use wlandebug > and/or athdebug to see what is going on. After doing revison-by-revision upgrade from r198443 to r198931, with the help from Rui Paulo, I am at r198931 and happily associated with the AP. Looks like a case of PEBKAC... I do apologize for the noise. -- Alexandre Kovalenko (????????? ?????????) From sam at errno.com Sat Nov 7 17:50:32 2009 From: sam at errno.com (Sam Leffler) Date: Sat Nov 7 17:50:39 2009 Subject: After sys/net80211 changes in r198931 laptop is no longer associating with AP In-Reply-To: <20091107052609.486B81CC0E@ptavv.es.net> References: <20091107052609.486B81CC0E@ptavv.es.net> Message-ID: <4AF5B365.8030508@errno.com> Kevin Oberman wrote: >> Date: Fri, 06 Nov 2009 19:49:33 -0800 >> From: Sam Leffler >> >> Kevin Oberman wrote: >>>> Date: Thu, 5 Nov 2009 15:24:59 +0100 >>>> From: Paul B Mahol >>>> Sender: owner-freebsd-current@freebsd.org >>>> >>>> On 11/5/09, Alexandre "Sunny" Kovalenko wrote: >>>>> It seems that 8.0 discussion is still going on on @current... if I >>>>> should have posted this on @stable, please, feel free to chastise me as >>>>> appropriate. >>>>> >>>>> After updating to r198831 my laptop no longer associates with either of >>>>> two APs I have. Rolling back just 'sys/net80211' to r198443 fixes the >>>>> problem. >>>>> >>>>> Working system: >>>>> FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC1 FreeBSD 8.0-RC1 #0 >>>>> r198443M: Sat Oct 24 14:03:30 EDT 2009 >>>>> root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 >>>>> >>>>> Non-working system: >>>>> FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC2 FreeBSD 8.0-RC2 #0 >>>>> r198931: Wed Nov 4 20:56:16 EST 2009 >>>>> root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 >>>>> >>>>> APs are is: >>>>> SSID/MESH ID BSSID CHAN RATE S:N INT CAPS >>>>> AP_SSID 00:1f:33:3b:xx:xx 3 54M -68:-96 100 EP RSN WPS >>>>> WME >>>>> AP_SSID 00:1f:90:cb:xx:xx 8 54M -73:-96 100 EPS RSN WPA >>>>> ATH >>>>> >>>>> Relevant piece of wpa_supplicant.conf is: >>>>> >>>>> ctrl_interface=/var/run/wpa_supplicant >>>>> ctrl_interface_group=wheel >>>>> eapol_version=2 >>>>> >>>>> network={ >>>>> ssid="AP_SSID" >>>>> scan_ssid=1 >>>>> priority=1 >>>>> proto=WPA >>>>> key_mgmt=WPA-PSK >>>>> psk="Really secure something" >>>>> } >>>>> >>>>> APs are set not to broadcast SSID, but enabling broadcast does not >>>>> change much. >>>>> >>>>> Running wpa_supplicant with -d shows that it could not match AP_SSID. >>>>> >>>>> If there is anything else I can provide, please, let me know. >>>> What driver are you using? >>>> Looking into net80211 svn log for that time period I only see mesh hacks ... >>> I am seeing exactly the same issue. Atheros 5212 with a non-broadcast >>> SSID. Similar wpa_supplicant.conf including 'scan_ssid=1'. 'ifconfig >>> wlan0' shows no ssid. Every time I boot my laptop at home, I need to >>> enter 'ifconfig wlan0 ssid MySSID'. As soon as I do this, it immediately >>> associates correctly. >>> >>> This was never a problem when I was running V7.0. Again, it only is an >>> issue when I am associating with my non-broadcast SSID at home. When at >>> work or traveling where the SSID is broadcast, wpa_supplicant works just >>> fine. >>> >>> If I ever get more time, I'll try to run wpa_supplicant with gdb and see >>> what is happenning, but I may not get a chance any time soon. >> I believe your problem is unrelated. I traced it to wpa_supplicant not >> doing the right thing--it doesn't pass the ssid's of ap into the code >> that issues scan requests so it's not possible for the 802.11 stack to >> send directed probe request frames (to elicit a response from the ap >> hiding it's ssid). You can verify this by sniffing packets during a >> scan. I have no idea why it works for you on 7.x as that code is >> woefully less capable than what's in 8.x. >> >> Fixing wpa_supplicant request architectural changes to the code. I >> can't recall if Jouni did this is in his devel branch. > > Yes, I guess so, although the symptoms are very similar, his worked on > RC1 and failed on RC2. Mine has not worked since I moved from 7-Stable > to head (before 8 was branched). Guess I'll have to keep kicking it or > turn on broadcast on my AP. Hiding ssid has zero security benefit and just causes extra traffic on the channel as stations must use directed probe requests to find your ap. Sam From gaijin.k at gmail.com Sat Nov 7 18:32:43 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Sat Nov 7 18:32:50 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091107115256.3df62bc3@ernst.jennejohn.org> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> Message-ID: <1257618758.1511.14.camel@RabbitsDen> On Sat, 2009-11-07 at 11:52 +0100, Gary Jennejohn wrote: > On Sat, 07 Nov 2009 12:20:51 +0300 > S.N.Grigoriev wrote: > > > I've recompiled the kernel with 'options DDB' (using 7-stable). > > The sysctl variable 'debug.debugger_on_panic' is now set to '1'. > > But I still have silent reboots every time I try to build world/kernel. > > 'savecore -v' reports: 'no dumps found'. What did I do incorrectly? > > > > It could be that you also need "options KDB" for the kernel to enter > ddb on panic, but I'm not 100% sure about that. > > Can't hurt to try it. > > Do you also have dumpdev defined in /etc/rc.conf? It's set to AUTO > by default, Apparently not on 8.0RC... RabbitsDen# grep dumpdev defaults/rc.conf dumpdev="NO" # Device to crashdump to (device name, AUTO, or NO). savecore_flags="" # Used if dumpdev is enabled above, and present. RabbitsDen# uname -a FreeBSD RabbitsDen.RabbitsLawn.verizon.net 8.0-RC2 FreeBSD 8.0-RC2 #0 r198931: Sat Nov 7 12:07:32 EST 2009 root@RabbitsDen.RabbitsLawn.verizon.net:/usr/obj/usr/src/sys/TPX60 i386 while on 7.2 twinhead# grep dumpdev defaults/rc.conf dumpdev="AUTO" # Device to crashdump to (device name, AUTO, or NO). savecore_flags="" # Used if dumpdev is enabled above, and present. twinhead# uname -a FreeBSD twinhead.rabbitslawn.verizon.net 7.2-RELEASE-p3 FreeBSD 7.2-RELEASE-p3 #0: Sat Aug 22 12:43:26 EDT 2009 root@twinhead.rabbitslawn.verizon.net:/usr/obj/usr/src/sys/TWINHEAD amd64 So one needs explicit dumpdev="AUTO" in the /etc/rc.conf. That caught me by surprise too... Sergey, I think it would be best if you follow http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN and the do an ultimate test: * quiesce your system * switch to the console * sync (few times, if you are really old school ;) * sysctl debug.kdb.panic=1 (this would *panic* the system and, given everything is set-up properly, produce the crash dump) if you do not have debug.kdb.panic sysctl, please, add option KDB to your kernel configuration. If you get crash dump from the kernel-induced panic and your system keeps rebooting without a trace, I would suspect some hardware testing might be in order. -- Alexandre Kovalenko (????????? ?????????) From alexbestms at math.uni-muenster.de Sat Nov 7 19:59:39 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sat Nov 7 19:59:46 2009 Subject: [patch] stop kdump from segfaulting with a linuxulator ktrace.out Message-ID: could somebody please commit this very simple patch to HEAD which has been around for almost 2 years, but never got committed (bin/120055). thanks in advance. alex -------------- next part -------------- Index: kdump.c =================================================================== --- kdump.c (revision 199016) +++ kdump.c (working copy) @@ -799,7 +799,7 @@ narg--; } } - while (narg) { + while (narg > 0) { print_number(ip,narg,c); } (void)putchar(')'); From attilio at freebsd.org Sat Nov 7 20:59:58 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sat Nov 7 21:00:05 2009 Subject: [patch] stop kdump from segfaulting with a linuxulator ktrace.out In-Reply-To: References: Message-ID: <3bbf2fe10911071259u47c18642x3259c9c4898f7ff0@mail.gmail.com> 2009/11/7 Alexander Best : > could somebody please commit this very simple patch to HEAD which has been > around for almost 2 years, but never got committed (bin/120055). Can you fill a PR with details and assign to me? Attilio -- Peace can only be achieved by understanding - A. Einstein From attilio at freebsd.org Sat Nov 7 21:47:55 2009 From: attilio at freebsd.org (Attilio Rao) Date: Sat Nov 7 21:48:02 2009 Subject: [patch] stop kdump from segfaulting with a linuxulator ktrace.out In-Reply-To: <3bbf2fe10911071259u47c18642x3259c9c4898f7ff0@mail.gmail.com> References: <3bbf2fe10911071259u47c18642x3259c9c4898f7ff0@mail.gmail.com> Message-ID: <3bbf2fe10911071347q18414334xf73597d948ed717f@mail.gmail.com> 2009/11/7 Attilio Rao : > 2009/11/7 Alexander Best : >> could somebody please commit this very simple patch to HEAD which has been >> around for almost 2 years, but never got committed (bin/120055). > > Can you fill a PR with details and assign to me? > Sorry, I didn't notice we already have 2 PRs on it. Fix committed as r199024. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From alexbestms at math.uni-muenster.de Sat Nov 7 22:05:44 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sat Nov 7 22:05:51 2009 Subject: [patch] stop kdump from segfaulting with a linuxulator ktrace.out In-Reply-To: <3bbf2fe10911071347q18414334xf73597d948ed717f@mail.gmail.com> Message-ID: Attilio Rao schrieb am 2009-11-07: > 2009/11/7 Attilio Rao : > > 2009/11/7 Alexander Best : > >> could somebody please commit this very simple patch to HEAD which > >> has been > >> around for almost 2 years, but never got committed (bin/120055). > > Can you fill a PR with details and assign to me? > Sorry, I didn't notice we already have 2 PRs on it. > Fix committed as r199024. > Thanks, > Attilio thanks a lot for committing this fix. :) i'll try to find some time and come up with patches for 8-,7- and 6-stable as well so this can get mfc'ed. cheers. alex From alexbestms at math.uni-muenster.de Sun Nov 8 00:02:40 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sun Nov 8 00:02:47 2009 Subject: [patch] prevent burncd from failing when device is busy while trying to eject Message-ID: this patch was submitted by Jaakko Heinonen in january, but didn't get committed to HEAD yet. when burncd is used in combination with the eject switch it doesn't care if the device is busy or not. if eject doesn't succeed burncd fails with EIO. the patch issues ATAPI_TEST_UNIT_READY by calling (ioctl(fd, CDIOCRESET). this gets repeated as long as the device isn't busy anymore or a timeout is being reached. this patch depends upon the removal of a bogus privilege check in sys/dev/ata/ata-cd.c would be nice if somebody could commit both patches. they've been tested for almost a year now and cause no breakage to occur. they can also safely be merged to 8-stable. in order to make it into 7- and 6-stable this other patch (bin/95979) has to be mfc'ed to those branches first. thanks in advance. alex -------------- next part -------------- Index: usr.sbin/burncd/burncd.c =================================================================== --- usr.sbin/burncd/burncd.c (revision 199016) +++ usr.sbin/burncd/burncd.c (working copy) @@ -65,6 +65,7 @@ void do_DAO(int fd, int, int); void do_TAO(int fd, int, int, int); void do_format(int, int, char *); +void wait_for_ready(int); int write_file(int fd, struct track_info *); int roundup_blocks(struct track_info *); void cue_ent(struct cdr_cue_entry *, int, int, int, int, int, int, int); @@ -219,6 +220,8 @@ break; last = pct; } + wait_for_ready(fd); + if (!quiet) printf("\n"); continue; @@ -322,6 +325,7 @@ err_set_exit(NULL); err(EX_IOERR, "ioctl(CDRIOCSETBLOCKSIZE)"); } + wait_for_ready(fd); if (eject) if (ioctl(fd, CDIOCEJECT) < 0) @@ -600,6 +604,27 @@ fprintf(stderr, "\n"); } +void +wait_for_ready(int fd) +{ + int timeout = 10 * 1000; + + while (timeout > 0) { + /* + * CDIOCRESET issues ATAPI_TEST_UNIT_READY command. + */ + if (ioctl(fd, CDIOCRESET) == 0) + return; + else if (errno != EBUSY) + err(EX_IOERR, "ioctl(CDIOCRESET)"); + + usleep(500 * 1000); + timeout -= 500; + } + + errx(EX_IOERR, "timed out while waiting for the drive to become ready"); +} + int write_file(int fd, struct track_info *track_info) { -------------- next part -------------- Index: sys/dev/ata/atapi-cd.c =================================================================== --- sys/dev/ata/atapi-cd.c (revision 199016) +++ sys/dev/ata/atapi-cd.c (working copy) @@ -256,13 +256,7 @@ cdp->flags |= F_LOCKED; break; - /* - * XXXRW: Why does this require privilege? - */ case CDIOCRESET: - error = priv_check(td, PRIV_DRIVER); - if (error) - break; error = acd_test_ready(dev); break; From alexbestms at math.uni-muenster.de Sun Nov 8 00:05:58 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sun Nov 8 00:06:11 2009 Subject: [patch] prevent burncd from failing when device is busy while trying to eject In-Reply-To: Message-ID: oh. forget to mention. here's the initial pr including the patches by Jaakko. i've merely hacked them into an up to date snapshot of HEAD: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/123693 cheers. alex From ksh at philpep.org Sun Nov 8 04:12:25 2009 From: ksh at philpep.org (Ksh J. Fry) Date: Sun Nov 8 04:13:34 2009 Subject: yacc(1) segfault Message-ID: <4AF64038.1050108@philpep.org> Anyone to confirm this bug on CURRENT : http://www.freebsd.org/cgi/query-pr.cgi?pr=140309 ? I don't think this bug come directly from yacc because when you compile yacc source from CURRENT on freebsd 7.2-RELEASE there is no bug. Bugs on CURRENT should be declared on freebsd bug tracker, or just here :/ ? From moonlightakkiy at yahoo.ca Sun Nov 8 10:22:52 2009 From: moonlightakkiy at yahoo.ca (PseudoCylon) Date: Sun Nov 8 10:22:59 2009 Subject: finished run driver for CURRENT Message-ID: <668402.59630.qm@web51804.mail.re2.yahoo.com> Hello everyone, I finished porting run driver to CURRENT (sort of). I posted it at freebsd fourums http://forums.freebsd.org/showpost.php?s=a3756a43cb6eca54dea97673ac8424e7&p=47936&postcount=28 Anyone interested in please try it out. __________________________________________________________________ Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca From hselasky at c2i.net Sun Nov 8 12:18:44 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Nov 8 12:18:52 2009 Subject: finished run driver for CURRENT In-Reply-To: <668402.59630.qm@web51804.mail.re2.yahoo.com> References: <668402.59630.qm@web51804.mail.re2.yahoo.com> Message-ID: <200911081320.04408.hselasky@c2i.net> On Sunday 08 November 2009 11:22:50 PseudoCylon wrote: > Hello everyone, > > I finished porting run driver to CURRENT (sort of). I posted it at freebsd > fourums > http://forums.freebsd.org/showpost.php?s=a3756a43cb6eca54dea97673ac8424e7&p >=47936&postcount=28 Anyone interested in please try it out. Just some comments: There is an ep_index field you can set, instead of specifying exactly which endpoint to use. Eg. UE_BULK_IN UE_ADDR_ANY ep_index = 0, /* will match first bulk_in + addr_any */ UE_BULK_OUT UE_ADDR_ANY ep_index = 2, /* will match third bulk_out + addr_any */ I'm not sure if the manufacturer will change those values? Else, do you have any other feedback on the new USB stack? Was it difficult? --HPS From bland at freebsd.org Sun Nov 8 13:24:46 2009 From: bland at freebsd.org (Alexander Nedotsukov) Date: Sun Nov 8 13:24:53 2009 Subject: umass problem. In-Reply-To: <200911070109.28595.hselasky@c2i.net> References: <202969100caf7f0bb8098572b0dad622@mail> <20d8e6193795d83f9ffa30ab94bf86eb@mail> <200911070109.28595.hselasky@c2i.net> Message-ID: Hans, It works. Perhaps you need to adjust debug output of ehci_poll_timeout () but otherwise it is fine. Just curious, is there is no way to detect lost interrupt in new usb stack quickly or check in the old one was not correct anyway? Thanks, Alexander. On 07.11.2009, at 9:09, Hans Petter Selasky wrote: > On Friday 06 November 2009 05:52:48 Alexander Nedotsukov wrote: >> Well I do. This is a regression in EHCI driver introduced along the >> new >> usb stack. Please review patch attached. >> >> Thanks, >> Alexander. >> > > Hi, > > Your patch has been committed to USB P4 with some modifications. > Please test! > > http://p4web.freebsd.org/chv.cgi?CH=170302 > > --HPS > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org > " From hselasky at c2i.net Sun Nov 8 13:31:03 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Sun Nov 8 13:31:10 2009 Subject: umass problem. In-Reply-To: References: <202969100caf7f0bb8098572b0dad622@mail> <200911070109.28595.hselasky@c2i.net> Message-ID: <200911081432.24072.hselasky@c2i.net> On Sunday 08 November 2009 14:24:39 Alexander Nedotsukov wrote: > Just curious, is there is no way to detect lost interrupt in new usb > stack quickly or check in the old one was not correct anyway? Hi, The check might not be correct, because new jobs can be queued immediately after the interrupt, and in that case it is not correct to check of the number of jobs is zero. --HPS From jontheil at gmail.com Sun Nov 8 14:25:17 2009 From: jontheil at gmail.com (Jon Theil Nielsen) Date: Sun Nov 8 14:25:24 2009 Subject: Samba problems on 8.0-RC2 Message-ID: <8f82c35c0911080555x6a0721fem7bc01d3e3ff30bcf@mail.gmail.com> Hi After running the latest upgrade for samba33, I cannot start it anymore. The error message is: *Starting smbd. /libexec/ld-elf.so.1: /usr/local/sbin/smbd: invalid PT_PHDR /usr/local/etc/rc.d/samba: WARNING: failed to start smbd* uname -a says: *mflserver2.mydomain.dk 8.0-RC2 FreeBSD 8.0-RC2 #0: Sun Nov 8 02:37:45 CET 2009 root@mydomain.dk:/usr/obj/usr/src/sys/SERVER2 i386* I'm not sure if this problem is related to the system or to samba itself. Best regards Jon Theil Nielsen From kostikbel at gmail.com Sun Nov 8 14:33:54 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Sun Nov 8 14:34:01 2009 Subject: Samba problems on 8.0-RC2 In-Reply-To: <8f82c35c0911080555x6a0721fem7bc01d3e3ff30bcf@mail.gmail.com> References: <8f82c35c0911080555x6a0721fem7bc01d3e3ff30bcf@mail.gmail.com> Message-ID: <20091108143348.GQ2331@deviant.kiev.zoral.com.ua> On Sun, Nov 08, 2009 at 02:55:49PM +0100, Jon Theil Nielsen wrote: > Hi > > After running the latest upgrade for samba33, I cannot start it anymore. The > error message is: > *Starting smbd. > /libexec/ld-elf.so.1: /usr/local/sbin/smbd: invalid PT_PHDR > /usr/local/etc/rc.d/samba: WARNING: failed to start smbd* > uname -a says: > *mflserver2.mydomain.dk 8.0-RC2 FreeBSD 8.0-RC2 #0: Sun Nov 8 02:37:45 CET > 2009 root@mydomain.dk:/usr/obj/usr/src/sys/SERVER2 i386* > I'm not sure if this problem is related to the system or to samba itself. I think you have old rtld, i.e. it misses r197931, but new kernel. Kernel maps PIE binaries at non-zero base address, that cannot be properly handled by old rtld. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091108/18233629/attachment.pgp From ganbold at micom.mng.net Sun Nov 8 15:50:27 2009 From: ganbold at micom.mng.net (Ganbold) Date: Sun Nov 8 15:50:45 2009 Subject: finished run driver for CURRENT In-Reply-To: <668402.59630.qm@web51804.mail.re2.yahoo.com> References: <668402.59630.qm@web51804.mail.re2.yahoo.com> Message-ID: <4AF6DFA9.8080303@micom.mng.net> PseudoCylon wrote: > Hello everyone, > > I finished porting run driver to CURRENT (sort of). I posted it at freebsd fourums > http://forums.freebsd.org/showpost.php?s=a3756a43cb6eca54dea97673ac8424e7&p=47936&postcount=28 > Anyone interested in please try it out. > Compile fails at line 2338 of if_run.c. /home/tsgan/run-CUR/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c: In function 'run_tx': /home/tsgan/run-CUR/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:2338: warning: comparison between pointer and integer *** Error code 1 Stop in /home/tsgan/run-CUR/sys/modules/usb/run. I guess it should either: struct ieee80211_channel *chan; chan = ni->ni_chan == IEEE80211_CHAN_ANYC ? ic->ic_curchan : ni->ni_chan; or: struct ieee80211_channel *chan; chan = ni->ni_chan == (ieee80211_channel *)IEEE80211_CHAN_ANY ? ic->ic_curchan : ni->ni_chan; I didn't test association with AP (don't have AP), system finds usb wireless Planex GW-USMicroN device: Nov 8 23:08:00 beastie kernel: ugen3.3: at usbus3 Nov 8 23:08:00 beastie kernel: run0: <1.0> on usbus3 Nov 8 23:08:00 beastie kernel: run0: MAC/BBP RT3070 (rev 0x0200), RF RT3020 (MIMO 1T1R), address 00:22:cf:03:e0:30 Nov 8 23:08:00 beastie kernel: run0: You are using firmware RT2870. run0: flags=8802 metric 0 mtu 2290 ether 00:22:cf:03:e0:30 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier regards, Ganbold Ts. > > __________________________________________________________________ > Be smarter than spam. See how smart SpamGuard is at giving junk email the boot with the All-new Yahoo! Mail. Click on Options in Mail and switch to New Mail today or register for free at http://mail.yahoo.ca > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > > > -- He who laughs last hasn't been told the terrible truth. From ubm.freebsd at googlemail.com Sun Nov 8 11:43:34 2009 From: ubm.freebsd at googlemail.com (Marc UBM Bocklet) Date: Sun Nov 8 15:59:24 2009 Subject: gjournal crash with external usb drive after unclean shutdown Message-ID: <20091108124330.b634560c.ubm.freebsd@gmail.com> Hiho! :-) Following an unclean shutdown (panic, related to a bad network card in another machine), my gjournaled external usb drive reliably crashes my system when I connect it. I got a core dump available for poking around further. Textdump info is attached. I'm not sure if the disk is dying or the journal somehow got into a really bad state. textdump is available on request! :-) Some information: FreeBSD greatsheep.chaos.base 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Fri Sep 25 19:16:18 CEST 2009 sheep@ubm.mine.nu:/usr/obj/usr/src/sys/SUBMARINE_SMP i386 Panic message: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x8a6c7000 fault code = supervisor read, page not present instruction pointer = 0x20:0x8086d3fe stack pointer = 0x28:0xdc71e964 frame pointer = 0x28:0xdc71e9e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2087 (g_journal da0) kgdb backtrace: (kgdb) bt #0 doadump () at pcpu.h:246 #1 0x804a4509 in db_fncall (dummy1=1, dummy2=0, dummy3=-2137208096, #dummy4=0xdc71e6fc "") at /usr/src/sys/ddb/db_command.c:548 2 #0x804a4901 in db_command (last_cmdp=0x809495bc, cmd_table=0x0, #dopager=1) at /usr/src/sys/ddb/db_command.c:445 3 0x804a4a5a in #db_command_loop () at /usr/src/sys/ddb/db_command.c:498 4 0x804a68cd #in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:229 5 #0x806358e6 in kdb_trap (type=12, code=0, tf=0xdc71e924) #at /usr/src/sys/kern/subr_kdb.c:535 6 0x8086f40f in trap_fatal #(frame=0xdc71e924, eva=2322362368) #at /usr/src/sys/i386/i386/trap.c:929 7 0x8086f6b0 in trap_pfault #(frame=0xdc71e924, usermode=0, eva=2322362368) #at /usr/src/sys/i386/i386/trap.c:851 8 0x808700c3 in trap #(frame=0xdc71e924) at /usr/src/sys/i386/i386/trap.c:533 9 0x80852feb #in calltrap () at /usr/src/sys/i386/i386/exception.s:165 10 0x8086d3fe #in generic_bcopy () at /usr/src/sys/i386/i386/support.s:498 Previous frame inner to this frame (corrupt stack?) dmesg lines leading up to the panic: ugen2.2: at usbus2 umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0800 umass0:1:0:-1: Attached to scbus1 da0 at umass-sim0 bus 0 scbus1 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 238475MB (488397168 512 byte sectors: 255H 63S/T 30401C) GEOM_JOURNAL: Journal 1159150689: da0 contains data. GEOM_JOURNAL: Journal 1159150689: da0 contains journal. GEOM_JOURNAL: Journal da0 consistent. (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): ILLEGAL REQUEST asc:20,0 (da0:umass-sim0:0:0:0): Invalid command operation code (da0:umass-sim0:0:0:0): Unretryable error GEOM_JOURNAL: BIO_FLUSH not supported by da0. GEOM_JOURNAL: Error while reading data from da0 (error=5). GEOM_JOURNAL: Error while reading data from da0 (error=5). Any help or pointers are appreciated, thanks in advance! :-) Bye Marc From alexbestms at math.uni-muenster.de Sun Nov 8 16:32:56 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sun Nov 8 16:33:03 2009 Subject: [patch] prevent burncd from failing when device is busy while trying to eject Message-ID: Alexander Motin just committed r199050. this might fix the issue which was being addressed by the patches i posted beforehand. i'll test to see if r199050 indeed takes care of the problem. for now please ignore the patches i posted beforehand. alex From jaz at goatcse.cx Sun Nov 8 20:59:32 2009 From: jaz at goatcse.cx (Jaz) Date: Sun Nov 8 20:59:39 2009 Subject: What is the state of ZFS on FreeBSD? In-Reply-To: <19189.33305.72539.876729@jerusalem.litteratus.org> References: <9e20d71e0911042247n216e9b02t7b317a55a9bbe131@mail.gmail.com> <19188.8189.660106.589512@jerusalem.litteratus.org> <20091107094506.GQ59090@over-yonder.net> <19189.33305.72539.876729@jerusalem.litteratus.org> Message-ID: <60a0e8260911081236l3162c2f1u99351720a85477d7@mail.gmail.com> I have been using a RAIDZ array on FreeBSD 7.0 amd64 since when 7.0 was first released and have been very happy with it. Great performance and no panics. 2009/11/8 Robert Huff : > Matthew D. Fuller writes: > >> ?On Fri, Nov 06, 2009 at 08:09:17AM -0500 I heard the voice of >> ?Robert Huff, and lo! it spake thus: >> ?> >> ?> I'll wait until it has a few more gigadays under its belt before >> ?> betting the ranch. >> >> ?A gigaday is 2.74 million years ? 8-} > > ? ? ? ?I didn't say "on a single amchine". > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Robert Huff > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From alexbestms at math.uni-muenster.de Sun Nov 8 21:16:42 2009 From: alexbestms at math.uni-muenster.de (Alexander Best) Date: Sun Nov 8 21:16:49 2009 Subject: [patch] prevent burncd from failing when device is busy while trying to eject Message-ID: i tested r199050 and the changes do NOT solve this problem. so the patches i posted still need to get committed. alex From don at siad.net Sun Nov 8 21:54:53 2009 From: don at siad.net (Don L. Belcher) Date: Sun Nov 8 21:54:59 2009 Subject: bootstrap loader problem Message-ID: <4AF73E2B.9010404@siad.net> John Baldwin wrote: > On Sunday 01 November 2009 7:35:55 pm Don L. Belcher wrote: > >> New Dell 1737 laptop >> >> The following error occurs with versions 7.2 release and later >> this message is from 8 RC2. All versions tried with 7.1 release and >> earlier work fine, I tried 7.1, 7.2 and 6.4. I rebuilt 8 RC2 CD with >> "loader" >> from 7.1 release and the 8 RC2 comes up O.K. now. >> I have two questions: >> 1) is anybody familiar with this problem >> 2) is it ok to install 8 RC2 using the 7.1 "loader" >> >> BTX loader 1.00 BTX version is 1.02 >> Consoles: internal video/keyboard >> panic: free: guard1 fail @ 0xbb797074 from (diretory path to) >> common/console.c:94 >> --> Press a key (etc) >> > > I have not seen that before. Can you try compiling a loader on 8 that > doesn't include GPT support? (cd /sys/boot; make > LOADER_NO_GPT_SUPPORT=yes) > Sorry it took so long. I installed to hard drive and the "loader" does not exhibit the problem. The problem only shows up when booting from CD ROM. The boot from CD ROM works OK using the "loader" built with make LOADER_NO_GPT_SUPPORT=yes > A loader from 7.1 should work ok on 8.0. > > From timur at FreeBSD.org Sun Nov 8 23:02:52 2009 From: timur at FreeBSD.org (Timur I. Bakeyev) Date: Sun Nov 8 23:02:59 2009 Subject: Samba problems on 8.0-RC2 In-Reply-To: <20091108143348.GQ2331@deviant.kiev.zoral.com.ua> References: <8f82c35c0911080555x6a0721fem7bc01d3e3ff30bcf@mail.gmail.com> <20091108143348.GQ2331@deviant.kiev.zoral.com.ua> Message-ID: <7d743c270911081436p52faac09l53f02e8b53adc1e9@mail.gmail.com> Kostik, do I understand you correctly, that your patch in back-merged into the 8-STABLE and will be present in the final released version of FreeBSD 8? With regards, Timur. On Sun, Nov 8, 2009 at 3:33 PM, Kostik Belousov wrote: > On Sun, Nov 08, 2009 at 02:55:49PM +0100, Jon Theil Nielsen wrote: >> Hi >> >> After running the latest upgrade for samba33, I cannot start it anymore. The >> error message is: >> *Starting smbd. >> /libexec/ld-elf.so.1: /usr/local/sbin/smbd: invalid PT_PHDR >> /usr/local/etc/rc.d/samba: WARNING: failed to start smbd* >> uname -a says: >> *mflserver2.mydomain.dk 8.0-RC2 FreeBSD 8.0-RC2 #0: Sun Nov ?8 02:37:45 CET >> 2009 ? ? root@mydomain.dk:/usr/obj/usr/src/sys/SERVER2 ?i386* >> I'm not sure if this problem is related to the system or to samba itself. > > I think you have old rtld, i.e. it misses r197931, but new kernel. > Kernel maps PIE binaries at non-zero base address, that cannot be > properly handled by old rtld. > From john.marshall at riverwillow.com.au Sun Nov 8 23:31:04 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Sun Nov 8 23:31:16 2009 Subject: Samba problems on 8.0-RC2 In-Reply-To: <20091108143348.GQ2331@deviant.kiev.zoral.com.ua> References: <8f82c35c0911080555x6a0721fem7bc01d3e3ff30bcf@mail.gmail.com> <20091108143348.GQ2331@deviant.kiev.zoral.com.ua> Message-ID: <20091108233052.GB1004@rwpc12.mby.riverwillow.net.au> On Sun, 08 Nov 2009, 16:33 +0200, Kostik Belousov wrote: > On Sun, Nov 08, 2009 at 02:55:49PM +0100, Jon Theil Nielsen wrote: > > Hi > > > > After running the latest upgrade for samba33, I cannot start it anymore. The > > error message is: > > *Starting smbd. > > /libexec/ld-elf.so.1: /usr/local/sbin/smbd: invalid PT_PHDR > > /usr/local/etc/rc.d/samba: WARNING: failed to start smbd* > > uname -a says: > > *mflserver2.mydomain.dk 8.0-RC2 FreeBSD 8.0-RC2 #0: Sun Nov 8 02:37:45 CET > > 2009 root@mydomain.dk:/usr/obj/usr/src/sys/SERVER2 i386* > > I'm not sure if this problem is related to the system or to samba itself. > > I think you have old rtld, i.e. it misses r197931, but new kernel. > Kernel maps PIE binaries at non-zero base address, that cannot be > properly handled by old rtld. I have been running Samba 3.3.n on 8.0/i386 all the way through from -BETA1 to -RC2 with no problems. After seeing your post I upgraded Samba to 3.3.9 and everything still works. I think Kostik is suggesting that perhaps you missed an installworld and your world and kernel are out of synch. -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091108/ae9abd47/attachment.pgp From moonlightakkiy at yahoo.ca Mon Nov 9 05:44:53 2009 From: moonlightakkiy at yahoo.ca (PseudoCylon) Date: Mon Nov 9 05:45:04 2009 Subject: finished run driver for CURRENT In-Reply-To: <668402.59630.qm@web51804.mail.re2.yahoo.com> References: <668402.59630.qm@web51804.mail.re2.yahoo.com> Message-ID: <366719.85562.qm@web51805.mail.re2.yahoo.com> ----- Original Message ---- > Subject: Re: finished run driver for CURRENT > > On Sunday 08 November 2009 11:22:50 PseudoCylon wrote: > > Hello everyone, > > > > I finished porting run driver to CURRENT (sort of). I posted it at freebsd > > fourums > > http://forums.freebsd.org/showpost.php?s=a3756a43cb6eca54dea97673ac8424e7&p > >=47936&postcount=28 Anyone interested in please try it out. > > Just some comments: > > There is an ep_index field you can set, instead of specifying exactly which > endpoint to use. > > Eg. > > UE_BULK_IN > UE_ADDR_ANY > > ep_index = 0, /* will match first bulk_in + addr_any */ > > > UE_BULK_OUT > UE_ADDR_ANY > > ep_index = 2, /* will match third bulk_out + addr_any */ > > I'm not sure if the manufacturer will change those values? > > Else, do you have any other feedback on the new USB stack? Was it difficult? > > --HPS > > Compile fails at line 2338 of if_run.c. > > /home/tsgan/run-CUR/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c: > In function 'run_tx': > /home/tsgan/run-CUR/sys/modules/usb/run/../../../dev/usb/wlan/if_run.c:2338: > warning: comparison between pointer and integer > *** Error code 1 > > Stop in /home/tsgan/run-CUR/sys/modules/usb/run. > > I guess it should either: > > struct ieee80211_channel *chan; > chan = ni->ni_chan == IEEE80211_CHAN_ANYC ? ic->ic_curchan : > ni->ni_chan; > > or: > > struct ieee80211_channel *chan; > chan = ni->ni_chan == (ieee80211_channel *)IEEE80211_CHAN_ANY ? > ic->ic_curchan : ni->ni_chan; > Thank you to everyone testing the driver. I've implemented all suggestions. __________________________________________________________________ Get a sneak peak at messages with a handy reading pane with All new Yahoo! Mail: http://ca.promos.yahoo.com/newmail/overview2/ From alteriks at gmail.com Mon Nov 9 08:48:21 2009 From: alteriks at gmail.com (alteriks@gmail.com) Date: Mon Nov 9 08:48:28 2009 Subject: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" In-Reply-To: <1256812598.39726.22.camel@balrog.2hip.net> References: <200910291044.21818.alteriks@gmail.com> <1256812598.39726.22.camel@balrog.2hip.net> Message-ID: <200911090948.12578.alteriks@gmail.com> On Thursday 29 October 2009 11:36:38 Robert Noland wrote: > Ok, if you are getting this... It may be helpful if you can run "zdb > -uuu zroot", so I can see what is going on with the root block pointer. > I think you should be able to do that from fixit. Also note that you > don't have the latest version of the loader if it is printing "lld", > though as long as all of the drives are detected it likely won't make a > difference. The "can't read MOS" error is the first attempt to read > from the pool after probing all of the devices to sort out the > configuration. Everything up to this point reads data directly from the > vdev labels on each drive, so this is the first time that it tries to > read from the pool. > Sorry I forgot about this part. Here is zdb -uuu zroot Uberblock magic = 0000000000bab10c version = 13 txg = 111 guid_sum = 14036990686815153767 timestamp = 1257636491 UTC = Sat Nov 7 23:28:11 2009 rootbp = [L0 DMU objset] 400L/200P DVA[0]=<0:110004a000:400> DVA[1]=<0:40038400:400> DVA[2]=<0:1980041c00:400> fletcher4 lzjb LE contiguous birth=111 fill=126 cksum=7e96f92e7:357c99e1eb9:b7d10db3a713:1ac2df05bd147a From ohartman at zedat.fu-berlin.de Mon Nov 9 08:50:43 2009 From: ohartman at zedat.fu-berlin.de (O. Hartmann) Date: Mon Nov 9 08:50:49 2009 Subject: Installer: missing GEOM/gpart capabilities slicing disk? Message-ID: <4AF7D802.7030401@zedat.fu-berlin.de> Hello. I try to install a fresh new FreeBSD 8.0-RC2 (from snapshot-DVD) on a barndnew harddrive. As far as I recall partitioning a disk is now done via gpart and the limitation of having only 8 (-2) partitions from a through h except b and c is now obsoleted. When dropping into the installation process, I realised that the 8 partition boundary is still present. Is there a howto (I searched the wiki and lists without success)? I read a lot about how to install FreeBSD on op of a complete ZFS infrastructure, but key issue seems to be a hands-on partitioning of the target haddrive via the fixit procedure. Any help is appreciated. Thanks in advance, Oliver From rnoland at FreeBSD.org Mon Nov 9 11:09:33 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Mon Nov 9 11:11:39 2009 Subject: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" In-Reply-To: <200911090948.12578.alteriks@gmail.com> References: <200910291044.21818.alteriks@gmail.com> <1256812598.39726.22.camel@balrog.2hip.net> <200911090948.12578.alteriks@gmail.com> Message-ID: <1257764963.27939.22.camel@balrog.2hip.net> On Mon, 2009-11-09 at 09:48 +0100, alteriks@gmail.com wrote: > On Thursday 29 October 2009 11:36:38 Robert Noland wrote: > > Ok, if you are getting this... It may be helpful if you can run "zdb > > -uuu zroot", so I can see what is going on with the root block pointer. > > I think you should be able to do that from fixit. Also note that you > > don't have the latest version of the loader if it is printing "lld", > > though as long as all of the drives are detected it likely won't make a > > difference. The "can't read MOS" error is the first attempt to read > > from the pool after probing all of the devices to sort out the > > configuration. Everything up to this point reads data directly from the > > vdev labels on each drive, so this is the first time that it tries to > > read from the pool. > > > Sorry I forgot about this part. > Here is zdb -uuu zroot > Uberblock > > magic = 0000000000bab10c > version = 13 > txg = 111 > guid_sum = 14036990686815153767 > timestamp = 1257636491 UTC = Sat Nov 7 23:28:11 2009 > rootbp = [L0 DMU objset] 400L/200P DVA[0]=<0:110004a000:400> > DVA[1]=<0:40038400:400> DVA[2]=<0:1980041c00:400> fletcher4 lzjb LE contiguous > birth=111 fill=126 cksum=7e96f92e7:357c99e1eb9:b7d10db3a713:1ac2df05bd147a Ok, that all looks correct for a raidz1. The logical size is 1024 bytes (400L) which is the uncompressed size of the data. The physical size is 512 bytes (200P) which is one sector on disk and the allocated size is 1024 bytes (512 bytes + 512 bytes of parity). For a raidz or mirror pool, the vdev is always 0, which represents the pseudo vdev, but it doesn't tell us for sure that all of the physical disks have been found. We should be able to verify that all the disks are present by summing the GUIDs. I'll have a look at that, so that we can at least warn if that is the case. If all of the physical devices are accounted for, then something is going wrong in the raidz read function, though I don't understand why it isn't more prolific if that is the case. i.e. why my raidz2 test is working fine. robert. -- Robert Noland FreeBSD From kostikbel at gmail.com Mon Nov 9 12:00:59 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Mon Nov 9 12:01:06 2009 Subject: Samba problems on 8.0-RC2 In-Reply-To: <7d743c270911081436p52faac09l53f02e8b53adc1e9@mail.gmail.com> References: <8f82c35c0911080555x6a0721fem7bc01d3e3ff30bcf@mail.gmail.com> <20091108143348.GQ2331@deviant.kiev.zoral.com.ua> <7d743c270911081436p52faac09l53f02e8b53adc1e9@mail.gmail.com> Message-ID: <20091109120054.GX2331@deviant.kiev.zoral.com.ua> On Sun, Nov 08, 2009 at 11:36:56PM +0100, Timur I. Bakeyev wrote: > Kostik, > > do I understand you correctly, that your patch in back-merged into the > 8-STABLE and will be present in the final released version of FreeBSD > 8? FreeBSD 8.0, yes. It is in 8.0 RC2 already. > > With regards, > Timur. > > On Sun, Nov 8, 2009 at 3:33 PM, Kostik Belousov wrote: > > On Sun, Nov 08, 2009 at 02:55:49PM +0100, Jon Theil Nielsen wrote: > >> Hi > >> > >> After running the latest upgrade for samba33, I cannot start it anymore. The > >> error message is: > >> *Starting smbd. > >> /libexec/ld-elf.so.1: /usr/local/sbin/smbd: invalid PT_PHDR > >> /usr/local/etc/rc.d/samba: WARNING: failed to start smbd* > >> uname -a says: > >> *mflserver2.mydomain.dk 8.0-RC2 FreeBSD 8.0-RC2 #0: Sun Nov ?8 02:37:45 CET > >> 2009 ? ? root@mydomain.dk:/usr/obj/usr/src/sys/SERVER2 ?i386* > >> I'm not sure if this problem is related to the system or to samba itself. > > > > I think you have old rtld, i.e. it misses r197931, but new kernel. > > Kernel maps PIE binaries at non-zero base address, that cannot be > > properly handled by old rtld. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091109/fb5d0482/attachment.pgp From mexas at bristol.ac.uk Mon Nov 9 13:21:19 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Mon Nov 9 13:21:34 2009 Subject: QMutex: mutex destroy failure: Device busy -> Seg fault in ports/x11/kdebase4-workspace Message-ID: <20091109132113.GA71911@mech-cluster241.men.bris.ac.uk> On ia64 HEAD while building x11/kdebase4-workspace I get lots of messages similar to: QWaitCondition: mutex destroy failure: Device busy QMutex: mutex destroy failure: Device busy culminating in this error: [skip] Linking CXX shared module ../../lib/kgreet_generic.so [ 10%] Built target kgreet_generic [ 10%] Generating org.kde.Kephal.Screens.xml QMutex: mutex destroy failure: Device busy [ 10%] Generating org.kde.Kephal.Outputs.xml [ 10%] Generating org.kde.Kephal.Configurations.xml Segmentation fault (core dumped) *** Error code 139 1 error *** Error code 2 Linking CXX shared module ../../lib/kgreet_winbind.so [ 10%] Built target kgreet_winbind 1 error *** Error code 2 1 error *** Error code 1 Stop in /usr/ports/x11/kdebase4-workspace. *** Error code 1 Please advise anton PS. I don't really need KDE at all. But Marcel reports that konqueror seems to be working. So I just want to build this. At present there's no secure graphical web browser for ia64. Until recently kazehakase was working. But now it doesn't, because security/nss doesn't build. And firefox doesn't build because of broken xpcom.. -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From jhb at freebsd.org Mon Nov 9 15:50:22 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Nov 9 15:50:43 2009 Subject: bootstrap loader problem In-Reply-To: <4AF73E2B.9010404@siad.net> References: <4AF73E2B.9010404@siad.net> Message-ID: <200911091021.26160.jhb@freebsd.org> On Sunday 08 November 2009 4:54:51 pm Don L. Belcher wrote: > John Baldwin wrote: > > On Sunday 01 November 2009 7:35:55 pm Don L. Belcher wrote: > > > >> New Dell 1737 laptop > >> > >> The following error occurs with versions 7.2 release and later > >> this message is from 8 RC2. All versions tried with 7.1 release and > >> earlier work fine, I tried 7.1, 7.2 and 6.4. I rebuilt 8 RC2 CD with > >> "loader" > >> from 7.1 release and the 8 RC2 comes up O.K. now. > >> I have two questions: > >> 1) is anybody familiar with this problem > >> 2) is it ok to install 8 RC2 using the 7.1 "loader" > >> > >> BTX loader 1.00 BTX version is 1.02 > >> Consoles: internal video/keyboard > >> panic: free: guard1 fail @ 0xbb797074 from (diretory path to) > >> common/console.c:94 > >> --> Press a key (etc) > >> > > > > I have not seen that before. Can you try compiling a loader on 8 that > > doesn't include GPT support? (cd /sys/boot; make > > LOADER_NO_GPT_SUPPORT=yes) > > > Sorry it took so long. I installed to hard drive and the "loader" does > not exhibit the problem. > The problem only shows up when booting from CD ROM. The boot from CD ROM > works > OK using the "loader" built with make LOADER_NO_GPT_SUPPORT=yes Bizarre, so somehow the BIOS for your CD drive is choking when the loader uses memory > 1MB for its malloc(). Hmmm, I know other people tested that change because I had to add bounce buffering to the CD drivers in the loader for buffers > 1MB. I could perhaps have a bug in the bounce buffering code that is trashing malloc's internal state if it does a buffer overrun of some sort. -- John Baldwin From tinderbox at freebsd.org Mon Nov 9 19:47:12 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Mon Nov 9 19:47:32 2009 Subject: [head tinderbox] failure on arm/arm Message-ID: <200911091854.nA9Is2dZ054553@freebsd-current.sentex.ca> TB --- 2009-11-09 18:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-09 18:15:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-11-09 18:15:00 - cleaning the object tree TB --- 2009-11-09 18:15:10 - cvsupping the source tree TB --- 2009-11-09 18:15:10 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2009-11-09 18:15:47 - building world TB --- 2009-11-09 18:15:47 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-09 18:15:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-09 18:15:47 - TARGET=arm TB --- 2009-11-09 18:15:47 - TARGET_ARCH=arm TB --- 2009-11-09 18:15:47 - TZ=UTC TB --- 2009-11-09 18:15:47 - __MAKE_CONF=/dev/null TB --- 2009-11-09 18:15:47 - cd /src TB --- 2009-11-09 18:15:47 - /usr/bin/make -B buildworld >>> World build started on Mon Nov 9 18:15:47 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] (cd /src/rescue/rescue/../../sbin/camcontrol && /usr/bin/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/camcontrol/ depend && /usr/bin/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/camcontrol/ camcontrol.o util.o modeedit.o) rm -f .depend mkdep -f .depend -a -DRESCUE /src/sbin/camcontrol/camcontrol.c /src/sbin/camcontrol/util.c /src/sbin/camcontrol/modeedit.c echo camcontrol: /obj/arm/src/tmp/usr/lib/libc.a /obj/arm/src/tmp/usr/lib/libcam.a /obj/arm/src/tmp/usr/lib/libsbuf.a /obj/arm/src/tmp/usr/lib/libutil.a >> .depend cc -O -pipe -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/camcontrol/camcontrol.c cc1: warnings being treated as errors /src/sbin/camcontrol/camcontrol.c: In function 'atapm': /src/sbin/camcontrol/camcontrol.c:4156: warning: comparison is always true due to limited range of data type *** Error code 1 Stop in /src/sbin/camcontrol. *** Error code 1 Stop in /obj/arm/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-09 18:54:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-09 18:54:02 - ERROR: failed to build world TB --- 2009-11-09 18:54:02 - 1693.77 user 465.28 system 2342.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full From mike at sentex.net Mon Nov 9 20:33:09 2009 From: mike at sentex.net (Mike Tancsa) Date: Mon Nov 9 20:33:16 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <20091017222314.GB19204@michelle.cdnetworks.com> References: <20091017170351.GZ29771@expo.ukrweb.net> <20091017222314.GB19204@michelle.cdnetworks.com> Message-ID: <200911092033.nA9KX6dD013378@lava.sentex.ca> At 05:23 PM 10/17/2009, Pyun YongHyeon wrote: >On Sat, Oct 17, 2009 at 08:03:51PM +0300, Mykola Dzham wrote: > > Hi! > > On hight network load system panics: > > > > GET BUF: dmamap load failure - 12 > > GET BUF: dmamap load failure - 12 > > GET BUF: dmamap load failure - 12 > > GET BUF: dmamap load failure - 12 > > GET BUF: dmamap load failure - 12 > > GET BUF: dmamap load failure - 12 > > GET BUF: dmamap load failure - 12 > > GET BUF: dmamap load failure - 12 > > GET BUF: dmamap load failure - 12 > > GET BUF: dmamap load failure - 12 > > GET BUF: dmamap load failure - 12 > > GET BUF: dmamap load failure - 12 > > GET BUF: dmamap load failure - 12 > > GET BUF: dmamap load failure - 12 > > GET BUF: dmamap load failure - 12 > > > >I believe this type of message should not be in fast path and it >should be rate-limited. > > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 2; apic id = 02 > > fault virtual address = 0x0 > > fault code = supervisor read data, page not present > > instruction pointer = 0x20:0xffffffff8025e4a5 > > stack pointer = 0x28:0xffffff87312f3a60 > > frame pointer = 0x28:0xffffff87312f3a80 > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, long 1, def32 0, gran 1 > > processor eflags = interrupt enabled, resume, IOPL = 0 > > current process = 0 (igb0 taskq) > > trap number = 12 > > panic: page fault > > cpuid = 2 > > KDB: stack backtrace: > > db_trace_self_wrapper() at 0xffffffff80185baa = > > db_trace_self_wrapper+0x2a > > panic() at 0xffffffff8020e992 = panic+0x182 > > trap_fatal() at 0xffffffff8040eefd = trap_fatal+0x2ad > > trap_pfault() at 0xffffffff8040f27d = trap_pfault+0x22d > > trap() at 0xffffffff8040fbff = trap+0x3cf > > calltrap() at 0xffffffff803f6e13 = calltrap+0x8 > > --- trap 0xc, rip = 0xffffffff8025e4a5, rsp = 0xffffff87312f3a60, rbp = > > 0xffffff87312f3a80 --- > > mb_free_ext() at 0xffffffff8025e4a5 = mb_free_ext+0x15 > > igb_get_buf() at 0xffffffff80a3a6e5 = igb_get_buf+0x2e5 > > igb_rxeof() at 0xffffffff80a3abd5 = igb_rxeof+0x425 > > igb_handle_rx() at 0xffffffff80a3b14b = igb_handle_rx+0x3b > > taskqueue_run() at 0xffffffff80243ec1 = taskqueue_run+0x91 > > taskqueue_thread_loop() at 0xffffffff8024404f = > > taskqueue_thread_loop+0x3f > > fork_exit() at 0xffffffff801ea9b2 = fork_exit+0x112 > > fork_trampoline() at 0xffffffff803f72ee = fork_trampoline+0xe > > --- trap 0, rip = 0, rsp = 0xffffff87312f3d30, rbp = 0 --- > > Uptime: 1h46m18s I was just about to start testing such hardware and found the bug fairly easy to reproduce. From /var/crash/core.txt panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq257: igb0) trap number = 12 panic: page fault cpuid = 5 Uptime: 30m34s Physical memory: 3560 MB Dumping 252 MB: 237 221 205 189 173 157 141 125 109 93 77 61 45 29 13 #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc08853b7 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc08856a9 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xc0bb6c7c in trap_fatal (frame=0xe75f8bd8, eva=16) at /usr/src/sys/i386/i386/trap.c:938 #4 0xc0bb6f00 in trap_pfault (frame=0xe75f8bd8, usermode=0, eva=16) at /usr/src/sys/i386/i386/trap.c:851 #5 0xc0bb7905 in trap (frame=0xe75f8bd8) at /usr/src/sys/i386/i386/trap.c:533 #6 0xc0b9a0cb in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0xc061eecc in igb_rxeof (rxr=0xc7400e00, count=100) at /usr/src/sys/dev/e1000/if_igb.c:4074 #8 0xc061f409 in igb_msix_rx (arg=0xc7400e00) at /usr/src/sys/dev/e1000/if_igb.c:1455 #9 0xc085d3db in intr_event_execute_handlers (p=0xc71527f8, ie=0xc748d680) at /usr/src/sys/kern/kern_intr.c:1165 #10 0xc085e97b in ithread_loop (arg=0xc74b8970) at /usr/src/sys/kern/kern_intr.c:1178 #11 0xc085b121 in fork_exit (callout=0xc085e910 , arg=0xc74b8970, frame=0xe75f8d38) at /usr/src/sys/kern/kern_fork.c:843 #12 0xc0b9a140 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) using the patch provided by Pyun YongHyeon provided, allows the second port on the dual port nic to partially work, but the box still panics after a bit of traffic. If I just use igb1, it seems to be ok. But if I try and bring up igb0 and use it, 'bad things happen'. Panic with patch below panic: page fault GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 05 fault virtual address = 0xc fault code = supervisor write, page not present instruction pointer = 0x20:0xc061f147 stack pointer = 0x28:0xe75f7c24 frame pointer = 0x28:0xe75f7c78 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq257: igb0) trap number = 12 panic: page fault cpuid = 5 Uptime: 8m27s Physical memory: 3560 MB Dumping 127 MB: 112 96 80 64 48 32 16 #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc0885597 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc0885889 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xc0bb6e1c in trap_fatal (frame=0xe75f7be4, eva=12) at /usr/src/sys/i386/i386/trap.c:938 #4 0xc0bb70a0 in trap_pfault (frame=0xe75f7be4, usermode=0, eva=12) at /usr/src/sys/i386/i386/trap.c:851 #5 0xc0bb7aa5 in trap (frame=0xe75f7be4) at /usr/src/sys/i386/i386/trap.c:533 #6 0xc0b9a26b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0xc061f147 in igb_rxeof (rxr=0xc7400e00, count=100) at /usr/src/sys/dev/e1000/if_igb.c:4130 #8 0xc061f679 in igb_msix_rx (arg=0xc7400e00) at /usr/src/sys/dev/e1000/if_igb.c:1456 #9 0xc085d5bb in intr_event_execute_handlers (p=0xc71527f8, ie=0xc748d680) at /usr/src/sys/kern/kern_intr.c:1165 #10 0xc085eb5b in ithread_loop (arg=0xc74b8960) at /usr/src/sys/kern/kern_intr.c:1178 #11 0xc085b301 in fork_exit (callout=0xc085eaf0 , arg=0xc74b8960, frame=0xe75f7d38) at /usr/src/sys/kern/kern_fork.c:843 #12 0xc0b9a2e0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From xcllnt at mac.com Mon Nov 9 20:37:06 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Nov 9 20:37:18 2009 Subject: Installer: missing GEOM/gpart capabilities slicing disk? In-Reply-To: <4AF7D802.7030401@zedat.fu-berlin.de> References: <4AF7D802.7030401@zedat.fu-berlin.de> Message-ID: <32916A26-60CF-457A-9F61-67DB295A4D9C@mac.com> On Nov 9, 2009, at 12:51 AM, O. Hartmann wrote: > Hello. > I try to install a fresh new FreeBSD 8.0-RC2 (from snapshot-DVD) on > a barndnew harddrive. As far as I recall partitioning a disk is now > done via gpart and the limitation of having only 8 (-2) partitions > from a through h except b and c is now obsoleted. When dropping into > the installation process, I realised that the 8 partition boundary > is still present. sysinstall does not use gpart nor the kernel interface that GEOM_PART exposes. FYI, -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Mon Nov 9 20:48:28 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Mon Nov 9 20:48:34 2009 Subject: QMutex: mutex destroy failure: Device busy -> Seg fault in ports/x11/kdebase4-workspace In-Reply-To: <20091109132113.GA71911@mech-cluster241.men.bris.ac.uk> References: <20091109132113.GA71911@mech-cluster241.men.bris.ac.uk> Message-ID: <3A2818E0-70DE-4837-9E47-08FFDF74072D@mac.com> On Nov 9, 2009, at 5:21 AM, Anton Shterenlikht wrote: > On ia64 HEAD while building x11/kdebase4-workspace > I get lots of messages similar to: > > QWaitCondition: mutex destroy failure: Device busy > QMutex: mutex destroy failure: Device busy > > culminating in this error: > > > [skip] > > > Linking CXX shared module ../../lib/kgreet_generic.so > [ 10%] Built target kgreet_generic > [ 10%] Generating org.kde.Kephal.Screens.xml > QMutex: mutex destroy failure: Device busy > [ 10%] Generating org.kde.Kephal.Outputs.xml > [ 10%] Generating org.kde.Kephal.Configurations.xml > Segmentation fault (core dumped) > *** Error code 139 > 1 error > *** Error code 2 > Linking CXX shared module ../../lib/kgreet_winbind.so > [ 10%] Built target kgreet_winbind > 1 error > *** Error code 2 > 1 error > *** Error code 1 > > Stop in /usr/ports/x11/kdebase4-workspace. > *** Error code 1 > > > Please advise > anton This is most likely a compiler bug. Just restart the build. I noticed some instability as well, but when restarting it would always move past the original problem. Please do not override compiler options. Just keep the default for now. > PS. I don't really need KDE at all. But Marcel reports that > konqueror seems to be working. So I just want to build this. I have some outstanding patches, you may want to apply. See attached. > At present there's no > secure graphical web browser for ia64. Until recently > kazehakase was working. But now it doesn't, because security/nss > doesn't build. And firefox doesn't build because of broken xpcom.. Firefox used to build. I'll see up with that... -- Marcel Moolenaar xcllnt@mac.com -------------- next part -------------- A non-text attachment was scrubbed... Name: ports.diff Type: application/octet-stream Size: 3626 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091109/4360c939/ports.obj From dave at dogwood.com Mon Nov 9 21:33:31 2009 From: dave at dogwood.com (David Cornejo) Date: Mon Nov 9 21:34:05 2009 Subject: sftp seg faulting Message-ID: <4ab61a80911091307o28ca4e78pa8e42441bcf2e604@mail.gmail.com> Hi, In recent builds of 9-CURRENT on amd64 platform I am getting seg faults that seem related to glob - same vintage works on x86. Attempting ls of remote directory: (gdb) run Starting program: /usr/bin/sftp white Connecting to white... Password: sftp> ls Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x0000000800f0f750 in glob2 (pathbuf=0x7fffffff5900, pathend=0x7fffffff5950, pathend_last=0x7fffffff78f8, pattern=Variable "pattern" is not available. ) at /usr/src/lib/libc/gen/glob.c:844 #2 0x0000000800f0fdb2 in glob0 (pattern=0x7fffffffb9c0, pglob=0x7fffffffdb60, limit=0x7fffffffd9c0) at /usr/src/lib/libc/gen/glob.c:533 #3 0x0000000800f100e7 in globexp1 (pattern=0x7fffffffb9c0, pglob=0x7fffffffdb60, limit=0x7fffffffd9c0) at /usr/src/lib/libc/gen/glob.c:253 #4 0x0000000800f1049c in glob (pattern=0x801a6804a "", flags=Variable "flags" is not available. ) at /usr/src/lib/libc/gen/glob.c:229 #5 0x00000000004037b2 in do_globbed_ls (conn=0x801a25740, path=0x801a68040 "/home/dave", strip_path=0x801a68040 "/home/dave", lflag=8) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:752 #6 0x0000000000405673 in parse_dispatch_command (conn=0x801a25740, cmd=0x7fffffffe1a0 "ls", pwd=0x7fffffffe190, err_abort=0) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:1328 #7 0x0000000000405b33 in interactive_loop (fd_in=Variable "fd_in" is not available. ) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:1594 #8 0x0000000000406111 in main (argc=27279464, argv=0x801a04068) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:1825 (gdb) frame 1 #1 0x0000000800f0f750 in glob2 (pathbuf=0x7fffffff5900, pathend=0x7fffffff5950, pathend_last=0x7fffffff78f8, pattern=Variable "pattern" is not available. ) at /usr/src/lib/libc/gen/glob.c:844 844 return((*pglob->gl_lstat)(buf, sb)); (gdb) print pglob $1 = (glob_t *) 0x7fffffffdb60 (gdb) print *pglob $2 = {gl_pathc = 0, gl_matchc = 0, gl_offs = 0, gl_flags = 216, gl_pathv = 0x0, gl_errfunc = 0, gl_closedir = 0x409180 , gl_readdir = 0x4090d0 , gl_opendir = 0x4090a0 , gl_lstat = 0, gl_stat = 0x7fffffffdca0} (gdb) Attempting to put file: (gdb) run Starting program: /usr/bin/sftp white Connecting to white... Password: sftp> put testfile Program received signal SIGSEGV, Segmentation fault. 0x000000000040347c in process_put (conn=0x801a25740, src=0x801a69060 "testfile", dst=Variable "dst" is not available. ) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:590 590 for (i = 0; g.gl_pathv[i] && !interrupted; i++) { (gdb) list 585 tmp_dst); 586 err = -1; 587 goto out; 588 } 589 590 for (i = 0; g.gl_pathv[i] && !interrupted; i++) { 591 if (stat(g.gl_pathv[i], &sb) == -1) { 592 err = -1; 593 error("stat %s: %s", g.gl_pathv[i], strerror(errno)); 594 continue; (gdb) bt #0 0x000000000040347c in process_put (conn=0x801a25740, src=0x801a69060 "testfile", dst=Variable "dst" is not available. ) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:590 #1 0x0000000000404c7d in parse_dispatch_command (conn=0x801a25740, cmd=0x7fffffffe1a0 "put testfile", pwd=0x7fffffffe190, err_abort=0) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:1267 #2 0x0000000000405b33 in interactive_loop (fd_in=Variable "fd_in" is not available. ) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:1594 #3 0x0000000000406111 in main (argc=27279464, argv=0x801a04068) at /usr/src/secure/usr.bin/sftp/../../../crypto/openssh/sftp.c:1825 (gdb) print g $1 = {gl_pathc = 1, gl_matchc = 0, gl_offs = 1, gl_flags = 0, gl_pathv = 0x0, gl_errfunc = 0x10, gl_closedir = 0x801a69070, gl_readdir = 0, gl_opendir = 0, gl_lstat = 0, gl_stat = 0} (gdb) I'm either unlucky in tracing through glob or haven't been persistent enough - anyone have any idea what might be going on? thanks, dave c From delphij at delphij.net Mon Nov 9 21:44:33 2009 From: delphij at delphij.net (Xin LI) Date: Mon Nov 9 21:44:40 2009 Subject: sftp seg faulting In-Reply-To: <4ab61a80911091307o28ca4e78pa8e42441bcf2e604@mail.gmail.com> References: <4ab61a80911091307o28ca4e78pa8e42441bcf2e604@mail.gmail.com> Message-ID: <4AF88D2F.3060306@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Cornejo wrote: > Hi, > > In recent builds of 9-CURRENT on amd64 platform I am getting seg > faults that seem related to glob - same vintage works on x86. > > Attempting ls of remote directory: > > (gdb) run > Starting program: /usr/bin/sftp white > Connecting to white... > Password: [...] > I'm either unlucky in tracing through glob or haven't been persistent > enough - anyone have any idea what might be going on? I am currently using a patch des@ sent to me (and also to this list) which worked fine. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkr4jS8ACgkQi+vbBBjt66C9rwCfY6HH8I4WzoOlgL4UQNSFKvrA QfsAoIO0/IihgHEio/N8iHvRYFdgPtJh =bBF5 -----END PGP SIGNATURE----- -------------- next part -------------- Index: crypto/openssh/ssh_namespace.h =================================================================== --- crypto/openssh/ssh_namespace.h (revision 197801) +++ crypto/openssh/ssh_namespace.h (working copy) @@ -223,6 +223,8 @@ #define get_u32 ssh_get_u32 #define get_u64 ssh_get_u64 #define getrrsetbyname ssh_getrrsetbyname +#define glob ssh_glob +#define globfree ssh_globfree #define host_hash ssh_host_hash #define hostfile_read_key ssh_hostfile_read_key #define hpdelim ssh_hpdelim Index: secure/lib/libssh/Makefile =================================================================== --- secure/lib/libssh/Makefile (revision 197801) +++ secure/lib/libssh/Makefile (working copy) @@ -19,7 +19,7 @@ # compiled directly into sshd instead. # Portability layer -SRCS+= bsd-misc.c fmt_scaled.c getrrsetbyname.c \ +SRCS+= bsd-misc.c fmt_scaled.c getrrsetbyname.c glob.c \ openssl-compat.c port-tun.c strtonum.c vis.c xcrypt.c xmmap.c # FreeBSD additions SRCS+= version.c From mike at sentex.net Mon Nov 9 22:15:41 2009 From: mike at sentex.net (Mike Tancsa) Date: Mon Nov 9 22:15:49 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <200911092033.nA9KX6dD013378@lava.sentex.ca> References: <20091017170351.GZ29771@expo.ukrweb.net> <20091017222314.GB19204@michelle.cdnetworks.com> <200911092033.nA9KX6dD013378@lava.sentex.ca> Message-ID: <200911092215.nA9MFeDP013898@lava.sentex.ca> At 03:33 PM 11/9/2009, Mike Tancsa wrote: And with dcons connected for debugging, a clean RELENG_8 just checked out, this comes up on the console when trying to bring up igb0 (igb1 works just fine) GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 GET BUF: dmamap load failure - 12 Fatal trap 12: page fault while in kernel mode cpuid = 5; apic id = 05 fault virtual address = 0x10 fault code = supervisor write, page not present instruction pointer = 0x20:0xc062838c stack pointer = 0x28:0xe75f4c18 frame pointer = 0x28:0xe75f4c78 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 12 (irq257: igb0) [thread pid 12 tid 100046 ] Stopped at igb_rxeof+0x1ec: orl $0x2,0x10(%esi) db> bt Tracing pid 12 tid 100046 td 0xc743a000 igb_rxeof(c74ca1c0,5,5,c74ca240,c749a700,...) at igb_rxeof+0x1ec igb_msix_rx(c74a4b00,0,109,d40f8d68,aa,...) at igb_msix_rx+0x29 intr_event_execute_handlers(c715f7f8,c749a700,c0c86d45,4f6,c749a770,...) at intr_event_execute_handlers+0x14b ithread_loop(c74b0a00,e75f4d38,90a490a4,e8c3e8c3,176b176b,...) at ithread_loop+0x6b fork_exit(c086b420,c74b0a00,e75f4d38) at fork_exit+0x91 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe75f4d70, ebp = 0 --- db> db> ps pid ppid pgrp uid state wmesg wchan cmd 1399 1383 1399 0 S+ select 0xc8a56924 ping 1383 1382 1383 0 S+ pause 0xc8b79300 csh 1382 1379 1382 1001 S+ wait 0xc8b79000 su 1379 1378 1379 1001 Ss+ pause 0xc8dd7da0 csh 1378 1376 1376 1001 S select 0xc7c1f224 sshd 1376 1231 1376 0 Ss sbwait 0xc8b83d98 sshd 1361 1360 1361 0 S+ ttyin 0xc7963070 csh 1360 1356 1360 1001 S+ wait 0xc7a69aa0 su 1356 1355 1356 1001 Ss+ pause 0xc7a6ada0 csh 1355 1353 1353 1001 S select 0xc7a80764 sshd 1353 1231 1353 0 Ss sbwait 0xc8b71a60 sshd 1344 1 1344 65 Ss select 0xc7965c64 dhclient 1326 1 1326 0 Ss select 0xc7a80264 dhclient 1305 1 1305 0 Ss+ ttyin 0xc71a7c70 getty 1304 1 1304 0 Ss+ ttyin 0xc71a8870 getty 1303 1 1303 0 Ss+ ttyin 0xc71a8a70 getty 1302 1 1302 0 Ss+ ttyin 0xc71a8c70 getty 1301 1 1301 0 Ss+ ttyin 0xc71a8e70 getty 1300 1 1300 0 Ss+ ttyin 0xc76f4070 getty 1299 1 1299 0 Ss+ ttyin 0xc76f4470 getty 1298 1 1298 0 Ss+ ttyin 0xc76f4a70 getty 1297 1 1297 0 Ss+ ttyin 0xc76f4870 getty 1275 1 1275 0 Ss select 0xc7946d64 inetd 1248 1 1248 0 Ss nanslp 0xc0dcdf04 cron 1242 1 1242 25 Ss pause 0xc7a69058 sendmail 1238 1 1238 0 Ss select 0xc79f4c24 sendmail 1231 1 1231 0 Ss select 0xc7946724 sshd 1209 1 1209 136 Ss select 0xc79f48a4 dhcpd 1166 1 1166 65534 Ss select 0xc79469a4 sdpd 1075 1074 1074 0 S (threaded) nfsd 100191 S rpcsvc 0xc7c206d0 nfsd: service 100190 S rpcsvc 0xc7c20710 nfsd: service 100189 S rpcsvc 0xc7946610 nfsd: service 100124 S rpcsvc 0xc7966510 nfsd: master 1074 1 1074 0 Ss select 0xc7946424 nfsd 1066 1 1066 0 Ss select 0xc79460e4 mountd 989 1 989 0 Ss select 0xc7946b24 rpcbind 972 1 972 0 Rs CPU 0 syslogd 795 1 795 0 Ss select 0xc7a80b24 devd 744 1 744 0 Ss select 0xc7a80464 moused 491 486 486 64 S bpf 0xc7959600 pflogd 486 1 486 0 Ss sbwait 0xc7bfcbfc pflogd 483 0 0 0 SL pftm 0xc87610f0 [pfpurge] 144 1 144 0 Ss pause 0xc7a6f5a8 adjkerntz 22 0 0 0 SL flowclea 0xc0de1d48 [flowcleaner] 21 0 0 0 SL sdflush 0xc0ded440 [softdepflush] 20 0 0 0 SL syncer 0xc0de1b50 [syncer] 19 0 0 0 SL vlruwt 0xc791e550 [vnlru] 18 0 0 0 SL psleep 0xc0de1888 [bufdaemon] 17 0 0 0 SL pgzero 0xc0dee114 [pagezero] 16 0 0 0 SL psleep 0xc0dedd3c [vmdaemon] 9 0 0 0 SL psleep 0xc0dedd04 [pagedaemon] 8 0 0 0 SL waiting_ 0xc0de363c [sctp_iterator] 7 0 0 0 SL - 0xc71a623c [fdc0] 6 0 0 0 SL - 0xc75de000 [fw0_probe] 15 0 0 0 SL (threaded) usb 100111 D - 0xc7951608 [ucom] 100110 D - 0xc79f7408 [ucom] 100091 D - 0xc75c6d0c [usbus7] 100090 D - 0xc75c6cdc [usbus7] 100089 D - 0xc75c6cac [usbus7] 100088 D - 0xc75c6c7c [usbus7] 100087 D - 0xc75b4dac [usbus6] 100086 D - 0xc75b4d7c [usbus6] 100085 D - 0xc75b4d4c [usbus6] 100084 D - 0xc75b4d1c [usbus6] 100083 D - 0xc759ddac [usbus5] 100082 D - 0xc759dd7c [usbus5] 100081 D - 0xc759dd4c [usbus5] 100080 D - 0xc759dd1c [usbus5] 100079 D - 0xc7583dac [usbus4] 100078 D - 0xc7583d7c [usbus4] 100077 D - 0xc7583d4c [usbus4] 100076 D - 0xc7583d1c [usbus4] 100073 D - 0xc7559d0c [usbus3] 100072 D - 0xc7559cdc [usbus3] 100071 D - 0xc7559cac [usbus3] 100070 D - 0xc7559c7c [usbus3] 100068 D - 0xc7544dac [usbus2] 100067 D - 0xc7544d7c [usbus2] 100066 D - 0xc7544d4c [usbus2] 100065 D - 0xc7544d1c [usbus2] 100063 D - 0xc752fdac [usbus1] 100062 D - 0xc752fd7c [usbus1] 100061 D - 0xc752fd4c [usbus1] 100060 D - 0xc752fd1c [usbus1] 100058 D - 0xc750fdac [usbus0] 100057 D - 0xc750fd7c [usbus0] 100056 D - 0xc750fd4c [usbus0] 100055 D - 0xc750fd1c [usbus0] 5 0 0 0 SL ccb_scan 0xc0d9a154 [xpt_thrd] 14 0 0 0 SL - 0xc0dcdd64 [yarrow] 4 0 0 0 SL - 0xc0dcbb24 [g_down] 3 0 0 0 SL - 0xc0dcbb20 [g_up] 2 0 0 0 SL - 0xc0dcbb18 [g_event] 13 0 0 0 SL (threaded) ng_queue 100028 D sleep 0xc0fd2160 [ng_queue7] 100027 D sleep 0xc0fd2160 [ng_queue6] 100026 D sleep 0xc0fd2160 [ng_queue5] 100025 D sleep 0xc0fd2160 [ng_queue4] 100024 D sleep 0xc0fd2160 [ng_queue3] 100023 D sleep 0xc0fd2160 [ng_queue2] 100022 D sleep 0xc0fd2160 [ng_queue1] 100021 D sleep 0xc0fd2160 [ng_queue0] 12 0 0 0 RL (threaded) intr 100099 I [swi0: uart] 100098 I [irq1: atkbd0] 100097 I [irq15: ata1] 100096 I [irq14: ata0] 100094 I [irq263: ahci0] 100075 I [irq23: uhci3 ehci1] 100074 I [irq17: siis0] 100069 I [irq18: ehci0 uhci5] 100064 I [irq19: fwohci0++] 100059 I [irq21: uhci1] 100054 I [irq16: uhci0+] 100051 I [irq261: igb1] 100050 I [irq260: igb1] 100049 I [irq259: igb1] 100047 I [irq258: igb0] 100046 Run CPU 5 [irq257: igb0] 100045 I [irq256: igb0] 100044 I [irq9: acpi0] 100043 I [swi6: Giant taskq] 100041 I [swi5: +] 100037 I [swi2: cambio] 100034 I [swi6: task queue] 100020 I [swi4: clock] 100019 I [swi4: clock] 100018 I [swi4: clock] 100017 I [swi4: clock] 100016 I [swi4: clock] 100015 I [swi4: clock] 100014 I [swi4: clock] 100013 I [swi4: clock] 100012 I [swi1: netisr 0] 100011 I [swi3: vm] 11 0 0 0 RL (threaded) idle 100010 CanRun [idle: cpu0] 100009 Run CPU 1 [idle: cpu1] 100008 Run CPU 2 [idle: cpu2] 100007 Run CPU 3 [idle: cpu3] 100006 Run CPU 4 [idle: cpu4] 100005 CanRun [idle: cpu5] 100004 Run CPU 6 [idle: cpu6] 100003 Run CPU 7 [idle: cpu7] 1 0 1 0 SLs wait 0xc715fd48 [init] 10 0 0 0 SL audit_wo 0xc0decd60 [audit] 0 0 0 0 SLs (threaded) kernel 100092 D - 0xc75e88c0 [fw0_taskq] 100053 D - 0xc74e1300 [em0 taskq] 100052 D - 0xc74e2680 [igb1 taskq] 100048 D - 0xc74ca1c0 [igb0 taskq] 100042 D - 0xc73a78c0 [thread taskq] 100040 D - 0xc73a7d00 [acpi_task_2] 100039 D - 0xc73a7d00 [acpi_task_1] 100038 D - 0xc73a7d00 [acpi_task_0] 100035 D - 0xc73a7e80 [kqueue taskq] 100032 D - 0xc71468c0 [firmware taskq] 100000 D sched 0xc0dcbbe0 [swapper] db> ---Mike >>_______________________________________________ >>freebsd-current@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-current >>To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > >-------------------------------------------------------------------- >Mike Tancsa, tel +1 519 651 3400 >Sentex Communications, mike@sentex.net >Providing Internet since 1994 www.sentex.net >Cambridge, Ontario Canada www.sentex.net/mike > >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From rmacklem at uoguelph.ca Mon Nov 9 22:57:05 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Mon Nov 9 22:57:11 2009 Subject: Help needed: TCP Wizards (was 8.0-RC1 NFS client timeout issue) In-Reply-To: <030A8229-9707-4F70-B4BE-584F1BF9ECEC@FreeBSD.org> References: <4AF0B7DF.9030405@freebsd.org> <030A8229-9707-4F70-B4BE-584F1BF9ECEC@FreeBSD.org> Message-ID: On Thu, 5 Nov 2009, Rui Paulo wrote: >> >> Now, here's where someone may be able to help? >> >> Grep'ng around, I found 4 places where the TCP stack called ip_output() >> (one in each of tcp_output.c, tcp_subr.c, tcp_timewait.c and >> tcp_syncache.c) and I put a printf like this just before them: >> if (flags & TH_RST) >> printf("sent a reset\n"); >> >> (The exact format varies for each, because of where the TCP >> header flags are and have different printf messages.) >> >> Now, the weird part is, that when the extraneous RST is sent to the >> server, I don't get any printf. (I do get a few of these, but at other >> times for what appear to be legitimate RSTs.) >> >> I can't see anywhere else that the TCP stack would send an RST and, so, >> I'm stuck w.r.t. figuring out what is sending them? >> Ok, if you found the previous posts entertaining, you might enjoy this:-) Along with the printfs before all the ip_output() calls, I added calls inside ip_output() and, eventually, even calls in front of every if_output(). Never got anything that indicated an RST was being sent. (I only saw what I expected, which was an ACK reply being sent.) BUT, at almost exactly the same time, there were the FreeBSD8-CURRENT client->server RST packets on the server's snoop trace. Hmm, did a tcpdump in the client and, yes, the same packets were there. To keep it simple, I had done the dinosaur thing and plugged both the client and server into an old, dumb 10baseT hub, so that I could easily watch everything. (I also had an uplink cable to the net port in the wall, so I could move kernels around from the machine I usually build them on.) I was at the point where I couldn't conceivably figure out where the FreeBSD-CURRENT client was generating these RSTs. So guess what... --> it wasn't I unplugged the uplink cable and, no more RSTs. I've been testing for long enough now, that I am 99% certain they were being injected. Since the from address and even the MAC address is correct, I can only assume that it was the Cisco switch that was doing the injecting. (How else could a packet come in from the Cisco switch with the MAC address of the FreeBSD-CURRENT client machine?) It was usually triggered by a server reboot. After the server reboot, the server does send an RST to the client. This seems legit, but might be what makes Cisco think that "bad things" are happening? (I have no access to info about the switches or their configuration, although the campus standard is for these ports to be used by a single desktop machine only and not a switch or hub.) So, it seems that FreeBSD8-CURRENT reconnects fine now, so long as nothing is injecting RSTs into the newly created connection. Well, I'm not sure I found this fun, but hopefully others are entertained:-), rick From jfvogel at gmail.com Mon Nov 9 22:59:54 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Mon Nov 9 23:00:01 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <200911092215.nA9MFeDP013898@lava.sentex.ca> References: <20091017170351.GZ29771@expo.ukrweb.net> <20091017222314.GB19204@michelle.cdnetworks.com> <200911092033.nA9KX6dD013378@lava.sentex.ca> <200911092215.nA9MFeDP013898@lava.sentex.ca> Message-ID: <2a41acea0911091459w2b4fec5djd64d0324557b7da2@mail.gmail.com> Are you using standard MTU or jumbo? That get_buf error is ENOMEM, looks like that happens when in the bus_dma stuff reserve_bounce_pages() fails. Are you maybe using a 32 bit kernel? I have not seen this failure here. Jack On Mon, Nov 9, 2009 at 2:15 PM, Mike Tancsa wrote: > At 03:33 PM 11/9/2009, Mike Tancsa wrote: > > > And with dcons connected for debugging, a clean RELENG_8 just checked out, > this comes up on the console when trying to bring up igb0 (igb1 works just > fine) > > > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 5; apic id = 05 > fault virtual address = 0x10 > > fault code = supervisor write, page not present > instruction pointer = 0x20:0xc062838c > stack pointer = 0x28:0xe75f4c18 > frame pointer = 0x28:0xe75f4c78 > > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (irq257: igb0) > [thread pid 12 tid 100046 ] > Stopped at igb_rxeof+0x1ec: orl $0x2,0x10(%esi) > db> bt > Tracing pid 12 tid 100046 td 0xc743a000 > igb_rxeof(c74ca1c0,5,5,c74ca240,c749a700,...) at igb_rxeof+0x1ec > igb_msix_rx(c74a4b00,0,109,d40f8d68,aa,...) at igb_msix_rx+0x29 > intr_event_execute_handlers(c715f7f8,c749a700,c0c86d45,4f6,c749a770,...) at > intr_event_execute_handlers+0x14b > ithread_loop(c74b0a00,e75f4d38,90a490a4,e8c3e8c3,176b176b,...) at > ithread_loop+0x6b > fork_exit(c086b420,c74b0a00,e75f4d38) at fork_exit+0x91 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe75f4d70, ebp = 0 --- > db> > > db> ps > pid ppid pgrp uid state wmesg wchan cmd > 1399 1383 1399 0 S+ select 0xc8a56924 ping > 1383 1382 1383 0 S+ pause 0xc8b79300 csh > 1382 1379 1382 1001 S+ wait 0xc8b79000 su > 1379 1378 1379 1001 Ss+ pause 0xc8dd7da0 csh > 1378 1376 1376 1001 S select 0xc7c1f224 sshd > 1376 1231 1376 0 Ss sbwait 0xc8b83d98 sshd > 1361 1360 1361 0 S+ ttyin 0xc7963070 csh > 1360 1356 1360 1001 S+ wait 0xc7a69aa0 su > 1356 1355 1356 1001 Ss+ pause 0xc7a6ada0 csh > 1355 1353 1353 1001 S select 0xc7a80764 sshd > 1353 1231 1353 0 Ss sbwait 0xc8b71a60 sshd > 1344 1 1344 65 Ss select 0xc7965c64 dhclient > 1326 1 1326 0 Ss select 0xc7a80264 dhclient > 1305 1 1305 0 Ss+ ttyin 0xc71a7c70 getty > 1304 1 1304 0 Ss+ ttyin 0xc71a8870 getty > 1303 1 1303 0 Ss+ ttyin 0xc71a8a70 getty > 1302 1 1302 0 Ss+ ttyin 0xc71a8c70 getty > 1301 1 1301 0 Ss+ ttyin 0xc71a8e70 getty > 1300 1 1300 0 Ss+ ttyin 0xc76f4070 getty > 1299 1 1299 0 Ss+ ttyin 0xc76f4470 getty > 1298 1 1298 0 Ss+ ttyin 0xc76f4a70 getty > 1297 1 1297 0 Ss+ ttyin 0xc76f4870 getty > 1275 1 1275 0 Ss select 0xc7946d64 inetd > 1248 1 1248 0 Ss nanslp 0xc0dcdf04 cron > 1242 1 1242 25 Ss pause 0xc7a69058 sendmail > 1238 1 1238 0 Ss select 0xc79f4c24 sendmail > 1231 1 1231 0 Ss select 0xc7946724 sshd > 1209 1 1209 136 Ss select 0xc79f48a4 dhcpd > 1166 1 1166 65534 Ss select 0xc79469a4 sdpd > 1075 1074 1074 0 S (threaded) nfsd > 100191 S rpcsvc 0xc7c206d0 nfsd: service > 100190 S rpcsvc 0xc7c20710 nfsd: service > 100189 S rpcsvc 0xc7946610 nfsd: service > 100124 S rpcsvc 0xc7966510 nfsd: master > 1074 1 1074 0 Ss select 0xc7946424 nfsd > 1066 1 1066 0 Ss select 0xc79460e4 mountd > 989 1 989 0 Ss select 0xc7946b24 rpcbind > 972 1 972 0 Rs CPU 0 syslogd > 795 1 795 0 Ss select 0xc7a80b24 devd > 744 1 744 0 Ss select 0xc7a80464 moused > 491 486 486 64 S bpf 0xc7959600 pflogd > 486 1 486 0 Ss sbwait 0xc7bfcbfc pflogd > 483 0 0 0 SL pftm 0xc87610f0 [pfpurge] > 144 1 144 0 Ss pause 0xc7a6f5a8 adjkerntz > 22 0 0 0 SL flowclea 0xc0de1d48 [flowcleaner] > 21 0 0 0 SL sdflush 0xc0ded440 [softdepflush] > 20 0 0 0 SL syncer 0xc0de1b50 [syncer] > 19 0 0 0 SL vlruwt 0xc791e550 [vnlru] > 18 0 0 0 SL psleep 0xc0de1888 [bufdaemon] > 17 0 0 0 SL pgzero 0xc0dee114 [pagezero] > 16 0 0 0 SL psleep 0xc0dedd3c [vmdaemon] > 9 0 0 0 SL psleep 0xc0dedd04 [pagedaemon] > 8 0 0 0 SL waiting_ 0xc0de363c [sctp_iterator] > 7 0 0 0 SL - 0xc71a623c [fdc0] > 6 0 0 0 SL - 0xc75de000 [fw0_probe] > 15 0 0 0 SL (threaded) usb > 100111 D - 0xc7951608 [ucom] > 100110 D - 0xc79f7408 [ucom] > 100091 D - 0xc75c6d0c [usbus7] > 100090 D - 0xc75c6cdc [usbus7] > 100089 D - 0xc75c6cac [usbus7] > 100088 D - 0xc75c6c7c [usbus7] > 100087 D - 0xc75b4dac [usbus6] > 100086 D - 0xc75b4d7c [usbus6] > 100085 D - 0xc75b4d4c [usbus6] > 100084 D - 0xc75b4d1c [usbus6] > 100083 D - 0xc759ddac [usbus5] > 100082 D - 0xc759dd7c [usbus5] > 100081 D - 0xc759dd4c [usbus5] > 100080 D - 0xc759dd1c [usbus5] > 100079 D - 0xc7583dac [usbus4] > 100078 D - 0xc7583d7c [usbus4] > 100077 D - 0xc7583d4c [usbus4] > 100076 D - 0xc7583d1c [usbus4] > 100073 D - 0xc7559d0c [usbus3] > 100072 D - 0xc7559cdc [usbus3] > 100071 D - 0xc7559cac [usbus3] > 100070 D - 0xc7559c7c [usbus3] > 100068 D - 0xc7544dac [usbus2] > 100067 D - 0xc7544d7c [usbus2] > 100066 D - 0xc7544d4c [usbus2] > 100065 D - 0xc7544d1c [usbus2] > 100063 D - 0xc752fdac [usbus1] > 100062 D - 0xc752fd7c [usbus1] > 100061 D - 0xc752fd4c [usbus1] > 100060 D - 0xc752fd1c [usbus1] > 100058 D - 0xc750fdac [usbus0] > 100057 D - 0xc750fd7c [usbus0] > 100056 D - 0xc750fd4c [usbus0] > 100055 D - 0xc750fd1c [usbus0] > 5 0 0 0 SL ccb_scan 0xc0d9a154 [xpt_thrd] > 14 0 0 0 SL - 0xc0dcdd64 [yarrow] > 4 0 0 0 SL - 0xc0dcbb24 [g_down] > 3 0 0 0 SL - 0xc0dcbb20 [g_up] > 2 0 0 0 SL - 0xc0dcbb18 [g_event] > 13 0 0 0 SL (threaded) ng_queue > 100028 D sleep 0xc0fd2160 [ng_queue7] > 100027 D sleep 0xc0fd2160 [ng_queue6] > 100026 D sleep 0xc0fd2160 [ng_queue5] > 100025 D sleep 0xc0fd2160 [ng_queue4] > 100024 D sleep 0xc0fd2160 [ng_queue3] > 100023 D sleep 0xc0fd2160 [ng_queue2] > 100022 D sleep 0xc0fd2160 [ng_queue1] > 100021 D sleep 0xc0fd2160 [ng_queue0] > 12 0 0 0 RL (threaded) intr > 100099 I [swi0: uart] > 100098 I [irq1: atkbd0] > 100097 I [irq15: ata1] > 100096 I [irq14: ata0] > 100094 I [irq263: ahci0] > 100075 I [irq23: uhci3 ehci1] > 100074 I [irq17: siis0] > 100069 I [irq18: ehci0 uhci5] > 100064 I [irq19: fwohci0++] > 100059 I [irq21: uhci1] > 100054 I [irq16: uhci0+] > 100051 I [irq261: igb1] > 100050 I [irq260: igb1] > 100049 I [irq259: igb1] > 100047 I [irq258: igb0] > 100046 Run CPU 5 [irq257: igb0] > 100045 I [irq256: igb0] > 100044 I [irq9: acpi0] > 100043 I [swi6: Giant taskq] > 100041 I [swi5: +] > 100037 I [swi2: cambio] > 100034 I [swi6: task queue] > 100020 I [swi4: clock] > 100019 I [swi4: clock] > 100018 I [swi4: clock] > 100017 I [swi4: clock] > 100016 I [swi4: clock] > 100015 I [swi4: clock] > 100014 I [swi4: clock] > 100013 I [swi4: clock] > 100012 I [swi1: netisr 0] > 100011 I [swi3: vm] > 11 0 0 0 RL (threaded) idle > 100010 CanRun [idle: cpu0] > 100009 Run CPU 1 [idle: cpu1] > 100008 Run CPU 2 [idle: cpu2] > 100007 Run CPU 3 [idle: cpu3] > 100006 Run CPU 4 [idle: cpu4] > 100005 CanRun [idle: cpu5] > 100004 Run CPU 6 [idle: cpu6] > 100003 Run CPU 7 [idle: cpu7] > 1 0 1 0 SLs wait 0xc715fd48 [init] > 10 0 0 0 SL audit_wo 0xc0decd60 [audit] > 0 0 0 0 SLs (threaded) kernel > 100092 D - 0xc75e88c0 [fw0_taskq] > 100053 D - 0xc74e1300 [em0 taskq] > 100052 D - 0xc74e2680 [igb1 taskq] > 100048 D - 0xc74ca1c0 [igb0 taskq] > 100042 D - 0xc73a78c0 [thread taskq] > 100040 D - 0xc73a7d00 [acpi_task_2] > 100039 D - 0xc73a7d00 [acpi_task_1] > 100038 D - 0xc73a7d00 [acpi_task_0] > 100035 D - 0xc73a7e80 [kqueue taskq] > 100032 D - 0xc71468c0 [firmware taskq] > 100000 D sched 0xc0dcbbe0 [swapper] > db> > > > ---Mike > > > > > > > > > > _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to " >>> freebsd-current-unsubscribe@freebsd.org" >>> >> >> -------------------------------------------------------------------- >> Mike Tancsa, tel +1 519 651 3400 >> Sentex Communications, mike@sentex.net >> Providing Internet since 1994 www.sentex.net >> Cambridge, Ontario Canada www.sentex.net/mike >> >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org >> " >> > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > From pyunyh at gmail.com Mon Nov 9 23:25:41 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Mon Nov 9 23:25:47 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <200911092215.nA9MFeDP013898@lava.sentex.ca> References: <20091017170351.GZ29771@expo.ukrweb.net> <20091017222314.GB19204@michelle.cdnetworks.com> <200911092033.nA9KX6dD013378@lava.sentex.ca> <200911092215.nA9MFeDP013898@lava.sentex.ca> Message-ID: <20091109232500.GB1141@michelle.cdnetworks.com> On Mon, Nov 09, 2009 at 05:15:44PM -0500, Mike Tancsa wrote: > At 03:33 PM 11/9/2009, Mike Tancsa wrote: > > > And with dcons connected for debugging, a clean RELENG_8 just checked > out, this comes up on the console when trying to bring up igb0 (igb1 > works just fine) > > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > GET BUF: dmamap load failure - 12 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 5; apic id = 05 > fault virtual address = 0x10 > fault code = supervisor write, page not present > instruction pointer = 0x20:0xc062838c > stack pointer = 0x28:0xe75f4c18 > frame pointer = 0x28:0xe75f4c78 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 12 (irq257: igb0) > [thread pid 12 tid 100046 ] > Stopped at igb_rxeof+0x1ec: orl $0x2,0x10(%esi) > db> bt > Tracing pid 12 tid 100046 td 0xc743a000 > igb_rxeof(c74ca1c0,5,5,c74ca240,c749a700,...) at igb_rxeof+0x1ec > igb_msix_rx(c74a4b00,0,109,d40f8d68,aa,...) at igb_msix_rx+0x29 > intr_event_execute_handlers(c715f7f8,c749a700,c0c86d45,4f6,c749a770,...) > at intr_event_execute_handlers+0x14b > ithread_loop(c74b0a00,e75f4d38,90a490a4,e8c3e8c3,176b176b,...) at > ithread_loop+0x6b > fork_exit(c086b420,c74b0a00,e75f4d38) at fork_exit+0x91 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0, eip = 0, esp = 0xe75f4d70, ebp = 0 --- > db> > Sorry Mike, I haven't had time to fix the issue with igb(4). As you know I have been fixing several bugs in bge(4). Most bugs(4) were fixed in my local tree but one thing, poor Tx performance on PCIe controller was not solved yet. At first I thought it could be side-effect of newly added TSO feature written by me but stock bge(4) also showed the same issue. The controller does not show poor performance if TSO is used. But not all TCP traffic can make use TSO, bge(4) may suffer from poor Tx performance. I still have no idea why it happens. If I manage to fix that one I'll look into the igb(4) issue. From alexbestms at wwu.de Mon Nov 9 23:43:19 2009 From: alexbestms at wwu.de (Alexander Best) Date: Mon Nov 9 23:43:25 2009 Subject: [patch] ee segfaults when jumping to line zero Message-ID: hi there, could somebody please commit the attached patch to HEAD and mfc it asap? it's a no brainer. ee inits a *char with NULL and accesses it before the *char is being initialised properly. to repeat: 1)start `ee' 2)press `ctrl+c' 3)enter `0' =====>>> BAM!!! this will occur under all branches running ee 1.5.0. the problem might also occur in branches with previous versions of ee. i think only 6-stable is still using the 1.4.X ee release. the patch was submitted by Fredrik Lindberg in bin/137707, but sadly nobody paid attention to it. :( this fix should also be forwarded to re@ asap so we can have it in 8.0-RELEASE. alex -------------- next part -------------- Index: ee.c =================================================================== --- ee.c (revision 196171) +++ ee.c (working copy) @@ -1993,7 +1993,7 @@ int number; int i; char *ptr; - char *direction = NULL; + char *direction = "d"; struct text *t_line; ptr = cmd_str; --------------060704070207090201020407-- From cswiger at mac.com Mon Nov 9 23:45:50 2009 From: cswiger at mac.com (Chuck Swiger) Date: Mon Nov 9 23:45:56 2009 Subject: Help needed: TCP Wizards (was 8.0-RC1 NFS client timeout issue) In-Reply-To: References: <4AF0B7DF.9030405@freebsd.org> <030A8229-9707-4F70-B4BE-584F1BF9ECEC@FreeBSD.org> Message-ID: On Nov 9, 2009, at 3:04 PM, Rick Macklem wrote: [ ... ] > It was usually triggered by a server reboot. After the server reboot, > the server does send an RST to the client. This seems legit, but might > be what makes Cisco think that "bad things" are happening? (I have no > access to info about the switches or their configuration, although the > campus standard is for these ports to be used by a single desktop > machine > only and not a switch or hub.) The description you've provided suggests your network admins are configuring end-user ports with "Port Fast" to avoid the time required to do spanning tree learning & detection; they want you to not use a switch or hub on such ports to avoid the risk of creating a loop. Cisco routers have some options which cause them to drop packets and disable the port in such a mode if it sees more than the allowed # of ether MAC addresses coming from that port, or if it receives BPDU packets indicating that a switch was connected to the port; however, this wouldn't cause RST packets to be generated, you'd just lose your uplink. Seeing forged RST packets suggests that something like the Sandvine PTS equipment is also around on that network. Regards, -- -Chuck From mike at sentex.net Tue Nov 10 00:21:59 2009 From: mike at sentex.net (Mike Tancsa) Date: Tue Nov 10 00:22:10 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <2a41acea0911091459w2b4fec5djd64d0324557b7da2@mail.gmail.co m> References: <20091017170351.GZ29771@expo.ukrweb.net> <20091017222314.GB19204@michelle.cdnetworks.com> <200911092033.nA9KX6dD013378@lava.sentex.ca> <200911092215.nA9MFeDP013898@lava.sentex.ca> <2a41acea0911091459w2b4fec5djd64d0324557b7da2@mail.gmail.com> Message-ID: <200911100021.nAA0LvMG014534@lava.sentex.ca> At 05:59 PM 11/9/2009, Jack Vogel wrote: >Are you using standard MTU or jumbo? That get_buf error is ENOMEM, looks like >that happens when in the bus_dma stuff reserve_bounce_pages() fails. > >Are you maybe using a 32 bit kernel? I have not seen this failure here. Hi Jack, Standard MTU and i386 ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From mike at sentex.net Tue Nov 10 00:24:26 2009 From: mike at sentex.net (Mike Tancsa) Date: Tue Nov 10 00:24:33 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <20091109232500.GB1141@michelle.cdnetworks.com> References: <20091017170351.GZ29771@expo.ukrweb.net> <20091017222314.GB19204@michelle.cdnetworks.com> <200911092033.nA9KX6dD013378@lava.sentex.ca> <200911092215.nA9MFeDP013898@lava.sentex.ca> <20091109232500.GB1141@michelle.cdnetworks.com> Message-ID: <200911100024.nAA0OOIH014557@lava.sentex.ca> At 06:25 PM 11/9/2009, Pyun YongHyeon wrote: >Sorry Mike, >I haven't had time to fix the issue with igb(4). As you know I have Hi, No worries! I was trying to reproduce the problems with Quagga and thought I could just use this box as it has multiple nics. But I was not able to get the second port on the dual port card to work in this config for some reason and thought I would engage Jack as well in case it was some obvious issue. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From jfvogel at gmail.com Tue Nov 10 00:33:14 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Nov 10 00:33:21 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <200911100021.nAA0LvMG014534@lava.sentex.ca> References: <20091017170351.GZ29771@expo.ukrweb.net> <20091017222314.GB19204@michelle.cdnetworks.com> <200911092033.nA9KX6dD013378@lava.sentex.ca> <200911092215.nA9MFeDP013898@lava.sentex.ca> <2a41acea0911091459w2b4fec5djd64d0324557b7da2@mail.gmail.com> <200911100021.nAA0LvMG014534@lava.sentex.ca> Message-ID: <2a41acea0911091633u2899b47ewb514b6276ba2cf62@mail.gmail.com> Some reason you aren't using amd64? I will have a system installed that way and see if I can repro it then, thanks. Jack On Mon, Nov 9, 2009 at 4:22 PM, Mike Tancsa wrote: > At 05:59 PM 11/9/2009, Jack Vogel wrote: > >> Are you using standard MTU or jumbo? That get_buf error is ENOMEM, looks >> like >> that happens when in the bus_dma stuff reserve_bounce_pages() fails. >> >> Are you maybe using a 32 bit kernel? I have not seen this failure here. >> > > Hi Jack, > Standard MTU and i386 > > ---Mike > > > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > From alexbestms at wwu.de Tue Nov 10 00:53:58 2009 From: alexbestms at wwu.de (Alexander Best) Date: Tue Nov 10 00:54:06 2009 Subject: [patch] ee segfaults when jumping to line zero Message-ID: patch has been committed to head by delphij@ (r199123). thanks a bunch. alex From rmacklem at uoguelph.ca Tue Nov 10 01:08:54 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Tue Nov 10 01:09:01 2009 Subject: Help needed: TCP Wizards (was 8.0-RC1 NFS client timeout issue) In-Reply-To: References: <4AF0B7DF.9030405@freebsd.org> <030A8229-9707-4F70-B4BE-584F1BF9ECEC@FreeBSD.org> Message-ID: On Mon, 9 Nov 2009, Chuck Swiger wrote: > On Nov 9, 2009, at 3:04 PM, Rick Macklem wrote: > [ ... ] >> It was usually triggered by a server reboot. After the server reboot, >> the server does send an RST to the client. This seems legit, but might >> be what makes Cisco think that "bad things" are happening? (I have no >> access to info about the switches or their configuration, although the >> campus standard is for these ports to be used by a single desktop machine >> only and not a switch or hub.) > > The description you've provided suggests your network admins are configuring > end-user ports with "Port Fast" to avoid the time required to do spanning > tree learning & detection; they want you to not use a switch or hub on such > ports to avoid the risk of creating a loop. Cisco routers have some options > which cause them to drop packets and disable the port in such a mode if it > sees more than the allowed # of ether MAC addresses coming from that port, or > if it receives BPDU packets indicating that a switch was connected to the > port; however, this wouldn't cause RST packets to be generated, you'd just > lose your uplink. > > Seeing forged RST packets suggests that something like the Sandvine PTS > equipment is also around on that network. > I'll admit I've never seen any of the hardware and don't know what all is set up. (The campus networking folks seem to consider such things "need to know" and I'm not in the "need to know" category:-) So, I can't say what is at fault, it just sure looks like the RSTs are coming down the uplink and they even have the MAC of the FreeBSD-CURRENT client. I do recall that we were the biggest Cisco IP phone installation they had ever done, when it went in, but that was a fair number of years ago. rick From mike at sentex.net Tue Nov 10 02:27:57 2009 From: mike at sentex.net (Mike Tancsa) Date: Tue Nov 10 02:28:06 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <2a41acea0911091633u2899b47ewb514b6276ba2cf62@mail.gmail.co m> References: <20091017170351.GZ29771@expo.ukrweb.net> <20091017222314.GB19204@michelle.cdnetworks.com> <200911092033.nA9KX6dD013378@lava.sentex.ca> <200911092215.nA9MFeDP013898@lava.sentex.ca> <2a41acea0911091459w2b4fec5djd64d0324557b7da2@mail.gmail.com> <200911100021.nAA0LvMG014534@lava.sentex.ca> <2a41acea0911091633u2899b47ewb514b6276ba2cf62@mail.gmail.com> Message-ID: <200911100227.nAA2RtDY015177@lava.sentex.ca> At 07:33 PM 11/9/2009, Jack Vogel wrote: >Some reason you aren't using amd64? I will have a system installed that way >and see if I can repro it then, thanks. I had found in the past i386 was faster for firewall and routing applications. Perhaps thats different now, I will give it a try again to see if there is any difference. pciconf and dmesg attached. ---Mike >Jack > > >On Mon, Nov 9, 2009 at 4:22 PM, Mike Tancsa ><mike@sentex.net> wrote: >At 05:59 PM 11/9/2009, Jack Vogel wrote: >Are you using standard MTU or jumbo? That get_buf error is ENOMEM, looks like >that happens when in the bus_dma stuff reserve_bounce_pages() fails. > >Are you maybe using a 32 bit kernel? I have not seen this failure here. > > >Hi Jack, > Standard MTU and i386 > > ---Mike > > > >-------------------------------------------------------------------- >Mike Tancsa, tel +1 519 651 3400 >Sentex >Communications, >mike@sentex.net >Providing Internet since >1994 www.sentex.net >Cambridge, Ontario >Canada www.sentex.net/mike > -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike -------------- next part -------------- 0(ich10)% cat /var/run/dmesg.boot Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RC2 #5: Mon Nov 9 17:03:08 EST 2009 mdtancsa@ich10.sentex.ca:/usr/obj/usr/src/sys/server i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i7 CPU @ 9200 @ 2.67GHz (2666.78-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Stepping = 5 Features=0xbfebfbff Features2=0x98e3bd AMD Features=0x28100000 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3661766656 (3492 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0 450/0 20090521 tbfadt-655 ACPI Warning: Invalid length for Pm2ControlBlock: 0, using default 8 20090521 tbfadt-707 ioapic0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 igb0: port 0x4020-0x403f mem 0xe1620000-0xe163ffff,0xe1400000-0xe15fffff,0xe1644000-0xe1647fff irq 16 at device 0.0 on pci1 igb0: Using MSIX interrupts with 3 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 00:30:48:94:88:20 igb1: port 0x4000-0x401f mem 0xe1600000-0xe161ffff,0xe1200000-0xe13fffff,0xe1640000-0xe1643fff irq 17 at device 0.1 on pci1 igb1: Using MSIX interrupts with 3 vectors igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: Ethernet address: 00:30:48:94:88:21 pcib2: irq 16 at device 3.0 on pci0 pci2: on pcib2 pcib3: irq 16 at device 7.0 on pci0 pci3: on pcib3 pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) em0: port 0x5100-0x511f mem 0xe1900000-0xe191ffff,0xe1923000-0xe1923fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1c:c0:95:0d:0d uhci0: port 0x50e0-0x50ff irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x3f00 usbus0: on uhci0 uhci1: port 0x50c0-0x50df irq 21 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0x50a0-0x50bf irq 19 at device 26.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: on uhci2 ehci0: mem 0xe1922000-0xe19223ff irq 18 at device 26.7 on pci0 ehci0: [ITHREAD] usbus3: EHCI version 1.0 usbus3: on ehci0 pci0: at device 27.0 (no driver attached) pcib4: irq 17 at device 28.0 on pci0 pci4: on pcib4 pcib5: irq 16 at device 28.1 on pci0 pci5: on pcib5 siis0: port 0x3000-0x307f mem 0xe1804000-0xe180407f,0xe1800000-0xe1803fff irq 17 at device 0.0 on pci5 siis0: [ITHREAD] siisch0: at channel 0 on siis0 siisch0: [ITHREAD] siisch1: at channel 1 on siis0 siisch1: [ITHREAD] pcib6: irq 17 at device 28.4 on pci0 pci6: on pcib6 atapci0: port 0x2018-0x201f,0x2024-0x2027,0x2010-0x2017,0x2020-0x2023,0x2000-0x200f mem 0xe1700000-0xe17003ff irq 16 at device 0.0 on pci6 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] uhci3: port 0x5080-0x509f irq 23 at device 29.0 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus4: on uhci3 uhci4: port 0x5060-0x507f irq 19 at device 29.1 on pci0 uhci4: [ITHREAD] uhci4: LegSup = 0x2f00 usbus5: on uhci4 uhci5: port 0x5040-0x505f irq 18 at device 29.2 on pci0 uhci5: [ITHREAD] uhci5: LegSup = 0x2f00 usbus6: on uhci5 ehci1: mem 0xe1921000-0xe19213ff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus7: EHCI version 1.0 usbus7: on ehci1 pcib7: at device 30.0 on pci0 pci7: on pcib7 vgapci0: port 0x1000-0x10ff mem 0xe0000000-0xe0ffffff,0xe1005000-0xe1005fff irq 18 at device 2.0 on pci7 fwohci0: mem 0xe1004000-0xe10047ff,0xe1000000-0xe1003fff irq 19 at device 3.0 on pci7 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:90:27:00:02:40:2c:70 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0xda1760 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:90:27:40:2c:70 fwe0: Ethernet address: 02:90:27:40:2c:70 fwip0: on firewire0 fwip0: Firewire address: 00:90:27:00:02:40:2c:70 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, non CYCLEMASTER mode isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0x5128-0x512f,0x5134-0x5137,0x5120-0x5127,0x5130-0x5133,0x5020-0x503f mem 0xe1920000-0xe19207ff irq 19 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] pci0: at device 31.3 (no driver attached) atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f0 irq 6 drq 2 on acpi0 fdc0: [FILTER] cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 cpu2: on acpi0 est2: on cpu2 p4tcc2: on cpu2 cpu3: on acpi0 est3: on cpu3 p4tcc3: on cpu3 cpu4: on acpi0 est4: on cpu4 p4tcc4: on cpu4 cpu5: on acpi0 est5: on cpu5 p4tcc5: on cpu5 cpu6: on acpi0 est6: on cpu6 p4tcc6: on cpu6 cpu7: on acpi0 est7: on cpu7 p4tcc7: on cpu7 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc97ff,0xcc000-0xccfff,0xcd000-0xcdfff,0xce000-0xcefff,0xcf800-0xd07ff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata0: [ITHREAD] ata1 at port 0x170-0x177,0x376 irq 15 on isa0 ata1: [ITHREAD] atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] ppc0: parallel port not found. uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] Timecounters tick every 1.000 msec Waiting 5 seconds for SCSI devices to settle firewire0: 2 nodes, maxhop <= 1 cable IRM irm(1) usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 12Mbps Full Speed USB v1.0 usbus6: 12Mbps Full Speed USB v1.0 usbus7: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 ugen7.1: at usbus7 uhub7: on usbus7 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub4: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered firewire0: New S400 device ID:0011060000999ad6 uhub3: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ugen6.2: at usbus6 ukbd0: on usbus6 kbd2 at ukbd0 ums0: on usbus6 ums0: 5 buttons and [XYZ] coordinates ID=1 (aprobe2:ahcich0:0:0:0): SIGNATURE: 0000 (aprobe3:ahcich1:0:0:0): SIGNATURE: 0000 ada0 at ahcich0 bus 0 target 0 lun 0 ada0: ATA/ATAPI-8 SATA 2.x device ada0: 300.000MB/s transfers ada0: 476940MB (976773168 512 byte sectors: 16H 63S/T 16383C) ada0: Native Command Queueing enabled ada1 at ahcich1 bus 0 target 0 lun 0 ada1: ATA/ATAPI-7 SATA 2.x device ada1: 300.000MB/s transfers ada1: 76319MB (156301488 512 byte sectors: 16H 63S/T 16383C) ada1: Native Command Queueing enabled lapic2: Forcing LINT1 to edge trigger SMP: AP CPU #2 Launched! lapic7: Forcing LINT1 to edge trigger SMP: AP CPU #7 Launched! lapic3: Forcing LINT1 to edge trigger SMP: AP CPU #3 Launched! lapic6: Forcing LINT1 to edge trigger SMP: AP CPU #6 Launched! lapic4: Forcing LINT1 to edge trigger SMP: AP CPU #4 Launched! lapic1: Forcing LINT1 to edge trigger SMP: AP CPU #1 Launched! lapic5: Forcing LINT1 to edge trigger SMP: AP CPU #5 Launched! GEOM: ada0s1: geometry does not match label (255h,63s != 16h,63s). Trying to mount root from ufs:/dev/ada0s1a WARNING: / was not properly dismounted ugen1.2: at usbus1 ugen2.2: at usbus2 uftdi0: on usbus1 uftdi1: on usbus2 0(ich10)# pciconf -lvc 10[40] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) none3@pci0:0:20:1: class=0x080000 card=0x00000000 chip=0x34228086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub GPIO and Scratch Pad Registers' class = base peripheral subclass = interrupt controller cap 10[40] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) none4@pci0:0:20:2: class=0x080000 card=0x00000000 chip=0x34238086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub Control Status and RAS Registers' class = base peripheral subclass = interrupt controller cap 10[40] = PCI-Express 2 root endpoint max data 128(128) link x0(x0) none5@pci0:0:20:3: class=0x080000 card=0x00000000 chip=0x34388086 rev=0x12 hdr=0x00 vendor = 'Intel Corporation' device = 'QuickPath Architecture I/O Hub Throttle Registers' class = base peripheral subclass = interrupt controller em0@pci0:0:25:0: class=0x020000 card=0x00008086 chip=0x10cc8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message uhci0@pci0:0:26:0: class=0x0c0300 card=0x4f538086 chip=0x3a378086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *4' class = serial bus subclass = USB cap 13[50] = PCI Advanced Features: FLR TP uhci1@pci0:0:26:1: class=0x0c0300 card=0x4f538086 chip=0x3a388086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *5' class = serial bus subclass = USB cap 13[50] = PCI Advanced Features: FLR TP uhci2@pci0:0:26:2: class=0x0c0300 card=0x4f538086 chip=0x3a398086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *6' class = serial bus subclass = USB cap 13[50] = PCI Advanced Features: FLR TP ehci0@pci0:0:26:7: class=0x0c0320 card=0x4f538086 chip=0x3a3c8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB EHCI Controller *2' class = serial bus subclass = USB cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 none6@pci0:0:27:0: class=0x040300 card=0x00228086 chip=0x3a3e8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'HD Audio Controller' class = multimedia subclass = HDA cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 05[60] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 1 root endpoint max data 128(128) link x0(x0) pcib4@pci0:0:28:0: class=0x060400 card=0x4f538086 chip=0x3a408086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' device = 'PCI Express Port 1' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(128) link x0(x1) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x4f538086 cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib5@pci0:0:28:1: class=0x060400 card=0x4f538086 chip=0x3a428086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' device = 'PCI Express Port 2' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(128) link x1(x1) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x4f538086 cap 01[a0] = powerspec 2 supports D0 D3 current D0 pcib6@pci0:0:28:4: class=0x060400 card=0x4f538086 chip=0x3a488086 rev=0x00 hdr=0x01 vendor = 'Intel Corporation' device = 'PCI Express Port 5' class = bridge subclass = PCI-PCI cap 10[40] = PCI-Express 1 root port max data 128(128) link x1(x1) cap 05[80] = MSI supports 1 message cap 0d[90] = PCI Bridge card=0x4f538086 cap 01[a0] = powerspec 2 supports D0 D3 current D0 uhci3@pci0:0:29:0: class=0x0c0300 card=0x4f538086 chip=0x3a348086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *1' class = serial bus subclass = USB cap 13[50] = PCI Advanced Features: FLR TP uhci4@pci0:0:29:1: class=0x0c0300 card=0x4f538086 chip=0x3a358086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *2' class = serial bus subclass = USB cap 13[50] = PCI Advanced Features: FLR TP uhci5@pci0:0:29:2: class=0x0c0300 card=0x4f538086 chip=0x3a368086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB UHCI Controller *3' class = serial bus subclass = USB cap 13[50] = PCI Advanced Features: FLR TP ehci1@pci0:0:29:7: class=0x0c0320 card=0x4f538086 chip=0x3a3a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'USB EHCI Controller *1' class = serial bus subclass = USB cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 pcib7@pci0:0:30:0: class=0x060401 card=0x4f538086 chip=0x244e8086 rev=0x90 hdr=0x01 vendor = 'Intel Corporation' device = '82801 Family (ICH2/3/4/5/6/7/8/9,63xxESB) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI cap 0d[50] = PCI Bridge card=0x4f538086 isab0@pci0:0:31:0: class=0x060100 card=0x4f538086 chip=0x3a168086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'LPC Interface Controller' class = bridge subclass = PCI-ISA cap 09[e0] = vendor (length 12) Intel cap 1 version 0 features: SATA RAID-5, 4 PCI-e x1 slots ahci0@pci0:0:31:2: class=0x010601 card=0x4f538086 chip=0x3a228086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '6 port SATA AHCI Controller' class = mass storage subclass = SATA cap 05[80] = MSI supports 16 messages enabled with 1 message cap 01[70] = powerspec 3 supports D0 D3 current D0 cap 12[a8] = SATA Index-Data Pair none7@pci0:0:31:3: class=0x0c0500 card=0x4f538086 chip=0x3a308086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'SMB controller (50011458)' class = serial bus subclass = SMBus igb0@pci0:1:0:0: class=0x020000 card=0x10a715d9 chip=0x10a78086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82575EB Gigabit Network Connection' class = network subclass = ethernet cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 11[60] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(256) link x4(x4) igb1@pci0:1:0:1: class=0x020000 card=0x10a715d9 chip=0x10a78086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82575EB Gigabit Network Connection' class = network subclass = ethernet cap 01[40] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 11[60] = MSI-X supports 10 messages in map 0x1c enabled cap 10[a0] = PCI-Express 2 endpoint max data 256(256) link x4(x4) siis0@pci0:5:0:0: class=0x010400 card=0x71321095 chip=0x31321095 rev=0x01 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'PCI Express (1x) to 2 Port SATA300 (SiI 3132)' class = mass storage subclass = RAID cap 01[54] = powerspec 2 supports D0 D1 D2 D3 current D0 cap 05[5c] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 1 legacy endpoint max data 128(1024) link x1(x1) atapci0@pci0:6:0:0: class=0x01018f card=0x4f538086 chip=0x612111ab rev=0xb2 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '6121 SATA2 Controller' class = mass storage subclass = ATA cap 01[48] = powerspec 2 supports D0 D1 D3 current D0 cap 05[50] = MSI supports 1 message cap 10[e0] = PCI-Express 1 legacy endpoint max data 128(128) link x1(x1) vgapci0@pci0:7:2:0: class=0x030000 card=0x00081002 chip=0x474d1002 rev=0x65 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SLAT (Rage XL AGP 2x)' class = display subclass = VGA cap 01[5c] = powerspec 1 supports D0 D1 D2 D3 current D0 fwohci0@pci0:7:3:0: class=0x0c0010 card=0x4f538086 chip=0x8023104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'IEEE1394a-2000 OHCI PHY/Link-Layer Ctrlr (TSB43AB21/A)' class = serial bus subclass = FireWire cap 01[44] = powerspec 2 supports D0 D1 D2 D3 current D0 0(ich10)# From xcllnt at mac.com Tue Nov 10 07:34:04 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Nov 10 07:34:12 2009 Subject: QMutex: mutex destroy failure: Device busy -> Seg fault in ports/x11/kdebase4-workspace In-Reply-To: <3A2818E0-70DE-4837-9E47-08FFDF74072D@mac.com> References: <20091109132113.GA71911@mech-cluster241.men.bris.ac.uk> <3A2818E0-70DE-4837-9E47-08FFDF74072D@mac.com> Message-ID: On Nov 9, 2009, at 12:48 PM, Marcel Moolenaar wrote: > >> At present there's no >> secure graphical web browser for ia64. Until recently >> kazehakase was working. But now it doesn't, because security/nss >> doesn't build. And firefox doesn't build because of broken xpcom.. > > Firefox used to build. I'll see up with that... Apply the attached patch to /usr/ports/www/firefox3. I'm testing the same patch against firefox35 as I type this. FYI, -- Marcel Moolenaar xcllnt@mac.com -------------- next part -------------- A non-text attachment was scrubbed... Name: firefox3.diff Type: application/octet-stream Size: 2693 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091110/bc94c839/firefox3.obj From dfr at rabson.org Tue Nov 10 08:43:06 2009 From: dfr at rabson.org (Doug Rabson) Date: Tue Nov 10 08:43:12 2009 Subject: Help needed: TCP Wizards (was 8.0-RC1 NFS client timeout issue) In-Reply-To: References: <4AF0B7DF.9030405@freebsd.org> <030A8229-9707-4F70-B4BE-584F1BF9ECEC@FreeBSD.org> Message-ID: <3D80A486-FB8F-451D-BF44-F62C647D8556@rabson.org> On 9 Nov 2009, at 23:04, Rick Macklem wrote: > > > On Thu, 5 Nov 2009, Rui Paulo wrote: > >>> Now, here's where someone may be able to help? >>> Grep'ng around, I found 4 places where the TCP stack called >>> ip_output() >>> (one in each of tcp_output.c, tcp_subr.c, tcp_timewait.c and >>> tcp_syncache.c) and I put a printf like this just before them: >>> if (flags & TH_RST) >>> printf("sent a reset\n"); >>> >>> (The exact format varies for each, because of where the TCP >>> header flags are and have different printf messages.) >>> Now, the weird part is, that when the extraneous RST is sent to the >>> server, I don't get any printf. (I do get a few of these, but at >>> other >>> times for what appear to be legitimate RSTs.) >>> I can't see anywhere else that the TCP stack would send an RST >>> and, so, >>> I'm stuck w.r.t. figuring out what is sending them? > Ok, if you found the previous posts entertaining, you might enjoy > this:-) > > Along with the printfs before all the ip_output() calls, I added calls > inside ip_output() and, eventually, even calls in front of every > if_output(). Never got anything that indicated an RST was being sent. > (I only saw what I expected, which was an ACK reply being sent.) > > BUT, at almost exactly the same time, there were the FreeBSD8-CURRENT > client->server RST packets on the server's snoop trace. > > Hmm, did a tcpdump in the client and, yes, the same packets were > there. > > To keep it simple, I had done the dinosaur thing and plugged both the > client and server into an old, dumb 10baseT hub, so that I could > easily > watch everything. (I also had an uplink cable to the net port in the > wall, so I could move kernels around from the machine I usually build > them on.) > > I was at the point where I couldn't conceivably figure out where the > FreeBSD-CURRENT client was generating these RSTs. So guess what... > --> it wasn't > > I unplugged the uplink cable and, no more RSTs. I've been testing for > long enough now, that I am 99% certain they were being injected. Since > the from address and even the MAC address is correct, I can only > assume > that it was the Cisco switch that was doing the injecting. (How else > could a packet come in from the Cisco switch with the MAC address of > the FreeBSD-CURRENT client machine?) > > It was usually triggered by a server reboot. After the server reboot, > the server does send an RST to the client. This seems legit, but might > be what makes Cisco think that "bad things" are happening? (I have no > access to info about the switches or their configuration, although the > campus standard is for these ports to be used by a single desktop > machine > only and not a switch or hub.) > > So, it seems that FreeBSD8-CURRENT reconnects fine now, so long as > nothing is injecting RSTs into the newly created connection. > > Well, I'm not sure I found this fun, but hopefully others are > entertained:-), rick > We had some issues at work where the Cisco intrusion detection thing was resetting connections bogusly. Do you have IDS enabled on your Cisco gear? From des at des.no Tue Nov 10 09:05:21 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue Nov 10 09:05:28 2009 Subject: sftp seg faulting In-Reply-To: <4AF88D2F.3060306@delphij.net> (Xin LI's message of "Mon, 09 Nov 2009 13:44:15 -0800") References: <4ab61a80911091307o28ca4e78pa8e42441bcf2e604@mail.gmail.com> <4AF88D2F.3060306@delphij.net> Message-ID: <86fx8mu4vj.fsf@ds4.des.no> Xin LI writes: > David Cornejo writes: > > In recent builds of 9-CURRENT on amd64 platform I am getting seg > > faults that seem related to glob - same vintage works on x86. > I am currently using a patch des@ sent to me (and also to this list) > which worked fine. Uh, did I forget to commit it? DES -- Dag-Erling Sm?rgrav - des@des.no From serguey-grigoriev at yandex.ru Tue Nov 10 09:42:03 2009 From: serguey-grigoriev at yandex.ru (S.N.Grigoriev) Date: Tue Nov 10 09:42:10 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <1257618758.1511.14.camel@RabbitsDen> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> Message-ID: <6511257846119@webmail85.yandex.ru> 07.11.09, 13:32, "Alexandre \"Sunny\" Kovalenko" wrote: > Sergey, I think it would be best if you follow > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN > and the do an ultimate test: > * quiesce your system > * switch to the console > * sync (few times, if you are really old school ;) > * sysctl debug.kdb.panic=1 (this would *panic* the system and, given > everything is set-up properly, produce the crash dump) > > if you do not have debug.kdb.panic sysctl, please, add option KDB to > your kernel configuration. > If you get crash dump from the kernel-induced panic and your system > keeps rebooting without a trace, I would suspect some hardware testing > might be in order. Alexandre, I followed your tips. The kernel configuration now contains options DDB and KDB. The sysctl variable 'debug.debugger_on_panic' is set to '1'. After the 'sysctl debug.kdb.panic=1' command the debugger prompt appears. To have a crash dump I should type 'panic' on the debugger prompt. If I type 'reboot' instead, there are no crash dumps. Is that behaviour correct? Another question: must all panics go to the bebugger prompt? I still have neither crash dumps nor debugger prompt during world/kernel compilations. Just reboots. -- Regards, S.Grigoriev. From gavin at FreeBSD.org Tue Nov 10 09:56:58 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Nov 10 09:57:05 2009 Subject: gjournal crash with external usb drive after unclean shutdown In-Reply-To: <20091108124330.b634560c.ubm.freebsd@gmail.com> References: <20091108124330.b634560c.ubm.freebsd@gmail.com> Message-ID: <1257847014.17247.2.camel@buffy.york.ac.uk> On Sun, 2009-11-08 at 12:43 +0100, Marc UBM Bocklet wrote: > Hiho! :-) > > Following an unclean shutdown (panic, related to a bad network card in > another machine), my gjournaled external usb drive reliably crashes my > system when I connect it. I got a core dump available for poking around > further. Textdump info is attached. I'm not sure if the disk is dying > or the journal somehow got into a really bad state. textdump is > available on request! :-) You might be better taking this to the freebsd-geom@ mailing list. Gavin From gary.jennejohn at freenet.de Tue Nov 10 09:58:59 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Tue Nov 10 09:59:09 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <6511257846119@webmail85.yandex.ru> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> Message-ID: <20091110105856.1270038e@ernst.jennejohn.org> On Tue, 10 Nov 2009 12:41:59 +0300 S.N.Grigoriev wrote: > I followed your tips. The kernel configuration now contains options DDB > and KDB. The sysctl variable 'debug.debugger_on_panic' is set to '1'. > After the 'sysctl debug.kdb.panic=1' command the debugger prompt > appears. > To have a crash dump I should type 'panic' on the debugger prompt. > If I type 'reboot' instead, there are no crash dumps. Is that behaviour > correct? > In this case yes, because you forced the panic by setting the sysctl. > Another question: must all panics go to the bebugger prompt? > They should, if the kernel itself causes the panic. As Alexandre wrote, a hardware problem probably would not cause a kernel panic. I've seen panics like this myself and they were almost always caused by faulty memory. Running "make buildworld" really stresses the system and reveals hardware faults like that. > I still have neither crash dumps nor debugger prompt during > world/kernel compilations. Just reboots. > Are you in the console or running Xorg when it happens? --- Gary Jennejohn From O.Seibert at cs.ru.nl Tue Nov 10 10:54:50 2009 From: O.Seibert at cs.ru.nl (Olaf Seibert) Date: Tue Nov 10 12:21:51 2009 Subject: Help needed: TCP Wizards (was 8.0-RC1 NFS client timeout issue) In-Reply-To: References: <4AF0B7DF.9030405@freebsd.org> <030A8229-9707-4F70-B4BE-584F1BF9ECEC@FreeBSD.org> Message-ID: <20091110105446.GI841@twoquid.cs.ru.nl> On Mon 09 Nov 2009 at 18:04:39 -0500, Rick Macklem wrote: > Well, I'm not sure I found this fun, but hopefully others are > entertained:-), rick I have to admit that I am :-) Although reading this kind of stories is usually more entertaining than being in them... Thanks again for your adventures! -Olaf. -- From serguey-grigoriev at yandex.ru Tue Nov 10 13:57:51 2009 From: serguey-grigoriev at yandex.ru (S.N.Grigoriev) Date: Tue Nov 10 13:58:04 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091110105856.1270038e@ernst.jennejohn.org> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> Message-ID: <12631257861469@webmail52.yandex.ru> 10.11.09, 10:58, "Gary Jennejohn" wrote: > I've seen panics like this myself and they were almost always caused > by faulty memory. Running "make buildworld" really stresses the > system and reveals hardware faults like that. Is there a non-zero probability that 7-stable irrespective of faulty memory ALWAYS works fine on the same hardware (including 'make -j 8 buildworld') but 8.0 ALWAYS crashes? > Are you in the console or running Xorg when it happens? Yes, I'm in the console. Xorg is not install at all. -- Regards, S.Grigoriev. From gary.jennejohn at freenet.de Tue Nov 10 14:07:08 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Tue Nov 10 14:07:22 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <12631257861469@webmail52.yandex.ru> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <12631257861469@webmail52.yandex.ru> Message-ID: <20091110150705.648bce4f@ernst.jennejohn.org> On Tue, 10 Nov 2009 16:57:49 +0300 S.N.Grigoriev wrote: > > > 10.11.09, 10:58, "Gary Jennejohn" > wrote: > > > I've seen panics like this myself and they were almost always caused > > by faulty memory. Running "make buildworld" really stresses the > > system and reveals hardware faults like that. > > Is there a non-zero probability that 7-stable irrespective of faulty memory > ALWAYS works fine on the same hardware (including 'make -j 8 buildworld') > but 8.0 ALWAYS crashes? > Who can say? Newer versions of FreeBSD could be more aggressive in their memory usage. Other parts of the kernel like the ATA/AHCI subsystem also use hardware capabilities more fully. It seems that the kernel is not seeing any panic, otherwise it should land in the debugger. This points to some hardware problem, especially since other users are not reporting crashes like you see. --- Gary Jennejohn From avg at icyb.net.ua Tue Nov 10 14:28:52 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Nov 10 14:28:58 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <12631257861469@webmail52.yandex.ru> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <12631257861469@webmail52.yandex.ru> Message-ID: <4AF9789E.5000904@icyb.net.ua> on 10/11/2009 15:57 S.N.Grigoriev said the following: > > 10.11.09, 10:58, "Gary Jennejohn" > wrote: > >> I've seen panics like this myself and they were almost always caused >> by faulty memory. Running "make buildworld" really stresses the >> system and reveals hardware faults like that. > > Is there a non-zero probability that 7-stable irrespective of faulty memory > ALWAYS works fine on the same hardware (including 'make -j 8 buildworld') > but 8.0 ALWAYS crashes? > >> Are you in the console or running Xorg when it happens? > > Yes, I'm in the console. Xorg is not install at all. I can not provide any help with your problem, sorry. But I'd like to point out one thing. I think that it was you mistake to report your problem in this thread as opposed to a new thread or a PR. This thread started with a report by Kai Gallasch about a lock order reversal panic. Hence the subject of this thread. Then you said that you have "the same problem", but the symptoms you described were a spontaneous reboot without any panic messages. So some people spent their time trying to help you to set up kernel dumps, some people missed your report because of the subject, some people missed Kai's report because the discussion went the wrong way, some people were tempted to point to the latest hardware issue discovered. Apologies that I picked on you, but it's not helpful when such a different stuff is piled up into the same thread. Just for the record, here is the original message: http://groups.google.com/group/mailing.freebsd.current/browse_thread/thread/7cdc98adfb88a34d And it's clear lock order reversal panic that was lost in th noise generated by the followups. Yours ranting, -- Andriy Gapon From avg at freebsd.org Tue Nov 10 14:30:32 2009 From: avg at freebsd.org (Andriy Gapon) Date: Tue Nov 10 14:30:40 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <4AF9789E.5000904@icyb.net.ua> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <12631257861469@webmail52.yandex.ru> <4AF9789E.5000904@icyb.net.ua> Message-ID: <4AF97904.2090803@freebsd.org> on 10/11/2009 16:28 Andriy Gapon said the following: > Yours ranting, Sorry for the rant, it seems that I've missed half the text in the original report :-( -- Andriy Gapon From gaijin.k at gmail.com Tue Nov 10 14:44:19 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Tue Nov 10 14:44:26 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <6511257846119@webmail85.yandex.ru> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> Message-ID: <1257864238.46072.22.camel@RabbitsDen> On Tue, 2009-11-10 at 12:41 +0300, S.N.Grigoriev wrote: > > 07.11.09, 13:32, "Alexandre \"Sunny\" Kovalenko" > wrote: > > > Sergey, I think it would be best if you follow > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html#KERNELDEBUG-OBTAIN > > and the do an ultimate test: > > * quiesce your system > > * switch to the console > > * sync (few times, if you are really old school ;) > > * sysctl debug.kdb.panic=1 (this would *panic* the system and, given > > everything is set-up properly, produce the crash dump) > > > > if you do not have debug.kdb.panic sysctl, please, add option KDB to > > your kernel configuration. > > If you get crash dump from the kernel-induced panic and your system > > keeps rebooting without a trace, I would suspect some hardware testing > > might be in order. > > Alexandre, > > I followed your tips. The kernel configuration now contains options DDB > and KDB. The sysctl variable 'debug.debugger_on_panic' is set to '1'. > After the 'sysctl debug.kdb.panic=1' command the debugger prompt > appears. > To have a crash dump I should type 'panic' on the debugger prompt. > If I type 'reboot' instead, there are no crash dumps. Is that behaviour > correct? This is correct -- if you use reboot from the debugger prompt, you will not get crash dump. I don't know whether this is "right" behavior or not, but I have definitely seen this before. > Another question: must all panics go to the bebugger prompt? No, set debug.debugger_on_panic to 0 and system will reboot on panic producing crash dump at startup, provided you have crash dump device configured properly. If I understood you correctly, after you typed 'panic' in the debugger prompt, your system restarted and, eventually, usable dump found its way to /var/crash. Is this correct? If yes, you can change your system to skip debugger on panic. > I still have neither crash dumps nor debugger prompt during > world/kernel compilations. Just reboots. > I am not qualified to tell you that there is absolutely no possibility that FreeBSD could reboot without leaving any trace on the perfectly functioning hardware, but I would think exploring other options might not be out of order now. Unscientifically, I have observed that 8.0RC2 runs hotter on long builds than 7-STABLE did before. I have lowered _PSV, because handrest gets uncomfortably warm and I seem to see it being hit (CPU is being throttled) more often than I remember from the days of 7-STABLE. Again, this is *completely* unscientific. It is also possible that I have dust accumulated in the airduct and has nothing to do with the differences in the OS level. If you still dual boot on that machine and have some device to check power draw during buildworld for both 7.2 and 8.0 it might be a worthwhile exercise. ANother thing would be to monitor whatever thermal sensor you have available to you, I think k8temp(8) provides necessary services for AMD64. Connecting either serial or firewire console to the machine and capturing anything sent to the console right before the reboot might be yet another thing to try. -- Alexandre Kovalenko (????????? ?????????) From gaijin.k at gmail.com Tue Nov 10 14:47:43 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Tue Nov 10 14:47:50 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091110105856.1270038e@ernst.jennejohn.org> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> Message-ID: <1257864452.46072.25.camel@RabbitsDen> On Tue, 2009-11-10 at 10:58 +0100, Gary Jennejohn wrote: > On Tue, 10 Nov 2009 12:41:59 +0300 > S.N.Grigoriev wrote: > > > I followed your tips. The kernel configuration now contains options DDB > > and KDB. The sysctl variable 'debug.debugger_on_panic' is set to '1'. > > After the 'sysctl debug.kdb.panic=1' command the debugger prompt > > appears. > > To have a crash dump I should type 'panic' on the debugger prompt. > > If I type 'reboot' instead, there are no crash dumps. Is that behaviour > > correct? > > > > In this case yes, because you forced the panic by setting the sysctl. > > > Another question: must all panics go to the bebugger prompt? > > > > They should, if the kernel itself causes the panic. As Alexandre > wrote, a hardware problem probably would not cause a kernel panic. I really hope I have not written anything like that ;-) I have seen plenty of panics induced by hardware problems -- from faulty memory to overheated CPU and beyond. What I was trying to say that a reboot *without a panic* is more likely a hardware problem than not. -- Alexandre Kovalenko (????????? ?????????) From gary.jennejohn at freenet.de Tue Nov 10 15:22:08 2009 From: gary.jennejohn at freenet.de (gary.jennejohn@freenet.de) Date: Tue Nov 10 15:22:15 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <1257864452.46072.25.camel@RabbitsDen> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> Message-ID: <20091110162205.48abcffe@ernst.jennejohn.org> On Tue, 10 Nov 2009 09:47:32 -0500 "Alexandre \"Sunny\" Kovalenko" wrote: > > They should, if the kernel itself causes the panic. As Alexandre > > wrote, a hardware problem probably would not cause a kernel panic. > > I really hope I have not written anything like that ;-) I have seen > plenty of panics induced by hardware problems -- from faulty memory to > overheated CPU and beyond. What I was trying to say that a reboot > *without a panic* is more likely a hardware problem than not. > Well, OK, I may have misinterpreted what you wrote or have chosen bad wording myself to convey the same message. Nonetheless it looks like a hardware problem to me. --- Gary Jennejohn From avg at icyb.net.ua Tue Nov 10 17:05:30 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Nov 10 17:05:37 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091110162205.48abcffe@ernst.jennejohn.org> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> Message-ID: <4AF99D53.9030005@icyb.net.ua> on 10/11/2009 17:22 gary.jennejohn@freenet.de said the following: > Well, OK, I may have misinterpreted what you wrote or have chosen bad > wording myself to convey the same message. Nonetheless it looks like > a hardware problem to me. [Trying to make up for my previous mistake.] The symptom certainly looks like misbehaving hardware, but other information from the reports seems to suggest that it is possible that this misbehavior might be caused by software misconfiguring the hardware. I would re-test vm.pmap.pg_ps_enabled=0 just to be sure that it was correctly teh first time. I would try to see how 8.0-RC1 kernel behaves and in general try to find last working, first non-working version. It would be useful to know any (if any) non-default loader.conf and rc.conf settings or kernel config (if not GENERIC). Not a trivial issue unless it is hardware indeed. -- Andriy Gapon From gallasch at free.de Tue Nov 10 17:48:30 2009 From: gallasch at free.de (Kai Gallasch) Date: Tue Nov 10 17:48:37 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <4AF99D53.9030005@icyb.net.ua> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> Message-ID: <20091110184821.4f58a0bf@orwell.free.de> Am Tue, 10 Nov 2009 19:05:23 +0200 schrieb Andriy Gapon : > on 10/11/2009 17:22 gary.jennejohn@freenet.de said the following: > > Well, OK, I may have misinterpreted what you wrote or have chosen > > bad wording myself to convey the same message. Nonetheless it > > looks like a hardware problem to me. > > [Trying to make up for my previous mistake.] > > The symptom certainly looks like misbehaving hardware, but other > information from the reports seems to suggest that it is possible > that this misbehavior might be caused by software misconfiguring the > hardware. Hi. This thread was started by me. In the meantime I filed a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=140338 > I would re-test vm.pmap.pg_ps_enabled=0 just to be sure that it was > correctly teh first time. I toggled vm.pmap.pg_ps_enabled three times between reboots and the result is always the same. superpages enabled: reboot, superpages not enabled: server stable > I would try to see how 8.0-RC1 kernel behaves and in general try to > find last working, first non-working version. 8.0RC1, 8.0BETA4 already showed the same behaviour > It would be useful to know any (if any) non-default loader.conf and > rc.conf settings or kernel config (if not GENERIC). loader.conf untouched, rc.conf had just settings for networking active when testing. In the end I enabled some other stuff to have it ready for 8.0 RELEASE, *after* I found out that disabling superpages helped against the crashes. Ah yes. I also ran memtest86 on the server for about half a day - no problems. But read for yourself in the PR. I don't rule out that this behaviour with vm.pmap.pg_ps_enabled maybe hardware related, but why then is the server running stable with RELENG_7 and memtest and server diagnostics don't report any problem? --Kai. -- I am NOMAD! From amvandemore at gmail.com Tue Nov 10 17:55:21 2009 From: amvandemore at gmail.com (Adam Vande More) Date: Tue Nov 10 17:55:31 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091110184821.4f58a0bf@orwell.free.de> References: <1031257439203@webmail57.yandex.ru> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> <20091110184821.4f58a0bf@orwell.free.de> Message-ID: <6201873e0911100955k6b7613f7h5ca42e077b99de22@mail.gmail.com> > > > I don't rule out that this behaviour with vm.pmap.pg_ps_enabled maybe > hardware related, but why then is the server running stable > with RELENG_7 and memtest and server diagnostics don't report any > problem? > > --Kai. > > If memtest fails a module, you can generally trust the result. There are many occasions when faulty modules will pass however so the only reliable course of action when diagnosing memory issues is to replace with known good modules. -- Adam Vande More From delphij at delphij.net Tue Nov 10 18:16:33 2009 From: delphij at delphij.net (Xin LI) Date: Tue Nov 10 18:16:40 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: <200911050922.10205.hselasky@c2i.net> References: <20091002150931.K35591@pooker.samsco.org> <30F3E66A-4A69-46CE-96F4-44B4049722E2@samsco.org> <200911050922.10205.hselasky@c2i.net> Message-ID: <4AF9ADF4.5040601@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hans Petter Selasky wrote: > Hi, > > There is a newer patch in USB P4. > > The problem is when the /usr partition for example is not residing on the root > disk, which is the only disk the code is waiting for. Then the patch will make > the bootup fail. What if we teach rc.d scripts to do something like this: do { mount -a && break; sleep 1; counter++; } while counter < 30? Will this make sense? Or is there any other concerns? > --HPS > > On Thursday 05 November 2009 04:34:33 Chao Shin wrote: >> ? Sun, 04 Oct 2009 07:52:45 +0800?Scott Long ??: >> >> Hi all >> >> Is there any newer patch/workarounds available? >> >>> On Oct 3, 2009, at 12:51 PM, Marcel Moolenaar wrote: >>>> On Oct 3, 2009, at 9:00 AM, Hans Petter Selasky wrote: >>>>> On Saturday 03 October 2009 17:05:35 Scott Long wrote: >>>>>> On Oct 3, 2009, at 4:30 AM, Hans Petter Selasky wrote: >>>>>>> On Saturday 03 October 2009 10:19:57 Scott Long wrote: >>>>>>>> config_intrhook system will sleep after all >>>>>>> Then why do you need the intr hook callback? >>>>>> The config_intrhook lets you know that interrupts are enabled, the >>>>>> scheduler is running, and mountroot hasn't run yet. It provides a >>>>>> very convenient and standard way to do exactly what we want with USB >>>>>> enumeration. >>>>> Hi, >>>>> >>>>> The root HUB attach and explore code is already running from a separate >>>>> thread, so won't that be superfluous? I mean, the HUB explore code for >>>>> any USB >>>>> HUB will not run until the scheduler is running anyway. >>>>> >>>>> In my opinion delaying the system until the boot disk is present is >>>>> just not >>>>> good. We should rather be event driven, so that every time a new disk >>>>> becomes >>>>> present it checks it for mountroot. >>>>> >>>>> while (1) { >>>>> if (mountroot is successful) >>>>> break; >>>>> if (ctrl+c is pressed) >>>>> manual_mountroot(); >>>>> printf("Waiting 1 second for root-disk to appear. Press CTRL+C to >>>>> abort.\n"); >>>>> sleep(1); >>>>> } >>>> Yes. >>>> >>>> The mount root code should keep a list of potential root devices to try >>>> and >>>> it should try a device as soon as it appears. The current approach to >>>> block >>>> the root mount simply because we want everything to be discovered >>>> before we >>>> try to mount the root is preventing fast boots -- such as when the root >>>> is >>>> a memory disk and you don't need to wait for anything... >>>> >>>> Put differently: it's rather odd to hold off the root mount when the >>>> root >>>> device is already present... >>>> >>>> An approach like this also allows one to indefinitely wait for the root >>>> device, which is a good feature to have... >>> When /etc/rc tries to mount everything in the fstab, it'll fail the boot >>> if some of the devices haven't arrived in time. An argument can be made >>> for fixing that as well, but we're starting to get beyond on the scope >>> of fixing what is needed for 8.0-RELEASE. >>> >>> Scott >>> >>> >>> _______________________________________________ >>> freebsd-current@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to >>> "freebsd-current-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkr5rfQACgkQi+vbBBjt66CMEgCffmh1MK5RysLrL6vooObZQhUP SyAAn2DNLOofpfkOR3aL6WUSwA+yAlw4 =panI -----END PGP SIGNATURE----- From jfvogel at gmail.com Tue Nov 10 18:57:57 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Nov 10 18:59:08 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <200911100227.nAA2RtDY015177@lava.sentex.ca> References: <20091017170351.GZ29771@expo.ukrweb.net> <20091017222314.GB19204@michelle.cdnetworks.com> <200911092033.nA9KX6dD013378@lava.sentex.ca> <200911092215.nA9MFeDP013898@lava.sentex.ca> <2a41acea0911091459w2b4fec5djd64d0324557b7da2@mail.gmail.com> <200911100021.nAA0LvMG014534@lava.sentex.ca> <2a41acea0911091633u2899b47ewb514b6276ba2cf62@mail.gmail.com> <200911100227.nAA2RtDY015177@lava.sentex.ca> Message-ID: <2a41acea0911101057q4f913e30m9319e52bbd254cfe@mail.gmail.com> I have repro'd this failure this morning and think I have a fix for it, I am testing that soon. Stay tuned, Jack On Mon, Nov 9, 2009 at 6:28 PM, Mike Tancsa wrote: > At 07:33 PM 11/9/2009, Jack Vogel wrote: > >> Some reason you aren't using amd64? I will have a system installed that >> way >> and see if I can repro it then, thanks. >> > > > I had found in the past i386 was faster for firewall and routing > applications. Perhaps thats different now, I will give it a try again to > see if there is any difference. > > pciconf and dmesg attached. > > ---Mike > > > > Jack >> >> >> >> On Mon, Nov 9, 2009 at 4:22 PM, Mike Tancsa < >> mike@sentex.net> wrote: >> At 05:59 PM 11/9/2009, Jack Vogel wrote: >> Are you using standard MTU or jumbo? That get_buf error is ENOMEM, looks >> like >> that happens when in the bus_dma stuff reserve_bounce_pages() fails. >> >> Are you maybe using a 32 bit kernel? I have not seen this failure here. >> >> >> Hi Jack, >> Standard MTU and i386 >> >> ---Mike >> >> >> >> -------------------------------------------------------------------- >> Mike Tancsa, tel +1 519 651 3400 >> Sentex Communications, mike@sentex.net >> Providing Internet since 1994 >> www.sentex.net >> Cambridge, Ontario Canada < >> http://www.sentex.net/mike>www.sentex.net/mike >> >> > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > From jfvogel at gmail.com Tue Nov 10 19:20:42 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Nov 10 19:20:55 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <2a41acea0911101057q4f913e30m9319e52bbd254cfe@mail.gmail.com> References: <20091017170351.GZ29771@expo.ukrweb.net> <20091017222314.GB19204@michelle.cdnetworks.com> <200911092033.nA9KX6dD013378@lava.sentex.ca> <200911092215.nA9MFeDP013898@lava.sentex.ca> <2a41acea0911091459w2b4fec5djd64d0324557b7da2@mail.gmail.com> <200911100021.nAA0LvMG014534@lava.sentex.ca> <2a41acea0911091633u2899b47ewb514b6276ba2cf62@mail.gmail.com> <200911100227.nAA2RtDY015177@lava.sentex.ca> <2a41acea0911101057q4f913e30m9319e52bbd254cfe@mail.gmail.com> Message-ID: <2a41acea0911101120o39fd695cpa325736d00b11587@mail.gmail.com> This is a fix for this problem, please apply and test this. Jack ------- if_igb.c (revision 197079) +++ if_igb.c (working copy) @@ -2654,7 +2654,7 @@ int error; error = bus_dma_tag_create(bus_get_dma_tag(adapter->dev), /* parent */ - IGB_DBA_ALIGN, 0, /* alignment, bounds */ + 1, 0, /* alignment, bounds */ BUS_SPACE_MAXADDR, /* lowaddr */ BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ @@ -2867,7 +2867,7 @@ * Setup DMA descriptor areas. */ if ((error = bus_dma_tag_create(NULL, /* parent */ - PAGE_SIZE, 0, /* alignment, bounds */ + 1, 0, /* alignment, bounds */ BUS_SPACE_MAXADDR, /* lowaddr */ BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ @@ -3554,7 +3554,7 @@ ** it may not always use this. */ if ((error = bus_dma_tag_create(NULL, /* parent */ - PAGE_SIZE, 0, /* alignment, bounds */ + 1, 0, /* alignment, bounds */ BUS_SPACE_MAXADDR, /* lowaddr */ BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ On Tue, Nov 10, 2009 at 10:57 AM, Jack Vogel wrote: > I have repro'd this failure this morning and think I have a fix for it, I > am testing that soon. > > Stay tuned, > > Jack > > > > On Mon, Nov 9, 2009 at 6:28 PM, Mike Tancsa wrote: > >> At 07:33 PM 11/9/2009, Jack Vogel wrote: >> >>> Some reason you aren't using amd64? I will have a system installed that >>> way >>> and see if I can repro it then, thanks. >>> >> >> >> I had found in the past i386 was faster for firewall and routing >> applications. Perhaps thats different now, I will give it a try again to >> see if there is any difference. >> >> pciconf and dmesg attached. >> >> ---Mike >> >> >> >> Jack >>> >>> >>> >>> On Mon, Nov 9, 2009 at 4:22 PM, Mike Tancsa < >>> mike@sentex.net> wrote: >>> At 05:59 PM 11/9/2009, Jack Vogel wrote: >>> Are you using standard MTU or jumbo? That get_buf error is ENOMEM, looks >>> like >>> that happens when in the bus_dma stuff reserve_bounce_pages() fails. >>> >>> Are you maybe using a 32 bit kernel? I have not seen this failure here. >>> >>> >>> Hi Jack, >>> Standard MTU and i386 >>> >>> ---Mike >>> >>> >>> >>> -------------------------------------------------------------------- >>> Mike Tancsa, tel +1 519 651 3400 >>> Sentex Communications, mike@sentex.net >>> Providing Internet since 1994 >>> www.sentex.net >>> Cambridge, Ontario Canada < >>> http://www.sentex.net/mike>www.sentex.net/mike >>> >>> >> -------------------------------------------------------------------- >> Mike Tancsa, tel +1 519 651 3400 >> Sentex Communications, mike@sentex.net >> Providing Internet since 1994 www.sentex.net >> Cambridge, Ontario Canada www.sentex.net/mike >> > > From xcllnt at mac.com Tue Nov 10 19:33:36 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Tue Nov 10 19:33:43 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: <4AF9ADF4.5040601@delphij.net> References: <20091002150931.K35591@pooker.samsco.org> <30F3E66A-4A69-46CE-96F4-44B4049722E2@samsco.org> <200911050922.10205.hselasky@c2i.net> <4AF9ADF4.5040601@delphij.net> Message-ID: <094E4A4A-811E-497F-A720-FD36A2D06265@mac.com> On Nov 10, 2009, at 10:16 AM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hans Petter Selasky wrote: >> Hi, >> >> There is a newer patch in USB P4. >> >> The problem is when the /usr partition for example is not residing on the root >> disk, which is the only disk the code is waiting for. Then the patch will make >> the bootup fail. > > What if we teach rc.d scripts to do something like this: > > do { > mount -a && break; > sleep 1; counter++; > } while counter < 30? > > Will this make sense? Or is there any other concerns? We should add more specific control by adding mount options. Just like NFS mounts can be done in the background, so can we have a mount option that doesn't cause a fail when the underlying device isn't there, but instead results in mount blocking until the device arrives. This then can be combined with a background option to have the boot continue while the mount is pending. -- Marcel Moolenaar xcllnt@mac.com From atkin901 at yahoo.com Tue Nov 10 17:16:17 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Tue Nov 10 19:56:11 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <4AF99D53.9030005@icyb.net.ua> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> Message-ID: Andriy Gapon wrote: > on 10/11/2009 17:22 gary.jennejohn@freenet.de said the following: >> Well, OK, I may have misinterpreted what you wrote or have chosen bad >> wording myself to convey the same message. Nonetheless it looks like >> a hardware problem to me. > > [Trying to make up for my previous mistake.] > > The symptom certainly looks like misbehaving hardware, but other information from > the reports seems to suggest that it is possible that this misbehavior might be > caused by software misconfiguring the hardware. > > I would re-test vm.pmap.pg_ps_enabled=0 just to be sure that it was correctly teh > first time. > I would try to see how 8.0-RC1 kernel behaves and in general try to find last > working, first non-working version. > It would be useful to know any (if any) non-default loader.conf and rc.conf > settings or kernel config (if not GENERIC). > > Not a trivial issue unless it is hardware indeed. > Also, you can try adding: hw.mca.enabled="1" in /boot/loader.conf, reboot, and then see if there is a machine check exception on the console during the buildworld. From da.wire at gmail.com Tue Nov 10 19:27:32 2009 From: da.wire at gmail.com (da wire) Date: Tue Nov 10 19:56:44 2009 Subject: 9-CURRENT page fault when loading kernel ipfw nat and if_em Message-ID: Hi, If i load the following rules for example ${ipfwcmd} nat 123 config ip 192.168.0.254 log ${firewall_nat_flags} same_ports reset unreg_only ${ipfwcmd} add 11 nat 123 log ip from any to any out xmit em3 ${ipfwcmd} add 11 nat 123 log ip from any to any in recv em3 ${ipfwcmd} add 14 nat 123 ip4 from any to any via "${oif}" I get the following FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #57: Tue Nov 10 15:23:19 GMT 2009 panic: from debugger GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xc fault code = supervisor write, page not present instruction pointer = 0x20:0xc061819a stack pointer = 0x28:0xe892d60c frame pointer = 0x28:0xe892d8b4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2914 (fetchmail) panic: from debugger cpuid = 0 Uptime: 6m41s Physical memory: 2022 MB Dumping 197 MB: 182 166 150 134 118 102 86 70 54 38 22 6 Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols from /boot/kernel/geom_journal.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_journal.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/ipfw_nat.ko...Reading symbols from /boot/kernel/ipfw_nat.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipfw_nat.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /usr/local/modules/fuse.ko...done. Loaded symbols for /usr/local/modules/fuse.ko Reading symbols from /usr/local/modules/rtc.ko...done. Loaded symbols for /usr/local/modules/rtc.ko #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc08c43e7 in boot (howto=260) at ../../../kern/kern_shutdown.c:416 #2 0xc08c46f2 in panic (fmt=Variable "fmt" is not available. ) at ../../../kern/kern_shutdown.c:579 #3 0xc04d2387 in db_panic (addr=Could not find the frame base for "db_panic". ) at ../../../ddb/db_command.c:478 #4 0xc04d2911 in db_command (last_cmdp=0xc0dee65c, cmd_table=0x0, dopager=1) at ../../../ddb/db_command.c:445 #5 0xc04d2a6a in db_command_loop () at ../../../ddb/db_command.c:498 #6 0xc04d48dd in db_trap (type=12, code=0) at ../../../ddb/db_main.c:229 #7 0xc08f3016 in kdb_trap (type=12, code=0, tf=0xe892d5cc) at ../../../kern/subr_kdb.c:535 #8 0xc0bfdf8f in trap_fatal (frame=0xe892d5cc, eva=12) at ../../../i386/i386/trap.c:929 #9 0xc0bfe230 in trap_pfault (frame=0xe892d5cc, usermode=0, eva=12) at ../../../i386/i386/trap.c:851 #10 0xc0bfec73 in trap (frame=0xe892d5cc) at ../../../i386/i386/trap.c:533 #11 0xc0be11eb in calltrap () at ../../../i386/i386/exception.s:165 #12 0xc061819a in em_xmit (adapter=0xc6451000, m_headp=Variable "m_headp" is not available. ) at ../../../dev/e1000/if_em.c:3791 #13 0xc061b5ff in em_mq_start_locked (ifp=0xc643c000, m=0xc736c300) at ../../../dev/e1000/if_em.c:1037 #14 0xc061bc70 in em_mq_start (ifp=0xc643c000, m=0xc736c300) at ../../../dev/e1000/if_em.c:1097 #15 0xc096fa80 in ether_output_frame (ifp=0xc643c000, m=0xc736c300) at ../../../net/if_ethersubr.c:452 #16 0xc0970443 in ether_output (ifp=0xc643c000, m=0xc736c300, dst=0xc6844950, ro=0xe892da10) at ../../../net/if_ethersubr.c:423 #17 0xc09d6d08 in ip_output (m=0xc69ab300, opt=0x0, ro=0xe892da10, flags=Variable "flags" is not available. ) at ../../../netinet/ip_output.c:620 #18 0xc0a42daf in tcp_output (tp=0xc7087c58) at ../../../netinet/tcp_output.c:1187 #19 0xc0a4f84a in tcp_usr_send (so=0xc70f5670, flags=0, m=0xc672b700, nam=0x0, control=0x0, td=0xc70e8230) at tcp_offload.h:282 #20 0xc09266f5 in sosend_generic (so=0xc70f5670, addr=0x0, uio=0xe892dc58, top=0xc672b700, control=0x0, flags=0, td=0xc70e8230) at ../../../kern/uipc_socket.c:1265 #21 0xc092218f in sosend (so=0xc70f5670, addr=0x0, uio=0xe892dc58, top=0x0, control=0x0, flags=0, td=0xc70e8230) at ../../../kern/uipc_socket.c:1309 #22 0xc0909c0a in soo_write (fp=0xc6862d20, uio=0xe892dc58, active_cred=0xc6803680, flags=0, td=0xc70e8230) at ../../../kern/sys_socket.c:102 #23 0xc09037c7 in dofilewrite (td=0xc70e8230, fd=3, fp=0xc6862d20, auio=0xe892dc58, offset=-1, flags=0) at file.h:239 #24 0xc0903ab8 in kern_writev (td=0xc70e8230, fd=3, auio=0xe892dc58) at ../../../kern/sys_generic.c:446 #25 0xc0903b3f in write (td=0xc70e8230, uap=0xe892dcf8) at ../../../kern/sys_generic.c:362 #26 0xc0bfe575 in syscall (frame=0xe892dd38) at ../../../i386/i386/trap.c:1078 #27 0xc0be1250 in Xint0x80_syscall () at ../../../i386/i386/exception.s:261 #28 0x00000033 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) I was wondering if its anything similar to this post http://www.mail-archive.com/freebsd-net@freebsd.org/msg31015.html Any help would be great. Simon From atkin901 at yahoo.com Tue Nov 10 19:29:31 2009 From: atkin901 at yahoo.com (Mark Atkinson) Date: Tue Nov 10 19:56:58 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091110184821.4f58a0bf@orwell.free.de> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> <20091110184821.4f58a0bf@orwell.free.de> Message-ID: Kai Gallasch wrote: > Am Tue, 10 Nov 2009 19:05:23 +0200 > schrieb Andriy Gapon : > >> on 10/11/2009 17:22 gary.jennejohn@freenet.de said the following: >>> Well, OK, I may have misinterpreted what you wrote or have chosen >>> bad wording myself to convey the same message. Nonetheless it >>> looks like a hardware problem to me. >> [Trying to make up for my previous mistake.] >> >> The symptom certainly looks like misbehaving hardware, but other >> information from the reports seems to suggest that it is possible >> that this misbehavior might be caused by software misconfiguring the >> hardware. > > Hi. > > This thread was started by me. In the meantime I filed a PR: > http://www.freebsd.org/cgi/query-pr.cgi?pr=140338 > >> I would re-test vm.pmap.pg_ps_enabled=0 just to be sure that it was >> correctly teh first time. > > I toggled vm.pmap.pg_ps_enabled three times between reboots and the > result is always the same. superpages enabled: reboot, superpages not > enabled: server stable > >> I would try to see how 8.0-RC1 kernel behaves and in general try to >> find last working, first non-working version. > 8.0RC1, 8.0BETA4 already showed the same behaviour > >> It would be useful to know any (if any) non-default loader.conf and >> rc.conf settings or kernel config (if not GENERIC). > > loader.conf untouched, rc.conf had just settings for networking active > when testing. In the end I enabled some other stuff to have it ready for > 8.0 RELEASE, *after* I found out that disabling superpages helped > against the crashes. > > Ah yes. I also ran memtest86 on the server for about half a day - no > problems. > > But read for yourself in the PR. > > I don't rule out that this behaviour with vm.pmap.pg_ps_enabled maybe > hardware related, but why then is the server running stable > with RELENG_7 and memtest and server diagnostics don't report any > problem? See the following, where I noticed this problem first a long time ago on my HPDL385g5. It also passed memtest86 for days and I was able to swap out memory modules to the same result. http://article.gmane.org/gmane.os.freebsd.current/111307 I suspect this is actually a machine check exception you're seeing, which you'll notice if you enable hw.mca.enabled="1", and superpages, then do buildworld. Using -j doesn't matter, it's just takes longer to throw an exception. I'm hoping this is the rev E lfence problem, even though my chips are not targetted. When and if a patch goes into -current, I'll try it out to see if the problem with superpages goes away. -Mark From mike at sentex.net Tue Nov 10 20:18:05 2009 From: mike at sentex.net (Mike Tancsa) Date: Tue Nov 10 20:18:13 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <2a41acea0911101120o39fd695cpa325736d00b11587@mail.gmail.co m> References: <20091017170351.GZ29771@expo.ukrweb.net> <20091017222314.GB19204@michelle.cdnetworks.com> <200911092033.nA9KX6dD013378@lava.sentex.ca> <200911092215.nA9MFeDP013898@lava.sentex.ca> <2a41acea0911091459w2b4fec5djd64d0324557b7da2@mail.gmail.com> <200911100021.nAA0LvMG014534@lava.sentex.ca> <2a41acea0911091633u2899b47ewb514b6276ba2cf62@mail.gmail.com> <200911100227.nAA2RtDY015177@lava.sentex.ca> <2a41acea0911101057q4f913e30m9319e52bbd254cfe@mail.gmail.com> <2a41acea0911101120o39fd695cpa325736d00b11587@mail.gmail.com> Message-ID: <200911102018.nAAKI3s7021614@lava.sentex.ca> At 02:20 PM 11/10/2009, Jack Vogel wrote: >This is a fix for this problem, please apply and test this. Hi, Thanks! Yes, I am able to use both ports of the NIC now and no panics yet. Prior to this patch, bringing up both ports resulted in a non functioning NIC and panic! Generating some UDP and tcp traffic through the box, all seems to be OK on first blush. I will try some more extensive tests over the next little while. igb0: Excessive collisions = 0 igb0: Sequence errors = 0 igb0: Defer count = 0 igb0: Missed Packets = 0 igb0: Receive No Buffers = 40 igb0: Receive Length Errors = 0 igb0: Receive errors = 2 igb0: Crc errors = 4 igb0: Alignment errors = 0 igb0: Collision/Carrier extension errors = 0 igb0: RX overruns = 0 igb0: watchdog timeouts = 0 igb0: XON Rcvd = 0 igb0: XON Xmtd = 0 igb0: XOFF Rcvd = 0 igb0: XOFF Xmtd = 0 igb0: Good Packets Rcvd = 103212774 igb0: Good Packets Xmtd = 9347339 igb0: TSO Contexts Xmtd = 0 igb0: TSO Contexts Failed = 0 igb1: Excessive collisions = 0 igb1: Sequence errors = 0 igb1: Defer count = 0 igb1: Missed Packets = 0 igb1: Receive No Buffers = 0 igb1: Receive Length Errors = 0 igb1: Receive errors = 0 igb1: Crc errors = 0 igb1: Alignment errors = 0 igb1: Collision/Carrier extension errors = 0 igb1: RX overruns = 0 igb1: watchdog timeouts = 0 igb1: XON Rcvd = 0 igb1: XON Xmtd = 0 igb1: XOFF Rcvd = 0 igb1: XOFF Xmtd = 0 igb1: Good Packets Rcvd = 9365642 igb1: Good Packets Xmtd = 17781877 igb1: TSO Contexts Xmtd = 988 igb1: TSO Contexts Failed = 0 # ./netsend 10.255.255.3 600 300 280000 10 Sending packet of payload size 300 every 0.000003571s for 10 seconds start: 1257884127.000000000 finish: 1257884137.000003339 send calls: 2800336 send errors: 1970 approx send rate: 279836 approx error rate: 0 waited: 1259257 approx waits/sec: 125925 approx wait rate: 0 # traceroute 10.255.255.3 traceroute to 10.255.255.3 (10.255.255.3), 64 hops max, 40 byte packets 1 1.1.1.1 (1.1.1.1) 0.096 ms 0.073 ms 0.115 ms 2 10.255.255.3 (10.255.255.3) 67.953 ms 0.297 ms 0.241 ms The box with the igb nics has the interfaces 1.1.1.1 and 10.255.255.1 ---Mike >Jack > >------- if_igb.c (revision 197079) >+++ if_igb.c (working copy) >@@ -2654,7 +2654,7 @@ > int error; > > error = bus_dma_tag_create(bus_get_dma_tag(adapter->dev), /* parent */ >- IGB_DBA_ALIGN, 0, /* alignment, bounds */ >+ 1, 0, /* alignment, bounds */ > BUS_SPACE_MAXADDR, /* lowaddr */ > BUS_SPACE_MAXADDR, /* highaddr */ > NULL, NULL, /* filter, filterarg */ >@@ -2867,7 +2867,7 @@ > * Setup DMA descriptor areas. > */ > if ((error = bus_dma_tag_create(NULL, /* parent */ >- PAGE_SIZE, 0, /* alignment, bounds */ >+ 1, 0, /* alignment, bounds */ > BUS_SPACE_MAXADDR, /* lowaddr */ > BUS_SPACE_MAXADDR, /* highaddr */ > NULL, NULL, /* filter, filterarg */ >@@ -3554,7 +3554,7 @@ > ** it may not always use this. > */ > if ((error = bus_dma_tag_create(NULL, /* parent */ >- PAGE_SIZE, 0, /* alignment, bounds */ >+ 1, 0, /* alignment, bounds */ > BUS_SPACE_MAXADDR, /* lowaddr */ > BUS_SPACE_MAXADDR, /* highaddr */ > NULL, NULL, /* filter, filterarg */ > > > >On Tue, Nov 10, 2009 at 10:57 AM, Jack Vogel ><jfvogel@gmail.com> wrote: >I have repro'd this failure this morning and think I have a fix for >it, I am testing that soon. > >Stay tuned, > >Jack > > > >On Mon, Nov 9, 2009 at 6:28 PM, Mike Tancsa ><mike@sentex.net> wrote: >At 07:33 PM 11/9/2009, Jack Vogel wrote: >Some reason you aren't using amd64? I will have a system installed that way >and see if I can repro it then, thanks. > > > >I had found in the past i386 was faster for firewall and routing >applications. Perhaps thats different now, I will give it a try >again to see if there is any difference. > >pciconf and dmesg attached. > > ---Mike > > > >Jack > > > >On Mon, Nov 9, 2009 at 4:22 PM, Mike Tancsa ><mike@sentex.net> wrote: >At 05:59 PM 11/9/2009, Jack Vogel wrote: >Are you using standard MTU or jumbo? That get_buf error is ENOMEM, looks like >that happens when in the bus_dma stuff reserve_bounce_pages() fails. > >Are you maybe using a 32 bit kernel? I have not seen this failure here. > > >Hi Jack, > Standard MTU and i386 > > ---Mike > > > >-------------------------------------------------------------------- >Mike Tancsa, tel +1 519 651 3400 >Sentex Communications, mike@sentex.net >Providing Internet since >1994 ><http://www.sentex.net>www.sentex.net >Cambridge, Ontario >Canada ><http://www.sentex.net/mike>www.sentex.net/mike > > >-------------------------------------------------------------------- >Mike Tancsa, tel +1 519 651 3400 >Sentex >Communications, >mike@sentex.net >Providing Internet since >1994 www.sentex.net >Cambridge, Ontario >Canada www.sentex.net/mike > > -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From gaijin.k at gmail.com Tue Nov 10 20:29:50 2009 From: gaijin.k at gmail.com (Alexandre "Sunny" Kovalenko) Date: Tue Nov 10 20:30:18 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <4AF99D53.9030005@icyb.net.ua> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> Message-ID: <1257884975.46072.29.camel@RabbitsDen> On Tue, 2009-11-10 at 19:05 +0200, Andriy Gapon wrote: > on 10/11/2009 17:22 gary.jennejohn@freenet.de said the following: > > Well, OK, I may have misinterpreted what you wrote or have chosen bad > > wording myself to convey the same message. Nonetheless it looks like > > a hardware problem to me. > > [Trying to make up for my previous mistake.] > > The symptom certainly looks like misbehaving hardware, but other information from > the reports seems to suggest that it is possible that this misbehavior might be > caused by software misconfiguring the hardware. > > I would re-test vm.pmap.pg_ps_enabled=0 just to be sure that it was correctly teh > first time. > I would try to see how 8.0-RC1 kernel behaves and in general try to find last > working, first non-working version. To that end, Rui Paulo committed utility to do binary search on the revisions, which will, likely, come handy. >>>> 1. install devel/p5-App-SVN-Bisect >>>> 2. svn checkout http://svn.freebsd.org/base/stable/8 freebsd >>>> 3. svn-bisect --start 198443 --end 198831 start >>>> 4. Build a kernel and test. >>>> If it works, type 'svn-bisect good' >>>> If it doesn't work, type 'svn-bisect bad' >>>> 5. Repeat process from step 4 until svn-bisect finds the culprit >>>> revision. >>>> >>>>http://search.cpan.org/~infinoid/App-SVN-Bisect-0.8/bin/svn-bisect#EXAMPLE -- Alexandre Kovalenko (????????? ?????????) From admin at lissyara.su Tue Nov 10 21:10:17 2009 From: admin at lissyara.su (Alex Keda) Date: Tue Nov 10 21:10:51 2009 Subject: boot stop last few days Message-ID: <4AF9D6B3.3020003@lissyara.su> hi! last 2 days some broken in -CURRENT boot stops with last string: ATA PseudoRAID loaded I have it problem with 2 machine, amd64 FreeBSD HP.lissyara.su 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r199040: Sun Nov 8 15:02:05 MSK 2009 root@HP.lissyara.su:/usr/obj/usr/src/sys/GENERIC amd64 From gavin at FreeBSD.org Tue Nov 10 21:45:09 2009 From: gavin at FreeBSD.org (Gavin Atkinson) Date: Tue Nov 10 21:45:16 2009 Subject: [PATCH] Remove if_watchdog use In-Reply-To: <200911061508.22482.jhb@freebsd.org> References: <200911061508.22482.jhb@freebsd.org> Message-ID: <20091110194048.D61601@ury.york.ac.uk> On Fri, 6 Nov 2009, John Baldwin wrote: > I have a patchset that converts all the remaining users of if_watchdog to > using a private callout instead. In some cases the the driver already used a > private timer to drive a stats timer and I merely hooked into that timer. In > other cases a new callout needed to be added to the driver. Some drivers > even abused the if_watchdog interface to provide a stats timer that fired > every second. :) For a few drivers I also fixed other things such as busted > locking, order-of-operations issues in detach, or just completely busted > drivers (fea(4) and fpa(4) which share the pdq backend). Please test. > Barring any major screaming and shouting I plan to commit this in a week or > so and after that to work on removing the if_watchdog/if_timer stuff from the > network stack. > > The patch is at http://www.FreeBSD.org/~jhb/patches/cleanup.patch > > Driver details: > - an(4) > - Locking fixes to not do silly things like drop the lock only to call a > function that immediately reacquires the lock. Also removes recursive > locking. > - Hooks into the stat timer to drive the watchdog timer. I managed to get a panic when running wpa_supplicant: System call ioctl returning with the following locks held: exclusive sleep mutex an0 (network driver) r=0 (0xc58fc180) locked @ /usr/src/sys/dev/an/if_an.c:2341 panic: witness_warn This seems to fix that: --- /usr/src/sys/dev/an/if_an.c.orig 2009-11-10 19:26:21.000000000 +0000 +++ /usr/src/sys/dev/an/if_an.c 2009-11-10 19:27:24.000000000 +0000 @@ -2570,6 +2570,9 @@ an_setdef(sc, &sc->areq); AN_UNLOCK(sc); break; + default: + AN_UNLOCK(sc); + break; } /* I also get the following LOR on unplug (but see it before your patch too): lock order reversal: 1st 0xc50f5208 if_afdata (if_afdata) @ /usr/src/sys/net/if.c:912 2nd 0xc0f9db68 mld_mtx (mld_mtx) @ /usr/src/sys/netinet6/mld6.c:569 KDB: stack backtrace: db_trace_self_wrapper(c0cb835f,e54b1b20,c08e7b55,c08d891b,c0cbb215,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08d891b,c0cbb215,c4d30e18,c4d2a9c0,e54b1b7c,...) at kdb_backtrace+0x29 _witness_debugger(c0cbb215,c0f9db68,c0cbb365,c4d2a9c0,c0cd457d,...) at _witness_debugger+0x25 witness_checkorder(c0f9db68,9,c0cd457d,239,0,...) at witness_checkorder+0x839 _mtx_lock_flags(c0f9db68,0,c0cd457d,239,c5340ba0,...) at _mtx_lock_flags+0xc9 mld_domifdetach(c50f5000,c0db5e54,c0dc0880,e54b1c24,c09532a6,...) at mld_domifdetach+0x2c in6_domifdetach(c50f5000,c5340ba0,390,4be,c50f522c,...) at in6_domifdetach+0x15 if_detach(c50f5000) at if_detach+0x916 ether_ifdetach(c50f5000,0,c0c6cbbc,34f,c555d380,...) at ether_ifdetach+0x3d an_detach(c555d380,c4ead060,c0da0758,a76,e54b1c94,...) at an_detach+0xb5 device_detach(c555d380,0,c0d5a9b8,0,c4ff6500,...) at device_detach+0x8c pccard_detach_card(c4ff6500,c4e3e8bc,c0d5a9b8) at pccard_detach_card+0x44 exca_removal(c4ed2004,0,c0c93731,1da,c8,...) at exca_removal+0x59 cbb_event_thread(c4ed2000,e54b1d38,c0cb02eb,343,c4d81aa0,...) at cbb_event_thread+0x107 fork_exit(c0720cb0,c4ed2000,e54b1d38) at fork_exit+0xb8 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xe54b1d70, ebp = 0 --- an0: detached Other than that, the patches to an(4) seem to work as well before your patch as after, with light TCP traffic and heavy ping traffic. However, an(4) appears to require a lot of work (unrelated to your patch) to bring it up to the state of other wireless drivers. > - ixgb(4) > - Uses callout_init_mtx() instead of callout_init(..., CALLOUT_MPSAFE). > - Remove silly callout handling in a few places (cancelling the callout > only to rescheduled it again immediately afterwards). > - Hooks into the stat timer to drive the watchdog timer. These changes to ixgb_detach() don't compile as ifp is no longer used in the !DEVICE_POLLING case. /usr/src/sys/dev/ixgb/if_ixgb.c: In function 'ixgb_detach': /usr/src/sys/dev/ixgb/if_ixgb.c:369: warning: unused variable 'ifp' Hope that helps, Gavin From jhb at freebsd.org Tue Nov 10 22:03:04 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Nov 10 22:03:11 2009 Subject: [PATCH] Remove if_watchdog use In-Reply-To: <20091110194048.D61601@ury.york.ac.uk> References: <200911061508.22482.jhb@freebsd.org> <20091110194048.D61601@ury.york.ac.uk> Message-ID: <200911101702.57525.jhb@freebsd.org> On Tuesday 10 November 2009 4:45:03 pm Gavin Atkinson wrote: > On Fri, 6 Nov 2009, John Baldwin wrote: > > > I have a patchset that converts all the remaining users of if_watchdog to > > using a private callout instead. In some cases the the driver already used a > > private timer to drive a stats timer and I merely hooked into that timer. In > > other cases a new callout needed to be added to the driver. Some drivers > > even abused the if_watchdog interface to provide a stats timer that fired > > every second. :) For a few drivers I also fixed other things such as busted > > locking, order-of-operations issues in detach, or just completely busted > > drivers (fea(4) and fpa(4) which share the pdq backend). Please test. > > Barring any major screaming and shouting I plan to commit this in a week or > > so and after that to work on removing the if_watchdog/if_timer stuff from the > > network stack. > > > > The patch is at http://www.FreeBSD.org/~jhb/patches/cleanup.patch > > > > Driver details: > > - an(4) > > - Locking fixes to not do silly things like drop the lock only to call a > > function that immediately reacquires the lock. Also removes recursive > > locking. > > - Hooks into the stat timer to drive the watchdog timer. > > I managed to get a panic when running wpa_supplicant: > > System call ioctl returning with the following locks held: > exclusive sleep mutex an0 (network driver) r=0 (0xc58fc180) locked @ > /usr/src/sys/dev/an/if_an.c:2341 > panic: witness_warn > > This seems to fix that: > > --- /usr/src/sys/dev/an/if_an.c.orig 2009-11-10 19:26:21.000000000 > +0000 > +++ /usr/src/sys/dev/an/if_an.c 2009-11-10 19:27:24.000000000 +0000 > @@ -2570,6 +2570,9 @@ > an_setdef(sc, &sc->areq); > AN_UNLOCK(sc); > break; > + default: > + AN_UNLOCK(sc); > + break; > } > > /* Ok, thanks. Sadly the ioctl handling probably needs a bit more work since it calls copyin() while holding the an(4) mutex, but I will leave that for another day. > I also get the following LOR on unplug (but see it before your patch too): > > lock order reversal: > 1st 0xc50f5208 if_afdata (if_afdata) @ /usr/src/sys/net/if.c:912 > 2nd 0xc0f9db68 mld_mtx (mld_mtx) @ /usr/src/sys/netinet6/mld6.c:569 I think this has to do with the stack in general and is not specific to an(4). > Other than that, the patches to an(4) seem to work as well before your > patch as after, with light TCP traffic and heavy ping traffic. However, > an(4) appears to require a lot of work (unrelated to your patch) to bring > it up to the state of other wireless drivers. Thanks, I will commit the an(4) bits in a bit. > > - ixgb(4) > > - Uses callout_init_mtx() instead of callout_init(..., CALLOUT_MPSAFE). > > - Remove silly callout handling in a few places (cancelling the callout > > only to rescheduled it again immediately afterwards). > > - Hooks into the stat timer to drive the watchdog timer. > > These changes to ixgb_detach() don't compile as ifp is no longer used in > the !DEVICE_POLLING case. > > /usr/src/sys/dev/ixgb/if_ixgb.c: In function 'ixgb_detach': > /usr/src/sys/dev/ixgb/if_ixgb.c:369: warning: unused variable 'ifp' Oops, ixgb isn't in LINT so I keep missing it. I need to just add it to NOTES. Thanks. -- John Baldwin From gavin at freebsd.org Tue Nov 10 22:17:52 2009 From: gavin at freebsd.org (Gavin Atkinson) Date: Tue Nov 10 22:17:59 2009 Subject: [PATCH] Remove if_watchdog use In-Reply-To: <200911101702.57525.jhb@freebsd.org> References: <200911061508.22482.jhb@freebsd.org> <20091110194048.D61601@ury.york.ac.uk> <200911101702.57525.jhb@freebsd.org> Message-ID: <20091110221339.Y61601@ury.york.ac.uk> On Tue, 10 Nov 2009, John Baldwin wrote: > On Tuesday 10 November 2009 4:45:03 pm Gavin Atkinson wrote: >> I managed to get a panic when running wpa_supplicant: >> >> System call ioctl returning with the following locks held: >> exclusive sleep mutex an0 (network driver) r=0 (0xc58fc180) locked @ >> /usr/src/sys/dev/an/if_an.c:2341 >> panic: witness_warn >> >> This seems to fix that: >> >> --- /usr/src/sys/dev/an/if_an.c.orig 2009-11-10 19:26:21.000000000 >> +0000 >> +++ /usr/src/sys/dev/an/if_an.c 2009-11-10 19:27:24.000000000 +0000 >> @@ -2570,6 +2570,9 @@ >> an_setdef(sc, &sc->areq); >> AN_UNLOCK(sc); >> break; >> + default: >> + AN_UNLOCK(sc); >> + break; >> } >> >> /* > > Ok, thanks. Sadly the ioctl handling probably needs a bit more work since it > calls copyin() while holding the an(4) mutex, but I will leave that for > another day. It actually appears that the above panic is not something that has been introduced with your patch - I can reproduce it on a vanilla system. The above patch fixes it in the original code too. Gavin From pjd at FreeBSD.org Tue Nov 10 22:45:32 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Nov 10 22:45:39 2009 Subject: HEADS UP: Important bug fix in ZFS replay code! In-Reply-To: <200911102227.nAAMRXTf073603@svn.freebsd.org> References: <200911102227.nAAMRXTf073603@svn.freebsd.org> Message-ID: <20091110224524.GC3194@garage.freebsd.pl> Hi. There was important bug in ZFS replay code. If there were setattr logs (not related to permission change) in ZIL during unclean shutdown, one can end up with files that have mode set to 07777. This is very dangerous, especially if you have untrusted local users, as this will set setuid bit on such files. Note that FreeBSD will remove setuid bits when someone will try to modify the file, but it is still dangerous. You can locate such files with the following command: # find / -perm -7777 -print0 | xargs -0 ls -ld You can locate and fix such files with the following command: # find / -perm -7777 -print0 | xargs -0 chmod a-s,o-w,-t On Tue, Nov 10, 2009 at 10:27:33PM +0000, Pawel Jakub Dawidek wrote: > Author: pjd > Date: Tue Nov 10 22:27:33 2009 > New Revision: 199157 > URL: http://svn.freebsd.org/changeset/base/199157 > > Log: > Be careful which vattr fields are set during setattr replay. > Without this fix strange things can appear after unclean shutdown like > files with mode set to 07777. > > Reported by: des > MFC after: 3 days > > Modified: > head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_replay.c > > Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_replay.c > ============================================================================== > --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_replay.c Tue Nov 10 22:25:46 2009 (r199156) > +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_replay.c Tue Nov 10 22:27:33 2009 (r199157) > @@ -60,10 +60,14 @@ zfs_init_vattr(vattr_t *vap, uint64_t ma > { > VATTR_NULL(vap); > vap->va_mask = (uint_t)mask; > - vap->va_type = IFTOVT(mode); > - vap->va_mode = mode & MODEMASK; > - vap->va_uid = (uid_t)(IS_EPHEMERAL(uid)) ? -1 : uid; > - vap->va_gid = (gid_t)(IS_EPHEMERAL(gid)) ? -1 : gid; > + if (mask & AT_TYPE) > + vap->va_type = IFTOVT(mode); > + if (mask & AT_MODE) > + vap->va_mode = mode & MODEMASK; > + if (mask & AT_UID) > + vap->va_uid = (uid_t)(IS_EPHEMERAL(uid)) ? -1 : uid; > + if (mask & AT_GID) > + vap->va_gid = (gid_t)(IS_EPHEMERAL(gid)) ? -1 : gid; > vap->va_rdev = zfs_cmpldev(rdev); > vap->va_nodeid = nodeid; > } -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091110/9ffc89b7/attachment.pgp From anti_spam256 at yahoo.ca Wed Nov 11 06:59:12 2009 From: anti_spam256 at yahoo.ca (James Phillips) Date: Wed Nov 11 06:59:22 2009 Subject: Call for testers: fxp(4) WOL Message-ID: <873263.68116.qm@web65502.mail.ac4.yahoo.com> Original From: Pyun YongHyeon date: Wed, 15 Oct 2008 09:37:45 +0900 Hello, I was finally able to test the WOL on my machine, a pre-2000 Compaq Deskpro Running an Intel 82558 Pro/100 Ethernet NIC with WOL. This card only supports "Magic Packets." I had to enable APM instead of ACPI; following these instructions: http://forums.freebsd.org/showthread.php?t=4619 (On my first try I made a show-stopping typo as well). FreeBSD version: 7.2-RELEASE-p2 GENERIC i386 Some selected boot messages: apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 . . . fxp0 options = 2000 < VLAN_MTU, WOL_MAGIC> # apm APM version: 1.2 APM Management: Enabled AC Line Status: on-line Battery Status: unknown Remaining battery life: unknown Remaining battery time: unknown Number of batteries: 0 Resume timer: disabled Resume on ring indicator: disabled APM Capabilities: global standby state global suspend state resume timer from standby resume timer from suspend RI resume from standby RI resume from suspend # zzz -> Screen flickered, did not respond to pings. >From router: [gate@Freesco] wakelan -h Usage: wakelan [options] [mac] [broadcast] [port] -b addr broadcast address -m mac mac address of host -p port UDP port to broadcast to -v[v] version [gate@Freesco] wakelan -b 192.168.26.255 -m 00:08:c7:bb:83:d8 -> Machine again responded to pings. Ping results with the Power/Suspend Switch activated in the middle (no WOL this time): james@test:~$ ping dusty PING dusty.inet (192.168.26.69) 56(84) bytes of data. 64 bytes from dusty (192.168.26.69): icmp_seq=1 ttl=64 time=3.87 ms 64 bytes from dusty (192.168.26.69): icmp_seq=2 ttl=64 time=3.06 ms 64 bytes from dusty (192.168.26.69): icmp_seq=3 ttl=64 time=0.174 ms 64 bytes from dusty (192.168.26.69): icmp_seq=4 ttl=64 time=0.187 ms 64 bytes from dusty (192.168.26.69): icmp_seq=5 ttl=64 time=0.178 ms 64 bytes from dusty (192.168.26.69): icmp_seq=6 ttl=64 time=0.188 ms 64 bytes from dusty (192.168.26.69): icmp_seq=7 ttl=64 time=0.176 ms 64 bytes from dusty (192.168.26.69): icmp_seq=8 ttl=64 time=0.200 ms 64 bytes from dusty (192.168.26.69): icmp_seq=9 ttl=64 time=0.192 ms 64 bytes from dusty (192.168.26.69): icmp_seq=10 ttl=64 time=3.97 ms 64 bytes from dusty (192.168.26.69): icmp_seq=22 ttl=64 time=0.229 ms 64 bytes from dusty (192.168.26.69): icmp_seq=23 ttl=64 time=0.195 ms 64 bytes from dusty (192.168.26.69): icmp_seq=24 ttl=64 time=0.166 ms 64 bytes from dusty (192.168.26.69): icmp_seq=25 ttl=64 time=0.178 ms 64 bytes from dusty (192.168.26.69): icmp_seq=26 ttl=64 time=0.176 ms 64 bytes from dusty (192.168.26.69): icmp_seq=27 ttl=64 time=0.182 ms 64 bytes from dusty (192.168.26.69): icmp_seq=28 ttl=64 time=0.184 ms 64 bytes from dusty (192.168.26.69): icmp_seq=29 ttl=64 time=0.181 ms 64 bytes from dusty (192.168.26.69): icmp_seq=30 ttl=64 time=0.176 ms 64 bytes from dusty (192.168.26.69): icmp_seq=31 ttl=64 time=0.158 ms --- dusty.inet ping statistics --- 31 packets transmitted, 20 received, 35% packet loss, time 29999ms rtt min/avg/max/mdev = 0.158/0.701/3.970/1.242 ms -> As expected. I am working on getting my router to automatically wake up the server when a client machine wakes-up/connects to the network. I have been feeling guilty leaving my server idling 24/7 even if it is barely used. Regards, James Phillips __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. From mav at FreeBSD.org Wed Nov 11 09:06:52 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Nov 11 09:06:59 2009 Subject: boot stop last few days In-Reply-To: <1257898985.00182387.1257888001@10.7.7.3> References: <1257898985.00182387.1257888001@10.7.7.3> Message-ID: <4AFA7EA7.60401@FreeBSD.org> Alex Keda wrote: > last 2 days some broken in -CURRENT > boot stops with last string: > > ATA PseudoRAID loaded > > I have it problem with 2 machine, amd64 > > FreeBSD HP.lissyara.su 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r199040: Sun > Nov 8 15:02:05 MSK 2009 > root@HP.lissyara.su:/usr/obj/usr/src/sys/GENERIC amd64 Any additional info? Which revision works and which broke? -- Alexander Motin From ed at 80386.nl Wed Nov 11 10:01:55 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Nov 11 10:02:03 2009 Subject: boot stop last few days In-Reply-To: <4AF9D6B3.3020003@lissyara.su> References: <4AF9D6B3.3020003@lissyara.su> Message-ID: <20091111100153.GE64905@hoeg.nl> Hi Alex, * Alex Keda wrote: > last 2 days some broken in -CURRENT > boot stops with last string: This could be related to r199067. kuriyama@ sent me some patches to test, but I still have to find some time to do so. http://lists.freebsd.org/pipermail/svn-src-head/2009-November/011639.html -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091111/037a96cb/attachment.pgp From ed at 80386.nl Wed Nov 11 10:12:08 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Nov 11 10:12:16 2009 Subject: Final call for testers: TERM=xterm Message-ID: <20091111101207.GF64905@hoeg.nl> Hi folks, I just committed some patches to SVN that should complete the Xterm- style terminal emulator support. This means we can just share the same termcap entry between the console driver and X11 terminal emulators, which has many advantages, including: - The ability to use dtach(1) without problems. - Support for more advanced (networking) devices with serial administrative interfaces. - Better compatibility with other operating systems. - Reduced bandwidth. I'd like to flip the switch one of these days on all platforms, except i386. On i386 the /etc/ttys file is shared between i386 and pc98. pc98 will still use its own cons25 emulator instead of the xterm emulator, so I'll initially convert all the other platforms and deal with i386 (and hopefully pc98) later. I'll discuss this with nyan@. How to test this: 1. Make sure you run 9.0-CURRENT SVN r199175 or later. 2. Run `vidcontrol -T xterm'. 3. Run `export TERM=xterm'. After doing this, you shouldn't notice a lot. Make sure applications like your shell, your editor, etc. still work as expected. Known issues: - Right now we only implement the VT220 mouse protocol. This means your mouse should still work properly, but applications are only capable of detecting drags/selections after releasing the mouse button. This could eventually be solved by implementing the Xterm mouse protocol. If no serious problems arise, I'll make Xterm the default on Friday/Saturday. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091111/6a3826ca/attachment.pgp From gary.jennejohn at freenet.de Wed Nov 11 13:02:21 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Wed Nov 11 13:02:27 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <20091111101207.GF64905@hoeg.nl> References: <20091111101207.GF64905@hoeg.nl> Message-ID: <20091111140216.56e63ac6@ernst.jennejohn.org> On Wed, 11 Nov 2009 11:12:07 +0100 Ed Schouten wrote: > I just committed some patches to SVN that should complete the Xterm- > style terminal emulator support. This means we can just share the same > termcap entry between the console driver and X11 terminal emulators, > which has many advantages, including: > [snip] > If no serious problems arise, I'll make Xterm the default on > Friday/Saturday. > I'm running AMD64. Arrow keys don't work correctly. For example, if I do "make config" in a port then using the down arrow immediately exits the menu rather than moving the cursor. The same thing happens with sade. Note that I set one entry in /etc/ttys to xterm rather than using the vidcontrol trick. With cons25 it works correctly. I merely installed and booted a new kernel. Not sure whether I also need a new termcap. --- Gary Jennejohn From avg at icyb.net.ua Wed Nov 11 13:09:31 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Nov 11 13:09:38 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091110184821.4f58a0bf@orwell.free.de> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> <20091110184821.4f58a0bf@orwell.free.de> Message-ID: <4AFAB772.2050303@icyb.net.ua> on 10/11/2009 19:48 Kai Gallasch said the following: > Am Tue, 10 Nov 2009 19:05:23 +0200 > schrieb Andriy Gapon : > >> on 10/11/2009 17:22 gary.jennejohn@freenet.de said the following: >>> Well, OK, I may have misinterpreted what you wrote or have chosen >>> bad wording myself to convey the same message. Nonetheless it >>> looks like a hardware problem to me. >> [Trying to make up for my previous mistake.] >> >> The symptom certainly looks like misbehaving hardware, but other >> information from the reports seems to suggest that it is possible >> that this misbehavior might be caused by software misconfiguring the >> hardware. > > Hi. > > This thread was started by me. In the meantime I filed a PR: > http://www.freebsd.org/cgi/query-pr.cgi?pr=140338 > >> I would re-test vm.pmap.pg_ps_enabled=0 just to be sure that it was >> correctly teh first time. > > I toggled vm.pmap.pg_ps_enabled three times between reboots and the > result is always the same. superpages enabled: reboot, superpages not > enabled: server stable Yes, I saw your report. I was following on the other report where the symptoms are very similar but pg_ps_enabled does not seem to help. >> I would try to see how 8.0-RC1 kernel behaves and in general try to >> find last working, first non-working version. > 8.0RC1, 8.0BETA4 already showed the same behaviour > >> It would be useful to know any (if any) non-default loader.conf and >> rc.conf settings or kernel config (if not GENERIC). > > loader.conf untouched, rc.conf had just settings for networking active > when testing. In the end I enabled some other stuff to have it ready for > 8.0 RELEASE, *after* I found out that disabling superpages helped > against the crashes. > > Ah yes. I also ran memtest86 on the server for about half a day - no > problems. > > But read for yourself in the PR. > > I don't rule out that this behaviour with vm.pmap.pg_ps_enabled maybe > hardware related, but why then is the server running stable > with RELENG_7 and memtest and server diagnostics don't report any > problem? What I meant is that sometimes software can incorrectly configure hardware. Or configure it in a way that was thoroughly tested by manufacturer. I didn't mean to say that your hardware has any defect (but perhaps it does, hardware errata don't exist for nothing). -- Andriy Gapon From ed at 80386.nl Wed Nov 11 13:40:36 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Nov 11 13:40:43 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <20091111140216.56e63ac6@ernst.jennejohn.org> References: <20091111101207.GF64905@hoeg.nl> <20091111140216.56e63ac6@ernst.jennejohn.org> Message-ID: <710B0B1E-50E7-4194-8697-0511087D4C7A@80386.nl> Hi Gary, Have you made sure you ran vidcontrol on that specific window? You can also add TEKEN_XTERM to your kernel config. I thought dialog worked properly, but I'll test it again this evening. -- Ed Schouten (from iPod) WWW: http://80386.nl/ On 11 nov 2009, at 14:02, Gary Jennejohn wrote: > On Wed, 11 Nov 2009 11:12:07 +0100 > Ed Schouten wrote: > >> I just committed some patches to SVN that should complete the Xterm- >> style terminal emulator support. This means we can just share the >> same >> termcap entry between the console driver and X11 terminal emulators, >> which has many advantages, including: >> > [snip] >> If no serious problems arise, I'll make Xterm the default on >> Friday/Saturday. >> > > I'm running AMD64. > > Arrow keys don't work correctly. For example, if I do "make config" > in a port then using the down arrow immediately exits the menu rather > than moving the cursor. The same thing happens with sade. > > Note that I set one entry in /etc/ttys to xterm rather than using the > vidcontrol trick. > > With cons25 it works correctly. > > I merely installed and booted a new kernel. Not sure whether I also > need a new termcap. > > --- > Gary Jennejohn > From gary.jennejohn at freenet.de Wed Nov 11 13:51:48 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Wed Nov 11 13:51:55 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <710B0B1E-50E7-4194-8697-0511087D4C7A@80386.nl> References: <20091111101207.GF64905@hoeg.nl> <20091111140216.56e63ac6@ernst.jennejohn.org> <710B0B1E-50E7-4194-8697-0511087D4C7A@80386.nl> Message-ID: <20091111145145.0d958ade@ernst.jennejohn.org> On Wed, 11 Nov 2009 14:40:28 +0100 Ed Schouten wrote: > Have you made sure you ran vidcontrol on that specific window? You can > also add TEKEN_XTERM to your kernel config. I thought dialog worked > properly, but I'll test it again this evening. > I already mentioned what I did in the first mail: > > Note that I set one entry in /etc/ttys to xterm rather than using the > > vidcontrol trick. > > --- Gary Jennejohn From tinderbox at freebsd.org Wed Nov 11 13:55:40 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Nov 11 13:55:52 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <200911111257.nABCvnwb003371@freebsd-current.sentex.ca> TB --- 2009-11-11 11:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-11 11:55:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-11-11 11:55:00 - cleaning the object tree TB --- 2009-11-11 11:55:19 - cvsupping the source tree TB --- 2009-11-11 11:55:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-11-11 11:55:51 - building world TB --- 2009-11-11 11:55:51 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-11 11:55:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-11 11:55:51 - TARGET=pc98 TB --- 2009-11-11 11:55:51 - TARGET_ARCH=i386 TB --- 2009-11-11 11:55:51 - TZ=UTC TB --- 2009-11-11 11:55:51 - __MAKE_CONF=/dev/null TB --- 2009-11-11 11:55:51 - cd /src TB --- 2009-11-11 11:55:51 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 11 11:55:54 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 11 12:54:35 UTC 2009 TB --- 2009-11-11 12:54:35 - generating LINT kernel config TB --- 2009-11-11 12:54:35 - cd /src/sys/pc98/conf TB --- 2009-11-11 12:54:35 - /usr/bin/make -B LINT TB --- 2009-11-11 12:54:35 - building LINT kernel TB --- 2009-11-11 12:54:35 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-11 12:54:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-11 12:54:35 - TARGET=pc98 TB --- 2009-11-11 12:54:35 - TARGET_ARCH=i386 TB --- 2009-11-11 12:54:35 - TZ=UTC TB --- 2009-11-11 12:54:35 - __MAKE_CONF=/dev/null TB --- 2009-11-11 12:54:35 - cd /src TB --- 2009-11-11 12:54:35 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 11 12:54:35 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_sim.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_xpt.c /src/sys/cam/cam_xpt.c:288: error: static declaration of 'xpt_start_tags' follows non-static declaration /src/sys/cam/cam_xpt_internal.h:179: error: previous declaration of 'xpt_start_tags' was here cc1: warnings being treated as errors /src/sys/cam/cam_xpt.c: In function 'xpt_action_default': /src/sys/cam/cam_xpt.c:2525: warning: implicit declaration of function 'xpt_schedule_dev_sendq' /src/sys/cam/cam_xpt.c:2525: warning: nested extern declaration of 'xpt_schedule_dev_sendq' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-11 12:57:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-11 12:57:49 - ERROR: failed to build lint kernel TB --- 2009-11-11 12:57:49 - 2726.30 user 642.27 system 3769.65 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From tinderbox at freebsd.org Wed Nov 11 14:01:52 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Nov 11 14:02:05 2009 Subject: [head tinderbox] failure on i386/i386 Message-ID: <200911111304.nABD42uZ067441@freebsd-current.sentex.ca> TB --- 2009-11-11 11:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-11 11:55:00 - starting HEAD tinderbox run for i386/i386 TB --- 2009-11-11 11:55:00 - cleaning the object tree TB --- 2009-11-11 11:55:29 - cvsupping the source tree TB --- 2009-11-11 11:55:29 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2009-11-11 12:01:04 - building world TB --- 2009-11-11 12:01:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-11 12:01:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-11 12:01:04 - TARGET=i386 TB --- 2009-11-11 12:01:04 - TARGET_ARCH=i386 TB --- 2009-11-11 12:01:04 - TZ=UTC TB --- 2009-11-11 12:01:04 - __MAKE_CONF=/dev/null TB --- 2009-11-11 12:01:04 - cd /src TB --- 2009-11-11 12:01:04 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 11 12:01:05 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 11 13:00:24 UTC 2009 TB --- 2009-11-11 13:00:24 - generating LINT kernel config TB --- 2009-11-11 13:00:24 - cd /src/sys/i386/conf TB --- 2009-11-11 13:00:24 - /usr/bin/make -B LINT TB --- 2009-11-11 13:00:24 - building LINT kernel TB --- 2009-11-11 13:00:24 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-11 13:00:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-11 13:00:24 - TARGET=i386 TB --- 2009-11-11 13:00:24 - TARGET_ARCH=i386 TB --- 2009-11-11 13:00:24 - TZ=UTC TB --- 2009-11-11 13:00:24 - __MAKE_CONF=/dev/null TB --- 2009-11-11 13:00:24 - cd /src TB --- 2009-11-11 13:00:24 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 11 13:00:24 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_sim.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_xpt.c /src/sys/cam/cam_xpt.c:288: error: static declaration of 'xpt_start_tags' follows non-static declaration /src/sys/cam/cam_xpt_internal.h:179: error: previous declaration of 'xpt_start_tags' was here cc1: warnings being treated as errors /src/sys/cam/cam_xpt.c: In function 'xpt_action_default': /src/sys/cam/cam_xpt.c:2525: warning: implicit declaration of function 'xpt_schedule_dev_sendq' /src/sys/cam/cam_xpt.c:2525: warning: nested extern declaration of 'xpt_schedule_dev_sendq' *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-11 13:04:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-11 13:04:02 - ERROR: failed to build lint kernel TB --- 2009-11-11 13:04:02 - 2775.27 user 636.39 system 4142.33 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From tinderbox at freebsd.org Wed Nov 11 14:27:39 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Nov 11 14:27:45 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <200911111329.nABDTmKR001765@freebsd-current.sentex.ca> TB --- 2009-11-11 11:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-11 11:55:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-11-11 11:55:00 - cleaning the object tree TB --- 2009-11-11 11:55:32 - cvsupping the source tree TB --- 2009-11-11 11:55:32 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-11-11 12:01:04 - building world TB --- 2009-11-11 12:01:04 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-11 12:01:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-11 12:01:04 - TARGET=amd64 TB --- 2009-11-11 12:01:04 - TARGET_ARCH=amd64 TB --- 2009-11-11 12:01:04 - TZ=UTC TB --- 2009-11-11 12:01:04 - __MAKE_CONF=/dev/null TB --- 2009-11-11 12:01:04 - cd /src TB --- 2009-11-11 12:01:04 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 11 12:01:05 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Nov 11 13:26:30 UTC 2009 TB --- 2009-11-11 13:26:30 - generating LINT kernel config TB --- 2009-11-11 13:26:30 - cd /src/sys/amd64/conf TB --- 2009-11-11 13:26:30 - /usr/bin/make -B LINT TB --- 2009-11-11 13:26:30 - building LINT kernel TB --- 2009-11-11 13:26:30 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-11 13:26:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-11 13:26:30 - TARGET=amd64 TB --- 2009-11-11 13:26:30 - TARGET_ARCH=amd64 TB --- 2009-11-11 13:26:30 - TZ=UTC TB --- 2009-11-11 13:26:30 - __MAKE_CONF=/dev/null TB --- 2009-11-11 13:26:30 - cd /src TB --- 2009-11-11 13:26:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 11 13:26:30 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_sim.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_xpt.c /src/sys/cam/cam_xpt.c:288: error: static declaration of 'xpt_start_tags' follows non-static declaration /src/sys/cam/cam_xpt_internal.h:179: error: previous declaration of 'xpt_start_tags' was here cc1: warnings being treated as errors /src/sys/cam/cam_xpt.c: In function 'xpt_action_default': /src/sys/cam/cam_xpt.c:2525: warning: implicit declaration of function 'xpt_schedule_dev_sendq' /src/sys/cam/cam_xpt.c:2525: warning: nested extern declaration of 'xpt_schedule_dev_sendq' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-11 13:29:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-11 13:29:48 - ERROR: failed to build lint kernel TB --- 2009-11-11 13:29:48 - 3935.70 user 916.02 system 5688.78 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From onemda at gmail.com Wed Nov 11 14:44:58 2009 From: onemda at gmail.com (Paul B Mahol) Date: Wed Nov 11 14:45:04 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <20091111101207.GF64905@hoeg.nl> References: <20091111101207.GF64905@hoeg.nl> Message-ID: <3a142e750911110644p10de9e15w46c2c7adbd295773@mail.gmail.com> On 11/11/09, Ed Schouten wrote: > Hi folks, > > I just committed some patches to SVN that should complete the Xterm- > style terminal emulator support. This means we can just share the same > termcap entry between the console driver and X11 terminal emulators, > which has many advantages, including: > > - The ability to use dtach(1) without problems. > - Support for more advanced (networking) devices with serial > administrative interfaces. > - Better compatibility with other operating systems. > - Reduced bandwidth. > > I'd like to flip the switch one of these days on all platforms, except > i386. On i386 the /etc/ttys file is shared between i386 and pc98. pc98 > will still use its own cons25 emulator instead of the xterm emulator, so > I'll initially convert all the other platforms and deal with i386 (and > hopefully pc98) later. I'll discuss this with nyan@. > > How to test this: > > 1. Make sure you run 9.0-CURRENT SVN r199175 or later. > 2. Run `vidcontrol -T xterm'. > 3. Run `export TERM=xterm'. > > After doing this, you shouldn't notice a lot. Make sure applications > like your shell, your editor, etc. still work as expected. It would be nice that keeping shift key pressed and pressing middle mouse key works like it does in xterm. From tinderbox at freebsd.org Wed Nov 11 15:00:20 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Nov 11 15:00:32 2009 Subject: [head tinderbox] failure on ia64/ia64 Message-ID: <200911111402.nABE2Uwh052394@freebsd-current.sentex.ca> TB --- 2009-11-11 12:43:26 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-11 12:43:26 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-11-11 12:43:26 - cleaning the object tree TB --- 2009-11-11 12:43:42 - cvsupping the source tree TB --- 2009-11-11 12:43:42 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-11-11 12:44:09 - building world TB --- 2009-11-11 12:44:09 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-11 12:44:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-11 12:44:09 - TARGET=ia64 TB --- 2009-11-11 12:44:09 - TARGET_ARCH=ia64 TB --- 2009-11-11 12:44:09 - TZ=UTC TB --- 2009-11-11 12:44:09 - __MAKE_CONF=/dev/null TB --- 2009-11-11 12:44:09 - cd /src TB --- 2009-11-11 12:44:09 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 11 12:44:09 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 11 13:59:55 UTC 2009 TB --- 2009-11-11 13:59:55 - generating LINT kernel config TB --- 2009-11-11 13:59:55 - cd /src/sys/ia64/conf TB --- 2009-11-11 13:59:55 - /usr/bin/make -B LINT TB --- 2009-11-11 13:59:55 - building LINT kernel TB --- 2009-11-11 13:59:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-11 13:59:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-11 13:59:55 - TARGET=ia64 TB --- 2009-11-11 13:59:55 - TARGET_ARCH=ia64 TB --- 2009-11-11 13:59:55 - TZ=UTC TB --- 2009-11-11 13:59:55 - __MAKE_CONF=/dev/null TB --- 2009-11-11 13:59:55 - cd /src TB --- 2009-11-11 13:59:55 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 11 13:59:55 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/cam_sim.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/cam/cam_xpt.c /src/sys/cam/cam_xpt.c:288: error: static declaration of 'xpt_start_tags' follows non-static declaration /src/sys/cam/cam_xpt_internal.h:179: error: previous declaration of 'xpt_start_tags' was here cc1: warnings being treated as errors /src/sys/cam/cam_xpt.c: In function 'xpt_action_default': /src/sys/cam/cam_xpt.c:2525: warning: implicit declaration of function 'xpt_schedule_dev_sendq' /src/sys/cam/cam_xpt.c:2525: warning: nested extern declaration of 'xpt_schedule_dev_sendq' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-11 14:02:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-11 14:02:30 - ERROR: failed to build lint kernel TB --- 2009-11-11 14:02:30 - 3726.84 user 627.39 system 4744.55 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From tinderbox at freebsd.org Wed Nov 11 15:04:26 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Nov 11 15:04:33 2009 Subject: [head tinderbox] failure on powerpc/powerpc Message-ID: <200911111406.nABE6a4A084112@freebsd-current.sentex.ca> TB --- 2009-11-11 13:04:02 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-11 13:04:02 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-11-11 13:04:02 - cleaning the object tree TB --- 2009-11-11 13:04:16 - cvsupping the source tree TB --- 2009-11-11 13:04:16 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-11-11 13:04:41 - building world TB --- 2009-11-11 13:04:41 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-11 13:04:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-11 13:04:41 - TARGET=powerpc TB --- 2009-11-11 13:04:41 - TARGET_ARCH=powerpc TB --- 2009-11-11 13:04:41 - TZ=UTC TB --- 2009-11-11 13:04:41 - __MAKE_CONF=/dev/null TB --- 2009-11-11 13:04:41 - cd /src TB --- 2009-11-11 13:04:41 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 11 13:04:42 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 11 14:04:31 UTC 2009 TB --- 2009-11-11 14:04:31 - generating LINT kernel config TB --- 2009-11-11 14:04:31 - cd /src/sys/powerpc/conf TB --- 2009-11-11 14:04:31 - /usr/bin/make -B LINT TB --- 2009-11-11 14:04:31 - building LINT kernel TB --- 2009-11-11 14:04:31 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-11 14:04:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-11 14:04:31 - TARGET=powerpc TB --- 2009-11-11 14:04:31 - TARGET_ARCH=powerpc TB --- 2009-11-11 14:04:31 - TZ=UTC TB --- 2009-11-11 14:04:31 - __MAKE_CONF=/dev/null TB --- 2009-11-11 14:04:31 - cd /src TB --- 2009-11-11 14:04:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 11 14:04:32 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/cam/cam_sim.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/cam/cam_xpt.c /src/sys/cam/cam_xpt.c:288: error: static declaration of 'xpt_start_tags' follows non-static declaration /src/sys/cam/cam_xpt_internal.h:179: error: previous declaration of 'xpt_start_tags' was here cc1: warnings being treated as errors /src/sys/cam/cam_xpt.c: In function 'xpt_action_default': /src/sys/cam/cam_xpt.c:2525: warning: implicit declaration of function 'xpt_schedule_dev_sendq' /src/sys/cam/cam_xpt.c:2525: warning: nested extern declaration of 'xpt_schedule_dev_sendq' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-11 14:06:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-11 14:06:36 - ERROR: failed to build lint kernel TB --- 2009-11-11 14:06:36 - 2810.84 user 591.14 system 3753.84 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From tinderbox at freebsd.org Wed Nov 11 15:25:21 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Wed Nov 11 15:25:33 2009 Subject: [head tinderbox] failure on sparc64/sparc64 Message-ID: <200911111427.nABERUCE071398@freebsd-current.sentex.ca> TB --- 2009-11-11 13:29:51 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-11 13:29:51 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-11-11 13:29:51 - cleaning the object tree TB --- 2009-11-11 13:30:08 - cvsupping the source tree TB --- 2009-11-11 13:30:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-11-11 13:30:31 - building world TB --- 2009-11-11 13:30:31 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-11 13:30:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-11 13:30:31 - TARGET=sparc64 TB --- 2009-11-11 13:30:31 - TARGET_ARCH=sparc64 TB --- 2009-11-11 13:30:31 - TZ=UTC TB --- 2009-11-11 13:30:31 - __MAKE_CONF=/dev/null TB --- 2009-11-11 13:30:31 - cd /src TB --- 2009-11-11 13:30:31 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 11 13:30:31 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 11 14:25:20 UTC 2009 TB --- 2009-11-11 14:25:20 - generating LINT kernel config TB --- 2009-11-11 14:25:20 - cd /src/sys/sparc64/conf TB --- 2009-11-11 14:25:20 - /usr/bin/make -B LINT TB --- 2009-11-11 14:25:20 - building LINT kernel TB --- 2009-11-11 14:25:20 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-11 14:25:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-11 14:25:20 - TARGET=sparc64 TB --- 2009-11-11 14:25:20 - TARGET_ARCH=sparc64 TB --- 2009-11-11 14:25:20 - TZ=UTC TB --- 2009-11-11 14:25:20 - __MAKE_CONF=/dev/null TB --- 2009-11-11 14:25:20 - cd /src TB --- 2009-11-11 14:25:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Nov 11 14:25:20 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/cam/cam_sim.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/cam/cam_xpt.c /src/sys/cam/cam_xpt.c:288: error: static declaration of 'xpt_start_tags' follows non-static declaration /src/sys/cam/cam_xpt_internal.h:179: error: previous declaration of 'xpt_start_tags' was here cc1: warnings being treated as errors /src/sys/cam/cam_xpt.c: In function 'xpt_action_default': /src/sys/cam/cam_xpt.c:2525: warning: implicit declaration of function 'xpt_schedule_dev_sendq' /src/sys/cam/cam_xpt.c:2525: warning: nested extern declaration of 'xpt_schedule_dev_sendq' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-11 14:27:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-11 14:27:30 - ERROR: failed to build lint kernel TB --- 2009-11-11 14:27:30 - 2631.51 user 562.16 system 3459.20 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From david at catwhisker.org Wed Nov 11 15:44:00 2009 From: david at catwhisker.org (David Wolfskill) Date: Wed Nov 11 15:44:08 2009 Subject: No DHCP lease with iwi(4)/wlan(4); works with an(4) at r197399 In-Reply-To: <20090925162403.GM1320@albert.catwhisker.org> References: <20090923140936.GF1320@albert.catwhisker.org> <3a142e750909231508j1a5092f8nfae264f367ba410@mail.gmail.com> <20090925162403.GM1320@albert.catwhisker.org> Message-ID: <20091111154359.GB1351@albert.catwhisker.org> On Fri, Sep 25, 2009 at 09:24:03AM -0700, David Wolfskill wrote: > ... > But I did find one rather curious thing: I was able to get the > iwi(4) to work OK (while running head) with one of my access points; > it's the other that seems to have an issue with iwi(4) under head. > > I have 2 different access points at home: > * An original Apple Airport > * A Linksys WAP-11. > (Each is, within the bounds of their rather different natures, > configured the same except for channel: One is on channel 1; the other > is on channel 6. Neither is a DHCP server: each merely passes the DHCP > traffic.) > > Under stable/6 and stable/7, each works fine with iwi(4). > > Under head (presently at r197479), the Linksys WAP-11 works (associates > & dhclient(8) negotiates a DHCP lease using iwi(4)/wlan(4)). > > Under head, the Apple Airport associates, but dhclient(8) cannot see a > DHCP offer via iwi(4)/wlan(4). >... This morning, after upgrading head to r199179, I now cannot get a DHCP lease using teh Linksys WAP-11. Prior to the upgrade, I was last running head r199134, which was able to get a DHCP lease from teh Linksys WAP-11. uname strings: FreeBSD g1-106.catwhisker.org 9.0-CURRENT FreeBSD 9.0-CURRENT #1172 r199134: Tue Nov 10 10:47:11 PST 2009 root@d254.dwolf.juniper.net.:/common/S4/obj/usr/src/sys/CANARY i386 FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #1173 r199179: Wed Nov 11 06:50:22 PST 2009 root@g1-106.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 [The latter has no current hostname, since dhclient-exit-hooks didn't get an IP address.] I verified that the iwi0/wlan0 NIC did associate first. I recall the UPDATING entry from a couple of days ago: 20091109: The layout of the structure ieee80211req_scan_result has changed. Applications that require wireless scan results (e.g. ifconfig(8)) from net80211 need to be recompiled. and admit that I did the upgrade with -DNOCLEAN. But it worked OK for the upgrade yesterday -- and I don't expect that I actually use scan results in any case. (Recall that association still works.) Peace, david -- David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091111/1a2a63be/attachment.pgp From onemda at gmail.com Wed Nov 11 17:31:54 2009 From: onemda at gmail.com (Paul B Mahol) Date: Wed Nov 11 17:32:01 2009 Subject: No DHCP lease with iwi(4)/wlan(4); works with an(4) at r197399 In-Reply-To: <20091111154359.GB1351@albert.catwhisker.org> References: <20090923140936.GF1320@albert.catwhisker.org> <3a142e750909231508j1a5092f8nfae264f367ba410@mail.gmail.com> <20090925162403.GM1320@albert.catwhisker.org> <20091111154359.GB1351@albert.catwhisker.org> Message-ID: <3a142e750911110931x153a46ebhe8de0c1f6f96df2b@mail.gmail.com> On 11/11/09, David Wolfskill wrote: > On Fri, Sep 25, 2009 at 09:24:03AM -0700, David Wolfskill wrote: >> ... >> But I did find one rather curious thing: I was able to get the >> iwi(4) to work OK (while running head) with one of my access points; >> it's the other that seems to have an issue with iwi(4) under head. >> >> I have 2 different access points at home: >> * An original Apple Airport >> * A Linksys WAP-11. >> (Each is, within the bounds of their rather different natures, >> configured the same except for channel: One is on channel 1; the other >> is on channel 6. Neither is a DHCP server: each merely passes the DHCP >> traffic.) >> >> Under stable/6 and stable/7, each works fine with iwi(4). >> >> Under head (presently at r197479), the Linksys WAP-11 works (associates >> & dhclient(8) negotiates a DHCP lease using iwi(4)/wlan(4)). >> >> Under head, the Apple Airport associates, but dhclient(8) cannot see a >> DHCP offer via iwi(4)/wlan(4). >>... > > This morning, after upgrading head to r199179, I now cannot get a DHCP > lease using teh Linksys WAP-11. > > Prior to the upgrade, I was last running head r199134, which was able to > get a DHCP lease from teh Linksys WAP-11. > > uname strings: > > FreeBSD g1-106.catwhisker.org 9.0-CURRENT FreeBSD 9.0-CURRENT #1172 r199134: > Tue Nov 10 10:47:11 PST 2009 > root@d254.dwolf.juniper.net.:/common/S4/obj/usr/src/sys/CANARY i386 > > FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #1173 r199179: Wed Nov 11 06:50:22 > PST 2009 root@g1-106.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY > i386 > > [The latter has no current hostname, since dhclient-exit-hooks > didn't get an IP address.] > > I verified that the iwi0/wlan0 NIC did associate first. I recall > the UPDATING entry from a couple of days ago: > > 20091109: > The layout of the structure ieee80211req_scan_result has changed. > Applications that require wireless scan results (e.g. ifconfig(8)) > from net80211 need to be recompiled. > > and admit that I did the upgrade with -DNOCLEAN. But it worked OK > for the upgrade yesterday -- and I don't expect that I actually use > scan results in any case. (Recall that association still works.) How scan results look now? Try sysctl debug options for your driver (debug.iwi). From gibbs at scsiguy.com Wed Nov 11 17:36:18 2009 From: gibbs at scsiguy.com (Justin T. Gibbs) Date: Wed Nov 11 17:36:25 2009 Subject: [PATCH] Adding sysctl for errors statistics to ahd(4) In-Reply-To: <3bbf2fe10911060643g60079e31y7679b32dac670fd8@mail.gmail.com> References: <3bbf2fe10911060643g60079e31y7679b32dac670fd8@mail.gmail.com> Message-ID: <4AFAEE89.3020009@scsiguy.com> On 11/6/2009 7:43 AM, Attilio Rao wrote: > This patch introduces some mechanisms for collecting informations on > errors frequency and debugging (and relative sysctls for printing them > out) for the ahd(4) driver: > http://www.freebsd.org/~attilio/Sandvine/STABLE_8/ahd/ahd-current2.diff > > The usage of array for sysctls is a bit too paranoid but it allows for > further extendibility of the code and doesn't loose of cleaness. > This code has been contributed back by Sandvine Incorporated with some cleanups. > Please review. > > Thanks, > Attilio In general, I think the patch is fine. It violates the existing style of the driver in some places (e.g. the aic7xxx drivers wrap function arguments to the opening '(' not to a 4 space indent), which should probably be addressed so the code remains consistent. My only real complaint is that there is not some generic reporting mechanism for these types of statistics. The ahd chips are legacy. Will Sandvine or vendor X add similar but slightly different sysctls to the next driver they need to integrate into their product? Higher level monitoring software can't be written to be agnostic of the storage controller and thus survive largely untouched as the HW under the software changes. I don't expect Sandvine to address this, but the project should. In the mean time, I'm okay with the patch going in since it is obviously useful to at least one company. -- Justin From rea-fbsd at codelabs.ru Wed Nov 11 17:40:18 2009 From: rea-fbsd at codelabs.ru (Eygene Ryabinkin) Date: Wed Nov 11 17:46:06 2009 Subject: [patch] allow boot-time attachment of daX devices to GEOM_ELI Message-ID: <20091111174011.3E7FF17182@shadow.codelabs.ru> >Submitter-Id: current-users >Originator: Eygene Ryabinkin >Organization: Code Labs >Confidential: no >Synopsis: [patch] allow boot-time attachment of daX devices to GEOM_ELI >Severity: serious >Priority: medium >Category: kern >Class: sw-bug >Release: FreeBSD 9.0-CURRENT amd64 >Environment: System: FreeBSD 9.0-CURRENT amd64 >Description: Currently, one can not make GEOM_ELI to attach encrypted providers at a boot time if these providers are backed by the da(4) devices (USB disks or sticks). This happens because umass(4) only pushes CAM layer to attach the created device, but the actual attachment is done asynchronously and on my machines it is done after the root mount. This makes me unable to boot my machines whose disks are removable USB ones and all partitions (with the boot one) are lying inside GEOM_ELI volume. >How-To-Repeat: Create GEOM_ELI volume on the removable USB stick, set boot flag on it (geli configure -b /dev/da) and boot the machine. You won't be asked for the password to attach the encrypted volume on boot (at least, this won't happen on the machines where daX will be attached after the root mount and at least on my notebook it is true). >Fix: The following patch fixes the things both for 9-CURRENT and 8-RC2. It uses a hacky way to pass the softc to the CAM callback, but I found no other ways to do so and daX should drop the root mount hold only after it will be completely attached or failed to do so. --- attach-umass-and-da-before-root-mount.diff begins here --- >From ced3079c3de1b07654ebd35ea80347d9f39b105e Mon Sep 17 00:00:00 2001 From: Eygene Ryabinkin Date: Wed, 11 Nov 2009 20:21:12 +0300 This allows attaching of external USB disks that carry volumes encrypted by GEOM_ELI, otherwise daX are probed and attached only after root mount and this makes impossible to use geli-backed device as the container for the root partition. Signed-off-by: Eygene Ryabinkin --- sys/cam/scsi/scsi_da.c | 7 ++++++ sys/dev/usb/storage/umass.c | 48 ++++++++++++++++++++++++++++++++++++++---- 2 files changed, 50 insertions(+), 5 deletions(-) diff --git a/sys/cam/scsi/scsi_da.c b/sys/cam/scsi/scsi_da.c index d05376e..0f766ed 100644 --- a/sys/cam/scsi/scsi_da.c +++ b/sys/cam/scsi/scsi_da.c @@ -130,6 +130,7 @@ struct da_softc { struct sysctl_ctx_list sysctl_ctx; struct sysctl_oid *sysctl_tree; struct callout sendordered_c; + struct root_hold_token *sc_rootmount; }; struct da_quirk_entry { @@ -1166,6 +1167,8 @@ daregister(struct cam_periph *periph, void *arg) return(CAM_REQ_CMP_ERR); } + softc->sc_rootmount = root_mount_hold("scsi_da"); + LIST_INIT(&softc->pending_ccbs); softc->state = DA_STATE_PROBE; bioq_init(&softc->bio_queue); @@ -1754,6 +1757,10 @@ dadone(struct cam_periph *periph, union ccb *done_ccb) * operation. */ xpt_release_ccb(done_ccb); + if (softc->sc_rootmount != NULL) { + root_mount_rel(softc->sc_rootmount); + softc->sc_rootmount = NULL; + } cam_periph_unhold(periph); return; } diff --git a/sys/dev/usb/storage/umass.c b/sys/dev/usb/storage/umass.c index 18756c9..a3a973e 100644 --- a/sys/dev/usb/storage/umass.c +++ b/sys/dev/usb/storage/umass.c @@ -1034,6 +1034,8 @@ struct umass_softc { uint8_t sc_maxlun; /* maximum LUN number, inclusive */ uint8_t sc_last_xfer_index; uint8_t sc_status_try; + + struct root_hold_token *sc_rootmount; }; struct umass_probe_proto { @@ -1043,6 +1045,15 @@ struct umass_probe_proto { int32_t error; }; +/* + * Wrapped 'union ccb *' to "pass" 'struct umass_softc *' + * into the CAM callback. + */ +struct wrapped_ccb_ptr { + union ccb ccb; + struct umass_softc *sc; +}; + /* prototypes */ static device_probe_t umass_probe; @@ -1502,6 +1513,13 @@ umass_attach(device_t dev) sc->sc_quirks = temp.quirks; sc->sc_unit = device_get_unit(dev); + /* + * We will release rootmount for this device only when + * it will be attached to the SCSI bus or will be + * failed to do so. This is done inside rescan_callback. + */ + sc->sc_rootmount = root_mount_hold(device_get_nameunit(dev)); + snprintf(sc->sc_name, sizeof(sc->sc_name), "%s", device_get_nameunit(dev)); @@ -1646,6 +1664,10 @@ umass_attach(device_t dev) return (0); /* success */ detach: + if (sc->sc_rootmount != NULL) { + root_mount_rel(sc->sc_rootmount); + sc->sc_rootmount = NULL; + } umass_detach(dev); return (ENXIO); /* failure */ } @@ -2745,12 +2767,18 @@ umass_cam_attach_sim(struct umass_softc *sc) return (0); } +/* + * "Wrapped" ccb will be passed to this callback: second argument + * will really point to 'struct wrapped_ccb_ptr *', so we can + * cast it. + */ static void umass_cam_rescan_callback(struct cam_periph *periph, union ccb *ccb) { -#if USB_DEBUG - struct umass_softc *sc = NULL; + struct wrapped_ccb_ptr *wccb = (struct wrapped_ccb_ptr *)ccb; + struct umass_softc *sc = wccb->sc; +#if USB_DEBUG if (ccb->ccb_h.status != CAM_REQ_CMP) { DPRINTF(sc, UDMASS_SCSI, "%s:%d Rescan failed, 0x%04x\n", periph->periph_name, periph->unit_number, @@ -2761,6 +2789,11 @@ umass_cam_rescan_callback(struct cam_periph *periph, union ccb *ccb) } #endif + if (sc->sc_rootmount != NULL) { + root_mount_rel(sc->sc_rootmount); + sc->sc_rootmount = NULL; + } + xpt_free_path(ccb->ccb_h.path); free(ccb, M_USBDEV); } @@ -2769,6 +2802,7 @@ static void umass_cam_rescan(struct umass_softc *sc) { struct cam_path *path; + struct wrapped_ccb_ptr *wccb; union ccb *ccb; DPRINTF(sc, UDMASS_SCSI, "scbus%d: scanning for %d:%d:%d\n", @@ -2776,11 +2810,15 @@ umass_cam_rescan(struct umass_softc *sc) cam_sim_path(sc->sc_sim), sc->sc_unit, CAM_LUN_WILDCARD); - ccb = malloc(sizeof(*ccb), M_USBDEV, M_WAITOK | M_ZERO); + wccb = malloc(sizeof(*wccb), M_USBDEV, M_WAITOK | M_ZERO); - if (ccb == NULL) { + if (wccb == NULL) { return; } + + ccb = &wccb->ccb; + wccb->sc = sc; + #if (__FreeBSD_version >= 700037) mtx_lock(&sc->sc_mtx); #endif @@ -2791,7 +2829,7 @@ umass_cam_rescan(struct umass_softc *sc) #if (__FreeBSD_version >= 700037) mtx_unlock(&sc->sc_mtx); #endif - free(ccb, M_USBDEV); + free(wccb, M_USBDEV); return; } xpt_setup_ccb(&ccb->ccb_h, path, 5 /* priority (low) */ ); -- 1.6.4.3 --- attach-umass-and-da-before-root-mount.diff ends here --- From jpiccari at bblocked.org Wed Nov 11 17:54:08 2009 From: jpiccari at bblocked.org (Joshua Piccari) Date: Wed Nov 11 18:05:58 2009 Subject: Wondering how stable x86emu? Message-ID: <15d3bc360911110926m4811574bmaea5e42879340d64@mail.gmail.com> Hi all, Hi all I'm wondering if anybody can comment on when we can expect to see x86emu come to a branch other than -CURRENT? Or if anyone has a patch for x86emu that would work (even slightly) with 8.0-RC2? I guess if nothing else it would be nice to know what files are involved so I can make a patch for RC2. Anyways, any info would be greatly appreciated since I've been waiting for something like this for a long time. Great work, and really looking forward to it. :D -- Joshua A Piccari /dv/ From delphij at delphij.net Wed Nov 11 18:13:47 2009 From: delphij at delphij.net (Xin LI) Date: Wed Nov 11 18:13:54 2009 Subject: Wondering how stable x86emu? In-Reply-To: <15d3bc360911110926m4811574bmaea5e42879340d64@mail.gmail.com> References: <15d3bc360911110926m4811574bmaea5e42879340d64@mail.gmail.com> Message-ID: <4AFAFECD.5020306@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joshua Piccari wrote: > Hi all, > > Hi all I'm wondering if anybody can comment on when we can expect to > see x86emu come to a branch other than -CURRENT? Or if anyone has a > patch for x86emu that would work (even slightly) with 8.0-RC2? I guess > if nothing else it would be nice to know what files are involved so I > can make a patch for RC2. > > Anyways, any info would be greatly appreciated since I've been waiting > for something like this for a long time. Great work, and really > looking forward to it. :D I'm not sure what are you referring to... It worked just fine for i.e. VESA stuff on amd64, but I think it's too late for 8.0 since it has been introduced too late. However, it would be a good target for 8.1 I guess, there are some rough edges but so far it works just fine for me. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkr6/s0ACgkQi+vbBBjt66C40ACfanaW0PUhohpx6csuwWIDZX0l F5YAn29BDqcCajJ/rrsupxiYmr7izK09 =qDWD -----END PGP SIGNATURE----- From scottl at samsco.org Wed Nov 11 18:38:23 2009 From: scottl at samsco.org (Scott Long) Date: Wed Nov 11 18:39:13 2009 Subject: [patch] allow boot-time attachment of daX devices to GEOM_ELI In-Reply-To: <20091111174011.3E7FF17182@shadow.codelabs.ru> References: <20091111174011.3E7FF17182@shadow.codelabs.ru> Message-ID: <017A1314-C5F2-4A71-857A-A381F029540B@samsco.org> I understand your concern about G_ELI. I'm not a fan of root_mount_hold, and I'd really like it to go away in favor of the SYSINIT and INTRHOOK mechanisms that already existed before root_mount_hold was introduced. It's really a hack, and a messy one that requires extensive modification to the system to work; i.e. root_mount_hold calls need to be added to just about every storage driver, not just 'ad' and 'da', while the existing SYSINIT based ordering does not. I'll look into this and see if I can come up with an alternate solution. Scott On Nov 11, 2009, at 10:40 AM, Eygene Ryabinkin wrote: > >> Submitter-Id: current-users >> Originator: Eygene Ryabinkin >> Organization: Code Labs >> Confidential: no >> Synopsis: [patch] allow boot-time attachment of daX devices to >> GEOM_ELI >> Severity: serious >> Priority: medium >> Category: kern >> Class: sw-bug >> Release: FreeBSD 9.0-CURRENT amd64 >> Environment: > > System: FreeBSD 9.0-CURRENT amd64 > >> Description: > > Currently, one can not make GEOM_ELI to attach encrypted providers > at a > boot time if these providers are backed by the da(4) devices (USB > disks > or sticks). This happens because umass(4) only pushes CAM layer to > attach the created device, but the actual attachment is done > asynchronously and on my machines it is done after the root mount. > > This makes me unable to boot my machines whose disks are removable USB > ones and all partitions (with the boot one) are lying inside GEOM_ELI > volume. > >> How-To-Repeat: > > Create GEOM_ELI volume on the removable USB stick, set boot flag on it > (geli configure -b /dev/da) and boot the machine. You > won't > be asked for the password to attach the encrypted volume on boot (at > least, this won't happen on the machines where daX will be attached > after the root mount and at least on my notebook it is true). > >> Fix: > > The following patch fixes the things both for 9-CURRENT and 8-RC2. It > uses a hacky way to pass the softc to the CAM callback, but I found no > other ways to do so and daX should drop the root mount hold only after > it will be completely attached or failed to do so. > > --- attach-umass-and-da-before-root-mount.diff begins here --- > From ced3079c3de1b07654ebd35ea80347d9f39b105e Mon Sep 17 00:00:00 2001 > From: Eygene Ryabinkin > Date: Wed, 11 Nov 2009 20:21:12 +0300 > > This allows attaching of external USB disks that carry volumes > encrypted > by GEOM_ELI, otherwise daX are probed and attached only after root > mount > and this makes impossible to use geli-backed device as the container > for > the root partition. > > Signed-off-by: Eygene Ryabinkin > --- > sys/cam/scsi/scsi_da.c | 7 ++++++ > sys/dev/usb/storage/umass.c | 48 ++++++++++++++++++++++++++++++++++ > ++++---- > 2 files changed, 50 insertions(+), 5 deletions(-) > > diff --git a/sys/cam/scsi/scsi_da.c b/sys/cam/scsi/scsi_da.c > index d05376e..0f766ed 100644 > --- a/sys/cam/scsi/scsi_da.c > +++ b/sys/cam/scsi/scsi_da.c > @@ -130,6 +130,7 @@ struct da_softc { > struct sysctl_ctx_list sysctl_ctx; > struct sysctl_oid *sysctl_tree; > struct callout sendordered_c; > + struct root_hold_token *sc_rootmount; > }; > > struct da_quirk_entry { > @@ -1166,6 +1167,8 @@ daregister(struct cam_periph *periph, void *arg) > return(CAM_REQ_CMP_ERR); > } > > + softc->sc_rootmount = root_mount_hold("scsi_da"); > + > LIST_INIT(&softc->pending_ccbs); > softc->state = DA_STATE_PROBE; > bioq_init(&softc->bio_queue); > @@ -1754,6 +1757,10 @@ dadone(struct cam_periph *periph, union ccb > *done_ccb) > * operation. > */ > xpt_release_ccb(done_ccb); > + if (softc->sc_rootmount != NULL) { > + root_mount_rel(softc->sc_rootmount); > + softc->sc_rootmount = NULL; > + } > cam_periph_unhold(periph); > return; > } > diff --git a/sys/dev/usb/storage/umass.c b/sys/dev/usb/storage/umass.c > index 18756c9..a3a973e 100644 > --- a/sys/dev/usb/storage/umass.c > +++ b/sys/dev/usb/storage/umass.c > @@ -1034,6 +1034,8 @@ struct umass_softc { > uint8_t sc_maxlun; /* maximum LUN number, inclusive */ > uint8_t sc_last_xfer_index; > uint8_t sc_status_try; > + > + struct root_hold_token *sc_rootmount; > }; > > struct umass_probe_proto { > @@ -1043,6 +1045,15 @@ struct umass_probe_proto { > int32_t error; > }; > > +/* > + * Wrapped 'union ccb *' to "pass" 'struct umass_softc *' > + * into the CAM callback. > + */ > +struct wrapped_ccb_ptr { > + union ccb ccb; > + struct umass_softc *sc; > +}; > + > /* prototypes */ > > static device_probe_t umass_probe; > @@ -1502,6 +1513,13 @@ umass_attach(device_t dev) > sc->sc_quirks = temp.quirks; > sc->sc_unit = device_get_unit(dev); > > + /* > + * We will release rootmount for this device only when > + * it will be attached to the SCSI bus or will be > + * failed to do so. This is done inside rescan_callback. > + */ > + sc->sc_rootmount = root_mount_hold(device_get_nameunit(dev)); > + > snprintf(sc->sc_name, sizeof(sc->sc_name), > "%s", device_get_nameunit(dev)); > > @@ -1646,6 +1664,10 @@ umass_attach(device_t dev) > return (0); /* success */ > > detach: > + if (sc->sc_rootmount != NULL) { > + root_mount_rel(sc->sc_rootmount); > + sc->sc_rootmount = NULL; > + } > umass_detach(dev); > return (ENXIO); /* failure */ > } > @@ -2745,12 +2767,18 @@ umass_cam_attach_sim(struct umass_softc *sc) > return (0); > } > > +/* > + * "Wrapped" ccb will be passed to this callback: second argument > + * will really point to 'struct wrapped_ccb_ptr *', so we can > + * cast it. > + */ > static void > umass_cam_rescan_callback(struct cam_periph *periph, union ccb *ccb) > { > -#if USB_DEBUG > - struct umass_softc *sc = NULL; > + struct wrapped_ccb_ptr *wccb = (struct wrapped_ccb_ptr *)ccb; > + struct umass_softc *sc = wccb->sc; > > +#if USB_DEBUG > if (ccb->ccb_h.status != CAM_REQ_CMP) { > DPRINTF(sc, UDMASS_SCSI, "%s:%d Rescan failed, 0x%04x\n", > periph->periph_name, periph->unit_number, > @@ -2761,6 +2789,11 @@ umass_cam_rescan_callback(struct cam_periph > *periph, union ccb *ccb) > } > #endif > > + if (sc->sc_rootmount != NULL) { > + root_mount_rel(sc->sc_rootmount); > + sc->sc_rootmount = NULL; > + } > + > xpt_free_path(ccb->ccb_h.path); > free(ccb, M_USBDEV); > } > @@ -2769,6 +2802,7 @@ static void > umass_cam_rescan(struct umass_softc *sc) > { > struct cam_path *path; > + struct wrapped_ccb_ptr *wccb; > union ccb *ccb; > > DPRINTF(sc, UDMASS_SCSI, "scbus%d: scanning for %d:%d:%d\n", > @@ -2776,11 +2810,15 @@ umass_cam_rescan(struct umass_softc *sc) > cam_sim_path(sc->sc_sim), > sc->sc_unit, CAM_LUN_WILDCARD); > > - ccb = malloc(sizeof(*ccb), M_USBDEV, M_WAITOK | M_ZERO); > + wccb = malloc(sizeof(*wccb), M_USBDEV, M_WAITOK | M_ZERO); > > - if (ccb == NULL) { > + if (wccb == NULL) { > return; > } > + > + ccb = &wccb->ccb; > + wccb->sc = sc; > + > #if (__FreeBSD_version >= 700037) > mtx_lock(&sc->sc_mtx); > #endif > @@ -2791,7 +2829,7 @@ umass_cam_rescan(struct umass_softc *sc) > #if (__FreeBSD_version >= 700037) > mtx_unlock(&sc->sc_mtx); > #endif > - free(ccb, M_USBDEV); > + free(wccb, M_USBDEV); > return; > } > xpt_setup_ccb(&ccb->ccb_h, path, 5 /* priority (low) */ ); > -- > 1.6.4.3 > --- attach-umass-and-da-before-root-mount.diff ends here --- From sfourman at gmail.com Wed Nov 11 18:50:43 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Wed Nov 11 18:50:51 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue Message-ID: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> Hello list, I am running FreeBSD 8.0RC2 and I dont understand why my ZFS/NFS is acting weird on writes. I get ~150mbit writes idk if this is good or not? but it paused for a few seconds every once and awhile. I have cut and pasted a bunch of stuff below. does anyone have any insight? this is a recent machine with a AMD processor and 4GB of memory. the switch in the middle is a Dell 5224 gigabit switch if that maters. and the Clients performing the writes are also FreeBSD 8RC2 I will say one thing... While I am performing writes.. if I was to do a Read from a different client I only can get like ~3mbit reads. if I do nothing but a read on a single client I can get ~300mbit reads any help would be appreciated Sam Fourman Jr. Fourman Networks. # zpool status pool: Network state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM Network ONLINE 0 0 0 raidz1 ONLINE 0 0 0 da0 ONLINE 0 0 0 da1 ONLINE 0 0 0 da2 ONLINE 0 0 0 da3 ONLINE 0 0 0 da4 ONLINE 0 0 0 da5 ONLINE 0 0 0 errors: No known data errors # ifconfig re0: flags=8843 metric 0 mtu 1500 options=389b ether 90:e6:ba:10:0e:2d inet 192.168.12.10 netmask 0xffffff00 broadcast 192.168.12.255 inet 192.168.12.11 netmask 0xffffff00 broadcast 192.168.12.255 inet 192.168.12.12 netmask 0xffffff00 broadcast 192.168.12.255 inet 192.168.12.13 netmask 0xffffff00 broadcast 192.168.12.255 media: Ethernet autoselect (1000baseT ) status: active plip0: flags=8810 metric 0 mtu 1500 lo0: flags=8049 metric 0 mtu 16384 options=3 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 # ifstat -b -i re0 re0 Kbps in Kbps out 3.37 5.18 3.37 5.05 3.37 5.05 42.21 48.22 5.89 5.05 3.37 5.05 3.37 5.05 41.68 48.20 110.44 101.74 3.37 5.05 3.37 5.05 5.03 6.37 10.83 12.84 62.05 62.50 3.37 5.05 3.37 5.05 5.21 6.47 3.37 5.05 56521.85 2052.38 133949.5 4723.58 141345.1 4968.34 154383.0 5433.63 154244.1 5423.14 121558.2 4306.39 155455.9 5475.89 142424.3 5015.22 159326.7 5609.79 152141.6 5281.99 146702.9 7199.11 151088.5 5312.14 151621.7 5346.30 112848.5 3939.65 4.80 5.05 46.20 49.68 5.21 6.47 3.37 5.05 3.37 5.05 5.21 6.47 44.72 48.20 132888.9 4652.04 153707.7 5402.98 152234.6 5343.49 136510.0 4814.00 124268.0 4437.97 158612.9 5590.24 156464.4 5514.69 142010.5 5010.10 148333.6 5211.41 re0 Kbps in Kbps out 155707.6 5525.03 156187.8 5504.36 121838.5 4282.46 16874.25 621.48 5.21 6.47 46.17 49.61 3.37 5.05 5.21 6.47 3.37 5.05 30120.71 1058.03 156991.7 5639.63 147261.1 5311.55 131024.8 4725.30 151883.2 5353.18 155146.7 5456.85 161816.2 5727.37 144066.7 5138.94 155767.4 5507.38 142959.7 5043.90 152714.3 5428.75 110144.8 3987.22 3.37 5.05 3.37 5.05 5.03 6.37 3.37 5.05 64.62 68.86 11302.01 367.31 154841.7 5489.48 160238.3 5635.34 151150.4 5323.96 160726.1 5696.35 152421.8 5381.29 161405.3 5751.44 152095.4 5349.11 116161.9 4104.15 158146.7 5573.70 147790.0 5247.66 12551.27 462.41 3.37 5.05 3.37 5.05 3.37 5.05 2160.03 2117.73 11297.74 376.93 158567.7 5610.60 147388.6 5186.73 151555.5 5349.12 157579.2 5587.67 149001.2 5268.48 re0 Kbps in Kbps out 154172.6 5507.73 162795.7 5753.79 151039.5 5315.01 153744.4 5478.71 88269.23 3137.44 3.37 5.05 3.37 5.05 25.07 24.70 44.72 48.20 3.37 5.05 107780.3 3813.35 151123.3 5326.76 153103.2 5440.45 149461.4 5318.25 154987.6 5465.26 147789.8 5223.30 140811.6 4981.23 158819.1 5658.08 156550.1 5542.69 117199.0 4096.97 3.37 5.05 3.37 5.05 3.37 5.05 44.70 48.17 3.37 5.05 116172.3 4084.82 159684.2 5595.67 155388.3 5470.82 153778.8 5471.12 160333.3 5650.18 151555.5 5346.59 153912.8 5427.27 146753.1 5234.99 151624.0 5337.10 41923.68 1478.39 3.37 5.05 3.37 5.05 66.24 67.47 3.37 5.05 61305.44 2143.38 157087.6 5549.02 155647.7 5553.67 157510.1 5605.24 146786.6 5180.34 135555.9 4780.34 158633.3 5578.98 157735.7 5538.46 151445.5 5390.60 re0 Kbps in Kbps out 88655.49 3138.99 5.21 7.61 3.37 5.05 3.37 5.05 314.11 309.87 35855.92 3019.12 126837.6 4492.57 136117.2 4806.87 147924.3 5229.35 150553.5 5315.17 158044.2 5609.08 159151.6 5627.26 147855.5 5178.02 156533.7 5495.67 125278.2 4390.51 44.72 48.20 3.37 5.05 3.37 5.05 3.37 5.05 12400.47 420.22 141994.2 5045.35 157535.1 5537.08 154312.9 5412.69 159218.2 5633.57 152698.8 5365.41 155403.4 5563.36 150104.5 5317.83 156397.1 5517.41 86013.25 3048.44 3.37 5.05 44.72 48.20 3.37 5.05 3.37 5.05 47334.93 1647.06 149320.0 5347.42 149435.6 5308.92 156021.1 5474.01 152563.6 5375.73 155523.0 5473.40 152630.9 5385.65 152203.3 5394.63 142484.9 5030.69 56701.45 2052.13 3.37 5.05 3.37 5.05 46.17 49.62 5.03 6.37 94137.63 3297.45 re0 Kbps in Kbps out 164023.3 5785.23 147958.4 5279.17 152165.2 5356.31 147259.5 5208.91 155024.8 5456.01 158034.7 5552.35 147619.9 5249.18 135962.4 4821.04 3.37 5.05 3.37 5.05 3.37 5.05 44.54 48.00 24643.59 808.53 155887.8 5499.69 152622.6 5374.52 90909.52 3216.71 150315.9 6516.74 149293.3 6100.74 157711.7 5644.70 142586.9 5036.40 146279.9 5149.50 126335.6 4510.90 3.37 5.05 3.37 5.05 3.37 5.05 3.37 5.05 31785.91 1137.64 152113.2 5361.44 149366.4 5262.94 141578.1 4984.64 147796.4 5205.79 154105.2 5549.08 161407.3 5713.83 149983.9 5294.44 145774.1 5148.62 58054.58 2079.92 3.37 5.05 45.64 48.75 3.37 5.05 10.38 41.29 115633.4 4057.17 145172.9 5109.34 160267.6 5680.67 154851.5 5455.03 157873.1 5621.18 150019.6 5295.47 160156.1 5655.63 146290.4 5200.17 re0 Kbps in Kbps out 97345.63 3477.19 3.37 6.19 3.37 5.05 3.37 5.05 46.56 49.61 73127.16 2544.00 150076.1 5293.10 152638.9 5381.02 153774.1 5412.67 155966.5 5522.56 161909.6 5662.65 158143.3 5553.83 150476.0 5284.16 115083.2 4048.69 11872.56 459.17 3.37 5.05 3.37 5.05 5.10 6.69 48749.13 1788.02 160387.1 5730.22 151622.1 5301.40 158541.1 5553.69 163521.1 5719.97 155853.6 5478.11 159261.4 5626.13 ^C # /boot/loader.conf kern.ipc.semaem=32767 kern.ipc.semvmx=65534 kern.ipc.semusz=184 kern.ipc.semume=80 kern.ipc.semopm=200 kern.ipc.semmsl=120 kern.ipc.semmnu=4096 kern.ipc.semmns=8192 kern.ipc.semmni=32767 kern.ipc.semmap=60 /etc/sysctl.conf # Jail Settings security.jail.jailed: 0 security.jail.mount_allowed: 0 security.jail.chflags_allowed: 0 security.jail.allow_raw_sockets: 1 security.jail.enforce_statfs: 2 security.jail.sysvipc_allowed: 1 security.jail.socket_unixiproute_only: 1 security.jail.set_hostname_allowed: 1 # More Shared memory for jails/PostgreSQL kern.ipc.shmall=65536 kern.ipc.shmmax=134217728 kern.ipc.semmap=4096 # dmesg Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RC2 #2: Tue Nov 10 21:05:03 CST 2009 sfourman@.PuffyBSD.Com:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Phenom(tm) II X2 550 Processor (3100.02-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f42 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3847766016 (3669 MB) ACPI APIC Table: <092809 APIC1459> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0 0/1 20090521 tbfadt-655 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <092809 XSDT1459> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of ffb80000, 80000 (3) failed acpi0: reservation of fec10000, 20 (3) failed acpi0: reservation of fed40000, 5000 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cff00000 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: HPET never increments, disabling device_attach: acpi_hpet0 attach returned 6 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xd000-0xd0ff mem 0xd0000000-0xdfffffff,0xfe9f0000-0xfe9fffff,0xfe800000-0xfe8fffff irq 18 at device 5.0 on pci1 pci1: at device 5.1 (no driver attached) pcib2: irq 18 at device 10.0 on pci0 pci2: on pcib2 re0: port 0xe800-0xe8ff mem 0xfdbff000-0xfdbfffff,0xfdbf8000-0xfdbfbfff irq 18 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x28000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 90:e6:ba:10:0e:2d re0: [FILTER] atapci0: port 0xc000-0xc007,0xb000-0xb003,0xa000-0xa007,0x9000-0x9003,0x8000-0x800f mem 0xfe7ffc00-0xfe7fffff irq 22 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.10 controller with 4 3Gbps ports, PM supported ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ohci0: mem 0xfe7fe000-0xfe7fefff irq 16 at device 18.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfe7fd000-0xfe7fdfff irq 16 at device 18.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0xfe7ff800-0xfe7ff8ff irq 17 at device 18.2 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: on ehci0 ohci2: mem 0xfe7fc000-0xfe7fcfff irq 18 at device 19.0 on pci0 ohci2: [ITHREAD] usbus3: on ohci2 ohci3: mem 0xfe7fb000-0xfe7fbfff irq 18 at device 19.1 on pci0 ohci3: [ITHREAD] usbus4: on ohci3 ehci1: mem 0xfe7ff400-0xfe7ff4ff irq 19 at device 19.2 on pci0 ehci1: [ITHREAD] usbus5: EHCI version 1.0 usbus5: on ehci1 pci0: at device 20.0 (no driver attached) atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata0: on atapci1 ata0: [ITHREAD] ata1: on atapci1 ata1: [ITHREAD] pci0: at device 20.2 (no driver attached) isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci3: on pcib3 pcib4: at device 5.0 on pci3 pci4: on pcib4 arcmsr0: mem 0xfebff000-0xfebfffff,0xfdc00000-0xfdffffff irq 22 at device 14.0 on pci4 ARECA RAID ADAPTER0: Driver Version 1.20.00.16 2009-10-10 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.47 2009-06-25 arcmsr0: [ITHREAD] ohci4: mem 0xfe7fa000-0xfe7fafff irq 18 at device 20.5 on pci0 ohci4: [ITHREAD] usbus6: on ohci4 acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] cpu0: on acpi0 acpi_throttle0: on cpu0 hwpstate0: on cpu0 cpu1: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 orm0: at iomem 0xcf000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 usbus6: 12Mbps Full Speed USB v1.0 ad4: 38146MB at ata2-master SATA150 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 Waiting 5 seconds for SCSI devices to settle uhub6: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub3: 3 ports with 3 removable, self powered uhub4: 3 ports with 3 removable, self powered uhub2: 6 ports with 6 removable, self powered uhub5: 6 ports with 6 removable, self powered (probe16:arcmsr0:0:16:0): inquiry data fails comparison at DV1 step da0 at arcmsr0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-5 device da0: 166.666MB/s transfers (83.333MHz, offset 32, 16bit) da0: Command Queueing enabled da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da1 at arcmsr0 bus 0 target 0 lun 1 da1: Fixed Direct Access SCSI-5 device da1: 166.666MB/s transfers (83.333MHz, offset 32, 16bit) da1: Command Queueing enabled da1: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da2 at arcmsr0 bus 0 target 0 lun 2 da2: Fixed Direct Access SCSI-5 device da2: 166.666MB/s transfers (83.333MHz, offset 32, 16bit) da2: Command Queueing enabled da2: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da3 at arcmsr0 bus 0 target 0 lun 3 da3: Fixed Direct Access SCSI-5 device da3: 166.666MB/s transfers (83.333MHz, offset 32, 16bit) da3: Command Queueing enabled da3: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da4 at arcmsr0 bus 0 target 0 lun 4 da4: Fixed Direct Access SCSI-5 device da4: 166.666MB/s transfers (83.333MHz, offset 32, 16bit) da4: Command Queueing enabled da4: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) da5 at arcmsr0 bus 0 target 0 lun 5 da5: Fixed Direct Access SCSI-5 device da5: 166.666MB/s transfers (83.333MHz, offset 32, 16bit) da5: Command Queueing enabled da5: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad4s1a ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version 13 ZFS storage pool version 13 re0: link state changed to UP # From ivoras at freebsd.org Wed Nov 11 19:09:04 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Nov 11 19:09:11 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> Message-ID: Sam Fourman Jr. wrote: > Hello list, > > I am running FreeBSD 8.0RC2 and I dont understand why my ZFS/NFS is > acting weird on writes. > I get ~150mbit writes idk if this is good or not? but it paused for a > few seconds every once and awhile. You didn't give any "iostat" statistics - I suspect that if you correlate ifstat and iostat output that you will see that network "pauses" happen during spikes in IO. You should check for this and post your results. From serguey-grigoriev at yandex.ru Wed Nov 11 19:27:53 2009 From: serguey-grigoriev at yandex.ru (S.N.Grigoriev) Date: Wed Nov 11 19:28:01 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> Message-ID: <941257966918@webmail42.yandex.ru> 10.11.09, 09:15, "Mark Atkinson" wrote: > Andriy Gapon wrote: > > on 10/11/2009 17:22 gary.jennejohn@freenet.de said the following: > >> Well, OK, I may have misinterpreted what you wrote or have chosen bad > >> wording myself to convey the same message. Nonetheless it looks like > >> a hardware problem to me. > > > > [Trying to make up for my previous mistake.] > > > > The symptom certainly looks like misbehaving hardware, but other information from > > the reports seems to suggest that it is possible that this misbehavior might be > > caused by software misconfiguring the hardware. > > > > I would re-test vm.pmap.pg_ps_enabled=0 just to be sure that it was correctly teh > > first time. > > I would try to see how 8.0-RC1 kernel behaves and in general try to find last > > working, first non-working version. > > It would be useful to know any (if any) non-default loader.conf and rc.conf > > settings or kernel config (if not GENERIC). > > > > Not a trivial issue unless it is hardware indeed. > > > Also, you can try adding: > hw.mca.enabled="1" in /boot/loader.conf, reboot, and then see if there > is a machine check exception on the console during the buildworld. Mark, I've added hw.mca.enabled="1" in /boot/loader.conf and got the following screen during the buildworld: ..... -c /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/sb.c MCA: CPU3 UNCOR PCC OVER DTLIB L1 error MCA: Address 0x8015fb000 Fatal trap 28: machine check trap while in user mode Fatal trap 28: machine check trap while in user mode cpuid = 3, apic id = 03 ..... etc. I've typed 'panic' at the 'db>' prompt but got no crash dump. Tell me please what can I do for further problem investigation. -- Regards, S.Grigoriev. From mel.flynn+fbsd.current at mailing.thruhere.net Wed Nov 11 19:48:52 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Wed Nov 11 19:48:58 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <20091111101207.GF64905@hoeg.nl> References: <20091111101207.GF64905@hoeg.nl> Message-ID: <200911112031.43685.mel.flynn+fbsd.current@mailing.thruhere.net> Hi Ed, On Wednesday 11 November 2009 11:12:07 Ed Schouten wrote: > - Better compatibility with other operating systems. I'm not in a position to test this at the moment, but does this mean our console will now also "fold" paging/editor applications? I hate this feature with a passion on linux and I've unable to find out how to disable it, especially since the few linux machines I manage have no termcap or terminfo database on the places they say they should be. What I mean with folding is: root@www:~# man less Reformatting less(1), please wait... root@www:~# As you can see, no more less(1) manpage (it's not limited to less, vim etc as well). When I change to vt100 terminal, this doesn't occur, hence my worry about the above sentence in combination with $subject. IF this is going to be the default, I would appreciate an rc.conf setting or at least an explanation of what triggers this behavior and how to turn it off in the manpage, as various quests in google have yielded neither information nor solution. -- Mel From mel.flynn+fbsd.current at mailing.thruhere.net Wed Nov 11 20:01:41 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Wed Nov 11 20:01:52 2009 Subject: Revisiting mergemaster truncating mergemaster.mtree Message-ID: <200911112101.37805.mel.flynn+fbsd.current@mailing.thruhere.net> Hi Doug, just recreated the old "mergemaster -p truncates mtree". The machine in question is 7.2-p4, to be upgraded to stable/8. Luckily for me, I copied the mtree file to .bak before doing this (justified paranoia :). history snippet: 280 sudo cp /var/db/mergemaster.mtree /var/db/mergemaster.mtree.bak 282 sudo -E make installkernel 283 sudo -E mergemaster -p 284 sudo -E make installworld 285 sudo -E mergemaster -iUF ^^ ^C there, "no mtree database found" Result: -rw------- 1 root wheel 0 Nov 11 10:35 mergemaster.mtree -rw------- 1 root wheel 165681 Nov 11 10:32 mergemaster.mtree.bak Environment: % sudo -E env|grep -Ev '^(SSH|TERM|STY|WINDOW|SUDO)' OLDPWD=/usr/src SHELL=/usr/local/bin/zsh _=/usr/local/bin/sudo MAKEOBJDIRPREFIX=/data/obj PWD=/usr/src SAVEHIST=5000 HISTSIZE=500 HISTFILE=/home/mel/.zsh_history HELPDIR=/usr/local/lib/zsh/help EDITOR=vim PAGER=less -i -s -g LESS=-cigex3M MAIL=/var/spool/mail/mel SHLVL=2 USER=root LOGNAME=root HOME=/home/mel PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/home/mel/bin CCACHE_DIR=/data/ccache/mel HTTP_PROXY=http://squid/ FTP_PASSIVE_MODE=YES BLOCKSIZE=K USERNAME=root No /etc/mergemaster* or ~/.mergemasterrc. The machine was installed from 7.2 CD and freebsd-update'd to -p4. Let me know if there's anything else I can provide to help track this down, but I have to proceed with upgrade for this specific machine. FWIW, I've been unable to reproduce this lately on stable/7 or stable/8 machines, but since it was never identified I figured you may be interested to know what codepath does this, so it doesn't reoccur. -- Mel From jhb at freebsd.org Wed Nov 11 20:05:20 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Nov 11 20:05:27 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <941257966918@webmail42.yandex.ru> References: <1031257439203@webmail57.yandex.ru> <941257966918@webmail42.yandex.ru> Message-ID: <200911111504.14906.jhb@freebsd.org> On Wednesday 11 November 2009 2:15:18 pm S.N.Grigoriev wrote: > > 10.11.09, 09:15, "Mark Atkinson" > wrote: > > > Andriy Gapon wrote: > > > on 10/11/2009 17:22 gary.jennejohn@freenet.de said the following: > > >> Well, OK, I may have misinterpreted what you wrote or have chosen bad > > >> wording myself to convey the same message. Nonetheless it looks like > > >> a hardware problem to me. > > > > > > [Trying to make up for my previous mistake.] > > > > > > The symptom certainly looks like misbehaving hardware, but other information from > > > the reports seems to suggest that it is possible that this misbehavior might be > > > caused by software misconfiguring the hardware. > > > > > > I would re-test vm.pmap.pg_ps_enabled=0 just to be sure that it was correctly teh > > > first time. > > > I would try to see how 8.0-RC1 kernel behaves and in general try to find last > > > working, first non-working version. > > > It would be useful to know any (if any) non-default loader.conf and rc.conf > > > settings or kernel config (if not GENERIC). > > > > > > Not a trivial issue unless it is hardware indeed. > > > > > Also, you can try adding: > > hw.mca.enabled="1" in /boot/loader.conf, reboot, and then see if there > > is a machine check exception on the console during the buildworld. > > Mark, > > I've added hw.mca.enabled="1" in /boot/loader.conf and got the following > screen during the buildworld: > > ..... > -c /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/sb.c > > MCA: CPU3 UNCOR PCC OVER DTLIB L1 error > MCA: Address 0x8015fb000 You hardware is broken and it is telling you so. You have had multiple machine checks with the most severe one being an uncorrectable error in your data TLB (i.e. in the CPU itself). -- John Baldwin From des at des.no Wed Nov 11 20:14:50 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Nov 11 20:14:57 2009 Subject: HEADS UP: Important bug fix in ZFS replay code! In-Reply-To: <20091110224524.GC3194@garage.freebsd.pl> (Pawel Jakub Dawidek's message of "Tue, 10 Nov 2009 23:45:24 +0100") References: <200911102227.nAAMRXTf073603@svn.freebsd.org> <20091110224524.GC3194@garage.freebsd.pl> Message-ID: <86k4xwom2v.fsf@ds4.des.no> Pawel Jakub Dawidek writes: > You can locate such files with the following command: > > # find / -perm -7777 -print0 | xargs -0 ls -ld or 'grep rws /var/run/setuid.today' :) DES -- Dag-Erling Sm?rgrav - des@des.no From atkin901 at gmail.com Wed Nov 11 20:20:10 2009 From: atkin901 at gmail.com (Mark Atkinson) Date: Wed Nov 11 20:20:17 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <941257966918@webmail42.yandex.ru> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> <941257966918@webmail42.yandex.ru> Message-ID: S.N.Grigoriev wrote: > > 10.11.09, 09:15, "Mark Atkinson" > wrote: > >> Andriy Gapon wrote: >>> on 10/11/2009 17:22 gary.jennejohn@freenet.de said the following: >>>> Well, OK, I may have misinterpreted what you wrote or have chosen bad >>>> wording myself to convey the same message. Nonetheless it looks like >>>> a hardware problem to me. >>> [Trying to make up for my previous mistake.] >>> >>> The symptom certainly looks like misbehaving hardware, but other information from >>> the reports seems to suggest that it is possible that this misbehavior might be >>> caused by software misconfiguring the hardware. >>> >>> I would re-test vm.pmap.pg_ps_enabled=0 just to be sure that it was correctly teh >>> first time. >>> I would try to see how 8.0-RC1 kernel behaves and in general try to find last >>> working, first non-working version. >>> It would be useful to know any (if any) non-default loader.conf and rc.conf >>> settings or kernel config (if not GENERIC). >>> >>> Not a trivial issue unless it is hardware indeed. >>> >> Also, you can try adding: >> hw.mca.enabled="1" in /boot/loader.conf, reboot, and then see if there >> is a machine check exception on the console during the buildworld. > > Mark, > > I've added hw.mca.enabled="1" in /boot/loader.conf and got the following > screen during the buildworld: > > ...... > -c /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/sb.c > > MCA: CPU3 UNCOR PCC OVER DTLIB L1 error > MCA: Address 0x8015fb000 > > > Fatal trap 28: machine check trap while in user mode > > Fatal trap 28: machine check trap while in user mode > cpuid = 3, apic id = 03 > ...... etc. > > > I've typed 'panic' at the 'db>' prompt but got no crash dump. > Tell me please what can I do for further problem investigation. > Well, you're about at the point I am now with my HP dl385g5, only turning off superpages would result in a successful buildworld. Mine would often machine check during gas compilation as well. You can try issuing 'where' or 'bt' to see the backtrace, but It probably wouldn't reveal anything useful. If 'panic' doesn't create a dump, you can try 'call doadump', then 'reset' to reset the machine. All the best, Mark From lists at c0mplx.org Wed Nov 11 20:22:11 2009 From: lists at c0mplx.org (Kurt Jaeger) Date: Wed Nov 11 20:22:18 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <200911112031.43685.mel.flynn+fbsd.current@mailing.thruhere.net> References: <20091111101207.GF64905@hoeg.nl> <200911112031.43685.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <20091111202211.GB2103@home.opsec.eu> Hi! > I'm not in a position to test this at the moment, but does this mean our > console will now also "fold" paging/editor applications? > I hate this feature with a passion on linux and I've unable to find out > how to > disable it, especially since the few linux machines I manage have no termcap > or terminfo database on the places they say they should be. > What I mean with folding is: > root@www:~# man less > Reformatting less(1), please wait... > root@www:~# For less, have a look at the "-X" flag: Disables sending the termcap initialization and deinitialization strings to the terminal. In termcap/terminfo, you probably have to look for the 'ti' and 'te' capabilities. Basically, find the xterm termcap/terminfo source file, edit it to change/delete ti/te and re-compile the source using tic. Yes, someone should write a howto about this 8-} -- pi@opsec.eu +49 171 3101372 11 years to go ! From pyunyh at gmail.com Wed Nov 11 20:31:35 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Nov 11 20:31:42 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <200911102018.nAAKI3s7021614@lava.sentex.ca> References: <20091017222314.GB19204@michelle.cdnetworks.com> <200911092033.nA9KX6dD013378@lava.sentex.ca> <200911092215.nA9MFeDP013898@lava.sentex.ca> <2a41acea0911091459w2b4fec5djd64d0324557b7da2@mail.gmail.com> <200911100021.nAA0LvMG014534@lava.sentex.ca> <2a41acea0911091633u2899b47ewb514b6276ba2cf62@mail.gmail.com> <200911100227.nAA2RtDY015177@lava.sentex.ca> <2a41acea0911101057q4f913e30m9319e52bbd254cfe@mail.gmail.com> <2a41acea0911101120o39fd695cpa325736d00b11587@mail.gmail.com> <200911102018.nAAKI3s7021614@lava.sentex.ca> Message-ID: <20091111203101.GC15449@michelle.cdnetworks.com> On Tue, Nov 10, 2009 at 03:18:09PM -0500, Mike Tancsa wrote: > At 02:20 PM 11/10/2009, Jack Vogel wrote: > >This is a fix for this problem, please apply and test this. > > Hi, > Thanks! Yes, I am able to use both ports of the NIC now and > no panics yet. Prior to this patch, bringing up both ports resulted > in a non functioning NIC and panic! Generating some UDP and tcp > traffic through the box, all seems to be OK on first blush. > I think this is a separate issue. Jack's patch surely reduce the number of chance of bus_dmamap_load_mbuf_sg(9) failure because it removed unnecessary DMA alignment restriction but once it happen you would get the same result. Note, original poster's machine is amd64. > I will try some more extensive tests over the next little while. > > igb0: Excessive collisions = 0 > igb0: Sequence errors = 0 > igb0: Defer count = 0 > igb0: Missed Packets = 0 > igb0: Receive No Buffers = 40 > igb0: Receive Length Errors = 0 > igb0: Receive errors = 2 > igb0: Crc errors = 4 > igb0: Alignment errors = 0 > igb0: Collision/Carrier extension errors = 0 > igb0: RX overruns = 0 > igb0: watchdog timeouts = 0 > igb0: XON Rcvd = 0 > igb0: XON Xmtd = 0 > igb0: XOFF Rcvd = 0 > igb0: XOFF Xmtd = 0 > igb0: Good Packets Rcvd = 103212774 > igb0: Good Packets Xmtd = 9347339 > igb0: TSO Contexts Xmtd = 0 > igb0: TSO Contexts Failed = 0 > igb1: Excessive collisions = 0 > igb1: Sequence errors = 0 > igb1: Defer count = 0 > igb1: Missed Packets = 0 > igb1: Receive No Buffers = 0 > igb1: Receive Length Errors = 0 > igb1: Receive errors = 0 > igb1: Crc errors = 0 > igb1: Alignment errors = 0 > igb1: Collision/Carrier extension errors = 0 > igb1: RX overruns = 0 > igb1: watchdog timeouts = 0 > igb1: XON Rcvd = 0 > igb1: XON Xmtd = 0 > igb1: XOFF Rcvd = 0 > igb1: XOFF Xmtd = 0 > igb1: Good Packets Rcvd = 9365642 > igb1: Good Packets Xmtd = 17781877 > igb1: TSO Contexts Xmtd = 988 > igb1: TSO Contexts Failed = 0 > > > > # ./netsend 10.255.255.3 600 300 280000 10 > Sending packet of payload size 300 every 0.000003571s for 10 seconds > > start: 1257884127.000000000 > finish: 1257884137.000003339 > send calls: 2800336 > send errors: 1970 > approx send rate: 279836 > approx error rate: 0 > waited: 1259257 > approx waits/sec: 125925 > approx wait rate: 0 > # traceroute 10.255.255.3 > traceroute to 10.255.255.3 (10.255.255.3), 64 hops max, 40 byte packets > 1 1.1.1.1 (1.1.1.1) 0.096 ms 0.073 ms 0.115 ms > 2 10.255.255.3 (10.255.255.3) 67.953 ms 0.297 ms 0.241 ms > > The box with the igb nics has the interfaces 1.1.1.1 and 10.255.255.1 > > ---Mike > > > >Jack > > > >------- if_igb.c (revision 197079) > >+++ if_igb.c (working copy) > >@@ -2654,7 +2654,7 @@ > > int error; > > > > error = bus_dma_tag_create(bus_get_dma_tag(adapter->dev), /* parent */ > >- IGB_DBA_ALIGN, 0, /* alignment, bounds */ > >+ 1, 0, /* alignment, bounds */ > > BUS_SPACE_MAXADDR, /* lowaddr */ > > BUS_SPACE_MAXADDR, /* highaddr */ > > NULL, NULL, /* filter, filterarg */ > >@@ -2867,7 +2867,7 @@ > > * Setup DMA descriptor areas. > > */ > > if ((error = bus_dma_tag_create(NULL, /* parent */ > >- PAGE_SIZE, 0, /* alignment, bounds */ > >+ 1, 0, /* alignment, bounds */ > > BUS_SPACE_MAXADDR, /* lowaddr */ > > BUS_SPACE_MAXADDR, /* highaddr */ > > NULL, NULL, /* filter, filterarg */ > >@@ -3554,7 +3554,7 @@ > > ** it may not always use this. > > */ > > if ((error = bus_dma_tag_create(NULL, /* parent */ > >- PAGE_SIZE, 0, /* alignment, bounds */ > >+ 1, 0, /* alignment, bounds */ > > BUS_SPACE_MAXADDR, /* lowaddr */ > > BUS_SPACE_MAXADDR, /* highaddr */ > > NULL, NULL, /* filter, filterarg */ > > > > > > > >On Tue, Nov 10, 2009 at 10:57 AM, Jack Vogel > ><jfvogel@gmail.com> wrote: > >I have repro'd this failure this morning and think I have a fix for > >it, I am testing that soon. > > > >Stay tuned, > > > >Jack > > > > > > > >On Mon, Nov 9, 2009 at 6:28 PM, Mike Tancsa > ><mike@sentex.net> wrote: > >At 07:33 PM 11/9/2009, Jack Vogel wrote: > >Some reason you aren't using amd64? I will have a system installed that way > >and see if I can repro it then, thanks. > > > > > > > >I had found in the past i386 was faster for firewall and routing > >applications. Perhaps thats different now, I will give it a try > >again to see if there is any difference. > > > >pciconf and dmesg attached. > > > > ---Mike > > > > > > > >Jack > > > > > > > >On Mon, Nov 9, 2009 at 4:22 PM, Mike Tancsa > ><mike@sentex.net> wrote: > >At 05:59 PM 11/9/2009, Jack Vogel wrote: > >Are you using standard MTU or jumbo? That get_buf error is ENOMEM, looks > >like > >that happens when in the bus_dma stuff reserve_bounce_pages() fails. > > > >Are you maybe using a 32 bit kernel? I have not seen this failure here. > > > > > >Hi Jack, > > Standard MTU and i386 > > > > ---Mike > > > > > > > >-------------------------------------------------------------------- > >Mike Tancsa, tel +1 519 651 3400 > >Sentex Communications, mike@sentex.net > >Providing Internet since > >1994 > ><http://www.sentex.net>www.sentex.net > >Cambridge, Ontario > >Canada > ><http://www.sentex.net/mike>www.sentex.net/mike > > > > > >-------------------------------------------------------------------- > >Mike Tancsa, tel +1 519 651 3400 > >Sentex > >Communications, > >mike@sentex.net > >Providing Internet since > >1994 www.sentex.net > >Cambridge, Ontario > >Canada > >www.sentex.net/mike > > > > > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > From des at des.no Wed Nov 11 20:31:49 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Nov 11 20:31:56 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <200911112031.43685.mel.flynn+fbsd.current@mailing.thruhere.net> (Mel Flynn's message of "Wed, 11 Nov 2009 20:31:43 +0100") References: <20091111101207.GF64905@hoeg.nl> <200911112031.43685.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <86fx8kolak.fsf@ds4.des.no> Mel Flynn writes: > I'm not in a position to test this at the moment, but does this mean > our console will now also "fold" paging/editor applications? I hate > this feature with a passion on linux and I've unable to find out how > to disable it, especially since the few linux machines I manage have > no termcap or terminfo database on the places they say they should be. The fact that FreeBSD doesn't do this is a bug. The purpose of /etc/termcap is to document the actual capabilities of the terminal, and saving and restoring the screen is one of xterm's capabilities, but somebody who didn't like it unilaterally decided to force their own personal preferences on everyone instead of tweaking their own shell configuration (export LESS=-X). DES -- Dag-Erling Sm?rgrav - des@des.no From mel.flynn+fbsd.current at mailing.thruhere.net Wed Nov 11 20:33:44 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Wed Nov 11 20:33:51 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: References: <20091111101207.GF64905@hoeg.nl> <200911112031.43685.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <200911112133.40692.mel.flynn+fbsd.current@mailing.thruhere.net> On Wednesday 11 November 2009 21:05:38 Ben Kelly wrote: > On Nov 11, 2009, at 2:31 PM, Mel Flynn wrote: > > On Wednesday 11 November 2009 11:12:07 Ed Schouten wrote: > >> - Better compatibility with other operating systems. > > > > I'm not in a position to test this at the moment, but does this mean our > > console will now also "fold" paging/editor applications? > > I hate this feature with a passion on linux and I've unable to find out > > how to disable it, especially since the few linux machines I manage have > > no termcap or terminfo database on the places they say they should be. > > What I mean with folding is: > > root@www:~# man less > > Reformatting less(1), please wait... > > root@www:~# > > > > As you can see, no more less(1) manpage (it's not limited to less, vim > > etc as well). When I change to vt100 terminal, this doesn't occur, hence > > my worry about the above sentence in combination with $subject. IF this > > is going to be the default, I would appreciate an rc.conf setting or at > > least an explanation of what triggers this behavior and how to turn it > > off in the manpage, as various quests in google have yielded neither > > information nor solution. > > Does this page help at all? > > http://www.shallowsky.com/linux/noaltscreen.html *bow*. Altscreen....it helps if you know what you're looking for. -- Mel From ed at 80386.nl Wed Nov 11 20:34:15 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Nov 11 20:34:22 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <86fx8kolak.fsf@ds4.des.no> References: <20091111101207.GF64905@hoeg.nl> <200911112031.43685.mel.flynn+fbsd.current@mailing.thruhere.net> <86fx8kolak.fsf@ds4.des.no> Message-ID: <20091111203413.GJ64905@hoeg.nl> * Dag-Erling Sm?rgrav wrote: > The fact that FreeBSD doesn't do this is a bug. The purpose of > /etc/termcap is to document the actual capabilities of the terminal, and > saving and restoring the screen is one of xterm's capabilities, but > somebody who didn't like it unilaterally decided to force their own > personal preferences on everyone instead of tweaking their own shell > configuration (export LESS=-X). As a side note, right now we don't support switching to alternate screen buffers (just becomes a no-op), but it looks like applications don't break because of this. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091111/a3bdc122/attachment.pgp From ed at 80386.nl Wed Nov 11 20:36:35 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Nov 11 20:36:41 2009 Subject: [Patch] Final call for testers: TERM=xterm In-Reply-To: <20091111101207.GF64905@hoeg.nl> References: <20091111101207.GF64905@hoeg.nl> Message-ID: <20091111203633.GK64905@hoeg.nl> Skipped content of type multipart/mixed-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091111/efc29a9b/attachment.pgp From dnelson at allantgroup.com Wed Nov 11 20:49:05 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Wed Nov 11 20:49:12 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> Message-ID: <20091111204903.GI89052@dan.emsphone.com> In the last episode (Nov 11), Ivan Voras said: > Sam Fourman Jr. wrote: > > I am running FreeBSD 8.0RC2 and I dont understand why my ZFS/NFS is > > acting weird on writes. I get ~150mbit writes idk if this is good or > > not? but it paused for a few seconds every once and awhile. > > You didn't give any "iostat" statistics - I suspect that if you > correlate ifstat and iostat output that you will see that network > "pauses" happen during spikes in IO. You should check for this and post > your results. Yes, iostat would be useful here. "iostat -zxC 2" will give you per-disk stats plus CPU usage every 2 seconds (CPU may be a factor if you have compression enabled). On a Solaris box I admin, setting zfs_write_limit_override helped stuttering while doing heavy writes. It's not exported on FreeBSD, but it should be easy to add it as a RW sysctl; it lives in dsl_pool.c and can be tweaked at runtime. Start big and tune it down so each write burst takes under a second; it looks like you're writing solid for around 6-8 seconds now. The number will vary depending on your disk speed and how much ARC you have. -- Dan Nelson dnelson@allantgroup.com From sthaug at nethelp.no Wed Nov 11 21:23:00 2009 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Wed Nov 11 21:23:08 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <86fx8kolak.fsf@ds4.des.no> References: <20091111101207.GF64905@hoeg.nl> <200911112031.43685.mel.flynn+fbsd.current@mailing.thruhere.net> <86fx8kolak.fsf@ds4.des.no> Message-ID: <20091111.215617.74746990.sthaug@nethelp.no> > The fact that FreeBSD doesn't do this is a bug. The purpose of > /etc/termcap is to document the actual capabilities of the terminal, and > saving and restoring the screen is one of xterm's capabilities, but > somebody who didn't like it unilaterally decided to force their own > personal preferences on everyone instead of tweaking their own shell > configuration (export LESS=-X). That may be so. However, I (like others on this list) hate that feature and its default usage in Linux with a passion. If the FreeBSD default is changed I guess I'll hate that equally much, which is kind of sad - because in most respects FreeBSD does what I want. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From swell.k at gmail.com Wed Nov 11 21:24:40 2009 From: swell.k at gmail.com (Anonymous) Date: Wed Nov 11 21:24:47 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <200911112031.43685.mel.flynn+fbsd.current@mailing.thruhere.net> (Mel Flynn's message of "Wed, 11 Nov 2009 20:31:43 +0100") References: <20091111101207.GF64905@hoeg.nl> <200911112031.43685.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <86d43oeovf.fsf@gmail.com> Mel Flynn writes: > Hi Ed, > > On Wednesday 11 November 2009 11:12:07 Ed Schouten wrote: > >> - Better compatibility with other operating systems. > > I'm not in a position to test this at the moment, but does this mean our > console will now also "fold" paging/editor applications? > I hate this feature with a passion on linux and I've unable to find out how to > disable it, especially since the few linux machines I manage have no termcap > or terminfo database on the places they say they should be. > What I mean with folding is: > root@www:~# man less > Reformatting less(1), please wait... > root@www:~# > > As you can see, no more less(1) manpage (it's not limited to less, vim etc as > well). When I change to vt100 terminal, this doesn't occur, hence my worry > about the above sentence in combination with $subject. IF this is going to be > the default, I would appreciate an rc.conf setting or at least an explanation > of what triggers this behavior and how to turn it off in the manpage, as > various quests in google have yielded neither information nor solution. I think for termcap(5) you can disable it by $ export TERMCAP="${TERM}:ti@:te@:tc=${TERM}:" From sfourman at gmail.com Wed Nov 11 21:26:17 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Wed Nov 11 21:26:28 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <20091111204903.GI89052@dan.emsphone.com> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> Message-ID: <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> On Wed, Nov 11, 2009 at 2:49 PM, Dan Nelson wrote: > In the last episode (Nov 11), Ivan Voras said: >> Sam Fourman Jr. wrote: >> > I am running FreeBSD 8.0RC2 and I dont understand why my ZFS/NFS is >> > acting weird on writes. ?I get ~150mbit writes idk if this is good or >> > not? ?but it paused for a few seconds every once and awhile. >> >> You didn't give any "iostat" statistics - I suspect that if you >> correlate ifstat and iostat output that you will see that network >> "pauses" happen during spikes in IO. You should check for this and post >> your results. > > Yes, iostat would be useful here. ?"iostat -zxC 2" will give you per-disk > stats plus CPU usage every 2 seconds (CPU may be a factor if you have > compression enabled). > > On a Solaris box I admin, setting zfs_write_limit_override helped stuttering > while doing heavy writes. ?It's not exported on FreeBSD, but it should be > easy to add it as a RW sysctl; it lives in dsl_pool.c and can be tweaked at > runtime. ?Start big and tune it down so each write burst takes under a > second; it looks like you're writing solid for around 6-8 seconds now. ?The > number will vary depending on your disk speed and how much ARC you have. here are some iostats for you. I do not believe I have compression enabled am I mistaken? isn'y SATA2 300MB/s? and I am doing ~6MB/s per disk? I built this machine with 4GB of memory because I thought ZFS would like it. now maybe a re(4) interface isnt the best choice. if that is the problem here I can change it. We spent ~$800 on a hardware RAID card thinking that it would help performance Why is it that with sftp we do not see the pauses in Network transfer? # iostat -zxC 1 (with NFS and ZFS) extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id ad4 0.1 0.4 2.0 6.1 0 3.1 0 0 0 1 1 98 da0 2.2 7.2 127.0 246.7 0 120.3 6 da1 2.0 7.5 117.3 246.2 0 120.4 6 da2 2.2 7.3 127.1 246.7 0 119.8 6 da3 2.0 7.6 115.5 246.2 0 119.8 5 da4 2.2 7.3 126.1 246.7 0 119.9 5 da5 2.0 7.5 115.6 246.3 0 119.8 5 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id 0 0 0 0 99 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id 0 0 0 0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id 0 0 0 0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id 0 0 0 0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id 0 0 0 0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id 0 0 0 0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id 0 0 0 0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id 0 0 0 0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id 0 0 0 0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id 0 0 0 0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id 0 0 0 0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id ad4 0.0 11.0 0.0 175.6 0 1.4 0 2 0 3 0 95 da0 0.0 47.9 0.0 94.3 0 1.0 1 da1 0.0 54.9 0.0 84.8 0 1.4 2 da2 0.0 44.9 0.0 92.8 0 1.0 1 da3 0.0 48.9 0.0 83.3 0 1.4 2 da4 0.0 47.9 0.0 95.3 0 1.0 1 da5 0.0 53.9 0.0 87.8 0 1.2 2 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id 0 0 0 0 99 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id 0 0 0 0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id 0 0 0 0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id 0 0 0 0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id ad4 0.0 28.9 0.0 462.8 0 3.5 1 0 0 0 0 99 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 131.7 0.0 8392.0 0.0 35 73.6 60 0 0 4 3 93 da1 118.8 0.0 7561.7 0.0 35 74.9 62 da2 127.7 0.0 8136.5 0.0 35 77.7 63 da3 103.8 0.0 6603.7 0.0 29 137.6 79 da4 106.8 0.0 6795.8 0.0 33 112.9 74 da5 123.7 0.0 7919.4 0.0 35 126.9 83 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 51.9 89.9 3322.5 1487.5 4 77.4 38 0 0 6 5 89 da1 55.9 109.8 3578.1 1469.6 4 76.4 49 da2 58.9 88.9 3769.8 1604.8 1 75.3 46 da3 69.9 105.8 4472.6 1652.8 0 117.0 82 da4 66.9 85.9 4280.9 1490.0 3 112.4 70 da5 66.9 108.8 4280.9 1469.6 3 105.3 69 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 107.7 0.0 5069.1 10 53.0 80 0 0 9 8 83 da1 0.0 107.7 0.0 5069.1 10 54.4 81 da2 0.0 103.7 0.0 4953.9 10 50.4 73 da3 0.0 102.7 0.0 4890.1 10 51.7 74 da4 0.0 108.7 0.0 5299.5 6 50.0 74 da5 0.0 108.7 0.0 5299.5 6 51.6 76 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 106.7 0.0 5196.4 4 50.5 76 0 0 8 8 85 da1 0.0 106.7 0.0 5196.4 4 52.1 78 da2 0.0 103.7 0.0 5196.4 4 49.3 73 da3 0.0 103.7 0.0 5196.4 4 52.1 75 da4 0.0 103.7 0.0 4991.5 3 51.7 78 da5 0.0 103.7 0.0 4991.5 5 52.8 80 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 114.8 0.0 5404.5 0 47.5 81 0 0 9 7 84 da1 0.0 111.8 0.0 5250.9 3 49.4 78 da2 0.0 113.8 0.0 5404.5 0 48.3 73 da3 0.0 113.8 0.0 5404.5 0 50.1 75 da4 0.0 111.8 0.0 5379.1 0 48.0 78 da5 0.0 111.8 0.0 5379.1 0 49.1 81 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 102.7 0.0 4890.1 13 50.2 70 0 0 8 9 83 da1 0.0 105.7 0.0 5043.7 13 53.0 77 da2 0.0 105.7 0.0 5120.5 9 47.7 73 da3 0.0 105.7 0.0 5120.5 9 50.5 75 da4 0.0 107.7 0.0 5120.1 9 49.7 77 da5 0.0 107.7 0.0 5120.1 9 51.6 79 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 109.8 0.0 5353.4 0 52.6 81 0 0 7 7 85 da1 0.0 109.8 0.0 5353.4 0 53.9 81 da2 0.0 103.8 0.0 5122.3 0 53.0 78 da3 0.0 103.8 0.0 5122.3 0 54.5 78 da4 0.0 105.8 0.0 5122.8 0 52.8 80 da5 0.0 105.8 0.0 5122.8 0 54.7 81 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 107.8 0.0 5150.4 8 50.0 77 0 0 9 8 83 da1 0.0 107.8 0.0 5150.4 8 52.3 79 da2 0.0 107.8 0.0 5176.4 8 49.2 77 da3 0.0 107.8 0.0 5176.4 8 51.5 78 da4 0.0 108.8 0.0 5175.9 8 49.9 77 da5 0.0 108.8 0.0 5175.9 8 52.7 77 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 107.7 0.0 5299.6 0 53.5 78 0 0 7 7 86 da1 0.0 107.7 0.0 5299.6 0 56.1 78 da2 0.0 105.7 0.0 5146.0 2 54.0 82 da3 0.0 103.7 0.0 5043.3 4 54.1 77 da4 0.0 107.7 0.0 5248.7 1 54.1 78 da5 0.0 107.7 0.0 5248.7 1 56.2 78 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 106.8 0.0 5124.5 8 48.7 77 0 0 9 9 82 da1 0.0 102.8 0.0 4893.9 12 52.0 76 da2 0.0 105.8 0.0 5022.2 13 51.7 75 da3 0.0 107.8 0.0 5125.0 13 54.9 81 da4 0.0 107.8 0.0 5150.5 8 50.2 78 da5 0.0 107.8 0.0 5150.5 8 50.7 79 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 105.7 0.0 5171.9 1 53.0 78 0 0 9 7 84 da1 0.0 109.7 0.0 5402.3 1 54.8 81 da2 0.0 107.7 0.0 5274.1 3 51.5 81 da3 0.0 105.7 0.0 5171.4 5 52.0 77 da4 0.0 105.7 0.0 5146.0 1 53.8 76 da5 0.0 105.7 0.0 5146.0 1 55.1 78 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 107.8 0.0 5124.6 9 49.8 79 0 0 9 11 80 da1 0.0 105.8 0.0 4996.8 11 52.0 78 da2 0.0 105.8 0.0 5022.3 13 51.3 73 da3 0.0 107.8 0.0 5125.1 13 54.5 79 da4 0.0 107.8 0.0 5150.6 9 49.4 76 da5 0.0 107.8 0.0 5150.6 9 51.3 77 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 105.8 0.0 5148.1 0 53.2 79 0 0 6 7 87 da1 0.0 107.8 0.0 5275.8 0 54.7 79 da2 0.0 108.8 0.0 5378.6 0 52.2 81 da3 0.0 108.8 0.0 5378.6 0 54.1 81 da4 0.0 106.8 0.0 5148.1 0 53.9 82 da5 0.0 106.8 0.0 5148.1 0 55.6 82 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id ad4 0.0 4.0 0.0 12.0 0 0.5 0 0 0 16 6 77 da0 0.0 108.8 0.0 4988.2 64 69.9 65 da1 0.0 109.8 0.0 5091.5 64 91.7 73 da2 0.0 107.8 0.0 5014.1 64 48.3 57 da3 0.0 86.8 0.0 3733.3 43 71.4 73 da4 0.0 109.8 0.0 5088.0 64 70.6 71 da5 0.0 104.8 0.0 4578.0 62 59.0 61 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 98.8 0.0 5724.0 69 490.3 109 0 0 2 1 97 da1 0.0 86.8 0.0 5007.5 69 562.7 102 da2 0.0 125.7 0.0 7222.9 69 465.5 114 da3 0.0 92.8 0.0 5303.4 70 538.2 100 da4 0.0 113.8 0.0 6557.3 70 486.6 104 da5 0.0 110.8 0.0 6339.2 69 468.6 114 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 104.8 0.0 6032.5 68 706.3 100 0 0 2 0 98 da1 0.0 103.8 0.0 5993.6 62 654.4 99 da2 0.0 104.8 0.0 6057.4 67 657.3 100 da3 0.0 104.8 0.0 6057.4 62 654.0 100 da4 0.0 104.8 0.0 6057.4 67 644.2 100 da5 0.0 103.8 0.0 5993.6 61 683.7 99 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 104.8 0.0 6057.3 67 624.9 100 0 0 1 1 98 da1 0.0 104.8 0.0 6057.3 63 531.2 100 da2 0.0 104.8 0.0 6057.3 68 625.4 100 da3 0.0 104.8 0.0 6032.3 63 551.6 100 da4 0.0 104.8 0.0 6057.3 68 625.7 100 da5 0.0 105.8 0.0 6121.1 61 510.1 101 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 106.8 0.0 6160.2 68 616.8 100 0 0 2 1 97 da1 0.0 106.8 0.0 6160.2 62 522.8 100 da2 0.0 106.8 0.0 6160.2 67 617.1 100 da3 0.0 106.8 0.0 6185.1 62 522.8 100 da4 0.0 106.8 0.0 6160.2 67 617.4 100 da5 0.0 106.8 0.0 6160.2 62 503.4 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 107.7 0.0 6221.3 68 607.9 100 0 0 0 2 98 da1 0.0 108.7 0.0 6285.1 63 515.2 100 da2 0.0 108.7 0.0 6285.1 68 608.3 101 da3 0.0 108.7 0.0 6260.2 63 515.3 100 da4 0.0 107.7 0.0 6221.3 67 608.6 100 da5 0.0 107.7 0.0 6221.3 62 496.0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 109.8 0.0 6354.5 68 599.2 101 0 0 1 1 98 da1 0.0 109.8 0.0 6329.5 63 507.8 100 da2 0.0 108.8 0.0 6290.6 65 599.4 99 da3 0.0 108.8 0.0 6290.6 62 507.9 99 da4 0.0 109.8 0.0 6354.5 66 599.7 100 da5 0.0 109.8 0.0 6329.5 62 489.0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 112.8 0.0 6518.3 31 586.1 100 0 0 1 1 98 da1 0.0 112.8 0.0 6518.3 53 480.6 100 da2 0.0 112.8 0.0 6493.4 5 573.1 100 da3 0.0 112.8 0.0 6174.5 63 677.5 100 da4 0.0 112.8 0.0 6493.4 15 576.6 100 da5 0.0 111.8 0.0 5690.1 42 846.4 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 159.6 0.0 5581.4 1 208.5 86 0 0 7 7 86 da1 0.0 188.5 0.0 6181.4 1 346.6 87 da2 0.0 131.7 0.0 4023.3 2 152.0 76 da3 0.0 191.5 0.0 7381.9 5 244.5 86 da4 0.0 140.6 0.0 4442.3 5 177.2 80 da5 0.0 164.6 0.0 5976.9 5 149.8 84 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 103.8 0.0 4945.3 13 50.8 78 0 0 12 7 81 da1 0.0 103.8 0.0 4945.3 13 52.6 79 da2 0.0 105.8 0.0 4983.7 13 52.0 77 da3 0.0 108.8 0.0 5150.5 13 54.2 80 da4 0.0 107.8 0.0 5150.5 13 52.5 79 da5 0.0 107.8 0.0 5150.5 13 54.9 79 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 106.8 0.0 5250.5 4 51.8 80 0 0 7 7 86 da1 0.0 106.8 0.0 5250.5 4 53.5 79 da2 0.0 107.8 0.0 5225.1 5 52.8 81 da3 0.0 107.8 0.0 5225.1 5 54.9 82 da4 0.0 102.8 0.0 5020.5 8 51.7 74 da5 0.0 102.8 0.0 5020.5 8 53.2 74 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 102.7 0.0 5069.2 0 53.3 77 0 0 7 7 85 da1 0.0 102.7 0.0 5069.2 0 56.2 80 da2 0.0 104.7 0.0 5094.7 0 54.2 80 da3 0.0 104.7 0.0 5094.7 0 55.7 80 da4 0.0 108.7 0.0 5299.6 0 55.0 83 da5 0.0 108.7 0.0 5299.6 0 57.2 83 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 109.8 0.0 5304.2 5 48.8 77 0 0 7 8 85 da1 0.0 109.8 0.0 5304.2 5 50.9 79 da2 0.0 105.8 0.0 5048.1 9 49.2 75 da3 0.0 105.8 0.0 5048.1 9 50.7 77 da4 0.0 106.8 0.0 5073.6 9 49.7 74 da5 0.0 106.8 0.0 5073.6 9 50.4 74 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 105.7 0.0 5095.2 1 55.4 80 0 0 10 8 83 da1 0.0 105.7 0.0 5095.2 1 57.4 80 da2 0.0 108.7 0.0 5376.5 1 54.4 81 da3 0.0 108.7 0.0 5376.5 1 56.5 82 da4 0.0 104.7 0.0 5120.1 5 53.7 79 da5 0.0 108.7 0.0 5350.5 1 56.6 86 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id ad4 0.0 13.0 0.0 207.7 0 1.8 0 0 0 10 10 80 da0 0.0 107.8 0.0 5124.5 6 49.7 78 da1 0.0 107.8 0.0 5124.5 6 51.6 79 da2 0.0 104.8 0.0 4970.7 8 49.4 73 da3 0.0 102.8 0.0 4868.4 10 52.2 70 da4 0.0 110.8 0.0 5330.1 6 50.6 80 da5 0.0 106.8 0.0 5099.5 6 51.1 75 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id ad4 0.0 1.0 0.0 2.0 0 0.2 0 0 0 8 10 82 da0 0.0 102.7 0.0 5069.0 0 51.9 78 da1 0.0 102.7 0.0 5069.0 0 53.1 78 da2 0.0 105.7 0.0 5197.2 0 52.0 77 da3 0.0 107.7 0.0 5299.4 0 53.1 81 da4 0.0 105.7 0.0 5069.0 0 54.6 79 da5 0.0 105.7 0.0 5069.0 0 55.1 81 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 105.8 0.0 5099.8 7 49.0 74 0 0 9 7 84 da1 0.0 105.8 0.0 5099.8 7 49.6 75 da2 0.0 110.8 0.0 5329.9 3 49.2 80 da3 0.0 110.8 0.0 5329.9 3 51.2 80 da4 0.0 109.8 0.0 5240.5 4 50.6 78 da5 0.0 106.8 0.0 5073.8 7 51.5 77 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 106.8 0.0 5198.3 0 53.9 80 0 0 6 7 87 da1 0.0 106.8 0.0 5198.3 0 56.4 82 da2 0.0 101.8 0.0 4968.3 0 53.5 77 da3 0.0 101.8 0.0 4968.3 0 54.4 80 da4 0.0 103.8 0.0 5057.6 0 53.3 75 da5 0.0 106.8 0.0 5224.3 0 55.6 77 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 106.8 0.0 5098.2 7 48.8 73 0 0 7 9 84 da1 0.0 106.8 0.0 5098.2 7 50.7 76 da2 0.0 110.8 0.0 5328.2 3 49.2 78 da3 0.0 110.8 0.0 5328.2 3 51.2 80 da4 0.0 108.8 0.0 5238.9 4 49.8 75 da5 0.0 105.8 0.0 5072.2 7 50.7 73 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 137.7 0.0 7561.1 70 223.8 94 0 0 13 2 85 da1 0.0 116.8 0.0 6087.7 70 241.2 94 da2 0.0 92.8 0.0 4976.1 70 297.9 91 da3 0.0 111.8 0.0 5906.1 70 277.4 72 da4 0.0 80.8 0.0 4320.9 70 279.3 88 da5 0.0 106.8 0.0 5625.7 70 316.1 91 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 111.7 0.0 6451.7 70 643.3 100 0 0 1 1 98 da1 0.0 111.7 0.0 6451.7 70 643.6 100 da2 0.0 111.7 0.0 6451.7 70 595.3 100 da3 0.0 104.7 0.0 6054.7 69 641.7 118 da4 0.0 112.7 0.0 6515.5 69 620.6 101 da5 0.0 103.7 0.0 5990.8 70 602.5 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 108.8 0.0 6287.9 69 635.6 100 0 0 2 2 97 da1 0.0 109.8 0.0 6326.8 70 636.0 100 da2 0.0 109.8 0.0 6326.8 70 635.7 100 da3 0.0 109.8 0.0 6351.7 69 635.9 101 da4 0.0 108.8 0.0 6262.9 70 635.4 100 da5 0.0 109.8 0.0 6326.8 70 635.3 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id ad4 0.0 8.0 0.0 127.7 0 1.1 0 0 0 3 0 96 da0 0.0 109.8 0.0 6326.8 65 616.5 100 da1 0.0 108.8 0.0 6287.9 62 630.3 100 da2 0.0 108.8 0.0 6287.9 66 635.8 99 da3 0.0 109.8 0.0 6326.8 60 634.5 100 da4 0.0 109.8 0.0 6351.7 66 635.5 100 da5 0.0 108.8 0.0 6287.9 61 635.4 99 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 109.8 0.0 6351.7 65 562.5 100 0 0 4 1 95 da1 0.0 109.8 0.0 6351.7 62 507.9 100 da2 0.0 109.8 0.0 6351.7 66 586.2 100 da3 0.0 108.8 0.0 6287.9 61 471.3 99 da4 0.0 108.8 0.0 6287.9 65 576.8 99 da5 0.0 109.8 0.0 6351.7 61 503.6 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 108.8 0.0 6263.0 66 562.1 99 0 0 2 0 97 da1 0.0 108.8 0.0 6263.0 63 507.6 99 da2 0.0 109.8 0.0 6326.8 66 580.3 100 da3 0.0 109.8 0.0 6326.8 61 471.1 100 da4 0.0 109.8 0.0 6326.8 65 561.7 100 da5 0.0 109.8 0.0 6326.8 61 488.7 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 129.8 0.0 4390.7 0 380.0 70 0 0 1 4 95 da1 0.0 154.7 0.0 5853.3 0 440.6 91 da2 0.0 166.7 0.0 6683.4 0 410.9 96 da3 0.0 169.7 0.0 6133.9 0 439.4 95 da4 0.0 176.7 0.0 7427.7 0 424.0 98 da5 0.0 170.7 0.0 6736.9 0 449.1 97 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 111.8 0.0 5148.2 8 44.7 75 0 0 7 7 85 da1 0.0 111.8 0.0 5148.2 8 47.3 75 da2 0.0 109.8 0.0 5148.2 8 45.2 75 da3 0.0 109.8 0.0 5148.2 8 47.2 76 da4 0.0 107.8 0.0 4917.7 13 46.1 77 da5 0.0 107.8 0.0 4917.7 13 48.2 76 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 105.7 0.0 5196.9 0 52.8 80 0 0 8 9 83 da1 0.0 105.7 0.0 5196.9 0 55.7 83 da2 0.0 106.7 0.0 5171.9 1 53.8 78 da3 0.0 106.7 0.0 5171.9 1 55.9 78 da4 0.0 109.7 0.0 5427.8 0 52.2 81 da5 0.0 109.7 0.0 5427.8 0 54.8 82 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 106.8 0.0 5227.4 4 47.3 75 0 0 12 8 80 da1 0.0 106.8 0.0 5227.4 4 48.9 75 da2 0.0 107.8 0.0 4996.7 9 49.3 80 da3 0.0 107.8 0.0 4996.7 9 52.0 81 da4 0.0 104.8 0.0 4996.7 8 47.2 65 da5 0.0 104.8 0.0 4996.7 8 50.0 68 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 102.7 0.0 4966.8 0 53.2 76 0 0 8 9 83 da1 0.0 102.7 0.0 4966.8 0 56.1 77 da2 0.0 105.7 0.0 5222.6 0 52.4 76 da3 0.0 105.7 0.0 5222.6 0 55.4 78 da4 0.0 106.7 0.0 5196.7 0 53.6 81 da5 0.0 106.7 0.0 5196.7 0 56.1 81 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 111.8 0.0 5279.0 6 50.9 82 0 0 6 10 84 da1 0.0 113.8 0.0 5406.7 4 52.7 82 da2 0.0 106.8 0.0 5150.7 9 49.9 76 da3 0.0 106.8 0.0 5150.7 9 51.4 77 da4 0.0 106.8 0.0 5176.6 8 49.1 76 da5 0.0 106.8 0.0 5176.6 8 50.2 78 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 103.7 0.0 5146.0 0 53.0 77 0 0 7 9 84 da1 0.0 101.7 0.0 5018.3 0 55.6 79 da2 0.0 108.7 0.0 5273.7 0 54.7 82 da3 0.0 108.7 0.0 5273.7 0 55.2 82 da4 0.0 107.7 0.0 5248.2 0 54.3 80 da5 0.0 107.7 0.0 5248.2 0 56.9 80 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 106.8 0.0 5073.6 9 49.1 74 0 0 10 9 82 da1 0.0 106.8 0.0 5073.6 9 51.1 74 da2 0.0 108.8 0.0 5304.2 5 48.1 76 da3 0.0 108.8 0.0 5304.2 5 50.3 78 da4 0.0 106.8 0.0 5048.1 9 49.3 78 da5 0.0 106.8 0.0 5048.1 9 51.2 78 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 107.8 0.0 5122.3 11 50.3 79 0 0 8 8 83 da1 0.0 107.8 0.0 5122.3 11 52.7 83 da2 0.0 103.8 0.0 4892.3 11 50.4 71 da3 0.0 103.8 0.0 4892.3 11 51.7 71 da4 0.0 109.8 0.0 5378.8 6 48.5 74 da5 0.0 109.8 0.0 5378.8 6 50.0 77 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 108.5 0.0 5188.6 4 51.0 78 0 0 7 9 84 da1 0.0 108.5 0.0 5188.6 4 53.0 80 da2 0.0 106.6 0.0 5188.6 4 51.6 72 da3 0.0 106.6 0.0 5188.6 4 52.6 73 da4 0.0 99.6 0.0 4958.1 4 50.5 76 da5 0.0 99.6 0.0 4958.1 4 52.4 77 ^C # Here is a quick sample with sftp and ZFS (keep in mind ssh has encryption NFS does not) # ifstat -b -i re0 re0 Kbps in Kbps out 260931.9 8590.13 205778.7 6825.03 285794.0 9565.88 242095.0 8016.92 238060.4 7924.14 262288.7 8660.99 260094.6 8660.25 268791.7 8869.08 303607.5 10010.25 263964.4 8736.56 261743.6 8659.45 246390.6 8191.83 300105.3 10305.06 255019.9 8291.85 283355.3 9390.99 277390.9 9198.74 279070.0 9218.81 278103.5 9339.65 258649.8 8492.39 251343.6 8320.49 283036.9 9346.05 283302.4 9277.87 278886.2 9384.52 300472.5 9772.91 292509.8 9669.22 299081.4 9816.50 313643.0 10299.40 289208.9 9747.82 313738.8 10228.35 207670.6 6837.77 248762.1 8224.13 194959.1 6457.88 265009.2 9495.61 249181.9 8228.59 272940.6 8945.51 226037.8 7485.62 273701.2 9048.08 236890.4 7834.88 # iostat -zxC 1 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id ad4 0.1 0.4 1.8 6.1 0 3.0 0 1 0 1 1 97 da0 2.0 13.4 117.8 551.1 16 203.8 10 da1 1.9 13.7 108.8 550.6 16 200.5 10 da2 2.1 13.4 117.8 551.1 20 203.0 10 da3 1.9 13.8 107.1 550.6 20 200.1 9 da4 2.0 13.4 116.8 551.1 16 203.4 9 da5 1.9 13.8 107.3 550.6 16 199.8 9 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 108.8 0.0 6289.0 69 315.8 101 21 0 18 13 48 da1 0.0 107.8 0.0 6225.1 70 321.8 102 da2 0.0 108.8 0.0 6289.0 69 331.0 100 da3 0.0 111.8 0.0 6455.7 70 322.7 101 da4 0.0 104.8 0.0 6058.4 69 326.7 101 da5 0.0 108.8 0.0 6289.0 69 327.1 101 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 109.8 0.0 6326.8 69 633.3 100 15 0 8 9 68 da1 0.0 109.8 0.0 6326.8 70 627.8 100 da2 0.0 109.8 0.0 6351.8 69 624.3 100 da3 0.0 108.8 0.0 6287.9 69 629.0 99 da4 0.0 109.8 0.0 6351.8 69 640.0 100 da5 0.0 109.8 0.0 6351.8 69 625.0 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 109.8 0.0 6351.9 44 634.9 100 3 0 3 3 91 da1 0.0 108.8 0.0 6288.0 46 634.5 99 da2 0.0 109.8 0.0 6326.9 41 634.8 100 da3 0.0 109.8 0.0 6351.9 39 634.6 100 da4 0.0 109.8 0.0 6326.9 48 635.2 100 da5 0.0 108.8 0.0 6263.0 45 635.2 99 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 111.8 0.0 6163.1 68 356.9 98 9 0 18 6 67 da1 0.0 127.7 0.0 7109.6 68 354.4 98 da2 0.0 106.8 0.0 5829.3 68 399.2 91 da3 0.0 104.8 0.0 5701.1 67 349.2 84 da4 0.0 113.8 0.0 6291.3 68 377.4 96 da5 0.0 110.8 0.0 6124.2 68 353.0 79 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 129.8 0.0 6805.8 70 519.5 100 19 0 14 19 49 da1 0.0 119.8 0.0 5371.1 70 502.2 100 da2 0.0 93.8 0.0 5408.1 58 607.6 104 da3 0.0 139.8 0.0 6706.4 70 457.6 111 da4 0.0 132.8 0.0 7582.5 60 476.8 102 da5 0.0 130.8 0.0 6156.3 69 511.3 117 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 109.8 0.0 6326.8 70 535.4 100 17 0 12 12 59 da1 0.0 109.8 0.0 6351.8 70 523.0 100 da2 0.0 109.8 0.0 6351.8 58 396.3 100 da3 0.0 109.8 0.0 6326.8 70 521.1 100 da4 0.0 109.8 0.0 6351.8 60 431.1 100 da5 0.0 109.8 0.0 6326.8 69 515.6 101 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 109.8 0.0 6351.7 70 632.7 100 18 0 11 15 56 da1 0.0 109.8 0.0 6326.8 70 632.7 100 da2 0.0 109.8 0.0 6326.8 58 414.1 100 da3 0.0 110.8 0.0 6415.6 69 632.4 101 da4 0.0 109.8 0.0 6326.8 60 468.3 100 da5 0.0 109.8 0.0 6351.7 69 632.5 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 104.8 0.0 5996.4 0 631.6 93 22 0 8 14 57 da1 0.0 123.7 0.0 6598.7 0 616.9 99 da2 0.0 135.7 0.0 7264.3 5 668.5 101 da3 0.0 115.8 0.0 6149.6 0 623.4 97 da4 0.0 99.8 0.0 5323.8 0 746.0 89 da5 0.0 125.7 0.0 6735.4 0 615.4 99 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 126.7 0.0 4006.1 70 115.8 43 17 0 18 12 54 da1 0.0 126.7 0.0 3634.9 70 115.3 51 da2 0.0 109.8 0.0 3090.1 70 100.1 52 da3 0.0 109.8 0.0 2708.9 70 107.4 48 da4 0.0 115.8 0.0 3163.9 70 92.1 52 da5 0.0 118.8 0.0 3196.3 70 111.5 52 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 103.8 0.0 5993.5 67 592.8 108 20 0 12 15 53 da1 0.0 114.8 0.0 6646.1 62 547.2 100 da2 0.0 117.8 0.0 6812.8 67 554.3 100 da3 0.0 108.8 0.0 6287.9 64 566.6 103 da4 0.0 108.8 0.0 6287.9 66 595.2 100 da5 0.0 104.8 0.0 6057.4 62 597.1 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 109.8 0.0 6326.6 67 597.7 100 23 0 10 15 52 da1 0.0 109.8 0.0 6326.6 62 546.1 100 da2 0.0 109.8 0.0 6326.6 67 601.6 100 da3 0.0 110.8 0.0 6390.5 62 563.9 101 da4 0.0 109.8 0.0 6351.5 66 603.0 100 da5 0.0 109.8 0.0 6326.6 62 566.4 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id ad4 0.0 1.0 0.0 6.0 0 0.4 0 18 0 10 13 59 da0 0.0 109.7 0.0 6349.1 67 578.3 100 da1 0.0 109.7 0.0 6349.1 62 506.0 100 da2 0.0 109.7 0.0 6349.1 67 578.2 100 da3 0.0 109.7 0.0 6324.2 62 486.9 100 da4 0.0 109.7 0.0 6324.2 66 578.2 100 da5 0.0 109.7 0.0 6349.1 61 505.5 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 110.8 0.0 6367.5 37 577.3 101 18 0 10 12 60 da1 0.0 109.8 0.0 6303.6 40 505.1 100 da2 0.0 109.8 0.0 6303.6 44 577.4 100 da3 0.0 109.8 0.0 6303.6 60 486.3 100 da4 0.0 109.8 0.0 6303.6 47 577.3 100 da5 0.0 109.8 0.0 6316.6 58 500.2 100 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 145.7 0.0 5188.2 70 280.0 85 19 0 16 10 55 da1 0.0 146.7 0.0 4827.9 70 360.9 89 da2 0.0 154.7 0.0 6099.2 70 300.0 83 da3 0.0 173.6 0.0 6462.0 70 371.0 84 da4 0.0 163.7 0.0 6266.4 70 297.1 91 da5 0.0 176.6 0.0 6327.8 70 352.1 89 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 122.7 0.0 7082.2 69 507.1 102 25 0 11 13 51 da1 0.0 117.8 0.0 6812.8 70 514.6 99 da2 0.0 104.8 0.0 6057.3 69 589.2 108 da3 0.0 102.8 0.0 5929.6 69 591.3 109 da4 0.0 107.8 0.0 6224.0 70 561.0 101 da5 0.0 105.8 0.0 6096.3 70 566.3 104 extended device statistics cpu device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id da0 0.0 109.7 0.0 6348.9 69 632.2 100 20 0 12 11 57 da1 0.0 109.7 0.0 6324.0 70 633.1 100 da2 0.0 109.7 0.0 6324.0 69 632.3 100 da3 0.0 109.7 0.0 6348.9 69 633.1 100 da4 0.0 109.7 0.0 6348.9 70 633.1 100 da5 0.0 109.7 0.0 6348.9 70 632.3 100 ^C # From des at des.no Wed Nov 11 21:34:04 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Nov 11 21:34:16 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <20091111.215617.74746990.sthaug@nethelp.no> (sthaug@nethelp.no's message of "Wed, 11 Nov 2009 21:56:17 +0100 (CET)") References: <20091111101207.GF64905@hoeg.nl> <200911112031.43685.mel.flynn+fbsd.current@mailing.thruhere.net> <86fx8kolak.fsf@ds4.des.no> <20091111.215617.74746990.sthaug@nethelp.no> Message-ID: <86639goiet.fsf@ds4.des.no> sthaug@nethelp.no writes: > That may be so. However, I (like others on this list) hate that feature > and its default usage in Linux with a passion. I don't understand why you are blaming Linux for this. It's an xterm feature that probably goes back twenty years or more (xterm turned 25 a few months ago). We're not talking just xterm, either; searching for "ti=" in /etc/termcap reveals that it was available on dozens of terminals, including several IBM and TekTronix models, just to drop a couple of big names. Modern Unix was built on the "mechanism, not policy" principle, and there is no reason why we should make an exception in this particular instance. If our termcap hadn't been intentionally sabotaged, those who hate this feature (as I used to) could easily turn it off, but as things stand, those who like it (as I do now) can't easily turn it back on, especially if they work in mixed environments. DES -- Dag-Erling Sm?rgrav - des@des.no From sthaug at nethelp.no Wed Nov 11 21:46:31 2009 From: sthaug at nethelp.no (sthaug@nethelp.no) Date: Wed Nov 11 21:46:38 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <86639goiet.fsf@ds4.des.no> References: <86fx8kolak.fsf@ds4.des.no> <20091111.215617.74746990.sthaug@nethelp.no> <86639goiet.fsf@ds4.des.no> Message-ID: <20091111.224629.71094278.sthaug@nethelp.no> > > That may be so. However, I (like others on this list) hate that feature > > and its default usage in Linux with a passion. > > I don't understand why you are blaming Linux for this. It's an xterm > feature that probably goes back twenty years or more (xterm turned 25 a > few months ago). We're not talking just xterm, either; searching for > "ti=" in /etc/termcap reveals that it was available on dozens of > terminals, including several IBM and TekTronix models, just to drop a > couple of big names. Oh, I'm not blaming Linux. I have edited my fair share of termcap files, even going back to SunOS and early X11, just to get rid of this (in my view) extremely annoying feature. > Modern Unix was built on the "mechanism, not policy" principle, and > there is no reason why we should make an exception in this particular > instance. If our termcap hadn't been intentionally sabotaged, those who > hate this feature (as I used to) could easily turn it off, but as things > stand, those who like it (as I do now) can't easily turn it back on, > especially if they work in mixed environments. You can have your own private termcap/terminfo file, so it is possible to use the feature if you want to. "mechanism, not policy" is fine, but there is also a need to choose sensible defaults. In this case I like the FreeBSD default better than the Linux default. If the FreeBSD default changes, I'll learn to live with that. I think we'll have to agree t disagree. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From ivoras at freebsd.org Wed Nov 11 21:53:03 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Nov 11 21:53:10 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> Message-ID: <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> 2009/11/11 Sam Fourman Jr. : > On Wed, Nov 11, 2009 at 2:49 PM, Dan Nelson wrote: >> In the last episode (Nov 11), Ivan Voras said: >>> Sam Fourman Jr. wrote: >>> > I am running FreeBSD 8.0RC2 and I dont understand why my ZFS/NFS is >>> > acting weird on writes. ?I get ~150mbit writes idk if this is good or >>> > not? ?but it paused for a few seconds every once and awhile. >>> >>> You didn't give any "iostat" statistics - I suspect that if you >>> correlate ifstat and iostat output that you will see that network >>> "pauses" happen during spikes in IO. You should check for this and post >>> your results. >> >> Yes, iostat would be useful here. ?"iostat -zxC 2" will give you per-disk >> stats plus CPU usage every 2 seconds (CPU may be a factor if you have >> compression enabled). >> >> On a Solaris box I admin, setting zfs_write_limit_override helped stuttering >> while doing heavy writes. ?It's not exported on FreeBSD, but it should be >> easy to add it as a RW sysctl; it lives in dsl_pool.c and can be tweaked at >> runtime. ?Start big and tune it down so each write burst takes under a >> second; it looks like you're writing solid for around 6-8 seconds now. ?The >> number will vary depending on your disk speed and how much ARC you have. > > > here are some iostats for you. I do not believe I have compression enabled > am I mistaken? isn'y SATA2 300MB/s? and I am doing ~6MB/s per disk? > I built this machine with 4GB of memory because I thought ZFS would like it. > now maybe a re(4) interface isnt the best choice. if that is the > problem here I can change it. Your io/ifstat data is very long but you didn't say if you observed hiccups in network performance during heavy IO times? Since you don't have timestamps in your data you are the only one who can say. > We spent ~$800 on a hardware RAID card thinking that it would help performance > > Why is it that with sftp we do not see the pauses in Network transfer? I think NFS uses sync disk IO access by default, this may be your problem if you are write-heavy. Try setting vfs.nfsrv.async to 1 to see if this is the cause of your problems. From mel.flynn+fbsd.current at mailing.thruhere.net Wed Nov 11 22:11:56 2009 From: mel.flynn+fbsd.current at mailing.thruhere.net (Mel Flynn) Date: Wed Nov 11 22:12:03 2009 Subject: Possible regression with msk driver Message-ID: <200911112311.51709.mel.flynn+fbsd.current@mailing.thruhere.net> Hi, I just booted a box from 7.2-p4 to FreeBSD 8.0-PRERELEASE #0 r199185. It didn't ping, even though the interface was marked up and active. No traffic at all. The fix was to ifconfig msk0 down; ifconfig msk0 up. From then on, everything worked and still is: mskc0: port 0xe800-0xe8ff mem 0xf9efc000-0xf9efffff irq 16 at device 0.0 on pci3 msk0: on mskc0 msk0: Ethernet address: 00:1b:fc:e3:9b:6a miibus0: on msk0 e1000phy0: PHY 0 on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto mskc0: [FILTER] mskc0@pci0:3:0:0: class=0x020000 card=0x826e1043 chip=0x436411ab rev=0x12 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' class = network subclass = ethernet msk0: flags=8843 metric 0 mtu 1500 options=11a ether 00:1b:fc:xx:xx:xx inet 192.168.xxx.xxx netmask 0xffffff00 broadcast 192.168.xxx.255 media: Ethernet autoselect (1000baseT ) status: active Now - this machine still had 7.x /etc/rc.d, but since ifconfig down/up fixed the problem I don't know if this is a likely suspect. My onsite contact is unavailable right now, but if she gets back I will reboot the machine with the mergemaster'd rc.d to see if it's reproducible. The machine is a dual core 64-bit running i386 SMP kernel with 4G memory and a few ACPI problems: ACPI APIC Table: ACPI Warning: \\_SB_.PCI0.SBRG.FDC_._FDE: Return type mismatch - found Package, expected Buffer 20090521 nspredef-1051 ACPI Warning: Incorrect checksum in table [OEMB] - 4E, should be 43 20090521 tbutils-275 With release around the door, I figured I'd get this out there, at the risk of posting a red herring. -- Mel From olivier at gid0.org Wed Nov 11 22:16:12 2009 From: olivier at gid0.org (Olivier Smedts) Date: Wed Nov 11 22:16:19 2009 Subject: Possible regression with msk driver In-Reply-To: <200911112311.51709.mel.flynn+fbsd.current@mailing.thruhere.net> References: <200911112311.51709.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <367b2c980911111416i152abdb9hb251c55697d64ea1@mail.gmail.com> 2009/11/11 Mel Flynn : > Hi, > > I just booted a box from 7.2-p4 to FreeBSD 8.0-PRERELEASE #0 r199185. It > didn't ping, even though the interface was marked up and active. No traffic at > all. Sometimes I've got the same problem, unplugging and plugging the network cable "solves" the problem. I didn't try to diagnose it but it didn't happen with 7-STABLE. > > The fix was to ifconfig msk0 down; ifconfig msk0 up. From then on, everything > worked and still is: > mskc0: port 0xe800-0xe8ff mem > 0xf9efc000-0xf9efffff irq 16 at device 0.0 on pci3 > msk0: on mskc0 > msk0: Ethernet address: 00:1b:fc:e3:9b:6a > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: ?10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > mskc0: [FILTER] > > mskc0@pci0:3:0:0: ? ? ? class=0x020000 card=0x826e1043 chip=0x436411ab > rev=0x12 hdr=0x00 > ? ?vendor ? ? = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > ? ?device ? ? = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' > ? ?class ? ? ?= network > ? ?subclass ? = ethernet > > msk0: flags=8843 metric 0 mtu 1500 > ? ? ? ?options=11a > ? ? ? ?ether 00:1b:fc:xx:xx:xx > ? ? ? ?inet 192.168.xxx.xxx netmask 0xffffff00 broadcast 192.168.xxx.255 > ? ? ? ?media: Ethernet autoselect (1000baseT ) > ? ? ? ?status: active > > Now - this machine still had 7.x /etc/rc.d, but since ifconfig down/up fixed > the problem I don't know if this is a likely suspect. > > My onsite contact is unavailable right now, but if she gets back I will reboot > the machine with the mergemaster'd rc.d to see if it's reproducible. > The machine is a dual core 64-bit running i386 SMP kernel with 4G memory and a > few ACPI problems: > ACPI APIC Table: > ACPI Warning: \\_SB_.PCI0.SBRG.FDC_._FDE: Return type mismatch - found > Package, expected Buffer 20090521 nspredef-1051 > ACPI Warning: Incorrect checksum in table [OEMB] - 4E, should be 43 20090521 > tbutils-275 > > With release around the door, I figured I'd get this out there, at the risk of > posting ?a red herring. > -- > Mel > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From jfvogel at gmail.com Wed Nov 11 22:19:25 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Wed Nov 11 22:19:33 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <20091111203101.GC15449@michelle.cdnetworks.com> References: <20091017222314.GB19204@michelle.cdnetworks.com> <200911092215.nA9MFeDP013898@lava.sentex.ca> <2a41acea0911091459w2b4fec5djd64d0324557b7da2@mail.gmail.com> <200911100021.nAA0LvMG014534@lava.sentex.ca> <2a41acea0911091633u2899b47ewb514b6276ba2cf62@mail.gmail.com> <200911100227.nAA2RtDY015177@lava.sentex.ca> <2a41acea0911101057q4f913e30m9319e52bbd254cfe@mail.gmail.com> <2a41acea0911101120o39fd695cpa325736d00b11587@mail.gmail.com> <200911102018.nAAKI3s7021614@lava.sentex.ca> <20091111203101.GC15449@michelle.cdnetworks.com> Message-ID: <2a41acea0911111419v5ae5682cy12613e1bd9a9c325@mail.gmail.com> On Wed, Nov 11, 2009 at 12:31 PM, Pyun YongHyeon wrote: > On Tue, Nov 10, 2009 at 03:18:09PM -0500, Mike Tancsa wrote: > > At 02:20 PM 11/10/2009, Jack Vogel wrote: > > >This is a fix for this problem, please apply and test this. > > > > Hi, > > Thanks! Yes, I am able to use both ports of the NIC now and > > no panics yet. Prior to this patch, bringing up both ports resulted > > in a non functioning NIC and panic! Generating some UDP and tcp > > traffic through the box, all seems to be OK on first blush. > > > > I think this is a separate issue. Jack's patch surely reduce the > number of chance of bus_dmamap_load_mbuf_sg(9) failure because it > removed unnecessary DMA alignment restriction but once it happen > you would get the same result. Note, original poster's machine is > amd64. > > Ya, so maybe a more robust solution to that failure would be a good thing, but this is not the time for more elaborate code, having this small fix put in is low risk and the better failure response can come later. In fact, I have a number of places in the ixgbe driver where I'm pondering over what to do in failure mode anyway. Jack > > I will try some more extensive tests over the next little while. > > > > igb0: Excessive collisions = 0 > > igb0: Sequence errors = 0 > > igb0: Defer count = 0 > > igb0: Missed Packets = 0 > > igb0: Receive No Buffers = 40 > > igb0: Receive Length Errors = 0 > > igb0: Receive errors = 2 > > igb0: Crc errors = 4 > > igb0: Alignment errors = 0 > > igb0: Collision/Carrier extension errors = 0 > > igb0: RX overruns = 0 > > igb0: watchdog timeouts = 0 > > igb0: XON Rcvd = 0 > > igb0: XON Xmtd = 0 > > igb0: XOFF Rcvd = 0 > > igb0: XOFF Xmtd = 0 > > igb0: Good Packets Rcvd = 103212774 > > igb0: Good Packets Xmtd = 9347339 > > igb0: TSO Contexts Xmtd = 0 > > igb0: TSO Contexts Failed = 0 > > igb1: Excessive collisions = 0 > > igb1: Sequence errors = 0 > > igb1: Defer count = 0 > > igb1: Missed Packets = 0 > > igb1: Receive No Buffers = 0 > > igb1: Receive Length Errors = 0 > > igb1: Receive errors = 0 > > igb1: Crc errors = 0 > > igb1: Alignment errors = 0 > > igb1: Collision/Carrier extension errors = 0 > > igb1: RX overruns = 0 > > igb1: watchdog timeouts = 0 > > igb1: XON Rcvd = 0 > > igb1: XON Xmtd = 0 > > igb1: XOFF Rcvd = 0 > > igb1: XOFF Xmtd = 0 > > igb1: Good Packets Rcvd = 9365642 > > igb1: Good Packets Xmtd = 17781877 > > igb1: TSO Contexts Xmtd = 988 > > igb1: TSO Contexts Failed = 0 > > > > > > > > # ./netsend 10.255.255.3 600 300 280000 10 > > Sending packet of payload size 300 every 0.000003571s for 10 seconds > > > > start: 1257884127.000000000 > > finish: 1257884137.000003339 > > send calls: 2800336 > > send errors: 1970 > > approx send rate: 279836 > > approx error rate: 0 > > waited: 1259257 > > approx waits/sec: 125925 > > approx wait rate: 0 > > # traceroute 10.255.255.3 > > traceroute to 10.255.255.3 (10.255.255.3), 64 hops max, 40 byte packets > > 1 1.1.1.1 (1.1.1.1) 0.096 ms 0.073 ms 0.115 ms > > 2 10.255.255.3 (10.255.255.3) 67.953 ms 0.297 ms 0.241 ms > > > > The box with the igb nics has the interfaces 1.1.1.1 and 10.255.255.1 > > > > ---Mike > > > > > > >Jack > > > > > >------- if_igb.c (revision 197079) > > >+++ if_igb.c (working copy) > > >@@ -2654,7 +2654,7 @@ > > > int error; > > > > > > error = bus_dma_tag_create(bus_get_dma_tag(adapter->dev), /* parent > */ > > >- IGB_DBA_ALIGN, 0, /* alignment, bounds */ > > >+ 1, 0, /* alignment, bounds */ > > > BUS_SPACE_MAXADDR, /* lowaddr */ > > > BUS_SPACE_MAXADDR, /* highaddr */ > > > NULL, NULL, /* filter, filterarg */ > > >@@ -2867,7 +2867,7 @@ > > > * Setup DMA descriptor areas. > > > */ > > > if ((error = bus_dma_tag_create(NULL, /* parent */ > > >- PAGE_SIZE, 0, /* alignment, bounds */ > > >+ 1, 0, /* alignment, bounds */ > > > BUS_SPACE_MAXADDR, /* lowaddr */ > > > BUS_SPACE_MAXADDR, /* highaddr */ > > > NULL, NULL, /* filter, filterarg */ > > >@@ -3554,7 +3554,7 @@ > > > ** it may not always use this. > > > */ > > > if ((error = bus_dma_tag_create(NULL, /* parent */ > > >- PAGE_SIZE, 0, /* alignment, bounds */ > > >+ 1, 0, /* alignment, bounds */ > > > BUS_SPACE_MAXADDR, /* lowaddr */ > > > BUS_SPACE_MAXADDR, /* highaddr */ > > > NULL, NULL, /* filter, filterarg */ > > > > > > > > > > > >On Tue, Nov 10, 2009 at 10:57 AM, Jack Vogel > > ><jfvogel@gmail.com> wrote: > > >I have repro'd this failure this morning and think I have a fix for > > >it, I am testing that soon. > > > > > >Stay tuned, > > > > > >Jack > > > > > > > > > > > >On Mon, Nov 9, 2009 at 6:28 PM, Mike Tancsa > > ><mike@sentex.net> wrote: > > >At 07:33 PM 11/9/2009, Jack Vogel wrote: > > >Some reason you aren't using amd64? I will have a system installed that > way > > >and see if I can repro it then, thanks. > > > > > > > > > > > >I had found in the past i386 was faster for firewall and routing > > >applications. Perhaps thats different now, I will give it a try > > >again to see if there is any difference. > > > > > >pciconf and dmesg attached. > > > > > > ---Mike > > > > > > > > > > > >Jack > > > > > > > > > > > >On Mon, Nov 9, 2009 at 4:22 PM, Mike Tancsa > > ><mike@sentex.net> wrote: > > >At 05:59 PM 11/9/2009, Jack Vogel wrote: > > >Are you using standard MTU or jumbo? That get_buf error is ENOMEM, looks > > >like > > >that happens when in the bus_dma stuff reserve_bounce_pages() fails. > > > > > >Are you maybe using a 32 bit kernel? I have not seen this failure here. > > > > > > > > >Hi Jack, > > > Standard MTU and i386 > > > > > > ---Mike > > > > > > > > > > > >-------------------------------------------------------------------- > > >Mike Tancsa, tel +1 519 651 3400 > > >Sentex Communications, mike@sentex.net > > >Providing Internet since > > >1994 > > ><http://www.sentex.net>www.sentex.net > > >Cambridge, Ontario > > >Canada > > ><http://www.sentex.net/mike> > www.sentex.net/mike > > > > > > > > >-------------------------------------------------------------------- > > >Mike Tancsa, tel +1 519 651 3400 > > >Sentex > > >Communications, > > >mike@sentex.net > > >Providing Internet since > > >1994 www.sentex.net > > >Cambridge, Ontario > > >Canada > > >www.sentex.net/mike > > > > > > > > > > -------------------------------------------------------------------- > > Mike Tancsa, tel +1 519 651 3400 > > Sentex Communications, mike@sentex.net > > Providing Internet since 1994 www.sentex.net > > Cambridge, Ontario Canada www.sentex.net/mike > > > From jpiccari at bblocked.org Wed Nov 11 20:17:26 2009 From: jpiccari at bblocked.org (Joshua Piccari) Date: Wed Nov 11 22:24:45 2009 Subject: Wondering how stable x86emu? In-Reply-To: <4AFAFECD.5020306@delphij.net> References: <15d3bc360911110926m4811574bmaea5e42879340d64@mail.gmail.com> <4AFAFECD.5020306@delphij.net> Message-ID: <15d3bc360911111217p1bc38284md731e3ff89364798@mail.gmail.com> On Wed, Nov 11, 2009 at 10:13 AM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Joshua Piccari wrote: >> Hi all, >> >> Hi all I'm wondering if anybody can comment on when we can expect to >> see x86emu come to a branch other than -CURRENT? Or if anyone has a >> patch for x86emu that would work (even slightly) with 8.0-RC2? I guess >> if nothing else it would be nice to know what files are involved so I >> can make a patch for RC2. >> >> Anyways, any info would be greatly appreciated since I've been waiting >> for something like this for a long time. Great work, and really >> looking forward to it. :D > > I'm not sure what are you referring to... ?It worked just fine for i.e. > VESA stuff on amd64, but I think it's too late for 8.0 since it has been > introduced too late. ?However, it would be a good target for 8.1 I > guess, there are some rough edges but so far it works just fine for me. Yeah, I realized that it probably wouldn't make it to 8.0 but I was wondering if anybody has an unofficial patch that can be used in the meantime. The reason I ask is before it was committed it was a patch for 8.0-BETA3 floating around on the forums. It seems that the patch has been removed since it was committed but I'd hoped someone out there still had it so I could use it with 8.0-RC2. -- Joshua A Piccari /dv/ From pyunyh at gmail.com Wed Nov 11 22:25:54 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Nov 11 22:26:02 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <2a41acea0911111419v5ae5682cy12613e1bd9a9c325@mail.gmail.com> References: <200911092215.nA9MFeDP013898@lava.sentex.ca> <2a41acea0911091459w2b4fec5djd64d0324557b7da2@mail.gmail.com> <200911100021.nAA0LvMG014534@lava.sentex.ca> <2a41acea0911091633u2899b47ewb514b6276ba2cf62@mail.gmail.com> <200911100227.nAA2RtDY015177@lava.sentex.ca> <2a41acea0911101057q4f913e30m9319e52bbd254cfe@mail.gmail.com> <2a41acea0911101120o39fd695cpa325736d00b11587@mail.gmail.com> <200911102018.nAAKI3s7021614@lava.sentex.ca> <20091111203101.GC15449@michelle.cdnetworks.com> <2a41acea0911111419v5ae5682cy12613e1bd9a9c325@mail.gmail.com> Message-ID: <20091111222520.GD15449@michelle.cdnetworks.com> On Wed, Nov 11, 2009 at 02:19:21PM -0800, Jack Vogel wrote: > On Wed, Nov 11, 2009 at 12:31 PM, Pyun YongHyeon wrote: > > > On Tue, Nov 10, 2009 at 03:18:09PM -0500, Mike Tancsa wrote: > > > At 02:20 PM 11/10/2009, Jack Vogel wrote: > > > >This is a fix for this problem, please apply and test this. > > > > > > Hi, > > > Thanks! Yes, I am able to use both ports of the NIC now and > > > no panics yet. Prior to this patch, bringing up both ports resulted > > > in a non functioning NIC and panic! Generating some UDP and tcp > > > traffic through the box, all seems to be OK on first blush. > > > > > > > I think this is a separate issue. Jack's patch surely reduce the > > number of chance of bus_dmamap_load_mbuf_sg(9) failure because it > > removed unnecessary DMA alignment restriction but once it happen > > you would get the same result. Note, original poster's machine is > > amd64. > > > > Ya, so maybe a more robust solution to that failure would be a good > thing, but this is not the time for more elaborate code, having this small > fix put in is low risk and the better failure response can come later. > Agreed. :-) > In fact, I have a number of places in the ixgbe driver where I'm pondering > over what to do in failure mode anyway. > That's great! > Jack > From wollman at bimajority.org Wed Nov 11 21:33:08 2009 From: wollman at bimajority.org (Garrett Wollman) Date: Wed Nov 11 22:30:49 2009 Subject: Message-ID: <19195.11666.854785.64042@hergotha.csail.mit.edu> Why is __assert() in not declared as non-returning (__dead2)? -GAWollman From pyunyh at gmail.com Wed Nov 11 22:38:24 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Nov 11 22:38:32 2009 Subject: Call for bge(4) testers Message-ID: <20091111223751.GE15449@michelle.cdnetworks.com> Hi, I had been working on fixing bus_dma(9) bugs and adding TSO capability to bge(4). Now TSO is supported for BCM5755 or newer controllers. Actually some pre-BCM5755 controllers also support TSO with the help of special firmware but the license issue and lower performance of firmware based TSO as well as TSO bug I intentionally excluded TSO support for pre-BCM5755 controllers. You can get the patch form the following URL. The diff was generated against latest HEAD. http://people.freebsd.org/~yongari/bge/bge.tso.1111.diff or http://people.freebsd.org/~yongari/bge/if_bge.c http://people.freebsd.org/~yongari/bge/if_bgereg.h The diff also has a lot of functional changes which may affect other bge(4) controllers. Specifically the diff - Added workarounds for known DMA bug. This workaround shall make bge(4) use bounce buffers so this fix requires all previous changes made in HEAD. This may slow down overall performance if bounce buffers are used but I think it's better than leaving the bug. - Tuned interrupt coalescing parameters. - Use taskqeue to get better performance on PCIe controllers. - TSO support for BCM5755 or newer controllers. - Tx path cleaned up. - Interrupt handler now clears status word as it does in polling case. I'm interesting in performance changes before/after the diff and any regressions from the diff. Please test I'll commit the diff next week unless I get regressions. Thanks. From delphij at delphij.net Wed Nov 11 22:59:05 2009 From: delphij at delphij.net (Xin LI) Date: Wed Nov 11 22:59:12 2009 Subject: Wondering how stable x86emu? In-Reply-To: <15d3bc360911111217p1bc38284md731e3ff89364798@mail.gmail.com> References: <15d3bc360911110926m4811574bmaea5e42879340d64@mail.gmail.com> <4AFAFECD.5020306@delphij.net> <15d3bc360911111217p1bc38284md731e3ff89364798@mail.gmail.com> Message-ID: <4AFB41AA.8090701@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joshua Piccari wrote: > On Wed, Nov 11, 2009 at 10:13 AM, Xin LI wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Joshua Piccari wrote: >>> Hi all, >>> >>> Hi all I'm wondering if anybody can comment on when we can expect to >>> see x86emu come to a branch other than -CURRENT? Or if anyone has a >>> patch for x86emu that would work (even slightly) with 8.0-RC2? I guess >>> if nothing else it would be nice to know what files are involved so I >>> can make a patch for RC2. >>> >>> Anyways, any info would be greatly appreciated since I've been waiting >>> for something like this for a long time. Great work, and really >>> looking forward to it. :D >> I'm not sure what are you referring to... It worked just fine for i.e. >> VESA stuff on amd64, but I think it's too late for 8.0 since it has been >> introduced too late. However, it would be a good target for 8.1 I >> guess, there are some rough edges but so far it works just fine for me. > > Yeah, I realized that it probably wouldn't make it to 8.0 but I was > wondering if anybody has an unofficial patch that can be used in the > meantime. > > The reason I ask is before it was committed it was a patch for > 8.0-BETA3 floating around on the forums. It seems that the patch has > been removed since it was committed but I'd hoped someone out there > still had it so I could use it with 8.0-RC2. I see. There are some recent improvements on -HEAD that we feel that will need some "settle" before putting it through for an MFC patchset. If you have interest, you can actually try manually fetching the -HEAD version of sys/contrib/x86emu, as well as the files committed by jkim@ and I (mainly dev/fb, dev/dpms, i386/isa and modules/x86bios, modules/vesa, modules/dpms, etc). Files in conf/ would require some manual work but these would be trivial. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkr7QakACgkQi+vbBBjt66CuQQCeOz11p3Uj84bkaOFiJ7y4w/lm 8sgAnRLz3+0DRdLHuPSP9ZABlEYDezTO =vCLT -----END PGP SIGNATURE----- From pyunyh at gmail.com Wed Nov 11 23:15:03 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Wed Nov 11 23:15:09 2009 Subject: Possible regression with msk driver In-Reply-To: <200911112311.51709.mel.flynn+fbsd.current@mailing.thruhere.net> References: <200911112311.51709.mel.flynn+fbsd.current@mailing.thruhere.net> Message-ID: <20091111231426.GF15449@michelle.cdnetworks.com> On Wed, Nov 11, 2009 at 11:11:51PM +0100, Mel Flynn wrote: > Hi, > > I just booted a box from 7.2-p4 to FreeBSD 8.0-PRERELEASE #0 r199185. It > didn't ping, even though the interface was marked up and active. No traffic at > all. > > The fix was to ifconfig msk0 down; ifconfig msk0 up. From then on, everything > worked and still is: > mskc0: port 0xe800-0xe8ff mem > 0xf9efc000-0xf9efffff irq 16 at device 0.0 on pci3 > msk0: on mskc0 > msk0: Ethernet address: 00:1b:fc:e3:9b:6a > miibus0: on msk0 > e1000phy0: PHY 0 on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-FDX, auto > mskc0: [FILTER] > > mskc0@pci0:3:0:0: class=0x020000 card=0x826e1043 chip=0x436411ab > rev=0x12 hdr=0x00 > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = 'Yukon PCI-E Gigabit Ethernet Controller (88E8056)' > class = network > subclass = ethernet > > msk0: flags=8843 metric 0 mtu 1500 > options=11a > ether 00:1b:fc:xx:xx:xx > inet 192.168.xxx.xxx netmask 0xffffff00 broadcast 192.168.xxx.255 > media: Ethernet autoselect (1000baseT ) > status: active > > Now - this machine still had 7.x /etc/rc.d, but since ifconfig down/up fixed > the problem I don't know if this is a likely suspect. > Most likely it lost link state changes so I guess msk(4) still think it has no established link. Because there had been several problems with EC Ultra + 88E1149 I'm not sure it's newly introduced regression though. There are some changes in CURRENT. Would you try latest msk(4)/e1000phy(4) in CURRENT? I think you can download the following files from CURRENT. sys/dev/msk/if_msk.c sys/dev/msk/if_mskreg.h sys/dev/mii/e1000phy.c sys/dev/mii/e1000phyreg.h If that does not work I'll send you a possible patch. > My onsite contact is unavailable right now, but if she gets back I will reboot > the machine with the mergemaster'd rc.d to see if it's reproducible. I don't think it's related with rc.d scripts. > The machine is a dual core 64-bit running i386 SMP kernel with 4G memory and a > few ACPI problems: > ACPI APIC Table: > ACPI Warning: \\_SB_.PCI0.SBRG.FDC_._FDE: Return type mismatch - found > Package, expected Buffer 20090521 nspredef-1051 > ACPI Warning: Incorrect checksum in table [OEMB] - 4E, should be 43 20090521 > tbutils-275 > > With release around the door, I figured I'd get this out there, at the risk of > posting a red herring. > -- > Mel From dnelson at allantgroup.com Wed Nov 11 23:26:29 2009 From: dnelson at allantgroup.com (Dan Nelson) Date: Wed Nov 11 23:26:36 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> Message-ID: <20091111232627.GK89052@dan.emsphone.com> In the last episode (Nov 11), Sam Fourman Jr. said: > On Wed, Nov 11, 2009 at 2:49 PM, Dan Nelson wrote: > > In the last episode (Nov 11), Ivan Voras said: > >> Sam Fourman Jr. wrote: > >> > I am running FreeBSD 8.0RC2 and I dont understand why my ZFS/NFS is > >> > acting weird on writes. ?I get ~150mbit writes idk if this is good > >> > or not? ?but it paused for a few seconds every once and awhile. > >> > >> You didn't give any "iostat" statistics - I suspect that if you > >> correlate ifstat and iostat output that you will see that network > >> "pauses" happen during spikes in IO. You should check for this and > >> post your results. > > > > Yes, iostat would be useful here. ?"iostat -zxC 2" will give you > > per-disk stats plus CPU usage every 2 seconds (CPU may be a factor if > > you have compression enabled). > > > > On a Solaris box I admin, setting zfs_write_limit_override helped > > stuttering while doing heavy writes. ?It's not exported on FreeBSD, but > > it should be easy to add it as a RW sysctl; it lives in dsl_pool.c and > > can be tweaked at runtime. ?Start big and tune it down so each write > > burst takes under a second; it looks like you're writing solid for > > around 6-8 seconds now. ?The number will vary depending on your disk > > speed and how much ARC you have. > > here are some iostats for you. I do not believe I have compression enabled > am I mistaken? isn'y SATA2 300MB/s? and I am doing ~6MB/s per disk? I > built this machine with 4GB of memory because I thought ZFS would like it. > now maybe a re(4) interface isnt the best choice. if that is the problem > here I can change it. We spent ~$800 on a hardware RAID card thinking > that it would help performance > > Why is it that with sftp we do not see the pauses in Network transfer? Your service times below are worrying (both for the NFS and sftp cases); anything above 50ms for a sustained period is usually a problem. You mention hardware RAID, but I see 6 da# devices; are these just hooked up in passthrough mode, or is each da device backed by multiple SATA disks? What kind of write caching do you have enabled on the RAID? Can you disable it? It sort of looks like zfs is bursting more data to disk than the RAID card has RAM for, and it's spending multiple seconds just trying to recover. It's also odd that you're seeing queue depths up to 70 on those disks when zfs by default should only do 35 (sysctl vfs.zfs.vdev.max_pending). NFS has data consistency guarantees that require it to flush to disk more often than your sftp connection, so that may explain why the disk behaviour is different. > # iostat -zxC 1 (with NFS and ZFS) [...] > extended device statistics cpu > device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id > da0 0.0 104.8 0.0 6057.3 67 624.9 100 0 0 1 1 98 > da1 0.0 104.8 0.0 6057.3 63 531.2 100 > da2 0.0 104.8 0.0 6057.3 68 625.4 100 > da3 0.0 104.8 0.0 6032.3 63 551.6 100 > da4 0.0 104.8 0.0 6057.3 68 625.7 100 > da5 0.0 105.8 0.0 6121.1 61 510.1 101 > extended device statistics cpu > device r/s w/s kr/s kw/s wait svc_t %b us ni sy in id > da0 0.0 106.8 0.0 6160.2 68 616.8 100 0 0 2 1 97 > da1 0.0 106.8 0.0 6160.2 62 522.8 100 > da2 0.0 106.8 0.0 6160.2 67 617.1 100 > da3 0.0 106.8 0.0 6185.1 62 522.8 100 > da4 0.0 106.8 0.0 6160.2 67 617.4 100 > da5 0.0 106.8 0.0 6160.2 62 503.4 100 -- Dan Nelson dnelson@allantgroup.com From emikulic at gmail.com Wed Nov 11 23:34:10 2009 From: emikulic at gmail.com (Emil Mikulic) Date: Wed Nov 11 23:34:16 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: References: <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> Message-ID: <20091111231753.GA52833@dmr.ath.cx> On Tue, Nov 10, 2009 at 09:15:42AM -0800, Mark Atkinson wrote: > Also, you can try adding: > > hw.mca.enabled="1" in /boot/loader.conf This is a little off-topic, but: Why is this disabled by default in FreeBSD? From sfourman at gmail.com Wed Nov 11 23:44:52 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Wed Nov 11 23:44:59 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <20091111232627.GK89052@dan.emsphone.com> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <20091111232627.GK89052@dan.emsphone.com> Message-ID: <11167f520911111544n2960fbe3w94e58452a95737f9@mail.gmail.com> On Wed, Nov 11, 2009 at 5:26 PM, Dan Nelson wrote: > In the last episode (Nov 11), Sam Fourman Jr. said: >> On Wed, Nov 11, 2009 at 2:49 PM, Dan Nelson wrote: >> > In the last episode (Nov 11), Ivan Voras said: >> >> Sam Fourman Jr. wrote: >> >> > I am running FreeBSD 8.0RC2 and I dont understand why my ZFS/NFS is >> >> > acting weird on writes. ??I get ~150mbit writes idk if this is good >> >> > or not? ??but it paused for a few seconds every once and awhile. >> >> >> >> You didn't give any "iostat" statistics - I suspect that if you >> >> correlate ifstat and iostat output that you will see that network >> >> "pauses" happen during spikes in IO. ?You should check for this and >> >> post your results. >> > >> > Yes, iostat would be useful here. ?"iostat -zxC 2" will give you >> > per-disk stats plus CPU usage every 2 seconds (CPU may be a factor if >> > you have compression enabled). >> > >> > On a Solaris box I admin, setting zfs_write_limit_override helped >> > stuttering while doing heavy writes. ??It's not exported on FreeBSD, but >> > it should be easy to add it as a RW sysctl; it lives in dsl_pool.c and >> > can be tweaked at runtime. ??Start big and tune it down so each write >> > burst takes under a second; it looks like you're writing solid for >> > around 6-8 seconds now. ??The number will vary depending on your disk >> > speed and how much ARC you have. >> >> here are some iostats for you. I do not believe I have compression enabled >> am I mistaken? ?isn'y SATA2 300MB/s? ?and I am doing ~6MB/s per disk? ?I >> built this machine with 4GB of memory because I thought ZFS would like it. >> now maybe a re(4) interface isnt the best choice. ?if that is the problem >> here I can change it. ?We spent ~$800 on a hardware RAID card thinking >> that it would help performance >> >> Why is it that with sftp we do not see the pauses in Network transfer? > > Your service times below are worrying (both for the NFS and sftp cases); > anything above 50ms for a sustained period is usually a problem. ?You > mention hardware RAID, but I see 6 da# devices; are these just hooked up in > passthrough mode, or is each da device backed by multiple SATA disks? ?What > kind of write caching do you have enabled on the RAID? ?Can you disable it? > It sort of looks like zfs is bursting more data to disk than the RAID card > has RAM for, and it's spending multiple seconds just trying to recover. > It's also odd that you're seeing queue depths up to 70 on those disks when > zfs by default should only do 35 (sysctl vfs.zfs.vdev.max_pending). > > NFS has data consistency guarantees that require it to flush to disk more > often than your sftp connection, so that may explain why the disk behaviour > is different. > here is some sysctl output (i believe my max pending is 35) # sysctl vfs.zfs vfs.zfs.arc_meta_limit: 67108864 vfs.zfs.arc_meta_used: 26956528 vfs.zfs.mdcomp_disable: 0 vfs.zfs.arc_min: 33554432 vfs.zfs.arc_max: 268435456 vfs.zfs.zfetch.array_rd_sz: 1048576 vfs.zfs.zfetch.block_cap: 256 vfs.zfs.zfetch.min_sec_reap: 2 vfs.zfs.zfetch.max_streams: 8 vfs.zfs.prefetch_disable: 1 vfs.zfs.recover: 0 vfs.zfs.txg.synctime: 5 vfs.zfs.txg.timeout: 30 vfs.zfs.scrub_limit: 10 vfs.zfs.vdev.cache.bshift: 16 vfs.zfs.vdev.cache.size: 10485760 vfs.zfs.vdev.cache.max: 16384 vfs.zfs.vdev.aggregation_limit: 131072 vfs.zfs.vdev.ramp_rate: 2 vfs.zfs.vdev.time_shift: 6 vfs.zfs.vdev.min_pending: 4 vfs.zfs.vdev.max_pending: 35 vfs.zfs.cache_flush_disable: 0 vfs.zfs.zil_disable: 0 vfs.zfs.version.zpl: 3 vfs.zfs.version.vdev_boot: 1 vfs.zfs.version.spa: 13 vfs.zfs.version.dmu_backup_stream: 1 vfs.zfs.version.dmu_backup_header: 2 vfs.zfs.version.acl: 1 vfs.zfs.debug: 0 vfs.zfs.super_owner: 0 I am using this ARECA ARC-1130 in JBOD Mode We have write cache disabled on the controller. arcmsr0: mem 0xfebff000-0xfebfffff,0xfdc00000-0xfdffffff irq 22 at device 14.0 on pci4 ARECA RAID ADAPTER0: Driver Version 1.20.00.16 2009-10-10 ARECA RAID ADAPTER0: FIRMWARE VERSION V1.47 2009-06-25 arcmsr0: [ITHREAD] The motherboard in this machine is Asus M4A785-M http://usa.asus.com/product.aspx?P_ID=ef0qgvMIwOUagAVl&templete=2 if my hardware setup is the trouble, do I just need to start from scratch and select and build a better machine? in the end I was looking to get the fastest writes I can. I am just confused on where I went wrong with this machine. Sam Fourman Jr. From des at des.no Wed Nov 11 23:49:57 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Nov 11 23:50:04 2009 Subject: How to confuse geom_part_mbr Message-ID: <86tyx0mxjw.fsf@ds4.des.no> While installing 8.0-RC2 via a netbooted 7.0-RELEASE: # fdisk -I -B ad0 # bsdlabel -rw ad0 auto # bsdlabel -e ad0 [hmm, that wasn't right!] # fdisk -I -B ad0 # bsdlabel -rw ad0s1 auto # bsdlabel -e ad0s1 # bsdlabel -B ad0s1a # newfs -U -L root ad0s1a # mount /dev/ufs/root /mnt [install to /mnt] # reboot The machine won't boot, even though you have a valid partition table on ad0 that points to a valid bsdlabel in ad0s1. The only way to fix it is to zero the first few sectors of ad0 and re-run fdisk. (yes, I know I should update my nfsroot) DES -- Dag-Erling Sm?rgrav - des@des.no From wblock at wonkity.com Wed Nov 11 23:54:42 2009 From: wblock at wonkity.com (Warren Block) Date: Wed Nov 11 23:54:50 2009 Subject: /etc/rc.d locking devd.pid (was Re: Restarting devd) In-Reply-To: References: <20091018220935.GR2160@deviant.kiev.zoral.com.ua> Message-ID: On Sun, 18 Oct 2009, Warren Block wrote: > On Mon, 19 Oct 2009, Kostik Belousov wrote: >>> >>> ...and this is due to dhclient, run from /etc/rc.d at startup, locking >>> /var/run/devd.pid: >>> >>> lightning% lsof /var/run/devd.pid >>> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >>> devd 400 root 6w VREG 0,101 3 47124 /var/run/devd.pid >>> dhclient 865 root 6w VREG 0,101 3 47124 /var/run/devd.pid >>> dhclient 1024 _dhcp 6w VREG 0,101 3 47124 /var/run/devd.pid >>> >>> This is a regression from 7-STABLE, where devd.pid is only locked by >>> devd after startup. >> >> Devd forks to spawn dhclient, it seems, and opened file descriptor for >> the lock file is leaking to the child. Since pidfile(3) uses flock(2), >> the lock survives devd death. >> >> I think that this is a generic issue with pidfile/fork interaction. >> It is not obvious whether setting FD_CLOEXEC flag is right thing to >> do there. (And that didn't fix it, but information included for completeness.) I've entered PR bin/140462 for this. -Warren Block * Rapid City, South Dakota USA From eculp at encontacto.net Wed Nov 11 23:59:41 2009 From: eculp at encontacto.net (eculp) Date: Wed Nov 11 23:59:48 2009 Subject: Epson MFP CX5600 was Re: usb2 + scanner HP ScanJet 4300C Message-ID: <20091111175935.19402q31p6gbp1q8@econet.encontacto.net> Based on the Luigi's link included in an almost year old email to these lists, I purchased an Epson CX5600 with all intentions of using the scanner but never seemed to get around to configuring it. Many things have happened since then including new USB, etc. etc. The printer still works fine using cups. I have just tried to configure the scanner without luck. A device isn't created in /dev and only the printer is recognized on boot: Nov 11 17:24:51 ed kernel: uhub0: 5 ports with 5 removable, self powered Nov 11 17:24:51 ed kernel: uhub2: 5 ports with 5 removable, self powered Nov 11 17:24:51 ed kernel: GEOM: ad4s2: geometry does not match label (255h,63s != 16h,63s). Nov 11 17:24:51 ed kernel: GEOM: ad4s3: geometry does not match label (255h,63s != 16h,63s). Nov 11 17:24:51 ed kernel: uhub1: 5 ports with 5 removable, self powered Nov 11 17:24:51 ed kernel: uhub3: 5 ports with 5 removable, self powered Nov 11 17:24:51 ed kernel: ugen1.2: at usbus1 Nov 11 17:24:51 ed kernel: ugen2.2: at usbus2 Nov 11 17:24:51 ed kernel: ulpt0: on usbus2 Nov 11 17:24:51 ed kernel: ulpt0: using bi-directional mode I installed: drwxr-xr-x 2 root wheel 512 Nov 11 16:27 sane-backends-1.0.20_4 drwxr-xr-x 2 root wheel 512 Nov 11 16:41 sane-frontends-1.0.14_5 drwxr-xr-x 2 root wheel 512 Nov 11 16:47 xsane-0.996_1 added entries in usbdevs and devd.conf. I don't really know where to go from here. I haven't configured a scanner for freebsd in years and am totally lost. It isn't really that important but it would certainly be handy. I am running up to date Current: FreeBSD ed.local.net.mx 9.0-CURRENT FreeBSD 9.0-CURRENT #360: Wed Nov 11 06:55:25 CST 2009 root@ed.local.net.mx:/usr/obj/usr/src/sys/ENCONTACTO i386 That could be part of the problem. Thanks, ed P.S. Luigi thanks for the great tutoral. I'm pretty sure the problems are from the changes made in current this year. ----- Forwarded message from rizzo@iet.unipi.it ----- Date: Fri, 12 Dec 2008 23:04:28 +0100 From: Luigi Rizzo Subject: Re: usb2 + scanner HP ScanJet 4300C To: Oliver Fromme Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org On Fri, Dec 12, 2008 at 09:27:27PM +0100, Oliver Fromme wrote: > Hi, > > I've got a HP ScanJet 4300C that seems to be a little bit > stubborn. > ... > Is there anything I can do, except for forgetting about > this scanner alltogether? one option is to put the device IDs in uscanner.c and see if it is recognised. But other than that, i wouldn't waste much time: for 50..80 euro you can get one of the Epson multifunction printer scanners (i have personally tried DX4400 to DX7050) which are well supported and extremely reliable. see http://info.iet.unipi.it/~luigi/FreeBSD/dx5050.html cheers luigi _______________________________________________ freebsd-usb@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-usb To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" ----- End forwarded message ----- From xcllnt at mac.com Thu Nov 12 01:00:39 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Nov 12 01:00:46 2009 Subject: How to confuse geom_part_mbr In-Reply-To: <86tyx0mxjw.fsf@ds4.des.no> References: <86tyx0mxjw.fsf@ds4.des.no> Message-ID: <94D5F246-3413-4256-A0FB-6DF2D3BFE9D0@mac.com> On Nov 11, 2009, at 3:49 PM, Dag-Erling Sm?rgrav wrote: > While installing 8.0-RC2 via a netbooted 7.0-RELEASE: > > # fdisk -I -B ad0 > # bsdlabel -rw ad0 auto > # bsdlabel -e ad0 > [hmm, that wasn't right!] > # fdisk -I -B ad0 > # bsdlabel -rw ad0s1 auto > # bsdlabel -e ad0s1 > # bsdlabel -B ad0s1a > # newfs -U -L root ad0s1a > # mount /dev/ufs/root /mnt > [install to /mnt] > # reboot > > The machine won't boot, even though you have a valid partition table on > ad0 that points to a valid bsdlabel in ad0s1. No, you don't have a valid partition table on ad0, because you didn't remove the BSD disklabel in sector 2 on ad0. You just overwrote sector 1 on ad0 and created a new BSD disklabel in sector 64. You still have a dangerously dedicated disk without partitions, by virtue of the BSD label in sector 2. -- Marcel Moolenaar xcllnt@mac.com From des at des.no Thu Nov 12 01:43:17 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Nov 12 01:43:38 2009 Subject: How to confuse geom_part_mbr In-Reply-To: <94D5F246-3413-4256-A0FB-6DF2D3BFE9D0@mac.com> (Marcel Moolenaar's message of "Wed, 11 Nov 2009 17:00:17 -0800") References: <86tyx0mxjw.fsf@ds4.des.no> <94D5F246-3413-4256-A0FB-6DF2D3BFE9D0@mac.com> Message-ID: <86d43omsb0.fsf@ds4.des.no> Marcel Moolenaar writes: > Dag-Erling Sm?rgrav writes: > > The machine won't boot, even though you have a valid partition table > > on ad0 that points to a valid bsdlabel in ad0s1. > No, you don't have a valid partition table on ad0, because > you didn't remove the BSD disklabel in sector 2 on ad0. Yes, I do have a valid partition table. It is exactly byte-by-byte identical to the one I get after I zero sector two and re-run fdisk. The fact that there is unwanted data in sector 2 does *not* make it any less valid. What's more, this could have easily been avoided if geom_whatever gave the partition table precedence over the label it found in sector 2. DES -- Dag-Erling Sm?rgrav - des@des.no From attilio at freebsd.org Thu Nov 12 01:46:19 2009 From: attilio at freebsd.org (Attilio Rao) Date: Thu Nov 12 01:46:26 2009 Subject: [PATCH] Adding sysctl for errors statistics to ahd(4) In-Reply-To: <4AFAEE89.3020009@scsiguy.com> References: <3bbf2fe10911060643g60079e31y7679b32dac670fd8@mail.gmail.com> <4AFAEE89.3020009@scsiguy.com> Message-ID: <3bbf2fe10911111746g48c8fb82r74744dffedf49758@mail.gmail.com> 2009/11/11 Justin T. Gibbs : > On 11/6/2009 7:43 AM, Attilio Rao wrote: >> This patch introduces some mechanisms for collecting informations on >> errors frequency and debugging (and relative sysctls for printing them >> out) for the ahd(4) driver: >> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/ahd/ahd-current2.diff >> >> The usage of array for sysctls is a bit too paranoid but it allows for >> further extendibility of the code and doesn't loose of cleaness. >> This code has been contributed back by Sandvine Incorporated with some >> cleanups. >> Please review. >> >> Thanks, >> Attilio > > In general, I think the patch is fine. It violates the existing style > of the driver in some places (e.g. the aic7xxx drivers wrap function > arguments to the opening '(' not to a 4 space indent), which should > probably be addressed so the code remains consistent. Sorry, I cannot find where these existing style breakage happens, could you be a bit more precise? (I just found an un-sorted header introduction in aic79xx.h that I will fix). Anyways, your idea about a generalized interface in newbus for handling that is not bad and as long as I'm planning some works in this area I can add this item to the TODO list. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From scottl at samsco.org Thu Nov 12 01:55:50 2009 From: scottl at samsco.org (Scott Long) Date: Thu Nov 12 01:55:57 2009 Subject: [PATCH] Adding sysctl for errors statistics to ahd(4) In-Reply-To: <3bbf2fe10911111746g48c8fb82r74744dffedf49758@mail.gmail.com> References: <3bbf2fe10911060643g60079e31y7679b32dac670fd8@mail.gmail.com> <4AFAEE89.3020009@scsiguy.com> <3bbf2fe10911111746g48c8fb82r74744dffedf49758@mail.gmail.com> Message-ID: I don't think that there was a specific mention of newbus. I actually sees storage stats being the domain of either CAM or GEOM, and far too specific for newbus. Scott Sent from my iPhone On Nov 11, 2009, at 6:46 PM, Attilio Rao wrote: > 2009/11/11 Justin T. Gibbs : >> On 11/6/2009 7:43 AM, Attilio Rao wrote: >>> This patch introduces some mechanisms for collecting informations on >>> errors frequency and debugging (and relative sysctls for printing >>> them >>> out) for the ahd(4) driver: >>> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/ahd/ahd-current2.diff >>> >>> The usage of array for sysctls is a bit too paranoid but it allows >>> for >>> further extendibility of the code and doesn't loose of cleaness. >>> This code has been contributed back by Sandvine Incorporated with >>> some >>> cleanups. >>> Please review. >>> >>> Thanks, >>> Attilio >> >> In general, I think the patch is fine. It violates the existing >> style >> of the driver in some places (e.g. the aic7xxx drivers wrap function >> arguments to the opening '(' not to a 4 space indent), which should >> probably be addressed so the code remains consistent. > > Sorry, I cannot find where these existing style breakage happens, > could you be a bit more precise? > (I just found an un-sorted header introduction in aic79xx.h that I > will fix). > > Anyways, your idea about a generalized interface in newbus for > handling that is not bad and as long as I'm planning some works in > this area I can add this item to the TODO list. > > Thanks, > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein From xcllnt at mac.com Thu Nov 12 01:58:22 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Nov 12 01:58:30 2009 Subject: How to confuse geom_part_mbr In-Reply-To: <86d43omsb0.fsf@ds4.des.no> References: <86tyx0mxjw.fsf@ds4.des.no> <94D5F246-3413-4256-A0FB-6DF2D3BFE9D0@mac.com> <86d43omsb0.fsf@ds4.des.no> Message-ID: <7D0E66F2-A3E1-40F9-949B-7C4347E61E21@mac.com> On Nov 11, 2009, at 5:43 PM, Dag-Erling Sm?rgrav wrote: > Marcel Moolenaar writes: >> Dag-Erling Sm?rgrav writes: >>> The machine won't boot, even though you have a valid partition table >>> on ad0 that points to a valid bsdlabel in ad0s1. >> No, you don't have a valid partition table on ad0, because >> you didn't remove the BSD disklabel in sector 2 on ad0. > > Yes, I do have a valid partition table. It is exactly byte-by-byte > identical to the one I get after I zero sector two and re-run fdisk. > The fact that there is unwanted data in sector 2 does *not* make it any > less valid. Of course it does. It's the same as GPT. There's a MBR in front of it and if you don't know about GPT tables, you'll see the MBR, otherwise you'll use the GPT. The difference is that the MBR in front of a BSD disklabel is not supposed to have partitions. But you may not be able to distinguish boot code from a valid partition entry. > > What's more, this could have easily been avoided if geom_whatever gave > the partition table precedence over the label it found in sector 2. That break standard BSD disklabels, because they would be probed as MBRs. -- Marcel Moolenaar xcllnt@mac.com From gibbs at scsiguy.com Thu Nov 12 03:25:29 2009 From: gibbs at scsiguy.com (Justin T. Gibbs) Date: Thu Nov 12 03:25:36 2009 Subject: [PATCH] Adding sysctl for errors statistics to ahd(4) In-Reply-To: <3bbf2fe10911111746g48c8fb82r74744dffedf49758@mail.gmail.com> References: <3bbf2fe10911060643g60079e31y7679b32dac670fd8@mail.gmail.com> <4AFAEE89.3020009@scsiguy.com> <3bbf2fe10911111746g48c8fb82r74744dffedf49758@mail.gmail.com> Message-ID: <4AFB801F.5020806@scsiguy.com> On 11/11/2009 6:46 PM, Attilio Rao wrote: > 2009/11/11 Justin T. Gibbs: >> On 11/6/2009 7:43 AM, Attilio Rao wrote: >>> This patch introduces some mechanisms for collecting informations on >>> errors frequency and debugging (and relative sysctls for printing them >>> out) for the ahd(4) driver: >>> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/ahd/ahd-current2.diff >>> >>> The usage of array for sysctls is a bit too paranoid but it allows for >>> further extendibility of the code and doesn't loose of cleaness. >>> This code has been contributed back by Sandvine Incorporated with some >>> cleanups. >>> Please review. >>> >>> Thanks, >>> Attilio >> >> In general, I think the patch is fine. It violates the existing style >> of the driver in some places (e.g. the aic7xxx drivers wrap function >> arguments to the opening '(' not to a 4 space indent), which should >> probably be addressed so the code remains consistent. > > Sorry, I cannot find where these existing style breakage happens, > could you be a bit more precise? > (I just found an un-sorted header introduction in aic79xx.h that I will fix). For example this code: + ahd->sysctl_tree[AHD_SYSCTL_ROOT] = SYSCTL_ADD_NODE( + &ahd->sysctl_ctx[AHD_SYSCTL_ROOT], SYSCTL_STATIC_CHILDREN(_hw), + OID_AUTO, device_get_nameunit(ahd->dev_softc), CTLFLAG_RD, + 0, ahd_sysctl_node_descriptions[AHD_SYSCTL_ROOT]); + SYSCTL_ADD_PROC(&ahd->sysctl_ctx[AHD_SYSCTL_ROOT], + SYSCTL_CHILDREN(ahd->sysctl_tree[AHD_SYSCTL_ROOT]), OID_AUTO, + "clear", CTLTYPE_UINT | CTLFLAG_RW, ahd, 0, ahd_clear_allcounters, + "IU", "Clear all counters"); should look like this, not style(9), to match the existing style of the driver: ahd->sysctl_tree[AHD_SYSCTL_ROOT] = SYSCTL_ADD_NODE(&ahd->sysctl_ctx[AHD_SYSCTL_ROOT], SYSCTL_STATIC_CHILDREN(_hw), OID_AUTO, device_get_nameunit(ahd->dev_softc), CTLFLAG_RD, 0, ahd_sysctl_node_descriptions[AHD_SYSCTL_ROOT]); SYSCTL_ADD_PROC(&ahd->sysctl_ctx[AHD_SYSCTL_ROOT], SYSCTL_CHILDREN(ahd->sysctl_tree[AHD_SYSCTL_ROOT]), OID_AUTO, "clear", CTLTYPE_UINT|CTLFLAG_RW, ahd, 0, ahd_clear_allcounters, "IU", "Clear all counters"); -- Justin From pyunyh at gmail.com Thu Nov 12 03:48:23 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Nov 12 03:48:30 2009 Subject: Call for bge(4) testers In-Reply-To: <20091111223751.GE15449@michelle.cdnetworks.com> References: <20091111223751.GE15449@michelle.cdnetworks.com> Message-ID: <20091112034749.GI15449@michelle.cdnetworks.com> On Wed, Nov 11, 2009 at 02:37:51PM -0800, Pyun YongHyeon wrote: > > Hi, > > I had been working on fixing bus_dma(9) bugs and adding TSO > capability to bge(4). Now TSO is supported for BCM5755 or newer > controllers. Actually some pre-BCM5755 controllers also support > TSO with the help of special firmware but the license issue and > lower performance of firmware based TSO as well as TSO bug I > intentionally excluded TSO support for pre-BCM5755 controllers. > You can get the patch form the following URL. The diff was > generated against latest HEAD. > > http://people.freebsd.org/~yongari/bge/bge.tso.1111.diff Eh, there was a typo so I regenerated the diff. http://people.freebsd.org/~yongari/bge/bge.tso.1111-1.diff From wblock at wonkity.com Thu Nov 12 03:58:00 2009 From: wblock at wonkity.com (Warren Block) Date: Thu Nov 12 03:58:13 2009 Subject: Epson MFP CX5600 was Re: usb2 + scanner HP ScanJet 4300C In-Reply-To: <20091111175935.19402q31p6gbp1q8@econet.encontacto.net> References: <20091111175935.19402q31p6gbp1q8@econet.encontacto.net> Message-ID: On Wed, 11 Nov 2009, eculp wrote: > Based on the Luigi's link included in an almost year old email to these > lists, I purchased an Epson CX5600 with all intentions of using the scanner > but never seemed to get around to configuring it. Many things have happened > since then including new USB, etc. etc. The printer still works fine using > cups. I have just tried to configure the scanner without luck. A device > isn't created in /dev and only the printer is recognized on boot: > > Nov 11 17:24:51 ed kernel: uhub0: 5 ports with 5 removable, self powered > Nov 11 17:24:51 ed kernel: uhub2: 5 ports with 5 removable, self powered > Nov 11 17:24:51 ed kernel: GEOM: ad4s2: geometry does not match label > (255h,63s != 16h,63s). > Nov 11 17:24:51 ed kernel: GEOM: ad4s3: geometry does not match label > (255h,63s != 16h,63s). > Nov 11 17:24:51 ed kernel: uhub1: 5 ports with 5 removable, self powered > Nov 11 17:24:51 ed kernel: uhub3: 5 ports with 5 removable, self powered > Nov 11 17:24:51 ed kernel: ugen1.2: at usbus1 > Nov 11 17:24:51 ed kernel: ugen2.2: at usbus2 > Nov 11 17:24:51 ed kernel: ulpt0: on usbus2 > Nov 11 17:24:51 ed kernel: ulpt0: using bi-directional mode > > I installed: > > drwxr-xr-x 2 root wheel 512 Nov 11 16:27 sane-backends-1.0.20_4 > drwxr-xr-x 2 root wheel 512 Nov 11 16:41 sane-frontends-1.0.14_5 > drwxr-xr-x 2 root wheel 512 Nov 11 16:47 xsane-0.996_1 > > added entries in usbdevs Not needed for scanners any more, I think. > and devd.conf. Things are different than they used to be since uscanner(4) is gone. Now, you can just refer to the USB device, probably ugen2.2 from above. The Handbook scanning section does have notes for FreeBSD 8. However, I wanted to create a static device for the scanner at uscanner0. First, devd is used to recognize the scanner on attach. devd.conf: attach 20 { device-name "ugen[0-9]+"; match "vendor" "0x04b8"; match "product" "0x010a"; action "/bin/ln -sf /dev/$device-name /dev/uscanner0; \ /sbin/devfs rule applyset" detach 20 { device-name "ugen[0-9]+"; match "vendor" "0x04b8"; match "product" "0x010a"; action "/bin/rm /dev/uscanner0" Note that this doesn't care which ugen device is created, it looks for the vendor and product ID of the scanner. When that device attaches, a link is created to /dev/uscanner0 and devfs rules are reapplied so the owner and permissions are set on that link. Speaking of which, devfs.rules: add path 'ugen*' mode 0660 group operator add path 'usb*' mode 0770 group operator add path 'uscanner*' mode 0660 group operator About that middle rule: I found that was needed to let non-root members of the operator group scan. It may be a mistake. And finally, /usr/local/etc/sane.d/epson.conf has just: usb /dev/uscanner0 -Warren Block * Rapid City, South Dakota USA From julian at elischer.org Thu Nov 12 04:55:15 2009 From: julian at elischer.org (Julian Elischer) Date: Thu Nov 12 04:55:22 2009 Subject: How to confuse geom_part_mbr In-Reply-To: <86d43omsb0.fsf@ds4.des.no> References: <86tyx0mxjw.fsf@ds4.des.no> <94D5F246-3413-4256-A0FB-6DF2D3BFE9D0@mac.com> <86d43omsb0.fsf@ds4.des.no> Message-ID: <4AFB953C.8030607@elischer.org> Dag-Erling Sm?rgrav wrote: > Marcel Moolenaar writes: >> Dag-Erling Sm?rgrav writes: >>> The machine won't boot, even though you have a valid partition table >>> on ad0 that points to a valid bsdlabel in ad0s1. >> No, you don't have a valid partition table on ad0, because >> you didn't remove the BSD disklabel in sector 2 on ad0. > > Yes, I do have a valid partition table. It is exactly byte-by-byte > identical to the one I get after I zero sector two and re-run fdisk. > The fact that there is unwanted data in sector 2 does *not* make it any > less valid. > > What's more, this could have easily been avoided if geom_whatever gave > the partition table precedence over the label it found in sector 2. > > DES The dummy MBR on a disklabel can be relatively easily identified, and the regular MDR tasting code should note it and give it a lower priority than a real MBR. (and a disklabel) From xcllnt at mac.com Thu Nov 12 06:06:06 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Nov 12 06:06:13 2009 Subject: How to confuse geom_part_mbr In-Reply-To: <4AFB953C.8030607@elischer.org> References: <86tyx0mxjw.fsf@ds4.des.no> <94D5F246-3413-4256-A0FB-6DF2D3BFE9D0@mac.com> <86d43omsb0.fsf@ds4.des.no> <4AFB953C.8030607@elischer.org> Message-ID: <8DB6C1EB-939D-4128-A15B-A86F4FA63F65@mac.com> On Nov 11, 2009, at 8:55 PM, Julian Elischer wrote: > Dag-Erling Sm?rgrav wrote: >> Marcel Moolenaar writes: >>> Dag-Erling Sm?rgrav writes: >>>> The machine won't boot, even though you have a valid partition table >>>> on ad0 that points to a valid bsdlabel in ad0s1. >>> No, you don't have a valid partition table on ad0, because >>> you didn't remove the BSD disklabel in sector 2 on ad0. >> Yes, I do have a valid partition table. It is exactly byte-by-byte >> identical to the one I get after I zero sector two and re-run fdisk. >> The fact that there is unwanted data in sector 2 does *not* make it any >> less valid. >> What's more, this could have easily been avoided if geom_whatever gave >> the partition table precedence over the label it found in sector 2. >> DES > > The dummy MBR on a disklabel can be relatively easily identified, and the regular MDR tasting code should note it and give it a lower priority than a real MBR. (and a disklabel) Fuzzy logic. How do you distinguish an empty MBR from a dummy one? The exists of the BSD disklabel in sector 2 is obviously and non-fuzzily a much better identifier. The problem with tools like fdisk and disklabel is that they work well to create metadata, but they don't deal with the removal of metadata. Combine that with the ignorance of one tool towards the other and you get what des@ points out: stale data that cause problems. Note also that there is no ordering or priority mechanism between the old GEOM_MBR and GEOM_BSD. It just so happens that GEOM_MBR tastes first. But this is not at all a given. In fact, if you remove GEOM_MBR from your kernel config you'll see that GEOM_BSD attaches. The bottomline: gpart implements the correct algorithm because it's the only one that stable and reliable. -- Marcel Moolenaar xcllnt@mac.com From dhorn2000 at gmail.com Thu Nov 12 06:48:03 2009 From: dhorn2000 at gmail.com (David Horn) Date: Thu Nov 12 06:48:09 2009 Subject: initcpu.c r199067 boot hang Message-ID: <25ff90d60911112248w16d966a3je5d4440ada2950ed@mail.gmail.com> I am seeing a problem on my Dell Inspiron 1520 laptop causing a boot failure (hang) after r199067 with -CURRENT. Kernel with 199066 works fine. System is amd64 running generic kernel, and no loader.conf entries. System has latest bios update. CPU: Intel(R) Core(TM)2 Duo CPU T7500 @ 2.20GHz (2194.52-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fa Stepping = 10 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2052681728 (1957 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 Root FS happens to be on USB (although looking at the svn diff for 199067, I am guessing this does not make a difference) Hang occurs right about the time that I would expect to normally see the following: SMP: AP CPU #1 Launched! This is a hard hang requiring 4 second power button push. Please let me know if any additional details or tests would be useful. ---Dave Horn From hselasky at c2i.net Thu Nov 12 07:59:25 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Thu Nov 12 07:59:45 2009 Subject: Epson MFP CX5600 was Re: usb2 + scanner HP ScanJet 4300C In-Reply-To: <20091111175935.19402q31p6gbp1q8@econet.encontacto.net> References: <20091111175935.19402q31p6gbp1q8@econet.encontacto.net> Message-ID: <200911120858.25508.hselasky@c2i.net> On Thursday 12 November 2009 00:59:35 eculp wrote: > Based on the Luigi's link included in an almost year old email to > these lists, I purchased an Epson CX5600 with all intentions of using > the scanner but never seemed to get around to configuring it. Many > things have happened since then including new USB, etc. etc. The > printer still works fine using cups. I have just tried to configure > the scanner without luck. A device isn't created in /dev and only the > printer is recognized on boot: > > Nov 11 17:24:51 ed kernel: uhub0: 5 ports with 5 removable, self powered > Nov 11 17:24:51 ed kernel: uhub2: 5 ports with 5 removable, self powered > Nov 11 17:24:51 ed kernel: GEOM: ad4s2: geometry does not match label > (255h,63s != 16h,63s). > Nov 11 17:24:51 ed kernel: GEOM: ad4s3: geometry does not match label > (255h,63s != 16h,63s). > Nov 11 17:24:51 ed kernel: uhub1: 5 ports with 5 removable, self powered > Nov 11 17:24:51 ed kernel: uhub3: 5 ports with 5 removable, self powered > Nov 11 17:24:51 ed kernel: ugen1.2: at usbus1 > Nov 11 17:24:51 ed kernel: ugen2.2: at usbus2 > Nov 11 17:24:51 ed kernel: ulpt0: on usbus2 > Nov 11 17:24:51 ed kernel: ulpt0: using bi-directional mode > > I installed: > > drwxr-xr-x 2 root wheel 512 Nov 11 16:27 sane-backends-1.0.20_4 > drwxr-xr-x 2 root wheel 512 Nov 11 16:41 sane-frontends-1.0.14_5 > drwxr-xr-x 2 root wheel 512 Nov 11 16:47 xsane-0.996_1 > > > added entries in usbdevs and devd.conf. > > I don't really know where to go from here. I haven't configured a > scanner for freebsd in years and am totally lost. It isn't really > that important but it would certainly be handy. Hi, Your scanner should be available under /dev/usb/1.2.xxx according to ugen1.2 What do you mean by configure? Upload firmware? --HPS > > I am running up to date Current: > > FreeBSD ed.local.net.mx 9.0-CURRENT FreeBSD 9.0-CURRENT #360: Wed Nov > 11 06:55:25 CST 2009 > root@ed.local.net.mx:/usr/obj/usr/src/sys/ENCONTACTO i386 > > That could be part of the problem. > > Thanks, > > ed > > P.S. Luigi thanks for the great tutoral. I'm pretty sure the problems > are from the changes made in current this year. > > > ----- Forwarded message from rizzo@iet.unipi.it ----- > Date: Fri, 12 Dec 2008 23:04:28 +0100 > From: Luigi Rizzo > Subject: Re: usb2 + scanner HP ScanJet 4300C > To: Oliver Fromme > Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org > > On Fri, Dec 12, 2008 at 09:27:27PM +0100, Oliver Fromme wrote: > > Hi, > > > > I've got a HP ScanJet 4300C that seems to be a little bit > > stubborn. > > ... > > > Is there anything I can do, except for forgetting about > > this scanner alltogether? > > one option is to put the device IDs in uscanner.c and see if > it is recognised. But other than that, i wouldn't waste much time: > for 50..80 euro you can get one of the > Epson multifunction printer scanners (i have personally > tried DX4400 to DX7050) which are well supported and > extremely reliable. > > see http://info.iet.unipi.it/~luigi/FreeBSD/dx5050.html > > cheers > luigi > _______________________________________________ > freebsd-usb@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-usb > To unsubscribe, send any mail to "freebsd-usb-unsubscribe@freebsd.org" > > > ----- End forwarded message ----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From giovanni.trematerra at gmail.com Thu Nov 12 08:48:38 2009 From: giovanni.trematerra at gmail.com (Giovanni Trematerra) Date: Thu Nov 12 08:48:44 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091111231753.GA52833@dmr.ath.cx> References: <20091106101943.5a763f43@ernst.jennejohn.org> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> <20091111231753.GA52833@dmr.ath.cx> Message-ID: <4e6cba830911120048w71900f8vc263021b99b6a2fa@mail.gmail.com> On Thu, Nov 12, 2009 at 12:17 AM, Emil Mikulic wrote: > On Tue, Nov 10, 2009 at 09:15:42AM -0800, Mark Atkinson wrote: >> Also, you can try adding: >> >> hw.mca.enabled="1" in /boot/loader.conf > > This is a little off-topic, but: > Why is this disabled by default in FreeBSD? I guess because it introduces an overhead. -- Trematerra Giovanni From bsam at ipt.ru Thu Nov 12 09:18:50 2009 From: bsam at ipt.ru (Boris Samorodov) Date: Thu Nov 12 09:18:57 2009 Subject: [usb] [8.0-RC3] endless loop at attach and freeze under X Message-ID: <90129735@h30.sp.ipt.ru> Hello List, The system and the device: ----- % uname -a FreeBSD h30.sp.ipt.ru 8.0-RC3 FreeBSD 8.0-RC3 #0: Thu Nov 12 11:25:27 MSK 2009 root@h30.sp.ipt.ru:/usr/obj/usr/src/sys/INDUS i386 ----- ugen3.2: at usbus3 umass0: on usbus3 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:2:0:-1: Attached to scbus2 ----- Endless loop occures while plugging: ----- (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition (probe0:umass-sim0:0:0:0): ILLEGAL REQUEST asc:21,0 (probe0:umass-sim0:0:0:0): Logical block address out of range (probe0:umass-sim0:0:0:0): Unretryable error da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 994MB (2036224 512 byte sectors: 64H 32S/T 994C) (da0:umass-sim0:0:0:0): READ(10). CDB: 28 0 0 1f 11 ff 0 0 1 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): Sense Error Code 0x72 ... [the last 4 lines keep displaying until unplug] ----- Even worse, under X (a gnome session here) the system just freezes if the cardreader is attached. -- WBR, bsam From tinderbox at freebsd.org Thu Nov 12 10:43:54 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Nov 12 10:44:08 2009 Subject: [head tinderbox] failure on i386/pc98 Message-ID: <200911120946.nAC9k4HX017094@freebsd-current.sentex.ca> TB --- 2009-11-12 08:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-12 08:10:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-11-12 08:10:00 - cleaning the object tree TB --- 2009-11-12 08:10:18 - cvsupping the source tree TB --- 2009-11-12 08:10:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-11-12 08:31:16 - building world TB --- 2009-11-12 08:31:16 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-12 08:31:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-12 08:31:16 - TARGET=pc98 TB --- 2009-11-12 08:31:16 - TARGET_ARCH=i386 TB --- 2009-11-12 08:31:16 - TZ=UTC TB --- 2009-11-12 08:31:16 - __MAKE_CONF=/dev/null TB --- 2009-11-12 08:31:16 - cd /src TB --- 2009-11-12 08:31:16 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 12 08:31:17 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Nov 12 09:27:36 UTC 2009 TB --- 2009-11-12 09:27:36 - generating LINT kernel config TB --- 2009-11-12 09:27:36 - cd /src/sys/pc98/conf TB --- 2009-11-12 09:27:36 - /usr/bin/make -B LINT TB --- 2009-11-12 09:27:36 - building LINT kernel TB --- 2009-11-12 09:27:36 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-12 09:27:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-12 09:27:36 - TARGET=pc98 TB --- 2009-11-12 09:27:36 - TARGET_ARCH=i386 TB --- 2009-11-12 09:27:36 - TZ=UTC TB --- 2009-11-12 09:27:36 - __MAKE_CONF=/dev/null TB --- 2009-11-12 09:27:36 - cd /src TB --- 2009-11-12 09:27:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Nov 12 09:27:36 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> export_syms awk -f /src/sys/conf/kmod_syms.awk rdma_core.kld export_syms | xargs -J% objcopy % rdma_core.kld ld -Bshareable -d -warn-common -o rdma_core.ko rdma_core.kld objcopy --strip-debug rdma_core.ko ===> rdma/krping (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/pc98/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/pc98/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/rdma/krping/../../../contrib/rdma/krping/krping.c /src/sys/modules/rdma/krping/../../../contrib/rdma/krping/krping.c:117: error: static declaration of 'inet_aton' follows non-static declaration @/netinet/in.h:716: error: previous declaration of 'inet_aton' was here *** Error code 1 Stop in /src/sys/modules/rdma/krping. *** Error code 1 Stop in /src/sys/modules/rdma. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-12 09:46:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-12 09:46:04 - ERROR: failed to build lint kernel TB --- 2009-11-12 09:46:04 - 3483.03 user 706.76 system 5763.78 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From tinderbox at freebsd.org Thu Nov 12 11:07:25 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Nov 12 11:07:42 2009 Subject: [head tinderbox] failure on i386/i386 Message-ID: <200911121009.nACA9Z5T094824@freebsd-current.sentex.ca> TB --- 2009-11-12 08:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-12 08:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2009-11-12 08:10:00 - cleaning the object tree TB --- 2009-11-12 08:10:22 - cvsupping the source tree TB --- 2009-11-12 08:10:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2009-11-12 08:49:24 - building world TB --- 2009-11-12 08:49:24 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-12 08:49:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-12 08:49:24 - TARGET=i386 TB --- 2009-11-12 08:49:24 - TARGET_ARCH=i386 TB --- 2009-11-12 08:49:24 - TZ=UTC TB --- 2009-11-12 08:49:24 - __MAKE_CONF=/dev/null TB --- 2009-11-12 08:49:24 - cd /src TB --- 2009-11-12 08:49:24 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 12 08:49:25 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Nov 12 09:48:18 UTC 2009 TB --- 2009-11-12 09:48:18 - generating LINT kernel config TB --- 2009-11-12 09:48:18 - cd /src/sys/i386/conf TB --- 2009-11-12 09:48:18 - /usr/bin/make -B LINT TB --- 2009-11-12 09:48:18 - building LINT kernel TB --- 2009-11-12 09:48:18 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-12 09:48:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-12 09:48:18 - TARGET=i386 TB --- 2009-11-12 09:48:18 - TARGET_ARCH=i386 TB --- 2009-11-12 09:48:18 - TZ=UTC TB --- 2009-11-12 09:48:18 - __MAKE_CONF=/dev/null TB --- 2009-11-12 09:48:18 - cd /src TB --- 2009-11-12 09:48:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Nov 12 09:48:18 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] :> export_syms awk -f /src/sys/conf/kmod_syms.awk rdma_core.kld export_syms | xargs -J% objcopy % rdma_core.kld ld -Bshareable -d -warn-common -o rdma_core.ko rdma_core.kld objcopy --strip-debug rdma_core.ko ===> rdma/krping (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/i386/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -I/obj/i386/src/sys/LINT -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/rdma/krping/../../../contrib/rdma/krping/krping.c /src/sys/modules/rdma/krping/../../../contrib/rdma/krping/krping.c:117: error: static declaration of 'inet_aton' follows non-static declaration @/netinet/in.h:716: error: previous declaration of 'inet_aton' was here *** Error code 1 Stop in /src/sys/modules/rdma/krping. *** Error code 1 Stop in /src/sys/modules/rdma. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-12 10:09:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-12 10:09:35 - ERROR: failed to build lint kernel TB --- 2009-11-12 10:09:35 - 3676.95 user 720.63 system 7174.75 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From tinderbox at freebsd.org Thu Nov 12 11:30:55 2009 From: tinderbox at freebsd.org (FreeBSD Tinderbox) Date: Thu Nov 12 11:31:01 2009 Subject: [head tinderbox] failure on amd64/amd64 Message-ID: <200911121033.nACAX5w5064845@freebsd-current.sentex.ca> TB --- 2009-11-12 08:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-11-12 08:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-11-12 08:10:00 - cleaning the object tree TB --- 2009-11-12 08:10:30 - cvsupping the source tree TB --- 2009-11-12 08:10:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-11-12 08:48:26 - building world TB --- 2009-11-12 08:48:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-12 08:48:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-12 08:48:26 - TARGET=amd64 TB --- 2009-11-12 08:48:26 - TARGET_ARCH=amd64 TB --- 2009-11-12 08:48:26 - TZ=UTC TB --- 2009-11-12 08:48:26 - __MAKE_CONF=/dev/null TB --- 2009-11-12 08:48:26 - cd /src TB --- 2009-11-12 08:48:26 - /usr/bin/make -B buildworld >>> World build started on Thu Nov 12 08:48:27 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Nov 12 10:13:40 UTC 2009 TB --- 2009-11-12 10:13:40 - generating LINT kernel config TB --- 2009-11-12 10:13:40 - cd /src/sys/amd64/conf TB --- 2009-11-12 10:13:40 - /usr/bin/make -B LINT TB --- 2009-11-12 10:13:40 - building LINT kernel TB --- 2009-11-12 10:13:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-11-12 10:13:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-11-12 10:13:40 - TARGET=amd64 TB --- 2009-11-12 10:13:40 - TARGET_ARCH=amd64 TB --- 2009-11-12 10:13:40 - TZ=UTC TB --- 2009-11-12 10:13:40 - __MAKE_CONF=/dev/null TB --- 2009-11-12 10:13:40 - cd /src TB --- 2009-11-12 10:13:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Nov 12 10:13:40 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ld -d -warn-common -r -d -o rdma_core.ko rdma_device.o rdma_cache.o rdma_verbs.o :> export_syms awk -f /src/sys/conf/kmod_syms.awk rdma_core.ko export_syms | xargs -J% objcopy % rdma_core.ko objcopy --strip-debug rdma_core.ko ===> rdma/krping (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/src/sys/LINT/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -fno-omit-frame-pointer -I/obj/src/sys/LINT -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/rdma/krping/../../../contrib/rdma/krping/krping.c /src/sys/modules/rdma/krping/../../../contrib/rdma/krping/krping.c:117: error: static declaration of 'inet_aton' follows non-static declaration @/netinet/in.h:716: error: previous declaration of 'inet_aton' was here *** Error code 1 Stop in /src/sys/modules/rdma/krping. *** Error code 1 Stop in /src/sys/modules/rdma. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-11-12 10:33:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-11-12 10:33:05 - ERROR: failed to build lint kernel TB --- 2009-11-12 10:33:05 - 4764.99 user 981.59 system 8584.72 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From nyan at jp.FreeBSD.org Thu Nov 12 12:49:03 2009 From: nyan at jp.FreeBSD.org (Takahashi Yoshihiro) Date: Thu Nov 12 12:49:11 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <20091111101207.GF64905@hoeg.nl> References: <20091111101207.GF64905@hoeg.nl> Message-ID: <20091112.214836.27789213.nyan@jp.FreeBSD.org> In article <20091111101207.GF64905@hoeg.nl> Ed Schouten writes: > I'd like to flip the switch one of these days on all platforms, except > i386. On i386 the /etc/ttys file is shared between i386 and pc98. pc98 > will still use its own cons25 emulator instead of the xterm emulator, so > I'll initially convert all the other platforms and deal with i386 (and > hopefully pc98) later. I'll discuss this with nyan@. It seems that scterm-teken.c works for pc98, but it cannot display Japanese differently from scterm-sck.c. I think that Japanese support is more important than xterm support for pc98. So it should add etc/etc.pc98/ttys. --- TAKAHASHI Yoshihiro From ed at 80386.nl Thu Nov 12 12:59:07 2009 From: ed at 80386.nl (Ed Schouten) Date: Thu Nov 12 12:59:17 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <20091112.214836.27789213.nyan@jp.FreeBSD.org> References: <20091111101207.GF64905@hoeg.nl> <20091112.214836.27789213.nyan@jp.FreeBSD.org> Message-ID: <20091112125903.GS64905@hoeg.nl> Hey Takahashi, * Takahashi Yoshihiro wrote: > In article <20091111101207.GF64905@hoeg.nl> > Ed Schouten writes: > > I'd like to flip the switch one of these days on all platforms, except > > i386. On i386 the /etc/ttys file is shared between i386 and pc98. pc98 > > will still use its own cons25 emulator instead of the xterm emulator, so > > I'll initially convert all the other platforms and deal with i386 (and > > hopefully pc98) later. I'll discuss this with nyan@. > > It seems that scterm-teken.c works for pc98, but it cannot display > Japanese differently from scterm-sck.c. I think that Japanese support > is more important than xterm support for pc98. So it should add > etc/etc.pc98/ttys. Sure. That could work. I'll first commit the patch I have and after that I'll decouple /etc/ttys on i386 on pc98. I'll keep you informed. -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091112/4a9d5ed5/attachment.pgp From avg at icyb.net.ua Thu Nov 12 13:36:50 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Nov 12 13:36:57 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <941257966918@webmail42.yandex.ru> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> <941257966918@webmail42.yandex.ru> Message-ID: <4AFC0F6A.3000501@icyb.net.ua> on 11/11/2009 21:15 S.N.Grigoriev said the following: > > MCA: CPU3 UNCOR PCC OVER DTLIB L1 error > MCA: Address 0x8015fb000 > > > Fatal trap 28: machine check trap while in user mode > > Fatal trap 28: machine check trap while in user mode > cpuid = 3, apic id = 03 > ..... etc. > > > I've typed 'panic' at the 'db>' prompt but got no crash dump. > Tell me please what can I do for further problem investigation. Serguey, are you sure that setting vm.pmap.pg_ps_enabled=0 doesn't help you? I know that already asked you this once. But, could you please try again with vm.pmap.pg_ps_enabled=0 and hw.mca.enabled=1 and see what kind of behavior you get? I am curious what would happen, would it be the same kind of machine check condition. -- Andriy Gapon From avg at icyb.net.ua Thu Nov 12 13:39:05 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Nov 12 13:39:12 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <4e6cba830911120048w71900f8vc263021b99b6a2fa@mail.gmail.com> References: <20091106101943.5a763f43@ernst.jennejohn.org> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> <20091111231753.GA52833@dmr.ath.cx> <4e6cba830911120048w71900f8vc263021b99b6a2fa@mail.gmail.com> Message-ID: <4AFC0FF3.50303@icyb.net.ua> on 12/11/2009 10:48 Giovanni Trematerra said the following: > On Thu, Nov 12, 2009 at 12:17 AM, Emil Mikulic wrote: >> On Tue, Nov 10, 2009 at 09:15:42AM -0800, Mark Atkinson wrote: >>> Also, you can try adding: >>> >>> hw.mca.enabled="1" in /boot/loader.conf >> This is a little off-topic, but: >> Why is this disabled by default in FreeBSD? > > I guess because it introduces an overhead. I don't think that there is any noticable overhead. My guess is because it is a new feature which has not been wildly tested yet. -- Andriy Gapon From avg at icyb.net.ua Thu Nov 12 13:59:31 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Nov 12 13:59:39 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> <941257966918@webmail42.yandex.ru> Message-ID: <4AFC14BE.7020106@icyb.net.ua> on 11/11/2009 22:13 Mark Atkinson said the following: > > Well, you're about at the point I am now with my HP dl385g5, only > turning off superpages would result in a successful buildworld. Mine > would often machine check during gas compilation as well. Mark, you mentioning MCA was magic moment for me. I was debugging a problem which seemed to be quite different, but now I think that it converges to the problem discussed in this thread (if indeed it's the same problem for all reporters). The difference is that I use a "consumer level" system based on family 10h Athlon II and you use Opterons, seemingly also 10h or Fh families. I guess that means that you and Kai both use "high end"/"server grade" systems or some such. It's possible that firmware/BIOS on your systems enables and monitors MCA by default, even when the OS is not MCA-enabled. As such, I am curious if you have any BIOS settings that look like being related to Machine Check. Or perhaps there is something like Event Log in BIOS. Maybe it even gets something useful. Could you please check? About my problem - it seems that I was working from the opposite end. I have been using head/CURRENT with pg_ps_enabled=1 for quite a while now. And then I decided to try hw.mca.enabled=1 and after that I started having the same symptoms as described here. Unfortunately, I never did get Machine Check trap, it's always something that looks like CPU halt and then reset by watchdog (if it is enabled). So, for me: superpages and no machine check - works machine check and no superpages - works machine check and superpages - problem -- Andriy Gapon From mexas at bristol.ac.uk Thu Nov 12 14:15:31 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Nov 12 14:15:37 2009 Subject: compiler discussion Message-ID: <20091112141519.GA66229@mech-cluster241.men.bris.ac.uk> Following from the discussion on the system compiler for ia64, I tried to list few major ports which I'd love to have on ia64, but can't, because of GCC problems: - math/blas, lapack, lapack95, arpack, scalapack, atlas, etc. - science/hdf5-18 (fortran APIs can't be built) - french/aster (industial quality FEA code) - cad/calculix (another good FEA code) All these depend on lang/gcc44, which doesn't build. The only fortran compiler I know to build and work successfully on ia64 is (correct me if I'm wrong) g95. I wonder if it's possible/desirable/easy to use lang/g95 for the above and other fortran-dependent ports? In principal, lang/g95 looks very good, and it's got some features not available in gfortran, e.g. limited support for 2003 standard. Any comments? Also, any comments on the usability (particularly for fortran) of llvm and lang/llvm-gcc4 on ia64? many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From matthias.andree at gmx.de Thu Nov 12 14:16:11 2009 From: matthias.andree at gmx.de (Matthias Andree) Date: Thu Nov 12 14:16:45 2009 Subject: HEADS UP: Important bug fix in ZFS replay code! In-Reply-To: <20091110224524.GC3194@garage.freebsd.pl> References: <200911102227.nAAMRXTf073603@svn.freebsd.org> <20091110224524.GC3194@garage.freebsd.pl> Message-ID: Am 10.11.2009, 23:45 Uhr, schrieb Pawel Jakub Dawidek : > You can locate such files with the following command: > > # find / -perm -7777 -print0 | xargs -0 ls -ld Use ls -ldb to be on the safe side (control characters!). So how about these refinements: find / -perm -7777 -exec ls -ldb '{}' + find / -perm -7777 -ls (not sure what that does with escapes) > You can locate and fix such files with the following command: > > # find / -perm -7777 -print0 | xargs -0 chmod a-s,o-w,-t find / -perm -7777 -exec chmod a-s,o-w,-t '{}' + -- Matthias Andree From alireza.torabi at gmail.com Thu Nov 12 14:58:13 2009 From: alireza.torabi at gmail.com (Alireza Torabi) Date: Thu Nov 12 14:58:21 2009 Subject: Current 9 freeze after ATA PseudoRAID loaded on AMD64 smp during boot In-Reply-To: References: Message-ID: Oh, I've tried the BIOS SATA in ATA, AHCI and IRRT (Intel Rapid Restore Technology). This box had a customised 9 kernel quite happily in IRRT before the csup I should add. The SATA is Intel ICH9 btw. On 11/12/09, Alireza Torabi wrote: > Hi folks, > > My FreeBSD current (just csup-ed now: 12 Nov 2009) freezes after "ATA > PseduoRAID loaded" message during boot. Nothing happens after that and > I need to do a cold reboot. > > I've tried the GENERIC kernel with no joy :( > > Any leads or ideas is truly appreciated. > > Thanks > Alireza > From alireza.torabi at gmail.com Thu Nov 12 15:08:04 2009 From: alireza.torabi at gmail.com (Alireza Torabi) Date: Thu Nov 12 15:08:10 2009 Subject: Current 9 freeze after ATA PseudoRAID loaded on AMD64 smp during boot Message-ID: Hi folks, My FreeBSD current (just csup-ed now: 12 Nov 2009) freezes after "ATA PseduoRAID loaded" message during boot. Nothing happens after that and I need to do a cold reboot. I've tried the GENERIC kernel with no joy :( Any leads or ideas is truly appreciated. Thanks Alireza From attilio at freebsd.org Thu Nov 12 15:17:16 2009 From: attilio at freebsd.org (Attilio Rao) Date: Thu Nov 12 15:17:24 2009 Subject: [PATCH] Adding sysctl for errors statistics to ahd(4) In-Reply-To: <4AFB801F.5020806@scsiguy.com> References: <3bbf2fe10911060643g60079e31y7679b32dac670fd8@mail.gmail.com> <4AFAEE89.3020009@scsiguy.com> <3bbf2fe10911111746g48c8fb82r74744dffedf49758@mail.gmail.com> <4AFB801F.5020806@scsiguy.com> Message-ID: <3bbf2fe10911120717u79b2f057vceb41bc021c9ee0d@mail.gmail.com> 2009/11/12 Justin T. Gibbs : > On 11/11/2009 6:46 PM, Attilio Rao wrote: >> 2009/11/11 Justin T. Gibbs: >>> On 11/6/2009 7:43 AM, Attilio Rao wrote: >>>> This patch introduces some mechanisms for collecting informations on >>>> errors frequency and debugging (and relative sysctls for printing them >>>> out) for the ahd(4) driver: >>>> http://www.freebsd.org/~attilio/Sandvine/STABLE_8/ahd/ahd-current2.diff >>>> >>>> The usage of array for sysctls is a bit too paranoid but it allows for >>>> further extendibility of the code and doesn't loose of cleaness. >>>> This code has been contributed back by Sandvine Incorporated with some >>>> cleanups. >>>> Please review. >>>> >>>> Thanks, >>>> Attilio >>> >>> In general, I think the patch is fine. It violates the existing style >>> of the driver in some places (e.g. the aic7xxx drivers wrap function >>> arguments to the opening '(' not to a 4 space indent), which should >>> probably be addressed so the code remains consistent. >> >> Sorry, I cannot find where these existing style breakage happens, >> could you be a bit more precise? >> (I just found an un-sorted header introduction in aic79xx.h that I will fix). > > > For example this code: > > + ahd->sysctl_tree[AHD_SYSCTL_ROOT] = SYSCTL_ADD_NODE( > + &ahd->sysctl_ctx[AHD_SYSCTL_ROOT], SYSCTL_STATIC_CHILDREN(_hw), > + OID_AUTO, device_get_nameunit(ahd->dev_softc), CTLFLAG_RD, > + 0, ahd_sysctl_node_descriptions[AHD_SYSCTL_ROOT]); > + SYSCTL_ADD_PROC(&ahd->sysctl_ctx[AHD_SYSCTL_ROOT], > + SYSCTL_CHILDREN(ahd->sysctl_tree[AHD_SYSCTL_ROOT]), OID_AUTO, > + "clear", CTLTYPE_UINT | CTLFLAG_RW, ahd, 0, ahd_clear_allcounters, > + "IU", "Clear all counters"); > > should look like this, not style(9), to match the existing style of the > driver: > > ahd->sysctl_tree[AHD_SYSCTL_ROOT] = > SYSCTL_ADD_NODE(&ahd->sysctl_ctx[AHD_SYSCTL_ROOT], > SYSCTL_STATIC_CHILDREN(_hw), OID_AUTO, > device_get_nameunit(ahd->dev_softc), CTLFLAG_RD, > 0, ahd_sysctl_node_descriptions[AHD_SYSCTL_ROOT]); > > SYSCTL_ADD_PROC(&ahd->sysctl_ctx[AHD_SYSCTL_ROOT], > SYSCTL_CHILDREN(ahd->sysctl_tree[AHD_SYSCTL_ROOT]), > OID_AUTO, "clear", CTLTYPE_UINT|CTLFLAG_RW, ahd, 0, > ahd_clear_allcounters, "IU", "Clear all counters"); > Could you check if this revision of the patch is adeguate?: http://www.freebsd.org/~attilio/Sandvine/STABLE_8/ahd/ahd-current3.diff Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From freebsd at levsha.org.ua Thu Nov 12 15:18:45 2009 From: freebsd at levsha.org.ua (Mykola Dzham) Date: Thu Nov 12 15:18:53 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <2a41acea0911101120o39fd695cpa325736d00b11587@mail.gmail.com> References: <20091017170351.GZ29771@expo.ukrweb.net> <20091017222314.GB19204@michelle.cdnetworks.com> <200911092033.nA9KX6dD013378@lava.sentex.ca> <200911092215.nA9MFeDP013898@lava.sentex.ca> <2a41acea0911091459w2b4fec5djd64d0324557b7da2@mail.gmail.com> <200911100021.nAA0LvMG014534@lava.sentex.ca> <2a41acea0911091633u2899b47ewb514b6276ba2cf62@mail.gmail.com> <200911100227.nAA2RtDY015177@lava.sentex.ca> <2a41acea0911101057q4f913e30m9319e52bbd254cfe@mail.gmail.com> <2a41acea0911101120o39fd695cpa325736d00b11587@mail.gmail.com> Message-ID: <20091112151852.GC81701@expo.ukrweb.net> Jack Vogel wrote: > This is a fix for this problem, please apply and test this. > > Jack > > ------- if_igb.c (revision 197079) > +++ if_igb.c (working copy) > @@ -2654,7 +2654,7 @@ > int error; > > error = bus_dma_tag_create(bus_get_dma_tag(adapter->dev), /* parent */ > - IGB_DBA_ALIGN, 0, /* alignment, bounds */ > + 1, 0, /* alignment, bounds */ > BUS_SPACE_MAXADDR, /* lowaddr */ > BUS_SPACE_MAXADDR, /* highaddr */ > NULL, NULL, /* filter, filterarg */ > @@ -2867,7 +2867,7 @@ > * Setup DMA descriptor areas. > */ > if ((error = bus_dma_tag_create(NULL, /* parent */ > - PAGE_SIZE, 0, /* alignment, bounds */ > + 1, 0, /* alignment, bounds */ > BUS_SPACE_MAXADDR, /* lowaddr */ > BUS_SPACE_MAXADDR, /* highaddr */ > NULL, NULL, /* filter, filterarg */ > @@ -3554,7 +3554,7 @@ > ** it may not always use this. > */ > if ((error = bus_dma_tag_create(NULL, /* parent */ > - PAGE_SIZE, 0, /* alignment, bounds */ > + 1, 0, /* alignment, bounds */ > BUS_SPACE_MAXADDR, /* lowaddr */ > BUS_SPACE_MAXADDR, /* highaddr */ > NULL, NULL, /* filter, filterarg */ This patch fix my problem too: 4 hour uptime on patched 8.0-RC2 with high network load without any problems. Thanks! -- LEFT-(UANIC|RIPE) JID: levsha@jabber.net.ua PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280 From dhorn2000 at gmail.com Thu Nov 12 15:21:40 2009 From: dhorn2000 at gmail.com (David Horn) Date: Thu Nov 12 15:21:50 2009 Subject: Current 9 freeze after ATA PseudoRAID loaded on AMD64 smp during boot In-Reply-To: References: Message-ID: <25ff90d60911120721h5921b515jca4ba41c56f2f38f@mail.gmail.com> On Thu, Nov 12, 2009 at 9:52 AM, Alireza Torabi wrote: > Oh, I've tried the BIOS SATA in ATA, AHCI and IRRT (Intel Rapid > Restore Technology). > > This box had a customised 9 kernel quite happily in IRRT before the > csup I should add. The SATA is Intel ICH9 btw. > > On 11/12/09, Alireza Torabi wrote: >> Hi folks, >> >> My FreeBSD current (just csup-ed now: 12 Nov 2009) freezes after "ATA >> PseduoRAID loaded" message during boot. Nothing happens after that and >> I need to do a cold reboot. >> >> I've tried the GENERIC kernel with no joy :( >> >> Any leads or ideas is truly appreciated. >> >> Thanks >> Alireza >> Sounds like the same problem I have. If you try backing out to SVN r199066 or CVS version 1.56 (sys/amd64/amd64/initcpu.c), you can confirm. Good Luck. --Dave Horn From kostikbel at gmail.com Thu Nov 12 15:26:09 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Nov 12 15:26:15 2009 Subject: Current 9 freeze after ATA PseudoRAID loaded on AMD64 smp during boot In-Reply-To: <25ff90d60911120721h5921b515jca4ba41c56f2f38f@mail.gmail.com> References: <25ff90d60911120721h5921b515jca4ba41c56f2f38f@mail.gmail.com> Message-ID: <20091112152603.GI2331@deviant.kiev.zoral.com.ua> On Thu, Nov 12, 2009 at 10:21:38AM -0500, David Horn wrote: > On Thu, Nov 12, 2009 at 9:52 AM, Alireza Torabi > wrote: > > Oh, I've tried the BIOS SATA in ATA, AHCI and IRRT (Intel Rapid > > Restore Technology). > > > > This box had a customised 9 kernel quite happily in IRRT before the > > csup I should add. The SATA is Intel ICH9 btw. > > > > On 11/12/09, Alireza Torabi wrote: > >> Hi folks, > >> > >> My FreeBSD current (just csup-ed now: 12 Nov 2009) freezes after "ATA > >> PseduoRAID loaded" message during boot. Nothing happens after that and > >> I need to do a cold reboot. > >> > >> I've tried the GENERIC kernel with no joy :( > >> > >> Any leads or ideas is truly appreciated. > >> > >> Thanks > >> Alireza > >> > > Sounds like the same problem I have. If you try backing out to SVN > r199066 or CVS version 1.56 (sys/amd64/amd64/initcpu.c), you can > confirm. Better, try http://people.freebsd.org/~kib/misc/initcache.2.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091112/c0873cb5/attachment.pgp From mike at sentex.net Thu Nov 12 15:29:10 2009 From: mike at sentex.net (Mike Tancsa) Date: Thu Nov 12 15:29:17 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <2a41acea0911111419v5ae5682cy12613e1bd9a9c325@mail.gmail.co m> References: <20091017222314.GB19204@michelle.cdnetworks.com> <200911092215.nA9MFeDP013898@lava.sentex.ca> <2a41acea0911091459w2b4fec5djd64d0324557b7da2@mail.gmail.com> <200911100021.nAA0LvMG014534@lava.sentex.ca> <2a41acea0911091633u2899b47ewb514b6276ba2cf62@mail.gmail.com> <200911100227.nAA2RtDY015177@lava.sentex.ca> <2a41acea0911101057q4f913e30m9319e52bbd254cfe@mail.gmail.com> <2a41acea0911101120o39fd695cpa325736d00b11587@mail.gmail.com> <200911102018.nAAKI3s7021614@lava.sentex.ca> <20091111203101.GC15449@michelle.cdnetworks.com> <2a41acea0911111419v5ae5682cy12613e1bd9a9c325@mail.gmail.com> Message-ID: <200911121529.nACFT8ad037531@lava.sentex.ca> At 05:19 PM 11/11/2009, Jack Vogel wrote: >Ya, so maybe a more robust solution to that failure would be a good >thing, but this is not the time for more elaborate code, having this small >fix put in is low risk and the better failure response can come later. > >In fact, I have a number of places in the ixgbe driver where I'm pondering >over what to do in failure mode anyway. [trimming re@freebsd as this isnt a release issue] No panics yet, but at around 350k pps, I see interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source interrupt storm detected on "irq257:"; throttling interrupt source 0(ich10)# vmstat -i interrupt total rate irq16: uhci0+ 22 0 irq18: ehci0 uhci5 15 0 irq19: fwohci0++ 78 0 irq21: uhci1 17 0 irq23: uhci3 ehci1 2 0 cpu0: timer 175404021 1998 irq256: igb0 19731770 224 irq257: igb0 30741918 350 irq258: igb0 14 0 irq259: igb1 71514077 814 irq260: igb1 28098687 320 irq261: igb1 2 0 irq262: em0 4435336 50 irq263: ahci0 89527 1 cpu7: timer 175395421 1998 cpu6: timer 175394148 1998 cpu1: timer 175395011 1998 cpu4: timer 175394583 1998 cpu5: timer 175395129 1998 cpu3: timer 175395466 1998 cpu2: timer 175394884 1998 Total 1557780128 17749 0(ich10)# -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From sgk at troutmask.apl.washington.edu Thu Nov 12 15:34:14 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Thu Nov 12 15:34:21 2009 Subject: compiler discussion In-Reply-To: <20091112141519.GA66229@mech-cluster241.men.bris.ac.uk> References: <20091112141519.GA66229@mech-cluster241.men.bris.ac.uk> Message-ID: <20091112153407.GA62396@troutmask.apl.washington.edu> On Thu, Nov 12, 2009 at 02:15:19PM +0000, Anton Shterenlikht wrote: > Following from the discussion on the system compiler for ia64, > I tried to list few major ports which I'd love to have on ia64, > but can't, because of GCC problems: > > - math/blas, lapack, lapack95, arpack, scalapack, atlas, etc. > - science/hdf5-18 (fortran APIs can't be built) > - french/aster (industial quality FEA code) > - cad/calculix (another good FEA code) > > All these depend on lang/gcc44, which doesn't build. Doesn't build is not a very good description if you're looking for help. Post the build log somewhere. Have you submitted bug reports to gcc.gnu.org? Bugs that are unreported are unlikely to be fixed. > The only fortran compiler I know to build and work > successfully on ia64 is (correct me if I'm wrong) g95. > > I wonder if it's possible/desirable/easy to use lang/g95 for > the above and other fortran-dependent ports? Given Polyhedron Benchmarks, it may be preferable to determine why you can't build gcc44 and fix that problem.* > In principal, lang/g95 looks very good, and it's got > some features not available in gfortran, e.g. limited > support for 2003 standard. > > Any comments? AFAIK, g95 has TR 15580 implemented and gfortran doesn't. Other than that feature, gfortran has a fairly long list of Fortran 2003 features implemented, which you can find partially enumerated at the gfortran wiki. > Also, any comments on the usability (particularly for fortran) > of llvm and lang/llvm-gcc4 on ia64? Last time I checked, Fortran in llvm was based off a very old gfortran. The llvm website mentions gcc 4.2.?. While the 4.2.? gfortran isn't too bad, you most certainly would rather use gcc44 if you can. Literally, hundreds of bugs and several new feature have been add to gfortran in going from 4.2.? to gcc 4.4.2. Have you checked the Open64 project? *disclaimer: I've contributed a few hundred patches to gfortran, and I'm listed as a gfortran maintainer. -- Steve From adamk at voicenet.com Thu Nov 12 15:34:51 2009 From: adamk at voicenet.com (Adam K Kirchhoff) Date: Thu Nov 12 15:34:58 2009 Subject: Current 9 freeze after ATA PseudoRAID loaded on AMD64 smp during boot In-Reply-To: References: Message-ID: <200911121021.26818.adamk@voicenet.com> On Thursday 12 November 2009 09:43:13 Alireza Torabi wrote: > Hi folks, > > My FreeBSD current (just csup-ed now: 12 Nov 2009) freezes after "ATA > PseduoRAID loaded" message during boot. Nothing happens after that and > I need to do a cold reboot. > > I've tried the GENERIC kernel with no joy :( > > Any leads or ideas is truly appreciated. I've had similar problems in the last few days. Both complete freezes and kernel panics. I've gotten it to work fine with a GENERIC kernel compiled without SMP support. Can you give that a shot? Adam From kensmith at buffalo.edu Thu Nov 12 15:38:40 2009 From: kensmith at buffalo.edu (Ken Smith) Date: Thu Nov 12 15:39:22 2009 Subject: 8.0-RC3 Available Message-ID: <1258040317.7556.29.camel@bauer.cse.buffalo.edu> The third and hopefully last of the Release Candidates for the FreeBSD 8.0 release cycle is now available. Unless something catastrophic comes up within the next couple of days we will begin the final builds for 8.0-RELEASE. There is one known issue with the igb(4) driver we are still deciding whether or not to fix as part of 8.0-RELEASE versus doing an Errata Notice for it some time after the release is out. It has been patched in head, and the SVN commit for it is r199192. If any of you are able to give that patch a try on a machine with the igb(4) NIC it would be appreciated. If you notice problems you can report them through the normal Gnats PR system or on the freebsd-current mailing list. I do cross-post announcements to freebsd-stable because this particular release is "about to become a stable branch" but when it comes to watching for issues related to the release most of the developers pay more attention to the freebsd-current list. ISO images for all supported architectures are available on the FTP sites, and a "memory stick" image is available for amd64/i386 architectures. For amd64/i386 architectures the cdrom and memstick images include the documentation packages but no other packages. The DVD image includes the packages that will probably be available on the official release media but is subject to change between now and release. For sparc64 there is now a livefs cdrom, disc1 includes the documentation packages, and the DVD image has the set of packages that currently build for sparc64 (which is a sub-set of the set provided for amd64/i386). If you are using csup/cvsup methods to update an older system the branch tag to use is RELENG_8_0. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, 8.0-BETA4, 8.0-RC1 or 8.0-RC2 can upgrade as follows: # freebsd-update upgrade -r 8.0-RC3 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. Systems running 8.0-BETA3 may print the warning INDEX-OLD.all: Invalid arguments when downloading updates; this warning is a harmless bug (fixed in 8.0-BETA4) and can be safely ignored. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components: # freebsd-update install At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or earlier will be prompted by freebsd-update to rebuild all third-party applications (e.g., ports installed from the ports tree) due to updates in system libraries. See: http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html for mode details. After updating installed third-party applications (and again, only if freebsd-update printed a message indicating that this was necessary), run freebsd-update again so that it can delete the old (no longer used) system libraries: # freebsd-update install Finally, reboot into 8.0-RC3: # shutdown -r now MD5/SHA256 checksums for the image files: MD5 (8.0-RC3-amd64-bootonly.iso) = 641881caa82ea85c118bc15fff12fce6 MD5 (8.0-RC3-amd64-disc1.iso) = 854c273b89792cd0366d5399df1034eb MD5 (8.0-RC3-amd64-dvd1.iso) = 9bd1bb2507bc2a3037bc321bb2724bd6 MD5 (8.0-RC3-amd64-livefs.iso) = c5f427c8bf823e10a5348935cec2d7ee MD5 (8.0-RC3-amd64-memstick.img) = 6af9e213914a58a5779715ae5882bd25 MD5 (8.0-RC3-i386-bootonly.iso) = dfaec92ae358ab780d317aa66482ca9e MD5 (8.0-RC3-i386-disc1.iso) = 460f6cfddaebee6ae59a7d5f73695246 MD5 (8.0-RC3-i386-dvd1.iso) = 98d3f65f2444a8745f787df5ce9e1f0c MD5 (8.0-RC3-i386-livefs.iso) = 5184b7f6403d1d24991533bde0e580ff MD5 (8.0-RC3-i386-memstick.img) = 8774ef1d6bdf541e440f2f8ed22a2493 MD5 (8.0-RC3-ia64-bootonly.iso) = fd0af8f34937cf7fc78ea0063252afb7 MD5 (8.0-RC3-ia64-disc1.iso) = 96313c25e53fc333c258ed675007f3d7 MD5 (8.0-RC3-ia64-disc2.iso) = 235714607a2805c396ece829839405be MD5 (8.0-RC3-ia64-disc3.iso) = 53fca9243ccc788190ca58d24f363cbe MD5 (8.0-RC3-ia64-dvd1.iso) = 4e24736ab50bc2227c72dbeab6869266 MD5 (8.0-RC3-ia64-livefs.iso) = b6d76cf77ed714631bf714ff78b8e950 MD5 (8.0-RC3-pc98-bootonly.iso) = 137d17ec3830b6ae831b6fb48adf86e0 MD5 (8.0-RC3-pc98-disc1.iso) = 3624b1f7b3a659a7454718e38b9a1ee0 MD5 (8.0-RC3-pc98-livefs.iso) = 29ed3786b2df1c2e72e45d1187f3e788 MD5 (8.0-RC3-powerpc-bootonly.iso) = e7d8508639dee4aed5e52a24d6e27b69 MD5 (8.0-RC3-powerpc-disc1.iso) = 1016ae7753db153b7be0f5d167f595b9 MD5 (8.0-RC3-powerpc-disc2.iso) = aec2400454631cc2eaecb6f618bfecc8 MD5 (8.0-RC3-powerpc-disc3.iso) = fe36d621ad4b6347f8ade9800ccfab7b MD5 (8.0-RC3-sparc64-bootonly.iso) = c35ddcb4dd050c793d89973eba02df72 MD5 (8.0-RC3-sparc64-disc1.iso) = 0d3855603ac868609fb882c321555508 MD5 (8.0-RC3-sparc64-dvd1.iso) = 7a402ec8d17804bd6d16fad0969c9e52 MD5 (8.0-RC3-sparc64-livefs.iso) = 61c90ecce584c0c91f91e744f40a7d42 SHA256 (8.0-RC3-amd64-bootonly.iso) = fbf7c68cf81c300ec4e944ed6491f65d217168a85c1863c019cb41eec30cae94 SHA256 (8.0-RC3-amd64-disc1.iso) = 7e377f38cb6dc0ba1aa1fa13facf7e03f3cefad3d1490de797ed3a91680892e8 SHA256 (8.0-RC3-amd64-dvd1.iso) = fa4671d9b9b5b8208579d51cc2f72188a9537984ee28ba851236a52f32022597 SHA256 (8.0-RC3-amd64-livefs.iso) = c8c3728583b43e76d5e305b20fed578474adb5b14dbf2537b8ca9156b2d1c4cd SHA256 (8.0-RC3-amd64-memstick.img) = b8d90dbfca07160d9818bf6705b5dd99ba25fe1624cdda3f3f4919681d1b1af1 SHA256 (8.0-RC3-i386-bootonly.iso) = f514dbec335fbf72917b25c1e79f6bca4e9dd74e037f75ab30d810e7942ac2fc SHA256 (8.0-RC3-i386-disc1.iso) = 6b306af4a74df57d2c155891557878d747bac92a24c2b46947f89e7d9657addc SHA256 (8.0-RC3-i386-dvd1.iso) = 21794b11142eeb7eb56c8810b83dcd67230b0d26a0f0e5839866172d977a5626 SHA256 (8.0-RC3-i386-livefs.iso) = 3dfd45e0a5550913b29d19d989f19167159d1f926f1667d1622890a5f83be93b SHA256 (8.0-RC3-i386-memstick.img) = afc65bf14101ace1f069323678a8070ab84823bf191aeefa8fc9909d38e9306e SHA256 (8.0-RC3-ia64-bootonly.iso) = 1fefdd0b03c943162cbb66d507e11c3a2e541e97a0742471de49f17ae96b953c SHA256 (8.0-RC3-ia64-disc1.iso) = 67124c8101dd3fb06dbd3771c3eb18560207b42e46c331cc2ab02ba5284a72b7 SHA256 (8.0-RC3-ia64-disc2.iso) = 4eaa1125f98c5ed463f7577b9818dd57dbaee0bad01a1c7543ad4cc89c1770d0 SHA256 (8.0-RC3-ia64-disc3.iso) = c178a48004a12d6f178b478da146582742a88a27fcbf380029ae7fb3f6db6472 SHA256 (8.0-RC3-ia64-dvd1.iso) = d45a8e6ae622c1985d5b9c346c74f44884f3adba3c02d0b69bb58f19b359fa73 SHA256 (8.0-RC3-ia64-livefs.iso) = 9132340e15b75601017b0b57902fa48926e1d1a257f1f5149baa07c15e0dede8 SHA256 (8.0-RC3-pc98-bootonly.iso) = 42beee44af5859861718978a03de04e6a6fd0e63afec66a939830286fb73b22a SHA256 (8.0-RC3-pc98-disc1.iso) = 4b00447579349443d80082d1809b0d04688ea317a9bee3f551c13a35c82c549d SHA256 (8.0-RC3-pc98-livefs.iso) = 243306c98a9eade16d90994217fd89f0aba51cfd8399b1017754a3415f2e79e8 SHA256 (8.0-RC3-powerpc-bootonly.iso) = 4cfbcac5fc69bb10860ed2c511bcf175be730c2fd11e57ccd2c8c77322ea5172 SHA256 (8.0-RC3-powerpc-disc1.iso) = 6d7725d24c01d985590566eb168cde1e6d334a3cdc6bdc7a4508ea54c205c489 SHA256 (8.0-RC3-powerpc-disc2.iso) = ecfd22166dd411359d74a61c1724cfa747e4a7e9cb8b47776643795f6388942b SHA256 (8.0-RC3-powerpc-disc3.iso) = fc3c0c2823b36cc6530c7afdb73dbfa3cb1bf6a64a59fd4a55307e1e4d1541fe SHA256 (8.0-RC3-sparc64-bootonly.iso) = 44a641e1f3080112d6063f923d1e5d17f9d9eedd1004888aace77e08beca2fdf SHA256 (8.0-RC3-sparc64-disc1.iso) = e68eec5765f9313a9cbe4e94915b89d68caa4f4f65884be9e7b1d463862c17e3 SHA256 (8.0-RC3-sparc64-dvd1.iso) = e824cc316c520d29673c51e5ccf58aba9a79b17e7b61b67c1d13da7300911f7b SHA256 (8.0-RC3-sparc64-livefs.iso) = a4f0f8f02a9b1bad01088f5cb81a9a4d93ef6aad095afdd79cb5525b4a1e53b5 -- Ken Smith - From there to here, from here to | kensmith@buffalo.edu there, funny things are everywhere. | - Theodore Geisel | -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091112/94bbbc6a/attachment.pgp From dhorn2000 at gmail.com Thu Nov 12 15:57:12 2009 From: dhorn2000 at gmail.com (David Horn) Date: Thu Nov 12 15:57:34 2009 Subject: Current 9 freeze after ATA PseudoRAID loaded on AMD64 smp during boot In-Reply-To: <20091112152603.GI2331@deviant.kiev.zoral.com.ua> References: <25ff90d60911120721h5921b515jca4ba41c56f2f38f@mail.gmail.com> <20091112152603.GI2331@deviant.kiev.zoral.com.ua> Message-ID: <25ff90d60911120757l467c1018g237a3bc7eacae9d0@mail.gmail.com> On Thu, Nov 12, 2009 at 10:26 AM, Kostik Belousov wrote: > On Thu, Nov 12, 2009 at 10:21:38AM -0500, David Horn wrote: >> On Thu, Nov 12, 2009 at 9:52 AM, Alireza Torabi >> wrote: >> > Oh, I've tried the BIOS SATA in ATA, AHCI and IRRT (Intel Rapid >> > Restore Technology). >> > >> > This box had a customised 9 kernel quite happily in IRRT before the >> > csup I should add. The SATA is Intel ICH9 btw. >> > >> > On 11/12/09, Alireza Torabi wrote: >> >> Hi folks, >> >> >> >> My FreeBSD current (just csup-ed now: 12 Nov 2009) freezes after "ATA >> >> PseduoRAID loaded" message during boot. Nothing happens after that and >> >> I need to do a cold reboot. >> >> >> >> I've tried the GENERIC kernel with no joy :( >> >> >> >> Any leads or ideas is truly appreciated. >> >> >> >> Thanks >> >> Alireza >> >> >> >> Sounds like the same problem I have. ?If you try backing out to SVN >> r199066 or CVS version 1.56 (sys/amd64/amd64/initcpu.c), you can >> confirm. > > Better, try > http://people.freebsd.org/~kib/misc/initcache.2.patch > Patch works great for me. (generic kernel, amd64 on c2d T7500). Thanks Kostik! ---Dave Horn From atkin901 at gmail.com Thu Nov 12 15:58:12 2009 From: atkin901 at gmail.com (Mark Atkinson) Date: Thu Nov 12 15:58:19 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <4AFC14BE.7020106@icyb.net.ua> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> <941257966918@webmail42.yandex.ru> <4AFC14BE.7020106@icyb.net.ua> Message-ID: Andriy Gapon wrote: > on 11/11/2009 22:13 Mark Atkinson said the following: >> Well, you're about at the point I am now with my HP dl385g5, only >> turning off superpages would result in a successful buildworld. Mine >> would often machine check during gas compilation as well. > > Mark, > > you mentioning MCA was magic moment for me. > I was debugging a problem which seemed to be quite different, but now I think that > it converges to the problem discussed in this thread (if indeed it's the same > problem for all reporters). I'm not sure it's exactly the same. I only know a couple of things - my memory tests good. - turning off superpages allows this machine to function properly. I suspect there's a problem with one of the following: - the bios of my machine - the on die memory controller/intructions of the cpu - the motherboard electrical interface to memory or bus in some shape or form. > Or perhaps there is something like Event Log in BIOS. Maybe it > even gets something useful. > Could you please check? Yes. When you receive a MCE on the HP machines the bios notices and prints a message on the next bootup, something like "an unhandled memory error has occured since last power on." In my current job, which works with hardware, we'll occasionally see MCEs during development. It's easy to say the memory is bad, and it is the first thing we replace to test. However it can also be the electrical interface to the hardware which may or may not be fixable/worked around in firmware. I have also witnessed the software initializing or controlling the hardware may result in a unhandled condition spurring an MCE. > About my problem - it seems that I was working from the opposite end. I have been > using head/CURRENT with pg_ps_enabled=1 for quite a while now. And then I decided > to try hw.mca.enabled=1 and after that I started having the same symptoms as > described here. Unfortunately, I never did get Machine Check trap, it's always > something that looks like CPU halt and then reset by watchdog (if it is enabled). > So, for me: > superpages and no machine check - works > machine check and no superpages - works > machine check and superpages - problem That's not quite the same for sure, definitely try replacing the memory first if you haven't already. All the best, Mark From serguey-grigoriev at yandex.ru Thu Nov 12 16:34:09 2009 From: serguey-grigoriev at yandex.ru (S.N.Grigoriev) Date: Thu Nov 12 16:34:16 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <4AFC0F6A.3000501@icyb.net.ua> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> <941257966918@webmail42.yandex.ru> <4AFC0F6A.3000501@icyb.net.ua> Message-ID: <36041258043646@webmail59.yandex.ru> 12.11.09, 15:36, "Andriy Gapon" wrote: > Serguey, > are you sure that setting vm.pmap.pg_ps_enabled=0 doesn't help you? > I know that already asked you this once. > But, could you please try again with vm.pmap.pg_ps_enabled=0 and hw.mca.enabled=1 > and see what kind of behavior you get? > I am curious what would happen, would it be the same kind of machine check condition. Andriy, I've done the world compilation with 'vm.pmap.pg_ps_enabled=0'. The first attempt has finished with silent reboot. The second one has been captured by the debugger: panic: backgroundwritedone: lost buffer cpuid = 0 KDB: enter: panic [thread pid 3 tid 100014 ] Stopped at breakpoint+0x5: leave -- Regards, S.Grigoriev. From jhb at freebsd.org Thu Nov 12 16:45:59 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Nov 12 16:46:06 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091111231753.GA52833@dmr.ath.cx> References: <20091106101943.5a763f43@ernst.jennejohn.org> <20091111231753.GA52833@dmr.ath.cx> Message-ID: <200911121133.30784.jhb@freebsd.org> On Wednesday 11 November 2009 6:17:53 pm Emil Mikulic wrote: > On Tue, Nov 10, 2009 at 09:15:42AM -0800, Mark Atkinson wrote: > > Also, you can try adding: > > > > hw.mca.enabled="1" in /boot/loader.conf > > This is a little off-topic, but: > Why is this disabled by default in FreeBSD? Because it is still a new feature and on some machines it causes panics/freezes out of the box. I'd be happier turning it on once it has been tested more and once we've figured out the reasons for the various freezes, etc. that seem to be related to enabling it. -- John Baldwin From codestr0m at osunix.org Thu Nov 12 14:52:13 2009 From: codestr0m at osunix.org (=?ISO-8859-1?Q?=22C=2E_Bergstr=F6m=22?=) Date: Thu Nov 12 16:50:27 2009 Subject: compiler discussion In-Reply-To: <20091112141519.GA66229@mech-cluster241.men.bris.ac.uk> References: <20091112141519.GA66229@mech-cluster241.men.bris.ac.uk> Message-ID: <4AFC1D0F.1020805@osunix.org> Anton Shterenlikht wrote: > Following from the discussion on the system compiler for ia64, > I tried to list few major ports which I'd love to have on ia64, > but can't, because of GCC problems: > > - math/blas, lapack, lapack95, arpack, scalapack, atlas, etc. > - science/hdf5-18 (fortran APIs can't be built) > - french/aster (industial quality FEA code) > - cad/calculix (another good FEA code) > > All these depend on lang/gcc44, which doesn't build. > > The only fortran compiler I know to build and work > successfully on ia64 is (correct me if I'm wrong) g95. > > I wonder if it's possible/desirable/easy to use lang/g95 for > the above and other fortran-dependent ports? > > In principal, lang/g95 looks very good, and it's got > some features not available in gfortran, e.g. limited > support for 2003 standard. > > Any comments? > > Lots, but the main is that I don't think the g95 developer is still active. Please ping Andy and if you do get a response let me know. From mexas at bristol.ac.uk Thu Nov 12 16:52:14 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Nov 12 16:52:27 2009 Subject: compiler discussion In-Reply-To: <20091112153407.GA62396@troutmask.apl.washington.edu> References: <20091112141519.GA66229@mech-cluster241.men.bris.ac.uk> <20091112153407.GA62396@troutmask.apl.washington.edu> Message-ID: <20091112165208.GC1283@mech-cluster241.men.bris.ac.uk> On Thu, Nov 12, 2009 at 07:34:07AM -0800, Steve Kargl wrote: > On Thu, Nov 12, 2009 at 02:15:19PM +0000, Anton Shterenlikht wrote: > > Following from the discussion on the system compiler for ia64, > > I tried to list few major ports which I'd love to have on ia64, > > but can't, because of GCC problems: > > > > - math/blas, lapack, lapack95, arpack, scalapack, atlas, etc. > > - science/hdf5-18 (fortran APIs can't be built) > > - french/aster (industial quality FEA code) > > - cad/calculix (another good FEA code) > > > > All these depend on lang/gcc44, which doesn't build. > > Doesn't build is not a very good description if you're > looking for help. Post the build log somewhere. > Have you submitted bug reports to gcc.gnu.org? Bugs > that are unreported are unlikely to be fixed. sorry, I thought it was a known issue. Here's my bug report: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959 I admit, I haven't checked the suggested patch yet.. > Have you checked the Open64 project? will do many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From rmacklem at uoguelph.ca Thu Nov 12 16:55:22 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Thu Nov 12 16:55:29 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> Message-ID: On Wed, 11 Nov 2009, Ivan Voras wrote: > > I think NFS uses sync disk IO access by default, this may be your > problem if you are write-heavy. Try setting vfs.nfsrv.async to 1 to > see if this is the cause of your problems. Just fyi, I took a quick look and I don't think this will be a good idea for NFSv3. (It allows the server to cheat for NFSv2 and avoid synchronous writes, which was contrary to the standard, but became fashionable for performance reasons, before NFSv3 came out.) For NFSv3, the writes are normally done asynchronously, followed by a Commit RPC to force them to disk, done by the client when it is flushing its buffer cache. When you set this sysctl, the NFSv3 server (sys/nfsserver, not the experimental one), all it does is reply to the write RPC that it has already been committed. This may have two effects, depending upon the client: 1 - The client may then choose to not bother with a Commit RPC. --> This shouldn't help performance much, because the data will normally have made to disk by now. *** This might be an interesting experiment to try on a ZFS server though, since if it does make a significant difference, it suggests that ZFS does a lot of work figuring out that the blocks are already on stable storage or something like that. (ie. It might hint at where to look for a ZFS related perf. problem.) OR 2 - Nothing, because the client doesn't notice it doesn't need to commit it and does the Commit RPC anyhow. Also, it is potentially dangerous, since if the server crashes after the client has done the write, but before the server has written it to disk, the data may be lost. (ie. The client might have flushed the dirty blocks out of its buffer cache, because it didn't think it needed to do a Commit RPC.) rick From mexas at bristol.ac.uk Thu Nov 12 17:03:21 2009 From: mexas at bristol.ac.uk (Anton Shterenlikht) Date: Thu Nov 12 17:03:28 2009 Subject: konqueror causes panic on ia64 current Message-ID: <20091112170222.GA1426@mech-cluster241.men.bris.ac.uk> on ia64 current, kern.osrevision: 199506, I've built kdebase-4.3.1_1. Lanching konqueror caused panic after about 5 mouse clicks. What I've recovered is below. I can try to repeat it, and collect a full crash dump if it's of any use. anton ############################# cpu_thread_exit(0xe000000019fcee40, 0xe0000000043b30c0, 0x50e, 0x163) at cpu_thread_exit+0x20 thread_exit(0xe00000000483d1f8, 0xe00000000483be40, 0xe000000011713a58, 0xe000000019fcee40) at threa d_exit+0x130 thr_exit(0xe0000000117139d0, 0xe000000011713aa8, 0xe00000000483d1d0, 0xe0000000117139b0) at thr_exit +0x120 syscall(0xa0000000c3b0f400, 0x1af, 0x2000000043aa67f0, 0xe000000019fcee40, 0xe0000000117139b0, 0xe00 00000049396f8, 0x1af, 0xa0000000c3b0f4e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return KDB: enter: panic [thread pid 72526 tid 100179 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe1f3c8,gp ;; db> db> panic boot(0x104, 0xe00000000483bbd8, 0xe000000004396170, 0x793) at boot+0x70 panic(0xe00000000480eb50) at panic+0x350 db_panic(0xe00000000413d5d0, 0x40c, 0xffffffffffffffff) at db_panic+0x40 db_command(0xe000000004988118, 0x0, 0x1) at db_command+0x750 db_command_loop(0xe000000004988140, 0xe000000004988110, 0xe000000004988118, 0xe00000000480ec00) at d b_command_loop+0xf0 db_trap(0xb, 0xe0000000043f9e60) at db_trap+0x2b0 kdb_trap(0xb, 0x0, 0xa0000000c3b0f000, 0x1, 0x10080a2010, 0xe0000000047e9640, 0x716, 0xe000000004b69 b80) at kdb_trap+0x200 trap(0xb, 0xa0000000c3b0f000) at trap+0x7c0 ivt_Break_Instruction() at ivt_Break_Instruction+0x40 --- trapframe at 0xa0000000c3b0f000 kdb_enter(0xe00000000483bd90, 0xe00000000483bd90, 0xe000000004396120, 0x793) at kdb_enter+0xa0 panic(0xe000000004874470, 0x0, 0xe000000004874448, 0x5d3) at panic+0x2f0 ia64_highfp_drop(0xe000000019fcee40) at ia64_highfp_drop+0x100 cpu_thread_exit(0xe000000019fcee40, 0xe0000000043b30c0, 0x50e, 0x163) at cpu_thread_exit+0x20 thread_exit(0xe00000000483d1f8, 0xe00000000483be40, 0xe000000011713a58, 0xe000000019fcee40) at threa d_exit+0x130 thr_exit(0xe0000000117139d0, 0xe000000011713aa8, 0xe00000000483d1d0, 0xe0000000117139b0) at thr_exit +0x120 syscall(0xa0000000c3b0f400, 0x1af, 0x2000000043aa67f0, 0xe000000019fcee40, 0xe0000000117139b0, 0xe00 00000049396f8, 0x1af, 0xa0000000c3b0f4e8) at syscall+0x3e0 epc_syscall_return() at epc_syscall_return db> -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From gary.jennejohn at freenet.de Thu Nov 12 17:28:28 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Thu Nov 12 17:28:35 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <200911121133.30784.jhb@freebsd.org> References: <20091106101943.5a763f43@ernst.jennejohn.org> <20091111231753.GA52833@dmr.ath.cx> <200911121133.30784.jhb@freebsd.org> Message-ID: <20091112182825.73b0079c@ernst.jennejohn.org> On Thu, 12 Nov 2009 11:33:30 -0500 John Baldwin wrote: > On Wednesday 11 November 2009 6:17:53 pm Emil Mikulic wrote: > > On Tue, Nov 10, 2009 at 09:15:42AM -0800, Mark Atkinson wrote: > > > Also, you can try adding: > > > > > > hw.mca.enabled="1" in /boot/loader.conf > > > > This is a little off-topic, but: > > Why is this disabled by default in FreeBSD? > > Because it is still a new feature and on some machines it causes > panics/freezes out of the box. I'd be happier turning it on once it has been > tested more and once we've figured out the reasons for the various freezes, > etc. that seem to be related to enabling it. > A safer way to test this is to enter set hw.mca.enabled="1" on the loader command line rather than putting it into loader.conf. I just did this on my "consumer" AMD64 board without ill effect. --- Gary Jennejohn From jfvogel at gmail.com Thu Nov 12 17:38:53 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Nov 12 17:39:02 2009 Subject: page fault in igb driver on 8.0-RC2 In-Reply-To: <200911121529.nACFT8ad037531@lava.sentex.ca> References: <20091017222314.GB19204@michelle.cdnetworks.com> <200911100021.nAA0LvMG014534@lava.sentex.ca> <2a41acea0911091633u2899b47ewb514b6276ba2cf62@mail.gmail.com> <200911100227.nAA2RtDY015177@lava.sentex.ca> <2a41acea0911101057q4f913e30m9319e52bbd254cfe@mail.gmail.com> <2a41acea0911101120o39fd695cpa325736d00b11587@mail.gmail.com> <200911102018.nAAKI3s7021614@lava.sentex.ca> <20091111203101.GC15449@michelle.cdnetworks.com> <2a41acea0911111419v5ae5682cy12613e1bd9a9c325@mail.gmail.com> <200911121529.nACFT8ad037531@lava.sentex.ca> Message-ID: <2a41acea0911120938g60de3ff0o6fbca1c06bdeb7a3@mail.gmail.com> The storm threshold is a tuneable, like for 10G the default (1000) is guaranteed to be too low, we usually up it to 10000 in our lab. In this case its not indicative of a problem so just increase until it does not throttle the source. Jack On Thu, Nov 12, 2009 at 7:28 AM, Mike Tancsa wrote: > At 05:19 PM 11/11/2009, Jack Vogel wrote: > > Ya, so maybe a more robust solution to that failure would be a good >> thing, but this is not the time for more elaborate code, having this small >> fix put in is low risk and the better failure response can come later. >> >> In fact, I have a number of places in the ixgbe driver where I'm pondering >> over what to do in failure mode anyway. >> > > [trimming re@freebsd as this isnt a release issue] > > No panics yet, but at around 350k pps, I see > > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > interrupt storm detected on "irq257:"; throttling interrupt source > > 0(ich10)# vmstat -i > interrupt total rate > irq16: uhci0+ 22 0 > irq18: ehci0 uhci5 15 0 > irq19: fwohci0++ 78 0 > irq21: uhci1 17 0 > irq23: uhci3 ehci1 2 0 > cpu0: timer 175404021 1998 > irq256: igb0 19731770 224 > irq257: igb0 30741918 350 > irq258: igb0 14 0 > irq259: igb1 71514077 814 > irq260: igb1 28098687 320 > irq261: igb1 2 0 > irq262: em0 4435336 50 > irq263: ahci0 89527 1 > cpu7: timer 175395421 1998 > cpu6: timer 175394148 1998 > cpu1: timer 175395011 1998 > cpu4: timer 175394583 1998 > cpu5: timer 175395129 1998 > cpu3: timer 175395466 1998 > cpu2: timer 175394884 1998 > Total 1557780128 17749 > 0(ich10)# > > > > > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > From gallasch at free.de Thu Nov 12 18:13:47 2009 From: gallasch at free.de (Kai Gallasch) Date: Thu Nov 12 18:13:55 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <4AFC14BE.7020106@icyb.net.ua> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> <941257966918@webmail42.yandex.ru> <4AFC14BE.7020106@icyb.net.ua> Message-ID: <20091112191344.09ccaff9@orwell.free.de> Am Thu, 12 Nov 2009 15:59:26 +0200 schrieb Andriy Gapon : > on 11/11/2009 22:13 Mark Atkinson said the following: > > > > Well, you're about at the point I am now with my HP dl385g5, only > > turning off superpages would result in a successful buildworld. > > Mine would often machine check during gas compilation as well. > > Mark, > > you mentioning MCA was magic moment for me. > I was debugging a problem which seemed to be quite different, but now > I think that it converges to the problem discussed in this thread (if > indeed it's the same problem for all reporters). > The difference is that I use a "consumer level" system based on > family 10h Athlon II and you use Opterons, seemingly also 10h or Fh > families. I guess that means that you and Kai both use "high > end"/"server grade" systems or some such. It's possible that > firmware/BIOS on your systems enables and monitors MCA by default, > even when the OS is not MCA-enabled. As such, I am curious if you > have any BIOS settings that look like being related to Machine > Check. Or perhaps there is something like Event Log in BIOS. Maybe > it even gets something useful. Could you please check? Hi. Here is one BIOS options on my server that is of possible interest to this kind of problem: Advanced Options -> Processor Options: No-Execute Page-Protection (DISABLED) "Enables the HW portion of a feature that allows systems to be protected against malicious code and viruses. In combination with an OS that supports this feature, memory is marked as non-executable unless the location explicitly contains executable code. Some viruses attempt to insert and execute code from non-executable memory locations. These attacks are intercepted and an exception is raised." --Kai. From sfourman at gmail.com Thu Nov 12 18:44:11 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Thu Nov 12 18:44:19 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> Message-ID: <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> On Thu, Nov 12, 2009 at 11:02 AM, Rick Macklem wrote: > > > On Wed, 11 Nov 2009, Ivan Voras wrote: > >> >> I think NFS uses sync disk IO access by default, this may be your >> problem if you are write-heavy. Try setting vfs.nfsrv.async to 1 to >> see if this is the cause of your problems. > > Just fyi, I took a quick look and I don't think this will be a good > idea for NFSv3. (It allows the server to cheat for NFSv2 and avoid > synchronous writes, which was contrary to the standard, but became > fashionable for performance reasons, before NFSv3 came out.) > > For NFSv3, the writes are normally done asynchronously, followed > by a Commit RPC to force them to disk, done by the client when it > is flushing its buffer cache. > > When you set this sysctl, the NFSv3 server (sys/nfsserver, not the > experimental one), all it does is reply to the write RPC that it > has already been committed. This may have two effects, depending > upon the client: > 1 - The client may then choose to not bother with a Commit RPC. > ? ?--> This shouldn't help performance much, because the data > ? ? ? ?will normally have made to disk by now. > *** This might be an interesting experiment to try on a ZFS server > ? ?though, since if it does make a significant difference, it > ? ?suggests that ZFS does a lot of work figuring out that the > ? ?blocks are already on stable storage or something like that. > ? ?(ie. It might hint at where to look for a ZFS related perf. > ? ? problem.) > OR > 2 - Nothing, because the client doesn't notice it doesn't need to > ? ?commit it and does the Commit RPC anyhow. > > Also, it is potentially dangerous, since if the server crashes after > the client has done the write, but before the server has written it > to disk, the data may be lost. (ie. The client might have flushed the > dirty blocks out of its buffer cache, because it didn't think it needed > to do a Commit RPC.) > > rick I guess I am confused a bit. Why is it that sftp has better write speed than NFS? and from what I am hearing there isn't a good way to fox it? what about if I try and tweak the nfs connection paramaters. all of these tests were done with whatever default is. anyone have any Ideas on better client connection parameters? Sam Fourman Jr. From sullrich at gmail.com Thu Nov 12 18:48:50 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Thu Nov 12 18:48:56 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> Message-ID: On Thu, Nov 12, 2009 at 1:44 PM, Sam Fourman Jr. wrote: > I guess I am confused a bit. > Why is it that sftp has better write speed than NFS? and from what I > am hearing there isn't a good way to fox it? > what about if I try and tweak the nfs connection paramaters. all of > these tests were done with whatever default is. > > anyone have any Ideas on better client connection parameters? Sam, might want to take a look at my thread on freebsd-fs titled "Slow disk write IO with ZFS / NFS". Scott From avg at icyb.net.ua Thu Nov 12 18:52:15 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Nov 12 18:52:22 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091112182825.73b0079c@ernst.jennejohn.org> References: <20091106101943.5a763f43@ernst.jennejohn.org> <20091111231753.GA52833@dmr.ath.cx> <200911121133.30784.jhb@freebsd.org> <20091112182825.73b0079c@ernst.jennejohn.org> Message-ID: <4AFC595A.8050703@icyb.net.ua> on 12/11/2009 19:28 Gary Jennejohn said the following: > > A safer way to test this is to enter > set hw.mca.enabled="1" > on the loader command line rather than putting it into loader.conf. > > I just did this on my "consumer" AMD64 board without ill effect. What CPU do you have, could you provide its description from dmesg? Did you stress-tested it enough (like parallel buildworld)? -- Andriy Gapon From gallasch at free.de Thu Nov 12 18:59:35 2009 From: gallasch at free.de (Kai Gallasch) Date: Thu Nov 12 18:59:43 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <200911111504.14906.jhb@freebsd.org> References: <1031257439203@webmail57.yandex.ru> <941257966918@webmail42.yandex.ru> <200911111504.14906.jhb@freebsd.org> Message-ID: <20091112195932.5875387e@orwell.free.de> Am Wed, 11 Nov 2009 15:04:14 -0500 schrieb John Baldwin : > On Wednesday 11 November 2009 2:15:18 pm S.N.Grigoriev wrote: > > > > 10.11.09, 09:15, "Mark Atkinson" > > wrote: > > > > > Andriy Gapon wrote: > > > > on 10/11/2009 17:22 gary.jennejohn@freenet.de said the > > > > following: > > > > Not a trivial issue unless it is hardware indeed. > > > > > > > Also, you can try adding: > > > hw.mca.enabled="1" in /boot/loader.conf, reboot, and then see if > > > there is a machine check exception on the console during the > > > buildworld. > > > > Mark, > > > > I've added hw.mca.enabled="1" in /boot/loader.conf and got the > > following screen during the buildworld: > > > > ..... > > -c /usr/src/gnu/usr.bin/binutils/as/../../../../contrib/binutils/gas/sb.c > > > > MCA: CPU3 UNCOR PCC OVER DTLIB L1 error > > MCA: Address 0x8015fb000 > > You hardware is broken and it is telling you so. You have had > multiple machine checks with the most severe one being an > uncorrectable error in your data TLB (i.e. in the CPU itself). John, I also set hw.mca.enabled="1" and vm.pmap.pg_ps_enabled="1" in /boot/loader.conf on my (under load) spontaneously rebooting opteron proliant server. Server was upgraded to FREEBSD-8.0-PRERELEASE today. This is what happened.. ---- machine check trap, first run ---- sonnenkraft:/usr/obj # MCA: CPU 5 UNCOR PCC OVER DTLB L1 error MCA: Address 0x80e5c8000 Fatal trap 28: machine check trap while in user mode cpuid = 5; apic id = 05 instruction pointer = 0x43:0x691688 stack pointer = 0x3b:0x7fffffffdf90 frame pointer = 0x3b:0x6a2 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 3, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 29319 (cc1) [thread pid 29319 tid 100086 ] Stopped at 0x691688: leal 0x1(%rax),%edx db> where Tracing pid 29319 tid 100086 td 0xffffff000e065390 WAKEUP_cpu() at 0x691688 *** error reading from address 6aa *** db> bt Tracing pid 29319 tid 100086 td 0xffffff000e065390 WAKEUP_cpu() at 0x691688 *** error reading from address 6aa *** db> call doadump Cannot dump. Device not defined or unavailable. = 0x30 ---- machine check trap, second run - this time with dumpdev defined ---- sonnenkraft:~ # MCA: CPU 2 UNCOR PCC OVER DTLB L1 error MCA: Address 0x8011d3000 Fatal trap 28: machine check trap while in user mode cpuid = 2; apic id = 02 instruction pointer = 0x43:0x6b1241 stack pointer = 0x3b:0x7fffffffe200 frame pointer = 0x3b:0x7fffffffe240 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 3, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 69498 (cc1) [thread pid 69498 tid 100338 ] Stopped at 0x6b1241: call 0x6af140 db> where Tracing pid 69498 tid 100338 td 0xffffff000ef75720 WAKEUP_cpu() at 0x6b1241 db> bt Tracing pid 69498 tid 100338 td 0xffffff000ef75720 WAKEUP_cpu() at 0x6b1241 db> call doadump Physical memory: 20462 MB Dumping 2303 MB: 2288 2272 2256 2240 2224 2208 2192 2176 2160 2144 2128 2112 2096 2080 2064 2048 2032 2016 2000 1984 1968 1952 1936 1920 1904 1888 1872 1856 1840 1824 1808 1792 1776 1760 1744 1728 1712 1696 1680 1664 1648 1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472 1456 1440 1424 1408 1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216 1200 1184 1168 1152 1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960 944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 Dump complete = 0 db> reboot cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 2 ---- machine check trap, third run - BIOS: static low power mode enabled, to rule out power/heat issue ---- sonnenkraft:~ # MCA: CPU 4 UNCOR PCC OVER DTLB L1 error MCA: Address 0x8011fd000 Fatal trap 28: machine check trap while in user mode cpuid = 4; apic id = 04 instruction pointer = 0x43:0x76127d stack pointer = 0x3b:0x7fffffffe068 frame pointer = 0x3b:0x7fffffffe090 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 3, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 73135 (cc1) [thread pid 73135 tid 100146 ] Stopped at 0x76127d: xorl %edx,%edx db> where Tracing pid 73135 tid 100146 td 0xffffff00071caab0 WAKEUP_cpu() at 0x76127d db> bt Tracing pid 73135 tid 100146 td 0xffffff00071caab0 WAKEUP_cpu() at 0x76127d db> call doadump Physical memory: 20462 MB Dumping 2335 MB: 2320 2304 2288 2272 2256 2240 2224 2208 2192 2176 2160 2144 2128 2112 2096 2080 2064 2048 2032 2016 2000 1984 1968 1952 1936 1920 1904 1888 1872 1856 1840 1824 1808 1792 1776 1760 1744 1728 1712 1696 1680 1664 1648 1632 1616 1600 1584 1568 1552 1536 1520 1504 1488 1472 1456 1440 1424 1408 1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216 1200 1184 1168 1152 1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960 944 928 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 608 592 576 560 544 528 512 496 480 464 448 432 416 400 384 368 352 336 320 304 288 272 256 240 224 208 192 176 160 144 128 112 96 80 64 48 32 16 Dump complete = 0 db> reboot cpu_reset: Restarting BSP cpu_reset_proxy: Stopped CPU 4 ---- END: ---- What hardware parts are defective and need replacement? CPU, memory or mainboard? I now have two vmcore's + crashinfo core.txt available on the server. Are they of any use to get further information? --Kai. -- Draft beer, not people. From sfourman at gmail.com Thu Nov 12 19:01:48 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Thu Nov 12 19:01:54 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> Message-ID: <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> On Thu, Nov 12, 2009 at 12:48 PM, Scott Ullrich wrote: > On Thu, Nov 12, 2009 at 1:44 PM, Sam Fourman Jr. wrote: >> I guess I am confused a bit. >> Why is it that sftp has better write speed than NFS? and from what I >> am hearing there isn't a good way to fox it? >> what about if I try and tweak the nfs connection paramaters. all of >> these tests were done with whatever default is. >> >> anyone have any Ideas on better client connection parameters? > > Sam, might want to take a look at my thread on freebsd-fs titled "Slow > disk write IO with ZFS / NFS". > > Scott ---paste from Slow disk write IO with ZFS / NFS -------- Failing that, Add a log device to the pool, SSD or ramdisk is ideal, but separate disk HDD spindles to your data zpool also works pretty well. ----------- is there anyway to safely have a log device on a ramdisk? I would assume not. Does anyone have a link to a how to for putting the ZFS log device on seprate disk spindles? Sam Fourman From des at des.no Thu Nov 12 19:29:52 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Nov 12 19:29:58 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> (Sam Fourman, Jr.'s message of "Thu, 12 Nov 2009 13:01:45 -0600") References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> Message-ID: <86eio3czip.fsf@ds4.des.no> "Sam Fourman Jr." writes: > is there anyway to safely have a log device on a ramdisk? Uh, no. > Does anyone have a link to a how to for putting the ZFS log device on > seprate disk spindles? % sudo zpool add pool_name log device_name DES -- Dag-Erling Sm?rgrav - des@des.no From xcllnt at mac.com Thu Nov 12 19:38:40 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Nov 12 19:38:52 2009 Subject: konqueror causes panic on ia64 current In-Reply-To: <20091112170222.GA1426@mech-cluster241.men.bris.ac.uk> References: <20091112170222.GA1426@mech-cluster241.men.bris.ac.uk> Message-ID: <14DDE756-9E12-4EF8-8A17-8883738874A1@mac.com> On Nov 12, 2009, at 9:02 AM, Anton Shterenlikht wrote: > on ia64 current, kern.osrevision: 199506, I've built > kdebase-4.3.1_1. Lanching konqueror caused panic after > about 5 mouse clicks. What I've recovered is below. Please update your sources. This problem is fixed. FYI, -- Marcel Moolenaar xcllnt@mac.com From gary.jennejohn at freenet.de Thu Nov 12 19:48:08 2009 From: gary.jennejohn at freenet.de (Gary Jennejohn) Date: Thu Nov 12 19:48:15 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <4AFC595A.8050703@icyb.net.ua> References: <20091106101943.5a763f43@ernst.jennejohn.org> <20091111231753.GA52833@dmr.ath.cx> <200911121133.30784.jhb@freebsd.org> <20091112182825.73b0079c@ernst.jennejohn.org> <4AFC595A.8050703@icyb.net.ua> Message-ID: <20091112204805.6ea0247f@ernst.jennejohn.org> On Thu, 12 Nov 2009 20:52:10 +0200 Andriy Gapon wrote: > on 12/11/2009 19:28 Gary Jennejohn said the following: > > > > A safer way to test this is to enter > > set hw.mca.enabled="1" > > on the loader command line rather than putting it into loader.conf. > > > > I just did this on my "consumer" AMD64 board without ill effect. > > What CPU do you have, could you provide its description from dmesg? > Did you stress-tested it enough (like parallel buildworld)? > I did about 1/2 of a parallel build world (-j3) and then stopped it. I figured, if it lasts that long, it should make it all the way through. CPU: AMD Athlon(tm) Dual Core Processor 4850e (2505.35-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f TSC: P-state invariant --- Gary Jennejohn From fbsdlist at src.cx Thu Nov 12 20:19:41 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Thu Nov 12 20:19:47 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> Message-ID: > is there anyway to safely have a log device on a ramdisk? I would assume not. Log seems to be somewhat weak point in ZFS. If you lose your log device, you will lose your pool. Plus, there's no way to remove log device from the pool. So, once you attach some device as a log, you'd better be sure that device does not disappear, because it will take the rest of the pool with it. From that point, real ram-disk (i.e. /dev/mdN) is definitely a recipe for disaster. External ramdisk with a battery backup may be an option, but even in mirrored configuration seems rather risky to me. http://jmlittle.blogspot.com/2008/05/problem-with-slogs-how-i-lost.html I'd say that SSD are probably the best fit for slog role. --Artem From des at des.no Thu Nov 12 20:34:57 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Nov 12 20:35:04 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: (Artem Belevich's message of "Thu, 12 Nov 2009 12:19:39 -0800") References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> Message-ID: <86my2ro51s.fsf@ds4.des.no> Artem Belevich writes: > Log seems to be somewhat weak point in ZFS. If you lose your log > device, you will lose your pool. Plus, there's no way to remove log > device from the pool. The zpool(1M) manpage seems to disagree: Log devices can be added, replaced, attached, detached, and imported and exported as part of the larger pool. DES -- Dag-Erling Sm?rgrav - des@des.no From scf at FreeBSD.org Thu Nov 12 20:45:00 2009 From: scf at FreeBSD.org (Sean C. Farley) Date: Thu Nov 12 20:45:06 2009 Subject: geometry/media size does not match label messages Message-ID: I have an existing system running stable/7 and am preparing to upgrade it to stable/8 (as of r199085). The system has two slices mirrored. Upon booting from a Fixit disc, there are messages I see with stable/8 but not stable/7: GEOM: ad4s3: geometry does not match label (255h,63s != 16h,63s). GEOM: ad4s3: media size does not match label. GEOM: ad6s3: geometry does not match label (255h,63s != 16h,63s). GEOM: ad6s3: media size does not match label. This also occurs when having mirrored two freshly created slices (within VirtualBox), so it is not an existing issue seen from a newer kernel branch. I have a script[1] to perform the creation from the Fixit disc to show how I built the system. >From what I understand, these messages are due to the order GEOM tastes providers. Since mirrored slices may actually be from different drives and not match, I can see why the labels may not match. Should/could the tasting be adjusted to prevent these messages from appearing assuming everything is valid? It looks valid, yes? The swap slices using gpart or bsdlabel: Geom name: ad4s2 fwheads: 16 fwsectors: 63 last: 8388575 first: 0 entries: 8 scheme: BSD bytes/sector: 512 sectors/track: 63 tracks/cylinder: 16 sectors/cylinder: 1008 cylinders: 8322 sectors/unit: 8388576 ... 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 8388576 0 unused 0 0 # "raw" part, don't edit h: 8388560 16 swap Here is the slice from the mirror (or ad[46]s3 if preferred): Geom name: mirror/slice0 fwheads: 255 fwsectors: 63 last: 75497434 first: 0 entries: 8 scheme: BSD bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 4699 sectors/unit: 75497435 ... 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 4194304 16 4.2BSD 0 0 0 b: 4194304 4194320 4.2BSD 0 0 0 c: 75497435 0 unused 0 0 # "raw" part, don't edit d: 8388608 8388624 4.2BSD 0 0 0 e: 58720203 16777232 4.2BSD 0 0 0 Sean 1. http://people.freebsd.org/~scf/Install-gmirror-MBR.txt -- scf@FreeBSD.org From fbsdlist at src.cx Thu Nov 12 20:54:45 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Thu Nov 12 20:54:51 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <86my2ro51s.fsf@ds4.des.no> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> <86my2ro51s.fsf@ds4.des.no> Message-ID: 2009/11/12 Dag-Erling Sm?rgrav : > The zpool(1M) manpage seems to disagree: > > ? ? ? Log ?devices ?can ?be added, replaced, attached, detached, and imported > ? ? ? and exported as part of the larger pool. Solaris' man page has somewhat different wording -- it indicates that only part of mirrored log device can be removed. See http://docs.sun.com/app/docs/doc/819-2240/zpool-1m In any case the reality is that you can not remove log vdev from the pool: $ zpool status z1 pool: z1 state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM z1 ONLINE 0 0 0 mirror ONLINE 0 0 0 ada3p3 ONLINE 0 0 0 ada2p3 ONLINE 0 0 0 logs ONLINE 0 0 0 gpt/zil ONLINE 0 0 0 cache gpt/l2arc ONLINE 0 0 0 errors: No known data errors $ zpool remove z1 gpt/zil Password: cannot remove gpt/zil: only inactive hot spares or cache devices can be removed --Artem From gnemmi at gmail.com Thu Nov 12 21:12:52 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Thu Nov 12 21:13:00 2009 Subject: Call for bge(4) testers In-Reply-To: <20091112034749.GI15449@michelle.cdnetworks.com> References: <20091111223751.GE15449@michelle.cdnetworks.com> <20091112034749.GI15449@michelle.cdnetworks.com> Message-ID: <200911121912.44926.gnemmi@gmail.com> On Thursday 12 November 2009 1:47:49 am Pyun YongHyeon wrote: > On Wed, Nov 11, 2009 at 02:37:51PM -0800, Pyun YongHyeon wrote: > > Hi, > > > > I had been working on fixing bus_dma(9) bugs and adding TSO > > capability to bge(4). Now TSO is supported for BCM5755 or newer > > controllers. Actually some pre-BCM5755 controllers also support > > TSO with the help of special firmware but the license issue and > > lower performance of firmware based TSO as well as TSO bug I > > intentionally excluded TSO support for pre-BCM5755 controllers. > > You can get the patch form the following URL. The diff was > > generated against latest HEAD. > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111.diff > > Eh, there was a typo so I regenerated the diff. > http://people.freebsd.org/~yongari/bge/bge.tso.1111-1.diff Hi Just wanted to know before getting on to it, will your patch help to resolve kern/136876? Best Regards Gonzalo Nemmi From sullrich at gmail.com Thu Nov 12 21:15:10 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Thu Nov 12 21:15:17 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> Message-ID: On Thu, Nov 12, 2009 at 3:19 PM, Artem Belevich wrote: > > Log seems to be somewhat weak point in ZFS. If you lose your log > device, you will lose your pool. Plus, there's no way to remove log > device from the pool. So, once you attach some device as a log, you'd > better be sure that device does not disappear, because it will take > the rest of the pool with it. From that point, real ram-disk (i.e. > /dev/mdN) is definitely a recipe for disaster. External ramdisk with a > battery backup may be an option, but even in mirrored configuration > seems rather risky to me. > > http://jmlittle.blogspot.com/2008/05/problem-with-slogs-how-i-lost.html > > I'd say that SSD are probably the best fit for slog role. Indeed. I mirrored 2 SSDs on an Areca in case I loose one of them. Partitioned the SSD into a log device and the rest being cache (see the ZFS best practices guide for details). Needless to say my performance matches that of normal writes and reads when using NFS now. Scott From ivoras at freebsd.org Thu Nov 12 21:29:16 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Nov 12 21:29:23 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> Message-ID: <9bbcef730911121328t342b2268oceba3712b52511d4@mail.gmail.com> 2009/11/12 Scott Ullrich : > On Thu, Nov 12, 2009 at 3:19 PM, Artem Belevich wrote: >> >> Log seems to be somewhat weak point in ZFS. If you lose your log >> device, you will lose your pool. Plus, there's no way to remove log >> device from the pool. So, once you attach some device as a log, you'd >> better be sure that device does not disappear, because it will take >> the rest of the pool with it. From that point, real ram-disk (i.e. >> /dev/mdN) is definitely a recipe for disaster. External ramdisk with a >> battery backup may be an option, but even in mirrored configuration >> seems rather risky to me. >> >> http://jmlittle.blogspot.com/2008/05/problem-with-slogs-how-i-lost.html >> >> I'd say that SSD are probably the best fit for slog role. > > Indeed. ? I mirrored 2 SSDs on an Areca in case I loose one of them. > Partitioned the SSD into a log device and the rest being cache (see > the ZFS best practices guide for details). > > Needless to say my performance matches that of normal writes and reads > when using NFS now. So in short, you are saying the to get "normal" performance out of ZFS+NFS, the best way is to invest in an Areca and 2 SSDs :)) From des at des.no Thu Nov 12 21:30:57 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Nov 12 21:31:04 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: (Scott Ullrich's message of "Thu, 12 Nov 2009 16:14:49 -0500") References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> Message-ID: <861vk3o2gg.fsf@ds4.des.no> Scott Ullrich writes: > Indeed. I mirrored 2 SSDs on an Areca in case I loose one of them. You can also use a ZFS mirror for the zil: # zpool add pool_name log mirror ssd0 ssd1 in which case you can replace ssd0 or ssd1 as usual should one of them fail. DES -- Dag-Erling Sm?rgrav - des@des.no From sfourman at gmail.com Thu Nov 12 21:39:14 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Thu Nov 12 21:39:21 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> Message-ID: <11167f520911121339y4161a1a2sae8b6196c3b7a1fb@mail.gmail.com> On Thu, Nov 12, 2009 at 3:14 PM, Scott Ullrich wrote: > On Thu, Nov 12, 2009 at 3:19 PM, Artem Belevich wrote: >> >> Log seems to be somewhat weak point in ZFS. If you lose your log >> device, you will lose your pool. Plus, there's no way to remove log >> device from the pool. So, once you attach some device as a log, you'd >> better be sure that device does not disappear, because it will take >> the rest of the pool with it. From that point, real ram-disk (i.e. >> /dev/mdN) is definitely a recipe for disaster. External ramdisk with a >> battery backup may be an option, but even in mirrored configuration >> seems rather risky to me. >> >> http://jmlittle.blogspot.com/2008/05/problem-with-slogs-how-i-lost.html >> >> I'd say that SSD are probably the best fit for slog role. > > Indeed. ? I mirrored 2 SSDs on an Areca in case I loose one of them. > Partitioned the SSD into a log device and the rest being cache (see > the ZFS best practices guide for details). > > Needless to say my performance matches that of normal writes and reads > when using NFS now. if you wouldn't mind posting, what kind of NFS performance can you achieve? my application is office Fileserver (the clients are FreeBSD 8 diskless PXE boot) so idk if it is possible to achieve gigabit NFS performance. iperf is able to get ~970mbit from a client to the NFS server. I realize that disk i/o is the limiting factor so I bought 6x SATA2 disks and a Areca card Sam Fourman Jr. From kenyon at kenyonralph.com Thu Nov 12 21:54:52 2009 From: kenyon at kenyonralph.com (Kenyon Ralph) Date: Thu Nov 12 21:59:47 2009 Subject: 8.0-RC3 Available In-Reply-To: <1258040317.7556.29.camel@bauer.cse.buffalo.edu> References: <1258040317.7556.29.camel@bauer.cse.buffalo.edu> Message-ID: <20091112215449.GA21631@kenyonralph.com> On 2009-11-12T10:38:37-0500, Ken Smith wrote: > ISO images for all supported architectures are available on the FTP > sites, and a "memory stick" image is available for amd64/i386 > architectures. For amd64/i386 architectures the cdrom and memstick > images include the documentation packages but no other packages. I just did a successful minimal install on a Dell laptop from the amd64 memstick RC3 media. I created the memstick like this on a GNU/Linux machine: dd if=8.0-RC3-amd64-memstick.img of=/dev/sda bs=10240 conv=sync -- Kenyon Ralph -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091112/1fb01492/attachment.pgp From des at des.no Thu Nov 12 22:03:03 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Thu Nov 12 22:03:10 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <9bbcef730911121328t342b2268oceba3712b52511d4@mail.gmail.com> (Ivan Voras's message of "Thu, 12 Nov 2009 22:28:55 +0100") References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> <9bbcef730911121328t342b2268oceba3712b52511d4@mail.gmail.com> Message-ID: <86ws1vmmei.fsf@ds4.des.no> Ivan Voras writes: > So in short, you are saying the to get "normal" performance out of > ZFS+NFS, the best way is to invest in an Areca and 2 SSDs :)) The Areca is unnecessary. DES -- Dag-Erling Sm?rgrav - des@des.no From pyunyh at gmail.com Thu Nov 12 22:06:25 2009 From: pyunyh at gmail.com (Pyun YongHyeon) Date: Thu Nov 12 22:06:31 2009 Subject: Call for bge(4) testers In-Reply-To: <200911121912.44926.gnemmi@gmail.com> References: <20091111223751.GE15449@michelle.cdnetworks.com> <20091112034749.GI15449@michelle.cdnetworks.com> <200911121912.44926.gnemmi@gmail.com> Message-ID: <20091112220550.GJ15449@michelle.cdnetworks.com> On Thu, Nov 12, 2009 at 07:12:44PM -0200, Gonzalo Nemmi wrote: > On Thursday 12 November 2009 1:47:49 am Pyun YongHyeon wrote: > > On Wed, Nov 11, 2009 at 02:37:51PM -0800, Pyun YongHyeon wrote: > > > Hi, > > > > > > I had been working on fixing bus_dma(9) bugs and adding TSO > > > capability to bge(4). Now TSO is supported for BCM5755 or newer > > > controllers. Actually some pre-BCM5755 controllers also support > > > TSO with the help of special firmware but the license issue and > > > lower performance of firmware based TSO as well as TSO bug I > > > intentionally excluded TSO support for pre-BCM5755 controllers. > > > You can get the patch form the following URL. The diff was > > > generated against latest HEAD. > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111.diff > > > > Eh, there was a typo so I regenerated the diff. > > http://people.freebsd.org/~yongari/bge/bge.tso.1111-1.diff > > Hi > Just wanted to know before getting on to it, will your patch help to > resolve kern/136876? > My diff includes a fix for assuming PCIe device control register and MSI control registers would be reside in fixed address. And from the pciconf output I see the your MSI control register is located at different address. However bge(4) does not touch that register for BCM5906 so I guess my diff may not fix the resume issue. > Best Regards > Gonzalo Nemmi From avg at icyb.net.ua Thu Nov 12 22:09:58 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Nov 12 22:10:06 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091112204805.6ea0247f@ernst.jennejohn.org> References: <20091106101943.5a763f43@ernst.jennejohn.org> <20091111231753.GA52833@dmr.ath.cx> <200911121133.30784.jhb@freebsd.org> <20091112182825.73b0079c@ernst.jennejohn.org> <4AFC595A.8050703@icyb.net.ua> <20091112204805.6ea0247f@ernst.jennejohn.org> Message-ID: <4AFC8795.704@icyb.net.ua> on 12/11/2009 21:48 Gary Jennejohn said the following: > On Thu, 12 Nov 2009 20:52:10 +0200 > Andriy Gapon wrote: > >> on 12/11/2009 19:28 Gary Jennejohn said the following: >>> A safer way to test this is to enter >>> set hw.mca.enabled="1" >>> on the loader command line rather than putting it into loader.conf. >>> >>> I just did this on my "consumer" AMD64 board without ill effect. >> What CPU do you have, could you provide its description from dmesg? >> Did you stress-tested it enough (like parallel buildworld)? >> > > I did about 1/2 of a parallel build world (-j3) and then stopped it. I > figured, if it lasts that long, it should make it all the way through. > > CPU: AMD Athlon(tm) Dual Core Processor 4850e (2505.35-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff > Features2=0x2001 > AMD Features=0xea500800 > AMD Features2=0x11f > TSC: P-state invariant Hmm, all people, who do have the problem and who provided cpu information, seem to have family 16 (0x10, 10h) AMD processors. You have a family 15 one. Maybe it's that, maybe not. BTW, here is my info: CPU: AMD Athlon(tm) II X2 250 Processor (3013.73-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x100f62 Stepping = 2 Features=0x178bfbff Features2=0x802009 AMD Features=0xee500800 AMD Features2=0x37ff TSC: P-state invariant -- Andriy Gapon From gnemmi at gmail.com Thu Nov 12 22:39:39 2009 From: gnemmi at gmail.com (Gonzalo Nemmi) Date: Thu Nov 12 22:39:45 2009 Subject: Call for bge(4) testers In-Reply-To: <20091112220550.GJ15449@michelle.cdnetworks.com> References: <20091111223751.GE15449@michelle.cdnetworks.com> <200911121912.44926.gnemmi@gmail.com> <20091112220550.GJ15449@michelle.cdnetworks.com> Message-ID: <200911122039.31431.gnemmi@gmail.com> On Thursday 12 November 2009 8:05:50 pm Pyun YongHyeon wrote: > On Thu, Nov 12, 2009 at 07:12:44PM -0200, Gonzalo Nemmi wrote: > > On Thursday 12 November 2009 1:47:49 am Pyun YongHyeon wrote: > > > On Wed, Nov 11, 2009 at 02:37:51PM -0800, Pyun YongHyeon wrote: > > > > Hi, > > > > > > > > I had been working on fixing bus_dma(9) bugs and adding TSO > > > > capability to bge(4). Now TSO is supported for BCM5755 or newer > > > > controllers. Actually some pre-BCM5755 controllers also support > > > > TSO with the help of special firmware but the license issue and > > > > lower performance of firmware based TSO as well as TSO bug I > > > > intentionally excluded TSO support for pre-BCM5755 controllers. > > > > You can get the patch form the following URL. The diff was > > > > generated against latest HEAD. > > > > > > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111.diff > > > > > > Eh, there was a typo so I regenerated the diff. > > > http://people.freebsd.org/~yongari/bge/bge.tso.1111-1.diff > > > > Hi > > Just wanted to know before getting on to it, will your patch help > > to resolve kern/136876? > > My diff includes a fix for assuming PCIe device control register > and MSI control registers would be reside in fixed address. And > from the pciconf output I see the your MSI control register is > located at different address. However bge(4) does not touch that > register for BCM5906 so I guess my diff may not fix the resume > issue. > Thanks a lot for your prompt, clear and straight answer. Regards Gonzalo Nemmi From robillard.etienne at gmail.com Thu Nov 12 23:10:46 2009 From: robillard.etienne at gmail.com (Etienne Robillard) Date: Thu Nov 12 23:10:54 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <4AFC8795.704@icyb.net.ua> References: <20091106101943.5a763f43@ernst.jennejohn.org> <20091111231753.GA52833@dmr.ath.cx> <200911121133.30784.jhb@freebsd.org> <20091112182825.73b0079c@ernst.jennejohn.org> <4AFC595A.8050703@icyb.net.ua> <20091112204805.6ea0247f@ernst.jennejohn.org> <4AFC8795.704@icyb.net.ua> Message-ID: <4AFC9633.1050301@gmail.com> Andriy Gapon wrote: > on 12/11/2009 21:48 Gary Jennejohn said the following: >> On Thu, 12 Nov 2009 20:52:10 +0200 >> Andriy Gapon wrote: >> >>> on 12/11/2009 19:28 Gary Jennejohn said the following: >>>> A safer way to test this is to enter >>>> set hw.mca.enabled="1" >>>> on the loader command line rather than putting it into loader.conf. >>>> >>>> I just did this on my "consumer" AMD64 board without ill effect. >>> What CPU do you have, could you provide its description from dmesg? >>> Did you stress-tested it enough (like parallel buildworld)? >>> >> I did about 1/2 of a parallel build world (-j3) and then stopped it. I >> figured, if it lasts that long, it should make it all the way through. >> >> CPU: AMD Athlon(tm) Dual Core Processor 4850e (2505.35-MHz K8-class CPU) >> Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff >> Features2=0x2001 >> AMD Features=0xea500800 >> AMD Features2=0x11f >> TSC: P-state invariant > > Hmm, all people, who do have the problem and who provided cpu information, seem > to have family 16 (0x10, 10h) AMD processors. You have a family 15 one. Maybe > it's that, maybe not. > > BTW, here is my info: > CPU: AMD Athlon(tm) II X2 250 Processor (3013.73-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0x100f62 Stepping = 2 > > Features=0x178bfbff > Features2=0x802009 > AMD Features=0xee500800 > AMD > Features2=0x37ff > TSC: P-state invariant > > here's my dmesg output. No problem at all buildworld/installworld. I also didn't play much with any debugging options, this is the generic one... ;-) Copyright (c) 1992-2009 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RC2 #0: Sun Oct 25 07:27:19 UTC 2009 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ (2613.41-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x40f32 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f real memory = 536870912 (512 MB) avail memory = 499974144 (476 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 4 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, 1fde0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_hpet0: iomem 0xfefff000-0xfefff3ff on acpi0 Timecounter "HPET" frequency 25000000 Hz quality 900 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 2.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ehci0: mem 0xfeb00000-0xfeb000ff irq 22 at device 2.1 on pci0 ehci0: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xe800-0xe80f at device 6.0 on pci0 ata0: on atapci0 ata0: [ITHREAD] ata1: on atapci0 ata1: [ITHREAD] atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xd400-0xd40f mem 0xfe02c000-0xfe02cfff irq 23 at device 7.0 on pci0 atapci1: [ITHREAD] ata2: on atapci1 ata2: [ITHREAD] ata3: on atapci1 ata3: [ITHREAD] atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xc000-0xc00f mem 0xfe02b000-0xfe02bfff irq 21 at device 8.0 on pci0 atapci2: [ITHREAD] ata4: on atapci2 ata4: [ITHREAD] ata5: on atapci2 ata5: [ITHREAD] pcib1: at device 9.0 on pci0 pci1: on pcib1 fwohci0: port 0xac00-0xac7f mem 0xfdfff000-0xfdfff7ff irq 17 at device 1.0 on pci1 fwohci0: [ITHREAD] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:1e:8c:00:00:22:dc:f8 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1ef1c000 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:1e:8c:22:dc:f8 fwe0: Ethernet address: 02:1e:8c:22:dc:f8 fwip0: on firewire0 fwip0: Firewire address: 00:1e:8c:00:00:22:dc:f8 @ 0xfffe00000000, S400, maxrec 2048 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: fwohci_intr_core: BUS reset fwohci0: fwohci_intr_core: node_id=0x00000000, SelfID Count=1, CYCLEMASTER mode dc0: port 0xa800-0xa8ff mem 0xfdffe000-0xfdffe3ff irq 16 at device 6.0 on pci1 miibus0: on dc0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:12:17:51:31:ac dc0: [ITHREAD] nfe0: port 0xbc00-0xbc07 mem 0xfe02a000-0xfe02afff irq 22 at device 10.0 on pci0 miibus1: on nfe0 atphy0: PHY 0 on miibus1 atphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, auto nfe0: Ethernet address: 00:1f:c6:be:65:76 nfe0: [FILTER] pcib2: at device 11.0 on pci0 pci2: on pcib2 pcib3: at device 12.0 on pci0 pci3: on pcib3 pcib4: at device 13.0 on pci0 pci4: on pcib4 pcib5: at device 14.0 on pci0 pci5: on pcib5 vgapci0: port 0x9c00-0x9cff mem 0xd0000000-0xdfffffff,0xfdef0000-0xfdefffff irq 18 at device 0.0 on pci5 vgapci1: mem 0xfdee0000-0xfdeeffff at device 0.1 on pci5 acpi_tz0: on acpi0 ACPI Warning: \\_TZ_.THRM._PSL: Return Package type mismatch at index 0 - found [NULL Object Descriptor], expected Reference 20090521 nspredef-1058 atrtc0: port 0x70-0x73 on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 powernow0: on cpu0 cpu1: on acpi0 powernow1: on cpu1 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec firewire0: 1 nodes, maxhop <= 0 cable IRM irm(0) (me) firewire0: bus manager 0 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 acd0: DMA limited to UDMA33, device found non-ATA66 cable acd0: DVDR at ata0-slave UDMA33 ad8: 152627MB at ata4-master SATA300 uhub0: 9 ports with 9 removable, self powered uhub1: 9 ports with 9 removable, self powered SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad8s1a WARNING: / was not properly dismounted ugen0.2: at usbus0 ums0: on usbus0 ums0: 3 buttons and [XYZ] coordinates ID=0 ugen0.3: at usbus0 ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled nfe0: link state changed to UP hope this helps, Etienne -- Etienne Robillard Green Tea Hackers Club Blog: PGP Fingerprint: 178A BF04 23F0 2BF5 535D 4A57 FD53 FD31 98DC 4E57 From brampton+freebsd at gmail.com Thu Nov 12 23:36:36 2009 From: brampton+freebsd at gmail.com (Andrew Brampton) Date: Thu Nov 12 23:36:42 2009 Subject: dell 2950/ FreeBSD 8.0-RC2 In-Reply-To: <52c7f0c80910271114w27929312mc06aead560aa73bc@mail.gmail.com> References: <52c7f0c80910271114w27929312mc06aead560aa73bc@mail.gmail.com> Message-ID: 2009/10/27 C?dric Tabary : > Hello >>> Has anyone else seen this? > > Yes I have the exact same error messages on LCD and kernel freeze on same error. > Dell PowerEdge 1950, after 8.0-RC2 install > > Install CD boots ok, but GENERIC kernel freeze. > I've held back upgrading my servers to RC2 in case this also happened to me. RC3 is now out, so I'm wondering if that has fixed the issues, or did you find a way to fix the issue on RC2? thanks Andrew From weldon at excelsusphoto.com Thu Nov 12 23:42:30 2009 From: weldon at excelsusphoto.com (Weldon S Godfrey 3) Date: Thu Nov 12 23:54:43 2009 Subject: dell 2950/ FreeBSD 8.0-RC2 In-Reply-To: References: <52c7f0c80910271114w27929312mc06aead560aa73bc@mail.gmail.com> Message-ID: If memory serves me right, sometime around 11:36pm, Andrew Brampton told me: > I've held back upgrading my servers to RC2 in case this also happened > to me. RC3 is now out, so I'm wondering if that has fixed the issues, > or did you find a way to fix the issue on RC2? > > thanks > Andrew > _______________________________________________ I got around the issue by upgrading the BIOS to the latest version offered by Dell. From sullrich at gmail.com Fri Nov 13 00:38:49 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Fri Nov 13 00:38:57 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <9bbcef730911121328t342b2268oceba3712b52511d4@mail.gmail.com> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> <9bbcef730911121328t342b2268oceba3712b52511d4@mail.gmail.com> Message-ID: On Thu, Nov 12, 2009 at 4:28 PM, Ivan Voras wrote: > So in short, you are saying the to get "normal" performance out of > ZFS+NFS, the best way is to invest in an Areca and 2 SSDs :)) Yep, that seems to be the magic recipe for NFS related serving. Scott From sullrich at gmail.com Fri Nov 13 00:43:54 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Fri Nov 13 00:44:00 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <11167f520911121339y4161a1a2sae8b6196c3b7a1fb@mail.gmail.com> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> <11167f520911121339y4161a1a2sae8b6196c3b7a1fb@mail.gmail.com> Message-ID: On Thu, Nov 12, 2009 at 4:39 PM, Sam Fourman Jr. wrote: > if you wouldn't mind posting, what kind of NFS performance can you achieve? > > my application is office Fileserver (the clients are FreeBSD 8 > diskless PXE boot) > so idk if it is possible to achieve gigabit NFS performance. > iperf is able to get ~970mbit from a client to the NFS server. > I realize that disk i/o is the limiting factor so I bought 6x SATA2 > disks and a Areca card I was getting getting bursts up to 120Megaqbyte a sec but it would normally write at about 80MB/sec sustained. With was great for the boxes configuration. It's an old Dell 2950. Scott From ivoras at freebsd.org Fri Nov 13 00:57:07 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Fri Nov 13 00:57:14 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> <9bbcef730911121328t342b2268oceba3712b52511d4@mail.gmail.com> Message-ID: <9bbcef730911121656x7615efcbu7dfb1ef060c2797c@mail.gmail.com> 2009/11/13 Scott Ullrich : > On Thu, Nov 12, 2009 at 4:28 PM, Ivan Voras wrote: >> So in short, you are saying the to get "normal" performance out of >> ZFS+NFS, the best way is to invest in an Areca and 2 SSDs :)) > > Yep, that seems to be the magic recipe for NFS related serving. I know it's a bit late now that you've settled on your equipment but did you try discovering why you get performance so low you need SSDs to cope? I think I've read somewhere that disabling ZIL should help NFS performance - did you try it? Did you test your workload directly on the ZFS volume (without NFS) or with another network file system like Samba? From sullrich at gmail.com Fri Nov 13 01:05:58 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Fri Nov 13 01:06:06 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <9bbcef730911121656x7615efcbu7dfb1ef060c2797c@mail.gmail.com> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> <9bbcef730911121328t342b2268oceba3712b52511d4@mail.gmail.com> <9bbcef730911121656x7615efcbu7dfb1ef060c2797c@mail.gmail.com> Message-ID: On Thu, Nov 12, 2009 at 7:56 PM, Ivan Voras wrote: > 2009/11/13 Scott Ullrich : > I know it's a bit late now that you've settled on your equipment but > did you try discovering why you get performance so low you need SSDs > to cope? I think I've read somewhere that disabling ZIL should help > NFS performance - did you try it? I did try disabling ZIL and the performance was much better but I am overly cautious and would rather have it on. > Did you test your workload directly on the ZFS volume (without NFS) or with > another network file system like Samba? No, I was focused on NFS since this was originally a storage server for VMWare via NFS but since has been converted into a web server. Scott From mattjreimer at gmail.com Fri Nov 13 01:12:09 2009 From: mattjreimer at gmail.com (Matt Reimer) Date: Fri Nov 13 01:12:16 2009 Subject: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" In-Reply-To: References: <4AD710D6.70404@buchlovice.org> Message-ID: 2009/11/12 Matt Reimer : > > Radek, > > Try the attached patch (sponsored by VPOP Technologies). I found an > overflow in /sys/cddl/boot/zfs/zfssubr.c:vdev_raidz_read() that was > causing my 6x1TB raidz2 array to fail to boot. > > Apply the patch, build everything in /sys/boot, and then make sure you > update both gptzfsboot and /boot/loader. Oops, here's the patch. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: zfssubr.c.patch Type: application/octet-stream Size: 415 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091113/0d022807/zfssubr.c-0001.obj From delphij at delphij.net Fri Nov 13 01:12:38 2009 From: delphij at delphij.net (Xin LI) Date: Fri Nov 13 01:12:45 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: <200911050922.10205.hselasky@c2i.net> References: <20091002150931.K35591@pooker.samsco.org> <30F3E66A-4A69-46CE-96F4-44B4049722E2@samsco.org> <200911050922.10205.hselasky@c2i.net> Message-ID: <4AFCB277.5070306@delphij.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Hans, Hans Petter Selasky wrote: > Hi, > > There is a newer patch in USB P4. Which revisions are you referring to? So far it looks like that only p4 changeset 169183: Mount Root Patch - This patch allows for late root device discovery. Instead of giving up at the first try, the system keeps trying for 3 minutes to mount root. If CTRL+C is pressed during this time a mount-root menu will be shown. Else after 3 minutes the mount-root menu will be shown and then a panic will happen like before. - Clean up old mount root hold mechanism which did not work like expected. Is related? Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEARECAAYFAkr8sncACgkQi+vbBBjt66D+FwCgjGS74zSfEwZqcWsLO6eCFHy3 MVMAoJroxpPlKkdP6R+9Y22v5qWbUe6+ =ZqyA -----END PGP SIGNATURE----- From mattjreimer at gmail.com Fri Nov 13 01:27:04 2009 From: mattjreimer at gmail.com (Matt Reimer) Date: Fri Nov 13 01:27:15 2009 Subject: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" In-Reply-To: <4AD710D6.70404@buchlovice.org> References: <4AD710D6.70404@buchlovice.org> Message-ID: 2009/10/15 Radek Val??ek : > Hi, > > I want to ask if there is something new in adding support to > gptzfsboot/zfsboot for reading gang-blocks? > > From Sun's docs: > > Gang blocks > > When there is not enough contiguous space to write a complete block, the ZIO > pipeline will break the I/O up into smaller 'gang blocks' which can later be > assembled transparently to appear as complete blocks. > > Everything works fine for me, until I rewrite kernel/world after system > upgrade to latest one (releng_8). After this am I no longer able to boot > from zfs raidz1 pool with following messages: > >>/ ZFS: i/o error - all block copies unavailable > />/ ZFS: can't read MOS > />/ ZFS: unexpected object set type lld > />/ ZFS: unexpected object set type lld > />/ > />/ FreeBSD/i386 boot > />/ Default: z:/boot/kernel/kernel > />/ boot: > />/ ZFS: unexpected object set type lld > />/ > />/ FreeBSD/i386 boot > />/ Default: tank:/boot/kernel/kernel > />/ boot: Radek, Try the attached patch (sponsored by VPOP Technologies). I found an overflow in /sys/cddl/boot/zfs/zfssubr.c:vdev_raidz_read() that was causing my 6x1TB raidz2 array to fail to boot. Apply the patch, build everything in /sys/boot, and then make sure you update both gptzfsboot and /boot/loader. Robert, I'm guessing you couldn't replicate this because your array was small enough not to result in block numbers overflowing an int. The kernel source for the corresponding functionality is in /sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_raidz.c:vdev_raidz_map_alloc(). There all these variables are uint64_t, but I think unnecessarily. I tried changing the boot loader's vdev_raidz_read() variables to all uint64_t but then gptzfsboot would reboot itself, likely due to a stack overflow. The attached patch just changes a few variables that, after a quick analysis, seemed likely to overflow. If this looks good, would someone commit it? Matt From james-freebsd-current at jrv.org Fri Nov 13 01:54:21 2009 From: james-freebsd-current at jrv.org (James R. Van Artsdalen) Date: Fri Nov 13 01:54:28 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <9bbcef730911121328t342b2268oceba3712b52511d4@mail.gmail.com> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> <9bbcef730911121328t342b2268oceba3712b52511d4@mail.gmail.com> Message-ID: <4AFCBC46.4010209@jrv.org> Ivan Voras wrote: > So in short, you are saying the to get "normal" performance out of > ZFS+NFS, the best way is to invest in an Areca and 2 SSDs :)) The Areca seems very sensitive to the disk drives used and I had to abandon it. It takes a day or so to get the card's firmware to sound the on-board siren no matter which disk drives I tried. And in any case a couple of Silicon Image 3124 host adapters with external port multipliers is much faster: the CAM/SIIS driver with such a setup easily sustains > 800 MB/s and would do better but for bus bandwidth issues I didn't bother addressing. From sullrich at gmail.com Fri Nov 13 02:02:53 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Fri Nov 13 02:03:01 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <4AFCBC46.4010209@jrv.org> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> <9bbcef730911121328t342b2268oceba3712b52511d4@mail.gmail.com> <4AFCBC46.4010209@jrv.org> Message-ID: On Thu, Nov 12, 2009 at 8:54 PM, James R. Van Artsdalen wrote: > The Areca seems very sensitive to the disk drives used and I had to > abandon it. ?It takes a day or so to get the card's firmware to sound > the on-board siren no matter which disk drives I tried. I ended up writing a small cron script to check the status of the array. It is located at http://cvs.pfsense.org/~sullrich/misc/rc_scripts/rc.check_areca if anyone else is interested. I also added a zfs watch script that runs from cron: http://cvs.pfsense.org/~sullrich/misc/rc_scripts/rc.check_zfs_degraded YMMV. Scott From fbsdlist at src.cx Fri Nov 13 02:10:23 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Fri Nov 13 02:10:30 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <4AFCBC46.4010209@jrv.org> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> <9bbcef730911121328t342b2268oceba3712b52511d4@mail.gmail.com> <4AFCBC46.4010209@jrv.org> Message-ID: >> So in short, you are saying the to get "normal" performance out of >> ZFS+NFS, the best way is to invest in an Areca and 2 SSDs :)) I'm using LSI1068 8-port card and I'm pretty happy with it. My controller is on motherboard, but you can get AOC-USAS-L8i card with the same chipset fairly cheaply. http://www.supermicro.com/products/accessories/addon/AOC-USAS-L8i.cfm The gotcha is that while it's PCI-e card, its bracket is oriented in opposite direction compared to regular cards and components are on the wrong side of the board. However, bend the bracket the other way (or find regular bracket that would fit, or rig something to keep the card in place) and you're in business. As for where to hook up SSDs, I personally like the new AHCI driver. It does seem to have lower per-transfer overhead compared to the MPT driver for LSI1068 and shows better results for small sized transfers from my X25-M SSD (~10% gain over mpt). --Artem On Thu, Nov 12, 2009 at 5:54 PM, James R. Van Artsdalen wrote: > Ivan Voras wrote: >> So in short, you are saying the to get "normal" performance out of >> ZFS+NFS, the best way is to invest in an Areca and 2 SSDs :)) > > The Areca seems very sensitive to the disk drives used and I had to > abandon it. ?It takes a day or so to get the card's firmware to sound > the on-board siren no matter which disk drives I tried. > > And in any case a couple of Silicon Image 3124 host adapters with > external port multipliers is much faster: the CAM/SIIS driver with such > a setup easily sustains > 800 MB/s and would do better but for bus > bandwidth issues I didn't bother addressing. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From sfourman at gmail.com Fri Nov 13 02:13:25 2009 From: sfourman at gmail.com (Sam Fourman Jr.) Date: Fri Nov 13 02:13:32 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> <11167f520911121339y4161a1a2sae8b6196c3b7a1fb@mail.gmail.com> Message-ID: <11167f520911121813v29441ac4v2e3dfa6f4386ba4e@mail.gmail.com> On Thu, Nov 12, 2009 at 6:43 PM, Scott Ullrich wrote: > On Thu, Nov 12, 2009 at 4:39 PM, Sam Fourman Jr. wrote: >> if you wouldn't mind posting, what kind of NFS performance can you achieve? >> >> my application is office Fileserver (the clients are FreeBSD 8 >> diskless PXE boot) >> so idk if it is possible to achieve gigabit NFS performance. >> iperf is able to get ~970mbit from a client to the NFS server. >> I realize that disk i/o is the limiting factor so I bought 6x SATA2 >> disks and a Areca card > > I was getting getting bursts up to 120Megaqbyte a sec but it would > normally write at about 80MB/sec sustained. ?With was great for the > boxes configuration. ?It's an old Dell 2950. and this was with ZFS over NFS? My problem and the reason I started this thread I am getting less than 20MB/sec writes, with 6 SATAII disks attached to a single Arcera 1130 card so you are suggesting that it is possible that 2x SSD disks would get me the other 60MB/sec Sam Fourman Jr. From sullrich at gmail.com Fri Nov 13 02:18:33 2009 From: sullrich at gmail.com (Scott Ullrich) Date: Fri Nov 13 02:18:40 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <11167f520911121813v29441ac4v2e3dfa6f4386ba4e@mail.gmail.com> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> <11167f520911121339y4161a1a2sae8b6196c3b7a1fb@mail.gmail.com> <11167f520911121813v29441ac4v2e3dfa6f4386ba4e@mail.gmail.com> Message-ID: On Thu, Nov 12, 2009 at 9:13 PM, Sam Fourman Jr. wrote: > and this was with ZFS over NFS? My problem and the reason I started this thread > I am getting less than 20MB/sec writes, with 6 SATAII disks attached > to a single Arcera 1130 card Yes > so you are suggesting that it is possible that 2x SSD disks would get > me the other 60MB/sec I am unsure of your final numbers but it made a huge improvement taking it from intolerable to more than tolerable. I would give it a shot. Scott From fbsdlist at src.cx Fri Nov 13 02:24:03 2009 From: fbsdlist at src.cx (Artem Belevich) Date: Fri Nov 13 02:24:10 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: <11167f520911121813v29441ac4v2e3dfa6f4386ba4e@mail.gmail.com> References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> <11167f520911121339y4161a1a2sae8b6196c3b7a1fb@mail.gmail.com> <11167f520911121813v29441ac4v2e3dfa6f4386ba4e@mail.gmail.com> Message-ID: On Thu, Nov 12, 2009 at 6:13 PM, Sam Fourman Jr. wrote: > so you are suggesting that it is possible that 2x SSD disks would get > me the other 60MB/sec I guess you can test what SSDs would buy you in terms of performance. Disable ZIL and run your performance test. If ZIL is what's causing issues, then you will see a speedup. In this case proper log on SSDs should bring your performance fairly close to those numbers, provided SSDs can handle your write rate. If disabling ZIL does not help much, then separate log device will not help much either. On a side note, log device does not have to be big. According to Sun you'll need ~1/2 of your physical memory size: http://docs.sun.com/app/docs/doc/819-5461/gfgaa?a=view Given that typical SSDs these days are quite a bit larger than your typical RAM size, you may use the rest of the SSD as L2ARC. --Artem From james-freebsd-current at jrv.org Fri Nov 13 02:51:35 2009 From: james-freebsd-current at jrv.org (James R. Van Artsdalen) Date: Fri Nov 13 02:51:41 2009 Subject: Help ZFS FreeBSD 8.0 RC2 Write performance issue In-Reply-To: References: <11167f520911111050j36dd94far667c81e6f5c18e69@mail.gmail.com> <20091111204903.GI89052@dan.emsphone.com> <11167f520911111326v13bb442bt36e853afbecdf834@mail.gmail.com> <9bbcef730911111352t12188bdajbca71bcf35a5beb5@mail.gmail.com> <11167f520911121044l74744c30u5a4d9ca008ab863c@mail.gmail.com> <11167f520911121101o403751ddmb544dfaf1c61bf1e@mail.gmail.com> Message-ID: <4AFCC9B2.2050401@jrv.org> Artem Belevich wrote: > Log seems to be somewhat weak point in ZFS. If you lose your log > device, you will lose your pool. In ZFS losing *any* vdev causes a pool to fault! The log vdev is no different and is not a weak point in that regard. In ZFS *every* vdev should be redundant. In the case of a log this means a MIRROR since a log cannot be a RAIDZ. That's not a big deal since you really should put the MIRROR disks on different controllers, and preferably using different drives, independent cables & power supplies, etc. (I think a cache vdev is different and need not be reliable, but I have not tested to see what happens if it is not present when the pool is imported) The ZIL may have bugs but it's a very important feature to have, necessary in a transactional filesystem. A mythical "zfsck" program could probably wipe out the ZIL allowing the pool to import from the most recent uberblock state and losing a few seconds of sync's, better than nothing. Tricking ZFS into importing a pool with the log vdev missing is probably harder. > I'd say that SSD are probably the best fit for slog role. A PCI-e SSD like the OCZ P84 with sustained writes "up to" 600 MB/s might be a possibility for a high-throughput database server, if it uses an interface we have a driver for. From swell.k at gmail.com Fri Nov 13 03:53:45 2009 From: swell.k at gmail.com (Anonymous) Date: Fri Nov 13 03:53:52 2009 Subject: svn commit: r199066 - head/usr.bin/gzip In-Reply-To: <200911090237.nA92b2m7005471__19254.880565177$1257734275$gmane$org@svn.freebsd.org> (Xin LI's message of "Mon, 9 Nov 2009 02:37:02 +0000 (UTC)") References: <200911090237.nA92b2m7005471__19254.880565177$1257734275$gmane$org@svn.freebsd.org> Message-ID: <867htvhygy.fsf@gmail.com> Xin LI writes: > Author: delphij > Date: Mon Nov 9 02:37:02 2009 > New Revision: 199066 > URL: http://svn.freebsd.org/changeset/base/199066 > > Log: > Apply a NetBSD fix (revision 1.12) to handle multi-session bzip2 files > as created by pbzip2. > > Submitted by: mrg (NetBSD.org) > MFC after: 1 week > > Modified: > head/usr.bin/gzip/unbzip2.c > $ touch blah $ bzip2 blah $ gzip -d blah.bz2 gzip: read: No such file or directory Exit 2 Regression? Can you reproduce? From rnoland at FreeBSD.org Fri Nov 13 04:53:17 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Fri Nov 13 04:53:56 2009 Subject: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" In-Reply-To: References: <4AD710D6.70404@buchlovice.org> Message-ID: <1258087983.2303.23.camel@balrog.2hip.net> On Thu, 2009-11-12 at 16:54 -0800, Matt Reimer wrote: > 2009/10/15 Radek Val??ek : > > Hi, > > > > I want to ask if there is something new in adding support to > > gptzfsboot/zfsboot for reading gang-blocks? > > > > From Sun's docs: > > > > Gang blocks > > > > When there is not enough contiguous space to write a complete block, the ZIO > > pipeline will break the I/O up into smaller 'gang blocks' which can later be > > assembled transparently to appear as complete blocks. > > > > Everything works fine for me, until I rewrite kernel/world after system > > upgrade to latest one (releng_8). After this am I no longer able to boot > > from zfs raidz1 pool with following messages: > > > >>/ ZFS: i/o error - all block copies unavailable > > />/ ZFS: can't read MOS > > />/ ZFS: unexpected object set type lld > > />/ ZFS: unexpected object set type lld > > />/ > > />/ FreeBSD/i386 boot > > />/ Default: z:/boot/kernel/kernel > > />/ boot: > > />/ ZFS: unexpected object set type lld > > />/ > > />/ FreeBSD/i386 boot > > />/ Default: tank:/boot/kernel/kernel > > />/ boot: > > Radek, > > Try the attached patch (sponsored by VPOP Technologies). I found an > overflow in /sys/cddl/boot/zfs/zfssubr.c:vdev_raidz_read() that was > causing my 6x1TB raidz2 array to fail to boot. > > Apply the patch, build everything in /sys/boot, and then make sure you > update both gptzfsboot and /boot/loader. > > Robert, I'm guessing you couldn't replicate this because your array > was small enough not to result in block numbers overflowing an int. This is likely, all of my raidz tests were with vnode backed 1GB memory disks. So my largest configuration was a 6 x 1GB raidz2. > The kernel source for the corresponding functionality is in > /sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_raidz.c:vdev_raidz_map_alloc(). > There all these variables are uint64_t, but I think unnecessarily. I > tried changing the boot loader's vdev_raidz_read() variables to all > uint64_t but then gptzfsboot would reboot itself, likely due to a > stack overflow. The attached patch just changes a few variables that, > after a quick analysis, seemed likely to overflow. > > If this looks good, would someone commit it? ps@ grabbed it up already, but I may handle the MFC for him. I have some other minor fixups in my tree right now... like teaching printf to handle %llx. Thanks for finding this... It's been really frustrating that I couldn't produce a failing system. robert. > Matt > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From ed at 80386.nl Fri Nov 13 06:00:23 2009 From: ed at 80386.nl (Ed Schouten) Date: Fri Nov 13 06:00:29 2009 Subject: [Heads up] TERM=xterm is now the default (on non-i386) In-Reply-To: <20091111101207.GF64905@hoeg.nl> References: <20091111101207.GF64905@hoeg.nl> Message-ID: <20091113060021.GW64905@hoeg.nl> Hi folks, I just committed the previously mentioned patch to SVN. Please refer to the last part of the commit message to see what you can do when you run into trouble. ----- Forwarded message from Ed Schouten ----- > Date: Fri, 13 Nov 2009 05:54:55 +0000 (UTC) > From: Ed Schouten > To: src-committers@freebsd.org, svn-src-all@freebsd.org, > svn-src-head@freebsd.org > Subject: svn commit: r199243 - in head: . etc/etc.amd64 etc/etc.arm > etc/etc.ia64 etc/etc.mips etc/etc.powerpc etc/etc.sparc64 etc/root > share/skel sys/conf sys/dev/syscons > tools/tools/nanobsd/gateworks/Files... > > Author: ed > Date: Fri Nov 13 05:54:55 2009 > New Revision: 199243 > URL: http://svn.freebsd.org/changeset/base/199243 > > Log: > Switch the default terminal emulation style to xterm for most platforms. > > Right now syscons(4) uses a cons25-style terminal emulator. The > disadvantages of that are: > > - Little compatibility with embedded devices with serial interfaces. > - Bad bandwidth efficiency, mainly because of the lack of scrolling > regions. > - A very hard transition path to support for modern character sets like > UTF-8. > > Our terminal emulation library, libteken, has been supporting > xterm-style terminal emulation for months, so flip the switch and make > everyone use an xterm-style console driver. > > I still have to enable this on i386. Right now pc98 and i386 share the > same /etc/ttys file. I'm not going to switch pc98, because it uses its > own Kanji-capable cons25 emulator. > > IMPORTANT: What to do if things go wrong (i.e. graphical artifacts): > > - Run the application inside script(1), try to reduce the problem and > send me the log file. > - In the mean time, you can run `vidcontrol -T cons25' and `export > TERM=cons25' so you can run applications the same way you did before. > You can also build your kernel with `options TEKEN_CONS25' to make all > virtual terminals use the cons25 emulator by default. > > Discussed on: current@ ----- End forwarded message ----- Cheers, -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091113/44882853/attachment.pgp From mattjreimer at gmail.com Fri Nov 13 06:15:08 2009 From: mattjreimer at gmail.com (Matt Reimer) Date: Fri Nov 13 06:15:20 2009 Subject: GPT boot with ZFS RAIDZ "ZFS: i/o error - all block copies unavailable" In-Reply-To: <1258087983.2303.23.camel@balrog.2hip.net> References: <4AD710D6.70404@buchlovice.org> <1258087983.2303.23.camel@balrog.2hip.net> Message-ID: 2009/11/12 Robert Noland : > On Thu, 2009-11-12 at 16:54 -0800, Matt Reimer wrote: >> 2009/10/15 Radek Val??ek : >> > Everything works fine for me, until I rewrite kernel/world after system >> > upgrade to latest one (releng_8). After this am I no longer able to boot >> > from zfs raidz1 pool with following messages: >> > >> >>/ ZFS: i/o error - all block copies unavailable >> > />/ ZFS: can't read MOS >> > />/ ZFS: unexpected object set type lld >> > />/ ZFS: unexpected object set type lld >> > />/ >> > />/ FreeBSD/i386 boot >> > />/ Default: z:/boot/kernel/kernel >> > />/ boot: >> > />/ ZFS: unexpected object set type lld >> > />/ >> > />/ FreeBSD/i386 boot >> > />/ Default: tank:/boot/kernel/kernel >> > />/ boot: >> >> Radek, >> >> Try the attached patch (sponsored by VPOP Technologies). I found an >> overflow in /sys/cddl/boot/zfs/zfssubr.c:vdev_raidz_read() that was >> causing my 6x1TB raidz2 array to fail to boot. ... >> The kernel source for the corresponding functionality is in >> /sys/cddl/contrib/opensolaris/uts/common/fs/zfs/vdev_raidz.c:vdev_raidz_map_alloc(). >> There all these variables are uint64_t, but I think unnecessarily. I >> tried changing the boot loader's vdev_raidz_read() variables to all >> uint64_t but then gptzfsboot would reboot itself, likely due to a >> stack overflow. The attached patch just changes a few variables that, >> after a quick analysis, seemed likely to overflow. >> >> If this looks good, would someone commit it? > > ps@ grabbed it up already, but I may handle the MFC for him. ?I have > some other minor fixups in my tree right now... like teaching printf to > handle %llx. ?Thanks for finding this... It's been really frustrating > that I couldn't produce a failing system. Is it possible for this patch to get into 8.0-RELEASE, or is it too late? I suppose it doesn't matter that much since the loader isn't built with LOADER_ZFS_SUPPORT by default anyway, so folks are going to have to compile it themselves. Matt From wollman at bimajority.org Fri Nov 13 05:18:52 2009 From: wollman at bimajority.org (Garrett Wollman) Date: Fri Nov 13 06:27:10 2009 Subject: CFR: Exceedingly minor fixes to libc Message-ID: <19196.60473.337121.565916@hergotha.csail.mit.edu> If you have a moment, please take a look at the following patch. It contains some very minor fixes to various parts of libc which were found by the clang static analyzer. They fall into a few categories: 1) Bug fixes in very rare situations (mostly error-handling code that has probably never been executed). 2) Dead store elimination. 3) Elimination of unused variables. (Or in a few cases, making use of them.) Some minor style problems were also fixed in the vicinity. There should be no functional changes except in very unusual conditions. -GAWollman -------------- next part -------------- Index: stdio/fvwrite.c =================================================================== --- stdio/fvwrite.c (revision 199242) +++ stdio/fvwrite.c (working copy) @@ -60,7 +60,7 @@ char *nl; int nlknown, nldist; - if ((len = uio->uio_resid) == 0) + if (uio->uio_resid == 0) return (0); /* make sure we can write */ if (prepwrite(fp) != 0) Index: stdio/vfwprintf.c =================================================================== --- stdio/vfwprintf.c (revision 199242) +++ stdio/vfwprintf.c (working copy) @@ -293,7 +293,7 @@ * number of characters to print. */ p = mbsarg; - insize = nchars = 0; + insize = nchars = nconv = 0; mbs = initial_mbs; while (nchars != (size_t)prec) { nconv = mbrlen(p, MB_CUR_MAX, &mbs); Index: stdio/xprintf_time.c =================================================================== --- stdio/xprintf_time.c (revision 199242) +++ stdio/xprintf_time.c (working copy) @@ -64,7 +64,6 @@ intmax_t t, tx; int i, prec, nsec; - prec = 0; if (pi->is_long) { tv = *((struct timeval **)arg[0]); t = tv->tv_sec; @@ -78,6 +77,8 @@ } else { tp = *((time_t **)arg[0]); t = *tp; + nsec = 0; + prec = 0; } p = buf; Index: stdio/fgetws.c =================================================================== --- stdio/fgetws.c (revision 199242) +++ stdio/fgetws.c (working copy) @@ -89,7 +89,7 @@ if (!__mbsinit(&fp->_mbstate)) /* Incomplete character */ goto error; - *wsp++ = L'\0'; + *wsp = L'\0'; FUNLOCKFILE(fp); return (ws); Index: rpc/getnetconfig.c =================================================================== --- rpc/getnetconfig.c (revision 199242) +++ rpc/getnetconfig.c (working copy) @@ -412,13 +412,13 @@ * Noone needs these entries anymore, then frees them. * Make sure all info in netconfig_info structure has been reinitialized. */ - q = p = ni.head; + q = ni.head; ni.eof = ni.ref = 0; ni.head = NULL; ni.tail = NULL; mutex_unlock(&ni_lock); - while (q) { + while (q != NULL) { p = q->next; if (q->ncp->nc_lookups != NULL) free(q->ncp->nc_lookups); free(q->ncp); Index: rpc/svc_raw.c =================================================================== --- rpc/svc_raw.c (revision 199242) +++ rpc/svc_raw.c (working copy) @@ -176,9 +176,8 @@ msg->acpted_rply.ar_results.proc = (xdrproc_t) xdr_void; msg->acpted_rply.ar_results.where = NULL; - if (!xdr_replymsg(xdrs, msg) || - !SVCAUTH_WRAP(&SVC_AUTH(xprt), xdrs, xdr_proc, xdr_where)) - stat = FALSE; + stat = xdr_replymsg(xdrs, msg) && + SVCAUTH_WRAP(&SVC_AUTH(xprt), xdrs, xdr_proc, xdr_where); } else { stat = xdr_replymsg(xdrs, msg); } Index: rpc/clnt_raw.c =================================================================== --- rpc/clnt_raw.c (revision 199242) +++ rpc/clnt_raw.c (working copy) @@ -92,13 +92,13 @@ rpcprog_t prog; rpcvers_t vers; { - struct clntraw_private *clp = clntraw_private; + struct clntraw_private *clp; struct rpc_msg call_msg; - XDR *xdrs = &clp->xdr_stream; - CLIENT *client = &clp->client_object; + XDR *xdrs; + CLIENT *client; mutex_lock(&clntraw_lock); - if (clp == NULL) { + if ((clp = clntraw_private) == NULL) { clp = (struct clntraw_private *)calloc(1, sizeof (*clp)); if (clp == NULL) { mutex_unlock(&clntraw_lock); @@ -110,6 +110,9 @@ clp->_raw_buf = __rpc_rawcombuf; clntraw_private = clp; } + xdrs = &clp->xdr_stream; + client = &clp->client_object; + /* * pre-serialize the static part of the call msg and stash it away */ Index: rpc/svc_vc.c =================================================================== --- rpc/svc_vc.c (revision 199242) +++ rpc/svc_vc.c (working copy) @@ -141,7 +141,7 @@ r = mem_alloc(sizeof(*r)); if (r == NULL) { warnx("svc_vc_create: out of memory"); - goto cleanup_svc_vc_create; + return NULL; } r->sendsize = __rpc_get_t_size(si.si_af, si.si_proto, (int)sendsize); r->recvsize = __rpc_get_t_size(si.si_af, si.si_proto, (int)recvsize); Index: rpc/getrpcent.c =================================================================== --- rpc/getrpcent.c (revision 199242) +++ rpc/getrpcent.c (working copy) @@ -698,7 +698,7 @@ return (NS_RETURN); } - memcpy(&new_rpc, rpc, sizeof(struct rpcent)); + new_rpc = *rpc; *buffer_size = desired_size; memset(buffer, 0, desired_size); Index: rpc/rpcb_st_xdr.c =================================================================== --- rpc/rpcb_st_xdr.c (revision 199242) +++ rpc/rpcb_st_xdr.c (working copy) @@ -89,7 +89,6 @@ rpcbs_rmtcalllist *objp; { int32_t *buf; - struct rpcbs_rmtcalllist **pnext; if (xdrs->x_op == XDR_ENCODE) { buf = XDR_INLINE(xdrs, 6 * BYTES_PER_XDR_UNIT); @@ -123,8 +122,7 @@ if (!xdr_string(xdrs, &objp->netid, (u_int)~0)) { return (FALSE); } - pnext = &objp->next; - if (!xdr_pointer(xdrs, (char **) pnext, + if (!xdr_pointer(xdrs, (char **) &objp->next, sizeof (rpcbs_rmtcalllist), (xdrproc_t)xdr_rpcbs_rmtcalllist)) { return (FALSE); @@ -162,7 +160,7 @@ if (!xdr_string(xdrs, &objp->netid, (u_int)~0)) { return (FALSE); } - if (!xdr_pointer(xdrs, (char **) pnext, + if (!xdr_pointer(xdrs, (char **) &objp->next, sizeof (rpcbs_rmtcalllist), (xdrproc_t)xdr_rpcbs_rmtcalllist)) { return (FALSE); @@ -190,7 +188,7 @@ if (!xdr_string(xdrs, &objp->netid, (u_int)~0)) { return (FALSE); } - if (!xdr_pointer(xdrs, (char **) pnext, + if (!xdr_pointer(xdrs, (char **) &objp->next, sizeof (rpcbs_rmtcalllist), (xdrproc_t)xdr_rpcbs_rmtcalllist)) { return (FALSE); Index: rpc/key_call.c =================================================================== --- rpc/key_call.c (revision 199242) +++ rpc/key_call.c (working copy) @@ -302,7 +302,7 @@ void *localhandle; struct netconfig *nconf; struct netconfig *tpconf; - struct key_call_private *kcp = key_call_private_main; + struct key_call_private *kcp; struct timeval wait_time; struct utsname u; int main_thread; Index: yp/yplib.c =================================================================== --- yp/yplib.c (revision 199242) +++ yp/yplib.c (working copy) @@ -241,7 +241,7 @@ ypmatch_cache_lookup(struct dom_binding *ypdb, char *map, keydat *key, valdat *val) { - struct ypmatch_ent *c = ypdb->cache; + struct ypmatch_ent *c; ypmatch_cache_expire(ypdb); Index: gen/setmode.c =================================================================== --- gen/setmode.c (revision 199242) +++ gen/setmode.c (working copy) @@ -86,7 +86,7 @@ set = (const BITCMD *)bbox; newmode = omode; - for (value = 0;; set++) + for (;; set++) switch(set->cmd) { /* * When copying the user, group or other bits around, we "know" @@ -147,6 +147,7 @@ } #define ADDCMD(a, b, c, d) \ + do { \ if (set >= endset) { \ BITCMD *newset; \ setlen += SET_LEN_INCR; \ @@ -161,7 +162,8 @@ saveset = newset; \ endset = newset + (setlen - 2); \ } \ - set = addcmd(set, (a), (b), (c), (d)) + set = addcmd(set, (a), (b), (c), (d)); \ + } while (0) #define STANDARD_BITS (S_ISUID|S_ISGID|S_IRWXU|S_IRWXG|S_IRWXO) @@ -173,11 +175,12 @@ BITCMD *set, *saveset, *endset; sigset_t sigset, sigoset; mode_t mask; - int equalopdone=0, permXbits, setlen; + int equalopdone, permXbits, setlen; long perml; if (!*p) return (NULL); + equalopdone = 0; /* * Get a copy of the mask for the permissions that are mask relative. @@ -299,16 +302,10 @@ * Add any permissions that we haven't already * done. */ - if (perm || (op == '=' && !equalopdone)) { - if (op == '=') - equalopdone = 1; + if (perm || (op == '=' && !equalopdone)) ADDCMD(op, who, perm, mask); - perm = 0; - } - if (permXbits) { + if (permXbits) ADDCMD('X', who, permXbits, mask); - permXbits = 0; - } goto apply; } } Index: gen/wordexp.c =================================================================== --- gen/wordexp.c (revision 199242) +++ gen/wordexp.c (working copy) @@ -320,7 +320,7 @@ if (c == '\0' || level != 0) return (WRDE_SYNTAX); } else - c = *--words; + --words; break; default: break; Index: gen/getcap.c =================================================================== --- gen/getcap.c (revision 199242) +++ gen/getcap.c (working copy) @@ -647,7 +647,7 @@ cgetnext(char **bp, char **db_array) { size_t len; - int done, hadreaderr, i, savederrno, status; + int done, hadreaderr, savederrno, status; char *cp, *line, *rp, *np, buf[BSIZE], nbuf[BSIZE]; u_int dummy; @@ -658,7 +658,7 @@ (void)cgetclose(); return (-1); } - for(;;) { + for (;;) { if (toprec && !gottoprec) { gottoprec = 1; line = toprec; @@ -709,7 +709,6 @@ /* * Line points to a name line. */ - i = 0; done = 0; np = nbuf; for (;;) { Index: gen/getpwent.c =================================================================== --- gen/getpwent.c (revision 199242) +++ gen/getpwent.c (working copy) @@ -257,22 +257,19 @@ pwd_marshal_func(char *buffer, size_t *buffer_size, void *retval, va_list ap, void *cache_mdata) { - char *name; - uid_t uid; struct passwd *pwd; - char *orig_buf; - size_t orig_buf_size; struct passwd new_pwd; size_t desired_size, size; char *p; + /* advance past unused arguments */ switch ((enum nss_lookup_type)cache_mdata) { case nss_lt_name: - name = va_arg(ap, char *); + va_arg(ap, char *); break; case nss_lt_id: - uid = va_arg(ap, uid_t); + va_arg(ap, uid_t); break; case nss_lt_all: break; @@ -282,8 +279,7 @@ } pwd = va_arg(ap, struct passwd *); - orig_buf = va_arg(ap, char *); - orig_buf_size = va_arg(ap, size_t); + va_end(ap); /* remaining args are unused */ desired_size = sizeof(struct passwd) + sizeof(char *) + strlen(pwd->pw_name) + 1; @@ -361,8 +357,6 @@ pwd_unmarshal_func(char *buffer, size_t buffer_size, void *retval, va_list ap, void *cache_mdata) { - char *name; - uid_t uid; struct passwd *pwd; char *orig_buf; size_t orig_buf_size; @@ -370,12 +364,13 @@ char *p; + /* advance past unused arguments */ switch ((enum nss_lookup_type)cache_mdata) { case nss_lt_name: - name = va_arg(ap, char *); + va_arg(ap, char *); break; case nss_lt_id: - uid = va_arg(ap, uid_t); + va_arg(ap, uid_t); break; case nss_lt_all: break; @@ -921,7 +916,7 @@ errnop); } while (how == nss_lt_all && !(rv & NS_TERMINATE)); fin: - if (!stayopen && st->db != NULL) { + if (st->db != NULL && !stayopen) { (void)st->db->close(st->db); st->db = NULL; } @@ -1876,7 +1871,6 @@ syslog(LOG_ERR, "getpwent memory allocation failure"); *errnop = ENOMEM; - rv = NS_UNAVAIL; break; } st->compat = COMPAT_MODE_NAME; @@ -1940,7 +1934,7 @@ break; } fin: - if (!stayopen && st->db != NULL) { + if (st->db != NULL && !stayopen) { (void)st->db->close(st->db); st->db = NULL; } Index: gen/getgrent.c =================================================================== --- gen/getgrent.c (revision 199242) +++ gen/getgrent.c (working copy) @@ -207,22 +207,19 @@ grp_marshal_func(char *buffer, size_t *buffer_size, void *retval, va_list ap, void *cache_mdata) { - char *name; - gid_t gid; struct group *grp; - char *orig_buf; - size_t orig_buf_size; struct group new_grp; size_t desired_size, size, mem_size; char *p, **mem; + /* advance past unused arguments */ switch ((enum nss_lookup_type)cache_mdata) { case nss_lt_name: - name = va_arg(ap, char *); + va_arg(ap, char *); break; case nss_lt_id: - gid = va_arg(ap, gid_t); + va_arg(ap, gid_t); break; case nss_lt_all: break; @@ -232,8 +229,7 @@ } grp = va_arg(ap, struct group *); - orig_buf = va_arg(ap, char *); - orig_buf_size = va_arg(ap, size_t); + va_end(ap); /* remaining args are unused */ desired_size = _ALIGNBYTES + sizeof(struct group) + sizeof(char *); @@ -302,8 +298,6 @@ grp_unmarshal_func(char *buffer, size_t buffer_size, void *retval, va_list ap, void *cache_mdata) { - char *name; - gid_t gid; struct group *grp; char *orig_buf; size_t orig_buf_size; @@ -314,10 +308,10 @@ switch ((enum nss_lookup_type)cache_mdata) { case nss_lt_name: - name = va_arg(ap, char *); + va_arg(ap, char *); break; case nss_lt_id: - gid = va_arg(ap, gid_t); + va_arg(ap, gid_t); break; case nss_lt_all: break; @@ -1100,6 +1094,9 @@ case nss_lt_all: map = "group.byname"; break; + default: + *errnop = EINVAL; + return (NS_UNAVAIL); } grp = va_arg(ap, struct group *); buffer = va_arg(ap, char *); @@ -1392,6 +1389,13 @@ } break; case NS_RETURN: + /* + * If _nsdispatch() sets *errnop to ERANGE (can it?) + * we need a valid file position. Assume it might + * close st->fp, too (can it?). + */ + if (st->fp != NULL) + pos = ftello(st->fp); goto fin; default: break; @@ -1450,7 +1454,7 @@ pos = ftello(st->fp); } fin: - if (!stayopen && st->fp != NULL) { + if (st->fp != NULL && !stayopen) { fclose(st->fp); st->fp = NULL; } Index: gen/getusershell.c =================================================================== --- gen/getusershell.c (revision 199242) +++ gen/getusershell.c (working copy) @@ -124,7 +124,7 @@ if ((fp = fopen(_PATH_SHELLS, "r")) == NULL) return NS_UNAVAIL; - sp = cp = line; + cp = line; while (fgets(cp, MAXPATHLEN + 1, fp) != NULL) { while (*cp != '#' && *cp != '/' && *cp != '\0') cp++; Index: gen/pw_scan.c =================================================================== --- gen/pw_scan.c (revision 199242) +++ gen/pw_scan.c (working copy) @@ -202,7 +202,7 @@ if (p[0]) pw->pw_fields |= _PWF_SHELL; - if ((p = strsep(&bp, ":"))) { /* too many */ + if (strsep(&bp, ":") != NULL) { /* too many */ fmt: if (flags & _PWSCAN_WARN) warnx("corrupted entry"); Index: net/sctp_sys_calls.c =================================================================== --- net/sctp_sys_calls.c (revision 199242) +++ net/sctp_sys_calls.c (working copy) @@ -242,7 +242,8 @@ struct sockaddr *sa; struct sockaddr_in *sin; struct sockaddr_in6 *sin6; - int i, sz, argsz; + int i, argsz; + size_t sz; uint16_t sport = 0; /* validate the flags */ @@ -268,7 +269,7 @@ for (i = 0; i < addrcnt; i++) { sz = sa->sa_len; if (sa->sa_family == AF_INET) { - if (sa->sa_len != sizeof(struct sockaddr_in)) + if (sz != sizeof(struct sockaddr_in)) goto out_error; sin = (struct sockaddr_in *)sa; if (sin->sin_port) { @@ -284,7 +285,7 @@ } } } else if (sa->sa_family == AF_INET6) { - if (sa->sa_len != sizeof(struct sockaddr_in6)) + if (sz != sizeof(struct sockaddr_in6)) goto out_error; sin6 = (struct sockaddr_in6 *)sa; if (sin6->sin6_port) { @@ -318,10 +319,10 @@ for (i = 0; i < addrcnt; i++) { sz = sa->sa_len; if (sa->sa_family == AF_INET) { - if (sa->sa_len != sizeof(struct sockaddr_in)) + if (sz != sizeof(struct sockaddr_in)) goto out_error; } else if (sa->sa_family == AF_INET6) { - if (sa->sa_len != sizeof(struct sockaddr_in6)) + if (sz != sizeof(struct sockaddr_in6)) goto out_error; } else { /* invalid address family specified */ Index: net/getservent.c =================================================================== --- net/getservent.c (revision 199242) +++ net/getservent.c (working copy) @@ -476,11 +476,11 @@ struct nis_state *st; int rv; - enum nss_lookup_type how; char *name; char *proto; int port; + enum nss_lookup_type how; struct servent *serv; char *buffer; size_t bufsize; @@ -491,7 +491,8 @@ name = NULL; proto = NULL; - how = (enum nss_lookup_type)mdata; + + how = (intptr_t)mdata; switch (how) { case nss_lt_name: name = va_arg(ap, char *); Index: posix1e/acl_delete_entry.c =================================================================== --- posix1e/acl_delete_entry.c (revision 199242) +++ posix1e/acl_delete_entry.c (working copy) @@ -89,20 +89,20 @@ return (-1); } - if ((acl->ats_acl.acl_cnt < 1) || - (acl->ats_acl.acl_cnt > ACL_MAX_ENTRIES)) { + if ((acl_int->acl_cnt < 1) || + (acl_int->acl_cnt > ACL_MAX_ENTRIES)) { errno = EINVAL; return (-1); } - for (i = 0; i < acl->ats_acl.acl_cnt;) { - if (_entry_matches(&(acl->ats_acl.acl_entry[i]), entry_d)) { + for (i = 0; i < acl_int->acl_cnt;) { + if (_entry_matches(&(acl_int->acl_entry[i]), entry_d)) { /* ...shift the remaining entries... */ - for (j = i; j < acl->ats_acl.acl_cnt - 1; ++j) - acl->ats_acl.acl_entry[j] = - acl->ats_acl.acl_entry[j+1]; + for (j = i; j < acl_int->acl_cnt - 1; ++j) + acl_int->acl_entry[j] = + acl_int->acl_entry[j+1]; /* ...drop the count and zero the unused entry... */ - acl->ats_acl.acl_cnt--; - bzero(&acl->ats_acl.acl_entry[j], + acl_int->acl_cnt--; + bzero(&acl_int->acl_entry[j], sizeof(struct acl_entry)); acl->ats_cur_entry = 0; Index: inet/inet_cidr_pton.c =================================================================== --- inet/inet_cidr_pton.c (revision 199242) +++ inet/inet_cidr_pton.c (working copy) @@ -236,7 +236,6 @@ endp[- i] = colonp[n - i]; colonp[n - i] = 0; } - tp = endp; } memcpy(dst, tmp, NS_IN6ADDRSZ); From avg at icyb.net.ua Fri Nov 13 07:54:25 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Nov 13 07:54:32 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <4AFC9633.1050301@gmail.com> References: <20091106101943.5a763f43@ernst.jennejohn.org> <20091111231753.GA52833@dmr.ath.cx> <200911121133.30784.jhb@freebsd.org> <20091112182825.73b0079c@ernst.jennejohn.org> <4AFC595A.8050703@icyb.net.ua> <20091112204805.6ea0247f@ernst.jennejohn.org> <4AFC8795.704@icyb.net.ua> <4AFC9633.1050301@gmail.com> Message-ID: <4AFD108E.1000009@icyb.net.ua> on 13/11/2009 01:11 Etienne Robillard said the following: > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ (2613.41-MHz > K8-class CPU) > Origin = "AuthenticAMD" Id = 0x40f32 Stepping = 2 Your CPU is different, older family too. -- Andriy Gapon From avg at icyb.net.ua Fri Nov 13 07:57:38 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Nov 13 07:57:44 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> <941257966918@webmail42.yandex.ru> <4AFC14BE.7020106@icyb.net.ua> Message-ID: <4AFD1150.1080205@icyb.net.ua> on 12/11/2009 17:57 Mark Atkinson said the following: >> superpages and no machine check - works >> machine check and no superpages - works >> machine check and superpages - problem > > That's not quite the same for sure, definitely try replacing the memory > first if you haven't already. I am not sure why would you say this. I still see more similarities than differences: 1. in all cases it's family 10h CPUs 2. in all cases turning off super-pages helps 3. in all case failure seems to happen through MCA mechanism The hardware is quite tested too. -- Andriy Gapon From rdivacky at freebsd.org Fri Nov 13 08:01:50 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Fri Nov 13 08:01:57 2009 Subject: compiler discussion In-Reply-To: <20091112153407.GA62396@troutmask.apl.washington.edu> References: <20091112141519.GA66229@mech-cluster241.men.bris.ac.uk> <20091112153407.GA62396@troutmask.apl.washington.edu> Message-ID: <20091113080033.GB90272@freebsd.org> On Thu, Nov 12, 2009 at 07:34:07AM -0800, Steve Kargl wrote: > On Thu, Nov 12, 2009 at 02:15:19PM +0000, Anton Shterenlikht wrote: > > Following from the discussion on the system compiler for ia64, > > I tried to list few major ports which I'd love to have on ia64, > > but can't, because of GCC problems: > > > > - math/blas, lapack, lapack95, arpack, scalapack, atlas, etc. > > - science/hdf5-18 (fortran APIs can't be built) > > - french/aster (industial quality FEA code) > > - cad/calculix (another good FEA code) > > > > All these depend on lang/gcc44, which doesn't build. > > Doesn't build is not a very good description if you're > looking for help. Post the build log somewhere. > Have you submitted bug reports to gcc.gnu.org? Bugs > that are unreported are unlikely to be fixed. > > > The only fortran compiler I know to build and work > > successfully on ia64 is (correct me if I'm wrong) g95. > > > > I wonder if it's possible/desirable/easy to use lang/g95 for > > the above and other fortran-dependent ports? > > Given Polyhedron Benchmarks, it may be preferable to determine > why you can't build gcc44 and fix that problem.* > > > In principal, lang/g95 looks very good, and it's got > > some features not available in gfortran, e.g. limited > > support for 2003 standard. > > > > Any comments? > > AFAIK, g95 has TR 15580 implemented and gfortran doesn't. > Other than that feature, gfortran has a fairly long list > of Fortran 2003 features implemented, which you can find > partially enumerated at the gfortran wiki. > > > Also, any comments on the usability (particularly for fortran) > > of llvm and lang/llvm-gcc4 on ia64? > > Last time I checked, Fortran in llvm was based off a very old > gfortran. The llvm website mentions gcc 4.2.?. While the 4.2.? > gfortran isn't too bad, you most certainly would rather use gcc44 > if you can. Literally, hundreds of bugs and several new feature > have been add to gfortran in going from 4.2.? to gcc 4.4.2. you can use dragonegg gcc plugin which uses gcc frontend (for any language) and uses llvm backed to generate the code: http://dragonegg.llvm.org/ From avg at icyb.net.ua Fri Nov 13 08:09:41 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Nov 13 08:09:48 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <20091112195932.5875387e@orwell.free.de> References: <1031257439203@webmail57.yandex.ru> <941257966918@webmail42.yandex.ru> <200911111504.14906.jhb@freebsd.org> <20091112195932.5875387e@orwell.free.de> Message-ID: <4AFD140D.7010407@icyb.net.ua> on 12/11/2009 20:59 Kai Gallasch said the following: > sonnenkraft:~ # MCA: CPU 4 UNCOR PCC OVER DTLB L1 error Kai, very interesting info, it matches what Serguey reported too, thank you for the test! So in all cases where MCE information is captured it seems to be L1 data TLB error. John, BTW, OVER may be incorrectly reported by hardware in this case, see erratum 60: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/41322.pdf Kai, I have a hunch, could you please try the following _sledgehammer_ patch (only kernel build/install is needed): diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c index 44b71f3..a456609 100644 --- a/sys/amd64/amd64/pmap.c +++ b/sys/amd64/amd64/pmap.c @@ -2981,6 +2981,7 @@ setpte: * Map the superpage. */ pde_store(pde, PG_PS | newpde); + pmap_invalidate_all(pmap); pmap_pde_promotions++; CTR2(KTR_PMAP, "pmap_promote_pde: success for va %#lx" This will slow down an act of promotion to a superpage, but should not have any visible impact on overall performance. Serguey, you problem seems to not be limited to superpages only, so I am not sure if this patch would be of much help to you. -- Andriy Gapon From hselasky at c2i.net Fri Nov 13 08:10:30 2009 From: hselasky at c2i.net (Hans Petter Selasky) Date: Fri Nov 13 08:10:38 2009 Subject: [PATCH] Fix for USB media not found at boot In-Reply-To: <4AFCB277.5070306@delphij.net> References: <20091002150931.K35591@pooker.samsco.org> <200911050922.10205.hselasky@c2i.net> <4AFCB277.5070306@delphij.net> Message-ID: <200911130909.30828.hselasky@c2i.net> On Friday 13 November 2009 02:12:23 Xin LI wrote: > Hi, Hans, > > Hans Petter Selasky wrote: > > Hi, > > > > There is a newer patch in USB P4. > > Which revisions are you referring to? So far it looks like that only p4 > changeset 169183: > > Mount Root Patch > - This patch allows for late root device discovery. Instead of > giving up at the first try, the system keeps trying for 3 > minutes to mount root. If CTRL+C is pressed during this time > a mount-root menu will be shown. Else after 3 minutes the > mount-root menu will be shown and then a panic will happen > like before. > - Clean up old mount root hold mechanism which did not > work like expected. > > Is related? Hi, The changeset in question has not been committed to mainstream. Scott Long is working on an improved solution. Please coordinate with him. --HPS From avg at icyb.net.ua Fri Nov 13 08:10:50 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Fri Nov 13 08:10:57 2009 Subject: 8.0RC2 amd64 - kernel panic running make buildworld In-Reply-To: <36041258043646@webmail59.yandex.ru> References: <1031257439203@webmail57.yandex.ru> <20091105184925.16b55c43@ernst.jennejohn.org> <31221257446063@webmail71.yandex.ru> <20091106101943.5a763f43@ernst.jennejohn.org> <41361257585651@webmail39.yandex.ru> <20091107115256.3df62bc3@ernst.jennejohn.org> <1257618758.1511.14.camel@RabbitsDen> <6511257846119@webmail85.yandex.ru> <20091110105856.1270038e@ernst.jennejohn.org> <1257864452.46072.25.camel@RabbitsDen> <20091110162205.48abcffe@ernst.jennejohn.org> <4AF99D53.9030005@icyb.net.ua> <941257966918@webmail42.yandex.ru> <4AFC0F6A.3000501@icyb.net.ua> <36041258043646@webmail59.yandex.ru> Message-ID: <4AFD1468.5040909@icyb.net.ua> on 12/11/2009 18:34 S.N.Grigoriev said the following: > > 12.11.09, 15:36, "Andriy Gapon" > wrote: > >> Serguey, >> are you sure that setting vm.pmap.pg_ps_enabled=0 doesn't help you? >> I know that already asked you this once. >> But, could you please try again with vm.pmap.pg_ps_enabled=0 and hw.mca.enabled=1 >> and see what kind of behavior you get? >> I am curious what would happen, would it be the same kind of machine check condition. > > Andriy, > > I've done the world compilation with 'vm.pmap.pg_ps_enabled=0'. > The first attempt has finished with silent reboot. The second one has > been captured by the debugger: > > panic: backgroundwritedone: lost buffer > cpuid = 0 > KDB: enter: panic > [thread pid 3 tid 100014 ] > Stopped at breakpoint+0x5: leave > This is a really weird panic. Looks like perhaps there are multiple problems with your system. I wouldn't rule out a real hardware problem. Not sure what can be done. -- Andriy Gapon From quakelee at geekcn.org Fri Nov 13 08:42:56 2009 From: quakelee at geekcn.org (Chao Shin) Date: Fri Nov 13 08:43:10 2009 Subject: 8.0-RC3 Available In-Reply-To: <1258040317.7556.29.camel@bauer.cse.buffalo.edu> References: <1258040317.7556.29.camel@bauer.cse.buffalo.edu> Message-ID: Hi All, Is sysinstall can work now? After I set Label in sysinstall it has message come out said "Unable to find device node for /dev/ad4s1b in /dev! The creation of filesystems will be aborted." and installation aborted. I have installed freebsd with sysinstall ten years, that is first time I meet that > > The third and hopefully last of the Release Candidates for the FreeBSD > 8.0 release cycle is now available. Unless something catastrophic comes > up within the next couple of days we will begin the final builds for > 8.0-RELEASE. > > There is one known issue with the igb(4) driver we are still deciding > whether or not to fix as part of 8.0-RELEASE versus doing an Errata > Notice for it some time after the release is out. It has been patched > in head, and the SVN commit for it is r199192. If any of you are able > to give that patch a try on a machine with the igb(4) NIC it would be > appreciated. > > If you notice problems you can report them through the normal Gnats PR > system or on the freebsd-current mailing list. I do cross-post > announcements to freebsd-stable because this particular release is > "about to become a stable branch" but when it comes to watching for > issues related to the release most of the developers pay more attention > to the freebsd-current list. > > ISO images for all supported architectures are available on the FTP > sites, and a "memory stick" image is available for amd64/i386 > architectures. For amd64/i386 architectures the cdrom and memstick > images include the documentation packages but no other packages. The > DVD image includes the packages that will probably be available on the > official release media but is subject to change between now and release. > For sparc64 there is now a livefs cdrom, disc1 includes the > documentation packages, and the DVD image has the set of packages that > currently build for sparc64 (which is a sub-set of the set provided for > amd64/i386). > > If you are using csup/cvsup methods to update an older system the branch > tag to use is RELENG_8_0. > > The freebsd-update(8) utility supports binary upgrades of i386 and amd64 > systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, > 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, 8.0-BETA4, > 8.0-RC1 or 8.0-RC2 can upgrade as follows: > # freebsd-update upgrade -r 8.0-RC3 > During this process, FreeBSD Update may ask the user to help by merging > some configuration files or by confirming that the automatically > performed merging was done correctly. Systems running 8.0-BETA3 may > print the warning > > INDEX-OLD.all: Invalid arguments > > when downloading updates; this warning is a harmless bug (fixed in > 8.0-BETA4) and can be safely ignored. > > # freebsd-update install > The system must be rebooted with the newly installed kernel before > continuing. > # shutdown -r now > After rebooting, freebsd-update needs to be run again to install the new > userland components: > > # freebsd-update install > At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or > earlier will be prompted by freebsd-update to rebuild all third-party > applications (e.g., ports installed from the ports tree) due to updates > in system libraries. See: > > http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html > > for mode details. After updating installed third-party applications > (and again, only if freebsd-update printed a message indicating that > this was necessary), run freebsd-update again so that it can delete the > old (no longer used) system libraries: > > # freebsd-update install > Finally, reboot into 8.0-RC3: > # shutdown -r now > > MD5/SHA256 checksums for the image files: > > MD5 (8.0-RC3-amd64-bootonly.iso) = 641881caa82ea85c118bc15fff12fce6 > MD5 (8.0-RC3-amd64-disc1.iso) = 854c273b89792cd0366d5399df1034eb > MD5 (8.0-RC3-amd64-dvd1.iso) = 9bd1bb2507bc2a3037bc321bb2724bd6 > MD5 (8.0-RC3-amd64-livefs.iso) = c5f427c8bf823e10a5348935cec2d7ee > MD5 (8.0-RC3-amd64-memstick.img) = 6af9e213914a58a5779715ae5882bd25 > > MD5 (8.0-RC3-i386-bootonly.iso) = dfaec92ae358ab780d317aa66482ca9e > MD5 (8.0-RC3-i386-disc1.iso) = 460f6cfddaebee6ae59a7d5f73695246 > MD5 (8.0-RC3-i386-dvd1.iso) = 98d3f65f2444a8745f787df5ce9e1f0c > MD5 (8.0-RC3-i386-livefs.iso) = 5184b7f6403d1d24991533bde0e580ff > MD5 (8.0-RC3-i386-memstick.img) = 8774ef1d6bdf541e440f2f8ed22a2493 > > MD5 (8.0-RC3-ia64-bootonly.iso) = fd0af8f34937cf7fc78ea0063252afb7 > MD5 (8.0-RC3-ia64-disc1.iso) = 96313c25e53fc333c258ed675007f3d7 > MD5 (8.0-RC3-ia64-disc2.iso) = 235714607a2805c396ece829839405be > MD5 (8.0-RC3-ia64-disc3.iso) = 53fca9243ccc788190ca58d24f363cbe > MD5 (8.0-RC3-ia64-dvd1.iso) = 4e24736ab50bc2227c72dbeab6869266 > MD5 (8.0-RC3-ia64-livefs.iso) = b6d76cf77ed714631bf714ff78b8e950 > > MD5 (8.0-RC3-pc98-bootonly.iso) = 137d17ec3830b6ae831b6fb48adf86e0 > MD5 (8.0-RC3-pc98-disc1.iso) = 3624b1f7b3a659a7454718e38b9a1ee0 > MD5 (8.0-RC3-pc98-livefs.iso) = 29ed3786b2df1c2e72e45d1187f3e788 > MD5 (8.0-RC3-powerpc-bootonly.iso) = e7d8508639dee4aed5e52a24d6e27b69 > MD5 (8.0-RC3-powerpc-disc1.iso) = 1016ae7753db153b7be0f5d167f595b9 > MD5 (8.0-RC3-powerpc-disc2.iso) = aec2400454631cc2eaecb6f618bfecc8 > MD5 (8.0-RC3-powerpc-disc3.iso) = fe36d621ad4b6347f8ade9800ccfab7b > > MD5 (8.0-RC3-sparc64-bootonly.iso) = c35ddcb4dd050c793d89973eba02df72 > MD5 (8.0-RC3-sparc64-disc1.iso) = 0d3855603ac868609fb882c321555508 > MD5 (8.0-RC3-sparc64-dvd1.iso) = 7a402ec8d17804bd6d16fad0969c9e52 > MD5 (8.0-RC3-sparc64-livefs.iso) = 61c90ecce584c0c91f91e744f40a7d42 > > SHA256 (8.0-RC3-amd64-bootonly.iso) = > fbf7c68cf81c300ec4e944ed6491f65d217168a85c1863c019cb41eec30cae94 > SHA256 (8.0-RC3-amd64-disc1.iso) = > 7e377f38cb6dc0ba1aa1fa13facf7e03f3cefad3d1490de797ed3a91680892e8 > SHA256 (8.0-RC3-amd64-dvd1.iso) = > fa4671d9b9b5b8208579d51cc2f72188a9537984ee28ba851236a52f32022597 > SHA256 (8.0-RC3-amd64-livefs.iso) = > c8c3728583b43e76d5e305b20fed578474adb5b14dbf2537b8ca9156b2d1c4cd > SHA256 (8.0-RC3-amd64-memstick.img) = > b8d90dbfca07160d9818bf6705b5dd99ba25fe1624cdda3f3f4919681d1b1af1 > > SHA256 (8.0-RC3-i386-bootonly.iso) = > f514dbec335fbf72917b25c1e79f6bca4e9dd74e037f75ab30d810e7942ac2fc > SHA256 (8.0-RC3-i386-disc1.iso) = > 6b306af4a74df57d2c155891557878d747bac92a24c2b46947f89e7d9657addc > SHA256 (8.0-RC3-i386-dvd1.iso) = > 21794b11142eeb7eb56c8810b83dcd67230b0d26a0f0e5839866172d977a5626 > SHA256 (8.0-RC3-i386-livefs.iso) = > 3dfd45e0a5550913b29d19d989f19167159d1f926f1667d1622890a5f83be93b > SHA256 (8.0-RC3-i386-memstick.img) = > afc65bf14101ace1f069323678a8070ab84823bf191aeefa8fc9909d38e9306e > > SHA256 (8.0-RC3-ia64-bootonly.iso) = > 1fefdd0b03c943162cbb66d507e11c3a2e541e97a0742471de49f17ae96b953c > SHA256 (8.0-RC3-ia64-disc1.iso) = > 67124c8101dd3fb06dbd3771c3eb18560207b42e46c331cc2ab02ba5284a72b7 > SHA256 (8.0-RC3-ia64-disc2.iso) = > 4eaa1125f98c5ed463f7577b9818dd57dbaee0bad01a1c7543ad4cc89c1770d0 > SHA256 (8.0-RC3-ia64-disc3.iso) = > c178a48004a12d6f178b478da146582742a88a27fcbf380029ae7fb3f6db6472 > SHA256 (8.0-RC3-ia64-dvd1.iso) = > d45a8e6ae622c1985d5b9c346c74f44884f3adba3c02d0b69bb58f19b359fa73 > SHA256 (8.0-RC3-ia64-livefs.iso) = > 9132340e15b75601017b0b57902fa48926e1d1a257f1f5149baa07c15e0dede8 > > SHA256 (8.0-RC3-pc98-bootonly.iso) = > 42beee44af5859861718978a03de04e6a6fd0e63afec66a939830286fb73b22a > SHA256 (8.0-RC3-pc98-disc1.iso) = > 4b00447579349443d80082d1809b0d04688ea317a9bee3f551c13a35c82c549d > SHA256 (8.0-RC3-pc98-livefs.iso) = > 243306c98a9eade16d90994217fd89f0aba51cfd8399b1017754a3415f2e79e8 > > SHA256 (8.0-RC3-powerpc-bootonly.iso) = > 4cfbcac5fc69bb10860ed2c511bcf175be730c2fd11e57ccd2c8c77322ea5172 > SHA256 (8.0-RC3-powerpc-disc1.iso) = > 6d7725d24c01d985590566eb168cde1e6d334a3cdc6bdc7a4508ea54c205c489 > SHA256 (8.0-RC3-powerpc-disc2.iso) = > ecfd22166dd411359d74a61c1724cfa747e4a7e9cb8b47776643795f6388942b > SHA256 (8.0-RC3-powerpc-disc3.iso) = > fc3c0c2823b36cc6530c7afdb73dbfa3cb1bf6a64a59fd4a55307e1e4d1541fe > > SHA256 (8.0-RC3-sparc64-bootonly.iso) = > 44a641e1f3080112d6063f923d1e5d17f9d9eedd1004888aace77e08beca2fdf > SHA256 (8.0-RC3-sparc64-disc1.iso) = > e68eec5765f9313a9cbe4e94915b89d68caa4f4f65884be9e7b1d463862c17e3 > SHA256 (8.0-RC3-sparc64-dvd1.iso) = > e824cc316c520d29673c51e5ccf58aba9a79b17e7b61b67c1d13da7300911f7b > SHA256 (8.0-RC3-sparc64-livefs.iso) = > a4f0f8f02a9b1bad01088f5cb81a9a4d93ef6aad095afdd79cb5525b4a1e53b5 > -- The Power to Serve From quakelee at geekcn.org Fri Nov 13 08:54:27 2009 From: quakelee at geekcn.org (Chao Shin) Date: Fri Nov 13 08:54:40 2009 Subject: 8.0-RC3 Available In-Reply-To: References: <1258040317.7556.29.camel@bauer.cse.buffalo.edu> Message-ID: > Hi All, > > Is sysinstall can work now? > After I set Label in sysinstall it has message come out said > "Unable to find device node for /dev/ad4s1b in /dev! > The creation of filesystems will be aborted." > and installation aborted. > > I have installed freebsd with sysinstall ten years, that is first time I > meet that > my box is dell's optiplex 745, I've installed 7.2R on it without any problem before. >> >> The third and hopefully last of the Release Candidates for the FreeBSD >> 8.0 release cycle is now available. Unless something catastrophic comes >> up within the next couple of days we will begin the final builds for >> 8.0-RELEASE. >> >> There is one known issue with the igb(4) driver we are still deciding >> whether or not to fix as part of 8.0-RELEASE versus doing an Errata >> Notice for it some time after the release is out. It has been patched >> in head, and the SVN commit for it is r199192. If any of you are able >> to give that patch a try on a machine with the igb(4) NIC it would be >> appreciated. >> >> If you notice problems you can report them through the normal Gnats PR >> system or on the freebsd-current mailing list. I do cross-post >> announcements to freebsd-stable because this particular release is >> "about to become a stable branch" but when it comes to watching for >> issues related to the release most of the developers pay more attention >> to the freebsd-current list. >> >> ISO images for all supported architectures are available on the FTP >> sites, and a "memory stick" image is available for amd64/i386 >> architectures. For amd64/i386 architectures the cdrom and memstick >> images include the documentation packages but no other packages. The >> DVD image includes the packages that will probably be available on the >> official release media but is subject to change between now and release. >> For sparc64 there is now a livefs cdrom, disc1 includes the >> documentation packages, and the DVD image has the set of packages that >> currently build for sparc64 (which is a sub-set of the set provided for >> amd64/i386). >> >> If you are using csup/cvsup methods to update an older system the branch >> tag to use is RELENG_8_0. >> >> The freebsd-update(8) utility supports binary upgrades of i386 and amd64 >> systems running earlier FreeBSD releases. Systems running 7.0-RELEASE, >> 7.1-RELEASE, 7.2-RELEASE, 8.0-BETA1, 8.0-BETA2, 8.0-BETA3, 8.0-BETA4, >> 8.0-RC1 or 8.0-RC2 can upgrade as follows: >> # freebsd-update upgrade -r 8.0-RC3 >> During this process, FreeBSD Update may ask the user to help by merging >> some configuration files or by confirming that the automatically >> performed merging was done correctly. Systems running 8.0-BETA3 may >> print the warning >> >> INDEX-OLD.all: Invalid arguments >> >> when downloading updates; this warning is a harmless bug (fixed in >> 8.0-BETA4) and can be safely ignored. >> >> # freebsd-update install >> The system must be rebooted with the newly installed kernel before >> continuing. >> # shutdown -r now >> After rebooting, freebsd-update needs to be run again to install the new >> userland components: >> >> # freebsd-update install >> At this point, users of systems being upgraded from FreeBSD 8.0-BETA2 or >> earlier will be prompted by freebsd-update to rebuild all third-party >> applications (e.g., ports installed from the ports tree) due to updates >> in system libraries. See: >> >> http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html >> >> for mode details. After updating installed third-party applications >> (and again, only if freebsd-update printed a message indicating that >> this was necessary), run freebsd-update again so that it can delete the >> old (no longer used) system libraries: >> >> # freebsd-update install >> Finally, reboot into 8.0-RC3: >> # shutdown -r now >> >> MD5/SHA256 checksums for the image files: >> >> MD5 (8.0-RC3-amd64-bootonly.iso) = 641881caa82ea85c118bc15fff12fce6 >> MD5 (8.0-RC3-amd64-disc1.iso) = 854c273b89792cd0366d5399df1034eb >> MD5 (8.0-RC3-amd64-dvd1.iso) = 9bd1bb2507bc2a3037bc321bb2724bd6 >> MD5 (8.0-RC3-amd64-livefs.iso) = c5f427c8bf823e10a5348935cec2d7ee >> MD5 (8.0-RC3-amd64-memstick.img) = 6af9e213914a58a5779715ae5882bd25 >> >> MD5 (8.0-RC3-i386-bootonly.iso) = dfaec92ae358ab780d317aa66482ca9e >> MD5 (8.0-RC3-i386-disc1.iso) = 460f6cfddaebee6ae59a7d5f73695246 >> MD5 (8.0-RC3-i386-dvd1.iso) = 98d3f65f2444a8745f787df5ce9e1f0c >> MD5 (8.0-RC3-i386-livefs.iso) = 5184b7f6403d1d24991533bde0e580ff >> MD5 (8.0-RC3-i386-memstick.img) = 8774ef1d6bdf541e440f2f8ed22a2493 >> >> MD5 (8.0-RC3-ia64-bootonly.iso) = fd0af8f34937cf7fc78ea0063252afb7 >> MD5 (8.0-RC3-ia64-disc1.iso) = 96313c25e53fc333c258ed675007f3d7 >> MD5 (8.0-RC3-ia64-disc2.iso) = 235714607a2805c396ece829839405be >> MD5 (8.0-RC3-ia64-disc3.iso) = 53fca9243ccc788190ca58d24f363cbe >> MD5 (8.0-RC3-ia64-dvd1.iso) = 4e24736ab50bc2227c72dbeab6869266 >> MD5 (8.0-RC3-ia64-livefs.iso) = b6d76cf77ed714631bf714ff78b8e950 >> >> MD5 (8.0-RC3-pc98-bootonly.iso) = 137d17ec3830b6ae831b6fb48adf86e0 >> MD5 (8.0-RC3-pc98-disc1.iso) = 3624b1f7b3a659a7454718e38b9a1ee0 >> MD5 (8.0-RC3-pc98-livefs.iso) = 29ed3786b2df1c2e72e45d1187f3e788 >> MD5 (8.0-RC3-powerpc-bootonly.iso) = e7d8508639dee4aed5e52a24d6e27b69 >> MD5 (8.0-RC3-powerpc-disc1.iso) = 1016ae7753db153b7be0f5d167f595b9 >> MD5 (8.0-RC3-powerpc-disc2.iso) = aec2400454631cc2eaecb6f618bfecc8 >> MD5 (8.0-RC3-powerpc-disc3.iso) = fe36d621ad4b6347f8ade9800ccfab7b >> >> MD5 (8.0-RC3-sparc64-bootonly.iso) = c35ddcb4dd050c793d89973eba02df72 >> MD5 (8.0-RC3-sparc64-disc1.iso) = 0d3855603ac868609fb882c321555508 >> MD5 (8.0-RC3-sparc64-dvd1.iso) = 7a402ec8d17804bd6d16fad0969c9e52 >> MD5 (8.0-RC3-sparc64-livefs.iso) = 61c90ecce584c0c91f91e744f40a7d42 >> >> SHA256 (8.0-RC3-amd64-bootonly.iso) = >> fbf7c68cf81c300ec4e944ed6491f65d217168a85c1863c019cb41eec30cae94 >> SHA256 (8.0-RC3-amd64-disc1.iso) = >> 7e377f38cb6dc0ba1aa1fa13facf7e03f3cefad3d1490de797ed3a91680892e8 >> SHA256 (8.0-RC3-amd64-dvd1.iso) = >> fa4671d9b9b5b8208579d51cc2f72188a9537984ee28ba851236a52f32022597 >> SHA256 (8.0-RC3-amd64-livefs.iso) = >> c8c3728583b43e76d5e305b20fed578474adb5b14dbf2537b8ca9156b2d1c4cd >> SHA256 (8.0-RC3-amd64-memstick.img) = >> b8d90dbfca07160d9818bf6705b5dd99ba25fe1624cdda3f3f4919681d1b1af1 >> >> SHA256 (8.0-RC3-i386-bootonly.iso) = >> f514dbec335fbf72917b25c1e79f6bca4e9dd74e037f75ab30d810e7942ac2fc >> SHA256 (8.0-RC3-i386-disc1.iso) = >> 6b306af4a74df57d2c155891557878d747bac92a24c2b46947f89e7d9657addc >> SHA256 (8.0-RC3-i386-dvd1.iso) = >> 21794b11142eeb7eb56c8810b83dcd67230b0d26a0f0e5839866172d977a5626 >> SHA256 (8.0-RC3-i386-livefs.iso) = >> 3dfd45e0a5550913b29d19d989f19167159d1f926f1667d1622890a5f83be93b >> SHA256 (8.0-RC3-i386-memstick.img) = >> afc65bf14101ace1f069323678a8070ab84823bf191aeefa8fc9909d38e9306e >> >> SHA256 (8.0-RC3-ia64-bootonly.iso) = >> 1fefdd0b03c943162cbb66d507e11c3a2e541e97a0742471de49f17ae96b953c >> SHA256 (8.0-RC3-ia64-disc1.iso) = >> 67124c8101dd3fb06dbd3771c3eb18560207b42e46c331cc2ab02ba5284a72b7 >> SHA256 (8.0-RC3-ia64-disc2.iso) = >> 4eaa1125f98c5ed463f7577b9818dd57dbaee0bad01a1c7543ad4cc89c1770d0 >> SHA256 (8.0-RC3-ia64-disc3.iso) = >> c178a48004a12d6f178b478da146582742a88a27fcbf380029ae7fb3f6db6472 >> SHA256 (8.0-RC3-ia64-dvd1.iso) = >> d45a8e6ae622c1985d5b9c346c74f44884f3adba3c02d0b69bb58f19b359fa73 >> SHA256 (8.0-RC3-ia64-livefs.iso) = >> 9132340e15b75601017b0b57902fa48926e1d1a257f1f5149baa07c15e0dede8 >> >> SHA256 (8.0-RC3-pc98-bootonly.iso) = >> 42beee44af5859861718978a03de04e6a6fd0e63afec66a939830286fb73b22a >> SHA256 (8.0-RC3-pc98-disc1.iso) = >> 4b00447579349443d80082d1809b0d04688ea317a9bee3f551c13a35c82c549d >> SHA256 (8.0-RC3-pc98-livefs.iso) = >> 243306c98a9eade16d90994217fd89f0aba51cfd8399b1017754a3415f2e79e8 >> >> SHA256 (8.0-RC3-powerpc-bootonly.iso) = >> 4cfbcac5fc69bb10860ed2c511bcf175be730c2fd11e57ccd2c8c77322ea5172 >> SHA256 (8.0-RC3-powerpc-disc1.iso) = >> 6d7725d24c01d985590566eb168cde1e6d334a3cdc6bdc7a4508ea54c205c489 >> SHA256 (8.0-RC3-powerpc-disc2.iso) = >> ecfd22166dd411359d74a61c1724cfa747e4a7e9cb8b47776643795f6388942b >> SHA256 (8.0-RC3-powerpc-disc3.iso) = >> fc3c0c2823b36cc6530c7afdb73dbfa3cb1bf6a64a59fd4a55307e1e4d1541fe >> >> SHA256 (8.0-RC3-sparc64-bootonly.iso) = >> 44a641e1f3080112d6063f923d1e5d17f9d9eedd1004888aace77e08beca2fdf >> SHA256 (8.0-RC3-sparc64-disc1.iso) = >> e68eec5765f9313a9cbe4e94915b89d68caa4f4f65884be9e7b1d463862c17e3 >> SHA256 (8.0-RC3-sparc64-dvd1.iso) = >> e824cc316c520d29673c51e5ccf58aba9a79b17e7b61b67c1d13da7300911f7b >> SHA256 (8.0-RC3-sparc64-livefs.iso) = >> a4f0f8f02a9b1bad01088f5cb81a9a4d93ef6aad095afdd79cb5525b4a1e53b5 >> > > -- The Power to Serve From quakelee at geekcn.org Fri Nov 13 09:26:14 2009 From: quakelee at geekcn.org (Chao Shin) Date: Fri Nov 13 09:26:21 2009 Subject: 8.0-RC3 Available In-Reply-To: References: <1258040317.7556.29.camel@bauer.cse.buffalo.edu> Message-ID: ? Fri, 13 Nov 2009 16:42:44 +0800?Chao Shin ??: > Hi All, > > Is sysinstall can work now? > After I set Label in sysinstall it has message come out said > "Unable to find device node for /dev/ad4s1b in /dev! > The creation of filesystems will be aborted." > and installation aborted. > > I have installed freebsd with sysinstall ten years, that is first time I > meet that > I found the reason of that. I've fdisk that disk with dd mode before, the sysinstall can't overwrite the partition record, so can't label on it. If I want to install 8.0-rc3 on that disk, I have to erase the partition record with "dd if=/dev/zero of=/dev/ad4 bs=1M count=1" before installation. -- The Power to Serve From ed at 80386.nl Fri Nov 13 11:35:15 2009 From: ed at 80386.nl (Ed Schouten) Date: Fri Nov 13 11:35:22 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <20091112125903.GS64905@hoeg.nl> References: <20091111101207.GF64905@hoeg.nl> <20091112.214836.27789213.nyan@jp.FreeBSD.org> <20091112125903.GS64905@hoeg.nl> Message-ID: <20091113113515.GY64905@hoeg.nl> * Ed Schouten wrote: > * Takahashi Yoshihiro wrote: > > It seems that scterm-teken.c works for pc98, but it cannot display > > Japanese differently from scterm-sck.c. I think that Japanese support > > is more important than xterm support for pc98. So it should add > > etc/etc.pc98/ttys. > > Sure. That could work. I'll first commit the patch I have and after that > I'll decouple /etc/ttys on i386 on pc98. I'll keep you informed. Done. pc98 has its own /etc/ttys file and i386 also uses xterm now. Takahashi, I thought pc98 also used a custom TERM type (cons25w). Would it be nice if we just enabled that by default? -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20091113/472bccb3/attachment.pgp From nyan at jp.FreeBSD.org Fri Nov 13 11:51:22 2009 From: nyan at jp.FreeBSD.org (TAKAHASHI Yoshihiro) Date: Fri Nov 13 11:51:29 2009 Subject: Final call for testers: TERM=xterm In-Reply-To: <20091113113515.GY64905@hoeg.nl> References: <20091112.214836.27789213.nyan@jp.FreeBSD.org> <20091112125903.GS64905@hoeg.nl> <20091113113515.GY64905@hoeg.nl> Message-ID: <20091113.205108.173505928.nyan@jp.FreeBSD.org> In article <20091113113515.GY64905@hoeg.nl> Ed Schouten writes: > Done. pc98 has its own /etc/ttys file and i386 also uses xterm now. Thanks. > Takahashi, I thought pc98 also used a custom TERM type (cons25w). Would > it be nice if we just enabled that by default? Yes!! --- TAKAHASHI Yoshihiro From rpaulo at freebsd.org Fri Nov 13 12:21:00 2009 From: rpaulo at freebsd.org (Rui Paulo) Date: Fri Nov 13 12:21:07 2009 Subject: No DHCP lease with iwi(4)/wlan(4); works with an(4) at r197399 In-Reply-To: <20091111154359.GB1351@albert.catwhisker.org> References: <20090923140936.GF1320@albert.catwhisker.org> <3a142e750909231508j1a5092f8nfae264f367ba410@mail.gmail.com> <20090925162403.GM1320@albert.catwhisker.org> <20091111154359.GB1351@albert.catwhisker.org> Message-ID: <9A74A20E-67E9-4C32-BFDA-B0F6518BFD02@freebsd.org> On 11 Nov 2009, at 15:43, David Wolfskill wrote: > On Fri, Sep 25, 2009 at 09:24:03AM -0700, David Wolfskill wrote: >> ... >> But I did find one rather curious thing: I was able to get the >> iwi(4) to work OK (while running head) with one of my access points; >> it's the other that seems to have an issue with iwi(4) under head. >> >> I have 2 different access points at home: >> * An original Apple Airport >> * A Linksys WAP-11. >> (Each is, within the bounds of their rather different natures, >> configured the same except for channel: One is on channel 1; the other >> is on channel 6. Neither is a DHCP server: each merely passes the DHCP >> traffic.) >> >> Under stable/6 and stable/7, each works fine with iwi(4). >> >> Under head (presently at r197479), the Linksys WAP-11 works (associates >> & dhclient(8) negotiates a DHCP lease using iwi(4)/wlan(4)). >> >> Under head, the Apple Airport associates, but dhclient(8) cannot see a >> DHCP offer via iwi(4)/wlan(4). >> ... > > This morning, after upgrading head to r199179, I now cannot get a DHCP > lease using teh Linksys WAP-11. > > Prior to the upgrade, I was last running head r199134, which was able to > get a DHCP lease from teh Linksys WAP-11. > > uname strings: > > FreeBSD g1-106.catwhisker.org 9.0-CURRENT FreeBSD 9.0-CURRENT #1172 r199134: Tue Nov 10 10:47:11 PST 2009 root@d254.dwolf.juniper.net.:/common/S4/obj/usr/src/sys/CANARY i386 > > FreeBSD 9.0-CURRENT FreeBSD 9.0-CURRENT #1173 r199179: Wed Nov 11 06:50:22 PST 2009 root@g1-106.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY i386 > > [The latter has no current hostname, since dhclient-exit-hooks > didn't get an IP address.] > > I verified that the iwi0/wlan0 NIC did associate first. I recall > the UPDATING entry from a couple of days ago: > > 20091109: > The layout of the structure ieee80211req_scan_result has changed. > Applications that require wireless scan results (e.g. ifconfig(8)) > from net80211 need to be recompiled. > > and admit that I did the upgrade with -DNOCLEAN. But it worked OK > for the upgrade yesterday -- and I don't expect that I actually use > scan results in any case. (Recall that association still works.) Well, wpa_supplicant should've been rebuilt even with NOCLEAN (I used NOCLEAN, IIRC). Anyway, you wouldn't be able to associate if wpa_supplicant wasn't updated. BTW, wpa_supplicant uses scan results too. P.S.: if wpa_supplicant is old, it will display empty SSIDs if you run it with the debugging mode enabled. -- Rui Paulo From david at catwhisker.org Fri Nov 13 12:55:02 2009 From: david at catwhisker.org (David Wolfskill) Date: Fri Nov 13 12:55:08 2009 Subject: No DHCP lease with iwi(4)/wlan(4); works with an(4) at r197399 In-Reply-To: <9A74A20E-67E9-4C32-BFDA-B0F6518BFD02@freebsd.org> References: <20090923140936.GF1320@albert.catwhisker.org> <3a142e750909231508j1a5092f8nfae264f367ba410@mail.gmail.com> <20090925162403.GM1320@albert.catwhisker.org> <20091111154359.GB1351@albert.catwhisker.org> <9A74A20E-67E9-4C32-BFDA-B0F6518BFD02@freebsd.org> Message-ID: <20091113125501.GA1649@albert.catwhisker.org> On Fri, Nov 13, 2009 at 12:20:56PM +0000, Rui Paulo wrote: > ... > > 20091109: > > The layout of the structure ieee80211req_scan_result has changed. > > Applications that require wireless scan results (e.g. ifconfig(8)) > > from net80211 need to be recompiled. > > > > and admit that I did the upgrade with -DNOCLEAN. But it worked OK > > for the upgrade yesterday -- and I don't expect that I actually use > > scan results in any case. (Recall that association still works.) > > Well, wpa_supplicant shou