The kernel fails to see the entire disk with 2.6.34-rc2 with VIA
vt82c586b chipset.  I tracked it down to commit
f931a5d5785d7b7c44871bd7ad2762e29dfddf29 "via82cxxx: workaround h/w
bugs" and reverting just that one solves the problem, or just
commenting out just one outb write in that change.

via82cxxx 0000:00:07.1: VIA vt82c586b (rev 41) IDE UDMA33
via82cxxx 0000:00:07.1: IDE controller (0x1106:0x0571 rev 0x06)
via82cxxx 0000:00:07.1: not 100% native mode: will probe irqs later

Note the kernel panic is intentional as I'm given the test kernel an
invalid root device, so that I can suspend to disk, try a kernel,
resume and pick up where I left off.  It does have a side benefit of
dumping the size of all partitions.

2.6.34-rc2 unmodified, fails and sees 30985416 KiB for the last
partition.
ide-gd driver 1.18
hda: max request size: 128KiB
hda: 66055248 sectors (33820 MB) w/7936KiB Cache, CHS=65531/16/63
hda: cache flushes supported
 hda: hda1 hda2 hda3
hda: p3 size 236037312 exceeds device capacity, enabling native capacity
hda: p3 size 236037312 exceeds device capacity, limited to end of disk
ide-cd driver 5.00
...
Please append a correct "root=" boot option; here are the available partitions:
0300        33027624 hda driver: ide-gd
  0301           49391 hda1
  0302         1992816 hda2
  0303        30985416 hda3
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(22,2)

2.6.34-rc2 with patch revered, correct size 118018656
ide-gd driver 1.18
hda: max request size: 128KiB
hda: Host Protected Area detected.
        current capacity is 66055248 sectors (33820 MB)
        native  capacity is 240121728 sectors (122942 MB)
hda: 66055248 sectors (33820 MB) w/7936KiB Cache, CHS=65531/16/63
hda: cache flushes supported
 hda: hda1 hda2 hda3
hda: p3 size 236037312 exceeds device capacity, enabling native capacity
hda: detected capacity change from 33820286976 to 122942324736
ide-cd driver 5.00
0300       120060864 hda driver: ide-gd
  0301           ...
[ message continues ]

Does libata + pata_via work, if you pass ignore_hpa=1 module option to 
libata?

	Jeff




--

[ message continues ]

No, here is the output with ignore_hpa=1 on the command line.  I also
don't see any difference with it not on the command line.

scsi0 : pata_via
scsi1 : pata_via
ata1: PATA max UDMA/33 cmd 0x1f0 ctl 0x3f6 bmdma 0xe400 irq 14
ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0xe408 irq 15
ata1.00: HPA detected: current 66055248, native 240121728
ata1.00: ATA-7: Maxtor 6Y120P0, YAR41BW0, max UDMA/133
ata1.00: 66055248 sectors, multi 16: LBA 
ata1.00: configured for UDMA/33
scsi 0:0:0:0: Direct-Access     ATA      Maxtor 6Y120P0   YAR4 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 66055248 512-byte logical blocks: (33.8 GB/31.4 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda3
sda: p3 size 236037312 exceeds device capacity, limited to end of disk
sd 0:0:0:0: [sda] Attached SCSI disk
ata2.01: ATAPI: PLEXTOR CD-R   PX-W4012A, 1.06, max UDMA/33
ata2.01: configured for UDMA/33
scsi 1:0:1:0: CD-ROM            PLEXTOR  CD-R   PX-W4012A 1.06 PQ: 0 ANSI: 5
...
VFS: Cannot open root device "1602" or unknown-block(22,2)
Please append a correct "root=" boot option; here are the available partitions:
0800        33027624 sda driver: sd
  0801           49391 sda1
  0802         1992816 sda2
  0803        30985416 sda3
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(22,2)

-- 
David Fries <david@fries.net>
http://fries.net/~david/ (PGP encryption key available)
--

[ message continues ]

I said "module option", which is different from a kernel command line 
option.

If you are trying to build a module into the kernel image itself, you 
must use the "modulename.moduleoption" format on the kernel command 

This message should hopefully change, when the module option is 

All these errors related to unknown-block(22,2) are it trying to find 
/dev/hdX, when libata uses the SCSI block devices /dev/sdX

These errors are unrelated to HPA, and are a standard issue encountered 
when moving from legacy IDE driver to libata.

	Jeff


--

[ message continues ]

added
libata.dma=0 libata.ignore_hpa=1
and it's showing the full disk again, thanks for pointing that out,
I'm just not used to giving module parameters on the kernel command
line.  Now I'll see what Bartlomiej Zolnierkiewicz has to say about
his patch which broke via82cxxx.

scsi0 : pata_via
scsi1 : pata_via
ata1: PATA max UDMA/33 cmd 0x1f0 ctl 0x3f6 bmdma 0xe400 irq 14
ata2: PATA max UDMA/33 cmd 0x170 ctl 0x376 bmdma 0xe408 irq 15
ata1.00: HPA unlocked: 66055248 -> 240121728, native 240121728
ata1.00: ATA-7: Maxtor 6Y120P0, YAR41BW0, max UDMA/133
ata1.00: 240121728 sectors, multi 16: LBA 
ata1.00: configured for PIO4
scsi 0:0:0:0: Direct-Access     ATA      Maxtor 6Y120P0   YAR4 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 240121728 512-byte logical blocks: (122 GB/114 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
ata2.01: ATAPI: PLEXTOR CD-R   PX-W4012A, 1.06, max UDMA/33
ata2.01: configured for PIO4
scsi 1:0:1:0: CD-ROM            PLEXTOR  CD-R   PX-W4012A 1.06 PQ: 0 ANSI: 5
...
VFS: Cannot open root device "1602" or unknown-block(22,2)
Please append a correct "root=" boot option; here are the available partitions:
0800       120060864 sda driver: sd
  0801           49391 sda1
  0802         1992816 sda2
  0803       118018656 sda3
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(22,2)

-- 
David Fries <david@fries.net>
http://fries.net/~david/ (PGP encryption key available)
--

[ message continues ]

Please bring upstream IDE problems with upstream kernel maintainer.

I have very little control over what people are doing with some (taken
out of much larger context) atang-specific patches posted for review
to kernel mailing lists and over quality of integration/testing work
that should always accompany upstream merge.

The commit itself may also have a problem but since it was _never_ in
linux-next tree it never saw a wider upstream testing.  Moreover upstream
doesn't use unified driver source (atang tree does) which makes makes
debugging and long-term maintenance more time consuming than necessary.

I'm sorry to hear about your problem but it is not my fault and I prefer
using my _private_ time in more constructive ways..

--
Bartlomiej Zolnierkiewicz
--

[ message continues ]

From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>

This is not true Bart.

My ide-2.6 and ide-next-2.6 trees are both included in
linux-next   And if they are not, that needs to be fixed
because they very much are intended to be.

In any event, you wrote a patch which broke something and
if you're not willing to work on a fix I have no choice
but to simply revert.
--

[ message continues ]

Uh?  I had verified my claims before writing previous mail..

The patch ("via82cxxx: workaround h/w bugs") appeared in Linus'
tree on 19th January and it was neither in next-20100101 nor in
next-20100119.. etc.



Please..

You picked a patch out of larger patch series posted to a mailing
list (which was clearly marked as a one for my atang tree and not
for upstream), then you merged it adding your sign-off, did poor
job w.r.t. linux-next testing phase and now I'm the one to blame
for the breakage? :)

Well, your stance on kernel project management has been already
made crystal clear during rt28xx driver discussions so I'm not
really surprised here.  I also don't remember ever signing support
contract with you or your employer so I will be putting your mails
into a separate folder (lets call it 'almost-spam') from now on..

--
Bartlomiej Zolnierkiewicz
--

[ message continues ]

Hi Bart,


That commit first appeared in linux-next in next-20100120 as part of
Dave's ide tree.  It was merged into Linus' tree on March 5th (commit
4c10c937cc2eb197db565392db91d429eec71176 "Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-next-2.6").

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[ message continues ]

Hi Stephen,


Which doesn't change a bit the fundamental fact that the patch was not
meant for upstream by me and was clearly marked as such.  If David wanted
it upstream he should either be ready to provide support for it himself
or solve it in a more formal way..

--
Bartlomiej Zolnierkiewicz
--

[ message continues ]

From: David Fries <david@fries.net>

I've reverted Bart's change and will push that out to Linus.

Thanks for your report.
--

[ message continues ]