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/
