[17:05] <lamont> May 21 09:18:29 mix kernel: [159411.675112] rtc: lost 17 interrupts                     
[17:06] <lamont> make it stop saying that, mk?
[19:38] <psusi> does anyone know why the kernel was changed to default to defeating host protected areas on disks and why this should not be considered a bug and reverted?
[19:49] <mjg59> psusi: Because the alternative was for people's systems to stop working when they switched from IDE to libata
[19:49] <psusi> mjg59: eh?
[19:49] <mjg59> Turns out that most people consider that a bug
[19:49] <psusi> mjg59: I'm seeing people's systems breaking because of this change
[19:49] <mjg59> psusi: The IDE system deactivated the HPA since, well, forever
[19:49] <psusi> oh really?
[19:50] <mjg59> Yes
[19:50] <mjg59> So people created partitions in the HPA
[19:50] <mjg59> When libata didn't deactivate the HPA, stuff broke
[19:50] <psusi> hrm.... why is that not broken?  HPA means you arent supposed to muck with it
[19:50] <mjg59> Because their filesystems now extended into unreachable areas of the disk
[19:50] <psusi> well, yea... but it was broken before and then fixed
[19:50] <mjg59> No
[19:50] <psusi> so we revert to the broken heavior?  doesn't seem right
[19:51] <psusi> behavior even
[19:51] <mjg59> There is no way in the universe you can claim that breaking people's filesystems is a fix
[19:51] <psusi> no, the fix was NOT breaking HPA
[19:51] <mjg59> There is no way in the universe you can claim that breaking people's filesystems is a fix
[19:51] <psusi> but if they already had a broken system then fixing it broke their system
[19:52] <mjg59> That's not an acceptable option
[19:52] <mjg59> Which is why upstream behaiour was changed
[19:52] <mjg59> Also, this happened over a year ago
[19:52] <psusi> how is it acceptable to allow them to break their system by overwriting the HPA?
[19:53] <psusi> there may be parts of the bios written there that if we overwrite, the system won't boot
[19:53] <mjg59> Yes, it's acceptable to let people do that
[19:53] <mjg59> No, there will not be parts of the BIOS written there
[19:53] <psusi> there could be... you don't know why the bios protected it
[19:54] <mjg59> Yes, and it could also contain child pornography
[19:54] <psusi> it seems that some vendors put bios extension programs there
[19:54] <mjg59> In which case being able to delete it would be a good thing
[19:54] <psusi> the point is that via HPA, the bios is telling us DON'T TOUCH
[19:54] <mjg59> No, vendors do not put bios extension programs there
[19:55] <psusi> if you as the user want to override that, that's one thing... but doing it by default?
[19:55] <psusi> I have heard of some that do
[19:55] <psusi> there is at least one vendor I have heard of that uses it to store some sort of instant on cd playing program
[19:55] <psusi> so you can play audio cds without booting up fully
[19:55] <mjg59> Yes, it's a filesystem containing Linux
[19:56] <mjg59> It's not a BIOS extension
[19:56] <psusi> right... but it's marked as protected... so then we come and install Ubuntu and trash it
[19:56] <mjg59> So don't trash it
[19:56] <mjg59> The partitioner makes it easy to avoid this
[19:56] <psusi> kind of hard when it just looks like the tail end of free space on the disk
[19:56] <mjg59> No, it'll still look like a partition
[19:56] <psusi> it isn't listed in the partition table since it exists in the hidden part of the disk
[19:57] <mjg59> jpgpls
[19:58] <psusi> though at least in this one person's case, the protected area doesn't appear to contain anything.... but for some reason the bios wanted it protected and it's causing a problem when the disk size does not match what the bios recorded, which was minus the hpa
[19:59] <mjg59> "disk size"?
[20:00] <mjg59> If there's an HPA, the BIOS will still see the HPA
[20:00] <mjg59> It's not altered until Linux starts up
[20:00] <psusi> it appears to record the size without the hpa when it writes the fakeraid metadata
[20:00] <mjg59> Hm. Though, potentially, it would cause problems if the kernel or grub files end up in the HPA
[20:00] <psusi> then linux starts, disables the hpa, and suddenly the disk size is wrong
[20:00] <mjg59> psusi: At which point the BIOS isn't called again, so there's no problem
[20:01] <psusi> yea, there is... the metadata is now in the wrong location
[20:01] <mjg59> What metadata?
[20:01] <mjg59> What do you mean by "wrong location"?
[20:01] <psusi> it's supposed to be the last 2 sectors of the disk... but in this case, it's actually about a meg short of there
[20:01] <psusi> fakeraid metadata
[20:01] <mjg59> What?
[20:01] <mjg59> Ah
[20:01] <psusi> the bios writes it to what IT sees as the last 2 sectors
[20:01] <psusi> but that's just before the HPA starts
[20:01] <mjg59> That's more interesting, but easy to fix
[20:02] <psusi> we lift the HPA and now it's not in the last two sectors
[20:02] <mjg59> Ridiculously retarded BIOS
[20:02] <psusi> probably ;)
[20:02] <psusi> "but it works fine with windows"
[20:02] <mjg59> But, as I said, easy to fix
[20:02] <mjg59> The fakeraid code needs to check both the reported size and the old size
[20:03] <psusi> ack
[20:03] <psusi> hrm.... how would it find the old size?
[20:04] <mjg59> The kernel has the original size
[20:04] <mjg59> It reads it before messing with the HPA
[20:05] <psusi> any idea how one would look that up?
[20:05] <mjg59> In-kernel? Not off-hand.
[20:05] <mjg59> Just grep for hpa in drivers/ata/
[20:05] <psusi> hrm... guess it's time to do a git clone
[20:05] <mjg59> ANyway, getting into the station now
[20:05]  * mjg59 leaves
[21:59] <psusi> mjg59: it appears that the kernel does NOT retain the HPA disk size after lifting the limit
[22:06] <psusi> libata defines the parameter ata_ignore_hpa... can you not just pass ata_ignore_hpa=0 on the kernel command line if it is built as a module?