On 4/4/07, Rene Herman <[EMAIL PROTECTED]> wrote:
Taking forever to reproduce in as far as getting the oops. The thing is
now just locking hard each time. Will keep on trying...
Can you get anything out with sysrq-t? The original oops would be
enough to conclude it's a double-free if it weren't
On Tue, Apr 03 2007, Pekka J Enberg wrote:
> > mcdx:: close()
>
> However, we never hit do_mcdx_request(). Jens, do we need to do
> set_capacity() somewhere? I don't see other cdrom drivers doing it but
> they could be broken too...
Yeah, that would be appropriate.
--
Jens Axboe
-
To unsubsc
On 04/03/2007 08:32 PM, Pekka J Enberg wrote:
Please enable CONFIG_DEBUG_SLAB now and reproduce. It should tell us
what's going wrong there.
Taking forever to reproduce in as far as getting the oops. The thing is
now just locking hard each time. Will keep on trying...
Rene.
-
To unsubscrib
On Tue, 3 Apr 2007, Rene Herman wrote:
> That is, the exact same oops the tar test showed which I expect is progress --
> the dd is now in fact doing something :-)
Yes, that's expected. I think we fixed dd now.
On Tue, 3 Apr 2007, Rene Herman wrote:
> When I now switched the monitor to 5va2 itsel
On 04/03/2007 07:31 PM, Pekka J Enberg wrote:
Oh, well, here goes. Rene, would you be so kind and spin the wheel once
more? =)
Absolutely!
[EMAIL PROTECTED]:~# dd if=/dev/mcdx0 of=/dev/null
Oops: 0002 [#1]
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010082 (2.6.20.4 #11)
EIP is
On Tue, 3 Apr 2007, Rene Herman wrote:
> I believe the "tar" runs has produced something useful now though:
>
> [EMAIL PROTECTED]:~# dmesg -c >/dev/null
> [EMAIL PROTECTED]:~# strace -o tar.strace tar cvf foo.tar /mnt/cdrom
> tar: Removing leading `/' from member names
> /mnt/cdrom/
> /mnt/cdrom/d
On Tue, 3 Apr 2007, Pekka J Enberg wrote:
> However, we never hit do_mcdx_request(). Jens, do we need to do
> set_capacity() somewhere? I don't see other cdrom drivers doing it but
> they could be broken too...
Oh, well, here goes. Rene, would you be so kind and spin the wheel once
more? =)
On 04/03/2007 08:57 AM, Pekka J Enberg wrote:
> > Does this change the dd case?
> >
> > diff --git a/drivers/cdrom/mcdx.c b/drivers/cdrom/mcdx.c
> > index f574962..6c613d0 100644
> > --- a/drivers/cdrom/mcdx.c
> > +++ b/drivers/cdrom/mcdx.c
> > @@ -1248,6 +1248,7 @@ #endif
> > disk->private_data
On 04/03/2007 08:57 AM, Pekka J Enberg wrote:
[ re-including linux-kernel ]
Does this change the dd case?
diff --git a/drivers/cdrom/mcdx.c b/drivers/cdrom/mcdx.c
index f574962..6c613d0 100644
--- a/drivers/cdrom/mcdx.c
+++ b/drivers/cdrom/mcdx.c
@@ -1248,6 +1248,7 @@ #endif
disk->priv
On 04/02/2007 11:42 AM, Jens Axboe wrote:
I somehow doubt that the cards are capable of highmem addressing in
the first place :-)
Well, we could pretend we're using 286s and define the 15-16 MB hole as
"highmem". But other than that, these things plug into an ISA bus, so
no. Most of them are
On 04/02/2007 05:18 PM, Rene Herman wrote:
Thanks again, spinning!
Oh, forgot to mention. Yes, earlier PREEMPT was on and it's now disabled.
Rene.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at ht
On 04/02/2007 09:10 AM, Jens Axboe wrote:
Updated patch attached :-)
diff --git a/Documentation/feature-removal-schedule.txt
b/Documentation/feature-removal-schedule.txt
index 0bc8b0b..cff761a 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.
On 04/02/2007 10:55 AM, Pekka J Enberg wrote:
On Mon, 2 Apr 2007, Jens Axboe wrote:
But as I wrote earlier, it'll take lots more to make this driver close
to functional.
Heh, looking at the driver, that's quite an understatement =). Rene,
here's an untested attempt to use a mutex instead o
Pekka J Enberg wrote:
> On Mon, 2 Apr 2007, Jens Axboe wrote:
>> But as I wrote earlier, it'll take lots more to make this driver close
>> to functional.
>
> Heh, looking at the driver, that's quite an understatement =). Rene,
> here's an untested attempt to use a mutex instead of the horribly b
On Mon, Apr 02 2007, Boaz Harrosh wrote:
> Pekka J Enberg wrote:
> > On Mon, 2 Apr 2007, Jens Axboe wrote:
> >> But as I wrote earlier, it'll take lots more to make this driver close
> >> to functional.
> >
> > Heh, looking at the driver, that's quite an understatement =). Rene,
> > here's an un
On Mon, 2 Apr 2007, Boaz Harrosh wrote:
> Why are you using req->buffer in new code.
You did read the patch, right? It's not new code. Feel free to send a
patch, though. Thanks.
Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On Mon, 2 Apr 2007, Jens Axboe wrote:
> But as I wrote earlier, it'll take lots more to make this driver close
> to functional.
Heh, looking at the driver, that's quite an understatement =). Rene,
here's an untested attempt to use a mutex instead of the horribly broken
waitqueue "synchronizatio
On Mon, 2 Apr 2007, Jens Axboe wrote:
> Updated patch attached :-)
>
> diff --git a/Documentation/feature-removal-schedule.txt
> b/Documentation/feature-removal-schedule.txt
> index 0bc8b0b..cff761a 100644
> --- a/Documentation/feature-removal-schedule.txt
> +++ b/Documentation/feature-removal-sc
On Mon, Apr 02 2007, Pekka J Enberg wrote:
> On Mon, 2 Apr 2007, Rene Herman wrote:
> > + if (!blk_fs_request(req)) {
> > + spin_lock_irq(q->queue_lock);
>
> Contrary to what I said, this spin_lock_irq() is wrong...
>
> > + end_request(req, 0);
> > +
Hi Rene,
On 4/2/07, Rene Herman <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED]:~# dd if=/dev/mcdx0 of=/dev/null bs=2048
0+0 records in
0+0 records out
0 bytes (0 B) copied, 0.000221955 seconds, 0.0 kB/s
[EMAIL PROTECTED]:~#
This I know isn't:
[EMAIL PROTECTED]:~# readcd dev=/dev/mcdx0 f=/dev/nul
On Mon, 2 Apr 2007, Rene Herman wrote:
> + if (!blk_fs_request(req)) {
> + spin_lock_irq(q->queue_lock);
Contrary to what I said, this spin_lock_irq() is wrong...
> + end_request(req, 0);
> + goto again;
> + }
> +
> + spin_unlock_irq(q->
On Mon, Apr 02 2007, Rene Herman wrote:
> On 04/01/2007 12:06 PM, Pekka Enberg wrote:
>
> >Looks like mcdx_xfer is sleeping while holding q->queue_lock. The
> >attached (untested) patch should fix it.
>
> This (including your followup) does indeed avoid the traces in the
> kernel log, but unfor
On 04/02/2007 02:02 AM, Rene Herman wrote:
On 04/01/2007 12:06 PM, Pekka Enberg wrote:
Looks like mcdx_xfer is sleeping while holding q->queue_lock. The
attached (untested) patch should fix it.
This (including your followup) does indeed avoid the traces in the
kernel log, but unfortunately,
On 04/01/2007 12:06 PM, Pekka Enberg wrote:
Looks like mcdx_xfer is sleeping while holding q->queue_lock. The
attached (untested) patch should fix it.
This (including your followup) does indeed avoid the traces in the
kernel log, but unfortunately, the driver seems to need a bit more.
This
On 4/1/07, Pekka Enberg <[EMAIL PROTECTED]> wrote:
Looks like mcdx_xfer is sleeping while holding q->queue_lock. The
attached (untested) patch should fix it.
You also need to add a spin_lock_irq() before the call to
end_request() to Jens' patch.
-
To unsubscribe from this list: send the line "u
On 3/31/07, Rene Herman <[EMAIL PROTECTED]> wrote:
There's quite a bit of noise in dmesg though. Repeated 5 times:
===BUG: scheduling while atomic: mount/0x0001/1166
[] __sched_text_start+0x57/0x574
[] schedule_timeout+0x70/0x8f
[] process_timeout+0x0/0x5
[] interruptible_sleep_on_ti
On 03/31/2007 08:47 AM, Jens Axboe wrote:
Try this.
diff --git a/drivers/cdrom/mcdx.c b/drivers/cdrom/mcdx.c
index f574962..7086313 100644
--- a/drivers/cdrom/mcdx.c
+++ b/drivers/cdrom/mcdx.c
@@ -577,6 +577,11 @@ static void do_mcdx_request(request_queue_t * q)
if (!req)
read-only
> mount: /dev/mcdx0: can't read superblock
>
> [EMAIL PROTECTED]:~# dmesg | tail -4
> mcdx: Mitsumi CD-ROM installed at 0x300, irq 15. (Firmware version M 4)
> mcdx do_request(): non-read command to cd!!
> end_request: I/O error, dev mcdx0, sector 0
> FAT: unabl
on M 4)
[EMAIL PROTECTED]:~# mount /dev/mcdx0 /mnt/cdrom
mount: block device /dev/mcdx0 is write-protected, mounting read-only
mount: /dev/mcdx0: can't read superblock
[EMAIL PROTECTED]:~# dmesg | tail -4
mcdx: Mitsumi CD-ROM installed at 0x300, irq 15. (Firmware version M 4)
mcdx do_req
29 matches
Mail list logo
