"Linux regression tracking (Thorsten Leemhuis)" <regressi...@leemhuis.info> writes: > [CCing the regression list, as it should be in the loop for regressions: > https://docs.kernel.org/admin-guide/reporting-regressions.html] > > On 20.05.24 17:15, Christoph Hellwig wrote: >> Adding ben and the linuxppc list. > > Hmm, no reply and no other progress to get this resolved afaics. So lets > bring Michael into the mix, he might be able to help out.
Sorry I didn't see the original forward for some reason. I haven't seen this on my G5, but it's hard drive is on SATA. I think the CDROM is pata_macio, but there isn't a disk in the drive to test with. > BTW TWIMC: a PowerMac G5 user user reported similar symptoms here > recently: https://bugzilla.kernel.org/show_bug.cgi?id=218858 AFAICS that report is from a 4K page size kernel (Page orders: ... virtual = 12), so there must be something else going on? I've asked the reporter to confirm the page size. cheers >> Context: pata_macio initialization now fails as we enforce that the >> segment size is set properly. >> >> On Wed, May 15, 2024 at 04:52:29PM -0700, Guenter Roeck wrote: >>> pata_macio_common_init() Calling ata_host_activate() with limit 65280 >>> ... >>> max_segment_size is 65280; PAGE_SIZE is 65536; BLK_MAX_SEGMENT_SIZE is 65536 >>> WARNING: CPU: 0 PID: 12 at block/blk-settings.c:202 >>> blk_validate_limits+0x2d4/0x364 >>> ... >>> >>> This is with PPC_BOOK3S_64 which selects a default page size of 64k. >> >> Yeah. Did you actually manage to use pata macio previously? Or is >> it just used because it's part of the pmac default config? >> >>> Looking at the old code, I think it did what you suggested above, >> >>> but assuming that the driver requested a lower limit on purpose that >>> may not be the best solution. >> >>> Never mind, though - I updated my test configuration to explicitly >>> configure the page size to 4k to work around the problem. With that, >>> please consider this report a note in case someone hits the problem >>> on a real system (and sorry for the noise). >> >> Yes, the idea behind this change was to catch such errors. So far >> most errors have been drivers setting lower limits than what the >> hardware can actually handle, but I'd love to track this down. >> >> If the hardware can't actually handle the lower limit we should >> probably just fail the probe gracefully with a well comment if >> statement instead.
