[PATCH] allow use of mtd and jffs2 on uml
Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM dependencies down closer to the parts of mtd that actually need it. This allows enough of mtd to build to let jffs2 be used on uml. Signed-off-by: Jason Lunz <[EMAIL PROTECTED]> --- arch/um/Kconfig |4 +--- drivers/mtd/Kconfig | 12 +++- drivers/mtd/chips/Kconfig | 11 --- drivers/mtd/devices/Kconfig |7 +++ 4 files changed, 23 insertions(+), 11 deletions(-) Index: linux-2.6.23.1-uml/arch/um/Kconfig === --- linux-2.6.23.1-uml.orig/arch/um/Kconfig +++ linux-2.6.23.1-uml/arch/um/Kconfig @@ -326,9 +326,7 @@ source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" #This is just to shut up some Kconfig warnings, so no prompt. config INPUT Index: linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig === --- linux-2.6.23.1-uml.orig/drivers/mtd/devices/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig @@ -78,6 +78,7 @@ config MTD_SLRAM tristate "Uncached system RAM" + depends on HAS_IOMEM help If your CPU cannot cache all of the physical memory in your machine, you can still use it for storage or swap by using this driver to @@ -85,6 +86,7 @@ config MTD_PHRAM tristate "Physical system RAM" + depends on HAS_IOMEM help This is a re-implementation of the slram driver above. @@ -151,10 +153,13 @@ Testing MTD users (eg JFFS2) on large media and media that might be removed during a write (using the floppy drive). +if HAS_IOMEM comment "Disk-On-Chip Device Drivers" +endif config MTD_DOC2000 tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -177,6 +182,7 @@ config MTD_DOC2001 tristate "M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED)" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -198,6 +204,7 @@ config MTD_DOC2001PLUS tristate "M-Systems Disk-On-Chip Millennium Plus" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- Index: linux-2.6.23.1-uml/drivers/mtd/Kconfig === --- linux-2.6.23.1-uml.orig/drivers/mtd/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/Kconfig @@ -2,7 +2,6 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -278,15 +277,18 @@ This enables read only access to SmartMedia formatted NAND flash. You can mount it with FAT file system. -source "drivers/mtd/chips/Kconfig" -source "drivers/mtd/maps/Kconfig" +if HAS_IOMEM + source "drivers/mtd/chips/Kconfig" + source "drivers/mtd/maps/Kconfig" +endif source "drivers/mtd/devices/Kconfig" -source "drivers/mtd/nand/Kconfig" - -source "drivers/mtd/onenand/Kconfig" +if HAS_IOMEM + source "drivers/mtd/nand/Kconfig" + source "drivers/mtd/onenand/Kconfig" +endif source "drivers/mtd/ubi/Kconfig" Index: linux-2.6.23.1-uml/drivers/mtd/Makefile === --- linux-2.6.23.1-uml.orig/drivers/mtd/Makefile +++ linux-2.6.23.1-uml/drivers/mtd/Makefile @@ -26,6 +26,9 @@ nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ maps/ devices/ nand/ onenand/ +obj-y += devices/ +ifdef CONFIG_HAS_IOMEM +obj-y += chips/ maps/ nand/ onenand/ +endif obj-$(CONFIG_MTD_UBI) += ubi/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] allow use of mtd and jffs2 on uml
Allow parts of drivers/mtd to compile on uml by pushing the HAS_IOMEM dependencies down closer to the parts of mtd that actually need it. This allows enough of mtd to build to let jffs2 be used on uml. Signed-off-by: Jason Lunz [EMAIL PROTECTED] --- arch/um/Kconfig |4 +--- drivers/mtd/Kconfig | 12 +++- drivers/mtd/chips/Kconfig | 11 --- drivers/mtd/devices/Kconfig |7 +++ 4 files changed, 23 insertions(+), 11 deletions(-) Index: linux-2.6.23.1-uml/arch/um/Kconfig === --- linux-2.6.23.1-uml.orig/arch/um/Kconfig +++ linux-2.6.23.1-uml/arch/um/Kconfig @@ -326,9 +326,7 @@ source drivers/md/Kconfig -if BROKEN - source drivers/mtd/Kconfig -endif +source drivers/mtd/Kconfig #This is just to shut up some Kconfig warnings, so no prompt. config INPUT Index: linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig === --- linux-2.6.23.1-uml.orig/drivers/mtd/devices/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig @@ -78,6 +78,7 @@ config MTD_SLRAM tristate Uncached system RAM + depends on HAS_IOMEM help If your CPU cannot cache all of the physical memory in your machine, you can still use it for storage or swap by using this driver to @@ -85,6 +86,7 @@ config MTD_PHRAM tristate Physical system RAM + depends on HAS_IOMEM help This is a re-implementation of the slram driver above. @@ -151,10 +153,13 @@ Testing MTD users (eg JFFS2) on large media and media that might be removed during a write (using the floppy drive). +if HAS_IOMEM comment Disk-On-Chip Device Drivers +endif config MTD_DOC2000 tristate M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED) + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -177,6 +182,7 @@ config MTD_DOC2001 tristate M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED) + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -198,6 +204,7 @@ config MTD_DOC2001PLUS tristate M-Systems Disk-On-Chip Millennium Plus + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- Index: linux-2.6.23.1-uml/drivers/mtd/Kconfig === --- linux-2.6.23.1-uml.orig/drivers/mtd/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/Kconfig @@ -2,7 +2,6 @@ menuconfig MTD tristate Memory Technology Device (MTD) support - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -278,15 +277,18 @@ This enables read only access to SmartMedia formatted NAND flash. You can mount it with FAT file system. -source drivers/mtd/chips/Kconfig -source drivers/mtd/maps/Kconfig +if HAS_IOMEM + source drivers/mtd/chips/Kconfig + source drivers/mtd/maps/Kconfig +endif source drivers/mtd/devices/Kconfig -source drivers/mtd/nand/Kconfig - -source drivers/mtd/onenand/Kconfig +if HAS_IOMEM + source drivers/mtd/nand/Kconfig + source drivers/mtd/onenand/Kconfig +endif source drivers/mtd/ubi/Kconfig Index: linux-2.6.23.1-uml/drivers/mtd/Makefile === --- linux-2.6.23.1-uml.orig/drivers/mtd/Makefile +++ linux-2.6.23.1-uml/drivers/mtd/Makefile @@ -26,6 +26,9 @@ nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ maps/ devices/ nand/ onenand/ +obj-y += devices/ +ifdef CONFIG_HAS_IOMEM +obj-y += chips/ maps/ nand/ onenand/ +endif obj-$(CONFIG_MTD_UBI) += ubi/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] allow use of mtd and jffs2 on uml
Push the "depends on HAS_IOMEM" in mtd down closer to the parts that actually need it. This allows enough of mtd to build to let jffs2 be used on uml. Signed-off-by: Jason Lunz <[EMAIL PROTECTED]> --- On Wed, Oct 24, 2007 at 07:51:29AM +0100, David Woodhouse wrote: > Why build anything in chips/ or maps/ ? Did I mention it was crude? :) I followed your suggestion, and this version is much cleaner. > We should make sure mtdram, nandsim and onenandsim are all buildable > too. I wanted to keep this a pure kbuild change. Getting nand and onenand to build for uml would involve making them not use readb and friends, or getting uml to provide stub versions. arch/um/Kconfig |4 +--- drivers/mtd/Kconfig | 12 +++- drivers/mtd/chips/Kconfig | 11 --- drivers/mtd/devices/Kconfig |7 +++ 4 files changed, 23 insertions(+), 11 deletions(-) Index: linux-2.6.23.1-uml/arch/um/Kconfig === --- linux-2.6.23.1-uml.orig/arch/um/Kconfig +++ linux-2.6.23.1-uml/arch/um/Kconfig @@ -326,9 +326,7 @@ source "drivers/md/Kconfig" -if BROKEN - source "drivers/mtd/Kconfig" -endif +source "drivers/mtd/Kconfig" #This is just to shut up some Kconfig warnings, so no prompt. config INPUT Index: linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig === --- linux-2.6.23.1-uml.orig/drivers/mtd/devices/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig @@ -78,6 +78,7 @@ config MTD_SLRAM tristate "Uncached system RAM" + depends on HAS_IOMEM help If your CPU cannot cache all of the physical memory in your machine, you can still use it for storage or swap by using this driver to @@ -85,6 +86,7 @@ config MTD_PHRAM tristate "Physical system RAM" + depends on HAS_IOMEM help This is a re-implementation of the slram driver above. @@ -151,10 +153,13 @@ Testing MTD users (eg JFFS2) on large media and media that might be removed during a write (using the floppy drive). +if HAS_IOMEM comment "Disk-On-Chip Device Drivers" +endif config MTD_DOC2000 tristate "M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED)" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -177,6 +182,7 @@ config MTD_DOC2001 tristate "M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED)" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -198,6 +204,7 @@ config MTD_DOC2001PLUS tristate "M-Systems Disk-On-Chip Millennium Plus" + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- Index: linux-2.6.23.1-uml/drivers/mtd/Kconfig === --- linux-2.6.23.1-uml.orig/drivers/mtd/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/Kconfig @@ -2,7 +2,6 @@ menuconfig MTD tristate "Memory Technology Device (MTD) support" - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -278,15 +277,18 @@ This enables read only access to SmartMedia formatted NAND flash. You can mount it with FAT file system. -source "drivers/mtd/chips/Kconfig" -source "drivers/mtd/maps/Kconfig" +if HAS_IOMEM + source "drivers/mtd/chips/Kconfig" + source "drivers/mtd/maps/Kconfig" +endif source "drivers/mtd/devices/Kconfig" -source "drivers/mtd/nand/Kconfig" - -source "drivers/mtd/onenand/Kconfig" +if HAS_IOMEM + source "drivers/mtd/nand/Kconfig" + source "drivers/mtd/onenand/Kconfig" +endif source "drivers/mtd/ubi/Kconfig" Index: linux-2.6.23.1-uml/drivers/mtd/Makefile === --- linux-2.6.23.1-uml.orig/drivers/mtd/Makefile +++ linux-2.6.23.1-uml/drivers/mtd/Makefile @@ -26,6 +26,9 @@ nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ maps/ devices/ nand/ onenand/ +obj-y += devices/ +ifdef CONFIG_HAS_IOMEM +obj-y += chips/ maps/ nand/ onenand/ +endif obj-$(CONFIG_MTD_UBI) += ubi/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] allow use of mtd and jffs2 on uml
Push the depends on HAS_IOMEM in mtd down closer to the parts that actually need it. This allows enough of mtd to build to let jffs2 be used on uml. Signed-off-by: Jason Lunz [EMAIL PROTECTED] --- On Wed, Oct 24, 2007 at 07:51:29AM +0100, David Woodhouse wrote: Why build anything in chips/ or maps/ ? Did I mention it was crude? :) I followed your suggestion, and this version is much cleaner. We should make sure mtdram, nandsim and onenandsim are all buildable too. I wanted to keep this a pure kbuild change. Getting nand and onenand to build for uml would involve making them not use readb and friends, or getting uml to provide stub versions. arch/um/Kconfig |4 +--- drivers/mtd/Kconfig | 12 +++- drivers/mtd/chips/Kconfig | 11 --- drivers/mtd/devices/Kconfig |7 +++ 4 files changed, 23 insertions(+), 11 deletions(-) Index: linux-2.6.23.1-uml/arch/um/Kconfig === --- linux-2.6.23.1-uml.orig/arch/um/Kconfig +++ linux-2.6.23.1-uml/arch/um/Kconfig @@ -326,9 +326,7 @@ source drivers/md/Kconfig -if BROKEN - source drivers/mtd/Kconfig -endif +source drivers/mtd/Kconfig #This is just to shut up some Kconfig warnings, so no prompt. config INPUT Index: linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig === --- linux-2.6.23.1-uml.orig/drivers/mtd/devices/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/devices/Kconfig @@ -78,6 +78,7 @@ config MTD_SLRAM tristate Uncached system RAM + depends on HAS_IOMEM help If your CPU cannot cache all of the physical memory in your machine, you can still use it for storage or swap by using this driver to @@ -85,6 +86,7 @@ config MTD_PHRAM tristate Physical system RAM + depends on HAS_IOMEM help This is a re-implementation of the slram driver above. @@ -151,10 +153,13 @@ Testing MTD users (eg JFFS2) on large media and media that might be removed during a write (using the floppy drive). +if HAS_IOMEM comment Disk-On-Chip Device Drivers +endif config MTD_DOC2000 tristate M-Systems Disk-On-Chip 2000 and Millennium (DEPRECATED) + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -177,6 +182,7 @@ config MTD_DOC2001 tristate M-Systems Disk-On-Chip Millennium-only alternative driver (DEPRECATED) + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- @@ -198,6 +204,7 @@ config MTD_DOC2001PLUS tristate M-Systems Disk-On-Chip Millennium Plus + depends on HAS_IOMEM select MTD_DOCPROBE select MTD_NAND_IDS ---help--- Index: linux-2.6.23.1-uml/drivers/mtd/Kconfig === --- linux-2.6.23.1-uml.orig/drivers/mtd/Kconfig +++ linux-2.6.23.1-uml/drivers/mtd/Kconfig @@ -2,7 +2,6 @@ menuconfig MTD tristate Memory Technology Device (MTD) support - depends on HAS_IOMEM help Memory Technology Devices are flash, RAM and similar chips, often used for solid state file systems on embedded devices. This option @@ -278,15 +277,18 @@ This enables read only access to SmartMedia formatted NAND flash. You can mount it with FAT file system. -source drivers/mtd/chips/Kconfig -source drivers/mtd/maps/Kconfig +if HAS_IOMEM + source drivers/mtd/chips/Kconfig + source drivers/mtd/maps/Kconfig +endif source drivers/mtd/devices/Kconfig -source drivers/mtd/nand/Kconfig - -source drivers/mtd/onenand/Kconfig +if HAS_IOMEM + source drivers/mtd/nand/Kconfig + source drivers/mtd/onenand/Kconfig +endif source drivers/mtd/ubi/Kconfig Index: linux-2.6.23.1-uml/drivers/mtd/Makefile === --- linux-2.6.23.1-uml.orig/drivers/mtd/Makefile +++ linux-2.6.23.1-uml/drivers/mtd/Makefile @@ -26,6 +26,9 @@ nftl-objs := nftlcore.o nftlmount.o inftl-objs := inftlcore.o inftlmount.o -obj-y += chips/ maps/ devices/ nand/ onenand/ +obj-y += devices/ +ifdef CONFIG_HAS_IOMEM +obj-y += chips/ maps/ nand/ onenand/ +endif obj-$(CONFIG_MTD_UBI) += ubi/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[mtd] allow modular mtdsuper
Declare mtdsuper to be gpl-licensed so it can access get_mtd_device and
put_mtd_device when loaded as a module.
Signed-off-by: Jason Lunz <[EMAIL PROTECTED]>
---
drivers/mtd/mtdsuper.c |1 +
1 file changed, 1 insertion(+)
Index: linux-2.6.22.6-uml/drivers/mtd/mtdsuper.c
===
--- linux-2.6.22.6-uml.orig/drivers/mtd/mtdsuper.c
+++ linux-2.6.22.6-uml/drivers/mtd/mtdsuper.c
@@ -14,6 +14,8 @@
#include
#include
+MODULE_LICENSE("GPL");
+
/*
* compare superblocks to see if they're equivalent
* - they are if the underlying MTD device is the same
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[mtd] allow modular mtdsuper
Declare mtdsuper to be gpl-licensed so it can access get_mtd_device and put_mtd_device when loaded as a module. Signed-off-by: Jason Lunz [EMAIL PROTECTED] --- drivers/mtd/mtdsuper.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6.22.6-uml/drivers/mtd/mtdsuper.c === --- linux-2.6.22.6-uml.orig/drivers/mtd/mtdsuper.c +++ linux-2.6.22.6-uml/drivers/mtd/mtdsuper.c @@ -14,6 +14,8 @@ #include linux/namei.h #include linux/ctype.h +MODULE_LICENSE(GPL); + /* * compare superblocks to see if they're equivalent * - they are if the underlying MTD device is the same - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[jffs2] [rfc] fix write deadlock regression
I've bisected the deadlock when many small appends are done on jffs2 down to this commit: commit 6fe6900e1e5b6fa9e5c59aa5061f244fe3f467e2 Author: Nick Piggin <[EMAIL PROTECTED]> Date: Sun May 6 14:49:04 2007 -0700 mm: make read_cache_page synchronous Ensure pages are uptodate after returning from read_cache_page, which allows us to cut out most of the filesystem-internal PageUptodate calls. I didn't have a great look down the call chains, but this appears to fixes 7 possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in ecryptfs, 1 in jffs2, and a possible cleared data overwritten with readpage in block2mtd. All depending on whether the filler is async and/or can return with a !uptodate page. It introduced a wait to read_cache_page, as well as a read_cache_page_async function equivalent to the old read_cache_page without any callers. Switching jffs2_gc_fetch_page to read_cache_page_async for the old behavior makes the deadlocks go away, but maybe reintroduces the use-before-uptodate problem? I don't understand the mm/fs interaction well enough to say. Someone more knowledgable should see if similar deadlock issues may have been introduced for other read_cache_page callers, including the other two in jffs2. Signed-off-by: Jason Lunz <[EMAIL PROTECTED]> --- fs/jffs2/fs.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c index 1d3b7a9..8bc727b 100644 --- a/fs/jffs2/fs.c +++ b/fs/jffs2/fs.c @@ -627,7 +627,7 @@ unsigned char *jffs2_gc_fetch_page(struct jffs2_sb_info *c, struct inode *inode = OFNI_EDONI_2SFFJ(f); struct page *pg; - pg = read_cache_page(inode->i_mapping, offset >> PAGE_CACHE_SHIFT, + pg = read_cache_page_async(inode->i_mapping, offset >> PAGE_CACHE_SHIFT, (void *)jffs2_do_readpage_unlock, inode); if (IS_ERR(pg)) return (void *)pg; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[jffs2] [rfc] fix write deadlock regression
I've bisected the deadlock when many small appends are done on jffs2 down to this commit: commit 6fe6900e1e5b6fa9e5c59aa5061f244fe3f467e2 Author: Nick Piggin [EMAIL PROTECTED] Date: Sun May 6 14:49:04 2007 -0700 mm: make read_cache_page synchronous Ensure pages are uptodate after returning from read_cache_page, which allows us to cut out most of the filesystem-internal PageUptodate calls. I didn't have a great look down the call chains, but this appears to fixes 7 possible use-before uptodate in hfs, 2 in hfsplus, 1 in jfs, a few in ecryptfs, 1 in jffs2, and a possible cleared data overwritten with readpage in block2mtd. All depending on whether the filler is async and/or can return with a !uptodate page. It introduced a wait to read_cache_page, as well as a read_cache_page_async function equivalent to the old read_cache_page without any callers. Switching jffs2_gc_fetch_page to read_cache_page_async for the old behavior makes the deadlocks go away, but maybe reintroduces the use-before-uptodate problem? I don't understand the mm/fs interaction well enough to say. Someone more knowledgable should see if similar deadlock issues may have been introduced for other read_cache_page callers, including the other two in jffs2. Signed-off-by: Jason Lunz [EMAIL PROTECTED] --- fs/jffs2/fs.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/jffs2/fs.c b/fs/jffs2/fs.c index 1d3b7a9..8bc727b 100644 --- a/fs/jffs2/fs.c +++ b/fs/jffs2/fs.c @@ -627,7 +627,7 @@ unsigned char *jffs2_gc_fetch_page(struct jffs2_sb_info *c, struct inode *inode = OFNI_EDONI_2SFFJ(f); struct page *pg; - pg = read_cache_page(inode-i_mapping, offset PAGE_CACHE_SHIFT, + pg = read_cache_page_async(inode-i_mapping, offset PAGE_CACHE_SHIFT, (void *)jffs2_do_readpage_unlock, inode); if (IS_ERR(pg)) return (void *)pg; - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: jffs2 deadlock introduced in linux 2.6.22.5
On Thu, Aug 30, 2007 at 11:23:55AM -0700, Jason Lunz wrote: > commit 1d8715b388c978b0f1b1bf4812fcee0e73b023d7 was added between > 2.6.22.4 and 2.6.22.5 to cure a locking problem, but it seems to have > introduced another (worse?) one. I spoke too soon. I checked more carefully, and this problem was introduced somewhere between 2.6.21 and 2.6.22. The jffs2 fix in 2.6.22.5 isn't the culprit. Jason - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: jffs2 deadlock introduced in linux 2.6.22.5
On Thu, Aug 30, 2007 at 11:23:55AM -0700, Jason Lunz wrote: commit 1d8715b388c978b0f1b1bf4812fcee0e73b023d7 was added between 2.6.22.4 and 2.6.22.5 to cure a locking problem, but it seems to have introduced another (worse?) one. I spoke too soon. I checked more carefully, and this problem was introduced somewhere between 2.6.21 and 2.6.22. The jffs2 fix in 2.6.22.5 isn't the culprit. Jason - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
jffs2 deadlock introduced in linux 2.6.22.5
commit 1d8715b388c978b0f1b1bf4812fcee0e73b023d7 was added between 2.6.22.4 and 2.6.22.5 to cure a locking problem, but it seems to have introduced another (worse?) one. With a jffs2 filesystem (on block2mtd) on a 2.6.22.5 kernel, if I do anything that appends to a file with many small writes, I get what looks like a deadlock between the writer and the jffs2 gc thread. For example: # while true; do echo >> /some/file/on/jffs2; done will result in the bash hanging in D state, with these kernel stacks in dmesg after "echo t > /proc/sysrq-trigger": jffs2_gcd_mtd S DFD1EEA8 0 1086 2 (L-TLB) dfd1eebc 0046 0002 dfd1eea8 dfd1eea4 c0334a00 c0334a00 000a dfcb8550 2ee3df10 001a 2280 dfcb8670 c1407a00 0286 df9fa600 dfe20900 414a c1407ec4 Call Trace: [] __down_interruptible+0xb2/0x10b [] __sched_text_start+0x14b/0x8a4 [] default_wake_function+0x0/0xc [] __down_failed_interruptible+0x7/0xc [] jffs2_garbage_collect_pass+0x20/0x597 [jffs2] [] __dequeue_signal+0xd7/0x11c [] recalc_sigpending+0xb/0x1d [] dequeue_signal+0x9d/0x117 [] jffs2_garbage_collect_thread+0x11b/0x15a [jffs2] [] ret_from_fork+0x6/0x1c [] jffs2_garbage_collect_thread+0x0/0x15a [jffs2] [] jffs2_garbage_collect_thread+0x0/0x15a [jffs2] [] kernel_thread_helper+0x7/0x10 bash D CE2C85E0 0 2223 2219 (NOTLB) d834bb2c 0086 ce2c85e0 ce2c85e0 ce8004c0 0003 c0334a00 c0334a00 0009 df93ca70 2ee3bc90 001a 0002ff74 df93cb90 c1407a00 dfe20900 c1407ec4 Call Trace: [] io_schedule+0x1e/0x28 [] sync_page+0x38/0x3b [] __wait_on_bit+0x33/0x58 [] sync_page+0x0/0x3b [] wait_on_page_bit+0x63/0x69 [] wake_bit_function+0x0/0x3c [] read_cache_page+0x28/0x3f [] jffs2_gc_fetch_page+0x26/0x3b [jffs2] [] jffs2_garbage_collect_live+0x992/0xf87 [jffs2] [] block2mtd_write+0x18f/0x1a6 [block2mtd] [] default_mtd_writev+0x0/0x9e [mtdcore] [] jffs2_flash_direct_writev+0x62/0xd0 [jffs2] [] jffs2_garbage_collect_pass+0x4ff/0x597 [jffs2] [] aufs_read_unlock+0x17/0x5f [aufs] [] ibend+0x39/0x3f [aufs] [] jffs2_reserve_space+0xb5/0x15b [jffs2] [] send_sig_info+0x55/0x65 [] jffs2_write_inode_range+0x5a/0x278 [jffs2] [] jffs2_commit_write+0xec/0x1be [jffs2] [] generic_file_buffered_write+0x3f1/0x5af [] dput+0x15/0xda [] __link_path_walk+0xb2d/0xc0e [] current_fs_time+0x41/0x46 [] __generic_file_aio_write_nolock+0x479/0x4c8 [] link_path_walk+0xa9/0xb3 [] generic_file_aio_write+0x61/0xc2 [] permission+0xc8/0xdb [] do_sync_write+0x0/0x10a [] do_sync_write+0xc7/0x10a [] open_namei+0x254/0x571 [] autoremove_wake_function+0x0/0x33 [] do_sync_write+0x0/0x10a [] vfs_write+0xa8/0x130 [] sys_write+0x41/0x67 [] syscall_call+0x7/0xb Given that I never saw any jffs2 deadlocks in other 2.6.22 kernels, maybe that commit should be reverted until a better solution is found? Jason - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
jffs2 deadlock introduced in linux 2.6.22.5
commit 1d8715b388c978b0f1b1bf4812fcee0e73b023d7 was added between 2.6.22.4 and 2.6.22.5 to cure a locking problem, but it seems to have introduced another (worse?) one. With a jffs2 filesystem (on block2mtd) on a 2.6.22.5 kernel, if I do anything that appends to a file with many small writes, I get what looks like a deadlock between the writer and the jffs2 gc thread. For example: # while true; do echo /some/file/on/jffs2; done will result in the bash hanging in D state, with these kernel stacks in dmesg after echo t /proc/sysrq-trigger: jffs2_gcd_mtd S DFD1EEA8 0 1086 2 (L-TLB) dfd1eebc 0046 0002 dfd1eea8 dfd1eea4 c0334a00 c0334a00 000a dfcb8550 2ee3df10 001a 2280 dfcb8670 c1407a00 0286 df9fa600 dfe20900 414a c1407ec4 Call Trace: [c026b84c] __down_interruptible+0xb2/0x10b [c0269e4b] __sched_text_start+0x14b/0x8a4 [c0115380] default_wake_function+0x0/0xc [c026b727] __down_failed_interruptible+0x7/0xc [e09425bd] jffs2_garbage_collect_pass+0x20/0x597 [jffs2] [c0120cd0] __dequeue_signal+0xd7/0x11c [c01209ed] recalc_sigpending+0xb/0x1d [c01221e5] dequeue_signal+0x9d/0x117 [e09439e7] jffs2_garbage_collect_thread+0x11b/0x15a [jffs2] [c0103bf6] ret_from_fork+0x6/0x1c [e09438cc] jffs2_garbage_collect_thread+0x0/0x15a [jffs2] [e09438cc] jffs2_garbage_collect_thread+0x0/0x15a [jffs2] [c01048fb] kernel_thread_helper+0x7/0x10 bash D CE2C85E0 0 2223 2219 (NOTLB) d834bb2c 0086 ce2c85e0 ce2c85e0 ce8004c0 0003 c0334a00 c0334a00 0009 df93ca70 2ee3bc90 001a 0002ff74 df93cb90 c1407a00 dfe20900 c1407ec4 Call Trace: [c026aa96] io_schedule+0x1e/0x28 [c0139f4f] sync_page+0x38/0x3b [c026ad57] __wait_on_bit+0x33/0x58 [c0139f17] sync_page+0x0/0x3b [c013a09d] wait_on_page_bit+0x63/0x69 [c01286d4] wake_bit_function+0x0/0x3c [c013bce8] read_cache_page+0x28/0x3f [e0943b18] jffs2_gc_fetch_page+0x26/0x3b [jffs2] [e0941fa8] jffs2_garbage_collect_live+0x992/0xf87 [jffs2] [e08ee60e] block2mtd_write+0x18f/0x1a6 [block2mtd] [e08cd000] default_mtd_writev+0x0/0x9e [mtdcore] [e09449e2] jffs2_flash_direct_writev+0x62/0xd0 [jffs2] [e0942a9c] jffs2_garbage_collect_pass+0x4ff/0x597 [jffs2] [e0a02c82] aufs_read_unlock+0x17/0x5f [aufs] [e0a1d546] ibend+0x39/0x3f [aufs] [e093d3ba] jffs2_reserve_space+0xb5/0x15b [jffs2] [c0121e28] send_sig_info+0x55/0x65 [e093f845] jffs2_write_inode_range+0x5a/0x278 [jffs2] [e093b696] jffs2_commit_write+0xec/0x1be [jffs2] [c013b494] generic_file_buffered_write+0x3f1/0x5af [c016135e] dput+0x15/0xda [c015b4d4] __link_path_walk+0xb2d/0xc0e [c011d750] current_fs_time+0x41/0x46 [c013bacb] __generic_file_aio_write_nolock+0x479/0x4c8 [c015b65e] link_path_walk+0xa9/0xb3 [c013bb7b] generic_file_aio_write+0x61/0xc2 [c0159936] permission+0xc8/0xdb [c0153384] do_sync_write+0x0/0x10a [c015344b] do_sync_write+0xc7/0x10a [c015c56e] open_namei+0x254/0x571 [c01286a1] autoremove_wake_function+0x0/0x33 [c0153384] do_sync_write+0x0/0x10a [c0153c2a] vfs_write+0xa8/0x130 [c015419f] sys_write+0x41/0x67 [c0103d12] syscall_call+0x7/0xb Given that I never saw any jffs2 deadlocks in other 2.6.22 kernels, maybe that commit should be reverted until a better solution is found? Jason - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 on flash memory
In gmane.linux.kernel, you wrote: > I was wondering: is there any reason not to use ext2 on an USB > pendrive? Really my question is not only about USB pendrives, but any > device whose storage is flash based. Let's assume that the device has a > good quality flash memory with wear leveling and the like... Have a look at the UBI layer. It adds wear-levelling to MTD devices. Of course, to use it on a regular blockdev like this you'll have to do something like usb-storage (sd) -> block2mtd -> ubi -> jffs2. But it can be done afaik. Jason - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ext2 on flash memory
In gmane.linux.kernel, you wrote: I was wondering: is there any reason not to use ext2 on an USB pendrive? Really my question is not only about USB pendrives, but any device whose storage is flash based. Let's assume that the device has a good quality flash memory with wear leveling and the like... Have a look at the UBI layer. It adds wear-levelling to MTD devices. Of course, to use it on a regular blockdev like this you'll have to do something like usb-storage (sd) - block2mtd - ubi - jffs2. But it can be done afaik. Jason - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 OOM with 8Gb RAM
On Fri, Apr 13, 2007 at 03:46:53PM -0700, Andrew Morton wrote: > > If I want to run a system entirely from ram with a compressed filesystem > > image mounted on /, is it better to store that image in a ramdisk, or on > > a tmpfs and mount it via loopback? > > Store it all in ramfs, no loopback needed? I used to put everything in a tmpfs on /, and that certainly works. But most files in a typical image are rarely used and it's a pity to have lots of little files taking up a 4k page each. You get pretty big savings by compressing the system into a squashfs and mounting that, so the question becomes: where to put the squashfs? ramdisk or loopback mount it from tmpfs/ramfs? iirc, the problems with loopback have to do with writeout, which isn't a problem here since squashfs is readonly. Jason - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 OOM with 8Gb RAM
On Thu, Apr 12, 2007 at 12:15:53PM -0700, Andrew Morton wrote: > All of ZONE_NORMAL got used by ramdisk, and networking wants to > allocate a page from ZONE_NORMAL. An oom-killing is the correct > response, although probably not effective. > > ramdisk is a nasty thing - cannot you use ramfs or tmpfs? What do you mean by "nasty thing"? I've heard that about loopback too. If I want to run a system entirely from ram with a compressed filesystem image mounted on /, is it better to store that image in a ramdisk, or on a tmpfs and mount it via loopback? Jason - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 OOM with 8Gb RAM
On Thu, Apr 12, 2007 at 12:15:53PM -0700, Andrew Morton wrote: All of ZONE_NORMAL got used by ramdisk, and networking wants to allocate a page from ZONE_NORMAL. An oom-killing is the correct response, although probably not effective. ramdisk is a nasty thing - cannot you use ramfs or tmpfs? What do you mean by nasty thing? I've heard that about loopback too. If I want to run a system entirely from ram with a compressed filesystem image mounted on /, is it better to store that image in a ramdisk, or on a tmpfs and mount it via loopback? Jason - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 OOM with 8Gb RAM
On Fri, Apr 13, 2007 at 03:46:53PM -0700, Andrew Morton wrote: If I want to run a system entirely from ram with a compressed filesystem image mounted on /, is it better to store that image in a ramdisk, or on a tmpfs and mount it via loopback? Store it all in ramfs, no loopback needed? I used to put everything in a tmpfs on /, and that certainly works. But most files in a typical image are rarely used and it's a pity to have lots of little files taking up a 4k page each. You get pretty big savings by compressing the system into a squashfs and mounting that, so the question becomes: where to put the squashfs? ramdisk or loopback mount it from tmpfs/ramfs? iirc, the problems with loopback have to do with writeout, which isn't a problem here since squashfs is readonly. Jason - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [RFC] UML kernel & rootfs bundle with every kernel release ?
On Tue, Apr 03, 2007 at 10:28:40AM +0200, roland wrote: > what is the real advantage to package uml-kernel and rootfs into a single > file ? > > If this needs to be distributed with additional script, that's two files, > anyway. If a common means of doing this were widespread, the script would be distributed separately (probably with the uml utilities). Analagous to the way bootloaders are separate from linux on real hardware. That way, the distributor of a virtual machine would only distribute that single system image. The user would boot it using the script according to his own host environment. Jason - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [RFC] UML kernel rootfs bundle with every kernel release ?
On Tue, Apr 03, 2007 at 10:28:40AM +0200, roland wrote: what is the real advantage to package uml-kernel and rootfs into a single file ? If this needs to be distributed with additional script, that's two files, anyway. If a common means of doing this were widespread, the script would be distributed separately (probably with the uml utilities). Analagous to the way bootloaders are separate from linux on real hardware. That way, the distributor of a virtual machine would only distribute that single system image. The user would boot it using the script according to his own host environment. Jason - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [RFC] UML kernel & rootfs bundle with every kernel release ?
On Mon, Apr 02, 2007 at 05:44:34PM -0400, Jeff Dike wrote: > There are sites (http://uml.nagafix.co.uk/ being the best one I know > of) where, with two downloads, two uncompressions, and one command > line later, you have a booted UML. > > The only way I know of to improve on this, aside from inprovements in > the booted distro, is to package the filesystem as a rootfs within the > UML kernel binary. I've considered this, but haven't done anything > with it. I've done the converse: package the uml kernel within the rootfs image, and use a script that plays the part of bootloader. With ext2 at least, it's fairly easy to use the debugfs 'cat' command for this. That way, you simply distribute the fs image with a companion script that can boot any number of such images. Jason - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [RFC] UML kernel rootfs bundle with every kernel release ?
On Mon, Apr 02, 2007 at 05:44:34PM -0400, Jeff Dike wrote: There are sites (http://uml.nagafix.co.uk/ being the best one I know of) where, with two downloads, two uncompressions, and one command line later, you have a booted UML. The only way I know of to improve on this, aside from inprovements in the booted distro, is to package the filesystem as a rootfs within the UML kernel binary. I've considered this, but haven't done anything with it. I've done the converse: package the uml kernel within the rootfs image, and use a script that plays the part of bootloader. With ext2 at least, it's fairly easy to use the debugfs 'cat' command for this. That way, you simply distribute the fs image with a companion script that can boot any number of such images. Jason - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: 2.6.11-ac2
[EMAIL PROTECTED] said: > You know what would be really useful... if www.kernel.org listed the > "latest -ac" patch as something current instead of 2.6.10-ac12, which was > a great patch in its day, but hasn't been current for a while. > > In fairness, the -mm is out of date, too. Perhaps a bit of automation > would be appropriate here, so that no one would have to update this > manually. I could have sworn it showed 2.6.11-ac1 for a while. Maybe the 2.6.11.2 stuff broke it somehow? Jason - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH: 2.6.11-ac2
[EMAIL PROTECTED] said: You know what would be really useful... if www.kernel.org listed the latest -ac patch as something current instead of 2.6.10-ac12, which was a great patch in its day, but hasn't been current for a while. In fairness, the -mm is out of date, too. Perhaps a bit of automation would be appropriate here, so that no one would have to update this manually. I could have sworn it showed 2.6.11-ac1 for a while. Maybe the 2.6.11.2 stuff broke it somehow? Jason - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: from FIBMAP to FIONDEV
I'm looking for a way to do FIBMAP on linux 2.4 without being root, and I learned from the archive that it's restricted for security reasons, and that it's obsolete anyway. I found this discussion about a replacement called FIONDEV: http://uwsg.iu.edu/hypermail/linux/kernel/9906.1/0817.html However, I can't find any reference to FIONDEV in current 2.4 sources. Was anything similar ever coded? Is there a better way then FIBMAP to get the lba of a file, or are we still stuck with having to have CAP_SYS_RAWIO in order to do that? This is something that all linux dvd programs need to do in order to decrypt DVD, and it'd be nice if they didn't all have to run as root. :) Jason - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: from FIBMAP to FIONDEV
I'm looking for a way to do FIBMAP on linux 2.4 without being root, and I learned from the archive that it's restricted for security reasons, and that it's obsolete anyway. I found this discussion about a replacement called FIONDEV: http://uwsg.iu.edu/hypermail/linux/kernel/9906.1/0817.html However, I can't find any reference to FIONDEV in current 2.4 sources. Was anything similar ever coded? Is there a better way then FIBMAP to get the lba of a file, or are we still stuck with having to have CAP_SYS_RAWIO in order to do that? This is something that all linux dvd programs need to do in order to decrypt DVD, and it'd be nice if they didn't all have to run as root. :) Jason - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
DVD_AUTH ioctl fails with aic7xxx / 2.4.4
I've set up a Pioneer 305S scsi dvd-rom on an old adaptec card using the
stock aic7xxx driver included with the 2.4.4 kernel (not the old_aic7xxx
one). Everything works well, except when trying to access an encrypted
file on a DVD. This ioctl from libcss fails:
static int _get_title_key(int fd, int agid, int lba, char *key, char *key_title)
{
dvd_authinfo ai;
int i;
ai.type = DVD_LU_SEND_TITLE_KEY;
ai.lstk.agid = agid;
ai.lstk.lba = lba;
if (ioctl (fd, DVD_AUTH, )) {
perror ("GetTitleKey failed");
return -1;
}
All I see from the kernel is:
sr1: CDROM (ioctl) reports ILLEGAL REQUEST.
This happens with any DVD. Can someone tell me what the problem is? I
seem to be using the same libcss that everyone else uses with no
problem, and everything is properly configured, AFAIK.
thanks,
Jason
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
DVD_AUTH ioctl fails with aic7xxx / 2.4.4
I've set up a Pioneer 305S scsi dvd-rom on an old adaptec card using the
stock aic7xxx driver included with the 2.4.4 kernel (not the old_aic7xxx
one). Everything works well, except when trying to access an encrypted
file on a DVD. This ioctl from libcss fails:
static int _get_title_key(int fd, int agid, int lba, char *key, char *key_title)
{
dvd_authinfo ai;
int i;
ai.type = DVD_LU_SEND_TITLE_KEY;
ai.lstk.agid = agid;
ai.lstk.lba = lba;
if (ioctl (fd, DVD_AUTH, ai)) {
perror (GetTitleKey failed);
return -1;
}
All I see from the kernel is:
sr1: CDROM (ioctl) reports ILLEGAL REQUEST.
This happens with any DVD. Can someone tell me what the problem is? I
seem to be using the same libcss that everyone else uses with no
problem, and everything is properly configured, AFAIK.
thanks,
Jason
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
oops playing audio CD with scsi cdrom on test10-pre3
This is in reply to an earlier thread, "aic7xxx problem on linux-2.4.0-test10-pre1". If you play hr eject an audio cd-rom from gtcd (a GNOME cd player), you get an oops like the one mentioned. I just wanted to confirm that Jens' one-liner patch fixes the problem for me. The aic7xxx driver was involved for both me and the original poster, but it looks like the problem exists for any scsi cdrom drive, as it's in drivers/scsi/sr_ioctl.c. http://www.uwsg.indiana.edu/hypermail/linux/kernel/0010.1/0726.html Jason - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
oops playing audio CD with scsi cdrom on test10-pre3
This is in reply to an earlier thread, "aic7xxx problem on linux-2.4.0-test10-pre1". If you play hr eject an audio cd-rom from gtcd (a GNOME cd player), you get an oops like the one mentioned. I just wanted to confirm that Jens' one-liner patch fixes the problem for me. The aic7xxx driver was involved for both me and the original poster, but it looks like the problem exists for any scsi cdrom drive, as it's in drivers/scsi/sr_ioctl.c. http://www.uwsg.indiana.edu/hypermail/linux/kernel/0010.1/0726.html Jason - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
