Problems with QLogic 2312 FC controller on FreeBSD 4.11 stable
Hi, I'm struggling to get a QLogic 2312 FC controller to work with a FreeBSD 4.11 server after upgrading to the latest stable code in cvs. My server, an IBM-x336, is connected with fiber channel to a Nexsan SATABlade using the QLogic 2312 FC controller. I've been running 4.11-RELEASE for a while and this seemed to work, but had low performance on certain disk operations. I've now upgraded the kernel to 4.11-STABLE (cvs checkout 2006-08-07), and the external disk is no longer recognized after booting. Has anyone seen this before? Any suggestions on how to proceed? Some specs: Server: IBM-x336, 2GB ram, 2x3.2GHz CPU FC controller: QLogic 2312, using firmware from the FreeBSD ispfw module Disk raid: Nexsan SATABlade, firmware 9p41 With the 4.11-STABLE kernel, I get the following boot messages: Preloaded elf kernel kernel at 0xc066b000. Preloaded elf module vinum.ko at 0xc066b09c. Preloaded elf module ispfw.ko at 0xc066b13c. Warning: Pentium 4 CPU: PSE disabled Pentium Pro MTRR support enabled md0: Malloc disk npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard IOAPIC #0 intpin 16 - irq 2 IOAPIC #0 intpin 19 - irq 3 IOAPIC #0 intpin 23 - irq 5 IOAPIC #0 intpin 17 - irq 10 pci0: PCI bus on pcib0 pci0: unknown card (vendor=0x8086, dev=0x3591) at 0.1 pcib1: PCI to PCI bridge (vendor=8086 device=3595) irq 0 at device 2.0 on pci0 pci2: PCI bus on pcib1 pcib2: PCI to PCI bridge (vendor=8086 device=3597) irq 0 at device 4.0 on pci0 pci3: PCI bus on pcib2 pcib3: PCI to PCI bridge (vendor=8086 device=0329) at device 0.0 on pci3 IOAPIC #1 intpin 4 - irq 11 pci4: PCI bus on pcib3 mpt0: LSILogic 1030 Ultra4 Adapter port 0x4000-0x40ff mem 0xdefe-0xdefe,0xdeff-0xdeff irq 11 at device 1.0 on pci4 mpt0: MPI Version=1.2.15.0 mpt0: Capabilities: ( RAID-1 SAFTE ) mpt0: 0 Active Volumes (1 Max) mpt0: 0 Hidden Drive Members (6 Max) pcib4: PCI to PCI bridge (vendor=8086 device=032a) at device 0.2 on pci3 IOAPIC #2 intpin 0 - irq 16 pci5: PCI bus on pcib4 isp0: Qlogic ISP 2312 PCI FC-AL Adapter port 0x5000-0x50ff mem 0xdcfff000-0xdcff irq 16 at device 1.0 on pci5 isp0: Board Type 2312, Chip Revision 0x2, loaded F/W Revision 3.3.19 isp0: 839 max I/O commands supported isp0: NVRAM Port WWN 0x21e08b82cd8a ... (then no more reports from the isp driver, and no da2 device) With the 4.11-RELEASE kernel, I got these boot messages from the isp driver: isp0: Qlogic ISP 2312 PCI FC-AL Adapter port 0x5000-0x50ff mem 0xdcfff000-0xdcff irq 16 at device 1.0 on pci5 isp0: Board Type 2312, Chip Revision 0x2, loaded F/W Revision 3.1.20 isp0: Installed in 64-Bit PCI slot isp0: 744 max I/O commands supported isp0: NVRAM Port WWN 0x21e08b82cd8a ... isp0: LIP Received isp0: Loop UP isp0: Port Database Changed ... isp0: Firmware State Config Wait-Ready isp0: 2Gb link speed/s isp0: Loop ID 0, AL_PA 0xef, Port ID 0xef, Loop State 0x2, Topology 'Private Loop' isp0: Target 0 (Loop 0x0) Port ID 0xef (role Initiator) Arrived Port WWN 0x21e08b82cd8a Node WWN 0x20e08b82cd8a isp0: Target 1 (Loop 0x1) Port ID 0xe8 (role Target) Arrived Port WWN 0x5000402001ec058f Node WWN 0x2001000402ec058f ... da2 at isp0 bus 0 target 1 lun 0 da2: NEXSAN SATABl(C0A80103) 9p41 Fixed Direct Access SCSI-4 device da2: 200.000MB/s transfers, Tagged Queueing Enabled da2: 1907504MB (3906568192 512 byte sectors: 255H 63S/T 46564C) Best regards, Erik Østlyngen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
GEOM stacking
Hi, I have a running gmirror. Somewhere in its docs there is a mentioning about writing meta data to the last sector of a disk. Now, I would like to add PJD's gjournal journaling on top of the mirror. As far as I understand, it does write some meta data to the last sector of the journaled device, too. Will it overwrite the gmirror meta data and thus break the mirror or will it somehow magically work? Does each GEOM layer make the resulting block device one sector shorter? -- Vaclav Haisman signature.asc Description: OpenPGP digital signature
Re: RE: Re: Re: bce0: Error mapping mbuf into TX chain!
Hi Dave, On 8/7/06, David (Controller AE) Christensen [EMAIL PROTECTED] wrote: Scott, What are you doing when this problem occurs? Is it something I can easily duplicate here? When I tested the fix on -CURRENT I used the following command suggested by Doug to bring out the failure quickly: ssh bad machine dd if=/dev/zero bs=1 /dev/null Does this same command fail for you too? Yes, that brought the interface to a halt very quickly! To answer what I was doing on the machine, it's running mysql with a fairly large database and most of the 8G of ram in the machine devoted to mysql. I'm running the amd64 on a Dell 1950 with Woodcrest series (5100) Xeon processors and BCM5708 NICs. cheers, scott -Original Message- From: Scott Wilson [mailto:[EMAIL PROTECTED] Sent: Saturday, August 05, 2006 3:08 PM To: [EMAIL PROTECTED] Cc: Doug Ambrisko; David (Controller AE) Christensen; [EMAIL PROTECTED]; [EMAIL PROTECTED]; Eric Hodel Subject: Re: Re: Re: bce0: Error mapping mbuf into TX chain! On 8/5/06, Pyun YongHyeon [EMAIL PROTECTED] wrote: On Fri, Aug 04, 2006 at 03:52:40PM +0200, Scott Wilson wrote: On 7/13/06, Doug Ambrisko [EMAIL PROTECTED] wrote: David (Controller AE) Christensen writes: | Sorry, I've been out on vacation and just got back into town. I'll MFC | the patch within the next day or two. I'll let you merge in the down/up fix that I put into -current. Doug A. Hi, I just had a bce interface lock up with the same problem: Aug 4 07:00:16 pe3 kernel: bce0: /usr/src/sys/dev/bce/if_bce.c(4644): Error mapping mbuf into TX chain! Aug 4 07:00:47 pe3 last message repeated 368 times running v 1.2.2.5 of if_bce.c from RELENG_6 which has the defragmentation patch mentioned in this thread. Any suggestions on how I can help find a fix? scott Hmm... I can see several bus_dma(9) related bugs in bce(4). For architectures that have IOMMU hardware it may have corrupted DMA mapping and I'm pretty sure it wouldn't work on sparc64. When it has to handle many fragmented frame or has insufficient number of free Tx descriptors it would show unexpected results. Unfortunately I don't have hardwares supported by bce(4) and fixing requiries a working hardware. :-( I see ... I am running amd64 on some dell poweredge 1950 boxes. They're xeon processors, but have chosen amd64 because they have 8gig of ram each. Here are the relevant details on the interface bce0: Broadcom NetXtreme II BCM5708 1000Base-T (B1), v0.9.5 mem 0xf400-0xf5ff irq 16 at device 0.0 on pci9 bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz miibus0: MII bus on bce0 brgphy0: BCM5708C 10/100/1000baseTX PHY on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto I could make a machine available remotely to someone if it would help. Any other advice on how I can help move this forward would be greatly appreciated! thanks, scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RE: Re: Re: bce0: Error mapping mbuf into TX chain!
On 8/8/06, David (Controller AE) Christensen [EMAIL PROTECTED] wrote: Since BCE_MAX_SEGMENTS is too small I guess it will happen on highly fragmented packets under heavy loads. To simulate the situation you can use m_fragment(9) to fragment the frame in bce_tx_encap(). With m_fragment(9), ping -f -s 65507 x.x.x.x may trigger it. I didn't know about m_fragment before. I'll write a note to myself and look at how to add it to the debug path for a future driver revision. Btw, I've never seen this small number of Tx DMA segments support( BCE_MAX_SEGMENTS == 8) on GigE. Is this hardware limitation? The real value for BCE_MAX_SEGMENTS should be 16, not 8. I chose 8 as a reasonable value to start with. If the number of fragments exceeds 16 then we would expect to see performance drop and it is probably faster to have the OS defragment the packet rather than try to perform so many DMAs. What I don't understand is why the driver stays locked up after it gets into this mode. I guess that's a separate issue from the low max segments which is triggering it in the first place? -scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Device conflict 3ware twe and CMedia sound card
Hello, I seem to have a device conflict on my desktop. When attempting to fsck a gstripe volume attached via the twe card the system becomes 'choppy' and from looking at systat (when it isn't frozen) the system is receiving about 300k interrupts per second from the pcm device. If I leave the system in this state for a few minutes it will do an instant-reset, presumably because it can't cope. Verbose dmesg: http://goodforbusiness.co.uk/~dom/dmesg.boot Specific parts: twe0: 3ware Storage Controller. Driver version 1.50.01.002 port 0xdcb0-0xdcbf mem 0xdf00-0xdf7f irq 49 at device 13.0 on pci3 twe0: Reserved 0x10 bytes for rid 0x10 type 4 at 0xdcb0 ioapic2: routing intpin 1 (PCI IRQ 49) to vector 49 twe0: [GIANT-LOCKED] twe0: AEN: soft reset twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 twe0: Monitor ME7X 1.01.00.040, PCB Rev5, Achip 3.20, Pchip 1.30-66 twe0: port 0: WDC WD3200KS-00PFB0 305245MB twe0: port 1: WDC WD3200KS-00PFB0 305245MB pcm0: CMedia CMI8738 port 0xcc00-0xccff irq 17 at device 13.0 on pci7 pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xcc00 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 55 pcm0: [MPSAFE] pcm0: sndbuf_setmap 3e8ee000, 4000; 0xe5408000 - 3e8ee000 pcm0: sndbuf_setmap 3e8ea000, 4000; 0xe540c000 - 3e8ea000 I believe I can use device.hints(5) to work around this, but I am unsure variable I can set in order to resolve this. Does the device 13.0 from dmesg refer to the 'drq' ? Thanks, Dominic ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stop in buildworld under RELENG_4
On Tue, Aug 08, 2006 at 07:59:41PM -0400, Eric Millbrandt wrote: Is buildworld broken under RELENG_4. No. I made sure to start out with a clean buildtree and to delete /usr/obj. Here is the stop and attached is the entire script. DING! [EMAIL PROTECTED]:/usr/src# uname -a FreeBSD mongoloid.xx.com 4.11-STABLE FreeBSD 4.11-STABLE #9: Thu Mar 23 21:27:05 EST 2006 [EMAIL PROTECTED]:/builds/obj/usr/src/sys/MONGOLOID alpha 17:35 [EMAIL PROTECTED]:/usr/src# gcc --version 2.95.4 cc -c -O -pipe -mcpu=pca56 -fexceptions -DIN_GCC -D_PTHREADS -DGTHREAD_USE_WEAK -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config -I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I. -DL_fixdfsi -o _fixdfsi.o /usr/src/gnu/lib/libgcc/../../../contrib/gcc/libgcc1.c cc: Internal compiler error: program cc1 got fatal signal 4 *** Error code 1 This is SIGILL, and it's probably because you're using an incorrect CPUTYPE for your hardware. Kris pgpGA8GT5ALaj.pgp Description: PGP signature
Re: RE: Re: Re: bce0: Error mapping mbuf into TX chain!
On Wed, Aug 09, 2006 at 11:02:37AM +0200, Scott Wilson wrote: On 8/8/06, David (Controller AE) Christensen [EMAIL PROTECTED] wrote: Since BCE_MAX_SEGMENTS is too small I guess it will happen on highly fragmented packets under heavy loads. To simulate the situation you can use m_fragment(9) to fragment the frame in bce_tx_encap(). With m_fragment(9), ping -f -s 65507 x.x.x.x may trigger it. I didn't know about m_fragment before. I'll write a note to myself and look at how to add it to the debug path for a future driver revision. Btw, I've never seen this small number of Tx DMA segments support( BCE_MAX_SEGMENTS == 8) on GigE. Is this hardware limitation? The real value for BCE_MAX_SEGMENTS should be 16, not 8. I chose 8 as a reasonable value to start with. If the number of fragments exceeds 16 then we would expect to see performance drop and it is probably faster to have the OS defragment the packet rather than try to perform so many DMAs. What I don't understand is why the driver stays locked up after it gets into this mode. I guess that's a separate issue from the low max segments which is triggering it in the first place? There are several cases here. 1. Due to lack of free Tx descriptors bus_dmamap_load_mbuf(9) can fail, so loaded DMA map should be unloaded with bus_dmamap_unload(9) in order to reload it after m_defrag(9) call. 2. If m_defrag(9) fail you may want to free m_head as keeping it in queue may result in stuck condition. Since m_defrag(9) can't defragment the mbuf chain you can never send it again if you requeue the mbuf chain. 3. If the second bus_dmamap_load_mbuf(9) fail you should requeue m_head which was alreay modified with m_defrag(9). Just returning error from failure make bce(4) reuse invalud mbuf chain. As a general rule caller of m_defrag(9) should be prepared to cope with modified mbuf chains when it requeues the mbuf chains. -- 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]
Network often not responding
Hello, I have squid cache server using: MB Tyan Tiger K8W/S2875 Dual Opteron 246 4 GB DDR, connected to cisco catalyst. Freebsd AMD64 6.1-Stable sometimes network down and up again on uncertain condition i've tried change network card and disable onboadr gigabit ethernet, work good for a days then it happen again. Then i try to move another port on catalyst switch, it's same. When network not responding connecting using cross-cable not work too. it will up again 5 minutes later or more. I can't find any relevan error on /var/log/message except something like this: Aug 9 15:09:16 cache kernel: xl0: transmission error: 90 Aug 9 15:09:16 cache kernel: xl0: tx underrun, increasing tx start threshold to 120 bytes anyone experienced something like this ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
gzip is faster with -O3
dd if=/dev/random of=testfile bs=1m count=5000 gzip compiled with -O3: # date ; nice -10 ./gzip -c9 testfile testfile.gz ; date Wed Aug 9 08:01:21 CDT 2006 Wed Aug 9 08:09:06 CDT 2006 465 Seconds. gzip compiled with -O2: # date ; nice -10 ./gzip -c9 testfile testfile.gz ; date Wed Aug 9 08:19:14 CDT 2006 Wed Aug 9 08:27:06 CDT 2006 472 Seconds. 7 second difference, it's not much but I still wanted to share it with the group. -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gzip is faster with -O3
Nikolas Britton [EMAIL PROTECTED] writes: dd if=/dev/random of=testfile bs=1m count=5000 1. gzip isn't usually used to compress incompressible data. 2. use time to figure out how much CPU time it actually burns. 5 GB are somewhat I/O bound, but gcc options don't help with that, so CPU time is better than wallclock time. gzip compiled with -O3: # date ; nice -10 ./gzip -c9 testfile testfile.gz ; date Wed Aug 9 08:01:21 CDT 2006 -- Matthias Andree ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
problems getting RAID1 to work with SiI 0680 UDMA133 controller
I have this ultra ata IDE controller card that I try to use with RAID1, Both the harddrives I intend to use, ad6 ad4 are working, fsck gives no errors and I can read/write on them. I have setup raid1 on these in the bios utility for the ata controller card. but now It says one of them is down! Why is that? And what can I do about it? From dmesg: atapci0: SiI 0680 UDMA133 controller port 0x1050-0x1057,0x1060-0x1063,0x1058-0 x105f,0x1064-0x1067,0x1040-0x104f mem 0x4010-0x401000ff irq 18 at device 9.0 on pci2 ad0: 19092MB Seagate ST320414A 3.25 at ata0-master UDMA100 acd0: CDROM Compaq CRD-8484B/1.04 at ata1-master PIO4 ad4: 190782MB WDC WD2000JB-00GVA0 08.02D08 at ata2-master UDMA100 ad5: 286188MB Maxtor 6L300R0 BAJ41G20 at ata2-slave UDMA133 ad6: 190782MB WDC WD2000JB-00EVA0 15.05R15 at ata3-master UDMA100 ad7: 14664MB IBM DJNA-351520 J56OA30K at ata3-slave UDMA66 ar0: WARNING - mirror protection lost. RAID1 array in DEGRADED mode ar0: 190781MB Silicon Image Medley RAID1 status: DEGRADED ar0: disk0 DOWN no device found for this subdisk ar0: disk1 READY (mirror) using ad6 at ata3-master su-2.05b# atacontrol list ATA channel 0: Master: ad0 ST320414A/3.25 ATA/ATAPI revision 4 Slave: no device present ATA channel 1: Master: acd0 Compaq CRD-8484B/1.04 ATA/ATAPI revision 0 Slave: no device present ATA channel 2: Master: ad4 WDC WD2000JB-00GVA0/08.02D08 ATA/ATAPI revision 6 Slave: ad5 Maxtor 6L300R0/BAJ41G20 ATA/ATAPI revision 7 ATA channel 3: Master: ad6 WDC WD2000JB-00EVA0/15.05R15 ATA/ATAPI revision 6 Slave: ad7 IBM-DJNA-351520/J56OA30K ATA/ATAPI revision 4 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gzip is faster with -O3
Nikolas Britton wrote: dd if=/dev/random of=testfile bs=1m count=5000 gzip compiled with -O3: # date ; nice -10 ./gzip -c9 testfile testfile.gz ; date Wed Aug 9 08:01:21 CDT 2006 Wed Aug 9 08:09:06 CDT 2006 465 Seconds. gzip compiled with -O2: # date ; nice -10 ./gzip -c9 testfile testfile.gz ; date Wed Aug 9 08:19:14 CDT 2006 Wed Aug 9 08:27:06 CDT 2006 472 Seconds. 7 second difference, it's not much but I still wanted to share it with the group. You should use /bin/time for measuring. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Network often not responding
On Wed, Aug 09, 2006, Dominic Marks wrote: Aug 9 15:09:16 cache kernel: xl0: transmission error: 90 Aug 9 15:09:16 cache kernel: xl0: tx underrun, increasing tx start threshold to 120 bytes dc%d: TX underrun -- increasing TX threshold The device generated a transmit underrun error while attempting to DMA and transmit a packet. This happens if the host is not able to DMA the packet data into the NIC's FIFO fast enough. The driver will dynamically increase the ~~ trans- mit start threshold so that more data must be DMAed into the FIFO before the NIC will start transmitting it onto the wire. So it would seem like the card cannot keep pace with the system. What NICs ~ have you tried? Basing on the quoted text, isn't it the opposite? -- I saw `cout' being shifted Hello world times to the left and stopped right there. -- Steve Gonedes signature.asc Description: Digital signature
Re: GEOM stacking
Václav Haisman wrote: journaled device, too. Will it overwrite the gmirror meta data and thus break the mirror or will it somehow magically work? Does each GEOM layer make the resulting block device one sector shorter? No, when you create a mirror device, its size will be one sector less than size_of_raw_device. So when you add another GEOM class in it, the last sector will be the one before the last on the physical provider, and the new size will be two sectors less than physical, etc. In other words, geoms are nesting in each other and each nested geom is one sector smaller than the one it's in. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Device conflict 3ware twe and CMedia sound card
On Wednesday 09 August 2006 06:15, Dominic Marks wrote: Hello, I seem to have a device conflict on my desktop. When attempting to fsck a gstripe volume attached via the twe card the system becomes 'choppy' and from looking at systat (when it isn't frozen) the system is receiving about 300k interrupts per second from the pcm device. If I leave the system in this state for a few minutes it will do an instant-reset, presumably because it can't cope. Verbose dmesg: http://goodforbusiness.co.uk/~dom/dmesg.boot Specific parts: twe0: 3ware Storage Controller. Driver version 1.50.01.002 port 0xdcb0-0xdcbf mem 0xdf00-0xdf7f irq 49 at device 13.0 on pci3 twe0: Reserved 0x10 bytes for rid 0x10 type 4 at 0xdcb0 ioapic2: routing intpin 1 (PCI IRQ 49) to vector 49 twe0: [GIANT-LOCKED] twe0: AEN: soft reset twe0: 2 ports, Firmware FE8S 1.05.00.068, BIOS BE7X 1.08.00.048 twe0: Monitor ME7X 1.01.00.040, PCB Rev5, Achip 3.20, Pchip 1.30-66 twe0: port 0: WDC WD3200KS-00PFB0 305245MB twe0: port 1: WDC WD3200KS-00PFB0 305245MB pcm0: CMedia CMI8738 port 0xcc00-0xccff irq 17 at device 13.0 on pci7 pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xcc00 ioapic0: routing intpin 17 (PCI IRQ 17) to vector 55 pcm0: [MPSAFE] pcm0: sndbuf_setmap 3e8ee000, 4000; 0xe5408000 - 3e8ee000 pcm0: sndbuf_setmap 3e8ea000, 4000; 0xe540c000 - 3e8ea000 I believe I can use device.hints(5) to work around this, but I am unsure variable I can set in order to resolve this. Does the device 13.0 from dmesg refer to the 'drq' ? Does this system have an Intel PCI-X host bridge in it? If so, it's probably due to brain damage in that chip. You might be able to work around it by making twe0 use the same IRQ as pcm0 by adding the following hint: hint.pci3.13.INTA.irq=17 That should make twe0 use IRQ 17. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Problems with QLogic 2312 FC controller on FreeBSD 4.11 stable
working with Erik on this now... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gzip is faster with -O3
On 8/9/06, Matthias Andree [EMAIL PROTECTED] wrote: 1. gzip isn't usually used to compress incompressible data. 2. use time to figure out how much CPU time it actually burns. 5 GB are somewhat I/O bound, but gcc options don't help with that, so CPU time is better than wallclock time. dd if=/dev/zero of=testfile bs=1m count=5000 gzip comiled with -O3 # time nice -10 ./gzip -c9 testfile /dev/null 73.187u 8.682s 2:08.41 63.7%70+617k 40161+0io 0pf+0w gzip compiled with -O2 # time nice -10 ./gzip -c9 testfile /dev/null 61.183u 8.468s 2:00.14 57.9%58+609k 40162+0io 0pf+0w Now... what do all of those numbers mean, I've never used time before... thanks for the tip btw? -- BSD Podcasts @: http://bsdtalk.blogspot.com/ http://freebsdforall.blogspot.com/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gzip is faster with -O3
On Wed, Aug 09, 2006 at 05:31:58PM -0500, Nikolas Britton wrote: On 8/9/06, Matthias Andree [EMAIL PROTECTED] wrote: 1. gzip isn't usually used to compress incompressible data. 2. use time to figure out how much CPU time it actually burns. 5 GB are somewhat I/O bound, but gcc options don't help with that, so CPU time is better than wallclock time. dd if=/dev/zero of=testfile bs=1m count=5000 gzip comiled with -O3 # time nice -10 ./gzip -c9 testfile /dev/null 73.187u 8.682s 2:08.41 63.7%70+617k 40161+0io 0pf+0w gzip compiled with -O2 # time nice -10 ./gzip -c9 testfile /dev/null 61.183u 8.468s 2:00.14 57.9%58+609k 40162+0io 0pf+0w Now... what do all of those numbers mean, I've never used time before... thanks for the tip btw? In this case the used a similar amount of system time (the number ending in s), but the -O3 case took 8 seconds more user time (the number ending in u) and real time (the third number.) If this were statisticaly meaningful, -O3 would be slower in this case. If you want to do a meaningful test you need to do several runs each way, probably ignoring the first one due to cache effects and then run the results through the program you can build in src/tools/tools/ministat/ so see if there is a measurable difference. Poul-Henning Kamp has a nice (if probably somewhat overkill for this case) writeup on doing benchmarking here: http://lists.freebsd.org/pipermail/freebsd-current/2004-January/019595.html It's a tricky business even for something simple. :) You might also consider using /usr/bin/time instead of the csh builtin time. It's output is a little more readable. -- Brooks pgp820W2lpVvK.pgp Description: PGP signature
Re: Network often not responding
Hello, right now, i'm using 3com ethernet: xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xa880-0xa8ff mem 0xfeafec00-0xfeafec7f irq 19 at device 7.0 on pci2 miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:10:5a:0d:c1:45 onboard ethernet which disabled via BIOS was: Intel 82541E1 GbE Average traffic is 10-15Mbps on bussy hours, and connected client average 1000 #netstat -n | grep EST | wc -l # 780 I really confused, i don't have any other Freebsd AMD64 system installed, but other with i386 system never got any problem like this. Best regards, Wednesday, August 9, 2006, 9:10:01 PM, Dominic wrote: Googling for the second line I found this: http://lists.freebsd.org/pipermail/freebsd-doc/2005-November/009273.html It quotes this part of the manual page for dc, another network card: This is from the dc(4) man page: dc%d: TX underrun -- increasing TX threshold The device generated a transmit underrun error while attempting to DMA and transmit a packet. This happens if the host is not able to DMA the packet data into the NIC's FIFO fast enough. The driver will dynamically increase the trans- mit start threshold so that more data must be DMAed into the FIFO before the NIC will start transmitting it onto the wire. So it would seem like the card cannot keep pace with the system. What NICs have you tried? Dom ___ 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]
error: syntax error before _X_SENTINEL
Hello, I just recenlly found that I am almost always unable to build X (Xorg) related applications on a 5.5 box that has pretty recent source. The applications all die during the make process with the following error: error: syntax error before _X_SENTINEL Any to fix this? Googling indicates that this is a common problem without a solution. System runs Xorg 6.9. Thank you for all your time and consideration. -- panic: kernel trap (ignored) - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dell Server 2900 with the new Intel processor Woodcrest
[EMAIL PROTECTED] wrote: Thomas Agersborg wrote: I want to purchase a Dell Server 2900 with these specifications ... Dual-Core 64-bit Intel Xeon processor 5160 ... 4GB (4x1GB) 667MHz FBD memory (max 32GB) ... is there any issues which I need to be aware of in regard to the server and FreeBSD? You'll want (need) to run amd64 instead of i386. You can run i386, but the 64-bit capabilities will go to waste. You also won't get to use all of your 4 GB of RAM due to memory-mapping of hardware I/O addresses. The amd64 version does not have these problems. All the major software is now 64-bit clean, but you may have trouble with some desktop-type software (mplayer) and other less-common ports. Beyond that, all is good--PowerEdge+FreeBSD is an excellent combination. We even have IPMI support! ___ Just a few extra notes I could add. Its possible to use just the PAE kernel config with i386 to get access to all your ram, I only do it because I need 1.4 Java which is only really available on i386 but most people would use the 1.5 Java instead, also I need the i386 Perl Oracle driver as there is no AMD64 version of that. Other then those I would just use the AMD64 FreeBSD. I did see a commit on that new Perc5 Raid card somewhere I don't know if its in 6.1Release or just 6stable so I guess the only risk is that may have to run 6-Stable till 6.2 Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: error: syntax error before _X_SENTINEL
Chris H. wrote: Hello, I just recenlly found that I am almost always unable to build X (Xorg) related applications on a 5.5 box that has pretty recent source. The applications all die during the make process with the following error: error: syntax error before _X_SENTINEL Any to fix this? Googling indicates that this is a common problem without a solution. System runs Xorg 6.9. Thank you for all your time and consideration. I saw this: http://support.zenwalk.org/index.php?PHPSESSID=84b9cfbdfe961f45c90c7c47960b2268topic=2134.msg11956 Might be worth a try. Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
boot problem with ACPI disabled
Hi, I've got fatal trap on Dell D620 laptop when I tried to boot with ACPI disabled. Kernel compiled with APIC and SMP options. GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb 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 6.1-STABLE #7: Tue Aug 8 12:52:48 ULAST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DEVIL Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Genuine Intel(R) CPU T2300 @ 1.66GHz (1664.45-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6e8 Stepping = 8 Features=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xc1a9SSE3,MON,VMX,EST,TM2,b14,b15 AMD Features=0x10NX Cores per package: 2 real memory = 1063849984 (1014 MB) avail memory = 1031909376 (984 MB) ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) cpu0 on motherboard pcib0: Host to PCI bridge pcibus 0 on motherboard pir0: PCI Interrupt Routing Table: 12 Entries on motherboard pci0: PCI bus on pcib0 $PIR: No matching entry for 0.2.INTA pci0: display, VGA at device 2.0 (no driver attached) pci0: display at device 2.1 (no driver attached) pcm0: Intel 82801G High Definition Audio Controller mem 0xdfebc000-0xdfeb irq 10 at device 27.0 on pci0 pcm0: Output Streams: 4, Input Streams: 4, Bidirectional Streams: 0 pcm0: CORB Size: 256, RIRB Size: 256 pcib1: PCIBIOS PCI-PCI bridge at device 28.0 on pci0 pci11: PCI bus on pcib1 pcib2: PCIBIOS PCI-PCI bridge at device 28.1 on pci0 pci12: PCI bus on pcib2 pci12: network at device 0.0 (no driver attached) pcib3: PCIBIOS PCI-PCI bridge at device 28.2 on pci0 pci9: PCI bus on pcib3 bge0: Broadcom BCM5752 A2, ASIC rev. 0x6002 mem 0xdfcf-0xdfcf irq 5 at device 0.0 on pci9 bge0: firmware handshake timed out miibus0: MII bus on bge0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bge0: Ethernet address: 00:14:22:fb:32:a6 uhci0: UHCI (generic) USB controller port 0xbf80-0xbf9f irq 9 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: UHCI (generic) USB controller 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: UHCI (generic) USB controller port 0xbf60-0xbf7f irq 10 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: UHCI (generic) USB controller 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: UHCI (generic) USB controller port 0xbf40-0xbf5f irq 5 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: UHCI (generic) USB controller 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: UHCI (generic) USB controller port 0xbf20-0xbf3f irq 3 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: UHCI (generic) USB controller 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 82801GB/R (ICH7) USB 2.0 controller mem 0xffa8-0xffa803ff irq 9 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: waiting for BIOS to give up control usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: Intel 82801GB/R (ICH7) USB 2.0 controller on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib4: PCIBIOS PCI-PCI bridge at device 30.0 on pci0 pci3: PCI bus on pcib4 cbb0: O2Micro OZ6912/6972 PCI-CardBus Bridge irq 5 at device 1.0 on pci3 cardbus0: CardBus bus on cbb0 pccard0: 16-bit PCCard bus on cbb0 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: GENERIC ATA controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xbfa0-0xbfaf irq 11 at device 31.2 on pci0 ata0: ATA channel 0 on atapci0 ata1: ATA channel 1 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) kernel trap 30 with interrupts disabled Fatal trap 30: reserved (unknown) fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x70:0xc28d stack pointer = 0x28:0xf9c frame pointer = 0x28:0xfd4 code segment= base 0xc00f, limit 0x, type 0x1b = DPL 0, pres 1, def32 0, gran 0 processor eflags= IOPL = 0 current process = 0 (swapper) [thread pid 0 tid 0 ] Stopped at 0xc28d: *** error reading from address c28d *** db trace Tracing pid 0 tid 0 td 0xc0873480 (null)(780001,0,b0202,ffe,0) at 0xc28d db where Tracing pid 0 tid 0 td 0xc0873480 (null)(780001,0,b0202,ffe,0) at 0xc28d db
Re: Network often not responding
On Thu, Aug 10, 2006 at 08:18:23AM +0700, Akhmad Sakirun wrote: Hello, right now, i'm using 3com ethernet: xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xa880-0xa8ff mem 0xfeafec00-0xfeafec7f irq 19 at device 7.0 on pci2 miibus0: MII bus on xl0 xlphy0: 3Com internal media interface on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:10:5a:0d:c1:45 onboard ethernet which disabled via BIOS was: Intel 82541E1 GbE Average traffic is 10-15Mbps on bussy hours, and connected client average 1000 #netstat -n | grep EST | wc -l # 780 I really confused, i don't have any other Freebsd AMD64 system installed, but other with i386 system never got any problem like this. Best regards, Wednesday, August 9, 2006, 9:10:01 PM, Dominic wrote: Googling for the second line I found this: http://lists.freebsd.org/pipermail/freebsd-doc/2005-November/009273.html It quotes this part of the manual page for dc, another network card: This is from the dc(4) man page: dc%d: TX underrun -- increasing TX threshold The device generated a transmit underrun error while attempting to DMA and transmit a packet. This happens if the host is not able to DMA the packet data into the NIC's FIFO fast enough. The driver will dynamically increase the trans- mit start threshold so that more data must be DMAed into the FIFO before the NIC will start transmitting it onto the wire. So it would seem like the card cannot keep pace with the system. What NICs have you tried? Dom [CCed to wpaul, the author of xl(4)] I'm not familiar with 3Com 90x NICs but the datasheet says the following. Tx underrun halts the the transmitter and the transmit FIFO. The TxReset and TxEnable commands must be issued before any new packets are submitted to the NIC. But I can't find the above programming sequence in xl_txeoc() so your NIC may have been stuck in wedged state if it didn't work anymore after seeing tx underrun, increasing tx start threshold to xx bytes message. Normally xl(4) should activate watchdog timeout for above case but xl(4) has a bug which blindly clears armed watchdog in xl_txeof/ xl_txeof_90xB(). I think you can set the threshold to a higher value so make xl(4) not see the Tx underrun issue(simple patch attached, you may need to increase xl_tx_thread to higher value). The correct solution should follow the procedure outlined in datasheet and remember the threshold caused the underrun instead of resetting it in xl_init_locked() but it's hard to reset Tx path only and need knowledge of internals of the NIC so it's more easy to reset entire NIC if it see Tx underruns, I guess. -- Regards, Pyun YongHyeon --- if_xl.c.origTue Feb 14 21:44:56 2006 +++ if_xl.c Thu Aug 10 12:54:45 2006 @@ -2848,7 +2848,12 @@ CSR_WRITE_1(sc, XL_TX_FREETHRESH, XL_PACKET_SIZE 8); /* Set the TX start threshold for best performance. */ +#if 0 sc-xl_tx_thresh = XL_MIN_FRAMELEN; +#else + /* set higher Tx threshold: 120, 180, 230, 300 etc */ + sc-xl_tx_thresh = 120; +#endif CSR_WRITE_2(sc, XL_COMMAND, XL_CMD_TX_SET_START|sc-xl_tx_thresh); /* ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: error: syntax error before _X_SENTINEL
Hello Mark, and thank you for your prompt reply. Quoting Mark Kirkwood [EMAIL PROTECTED]: Chris H. wrote: Hello, I just recenlly found that I am almost always unable to build X (Xorg) related applications on a 5.5 box that has pretty recent source. The applications all die during the make process with the following error: error: syntax error before _X_SENTINEL Any to fix this? Googling indicates that this is a common problem without a solution. System runs Xorg 6.9. Thank you for all your time and consideration. I saw this: http://support.zenwalk.org/index.php?PHPSESSID=84b9cfbdfe961f45c90c7c47960b2268topic=2134.msg11956 Might be worth a try. Yes, I caught the thread on that board. But didn't find the solution you provided. Thanks! That was the /magic/ required to stop the whining offender (gdkx.h). After some more research and investigation, this anomoly appears to be a GTK/GD issue, and not X. I'm trying to figure out how to get this #ifdef hack sucked in globally for the gtk/gd environment. I'm /pretty/ sure gdkx.h will probably cover it. But would rather have it sucked in from a seperate file. So as to not contaminate the actual header file. I've cc'd the ports list, in hopes there is a better solution and (even better) a newer version that resolves this problem. # NOTE to ports list: please cc me in your replies. # Thanks again for your reply. --Chris Cheers Mark ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- panic: kernel trap (ignored) - FreeBSD 5.4-RELEASE-p12 (SMP - 900x2) Tue Mar 7 19:37:23 PST 2006 / ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: error: syntax error before _X_SENTINEL
On Wed, 09 Aug 2006 21:24:36 -0700 Chris H. [EMAIL PROTECTED] wrote: Hello Mark, and thank you for your prompt reply. Quoting Mark Kirkwood [EMAIL PROTECTED]: Chris H. wrote: Hello, I just recenlly found that I am almost always unable to build X (Xorg) related applications on a 5.5 box that has pretty recent source. The applications all die during the make process with the following error: error: syntax error before _X_SENTINEL Any to fix this? Googling indicates that this is a common problem without a solution. System runs Xorg 6.9. Thank you for all your time and consideration. I saw this: http://support.zenwalk.org/index.php?PHPSESSID=84b9cfbdfe961f45c90c7c47960b2268topic=2134.msg11956 Might be worth a try. Yes, I caught the thread on that board. But didn't find the solution you provided. Thanks! That was the /magic/ required to stop the whining offender (gdkx.h). After some more research and investigation, this anomoly appears to be a GTK/GD issue, and not X. I'm trying to figure out how to get this #ifdef hack sucked in globally for the gtk/gd environment. I'm /pretty/ sure gdkx.h will probably cover it. But would rather have it sucked in from a seperate file. So as to not contaminate the actual header file. I've cc'd the ports list, in hopes there is a better solution and (even better) a newer version that resolves this problem. Hi all, interesting this is appearing ... I had this problem around 23rd of march on my laptop running 6-STABLE at the time. I am not sure if this is the *same* issue, BUT I think it went like this... xproto's makefile says it conflicts with xorg-libraries-* CONFLICTS= XFree86-libraries-* xorg-libraries-* i think that I had installed by hand one of the X lib-packages and that had made the whole problem. conflicting libraries and include files. I removed all the extra Xfree86 libs and Xorg, reinstalled Xorg and that was it. I am not saying this is your problem... but it may be worth a try. Xfree86 lib-packages that were installed in my system at the time: libX11 libXau libXcursor libXdmcp libXfixes libXrender xextensions xproto They definitely install files (under include and lib/ ) that xorg provides. HIH, Beto ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
