2013-09-26 19:57 keltezéssel, Kay Sievers írta:
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
Thank you Kay for clarifying this! I think I will go with
creating a buffer, and printing this all in one line.
Tejun, during this weekend I will create a patch that
hopefully fixes this. However, if you think that setting
up a temporary buffer is inappropriate, please comment.
Thank you,
Levente Kurusa
--
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
