Re: Problem with the installer sysinstall.
On Tue, Nov 07, 2006 at 01:48:36PM -0500, Michael Butler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bruno Ducrot wrote: cpu0: ACPI CPU on acpi0 acpi_perf0: ACPI CPU Frequency Control on cpu0 acpi_throttle0: ACPI CPU Throttling on cpu0 cpu1: ACPI CPU on acpi0 acpi_throttle1: ACPI CPU Throttling on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 Anyway the OP should enable eist and p4tcc (by loading cpufreq on boot) and both acpi_perf and acpi_throttle will be gone. Adding 'device cpufreq' results in dmesg looking like .. acpi0: TOSINV Capell00 on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.PCIB.DOCK._STA] (Node 0xc64090e0), AE_NOT_EXIST ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.PCIB.DOCK._STA] (Node 0xc64090e0), AE_NOT_EXIST ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.PCIB.DOCK._STA] (Node 0xc64090e0), AE_NOT_EXIST ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.PCIB.DOCK._STA] (Node 0xc64090e0), AE_NOT_EXIST Strange. Does this happens only when you add cpufreq? Also, could you please add a link (www or ftp) to a file generated by acpidump -d -t the_model_of_this_computer.asl? acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_ec0: Embedded Controller: GPE 0x16 port 0x62,0x66 on acpi0 cpu0: ACPI CPU on acpi0 est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 est1: Enhanced SpeedStep Frequency Control on cpu1 p4tcc1: CPU Frequency Thermal Control on cpu1 Seems to be ok. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
On Tue, November 7, 2006 6:18 pm, Scott Long wrote: It's just unclear to me how you're associating bce problems with checksum offloading and IP fragmentation to em problems with design issues in the watchdog code. You are correct, the bce watchdog timeouts seem to be related to hw checksums, apologies for the mistake. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
On Monday, 6 November 2006 at 22:42:18 -0800, Jack Vogel wrote: On 11/6/06, Adrian Chadd [EMAIL PROTECTED] wrote: Just out of curiousity - why wasn't the offending MPSAFE related changes to em just reverted after discovering the em instability? The driver -was- stable a couple of months ago, no? Actually it was not. Some reports have cited problems back to 6.0 or before. Well i have 5.5 box with very similar symptomatic :) I do not see watchdog timeouts on it, but a lot of UP/DOWN events. The watchdog design was fundamentally flawed from an SMP point of view and needed to be changed. We also didnt want to go backwards if possible. My Intel driver had support for new hardware that was good to pick up. There's lots of new stuff coming too, so stay tuned :) After 48 hours of production running there is no watchdog timeouts on my 6.2 SMP server with your patch. Thanks for all who working on this. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- == - Best regards, Nikolay Pavlov. --- == ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
On Wed, Nov 08, 2006 at 04:40:03PM +0200, Nikolay Pavlov wrote: Well i have 5.5 box with very similar symptomatic :) I do not see watchdog timeouts on it, but a lot of UP/DOWN events. Are you sure this is the same problem as what's being discussed here? If you revert to a previous kernel or em driver, does the problem (link up/down) go away? Are you sure you don't actually have a flaky cable or RJ45 connector? What does the switch your NIC is connected to say? (does it show link going up and down) I feel horrible for both Scott and Jack -- I think there's tons of people coming out of the woodwork with ME TOO comments who may in fact be suffering from other problems, and are looking for a scapegoat thread. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic on 6.2-PRERELEASE (With backtrace)
On Friday, 3 November 2006 at 17:49:28 +0200, Nikolay Pavlov wrote: On Friday, 3 November 2006 at 17:33:42 +0200, Nikolay Pavlov wrote: Hi, guys. I have a panic running squid as web accelerator on 6.2-PRERELEASE. Here is a backtrace: [EMAIL PROTECTED]:/usr/obj/usr/src/sys/ACCEL# kgdb kernel.debug /var/crash/vmcore.0 kgdb: kvm_nlist(_stopped_cpus): kgdb: kvm_nlist(_stoppcbs): [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-marcel-freebsd. Unread portion of the kernel message buffer: panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated KDB: stack backtrace: kdb_backtrace(100,cb83b000,c1040500,c1040500,0,...) at kdb_backtrace+0x29 panic(c06e0826,1000,1400,dd22b6e8,1000,...) at panic+0xa8 kmem_malloc(c104b0c0,1000,102,ebc75aec,c063c285,...) at kmem_malloc+0x89 page_alloc(c103d080,1000,ebc75adf,102,38,...) at page_alloc+0x1a slab_zalloc(c103d080,102,c103d0c8,c103d080,c1032d9c,...) at slab_zalloc+0xa1 uma_zone_slab(c103d080,2) at uma_zone_slab+0xe8 uma_zalloc_bucket(c103d080,2) at uma_zalloc_bucket+0x11c uma_zalloc_arg(c103d080,dd18d100,2) at uma_zalloc_arg+0x2dc mb_zinit_pack(dd18d100,100,2) at mb_zinit_pack+0x18 uma_zalloc_bucket(c103d100,3) at uma_zalloc_bucket+0x168 uma_zalloc_arg(c103d100,ebc75bfc,2) at uma_zalloc_arg+0x2dc sosend(cbb7842c,0,ebc75cbc,0,0,0,cb83b000) at sosend+0x3c5 soo_write(daa2f870,ebc75cbc,cb68d100,0,cb83b000) at soo_write+0xa1 dofilewrite(cb83b000,1174,daa2f870,ebc75cbc,,...) at dofilewrite+0x77 kern_writev(cb83b000,1174,ebc75cbc,cfa4000,1000,...) at kern_writev+0x3b write(cb83b000,ebc75d04) at write+0x45 syscall(82e003b,3b,bfbe003b,e894ea0,e2e40,...) at syscall+0x25b Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (4, FreeBSD ELF32, write), eip = 0xa8319bab, esp = 0xbfbe8cac, ebp = 0xbfbe8cd8 --- KDB: enter: panic panic: from debugger Uptime: 5m34s Dumping 3967 MB (3 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 3966MB (1015280 pages) 3950 3934 3918 3902 3886 3870 3854 3838 3822 3806 3790 3774 3758 3742 3726 3710 3694 3678 3662 3646 3630 3614 3598 3582 3566 3550 3534 3518 3502 3486 3470 3454 3438 3422 3406 3390 3374 3358 3342 3326 3310 3294 3278 3262 3246 3230 3214 3198 3182 3166 3150 3134 3118 3102 3086 3070 3054 3038 3022 3006 2990 2974 2958 2942 2926 2910 2894 2878 2862 2846 2830 2814 2798 2782 2766 2750 2734 2718 2702 2686 2670 2654 2638 2622 2606 2590 2574 2558 2542 2526 2510 2494 2478 2462 2446 2430 2414 2398 2382 2366 2350 2334 2318 2302 2286 2270 2254 2238 2206 2190 2174 2158 2142 2126 2110 2094 2078 2062 2046 2030 2014 1998 1982 1966 1950 1934 1918 1902 1886 1870 1854 1838 1822 1806 1790 1774 1758 1742 1726 1710 1694 1678 1662 1646 1630 1614 1598 1582 1566 1550 1534 1518 1502 1486 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 ... ok chunk 2: 1MB (128 pages) #0 doadump () at pcpu.h:165 165 __asm __volatile(movl %%fs:0,%0 : =r (td)); (kgdb) quit Some additional information: [EMAIL PROTECTED]:~# cat /boot/loader.conf # --- Loader settings --- autoboot_delay=5 # Delay in seconds before autobooting # --- Kernel tunables --- kern.ipc.nmbclusters=131072 # Set the number of mbuf clusters kern.cam.scsi_delay=5000 # Delay (in ms) before probing SCSI kern.maxdsiz=2560M# Allow more memory allocation for squid kern.dfldsiz=2560M# Allow more memory allocation for squid kern.maxssiz=128M # Allow more memory allocation for squid # --- Networking modules --- pf_load=YES # Packet filter # --- Other modules --- accf_data_load=YES # Wait for data accept filter accf_http_load=YES # Wait for full HTTP request accept filter [EMAIL PROTECTED]:~# cat /etc/sysctl.conf # --- MAC access for squid --- net.inet.ip.portrange.reservedlow=0 net.inet.ip.portrange.reservedhigh=0 security.mac.portacl.rules=uid:100:tcp:80 # --- Kernel tunning --- kern.ipc.somaxconn=8192 # --- Network tunning and protection
Re: em driver testing
Jeremy Chadwick wrote: On Wed, Nov 08, 2006 at 04:40:03PM +0200, Nikolay Pavlov wrote: Well i have 5.5 box with very similar symptomatic :) I do not see watchdog timeouts on it, but a lot of UP/DOWN events. Are you sure this is the same problem as what's being discussed here? If you revert to a previous kernel or em driver, does the problem (link up/down) go away? Are you sure you don't actually have a flaky cable or RJ45 connector? What does the switch your NIC is connected to say? (does it show link going up and down) I feel horrible for both Scott and Jack -- I think there's tons of people coming out of the woodwork with ME TOO comments who may in fact be suffering from other problems, and are looking for a scapegoat thread. The timeout/watchdog mechanism in the interface layer has been a problem ever since the MPSAFE work was done on the network stack. It's prone to races, and as the OS has improved and gotten faster over the past 2 years, those races have gotten bigger. In a way, it's a actually a positive indication of progress and improvement =-) I don't doubt that there are users with other problems. We spent some time collecting as much user data as we could in order to find patterns and weed out the uncommon cases. But this timer/watchdog thing looks to be a strong candidate for being the root cause of many of the problems. We'll continue to investigate these problems and address other drivers. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
On Wednesday, 8 November 2006 at 7:41:02 -0800, Jeremy Chadwick wrote: On Wed, Nov 08, 2006 at 04:40:03PM +0200, Nikolay Pavlov wrote: Well i have 5.5 box with very similar symptomatic :) I do not see watchdog timeouts on it, but a lot of UP/DOWN events. Are you sure this is the same problem as what's being discussed here? If you revert to a previous kernel or em driver, does the problem (link up/down) go away? Are you sure you don't actually have a flaky cable or RJ45 connector? What does the switch your NIC is connected to say? (does it show link going up and down) I am pretty sure. All my servers using the same em chip, on all my 6.1 boxes either UP or SMP i see watchdog timeout, average load of this adapters is 5000 - 6000 interrunpts per second. I have only one box with 5.5 (same task and same platform), but i am not claiming that this is exactly the watchdog problem, it's just very symptomatic in context of discussion. In any case new 6.2 em patch works for me, at least i do not see watchdog timeouts after 48 hours of uptime. By the way the box is connected to 2950 switch, i can't find any problems on cabling. Here is how it looks like on 5.5: Oct 18 05:38:45 ms6 kernel: em0: Link is up 1000 Mbps Full Duplex Oct 18 05:38:50 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: not responding Oct 18 05:39:21 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: not responding Oct 18 05:39:32 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: is alive again Oct 18 05:52:22 ms6 kernel: em0: Link is Down Oct 18 05:55:13 ms6 kernel: em0: Link is up 1000 Mbps Full Duplex Oct 18 05:55:13 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: not responding Oct 18 05:55:44 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: not responding Oct 18 05:55:46 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: is alive again Oct 18 06:01:52 ms6 kernel: em0: Link is Down Oct 18 06:03:54 ms6 kernel: em0: Link is up 1000 Mbps Full Duplex Oct 18 06:03:54 ms6 kernel: em0: Link is Down Oct 18 06:04:01 ms6 kernel: em0: Link is up 1000 Mbps Full Duplex Oct 18 06:16:07 ms6 kernel: em0: Link is Down Oct 18 06:18:16 ms6 kernel: em0: Link is up 1000 Mbps Full Duplex Oct 18 06:21:55 ms6 kernel: em0: Link is Down Oct 18 06:25:12 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: not responding Oct 18 06:25:25 ms6 kernel: em0: Link is up 1000 Mbps Full Duplex Oct 18 06:25:27 ms6 kernel: em0: Link is Down Oct 18 06:25:33 ms6 kernel: em0: Link is up 1000 Mbps Full Duplex Oct 18 06:25:43 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: not responding Oct 18 06:26:10 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: is alive again Oct 18 06:43:12 ms6 kernel: em0: Link is Down Oct 18 06:45:13 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: not responding Oct 18 06:45:44 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: not responding Oct 18 06:46:15 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: not responding Oct 18 06:46:27 ms6 kernel: em0: Link is up 1000 Mbps Full Duplex Oct 18 06:46:28 ms6 kernel: em0: Link is Down Oct 18 06:46:34 ms6 kernel: em0: Link is up 1000 Mbps Full Duplex Oct 18 06:46:46 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: not responding Oct 18 06:47:17 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: not responding Oct 18 06:47:26 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: is alive again Oct 18 07:02:51 ms6 kernel: em0: Link is Down Oct 18 07:04:42 ms6 kernel: em0: Link is up 1000 Mbps Full Duplex Oct 18 07:04:44 ms6 kernel: em0: Link is Down Oct 18 07:04:50 ms6 kernel: em0: Link is up 1000 Mbps Full Duplex Oct 18 07:05:13 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: not responding Oct 18 07:05:25 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: is alive again Oct 18 16:40:05 ms6 kernel: receive error 60 from nfs server 206.53.x.x:/usr/home/shared Oct 19 03:55:13 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: not responding Oct 19 03:55:15 ms6 kernel: nfs server 206.53.x.x:/usr/home/shared: is alive again After that date it was rebooted at least three times and i don't see such symptoms any more. I feel horrible for both Scott and Jack -- I think there's tons of people coming out of the woodwork with ME TOO comments who may in fact be suffering from other problems, and are looking for a scapegoat thread. Just ignore me. Patch works for me and this is end. -- == - Best regards, Nikolay Pavlov. --- == ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
On Wednesday, 8 November 2006 at 9:26:26 -0700, Scott Long wrote: Jeremy Chadwick wrote: On Wed, Nov 08, 2006 at 04:40:03PM +0200, Nikolay Pavlov wrote: Well i have 5.5 box with very similar symptomatic :) I do not see watchdog timeouts on it, but a lot of UP/DOWN events. Are you sure this is the same problem as what's being discussed here? If you revert to a previous kernel or em driver, does the problem (link up/down) go away? Are you sure you don't actually have a flaky cable or RJ45 connector? What does the switch your NIC is connected to say? (does it show link going up and down) I feel horrible for both Scott and Jack -- I think there's tons of people coming out of the woodwork with ME TOO comments who may in fact be suffering from other problems, and are looking for a scapegoat thread. The timeout/watchdog mechanism in the interface layer has been a problem ever since the MPSAFE work was done on the network stack. It's prone to races, and as the OS has improved and gotten faster over the past 2 years, those races have gotten bigger. In a way, it's a actually a positive indication of progress and improvement =-) I don't doubt that there are users with other problems. We spent some time collecting as much user data as we could in order to find patterns and weed out the uncommon cases. But this timer/watchdog thing looks to be a strong candidate for being the root cause of many of the problems. We'll continue to investigate these problems and address other drivers. Scott Thanks Scott. From my side, I'd like to say that I'm always ready to help you in testing. -- == - Best regards, Nikolay Pavlov. --- == ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
Scott Long wrote: I don't doubt that there are users with other problems. We spent some time collecting as much user data as we could in order to find patterns and weed out the uncommon cases. But this timer/watchdog thing looks to be a strong candidate for being the root cause of many of the problems. We'll continue to investigate these problems and address other drivers. Out of interest are there any priorities for drivers that will get fixed before 6.2 release? Obviously em will but what others: bge, xl? Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
Steven Hartland wrote: Scott Long wrote: I don't doubt that there are users with other problems. We spent some time collecting as much user data as we could in order to find patterns and weed out the uncommon cases. But this timer/watchdog thing looks to be a strong candidate for being the root cause of many of the problems. We'll continue to investigate these problems and address other drivers. Out of interest are there any priorities for drivers that will get fixed before 6.2 release? Obviously em will but what others: bge, xl? Steve My personally opinion is that the changes needed are too risky to rush into 6.2 for all of the different drivers. For the vast majority of people, what is in 6.2 works quite well, and there is no need to introduce new bugs. We are pushing forward with if_em because the problems there are pretty widespread, and Intel is providing direct engineering and QA input. Thus, risk is reduced. Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: em driver testing
Scott Long wrote: My personally opinion is that the changes needed are too risky to rush into 6.2 for all of the different drivers. For the vast majority of people, what is in 6.2 works quite well, and there is no need to introduce new bugs. We are pushing forward with if_em because the problems there are pretty widespread, and Intel is providing direct engineering and QA input. Thus, risk is reduced. From a purely user's point of view, it would be nice if the problems were clearly mentioned in errata together with links to the newest patches or some other kind of pointer to the ongoing work so people know where to look if these bugs hit them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD doesn't boot at Supermicro H8SSL-i2
Thomas Krause wrote: BTW: There is no way to disable USB completely? You can try using loader hints: http://www.freebsd.org/cgi/man.cgi?query=device.hintssektion=5 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: problems compiling stable
On Tue, Nov 07, 2006 at 08:07:26PM +, Vince Hoffman wrote: Have you tried cd /usr/obj/usr/src/usr.bin/vi rm -rf * rm .depend (make clean doesnt delete .depend and rm -rf * doesnt either.) then try cd /usr/src/usr.bin make There's a convenience target for this, make cleandepend. Another useful target is cleandir, which removes the object directory if it's different from source directory, and otherwise does make clean cleandepend. Cheers, -- Ruslan Ermilov [EMAIL PROTECTED] FreeBSD committer pgpdEzKblsaWJ.pgp Description: PGP signature
Re: FreeBSD doesn't boot at Supermicro H8SSL-i2
Wouldn't disabling USB in BIOS work? This appears to be possible from most of the PC's I see in my travels. Ivan Voras wrote: Thomas Krause wrote: BTW: There is no way to disable USB completely? You can try using loader hints: http://www.freebsd.org/cgi/man.cgi?query=device.hintssektion=5 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: error in /etc/rc.d/mdconfig{,2}
Hi!
Two weeks later, this small typo-correction doesn't reach the RELENG_6
branch. Will it, before src-freeze?
Zahy Gabor at Zahemszky dot HU
On Thu, 2006-10-26 at 01:30 +0400, Ruslan Ermilov wrote:
On Wed, Oct 25, 2006 at 10:44:34PM +0200, Zahemszky G?bor wrote:
Hi!
I've just found, that both /etc/rc.d/mdconfig, and /etc/rc.d/mdconfig2
file in my 6.2.prerelease (cvsupped yesterday), has an incorrect kldload
line:
kldstat -q -m g_md || kldload geom_md || err 1 geom_md failed to load.
(mdconfig line 97, and mdconfig2 line 104)
The module name is g_md, and not geom_md.
# $FreeBSD: src/etc/rc.d/mdconfig,v 1.3.2.1 2006/08/21 15:06:38 flz Exp $
# $FreeBSD: src/etc/rc.d/mdconfig2,v 1.3.2.1 2006/08/21 15:06:38 flz Exp $
True. In RELENG_6 the module is named g_md.ko, while in HEAD it was
renamed to geom_md.ko.
Indeed, forgot to change the name, geom_uzip doesn't need to be changed.
Is there a reason why the rename hasn't been MFC'ed? g_md seems to be
the only one not to be named geom_something.
Anyway, here's the patch for RELENG_6, is it ok to commit?
Index: mdconfig
===
RCS file: /home/ncvs/src/etc/rc.d/mdconfig,v
retrieving revision 1.3.2.1
diff -u -r1.3.2.1 mdconfig
--- mdconfig21 Aug 2006 15:06:38 - 1.3.2.1
+++ mdconfig25 Oct 2006 21:42:22 -
@@ -108,7 +108,7 @@
return
fi
- kldstat -q -m g_md || kldload geom_md || err 1 geom_md failed
to load.
+ kldstat -q -m g_md || kldload g_md || err 1 g_md failed to
load.
for _md in ${_mdconfig_list}; do
init_variables ${_md}
Index: mdconfig2
===
RCS file: /home/ncvs/src/etc/rc.d/mdconfig2,v
retrieving revision 1.3.2.1
diff -u -r1.3.2.1 mdconfig2
--- mdconfig2 21 Aug 2006 15:06:38 - 1.3.2.1
+++ mdconfig2 25 Oct 2006 21:42:22 -
@@ -116,7 +116,7 @@
return
fi
- kldstat -q -m g_md || kldload geom_md || err 1 geom_md failed
to load.
+ kldstat -q -m g_md || kldload g_md || err 1 g_md failed to
load.
for _md in ${_mdconfig2_list}; do
init_variables ${_md}
--
#!/bin/ksh
Z='21N16I25C25E30, 40M30E33E25T15U!';IFS=' ABCDEFGHIJKLMNOPQRSTUVWXYZ
';set -- $Z;for i;{ [[ $i = ? ]]print $ibreak;[[ $i = ???
]]j=$ii=${i%?};typeset -i40 i=8#$i;print -n ${i#???};[[ $j = ???
]]print -n ${j#??} j=;typeset +i i;};IFS=' 0123456789 ';set --
$Z;for i;{ [[ $i = , ]]i=2;[[ $i = ?? ]]||typeset -l i;j=$j
$i;typeset +l i;};print $j
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: error in /etc/rc.d/mdconfig{,2}
Zahemszky Gábor wrote:
Hi!
Two weeks later, this small typo-correction doesn't reach the RELENG_6
branch. Will it, before src-freeze?
Zahy Gabor at Zahemszky dot HU
On Thu, 2006-10-26 at 01:30 +0400, Ruslan Ermilov wrote:
On Wed, Oct 25, 2006 at 10:44:34PM +0200, Zahemszky G?bor wrote:
Hi!
I've just found, that both /etc/rc.d/mdconfig, and /etc/rc.d/mdconfig2
file in my 6.2.prerelease (cvsupped yesterday), has an incorrect kldload
line:
kldstat -q -m g_md || kldload geom_md || err 1 geom_md failed to load.
(mdconfig line 97, and mdconfig2 line 104)
The module name is g_md, and not geom_md.
# $FreeBSD: src/etc/rc.d/mdconfig,v 1.3.2.1 2006/08/21 15:06:38 flz Exp $
# $FreeBSD: src/etc/rc.d/mdconfig2,v 1.3.2.1 2006/08/21 15:06:38 flz Exp $
True. In RELENG_6 the module is named g_md.ko, while in HEAD it was
renamed to geom_md.ko.
Indeed, forgot to change the name, geom_uzip doesn't need to be changed.
Is there a reason why the rename hasn't been MFC'ed? g_md seems to be
the only one not to be named geom_something.
Anyway, here's the patch for RELENG_6, is it ok to commit?
Index: mdconfig
===
RCS file: /home/ncvs/src/etc/rc.d/mdconfig,v
retrieving revision 1.3.2.1
diff -u -r1.3.2.1 mdconfig
--- mdconfig21 Aug 2006 15:06:38 - 1.3.2.1
+++ mdconfig25 Oct 2006 21:42:22 -
@@ -108,7 +108,7 @@
return
fi
- kldstat -q -m g_md || kldload geom_md || err 1 geom_md failed
to load.
+ kldstat -q -m g_md || kldload g_md || err 1 g_md failed to
load.
for _md in ${_mdconfig_list}; do
init_variables ${_md}
Index: mdconfig2
===
RCS file: /home/ncvs/src/etc/rc.d/mdconfig2,v
retrieving revision 1.3.2.1
diff -u -r1.3.2.1 mdconfig2
--- mdconfig2 21 Aug 2006 15:06:38 - 1.3.2.1
+++ mdconfig2 25 Oct 2006 21:42:22 -
@@ -116,7 +116,7 @@
return
fi
- kldstat -q -m g_md || kldload geom_md || err 1 geom_md failed
to load.
+ kldstat -q -m g_md || kldload g_md || err 1 g_md failed to
load.
for _md in ${_mdconfig2_list}; do
init_variables ${_md}
g_md.ko has been renamed geom_md.ko on Sunday, Nov 5.
Have a look at sys/modules/md/Makefile 1.13.8.1
Claude Buisson
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Dissapointing performance of ciss RAID 0+1 ?
I recently overhauled my RAID array - I now have 4 drives arranged as RAID 0+1, all being 15K 147gig Fujitsu's, and split across two buses, which are actively terminated to give U160 speeds (and I have verified this). The card is a 5304 (128M cache) in a PCI-X slot. This replaces a set of 6 7200 rpm drives as RAID 5 which were running at 40meg speeds due to non LVD termination. I would expect to see a large speed increase wouldn't I ? But it remains about the same - around 45 meg/sec for reading a large file (3 gig or so) and half that for copying said file. These are 'real world' tests in the sense that I us the drive for building large ISo images and copying them around - I really dont care what benchmarks say, it's the speed of these two operatiosn that I want to make fats. I've tried all the possible stripe sizes (128k gives the best performance) but still I only get the above speeds. Just one of the 15k drives on it's own performs better than this! I would expect the RAID-0 to give me at least some speedup, or in the worst case be the same, surely ? Booting up Windowws and running some tests gives me far better performance however, so I am wondering if there is some driver issue here. Has anyone else seen the same kind of results ? I am running the latest stable for amd64 and the machine has twin opteron 242's with a gig of RAM each. surely it can do better than this ? -pcf. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Proposed 6.2 em RELEASE patch
This patch is an evolution of the last one I sent out. It has a couple of minor corrections, like a bad forward decl in the header. The last patch has had quite a bit of testing and all reports have been positive. The only complaint was from Gleb who says he needs to keep his beloved infinite for loop in the interrupt handler, well I have a better one for you Gleb, keep reading. I have also been doing some extreme stress testing using SmartBits, and discovered the driver as it stands is really not able to take extreme receive side pounding, Scott pointed out that this is why the FAST_INTR work was done :) There were some people that had stability issues with that work, but there were also many that did not. I actually merged the FAST code onto my last patch, and ran the SB stress and found it really was able to gracefully handle that load, way to go Scott :) I've pondered this situation, and this patch I'm including here today is the result. Here's what it does: If you drop it in place, compile it, and go... you will get the code that has been tested for a week, it uses the older style interrupts, it has the watchdog and other SMP fixes so its been proven. BUT, I've added the FAST_INTR changes back into the code, so if you go into your Makefile and add -DEM_FAST_INTR you will then get the taskqueue stuff. So, Gleb, rather than replace the infinite for loop that no one thinks is a good idea, you can just define FAST_INTR again, and you should be good to go. I see this as the best thing for the 6.2 RELEASE, it lets us keep moving forward, people that want max performance can define EM_FAST_INTR and help us wring out any problems, it also will mean that I will have our Intel test group start using this code. But for those that just want a stable driver the standard compile will still give them that. The patch I'm including is against BETA3. Let me know of your concerns or issues. Cheers, Jack diff -Naur stable/dev/em/if_em.c newpatch/dev/em/if_em.c --- stable/dev/em/if_em.c Wed Nov 8 23:42:20 2006 +++ newpatch/dev/em/if_em.c Wed Nov 8 23:44:16 2006 @@ -204,7 +204,7 @@ static void em_start(struct ifnet *); static void em_start_locked(struct ifnet *ifp); static int em_ioctl(struct ifnet *, u_long, caddr_t); -static void em_watchdog(struct ifnet *); +static void em_watchdog(struct adapter *); static void em_init(void *); static void em_init_locked(struct adapter *); static void em_stop(void *); @@ -212,6 +212,8 @@ static int em_media_change(struct ifnet *); static void em_identify_hardware(struct adapter *); static int em_allocate_pci_resources(struct adapter *); +static int em_allocate_intr(struct adapter *); +static void em_free_intr(struct adapter *); static void em_free_pci_resources(struct adapter *); static void em_local_timer(void *); static int em_hardware_init(struct adapter *); @@ -253,8 +255,7 @@ static int em_82547_fifo_workaround(struct adapter *, int); static void em_82547_update_fifo_head(struct adapter *, int); static int em_82547_tx_fifo_reset(struct adapter *); -static void em_82547_move_tail(void *arg); -static void em_82547_move_tail_locked(struct adapter *); +static void em_82547_move_tail(void *); static int em_dma_malloc(struct adapter *, bus_size_t, struct em_dma_alloc *, int); static void em_dma_free(struct adapter *, struct em_dma_alloc *); @@ -267,11 +268,18 @@ static int em_sysctl_int_delay(SYSCTL_HANDLER_ARGS); static void em_add_int_delay_sysctl(struct adapter *, const char *, const char *, struct em_int_delay_info *, int, int); +static void em_add_rx_process_limit(struct adapter *, const char *, + const char *, int *, int); +#ifdef EM_FAST_INTR +static void em_intr_fast(void *); +static void em_handle_rxtx(void *context, int pending); +static void em_handle_link(void *context, int pending); +#else /* Legacy Interrupt Handling */ static void em_intr(void *); - #ifdef DEVICE_POLLING static poll_handler_t em_poll; -#endif +#endif /* DEVICE_POLLING */ +#endif /* EM_FAST_INTR */ /* * FreeBSD Device Interface Entry Points @@ -321,6 +329,10 @@ TUNABLE_INT(hw.em.txd, em_txd); TUNABLE_INT(hw.em.smart_pwr_down, em_smart_pwr_down); +/* How many packets rxeof tries to clean at a time */ +static int em_rx_process_limit = 100; +TUNABLE_INT(hw.em.rx_process_limit, em_rx_process_limit); + /* * Device identification routine * @@ -406,8 +418,8 @@ OID_AUTO, stats, CTLTYPE_INT|CTLFLAG_RW, adapter, 0, em_sysctl_stats, I, Statistics); - callout_init(adapter-timer, CALLOUT_MPSAFE); - callout_init(adapter-tx_fifo_timer, CALLOUT_MPSAFE); + callout_init_mtx(adapter-timer, adapter-mtx, 0); + callout_init_mtx(adapter-tx_fifo_timer, adapter-mtx, 0); /* Determine hardware revision */ em_identify_hardware(adapter); @@ -432,6 +444,11 @@ em_tx_abs_int_delay_dflt); } + /* Sysctls for
nvidia0 em0 shared irq problem persists on dell precision 670
I synced sources today and tested the em changes, and the problem has not gone away for me. nvidia0 and em0 are shown as shared with ioacpi disabled using a device hint. interrupt total rate irq1: atkbd0 60 0 irq6: fdc010 0 irq14: ata0 16 0 irq15: ata1 47 0 irq16: nvidia0+++1267513 2162 irq18: uhci2+ 52688 89 irq23: ehci0 1 0 irq48: em0106712182 cpu0: timer 1167964 1993 cpu1: timer 1165966 1989 Total3760977 6418 When disabling the ioapic, the rate falls to the 600s which is still a tad high no? I was running it with apic disabled as a work around, but I plan on buying another processor for this box soon. Running it with a SMP kernel with hyperthreading seems to allieviate some of the latency caused by the high interrupt rate; however, I did have it hang once today. Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-PRERELEASE #0: Wed Nov 8 16:01:29 PST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CSERV65.SMP ACPI APIC Table: DELL WS 670 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf43 Stepping = 3 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=0x641dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,b14 AMD Features=0x2010NX,LM Logical CPUs per core: 2 real memory = 1072209920 (1022 MB) avail memory = 1035874304 (987 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 pnpbios: Bad PnP BIOS data checksum ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic2: Changing APIC ID to 10 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard lapic0: Forcing LINT1 to edge trigger kqemu version 0x00010300 kqemu: KQEMU installed, max_locked_mem=517120kB. kbd1 at kbdmux0 acpi0: DELL WS 670 on motherboard 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 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 0.1 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 em0: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0xdcc0-0xdcff mem 0xdfee-0xdfef irq 48 at device 14.0 on pci3 em0: Ethernet address: 00:13:72:78:b9:e3 pcib4: ACPI PCI-PCI bridge irq 16 at device 3.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0 pci5: ACPI PCI bus on pcib5 nvidia0: Quadro PCI-E Series mem 0xdd00-0xddff,0xc000-0xcfff,0xde00-0xdeff irq 16 at device 0.0 on pci5 nvidia0: [GIANT-LOCKED] uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xff80-0xff9f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xff60-0xff7f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xff20-0xff3f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xffa80800-0xffa80bff irq 23 at
Re: Dissapointing performance of ciss RAID 0+1 ?
Pete French wrote: I recently overhauled my RAID array - I now have 4 drives arranged as RAID 0+1, all being 15K 147gig Fujitsu's, and split across two buses, which are actively terminated to give U160 speeds (and I have verified this). The card is a 5304 (128M cache) in a PCI-X slot. This replaces a set of 6 7200 rpm drives as RAID 5 which were running at 40meg speeds due to non LVD termination. I would expect to see a large speed increase wouldn't I ? But it remains about the same - around 45 meg/sec for reading a large file (3 gig or so) and half that for copying said file. These are 'real world' tests in the sense that I us the drive for building large ISo images and copying them around - I really dont care what benchmarks say, it's the speed of these two operatiosn that I want to make fats. I've tried all the possible stripe sizes (128k gives the best performance) but still I only get the above speeds. Just one of the 15k drives on it's own performs better than this! I would expect the RAID-0 to give me at least some speedup, or in the worst case be the same, surely ? Booting up Windowws and running some tests gives me far better performance however, so I am wondering if there is some driver issue here. Has anyone else seen the same kind of results ? I am running the latest stable for amd64 and the machine has twin opteron 242's with a gig of RAM each. surely it can do better than this ? You might be able to speed up the read by playing with the vfs.read_max sysctl (try 16 or 32). cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvidia0 em0 shared irq problem persists on dell precision 670
Russell Jackson wrote: [ ... ] pnpbios: Bad PnP BIOS data checksum Did you notice this? Try reflashing your motherboard to the latest available BIOS revision, doing a load defaults, and then clearing and reseting the ESCD. -- -Chuck ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvidia0 em0 shared irq problem persists on dell precision 670
Is the firewire controller something that you can disable? Can you selectively disable some of the USB controllers? Scott Russell Jackson wrote: I synced sources today and tested the em changes, and the problem has not gone away for me. nvidia0 and em0 are shown as shared with ioacpi disabled using a device hint. interrupt total rate irq1: atkbd0 60 0 irq6: fdc010 0 irq14: ata0 16 0 irq15: ata1 47 0 irq16: nvidia0+++1267513 2162 irq18: uhci2+ 52688 89 irq23: ehci0 1 0 irq48: em0106712182 cpu0: timer 1167964 1993 cpu1: timer 1165966 1989 Total3760977 6418 When disabling the ioapic, the rate falls to the 600s which is still a tad high no? I was running it with apic disabled as a work around, but I plan on buying another processor for this box soon. Running it with a SMP kernel with hyperthreading seems to allieviate some of the latency caused by the high interrupt rate; however, I did have it hang once today. Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.2-PRERELEASE #0: Wed Nov 8 16:01:29 PST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CSERV65.SMP ACPI APIC Table: DELL WS 670 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (2992.52-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf43 Stepping = 3 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=0x641dSSE3,RSVD2,MON,DS_CPL,CNTX-ID,CX16,b14 AMD Features=0x2010NX,LM Logical CPUs per core: 2 real memory = 1072209920 (1022 MB) avail memory = 1035874304 (987 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 pnpbios: Bad PnP BIOS data checksum ioapic0: Changing APIC ID to 8 ioapic1: Changing APIC ID to 9 ioapic2: Changing APIC ID to 10 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard ioapic2 Version 2.0 irqs 48-71 on motherboard lapic0: Forcing LINT1 to edge trigger kqemu version 0x00010300 kqemu: KQEMU installed, max_locked_mem=517120kB. kbd1 at kbdmux0 acpi0: DELL WS 670 on motherboard 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 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pci0: unknown at device 0.1 (no driver attached) pcib1: ACPI PCI-PCI bridge irq 16 at device 2.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 0.2 on pci1 pci3: ACPI PCI bus on pcib3 em0: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0xdcc0-0xdcff mem 0xdfee-0xdfef irq 48 at device 14.0 on pci3 em0: Ethernet address: 00:13:72:78:b9:e3 pcib4: ACPI PCI-PCI bridge irq 16 at device 3.0 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge irq 16 at device 4.0 on pci0 pci5: ACPI PCI bus on pcib5 nvidia0: Quadro PCI-E Series mem 0xdd00-0xddff,0xc000-0xcfff,0xde00-0xdeff irq 16 at device 0.0 on pci5 nvidia0: [GIANT-LOCKED] uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xff80-0xff9f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: Intel 82801EB (ICH5) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xff60-0xff7f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: Intel 82801EB (ICH5) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xff40-0xff5f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: Intel 82801EB (ICH5) USB controller USB-C on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xff20-0xff3f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: Intel 82801EB (ICH5) USB controller USB-D on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev
Re: nvidia0 em0 shared irq problem persists on dell precision 670
On Wed, Nov 08, 2006 at 09:23:45PM -0500, Chuck Swiger wrote: Russell Jackson wrote: [ ... ] pnpbios: Bad PnP BIOS data checksum Did you notice this? Try reflashing your motherboard to the latest available BIOS revision, doing a load defaults, and then clearing and reseting the ESCD. The box came from Dell with the latest revision already and there hasn't been a newer one released since. I vaguely remember bringing this up on the list shortly after the 6.1 release only to be told it was harmless. I guess I can try reflashing just to be sure. Thanks, -- Russell A. Jackson Network Analyst California State University, Bakersfield ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nvidia0 em0 shared irq problem persists on dell precision 670
On Wed, Nov 08, 2006 at 07:39:52PM -0700, Scott Long wrote: Is the firewire controller something that you can disable? Can you selectively disable some of the USB controllers? Scott I'll have to try that tomorrow at work. I did disable the em NIC in the BIOS setup, and (not surprisingly) the problem went away. -- Russell A. Jackson Network Analyst California State University, Bakersfield ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Proposed 6.2 em RELEASE patch
Without introduced this new patch, can I still use sysctl to maximise its performance like FAST_INTR? S On 11/9/06, Jack Vogel [EMAIL PROTECTED] wrote: This patch is an evolution of the last one I sent out. It has a couple of minor corrections, like a bad forward decl in the header. The last patch has had quite a bit of testing and all reports have been positive. The only complaint was from Gleb who says he needs to keep his beloved infinite for loop in the interrupt handler, well I have a better one for you Gleb, keep reading. I have also been doing some extreme stress testing using SmartBits, and discovered the driver as it stands is really not able to take extreme receive side pounding, Scott pointed out that this is why the FAST_INTR work was done :) There were some people that had stability issues with that work, but there were also many that did not. I actually merged the FAST code onto my last patch, and ran the SB stress and found it really was able to gracefully handle that load, way to go Scott :) I've pondered this situation, and this patch I'm including here today is the result. Here's what it does: If you drop it in place, compile it, and go... you will get the code that has been tested for a week, it uses the older style interrupts, it has the watchdog and other SMP fixes so its been proven. BUT, I've added the FAST_INTR changes back into the code, so if you go into your Makefile and add -DEM_FAST_INTR you will then get the taskqueue stuff. So, Gleb, rather than replace the infinite for loop that no one thinks is a good idea, you can just define FAST_INTR again, and you should be good to go. I see this as the best thing for the 6.2 RELEASE, it lets us keep moving forward, people that want max performance can define EM_FAST_INTR and help us wring out any problems, it also will mean that I will have our Intel test group start using this code. But for those that just want a stable driver the standard compile will still give them that. The patch I'm including is against BETA3. Let me know of your concerns or issues. Cheers, Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Proposed 6.2 em RELEASE patch
On 11/8/06, Sam Wun [EMAIL PROTECTED] wrote: Without introduced this new patch, can I still use sysctl to maximise its performance like FAST_INTR? S Not sure if I'm understanding you, but let me try. You cannot attain the same receive performance without the patch. When I use SmartBits and blast UDP packets at TWO fiber PCI-E NICS and set it to 70% utilization of the line it will just BURY the system, meaning that the shell on the console will appear wedged. Once you stop the test it recovers, but during it its totally consumed handling interrupts. Perhaps with careful tweaking of everything you can make things better, but if so that goes beyond my tuning knowledge. Just one NIC will be OK, and if I drop the utilization down to 45% its ok, but 50 and up and we go into the tank, as it were :) If you compile with EM_FAST_INTR then the system will continue to operate quite well with the same load. Now, this is one kind of load, and there is still other types that work just fine without FAST_INTR, and without the patch you can still use sysctl to adjust tuning parameters as your needs vary. BUT, I do not believe you can do as well as you can with FAST_INTR on, this is why I wanted to get this code back into the driver conditionally before RELEASE. Does that answer your question Sam? Regards, Jack On 11/9/06, Jack Vogel [EMAIL PROTECTED] wrote: This patch is an evolution of the last one I sent out. It has a couple of minor corrections, like a bad forward decl in the header. The last patch has had quite a bit of testing and all reports have been positive. The only complaint was from Gleb who says he needs to keep his beloved infinite for loop in the interrupt handler, well I have a better one for you Gleb, keep reading. I have also been doing some extreme stress testing using SmartBits, and discovered the driver as it stands is really not able to take extreme receive side pounding, Scott pointed out that this is why the FAST_INTR work was done :) There were some people that had stability issues with that work, but there were also many that did not. I actually merged the FAST code onto my last patch, and ran the SB stress and found it really was able to gracefully handle that load, way to go Scott :) I've pondered this situation, and this patch I'm including here today is the result. Here's what it does: If you drop it in place, compile it, and go... you will get the code that has been tested for a week, it uses the older style interrupts, it has the watchdog and other SMP fixes so its been proven. BUT, I've added the FAST_INTR changes back into the code, so if you go into your Makefile and add -DEM_FAST_INTR you will then get the taskqueue stuff. So, Gleb, rather than replace the infinite for loop that no one thinks is a good idea, you can just define FAST_INTR again, and you should be good to go. I see this as the best thing for the 6.2 RELEASE, it lets us keep moving forward, people that want max performance can define EM_FAST_INTR and help us wring out any problems, it also will mean that I will have our Intel test group start using this code. But for those that just want a stable driver the standard compile will still give them that. The patch I'm including is against BETA3. Let me know of your concerns or issues. Cheers, Jack ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Error applying libarchive.patch
I tried installing FreeBSD Security Advisory FreeBSD-SA-06:24.libarchive The patch failed. Am I doing something wrong? Is it not designed for my system? oz# uname -a FreeBSD oz.caah.org 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Thu Oct 12 07:40:47 EST 2006 root@:/usr/obj/usr/src/sys/GENERIC i386 oz# patch /home/sbiber/libarchive.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -- |Index: lib/libarchive/archive_read_support_compression_none.c |=== |RCS file: /home/ncvs/src/lib/libarchive/archive_read_support_compression_none.c,v |retrieving revision 1.8 |diff -u -I__FBSDID -r1.8 archive_read_support_compression_none.c |--- lib/libarchive/archive_read_support_compression_none.c 29 Aug 2006 04:59:25 - 1.8 |+++ lib/libarchive/archive_read_support_compression_none.c 2 Nov 2006 05:17:28 - -- Patching file lib/libarchive/archive_read_support_compression_none.c using Plan A... Hunk #1 failed at 257. Hunk #2 failed at 289. Hunk #3 failed at 307. Hunk #4 failed at 320. 4 out of 4 hunks failed--saving rejects to lib/libarchive/archive_read_support_compression_none.c.rej done -- Simon. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Error applying libarchive.patch
On Thu, Nov 09, 2006 at 05:49:20PM +1100, Simon Biber wrote: I tried installing FreeBSD Security Advisory FreeBSD-SA-06:24.libarchive The patch failed. Am I doing something wrong? Is it not designed for my system? I had the same problem as Simon on 6.1 boxes. |+++ lib/libarchive/archive_read_support_compression_none.c 2 Nov 2006 05:17:28 - -- Patching file lib/libarchive/archive_read_support_compression_none.c using Plan A... Hunk #1 failed at 257. Hunk #2 failed at 289. Hunk #3 failed at 307. Hunk #4 failed at 320. 4 out of 4 hunks failed--saving rejects to lib/libarchive/archive_read_support_compression_none.c.rej done It worked on 2 boxes running 6.2-PRERELEASE -- Scott Robbins PGP keyID EB3467D6 ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 ) gpg --keyserver pgp.mit.edu --recv-keys EB3467D6 Buffy: It was exactly you, Will. Every detail. Except for your not being a dominatrix... as far as we know. Willow: Oh, right, me and Oz play Mistress of Pain every night. Xander: Did anyone else just go to a scary visual place? Buffy: Oh, yeah. Giles: (raises glasses) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Error applying libarchive.patch
On Thu, 09 Nov 2006 17:49:20 +1100 Simon Biber [EMAIL PROTECTED] wrote: I tried installing FreeBSD Security Advisory FreeBSD-SA-06:24.libarchive The patch failed. Am I doing something wrong? Is it not designed for my system? From the SA: Affects:FreeBSD 6-STABLE after 2006-09-05 05:23:51 UTC This SA does not affect 6.1-RELEASE, the patch does not apply. oz# uname -a FreeBSD oz.caah.org 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Thu Oct 12 07:40:47 EST 2006 root@:/usr/obj/usr/src/sys/GENERIC i386 The best way to get all SAs that affect you is to either use freebsd-update or follow the RELENG_6_1 branch via csup. Joerg -- | /\ ASCII ribbon | GnuPG Key ID | e86d b753 3deb e749 6c3a | | \ / campaign against |0xbbcaad24 | 5706 1f7d 6cfd bbca ad24 | | XHTML in email |.the next sentence is true. | | / \ and news | .the previous sentence was a lie.| signature.asc Description: PGP signature
Re: Error applying libarchive.patch
On 11/9/06, Scott Robbins [EMAIL PROTECTED] wrote: On Thu, Nov 09, 2006 at 05:49:20PM +1100, Simon Biber wrote: I tried installing FreeBSD Security Advisory FreeBSD-SA-06:24.libarchive The patch failed. Am I doing something wrong? Is it not designed for my system? I had the same problem as Simon on 6.1 boxes. . . . It worked on 2 boxes running 6.2-PRERELEASE To quote http://security.freebsd.org/advisories/FreeBSD-SA-06:24.libarchive.asc Affects:FreeBSD 6-STABLE after 2006-09-05 05:23:51 UTC -- -- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Error applying libarchive.patch
On Thu, 9 Nov 2006, Simon Biber wrote: I tried installing FreeBSD Security Advisory FreeBSD-SA-06:24.libarchive The patch failed. Am I doing something wrong? Is it not designed for my system? Correct. http://security.freebsd.org/advisories/FreeBSD-SA-06:24.libarchive.asc notes that this only affects systems built from the 6-STABLE branch after 2006-09-05 05:23:51 UTC. oz# uname -a FreeBSD oz.caah.org 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Thu Oct 12 07:40:47 EST 2006 root@:/usr/obj/usr/src/sys/GENERIC i386 You're running 6.1-RELEASE, which does not fit this criteria. Your system is not vulnerable to the exploit. David Adam [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Error applying libarchive.patch
On 11/9/06, Simon Biber [EMAIL PROTECTED] wrote: I tried installing FreeBSD Security Advisory FreeBSD-SA-06:24.libarchive The patch failed. Am I doing something wrong? Is it not designed for my system? oz# uname -a FreeBSD oz.caah.org 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Thu Oct 12 07:40:47 EST 2006 root@:/usr/obj/usr/src/sys/GENERIC i386 According to Simon, this security advisory doesn't affect 6.1-RELEASE. On 11/8/06, Simon L. Nielsen [EMAIL PROTECTED] wrote: On 2006.11.08 10:36:02 -0500, Josh Paetzel wrote: Maybe this is an obvious question, but libarchive has been in the system since 5.3, but this issue only affects RELENG_6? So anyone tracking RELENG_6_1 isn't affected? Correct, the bug was introduced after 6.1 was branched. -- Simon L. Nielsen ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to [EMAIL PROTECTED] Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
