Re: 8-RC1: ral0: need multicast update callback
On Fri, Sep 25, 2009 at 11:29 PM, Scott Lambert lamb...@lambertfam.org wrote: iwn does not function after resume so I've actually run ethernet cables to where I use the laptop now. I have to unload the if_iwn module on suspend, and reload it on resume (via /etc/rc.[suspend|resume], of course). Have you tried that? -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
iwn driver on 7.1
I have a working driver for the Intel 4965, aka iwn(4), loaded on my Lenovo X300 running FreeBSD 7.1-RELEASE (amd64). This driver is a slightly-modified version of the iwn(4) driver backported from 8.0-CURRENT by Gavin Atkinson: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=221758+0+/usr/local/www/db/text/2008/freebsd-stable/20080928.freebsd-stable I was seeing the same symptoms described in these threads (among others): http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045264.html http://www.freebsd.org/cgi/getmsg.cgi?fetch=1334322+1338147+/usr/local/www/db/text/2009/freebsd-questions/20090118.freebsd-questions http://www.freebsd.org/cgi/getmsg.cgi?fetch=1418632+1421765+/usr/local/www/db/text/2009/freebsd-questions/20090118.freebsd-questions ...so I debugged and modified Gavin's driver for my system. The driver and the source tree diff can be downloaded here for any brave souls wanting to test it out: http://sites.google.com/site/bsdgooch/files I'm using the driver now to send this e-mail over a link to my TP-LINK TL-WR941ND access point (with WPA2). Feedback and bug reports would be useful. -brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: iwn driver on 7.1
The kernel panic was due to a NULL pointer dereference in the module. The code that was commented out created a situation in which the array of structs (line 2412): static const struct iwn_chan_band iwn_bands[] contained only 2 items. The code following the struct array that obtained the list of authorized channels: /* read the list of authorized channels */ for (i = 0; i N(iwn_bands)-2; i++) iwn_read_eeprom_band(sc, iwn_bands[i]); didn't actually get a list of anything, since N(iwn_bands)-2 evaluates to zero in this case. The NULL pointer part comes in when the call to ieee80211_sort_channels() on line 2436 sends a list of no items with a value of 0 for ic-ic_nchans. The backported insertion sort code from 8.0-CURRENT's 802.11 stack fails somewhere because of this value, due to access of some memory address in the chancompar() or swap(?) -- I didn't really dig that far into it. I guess the purpose of commenting out the A channels in the iwn_bands[] was to keep the driver from potentially using them, but honestly, I'm not sure if that's the appropriate way to do that (I'm just getting into this stuff). I'm sure the MFC'd VAP stuff that Sam Leffler is working on will alleviate all of this, but I wanted a working iwn(4) for now ;) On Sun, Jan 18, 2009 at 4:10 PM, Jan Henrik Sylvester m...@janh.de wrote: Da Rock wrote: On Sun, 2009-01-18 at 14:17 -0600, Brandon Gooch wrote: I have a working driver for the Intel 4965, aka iwn(4), loaded on my Lenovo X300 running FreeBSD 7.1-RELEASE (amd64). This driver is a slightly-modified version of the iwn(4) driver backported from 8.0-CURRENT by Gavin Atkinson: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=221758+0+/usr/local/www/db/text/2008/freebsd-stable/20080928.freebsd-stable I was seeing the same symptoms described in these threads (among others): http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045264.html http://www.freebsd.org/cgi/getmsg.cgi?fetch=1334322+1338147+/usr/local/www/db/text/2009/freebsd-questions/20090118.freebsd-questions http://www.freebsd.org/cgi/getmsg.cgi?fetch=1418632+1421765+/usr/local/www/db/text/2009/freebsd-questions/20090118.freebsd-questions ...so I debugged and modified Gavin's driver for my system. The driver and the source tree diff can be downloaded here for any brave souls wanting to test it out: http://sites.google.com/site/bsdgooch/files I'm using the driver now to send this e-mail over a link to my TP-LINK TL-WR941ND access point (with WPA2). Feedback and bug reports would be useful. -brandon Sounds like you got to it before I did- thank god! :) Question though: have you got it figured for a channels yet? I'll test it for you and keep you updated with my results. Thanks for working on the driver! The only difference to the version of gavin that I could see is that the bands in iwn_bands that got commented out were brought back. Or did I miss something? Do you know why they were commented out and it was unnecessary? Or was it just to fix the crash? I did a few test runs: It does not crash immediately as the version from gavin, but the error I had with the perforce version iwn0: error, INTR=8200SW_ERROR,RX_INTR STATUS=0x1 iwn0: iwn_config: could not set power mode, error 35 is there -- in 3 out of 3 tries. So nothing improved there. (I hit that error on first use in about 50% of the cases before.) Moreover, at 3 out of 4 tries to 'kldunload if_iwn' after hitting the error (after '/etc/rc.d/netif stop iwn0' and 'ifconfig iwn0 down'), there was a crash: 2 page faults and 1 freeze. I have not had that with the perforce version. (Maybe once long ago, but I think I forgot to stop iwn0 at that time.) The one time I actually got the (WPA2) connection up, I was able to transfer with a similar speed as with the perforce version. Thus, for me, there are no improvement over the (old) perforce version. Probably by chance, but I had more crashes. I think the thread on stable@ should rather be continued than the one on questions@, but since Da Rock answered on questions@, I reinclude both. Cheers, Jan Henrik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: iwn driver on 7.1 [no vaps in RELENG_7]
On Mon, Jan 19, 2009 at 7:38 PM, Damian Gerow dge...@afflictions.org wrote: Sam Leffler wrote: : OTOH iwn is now out of date and someone needs to update it. There's : newer firmware that is supposed to fix many of the bugs I hit when I : worked on the driver (and Intel refused to acknowledge) and obsd has : added support for newer parts that people want. It'd be great if : someone wanted to take over this driver. I've been working on this driver for the past few weeks (Christmas provided a healthy distraction), but it's a steep learning curve for a novice C coder. If anyone wants to work on this, let me know, as I have a small portion of the work already done. - Damian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org I'd like to work on this as well. I just pulled down the iwn code from OpenBSD current a little while ago and started hacking on it. I haven't made a lot of progress, so I'll gladly work with you on it. I'm a decent C programmer, but my lack of knowledge of kernel internals, functions, and data structures is my stumbling block. That's one of the main reasons I'm all about getting this driver working -- it gives me yet another chance to get into the kernel source and learn something new. Where do we begin? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: iwn driver on 7.1 [no vaps in RELENG_7]
On Mon, Jan 19, 2009 at 8:48 PM, Da Rock rock_on_the_...@comcen.com.au wrote: On Mon, 2009-01-19 at 20:38 -0500, Damian Gerow wrote: Sam Leffler wrote: : OTOH iwn is now out of date and someone needs to update it. There's : newer firmware that is supposed to fix many of the bugs I hit when I : worked on the driver (and Intel refused to acknowledge) and obsd has : added support for newer parts that people want. It'd be great if : someone wanted to take over this driver. I've been working on this driver for the past few weeks (Christmas provided a healthy distraction), but it's a steep learning curve for a novice C coder. If anyone wants to work on this, let me know, as I have a small portion of the work already done. - Damian I'm willing to work on it (doing so now), but from what you have said here it sounds like you're in the same boat as myself as I'm very new to this too :) What about collaboration between us with a Freebsd core team mentor? Is this possible? Code, test, then send the new code through the core team member for approval as well as hints to get the job done? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org I don't know how mentoring works in the FreeBSD world or if a canonical process of mentoring even exists, but I would definitely be willing to participate. I know it would be a heck of a lot better than hacking around on this stuff by myself. -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS and sh(1) panic: spin lock [lock addr] (smp rendezvous) held by [sh(1) proc tid] too long
On Sat, Feb 20, 2010 at 4:19 PM, Attilio Rao atti...@freebsd.org wrote: 2010/1/27 Brandon Gooch jamesbrandongo...@gmail.com: The machine, a Dell Optiplex 755, has been locking up recently. The situation usually occurs while using VirtualBox (running a 64-bit Windows 7 instance) and doing anything else in another xterm (such as rebuilding a port). I've been unable to reliably reproduce it (I'm in an X session and the machine will not panic properly). However, while rebuilding Xorg today at ttyv0 and runnning VBoxHeadless on ttyv1, I managed to trigger what I believe is the lockup. I've attached a textdump in hopes that someone may be able to take a look and provide clues or instruction on debugging this. I think that jhb@ saw a similar problem while working on nVidia driver or the like. Not sure if he made any progress to debug this. The situation has improved slightly, although attempting to run two VirtualBox guests at the same time inevitably leads to a lock-up. I've just taken to running one at a time. Not ideal, but until more debugging can be done, it's the only option I have. I ran into this using nvidia and radeon both. I can't really find a pattern, but I do see it when Windows is trying to draw a new window, or dim the screen when UAC kicks in... BTW, anyone know how to get a good dump when running Xorg? I'm not sure I've ever been able to, even when I panic on something non related to X or video drivers. -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: rc.d/rc.subr support for multiple FIBs
On Fri, Mar 12, 2010 at 12:44 PM, Steve Polyack kor...@comcast.net wrote: With multiple FIB support generally available in FreeBSD 8.0-RELEASE it would be quite beneficial to have the ability to build routing tables in secondary FIBs as well as start certain applications in certain FIBs from within rc.conf(5). I've done some poking around and came across two PRs which implement exactly what I'm looking for: http://www.freebsd.org/cgi/query-pr.cgi?pr=132483 http://www.freebsd.org/cgi/query-pr.cgi?pr=132476 My question is whether there are any plans to commit these into -CURRENT and possibly MFC them to a future 8.x-RELEASE. Having multiple FIBs available has been great so far, it goes hand and hand with Multi-IP Jails. The only thing missing are native methods for constructing the routing tables on boot (Yes, there is rc.local, but I don't want to go there...). Thanks, Steve Polyack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org I too would love to see this integrated; I've hacked together my own set of rc scripts (elegant in no way) to accomplish something similar on my systems. Also, general documentation regarding multiple FIBs (if that's what they are to be referred to as) in the official docs would be cool -- I'm not knowledgeable enough to do it myself (although I'm a pretty decent hand at Documentation Testing :) -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em driver regression
On Thu, Apr 8, 2010 at 9:46 AM, Mike Tancsa m...@sentex.net wrote: OK, some more data... It seems dhclient is getting upset as well since the updated driver Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 6 Apr 8 10:28:38 ich10 dhclient[1383]: ip length 328 disagrees with bytes received 332. Apr 8 10:28:38 ich10 dhclient[1383]: accepting packet with data after udp payload. Apr 8 10:28:38 ich10 dhclient[1383]: DHCPOFFER from 192.168.xx.1 Apr 8 10:28:40 ich10 dhclient[1383]: DHCPREQUEST on em0 to 255.255.255.255 port 67 Apr 8 10:28:40 ich10 dhclient[1383]: ip length 328 disagrees with bytes received 332. Apr 8 10:28:40 ich10 dhclient[1383]: accepting packet with data after udp payload. Apr 8 10:28:40 ich10 dhclient[1383]: DHCPACK from 192.168.xx.1 I also tried manually applying the patch below http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016189.htmlhttp://lists.freebsd.org/pipermail/svn-src-head/2010-April/016189.html but still get the same error on dhclient Apr 8 10:28:40 ich10 dhclient[1383]: ip length 328 disagrees with bytes received 332. which was not there before the 7.0.0 driver update em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=399bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_UCAST,WOL_MCAST,WOL_MAGIC ether 00:1c:c0:95:0d:0d inet 192.168.43.219 netmask 0xff00 broadcast 192.168.43.255 media: Ethernet autoselect (100baseTX full-duplex) status: active Also, should not # ifconfig em0 -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso 0(ich10)# ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=388bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC ether 00:1c:c0:95:0d:0d inet 192.168.43.219 netmask 0xff00 broadcast 192.168.43.255 media: Ethernet autoselect (100baseTX full-duplex) status: active 0(ich10)# killall dhclient 0(ich10)# dhclient em0 DHCPREQUEST on em0 to 255.255.255.255 port 67 ip length 328 disagrees with bytes received 332. accepting packet with data after udp payload. DHCPACK from 192.168.xx.1 bound to 192.168.xx.219 -- renewal in 22777 seconds. 0(ich10)# disable all the vlan features on the nic ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org I'm also seeing this. Jack, I've built the most recent revision from CURRENT and installed it on the 8-STABLE machine. This is the computer I e-mailed about yesterday (20100407) with which I've been having trouble with VirtualBox 3.1.6 (FreeBSD Host) Windows Guests, bridged networking, etc... Same situation with VirtualBox and still: ip length 328 disagrees with bytes received 332 -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em driver regression
On Thu, Apr 8, 2010 at 11:04 AM, Jack Vogel jfvo...@gmail.com wrote: Brandon, Did the checkin of yesterday afternoon resolve the problem of the win7 systems in VirtualBox? I will continue to look at this today. Jack Sorry, I was a little unclear on that :( No, the issue wasn't resolved even after the most recent commits. I will be available for testing all day (and this evening if required), let me know what you'd like from me, and I'll help any way I can. -Brandon On Thu, Apr 8, 2010 at 8:29 AM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Thu, Apr 8, 2010 at 9:46 AM, Mike Tancsa m...@sentex.net wrote: OK, some more data... It seems dhclient is getting upset as well since the updated driver Apr 8 10:28:37 ich10 dhclient[1383]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 6 Apr 8 10:28:38 ich10 dhclient[1383]: ip length 328 disagrees with bytes received 332. Apr 8 10:28:38 ich10 dhclient[1383]: accepting packet with data after udp payload. Apr 8 10:28:38 ich10 dhclient[1383]: DHCPOFFER from 192.168.xx.1 Apr 8 10:28:40 ich10 dhclient[1383]: DHCPREQUEST on em0 to 255.255.255.255 port 67 Apr 8 10:28:40 ich10 dhclient[1383]: ip length 328 disagrees with bytes received 332. Apr 8 10:28:40 ich10 dhclient[1383]: accepting packet with data after udp payload. Apr 8 10:28:40 ich10 dhclient[1383]: DHCPACK from 192.168.xx.1 I also tried manually applying the patch below http://lists.freebsd.org/pipermail/svn-src-head/2010-April/016189.htmlhttp://lists.freebsd.org/pipermail/svn-src-head/2010-April/016189.html but still get the same error on dhclient Apr 8 10:28:40 ich10 dhclient[1383]: ip length 328 disagrees with bytes received 332. which was not there before the 7.0.0 driver update em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=399bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_UCAST,WOL_MCAST,WOL_MAGIC ether 00:1c:c0:95:0d:0d inet 192.168.43.219 netmask 0xff00 broadcast 192.168.43.255 media: Ethernet autoselect (100baseTX full-duplex) status: active Also, should not # ifconfig em0 -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso 0(ich10)# ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=388bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC ether 00:1c:c0:95:0d:0d inet 192.168.43.219 netmask 0xff00 broadcast 192.168.43.255 media: Ethernet autoselect (100baseTX full-duplex) status: active 0(ich10)# killall dhclient 0(ich10)# dhclient em0 DHCPREQUEST on em0 to 255.255.255.255 port 67 ip length 328 disagrees with bytes received 332. accepting packet with data after udp payload. DHCPACK from 192.168.xx.1 bound to 192.168.xx.219 -- renewal in 22777 seconds. 0(ich10)# disable all the vlan features on the nic ? ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org I'm also seeing this. Jack, I've built the most recent revision from CURRENT and installed it on the 8-STABLE machine. This is the computer I e-mailed about yesterday (20100407) with which I've been having trouble with VirtualBox 3.1.6 (FreeBSD Host) Windows Guests, bridged networking, etc... Same situation with VirtualBox and still: ip length 328 disagrees with bytes received 332 -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em driver regression
On Thu, Apr 8, 2010 at 11:52 AM, Jack Vogel jfvo...@gmail.com wrote: Mike, I noticed this connection is only 100Mb, that isn't accidental? And, is it possible for you to check a connection at 1Gb and see if the watchdogs don't happen. My test engineer is running this code, and we are having trouble repro'ing the issue, so any clues might help. Is the kernel 64 or 32 bit? Jack Not to butt in or anything... 64-bit FreeBSD Stable, 1Gb em(4) connected to Cisco 2960G trunking port. My dmesg: Copyright (c) 1992-2010 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-STABLE #2 r206210:206343MS: Wed Apr 7 16:18:14 CDT 2010 r...@bgooch755.se.edu:/usr/obj/usr/src/sys/DELL755 amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (2394.00-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fb Family = 6 Model = f Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8103940096 (7728 MB) ACPI APIC Table: DELL B9K FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 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 ioapic0: Changing APIC ID to 8 ioapic0 Version 2.0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: DELL B9K 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 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xdc80-0xdcff mem 0xfd00-0xfdff,0xd000-0xdfff,0xfa00-0xfbff irq 16 at device 0.0 on pci1 nvidia0: GeForce 8400 GS on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [ITHREAD] pci0: simple comms at device 3.0 (no driver attached) atapci0: Intel ATA controller port 0xfe80-0xfe87,0xfe90-0xfe93,0xfea0-0xfea7,0xfeb0-0xfeb3,0xfef0-0xfeff irq 18 at device 3.2 on pci0 atapci0: [ITHREAD] ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] ata3: ATA channel 1 on atapci0 ata3: [ITHREAD] pci0: simple comms, UART at device 3.3 (no driver attached) em0: Intel(R) PRO/1000 Network Connection 7.0.1 port 0xecc0-0xecdf mem 0xfebe-0xfebf,0xfebdb000-0xfebdbfff irq 21 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1e:4f:d5:84:b7 uhci0: Intel 82801I (ICH9) USB controller port 0xff20-0xff3f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: Intel 82801I (ICH9) USB controller on uhci0 uhci1: Intel 82801I (ICH9) USB controller port 0xff00-0xff1f irq 17 at device 26.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: Intel 82801I (ICH9) USB controller on uhci1 ehci0: Intel 82801I (ICH9) USB 2.0 controller mem 0xfebd9c00-0xfebd9fff irq 22 at device 26.7 on pci0 ehci0: [ITHREAD] usbus2: EHCI version 1.0 usbus2: Intel 82801I (ICH9) USB 2.0 controller on ehci0 hdac0: Intel 82801I High Definition Audio Controller mem 0xfebdc000-0xfebd irq 16 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pcib2: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 uhci2: Intel 82801I (ICH9) USB controller port 0xff80-0xff9f irq 23 at device 29.0 on pci0 uhci2: [ITHREAD] usbus3: Intel 82801I (ICH9) USB controller on uhci2 uhci3: Intel 82801I (ICH9) USB controller port 0xff60-0xff7f irq 17 at device 29.1 on pci0 uhci3: [ITHREAD] usbus4: Intel 82801I (ICH9) USB controller on uhci3 uhci4: Intel 82801I (ICH9) USB controller port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci4: [ITHREAD] usbus5: Intel 82801I (ICH9) USB controller on uhci4 ehci1: Intel 82801I (ICH9) USB 2.0 controller mem 0xff980800-0xff980bff irq 23 at device 29.7 on pci0 ehci1: [ITHREAD] usbus6: EHCI version 1.0 usbus6: Intel 82801I (ICH9) USB 2.0 controller on ehci1 pcib3: ACPI PCI-PCI bridge at device 30.0 on pci0 pci3: ACPI PCI bus on pcib3 atapci1: SiI 3114 SATA150 controller
Re: em driver regression
On Thu, Apr 8, 2010 at 12:06 PM, Jack Vogel jfvo...@gmail.com wrote: On Thu, Apr 8, 2010 at 10:01 AM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Thu, Apr 8, 2010 at 11:52 AM, Jack Vogel jfvo...@gmail.com wrote: Mike, I noticed this connection is only 100Mb, that isn't accidental? And, is it possible for you to check a connection at 1Gb and see if the watchdogs don't happen. My test engineer is running this code, and we are having trouble repro'ing the issue, so any clues might help. Is the kernel 64 or 32 bit? Jack Not to butt in or anything... Not butting in :) OK, so this all looks fine or am I missing something? Jack This is the dmesg from the system exhibiting the ip length 328 disagrees with bytes received 332 while attempting to obtain a lease on the two DHCP-enabled VLANs, and also manifests in the VirtualBox bridged networking guests. I can honestly say that other than the output from dhclient and the VirtualBox issue, I might not have noticed problems otherwise. For instance, I have a VLAN interface configured to connect to an outside LAN segment and I'm running sshd on that interfaces IP address (using the new multiple routing table feature as well). I was able to connect to the sshd instance as usual, and I can make connections out as in: # setfib 4 ping google.com ...things seemed OK. Until VirtualBox. Then I started paying attention to messages scrolling by as my machine booted and saw the dhclient ip length thing (just as Mike Tancsa had) and thought, It must be the new em(4) driver. That's my story :) I don't know what chip my em(4) device is, how can I check that? Also, would some type of traffic capture help in this case? -Brandon 64-bit FreeBSD Stable, 1Gb em(4) connected to Cisco 2960G trunking port. My dmesg: Copyright (c) 1992-2010 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-STABLE #2 r206210:206343MS: Wed Apr 7 16:18:14 CDT 2010 r...@bgooch755.se.edu:/usr/obj/usr/src/sys/DELL755 amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz (2394.00-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fb Family = 6 Model = f Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8103940096 (7728 MB) ACPI APIC Table: DELL B9K FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 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 ioapic0: Changing APIC ID to 8 ioapic0 Version 2.0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: DELL B9K 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 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xdc80-0xdcff mem 0xfd00-0xfdff,0xd000-0xdfff,0xfa00-0xfbff irq 16 at device 0.0 on pci1 nvidia0: GeForce 8400 GS on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [ITHREAD] pci0: simple comms at device 3.0 (no driver attached) atapci0: Intel ATA controller port 0xfe80-0xfe87,0xfe90-0xfe93,0xfea0-0xfea7,0xfeb0-0xfeb3,0xfef0-0xfeff irq 18 at device 3.2 on pci0 atapci0: [ITHREAD] ata2: ATA channel 0 on atapci0 ata2: [ITHREAD] ata3: ATA channel 1 on atapci0 ata3: [ITHREAD] pci0: simple comms, UART at device 3.3 (no driver attached) em0: Intel(R) PRO/1000 Network Connection 7.0.1 port 0xecc0-0xecdf mem 0xfebe-0xfebf,0xfebdb000-0xfebdbfff irq 21 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:1e:4f:d5:84:b7 uhci0: Intel 82801I (ICH9) USB controller port 0xff20-0xff3f irq 16 at device 26.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: Intel 82801I (ICH9) USB controller on uhci0 uhci1: Intel 82801I (ICH9) USB controller port
Re: em driver regression
On Thu, Apr 8, 2010 at 2:17 PM, Jack Vogel jfvo...@gmail.com wrote: Try the code I just checked in, it puts in the CRC stripping, but also tweaks the TX code, this may resolve the watchdogs. Let me know. Cheers, Jack Yes, this is indeed the fix for both the dhclient and VirtualBox issue (at least with my setup). There appear to be no ill effects either. Thank you Jack (and Pyun) for tracking down the problems! I'll keep my eyes open for anything else. -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em regression, UDP LOR followed by ssh stall
On Fri, Apr 16, 2010 at 10:29 AM, Jack Vogel jfvo...@gmail.com wrote:
On Fri, Apr 16, 2010 at 5:22 AM, John Baldwin j...@freebsd.org wrote:
On Friday 16 April 2010 5:37:59 am Harald Schmalzbauer wrote:
Jeremy Chadwick schrieb am 16.04.2010 11:28 (localtime):
On Fri, Apr 16, 2010 at 11:18:56AM +0200, Harald Schmalzbauer wrote:
with RELENG_8 from 6 weeks ago I never ran into the problem that my
ssh connection stalled.
With today's RELENG_8 it reproducably hangs at first login. After
some time I can open another ssh session which seems to stay without
problems, but the first sessions is always dying a few seconds after
login.
here's a LOR:
{snip}
The e1000/em driver was recently modified (heavily). I saw the large
number of commits come across in a csup a few weeks ago, and there's
even more coming across in recent days (~38 hours ago):
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/
This is the 2nd problem report to come in about the recent e1000/em
changes. Because of this, I've avoided building kernel on all of my
systems, and would recommend others avoid doing the same until these
problems can get worked out.
Jack, can you shed some light on what's going on here?
Som more info:
it seems only one of my em interfaces is affected. The other interface
doesn't show any odd behaviour:
em1: Intel(R) PRO/1000 Legacy Network Connection 1.0.0 port
0x1800-0x183f mem 0xe192-0xe193,0xe190-0xe191 irq 18 at
device 2.0 on pci3
em1: [FILTER]
em1: Ethernet address: 00:15:17:8d:aa:d4
I only have one
em1: Watchdog timeout -- resetting
Try pulling in the latest version of if_lem.c from HEAD. There was a bug
in
if_lem.c that was missing an assignment that caused spurious watchdog
resets.
Yes, I can see I should get the stuff MFC'd, I will do that today if
possible.
Jack
Thanks Jack! Your work is very appreciated.
-Brandon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pf stalls connection when using route-to
On Tue, Apr 13, 2010 at 10:53 AM, Lin Jui-Nan Eric eric...@tamama.org wrote: On Tue, Apr 13, 2010 at 11:19 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: What FreeBSD version? uname -a output please. I have tried 7.2-R and 8.0-R. Both version stalls, too. 8.0-RELEASE: # uname -a FreeBSD bsd8 8.0-RELEASE-p2 FreeBSD 8.0-RELEASE-p2 #3: Wed Mar 3 17:15:52 CST 2010 r...@bsd8:/usr/obj/usr/src/sys/KERNEL amd64 [SNIP] Jack Vogel recently committed an updated, overhauled em(4) driver to 9-CURRENT, which was MFC'd to 8-STABLE: http://svn.freebsd.org/viewvc/base/stable/8/sys/dev/e1000/ Would it be possible for you to try your configuration on one of these newer versions? -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: iwn firmware instability with an up-to-date stable kernel
On Sat, Apr 24, 2010 at 4:59 AM, Garrett Cooper yanef...@gmail.com wrote: On Fri, Apr 23, 2010 at 9:42 PM, Garrett Cooper yanef...@gmail.com wrote: On Fri, Apr 23, 2010 at 8:05 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: 2010/4/23 Garrett Cooper yanef...@gmail.com: 2010/4/23 Garrett Cooper yanef...@gmail.com: 2010/4/18 Olivier Cochard-Labbé oliv...@cochard.me: 2010/4/18 Bernhard Schmidt bschm...@techwires.net: Are you able to reproduce this on demand? As in type a few commands and the firmware error occurs? No, I'm not able to reproduce on demand this problem. I'm seeing similar issues on occasion with my Lenovo as well: Apr 23 19:25:24 garrcoop-fbsd kernel: firmware error log: Apr 23 19:25:24 garrcoop-fbsd kernel: error type = NMI_INTERRUPT_WDG (0x0004) Apr 23 19:25:24 garrcoop-fbsd kernel: program counter = 0x046C Apr 23 19:25:24 garrcoop-fbsd kernel: source line = 0x00D0 Apr 23 19:25:24 garrcoop-fbsd kernel: error data = 0x00020703 Apr 23 19:25:24 garrcoop-fbsd kernel: branch link = 0x837004C2 Apr 23 19:25:24 garrcoop-fbsd kernel: interrupt link = 0x06DA18B8 Apr 23 19:25:24 garrcoop-fbsd kernel: time = 4287402440 Apr 23 19:25:24 garrcoop-fbsd kernel: driver status: Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 0: qid=0 cur=1 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 1: qid=1 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 2: qid=2 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 3: qid=3 cur=36 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 4: qid=4 cur=123 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 5: qid=5 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 6: qid=6 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 7: qid=7 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 8: qid=8 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 9: qid=9 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 10: qid=10 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 11: qid=11 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 12: qid=12 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 13: qid=13 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 14: qid=14 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: tx ring 15: qid=15 cur=0 queued=0 Apr 23 19:25:24 garrcoop-fbsd kernel: rx ring: cur=8 This may be because the system was under load (I was installing a port shortly before the connection dropped). I'll try poking at this further because it's going to be an annoying productivity loss :/. Sorry... should have included more helpful details. Thanks, -Garrett dmesg: iwn0: Intel(R) PRO/Wireless 4965BGN mem 0xdf2fe000-0xdf2f irq 17 at device 0.0 on pci3 iwn0: MIMO 2T3R, MoW1, address 00:1d:e0:7d:9f:c7 iwn0: [ITHREAD] iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps pciconf -lv snippet: i...@pci0:3:0:0: class=0x028000 card=0x11108086 chip=0x42308086 rev=0x61 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Wireless WiFi Link 4965AGN (Intel 4965AGN)' class = network c...@pci0:21:0:0: class=0x060700 card=0x20c617aa chip=0x04761180 rev=0xba hdr=0x02 uname -a: $ uname -a FreeBSD garrcoop-fbsd.cisco.com 8.0-STABLE FreeBSD 8.0-STABLE #0 r207006: Wed Apr 21 13:18:44 PDT 2010 r...@garrcoop-fbsd.cisco.com:/usr/obj/usr/src/sys/LAPPY_X86 i386 I'm actually looking at this right now. For me, it's actually happening when my machine stays on overnight (or for long periods of time, idle). Also, it seems to be causing the kernel to panic, although I'm now wondering if the Machine Check Architecture is somehow catching this device error and causing an exception (hw.mca.enabled=1)(?) -- not possible, right ??? Whatever the case, I can't seem to get the firmware error to occur with iwn(4) debugging or wlandebug options enabled, so who knows exactly what leads to this. I know Bernhard has worked hard on this driver, it's a shame that this freaky bug has bit us all now, without leaving many clues :( I've attached a textdump for posterity if nothing else :) Connectivity appears to be shoddy in my neck of the woods (kind of ironic... but meh). Just running buildworld, buildkernel, then doing a tcpdump in parallel causes the pseudo device to go up and down a lot. I assume this isn't standard behavior? Just for reference buildworld was started shortly after 19:39:05, and it finished at 21:29. The interface has also gone up and down once since then while the system's been basically idle. Hmmm... I'm seem to be in an excellent position to reproduce
Re: rc(8) script -- waiting for the network to become usable
On Mon, Apr 26, 2010 at 10:02 PM, Jeremy Chadwick
free...@jdc.parodius.com wrote:
On Tue, Apr 27, 2010 at 09:48:41AM +1000, Phil wrote:
Jeremy,
A good proposal to improve start-up robustness. If I may suggest,
waitnetwork_ip should include a short list of alternate IP's in
the event of a local network outage, or DOS, etc. Something like:
waitnetwork_ip=IP1 IP2 IP3
Having multiple target IP's will improve the likelihood of timely
booting when silly/nasty things happen on the wider network.
Good idea to have incorporated into the base system.
Phil,
I brought this point up in my post on -rc and -net, actually. I've
since extended the script to support multiple IPs in $waitnetwork_ip
(wasn't that hard). The logic is that if any of the IPs pass the ping
test, then the network connection is considered usable.
Attached is the modified script. I'll be updating the version on my
server (HTTP) momentarily.
--
| Jeremy Chadwick j...@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
#!/bin/sh
#
# $FreeBSD: $
#
# PROVIDE: waitnetwork
# REQUIRE: NETWORKING
# BEFORE: mountcritremote
# KEYWORD: nojail
# XXX - Once/if committed to base, it's better to have mountcritremote
# XXX - REQUIRE waitnetwork, rather than use the above BEFORE line.
. /etc/rc.subr
name=waitnetwork
rc_var=`set_rcvar`
start_cmd=waitnetwork_start
stop_cmd=:
# XXX - Once/if committed to base, the following defaults should
# XXX - be placed into src/etc/defaults/rc.conf instead of here
# XXX - Also be sure to keep waitnetwork_ip= commented out!
waitnetwork_enable=NO # Wait for network availability before
# continuing with NETWORKING rc scripts
#waitnetwork_ip= # IP address to ping
waitnetwork_count=5 # ping count (see ping(8) -c flag)
waitnetwork_timeout=60 # ping timeout (see ping(8) -t flag)
waitnetwork_start()
{
local ip rc success
success=0
if [ -z ${waitnetwork_ip} ]; then
warn You must define one or more IP addresses in
waitnetwork_ip
return
fi
for ip in ${waitnetwork_ip}; do
echo Waiting for ${ip} to respond to ICMP...
if [ -z ${waitnetwork_timeout} ]; then
/sbin/ping -c ${waitnetwork_count} ${ip} /dev/null
21
rc=$?
else
info Using timeout of ${waitnetwork_timeout} seconds
/sbin/ping -t ${waitnetwork_timeout} -c
${waitnetwork_count} ${ip} /dev/null 21
rc=$?
fi
if [ $rc -eq 0 ]; then
echo Host reachable; network considered available.
return
else
echo No response from host.
fi
done
echo Exhausted IP list. Continuing with startup, but be aware you
may
echo not have a fully functional networking layer at this point.
}
load_rc_config $name
run_rc_command $1
Not to hijack the thread, but this type of clean, quality work (even
though some consider it a hack), really helps a lot of people out.
I wonder, has anyone ever brought up the idea of an rc repository or
something similar, for rc scripts and/or configs that may help many,
but for whatever reason, will not be included in the base system?
I'm thinking of something more official, hosted at the freebsd.org
domain. Maybe in the same vein as:
http://www.sun.com/bigadmin/home/index.jsp
Shields up,
-Brandon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Kernel panic when unpluggin AC adaptor
On Mon, May 3, 2010 at 4:57 PM, David DEMELIER demelier.da...@gmail.com wrote:
2010/5/3 David DEMELIER demelier.da...@gmail.com:
Hi,
I just updated my 8.0-STABLE/amd64 today around 17h CEST, and it just
panics when I unplug my AC. The current process = 11 (idle: cpu1) is
this related to the cpufreq and related stuff ?
It also says cannot dump. Device not defined or unavailable so I can't
give you more infos now.
I can confirm that :
#performance_cx_lowest=HIGH
#performance_cpu_freq=${performance_cx_lowest}
#economy_cx_lowest=LOW
#economy_cpu_freq=${economy_cx_lowest}
in rc.conf was the problem.
Can you get a backtrace? I've been experiencing something strange
lately after applying optimization settings from:
http://wiki.freebsd.org/TuningPowerConsumption
I can't get a useful dump either, the machine is idle, and the
backtrace is strange to me:
db show allpcpu
Current CPU: 0
cpuid= 0
dynamic pcpu= 0x692d00
curthread= 0xff0001507390: pid 11 idle: cpu0
curpcb = 0xff839d40
fpcurthread = none
idlethread = 0xff0001507390: pid 11 idle: cpu0
curpmap = 0
tssp= 0x80840580
commontssp = 0x80840580
rsp0= 0xff839d40
gs32p = 0x8083f3b8
ldt = 0x8083f3f8
tss = 0x8083f3e8
cpuid= 1
dynamic pcpu= 0xff807f85ed00
curthread= 0xff0001507720: pid 11 idle: cpu1
curpcb = 0xff834d40
fpcurthread = none
idlethread = 0xff0001507720: pid 11 idle: cpu1
curpmap = 0
tssp= 0x808405e8
commontssp = 0x808405e8
rsp0= 0xff834d40
gs32p = 0x8083f420
ldt = 0x8083f460
tss = 0x8083f450
db bt
Tracing pid 11 tid 14 td 0xff0001507390
rman_get_bushandle() at rman_get_bushandle+0x1
sched_idletd() at sched_idletd+0x123
fork_exit() at fork_exit+0x118
fork_trampoline() at fork_trampoline+0xe
--- trap 0, rip = 0, rsp = 0xff839d30, rbp = 0 ---
-Brandon
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Kernel panic when unpluggin AC adaptor
On Wed, May 12, 2010 at 9:41 AM, Attilio Rao atti...@freebsd.org wrote: 2010/5/12 David DEMELIER demelier.da...@gmail.com: I remove the patch, and built the kernel (I updated the src this morning) and it does not panic now. It's really odd. If it reappears soon I will tell you. I looked at the code with Giovanni and I have the feeling that the race with the idle thread may still be fatal. We need to fix that. Attilio That seems to be the case, as my laptop shows about an 80-85 % chance of experiencing a panic if left idle for long-ish periods of time (2 to 4 hours). I usually rebuild world or big ports overnight, and more often than not I wake up to a panicked machine, same situation every time: ... rman_get_bushandle() at rman_get_bushandle+0x1 sched_idletd() at sched_idletd+0x123 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe ... The kernel/userland is rebuilt, the ports are finished compiling -- it's in the time AFTER the completion of all tasks that the machine gets bored and tries to kill itself :) I have seen the AC adapter plug/unplug hang in the past on this laptop, but I never made the connection between the events, as nowadays my laptop usually stays plugged in :( Attilio, I hope you can track this one down, let me know if I can do anything to help or test... -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Kernel panic when unpluggin AC adaptor
On Thu, May 13, 2010 at 7:25 PM, Giovanni Trematerra giovanni.tremate...@gmail.com wrote: On Thu, May 13, 2010 at 1:09 AM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Wed, May 12, 2010 at 9:41 AM, Attilio Rao atti...@freebsd.org wrote: 2010/5/12 David DEMELIER demelier.da...@gmail.com: I remove the patch, and built the kernel (I updated the src this morning) and it does not panic now. It's really odd. If it reappears soon I will tell you. I looked at the code with Giovanni and I have the feeling that the race with the idle thread may still be fatal. We need to fix that. Attilio That seems to be the case, as my laptop shows about an 80-85 % chance of experiencing a panic if left idle for long-ish periods of time (2 to 4 hours). I usually rebuild world or big ports overnight, and more often than not I wake up to a panicked machine, same situation every time: ... rman_get_bushandle() at rman_get_bushandle+0x1 sched_idletd() at sched_idletd+0x123 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe ... The kernel/userland is rebuilt, the ports are finished compiling -- it's in the time AFTER the completion of all tasks that the machine gets bored and tries to kill itself :) I have seen the AC adapter plug/unplug hang in the past on this laptop, but I never made the connection between the events, as nowadays my laptop usually stays plugged in :( Attilio, I hope you can track this one down, let me know if I can do anything to help or test... Attilio and I came up with this patch. It seems ready for stress testing and review Please test and report back. Thank you P.S: all the faults are only mine. I tried the patch, and my kernel panics I panic on boot. I have 8.5MB(!) of JPG images (6 of them) if anyone needs to see them. I'm looking for a place to post them, but if anyone wants, I can send via e-mail... -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Kernel panic when unpluggin AC adaptor
On Tue, May 18, 2010 at 9:04 AM, Giovanni Trematerra giovanni.tremate...@gmail.com wrote: On Sat, May 15, 2010 at 9:12 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Thu, May 13, 2010 at 7:25 PM, Giovanni Trematerra giovanni.tremate...@gmail.com wrote: On Thu, May 13, 2010 at 1:09 AM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Wed, May 12, 2010 at 9:41 AM, Attilio Rao atti...@freebsd.org wrote: 2010/5/12 David DEMELIER demelier.da...@gmail.com: I remove the patch, and built the kernel (I updated the src this morning) and it does not panic now. It's really odd. If it reappears soon I will tell you. I looked at the code with Giovanni and I have the feeling that the race with the idle thread may still be fatal. We need to fix that. Attilio That seems to be the case, as my laptop shows about an 80-85 % chance of experiencing a panic if left idle for long-ish periods of time (2 to 4 hours). I usually rebuild world or big ports overnight, and more often than not I wake up to a panicked machine, same situation every time: ... rman_get_bushandle() at rman_get_bushandle+0x1 sched_idletd() at sched_idletd+0x123 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe ... The kernel/userland is rebuilt, the ports are finished compiling -- it's in the time AFTER the completion of all tasks that the machine gets bored and tries to kill itself :) I have seen the AC adapter plug/unplug hang in the past on this laptop, but I never made the connection between the events, as nowadays my laptop usually stays plugged in :( Attilio, I hope you can track this one down, let me know if I can do anything to help or test... Attilio and I came up with this patch. It seems ready for stress testing and review Please test and report back. Thank you P.S: all the faults are only mine. I tried the patch, and my kernel panics I panic on boot. I have 8.5MB(!) of JPG images (6 of them) if anyone needs to see them. I'm looking for a place to post them, but if anyone wants, I can send via e-mail... Hi Brandon, Could you please, try this new one? The panic at boot stage should be solved, at least I tried on a 8-way machine and all went ok at boot. Please, remove WITNESS_SKIPSPIN from your kernel config file. This patch might be sub-optimal and contains style(9) error but if it works we are on the right way. Let me know if it works for you. Applied the patch, built, installed, and booted new kernel: no panic! I will remove WITNESS_SKIPSPIN and build another kernel. Then I'll try to trigger the panic (by letting my laptop sit idle after a buildworld session). Thanks for giving this some attention, I hope you and/or others are able to get to the bottom of this... -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Kernel panic when unpluggin AC adaptor
On Tue, May 18, 2010 at 10:47 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Tue, May 18, 2010 at 9:04 AM, Giovanni Trematerra giovanni.tremate...@gmail.com wrote: On Sat, May 15, 2010 at 9:12 PM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Thu, May 13, 2010 at 7:25 PM, Giovanni Trematerra giovanni.tremate...@gmail.com wrote: On Thu, May 13, 2010 at 1:09 AM, Brandon Gooch jamesbrandongo...@gmail.com wrote: On Wed, May 12, 2010 at 9:41 AM, Attilio Rao atti...@freebsd.org wrote: 2010/5/12 David DEMELIER demelier.da...@gmail.com: I remove the patch, and built the kernel (I updated the src this morning) and it does not panic now. It's really odd. If it reappears soon I will tell you. I looked at the code with Giovanni and I have the feeling that the race with the idle thread may still be fatal. We need to fix that. Attilio That seems to be the case, as my laptop shows about an 80-85 % chance of experiencing a panic if left idle for long-ish periods of time (2 to 4 hours). I usually rebuild world or big ports overnight, and more often than not I wake up to a panicked machine, same situation every time: ... rman_get_bushandle() at rman_get_bushandle+0x1 sched_idletd() at sched_idletd+0x123 fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe ... The kernel/userland is rebuilt, the ports are finished compiling -- it's in the time AFTER the completion of all tasks that the machine gets bored and tries to kill itself :) I have seen the AC adapter plug/unplug hang in the past on this laptop, but I never made the connection between the events, as nowadays my laptop usually stays plugged in :( Attilio, I hope you can track this one down, let me know if I can do anything to help or test... Attilio and I came up with this patch. It seems ready for stress testing and review Please test and report back. Thank you P.S: all the faults are only mine. I tried the patch, and my kernel panics I panic on boot. I have 8.5MB(!) of JPG images (6 of them) if anyone needs to see them. I'm looking for a place to post them, but if anyone wants, I can send via e-mail... Hi Brandon, Could you please, try this new one? The panic at boot stage should be solved, at least I tried on a 8-way machine and all went ok at boot. Please, remove WITNESS_SKIPSPIN from your kernel config file. This patch might be sub-optimal and contains style(9) error but if it works we are on the right way. Let me know if it works for you. Applied the patch, built, installed, and booted new kernel: no panic! I will remove WITNESS_SKIPSPIN and build another kernel. Then I'll try to trigger the panic (by letting my laptop sit idle after a buildworld session). Thanks for giving this some attention, I hope you and/or others are able to get to the bottom of this... Hey everyone, just reporting in: The laptop has experienced the longest uptime it's seen in a while -- so far, so good! I'll keep the machine up and running just in case... -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Kernel panic when unpluggin AC adaptor
On Sat, Jun 12, 2010 at 12:19 PM, David DEMELIER demelier.da...@gmail.com wrote: 2010/6/11 John Baldwin j...@freebsd.org: On Friday 11 June 2010 6:27:48 am Giovanni Trematerra wrote: On Thu, Jun 10, 2010 at 10:58 PM, Giovanni Trematerra giovanni.tremate...@gmail.com wrote: On Tue, May 4, 2010 at 6:35 PM, David DEMELIER demelier.da...@gmail.com wrote: Good news ! It worked, check the picture here : http://img63.imageshack.us/img63/4244/dsc00361g.jpg Into the file sys/dev/acpica/acpi_cpu.c at the end of acpi_cpu_notify (a per cpu notification handler), called when _CST objects changing, global cpu_cx_count is set to the greatest value of all sc-cpu_cx_count per-cpu variables. That could result in a panic as David reported, because that lets to invoke acpi_cpu_global_cx_lowest_sysctl from /etc/rc.d/power_profile, when AC adapter is unplugged, with a value that not all the CPUs could handle in the acpi_cpu_idle. The patch also change global cpu_cx_lowest according to new value of global cpu_cx_count if needed. David Demelier made a great work to test every patch I sent him to identify the source of the problem. Please, let me know your comments and possibly commit the patch if you think is good enough. As jhb@ pointed me out in private with the previous patch a CPU could never enter in the lowest Cx-state even if it gained. So I'd like to propose this new solution. When hw.acpi.cpu.cx_lowest sysctl is set, the global handler in sys/dev/acpi_cpu.c will set the greatest sc-cpu_cx_lowest value supported by the CPU and not the same value for all CPUs. Later, when CPU, possibly gain new Cx-states, the acpi_cpu_notify handler will set sc-cpu_cx_lowest accordingly with global cx_lowest and the Cx-states supported by the CPU. Now I think that /etc/rc.d/power_profile script has a problem but that is a different story. The script select the lowest_value only querying cx-states of the dev.cpu.0. If different CPUs may have different Cx-states, the script should use as lowest_value the lowest value between all the CPUs. Yes. Please, let me know your comments and possibly commit the patch if you think is good enough. I think this is a good compromise for now. -- John Baldwin Thanks for Giovanni's patience and work, he made a lot of research to solve this little problem :-). Is there a chance that this patch appears in 8.1-RELEASE ? Kind regards. -- Demelier David Someone would have to discuss with the Release Engineering team, but it would be cool :) -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850
On Tue, Jun 1, 2010 at 2:37 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Tue, Jun 01, 2010 at 03:18:39PM -0400, Brian A. Seklecki wrote: = Re-posted from freebsd-hardware@, since this is more of a bug report than a hardware comparability inquiry / buying strategy discussion. == All: Has anyone upgraded their PowerEdge 1850s to 8.0-PL or RELENG_8 -stable? We're seeing problems where 7.2-PL and 6.3-PL were not affected on the same hardware. The problem is that forcing the duplex 100/full on both sides no longer functions. Configuration: - A variety of Cisco L2/L3 switches over the last decade: -- 2848G-L3 -- 2950 -- 2960s -- 3550-12Ts -- 3550XLs -- Duplex forced 100/full on Cisco side - FreeBSD/amd64 RELENG_8 or 9-CURRENT with duplex forced '100baseTX mediaopt full-duplex', - This configuration has worked since FreeBSD 5.4 When connected to PowerEdge 1850r1/r2, with the onboard Intel 82541EI, the parenthesis show an actual media speed/duplex of: media: Ethernet 100baseTX full-duplex (100baseTX half-duplex) The same configuration using a Dell-sold Intel dual port 82546EB, in the same system, on the same switch, works fine. - ifconfig(8): - em3: flags=8843UP,BROADCAST,RUNNING,SIMPLEX, \r MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:13:72:4f:70:81 inet 192.168.97.20 netmask 0xff80 broadcast 192.168.97.127 media: Ethernet 100baseTX full-duplex (100baseTX half-duplex) status: active - em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,\ MULTICAST metric 0 mtu 1500 options=9bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM ether 00:04:23:c8:fe:ac media: Ethernet 100baseTX full-duplex status: active - - pciconf(8): - e...@pci0:7:8:0: class=0x02 card=0x016d1028 chip=0x10768086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (82541EI)' class = network subclass = ethernet e...@pci0:3:11:0: class=0x02 card=0x10128086 chip=0x10108086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (Copper) (82546EB)' class = network subclass = ethernet - rc.conf(5) for shits giggles: ifconfig_em0=inet X netmask Y media 100baseTX mediaopt full-duplex ifconfig_em3=inet Z netmask F media 100baseTX mediaopt full-duplex Example IOS switch config: interface FastEthernet0/39 description I hate Dell switchport access vlan 100 switchport mode access speed 100 duplex full spanning-tree portfast end I've been clearing interface counters on the switch side, but I'll send 'netstat -i', 'show interface counters', and 'sudo sysctl -w dev.em.3.stats=1' ASAP to illustrate connectivity errors soon. Are we being punished for patronizing Dell? Is it possible that ifconfig(8) output has simply changed? Are the values in the parenthesis on the right the Ethernet auto-sense desired values where as outside the parenthesis the current active values? In 6.3/7.2, once you forced a speed/duplex, the values in parenthesis went away entirely. The only way I've been able to make that happen is to #define in src/sys/dev/e1000/if_em.h: #define DO_AUTO_NEG 0 /* * This parameter control whether or not the driver will wait for * autonegotiation to complete. * 1 - Wait for autonegotiation to complete * 0 - Don't wait for autonegotiation to complete */ Also seems odd that some ICs are affected but not others. Its also possible that my problems are pf(4) + setfib(8) related and I that this is a separate issue. Two new notes since the original post: - I have confirmed this problem on two revisions of the Dell 8th gen hardware in two different datacenters - The problem persists on -CURRENT from 05/2010 - RELENG_7 does not seem to be impacted - More stats below. Thanks, ~BAS --- em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em1: link state changed to UP em1: link state changed to DOWN em0: Excessive collisions = 0 em0: Sequence errors = 0 em0: Defer count = 0 em0: Missed Packets = 0 em0: Receive No Buffers = 0 em0: Receive Length Errors = 0 em0: Receive errors = 0 em0: Crc errors = 0 em0: Alignment errors = 0 em0: Collision/Carrier extension errors = 0 em0: RX overruns = 0 em0: watchdog timeouts = 0 em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0 em0: XON Rcvd = 0 em0: XON
Re: 8.1 speed issues
On Fri, Jun 18, 2010 at 4:48 PM, William D. Colburn (Schlake) schl...@gmail.com wrote: So I've just upgraded from whatever was stable in 2004 to 8.1 (it's a private file server in my house, I pay no attention to it until it crashes), and uh, the speed difference is very noticeable. In short, it's like I bought a brand new machine that eleven times as fast when all I did was upgrade the OS. How on earth did you guys make such a dramatic improvement? BSD = Blazing Speed, Dude! Oh, and it's Free. Seriously though, if you're curious, the source code commit logs are always enlightening ;) -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: if_em problems, both 7 and 8-stable
On Sat, Jun 19, 2010 at 5:28 PM, Pete Carah p...@altadena.net wrote: I cannot successfully create a vlan on if_em on either releng 7 or releng 8; I have seen a patch for part of the problem (checksum offsets end up incorrect) but not all. Even turning off ALL hw_xxx flags leaves one unacceptable bug - the interface gets hard-reset any time you add or delete a vlan. I *know* that cisco uses these interfaces without these problems, so it has to be possible. I have used vlans in linux without appearing to get the same problems, though I'm not sure the rest of the configuration matches. What gives, especially since the patch for one of the problems (wrong checksum offsets) was generated about 6 months ago... We are trying to use an intel platform as a router; this is a show-stopper. I could try linux though I prefer not to... Would it be possible for you to provide more details about the hardware and software setup? The Intel chip and the revision (or relevant CVS info) about the builds of 7-RELENG and 8-RELENG would be useful, perhaps the dmesg of the machine and output of `pciconf -lv`? For what it's worth, I'm using vlans on an Intel 82566DM Gigabit Ethernet Adapter (82566DM), on-board in my Dell Optiplex 755, all hardware options on... $ ifconfig em0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC ether 00:1e:4f:d5:84:b7 inet 10.7.0.7 netmask 0xff00 broadcast 10.255.255.255 media: Ethernet autoselect (1000baseT full-duplex) status: active -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: zfs send/receive: is this slow?
On Fri, Oct 1, 2010 at 8:43 PM, Artem Belevich fbsdl...@src.cx wrote: As soon as I opened this email I knew what it would say. # time zfs send storage/bac...@transfer | mbuffer | zfs receive storage/compressed/bacula-mbuffer in @ 197 MB/s, out @ 205 MB/s, 1749 MB total, buffer 0% full ... Big difference. :) I'm glad it helped. Does anyone know why sending/receiving stuff via loopback is so much slower compared to pipe? This may shed some light on that topic: http://lists.freebsd.org/pipermail/freebsd-current/2010-September/019877.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: New event timers for 8-STABLE
2010/11/11 Alexander Motin m...@freebsd.org: Hi. I've created a patch, merging all kernel event timers related stuff from HEAD to 8-STABLE. The only thing I have skipped at this moment was mips architecture, because of too big code difference there between HEAD and 8-STABLE. Patch appeared to be quite large and includes more then 60 SVN revisions from HEAD. I hope I haven't missed anything important. I would like to ask interested people to test it. Patched code successfully builds on all platforms and successfully runs on my amd64 test machine. In HEAD code seems to be working enough stable, There only two known open issues at the moment: - kernel freeze on XEN HVM when using LAPIC timer in one-shot mode -- can be workarounded by switching to periodic mode or other timer. - if HPET interrupt shared with other device, system load average may lie (report +1 value) -- not a timer problem and not fatal. Please report me if you find anything else. Latest patch can be found here: http://people.freebsd.org/~mav/timers_merge/timers_merge-2010.patch Merge instructions (list of revisions, if somebody want to redo it): http://people.freebsd.org/~mav/timers_merge/guide-2010 After patching you need just rebuild/reinstall the kernel. I haven't merged related manual pages yet, so, if needed, consult with man pages from HEAD: eventtimers(7), attimer(4), atrtc(4), hpet(4). Reporting successes! No noticeable anomalies yet, two 8-STABLE systems (behaving similarly to my 9-CURRENT system in regard to timer settings). I'll keep prodding away to see what I can break ;) Of course I'll report the pertinent bits if/when required... Good job Alexander! -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: New event timers for 8-STABLE [SEC=UNCLASSIFIED]
On Thu, Nov 11, 2010 at 9:30 PM, Wilkinson, Alex alex.wilkin...@dsto.defence.gov.au wrote: 0n Fri, Nov 12, 2010 at 02:40:28AM +0200, Alexander Motin wrote: I've created a patch, merging all kernel event timers related stuff from HEAD to 8-STABLE. The only thing I have skipped at this moment was mips architecture, because of too big code difference there between HEAD and 8-STABLE. Patch appeared to be quite large and includes more then 60 SVN revisions from HEAD. I hope I haven't missed anything important. I would like to ask interested people to test it. Patched code successfully builds on all platforms and successfully runs on my amd64 test machine. In HEAD code seems to be working enough stable, There only two known open issues at the moment: - kernel freeze on XEN HVM when using LAPIC timer in one-shot mode -- can be workarounded by switching to periodic mode or other timer. - if HPET interrupt shared with other device, system load average may lie (report +1 value) -- not a timer problem and not fatal. Please report me if you find anything else. Latest patch can be found here: http://people.freebsd.org/~mav/timers_merge/timers_merge-2010.patch Merge instructions (list of revisions, if somebody want to redo it): http://people.freebsd.org/~mav/timers_merge/guide-2010 After patching you need just rebuild/reinstall the kernel. I haven't merged related manual pages yet, so, if needed, consult with man pages from HEAD: eventtimers(7), attimer(4), atrtc(4), hpet(4). patches apply cleanly but buildkernel fails: make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -march=nocona -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/dev/ath -I/usr/src/sys/dev/ath/ath_hal -I/usr/src/sys/contrib/ngatm -I/usr/src/sys/dev/twa -I/usr/src/sys/gnu/fs/xfs/FreeBSD -I/usr/src/sys/gnu/fs/xfs/FreeBSD/support -I/usr/src/sys/gnu/fs/xfs -I/usr/src/sys/contrib/opensolaris/compat -I/usr/src/sys/dev/cxgb -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 -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 cc: /usr/src/sys/kern/kern_et.c: No such file or directory cc: /usr/src/sys/kern/kern_clocksource.c: No such file or directory /usr/src/sys/dev/acpica/acpi_hpet.c:46:24: error: sys/timeet.h: No such file or directory /usr/src/sys/x86/x86/local_apic.c:52:24: error: sys/timeet.h: No such file or directory /usr/src/sys/x86/isa/atrtc.c:45:24: error: sys/timeet.h: No such file or directory /usr/src/sys/x86/isa/clock.c:60:24: error: sys/timeet.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/obj/usr/src/sys/MARGS. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Revert the patch (patch -R) and reapply the patch with -p0: [/usr/src]# patch -p0 /path/to/file.patch ...and try it again :) -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sense fetching [Was: cdrtools /devel ...]
2010/11/5 Alexander Motin m...@freebsd.org: Hi. I've reviewed tests that scgcheck does to SCSI subsystem. It shown combination of several issues in both CAM, ahci(4) and cdrtools itself. Several small patches allow us to pass most of that tests: http://people.freebsd.org/~mav/sense/ ahci_resid.patch: Add support for reporting residual length on data underrun. SCSI commands often returns results shorter then expected. Returned value allows application to know/check how much data it really has. It is also important for sense fetching, as ATAPI and USB devices return sense as data in response to REQUEST_SENSE command. sense_resid.patch: When manually requesting sense data (ATAPI or USB), request only as much data as user requested (not the fixed structure size), and return respective sense residual length. pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon as device freeze released before returning to user-level, user-level application by definition can't reliably fetch sense data if some other application (like hald) tries to access device same time. cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit wanted sense length to CAM and do not clear sense return buffer. It is mostly cosmetics, important probably only for scgcheck. Testers and reviewers welcome. I am especially interested in opinion about pass_autosence.patch -- may be we should lower sense fetching even deeper, to make it work for all cam_periph_runccb() consumers. Hey mav, sorry to chime in after so long here, but have some of these patches been committed (as of r215179)? Which patches are still applicable for testing? I assume the cdrtools patch for sure... -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sense fetching [Was: cdrtools /devel ...]
On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin m...@freebsd.org wrote: Brandon Gooch wrote: 2010/11/5 Alexander Motin m...@freebsd.org: Hi. I've reviewed tests that scgcheck does to SCSI subsystem. It shown combination of several issues in both CAM, ahci(4) and cdrtools itself. Several small patches allow us to pass most of that tests: http://people.freebsd.org/~mav/sense/ ahci_resid.patch: Add support for reporting residual length on data underrun. SCSI commands often returns results shorter then expected. Returned value allows application to know/check how much data it really has. It is also important for sense fetching, as ATAPI and USB devices return sense as data in response to REQUEST_SENSE command. sense_resid.patch: When manually requesting sense data (ATAPI or USB), request only as much data as user requested (not the fixed structure size), and return respective sense residual length. pass_autosence.patch: Unless CAM_DIS_AUTOSENSE is set, always fetch sense if not done by SIM, independently of CAM_PASS_ERR_RECOVER. As soon as device freeze released before returning to user-level, user-level application by definition can't reliably fetch sense data if some other application (like hald) tries to access device same time. cdrtools.patch: Make libscg (part of cdrtools) on FreeBSD to submit wanted sense length to CAM and do not clear sense return buffer. It is mostly cosmetics, important probably only for scgcheck. Testers and reviewers welcome. I am especially interested in opinion about pass_autosence.patch -- may be we should lower sense fetching even deeper, to make it work for all cam_periph_runccb() consumers. Hey mav, sorry to chime in after so long here, but have some of these patches been committed (as of r215179)? Which patches are still applicable for testing? I assume the cdrtools patch for sure... Now uncommitted pass_autosence.patch and possibly cdrtools.patch. OK. Patched kernel and cdrtools has resulted in a working cdrecord (burned an ISO successfully) and an endless stream of: ... (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error ... ad infinitum until I start cdrecord: (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): Requesting SCSI sense data (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit not ready, long write in progress) (cd0:ata0:0:0:0): Error 16, Unretryable error (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): Requesting SCSI sense data (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit not ready, long write in progress) (cd0:ata0:0:0:0): Error 16, Unretryable error (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): Requesting SCSI sense data (cd0:ata0:0:0:0): SCSI status error (cd0:ata0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (cd0:ata0:0:0:0): CAM status: SCSI Status Error (cd0:ata0:0:0:0): SCSI status: Check Condition (cd0:ata0:0:0:0): SCSI sense: NOT READY asc:4,8 (Logical unit not ready, long write in progress) (cd0:ata0:0:0:0): Error 16, Unretryable error (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data cdrecord output: bran...@x300:~$ sudo cdrecord dev=0,0,0 Fedora-14-i686-Live-Desktop.iso (11-13 11:41) cdrecord: No write mode specified. cdrecord: Assuming -sao mode. cdrecord: If your drive does not accept -sao, try -tao. cdrecord: Future versions of cdrecord may have different drive dependent defaults. Cdrecord-ProDVD-ProBD-Clone 3.00 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Jörg Schilling scsidev: '0,0,0' scsibus: 0 target: 0 lun: 0 Using libscg version 'schily-0.9'. Device type: Removable CD-ROM Version: 0 Response Format: 2 Capabilities : Vendor_info: 'MATSHITA' Identifikation : 'DVD-RAM UJ-844 ' Revision : 'RC02' Device seems to be: Generic mmc2 DVD-R/DVD-RW/DVD-RAM. Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO cdrecord: Warning: Cannot read drive buffer. cdrecord: Warning: The DMA speed test has been skipped. Starting to write CD/DVD/BD at speed 16 in real SAO mode for single session. Last chance to quit, starting real write0 seconds. Operation starts. Turning BURN-Free off cdrecord: WARNING: Drive
Re: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE
On Wed, Dec 1, 2010 at 4:30 PM, Zhihao Yuan lich...@gmail.com wrote: OK. Let's make this more clear: anyone has a working 8-2-PRERELEASE kernel (amd64 is preferred) with Dtrace supports, which can run the scripts/commands on the wiki? If so, please post your kernel configurations here, thanks. I have an i386 system working: FreeBSD d820.flick.local 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #2 r216091: Wed Dec 1 18:06:20 CST 2010 r...@d820.flick.local:/usr/obj/usr/src/sys/D820 i386 Just built the kernel and ran through some tests on the DTrace wiki page. Incidentally, I had a tough time on my system running HEAD built with clang. DTrace simply would not run properly until I built the kernel with the base gcc. It was as if the kernel and userland were not in sync, no matter what I tried (even netstat didn't work). Maybe you need to clean EVERYTHING, checkout a clean source tree (if you've been mucking around in there), and rebuild and install kernel and world. I wish I could help more, but I'm still just a newb in a lot of respects... -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE
On Wed, Dec 1, 2010 at 6:27 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: On Wed, Dec 01, 2010 at 06:22:40PM -0600, Brandon Gooch wrote: On Wed, Dec 1, 2010 at 4:30 PM, Zhihao Yuan lich...@gmail.com wrote: OK. Let's make this more clear: anyone has a working 8-2-PRERELEASE kernel (amd64 is preferred) with Dtrace supports, which can run the scripts/commands on the wiki? If so, please post your kernel configurations here, thanks. I have an i386 system working: [snip] Can you please try the command the OP originally provided? See command here: http://lists.freebsd.org/pipermail/freebsd-stable/2010-November/060216.html d820# dtrace -lP syscall | head ID PROVIDERMODULE FUNCTION NAME 17syscall syscall entry 18syscall syscall return 19syscallexit entry 20syscallexit return 21syscallfork entry 22syscallfork return 23syscallread entry 24syscallread return 25syscall write entry The error the OP received from the above command was pretty much exactly what I was seeing when I attempting to use DTrace on my HEAD system, built with clang. Same error, at least this part: /usr/lib/dtrace/psinfo.d, line 88: failed to resolve type kernel`struct thread * for identifier curthread: Unknown type name I was running simply 'dtrace -l' to list all probes... -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE
On Wed, Dec 1, 2010 at 7:37 PM, Zhihao Yuan lich...@gmail.com wrote: I guess such an error has nothing to do with the difference between compilers... I assumed that you used similar KERNCONF on your two systems. So, a hypothesis is: Dtrace does not work correctly on amd64. I should have mentioned that I do have DTrace sort of working on my HEAD system (amd64), just strange terminal behavior now (CTRL-C doesn't allow a running script to produce any output -- pkill dtrace works however...). I just found this, which seems to indicate that you may be on to something: http://forums.freebsd.org/showthread.php?t=19028 What does your kernel config look like? How about /etc/make.conf and /etc/src.conf? Maybe looking at the contents of these files will shed some light... -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.2-BETA1 sysinstall: No USB devices found
On Sun, Dec 12, 2010 at 9:17 AM, Bruce Cran br...@cran.org.uk wrote: On Sun, 12 Dec 2010 09:38:59 -0500 Kim Culhan w8hd...@gmail.com wrote: No USB devices found! Can you try re-scanning for devices (via the Options screen) - sysinstall can fail to detect USB disks the first time around. -- Bruce Cran How difficult would it be for the installer to automatically re-scan for devices when USB is selected as install or Fix-it media? -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sense fetching [Was: cdrtools /devel ...]
On Sun, Nov 14, 2010 at 9:32 AM, Alexander Motin m...@freebsd.org wrote: Brandon Gooch wrote: On Sat, Nov 13, 2010 at 3:34 AM, Alexander Motin m...@freebsd.org wrote: Now uncommitted pass_autosence.patch and possibly cdrtools.patch. OK. Patched kernel and cdrtools has resulted in a working cdrecord (burned an ISO successfully) and an endless stream of: ... (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error (pass0:ata0:0:0:0): Requesting SCSI sense data (pass0:ata0:0:0:0): SCSI status error ... I think it can be hald probing for media insertion. Probably we should slightly reduce error logging verbosity. May be somehow make to not log errors on requests submitted from user-level via pass driver. But most important part: It works, and it burned very quickly! The CD was created, and fully functional (I booted the Fedora image and completed an installation). Nice! What are your thoughts on committing this (or something like it)? Should I just keep a local patch set for the semi-long-term? Do you have something else in the works? -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em0 with latest driver hangs again and again (without Watchdog timeout message!)
On Thu, Mar 3, 2011 at 2:10 AM, Lev Serebryakov l...@serebryakov.spb.ru wrote: Hello, Arnaud. You wrote 2 марта 2011 г., 9:55:50: I have been running with 7.2.2 and so far so good. However, its hard to say in my case as the box I would only periodically see the issue. As I wrote to Jack, my NIC hangs today with 7.2.2 Do you have any detailed error ? What the output of sysctl dev.em.X where X is the index of the hung interface ? One more hang. Two logs are attached. -- // Black Lion AKA Lev Serebryakov l...@serebryakov.spb.ru I see that you have CRC errors: dev.em.0.mac_stats.crc_errs: 156 and receive errors: dev.em.0.mac_stats.recv_errs: 147 You probably have a hardware problem. Is this the only machine on which you're experiencing the problem? -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ath(4) panic + stuck beacon issue
On Fri, Mar 4, 2011 at 9:46 AM, Craig Whipp crwh...@gmail.com wrote: On Sun, 27 Feb 2011 08:01:46 -0800 Jeremy Chadwick free...@jdc.parodius.com wrote If a workaround or solution isn't plausible, what cards do people actually recommend that work reliably / have reliable drivers? I was under the impression Atheros cards were reliable/decent compared to, say, Broadcom. Is iwn(4) reliable? -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP 4BD6C0CB | I've had nothing but success with iwn(4) and an Intel 5100 based card. -Craig +1 for iwn(4) for general use (as that has been my use). Also, the maintainer of iwn(4), bschmidt@, is knowledgeable and responsive to issues as well... -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em0 with latest driver hangs again and again (without Watchdogtimeout message!)
On Sun, Mar 6, 2011 at 1:48 PM, Jack Vogel jfvo...@gmail.com wrote: Missed packets just mean that some temporary resource shortage or error caused the packet to be dropped. I don't believe this is indicative of a problem, just let it keep running, 2 days is good but 2 weeks is better :) Thanks for testing it! Jack Jack, I found several production machines I can test 7.2.2 on, if you'd be so kind to provide me with a link or an attachment :) I don't know exactly what chips they are, but I figure that testing is still testing... -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Sense fetching [Was: cdrtools /devel ...]
On Tue, Mar 8, 2011 at 8:29 AM, Jakub Lach jakub_l...@mailplus.pl wrote: Hello. Just ensuring that this issue would not be forgotten, If I recall correctly, without added patches one cannot burn CD with cdrtools, quite a problem for media burning suite ;) best regards, - Jakub Lach mav@ is working on graid(4), a replacement for ataraid(4) using the GEOM framework. This effort has taken precedence over a few outstanding patches he was working on, but he will eventually come back to it :) Perhaps another developer will step up and continue the work on the patches: http://people.freebsd.org/~mav/sense/ -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: panic, but /var/crash ist empty
On Wed, Apr 27, 2011 at 1:44 PM, Helmut Schneider jumpe...@gmx.de wrote: Hi, running 8.2-RELEASE-p1 within VMWare ESXi 4.1-u1 I want to use raw devices as hard disks. I create the devices using this link: http://www.mattiasholm.com/node/33 I tried 3 different hard drives (Seagate 2x80GB and 1x400GB SATA2) which are fine on a physical machine. I also ran Seatool many hours on all of them without errors. I can partiton the disks and create a few files/directories on it. But as soon as I copy a larger number of files to those disks (tried with MBR and GPT) the VM reboots *instantly* (I tried cp, dump/restore and rsync). No Rebooting within 15 seconds, just *snap*. I think I can see an panic but I'm not sure, it's too fast. (as far as I can see most of the times the data on the first UFS slice (and only the first UFS slice!) of the partition gets *severly* corrupted, most of the time all that is left are a few files within lost+found. Sometimes all the labels are gone but are recoverable using bsdlabel -R) The problem is that /var/crash remains empty. What can I do to create a backtrace to open a PR? Thanks, Helmut Hi Helmut, To get a backtrace from the crash (or drop to the debugger), you'll need to compile a kernel with at least a couple of options defined. These two: options KDB options DDB ...will allow you to work with the debugger on the console after a crash. Further, with the option KDB_TRACE in the kernel config, you'll get a backtrace printed automatically when the kernel panicsb. Here are a couple of excellent documents to read to get you started: http://www.freebsd.org/doc/en/books/handbook/kernelconfig-building.html http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html Kernel debug options: http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-options.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: powerd and increase in energy need
On Tue, Mar 20, 2012 at 3:41 PM, Matthias Gamsjager mgamsja...@gmail.com wrote: Hi, my zfs nas has an Asus p5e motherboard (x38 chip) and an intel q9300 (quad core 2,5Ghz) processor with all the energy save setting enabled in the bios. Today I connected the power cord to a voltcraft energy meter to see how much energy the whole system needs in idle mode. I found out that with powerd running the cpu get clocked down to 499 mhz with is nice. The funny thing is that this doesn't decrease the amount of watts the machine need. 2,5ghz or 499mhz doen't matter at all. It gets even funnier. With powerd running the systems actually needs 4 watts more then without powerd running. Isn't the whole point of powerd to to decease the energy needs of a machine? or is it utterly broken with this cpu generation? You probably want to check out the following article on the FreeBSD wiki: http://wiki.freebsd.org/TuningPowerConsumption The low-power states should be available to you after following the configuration guide. -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: sh(1) exiting on SIGWINCH
On Wed, Jul 4, 2012 at 5:08 PM, Peter Jeremy pe...@rulingia.com wrote: On 2012-Jul-04 20:03:32 +1000, Peter Jeremy pe...@server.rulingia.com wrote: I've recently updated a box from 8-stable to 9-stable/amd64 (r237995), compiled with gcc, and now sh(1) exits if I change the window size (ssh'ing to the target system within an xterm). I don't recall ever seeing this sort of behaviour before and am still trying to track down the relevant code path. Someone pointed me at kern/169603 and I can confirm that reverting r237738 (MFC of r237448) fixes the problem. Unfortunately, that is a fairly large patch and so I haven't investigated further. -- Peter Jeremy I just ran into this myself. Seems that the window resize is somehow causing sh(1) to receive an EOF while the shell is sitting at the prompt, which results in the shell exiting; haven't dug too deeply into the source yet, but can you try to run /bin/sh with the '-I' (that's capital letter 'i') and it the shell shouldn't exit (but it will bark at you with a 'Use exit to leave shell.' message on each resize. I'm CC'ing jilles@ for any potential insight into the behavior of sh(1) (and perhaps this updated libedit snapshot). Very disconcerting when I encountered this; glad I'm not alone on this one :) -Brandon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
