I admit that the code should be locked properly instead, but the global plan
is to drop all P3 tagged printks anyway. So let it be guarded for the moment.
Signed-off-by: Pete Zaitcev <[email protected]>
--- linux-2.6.10-rc2-bk8-ub/drivers/block/ub.c 2004-11-16 17:03:02.000000000 -0800
+++ linux-2.6.10-rc1-ub/drivers/block/ub.c 2004-11-07 19:01:03.000000000 -0800
@@ -1535,8 +1535,11 @@
ub_revalidate(sc);
/* This is pretty much a long term P3 */
- printk(KERN_INFO "%s: device %u capacity nsec %ld bsize %u\n",
- sc->name, sc->dev->devnum, sc->capacity.nsec, sc->capacity.bsize);
+ if (!atomic_read(&sc->poison)) { /* Cover sc->dev */
+ printk(KERN_INFO "%s: device %u capacity nsec %ld bsize %u\n",
+ sc->name, sc->dev->devnum,
+ sc->capacity.nsec, sc->capacity.bsize);
+ }
/* XXX Support sector size switching like in sr.c */
blk_queue_hardsect_size(disk->queue, sc->capacity.bsize);
On Tue, Nov 23, 2004 at 10:02:47AM -0800, Pete Zaitcev wrote:
> I admit that the code should be locked properly instead, but the global plan
> is to drop all P3 tagged printks anyway. So let it be guarded for the moment.
>
> Signed-off-by: Pete Zaitcev <[email protected]>
Applied, thanks.
greg k-h
On Tue, 2004-11-23 at 10:02 -0800, Pete Zaitcev wrote:
Hi,
> I admit that the code should be locked properly instead, but the global plan
> is to drop all P3 tagged printks anyway. So let it be guarded for the moment.
>
Sorry for the delay, but I have not had any time to really test this
again. I did some minor testing, and only after really working it,
I could get an oops, but not nearly the same (think it was deeper into
the scsi layer or maybe kobject stuff).
Will see when I can get some time to try and generate some consistent
traces if any.
Thanks,
--
Martin Schlemmer
On Sat, 27 Nov 2004 23:38:15 +0200, "Martin Schlemmer [c]" <[email protected]> wrote:
> On Tue, 2004-11-23 at 10:02 -0800, Pete Zaitcev wrote:
> > I admit that the code should be locked properly instead, but the global plan
> > is to drop all P3 tagged printks anyway. So let it be guarded for the moment.
> Sorry for the delay, but I have not had any time to really test this
> again. I did some minor testing, and only after really working it,
> I could get an oops, but not nearly the same (think it was deeper into
> the scsi layer or maybe kobject stuff).
This is strange, because ub hasn't got any connection with SCSI layer.
Without trying to deflect the blame for improper locking in ub, I have to
ask, does it all work without the preempt for you?
-- Pete