Hi, I don't suppose anyone has a patch for the latest 2.5 kernel do they? The older patches don't apply and there seems to be a lot of change in the areas the patch touches. What's the status with getting the patch into 2.5? -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --------------------------------------- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender.
On Fri, 28 Mar 2003, M wrote:
I don't suppose anyone has a patch for the latest 2.5 kernel do they?
I do now: http://w1.894.telia.com/~u89404340/patches/packet/2.5/packet-2.5.66.patch.bz...
What's the status with getting the patch into 2.5?
I have no idea. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
On Sat, 29 Mar 2003 09:56:35 +0100 (CET)
Peter Osterlund
On Fri, 28 Mar 2003, M wrote:
I don't suppose anyone has a patch for the latest 2.5 kernel do they?
I do now:
http://w1.894.telia.com/~u89404340/patches/packet/2.5/packet-2.5.66.patch.bz...
Many thanks, I was liking the new 2.5 stuff esp the interactivity fixes but needed the packet writing. -- Regards, M Martin Sillence PR Newswire DL +44 (0)1865 78 5065 F +44 (0)1865 78 5100 W www.prnewswire.eu.com --------------------------------------- Any views or opinions are solely those of the author and do not necessarily represent those of PR Newswire Europe. The e-mail contents are intended only for addressee and may contain confidential and/or privileged material. If you are not the intended recipient, please do not read, copy, use or disclose this communication and notify the sender.
On Sat, Mar 29 2003, Peter Osterlund wrote:
On Fri, 28 Mar 2003, M wrote:
I don't suppose anyone has a patch for the latest 2.5 kernel do they?
I do now:
http://w1.894.telia.com/~u89404340/patches/packet/2.5/packet-2.5.66.patch.bz...
What's the status with getting the patch into 2.5?
I have no idea.
A few things that need to be addressed before I can send it to Linus: - scsi_lib.c change, I cannot safely push this change. At some point the request needs to be killed, if it repeatedly returns NOT_READY. I'd recommend we just drop this for now. - relocate_blocks() hook must be dropped for now. - BIO_RW/REQ_RW abuse. Please use bio_data_dir() and rq_data_dir(). - You must not use bio_alloc() for permanent bio allocations! In theory, you could deplete the entire emergency pool this way, the whole kernel io system would break down. - pkt_fixup_segments() is deeply broken, how could this ever work?! You are passing i on the stack, the rest of the logic looks suspicious at best. - pkt_gather_data(), you should use bio_add_page(). this function should probably be rewritten. make-up bio's for the missing segments of a request, and piggy back the original bio to them. when they have all completed, send off the write. - Probably drop the -20 priority from kcdrwd -- Jens Axboe
On Tue, 1 Apr 2003, Jens Axboe wrote:
On Sat, Mar 29 2003, Peter Osterlund wrote:
On Fri, 28 Mar 2003, M wrote:
What's the status with getting the patch into 2.5?
I have no idea.
A few things that need to be addressed before I can send it to Linus:
Hi Jens. Thanks for the feedback.
- scsi_lib.c change, I cannot safely push this change. At some point the request needs to be killed, if it repeatedly returns NOT_READY. I'd recommend we just drop this for now.
Dropped. I kept it as a reminder to port the 2.4 fix that inserts "sync cache" commands in the request queue when switching from write to read mode. In some cases the scsi_lib.c change works around the problem that is fixed by the "sync cache" commands, but it doesn't work for all hardware. As we have discussed before, the better fix is probably to make the low level drivers (ide-cd.c and sr.c) insert the "sync cache" commands on their own.
- relocate_blocks() hook must be dropped for now.
Done.
- BIO_RW/REQ_RW abuse. Please use bio_data_dir() and rq_data_dir().
Fixed.
- You must not use bio_alloc() for permanent bio allocations! In theory, you could deplete the entire emergency pool this way, the whole kernel io system would break down.
I suspected this could happen. I don't see a way to make the bio objects non permanent. Does this mean I have to duplicate all code in bio_alloc() and replace the mempool_alloc() calls with kmalloc calls? Btw, the bio_alloc() call in raid1.c seems to have the same problem. A way to tell bio_alloc() to fail rather than to drain the pool would be useful for solving these problems.
- pkt_fixup_segments() is deeply broken, how could this ever work?! You are passing i on the stack, the rest of the logic looks suspicious at best.
I don't see the problem. i is just a loop variable, why can't it live on the stack? The rest of the logic is there to make it possible to use packet writing on old scsi controllers that can only handle 16 segments. I think you suggested a solution like this when someone mentioned this problem on the list a long time ago. Is there a better way to handle those scsi controllers now?
- pkt_gather_data(), you should use bio_add_page(). this function should probably be rewritten. make-up bio's for the missing segments of a request, and piggy back the original bio to them. when they have all completed, send off the write.
Are the segments for the original bio guaranteed to be aligned to the 2KB CD sector size? The code currently doesn't assume anything about the alignment of the original bio, which is complicating the code.
- Probably drop the -20 priority from kcdrwd
The loop driver is doing the same thing. Is there a reason to behave differently than the loop driver in this case? I have uploaded a new patch with the minor changes I have made so far: http://w1.894.telia.com/~u89404340/patches/packet/2.5/packet-2.5.66-2.patch.... -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
Peter Osterlund wrote: [SNIP]
The loop driver is doing the same thing. Is there a reason to behave differently than the loop driver in this case?
I have uploaded a new patch with the minor changes I have made so far:
http://w1.894.telia.com/~u89404340/patches/packet/2.5/packet-2.5.66-2.patch....
Peter, It might be a good idea to convert the kdevname() function calls to something more appropriate now, since it has been removed in 2.5.66-bk current. See the " [PATCH] remove kdevname() before someone starts using it again" thread on the LKML for more info on this subject and discussions of possible replacement functions. Cheers, Nicholas
On Mon, 7 Apr 2003, Nicholas Wourms wrote:
Peter Osterlund wrote: [SNIP]
The loop driver is doing the same thing. Is there a reason to behave differently than the loop driver in this case?
I have uploaded a new patch with the minor changes I have made so far:
http://w1.894.telia.com/~u89404340/patches/packet/2.5/packet-2.5.66-2.patch....
Peter,
It might be a good idea to convert the kdevname() function calls to something more appropriate now, since it has been removed in 2.5.66-bk current. See the " [PATCH] remove kdevname() before someone starts using it again" thread on the LKML for more info on this subject and discussions of possible replacement functions.
OK, this patch will be in the next release: --- linux/drivers/block/pktcdvd.c.orig Mon Apr 7 18:11:59 2003 +++ linux/drivers/block/pktcdvd.c Mon Apr 7 18:11:28 2003 @@ -644,6 +644,9 @@ static void pkt_gather_data(struct pktcdvd_device *pd, struct packet_data *pkt) { struct request *rq = pkt->rq; +#if PACKET_DEBUG > 1 + char b[BDEVNAME_SIZE]; +#endif sector_t start_s, end_s; unsigned int sectors; @@ -660,7 +663,7 @@ end_s = start_s + pd->settings.size; VPRINTK("pkt_gather_data: rw=%ld\n", rq_data_dir(rq)); - VPRINTK("need %d sectors for %s\n", sectors, kdevname(pd->dev)); + VPRINTK("need %d sectors for %s\n", sectors, bdevname(pd->bdev, b)); VPRINTK("from %llu to %llu\n", (unsigned long long)start_s, (unsigned long long)end_s); pkt->sector = start_s; @@ -2285,13 +2288,14 @@ static int pkt_make_request(request_queue_t *q, struct bio *bio) { struct pktcdvd_device *pd; + char b[BDEVNAME_SIZE]; - if (minor(to_kdev_t(bio->bi_bdev->bd_dev)) >= MAX_WRITERS) { - printk("pktcdvd: %s out of range\n", kdevname(to_kdev_t(bio->bi_bdev->bd_dev))); + pd = q->queuedata; + if (!pd) { + printk("pktcdvd: %s incorrect request queue\n", bdevname(bio->bi_bdev, b)); goto end_io; } - pd = &pkt_devs[minor(to_kdev_t(bio->bi_bdev->bd_dev))]; if (kdev_none(pd->dev)) { printk("pktcdvd: request received for non-active pd\n"); goto end_io; @@ -2410,8 +2414,10 @@ char *b = buf, *msg; struct list_head *foo; int i; + char bdev_buf[BDEVNAME_SIZE]; - b += sprintf(b, "\nWriter %s (%s):\n", pd->name, kdevname(pd->dev)); + b += sprintf(b, "\nWriter %s mapped to %s:\n", pd->name, + __bdevname(kdev_t_to_nr(pd->dev), bdev_buf)); b += sprintf(b, "\nSettings:\n"); b += sprintf(b, "\tpacket size:\t\t%dkB\n", pd->settings.size / 2); @@ -2514,7 +2520,7 @@ for (minor = 0; minor < MAX_WRITERS; minor++) { if (kdev_same(pkt_devs[minor].dev, dev)) { - printk("pktcdvd: %s already setup\n", kdevname(dev)); + printk("pktcdvd: %s already setup\n", bdevname(bdev, b)); return -EBUSY; } } -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
Although I know, that linux natively supports DVD-RAM, and I don't need packet-writing patch to be applied, but I address this question on this list, because I expect that some experienced foe may answere it. Can one use any kind of DVD-RAM device on linux (2.4.20), which have native support on XP, or just dedicated drives from specific vendors? For example: beside Panasonic drives does Samsung MR-A02B, or LG GMA-4020B work? I'm sorry for being offtopic. Thx for your answer, Dwokfur
On Fri, 11 Apr 2003, Toth Attila wrote:
For example: beside Panasonic drives does Samsung MR-A02B, or LG GMA-4020B work?
Yes, the LG GMA-4020B works. I just tested the writing and reading of DVD-RAM with Linux and it works fine. Best regards, Andreas
participants (6)
-
Andreas Nowack -
Jens Axboe -
M -
Nicholas Wourms -
Peter Osterlund -
Toth Attila