On Thu, Sep 26, 2013 at 4:09 PM, Tejun Heo <tj@xxxxxxxxxx> wrote: > (cc'ing Kay) > > On Wed, Sep 25, 2013 at 04:40:30PM +0200, Levente Kurusa wrote: >> I am getting the following output: >> [ 2.236379] ata_piix 0000:00:1f.2: MAP [ >> [ 2.236492] P0 P2 -- -- ] >> Instead of the expected: >> [ 2.236379] ata_piix 0000:00:1f.2: MAP [ P0 P2 -- -- ] >> >> This might be a minor problem, but I think it is better the second way. >> Of course, now that I better understand the code, I see that my fix to this, >> is not the best. I will make a new patch, if you think this should be fixed. > > Hmmm... so, you're saying pr_cont() is misbehaving after dev_info()? > If so, we don't want to paper over that from a low level driver like > ata_piix. Let's find out what's going on with pr_cont(). > > Kay, Levente is seeing the above output from > drivers/ata/ata_piix.c::piix_init_sata_map(). Any ideas? Yes, the dev_printk() versions are "atomic lines", cannot be concatenated with other invocations of printk() like the normal printks can. The reason is that the dev_* versions carry structured data to userspace, and there, the logs are indexed by device. We don't want to allow the convenient but very racy and non-thread-safe concatenation lines for dev_* versions, they might pick up unrelated text fragments from other threads into the logged text line; userspace (non-human tools) can not really cope with that. So, the printk should not use the dev_* version, or print all in one call, if a single line is expected. Kay -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
