Date: Mon, 13 Aug 2001 19:07:38 -0400 From: "Michael M." <mikem@wmis.net> To: freebsd-stable@freebsd.org Subject: Re: fxp SCB timeout problems, anyone have a solution? Message-ID: <5.1.0.14.2.20010813181107.04174140@127.0.0.1> In-Reply-To: <20010810100632.D18533@nexus.root.com> References: <BBDEEDD2EB67D311A0240008C74B9345129C78@ntxmidcity.sdccd.cc.ca.us> <BBDEEDD2EB67D311A0240008C74B9345129C78@ntxmidcity.sdccd.cc.ca.us>
next in thread | previous in thread | raw e-mail | index | archive | help
--=====================_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<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 0xff8ff000-0xff8fffff=
=20
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. 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
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
Greetings..<br><br>
I've been experiencing problems with fxp SCB timeouts too.. I've
actually<br>
had the problem for almost a month now.. starting with a build from<br>
7/17/2001, 06:42:09 EDT. I installed FreeBSD on this system about
<br>
a month ago, running a -STABLE build dated 7/17/2001. I've cvsup'd
a<br>
couple of times since then, through my recent build today:<br><br>
FreeBSD 4.4-PRERELEASE (CORP2) #4: Mon Aug 13 14:34:10 EDT 2001<br><br>
I'm still experiencing the same problem. For the past month, this
machine<br>
would hard lock every few days, when it was sitting idle (not in
production),<br>
seemingly without reason. After reading some of the new posts about
the <br>
fxp messages on the list, I decided to do some testing... If I set up a
ping -f<br>
to hammer away at the machine in question from just 2 other machines
on<br>
the LAN, I can make corp2 (the machine with the fxp problem) kernel
panic.<br><br>
At first it was surprising to me that this machine was experiencing a
problem,<br>
as it is running the same board as another machine that was just built
that <br>
has been running -STABLE fine for at least 2 months now (it's current
build<br>
date is 7/24/2001). After further investigation, I found corp2 was
actually <br>
running the Intel "D815EEA2" board - a slightly different model
than the <br>
"D815EEA" board the other (working) machine is
running.<br><br>
A snippet from Intel's website:<br><br>
<b>What is the difference between Intel Desktop Boards D815EEA and <br>
D815EPEA and the Intel Desktop Boards D815EEA2 and D815EPEA2?</b> <br>
The main differences are Intel=AE Desktop Boards D815EEA2 and D815EPEA2
<br>
now support two additional USB ports out the back panel (a total of
four). Also <br>
the game port on the back panel has been removed. <br>
<b>Note:</b> The D815EEA2 and D815EPEA2 require a different I/O shield
and <br>
software image than the one used on D815EEA and D815EPEA. <br><br>
Possible bug in just the A2?<br><br>
Anyway.. here is the dmesg, and stack trace from the crash:<br>
(notice the fxp0 / SCB timeouts too..)<br><br>
Fatal trap 10: trace trap while in kernel mode<br>
instruction pointer =3D 0x8:0xc0212d86<br>
stack pointer
=3D 0x10:0xc025085c<br>
frame pointer
=3D 0x10:0x0<br>
code
segment
=3D base 0x0, limit 0xfffff, type 0x1b<br>
&nbs=
p;
=3D DPL 0, pres 1, def32 1, gran 1<br>
processor eflags =3D interrupt
enabled, IOPL =3D 0<br>
current process =3D
Idle<br>
interrupt mask =3D
none<br>
trap
number &nbs=
p;
=3D 10<br>
panic: trace trap<br><br>
syncing disks... 4 4 4 4 4 4 4 fxp0: SCB timeout: 0x70, 0x0, 0x50
0x400<br>
4 4 4 4 4 fxp0: SCB timeout: 0x80, 0x0, 0x50 0x400<br>
fxp0: SCB timeout: 0x80, 0x0, 0x50 0x400<br>
4 4 4 4 4 4 fxp0: SCB timeout: 0x80, 0x0, 0x50 0x400<br>
fxp0: SCB timeout: 0x80, 0x0, 0x50 0x400<br>
4 4 <br>
giving up on 4 buffers<br>
ad0: WRITE command timeout tag=3D0 serv=3D0 - resetting<br>
ata0: resetting devices .. done<br>
fxp0: SCB timeout: 0x80, 0x0, 0x50 0x400<br>
fxp0: SCB timeout: 0x80, 0x0, 0x50 0x400<br>
Uptime: 11m10s<br><br>
dumping to dev #ad/0x30001, offset 24787<br>
dump ata0: resetting devices .. done<br>
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<br>
Automatic reboot in 15 seconds - press a key on the console to=20
abort<br>
Rebooting...<br>
Copyright (c) 1992-2001 The FreeBSD Project.<br>
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993,
1994<br>
The Regents of the University
of California. All rights reserved.<br>
FreeBSD 4.4-PRERELEASE #4: Mon Aug 13 14:34:10 EDT 2001<br>
root@corp2.:/usr/obj/usr/src/sys/CORP2<br>
Timecounter "i8254" frequency 1193182 Hz<br>
Timecounter "TSC" frequency 996769942 Hz<br>
CPU: Pentium III/Pentium III Xeon/Celeron (996.77-MHz 686-class=20
CPU)<br>
Origin =3D "GenuineIntel" Id =3D 0x68a Stepping
=3D 10<br>
Features=3D0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,=
CMOV,PAT,PSE36,MMX,FXSR,SSE><br>
real memory =3D 267124736 (260864K bytes)<br>
config> di sn0<br>
config> di lnc0<br>
config> di ie0<br>
config> di cs0<br>
config> q<br>
avail memory =3D 257245184 (251216K bytes)<br>
Preloaded elf kernel "kernel" at 0xc02d5000.<br>
Preloaded userconfig_script "/boot/kernel.conf" at
0xc02d509c.<br>
Pentium Pro MTRR support enabled<br>
md0: Malloc disk<br>
npx0: <math processor> on motherboard<br>
npx0: INT 16 interface<br>
pcib0: <Host to PCI bridge> on motherboard<br>
pci0: <PCI bus> on pcib0<br>
pci0: <Intel model 1132 VGA-compatible display device> at 2.0 irq
11<br>
pcib1: <Intel 82801BA/BAM (ICH2) Hub to PCI bridge> at device 30.0
on pci0<br>
pci1: <PCI bus> on pcib1<br>
fxp0: <Intel Pro/100 Ethernet> port 0xdf00-0xdf3f mem
0xff8ff000-0xff8fffff irq 11 at device 8.0 on pci1<br>
fxp0: Ethernet address 00:03:47:xx:xx:xx<br>
inphy0: <i82562ET 10/100 media interface> on miibus0<br>
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto<br>
isab0: <Intel 82801BA/BAM (ICH2) PCI to LPC bridge> at device 31.0
on pci0<br>
isa0: <ISA bus> on isab0<br>
atapci0: <Intel ICH2 ATA100 controller> port 0xffa0-0xffaf at
device 31.1 on pci0<br>
ata0: at 0x1f0 irq 14 on atapci0<br>
ata1: at 0x170 irq 15 on atapci0<br>
pci0: <Intel 82801BA/BAM (ICH2) USB controller USB-A> at 31.2 irq
11<br>
pci0: <unknown card> (vendor=3D0x8086, dev=3D0x2443) at 31.3 irq=20
9<br>
pci0: <Intel 82801BA/BAM (ICH2) USB controller USB-B> at 31.4 irq
10<br>
pci0: <unknown card> (vendor=3D0x8086, dev=3D0x2445) at 31.5 irq=20
9<br>
orm0: <Option ROMs> at iomem 0xc0000-0xcbfff,0xcc000-0xcd7ff on
isa0<br>
fdc0: <NEC 72065B or clone> at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2
on isa0<br>
fdc0: FIFO enabled, 8 bytes threshold<br>
fd0: <1440-KB 3.5" drive> on fdc0 drive 0<br>
atkbdc0: <Keyboard controller (i8042)> at port 0x60,0x64 on
isa0<br>
atkbd0: <AT Keyboard> flags 0x1 irq 1 on atkbdc0<br>
kbd0 at atkbd0<br>
psm0: failed to get data.<br>
psm0: <PS/2 Mouse> irq 12 on atkbdc0<br>
psm0: model Generic PS/2 mouse, device ID 0<br>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff
on isa0<br>
sc0: <System console> at flags 0x100 on isa0<br>
sc0: VGA <16 virtual consoles, flags=3D0x300><br>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0<br>
sio0: type 16550A<br>
sio1 at port 0x2f8-0x2ff irq 3 on isa0<br>
sio1: type 16550A<br>
ad0: 39266MB <IBM-DTLA-305040> [79780/16/63] at ata0-master
UDMA100<br>
acd0: CDROM <FX4824T> at ata1-master using PIO4<br>
Mounting root from ufs:/dev/ad0s1a<br><br>
----------<br><br>
corp2# nm -n /kernel | grep c0212d<br>
c0212d00 T __bb_init_func<br>
c0212d1c t idle<br>
c0212d64 t idle_loop<br>
c0212d84 T default_halt<br>
c0212d88 T cpu_switch<br>
corp2#<br><br>
----------<br><br>
(kgdb) where<br>
#0 dumpsys () at ../../kern/kern_shutdown.c:472<br>
#1 0xc0142f7b in boot (howto=3D256) at
../../kern/kern_shutdown.c:312<br>
#2 0xc0143348 in poweroff_wait (junk=3D0xc024856c, howto=3D-1071349574=
)
at ../../kern/kern_shutdown.c:580<br>
#3 0xc0213c76 in trap_fatal (frame=3D0xc025081c, eva=3D0) at
../../i386/i386/trap.c:951<br>
#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,=
<br>
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, <br>
tf_eflags =3D 582, tf_esp =3D -1071567487,
tf_ss =3D 15}) at ../../i386/i386/trap.c:613<br>
(kgdb)<br><br>
............................<br><br>
Is it likely a work-around can be found.. or do I need to scrap this
board?<br><br>
I hope this helps to shed some light on this problem... <br>
If any additional information is needed, please don't hesitate to
ask.<br><br>
Mike<br><br>
At 10:06 AM 8/10/2001 -0700, you wrote:<br>
<blockquote type=3Dcite class=3Dcite cite>><br>
>There is currently no fix for this. I went through the same thing
about 2<br>
>months ago with intel's newest i815 chipset MB. What I got from
David<br>
>Greenman is although the 82562 is seen as an fxp0 it was never
tested. I had<br>
>looked into this problem quiet a bit and forget exactly why it does
not<br>
>work, but it does not work. You might try upgrading to the newest
stable.<br><br>
Jonathan Lemon looked into this problem extensively and
found that there<br>
was actually some bugs in the new chip that were responsible for the
problem.<br>
There were some Intel workarounds, which were implemented, but I don't
think<br>
they solved the problem for all versions of the new chips.<br><br>
-DG<br><br>
David Greenman<br>
Co-founder, The FreeBSD Project -
<a href=3D"http://www.freebsd.org/"=
eudora=3D"autourl">http://www.freebsd.org</a><br>;
President, TeraSolutions, Inc. -
<a href=3D"http://www.terasolutions.com/"=
eudora=3D"autourl">http://www.terasolutions.com</a><br>;
Pave the road of life with opportunities.<br>
</blockquote></html>
--=====================_26925064==_.ALT--
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.2.20010813181107.04174140>