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