ste driver broken
Greetings, I recently upgraded one machine to a recent -CURRENT, and the NIC (DLink 550 TX) fails to be properly initialized. The rest of the system is pretty vanilla : Athlon XP, with Via chipset. Here is the relevant part of dmesg: ste0: D-Link DFE-550TX 10/100BaseTX port 0x9800-0x987f mem 0xe900-0xe97f irq 7 at device 11.0 on pci0 /usr/src/sys/vm/uma_core.c:1332: could sleep with ste0 locked from /usr/src/sys/pci/if_ste.c:937 /usr/src/sys/vm/uma_core.c:1332: could sleep with ste0 locked from /usr/src/sys/pci/if_ste.c:937 lock order reversal 1st 0xc25b69a4 ste0 (network driver) @ /usr/src/sys/pci/if_ste.c:937 2nd 0xc0318600 allproc (allproc) @ /usr/src/sys/kern/kern_fork.c:317 /usr/src/sys/vm/uma_core.c:1332: could sleep with ste0 locked from /usr/src/sys/pci/if_ste.c:937 /usr/src/sys/vm/uma_core.c:1332: could sleep with ste0 locked from /usr/src/sys/pci/if_ste.c:937 /usr/src/sys/vm/uma_core.c:1332: could sleep with ste0 locked from /usr/src/sys/pci/if_ste.c:937 ste0: Ethernet address: 00:50:ba:71:be:ea ste0: MII without any phy! device_probe_and_attach: ste0 attach returned 6 By replacing the current version of /usr/src/sys/pci/if_ste.c by version 1.33 I am able to obtain a correctly working system. This is a part of the new dmesg: ste0: D-Link DFE-550TX 10/100BaseTX port 0x9800-0x987f mem 0xe900-0xe97f irq 7 at device 11.0 on pci0 /usr/src/sys/vm/uma_core.c:1332: could sleep with ste0 locked from /usr/src/sys/pci/if_ste.c:906 /usr/src/sys/vm/uma_core.c:1332: could sleep with ste0 locked from /usr/src/sys/pci/if_ste.c:906 lock order reversal 1st 0xc26039a4 ste0 (network driver) @ /usr/src/sys/pci/if_ste.c:906 2nd 0xc0487c00 allproc (allproc) @ /usr/src/sys/kern/kern_fork.c:317 /usr/src/sys/vm/uma_core.c:1332: could sleep with ste0 locked from /usr/src/sys/pci/if_ste.c:906 /usr/src/sys/vm/uma_core.c:1332: could sleep with ste0 locked from /usr/src/sys/pci/if_ste.c:906 /usr/src/sys/vm/uma_core.c:1332: could sleep with ste0 locked from /usr/src/sys/pci/if_ste.c:906 ste0: Ethernet address: 00:50:ba:71:be:ea miibus0: MII bus on ste0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto /usr/src/sys/vm/uma_core.c:1332: could sleep with ste0 locked from /usr/src/sys/pci/if_ste.c:244 The main difference between the working and current revision of if_ste.c is very small and doesn't add anything new. I think it should be removed. -- François Tigeot| AFNIC http://www.nic.fr/ | mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Tue, Dec 20, 2011 at 03:29:25PM -0800, Jeremy Chadwick wrote: This also interested me: * Linux system crashed http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg8.html * OpenIndiana system crashed same way as Linux system http://leaf.dragonflybsd.org/mailarchive/kernel/2011-11/msg00017.html I cannot help but wonder if the Linux and OpenIndiana installations were more stressful on the hardware -- getting more out of the system, maybe resulting in increased power/load, which in turn resulted in the systems locking up (shoddy PSU, unstable mainboard, MCH problems, etc.). My point is that Francois states these things in such a way to imply that DragonflyBSD was more stable, Same thing can be said for FreeBSD, only Linux and OpenIndiana crashed reliably if I remember correctly. when in fact I happen to wonder the opposite point -- that is to say, Linux and OpenIndiana were trying to use the hardware more-so than DragonflyBSD, thus tickled what may be a hardware-level problem. I actually ran the benchmarks on two different machines with the same hardware -- brand new Supermicro boxes with ECC memory and no cut corners. Since then, I've found I could stop the Linux crashes by disabling some options in the BIOS setup: - advanced ACPI settings (don't remember exactly which ones) - and a new WHEA one. WHEA means Windows Hardware Error Architecture. For all I know, it may have been the only culprit but I didn't have time to verify if the machines also ran fine with only this option disabled. -- Francois Tigeot ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
moused(8) broken
Hi, On a system without kernel modules moused fails to start with the following message : moused: unable to load USB mouse driver: No such file or directory The hardware is a Via C3 mini-itx PC with an USB mouse. The system was compiled today; it worked on the 13th. Even though the ums driver is compiled in the kernel and /dev/ums0 is present it seems moused tries to load a kernel module and fails if this is not possible. I have verified the problem to be caused by revision 1.61 of src/usr.sbin/moused/moused.c -- François Tigeot| AFNIC http://www.nic.fr/ | mailto:[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
