Hi.
Let's assume a certain IDE controller does LBA48.
Let's at the same time assume the BIOS doesn't know jack
about LBA48.
Let's then assume that I can get a kernel to boot on it,
what method I use doesn't matter. The BIOS doesn't lock up
or anything but it doesn't use more than the fabled 137GB.
Can the Linux Kernel then use the full drive (160GB/250GB/whatever)
even though the BIOS doesn't? (LBA48)
That's question number 1.
Question 2: Does the nForce chipset handle LBA48?
They are related but please answer question 1 even if question 2
is "no" :)
I tried looking for the answers myself but couldn't find a definite
answer. If it's plain in sight somewhere, please point me in the right
direction.
// Stefan
On Sat, Jan 25, 2003 at 03:34:24AM +0100, Stefan Smietanowski wrote:
> Can the Linux Kernel use the full drive (160GB/250GB/whatever)
> even though the BIOS doesn't? (LBA48)
Usually, yes.
>>Can the Linux Kernel use the full drive (160GB/250GB/whatever)
>>even though the BIOS doesn't? (LBA48)
>
> Usually, yes.
Is there anything that could make "usually, yes" become a "no"?
// Stefan
> >>Can the Linux Kernel use the full drive (160GB/250GB/whatever)
> >>even though the BIOS doesn't? (LBA48)
> >
> > Usually, yes.
>
> Is there anything that could make "usually, yes" become a "no"?
Usually no.
:-)
John.
Yes, if the host controller can not handle the double pump for dma
operations. Disable DMA int it has to work. If it does not, you have a
nice pile of junk, and it should be come a door.
On Sat, 25 Jan 2003, Stefan Smietanowski wrote:
> >>Can the Linux Kernel use the full drive (160GB/250GB/whatever)
> >>even though the BIOS doesn't? (LBA48)
> >
> > Usually, yes.
>
> Is there anything that could make "usually, yes" become a "no"?
>
> // Stefan
>
> -
> 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/
>
Andre Hedrick
LAD Storage Consulting Group
> Yes, if the host controller can not handle the double pump for dma
> operations. Disable DMA int it has to work. If it does not, you have a
> nice pile of junk, and it should be come a door.
Shouldn't the driver disable DMA automatically (not allow to enable it) ?
Driver knows the controller type, knows the disk size ...
Or is it not so simple ?
> On Sat, 25 Jan 2003, Stefan Smietanowski wrote:
>
> > >>Can the Linux Kernel use the full drive (160GB/250GB/whatever)
> > >>even though the BIOS doesn't? (LBA48)
> > >
> > > Usually, yes.
> >
> > Is there anything that could make "usually, yes" become a "no"?
--
=======================================================================
Andrzej M. Krzysztofowicz [email protected]
phone (48)(58) 347 14 61
Faculty of Applied Phys. & Math., Gdansk University of Technology
Well doors may know this but the door-stop does not. The driver has no
clue currently and so we are back to a pig in a poke. I have never run
48-bit on AMD, and iirc NFORCE is a step-child of AMD.
It has everything to do with the DMA engine in the ASIC going south.
Cheers,
On Sat, 25 Jan 2003, Andrzej Krzysztofowicz wrote:
>
> > Yes, if the host controller can not handle the double pump for dma
> > operations. Disable DMA int it has to work. If it does not, you have a
> > nice pile of junk, and it should be come a door.
>
> Shouldn't the driver disable DMA automatically (not allow to enable it) ?
> Driver knows the controller type, knows the disk size ...
>
> Or is it not so simple ?
>
>
> > On Sat, 25 Jan 2003, Stefan Smietanowski wrote:
> >
> > > >>Can the Linux Kernel use the full drive (160GB/250GB/whatever)
> > > >>even though the BIOS doesn't? (LBA48)
> > > >
> > > > Usually, yes.
> > >
> > > Is there anything that could make "usually, yes" become a "no"?
>
> --
> =======================================================================
> Andrzej M. Krzysztofowicz [email protected]
> phone (48)(58) 347 14 61
> Faculty of Applied Phys. & Math., Gdansk University of Technology
>
Andre Hedrick
LAD Storage Consulting Group