repeatable crash on RELENG7
While trying to speed up nanobsd builds, I mounted /usr/obj on a ramdisk and found my box crashing. Thinking it might be hardware, I tried a separate machine, but with the same results. I have 4G of ram (i386). Am I just running out of some kernel memory ? If so, is there anything I can adjust to prevent this, yet still use mfs in this way ? mdconfig -a -t malloc -s 1800M newfs /dev/md0 mount /dev/md0 /usr/obj/ time make -j4 buildworld /var/log/build.out in the middle of the buildworld on the serial console (after adding witness etc) g_vfs_done():md0[WRITE(offset=1752924160, length=6144)]error = 28 g_vfs_done():md0[WRITE(offset=1752952832, length=4096)]error = 28 g_vfs_done():md0[WRITE(offset=1753006080, length=14336)]error = 28 g_vfs_done():md0[WRITE(offset=1753020416, length=2048)]error = 28 g_vfs_done():md0[WRITE(offset=1753202688, length=81920)]error = 28 g_vfs_done():md0[WRITE(offset=1191755776, length=131072)]error = 28 g_vfs_done():md0[WRITE(offset=1191886848, length=131072)]error = 28 g_vfs_done():md0[WRITE(offset=1192017920, length=131072)]error = 28 panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated cpuid = 1 KDB: enter: panic [thread pid 15139 tid 100160 ] Stopped at kdb_enter_why+0x3a: movl$0,kdb_why db db bt Tracing pid 15139 tid 100160 td 0xc7a85af0 kdb_enter_why(3231417278,3231417278,3231555983,3911968708,1,...) at kdb_enter_why+58 panic(3231555983,4096,335544320,3231555977,2000,...) at panic+310 kmem_malloc(3242659980,4096,258,3911968860,3230390816,...) at kmem_malloc+640 page_alloc(3242544416,4096,3911968847,258,3242544416,...) at page_alloc+39 slab_zalloc(3228209884,3242551688,8,3231552877,1878,...) at slab_zalloc+192 uma_zone_slab(3242551688,0,3231552877,1878,4,...) at uma_zone_slab+324 uma_zalloc_arg(3242544416,0,258,3349699312,3911969228,...) at uma_zalloc_arg+1395 ffs_vget(761124,922776,2,3911969228,3911969240,...) at ffs_vget+168 ufs_lookup(3911969308,3343471972,3911969744,3343471972,3911969340,...) at ufs_lookup+2555 VOP_CACHEDLOOKUP_APV(3232100544,3911969308,3911969744,3911969724,3335025920,...) at VOP_CACHEDLOOKUP_APV+165 vfs_cache_lookup(3911969440,3911969440,3911969704,3343471972,2,...) at vfs_cache_lookup+208 VOP_LOOKUP_APV(3232100544,3911969440,3349699312,3231462256,681,...) at VOP_LOOKUP_APV+165 lookup(3911969704,3231462256,198,191,3343637548,...) at lookup+1422 namei(3911969704,3911969608,96,0,3349699312,...) at namei+843 kern_stat(3349699312,672272928,0,3911969816,93,...) at kern_stat+61 stat(3349699312,3911970044,8,3231440732,3231973120,...) at stat+47 syscall(3911970104) at syscall+691 Xint0x80_syscall() at Xint0x80_syscall+32 --- syscall (188, FreeBSD ELF32, stat), eip = 134726611, esp = 3217021740, ebp = 3217021864 --- db Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.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 [EMAIL PROTECTED]
Re: repeatable crash on RELENG7
On Tue, Dec 02, 2008 at 08:19:17AM -0500, Mike Tancsa wrote: While trying to speed up nanobsd builds, I mounted /usr/obj on a ramdisk and found my box crashing. Thinking it might be hardware, I tried a separate machine, but with the same results. I have 4G of ram (i386). Am I just running out of some kernel memory ? If so, is there anything I can adjust to prevent this, yet still use mfs in this way ? mdconfig -a -t malloc -s 1800M You cannot have ~ 2Gb of kernel memory allocated for md, at least not on i386. newfs /dev/md0 mount /dev/md0 /usr/obj/ time make -j4 buildworld /var/log/build.out in the middle of the buildworld on the serial console (after adding witness etc) g_vfs_done():md0[WRITE(offset=1752924160, length=6144)]error = 28 g_vfs_done():md0[WRITE(offset=1752952832, length=4096)]error = 28 g_vfs_done():md0[WRITE(offset=1753006080, length=14336)]error = 28 g_vfs_done():md0[WRITE(offset=1753020416, length=2048)]error = 28 g_vfs_done():md0[WRITE(offset=1753202688, length=81920)]error = 28 g_vfs_done():md0[WRITE(offset=1191755776, length=131072)]error = 28 g_vfs_done():md0[WRITE(offset=1191886848, length=131072)]error = 28 g_vfs_done():md0[WRITE(offset=1192017920, length=131072)]error = 28 panic: kmem_malloc(4096): kmem_map too small: 335544320 total allocated cpuid = 1 KDB: enter: panic [thread pid 15139 tid 100160 ] Stopped at kdb_enter_why+0x3a: movl$0,kdb_why db db bt Tracing pid 15139 tid 100160 td 0xc7a85af0 kdb_enter_why(3231417278,3231417278,3231555983,3911968708,1,...) at kdb_enter_why+58 panic(3231555983,4096,335544320,3231555977,2000,...) at panic+310 kmem_malloc(3242659980,4096,258,3911968860,3230390816,...) at kmem_malloc+640 page_alloc(3242544416,4096,3911968847,258,3242544416,...) at page_alloc+39 slab_zalloc(3228209884,3242551688,8,3231552877,1878,...) at slab_zalloc+192 uma_zone_slab(3242551688,0,3231552877,1878,4,...) at uma_zone_slab+324 uma_zalloc_arg(3242544416,0,258,3349699312,3911969228,...) at uma_zalloc_arg+1395 ffs_vget(761124,922776,2,3911969228,3911969240,...) at ffs_vget+168 ufs_lookup(3911969308,3343471972,3911969744,3343471972,3911969340,...) at ufs_lookup+2555 VOP_CACHEDLOOKUP_APV(3232100544,3911969308,3911969744,3911969724,3335025920,...) at VOP_CACHEDLOOKUP_APV+165 vfs_cache_lookup(3911969440,3911969440,3911969704,3343471972,2,...) at vfs_cache_lookup+208 VOP_LOOKUP_APV(3232100544,3911969440,3349699312,3231462256,681,...) at VOP_LOOKUP_APV+165 lookup(3911969704,3231462256,198,191,3343637548,...) at lookup+1422 namei(3911969704,3911969608,96,0,3349699312,...) at namei+843 kern_stat(3349699312,672272928,0,3911969816,93,...) at kern_stat+61 stat(3349699312,3911970044,8,3231440732,3231973120,...) at stat+47 syscall(3911970104) at syscall+691 Xint0x80_syscall() at Xint0x80_syscall+32 --- syscall (188, FreeBSD ELF32, stat), eip = 134726611, esp = 3217021740, ebp = 3217021864 --- db Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.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 [EMAIL PROTECTED] pgpgil9ReIlXe.pgp Description: PGP signature
Re: 7.1-PRERELEASE: arcmsr write performance problem
On Dec 1, 2008, at 11:45 PM, Jan Mikkelsen wrote: Replying to my own post ... I have done a test on the same machine comparing 6.3-p1 to 7.1- PRE. The performance is the expected ~6MB/s (because of the lack of cache) on 6.3-p1, so the BIOS change doesn't seem to be at fault. This seems to be a regression somewhere between 6.3 to 7.1. The Areca driver is the same in 6.3 and 7.1, so the problem seems to be elsewhere. I think this is more than just a performance problem. The observations with gstat showing extremely high ms/w values (I have seen them as high as 22000) makes it look like IO completion interrupts are being lost. Any suggestions on where to look next? Are there obvious candidates? ATA maximum block transfer has dropped from 128k to 64k in 7.x. Am not sure where the handle is to tweak it back up but has slowed peak thruput on my Dell PE400SC. Can watch with systat -v Worse, I have a stripped array of 2 drives that won't transfer more than 43k at a chunk because apparently the stripe metadata didn't align nicely on 64k multiples. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: repeatable crash on RELENG7
At 08:38 AM 12/2/2008, Kostik Belousov wrote: mdconfig -a -t malloc -s 1800M You cannot have ~ 2Gb of kernel memory allocated for md, at least not on i386. Thanks, how do I find out what the limit is on a machine ? Is it vm.kvm_size ? ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: repeatable crash on RELENG7
On Tue, Dec 02, 2008 at 09:12:54AM -0500, Mike Tancsa wrote: At 08:38 AM 12/2/2008, Kostik Belousov wrote: mdconfig -a -t malloc -s 1800M You cannot have ~ 2Gb of kernel memory allocated for md, at least not on i386. Thanks, how do I find out what the limit is on a machine ? Is it vm.kvm_size ? It is much less, and highly depends on your load, since KVA is used for all kind of allocations made by kernel. I think either md(4) or mdconfig(8) have a warning about malloc backing for md. pgpi3n88NWYUU.pgp Description: PGP signature
ipfw2.c,v 1.76.2.17
Hi. Since this revision (appeared in 6.3) I think ipfw violates POLA. I mean ipfw table N list shows values of table in Internet '.' notation. A friend of mine was surprised to found Internet representation of this optional 32-bit unsigned value. For example security/bruteblock stores unix timestamps here and AFAICS there is no possibility to come back to the previous output format (other than reverting this revision). -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
btx/pxeboot problem
latest pxeboot (7.1): mother-boardNIC/LOM CPU - --- --- Intel SWV25 em xeonworks fine SUN X2200bgeamd works fine DELL PE 2950 bcexeonfailes 95% of the times hangs or goes into btx dump regs. mode :-) Intel SE7320VP21 mskxeonfailes 50% of the times - hangs pxeboot with btx.S 1.45 2008/02/27 23:35:39, works fine. so it seems that changes since 1.45 have fixed it for some, but it brakes for others :-). I can help testing, but btx is way out of my league. danny ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ioctl DIOCSMBR: Inappropriate ioctl for device
On Tue, Nov 25, 2008 at 12:40 PM, Rajkumar S [EMAIL PROTECTED] wrote: boot0cfg: /dev/ad2: Class not found boot0cfg: /dev/ad2: ioctl DIOCSMBR: Inappropriate ioctl for device I found the reason for this error: I need to set kern.geom.debugflags=16 before executing this command. raj ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RELENG_7_1: bce driver change generating too much interrupts ?
Since last upgrade, I see much more CPU time eated by interrupts (at least 10% cpu in top) (see http://dgeo.perso.ec-marseille.fr/cpu-week.png) The server behave correctly (Or seems to…), and high interrupt number seems to come from bce cards (source: systat -vmstat) I just upgraded from RELENG_7 Mon Sep 8 12:33:06 CEST 2008 to RELENG_7_1 Sat Nov 29 16:20:35 CET 2008 We have the same machine (dell PE 1950) which have not been upgraded (production use - the two machine are carp(4)-redundant) I don't know if it is related to SVN rev 184826 on 2008-11-10 22:40:16Z by delphij patch to sys/dev/bce/if_bce.c If I can help debugging something… These are production machines, but I may test patches or ? on the faulty system. Some clues: Under the very same load (carp interfaces down on other machine), vmstat shows: for newer system: procs memory page disk faults cpu r b w avmfre flt re pi pofr sr mf0 in sy cs us sy id 0 1 1 4806M 460M 649 0 0 0 582 2 0 21770 1270 13653 1 15 85 and for older: procs memory page disk faults cpu r b w avmfre flt re pi pofr sr mf0 in sy cs us sy id 0 1 0 3694M 414M 236 0 0 0 199 17 0 286 317 386 1 1 97 bce-related part of dmesg for the newer system: bce0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) mem 0xf400-0xf5ff irq 16 at device 0.0 on pci9 miibus0: MII bus on bce0 bce0: Ethernet address: 00:15:c5:f1:56:f4 bce0: [ITHREAD] bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x02090105); Flags( SPLT MFW MSI ) bce1: Broadcom NetXtreme II BCM5708 1000Base-T (B2) mem 0xf800-0xf9ff irq 16 at device 0.0 on pci5 miibus1: MII bus on bce1 bce1: Ethernet address: 00:15:c5:f1:56:f2 bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x02090105); Flags( SPLT MFW MSI ) And on the older system: bce0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) mem 0xf400-0xf5ff irq 16 at device 0.0 on pci9 miibus0: MII bus on bce0 bce0: Ethernet address: 00:15:c5:f1:6a:47 bce0: [ITHREAD] bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x02090105); Flags( MFW MSI ) bce1: Broadcom NetXtreme II BCM5708 1000Base-T (B2) mem 0xf800-0xf9ff irq 16 at device 0.0 on pci5 miibus1: MII bus on bce1 bce1: Ethernet address: 00:15:c5:f1:6a:45 bce1: [ITHREAD] bce1: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x02090105); Flags( MFW MSI ) -- Geoffroy Desvernay Ecole Centrale de Marseille signature.asc Description: OpenPGP digital signature
Re: ipfw2.c,v 1.76.2.17
On Tue, Dec 02, 2008 at 06:02:16PM +0300, pluknet wrote: Since this revision (appeared in 6.3) I think ipfw violates POLA. I mean ipfw table N list shows values of table in Internet '.' notation. A friend of mine was surprised to found Internet representation of this optional 32-bit unsigned value. For example security/bruteblock stores unix timestamps here and AFAICS there is no possibility to come back to the previous output format (other than reverting this revision). That was fixed 8 months ago. Just upgrade to 6.4. Eugene Grosbein ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient doing DISCOVER with bad IP checksum - bge
On Mon, Dec 01, 2008 at 12:27:58AM -0800, Jonathan Feally wrote: Sorry for the cross-post, but this could be either lists problem. I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is running ISC DHCPD 3.0.x from recent ports, and the other dhclient from make world. The server is refusing to answer the DISCOVER request, as it thinks the IP checksum is wrong, which tcpdump also confirms. Other DHCP clients are working fine on this network, so I do not believe it to be the network, server or dhcpd. Server is running a 2 Port Intel card - em driver. Client is a Dell PE1750 with 2 onboard NIC's - bge driver. I have tried turning off both RXCSUM and TXCSUM on both the client and server machines with no luck. I also tried the second NIC on the server with the same result. This setup was working just a couple of weeks ago, and the only thing that has changed is updating the src for a make world. PXE booting this server does result in an IP being issued, so it is pointing towards something new/changed in 7-STABLE. I have attached a 3 packet dump of the DISCOVER requests. Can anybody shed some light on this for me? Where are you running tcpdump? If on the host with the bge0 device, the checksums are probably useless due to checksum offloading. They should be valid on the server end of things. You might try disabling checksum offloading on the nic and see if that changes the results. It's possible the change to bpf.c to send packets through a socket when reassociateing isn't working correctly in that case. You might try backing out this change and seeing if the problem goes away (this will cause problems on some networks). http://svn.freebsd.org/viewvc/base/stable/7/sbin/dhclient/bpf.c?revision=178675view=markup -- Brooks pgpFJmm7bBQZt.pgp Description: PGP signature
Re: btx/pxeboot problem
On Tue, Dec 02, 2008 at 01:48:17PM +0200, Danny Braniss wrote: latest pxeboot (7.1): mother-boardNIC/LOM CPU - --- --- Intel SWV25 em xeonworks fine SUN X2200bgeamd works fine DELL PE 2950 bcexeonfailes 95% of the times hangs or goes into btx dump regs. mode :-) Intel SE7320VP21 mskxeonfailes 50% of the times - hangs pxeboot with btx.S 1.45 2008/02/27 23:35:39, works fine. so it seems that changes since 1.45 have fixed it for some, but it brakes for others :-). I can help testing, but btx is way out of my league. interesting, so this is the same problem i was seeing on the Asus/amd machines here... the commit log for 1.47 mention interrupt issues which are consistent with the random hangs or errors that I see while booting over the network. http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/btx/btx/btx.S.diff?r1=1.46;r2=1.47 I wonder if the hangs are related to interrupts coming in at the wrong time. I also wonder whether the same symptoms might also affect the standard loader and not just pxeloader, in which case the problem would be slightly more serious. I am afraid my ability to debug the problem isn't going much beyond this... cheers luigi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw2.c,v 1.76.2.17
2008/12/2 Andrey V. Elsukov [EMAIL PROTECTED]: 02.12.08, 18:02, pluknet [EMAIL PROTECTED]: Since this revision (appeared in 6.3) I think ipfw violates POLA. I mean ipfw table N list shows values of table in Internet '.' notation. A friend of mine was surprised to found Internet representation of this optional 32-bit unsigned value. For example security/bruteblock stores unix timestamps here and AFAICS there is no possibility to come back to the previous output format (other than reverting this revision). It fixed in 1.76.2.21. -- WBR, Andrey V. Elsukov Andrey, Eugene. Thank you all! And please forgive me my laziness, not allowed to check up last revisions of ipfw2.c. -- wbr, pluknet ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7_1: bce driver change generating too much interrupts ?
On Tue, December 2, 2008 4:57 am, Geoffroy Desvernay wrote: Since last upgrade, I see much more CPU time eated by interrupts (at least 10% cpu in top) (see http://dgeo.perso.ec-marseille.fr/cpu-week.png) I am also seeing the same behavior on a farm of Dell servers. [EMAIL PROTECTED]:~# vmstat -i interrupt total rate irq1: atkbd0 18 0 irq14: ata0 176 0 irq16: mfi067924 1 irq20: uhci1 uhci3 1 0 irq21: uhci0 uhci+ 5 0 cpu0: timer132244117 1997 irq257: bce1 3366039632 50853 cpu1: timer132244053 1997 cpu2: timer132244053 1997 cpu3: timer132244053 1997 Total 3895084032 58846 Not only this, but i have also noticed that there are a number of errors reported by netstat now. before the drivers update, i would not get these errors. [EMAIL PROTECTED]:~# netstat -i NameMtu Network Address Ipkts IerrsOpkts Oerrs Coll 0 bce1 1500 Link#2 00:1e:c9:b5:cc:b6 1848959 2197 1357031 0 0 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw2.c,v 1.76.2.17
02.12.08, 18:02, pluknet [EMAIL PROTECTED]: Since this revision (appeared in 6.3) I think ipfw violates POLA. I mean ipfw table N list shows values of table in Internet '.' notation. A friend of mine was surprised to found Internet representation of this optional 32-bit unsigned value. For example security/bruteblock stores unix timestamps here and AFAICS there is no possibility to come back to the previous output format (other than reverting this revision). It fixed in 1.76.2.21. -- WBR, Andrey V. Elsukov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: repeatable crash on RELENG7
At 09:20 AM 12/2/2008, Kostik Belousov wrote: On Tue, Dec 02, 2008 at 09:12:54AM -0500, Mike Tancsa wrote: At 08:38 AM 12/2/2008, Kostik Belousov wrote: mdconfig -a -t malloc -s 1800M You cannot have ~ 2Gb of kernel memory allocated for md, at least not on i386. Thanks, how do I find out what the limit is on a machine ? Is it vm.kvm_size ? It is much less, and highly depends on your load, since KVA is used for all kind of allocations made by kernel. I think either md(4) or mdconfig(8) have a warning about malloc backing for md. Thanks! A warning might be helpful to prevent such foot shooting :) ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??)
Can someone please confirm or rule out my issue with dhclient sending bad IP checksum packets. It would really suck if 7.1 was released with a broken DHCP client. I've had many problems lately, but none involved checksum nor the dhcpd (btw, I assume that you are seeing bad checksum on the receiving server) could you add a nic to your PE1750? danny Jonathan Feally wrote: Sorry for the cross-post, but this could be either lists problem. I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is running ISC DHCPD 3.0.x from recent ports, and the other dhclient from make world. The server is refusing to answer the DISCOVER request, as it thinks the IP checksum is wrong, which tcpdump also confirms. Other DHCP clients are working fine on this network, so I do not believe it to be the network, server or dhcpd. Server is running a 2 Port Intel card - em driver. Client is a Dell PE1750 with 2 onboard NIC's - bge driver. I have tried turning off both RXCSUM and TXCSUM on both the client and server machines with no luck. I also tried the second NIC on the server with the same result. This setup was working just a couple of weeks ago, and the only thing that has changed is updating the src for a make world. PXE booting this server does result in an IP being issued, so it is pointing towards something new/changed in 7-STABLE. I have attached a 3 packet dump of the DISCOVER requests. Can anybody shed some light on this for me? Thanks, -Jon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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]
synproxy state does not work on FreeBSD 7.1-PRERELEASE
crossmessage http://lists.freebsd.org/pipermail/freebsd-pf/2008-November/004881.html hello I tried to rule with `synproxy state` uname FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #0: Wed Oct 29 12:47:36 UTC 2008 (amd64 i386 arch) the `synproxy state` is not working (web-browser does not receive the html-page) uname FreeBSD 7.0-RELEASE GENERIC (amd64 i386 arch) the `synproxy state` is working # cat /etc/pf.conf pass on em0 proto tcp from any to 192.168.0.1 port 80 synproxy state to all, please check and confirm or deny /Vladimir Ermakov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: repeatable crash on RELENG7
On Tue, Dec 2, 2008 at 5:12 PM, Mike Tancsa [EMAIL PROTECTED] wrote: At 08:38 AM 12/2/2008, Kostik Belousov wrote: mdconfig -a -t malloc -s 1800M You cannot have ~ 2Gb of kernel memory allocated for md, at least not on i386. Thanks, how do I find out what the limit is on a machine ? Is it vm.kvm_size ? ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] Try tune both vm.kmem_size and vm.kmem_size_max via /boot/loader.conf. They are equal to 330M by default. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: synproxy state does not work on FreeBSD 7.1-PRERELEASE
Jesper Wallin wrote: think this is because you also do filtering on the loopback interface and therefore block the initial handshake. Try with set skip on lo0. :-) Regards, Jesper Thank you, but I did not use blocking rules. /Vladimir Ermakov ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??)
I will try another em card in that server to confirm/rule out the nic driver. I am seeing the same checksum number on both the source machine, the dhcp server machine, and a 3rd windows xp machine sniffing the traffic with etherreal/wireshark. The windows xp box is running an intel nic as well, and those 0.0.0.0.67 - 255.255.255.255.68 packets as seen by the server do have the correct checksum. After the nic test, if no change from one driver to the other, then I'll try to un-patch the bpf.c change. At this point it is acting like the checksum offloading (which I did disable on both the client and server) just isn't working. Will let you know. -Jon Danny Braniss wrote: Can someone please confirm or rule out my issue with dhclient sending bad IP checksum packets. It would really suck if 7.1 was released with a broken DHCP client. I've had many problems lately, but none involved checksum nor the dhcpd (btw, I assume that you are seeing bad checksum on the receiving server) could you add a nic to your PE1750? danny Jonathan Feally wrote: Sorry for the cross-post, but this could be either lists problem. I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is running ISC DHCPD 3.0.x from recent ports, and the other dhclient from make world. The server is refusing to answer the DISCOVER request, as it thinks the IP checksum is wrong, which tcpdump also confirms. Other DHCP clients are working fine on this network, so I do not believe it to be the network, server or dhcpd. Server is running a 2 Port Intel card - em driver. Client is a Dell PE1750 with 2 onboard NIC's - bge driver. I have tried turning off both RXCSUM and TXCSUM on both the client and server machines with no luck. I also tried the second NIC on the server with the same result. This setup was working just a couple of weeks ago, and the only thing that has changed is updating the src for a make world. PXE booting this server does result in an IP being issued, so it is pointing towards something new/changed in 7-STABLE. I have attached a 3 packet dump of the DISCOVER requests. Can anybody shed some light on this for me? Thanks, -Jon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ 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] -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7_1: bce driver change generating too much interrupts ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can anyone try reverting the changeset itself? There are two recent changesets: http://www.delphij.net/bce-185161.diff.bz2 http://www.delphij.net/bce-184826.diff.bz2 You can revert the change by doing this: cd /usr/src fetch http://www.delphij.net/bce-185161.diff.bz2 fetch http://www.delphij.net/bce-184826.diff.bz2 bzcat bce-185161.diff.bz2 | patch -R bzcat bce-184826.diff.bz2 | patch -R I'll check what's happening ASAP. Cheers, - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk1e88ACgkQi+vbBBjt66AsYACfXPwMnWtUsCeae/pBDOIav1Hd JN8AoL5cm8ZHYY0dKutRljtxRsiVYco0 =v1VF -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7_1: bce driver change generating too much interrupts ?
On Tue, December 2, 2008 1:17 pm, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Can anyone try reverting the changeset itself? There are two recent changesets: http://www.delphij.net/bce-185161.diff.bz2 http://www.delphij.net/bce-184826.diff.bz2 Thanks for the info, the exact card that i use is the following, it is shipped with Dell servers. --- [EMAIL PROTECTED]:3:0:0:class=0x02 card=0x01b31028 chip=0x164c14e4 rev=0x12 hdr=0x00 vendor = 'Broadcom Corporation' device = '5708C Broadcom NetXtreme II Gigabit Ethernet Adapter' class = network subclass = ethernet --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??)
Jonathan Feally wrote: I will try another em card in that server to confirm/rule out the nic driver. I am seeing the same checksum number on both the source machine, the dhcp server machine, and a 3rd windows xp machine sniffing the traffic with etherreal/wireshark. The windows xp box is running an intel nic as well, and those 0.0.0.0.67 - 255.255.255.255.68 packets as seen by the server do have the correct checksum. After the nic test, if no change from one driver to the other, then I'll try to un-patch the bpf.c change. At this point it is acting like the checksum offloading (which I did disable on both the client and server) just isn't working. Will let you know. -Jon Danny Braniss wrote: Tried a add-in em0 card - intel pro/1000 XT server card - 82544E chip - no change. also tried with ifconfig em0 -rxcsum ifconfig em0 -txcsum dhclient em0 No change. Packets still received with bad IP checksum. Went back to bge0 now and reversed rev 178675 back to 172506 care of patch via http://svn.freebsd.org/viewvc/base/stable/7/sbin/dhclient/bpf.c?r1=172506r2=178675view=patch Also no change. So this change to dhclient doesn't seem to be the issue. From looking at http://svn.freebsd.org/viewvc/base/stable/7/sbin/dhclient/ this patch I took out is 7 months old, and I had this system running on 7-STABLE just fine about as of about 2-3 weeks ago. So it must have been something else in the sys/net or sys/netinet. I do seem some changes that are 3 weeks old, 4 weeks, and 6 days for these directories on files that would effect the packet assembly. Authors are julian, rwatson, and bz. I'm going to look through these recent changes to try to find some that has to do with the checksum process. -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7_1: bce driver change generating too much interrupts ?
Xin LI a écrit : Can anyone try reverting the changeset itself? There are two recent changesets: http://www.delphij.net/bce-185161.diff.bz2 http://www.delphij.net/bce-184826.diff.bz2 You can revert the change by doing this: cd /usr/src fetch http://www.delphij.net/bce-185161.diff.bz2 fetch http://www.delphij.net/bce-184826.diff.bz2 bzcat bce-185161.diff.bz2 | patch -R bzcat bce-184826.diff.bz2 | patch -R I'll check what's happening ASAP. Done: I'd say it seems to be related... Before applying your patches: # vmstat -i interrupt total rate irq1: atkbd0 18 0 irq14: ata0 58 0 irq20: uhci1 96 0 irq21: uhci0 uhci+ 5 0 irq78: mfi0 539747 3 cpu0: timer350029937 1999 irq256: bce0 6757905080 38611 irq259: bce1 8296789513 47403 cpu1: timer350029945 1999 cpu2: timer350030010 1999 cpu3: timer350030025 1999 Total16455354434 94018 After patch, make buildkernel make reinstallkernel and reboot interrupt total rate irq1: atkbd0 18 0 irq14: ata0 58 0 irq20: uhci1 2 0 irq21: uhci0 uhci+ 5 0 irq78: mfi0 3947 24 cpu0: timer 320361 1989 irq256: bce06658 41 irq259: bce11428 8 cpu1: timer 320320 1989 cpu2: timer 320380 1989 cpu3: timer 320507 1990 Total1293684 8035 -- geoffroy desvernay signature.asc Description: OpenPGP digital signature
Freebsd 7 STABLE 200807 amd64 - Realtek 8168 not working
I have an Asus P5Q-WS running FreeBSD 7 and the onboard Realtek NIC's are not being detected. No Kernel modifications as this is a fresh install. pciconf -lv : [EMAIL PROTECTED]:3:0:0: class=0x02 card=0x82c61043 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet [EMAIL PROTECTED]:2:0:0: class=0x02 card=0x82c61043 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet /var/log/messages: pci3: ACPI PCI bus on pcib6 Dec 2 17:37:21 nas kernel: re0: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xc800-0xc8ff mem 0xfe5ff000-0xfe5f,0xfdef -0xfdef irq 16 at device 0.0 on pci3 Dec 2 17:37:21 nas kernel: re0: Unknown H/W revision: 3c40 Dec 2 17:37:21 nas kernel: device_attach: re0 attach returned 6 Dec 2 17:37:21 nas kernel: pcib7: ACPI PCI-PCI bridge irq 18 at device 28.5 on pci0 Dec 2 17:37:21 nas kernel: pci2: ACPI PCI bus on pcib7 Dec 2 17:37:21 nas kernel: re1: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xb800-0xb8ff mem 0xfe4ff000-0xfe4f,0xfddf -0xfddf irq 17 at device 0.0 on pci2 Dec 2 17:37:21 nas kernel: re1: Unknown H/W revision: 3c40 Dec 2 17:37:21 nas kernel: device_attach: re1 attach returned 6 Is anymore info need to generate a patch? let me know. -- Peter Sprokkelenburg mailto:[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: RELENG_7_1: bce driver change generating too much interrupts ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Here is a patch that adjusts parameters of the interrupt handler, which
reduces interrupts. These parameters are obtained from DragonFly, FYI.
Note that this does not restore previous behavior, say, few interrupt if
no traffic. I'm still looking into the real cause.
geoffroy desvernay wrote:
Xin LI a écrit :
Can anyone try reverting the changeset itself? There are two recent
changesets:
http://www.delphij.net/bce-185161.diff.bz2
http://www.delphij.net/bce-184826.diff.bz2
You can revert the change by doing this:
cd /usr/src
fetch http://www.delphij.net/bce-185161.diff.bz2
fetch http://www.delphij.net/bce-184826.diff.bz2
bzcat bce-185161.diff.bz2 | patch -R
bzcat bce-184826.diff.bz2 | patch -R
I'll check what's happening ASAP.
Done:
I'd say it seems to be related...
Before applying your patches:
# vmstat -i
interrupt total rate
irq1: atkbd0 18 0
irq14: ata0 58 0
irq20: uhci1 96 0
irq21: uhci0 uhci+ 5 0
irq78: mfi0 539747 3
cpu0: timer350029937 1999
irq256: bce0 6757905080 38611
irq259: bce1 8296789513 47403
cpu1: timer350029945 1999
cpu2: timer350030010 1999
cpu3: timer350030025 1999
Total16455354434 94018
After patch, make buildkernel make reinstallkernel and reboot
interrupt total rate
irq1: atkbd0 18 0
irq14: ata0 58 0
irq20: uhci1 2 0
irq21: uhci0 uhci+ 5 0
irq78: mfi0 3947 24
cpu0: timer 320361 1989
irq256: bce06658 41
irq259: bce11428 8
cpu1: timer 320320 1989
cpu2: timer 320380 1989
cpu3: timer 320507 1990
Total1293684 8035
- --
Xin LI [EMAIL PROTECTED] http://www.delphij.net/
FreeBSD - The Power to Serve!
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (FreeBSD)
iEYEARECAAYFAkk1xFMACgkQi+vbBBjt66DgRwCfRTItoRYMYtyWywXfa4arKl8n
+usAoLUBSnifVZhK5wmENCpOAngI10WB
=tLQJ
-END PGP SIGNATURE-
--- if_bce.c2008-12-02 14:02:30.078918595 -0800
+++ .#if_bce.c.1.34.2.3.2.1 2008-12-02 13:49:07.0 -0800
@@ -925,15 +925,15 @@
sc-bce_rx_ticks = 0;
#else
/* Improve throughput at the expense of increased latency. */
- sc-bce_tx_quick_cons_trip_int = 20;
- sc-bce_tx_quick_cons_trip = 20;
- sc-bce_tx_ticks_int = 80;
- sc-bce_tx_ticks = 80;
-
- sc-bce_rx_quick_cons_trip_int = 6;
- sc-bce_rx_quick_cons_trip = 6;
- sc-bce_rx_ticks_int = 18;
- sc-bce_rx_ticks = 18;
+ sc-bce_tx_quick_cons_trip_int = 255;
+ sc-bce_tx_quick_cons_trip = 255;
+ sc-bce_tx_ticks_int = 1022;
+ sc-bce_tx_ticks = 1022;
+
+ sc-bce_rx_quick_cons_trip_int = 128;
+ sc-bce_rx_quick_cons_trip = 128;
+ sc-bce_rx_ticks_int = 125;
+ sc-bce_rx_ticks = 125;
#endif
/* Update statistics once every second. */
@@ -2555,7 +2555,7 @@
} else if (BCE_CHIP_BOND_ID(sc) BCE_CHIP_BOND_ID_SERDES_BIT)
sc-bce_phy_flags |= BCE_PHY_SERDES_FLAG;
- if (sc-bce_phy_flags BCE_PHY_SERDES_FLAG) {
+ if (sc-bce_phy_flags BCE_PHY_SERDES_FLAG) {
sc-bce_flags |= BCE_NO_WOL_FLAG;
if (BCE_CHIP_NUM(sc) != BCE_CHIP_NUM_5706) {
sc-bce_phy_addr = 2;
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1?
Hello, There is already a PR for this issue. #122572 http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/122572 Regards, --Jason # Fernan Aguero fernan at iib.unsam.edu.ar Fri Oct 17 13:37:16 UTC 2008 Previous message: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? Next message: [FreeBSD] Fix for ServerWorks HT1000 in upcoming 7.1? Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] On Friday 10 October 2008 01:11:17 pm Fernan Aguero wrote: John, thanks for the tip. I have now successfully gone through the process of making a new bootable CD using the ATA_HT1000 patched kernel. [snipped] So far everything seems to be working OK ... compiled and installed a couple of ports (vim, screen, apache, portupgrade), and everything looks fine. I can run more thourough tests if you want. Just let me know what those are and guide me through them ... are we still on time for including this patch in the upcoming 7.1? Will there be a new beta or RC? Fernan I have already built world + kernel and installed some more ports. Again, everything works fine. Should I submit a PR asking for inclusion of this patch? This platform (ServerWorks HT1000, and the Dell PowerEdge SC1435) would not boot 7.0 nor 7.1-BETA. If the patch does not affect other chipsets, it would be good to include it in 7.1-RELEASE. Fernan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Freebsd 7 STABLE 200807 amd64 - Realtek 8168 not working
On Tue, Dec 02, 2008 at 06:05:19PM -0500, Peter Sprokkelenburg wrote: I have an Asus P5Q-WS running FreeBSD 7 and the onboard Realtek NIC's are not being detected. No Kernel modifications as this is a fresh install. pciconf -lv : [EMAIL PROTECTED]:3:0:0: class=0x02 card=0x82c61043 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet [EMAIL PROTECTED]:2:0:0: class=0x02 card=0x82c61043 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet /var/log/messages: pci3: ACPI PCI bus on pcib6 Dec 2 17:37:21 nas kernel: re0: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xc800-0xc8ff mem 0xfe5ff000-0xfe5f,0xfdef -0xfdef irq 16 at device 0.0 on pci3 Dec 2 17:37:21 nas kernel: re0: Unknown H/W revision: 3c40 Dec 2 17:37:21 nas kernel: device_attach: re0 attach returned 6 Dec 2 17:37:21 nas kernel: pcib7: ACPI PCI-PCI bridge irq 18 at device 28.5 on pci0 Dec 2 17:37:21 nas kernel: pci2: ACPI PCI bus on pcib7 Dec 2 17:37:21 nas kernel: re1: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xb800-0xb8ff mem 0xfe4ff000-0xfe4f,0xfddf -0xfddf irq 17 at device 0.0 on pci2 Dec 2 17:37:21 nas kernel: re1: Unknown H/W revision: 3c40 Dec 2 17:37:21 nas kernel: device_attach: re1 attach returned 6 Is anymore info need to generate a patch? Please use latest stable/7 or 7.1-BETA2. re(4) will recognize your 8168C controller. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Freebsd 7 STABLE 200807 amd64 - Realtek 8168 not working
You need to move up to at least 20080716... On 2008-12-02 06:05:19PM -0500, Peter Sprokkelenburg wrote: I have an Asus P5Q-WS running FreeBSD 7 and the onboard Realtek NIC's are not being detected. No Kernel modifications as this is a fresh install. pciconf -lv : [EMAIL PROTECTED]:3:0:0: class=0x02 card=0x82c61043 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet [EMAIL PROTECTED]:2:0:0: class=0x02 card=0x82c61043 chip=0x816810ec rev=0x02 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet /var/log/messages: pci3: ACPI PCI bus on pcib6 Dec 2 17:37:21 nas kernel: re0: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xc800-0xc8ff mem 0xfe5ff000-0xfe5f,0xfdef -0xfdef irq 16 at device 0.0 on pci3 Dec 2 17:37:21 nas kernel: re0: Unknown H/W revision: 3c40 Dec 2 17:37:21 nas kernel: device_attach: re0 attach returned 6 Dec 2 17:37:21 nas kernel: pcib7: ACPI PCI-PCI bridge irq 18 at device 28.5 on pci0 Dec 2 17:37:21 nas kernel: pci2: ACPI PCI bus on pcib7 Dec 2 17:37:21 nas kernel: re1: RealTek 8168/8111B PCIe Gigabit Ethernet port 0xb800-0xb8ff mem 0xfe4ff000-0xfe4f,0xfddf -0xfddf irq 17 at device 0.0 on pci2 Dec 2 17:37:21 nas kernel: re1: Unknown H/W revision: 3c40 Dec 2 17:37:21 nas kernel: device_attach: re1 attach returned 6 Is anymore info need to generate a patch? let me know. -- Peter Sprokkelenburg mailto:[EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- === Peter C. Lai | Bard College at Simon's Rock Systems Administrator| 84 Alford Rd. Information Technology Svcs. | Gt. Barrington, MA 01230 USA peter AT simons-rock.edu | (413) 528-7428 === ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_7_1: bce driver change generating too much interrupts ?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi guys,
I think I got a real fix.
Cheers,
- --
Xin LI [EMAIL PROTECTED] http://www.delphij.net/
FreeBSD - The Power to Serve!
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (FreeBSD)
iEYEARECAAYFAkk11n0ACgkQi+vbBBjt66Dy6wCfSl3eLRhj5TVs24Q+8ao5Mcz0
FNQAoK8KvziiXFoanhSlWv636o+HfYIj
=AixC
-END PGP SIGNATURE-
Index: if_bce.c
===
--- if_bce.c(revision 185565)
+++ if_bce.c(working copy)
@@ -7030,13 +7030,14 @@
/* Was it a link change interrupt? */
if ((status_attn_bits STATUS_ATTN_BITS_LINK_STATE) !=
- (sc-status_block-status_attn_bits_ack
STATUS_ATTN_BITS_LINK_STATE))
+ (sc-status_block-status_attn_bits_ack
STATUS_ATTN_BITS_LINK_STATE)) {
bce_phy_intr(sc);
- /* Clear any transient status updates during link state change.
*/
- REG_WR(sc, BCE_HC_COMMAND,
- sc-hc_command | BCE_HC_COMMAND_COAL_NOW_WO_INT);
- REG_RD(sc, BCE_HC_COMMAND);
+ /* Clear any transient status updates during link state
change. */
+ REG_WR(sc, BCE_HC_COMMAND,
+ sc-hc_command |
BCE_HC_COMMAND_COAL_NOW_WO_INT);
+ REG_RD(sc, BCE_HC_COMMAND);
+ }
/* If any other attention is asserted then the chip is toast. */
if (((status_attn_bits ~STATUS_ATTN_BITS_LINK_STATE) !=
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: repeatable crash on RELENG7
Mike Tancsa wrote: At 09:20 AM 12/2/2008, Kostik Belousov wrote: On Tue, Dec 02, 2008 at 09:12:54AM -0500, Mike Tancsa wrote: At 08:38 AM 12/2/2008, Kostik Belousov wrote: mdconfig -a -t malloc -s 1800M You cannot have ~ 2Gb of kernel memory allocated for md, at least not on i386. Thanks, how do I find out what the limit is on a machine ? Is it vm.kvm_size ? It is much less, and highly depends on your load, since KVA is used for all kind of allocations made by kernel. I think either md(4) or mdconfig(8) have a warning about malloc backing for md. Thanks! A warning might be helpful to prevent such foot shooting :) malloc Storage for this type of memory disk is allocated with malloc(9). This limits the size to the malloc bucket limit in the kernel. If the -o reserve option is not set, creating and filling a large malloc-backed memory disk is a very easy way to panic a system. You almost never want to use malloc backing for a md, in favour of swap backing. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper?? NOPE - We're OK)
OK, so I installed a different PE1750 with BETA2 and then updated the source via cvsup RELENG_7 from cvsup3 and all is ok now on that box. Went back the first box and cvsup'ed the src again into an empty directory and it compiled and worked fine. Looks like my updating of the source along the way missed http://svn.freebsd.org/viewvc/base?view=revisionrevision=182924 as that is the only diff between the 2 local source trees. Sorry for the confusion. I've never had this issue before with cvsup, but guess there's always a first time. Thanks to all for checking my own bad testing work. -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 7.1-PRERELEASE: arcmsr write performance problem
David Kelly wrote: On Dec 1, 2008, at 11:45 PM, Jan Mikkelsen wrote: Replying to my own post ... I have done a test on the same machine comparing 6.3-p1 to 7.1-PRE. The performance is the expected ~6MB/s (because of the lack of cache) on 6.3-p1, so the BIOS change doesn't seem to be at fault. This seems to be a regression somewhere between 6.3 to 7.1. The Areca driver is the same in 6.3 and 7.1, so the problem seems to be elsewhere. I think this is more than just a performance problem. The observations with gstat showing extremely high ms/w values (I have seen them as high as 22000) makes it look like IO completion interrupts are being lost. Any suggestions on where to look next? Are there obvious candidates? ATA maximum block transfer has dropped from 128k to 64k in 7.x. Am not sure where the handle is to tweak it back up but has slowed peak thruput on my Dell PE400SC. Can watch with systat -v Interesting, thanks. Worse, I have a stripped array of 2 drives that won't transfer more than 43k at a chunk because apparently the stripe metadata didn't align nicely on 64k multiples. I know the partitions start at 64kB multiples in my case. I did, however, reduce the RAID-6 stripe size to 4kB (from 64kB) and that improved things slightly, but the throughput on 7.1 is still slower by about a factor of a about 6 (measured by untaring ~3GB across ~167k files into a fresh filesystem). And on 7.1 the machine is unusable during much of the time. -- David Kelly N4HHE, [EMAIL PROTECTED] Whom computers would destroy, they must first drive mad. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
sysinstall automatic partition labelling/sizing problem
Automatic labelling on 7.0 created about 360MB for my root partition on a 8GB disk. After a buildkernel into 7.1-PRERELEASE, the root partition was exhausted during the installkernel. Maybe automatic labelling in sysinstall needs to allocate more than 360MB in the root (/) partition if it's going to stay big enough to accomodate a buildkernel and installkernel from source. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dhclient doing DISCOVER with bad IP checksum - compile optimization issue
Ok, I managed to cause it again. dhclient was the problem. My source tree was fine. Turns out that it is my make.conf CFLAGS=-O3 setting. When compiled with -O3 it will generate packets with bad checksums. Simply recompiling it with -O2 did not cause this issue and dhclient works fine. So the question becomes, what is happening with -O3 that is breaking it? So far I am not having any other issues with -O3 on the rest of the system. -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
