ACTIVITE ETRADUP
3D FOR SA= LES IN STOCK - AVAILABLE TODAY 2 SUNFIRE 15K COMPLETE 150 x SUN USB MOUSE USED 150 x SUN QWERTY USB KEYBOARD 2x LICENCES N199-919-99A9 SUN SANTRICITY 9.19 1 x SUN RACK 900-38 with complete Rohs PSU perfect= condition. 2 x COMPLETE SG-XSWBR0200E-8P-Z BROCADE SW200E wit= h rackmount 2x SUN FIRE V890 A53-JNG4C216GTFnbs= p; 4x 1.35 Ghz CPU ULTRASPARC V 16 x 501-7385-01nb= sp; 512MB 232p PC133 18c 16x16 Registered ECC SDRAM DIMM Sun Systems A53= -JNG4C216GTF Sun Fire V890 Server 4 * 1.35GHz UltraSPARC IV = pro Sun Fire V890 Server 4 * 1.35GHz UltraSPARC IV processors with 16MB 6x SUN 54= 0-5459-01 146.0GB Hard Drive FC (540-5459-01) SUN 146GB 3.5T= H 10K RPM FC HDD W/SLED 2x 375-3354-01 SUN 4GB Single P= ort Fibre PCI-X SUN 2x 501-6635-06= /span · DUAL GIGABITETHERNET / DUAL SCSI = PCI A 1x 501-6767-03= /span, SUN, SUN ALOM + (Plus) Card V490/890 (PK 1D/1-B22-1C)DAPTER 2x SUNFIRE X4100 AMD OSY285FAA6CB DUAL-CORE OPTE= RON 285 SE 2.6GHZ 2MB L2 CACHE SOCKET-940PIN PROCESSOR Redudant PSU, 4 Ethernet gigabit.= span style=color: black; 1x 2GB FC Dual Chan= nel HBA PCI-X 66-133MHZ FC5010409-04 2x SUN 390-0213= -04-BGP 73.0GB Hard Drive SAS (0556) SUN 73GB 2.5 SAS 10K HDD= span lang=EN-US style=color: black; 1x SUNFIRE X4100 AMD OPTERON 248E 2.2GHZR Redudant PSU, 4 Ethernet gigabit.= span style=color: black; 2x SUN 390-0213= -04-BGP 73.0GB Hard Drive SAS (0556) SUN 73GB 2.5 SAS 10K HDD= span lang=EN-US style=color: black; 1 SUN FIRE 25 K - 4 rack 1 RACK 900-38 8 STOREDGE S1 2x72 gb UW 1= 60 10k/rpm 3 STOREDGE 3120 JBOD 4 x 146 gb = uw320 15k/rpm594-1908-01 8 STOREDGE S1 2x72 gb UW 1= 60 10k/rpm 4 STOREDGE 3120 JBOD 4 x 146 gb = uw320 10k/rpm 1 UltraSPARC IV CPU/Memo= ry board 4 x 1.05GHz 540-5664-07 5 CPU/Memory Uniboard w/ 4×= ; US IV 1.05GHz, 16GB 540-5602-03 2 CPU/Memory board w/ 4 × = US IV 1.05GHz,0GB 540-5664-04 1 SYSTEM CONTROL BOARD CP2140-65= 0501-6772 8 X4422A Dual Gigabit Ethe= rnet / Dual SCSI PCI Adapter 501-6635 13X1034A Quad Fast Ethernet PCI (QFE/= P)501-5406 1 DVD drive 390-0161 1 DDS4 tape 390-0027 1 UltraSPARC IV CPU/Memo= ry board 4 x 1.05GHz 540-5664-07 7 CPU/Memory Uniboard w/ 4×= ; US IV 1.05GHz, 16GB 540-5662-05 1 CPU/Memory board w/ 4 × = US IV 1.05GHz,0GB 540-5664-04 1 SYSTEM CONTROL BOARD CP2140-65= 0501-6772 8 SUN STOREDGE CONTROLER A= V950-00475 1 DVD drive 390-0161 1 DAT72 Tape 380-1324 Pour ne plus recevoir des messages de ETRADUP, [1]suive= z ce lien. References 1. 3Dhttp://ho=/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD 8.1-RC2 Available...
The second and most likely final Release Candidate for the FreeBSD 8.1 release cycle is now available for amd64, i386, ia64, powerpc, and sparc64 architectures. Files suitable for creating installation media or doing FTP based installs through the network should be available on most of the FreeBSD mirror sites. Checksums for the images are at the bottom of this message. There was a recent regression fix related to Atheros AR9280 cards being detected incorrectly, making them unusable. If you were having problems with a wireless card that had worked before not working with the earlier test builds hopefully this will fix the problem. Testing of this fix would be appreciated. At this time DVD images are not available. There was a fairly serious security issue with the png graphics package. We will generate DVD images when the rebuilt packages become available, that will be announced then the images are ready. The target schedule for the release is available here: http://www.freebsd.org/releases/8.1R/schedule.html and the wiki page tracking the current status is here: http://wiki.freebsd.org/Releng/8.1TODO If you find problems you can report them through the normal Gnats based PR system or here on this mailing list. If you are updating an already running machine the CVS branch tag is RELENG_8_1, or if you prefer SVN use releng/8.1. The freebsd-update(8) utility supports binary upgrades of i386 and amd64 systems running earlier FreeBSD releases. Systems running 8.0-RELEASE, 8.1-BETA1, or 8.1-RC1 can upgrade as follows: # freebsd-update upgrade -r 8.1-RC2 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now After rebooting, freebsd-update needs to be run again to install the new userland components, and the system needs to be rebooted again: # freebsd-update install # shutdown -r now Users of earlier FreeBSD releases (FreeBSD 7.x) can also use freebsd-update to upgrade to FreeBSD 8.1-RC2, but will be prompted to rebuild all third-party applications (e.g., anything installed from the ports tree) after the second invocation of freebsd-update install, in order to handle differences in the system libraries between FreeBSD 7.x and FreeBSD 8.x. Checksums: MD5 (FreeBSD-8.1-RC2-amd64-bootonly.iso) = 473a9f6e280e6cac8cfcf62c4ebb3c99 MD5 (FreeBSD-8.1-RC2-amd64-disc1.iso) = 7eba227c8b8175a21446879fbc802a39 MD5 (FreeBSD-8.1-RC2-amd64-livefs.iso) = caa8df85fceb5e7eb9e9394aa378540d MD5 (FreeBSD-8.1-RC2-amd64-memstick.img) = 71f7c41900d41ad7e7cec63b7b75dad8 MD5 (FreeBSD-8.1-RC2-i386-bootonly.iso) = f8ebd88798da2f161b33a2f714c0e125 MD5 (FreeBSD-8.1-RC2-i386-disc1.iso) = fd77efeecd224298c6f3a08f239f294a MD5 (FreeBSD-8.1-RC2-i386-livefs.iso) = 9ec3b7901f377c643b8060b71c75ef25 MD5 (FreeBSD-8.1-RC2-i386-memstick.img) = 916e2a13027b01b912f92a94a06e7c84 MD5 (FreeBSD-8.1-RC2-ia64-bootonly.iso) = 3daed89818fd2c7a3561d78c4b9f4927 MD5 (FreeBSD-8.1-RC2-ia64-disc1.iso) = 89d064dd30375a4c9ee6e7dc7336ac2e MD5 (FreeBSD-8.1-RC2-ia64-disc2.iso) = e6b7caa02ecc8d1c62cbcecdb87ca9ea MD5 (FreeBSD-8.1-RC2-ia64-disc3.iso) = d3c1c4a194687b20c35fbbbaa83dacc2 MD5 (FreeBSD-8.1-RC2-ia64-dvd1.iso) = 9a3ee466a926c213a911d8c08b8ff450 MD5 (FreeBSD-8.1-RC2-ia64-livefs.iso) = c979d4bee75481e0ba39ead8f431e3ed MD5 (FreeBSD-8.1-RC2-pc98-bootonly.iso) = b487ef910c2950239d307a9684e636c1 MD5 (FreeBSD-8.1-RC2-pc98-disc1.iso) = 11d1fe67a521c29b8909ca5e41266eaa MD5 (FreeBSD-8.1-RC2-pc98-livefs.iso) = d5c03f71857d1951987e4aeb9259ec7a MD5 (FreeBSD-8.1-RC2-powerpc-bootonly.iso) = 86a088efbbd9fa2eb2f226ed637f063d MD5 (FreeBSD-8.1-RC2-powerpc-disc1.iso) = e2808baeab27cad13d494b8b7397de8c MD5 (FreeBSD-8.1-RC2-powerpc-disc2.iso) = 6836e68d4004cf5d904460ef55ae85df MD5 (FreeBSD-8.1-RC2-powerpc-disc3.iso) = ff131875a7b7665084793cce60873642 MD5 (FreeBSD-8.1-RC2-sparc64-bootonly.iso) = 28d00dbbbd590e60b33a079337a898a7 MD5 (FreeBSD-8.1-RC2-sparc64-disc1.iso) = 53a8b1bc84869c80e024688b45de2f9a MD5 (FreeBSD-8.1-RC2-sparc64-livefs.iso) = f76fe1312d097d159d3c3ab9e5802574 SHA256 (FreeBSD-8.1-RC2-amd64-bootonly.iso) = f8a9a009f7528ba48b09a928884346652048c70b5f6c9c21bd13874bcdcbe8f0 SHA256 (FreeBSD-8.1-RC2-amd64-disc1.iso) = 5aa8ef16b34fe7dae852f1ef16a4863bedd194677a9b3070777a646db122fa0f SHA256 (FreeBSD-8.1-RC2-amd64-livefs.iso) = b72f294d5208eca1e179b41340ea3ae809e1397b3f2ef4d3260a319d6d56ab6b SHA256 (FreeBSD-8.1-RC2-amd64-memstick.img) = 5de904a3fc33c510f97dc87f8b4fa288661f956fac3ba74ff41e9f720228978f SHA256 (FreeBSD-8.1-RC2-i386-bootonly.iso) = dfe2916339a6160584977ed588af5bc4a045cac1df438f2eed8550a7ae9cd9ae SHA256 (FreeBSD-8.1-RC2-i386-disc1.iso) = 335ad68ce598e5f1557ca4179fde3063793c484cd5f3022926fbff2a25fc5540 SHA256 (FreeBSD-8.1-RC2-i386-livefs.iso) =
[stable 7] bge() related panic on an HP dl380g3 (32 bit)
Started seeing this panic today from our BSD7 variant here at Yahoo. Our BGE driver is identical to 7stable at this time. Looks like all of these boxes are HP DL380G3 models. I have included the panic and pciconf -lv information. I assume that these machines have a variant of BGE that needs some kind of exception/quirk that I'm unaware of. panic - Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 06 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xa053f8e6 stack pointer = 0x28:0xa9599978 frame pointer = 0x28:0xa95999a4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 33 (irq29: bge0) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(a07a1271,a9599814,a04e7fe9,a07c029d,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(a07c029d,0,a076d19d,a9599820,0,...) at kdb_backtrace+0x29 panic(a076d19d,a07c15d2,a97b17a4,1,1,...) at panic+0x119 trap_fatal(a08a63e0,0,1,0,0,...) at trap_fatal+0x333 trap_pfault(a97e2800,a95998bc,dbdd,0,a9796250,...) at trap_pfault+0x260 trap(a9599938) at trap+0x462 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xa053f8e6, esp = 0xa9599978, ebp = 0xa95999a4 --- m_copym(a9df8800,5dc,5c8,1,0,...) at m_copym+0x36 ip_fragment(a9f66810,a9599a70,5dc,7,0,...) at ip_fragment+0x235 ip_output(a9df8800,0,a9599a44,0,0,a9ef6974,a085b740,0,0,a9ef6974,a05b54c1,a085b744,a085b74c,3e8) at ip_output+0xba6 tcp_respond(ab433448,a9f66810,a9f66824,a9df8800,0,...) at tcp_respond +0x395 tcp_dropwithreset(5a8,4,a9f66824,a9599b90,a9df8800,...) at tcp_dropwithreset+0xe9 tcp_input(a9df8800,14,a97966f0,a9599bf0,1,...) at tcp_input+0xcde ip_input(a9df8800,0,800,a97e2800,800,...) at ip_input+0x6f8 netisr_dispatch(2,a9df8800,10,3,0,...) at netisr_dispatch+0x55 ether_demux(a97e2800,a9df8800,3,0,3,...) at ether_demux+0x1c1 ether_input(a97e2800,a9df8800,a08b2480,a9cf4900,0,...) at ether_input +0x323 bge_rxeof(0,1,9157deaa,5647,100,...) at bge_rxeof+0x2c2 bge_intr(a97f7000,0,a079c70e,4fc,0,...) at bge_intr+0x132 ithread_loop(a97d9ad0,a9599d38,0,0,0,...) at ithread_loop+0x1ab fork_exit(a04c28c0,a97d9ad0,a9599d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xa9599d70, ebp = 0 --- Uptime: 8h36m2s Physical memory: 3894 MB Dumping 296 MB:Aborting dump due to I/O error. status == 0xb, scsi status == 0x0 ** DUMP FAILED (ERROR 5) ** Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset: Stopping other CPUs 4096 MB Detected ProLiant System BIOS - P29 (09/15/2004) Copyright 1982, 2004 Hewlett-Packard Development Group, L.P. Processor 1 initialized at 3.06 GHz/533 MHz(512 Kbyte L2) Advanced Memory Protection Mode: Advanced ECC Support Redundant ROM Detected - This system contains a valid backup system ROM. - pciconf -lv - hos...@pci0:0:0:0: class=0x06 card=0x chip=0x00141166 rev=0x33 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'Host Bridge (CNB20-HE)' class = bridge subclass = HOST-PCI hos...@pci0:0:0:1: class=0x06 card=0x chip=0x00141166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'Host Bridge (CNB20-HE)' class = bridge subclass = HOST-PCI hos...@pci0:0:0:2: class=0x06 card=0x chip=0x00141166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'Host Bridge (CNB20-HE)' class = bridge subclass = HOST-PCI vgap...@pci0:0:3:0: class=0x03 card=0x001e0e11 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI On-Board VGA for HP Proliant 350 G3 (Rage XL PCI)' class = display subclass = VGA no...@pci0:0:4:0: class=0x088000 card=0xb2060e11 chip=0xb2030e11 rev=0x01 hdr=0x00 vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'Integrated Lights Out Processor (iLo)' class = base peripheral no...@pci0:0:4:2: class=0x088000 card=0xb2060e11 chip=0xb2040e11 rev=0x01 hdr=0x00 vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'Integrated Lights Out Processor (iLo)' class = base peripheral is...@pci0:0:15:0: class=0x060100 card=0x02011166 chip=0x02011166 rev=0x93 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CSB5 PCI to ISA Bridge' class = bridge subclass = PCI-ISA atap...@pci0:0:15:1:
Re: RELENG_7 em problems (and RELENG_8)
Hi Jack, Just a followup to the email below. I now saw what appears to be the same problem on RELENG_8, but on a different nic and with VLANs. So not sure if this is a general em problem, a problem specific to some em NICs, or a TSO problem in general. The issue seemed to be triggered when I added a new vlan based on e...@pci0:14:0:0:class=0x02 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel PRO/1000 PL Network Adaptor (82573L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) pci14: ACPI PCI bus on pcib5 em3: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x6000-0x601f mem 0xe830-0xe831 irq 17 at device 0.0 on pci14 em3: Using MSI interrupt em3: [FILTER] em3: Ethernet address: 00:30:48:9f:eb:81 em3: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=2098VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:30:48:9f:eb:81 inet 10.255.255.254 netmask 0xfffc broadcast 10.255.255.255 media: Ethernet autoselect (1000baseT full-duplex) status: active I had to disable tso, rxcsum and txsum in order to see the devices on the other side of the two vlans trunked off em3. Unfortunately, the other sides were switches 100km and 500km away so I didnt have any tcpdump capabilities to diagnose the issue. I had already created one vlan off this NIC and all was fine. A few weeks later, I added a new one and I could no longer telnet into the remote switches from the local machine But, I could telnet into the switches from machines not on the problem box. Hence, it would appear to be a general TSO issue no ? I disabled tso on the nic (I didnt disable net.inet.tcp.tso as I forgot about that).. Still nothing. I could always ping the remote devices, but no tcp services. I then remembered this issue from before, so I tried disabling tso on the NIC. Still nothing. Then I disabled rxcsum and txcsum and I could then telnet into the remote devices. This newly observed issue was from a buildworld on Mon Jun 14 11:29:12 EDT 2010. I will try and recreate the issue locally again to see if I can trigger the problem on demand. Any thoughts on what it might be ? Perhaps an issue specific to certain em nics ? ---Mike At 04:31 PM 6/10/2010, Mike Tancsa wrote: Hi Jack, I am seeing some issues on RELENG_7 with a specific em nic e...@pci0:13:0:0:class=0x02 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (82573E)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) If I disable tso, I am not able to make a tcp connection into the host eg 0[psbgate1]# ifconfig em2 em2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC ether 00:30:48:9f:eb:80 inet 192.168.128.200 netmask 0xfff0 broadcast 192.168.128.207 media: Ethernet autoselect (100baseTX full-duplex) status: active 0[psbgate1]# ifconfig em2 -tso 0[psbgate1]# Looking at the pcap, the checksum is bad on the syn-ack. If I re-enable tso, it seems to be ok 16:18:01.113297 IP (tos 0x10, ttl 64, id 6339, offset 0, flags [DF], proto TCP (6), length 60) 192.168.128.196.54172 192.168.128.200.22: S, cksum 0x4e79 (correct), 3313156149:3313156149(0) win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 3376174416 0 16:18:01.123676 IP (tos 0x0, ttl 64, id 3311, offset 0, flags [DF], proto TCP (6), length 60) 192.168.128.200.22 192.168.128.196.54172: S, cksum 0x81c9 (incorrect (- 0x51f2), 1373042663:1373042663(0) ack 3313156150 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 1251567646 3376174416 em2: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x5000-0x501f mem 0xe820-0xe821 irq 16 at device 0.0 on pci13 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:30:48:9f:eb:80 pcib5: ACPI PCI-PCI bridge irq 16 at device 28.5 on pci0 pci14: ACPI PCI bus on pcib5 em3: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x6000-0x601f mem 0xe830-0xe831 irq 17 at device 0.0 on pci14 em3: Using MSI interrupt em3: [FILTER] em3: Ethernet address: 00:30:48:9f:eb:81 Also there is still the issue with http://lists.freebsd.org/pipermail/freebsd-stable/2009-November/052842.html in RELENG_7 ? ---Mike Mike Tancsa,
Re: RELENG_7 em problems (and RELENG_8)
I got the email, there are server outages around here today and people leaving for a long weekend, so not much getting done. I'll take some time and look into this after the weekend, ok? Jack On Fri, Jul 2, 2010 at 10:39 AM, Mike Tancsa m...@sentex.net wrote: Hi Jack, Just a followup to the email below. I now saw what appears to be the same problem on RELENG_8, but on a different nic and with VLANs. So not sure if this is a general em problem, a problem specific to some em NICs, or a TSO problem in general. The issue seemed to be triggered when I added a new vlan based on e...@pci0:14:0:0:class=0x02 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel PRO/1000 PL Network Adaptor (82573L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) pci14: ACPI PCI bus on pcib5 em3: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x6000-0x601f mem 0xe830-0xe831 irq 17 at device 0.0 on pci14 em3: Using MSI interrupt em3: [FILTER] em3: Ethernet address: 00:30:48:9f:eb:81 em3: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=2098VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:30:48:9f:eb:81 inet 10.255.255.254 netmask 0xfffc broadcast 10.255.255.255 media: Ethernet autoselect (1000baseT full-duplex) status: active I had to disable tso, rxcsum and txsum in order to see the devices on the other side of the two vlans trunked off em3. Unfortunately, the other sides were switches 100km and 500km away so I didnt have any tcpdump capabilities to diagnose the issue. I had already created one vlan off this NIC and all was fine. A few weeks later, I added a new one and I could no longer telnet into the remote switches from the local machine But, I could telnet into the switches from machines not on the problem box. Hence, it would appear to be a general TSO issue no ? I disabled tso on the nic (I didnt disable net.inet.tcp.tso as I forgot about that).. Still nothing. I could always ping the remote devices, but no tcp services. I then remembered this issue from before, so I tried disabling tso on the NIC. Still nothing. Then I disabled rxcsum and txcsum and I could then telnet into the remote devices. This newly observed issue was from a buildworld on Mon Jun 14 11:29:12 EDT 2010. I will try and recreate the issue locally again to see if I can trigger the problem on demand. Any thoughts on what it might be ? Perhaps an issue specific to certain em nics ? ---Mike At 04:31 PM 6/10/2010, Mike Tancsa wrote: Hi Jack, I am seeing some issues on RELENG_7 with a specific em nic e...@pci0:13:0:0:class=0x02 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (82573E)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) If I disable tso, I am not able to make a tcp connection into the host eg 0[psbgate1]# ifconfig em2 em2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=219bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC ether 00:30:48:9f:eb:80 inet 192.168.128.200 netmask 0xfff0 broadcast 192.168.128.207 media: Ethernet autoselect (100baseTX full-duplex) status: active 0[psbgate1]# ifconfig em2 -tso 0[psbgate1]# Looking at the pcap, the checksum is bad on the syn-ack. If I re-enable tso, it seems to be ok 16:18:01.113297 IP (tos 0x10, ttl 64, id 6339, offset 0, flags [DF], proto TCP (6), length 60) 192.168.128.196.54172 192.168.128.200.22: S, cksum 0x4e79 (correct), 3313156149:3313156149(0) win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 3376174416 0 16:18:01.123676 IP (tos 0x0, ttl 64, id 3311, offset 0, flags [DF], proto TCP (6), length 60) 192.168.128.200.22 192.168.128.196.54172: S, cksum 0x81c9 (incorrect (- 0x51f2), 1373042663:1373042663(0) ack 3313156150 win 65535 mss 1460,nop,wscale 3,sackOK,timestamp 1251567646 3376174416 em2: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x5000-0x501f mem 0xe820-0xe821 irq 16 at device 0.0 on pci13 em2: Using MSI interrupt em2: [FILTER] em2: Ethernet address: 00:30:48:9f:eb:80 pcib5: ACPI PCI-PCI bridge irq 16 at device 28.5 on pci0 pci14: ACPI PCI bus on pcib5 em3: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x6000-0x601f mem 0xe830-0xe831 irq 17 at device 0.0 on pci14 em3: Using MSI interrupt
Re: [stable 7] bge() related panic on an HP dl380g3 (32 bit)
On Fri, Jul 02, 2010 at 09:54:50AM -0700, Sean Bruno wrote: Started seeing this panic today from our BSD7 variant here at Yahoo. Our BGE driver is identical to 7stable at this time. Looks like all of these boxes are HP DL380G3 models. I have included the panic and pciconf -lv information. I assume that these machines have a variant of BGE that needs some kind of exception/quirk that I'm unaware of. Does your bge(4) driver include r208995? panic - Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 06 fault virtual address = 0xc fault code = supervisor read, page not present instruction pointer = 0x20:0xa053f8e6 stack pointer = 0x28:0xa9599978 frame pointer = 0x28:0xa95999a4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 33 (irq29: bge0) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper(a07a1271,a9599814,a04e7fe9,a07c029d,0,...) at db_trace_self_wrapper+0x26 kdb_backtrace(a07c029d,0,a076d19d,a9599820,0,...) at kdb_backtrace+0x29 panic(a076d19d,a07c15d2,a97b17a4,1,1,...) at panic+0x119 trap_fatal(a08a63e0,0,1,0,0,...) at trap_fatal+0x333 trap_pfault(a97e2800,a95998bc,dbdd,0,a9796250,...) at trap_pfault+0x260 trap(a9599938) at trap+0x462 calltrap() at calltrap+0x6 --- trap 0xc, eip = 0xa053f8e6, esp = 0xa9599978, ebp = 0xa95999a4 --- m_copym(a9df8800,5dc,5c8,1,0,...) at m_copym+0x36 ip_fragment(a9f66810,a9599a70,5dc,7,0,...) at ip_fragment+0x235 ip_output(a9df8800,0,a9599a44,0,0,a9ef6974,a085b740,0,0,a9ef6974,a05b54c1,a085b744,a085b74c,3e8) at ip_output+0xba6 tcp_respond(ab433448,a9f66810,a9f66824,a9df8800,0,...) at tcp_respond +0x395 tcp_dropwithreset(5a8,4,a9f66824,a9599b90,a9df8800,...) at tcp_dropwithreset+0xe9 tcp_input(a9df8800,14,a97966f0,a9599bf0,1,...) at tcp_input+0xcde ip_input(a9df8800,0,800,a97e2800,800,...) at ip_input+0x6f8 netisr_dispatch(2,a9df8800,10,3,0,...) at netisr_dispatch+0x55 ether_demux(a97e2800,a9df8800,3,0,3,...) at ether_demux+0x1c1 ether_input(a97e2800,a9df8800,a08b2480,a9cf4900,0,...) at ether_input +0x323 bge_rxeof(0,1,9157deaa,5647,100,...) at bge_rxeof+0x2c2 bge_intr(a97f7000,0,a079c70e,4fc,0,...) at bge_intr+0x132 ithread_loop(a97d9ad0,a9599d38,0,0,0,...) at ithread_loop+0x1ab fork_exit(a04c28c0,a97d9ad0,a9599d38) at fork_exit+0x99 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xa9599d70, ebp = 0 --- Uptime: 8h36m2s Physical memory: 3894 MB Dumping 296 MB:Aborting dump due to I/O error. status == 0xb, scsi status == 0x0 ** DUMP FAILED (ERROR 5) ** Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset: Stopping other CPUs 4096 MB Detected ProLiant System BIOS - P29 (09/15/2004) Copyright 1982, 2004 Hewlett-Packard Development Group, L.P. Processor 1 initialized at 3.06 GHz/533 MHz(512 Kbyte L2) Advanced Memory Protection Mode: Advanced ECC Support Redundant ROM Detected - This system contains a valid backup system ROM. - pciconf -lv - hos...@pci0:0:0:0: class=0x06 card=0x chip=0x00141166 rev=0x33 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'Host Bridge (CNB20-HE)' class = bridge subclass = HOST-PCI hos...@pci0:0:0:1: class=0x06 card=0x chip=0x00141166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'Host Bridge (CNB20-HE)' class = bridge subclass = HOST-PCI hos...@pci0:0:0:2: class=0x06 card=0x chip=0x00141166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'Host Bridge (CNB20-HE)' class = bridge subclass = HOST-PCI vgap...@pci0:0:3:0: class=0x03 card=0x001e0e11 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'ATI On-Board VGA for HP Proliant 350 G3 (Rage XL PCI)' class = display subclass = VGA no...@pci0:0:4:0: class=0x088000 card=0xb2060e11 chip=0xb2030e11 rev=0x01 hdr=0x00 vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'Integrated Lights Out Processor (iLo)' class = base peripheral no...@pci0:0:4:2: class=0x088000 card=0xb2060e11 chip=0xb2040e11 rev=0x01 hdr=0x00 vendor = 'Compaq Computer Corp (Now owned by Hewlett-Packard)' device = 'Integrated Lights Out Processor (iLo)' class = base peripheral is...@pci0:0:15:0: class=0x060100 card=0x02011166
My kernel panics suck
I got my new 8-stable system up, and now I just have recurrent disk controller failures. The machine can't stay more than about ten minutes before it panics into a hung kernel, or simple reboots. Unfortunately, I know the root cause of the panics. If my computer is sitting on the table, then the kernel doesn't panic. If the computer is sitting on the desk, then it panics like mad. The table is wooden, the desk is metal. Of course, I'm also changing power too. On the table, I use a wall outlet, while on the desk I use my Smart UPS. Unfortunately, you can't really help me with this. I'm just writing in out of the hope that I'll get some sympathy for this problem. -- Schlake ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [stable 7] bge() related panic on an HP dl380g3 (32 bit)
On Fri, 2010-07-02 at 12:11 -0700, Pyun YongHyeon wrote: On Fri, Jul 02, 2010 at 09:54:50AM -0700, Sean Bruno wrote: Started seeing this panic today from our BSD7 variant here at Yahoo. Our BGE driver is identical to 7stable at this time. Looks like all of these boxes are HP DL380G3 models. I have included the panic and pciconf -lv information. I assume that these machines have a variant of BGE that needs some kind of exception/quirk that I'm unaware of. Does your bge(4) driver include r208995? It did not. I screwed up the report. The bge(4) driver under test was from r205616 (we built it in April). Did this panic look like the one fixed by r208995? Sean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [stable 7] bge() related panic on an HP dl380g3 (32 bit)
On Fri, Jul 02, 2010 at 12:24:23PM -0700, Sean Bruno wrote: On Fri, 2010-07-02 at 12:11 -0700, Pyun YongHyeon wrote: On Fri, Jul 02, 2010 at 09:54:50AM -0700, Sean Bruno wrote: Started seeing this panic today from our BSD7 variant here at Yahoo. Our BGE driver is identical to 7stable at this time. Looks like all of these boxes are HP DL380G3 models. I have included the panic and pciconf -lv information. I assume that these machines have a variant of BGE that needs some kind of exception/quirk that I'm unaware of. Does your bge(4) driver include r208995? It did not. I screwed up the report. The bge(4) driver under test was from r205616 (we built it in April). Did this panic look like the one fixed by r208995? Yes. Sean ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_7 em problems (and RELENG_8)
On Fri, Jul 02, 2010 at 01:39:22PM -0400, Mike Tancsa wrote: Hi Jack, Just a followup to the email below. I now saw what appears to be the same problem on RELENG_8, but on a different nic and with VLANs. So not sure if this is a general em problem, a problem specific to some em NICs, or a TSO problem in general. The issue seemed to be triggered when I added a new vlan based on e...@pci0:14:0:0:class=0x02 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel PRO/1000 PL Network Adaptor (82573L)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1) pci14: ACPI PCI bus on pcib5 em3: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x6000-0x601f mem 0xe830-0xe831 irq 17 at device 0.0 on pci14 em3: Using MSI interrupt em3: [FILTER] em3: Ethernet address: 00:30:48:9f:eb:81 em3: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST metric 0 mtu 1500 options=2098VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:30:48:9f:eb:81 inet 10.255.255.254 netmask 0xfffc broadcast 10.255.255.255 media: Ethernet autoselect (1000baseT full-duplex) status: active I had to disable tso, rxcsum and txsum in order to see the devices on the other side of the two vlans trunked off em3. Unfortunately, the other sides were switches 100km and 500km away so I didnt have any tcpdump capabilities to diagnose the issue. I had already created one vlan off this NIC and all was fine. A few weeks later, I added a new one and I could no longer telnet into the remote switches from the local machine But, I could telnet into the switches from machines not on the problem box. Hence, it would appear to be a general TSO issue no ? I disabled tso on the nic (I didnt disable net.inet.tcp.tso as I forgot about that).. Still nothing. I could always ping the remote devices, but no tcp services. I then remembered this issue from before, so I tried disabling tso on the NIC. Still nothing. Then I disabled rxcsum and txcsum and I could then telnet into the remote devices. This newly observed issue was from a buildworld on Mon Jun 14 11:29:12 EDT 2010. I will try and recreate the issue locally again to see if I can trigger the problem on demand. Any thoughts on what it might be ? Perhaps an issue specific to certain em nics ? http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 I'm not sure whether you're seeing the same issue though. I didn't have chance to try latest em(4) on stable/7. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_7 em problems (and RELENG_8)
At 03:36 PM 7/2/2010, Pyun YongHyeon wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=141843 I'm not sure whether you're seeing the same issue though. I didn't have chance to try latest em(4) on stable/7. Wow, what a detailed PR! That sure sounds like the issue I am seeing as well. I am just setting up another box to try and recreate the issue ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net 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 freebsd-stable-unsubscr...@freebsd.org
Re: My kernel panics suck
On Fri, Jul 2, 2010 at 9:18 PM, William D. Colburn (Schlake) schl...@gmail.com wrote: I got my new 8-stable system up, and now I just have recurrent disk controller failures. The machine can't stay more than about ten minutes before it panics into a hung kernel, or simple reboots. Unfortunately, I know the root cause of the panics. If my computer is sitting on the table, then the kernel doesn't panic. If the computer is sitting on the desk, then it panics like mad. The table is wooden, the desk is metal. Of course, I'm also changing power too. On the table, I use a wall outlet, while on the desk I use my Smart UPS. Unfortunately, you can't really help me with this. I'm just writing in out of the hope that I'll get some sympathy for this problem. Yuck...! If you have an electrical insulation problem, and your desk is metal, I'd _really_ urge you to replace your hardware completely, or have it properly insulated by a professional electrician. An electric shock could cause real pain() and panic(). ;-) But seriously, if that's the only reason for the panics, it's a pretty strong hint that you have an electrical problem: when ICs are underpowered, they tend to behave erratically. -- Schlake -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: My kernel panics suck
On 07/02/2010 16:29, C. P. Ghost wrote: On Fri, Jul 2, 2010 at 9:18 PM, William D. Colburn (Schlake) schl...@gmail.com wrote: I got my new 8-stable system up, and now I just have recurrent disk controller failures. The machine can't stay more than about ten minutes before it panics into a hung kernel, or simple reboots. Unfortunately, I know the root cause of the panics. If my computer is sitting on the table, then the kernel doesn't panic. If the computer is sitting on the desk, then it panics like mad. The table is wooden, the desk is metal. Of course, I'm also changing power too. On the table, I use a wall outlet, while on the desk I use my Smart UPS. Unfortunately, you can't really help me with this. I'm just writing in out of the hope that I'll get some sympathy for this problem. Yuck...! If you have an electrical insulation problem, and your desk is metal, I'd _really_ urge you to replace your hardware completely, or have it properly insulated by a professional electrician. An electric shock could cause real pain() and panic(). ;-) But seriously, if that's the only reason for the panics, it's a pretty strong hint that you have an electrical problem: when ICs are underpowered, they tend to behave erratically. -- Schlake -cpghost. Adding to this, though I find it unlikely but worth mentioning but you could be grounding out to a already charged surface through a screw in the case (laptop/desktop), check the bottom and cover up anything you find with black electrical tape and try again. Another route would be to grab a multimeter and test the metal table for a positive ? source. If that metal table also happens to be screwed down to the floor then take all the screws out as one maybe more could be running across some weird current. Regards, -- +-+-+-+-+-+ |j|h|e|l|l| +-+-+-+-+-+ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: My kernel panics suck
On Fri, Jul 02, 2010 at 07:35:14PM -0400, jhell wrote: On 07/02/2010 16:29, C. P. Ghost wrote: On Fri, Jul 2, 2010 at 9:18 PM, William D. Colburn (Schlake) schl...@gmail.com wrote: I got my new 8-stable system up, and now I just have recurrent disk controller failures. The machine can't stay more than about ten minutes before it panics into a hung kernel, or simple reboots. Unfortunately, I know the root cause of the panics. If my computer is sitting on the table, then the kernel doesn't panic. If the computer is sitting on the desk, then it panics like mad. The table is wooden, the desk is metal. Of course, I'm also changing power too. On the table, I use a wall outlet, while on the desk I use my Smart UPS. Unfortunately, you can't really help me with this. I'm just writing in out of the hope that I'll get some sympathy for this problem. Yuck...! If you have an electrical insulation problem, and your desk is metal, I'd _really_ urge you to replace your hardware completely, or have it properly insulated by a professional electrician. An electric shock could cause real pain() and panic(). ;-) But seriously, if that's the only reason for the panics, it's a pretty strong hint that you have an electrical problem: when ICs are underpowered, they tend to behave erratically. -- Schlake -cpghost. Adding to this, though I find it unlikely but worth mentioning but you could be grounding out to a already charged surface through a screw in the case (laptop/desktop), check the bottom and cover up anything you find with black electrical tape and try again. Another route would be to grab a multimeter and test the metal table for a positive ? source. If that metal table also happens to be screwed down to the floor then take all the screws out as one maybe more could be running across some weird current. I'm a little surprised everyone's focused on the desk/grounding rather than the UPS. The OP doesn't state whether or not he's using a laptop either (it matters). I'm not denying improper grounding could cause issues, but I'd expect to hear of the OP getting shocked or something along those lines rather than my storage controller acts silly. Ripple or dirty power coming from a UPS -- because not all of them clean things up -- could cause all sorts of chaos hardware-wise too, and in some cases permanent damage. -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: My kernel panics suck
On Fri, Jul 2, 2010 at 5:49 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: Ripple or dirty power coming from a UPS -- because not all of them clean things up -- could cause all sorts of chaos hardware-wise too, and in some cases permanent damage. The UPS is actually my biggest suspect. It was an expensive one, but it is well over five years old now. As I told someone privately, though, I have a broken ankle, and this is my disk server with about 9T of spinning disk in it. It is hard for me to move currently. -- -- Schlake ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: My kernel panics suck
On Fri, Jul 2, 2010 at 5:40 PM, William D. Colburn (Schlake) schl...@gmail.com wrote: On Fri, Jul 2, 2010 at 5:49 PM, Jeremy Chadwick free...@jdc.parodius.com wrote: Ripple or dirty power coming from a UPS -- because not all of them clean things up -- could cause all sorts of chaos hardware-wise too, and in some cases permanent damage. The UPS is actually my biggest suspect. It was an expensive one, but it is well over five years old now. As I told someone privately, though, I have a broken ankle, and this is my disk server with about 9T of spinning disk in it. It is hard for me to move currently. If your system // storage controller has an event log (IPMI/RAID?) I would check to see what's reported by the system at the time of failure. Some servers also record events into the BMC (going back to IPMI) and display trouble codes on the LCDs (like Dell). It could be an issue with the power supply as well -- see whether or not you can spin up the disks a little slower (there are knobs in the kernel you can set to slow down detection so things work), or take some of the RAID members/volumes offline before booting up so you can power them down safely? If your system has a redundant power supply, try using the other one to see whether or not the issue persists. As for ruling out the UPS, try plugging the machine straight into the wall -- does it work? HTH, -Garrett ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
