On Tue, Feb 06, 2007 at 09:20:15AM +0400, Manu Abraham wrote:
...
> >BIST is required to complete in 2 seconds. Either with success or failure.
> >I expect BIOS to have complained before launching grub/lilo.
...
> BIST is supposed to terminate before, say the OS kernel is loaded?
Yes - that's what I was trying to imply above.
> or does it mean that it can keep running still ?
Don't know. Either it's still running (for much longer that 2 seconds),
linux is causing it run _again_, or linux is has terribly confused the
device somehow. More on this in an email I'm still working on...will
send that out in a bit.
> >> Region 0: Memory at f7ee0000 (32-bit, non-prefetchable) [disabled]
> >[size=4K]
> >> Region 2: Memory at e9b00000 (32-bit, prefetchable) [disabled]
> >[size=4K]
> >> Region 3: Memory at <unassigned> (32-bit, prefetchable) [disabled]
> >> Region 4: Memory at <ignored> (32-bit, non-prefetchable) [disabled]
> >> Region 5: Memory at <invalid-64bit-slot> (64-bit,
> >non-prefetchable) [disabled]
> >
> >This is obviously garbage. 64-bit registers can only be represented with
> >two consecutive "BAR" and region 5 is the last one.
> >There is no way this can be a 64-bit BAR.
> >Generally, 64-bit BARs start on an "even" numbered BAR (but I've forgotten
> >again if that's just convention or a requirement)
> >
>
> was just wondering how it could be a 64 bit device.
64-bit BAR is seperate from 64-bit Device (data path).
PCI has three different 32 vs 64-bit areas:
o BARs
o DMA
o HW/data path width.
"32-bit device" generally only refers to the latter.
The three attributes are generally all "32-bit" for "32-bit device".
That's less likely to be true for "64-bit devices". Several "64-bit
devices" can only DMA to 32-bit host memory and at least a few only
support 32-bit BARs (even if the device claims it has a 64-bit BAR).
hth,
grant
>
> >hth,
> >grant
> >
>
>
> Thanks a lot for the valuable info. I had not ruled out the option
> that it could be broken.
> I will try the device in the other OS also, to confirm this. Will post
> the status after that.
> But most probably as you said, could be broken.
>
> Thanks,
> Manu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
