In message: [EMAIL PROTECTED]
Michael Smith [EMAIL PROTECTED] writes:
: Is there a way that we can fix this without blindly allowing bad
: bus_alloc_resources ? I'm a bit confused as to wheather our code is
: behaving oddly or if it's just the device violating some spec...
:
:
On Sat, Mar 30, 2002 at 10:28:05PM -0800, Michael Smith wrote:
This avoids a panic when probing, there's probably still some
badness going on with make/destroy dev in this driver.
Pending commentary from Scott, I think you should commit this.
Yes, there is a lot of evilness in the asr
* Terry Lambert [EMAIL PROTECTED] [020331 00:05] wrote:
Michael Smith wrote:
What's the basis of the assumption that the I/O range is
unsupported in the first place, and why isn't it true for this
bridge chip, if it's a valid assumption for others?
The information was provided in
Alfred Perlstein wrote:
* Terry Lambert [EMAIL PROTECTED] [020331 00:05] wrote:
Michael Smith wrote:
What's the basis of the assumption that the I/O range is
unsupported in the first place, and why isn't it true for this
bridge chip, if it's a valid assumption for others?
The
Yeah, you do. I fully understood _that_ context; I think Mike
was talking about other context. It's pretty clear to me that
ranges ought to be per bridge chipset, rather than global... I
thought that that was what the option was working around: that
they were not.
I can't imagine how you
On Sat, Mar 30, 2002 at 10:28:05PM -0800, Michael Smith wrote:
This avoids a panic when probing, there's probably still some
badness going on with make/destroy dev in this driver.
Pending commentary from Scott, I think you should commit this.
Yes, there is a lot of evilness in the asr
Should I hold onto this card or should I suck it up and get
a 3ware online somewhere?
Be a man and buy a SCSI RAID controller. The Adaptec 5400S is
all you'll ever need =-)
You will tell me where I can buy disks for $1/GB and hotswap carriers at
$20 a pop, right? 8)
--
To announce
Michael Smith wrote:
Yeah, you do. I fully understood _that_ context; I think Mike
was talking about other context. It's pretty clear to me that
ranges ought to be per bridge chipset, rather than global... I
thought that that was what the option was working around: that
they were not.
Michael Smith wrote:
Should I hold onto this card or should I suck it up and get
a 3ware online somewhere?
Be a man and buy a SCSI RAID controller. The Adaptec 5400S is
all you'll ever need =-)
You will tell me where I can buy disks for $1/GB and hotswap carriers at
$20 a pop,
On Sun, 31 Mar 2002, Michael Smith wrote:
You will tell me where I can buy disks for $1/GB and hotswap carriers at
$20 a pop, right? 8)
eBay. :)
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| [EMAIL PROTECTED] | 2 x '84 Volvo 245DL|
I just got the Adaptec 4 port IDE raid card 2400A.
It doesn't probe right:
asr0: could not map memory
I added some debug printouts to the asr driver and pci code.
asr0: Adaptec Caching SCSI RAID mem 0xf600-0xf7ff irq 5 at device 5.1 on pci2
pcib2: device asr0 requested unsupported
* Alfred Perlstein [EMAIL PROTECTED] [020330 20:47] wrote:
I just got the Adaptec 4 port IDE raid card 2400A.
It doesn't probe right:
asr0: could not map memory
I added some debug printouts to the asr driver and pci code.
asr0: Adaptec Caching SCSI RAID mem 0xf600-0xf7ff irq 5
I just got the Adaptec 4 port IDE raid card 2400A.
It doesn't probe right:
asr0: could not map memory
I added some debug printouts to the asr driver and pci code.
asr0: Adaptec Caching SCSI RAID mem 0xf600-0xf7ff irq 5 at device 5
.1 on pci2
pcib2: device asr0 requested
* Michael Smith [EMAIL PROTECTED] [020330 21:34] wrote:
I just got the Adaptec 4 port IDE raid card 2400A.
It doesn't probe right:
asr0: could not map memory
I added some debug printouts to the asr driver and pci code.
asr0: Adaptec Caching SCSI RAID mem 0xf600-0xf7ff
* Alfred Perlstein [EMAIL PROTECTED] [020330 21:51] wrote:
* Michael Smith [EMAIL PROTECTED] [020330 21:34] wrote:
Your BIOS is assigning a memory range to the card that we don't believe
the bridge passes through. Our check is bogus because (as you see) the
range is actually legitimate
Is there a way that we can fix this without blindly allowing bad
bus_alloc_resources ? I'm a bit confused as to wheather our code is
behaving oddly or if it's just the device violating some spec...
Yes, our code is busted; it should check both ranges and get the
arithmetic right. I believe
This avoids a panic when probing, there's probably still some
badness going on with make/destroy dev in this driver.
Pending commentary from Scott, I think you should commit this.
Should I hold onto this card or should I suck it up and get
a 3ware online somewhere?
By all means use it;
* Michael Smith [EMAIL PROTECTED] [020330 22:25] wrote:
Is there a way that we can fix this without blindly allowing bad
bus_alloc_resources ? I'm a bit confused as to wheather our code is
behaving oddly or if it's just the device violating some spec...
Yes, our code is busted; it
Michael Smith wrote:
wtf is going on here?
Your BIOS is assigning a memory range to the card that we don't believe
the bridge passes through. Our check is bogus because (as you see) the
range is actually legitimate (and we booger up some calculations). Add
the
What's the basis of the assumption that the I/O range is
unsupported in the first place, and why isn't it true for this
bridge chip, if it's a valid assumption for others?
The information was provided in the debugging output and code that Alfred
supplied in earlier messages. The short
Michael Smith wrote:
What's the basis of the assumption that the I/O range is
unsupported in the first place, and why isn't it true for this
bridge chip, if it's a valid assumption for others?
The information was provided in the debugging output and code that Alfred
supplied in earlier
21 matches
Mail list logo
