Re: fxp0: device timeout and sk0: watchdog timeout problems
On Wednesday 18 January 2006 00:36, Pyun YongHyeon wrote: > > > > > >atm I have no clue. How about updated sk(4)? > > >http://people.freebsd.org/~yongari/sk/if_sk.c > > >http://people.freebsd.org/~yongari/sk/if_skreg.h > > Hi again I am running your both versions (UP and SMP) now for almost 10 days without any problem. I think the problem is gone! thank's a lot João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp0: device timeout and sk0: watchdog timeout problems, onboard pcn problem
On Thu, Jan 19, 2006 at 06:35:38PM +0800, Ganbold wrote: [...] > > >My servers are now almost 24h up with the new sk driver and none of them is > >having the problem any more until now. Until this I had crontab run > >"ifconfig > >sk0 up" all 10 minutes what helped me so long. > > ifconffig sk0 up might be the solution until I find the problem. > > >On my SMP system when sk stopped it caused also watchdog timeout on all > >other > >NICs, on UP kernel not. > > This system is SMP system, so I guess that is why fxp is timing out too. > Ok. I can't sure but I have an updated driver which is supposed to fix the issue on SMP. http://people.freebsd.org/~yongari/sk/sk_test/if_sk.c http://people.freebsd.org/~yongari/sk/sk_test/if_skreg.h Hope this helps. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp0: device timeout and sk0: watchdog timeout problems, onboard pcn problem
At 06:08 PM 1/19/2006, you wrote: hi maybe a stupid hint but did you checked the TP cable and pin order? I often saw such problems when a gigabit connected to an older /10 HUB or when using incorrect pin orders on the cables or even to long cables I will ask person to check the cables. Appearently the sk down events are gone on my server with Pyun's patched drivers, did you checked if you compiled with them in the right place? I put sk drivers in /usr/src/sys/pci and compiled and installed kernel again. My servers are now almost 24h up with the new sk driver and none of them is having the problem any more until now. Until this I had crontab run "ifconfig sk0 up" all 10 minutes what helped me so long. ifconffig sk0 up might be the solution until I find the problem. On my SMP system when sk stopped it caused also watchdog timeout on all other NICs, on UP kernel not. This system is SMP system, so I guess that is why fxp is timing out too. Do you use interface polling? Check with vmstat -i because you may have overlapping IRQs and you cards may not support it. Look into the MB manual and see which pci slots are shared and don't use them or try another bios setting. What MB you are using? It is not using polling. I should ask the person to check the MB. gw# vmstat -i interrupt total rate irq1: atkbd0 188 0 irq6: fdc010 0 irq13: npx01 0 irq14: ata01 0 irq16: ahc0 ahc1 56984 41 irq18: skc0 ohci0 411469300 irq19: fxp0 104891 76 cpu0: timer 2738746 1997 cpu1: timer 2720830 1984 Total6033120 4400 you may try ifconfig fxp link0 to load its microcode which could help but in my opinion and experience the fxp cards are bad when using more than one and I through them all out but interesting is that they work well on until releng_5, btw the sk also works well on releng_5 Yes, I have at least several machines running FreeBSD-5.3 with 2 fxp cards and they seem to be OK. Also I have another 2 FreeBSD 6.0 machine with 2 fxp NIC and they are also fine. I tried onboard pcn card: [EMAIL PROTECTED]:9:0: class=0x02 card=0x20001014 chip=0x20001022 rev=0x36 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Am79C970/1/2/3/5/6 PCnet LANCE PCI Ethernet Controller' class= network subclass = ethernet However system crashes after connecting the cable. After reboot it is the same, crashes. Ganbold João ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp0: device timeout and sk0: watchdog timeout problems
On Thursday 19 January 2006 04:14, Ganbold wrote: > I have same problem even after updating the sk code to the latest: > > Jan 19 12:58:53 gw kernel: fxp0: device timeout > Jan 19 12:59:10 gw kernel: sk0: watchdog timeout > Jan 19 12:59:10 gw kernel: sk0: link state changed to DOWN > Jan 19 12:59:20 gw kernel: fxp0: device timeout > Jan 19 12:59:52 gw kernel: fxp0: device timeout > Jan 19 13:00:23 gw kernel: fxp0: device timeout > Jan 19 13:00:29 gw kernel: sk0: watchdog timeout > Jan 19 13:00:52 gw kernel: fxp0: device timeout > Jan 19 13:01:05 gw kernel: sk0: watchdog timeout > > Ganbold > hi maybe a stupid hint but did you checked the TP cable and pin order? I often saw such problems when a gigabit connected to an older /10 HUB or when using incorrect pin orders on the cables or even to long cables Appearently the sk down events are gone on my server with Pyun's patched drivers, did you checked if you compiled with them in the right place? My servers are now almost 24h up with the new sk driver and none of them is having the problem any more until now. Until this I had crontab run "ifconfig sk0 up" all 10 minutes what helped me so long. On my SMP system when sk stopped it caused also watchdog timeout on all other NICs, on UP kernel not. Do you use interface polling? Check with vmstat -i because you may have overlapping IRQs and you cards may not support it. Look into the MB manual and see which pci slots are shared and don't use them or try another bios setting. What MB you are using? you may try ifconfig fxp link0 to load its microcode which could help but in my opinion and experience the fxp cards are bad when using more than one and I through them all out but interesting is that they work well on until releng_5, btw the sk also works well on releng_5 João A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp0: device timeout and sk0: watchdog timeout problems
On Thu, Jan 19, 2006 at 03:52:58PM +0800, Ganbold wrote: > Hi, > > At 03:16 PM 1/19/2006, you wrote: > >On Thu, Jan 19, 2006 at 02:14:13PM +0800, Ganbold wrote: > > > I have same problem even after updating the sk code to the latest: > > > > > > Jan 19 12:58:53 gw kernel: fxp0: device timeout > > > Jan 19 12:59:10 gw kernel: sk0: watchdog timeout > > > Jan 19 12:59:10 gw kernel: sk0: link state changed to DOWN > > > > > > >Does interface down and up help your situation? > > This server is located 370km from where I'm now. People there just > reboot the server. > :-( > >It would be great to know what mwchan is used if your application > >was blocked. > > mwchan? > You can check it with ps(1) or top(1). > >Would you try another onboard NIC with fxp to narrow down the issue? > > Hard to say since it is on remote site. I could ask person there. > > >Since it's hard to reproduce the problem on my system I need more > >information. Would you show me more information for your network > >configuration and how to reproduce it? > > This machine is doing NAT, ipfw and it has squid from ports. It seems > like 3GB-9GB web traffic is going through per day. Hmm, it seems it's very complex setup. I guess diabling ipfw/NAT is not a option to you. Do you use "uid" rule to check packets in your ipfw rule? The "uid" is known to have issues on system with debug.mpsafenet=1. > gw# ifconfig -a > sk0: flags=8843 mtu 1500 > options=2b > inet 175.176.1.11 netmask 0x broadcast 175.176.255.255 > ether 00:11:95:e1:7d:16 > media: Ethernet autoselect (1000baseTX ) > status: active > pcn0: flags=8802 mtu 1500 > ether 00:06:29:50:e2:3c > media: Ethernet autoselect (none) > status: no carrier > fxp0: flags=8843 mtu 1500 > options=b > inet x.x.x.x netmask 0xfff0 broadcast x.x.x.x > ether 00:03:47:e0:64:3c > media: Ethernet autoselect (100baseTX ) > status: active > > Other onboard NIC is pcn: > [EMAIL PROTECTED]:9:0: class=0x02 card=0x20001014 chip=0x20001022 > rev=0x36 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = 'Am79C970/1/2/3/5/6 PCnet LANCE PCI Ethernet Controller' > class= network > subclass = ethernet > I heard this card also might have some problems, but I'm not sure. > Correct me if I'm wrong. > Sorry, I don't know how well pcn(4) works. Anyway I'll try to reproduce it here and let you know if I have more information. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp0: device timeout and sk0: watchdog timeout problems
Hi, At 03:16 PM 1/19/2006, you wrote: On Thu, Jan 19, 2006 at 02:14:13PM +0800, Ganbold wrote: > I have same problem even after updating the sk code to the latest: > > Jan 19 12:58:53 gw kernel: fxp0: device timeout > Jan 19 12:59:10 gw kernel: sk0: watchdog timeout > Jan 19 12:59:10 gw kernel: sk0: link state changed to DOWN > Does interface down and up help your situation? This server is located 370km from where I'm now. People there just reboot the server. It would be great to know what mwchan is used if your application was blocked. mwchan? Would you try another onboard NIC with fxp to narrow down the issue? Hard to say since it is on remote site. I could ask person there. Since it's hard to reproduce the problem on my system I need more information. Would you show me more information for your network configuration and how to reproduce it? This machine is doing NAT, ipfw and it has squid from ports. It seems like 3GB-9GB web traffic is going through per day. gw# ifconfig -a sk0: flags=8843 mtu 1500 options=2b inet 175.176.1.11 netmask 0x broadcast 175.176.255.255 ether 00:11:95:e1:7d:16 media: Ethernet autoselect (1000baseTX ) status: active pcn0: flags=8802 mtu 1500 ether 00:06:29:50:e2:3c media: Ethernet autoselect (none) status: no carrier fxp0: flags=8843 mtu 1500 options=b inet x.x.x.x netmask 0xfff0 broadcast x.x.x.x ether 00:03:47:e0:64:3c media: Ethernet autoselect (100baseTX ) status: active Other onboard NIC is pcn: [EMAIL PROTECTED]:9:0: class=0x02 card=0x20001014 chip=0x20001022 rev=0x36 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Am79C970/1/2/3/5/6 PCnet LANCE PCI Ethernet Controller' class= network subclass = ethernet I heard this card also might have some problems, but I'm not sure. Correct me if I'm wrong. Ganbold -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp0: device timeout and sk0: watchdog timeout problems
On Thu, Jan 19, 2006 at 02:14:13PM +0800, Ganbold wrote: > I have same problem even after updating the sk code to the latest: > > Jan 19 12:58:53 gw kernel: fxp0: device timeout > Jan 19 12:59:10 gw kernel: sk0: watchdog timeout > Jan 19 12:59:10 gw kernel: sk0: link state changed to DOWN > Jan 19 12:59:20 gw kernel: fxp0: device timeout > Jan 19 12:59:52 gw kernel: fxp0: device timeout > Jan 19 13:00:23 gw kernel: fxp0: device timeout > Jan 19 13:00:29 gw kernel: sk0: watchdog timeout > Jan 19 13:00:52 gw kernel: fxp0: device timeout > Jan 19 13:01:05 gw kernel: sk0: watchdog timeout > Does interface down and up help your situation? It would be great to know what mwchan is used if your application was blocked. Would you try another onboard NIC with fxp to narrow down the issue? Since it's hard to reproduce the problem on my system I need more information. Would you show me more information for your network configuration and how to reproduce it? -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp0: device timeout and sk0: watchdog timeout problems
I have same problem even after updating the sk code to the latest: Jan 19 12:58:53 gw kernel: fxp0: device timeout Jan 19 12:59:10 gw kernel: sk0: watchdog timeout Jan 19 12:59:10 gw kernel: sk0: link state changed to DOWN Jan 19 12:59:20 gw kernel: fxp0: device timeout Jan 19 12:59:52 gw kernel: fxp0: device timeout Jan 19 13:00:23 gw kernel: fxp0: device timeout Jan 19 13:00:29 gw kernel: sk0: watchdog timeout Jan 19 13:00:52 gw kernel: fxp0: device timeout Jan 19 13:01:05 gw kernel: sk0: watchdog timeout Ganbold At 10:36 AM 1/18/2006, you wrote: On Wed, Jan 18, 2006 at 10:28:43AM +0800, Ganbold wrote: > At 09:55 AM 1/18/2006, you wrote: > > > inet 127.0.0.1 netmask 0xff00 > > > > > > I used new if_sk codes from Pyun YongHyeon but after 2 days I got > > > same problem device timeout. > > > fxp is also timing out and I don't know why. > > > Any idea? > > > > > > >If sk(4) is the cause of problem fxp wouldn't be affected. > > I guess so. But fxp also times out almost at same time as sk does. > > >Of course it's possible for sk(4) to corrupt kernel memory structure > >but the possibility is low. While fixing sk(4) I pushed sk(4) to the > >limit on sparc64. I never met such timeouts. > > > >atm I have no clue. How about updated sk(4)? > >http://people.freebsd.org/~yongari/sk/if_sk.c > >http://people.freebsd.org/~yongari/sk/if_skreg.h > > Is it new update? Because I used your update dated on Jan 12 2006. Is > it newer than that? > Yes. > >Disabling sk(4) remedy your issue? > > There is another on-board pcn NIC, I will try if problem exists with sk > driver. > Ok. Thank you. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp0: device timeout and sk0: watchdog timeout problems
On Wed, Jan 18, 2006 at 11:36:46AM +0900, Pyun YongHyeon wrote: P> > > > same problem device timeout. P> > > > fxp is also timing out and I don't know why. P> > > > Any idea? P> > > > P> > > P> > >If sk(4) is the cause of problem fxp wouldn't be affected. P> > P> > I guess so. But fxp also times out almost at same time as sk does. Have you tried another motherboard? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp0: device timeout and sk0: watchdog timeout problems
On Wed, Jan 18, 2006 at 10:28:43AM +0800, Ganbold wrote: > At 09:55 AM 1/18/2006, you wrote: > > > inet 127.0.0.1 netmask 0xff00 > > > > > > I used new if_sk codes from Pyun YongHyeon but after 2 days I got > > > same problem device timeout. > > > fxp is also timing out and I don't know why. > > > Any idea? > > > > > > >If sk(4) is the cause of problem fxp wouldn't be affected. > > I guess so. But fxp also times out almost at same time as sk does. > > >Of course it's possible for sk(4) to corrupt kernel memory structure > >but the possibility is low. While fixing sk(4) I pushed sk(4) to the > >limit on sparc64. I never met such timeouts. > > > >atm I have no clue. How about updated sk(4)? > >http://people.freebsd.org/~yongari/sk/if_sk.c > >http://people.freebsd.org/~yongari/sk/if_skreg.h > > Is it new update? Because I used your update dated on Jan 12 2006. Is > it newer than that? > Yes. > >Disabling sk(4) remedy your issue? > > There is another on-board pcn NIC, I will try if problem exists with sk > driver. > Ok. Thank you. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp0: device timeout and sk0: watchdog timeout problems
At 09:55 AM 1/18/2006, you wrote: > inet 127.0.0.1 netmask 0xff00 > > I used new if_sk codes from Pyun YongHyeon but after 2 days I got > same problem device timeout. > fxp is also timing out and I don't know why. > Any idea? > If sk(4) is the cause of problem fxp wouldn't be affected. I guess so. But fxp also times out almost at same time as sk does. Of course it's possible for sk(4) to corrupt kernel memory structure but the possibility is low. While fixing sk(4) I pushed sk(4) to the limit on sparc64. I never met such timeouts. atm I have no clue. How about updated sk(4)? http://people.freebsd.org/~yongari/sk/if_sk.c http://people.freebsd.org/~yongari/sk/if_skreg.h Is it new update? Because I used your update dated on Jan 12 2006. Is it newer than that? Disabling sk(4) remedy your issue? There is another on-board pcn NIC, I will try if problem exists with sk driver. Ganbold. -- Regards, Pyun YongHyeon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: fxp0: device timeout and sk0: watchdog timeout problems
On Wed, Jan 18, 2006 at 09:27:09AM +0800, Ganbold wrote: > Hi, > > I'm having problem with sk and fxp NIC. I get fxp0: device timeout > and sk0: watchdog timeout problems and network stops responding. > > gw# uname -an > FreeBSD xx.xx.xx 6.0-STABLE FreeBSD 6.0-STABLE #2: Mon Jan 16 > 12:09:59 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GATEWAY i386 > > Message log: > Jan 17 18:15:22 gw kernel: fxp0: device timeout > Jan 17 18:15:25 gw kernel: sk0: watchdog timeout > Jan 17 18:15:25 gw kernel: sk0: link state changed to DOWN > Jan 17 18:15:41 gw kernel: sk0: watchdog timeout > Jan 17 18:15:53 gw kernel: fxp0: device timeout > Jan 17 18:16:29 gw kernel: fxp0: device timeout > Jan 17 18:17:07 gw kernel: fxp0: device timeout > Jan 17 18:17:19 gw kernel: sk0: watchdog timeout > Jan 17 18:17:42 gw kernel: fxp0: device timeout > Jan 17 18:17:59 gw kernel: sk0: watchdog timeout > Jan 17 18:18:19 gw kernel: sk0: watchdog timeout > Jan 17 18:18:53 gw kernel: sk0: watchdog timeout > > pciconf -lv output: > > [EMAIL PROTECTED]:1:0: class=0x02 card=0x4c001186 chip=0x4c001186 > rev=0x11 hdr=0x00 > vendor = 'D-Link System Inc' > device = 'DGE-530T Gigabit Ethernet Adapter' > class= network > subclass = ethernet > [EMAIL PROTECTED]:2:0: class=0x02 card=0x01f11014 chip=0x12298086 > rev=0x0c hdr=0x00 > vendor = 'Intel Corporation' > device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' > class= network > subclass = ethernet > > dmesg.boot: > > Copyright (c) 1992-2005 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.0-STABLE #2: Mon Jan 16 12:09:59 UTC 2006 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GATEWAY > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Pentium III/Pentium III Xeon/Celeron (548.54-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x673 Stepping = 3 > > Features=0x383fbff > real memory = 536854528 (511 MB) > avail memory = 515850240 (491 MB) > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > cpu0 (BSP): APIC ID: 1 > cpu1 (AP): APIC ID: 0 > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0 irqs 0-23 on motherboard > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfe88-0xfe8b on acpi0 > cpu0: on acpi0 > cpu1: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > skc0: port 0x2000-0x20ff mem > 0xfebfc000-0xfebf irq 18 at device 1.0 on pci0 > skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x1) > sk0: on skc0 > sk0: Ethernet address: 00:11:95:e1:7d:16 > miibus0: on sk0 > e1000phy0: on miibus0 > e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > 1000baseTX-FDX, auto > ahc0: port 0x2200-0x22ff mem > 0xfebfb000-0xfebfbfff irq 16 at device 6.0 on pci0 > ahc1: [GIANT-LOCKED] > aic7895C: Ultra Wide Channel B, SCSI Id=7, 32/253 SCBs > pci0: at device 10.0 (no driver attached) > isab0: port 0xfe00-0xfe0f at device 15.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf irq 18 at device 15.1 on > pci0 > ata0: on atapci0 > ata1: on atapci0 > ohci0: mem 0xff70-0xff700fff irq > 18 at device 15.2 on pci0 > ohci0: [GIANT-LOCKED] > usb0: OHCI version 1.0, legacy support > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 2 ports with 2 removable, self powered > pcib1: on acpi0 > pci1: on pcib1 > fxp0: port 0x4b00-0x4b3f mem > 0xc0fdf000-0xc0fd,0xc0fa-0xc0fb irq 19 at device 2.0 o > n pci1 > miibus1: on fxp0 > inphy0: on miibus1 > inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > fxp0: Ethernet address: 00:03:47:e0:64:3c > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model Generic PS/2 mouse, device ID 0 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FAST] > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > ppc0: port 0x378-0x37f irq 7 on acpi0 > ppc0: Generic chipset (NIBBLE-only) in C
fxp0: device timeout and sk0: watchdog timeout problems
Hi, I'm having problem with sk and fxp NIC. I get fxp0: device timeout and sk0: watchdog timeout problems and network stops responding. gw# uname -an FreeBSD xx.xx.xx 6.0-STABLE FreeBSD 6.0-STABLE #2: Mon Jan 16 12:09:59 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GATEWAY i386 Message log: Jan 17 18:15:22 gw kernel: fxp0: device timeout Jan 17 18:15:25 gw kernel: sk0: watchdog timeout Jan 17 18:15:25 gw kernel: sk0: link state changed to DOWN Jan 17 18:15:41 gw kernel: sk0: watchdog timeout Jan 17 18:15:53 gw kernel: fxp0: device timeout Jan 17 18:16:29 gw kernel: fxp0: device timeout Jan 17 18:17:07 gw kernel: fxp0: device timeout Jan 17 18:17:19 gw kernel: sk0: watchdog timeout Jan 17 18:17:42 gw kernel: fxp0: device timeout Jan 17 18:17:59 gw kernel: sk0: watchdog timeout Jan 17 18:18:19 gw kernel: sk0: watchdog timeout Jan 17 18:18:53 gw kernel: sk0: watchdog timeout pciconf -lv output: [EMAIL PROTECTED]:1:0: class=0x02 card=0x4c001186 chip=0x4c001186 rev=0x11 hdr=0x00 vendor = 'D-Link System Inc' device = 'DGE-530T Gigabit Ethernet Adapter' class= network subclass = ethernet [EMAIL PROTECTED]:2:0: class=0x02 card=0x01f11014 chip=0x12298086 rev=0x0c hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class= network subclass = ethernet dmesg.boot: Copyright (c) 1992-2005 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.0-STABLE #2: Mon Jan 16 12:09:59 UTC 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GATEWAY ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium III/Pentium III Xeon/Celeron (548.54-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x383fbff real memory = 536854528 (511 MB) avail memory = 515850240 (491 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xfe88-0xfe8b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 skc0: port 0x2000-0x20ff mem 0xfebfc000-0xfebf irq 18 at device 1.0 on pci0 skc0: DGE-530T Gigabit Ethernet Adapter rev. (0x1) sk0: on skc0 sk0: Ethernet address: 00:11:95:e1:7d:16 miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto ahc0: port 0x2200-0x22ff mem 0xfebfb000-0xfebfbfff irq 16 at device 6.0 on pci0 ahc1: [GIANT-LOCKED] aic7895C: Ultra Wide Channel B, SCSI Id=7, 32/253 SCBs pci0: at device 10.0 (no driver attached) isab0: port 0xfe00-0xfe0f at device 15.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf irq 18 at device 15.1 on pci0 ata0: on atapci0 ata1: on atapci0 ohci0: mem 0xff70-0xff700fff irq 18 at device 15.2 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pcib1: on acpi0 pci1: on pcib1 fxp0: port 0x4b00-0x4b3f mem 0xc0fdf000-0xc0fd,0xc0fa-0xc0fb irq 19 at device 2.0 o n pci1 miibus1: on fxp0 inphy0: on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:03:47:e0:64:3c atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A pmtimer0 on isa0 orm0: at iomem 0xc-0xc7fff,0xcd000-0xce7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 1.000 msec IP Filter: v4.1.8 initialized. Default = pass all, Logging = enabled ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to accept, logging limited to 100 packets/ entry by default Waiting 5 seconds for SCSI devices to settle ses0 at ahc1 bus 0 target 14
