From owner-freebsd-stable Mon Aug 13 16: 8: 2 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 BDA6837B403 for ; Mon, 13 Aug 2001 16:07:29 -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 TAA32307 for ; Mon, 13 Aug 2001 19:20:03 -0400 (EDT) (envelope-from mikem@wmis.net) Message-Id: <5.1.0.14.2.20010813181107.04174140@127.0.0.1> X-Sender: mikem/pop3.wmis.net@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 13 Aug 2001 19:07:38 -0400 To: freebsd-stable@freebsd.org From: "Michael M." Subject: Re: fxp SCB timeout problems, anyone have a solution? In-Reply-To: <20010810100632.D18533@nexus.root.com> References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_26925064==_.ALT" 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 --=====================_26925064==_.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable 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 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= 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 four).= =20 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 236= =20 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217= =20 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198= =20 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179= =20 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160= =20 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141= =20 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122= =20 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103= =20 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79= =20 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54= =20 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29= =20 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1= =20 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 0xff8ff000-0xff8fffff= =20 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:

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 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 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 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
            &nbs= p;           =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           &nbs= p; =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 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 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=20 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=20 CPU)
  Origin =3D "GenuineIntel"  Id =3D 0x68a  Stepping =3D 10
  Features=3D0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,= CMOV,PAT,PSE36,MMX,FXSR,SSE>
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: <math processor> on motherboard
npx0: INT 16 interface
pcib0: <Host to PCI bridge> on motherboard
pci0: <PCI bus> on pcib0
pci0: <Intel model 1132 VGA-compatible display device> at 2.0 irq 11
pcib1: <Intel 82801BA/BAM (ICH2) Hub to PCI bridge> at device 30.0 on pci0
pci1: <PCI bus> on pcib1
fxp0: <Intel Pro/100 Ethernet> port 0xdf00-0xdf3f mem 0xff8ff000-0xff8fffff irq 11 at device 8.0 on pci1
fxp0: Ethernet address 00:03:47:xx:xx:xx
inphy0: <i82562ET 10/100 media interface> on miibus0
inphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
isab0: <Intel 82801BA/BAM (ICH2) PCI to LPC bridge> at device 31.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <Intel ICH2 ATA100 controller> port 0xffa0-0xffaf at device 31.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
pci0: <Intel 82801BA/BAM (ICH2) USB controller USB-A> at 31.2 irq 11
pci0: <unknown card> (vendor=3D0x8086, dev=3D0x2443) at 31.3 irq=20 9
pci0: <Intel 82801BA/BAM (ICH2) USB controller USB-B> at 31.4 irq 10
pci0: <unknown card> (vendor=3D0x8086, dev=3D0x2445) at 31.5 irq=20 9
orm0: <Option ROMs> at iomem 0xc0000-0xcbfff,0xcc000-0xcd7ff on isa0
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on isa0
atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0
kbd0 at atkbd0
psm0: failed to get data.
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: model Generic PS/2 mouse, device ID 0
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=3D0x300>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
ad0: 39266MB <IBM-DTLA-305040> [79780/16/63] at ata0-master UDMA100
acd0: CDROM <FX4824T> at ata1-master using PIO4
Mounting root from ufs:/dev/ad0s1a

----------

corp2# nm -n /kernel | grep c0212d
c0212d00 T __bb_init_func
c0212d1c t idle
c0212d64 t idle_loop
c0212d84 T default_halt
c0212d88 T cpu_switch
corp2#

----------

(kgdb) where
#0  dumpsys () at ../../kern/kern_shutdown.c:472
#1  0xc0142f7b in boot (howto=3D256) at ../../kern/kern_shutdown.c:312
#2  0xc0143348 in poweroff_wait (junk=3D0xc024856c, howto=3D-1071349574= ) at ../../kern/kern_shutdown.c:580
#3  0xc0213c76 in trap_fatal (frame=3D0xc025081c, eva=3D0) at ../../i386/i386/trap.c:951
#4  0xc021367f in trap (frame=3D{tf_fs =3D 16, tf_es =3D 16, tf_ds =3D -65520, tf_edi =3D -1, tf_esi =3D 0, tf_ebp =3D 0, tf_isp =3D -1071314872,=
      tf_ebx =3D 0, tf_edx =3D 75616, tf_ecx =3D -886177536, tf_eax =3D 0, tf_trapno =3D 10, tf_err =3D 0, tf_eip =3D -107156= 7482, tf_cs =3D 8,
      tf_eflags =3D 582, tf_esp =3D -1071567487, tf_ss =3D 15}) at ../../i386/i386/trap.c:613
(kgdb)

............................

Is it likely a work-around can be found.. or do I need to scrap this board?

I hope this helps to shed some light on this problem...
If any additional information is needed, please don't hesitate to ask.

Mike

At 10:06 AM 8/10/2001 -0700, you wrote:
>
>There is currently no fix for this. I went through the same thing about 2
>months ago with intel's newest i815 chipset MB. What I got from David
>Greenman is although the 82562 is seen as an fxp0 it was never tested. I had
>looked into this problem quiet a bit and forget exactly why it does not
>work, but it does not work. You might try upgrading to the newest stable.

   Jonathan Lemon looked into this problem extensively and found that there
was actually some bugs in the new chip that were responsible for the problem.
There were some Intel workarounds, which were implemented, but I don't think
they solved the problem for all versions of the new chips.

-DG

David Greenman
Co-founder, The FreeBSD Project - http://www.freebsd.org
President, TeraSolutions, Inc. - http://www.terasolutions.com
Pave the road of life with opportunities.
--=====================_26925064==_.ALT-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message