a7a20d103994fd760766e6c9d494daa569cbfe06 makes kernel 3.5 unbootable on an Intel chipset based motherboard
A message that is not in the archive (sent off-list or not yet received): [email protected]/
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): CA+55aFzb+_KWYRAddkBD5Mf01fOG68D+b+560Mm3cD_fhU5p7Q@mail.gmail.com
Quoted 11 lines · Linus Torvalds
Wrong people cc'd, it looks like.
Guys, commit
a7a20d103994("sd: limit the scope of the async probe domain") is causing boot problems. It's timing-dependent and apparently sometimes works, which makes sense with that commit.However, it *should* have been fixed by commit
43a8d39d0137("fix async probe regression"), but Artem seems to report the problem even in -rc7.Comments?
As far as I can tell, the fix should have worked. However, there are a lot of assumptions in the async stuff that end up not being true in the
presence of separate async domains. We should be fixing it all here:
http://git.kernel.org/?p=linux/kernel/git/jejb/scsi.git;a=shortlog;h=refs/heads/async
I've got to say, I don't understand the bug report. all of those commits were about probing for devices. However, the screen shot
https://bugzilla.kernel.org/attachment.cgi?id=75351
shows the devices were found, it's the partition tables that weren't. For us to see the message about sda's capacity, we're already in the async code the commits were trying to synchronise with.
However, there are some missing messages: there's no partition table print and no final
sd_printk(KERN_NOTICE, sdkp, "Attached SCSI %sdisk\n", sdp->removable ? "removable " : "");
So sd_probe_async() got stuck somewhere after the first sd_revalidata_disk().
James
Quoted 50 lines
Artem, can you put a working dmesg from the last good kernel in there as plain text?
Linus
Quoted 44 lines · On Tue, Jul 17, 2012 at 12:15 PM, <[email protected]> wrote:
https://bugzilla.kernel.org/show_bug.cgi?id=44771
--- Comment #9 from Artem S. Tashkinov <[email protected]> 2012-07-17 19:15:46 --- Wow, I'm not the first person to hit this problem:
Quoted 9 lines
Dudes,
so I've been testing latest linus (
731a7378b81c2f5fa88ca1ae20b83d548d5613dc) here and my box fails booting because it can't find the root partition, see message below.I did a bisect run (also below) and pointed me to the first bad commit (see below too).
Quoted 7 lines
Reverting the commit in question fixes booting.
Let me know what other info you'd need.
Posted: Wed May 30, 2012 2:10 pm
Borislav Petkov
Yet another person:
https://lkml.org/lkml/2012/5/25/271
Quoted 5 lines
Dan Williams
Ok, I'll take a look.
Thanks for the help!
And no fix whatsoever.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Quoted 11 lines · James Bottomley
Quoted 10 lines · Linus Torvalds
Wrong people cc'd, it looks like.
Guys, commit
a7a20d103994("sd: limit the scope of the async probe domain") is causing boot problems. It's timing-dependent and apparently sometimes works, which makes sense with that commit.However, it *should* have been fixed by commit
43a8d39d0137("fix async probe regression"), but Artem seems to report the problem even in -rc7.
Quoted 7 lines
Quoted 1 line
Comments?
As far as I can tell, the fix should have worked. However, there are a lot of assumptions in the async stuff that end up not being true in the
presence of separate async domains. We should be fixing it all here:http://git.kernel.org/?p=linux/kernel/git/jejb/scsi.git;a=shortlog;h=refs/heads/async
Those commits haven't been merged into 3.5-rc7, right? So Artem isn't using them.
Quoted 8 lines
I've got to say, I don't understand the bug report. all of those commits were about probing for devices. However, the screen shot
https://bugzilla.kernel.org/attachment.cgi?id=75351
shows the devices were found, it's the partition tables that weren't. For us to see the message about sda's capacity, we're already in the async code the commits were trying to synchronise with.
That's understandable, given that those commits aren't present in Artem's kernel. Are they queued for -stable?
Quoted 8 lines
However, there are some missing messages: there's no partition table print and no final
sd_printk(KERN_NOTICE, sdkp, "Attached SCSI %sdisk\n", sdp->removable ? "removable " : "");So
sd_probe_async()got stuck somewhere after the firstsd_revalidata_disk().
No, it didn't get stuck. The problem is that the scsi_wait_scan module didn't wait for the async scanning to finish.
And the reason for that is one you're already familiar with:CONFIG_SCSI_MOD=y.
Artem, if you change all your SCSI drivers to be modular rather than built-in, that ought to fix the problem. Alternatively, you can simply continue to use the "rootwait" option.
Alan Stern
Quoted 27 lines · Alan Stern
Quoted 11 lines · James Bottomley
Quoted 10 lines · Linus Torvalds
Wrong people cc'd, it looks like.
Guys, commit
a7a20d103994("sd: limit the scope of the async probe domain") is causing boot problems. It's timing-dependent and apparently sometimes works, which makes sense with that commit.However, it *should* have been fixed by commit
43a8d39d0137("fix async probe regression"), but Artem seems to report the problem even in -rc7.Quoted 7 lines
Quoted 1 line
Comments?
As far as I can tell, the fix should have worked. However, there are a lot of assumptions in the async stuff that end up not being true in the
presence of separate async domains. We should be fixing it all here:http://git.kernel.org/?p=linux/kernel/git/jejb/scsi.git;a=shortlog;h=refs/heads/async
Those commits haven't been merged into 3.5-rc7, right? So Artem isn't using them.
Quoted 3 lines
I've got to say, I don't understand the bug report. all of those commits were about probing for devices. However, the screen shot
Quoted 8 lines
Quoted 5 lines
https://bugzilla.kernel.org/attachment.cgi?id=75351
shows the devices were found, it's the partition tables that weren't. For us to see the message about sda's capacity, we're already in the async code the commits were trying to synchronise with.
That's understandable, given that those commits aren't present in Artem's kernel. Are they queued for -stable?
I did not flag them as such given the wider entanglements.
Quoted 7 lines
Quoted 7 lines
However, there are some missing messages: there's no partition table print and no final
sd_printk(KERN_NOTICE, sdkp, "Attached SCSI %sdisk\n",
sdp->removable? "removable " : "");
Quoted 8 lines
Quoted 2 lines
So
sd_probe_async()got stuck somewhere after the firstsd_revalidata_disk().No, it didn't get stuck. The problem is that the
scsi_wait_scanmodule didn't wait for the async scanning to finish.And the reason for that is one you're already familiar with:
CONFIG_SCSI_MOD=y.
I had forgotten that additional aspect. but I don't think that is the root cause. scsi_wait_scan() is a nop in Artem's config given CONFIG_SCSI_WAIT_SCAN=m. From what I have seen ahci typically ensures that wait_for_device_probe() is all that is needed to guarantee scanning is complete which commit a7a20d103994 ("sd: limit the scope of the async probe domain") breaks, and which commit 43a8d39d0137 ("[SCSI] fix async probe regression"), does not resolve because that requires a call to scsi_complete_async_scans() to close the loop.
Quoted 3 lines
Artem, if you change all your SCSI drivers to be modular rather than built-in, that ought to fix the problem. Alternatively, you can simply continue to use the "rootwait" option.
I think setting CONFIG_SCSI_WAIT_SCAN=y would also be a workaround, or going forward with the pending async rework to make sd probe work once again visible to async_synchronize_domain_full().
--
Dan