BT445C == No FreeBSD???
Troy Curtiss
BIOS, Diamond SS-PRO VLB video Card, and a BT445C VLB
SCSI Controller. I have been following this thread,
and have tried all of the hints in many a FAQ to get my
system to install FreeBSD. I am using the kcopy_bt kernel
code, my card (SCSI) is set to IRQ 12, DRQ 5, port 330. IT
seems to get recognized OK as well as my drives (Seagate 520MB
and Chinon CDrom), although hanging a few seconds for my
'allowing scsi devices to settle'. After FreeBSD has gone thru
all of the isa probing stuff, I get an error:
'stray interrupt b' and the system hangs for good. I have had
no problem installing FreeBSD on IDE machines, and I am certain
my SCSI chain is terminated correctly. Lastly, I hate to say it
but everything really screams (with respect to its environment)
under MS-DOG and Windoze. I see people getting their BT445S 's to
work all the time by playing with 'undocumented' switches, but my
board has none of these... just switches to select port, bios address,
floppy controller, and local bus clock speed (33mhz in my case). Any
help would be much appreciated... TIA
Troy Curtiss, HW/SW Engineer, Merix Corporation
Troy Curtiss
but something is still wrong. I've found that <sometimes> (indicating
an intermittent or unstable situation) I can make it thru the ISA
probe session, and get on to the install. The only time things start to
act up then is at the end of the install questions where the box actually
goes out and writes the partition info on the disk. Before my SCSI
controller loses sd0, I always get an 'ISA strayint b' error. From then
on out, I get error messages like 'sd0(aha0:0:0): timed out', which makes
me think that something in the BT445 driver is causing either itself or the
controller card itself to lose its mind. When I do a halt after breaking
out of the install, I hit return to soft-boot, and BIOS comes up OK, but
the SCSI controller BIOS doesn't [this leads me even further to believe
that something is poking the BT445C in a sensitive spot] come up at all
and the system hangs. I even power-cycled the hard drive itself whilest
getting the timeout errors, but that didn't help. SCSI terminations are just
fine, interrupts are all nice and non-conflictory, and all of the fancy
bios settings in both the AMI bios and the SCSI bios have been turned off
for safety's sake... but to no avail. I hope this isn't going to require
a new driver patch... Any help would be much appreciated. Thanks again.
Troy Curtiss
Julian Elischer
Troy Curtiss <tr...@tekgen.bv.tek.com> wrote:
>goes out and writes the partition info on the disk. Before my SCSI
>controller loses sd0, I always get an 'ISA strayint b' error. From then
>on out, I get error messages like 'sd0(aha0:0:0): timed out', which makes
>
the kernel is configured to use a different interrupt to that the board
is configured for....
check the interupt for the standard kernel, (I don't have one here) and
set the board to match....
julian
+----------------------------------+ ______ _ __
| __--_|\ Julian Elischer | \ U \/ / On assignment
| / \ jul...@tfs.com +------>x USA \ in a very strange
| ( OZ ) 300 lakeside Dr. oakland CA. \___ ___ | country !
+- X_.---._/ USA+(510) 645-3137(wk) \_/ \\
v
Theo de Raadt
the kernel is configured to use a different interrupt to that the board
is configured for....
check the interupt for the standard kernel, (I don't have one here) and
set the board to match....
I've decided to describe how the new NetBSD deals with this issue. I
think it rather neat, and also worthwhile for people to know about.
My kernel config file says:
controller bt0 at isa? port 0x330 irq ?
My bt742 controller is at port 0x330. I've not defined what irq that
the card is at -- the kernel will figure that out at boot time:
bt0 at isa0 port 0x330-0x333 irq 11: version 3.3, async, parity, 32 mbxs
scsibus0 at bt0
The device probe routine asked the controller, which said that it is
using irq 11. Everything is happy.
My config file also contains these three lines:
device ep0 at isa? port ? irq ?
device ep1 at isa? port ? irq ?
device ep2 at isa? port ? irq ?
This defines up to 3 3c509/3579 ethernet cards, and doesn't say what
ports or irqs they are at. The kernel boots:
ep0 at isa0 port 0x6000-0x600f irq 3: aui address 00:60:8c:70:e5:c5
ep1 at isa0 port 0x300-0x30f irq 3: aui/bnc/utp address 00:20:af:10:62:ab
... and finds two cards, the ports they are at, and their irqs. The
first one is an EISA card (that is why the port is so high. The card
is in slot 6).
You can ask some devices what irq they are at; others can tell you
what drq they are at. A few, like the `ep', can also tell you the
port. All EISA cards are indexed by their slot, so their port can
also be ?.
Not all devices are flexible enough to support this, but many of the
more sophisticated ones are (ie. almost all good SCSI controllers).
Most stupid devices tell you nothing, then you have to do like this:
controller fdc0 at isa? port 0x3f0 irq 6 drq 2
--
This space not left unintentionally unblank. der...@fsa.ca
Julian Elischer
Theo de Raadt <der...@fsa.ca> wrote:
>In article <Cu4w6...@tfs.com> jul...@tfs.com (Julian Elischer) writes:
> the kernel is configured to use a different interrupt to that the board
> is configured for....
>
> check the interupt for the standard kernel, (I don't have one here) and
> set the board to match....
>
>I've decided to describe how the new NetBSD deals with this issue. I
>think it rather neat, and also worthwhile for people to know about.
>
386bsd used to do this with the SCSI drivers, but it got broken in patchlevel
2.4 and in FreeBSD1.x
(the drivers would reconfigure themselves to match the hardware)
Bruce Evans rewrote the interrupt code, but unfortunatly, while it gave
greatly improved performance, it hard-coded some information about what
device was in what interupt vector at compile time..
This is being worked on and the NetBSD example will definitly looked at as
an example of correct functionality.
but until then, unfortunaltly the kernel config and the hardware need
to agree for freeBSD.
Charles M. Hannum
In article <Cu6KI...@tfs.com> jul...@tfs.com (Julian Elischer)
writes:
386bsd used to do this with the SCSI drivers, but it got broken in
patchlevel 2.4 and in FreeBSD1.x
Actually, that's not quite right. While the original 386BSD code
worked better with respect to dynamically allocating IRQs, it was
never able to share them. The interrupt handling I wrote for NetBSD
does.
(FYI, the interface I chose is very similar to BSDI, though I've only
seen the BSDI document describing it, and not their source code. The
one difference I can think of was made to support unloading of
drivers, which may require removing an interrupt handler.)
The flexibility of this interrupt handler registration/deregistration
system also makes PCI interrupt support very easy.
--
- Charles Hannum
NetBSD group
Working ports: i386, hp300, amiga, sun4c, mac68k, pc532, da30.
In progress: sun3, pmax, vax, sun4m, alpha, sun4.
Terry Lambert
[ ... ]
] I've decided to describe how the new NetBSD deals with this issue. I
] think it rather neat, and also worthwhile for people to know about.
] My config file also contains these three lines:
]
] device ep0 at isa? port ? irq ?
] device ep1 at isa? port ? irq ?
] device ep2 at isa? port ? irq ?
]
] This defines up to 3 3c509/3579 ethernet cards, and doesn't say what
] ports or irqs they are at. The kernel boots:
]
] ep0 at isa0 port 0x6000-0x600f irq 3: aui address 00:60:8c:70:e5:c5
] ep1 at isa0 port 0x300-0x30f irq 3: aui/bnc/utp address 00:20:af:10:62:ab
Uh, what determines the device order?
Specifically, it isn't sorted by port, and it isn't sorted by IRQ (that
you can tell, anyway) and it isn't sorted by hardware address (unless
it's reverse sorted order)... is it by who replies first?
The problem with a "replies first" naming is that you can't guarantee
the same address assignement each time without some shell script
gyrations (if you can afford them). Specifically, what if one of
these cards is inside a firewall and the other one is outside?
Be a real bummer to make a mistake.
Is the answer the shell script from hell, or what?
Terry Lambert
te...@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Charles M. Hannum
In article <3272h7$9...@u.cc.utah.edu> te...@cs.weber.edu (Terry
Lambert) writes:
Uh, what determines the device order?
The 3c509 specification determines the order. I don't have it handy,
so I can't give you an exact quote.
Specifically, it isn't sorted by port, and it isn't sorted by IRQ
(that you can tell, anyway) and it isn't sorted by hardware address
(unless it's reverse sorted order)... is it by who replies first?
All three of those (as well as the existing approach of not dealing
with it) have failure modes. One case where they might all fail is
replacing a card, or moving it to a different I/O address or IRQ
because you need to add a SCSI card.
Currently, you can specific explicit addresses for any of the cards
and be guaranteed a specific binding, if that's important for you.
The existing mechanism is not a replacement for site-specific or
machine-specific configurations; it's mainly intended for generic
kernels that can be used for installation on a wide variety of
machines. (And I might add that it works quite well for that.)
I don't think it's reasonable for the kernel to go out of its way to
avoid obvious failure modes, only to create new less-obvious ones.
The user is supposed to be intelligent; the kernel is a slave.
Be a real bummer to make a mistake.
Yah, someone might die!
Herb Peyerl
: 386bsd used to do this with the SCSI drivers, but it got broken in patchlevel
: 2.4 and in FreeBSD1.x
: (the drivers would reconfigure themselves to match the hardware)
I believe it to be invalid to reconfigure the driver to match the hardware.
While I was writing the if_ep driver, I looked at another driver that
reconfigured itself according to the first 3c509 it found. The problem
with this is that there was no guarantee which 3c509 you would get
upon bootup. You were "fairly sure" but not guaranteed. The last
thing I want as a user is to have the card that I normally associate
with "ep1" to suddenly show up as "ep0" on some boots requiring me to
change my ifconfig's based on my recollection of the MAC addr's during
boot...
For example: my config file says:
device ep0 at isa? port 0x350 net irq 7 vector epintr
device ep1 at isa? port ? net irq ? vector epintr
because I want to be sure that the card at 0x350,7 becomes ep0. I know
that I only have one additional 3c509 in the machine so I don't care
what its config is.
Note; there's a difference between a driver that reconfigures itself
according to the card and a driver that doesn't care what card's configuration
is...
But now I'm off topic.
--
hpe...@novatel.ca | NovAtel Communications Ltd.
hpe...@fsa.ca | <nothing I say matters anyway>
"A sucking chest wound is nature's way of telling you to slow down."