Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 14 Aug 2001 08:16:31 -0400
From:      Mike Tancsa <mike@sentex.net>
To:        "Michael M." <mikem@wmis.net>, freebsd-stable@freebsd.org
Subject:   Re: fxp SCB timeout problems, anyone have a solution?
Message-ID:  <5.1.0.14.0.20010814081137.0593b758@192.168.0.12>
In-Reply-To: <5.1.0.14.2.20010813181107.04174140@127.0.0.1>
References:  <20010810100632.D18533@nexus.root.com> <BBDEEDD2EB67D311A0240008C74B9345129C78@ntxmidcity.sdccd.cc.ca.us> <BBDEEDD2EB67D311A0240008C74B9345129C78@ntxmidcity.sdccd.cc.ca.us>

next in thread | previous in thread | raw e-mail | index | archive | help

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 order.=
=20
I have a very similar board as yours (AOpen)

fxp1: <Intel Pro/100 Ethernet> port 0xc400-0xc43f mem 0xd5101000-0xd5101fff=
=20
irq 11 at device 8.0 on pci1
fxp1: Ethernet address 00:01:80:05:d2:67
inphy1: <i82562ET 10/100 media interface> 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=
 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=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 65=
=20
>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=
=20
>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=
=20
>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
>=20
>Features=3D0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CM=
OV,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=20
>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=
=20
>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 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 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=
=20
>../../kern/kern_shutdown.c:580
>#3  0xc0213c76 in trap_fatal (frame=3D0xc025081c, eva=3D0) at=20
>../../i386/i386/trap.c:951
>#4  0xc021367f in trap (frame=3D{tf_fs =3D 16, tf_es =3D 16, tf_ds =3D=
 -65520,=20
>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,=
=20
> tf_trapno =3D 10, tf_err =3D 0, tf_eip =3D -1071567482, tf_cs =3D 8,
>       tf_eflags =3D 582, tf_esp =3D -1071567487, tf_ss =3D 15}) at=20
> ../../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.=
=20
>> 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.
>
>--------------------------------------------------------------------
>Mike Tancsa,                                      tel +1 519 651 3400
>Network Administration,                           mike@sentex.net
>Sentex Communications                             www.sentex.net
>Cambridge, Ontario Canada                         www.sentex.net/mike


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.1.0.14.0.20010814081137.0593b758>