Re: ide-problem still with 2.4.21-pre5-ac1

Re: ide-problem still with 2.4.21-pre5-ac1

[Andries.Brouwer]

> why its not honouring PTBL values in his case apparently

The disk capacity code foolishly sets heads to 255, and then
ide_xlate_1024 decides that we already have chosen a translation,
so that it does not have to figure out what translation to use.

Andries

See:
        if (xparm == 2) {
                if (!heads ||
                   (drive->bios_head >= heads && drive->bios_sect == 63))
                        transl = 0;
        }
        if (xparm == -1) {
                if (drive->bios_head > 16)
                        transl = 0;     /* we already have a translation */
        }

Re: ide-problem still with 2.4.21-pre5-ac1

[Bill Davidsen]

On Sun, 9 Mar 2003 Andries.Brouwer@cwi.nl wrote:

> > why its not honouring PTBL values in his case apparently
> 
> The disk capacity code foolishly sets heads to 255, and then
> ide_xlate_1024 decides that we already have chosen a translation,
> so that it does not have to figure out what translation to use.
> 
> Andries

[ code snipped ]

Since you identify this as the problem, do you propose a solution? A flag
indicating that default values are in place, perhaps? Better checks to
ensure that if LBA is used the geometry is forced sane in some way? I
don't think special case code is desirable in this case, at least beyond
checking a flag if that's what's needed.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: ide-problem still with 2.4.21-pre5-ac1

[Andries.Brouwer]

    From Thomas.Mieslinger@gls-germany.com  Tue Mar 11 10:03:40 2003
    sorry for my late answer but I was not in my office yesterday.

    These are our problems:
    - We cannot read the mapping from the partition-table because in most
    cases there are no partitions before booting linux!
    - We also cannot supply a fixed mapping in the kernel append-line
    because this would require an extra bootdisk for each hd.

    Why not extend the append-parameter?
    current:
    give a fixed mapping to the kernel                      hda=1050,32,64

    this may be a possible solution:
    give a fixed mapping to the kernel                      hda=1050,32,64
    use bios-supplied mapping:                              hda=bios-lba
    read mapping from newer disk:                           hda=disk-lba
    force a mapping with 255 heads like current kernel:     hda=*,255,*

Here hda=disk-lba is meaningless. The standard tells every new disk
(namely any disk with more than 16514063 sectors, that is about 8.5 GB)
to report CHS = 16383/16/63. There is no information there.

So the disk has nothing to tell us, except its total capacity.
(And that is already complicated - there are several levels of lying
involved there.)

Also hda=*,255,* and similar options sound meaningless.
If you want to force 255 heads and 63 sectors then that must
be told to *fdisk, no need to involve the kernel.
(If some *fdisk should be adapted I'll be happy to do so.)

So the only interesting option to ask for is hda=bios-lba.
That is also what you need if you later use DOS on that machine.

Linux does not use the BIOS and talks directly to the disk.
But the disk does not know what the BIOS will use.
The kernel does not know either - it depends on the setup options
you chose in the BIOS setup.

But in very early kernel startup, before going to protected mode,
the kernel asks the BIOS a few questions. Among these questions
used to be that of the geometry of hd0 and hd1.

In general it is complicated (impossible) to decide which disks
are hd0 and hd1. If you boot from SCSI then hd0 will be a SCSI disk.
If you avoid mentioning a disk in the BIOS setup, it is not
included in the BIOS numbering, but is is in the kernel numbering,
so hd0, hd1 might be hda, hdd, for example.

At first sight a kernel patch does not seem to be what you need.
If you use a uniform BIOS setup, then fdisk parameters should suffice.
If you use random BIOS setup, then doing what you want probably
requires writing a pattern to the disk using the BIOS and then
later see which disk got this pattern.

Andries

Re: ide-problem still with 2.4.21-pre5-ac1

[Thomas.Mieslinger]

Hello again,

sorry for my late answer but I was not in my office yesterday.

First I'd like to explain why we need the correct bios-translation within 
linux:
We install our Windows-boxes with a linux bootdisk like the project http://unattended.sourceforge.net
After creating and formatting the partitions with linux and dosemu we boot 
dos from hd, and run the windows setup-script. It is running fine on any 
hardware with kernel 2.2.22 and the patched 2.4.21-pre5.

These are our problems:
- We cannot read the mapping from the partition-table because in most 
cases there are no partitions before booting linux!
- We also cannot supply a fixed mapping in the kernel append-line because 
this would require an extra bootdisk for each hd.

Why not extend the append-parameter?
current:
give a fixed mapping to the kernel                      hda=1050,32,64

this may be a possible solution:
give a fixed mapping to the kernel                      hda=1050,32,64
use bios-supplied mapping:                              hda=bios-lba
read mapping from newer disk:                           hda=disk-lba
force a mapping with 255 heads like current kernel:     hda=*,255,*

I think the kernel 2.2.22 was "more lucky" finding the correct mapping 
because the very new disk-devices which cause the problem are only in use 
since we have switched to kernel 2.4 ;-)
The problem only appears with the following parameters:
- very new hd (maxtor 4D040H2 from dec-2001 was running fine, but maxtor 
6E040L0 manufactured oct-2002 does not. both disk are of the same size of 
40GB)
- computer has a bios which uses 240-head mapping by default with this 
disk. This applies to about the half of our pc-types, about 800 computers 
alltogether. These are the desktops Compaq Evo 510 and HP Vectra Vli-8 and 
the notebooks Compaq Evo N610c and HP Omnibook 6000. It will also hit the 
HP Omnibook 6100 and the older HP Omnibook 4150 after installing a newer 
hd.
I think that many brand-computers will get this problem with newer drives 
attached and using dual-boot Linux-windows on the disk. This may cause 
data-loss on the windows-partition, i fear.


hdparm output with kernel 2.2.22:
# cat /proc/version
Linux version 2.2.22 (root@fm) (gcc version 2.95.3 20010315 (SuSE)) #3 Sat 
Oct 26 17:11:59 CEST 2002

# hdparm -i /dev/hda                    Maxtor 6E040L0, "bad disk"
/dev/hda:
 Model=Maxtor 6E040L0, FwRev=NAR61590, SerialNo=E11G00EE
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=off
 DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=0(slow)
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78165360
 tDMA={min:120,rec:120}, DMA modes: mword0 mword1 mword2
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4

# hdparm -I /dev/hda
/dev/hda:
 Model=aMtxro6 0E040L                          , FwRev=AN6R5109, 
SerialNo=1EG100EE
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=off
 DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=0(slow)
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78165360
 tDMA={min:120,rec:120}, DMA modes: mword0 mword1 mword2
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4


# hdparm -i /dev/hda                    Maxtor 4D040H2, good disk
/dev/hda:
 Model=Maxtor 4D040H2, FwRev=DAH017K0, SerialNo=D22AKNYE
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=off
 DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=0(slow)
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=80043264
 tDMA={min:120,rec:120}, DMA modes: mword0 mword1 mword2
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4

# hdparm -I /dev/hda
/dev/hda:
 Model=aMtxro4 0D042H                          , FwRev=AD0H710K, 
SerialNo=2DA2NKEY
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=3(DualPortCache), BuffSize=2048kB, MaxMultSect=16, MultSect=off
 DblWordIO=no, maxPIO=2(fast), DMA=yes, maxDMA=0(slow)
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=80043264
 tDMA={min:120,rec:120}, DMA modes: mword0 mword1 mword2
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, PIO modes: mode3 mode4

Regards

Harald Schäfer
-- 
General Logistics Systems
Thomas Mieslinger
German-Parcel-Str. 1-7     fon: +49 6677 17 463
36286 Neuenstein            fax: +49 6677 17 111
Germany                           eMail: thomas.mieslinger@gls-germany.com

Re: ide-problem still with 2.4.21-pre5-ac1

[Andries.Brouwer]

> Since you identify this as the problem, do you propose a solution?

Alan asks a question, and I answer.
If he has further questions I will answer if I can.

Andries

Re: ide-problem still with 2.4.21-pre5-ac1

[Bill Davidsen]

On Sun, 9 Mar 2003 Andries.Brouwer@cwi.nl wrote:

> > So you are saying the same thing I am, are you not?
> 
> The problem was one about translation, not about capacity.

The *problem* was translation, the proposed *solution* was using the BIOS
values in preference to drive values would include capacity. Or I misread
the intent (or code).

I would think that the capacity should code from the drive, if the BIOS
geometry is clearly wrong from that capacity (no, I didn't define that)
then using it will/may cause problems in applications and perhaps the
kernel, although LBA should be used and geometry not an issue.

Feel free to read the original post otherwise, I thought using the BIOS
data was the intent, period.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: ide-problem still with 2.4.21-pre5-ac1

[Andre Hedrick]

Unless it is native and legacy addressed on the mainboard via the system
bios, Linux can not query the proper geometry.

I have always argued to defautl to LBA when beyond 8.4GB, but people want
to use the orphan sectors, why ... ??  Best guess is not wanting to leave
used sectors.  The was a holy war some time back and I gave up on the
issue.  CHS is dead, but it lives as a Zombie until there are only drives
which support 48-bit feature sets in existance.  Then the problem goes
away.


On 9 Mar 2003, Alan Cox wrote:

> On Sat, 2003-03-08 at 23:23, Andries Brouwer wrote:
> > Really strange values, as if someone wanted to force a H=255.
> > Must read current 2.4 source some time. What does hdparm say
> > under 2.2.22?
> 
> What I'm trying to work out is why its not honouring PTBL
> values in his case apparently. I don't care too much what shape
> the disk is but I do care that if the partition table says
> its this interpretation we use it
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> 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

Re: ide-problem still with 2.4.21-pre5-ac1

[Andries.Brouwer]

> So you are saying the same thing I am, are you not?

The problem was one about translation, not about capacity.

Andries

Re: ide-problem still with 2.4.21-pre5-ac1

[Bill Davidsen]

On Sun, 9 Mar 2003, Andries Brouwer wrote:

> On Sat, Mar 08, 2003 at 05:28:10PM -0500, Bill Davidsen wrote:
> > On Thu, 6 Mar 2003 Harald.Schaefer@gls-germany.com wrote:
> > 
> > >  *    1. CHS value set by user       (whatever user sets will be trusted)
> > >  *    2. LBA value from target drive (require new ATA feature)
> > >  *    3. LBA value from system BIOS  (new one is OK, old one may break)
> > >  *    4. CHS value from system BIOS  (traditional style)
> > > 
> > > I think that the priority of LBA from BIOS has to be raised to 2 and the
> > > priority of LBA from drive should be lowered to 3.
> > > The mapping-problem only appreared with very new drives in some
> > > brand-computers using a 240-head mapping from the bios.
> > 
> > I think the chances of a drive knowing its own correct LBA info is far
> > better than the BIOS getting it right. Many BIOS versions don't understand
> > large drives.
> 
> Maybe time for some preaching again.
> 
> The above sounds like nonsense,
> "its own correct LBA info" does not refer to anything.

Change the wording any way you like, my point that the drive is more
likely to have correct information about its LBA capacity than the BIOS.

> A disk that is less than twelve years old does not have a geometry.
> All disks that can handle LBA (that is, all disks less than
> twelve years old) use LBA under Linux.
> Thus, the disk has nothing to tell use except for its total capacity.

So you are saying the same thing I am, are you not? I said to use the
drive LBA capacity, you say that means nothing and then agree that is
exactly what the drive can tell us. Many people put new drives in old
machines which have a BIOS which doesn't understand large drives. So the
kernel should believe the drive about the size rather than the BIOS.

You call that nonsens and then say the same thing in other words as if you
were disagreeing with me.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: ide-problem still with 2.4.21-pre5-ac1

[Alan Cox]

On Sat, 2003-03-08 at 23:23, Andries Brouwer wrote:
> Really strange values, as if someone wanted to force a H=255.
> Must read current 2.4 source some time. What does hdparm say
> under 2.2.22?

What I'm trying to work out is why its not honouring PTBL
values in his case apparently. I don't care too much what shape
the disk is but I do care that if the partition table says
its this interpretation we use it

Re: ide-problem still with 2.4.21-pre5-ac1

[Andries Brouwer]

On Sat, Mar 08, 2003 at 05:28:10PM -0500, Bill Davidsen wrote:
> On Thu, 6 Mar 2003 Harald.Schaefer@gls-germany.com wrote:
> 
> >  *    1. CHS value set by user       (whatever user sets will be trusted)
> >  *    2. LBA value from target drive (require new ATA feature)
> >  *    3. LBA value from system BIOS  (new one is OK, old one may break)
> >  *    4. CHS value from system BIOS  (traditional style)
> > 
> > I think that the priority of LBA from BIOS has to be raised to 2 and the
> > priority of LBA from drive should be lowered to 3.
> > The mapping-problem only appreared with very new drives in some
> > brand-computers using a 240-head mapping from the bios.
> 
> I think the chances of a drive knowing its own correct LBA info is far
> better than the BIOS getting it right. Many BIOS versions don't understand
> large drives.

Maybe time for some preaching again.

The above sounds like nonsense,
"its own correct LBA info" does not refer to anything.

A disk that is less than twelve years old does not have a geometry.
All disks that can handle LBA (that is, all disks less than
twelve years old) use LBA under Linux.
Thus, the disk has nothing to tell use except for its total capacity.

Some silly legacy stuff is interested in a geometry.
It does not exist, but everybody can invent something,
Why would one do such a silly thing? Well, the DOS-type partition
table has fields that are expressed in terms of cyl/heads/secs,
and these are used by DOS. If one really uses DOS on the same
disk, then one needs the BIOS values, since DOS uses the BIOS.

On a Linux-only system there is never any problem, provided
one can boot. Don't panic if some ancient fdisk version
mumbles about unexpected things. 

Usually people that complain only think they have a problem,
while in fact all is well. Or they have a problem: the BIOS
cannot handle the disk and does not boot, but that is not a
Linux problem.

Now what about Harald.Schaefer's problem? I asked Google
for his complaint and find

"We create fdisk partitions with linux and run later DOS
from one of these partitions. DOS gets confused about the
linux mapping of the partition that is different from the
BIOS supplied values."

Now guessing what the BIOS will do is a black art,
and if "kernel 2.2.22 was running fine" it was lucky.
I see that 2.4.21-pre5 overrides in many cases what
the BIOS said, so it will be lucky less often.
But one can always specify an explicit geometry to fdisk.
(And find out what to say by inspecting the BIOS setup
screen under "autodetecting hard disks".)

Finally, on the shown hdparm output:

---------------------------------------------------------------------------
and a bad disk, which is recognized with "bit shift"-mapping from the BIOS:

hdparm -i /dev/hda
 Model=Maxtor 6E040L0, FwRev=NAR61590, SerialNo=E11G00EE
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78165360

hdparm -I /dev/hda
 CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=78165360

another disk that doesn't work

hdparm -i /dev/hda
 Model=FUJITSU MHR2030AT, FwRev=53BB, SerialNo=NJ36T2813MYW
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=58605120

hdparm -I /dev/hda
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=58605120
---------------------------------------------------------------------------

Really strange values, as if someone wanted to force a H=255.
Must read current 2.4 source some time. What does hdparm say
under 2.2.22?

Andries

Re: ide-problem still with 2.4.21-pre5-ac1

[Bill Davidsen]

On Thu, 6 Mar 2003 Harald.Schaefer@gls-germany.com wrote:

>  *    1. CHS value set by user       (whatever user sets will be trusted)
>  *    2. LBA value from target drive (require new ATA feature)
>  *    3. LBA value from system BIOS  (new one is OK, old one may break)
>  *    4. CHS value from system BIOS  (traditional style)
> 
> I think that the priority of LBA from BIOS has to be raised to 2 and the
> priority of LBA from drive should be lowered to 3.
> The mapping-problem only appreared with very new drives in some
> brand-computers using a 240-head mapping from the bios.

I think the chances of a drive knowing its own correct LBA info is far
better than the BIOS getting it right. Many BIOS versions don't understand
large drives.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: ide-problem still with 2.4.21-pre5-ac1

[Alan Cox]

On Thu, 2003-03-06 at 10:26, Harald.Schaefer@gls-germany.com wrote:
> sorry for sending you directly again instead to the kernel-ML. I do so
> because the problems are only caused by ide-disk.c. This mail is CCed to
> the ML.

I disagree there

> I was able to work around the problem for our little environment (about
> 2000 Computers of 9 different types) with the following dirty hack,
> changing from kernel-2.4.21-pre5-ac1:

We set the mapping to 255, 63, .. whe the drive supports reporting its
LBA geometry addressing. Otherwise we use the lba capacity based on 
the bios mapping. The 48bit LBA factor would explain the reason you
saw some drives work and some fail.

> In your mail you wrote that the kernel honors the mapping of existing
> partitions on the disk. Unfortunately the kernel 2.4.21-pre5-ac1 does not
> so! I created a primary dos-partition on a Fujitsu-disk attached to a
> Compaq Notebook Evo N610c using MS-DOS 6.22 fdisk, which bios uses a
> 240-head mapping, but linux used a 255-head maping at the next boot. This
> may destroy data on the disk.

Linux maps the disk in a logical block order at all times. The partition
code looks for any existing mappings and then translates based on the
data it discovers (fs/partition/msdos.c calling ide_xlate_1024()

> I think that the priority of LBA from BIOS has to be raised to 2 and the
> priority of LBA from drive should be lowered to 3.
> The mapping-problem only appreared with very new drives in some
> brand-computers using a 240-head mapping from the bios.

I don't think thats viable when doing 48bit LBA.

> We don't know which problems our workaround causes, but we're happy with it
> and would like to see it in an upcoming release. Why was a 255 head mapping
> hard coded in the kernel?

You'd have to ask Andre to be sure but I believe it is what the spec
says about those mappings. The more interesting question if thats what
you are seeing is why the ide_xlate_1024 handling isn't picking up 
on the situation. That seems to be the actual problem case.

Alan

Re: ide-problem still with 2.4.21-pre5-ac1

[Harald.Schaefer]

Hello Alan,

sorry for sending you directly again instead to the kernel-ML. I do so
because the problems are only caused by ide-disk.c. This mail is CCed to
the ML.

I was able to work around the problem for our little environment (about
2000 Computers of 9 different types) with the following dirty hack,
changing from kernel-2.4.21-pre5-ac1:
1150,1151c1150,1151
<           drive->head       = drive->bios_head = 255;
<           drive->sect       = drive->bios_sect = 63;
---
>           drive->head       = drive->bios_head;
>           drive->sect       = drive->bios_sect;


In your mail you wrote that the kernel honors the mapping of existing
partitions on the disk. Unfortunately the kernel 2.4.21-pre5-ac1 does not
so! I created a primary dos-partition on a Fujitsu-disk attached to a
Compaq Notebook Evo N610c using MS-DOS 6.22 fdisk, which bios uses a
240-head mapping, but linux used a 255-head maping at the next boot. This
may destroy data on the disk.

In ide-disk.c the following remark is listed at line 1127:
 *    1. CHS value set by user       (whatever user sets will be trusted)
 *    2. LBA value from target drive (require new ATA feature)
 *    3. LBA value from system BIOS  (new one is OK, old one may break)
 *    4. CHS value from system BIOS  (traditional style)

I think that the priority of LBA from BIOS has to be raised to 2 and the
priority of LBA from drive should be lowered to 3.
The mapping-problem only appreared with very new drives in some
brand-computers using a 240-head mapping from the bios.

We don't know which problems our workaround causes, but we're happy with it
and would like to see it in an upcoming release. Why was a 255 head mapping
hard coded in the kernel?

--snip--

On Tue, 2003-03-04 at 15:17, Harald.Schaefer@gls-germany.com wrote:
> [1.] One line summary of the problem:
> ide-drives are sometimes recognized with LBA-Mapping, even if the bios is
> configured diffrent

The kernel honours the partition mapping data it finds in the partition
table for. Its very hard to use/guess the bios mappings and for many
systems its not available hence we do this.

When we find the partition table doesn't seem to agree with the mapping
you'll see [PTBL] in the partition info when it probes the disk.

Can you post the query to the linux-kernel list rather than just to me.
I'm the IDE guy but people like Andries are the partitioning gurus

--snip--
Hello Alan,

we found a problem with the ide-drivers at some of our Computers.


[1.] One line summary of the problem:
ide-drives are sometimes recognized with LBA-Mapping, even if the bios is
configured diffrent

[2.] Full description of the problem/report:
kernel 2.2.22 was running fine and used the correct bios-mapping every time
the kernel 2.4.20 always uses lba-mapping regardless of the bios setting.
kernel 2.4.21-pre3 and -pre5 recognize the correct Disc mapping if the bios
uses by default LBA.
the patch 2.4.21-pre5-ac1 does the same as 2.4.21-pre3/pre5
If the bios uses by default bit shift or large mode the kernel recognize
the correct mapping
of the disc if a WDC WD400BB-60DGA0 or a Maxtor 4D040H2 is attached.
If a FUJITSU MHR2030AT or a Maxtor 6E040L0 is attached the kernel gets
confused. See
hdparam -i and -I outputs at the end of this document.

We create fdisk partitions with linux and run later dos from one of that
partitions. Dos gets
confused about the linux mapping of the partion that is different from the
bios supplied values.


[3.] Keywords (i.e., modules, networking, kernel):
ide, mapping, bios, lba

[4.] Kernel version (from /proc/version):
Linux version 2.4.21-pre3 (harri@eisler.fet.uni-hannover.de) (gcc version
2.95.4 20011002 (Debian prerelease)) #5 Mit Jan 22 11:33:07 CET 2003

[5.] Output of Oops.. message (if applicable) with symbolic information
     resolved (see Documentation/oops-tracing.txt)
not available

[6.] A small shell script or example program which triggers the
     problem (if possible)
not available

[7.] Environment

[7.1.] Software (add the output of the ver_linux script here)

[7.2.] Processor information (from /proc/cpuinfo):
the problem appears on some new Compaq-Desktops and Notebooks with
different CPU's
We have seen this also on older HP vli8 (PIII 650) and HP Omnibook 6000
(PIII 600).

Evo N610c Notebook for Example:
degpn025w130 # cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz
stepping        : 4
cpu MHz         : 1594.851
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov
pat p
se36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips        : 3185.04

Evo N510 Desktop:
degpn025w135 # cat proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 1.80GHz
stepping        : 4
cpu MHz         : 1794.239
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips        : 3578.26

[7.3.] Module information (from /proc/modules):
degpn025w130 # cat /proc/modules
nls_cp850               3404   0 (unused)
smbfs                  32360   1
ipt_reject              2616   1
ipt_masquerade           980   1
ipt_state                388   1
iptable_nat            13740   1 [ipt_masquerade]
iptable_filter          1468   1
ip_conntrack           15884   2 [ipt_masquerade ipt_state iptable_nat]
ip_tables              10656   7 [ipt_reject ipt_masquerade ipt_state
iptable_nat iptable_filter]
ds                      6604   2
i82365                 23076   2
pcmcia_core            43584   0 [ds i82365]
e100                   50516   1

degpn025w135 # cat /proc/modules
nls_cp850               3404   0 (unused)
smbfs                  32360   1
ipt_reject              2616   1
ipt_masquerade           980   1
ipt_state                388   1
iptable_nat            13740   1 [ipt_masquerade]
iptable_filter          1468   1
ip_conntrack           15884   2 [ipt_masquerade ipt_state iptable_nat]
ip_tables              10656   7 [ipt_reject ipt_masquerade ipt_state
iptable_nat iptable_filter]
e100                   50516   1


[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
degpn025w130 # cat /proc/ioports
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
03c0-03df : vga+
03e8-03ef : serial(auto)
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
2000-20ff : PCI device 11c1:0450
2400-243f : PCI device 8086:1038
  2400-243f : e100
2440-2447 : PCI device 11c1:0450
3000-3fff : PCI Bus #01
  3000-30ff : PCI device 1002:4c57
4000-40ff : PCI device 8086:2485
4400-443f : PCI device 8086:2485
4440-444f : PCI device 8086:248a
  4440-4447 : ide0
  4448-444f : ide1

degpn025w130 # cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-0ffcffff : System RAM
  00100000-001ce347 : Kernel code
  001ce348-002013bf : Kernel data
0ffd0000-0fff0bff : reserved
0fff0c00-0fffbfff : ACPI Non-volatile Storage
0fffc000-0fffffff : reserved
10000000-100003ff : PCI device 8086:248a
40000000-40000fff : PCI device 104c:ac51
  40000000-40000fff : i82365
40080000-40080fff : PCI device 104c:ac51
  40080000-40080fff : i82365
40100000-40100fff : PCI device 8086:1038
  40100000-40100fff : e100
40180000-40180fff : PCI device 1033:0035
40200000-40200fff : PCI device 1033:0035
40280000-402800ff : PCI device 11c1:0450
40300000-403000ff : PCI device 1033:00e0
40400000-404fffff : PCI Bus #01
  40400000-4040ffff : PCI device 1002:4c57
48000000-4fffffff : PCI Bus #01
  48000000-4fffffff : PCI device 1002:4c57
60000000-6fffffff : PCI device 8086:1a30


degpn025w135 # cat /proc/ioports
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial(auto)
0376-0376 : ide1
03c0-03df : vga+
03f6-03f6 : ide0
03f8-03ff : serial(auto)
0cf8-0cff : PCI conf1
1000-103f : PCI device 8086:103b
  1000-103f : e100
2000-20ff : PCI device 8086:24c5
2400-243f : PCI device 8086:24c5
2440-245f : PCI device 8086:24c2
2460-247f : PCI device 8086:24c4
24a0-24af : PCI device 8086:24cb
  24a0-24a7 : ide0
  24a8-24af : ide1

degpn025w135 # cat /proc/iomem
00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-0f7effff : System RAM
  00100000-001ce347 : Kernel code
  001ce348-002013bf : Kernel data
0f7f0000-0f7fffff : reserved
10000000-100003ff : PCI device 8086:24cb
f0000000-f7ffffff : PCI device 8086:2562
f8000000-fbffffff : PCI device 8086:2560
fc400000-fc47ffff : PCI device 8086:2562
fc480000-fc4803ff : PCI device 8086:24cd
fc480400-fc4805ff : PCI device 8086:24c5
fc480600-fc4806ff : PCI device 8086:24c5
fc500000-fc500fff : PCI device 8086:103b
  fc500000-fc500fff : e100
fec00000-ffffffff : reserved

[7.5.] PCI information ('lspci -vvv' as root)
sorry, lspci is not available on this linux-bootdisk. output of "cat
/proc/pci" instead
degpn025w130 # cat /proc/pci
PCI devices found:
  Bus  0, device   0, function  0:
    Class 0600: PCI device 8086:1a30 (rev 4).
      Prefetchable 32 bit memory at 0x60000000 [0x6fffffff].
  Bus  0, device   1, function  0:
    Class 0604: PCI device 8086:1a31 (rev 4).
      Master Capable.  Latency=64.  Min Gnt=12.
  Bus  0, device  30, function  0:
    Class 0604: PCI device 8086:2448 (rev 66).
      Master Capable.  No bursts.  Min Gnt=6.
  Bus  0, device  31, function  0:
    Class 0601: PCI device 8086:248c (rev 2).
  Bus  0, device  31, function  1:
    Class 0101: PCI device 8086:248a (rev 2).
      IRQ 11.
      I/O at 0x4440 [0x444f].
      Non-prefetchable 32 bit memory at 0x10000000 [0x100003ff].
  Bus  0, device  31, function  5:
    Class 0401: PCI device 8086:2485 (rev 2).
      IRQ 11.
      I/O at 0x4000 [0x40ff].
      I/O at 0x4400 [0x443f].
  Bus  1, device   0, function  0:
    Class 0300: PCI device 1002:4c57 (rev 0).
      IRQ 11.
      Master Capable.  Latency=66.  Min Gnt=8.
      Prefetchable 32 bit memory at 0x48000000 [0x4fffffff].
      I/O at 0x3000 [0x30ff].
      Non-prefetchable 32 bit memory at 0x40400000 [0x4040ffff].
  Bus  2, device   4, function  0:
    Class 0780: PCI device 11c1:0450 (rev 2).
      IRQ 11.
      Master Capable.  Latency=66.  Min Gnt=252.Max Lat=14.
      Non-prefetchable 32 bit memory at 0x40280000 [0x402800ff].
      I/O at 0x2440 [0x2447].
      I/O at 0x2000 [0x20ff].
  Bus  2, device   6, function  0:
    Class 0607: PCI device 104c:ac51 (rev 0).
      IRQ 11.
      Master Capable.  Latency=66.  Min Gnt=196.Max Lat=7.
      Non-prefetchable 32 bit memory at 0x40000000 [0x40000fff].
  Bus  2, device   6, function  1:
    Class 0607: PCI device 104c:ac51 (rev 0).
      IRQ 11.
      Master Capable.  Latency=66.  Min Gnt=196.Max Lat=7.
      Non-prefetchable 32 bit memory at 0x40080000 [0x40080fff].
  Bus  2, device   8, function  0:
    Class 0200: PCI device 8086:1038 (rev 66).
      IRQ 10.
      Master Capable.  Latency=66.  Min Gnt=8.Max Lat=56.
      Non-prefetchable 32 bit memory at 0x40100000 [0x40100fff].
      I/O at 0x2400 [0x243f].
  Bus  2, device  14, function  0:
    Class 0c03: PCI device 1033:0035 (rev 65).
      IRQ 10.
      Master Capable.  Latency=64.  Min Gnt=1.Max Lat=42.
      Non-prefetchable 32 bit memory at 0x40180000 [0x40180fff].
  Bus  2, device  14, function  1:
    Class 0c03: PCI device 1033:0035 (rev 65).
      IRQ 10.
      Master Capable.  Latency=64.  Min Gnt=1.Max Lat=42.
      Non-prefetchable 32 bit memory at 0x40200000 [0x40200fff].
  Bus  2, device  14, function  2:
    Class 0c03: PCI device 1033:00e0 (rev 2).
      IRQ 10.
      Master Capable.  Latency=64.  Min Gnt=16.Max Lat=34.
      Non-prefetchable 32 bit memory at 0x40300000 [0x403000ff].


degpn025w135 # cat /proc/pci
PCI devices found:
  Bus  0, device   0, function  0:
    Class 0600: PCI device 8086:2560 (rev 1).
      Prefetchable 32 bit memory at 0xf8000000 [0xfbffffff].
  Bus  0, device   2, function  0:
    Class 0300: PCI device 8086:2562 (rev 1).
      IRQ 10.
      Prefetchable 32 bit memory at 0xf0000000 [0xf7ffffff].
      Non-prefetchable 32 bit memory at 0xfc400000 [0xfc47ffff].
  Bus  0, device  29, function  0:
    Class 0c03: PCI device 8086:24c2 (rev 1).
      IRQ 10.
      I/O at 0x2440 [0x245f].
  Bus  0, device  29, function  1:
    Class 0c03: PCI device 8086:24c4 (rev 1).
      IRQ 11.
      I/O at 0x2460 [0x247f].
  Bus  0, device  29, function  7:
    Class 0c03: PCI device 8086:24cd (rev 1).
      IRQ 5.
      Non-prefetchable 32 bit memory at 0xfc480000 [0xfc4803ff].
  Bus  0, device  30, function  0:
    Class 0604: PCI device 8086:244e (rev 129).
      Master Capable.  No bursts.  Min Gnt=6.
  Bus  0, device  31, function  0:
    Class 0601: PCI device 8086:24c0 (rev 1).
  Bus  0, device  31, function  1:
    Class 0101: PCI device 8086:24cb (rev 1).
      IRQ 10.
      I/O at 0x24a0 [0x24af].
      Non-prefetchable 32 bit memory at 0x10000000 [0x100003ff].
  Bus  0, device  31, function  5:
    Class 0401: PCI device 8086:24c5 (rev 1).
      IRQ 5.
      I/O at 0x2000 [0x20ff].
      I/O at 0x2400 [0x243f].
      Non-prefetchable 32 bit memory at 0xfc480400 [0xfc4805ff].
      Non-prefetchable 32 bit memory at 0xfc480600 [0xfc4806ff].
  Bus  5, device   8, function  0:
    Class 0200: PCI device 8086:103b (rev 129).
      IRQ 5.
      Master Capable.  Latency=66.  Min Gnt=8.Max Lat=56.
      Non-prefetchable 32 bit memory at 0xfc500000 [0xfc500fff].
      I/O at 0x1000 [0x103f].


[7.6.] SCSI information (from /proc/scsi/scsi)
scsi drivers are not loaded.
degpn025w135 # cat  /proc/scsi/scsi
cat: /proc/scsi/scsi: No such file or directory


[7.7.] Other information that might be relevant to the problem
       (please look in /proc and include all information that you
       think to be relevant):



[X.] Other notes, patches, fixes, workarounds:
if the bios ist forced to use lba-mapping everything is running fine.
but in the notebook-bios mapping setting cannot be changed. It is set to
"bit shift" on
fujitsu disks

some harddisk are recognized with lba-setting, these models are running
fine.
output of "hdparm -i /dev/hda" and "hdparm -I /dev/hda" of some good disks:
hdparm -i /dev/hda
 Model=Maxtor 4D040H2, FwRev=DAH017K0, SerialNo=D22AKNYE
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=80043264
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5

hdparm -I /dev/hda
 Model=aMtxro4 0D042H                          , FwRev=AD0H710K,
SerialNo=2DA2NKEY
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=80043264
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5

hdparm -i /dev/hda
 Model=WDC WD400BB-60DGA0, FwRev=05.03E05, SerialNo=WD-WMADK1725099
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78165360
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5

hdparm -I /dev/hda
 Model=DW CDW04B0-B06GD0A                      , FwRev=500.E350,
SerialNo=DWW-AMKD715290
 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
 RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78165360
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5


and a bad disk, which is recognized with "bit shift"-mapping from the bios:

hdparm -i /dev/hda
 Model=Maxtor 6E040L0, FwRev=NAR61590, SerialNo=E11G00EE
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78165360
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5

hdparm -I /dev/hda
 Model=aMtxro6 0E040L                          , FwRev=AN6R5109,
SerialNo=1EG100EE
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=78165360
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5

another disk that doesn't work

hdparm -i /dev/hda
 Model=FUJITSU MHR2030AT, FwRev=53BB, SerialNo=NJ36T2813MYW
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=17475/15/63, CurSects=16513875, LBA=yes, LBAsects=58605120
 IORDY=yes, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5

hdparm -I /dev/hda
 Model=UFIJST UHM2R30A0 T                      , FwRev=35BB    , SerialNo=
JN632T18M3WY
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=58605120
 IORDY=yes, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes: pio0 pio1 pio2 pio3 pio4
 DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5


Harald Schäfer
--
GLS Germany
Basissysteme

Telefon +49 (0) 66 77 17 466