HEAD UP: non-MPSAFE network drivers to be disabled (was: 8.0 network stack MPsafety goals (fwd))

Dear all:

Just as a reminder, we've just about reached the one month
date before 
IFF_NEEDSGIANT drivers are disabled in the build.  You can
find a description 
of the general problem and list of specific drivers below.

As USB work is on-going, I will *not* disable the USB
drivers at this time, 
but all other drivers in the list below will be disabled on
26 June.  They 
will remain in the tree, easily accessible for patch
distribution and 
re-enabling, until October, when any remaining non-MPSAFE
drivers will be 
deleted in 8.x.  FreeBSD 8.0 will not ship with
compatibility shims to support 
non-MPSAFE network device drivers.

Robert N M Watson
Computer Laboratory
University of Cambridge

---------- Forwarded message ----------
Date: Sun, 3 Feb 2008 20:59:05 +0000 (GMT)
From: Robert Watson <rwatsonFreeBSD.org>
To: archFreeBSD.org
Subject: 8.0 network stack MPsafety goals (fwd)


Only a few days after predicted, this is a reminder that
IFF_NEEDSGIANT network 
drivers are going to stop working in the forseeable future. 
Please review the 
attached driver list, and if you depend on or care about a
Giant-dependent 
device driver, take action to make sure it doesn't remain on
the list in a 
month's time!

(As far as I'm aware, the list has not changed since my
December posting.)

Robert N M Watson
Computer Laboratory
University of Cambridge

---------- Forwarded message ----------
Date: Mon, 24 Dec 2007 10:43:28 +0000 (GMT)
From: Robert Watson <rwatsonFreeBSD.org>
To: archFreeBSD.org
Subject: 8.0 network stack MPsafety goals


Dear all:

With the 7.0 release around the corner, many developers are
starting to think 
about (and in quite a few cases, work on) their goals for
8.0.  One of our 
on-going kernel projects has been the elimination of the
Giant lock, and that 
project has transformed into one of optimizating behavior on
increasing numbers 
of processors.

In 7.0, despite the noteworth accomplishment of eliminating
debug.mpsasfenet 
and conditional network stack Gian acquisition, we were
unable to fully 
eliminate the IFF_NEEDSGIANT flag, which controls the
conditional acquisition 
of the Giant lock around non-MPSAFE network device drivers. 
Primarily these 
drivers are aging ISA network device drivers, although there
are some 
exceptions, such as the USB stack.

This e-mail proposes the elimination of the IFF_NEEDSGIANT
flag and associated 
infrastructure in FreeBSD 8.0, meaning that all network
device drivers must be 
able to operate without the Giant lock (largely the case
already).  Remaining 
drivers using the IFF_NEEDSGIANT flag must either be
updated, or less ideally, 
removed.  I propose the following schedule:

Date		Goals
----		-----
26 Dec 2007	Post proposed schedule for flag and
infrastructure removal
 		Post affected driver list

26 Jan 2008	Repost proposed schedule for flag and
infrastructure removal
 		Post updated affected driver list

26 Feb 2008	Adjust boot-time printf for affect drivers to
generate a loud
 		warning.
 		Post updated affected driver list

26 May 2008	Post HEADS UP of impending driver disabling
 		Post updated affected driver list

26 Jun 2008	Disable build of all drivers requiring
IFF_NEEDSGIANT
 		Post updated affected driver list

26 Sep 2008	Post HEADS up of impending driver removal
 		Post updated affected driver list

26 Oct 2008	Delete source of all drivers requiring
IFF_NEEDSGIANT
 		Remove flag and infrastructure

Here is a list of potentially affected drivers:

Name	Bus		Man page description
---	---		--------------------
ar	ISA/PCI		synchronous Digi/Arnet device driver
arl	ISA		Aironet Arlan 655 wireless network adapter driver
awi	PCCARD		AMD PCnetMobile IEEE 802.11 PCMCIA wireless
network
 			driver
axe	USB		ASIX Electronics AX88172 USB Ethernet driver
cdce	USB		USB Communication Device Class Ethernet driver
cnw	PCCARD		Netwave AirSurfer wireless network driver
cs	ISA/PCCARD	Ethernet device driver
cue	USB		CATC USB-EL1210A USB Ethernet driver
ex	ISA/PCCARD	Ethernet device driver for the Intel
EtherExpress
 			Pro/10 and Pro/10+
fe	CBUS/ISA/PCCARD	Fujitsu MB86960A/MB86965A based Ethernet
adapters
ic	I2C		I2C bus system
ie	ISA		Ethernet device driver
kue	USB		Kawasaki LSI KL5KUSB101B USB Ethernet driver
oltr	ISA/PCI		Olicom Token Ring device driver
plip	PPBUS		printer port Internet Protocol driver
ppp	TTY		point to point protocol network interface
ray	PCCARD		Raytheon Raylink/Webgear Aviator PCCard driver
rue	USB		RealTek RTL8150 USB to Fast Ethernet controller
driver
rum	USB		Ralink Technology USB IEEE 802.11a/b/g wireless
 			network device
sbni	ISA/PCI		Granch SBNI12 leased line modem driver
sbsh	PCI		Granch SBNI16 SHDSL modem device driver
sl	TTY		slip network interface
snc	ISA/PCCARD	National Semiconductor DP8393X SONIC Ethernet
adapter
 			driver
sr	ISA/PCI		synchronous RISCom/N2 / WANic 400/405 device
driver
udav	USB		Davicom DM9601 USB Ethernet driver
ural	USB		Ralink Technology RT2500USB IEEE 802.11 driver
xe	PCCARD		Xircom PCMCIA Ethernet device driver
zyd	USB		ZyDAS ZD1211/ZD1211B USB IEEE 802.11b/g wireless
 			network device

In some cases, the requirement for Giant is a property of a
subsystem the 
driver depends on as the driver itself; for example, the tty
subsystem for SLIP 
and PPP, and the USB subsystem for a number of USB ethernet
and wireless 
drivers.  With most of a year before to go on the proposed
schedule, my hope is 
that we will have lots of time to address these issues, but
wanted to get a 
roadmap out from a network protocol stack architecture
perspective so that 
device driver and subsystem authors could have a schedule in
mind.

FYI, the following drivers also reference IFF_NEEDSGIANT,
but only in order to 
provide their own conditional MPSAFEty, which can be removed
without affecting 
device driver functionality (I believe):

Name	Bus		Man page description
---	---		--------------------
ce	PCI		driver for synchronous Cronyx Tau-PCI/32 WAN
adapters
cp	PCI		driver for synchronous Cronyx Tau-PCI WAN adapters
ctau	ISA		driver for synchronous Cronyx Tau WAN adapters
cx	ISA		driver for synchronous/asynchronous Cronyx Sigma
WAN
 			adapters

Developers and users of the above drivers are heavily
encouraged to update the 
drivers to remove dependence on Giant, and/or make other
contingency plans.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-archfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch

To unsubscribe, send any mail to
"freebsd-arch-unsubscribefreebsd.org"
_______________________________________________
freebsd-archfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch

To unsubscribe, send any mail to
"freebsd-arch-unsubscribefreebsd.org"
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

On Sat, 2008-05-24 at 11:20 +0100, Robert Watson wrote:
> Dear all:
> 
> Just as a reminder, we've just about reached the one
month date before 
> IFF_NEEDSGIANT drivers are disabled in the build.  You
can find a description 
> of the general problem and list of specific drivers
below.
> 
> As USB work is on-going, I will *not* disable the USB
drivers at this time, 
> but all other drivers in the list below will be
disabled on 26 June.  They 
> will remain in the tree, easily accessible for patch
distribution and 
> re-enabling, until October, when any remaining
non-MPSAFE drivers will be 
> deleted in 8.x.  FreeBSD 8.0 will not ship with
compatibility shims to support 
> non-MPSAFE network device drivers.
> 
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
> 
> ---------- Forwarded message ----------
> Date: Sun, 3 Feb 2008 20:59:05 +0000 (GMT)
> From: Robert Watson <rwatsonFreeBSD.org>
> To: archFreeBSD.org
> Subject: 8.0 network stack MPsafety goals (fwd)
> 
> 
> Only a few days after predicted, this is a reminder
that IFF_NEEDSGIANT network 
> drivers are going to stop working in the forseeable
future.  Please review the 
> attached driver list, and if you depend on or care
about a Giant-dependent 
> device driver, take action to make sure it doesn't
remain on the list in a 
> month's time!
> 
> (As far as I'm aware, the list has not changed since my
December posting.)
> 
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
> 
> ---------- Forwarded message ----------
> Date: Mon, 24 Dec 2007 10:43:28 +0000 (GMT)
> From: Robert Watson <rwatsonFreeBSD.org>
> To: archFreeBSD.org
> Subject: 8.0 network stack MPsafety goals
> 
> 
> Dear all:
> 
> With the 7.0 release around the corner, many developers
are starting to think 
> about (and in quite a few cases, work on) their goals
for 8.0.  One of our 
> on-going kernel projects has been the elimination of
the Giant lock, and that 
> project has transformed into one of optimizating
behavior on increasing numbers 
> of processors.
> 
> In 7.0, despite the noteworth accomplishment of
eliminating debug.mpsasfenet 
> and conditional network stack Gian acquisition, we were
unable to fully 
> eliminate the IFF_NEEDSGIANT flag, which controls the
conditional acquisition 
> of the Giant lock around non-MPSAFE network device
drivers.  Primarily these 
> drivers are aging ISA network device drivers, although
there are some 
> exceptions, such as the USB stack.
> 
> This e-mail proposes the elimination of the
IFF_NEEDSGIANT flag and associated 
> infrastructure in FreeBSD 8.0, meaning that all network
device drivers must be 
> able to operate without the Giant lock (largely the
case already).  Remaining 
> drivers using the IFF_NEEDSGIANT flag must either be
updated, or less ideally, 
> removed.  I propose the following schedule:
> 
> Date		Goals
> ----		-----
> 26 Dec 2007	Post proposed schedule for flag and
infrastructure removal
>  		Post affected driver list
> 
> 26 Jan 2008	Repost proposed schedule for flag and
infrastructure removal
>  		Post updated affected driver list
> 
> 26 Feb 2008	Adjust boot-time printf for affect drivers
to generate a loud
>  		warning.
>  		Post updated affected driver list
> 
> 26 May 2008	Post HEADS UP of impending driver
disabling
>  		Post updated affected driver list
> 
> 26 Jun 2008	Disable build of all drivers requiring
IFF_NEEDSGIANT
>  		Post updated affected driver list
> 
> 26 Sep 2008	Post HEADS up of impending driver removal
>  		Post updated affected driver list
> 
> 26 Oct 2008	Delete source of all drivers requiring
IFF_NEEDSGIANT
>  		Remove flag and infrastructure
> 
> Here is a list of potentially affected drivers:
> 
> Name	Bus		Man page description
> ---	---		--------------------
> ar	ISA/PCI		synchronous Digi/Arnet device driver
> arl	ISA		Aironet Arlan 655 wireless network adapter
driver
> awi	PCCARD		AMD PCnetMobile IEEE 802.11 PCMCIA wireless
network
>  			driver
> axe	USB		ASIX Electronics AX88172 USB Ethernet driver
> cdce	USB		USB Communication Device Class Ethernet
driver
> cnw	PCCARD		Netwave AirSurfer wireless network driver
> cs	ISA/PCCARD	Ethernet device driver
> cue	USB		CATC USB-EL1210A USB Ethernet driver
> ex	ISA/PCCARD	Ethernet device driver for the Intel
EtherExpress
>  			Pro/10 and Pro/10+
> fe	CBUS/ISA/PCCARD	Fujitsu MB86960A/MB86965A based
Ethernet adapters
> ic	I2C		I2C bus system
> ie	ISA		Ethernet device driver
> kue	USB		Kawasaki LSI KL5KUSB101B USB Ethernet driver
> oltr	ISA/PCI		Olicom Token Ring device driver
> plip	PPBUS		printer port Internet Protocol driver
> ppp	TTY		point to point protocol network interface
> ray	PCCARD		Raytheon Raylink/Webgear Aviator PCCard
driver
> rue	USB		RealTek RTL8150 USB to Fast Ethernet
controller driver
> rum	USB		Ralink Technology USB IEEE 802.11a/b/g
wireless
>  			network device
> sbni	ISA/PCI		Granch SBNI12 leased line modem driver
> sbsh	PCI		Granch SBNI16 SHDSL modem device driver
> sl	TTY		slip network interface
> snc	ISA/PCCARD	National Semiconductor DP8393X SONIC
Ethernet adapter
>  			driver
> sr	ISA/PCI		synchronous RISCom/N2 / WANic 400/405
device driver
> udav	USB		Davicom DM9601 USB Ethernet driver
> ural	USB		Ralink Technology RT2500USB IEEE 802.11
driver
> xe	PCCARD		Xircom PCMCIA Ethernet device driver
> zyd	USB		ZyDAS ZD1211/ZD1211B USB IEEE 802.11b/g
wireless
>  			network device
> 
> In some cases, the requirement for Giant is a property
of a subsystem the 
> driver depends on as the driver itself; for example,
the tty subsystem for SLIP 
> and PPP, and the USB subsystem for a number of USB
ethernet and wireless 
> drivers.  With most of a year before to go on the
proposed schedule, my hope is 
> that we will have lots of time to address these issues,
but wanted to get a 
> roadmap out from a network protocol stack architecture
perspective so that 
> device driver and subsystem authors could have a
schedule in mind.
> 
> FYI, the following drivers also reference
IFF_NEEDSGIANT, but only in order to 
> provide their own conditional MPSAFEty, which can be
removed without affecting 
> device driver functionality (I believe):
> 
> Name	Bus		Man page description
> ---	---		--------------------
> ce	PCI		driver for synchronous Cronyx Tau-PCI/32 WAN
adapters
> cp	PCI		driver for synchronous Cronyx Tau-PCI WAN
adapters
> ctau	ISA		driver for synchronous Cronyx Tau WAN
adapters
> cx	ISA		driver for synchronous/asynchronous Cronyx
Sigma WAN
>  			adapters
> 
> Developers and users of the above drivers are heavily
encouraged to update the 
> drivers to remove dependence on Giant, and/or make
other contingency plans.
> 
> Robert N M Watson
> Computer Laboratory
> University of Cambridge

I've created a quick table of these at the following
location:
http://wiki
.freebsd.org/NetworkNeedsGiant

Please everyone feel free to fill in the blanks. I'll try to
do it as
well as time permits.

-- 
Coleman Kane

On Sat, 24 May 2008, Coleman Kane wrote:

> I've created a quick table of these at the following
location: 
> http://wiki
.freebsd.org/NetworkNeedsGiant
>
> Please everyone feel free to fill in the blanks. I'll
try to do it as well 
> as time permits.

FWIW, I suspect fixing things like SLIP and kernel PPP are
fairly trivial once 
tty locking is in place -- a per-softc mutex and a bit of
locking in the 
obvious spots would likely do it without too much trouble. 
In some paths, it 
might be necessary to inject data via the netisr, if that's
not already being 
done (probably is) to avoid input/output lock order issues.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

On Sat, 24 May 2008, Coleman Kane wrote:

> I've created a quick table of these at the following
location: 
> http://wiki
.freebsd.org/NetworkNeedsGiant
>
> Please everyone feel free to fill in the blanks. I'll
try to do it as well 
> as time permits.

You might also want to cross-link with the SMPTODO page.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

On Sat, May 24, 2008 at 8:56 AM, Robert Watson
<rwatsonfreebsd.org> wrote:
>
> On Sat, 24 May 2008, Coleman Kane wrote:
>
>> I've created a quick table of these at the
following location:
>> http://wiki
.freebsd.org/NetworkNeedsGiant
>>
>> Please everyone feel free to fill in the blanks.
I'll try to do it as well
>> as time permits.
>
> FWIW, I suspect fixing things like SLIP and kernel PPP
are fairly trivial
> once tty locking is in place -- a per-softc mutex and a
bit of locking in
> the obvious spots would likely do it without too much
trouble.  In some
> paths, it might be necessary to inject data via the
netisr, if that's not
> already being done (probably is) to avoid input/output
lock order issues.

ppp_tty.c is kind of hairy and rather stale.  I'd be
inclined to drop
strong hints about switching to either userland ppp(8), or
mpd +
netgraph if you want packets to stay in the kernel path and
avoid
userland.

I was once a big user of pppd(8) and if_ppp.c / ppp_tty.c
and
maintained them for a while.  But I use ppp(8) now and have
no
interest in maintaining it anymore.

pppd/if_ppp.c/ppp_tty.c is many many years stale compared to
what its
vendor supplies.

And, I think if_sl.c could probably do the same treatment. 
It would
probably be a better investment in time to write a userland
slip
driver and if_tun.c and/or write a ng_slip.c module
-- 
Peter Wemm - peterwemm.org; peterFreeBSD.org; peteryahoo-inc.com
"All of this is for nothing if we don't go to the
stars" - JMS/B5
"If Java had true garbage collection, most programs
would delete
themselves upon execution." -- Robert Sewell
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

On May 25, 2008, at 02:58 , Robert Watson wrote:
> While I'd be quite supportive of something along these
lines, I  
> think it probably is more work to port SLIP to
userspace than to  
> hack the current code a little bit to be MPSAFE,
assuming it remains  
> supported with the revised tty code.  SLIP is a fairly
straight- 
> forward piece of code, as long as you don't try to
understand the  
> line discipline stuff. 

Given that this is (a) 2008 and (b) 8.x we're talking about,
are there  
really that many consumers of SLIP to warrant it being
carried forward  
at all?

Seems to me that it would not be unreasonable to give a
heads up that  
the current kernel-space ppp/slip (and, for that matter,
plip) drivers  
are going away some time before 8.0-RELEASE, pppd is more
than  
adequately replaced by userland-ppp or netgraph, and if
there's some  
critical need by someone to have SLIP and/or PLIP, then
they'll need  
to step up to the plate to do the necessary
re-implementation.

Or stick with 7.x, which would be unaffected by this.

We have a lot of network drivers that are potentially up for
axing  
with the move to MPSAFE.  Why not push just a little harder
and slice  
out some serious legacy code?

It's all well and good to be able to say that the current
release of  
the kernel supports hardware that hasn't been used, other
than in  
idiosyncratic situations (yes, ahc(4), I'm looking at you)
for 5+  
years, but it seems that we have an opportunity here to
break out the  
Danish Ax[tm] in anger, and do some heavy-duty culling
before 8.0-REL.

-aDe

_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

On Mon, 26 May 2008, Ade Lovett wrote:

> On May 25, 2008, at 02:58 , Robert Watson wrote:
>
>> While I'd be quite supportive of something along
these lines, I think it 
>> probably is more work to port SLIP to userspace
than to hack the current 
>> code a little bit to be MPSAFE, assuming it remains
supported with the 
>> revised tty code.  SLIP is a fairly
straight-forward piece of code, as long 
>> as you don't try to understand the line discipline
stuff. 
>
> Given that this is (a) 2008 and (b) 8.x we're talking
about, are there 
> really that many consumers of SLIP to warrant it being
carried forward at 
> all?
>
> Seems to me that it would not be unreasonable to give a
heads up that the 
> current kernel-space ppp/slip (and, for that matter,
plip) drivers are going 
> away some time before 8.0-RELEASE, pppd is more than
adequately replaced by 
> userland-ppp or netgraph, and if there's some critical
need by someone to 
> have SLIP and/or PLIP, then they'll need to step up to
the plate to do the 
> necessary re-implementation.

The thread you're replying began with precisely such a heads
up. 

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

On Mon, May 26, 2008 at 05:34:09AM -0700 I heard the voice
of
Ade Lovett, and lo! it spake thus:
> 
> It's all well and good to be able to say that the
current release of
> the kernel supports hardware that hasn't been used,
other than in
> idiosyncratic situations (yes, ahc(4), I'm looking at
you) for 5+
> years, [...]

Neat, I didn't know I was idiosyncratic.

% uname -sr
FreeBSD 8.0-CURRENT

% grep ^ahc /var/run/dmesg.boot
ahc0: <Adaptec 2940 Ultra SCSI adapter> port
0x1000-0x10ff mem 0xf8001000-0xf8001fff irq 19 at device
11.0 on pci0
ahc0: [ITHREAD]
ahc1: <Adaptec aic7899 Ultra160 SCSI adapter> port
0x1400-0x14ff mem 0xf8002000-0xf8002fff irq 16 at device
13.0 on pci0
ahc1: [ITHREAD]
ahc2: <Adaptec aic7899 Ultra160 SCSI adapter> port
0x1800-0x18ff mem 0xf8003000-0xf8003fff irq 17 at device
13.1 on pci0
ahc2: [ITHREAD]

(all 3 in use)


-- 
Matthew Fuller     (MF4839)   |  fullermdover-yonder.net
Systems/Network Administrator |  http://www.over
-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

On Mon, 26 May 2008, Bruce M. Simpson wrote:

>> Given that this is (a) 2008 and (b) 8.x we're
talking about, are there 
>> really that many consumers of SLIP to warrant it
being carried forward at 
>> all?
>
> It's kind of a basic. [C]SLIP has been historically
handy to have around for 
> situations which warrant it. Mind you, given that we
have had tun(4) in the 
> tree for years now, a userland implementation of SLIP
is possible.
>
> As with all of these things it's down to someone
sitting down and doing it.
>
> I'm not volunteering to support any of this as I don't
use it myself (got 
> enough on my plate), merely pointing out that support
for SLIP in a system 
> is something many people have taken for granted over
the years, and for 
> prototyping something or providing IP over a simple
serial link without the 
> configuration overhead of PPP, SLIP is something
someone might be using.
>
> P.S. ahc(4) is commodity hardware, I think it can stay
right where it is 
> thank-you.

My suspicion is that getting SLIP basically working in
userspace is fairly 
straight forward, although I'm not sure how well-suited some
of our current 
admin tools (slattach, etc) are for the purpose.  If the new
tty code 
maintains support for line disciplines, updating the
existing SLIP code and 
adding locking code would probably be an equally sized (or
shorter) task. 
SLIP has its subtleties, but the current implementation is
relatively 
straight-forward, well-documented, etc.

Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"

On Mon, 26 May 2008, Matthew D. Fuller wrote:

> On Mon, May 26, 2008 at 05:34:09AM -0700 I heard the
voice of
> Ade Lovett, and lo! it spake thus:
>>
>> It's all well and good to be able to say that the
current release of the 
>> kernel supports hardware that hasn't been used,
other than in idiosyncratic 
>> situations (yes, ahc(4), I'm looking at you) for 5+
years, [...]
>
> Neat, I didn't know I was idiosyncratic.

Somehow it's always me who is idiosyncratic:

ahc0: <Adaptec aic7890/91 Ultra2 SCSI adapter> port
0xdc00-0xdcff mem 
0xf9fff000-0xf9ffffff irq 14 at device 11.0 on pci2 da0 at
ahc0 bus 0 target 0 
lun 0

Robert N M Watson
Computer Laboratory
University of Cambridge

>
> % uname -sr
> FreeBSD 8.0-CURRENT
>
> % grep ^ahc /var/run/dmesg.boot
> ahc0: <Adaptec 2940 Ultra SCSI adapter> port
0x1000-0x10ff mem 0xf8001000-0xf8001fff irq 19 at device
11.0 on pci0
> ahc0: [ITHREAD]
> ahc1: <Adaptec aic7899 Ultra160 SCSI adapter>
port 0x1400-0x14ff mem 0xf8002000-0xf8002fff irq 16 at
device 13.0 on pci0
> ahc1: [ITHREAD]
> ahc2: <Adaptec aic7899 Ultra160 SCSI adapter>
port 0x1800-0x18ff mem 0xf8003000-0xf8003fff irq 17 at
device 13.1 on pci0
> ahc2: [ITHREAD]
>
> (all 3 in use)
>
>
> -- 
> Matthew Fuller     (MF4839)   |  fullermdover-yonder.net
> Systems/Network Administrator |  http://www.over
-yonder.net/~fullermd/
>           On the Internet, nobody can hear you scream.
>
_______________________________________________
freebsd-currentfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-curre
nt
To unsubscribe, send any mail to
"freebsd-current-unsubscribefreebsd.org"