Hello, Josh.
On Wed, Dec 04, 2013 at 05:01:53PM -0600, Josh Hunt wrote:
> So there used to be a call to async_synchronize_full() in
> ata_host_register(), but it was removed by
> f29d3b23238e1955a8094e038c72546e99308e61 as part of some fastboot
> changes. Adding it back (in the attached patch) see
On Tue, Dec 3, 2013 at 9:19 AM, Tejun Heo wrote:
> Hello,
>
> On Tue, Dec 03, 2013 at 08:28:43AM -0600, Josh Hunt wrote:
>> You're right. Thanks for pointing this out. I did not realize there
>> was a bug in the init script. The version of initramfs-tools I was
>> using had the following bug:
>> h
Hello,
On Tue, Dec 03, 2013 at 08:28:43AM -0600, Josh Hunt wrote:
> You're right. Thanks for pointing this out. I did not realize there
> was a bug in the init script. The version of initramfs-tools I was
> using had the following bug:
> https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+b
On Tue, Nov 26, 2013 at 4:29 PM, Tejun Heo wrote:
> Hello,
>
> On Tue, Nov 26, 2013 at 04:12:41PM -0600, Josh Hunt wrote:
>> I should have clarified that I'm not using dm/md in my setup. I know
>> the modules are getting loaded in the log I attached, but root is not
>> a md/dm device.
>
> Can you
On Tue, Nov 26, 2013 at 2:12 PM, Josh Hunt wrote:
>
> I should have clarified that I'm not using dm/md in my setup. I know
> the modules are getting loaded in the log I attached, but root is not
> a md/dm device.
Hmm. The initcall debugging doesn't actually show any of the "wait for
async events"
Hello,
On Tue, Nov 26, 2013 at 04:12:41PM -0600, Josh Hunt wrote:
> I should have clarified that I'm not using dm/md in my setup. I know
> the modules are getting loaded in the log I attached, but root is not
> a md/dm device.
Can you please still try it? The init script is broken and we're now
On Tue, Nov 26, 2013 at 3:53 PM, Linus Torvalds
wrote:
> On Tue, Nov 26, 2013 at 1:29 PM, Josh Hunt wrote:
>>
>> Both ahci and sata_svw call ata_host_activate(), which call
>> ata_host_register() and async_schedule(async_port_probe, ap).
>
> Well, with the modern logic ("only wait for async probi
On Tue, Nov 26, 2013 at 1:29 PM, Josh Hunt wrote:
>
> Both ahci and sata_svw call ata_host_activate(), which call
> ata_host_register() and async_schedule(async_port_probe, ap).
Well, with the modern logic ("only wait for async probing if the
module itself did async probing") the ahci and svw mod
On Mon, Aug 12, 2013 at 10:09 AM, Tejun Heo wrote:
> Hello, Jonathan.
>
> On Mon, Aug 12, 2013 at 12:04:11AM -0700, Jonathan Nieder wrote:
>> My laptop fails to boot[1] with the message 'Volume group "data" not
>> found'. Bisects to v3.8-rc4~17 (the above commit). Reverting that
>> commit on top
Hello, Jonathan.
On Mon, Aug 12, 2013 at 12:04:11AM -0700, Jonathan Nieder wrote:
> My laptop fails to boot[1] with the message 'Volume group "data" not
> found'. Bisects to v3.8-rc4~17 (the above commit). Reverting that
> commit on top of current "master" (d92581fcad18, 2013-08-10) produces
> a
Hi,
Tejun Heo wrote:
> This avoids the described deadlock because iosched module doesn't use
> async and thus wouldn't invoke async_synchronize_full(). This is
> hacky and incomplete. It will deadlock if async module loading nests;
> however, this works around the known problem case and seems t
On Wed, Jan 16, 2013 at 9:03 AM, Arjan van de Ven wrote:
>
> we can even try twice
>
> the first time right after we mount the initramfs
> the second time when the initramfs code exits, and before we exec init
> (the initramfs supposedly mounted the real root fs at this point)
Yes. This, together
As Arjan suggested, trying to load the default modules right after the
initial rootfs mount could be an acceptable compromise and it would be
really nice (for both code sanity and avoiding future problems) to be
able to declare module loading nested inside async unspported.
we can even try twi
Hey,
On Tue, Jan 15, 2013 at 07:37:42PM -0800, Linus Torvalds wrote:
> I do want the same user-visible semantics, so it's not some one-liner.
>
> The compiled-in elevator would be easy enough to handle in the Kconfig
> file (maybe we do already, I didn't even bother to check). The real
> problem
But no, it's not just some trivial one-liner. Especially the question
about "when to try to load the module that is given on the kernel
command line" is not trivial. Do we require that the module is in the
initrd and loadable basically immediate at boot? Do we try again after
switching the root
On Wed, Jan 16, 2013 at 3:52 AM, Tejun Heo wrote:
> This avoids the described deadlock because iosched module doesn't use
> async and thus wouldn't invoke async_synchronize_full(). This is
> hacky and incomplete. It will deadlock if async module loading nests;
> however, this works around the kn
Tejun Heo writes:
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -3058,8 +3064,25 @@ static int do_init_module(struct module
> blocking_notifier_call_chain(&module_notify_list,
>MODULE_STATE_LIVE, mod);
>
> - /* We need to finish all async code
On Tue, Jan 15, 2013 at 7:25 PM, Tejun Heo wrote:
> Hello, Linus.
>
> On Tue, Jan 15, 2013 at 07:00:31PM -0800, Linus Torvalds wrote:
>> That said, maybe we could just make the rule be that you can't pick a
>> default IO scheduler that is modular.
>
> This is definitely much more preferable but it
On Wed, Jan 16, 2013 at 10:52 AM, Tejun Heo wrote:
> If the default iosched is built as module, the kernel may deadlock
> while trying to load the iosched module on device probe if the probing
> was running off async. This is because async_synchronize_full() at
> the end of module init ends up wa
Hello, Linus.
On Tue, Jan 15, 2013 at 07:00:31PM -0800, Linus Torvalds wrote:
> That said, maybe we could just make the rule be that you can't pick a
> default IO scheduler that is modular.
This is definitely much more preferable but it would affect use case
where everything is built modular and
On Tue, Jan 15, 2013 at 6:52 PM, Tejun Heo wrote:
>
> It makes me feel dirty but makes the problem go away and I can't think
> of anything better, so here is the implementation of "used async"
> workaround.
Ok, people, can we get a tested-by (or "Nope, doesn't work") from the
people who saw this?
If the default iosched is built as module, the kernel may deadlock
while trying to load the iosched module on device probe if the probing
was running off async. This is because async_synchronize_full() at
the end of module init ends up waiting for the async job which
initiated the module loading.
22 matches
Mail list logo
