# kernel 2.6.36-gentoo-r5 only recognize up to 136.9GB VHD?

## yaplej

Hello,

I have migrated my gentoo server to a MS Hyper-V VM and only had to add

Device Drivers>

CMD64x PATA support

to the kernel configuration in order to get the system to boot.  Without that I was getting kernel panic about VFS not being about to mount root...

The problem I have now is that I have two VHD sda and sdb.  So far sda 73GB seems to be working fine and it where the OS is.  I also have sdb 600GB and for whatever reason is only recognized as 136.9GB.  

```

dmesg | grep sdb

[    8.021483] sd 0:0:1:0: [sdb] 267382800 512-byte logical blocks: (136 GB/127 GiB)

[    8.023724] sd 0:0:1:0: [sdb] Write Protect is off

[    8.025469] sd 0:0:1:0: [sdb] Mode Sense: 00 3a 00 00

[    8.025543] sd 0:0:1:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA

[    8.259811]  sdb:

[    8.365510] sd 0:0:1:0: [sdb] Attached SCSI disk

```

So am I including the wrong driver in my kernel config or is this a limitation of this driver?

Thanks.

----------

## yaplej

Well.  Its a year old but this looks pretty close to my problem.

http://www.serverphorums.com/read.php?12,79638

----------

## NeddySeagoon

yaplej,

Something somewhere is not using 48bit Logical Block Addressing. The driver plays no part in that. 48 bit LBA has been in the kernel since before real drives reached 137G.

Check in the Virtual BIOS to see what options you have there.

Is the Emulated CMD64x PATA chip set your only choice?

The real CMD64x is probably the worst chip set in the world. It doesn't even support DMA trasfers.

----------

## yaplej

Well it does not even seem to be using the CMD64X driver so I dont know if my fooling around in the ATA/ATAPI/MFM/RLL section can also change settings in the Serial ATA and Parallel ATAPI drivers section also.  I have removed the CMD64X driver and building a new kernel.  I first tried enabling CMD640 in ATA/ATAPI/MFM/RLL.  It also enabled a bunch of chipsets but then went back to using Serial ATA and it also worked so I didnt know if enablishing a driver under one section would carry over into another.

```

lspci

0000:00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (AGP disabled) (rev 03)

0000:00:07.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 01)

0000:00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)

0000:00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)

0000:00:08.0 VGA compatible controller: Microsoft Corporation: Unknown device 5353

0000:00:0a.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 20)

```

----------

## NeddySeagoon

yaplej,

The 

```
0000:00:07.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01) 
```

Is a hybrid SATA/IDE chip set. 

Early ones did not have the SATA fitted so this chip set has proved problematical over the years.

Set your kernel up  like this 

You should never use the 

```
< > ATA/ATAPI/MFM/RLL support  --->
```

branch with kernels after about 2.6.23

----------

## yaplej

I tried to disable all other chipsets as in the guide but the VHD is still only detected as 136.9GB.  Perhaps there is something else in my .config that is conflicting?

http://pastebin.com/6CNfDZZc

----------

## NeddySeagoon

yaplej,

Your kernel looks ok. 

Google suggests that the 137G limit is a feature of MS Hyper-V

There are two workarounds - make more smaller virtual drives and stick them together either with linear raid0 or with LVM.

----------

## yaplej

I have been reading a lot and Hyper-V R2 should use LBA48 for the ATA interface and VHDs.  The 127GB limit was in Virtual Server product and was increased to 2048GB when they introduced Hyper-V.

http://social.technet.microsoft.com/Forums/en/winserverhyperv/thread/f5784096-808b-4a66-9bfd-fecb0a0946cc

This system was upgraded from kernel 2.6.11 and with that kernel it could see this 600GB VHD although it was hdb rather than sdb due to the older chipset drivers.  There has been so many changes from then it might be difficult at best to figure out why the older worked and the newer does not.

There was some mention that Linux might not be reading the VHD geometry correctly.  I dont know if there is much merrit to that.

Another solution was to use the Hyper-V drivers and connect the VHD with the Hyper-V SCSI interface.  I have read that some people were able to access larger VHDs using that method.  The problem I have is the modules seem to crash the system when I insmod them.  Perhaps thats another thread though.

I still think this is the same issue that was discused back in 2009 here http://www.serverphorums.com/read.php?12,79638.  Going over the commands they checked in that discussion the drive is being read as 136GB.

```

hdparm -I /dev/sdb

/dev/sdb:

ATA device, with non-removable media

        Model Number:       Virtual HD

        Serial Number:

        Firmware Revision:  1.1.0

Standards:

        Likely used: 2

Configuration:

        Logical         max     current

        cylinders       16383   65535

        heads           16      16

        sectors/track   63      255

        --

        bytes/track: 65024      bytes/sector: 512

        CHS current addressable sectors:  267382800

        LBA    user addressable sectors:  267382800

        device size with M = 1024*1024:      130558 MBytes

        device size with M = 1000*1000:      136899 MBytes (136 GB)

Capabilities:

        LBA, IORDY(can be disabled)

        Buffer size: 64.0kB

        Standby timer values: spec'd by Vendor

        R/W multiple sector transfer: Max = 128 Current = 128

        DMA: sdma0 sdma1 sdma2 mdma0 mdma1 *mdma2

             Cycle time: min=120ns recommended=120ns

        PIO: pio0 pio1 pio2 pio3 pio4

             Cycle time: no flow control=333ns  IORDY flow control=120ns

```

```

hdparm --Istdout /dev/sda

/dev/sda:

 HDIO_GET_MULTCOUNT failed: Inappropriate ioctl for device

 IO_support   =  1 (32-bit)

 readonly     =  0 (off)

 readahead    = 256 (on)

 geometry     = 9529/255/63, sectors = 78381957120, start = 0

045a 3fff 0000 0010 fe00 0200 003f abcd

dcba 0123 2020 2020 2020 2020 2020 2020

2020 2020 2020 2020 0003 0080 0000 312e

312e 3020 2020 5669 7274 7561 6c20 4844

2020 2020 2020 2020 2020 2020 2020 2020

2020 2020 2020 2020 2020 2020 2020 8080

0000 0f00 0000 0200 0200 0003 9292 0010

00ff f6e0 091f 0180 f6e0 091f 0007 0407

0003 0078 0078 014d 0078 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

0000 0000 0000 0000 0000 0000 0000 0000

```

----------

## NeddySeagoon

yaplej,

Linux had never cared about HDD geometery, its always used LBA.

When drives reached around 4Gb, geometery was a myth perpretrated by hard drives for uses of DOS based OS, like Windows as far as Windows 98.

At around 4G, HDD became zoned, so different zones have a different number of sectors per track. This makes better use of the platter surface since outer tracks can store more sectors pert track then inner tracks.  The effect is easy to detect - try sequential read speed tests near the outside and inside the of the disk. There is about a 2:1 difference.

The 137Gb limit is the VM not reporting any data in the LBA48 field of the IDE drive identify command, so linux uses the LBA28 data, which is correctly maxed out at 133Gb.

This is non compliant with the IDE standard which requires HDD > 137G to populate the LBA48 field.

----------

## yaplej

Thanks for clarifying that.  Like I said I didnt know if there was any merrit to that.

This has me wondering though why back in kernel 2.6.11 it worked and now in 2.6.36 it does not.  I guess we can assume Windows would read the LBA fields just like Linux would I mean hardware is hardware even if its emulated or not right?  So I created a new VM with a single 400GB VHD connection to the IDE interface.  After installing Windows XP Pro and it was able to recognize the full 400GB.  Widows does not count though so I then tried CentOS 5.4 i386 and it also can see it as a full 400GB.  I did noticed that in CentOS the VHD was reported as hda rather than sda and found CentOS is using kernel 2.6.18 so that explains why it can access the full 400GB drive because it seemed to work before 2.6.28.

I think your right that the only way around this right now is to use LVM or raid 0 with multiple drives.  At least that way I can get this project moving along and my data online again.

----------

## NeddySeagoon

yaplej,

In a VM the hard drive is emulated.  If the emulated response to the identify command is incomplete/incorrect - its the emulator that is broken.

The idea is that the guest can't tell the difference between real hardware and the VM.  In this case, it can.

The old IDE kernel branch used to have some options to make it more tolerant of malformed identify responses but its gone on 2.6.36. 

I've not used the IDE branch since 2.6.23. I have no idea when it went away.

----------

## yaplej

Thanks.

It makes sense if the older kernel was more tolerent of the emulation oddities.  The SCSI interface does seems to work for VHD > 137GB if I can get the hv modules to work with any sort of consistency/stability.

----------

## NeddySeagoon

yaplej,

It may have been more tolerant od drive oddities. The kernel is not supposed to be able to tell its in a VM and not on bare hardware.

I don't know if the option was removed, so there is now no user control or if it was automated somehow.

----------

## yaplej

Well I think this is SOLVED the IDE interface emulation in Hyper-V seems to have broken LBA48 support.  SCSI emulation works but is not stable at least in my playing around with it.  If I can get the system to boot with the hv modules it can access a VHD > 137GB but getting the system to boot with the hv modules has been difficult and inconsistent at best.

----------

