Re: bge problems in RELENG_9, bge0: watchdog timeout -- resetting
On Tue, Jul 03, 2012 at 08:57:04PM +0200, Anders Nordby wrote: > Hi, > > I'm having lots of difficulties with BCM5719, which is the default > network card of HP Proliant DL 360 G8 servers. I can get a few ping > replies before I get a couple of these: > > bge0: watchdog timeout -- resetting > > bge0: watchdog timeout -- resetting > > > Then everything hangs. Can not log in using ssh. > > I'm running: FreeBSD-9.0-RELENG_9-20120701-JPSNAP-amd64 > > Info about the NIC: > > # devinfo -rv | grep phy > brgphy0 pnpinfo oui=0x1be9 model=0x22 rev=0x0 at phyno=1 > > brgphy1 pnpinfo oui=0x1be9 model=0x22 rev=0x0 at phyno=2 > > brgphy2 pnpinfo oui=0x1be9 model=0x22 rev=0x0 at phyno=3 > > brgphy3 pnpinfo oui=0x1be9 model=0x22 rev=0x0 at phyno=4 > > # grep bge /var/run/dmesg.boot > bge0: mem > 0xf6bf-0xf6bf, > 0xf6be-0xf6be,0xf6bd-0xf6bd irq 32 at device 0.0 on pci3 > > bge0: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > > miibus0: on bge0 > > bge0: Ethernet address: 2c:76:8a:54:08:14 > > bge1: mem > 0xf6bc-0xf6bc, > 0xf6bb-0xf6bb,0xf6ba-0xf6ba irq 36 at device 0.1 on pci3 > > bge1: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > > miibus1: on bge1 > > bge1: Ethernet address: 2c:76:8a:54:08:15 > > bge2: mem > 0xf6b9-0xf6b9, > 0xf6b8-0xf6b8,0xf6b7-0xf6b7 irq 32 at device 0.2 on pci3 > > bge2: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > > miibus2: on bge2 > > bge2: Ethernet address: 2c:76:8a:54:08:16 > > bge3: mem > 0xf6b6-0xf6b6, > 0xf6b5-0xf6b5,0xf6b4-0xf6b4 irq 36 at device 0.3 on pci3 > > bge3: CHIP ID 0x05719001; ASIC REV 0x5719; CHIP REV 0x57190; PCI-E > > miibus3: on bge3 > > bge3: Ethernet address: 2c:76:8a:54:08:17 > > > Searching other bug reports and posts, I've tried: > > hw.bge.allow_asf="0" > > hw.pci.enable_msi="0" > > > But it didn't help. Any ideas? > > If I don't use the loader.conf settings above, I also get (before the > watchdog timeouts): > > bge0: 2 link states coalesced > > bge0: 2 link states coalesced > > bge0: 2 link states coalesced > There is a WIP version at the following URL. http://people.freebsd.org/~yongari/bge/if_bge.c http://people.freebsd.org/~yongari/bge/if_bgereg.h http://people.freebsd.org/~yongari/bge/brgphy.c I have a couple of positive feedbacks but it seems it still has some issues. Let me know whether it makes any difference on your box. > > Best regards, > > -- > Anders. ___ 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"
sh(1) exiting on SIGWINCH
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. ktrace output looks like: 1766 sh GIO fd 2 wrote 2 bytes "# " 1766 sh RET write 2 1766 sh CALL ioctl(0,TIOCGETA,0x801020364) 1766 sh RET ioctl 0 1766 sh CALL ioctl(0,TIOCSETAW,0x801020338) 1766 sh RET ioctl 0 1766 sh CALL read(0,0x7fffda8f,0x1) 1766 sh RET read -1 errno 4 Interrupted system call 1766 sh PSIG SIGWINCH caught handler=0x417d10 mask=0x0 code=0x10006 1766 sh CALL sigreturn(0x7fffd600) 1766 sh RET sigreturn JUSTRETURN 1766 sh CALL ioctl(0,TIOCSETAW,0x80102030c) 1766 sh RET ioctl 0 1766 sh CALL setpgid(0,0x6e6) 1766 sh RET setpgid -1 errno 1 Operation not permitted 1766 sh CALL ioctl(0xa,TIOCSPGRP,0x7fffda74) 1766 sh RET ioctl 0 1766 sh CALL close(0xa) 1766 sh RET close 0 1766 sh CALL exit(0) Does this ring any bells with anyone? -- Peter Jeremy pgp5N9G6c8SWr.pgp Description: PGP signature
Re: 9.0-STABLE: Can't umount umass device
On 07/04/12 00:14, Jason Hellenthal wrote: fstat /flash ? # fstat /flash USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME george gam_server 1654 5730 /flash 131072 drwxr-xr-x 32768 r /flash george gam_server 1654 5731 -131072 -rwxr-xr-x 512 r /flash Thanks for the tip, But, AARGH! Everything in the world seems to depend on this gamin thing. What's the recommended course of action?-- George On Tue, Jul 03, 2012 at 08:42:55PM -0400, George Mitchell wrote: uname -a: FreeBSD wonderland.m5p.com 9.0-STABLE FreeBSD 9.0-STABLE #9: Sun Jun 3 10:01:09 EDT 2012 geo...@wonderland.m5p.com:/usr/obj/usr/src/sys/WONDERLAND amd64 dmesg | grep umass: umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:3:0:-1: Attached to scbus3 (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): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed) da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 # mount -t msdosfs /dev/da0s1 /flash # umount /flash umount: unmount of /flash failed: Device busy -- George Mitchell ___ 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" ___ 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: 9.0-STABLE: Can't umount umass device
On 07/04/12 00:42, Ian Lepore wrote: On Tue, 2012-07-03 at 20:42 -0400, George Mitchell wrote: uname -a: FreeBSD wonderland.m5p.com 9.0-STABLE FreeBSD 9.0-STABLE #9: Sun Jun 3 10:01:09 EDT 2012 geo...@wonderland.m5p.com:/usr/obj/usr/src/sys/WONDERLAND amd64 dmesg | grep umass: umass0: on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:3:0:-1: Attached to scbus3 (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): SCSI sense: UNIT ATTENTION asc:28,0 (Not ready to ready change, medium may have changed) da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 # mount -t msdosfs /dev/da0s1 /flash # umount /flash umount: unmount of /flash failed: Device busy -- George Mitchell Are you running a desktop environment that automatically launches gam_server to watch for changes on mounted filesystems? If so, the fix is to edit /usr/local/etc/gamin/gaminrc and tell it to use polling rather than kernel notification on the mount points you use for removable media. -- Ian ___ 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" Thanks, this was the problem. By the way, here between these two rows of equals signs is the total amount of documentation that the gamin port/package installed on my system: == == Google showed me what to put in my /usr/local/etc/gamin/gaminrc file: poll /flash I appreciate the help! -- George ___ 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 with if_iwi(4) upon "netif restart"
On Mon, May 07, 2012 at 08:28:50PM +0200, Bernhard Schmidt wrote: > On Mon, May 7, 2012 at 5:54 AM, Alexey Dokuchaev wrote: > > Weird panic occurs to me here with iwi(4) based laptop when trying to hook > > up to WPA-protected network with "service netif restart". Kernel and > > userland are not strictly in sync, with the latter lagging behind couple > > of months, but presumably this fact should not matter on stable branch. > > does "ps" in kgdb reveal multiple instances of wpa_supplicant running? > If so, this seems to be the well known devd+netif+supplicant+newstate > race/missing refcount. > > Wanna try attached patch? Bernhard, Sorry it took so long to get back. With your patch applied, I haven't seen this panic for a while, however, double instances of wpa_supplicant still persist. So I think you can commit it, but underlying race remains to be fixed. ./danfe ___ 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 with if_iwi(4) upon "netif restart"
On Tuesday 19 June 2012 07:28:11 Alexey Dokuchaev wrote: > On Mon, May 07, 2012 at 08:28:50PM +0200, Bernhard Schmidt wrote: > > On Mon, May 7, 2012 at 5:54 AM, Alexey Dokuchaev wrote: > > > Weird panic occurs to me here with iwi(4) based laptop when trying to hook > > > up to WPA-protected network with "service netif restart". Kernel and > > > userland are not strictly in sync, with the latter lagging behind couple > > > of months, but presumably this fact should not matter on stable branch. > > > > does "ps" in kgdb reveal multiple instances of wpa_supplicant running? > > If so, this seems to be the well known devd+netif+supplicant+newstate > > race/missing refcount. > > > > Wanna try attached patch? > > Bernhard, > > Sorry it took so long to get back. With your patch applied, I haven't > seen this panic for a while, however, double instances of wpa_supplicant > still persist. So I think you can commit it, but underlying race remains > to be fixed. Ok, thanks. The patch is indeed supposed to only fix the panics. The underlying problem is that a "netif restart" results in 2 calls to "netif wlan0 start", one through the call itself the other due an event sent to devd. wpa_supplicant itself has a small window were it is possible that 2 instances are attached to one resource. I have yet to find a solution for this without adding any regressions. -- Bernhard ___ 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: 9.0-STABLE: Can't umount umass device
On 04/07/2012 14:17, George Mitchell wrote: > On 07/04/12 00:42, Ian Lepore wrote: >> >> >> Are you running a desktop environment that automatically launches >> gam_server to watch for changes on mounted filesystems? If so, the fix >> is to edit /usr/local/etc/gamin/gaminrc and tell it to use polling >> rather than kernel notification on the mount points you use for >> removable media. >> >> -- Ian >> >> ___ >> 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" > > Thanks, this was the problem. By the way, here between these two rows > of equals signs is the total amount of documentation that the gamin > port/package installed on my system: > == > == > Google showed me what to put in my /usr/local/etc/gamin/gaminrc file: > > poll /flash > > I appreciate the help! -- George To be fair the pkg-message for the port says jhary@ostracod $ cd (18:35:30 <~>) 0 jhary@ostracod $ pkg_info -D gamin-0.1.10_4 Information for gamin-0.1.10_4: Install notice: === Gamin will only provide realtime notification of changes for at most n files, where n is the minimum value between (kern.maxfiles * 0.7) and (kern.maxfilesperproc - 200). Beyond that limit, files will be polled. If you often open several large folders with Nautilus, you might want to increase the kern.maxfiles tunable (you do not need to set kern.maxfilesperproc, since it is computed at boot time from kern.maxfiles). For a typical desktop, add the following line to /boot/loader.conf, then reboot the system: kern.maxfiles="25000" The behavior of gamin can be controlled via the various gaminrc files. See http://www.gnome.org/~veillard/gamin/config.html on how to create these files. In particular, if you find gam_server is taking up too much CPU time polling for changes, something like the following may help in one of the gaminrc files: # reduce polling frequency to once per 10 seconds # for UFS file systems in order to lower CPU load fsset ufs poll 10 === The lack of a manpage is sadly down to gamin though. Vince > ___ > 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" ___ 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 2012-Jul-04 20:03:32 +1000, Peter Jeremy 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 pgp3dL0c9CGxT.pgp Description: PGP signature
Re: new Heimdal version, was NFSv3 + krb5 mysteries - need help tracking down
Hi Rick, On 30/06/12 00:48, Rick Macklem wrote: Maybe the person working on the newer Heimdal can comment? (I've changed the subject line so they might notice.) Can you give me a contact? He/she might not have noticed your subject change. Thanks, Attila ___ 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 wrote: > On 2012-Jul-04 20:03:32 +1000, Peter Jeremy 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"
