Re: xl0: watchdog timeout
Matt Smith wrote: Matt Smith wrote: Jimmy Selgen wrote: On Fri, 2003-11-21 at 21:29, Kris Kennaway wrote: On Fri, Nov 21, 2003 at 09:22:49PM +0100, Jimmy Selgen wrote: I saw this with some of sam's locking changes that (temporarily) broke DUMMYNET. I see you're using ipfilter - it's possible that this configuration has not been well-tested. Are you passing much traffic through ipfilter on this box? The box in question is my workstation, so I guess i'm not passing that much traffic through ipfilter. Also, when I said that the NIC still worked, I might have mislead you a bit. I had about 5-10 timeouts while scp'ing the dmesg output to my other workstation. Data seems to move from userland to the kernel, then get stuck in buffers there for 10-15 seconds, generating timeouts, before they're shipped off. I assume this is expected behaviour when a NIC isnt behaving correctly. It would be helpful if you can do a binary search to narrow down when the problem started. What would you have me search ? I'm a faily seasoned C programmer (12 years experience, some of them doing RTOS kernel work), but dont know much about FreeBSD kernel development, or the process of checking out different kernel revisions. I've tried a build without IPFILTER, and the problem still exists. I've also tried booting with ACPI disabled, and the problem is still there. I have attached a copy of my kernel config file, in case i'm doing something wrong. snip kernel file I have just noticed that my xl0 card is misbehaving as well. I have a 3c905c in my desktop and noticed that an ftp of a file from another machine on the lan (100 meg switched) was only going at around 70KB/sec. Normally I get around 9MB/sec. A netstat -bi xl0 shows lots of errors: NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 Link#1 00:04:76:8d:c5:fd 3081878 217616 3778632119 2451968 6 368229701 0 I also have this in my messages file: xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 240 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 300 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 360 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 420 bytes I do not currently have any debugging options compiled into this kernel. FreeBSD fraggle.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Nov 18 20:05:52 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FRAGGLE i386 I am actually in the process of building a new world/kernel to update it again as I thought it might be something that's fixed. I unfortunatly can not boot the old kernel to see if it works fine in that because of the statfs changes so it *could* possibly be the NIC has gone funny. I also have a 3c905a and a 3c905b in my router machine and this is showing no issues at all with the same dated kernel. http://xtaz.net/ Matt. I am now running a 5.2-BETA kernel from today and still have the problem with my xl0 card here. I can only get a max throughput of around 110KB/sec through it. And I am getting huge amounts of errors in the interface stats (5 minutes after booting): NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 Link#1 00:04:76:8d:c5:fd 217042 1290 57669634 309460 0 208178476 0 So the question is, is this my network card has died and I need to throw it out or is it related to Jimmy Selgen's email about the watchdog timeouts? It's a shame I can't boot an old kernel to test really. Matt. I have done some testing on this. I've changed the network cable, switch port etc. No affect. I've found though that if I ftp this box and GET a file it goes at around 6MB/sec. But if I PUT a file it goes at 100KB/sec. Previously this has worked at around 9-10MB/sec both ways. I can't place a date on it though because I've not tried to do large file transfers for a long time and only just noticed it this week. So it looks like it is driver related I guess. The buffer scenario Jimmy reported looks likely. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS lockup issues and xl0 watchdog timeout
I've had a possible idea regarding the NFS issues. I'm wondering if perhaps my NFS issues are related to the other email thread I have going which is the xl0: watchdog timeouts etc. I had not noticed this until last week because it's not often I copy large files from one machine to another but doing an ftp/scp etc from one machine to the other I'm only getting 100KB/sec with a PUT from my nfsclient-nfsserver, and 6MB/sec with a GET. This used to go at 9-10MB/sec both ways. Thinking about it I think this started happening around the same time I started having NFS issues. My NFS issues are also only when writing to the server from the client, never the other way around. So this ties up with the throughput figure difference I get on FTP. Jimmy mentioned a watchdog timeout caused by what looked like a 10-15 second delay in a buffer going from userland to kernel? I guess if this is the case it could kill NFS as well. Tomorrow night I will change my xl0 card in this desktop for a spare realtek card I happen to have and test throughput and NFS. I'll let you know my results. It would be interesting to see if the other person who reported these NFS issues (soren) has a similar experience. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl0: watchdog timeout
Matt Smith wrote: Jimmy Selgen wrote: On Fri, 2003-11-21 at 21:29, Kris Kennaway wrote: On Fri, Nov 21, 2003 at 09:22:49PM +0100, Jimmy Selgen wrote: I saw this with some of sam's locking changes that (temporarily) broke DUMMYNET. I see you're using ipfilter - it's possible that this configuration has not been well-tested. Are you passing much traffic through ipfilter on this box? The box in question is my workstation, so I guess i'm not passing that much traffic through ipfilter. Also, when I said that the NIC still worked, I might have mislead you a bit. I had about 5-10 timeouts while scp'ing the dmesg output to my other workstation. Data seems to move from userland to the kernel, then get stuck in buffers there for 10-15 seconds, generating timeouts, before they're shipped off. I assume this is expected behaviour when a NIC isnt behaving correctly. It would be helpful if you can do a binary search to narrow down when the problem started. What would you have me search ? I'm a faily seasoned C programmer (12 years experience, some of them doing RTOS kernel work), but dont know much about FreeBSD kernel development, or the process of checking out different kernel revisions. I've tried a build without IPFILTER, and the problem still exists. I've also tried booting with ACPI disabled, and the problem is still there. I have attached a copy of my kernel config file, in case i'm doing something wrong. snip kernel file I have just noticed that my xl0 card is misbehaving as well. I have a 3c905c in my desktop and noticed that an ftp of a file from another machine on the lan (100 meg switched) was only going at around 70KB/sec. Normally I get around 9MB/sec. A netstat -bi xl0 shows lots of errors: NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 Link#1 00:04:76:8d:c5:fd 3081878 217616 3778632119 2451968 6 368229701 0 I also have this in my messages file: xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 240 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 300 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 360 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 420 bytes I do not currently have any debugging options compiled into this kernel. FreeBSD fraggle.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Nov 18 20:05:52 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FRAGGLE i386 I am actually in the process of building a new world/kernel to update it again as I thought it might be something that's fixed. I unfortunatly can not boot the old kernel to see if it works fine in that because of the statfs changes so it *could* possibly be the NIC has gone funny. I also have a 3c905a and a 3c905b in my router machine and this is showing no issues at all with the same dated kernel. Matt. I am now running a 5.2-BETA kernel from today and still have the problem with my xl0 card here. I can only get a max throughput of around 110KB/sec through it. And I am getting huge amounts of errors in the interface stats (5 minutes after booting): NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 Link#1 00:04:76:8d:c5:fd 217042 1290 57669634 309460 0 208178476 0 So the question is, is this my network card has died and I need to throw it out or is it related to Jimmy Selgen's email about the watchdog timeouts? It's a shame I can't boot an old kernel to test really. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
xl0: watchdog timeout
Hi I'm getting some strange xl0 timeout messages on 5.1-CURRENT (synced today). I've searched the archives, and it seems that this problem is related to ACPI (http://docs.freebsd.org/cgi/getmsg.cgi?fetch=608457+0+archive/2003/freebsd-current/20031109.freebsd-current) Strange thing is that this worked perfectly with FreeBSD-5.1-RELEASE. The NIC still works, just get xl0: watchdog timeout every now and then. I'm attaching a full dmesg in case you know what to look for. The hardware is : AMD Barton 2800 Asus A7V8X Deluxe 1024 mb. DDR333 Ram (PC2700 ?) Promise 20376 SATA raid and the 3x509-TX. /Jimmy Copyright (c) 1992-2003 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 5.1-CURRENT #3: Fri Nov 21 18:11:06 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GRUMPY Preloaded elf kernel /boot/kernel/kernel at 0xc0905000. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) XP 2800+ (2083.11-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x6a0 Stepping = 0 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc040AMIE,DSP,3DNow! real memory = 1073725440 (1023 MB) avail memory = 1033555968 (985 MB) Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface pcibios: BIOS version 2.10 Using $PIR table, 12 entries at 0xc00f2080 pcib0: Host to PCI bridge at pcibus 0 on motherboard pci0: PCI bus on pcib0 pci_cfgintr: 0:8 INTA BIOS irq 10 pci_cfgintr: 0:16 INTA BIOS irq 9 pci_cfgintr: 0:16 INTB BIOS irq 9 pci_cfgintr: 0:16 INTC BIOS irq 9 pci_cfgintr: 0:16 INTD BIOS irq 9 agp0: VIA Generic host to PCI bridge mem 0xf000-0xf7ff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci_cfgintr: 1:0 INTA BIOS irq 11 pci1: display, VGA at device 0.0 (no driver attached) fwohci0: VIA VT6306 port 0xd800-0xd87f mem 0xe480-0xe48007ff at device 7.0 on pci0 pci_cfgintr: 0:7 INTA routed to irq 10 fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channel is 8. fwohci0: EUI64 00:e0:18:00:00:0b:51:39 fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: IEEE1394(FireWire) bus on fwohci0 sbp0: SBP-2/SCSI over FireWire on firewire0 fwe0: Ethernet over FireWire on firewire0 if_fwe0: Fake Ethernet address: 02:e0:18:0b:51:39 fwohci0: Initiate bus reset fwohci0: BUS reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop = 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) atapci0: Promise PDC20376 SATA150 controller port 0xb800-0xb87f,0xd000-0xd00f,0xd400-0xd43f mem 0xe380-0xe381,0xe400-0xe4000fff irq 10 at device 8.0 on pci0 atapci0: [MPSAFE] ata2: at 0xe400 on atapci0 ata2: [MPSAFE] ata3: at 0xe400 on atapci0 ata3: [MPSAFE] ata4: at 0xe400 on atapci0 ata4: [MPSAFE] pci0: network, ethernet at device 9.0 (no driver attached) pci0: multimedia, video at device 10.0 (no driver attached) xl0: 3Com 3c905-TX Fast Etherlink XL port 0xb400-0xb43f at device 11.0 on pci0 pci_cfgintr: 0:11 INTA routed to irq 4 xl0: Ethernet address: 00:10:4b:3e:1d:b4 miibus0: MII bus on xl0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: multimedia, audio at device 14.0 (no driver attached) fwohci1: vendor=1102, dev=4001 fwohci1: 1394 Open Host Controller Interface mem 0xe200-0xe2003fff,0xe280-0xe28007ff at device 14.2 on pci0 pci_cfgintr: 0:14 INTB routed to irq 4 fwohci1: OHCI version 1.10 (ROM=0) fwohci1: No. of Isochronous channel is 4. fwohci1: EUI64 00:02:3c:00:91:06:b2:c4 fwohci1: Phy 1394a available S400, 2 ports. fwohci1: Link S400, max_rec 2048 bytes. firewire1: IEEE1394(FireWire) bus on fwohci1 sbp1: SBP-2/SCSI over FireWire on firewire1 fwe1: Ethernet over FireWire on firewire1 if_fwe1: Fake Ethernet address: 02:02:3c:06:b2:c4 fwohci1: Initiate bus reset fwohci1: BUS reset fwohci1: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire1: 1 nodes, maxhop = 0, cable IRM = 0 (me) firewire1: bus manager 0 (me) uhci0: VIA 83C572 USB controller port 0xa400-0xa41f irq 9 at device 16.0 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Microsoft Microsoft 5-Button Mouse with IntelliEye(TM), rev 1.10/3.00, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. uhub0: port error, restarting port 2 uhub0: port error, giving up port 2 uhci1: VIA 83C572 USB controller port 0xa000-0xa01f irq 9 at device 16.1 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: VIA 83C572 USB controller port 0x9800-0x981f irq 9
Re: xl0: watchdog timeout
On Fri, Nov 21, 2003 at 09:22:49PM +0100, Jimmy Selgen wrote: Hi I'm getting some strange xl0 timeout messages on 5.1-CURRENT (synced today). I've searched the archives, and it seems that this problem is related to ACPI (http://docs.freebsd.org/cgi/getmsg.cgi?fetch=608457+0+archive/2003/freebsd-current/20031109.freebsd-current) Strange thing is that this worked perfectly with FreeBSD-5.1-RELEASE. The NIC still works, just get xl0: watchdog timeout every now and then. I saw this with some of sam's locking changes that (temporarily) broke DUMMYNET. I see you're using ipfilter - it's possible that this configuration has not been well-tested. Are you passing much traffic through ipfilter on this box? It would be helpful if you can do a binary search to narrow down when the problem started. Kris pgp0.pgp Description: PGP signature
Re: xl0: watchdog timeout
On Fri, 2003-11-21 at 21:29, Kris Kennaway wrote: On Fri, Nov 21, 2003 at 09:22:49PM +0100, Jimmy Selgen wrote: I saw this with some of sam's locking changes that (temporarily) broke DUMMYNET. I see you're using ipfilter - it's possible that this configuration has not been well-tested. Are you passing much traffic through ipfilter on this box? The box in question is my workstation, so I guess i'm not passing that much traffic through ipfilter. Also, when I said that the NIC still worked, I might have mislead you a bit. I had about 5-10 timeouts while scp'ing the dmesg output to my other workstation. Data seems to move from userland to the kernel, then get stuck in buffers there for 10-15 seconds, generating timeouts, before they're shipped off. I assume this is expected behaviour when a NIC isnt behaving correctly. It would be helpful if you can do a binary search to narrow down when the problem started. What would you have me search ? I'm a faily seasoned C programmer (12 years experience, some of them doing RTOS kernel work), but dont know much about FreeBSD kernel development, or the process of checking out different kernel revisions. I've tried a build without IPFILTER, and the problem still exists. I've also tried booting with ACPI disabled, and the problem is still there. I have attached a copy of my kernel config file, in case i'm doing something wrong. # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # #http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.384 2003/05/18 20:39:15 ru Exp $ machine i386 #cpuI486_CPU #cpuI586_CPU cpu I686_CPU ident GRUMPY #To statically compile in device wiring instead of /boot/device.hints #hints GENERIC.hints #Default places to look for devices. #makeoptionsDEBUG=-g#Build kernel with gdb(1) debug symbols #optionsSCHED_4BSD #4BSD scheduler options SCHED_ULE #ULE scheduler options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MD_ROOT #MD is a potential root device options NFSCLIENT #Network Filesystem Client options NFSSERVER #Network Filesystem Server options NFS_ROOT#NFS usable as root device, requires NFSCLIENT options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS#Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 options SCSI_DELAY=15000#Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV# install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT# Print register bitfields in debug # output. Adds ~215k to driver. #optionsIPFILTER #optionsPFIL_HOOKS #optionsIPFILTER_LOG #optionsIPFILTER_DEFAULT_BLOCK options CPU_ATHLON_SSE_HACK options CPU_ENABLE_SSE options CPU_FASTER_5X86_FPU options IPSEC options IPSEC_ESP options IPSTEALTH # Debugging for use in -current #optionsDDB #Enable the kernel debugger
Re: xl0: watchdog timeout
Jimmy Selgen wrote: On Fri, 2003-11-21 at 21:29, Kris Kennaway wrote: On Fri, Nov 21, 2003 at 09:22:49PM +0100, Jimmy Selgen wrote: I saw this with some of sam's locking changes that (temporarily) broke DUMMYNET. I see you're using ipfilter - it's possible that this configuration has not been well-tested. Are you passing much traffic through ipfilter on this box? The box in question is my workstation, so I guess i'm not passing that much traffic through ipfilter. Also, when I said that the NIC still worked, I might have mislead you a bit. I had about 5-10 timeouts while scp'ing the dmesg output to my other workstation. Data seems to move from userland to the kernel, then get stuck in buffers there for 10-15 seconds, generating timeouts, before they're shipped off. I assume this is expected behaviour when a NIC isnt behaving correctly. It would be helpful if you can do a binary search to narrow down when the problem started. What would you have me search ? I'm a faily seasoned C programmer (12 years experience, some of them doing RTOS kernel work), but dont know much about FreeBSD kernel development, or the process of checking out different kernel revisions. I've tried a build without IPFILTER, and the problem still exists. I've also tried booting with ACPI disabled, and the problem is still there. I have attached a copy of my kernel config file, in case i'm doing something wrong. snip kernel file I have just noticed that my xl0 card is misbehaving as well. I have a 3c905c in my desktop and noticed that an ftp of a file from another machine on the lan (100 meg switched) was only going at around 70KB/sec. Normally I get around 9MB/sec. A netstat -bi xl0 shows lots of errors: NameMtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll xl01500 Link#1 00:04:76:8d:c5:fd 3081878 217616 3778632119 2451968 6 368229701 0 I also have this in my messages file: xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 180 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 240 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 300 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 360 bytes xl0: transmission error: 90 xl0: tx underrun, increasing tx start threshold to 420 bytes I do not currently have any debugging options compiled into this kernel. FreeBSD fraggle.xtaz.co.uk 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Nov 18 20:05:52 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FRAGGLE i386 I am actually in the process of building a new world/kernel to update it again as I thought it might be something that's fixed. I unfortunatly can not boot the old kernel to see if it works fine in that because of the statfs changes so it *could* possibly be the NIC has gone funny. I also have a 3c905a and a 3c905b in my router machine and this is showing no issues at all with the same dated kernel. Matt. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl0: watchdog timeout
On Fri, Nov 21, 2003 at 11:40:37PM +0100, Jimmy Selgen wrote: The box in question is my workstation, so I guess i'm not passing that much traffic through ipfilter. Also, when I said that the NIC still worked, I might have mislead you a bit. I had about 5-10 timeouts while scp'ing the dmesg output to my other workstation. Data seems to move from userland to the kernel, then get stuck in buffers there for 10-15 seconds, generating timeouts, before they're shipped off. I assume this is expected behaviour when a NIC isnt behaving correctly. OK, it's still possible something is triggering a locking bug. Or your problem could be elsewhere. It would be helpful if you can do a binary search to narrow down when the problem started. What would you have me search ? I'm a faily seasoned C programmer (12 years experience, some of them doing RTOS kernel work), but dont know much about FreeBSD kernel development, or the process of checking out different kernel revisions. You have a couple of choices..if you update your sources by cvsup, there's a date keyword you can use in your cvsupfile to select sources from that date. If you're using cvsup to fetch a local repository and then cvs to check out from there, cvs also has the -D keyword you can use to update to a date string. Using cvs is better, because you can easily control it on the level of individual file revisions once you get down to testing a few specific changes. Setting up cvs and cvsup are both documented on the freebsd website. Basically, if you can iterate through different dates, halving the date between the last kernel you know worked and the first kernel you know did not, to push the boundaries down, it will narrow down the range of commits that caused the problem. I've tried a build without IPFILTER, and the problem still exists. I've also tried booting with ACPI disabled, and the problem is still there. OK, that probably rules them out. I have attached a copy of my kernel config file, in case i'm doing something wrong. Looked OK to me. Kris pgp0.pgp Description: PGP signature
xl0 watchdog timeout
After cvsup and make world, I could't use xl0 and kernel said kernel: xl0: watchdog timeout. # dmesg [snip] xl0: 3Com 3c920B-EMB Integrated Fast Etherlink XL port 0xe400-0xe47f mem 0xea 02-0xea02007f irq 10 at device 18.0 on pci0 xl0: Ethernet address: 00:04:75:3c:6b:ad miibus0: MII bus on xl0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto -- Shin-ichi YOSHIMOTO [EMAIL PROTECTED] http://diary.waishi.jp/~yosimoto/diary/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl0 watchdog timeout
On Tue, 4 Nov 2003, Shin-ichi Yoshimoto wrote: After cvsup and make world, I could't use xl0 and kernel said kernel: xl0: watchdog timeout. # dmesg [snip] xl0: 3Com 3c920B-EMB Integrated Fast Etherlink XL port 0xe400-0xe47f mem 0xea 02-0xea02007f irq 10 at device 18.0 on pci0 xl0: Ethernet address: 00:04:75:3c:6b:ad miibus0: MII bus on xl0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto I had this last week and two people convinced me to exchange my NIC . I haven't seen this anymore since. Regards, Uli. -- Shin-ichi YOSHIMOTO [EMAIL PROTECTED] http://diary.waishi.jp/~yosimoto/diary/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] +---+ |Peter Ulrich Kruppa| | Wuppertal | | Germany | +---+ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: xl0 watchdog timeout
On 04-Nov-2003 Shin-ichi Yoshimoto wrote: After cvsup and make world, I could't use xl0 and kernel said kernel: xl0: watchdog timeout. # dmesg [snip] xl0: 3Com 3c920B-EMB Integrated Fast Etherlink XL port 0xe400-0xe47f mem 0xea 02-0xea02007f irq 10 at device 18.0 on pci0 xl0: Ethernet address: 00:04:75:3c:6b:ad miibus0: MII bus on xl0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Can you please provide a full dmesg? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: xl0 watchdog timeout
Subject: RE: xl0 watchdog timeout, On Tue, 04 Nov 2003 10:39:44 -0500 (EST), John Baldwin wrote: Can you please provide a full dmesg? yes. Copyright (c) 1992-2003 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 5.1-CURRENT #7: Tue Nov 4 19:11:26 JST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DAEMON Preloaded elf kernel /boot/kernel/kernel at 0xc0793000. Preloaded elf module /boot/kernel/linux.ko at 0xc07931f4. Preloaded elf module /boot/kernel/ipfw.ko at 0xc07932a0. Preloaded elf module /boot/kernel/mga.ko at 0xc079334c. ACPI APIC Table: VIA694 AWRDACPI Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) III CPU family 1266MHz (1267.16-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 1073676288 (1023 MB) avail memory = 1037688832 (989 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 Version 2 irqs 0-23 on motherboard Pentium Pro MTRR support enabled npx0: [FAST] npx0: math processor on motherboard npx0: INT 16 interface acpi0: VIA694 AWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 7 entries at 0xc00fdc80 acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x4008-0x400b on acpi0 acpi_cpu0: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_tz0: Thermal Zone on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pcib0: could not get PCI interrupt routing table for \\_SB_.PCI0 - AE_BAD_DATA pci0: ACPI PCI bus on pcib0 agp0: VIA Generic host to PCI bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 drm0: Matrox G400/G450 (AGP) mem 0xe700-0xe77f,0xe600-0xe6003fff,0xe400-0xe5ff irq 10 at device 0.0 on pci1 info: [drm] AGP at 0xe000 64MB info: [drm] Initialized mga 3.1.0 20021029 on minor 0 atapci0: Promise PDC20267 UDMA100 controller port 0xd000-0xd03f,0xcc00-0xcc03,0x1800-0x1807,0xc400-0xc403,0x1000-0x1007 mem 0xea00-0xea01 irq 19 at device 8.0 on pci0 atapci0: [MPSAFE] ata2: at 0x1000 on atapci0 ata2: [MPSAFE] ata3: at 0x1800 on atapci0 ata3: [MPSAFE] isab0: PCI-ISA bridge at device 17.0 on pci0 isa0: ISA bus on isab0 atapci1: VIA 8233C UDMA100 controller port 0xd400-0xd40f at device 17.1 on pci0 ata0: at 0x1f0 irq 14 on atapci1 ata0: [MPSAFE] ata1: at 0x170 irq 15 on atapci1 ata1: [MPSAFE] uhci0: VIA 83C572 USB controller port 0xd800-0xd81f irq 11 at device 17.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: VIA 83C572 USB controller port 0xdc00-0xdc1f irq 11 at device 17.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: VIA 83C572 USB controller port 0xe000-0xe01f irq 11 at device 17.4 on pci0 usb2: VIA 83C572 USB controller on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered xl0: 3Com 3c920B-EMB Integrated Fast Etherlink XL port 0xe400-0xe47f mem 0xea02-0xea02007f irq 10 at device 18.0 on pci0 xl0: Ethernet address: 00:04:75:3c:6b:ad miibus0: MII bus on xl0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: Option ROMs at iomem 0xd4000-0xdc7ff,0xcc000-0xd3fff,0xc-0xc8fff on isa0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to accept, logging limited to 5000 packets/entry by default acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% acd0: DVDROM Pioneer DVD-ROM ATAPIModel DVD-120 at ata1-master UDMA66 GEOM: create disk ad4 dp=0xc66ceb70 ad4: 117246MB Maxtor
RE: xl0 watchdog timeout
On 04-Nov-2003 Shin-ichi Yoshimoto wrote: Subject: RE: xl0 watchdog timeout, On Tue, 04 Nov 2003 10:39:44 -0500 (EST), John Baldwin wrote: Can you please provide a full dmesg? yes. Try disabling ACPI. ACPI is unable to route any of your PCI interrupts, so all your PCI interrupts are hosed. You can try to talk with the folks on acpi-jp@ to figure out if your AML can be patched. pcib0: ACPI Host-PCI bridge port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pcib0: could not get PCI interrupt routing table for \\_SB_.PCI0 - AE_BAD_DATA pci0: ACPI PCI bus on pcib0 -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: xl0 watchdog timeout
Subject: RE: xl0 watchdog timeout, On Tue, 04 Nov 2003 12:23:19 -0500 (EST), John Baldwin wrote: Try disabling ACPI. ACPI is unable to route any of your PCI interrupts, I tried disabling ACPI. It works fine. Thanks John. so all your PCI interrupts are hosed. You can try to talk with the folks on acpi-jp@ to figure out if your AML can be patched. OK. I will try to talk with the folks on acpi-jp. -- Shin-ichi YOSHIMOTO [EMAIL PROTECTED] http://diary.waishi.jp/~yosimoto/diary/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: xl0: watchdog timeout
On Fri, Oct 10, 2003 at 08:33:01PM -0700, Kris Kennaway wrote: Since upgrading to -CURRENT last night I have been getting a lot of watchdog timeouts on my xl0 device every time I put it under load: citusc17# grep watchdog timeout messages | wc -l 44 Oct 10 02:30:48 citusc17 kernel: xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xdc00-0xdc7f mem 0xff00-0xff7f irq 11 at device 17.0 on pci0 Oct 10 02:30:48 citusc17 kernel: xl0: Ethernet address: 00:c0:4f:0e:26:15 Oct 10 02:30:48 citusc17 kernel: miibus0: MII bus on xl0 Oct 10 02:30:48 citusc17 kernel: xlphy0: 3Com internal media interface on miibus0 Oct 10 02:30:48 citusc17 kernel: xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Is anyone else seeing this? In case anyone else is interested, this is apparently caused by r1.69 of ip_dummynet.c (locking commit by sam): backing out this commit fixes the problems. I provided details of my configuration to sam off-list and he is looking into it. Kris pgp0.pgp Description: PGP signature
xl0: watchdog timeout
Since upgrading to -CURRENT last night I have been getting a lot of watchdog timeouts on my xl0 device every time I put it under load: citusc17# grep watchdog timeout messages | wc -l 44 Oct 10 02:30:48 citusc17 kernel: xl0: 3Com 3c905B-TX Fast Etherlink XL port 0xdc00-0xdc7f mem 0xff00-0xff7f irq 11 at device 17.0 on pci0 Oct 10 02:30:48 citusc17 kernel: xl0: Ethernet address: 00:c0:4f:0e:26:15 Oct 10 02:30:48 citusc17 kernel: miibus0: MII bus on xl0 Oct 10 02:30:48 citusc17 kernel: xlphy0: 3Com internal media interface on miibus0 Oct 10 02:30:48 citusc17 kernel: xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Is anyone else seeing this? Kris pgp0.pgp Description: PGP signature
RE: More xl0 watchdog timeout probs
tunneling #pseudo-device faith 1 # IPv6-to-IPv4 relaying (translation) # The `bpf' pseudo-device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter #device snp # Snoop device # USB support #device uhci# UHCI PCI-USB interface #device ohci# OHCI PCI-USB interface #device usb # USB Bus (required) #device ukbd# Keyboard #device ulpt# Printer #device ums # Mouse # MISC #optionsALT_BREAK_TO_DEBUGGER Wed, 4 Apr 2001 (4:28pm +1000) Message: @ Hi Anil, @ @ For me it worked to remove the @ device pccard @ line in the kernel config. This causes me to lose support for @ 16bit pcmcia cards, but on the other hand the cardbus card does @ work properly. I have since been informed that it is all supposed @ to work, but I haven't had time or chance to upgrade to verify @ (I still run 010306). @ @ Hope this helps, @ /Johny @ @ PS. When you boot after having installed the kernel without pccard @ support, you well get a warning or two complaining that it can't @ attach to the pccard bus, which is fine, since that is the one @ that appears to cause the trouble. @ @ @ -Original Message- @ From: Anil Jangity [SMTP:[EMAIL PROTECTED]] @ Sent: Wednesday, April 04, 2001 4:08 AM @ To: [EMAIL PROTECTED] @ Cc: [EMAIL PROTECTED] @ Subject:More xl0 watchdog timeout probs @ @ [please include me in Cc as I am not subscribed to the list] @ @ @ I looked through nearly all threads containing this topic and I am still @ stuck. I have tried some of the solutions posted but to no avail: @ @ Src I am using: @ Current (Mar 30) SYS/ (April 2) @ @ @ I am seeing that xl0: chip is in D6 power mode -- setting to D0 notice and @ as someone (Bill?) suggested I commented out the power mode check in the @ source but no luck. @ @ People have said this could be a IRQ issue and I should try changing @ the IRQ but I am not sure how, the bios on here doesn't seem to support @ that (Dell Latitude CP). HINTS file was no help. @ @ One thing I noticed: @ uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xece0-0xecff irq 11 @ at device 1.2 on pci0 @ pccbb0: TI1131 PCI-CardBus Bridge irq 11 at device 3.0 on pci0 @ pccbb1: TI1131 PCI-CardBus Bridge irq 11 at device 3.1 on pci0 @ xl0: 3Com 3c575B Fast Etherlink XL port 0x3000-0x307f mem @ 0x4402-0x4403,0x44002080-0x440020ff,0x44002000-0x4400207f irq 11 @ at device 0.0 on cardbus0 @ @ Why are they ALL using irq11? Are they being shared? Is that normal? I @ disabled USB in the kernel but that didn't help this watchdog errors. @ @ Thanks for any help!! and sorry for this repetitous post. @ @ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
More xl0 watchdog timeout probs
| LAN Cardbus Card | 001 | Functions: Network Adaptor, Memory TUPLE: CFTABLE_ENTRY_CB [6]: 00 80 80 80 80 19 CIS reading done xl0: 3Com 3c575B Fast Etherlink XL port 0x3000-0x307f mem 0x4402-0x4403,0x44002080-0x440020ff,0x44002000-0x4400207f irq 11 at device 0.0 on cardbus0 xl0: chip is in D6 power mode -- setting to D0 xl0: Ethernet address: 00:50:04:29:ac:2e miibus0: MII bus on xl0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto cardbus1: Detaching card: no cards to detach! pccbb1: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44] xl0: watchdog timeout xl0: watchdog timeout xl0: no carrier - transceiver cable problem? HINTS: hint.fdc.0.at="isa" hint.fdc.0.port="0x3F0" hint.fdc.0.irq="6" hint.fdc.0.drq="2" hint.fd.0.at="fdc0" hint.fd.0.drive="0" hint.ata.0.at="isa" hint.ata.0.port="0x1F0" hint.ata.0.irq="14" hint.ata.1.at="isa" hint.ata.1.port="0x170" hint.ata.1.irq="15" hint.ata.1.disabled="1" hint.atkbdc.0.at="isa" hint.atkbdc.0.port="0x060" hint.atkbd.0.at="atkbdc" hint.atkbd.0.irq="1" hint.atkbd.0.flags="0x1" hint.psm.0.at="atkbdc" hint.psm.0.irq="12" hint.vga.0.at="isa" hint.sc.0.at="isa" hint.sc.0.flags="0x100" hint.vt.0.at="isa" hint.pmtimer.0.at="isa" hint.npx.0.at="nexus" hint.npx.0.port="0x0F0" hint.npx.0.irq="13" hint.apm.0.at="nexus" hint.apm.0.flags="0x20" hint.pcic.0.at="isa" hint.pcic.0.irq="0" hint.pcic.0.port="0x3e0" hint.pcic.0.maddr="0xd" hint.pcic.1.at="isa" hint.pcic.1.irq="7" hint.pcic.1.port="0x3e2" hint.pcic.1.maddr="0xd4000" hint.sio.0.at="isa" hint.sio.0.port="0x3F8" hint.sio.0.flags="0x10" hint.sio.0.irq="4" hint.sio.1.at="isa" hint.sio.1.port="0x2F8" hint.sio.1.irq="3" hint.sio.2.at="isa" hint.sio.2.disabled="1" hint.sio.2.port="0x3E8" hint.sio.2.irq="5" hint.sio.3.at="isa" hint.sio.3.disabled="1" hint.sio.3.port="0x2E8" hint.sio.3.irq="9" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NEWCARD xl0: watchdog timeout
On Wed, Feb 14, 2001 at 05:52:27PM -0500, Will Andrews wrote: On Wed, Feb 14, 2001 at 10:19:24PM +0100, Pierre DAVID wrote: I just upgraded my Dell Latitude LT from 4.2-RELEASE TO -current (just before 9h Feb): all is working perfectly with a GENERIC kernel, pccardd and a 3Com 3C589 Ethernet card. I hope you are aware that -CURRENT is experimental and at times can be extremely unstable. Many thanks for your attention. I am a regular -current user from at least 4 years, and I know what -current means. Also, NEWCARD is really not supposed to be used unless you are planning on working on it. If nobody is using NEWCARD because of such warning, I wonder when NEWCARD will be functionnal for joe user. Be aware that I already tried the same NEWCARD kernel from a Sony Vaio and another Dell. - with the 3Com 3C589, I cannot get anything from the network (ECHO packets are emitted, but nothing returns) Hmm, that's odd. More precisely, ECHO packets are emitted from the NEWCARD machine, ECHO reply are transmitted by the pinged host, but nothing is received by the NEWCARD machine, which is typical of an IRQ problem. - with a 3Com 3CCFE575BT-D (xl0) - which works like a charm with a Sony Vaio - I get lot of: xl0: watchdog timeout and all communications are sloow. I smell an IRQ conflict. Many thanks for your helpful diagnostic ;-) Pierre To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NEWCARD xl0: watchdog timeout
On Wed, Feb 14, 2001 at 10:19:24PM +0100, Pierre DAVID wrote: I just upgraded my Dell Latitude LT from 4.2-RELEASE TO -current (just before 9h Feb): all is working perfectly with a GENERIC kernel, pccardd and a 3Com 3C589 Ethernet card. I hope you are aware that -CURRENT is experimental and at times can be extremely unstable. Also, NEWCARD is really not supposed to be used unless you are planning on working on it. - with the 3Com 3C589, I cannot get anything from the network (ECHO packets are emitted, but nothing returns) Hmm, that's odd. - with a 3Com 3CCFE575BT-D (xl0) - which works like a charm with a Sony Vaio - I get lot of: xl0: watchdog timeout and all communications are sloow. I smell an IRQ conflict. -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
