Re: freebsd ipsc -a output missing
The Presence [EMAIL PROTECTED] wrote: I have a generic kernel on my FreeBSD 6.2 system, and I am getting errors regarding PMAP_SHPGPERPROC which is set at 201 (default). The default value is 200. Because the system is a heavy load websever, this happens quite often. I want to calculate the proper value to to it to, but my ipcs software isn't working. Anyone know how to reconcile it? It has nothing to do with ipcs. The ipcs tool is used to report SysV IPC data. I suggest you try increasing PMAP_SHPGPERPROC in your kernel config, or adjust the vm.pmap.shpgperproc loader tunable (same effect, but doesn't require building a new kernel). I do have: options SYSVSHM # SYSV-style pscshared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores compiled into the kernel. Irrelevant. Output from ipcs -a: mercury# ipcs -a Message Queues: T ID KEY MODEOWNERGROUPCREATOR CGROUP CBYTES QNUM QBYTESLSPID LRPID STIMERTIMECTIME Shared Memory: T ID KEY MODEOWNERGROUPCREATOR CGROUP NATTCHSEGSZ CPID LPID ATIMEDTIMECTIME Semaphores: T ID KEY MODEOWNERGROUPCREATOR CGROUP NSEMS OTIMECTIME Obviously nothing on your machine uses SysV IPC, so all fields are empty. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd When your hammer is C++, everything begins to look like a thumb. -- Steve Haflich, in comp.lang.c++ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
PAE Slowdown
Hey all, I know that AMD64's the preferred way to run 4 gig systems, but I'm having a weird situation with 6.2-RELEASE-p8 and 6-STABLE as of last night. When I compile the PAE kernel, my system performance drops like a rock. It still boots and everything still runs, but for instance, running the Flops port my megaflops drop from the 950 MFLOPS range to 4 MFLOPS. It feels about as fast as a 486. I'm not sure what I should try disabling. I tried nodevice usb, but that didn't seem to change anything. SMP and GENERIC kernels work fine. CPU: Intel Core Duo 2 Quad 2.4ghz Memory: 8 gig (4 2 gig dimms) Swap: 16 gig partition If I try to boot without ACPI disabled the kernel doesn't finish booting, it stops after ata7. Full kernel message listing: Copyright (c) 1992-2007 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-RELEASE-p8 #0: Mon Oct 8 11:04:03 CDT 2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/PAE ACPI APIC Table: INTEL DP965LT Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPU @ 2.40GHz (2412.00-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6f7 Stepping = 7 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=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,b9,CX16,b14,b15 AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 4 real memory = 9059696640 (8640 MB) avail memory = 8340590592 (7954 MB) ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: INTEL DP965LT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 acpi_perf0: ACPI CPU Frequency Control on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 acpi_throttle0: ACPI CPU Throttling on cpu0 acpi_perf0: ACPI CPU Frequency Control on cpu0 acpi_perf0: failed in PERF_STATUS attach device_attach: acpi_perf0 attach returned 6 acpi_button0: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 3ware device driver for 9000 series storage controllers, version: 3.60.03.006 twa0: 3ware 9000 series Storage Controller port 0x3000-0x30ff mem 0xe800-0xe9ff,0xea20-0xea200fff irq 16 at device 0.0 on pci1 twa0: [GIANT-LOCKED] twa0: INFO: (0x15: 0x1300): Controller details:: Model 9650SE-4LPML, 4 ports, Firmware FE9X 3.08.02.005, BIOS BE9X 3.08.00.002 pci0: simple comms at device 3.0 (no driver attached) em0: Intel(R) PRO/1000 Network Connection Version - 6.2.9 port 0x40c0-0x40df mem 0xea30-0xea31,0xea32-0xea320fff irq 20 at device 25.0 on pci0 em0: Ethernet address: 00:19:d1:b0:d5:d0 pci0: serial bus, USB at device 26.0 (no driver attached) pci0: serial bus, USB at device 26.1 (no driver attached) pci0: serial bus, USB at device 26.7 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 28.0 on pci0 pci2: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 28.1 on pci0 pci3: ACPI PCI bus on pcib3 atapci0: GENERIC ATA controller port 0x2018-0x201f,0x2024-0x2027,0x2010-0x2017,0x2020-0x2023,0x2000-0x200f mem 0xea10-0xea1001ff irq 17 at device 0.0 on pci3 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 pcib4: ACPI PCI-PCI bridge at device 28.2 on pci0 pci4: ACPI PCI bus on pcib4 pcib5: ACPI PCI-PCI bridge at device 28.3 on pci0 pci5: ACPI PCI bus on pcib5 pcib6: ACPI PCI-PCI bridge at device 28.4 on pci0 pci6: ACPI PCI bus on pcib6 pci0: serial bus, USB at device 29.0 (no driver attached) pci0: serial bus, USB at device 29.1 (no driver attached) pci0: serial bus, USB at device 29.2 (no driver attached) pci0: serial bus, USB at device 29.7 (no driver attached) pcib7: ACPI PCI-PCI bridge at device 30.0 on pci0 pci7: ACPI PCI bus on pcib7 pci7: display, VGA at device 0.0 (no driver attached) fwohci0: Texas Instruments TSB43AB22/A mem 0xea084000-0xea0847ff,0xea08-0xea083fff irq 19 at device 3.0 on pci7 fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:90:27:00:01:e7:67:5e fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet address: 02:90:27:e7:67:5e fwe0: Ethernet address: 02:90:27:e7:67:5e fwe0: if_start running deferred for Giant sbp0: SBP-2/SCSI over FireWire on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop = 0, cable
Re: PAE Slowdown
Jeff Kramer wrote: Hey all, I know that AMD64's the preferred way to run 4 gig systems, but I'm having a weird situation with 6.2-RELEASE-p8 and 6-STABLE as of last night. When I compile the PAE kernel, my system performance drops like a rock. It still boots and everything still runs, but for instance, running the Flops port my megaflops drop from the 950 MFLOPS range to 4 MFLOPS. It feels about as fast as a 486. I'm not sure what I should try disabling. I tried nodevice usb, but that didn't seem to change anything. SMP and GENERIC kernels work fine. CPU: Intel Core Duo 2 Quad 2.4ghz Memory: 8 gig (4 2 gig dimms) Swap: 16 gig partition If I try to boot without ACPI disabled the kernel doesn't finish booting, it stops after ata7. Perhaps unrelated, but why don't you run amd64 version? I think PAE is a hack, for instance it does not allow processes to use more than 2GB memory, while AMD64 (called EM64T by Intel implementation) provides much more... Cheers, -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! signature.asc Description: OpenPGP digital signature
Re: PAE Slowdown
Jeff Kramer wrote: Hey all, I know that AMD64's the preferred way to run 4 gig systems, but I'm having a weird situation with 6.2-RELEASE-p8 and 6-STABLE as of last night. When I compile the PAE kernel, my system performance drops like a rock. It still boots and everything still runs, but for instance, running the Flops port my megaflops drop from the 950 MFLOPS range to 4 MFLOPS. It feels about as fast as a 486. Does vmstat -i show unusually high interrupt rates? signature.asc Description: OpenPGP digital signature
Re: PAE Slowdown
More weirdness, if I take out 4 gig of ram and only run with 4 total, the PAE kernel works fine. At 11:23 AM -0500 10/8/07, Jeff Kramer wrote: Hey all, I know that AMD64's the preferred way to run 4 gig systems, but I'm having a weird situation with 6.2-RELEASE-p8 and 6-STABLE as of last night. When I compile the PAE kernel, my system performance drops like a rock. It still boots and everything still runs, but for instance, running the Flops port my megaflops drop from the 950 MFLOPS range to 4 MFLOPS. It feels about as fast as a 486. I'm not sure what I should try disabling. I tried nodevice usb, but that didn't seem to change anything. SMP and GENERIC kernels work fine. CPU: Intel Core Duo 2 Quad 2.4ghz Memory: 8 gig (4 2 gig dimms) Swap: 16 gig partition -- Jeff Kramer [EMAIL PROTECTED] http://www.jeffkramer.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAE Slowdown
Hello, On 10/8/07, Jeff Kramer [EMAIL PROTECTED] wrote: More weirdness, if I take out 4 gig of ram and only run with 4 total, the PAE kernel works fine. Please don't top post, so we could track the thread :) As Li said, you better for for AMD64 arch to enjoy the speed of your box. -- Regards, -Abdullah Ibn Hamad Al-Marri Arab Portal http://www.WeArab.Net/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAE Slowdown
At 6:56 PM +0200 10/8/07, Ivan Voras wrote: Jeff Kramer wrote: Hey all, I know that AMD64's the preferred way to run 4 gig systems, but I'm having a weird situation with 6.2-RELEASE-p8 and 6-STABLE as of last night. When I compile the PAE kernel, my system performance drops like a rock. It still boots and everything still runs, but for instance, running the Flops port my megaflops drop from the 950 MFLOPS range to 4 MFLOPS. It feels about as fast as a 486. Does vmstat -i show unusually high interrupt rates? When it's running ok at idle (4 gig of ram): interrupt total rate irq1: atkbd0 77 0 irq16: twa0 1084 3 irq17: atapci0 1 0 irq19: fwohci0++ 3 0 irq20: em0 161 0 cpu0: timer 549165 1920 Total 550491 1924 When it's slow at idle (8 gig of ram): interrupt total rate irq1: atkbd0 48 0 irq16: twa0 1093 8 irq17: atapci0 1 0 irq19: fwohci0++ 3 0 irq20: em0 179 1 cpu0: timer 241862 1950 Total 243186 1961 -- Jeff Kramer [EMAIL PROTECTED] http://www.jeffkramer.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAE Slowdown
Jeff Kramer wrote: At 6:56 PM +0200 10/8/07, Ivan Voras wrote: Jeff Kramer wrote: Hey all, I know that AMD64's the preferred way to run 4 gig systems, but I'm having a weird situation with 6.2-RELEASE-p8 and 6-STABLE as of last night. When I compile the PAE kernel, my system performance drops like a rock. It still boots and everything still runs, but for instance, running the Flops port my megaflops drop from the 950 MFLOPS range to 4 MFLOPS. It feels about as fast as a 486. Does vmstat -i show unusually high interrupt rates? When it's running ok at idle (4 gig of ram): interrupt total rate irq1: atkbd0 77 0 irq16: twa0 1084 3 irq17: atapci0 1 0 irq19: fwohci0++ 3 0 irq20: em0 161 0 cpu0: timer 549165 1920 Total 550491 1924 When it's slow at idle (8 gig of ram): interrupt total rate irq1: atkbd0 48 0 irq16: twa0 1093 8 irq17: atapci0 1 0 irq19: fwohci0++ 3 0 irq20: em0 179 1 cpu0: timer 241862 1950 Total 243186 1961 The culprit could be the twa driver. Are you really generating that much I/O? Scott ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAE Slowdown
Jeff Kramer [EMAIL PROTECTED] writes: Hey all, I know that AMD64's the preferred way to run 4 gig systems, but I'm having a weird situation with 6.2-RELEASE-p8 and 6-STABLE as of last night. When I compile the PAE kernel, my system performance drops like a rock. It still boots and everything still runs, but for instance, running the Flops port my megaflops drop from the 950 MFLOPS range to 4 MFLOPS. It feels about as fast as a 486. This may not be a PAE-related problem. I say this because I noticed you have the same MB I have: ACPI APIC Table: INTEL DP965LT Several Intel MBs, including the DP965LT, have a BIOS bug that rears its head when you have 4G (or more) of memory installed, where the BIOS sets the cache control registers incorrectly. This cause a chunk of your main memory (on my system, the chunk between 448MB and 512MB) to be labeled uncachable, with the result being random slowdowns whenever the kernel or user processes happen to touch memory in that chunk. This problem drove me crazy trying to figure out what the problem was until I stumbled on this report on a Linux users' forum explaining the situation. http://forums.fedoraforum.org/showthread.php?t=157232 Fortunately, the workaround is fairly straightforward, adding an rc.d script to twiddle the MTRRs. Assuming this is your problem, if you could post the output of memcontrol list it should be possible to id which of the entires is bogus and needs to be removed. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: PAE Slowdown
At 2:00 PM -0500 10/8/07, Richard Todd wrote: Jeff Kramer [EMAIL PROTECTED] writes: Hey all, I know that AMD64's the preferred way to run 4 gig systems, but I'm having a weird situation with 6.2-RELEASE-p8 and 6-STABLE as of last night. When I compile the PAE kernel, my system performance drops like a rock. It still boots and everything still runs, but for instance, running the Flops port my megaflops drop from the 950 MFLOPS range to 4 MFLOPS. It feels about as fast as a 486. This may not be a PAE-related problem. I say this because I noticed you have the same MB I have: ACPI APIC Table: INTEL DP965LT Several Intel MBs, including the DP965LT, have a BIOS bug that rears its head when you have 4G (or more) of memory installed, where the BIOS sets the cache control registers incorrectly. This cause a chunk of your main memory (on my system, the chunk between 448MB and 512MB) to be labeled uncachable, with the result being random slowdowns whenever the kernel or user processes happen to touch memory in that chunk. This problem drove me crazy trying to figure out what the problem was until I stumbled on this report on a Linux users' forum explaining the situation. http://forums.fedoraforum.org/showthread.php?t=157232 Fortunately, the workaround is fairly straightforward, adding an rc.d script to twiddle the MTRRs. Assuming this is your problem, if you could post the output of memcontrol list it should be possible to id which of the entires is bogus and needs to be removed. Sweet, I just downgraded to the 1669 bios rev and it looks like it's running at full speed. I'm compiling an SMP/PAE kernel now, but it looks like this was the fix! Thanks, Richard! -- Jeff Kramer [EMAIL PROTECTED] http://www.jeffkramer.org/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads UP - MFC for em coming shortly
At 04:28 PM 10/5/2007, Jack Vogel wrote: I am preparing to update the em driver to the equivalent of my 6.6.6 driver. Just doing some last minute sanity checking, I hope to the checkin before end of day. Hi, thanks for fixing the compile issue, but I have another possible problem. Do you know if there were any performance regressions with this rev? On one firewall / router, I am seeing dropped packets. The PPS rate is only about 30k which should not be that much Oct 8 02:15:02 c1 kernel: em2: Excessive collisions = 0 Oct 8 02:15:02 c1 kernel: em2: Sequence errors = 0 Oct 8 02:15:02 c1 kernel: em2: Defer count = 0 Oct 8 02:15:02 c1 kernel: em2: Missed Packets = 2068 Oct 8 02:15:02 c1 kernel: em2: Receive No Buffers = 280 Oct 8 02:15:02 c1 kernel: em2: Receive Length Errors = 0 Oct 8 02:15:02 c1 kernel: em2: Receive errors = 3 Oct 8 02:15:02 c1 kernel: em2: Crc errors = 3 Oct 8 02:15:02 c1 kernel: em2: Alignment errors = 0 Oct 8 02:15:02 c1 kernel: em2: Collision/Carrier extension errors = 0 Oct 8 02:15:02 c1 kernel: em2: RX overruns = 17 Oct 8 02:15:02 c1 kernel: em2: watchdog timeouts = 0 Oct 8 02:15:02 c1 kernel: em2: XON Rcvd = 0 Oct 8 02:15:02 c1 kernel: em2: XON Xmtd = 0 Oct 8 02:15:02 c1 kernel: em2: XOFF Rcvd = 0 Oct 8 02:15:02 c1 kernel: em2: XOFF Xmtd = 0 Oct 8 02:15:02 c1 kernel: em2: Good Packets Rcvd = 146043044 Oct 8 02:15:02 c1 kernel: em2: Good Packets Xmtd = 75481090 Oct 8 02:15:02 c1 kernel: em2: TSO Contexts Xmtd = 0 Oct 8 02:15:02 c1 kernel: em2: TSO Contexts Failed = 0 % vmstat -i interrupt total rate irq1: atkbd0 5 0 irq4: sio0 10094 0 irq16: em0 291014020 5831 irq17: em1 em2 em3 298574806 5983 irq19: atapci1 53969 1 cpu0: timer 99802510 1999 cpu1: timer 99791176 1999 Total 789246580 15815 Load avg is quite low, although top doesnt show any interrupt activity for some reason. The settings are all default % sysctl -a dev.em.2 dev.em.2.%desc: Intel(R) PRO/1000 Network Connection Version - 6.6.6 dev.em.2.%driver: em dev.em.2.%location: slot=0 function=0 dev.em.2.%pnpinfo: vendor=0x8086 device=0x108c subvendor=0x8086 subdevice=0x348f class=0x02 dev.em.2.%parent: pci3 dev.em.2.debug_info: -1 dev.em.2.stats: -1 dev.em.2.rx_int_delay: 0 dev.em.2.tx_int_delay: 66 dev.em.2.rx_abs_int_delay: 66 dev.em.2.tx_abs_int_delay: 66 dev.em.2.rx_processing_limit: 100 em0: Intel(R) PRO/1000 Network Connection Version - 6.6.6 port 0x3020-0x303f mem 0x8826-0x8827,0x8824-0x8825 irq 16 at device 0.0 on pci2 em0: Ethernet address: 00:15:17:0b:70:98 em0: [FAST] em1: Intel(R) PRO/1000 Network Connection Version - 6.6.6 port 0x3000-0x301f mem 0x8822-0x8823,0x8820-0x8821 irq 17 at device 0.1 on pci2 em1: Ethernet address: 00:15:17:0b:70:99 em1: [FAST] pcib3: ACPI PCI-PCI bridge at device 28.5 on pci0 pci3: ACPI PCI bus on pcib3 em2: Intel(R) PRO/1000 Network Connection Version - 6.6.6 port 0x2000-0x201f mem 0x8818-0x8819,0x8810-0x8817 irq 17 at device 0.0 on pci3 em2: Ethernet address: 00:15:17:1e:94:0b em2: [FAST] pci3: simple comms, UART at device 0.3 (no driver attached) pci3: serial bus at device 0.4 (no driver attached) pcib4: ACPI PCI-PCI bridge at device 30.0 on pci0 pci4: ACPI PCI bus on pcib4 pci4: display, VGA at device 4.0 (no driver attached) em3: Intel(R) PRO/1000 Network Connection Version - 6.6.6 port 0x1100-0x113f mem 0x8802-0x8803,0x8800-0x8801 irq 17 at device 5.0 on pci4 em3: Ethernet address: 00:15:17:1e:94:0c em3: [FAST] [EMAIL PROTECTED]:0:0: class=0x02 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint [EMAIL PROTECTED]:0:1: class=0x02 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PT' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint [EMAIL PROTECTED]:0:0: class=0x02 card=0x348f8086 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'PRO/1000 PM' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit cap 10[e0] = PCI-Express 1 endpoint [EMAIL PROTECTED]:5:0: class=0x02 card=0x348f8086 chip=0x10768086 rev=0x05 hdr=0x00 vendor = 'Intel Corporation' device =
g_vfs_done():mfid1 ERROR when writing to 18TB MFI RAID volume
Hello, I am trying to diagnose an issue on a server I am trying to set up here. The errors are quite cryptic and don't make any sense to me, they come up about every 30 seconds while I am writing to the disks (at about 30MB/sec). Errors: Oct 8 15:44:02 server1 kernel: g_vfs_done():mfid1[WRITE(offset=-16052369358848, length=16384)]error = 5 Oct 8 15:44:02 server1 kernel: g_vfs_done():mfid1[WRITE(offset=-16052369342464, length=16384)]error = 5 Oct 8 15:44:02 server1 kernel: g_vfs_done():mfid1[WRITE(offset=-16052176732160, length=16384)]error = 5 Oct 8 15:44:02 server1 kernel: g_vfs_done():mfid1[WRITE(offset=-16052176715776, length=16384)]error = 5 Oct 8 15:44:02 server1 kernel: g_vfs_done():mfid1[WRITE(offset=-16051984089088, length=16384)]error = 5 Oct 8 15:44:02 server1 kernel: g_vfs_done():mfid1[WRITE(offset=-16051984072704, length=16384)]error = 5 Oct 8 15:44:32 server1 kernel: g_vfs_done():mfid1[WRITE(offset=-16053910519808, length=16384)]error = 5 Oct 8 15:44:32 server1 kernel: g_vfs_done():mfid1[WRITE(offset=-16053910503424, length=16384)]error = 5 Oct 8 15:44:32 server1 kernel: g_vfs_done():mfid1[WRITE(offset=-16053910487040, length=16384)]error = 5 Oct 8 15:44:32 server1 kernel: g_vfs_done():mfid1[WRITE(offset=-16053910470656, length=16384)]error = 5 Oct 8 15:44:32 server1 kernel: g_vfs_done():mfid1[WRITE(offset=-16053910454272, length=16384)]error = 5 Oct 8 15:44:32 server1 kernel: g_vfs_done():mfid1[WRITE(offset=-16053139947520, length=16384)]error = 5 Oct 8 15:44:32 server1 kernel: g_vfs_done():mfid1[WRITE(offset=-16053139931136, length=16384)]error = 5 Oct 8 15:44:32 server1 kernel: g_vfs_done():mfid1[WRITE(offset=-16053139914752, length=16384)]error = 5 Oct 8 15:44:32 server1 kernel: g_vfs_done():mfid1[WRITE(offset=-16053139898368, length=16384)]error = 5 etc... The volumes are large here, so perhaps this is what is causing this: # df -h Filesystem SizeUsed Avail Capacity Mounted on /dev/mfid0s1a131G2.8G118G 2%/ devfs1.0K1.0K 0B 100%/dev /dev/mfid118T201G 16T 1%/.2 procfs 4.0K4.0K 0B 100%/proc This is the dmesg.boot: Copyright (c) 1992-2007 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-STABLE #0: Mon Sep 17 18:09:38 EDT 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/host1950-64BITRAID-SMP ACPI APIC Table: DELL PE_SC3 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU5140 @ 2.33GHz (2327.51-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6f6 Stepping = 6 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=0x4e3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,b9,CX16,XTPR,b15,b18 AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF Cores per package: 2 real memory = 9395240960 (8960 MB) avail memory = 8295616512 (7911 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic1: Changing APIC ID to 3 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 64-87 on motherboard acpi0: DELL PE_SC3 on motherboard acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 2000 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 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 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 2.0 on pci0 pci6: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci6 pci7: ACPI PCI bus on pcib2 pcib3: ACPI PCI-PCI bridge at device 0.0 on pci7 pci8: ACPI PCI bus on pcib3 pcib4: PCI-PCI bridge at device 0.0 on pci8 pci9: PCI bus on pcib4 bce0: Broadcom NetXtreme II BCM5708 1000Base-T (B2) mem 0xf400-0xf5ff irq 16 at device 0.0 on pci9 miibus0: MII bus on bce0 brgphy0: BCM5708C 10/100/1000baseTX PHY on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce0: Ethernet address: 00:19:b9:e6:89:c8 bce0: ASIC (0x57081020); Rev (B2); Bus (PCI-X, 64-bit, 133MHz); F/W (0x02090105); Flags( MFW ) pcib5: ACPI PCI-PCI bridge at device 1.0 on pci7 pci10: ACPI PCI bus on pcib5 pcib6: PCI-PCI bridge at device 0.3 on pci6 pci11: PCI bus on pcib6 pcib7: ACPI
Re: Heads UP - MFC for em coming shortly
On 10/8/07, Mike Tancsa [EMAIL PROTECTED] wrote: At 04:28 PM 10/5/2007, Jack Vogel wrote: I am preparing to update the em driver to the equivalent of my 6.6.6 driver. Just doing some last minute sanity checking, I hope to the checkin before end of day. Hi, thanks for fixing the compile issue, but I have another possible problem. Do you know if there were any performance regressions with this rev? On one firewall / router, I am seeing dropped packets. The PPS rate is only about 30k which should not be that much So the missed packets are only showing up on em2? Uh, and that is a management-capable 82573, one that is often a problem without the eeprom patched, did you do that sometime in the past, I don't remember who did and who didnt :) Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads UP - MFC for em coming shortly
At 04:36 PM 10/8/2007, Jack Vogel wrote: So the missed packets are only showing up on em2? Hi, Yes, but thats where all the packets come in. Uh, and that is a management-capable 82573, one that is often a problem without the eeprom patched, did you do that sometime in the past, I don't remember who did and who didnt :) No, I havent. Where do I find this program and how can I find out if I need it or not. The box in question is about 100miles away and it would be handy to confirm its needed remotely ---Mik ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads UP - MFC for em coming shortly
On 10/8/07, Mike Tancsa [EMAIL PROTECTED] wrote: At 04:36 PM 10/8/2007, Jack Vogel wrote: So the missed packets are only showing up on em2? Hi, Yes, but thats where all the packets come in. Uh, and that is a management-capable 82573, one that is often a problem without the eeprom patched, did you do that sometime in the past, I don't remember who did and who didnt :) No, I havent. Where do I find this program and how can I find out if I need it or not. The box in question is about 100miles away and it would be handy to confirm its needed remotely Search thru the archives of this mailing list, look for 82573. There is a DOS patcher that I have sent out a couple times. Its harmless to run it, if the adapter is wrong or it doesnt need the patch it should tell you. What it does it change a bit in the EEPROM programming of the MANC register. If you can't find it in the archives let me know and I'll send it to you. Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads UP - MFC for em coming shortly
At 08:36 PM 10/8/2007, Jack Vogel wrote: Search thru the archives of this mailing list, look for 82573. There is a DOS patcher that I have sent out a couple times. Its harmless to run it, if the adapter is wrong or it doesnt need the patch it should tell you. What it does it change a bit in the EEPROM programming of the MANC register. If you can't find it in the archives let me know and I'll send it to you. Thanks, I did find this reference http://www.higherorder.com.au/2007/6/25/intel_82573_patch Is there a way from FreeBSD to tell remotely if its needed ? ---Mike Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Heads UP - MFC for em coming shortly
On 10/8/07, Mike Tancsa [EMAIL PROTECTED] wrote: At 08:36 PM 10/8/2007, Jack Vogel wrote: Search thru the archives of this mailing list, look for 82573. There is a DOS patcher that I have sent out a couple times. Its harmless to run it, if the adapter is wrong or it doesnt need the patch it should tell you. What it does it change a bit in the EEPROM programming of the MANC register. If you can't find it in the archives let me know and I'll send it to you. Thanks, I did find this reference http://www.higherorder.com.au/2007/6/25/intel_82573_patch Is there a way from FreeBSD to tell remotely if its needed ? Well, there would be a way, reading the MANC register and seeing if the suspect bit is present, but am not sure if there is some important point at which the thing gets misprogrammed, its just best to use the patcher, its harmless if its not needed. Sorry, I realize its a hassle to boot to that wonder DOS :) Jack ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
