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
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
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 unsubscribe
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 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
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
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/
>
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
> >
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
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
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 = stuffp;
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 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/dott/
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:[c1047787]Not tainted VLI
EFLAGS: 00010082 (2.6.20.4
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 itself
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
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
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
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
+++
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
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
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
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
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
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
> +++
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
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;
> + }
> +
> +
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
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 unfortunately,
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;
+ }
+
+
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/null
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);
+ goto
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
+++
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 synchronization
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, 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 untested attempt
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 broken
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
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
+++
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
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 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
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
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
[]
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
[c1170bff] __sched_text_start+0x57/0x574
[c1171964] schedule_timeout+0x70/0x8f
[c10199b2] process_timeout+0x0/0x5
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
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 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 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)
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)
ev/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: unable to read boot sector
> [EM
]:~# 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_request(): non-read command to cd
]:~# 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_request(): non-read command to cd
. (Firmware version M 4)
mcdx do_request(): non-read command to cd!!
end_request: I/O error, dev mcdx0, sector 0
FAT: unable to read boot sector
[EMAIL PROTECTED]:~#
This same 300/15 pair works under DOS in the same machine and IRQ15 is
firing. The error sounds very block-ish. Would you happen
58 matches
Mail list logo
