Alan Cox wrote:
> The one I sent has a memory leak but it won't matter for basic testing.
> Or you can change the final bit to
>
>
> scsi_normalize_sense((char *)sense, sizeof(*sense), &sshdr);
>
> if (zebedee != cgc->buffer) {
> if (cgc->data_direction ==
> That's as close as it gets without redoing everything from scratch.
> I'll give Alan's and James' patches a go within the next 13 hours.
>
> (Alan: what *else* would you name a variable associated with a bounce
> buffer besides Zebedee? Thanks for the occasion to smile...)
The one I sent has a
Jens Axboe wrote:
> Try Alan's patch, it should fix it. As mentioned earlier in this thread,
> the real fix is to get rid of the cgc stuff and inject into the block
> layer from cdrom.c. But Alan's patch should work-around the issue for
> now.
Trying that patch is the next thing on my plate. For
On Mon, Apr 30 2007, Bob Tracy wrote:
> rct wrote:
> > Apologies to all concerned for an unfortunate delay in resolving this.
> > (...)
> > I'll go retrieve a more conservatively-configured source tree (closer to
> > what DSL-N uses) and start over...
>
> Success with the Debian 2.6.18-4-486 build
rct wrote:
> Apologies to all concerned for an unfortunate delay in resolving this.
> (...)
> I'll go retrieve a more conservatively-configured source tree (closer to
> what DSL-N uses) and start over...
Success with the Debian 2.6.18-4-486 build, which is known to work
almost as well on the test
On Mon, Apr 30 2007, Christoph Hellwig wrote:
> On Mon, Apr 30, 2007 at 07:32:45PM +0200, Jens Axboe wrote:
> > It's due to the crappy ->generic_packet() ioctl stuff, it bypasses the
> > block layer. So that needs to be converted to use block pc requests and
> > the block layer interface, then thin
On Mon, Apr 30, 2007 at 07:32:45PM +0200, Jens Axboe wrote:
> It's due to the crappy ->generic_packet() ioctl stuff, it bypasses the
> block layer. So that needs to be converted to use block pc requests and
> the block layer interface, then things will just work.
>
> Christoph had a sort-of ready
On Fri, Apr 27 2007, James Bottomley wrote:
> > sgpnt[0:1] page c1ee5af0/0x1ee5af0 length 32
> > Kernel panic - not syncing: Buffer at physical address > 16 Mb used for
> > aha1542
> >
> > As before, no problems using the sda hard disk (which is the boot drive):
> > everything works reliably unti
Apologies to all concerned for an unfortunate delay in resolving this.
I chose "unwisely" when I picked a popular experimental distro's
2.6.20 kernel source as a base for my troubleshooting efforts. The
resulting kernel panics when it tries to load the initial ramdisk, and
I don't have the patienc
Alan Cox wrote:
> > As before, no problems using the sda hard disk (which is the boot drive):
> > everything works reliably until I touch the cdrom drive.
>
> A little quiet contemplation and gnome number 387 suggests trying the
> following
> (and providing more detailed information such as the l
James Bottomley wrote:
> On Fri, 2007-04-27 at 16:47 -0500, Bob Tracy wrote:
> > I previously reported an ISA DMA issue for the 2.6.12 kernel. The issue
> > persists through at least 2.6.18. SCSI controller is an Adaptec
> > AHA-1542B (ISA).
> >
> > The action "mount -t iso9660 /dev/scd0 /mnt/cd
On Fri, 2007-04-27 at 16:47 -0500, Bob Tracy wrote:
> I previously reported an ISA DMA issue for the 2.6.12 kernel. The issue
> persists through at least 2.6.18. SCSI controller is an Adaptec
> AHA-1542B (ISA).
>
> The action "mount -t iso9660 /dev/scd0 /mnt/cdrom -r"
>
> produces
>
> (cdrom d
> As before, no problems using the sda hard disk (which is the boot drive):
> everything works reliably until I touch the cdrom drive.
A little quiet contemplation and gnome number 387 suggests trying the following
(and providing more detailed information such as the last message printed before
th
I previously reported an ISA DMA issue for the 2.6.12 kernel. The issue
persists through at least 2.6.18. SCSI controller is an Adaptec
AHA-1542B (ISA).
The action "mount -t iso9660 /dev/scd0 /mnt/cdrom -r"
produces
(cdrom detection messages as various modules autoload, then...)
sgpnt[0:1] pag
14 matches
Mail list logo
