From owner-freebsd-stable Tue Aug 14 9:14:49 2001 Delivered-To: freebsd-stable@freebsd.org Received: from corp1.wmis.net (corp1.wmis.net [209.176.192.6]) by hub.freebsd.org (Postfix) with ESMTP id 3748B37B40A for ; Tue, 14 Aug 2001 09:14:38 -0700 (PDT) (envelope-from mikem@wmis.net) Received: from mike.wmis.net (gateway.wmis.net [216.109.194.253]) by corp1.wmis.net (8.9.3/8.9.3) with ESMTP id MAA33807; Tue, 14 Aug 2001 12:26:05 -0400 (EDT) (envelope-from mikem@wmis.net) Message-Id: <5.1.0.14.2.20010814120333.04649230@127.0.0.1> X-Sender: mikem/pop3.wmis.net@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 14 Aug 2001 12:13:30 -0400 To: Mike Tancsa , freebsd-stable@FreeBSD.ORG From: "Michael M." Subject: Re: fxp SCB timeout problems, anyone have a solution? In-Reply-To: <5.1.0.14.0.20010814081137.0593b758@192.168.0.12> References: <5.1.0.14.2.20010813181107.04174140@127.0.0.1> <20010810100632.D18533@nexus.root.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Good thing you asked.. this one slipped by me. It turns out I can duplicate the problem on both the A *AND* the A2 board.. when I was testing the machine with the A board, I didn't realize that it was plugged in at 100baseTX (f/d), while the A2 board was in running at "10baseT/UTP". I did some shuffling.. tried the A board in the 10baseT hub.. was able to= cause kernel panic with just a few ping -fs1500's ... BUT, when I plugged either machine into the 100baseTX switch, not only could I not crash them, but the fxp SCB timeout messages disappeared. (Perhaps I just couldn't generate enough data??). So.. to sum it up, both the A and A2 board will both have fxp SCB timeout messages, as well as kernel panics if running at 10baseT. The timeout messages and kernel panics go away if they're zipping along at 100baseTX. (Unless I'm not sending enough data to crash them at this higher speed...) Hope this helps! Mike At 08:16 AM 8/14/2001 -0400, Mike Tancsa wrote: >Very strange. I have been using the ET version of the board without the=20 >timeout problems. the EM however, I can reproduce them in very short=20 >order. I have a very similar board as yours (AOpen) > >fxp1: port 0xc400-0xc43f mem=20 >0xd5101000-0xd5101fff irq 11 at device 8.0 on pci1 >fxp1: Ethernet address 00:01:80:05:d2:67 >inphy1: on miibus1 >inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > >But I dont see these problems. Are you running in 10baseT ? 100BaseTX ?=20 >Half or full duplex ? > > ---Mike > >At 07:07 PM 8/13/2001 -0400, Michael M. wrote: >>Greetings.. >> >>I've been experiencing problems with fxp SCB timeouts too.. I've actually >>had the problem for almost a month now.. starting with a build from >>7/17/2001, 06:42:09 EDT. I installed FreeBSD on this system about >>a month ago, running a -STABLE build dated 7/17/2001. I've cvsup'd a >>couple of times since then, through my recent build today: >> >>FreeBSD 4.4-PRERELEASE (CORP2) #4: Mon Aug 13 14:34:10 EDT 2001 >> >>I'm still experiencing the same problem. For the past month, this machine >>would hard lock every few days, when it was sitting idle (not in= production), >>seemingly without reason. After reading some of the new posts about the >>fxp messages on the list, I decided to do some testing... If I set up a=20 >>ping -f >>to hammer away at the machine in question from just 2 other machines on >>the LAN, I can make corp2 (the machine with the fxp problem) kernel panic. >> >>At first it was surprising to me that this machine was experiencing a=20 >>problem, >>as it is running the same board as another machine that was just built= that >>has been running -STABLE fine for at least 2 months now (it's current= build >>date is 7/24/2001). After further investigation, I found corp2 was= actually >>running the Intel "D815EEA2" board - a slightly different model than the >>"D815EEA" board the other (working) machine is running. >> >>A snippet from Intel's website: >> >>What is the difference between Intel Desktop Boards D815EEA and >>D815EPEA and the Intel Desktop Boards D815EEA2 and D815EPEA2? >>The main differences are Intel=AE Desktop Boards D815EEA2 and D815EPEA2 >>now support two additional USB ports out the back panel (a total of=20 >>four). Also >>the game port on the back panel has been removed. >>Note: The D815EEA2 and D815EPEA2 require a different I/O shield and >>software image than the one used on D815EEA and D815EPEA. >> >>Possible bug in just the A2? >> >>Anyway.. here is the dmesg, and stack trace from the crash: >>(notice the fxp0 / SCB timeouts too..) >> >>Fatal trap 10: trace trap while in kernel mode >>instruction pointer =3D 0x8:0xc0212d86 >>stack pointer =3D 0x10:0xc025085c >>frame pointer =3D 0x10:0x0 >>code segment =3D base 0x0, limit 0xfffff, type 0x1b >> =3D DPL 0, pres 1, def32 1, gran 1 >>processor eflags =3D interrupt enabled, IOPL =3D 0 >>current process =3D Idle >>interrupt mask =3D none >>trap number =3D 10 >>panic: trace trap >> >>syncing disks... 4 4 4 4 4 4 4 fxp0: SCB timeout: 0x70, 0x0, 0x50 0x400 >>4 4 4 4 4 fxp0: SCB timeout: 0x80, 0x0, 0x50 0x400 >>fxp0: SCB timeout: 0x80, 0x0, 0x50 0x400 >>4 4 4 4 4 4 fxp0: SCB timeout: 0x80, 0x0, 0x50 0x400 >>fxp0: SCB timeout: 0x80, 0x0, 0x50 0x400 >>4 4 >>giving up on 4 buffers >>ad0: WRITE command timeout tag=3D0 serv=3D0 - resetting >>ata0: resetting devices .. done >>fxp0: SCB timeout: 0x80, 0x0, 0x50 0x400 >>fxp0: SCB timeout: 0x80, 0x0, 0x50 0x400 >>Uptime: 11m10s >> >>dumping to dev #ad/0x30001, offset 24787 >>dump ata0: resetting devices .. done >>254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237=20 >>236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219=20 >>218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201=20 >>200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183=20 >>182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165=20 >>164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147=20 >>146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129=20 >>128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111=20 >>110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90= =20 >>89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66=20 >>65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42=20 >>41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18=20 >>17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 succeeded >>Automatic reboot in 15 seconds - press a key on the console to abort >>Rebooting... >>Copyright (c) 1992-2001 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 4.4-PRERELEASE #4: Mon Aug 13 14:34:10 EDT 2001 >> root@corp2.:/usr/obj/usr/src/sys/CORP2 >>Timecounter "i8254" frequency 1193182 Hz >>Timecounter "TSC" frequency 996769942 Hz >>CPU: Pentium III/Pentium III Xeon/Celeron (996.77-MHz 686-class CPU) >> Origin =3D "GenuineIntel" Id =3D 0x68a Stepping =3D 10 >>Features=3D0x383f9ff >>real memory =3D 267124736 (260864K bytes) >>config> di sn0 >>config> di lnc0 >>config> di ie0 >>config> di cs0 >>config> q >>avail memory =3D 257245184 (251216K bytes) >>Preloaded elf kernel "kernel" at 0xc02d5000. >>Preloaded userconfig_script "/boot/kernel.conf" at 0xc02d509c. >>Pentium Pro MTRR support enabled >>md0: Malloc disk >>npx0: on motherboard >>npx0: INT 16 interface >>pcib0: on motherboard >>pci0: on pcib0 >>pci0: at 2.0 irq 11 >>pcib1: at device 30.0 on pci0 >>pci1: on pcib1 >>fxp0: port 0xdf00-0xdf3f mem=20 >>0xff8ff000-0xff8fffff irq 11 at device 8.0 on pci1 >>fxp0: Ethernet address 00:03:47:xx:xx:xx >>inphy0: on miibus0 >>inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >>isab0: at device 31.0 on pci0 >>isa0: on isab0 >>atapci0: port 0xffa0-0xffaf at device 31.1= =20 >>on pci0 >>ata0: at 0x1f0 irq 14 on atapci0 >>ata1: at 0x170 irq 15 on atapci0 >>pci0: at 31.2 irq 11 >>pci0: (vendor=3D0x8086, dev=3D0x2443) at 31.3 irq 9 >>pci0: at 31.4 irq 10 >>pci0: (vendor=3D0x8086, dev=3D0x2445) at 31.5 irq 9 >>orm0: