* reiserfs issue with 2.6.32.8 @ 2010-02-14 18:23 Bret Towe 2010-02-14 23:27 ` Rafael J. Wysocki 2010-02-15 6:39 ` Christian Kujau 0 siblings, 2 replies; 21+ messages in thread From: Bret Towe @ 2010-02-14 18:23 UTC (permalink / raw) To: Linux Kernel Mailing List I recently attempted upgrading from 2.6.31.6 to 2.6.32.8 on a local server that runs several filesystems and when trying to move or copy or create a file on a reiserfs system that was sitting on lvm over raid5(not sure if that matters) I would get mv or cp to return Invalid Argument and not doing anything moving files from xfs to xfs worked fine tho for now I went back to .31.6 I'm willing to test any patches required any config info or what not let me know and I'll dig it up dmesg was clean ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: reiserfs issue with 2.6.32.8 2010-02-14 18:23 reiserfs issue with 2.6.32.8 Bret Towe @ 2010-02-14 23:27 ` Rafael J. Wysocki 2010-02-15 6:39 ` Christian Kujau 1 sibling, 0 replies; 21+ messages in thread From: Rafael J. Wysocki @ 2010-02-14 23:27 UTC (permalink / raw) To: Bret Towe; +Cc: Linux Kernel Mailing List On Sunday 14 February 2010, Bret Towe wrote: > I recently attempted upgrading from 2.6.31.6 to 2.6.32.8 on a local server > that runs several filesystems and when trying to move or copy or create a file > on a reiserfs system that was sitting on lvm over raid5(not sure if > that matters) > I would get mv or cp to return Invalid Argument and not doing anything > moving files from xfs to xfs worked fine tho > > for now I went back to .31.6 I'm willing to test any patches required > any config info or what not let me know and I'll dig it up > dmesg was clean I have created the Bugzilla entry at http://bugzilla.kernel.org/show_bug.cgi?id=15309 for your report. Thanks, Rafael ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: reiserfs issue with 2.6.32.8 2010-02-14 18:23 reiserfs issue with 2.6.32.8 Bret Towe 2010-02-14 23:27 ` Rafael J. Wysocki @ 2010-02-15 6:39 ` Christian Kujau [not found] ` <dda83e781002142245l5c95d08bu214a796be289eb22@mail.gmail.com> 2010-02-24 5:31 ` reiserfs issue with 2.6.32.8 Bret Towe 1 sibling, 2 replies; 21+ messages in thread From: Christian Kujau @ 2010-02-15 6:39 UTC (permalink / raw) To: Bret Towe; +Cc: Linux Kernel Mailing List On Sun, 14 Feb 2010 at 10:23, Bret Towe wrote: > I recently attempted upgrading from 2.6.31.6 to 2.6.32.8 on a local server > that runs several filesystems and when trying to move or copy or create a file > on a reiserfs system that was sitting on lvm over raid5(not sure if > that matters) > I would get mv or cp to return Invalid Argument and not doing anything > moving files from xfs to xfs worked fine tho I'm running 2.6.32 (and now 2.6.33) with reiserfs filesystems too and cannot reproduce what you're seeing. Can you run mv/cp through strace and provide the output? Also, if you can: maybe setting REISERFS_CHECK in your kernel config might reveal something useful. Is this reproducible with 2.6.33-rcX as well? If so, I'd recommend to try again with plain 2.6.32 and if it's still there, I see no other way to narrow it down but with a git bisection (man git-bisect). Christian. -- BOFH excuse #216: What office are you in? Oh, that one. Did you know that your building was built over the universities first nuclear research site? And wow, aren't you the lucky one, your office is right over where the core is buried! ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <dda83e781002142245l5c95d08bu214a796be289eb22@mail.gmail.com>]
* Re: reiserfs issue with 2.6.32.8 [not found] ` <dda83e781002142245l5c95d08bu214a796be289eb22@mail.gmail.com> @ 2010-02-15 6:46 ` Bret Towe 2010-08-30 10:49 ` UIO and Fedora 13 (kernel 33.6) Armin Steinhoff 2010-08-30 11:07 ` UIO and Fedora 13 (kernel 33.6) / kernel module corrected Armin Steinhoff 0 siblings, 2 replies; 21+ messages in thread From: Bret Towe @ 2010-02-15 6:46 UTC (permalink / raw) To: Christian Kujau, Linux Kernel Mailing List On Sun, Feb 14, 2010 at 10:45 PM, Bret Towe <magnade@gmail.com> wrote: > On Sun, Feb 14, 2010 at 10:39 PM, Christian Kujau <lists@nerdbynature.de> wrote: >> On Sun, 14 Feb 2010 at 10:23, Bret Towe wrote: >>> I recently attempted upgrading from 2.6.31.6 to 2.6.32.8 on a local server >>> that runs several filesystems and when trying to move or copy or create a file >>> on a reiserfs system that was sitting on lvm over raid5(not sure if >>> that matters) >>> I would get mv or cp to return Invalid Argument and not doing anything >>> moving files from xfs to xfs worked fine tho >> >> I'm running 2.6.32 (and now 2.6.33) with reiserfs filesystems too and >> cannot reproduce what you're seeing. Can you run mv/cp through strace and >> provide the output? Also, if you can: maybe setting REISERFS_CHECK in your >> kernel config might reveal something useful. >> >> Is this reproducible with 2.6.33-rcX as well? If so, I'd recommend to try >> again with plain 2.6.32 and if it's still there, I see no other way to >> narrow it down but with a git bisection (man git-bisect). > > I forgot to note that file operations on the reiserfs partitions > worked fine inside themselves > > I guess I will see about running a few other kernels then over next > few days as time permits > first I will try is the reiserfs_check option tho then revert to .32 > and go from there > and I will also forget to hit reply all in the time being ^ permalink raw reply [flat|nested] 21+ messages in thread
* UIO and Fedora 13 (kernel 33.6) 2010-02-15 6:46 ` Bret Towe @ 2010-08-30 10:49 ` Armin Steinhoff 2010-08-30 16:24 ` Hans J. Koch 2010-08-30 11:07 ` UIO and Fedora 13 (kernel 33.6) / kernel module corrected Armin Steinhoff 1 sibling, 1 reply; 21+ messages in thread From: Armin Steinhoff @ 2010-08-30 10:49 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Hans J. Koch [-- Attachment #1: Type: text/plain, Size: 437 bytes --] Hi, I'm writing an UIO driver for a plain PC/104 board (ISA bus). After insmod <my_driver_mod> I don't see an entry of uio0 in /dev and also no entries in /sys/class. There are no error messages at module load. The same happens after loading the module uio.ko and uio_pdrv.ko ... no entries at all, no error messages. In the attachment is the kernel part of the driver. What could be the problem? --Armin a-steinhoff-at-web-de [-- Attachment #2: uio_jand.c --] [-- Type: text/x-csrc, Size: 3910 bytes --] /* * UIO CAN L2 * * (C) Armin Steinhoff <as@steinhoff-automation.com> * (C) 2007 Hans J. Koch <hjk@linutronix.de> * Original code (C) 2005 Benedikt Spranger <b.spranger@linutronix.de> * * Licensed under GPL version 2 only. * */ #include <linux/device.h> #include <linux/module.h> #include <linux/uio_driver.h> #include <linux/platform_device.h> #include <linux/moduleparam.h> #include <asm/io.h> #define DEBUG 1 #define DRIVER_MAJOR 240 #define INT_QUEUE_SIZE 64 static struct uio_info *info; static unsigned char int_x[2], * int_q[2]; static void __iomem *isr[2]; static unsigned int irq = 11; module_param (irq, uint, 11); MODULE_PARM_DESC (irq, "IRQ (default 11)"); static unsigned long base_addr = 0xd00000; module_param (base_addr, ulong, 0xd00000); MODULE_PARM_DESC (base_addr, "Base address (default 0xD0000)"); static unsigned long base_len; module_param (base_len, ulong, 0x1); MODULE_PARM_DESC (base_len, "Base length (default 0x1)"); static struct platform_device * uio_jand_device; static int jand_probe(struct device *dev); static int jand_remove(struct device *dev); static struct device_driver uio_jand_driver = { .name = "uio_jand", .bus = &platform_bus_type, .probe = jand_probe, .remove = jand_remove, }; static irqreturn_t int_handler(int irq, struct uio_info *dev_info) { int irq_flag = 0; unsigned char ISRstat; ISRstat = readb(isr[0]); if(ISRstat & 0x02) { int_q[0][int_x[0]] = ISRstat; int_x[0] = (int_x[0] + 1) & 0xF ; // modulo 16 irq_flag = 1; } ISRstat = readb(isr[1]); if(ISRstat & 0x02) { int_q[1][int_x[1]] = ISRstat; int_x[1] = (int_x[1] + 1) & 0xF ; // modulo 16 irq_flag = 1; } if(irq_flag) return(IRQ_HANDLED); else return(IRQ_NONE); } static int jand_probe(struct device *dev) { info = kzalloc(sizeof(struct uio_info), GFP_KERNEL); if (!info) { return -ENOMEM; } info->mem[0].addr = base_addr; info->mem[0].size = base_len; info->mem[0].memtype = UIO_MEM_PHYS; info->mem[0].internal_addr = ioremap(info->mem[0].addr,info->mem[0].size); if (!info->mem[0].internal_addr) goto out_release; /* interrupt queue */ info->mem[1].addr = (unsigned long)kmalloc(64, GFP_KERNEL); if (!info->mem[1].addr) goto out_release1; int_q[0] = (unsigned char * )info->mem[1].addr; int_q[1] = (unsigned char * )info->mem[1].addr +32; memset(&int_q[0], 0x00, 16); int_x[0] = 0; memset(&int_q[1], 0x00, 16); int_x[1] = 0; info->mem[1].memtype = UIO_MEM_LOGICAL; info->mem[1].size = 64; isr[0] = info->mem[0].internal_addr + 3; /* interrupt reg channel 1 */ isr[1] = info->mem[0].internal_addr + 3 + 0x200; /* interrupt reg channel 2 */ info->name = "uio_jand"; info->version = "0.0.1"; info->irq = irq; info->irq_flags = 0; info->handler = int_handler; if (uio_register_device(dev, info)) goto out_release2; printk("uio_jand started!\n"); return 0; out_release2: kfree((void *)info->mem[1].addr); printk("uio_register_device failed!\n"); out_release1: free_irq( irq, "uio_jand" ); iounmap(info->mem[0].internal_addr); release_mem_region( base_addr, base_len); out_release: kfree (info); printk("Error exit ENODEV! \n"); return -ENODEV; } static int jand_remove(struct device *dev) { uio_unregister_device(info); iounmap(info->mem[0].internal_addr); release_mem_region( base_addr, base_len); free_irq( irq, "uio_jand" ); kfree((void *)info->mem[1].addr); kfree (info); return 0; } static int __init uio_jand_init(void) { uio_jand_device = platform_device_register_simple("uio_jand", -1,NULL, 0); return driver_register(&uio_jand_driver); } static void __exit uio_jand_exit(void) { platform_device_unregister(uio_jand_device); driver_unregister(&uio_jand_driver); } module_init( uio_jand_init ); module_exit( uio_jand_exit ); MODULE_LICENSE("GPL"); MODULE_AUTHOR("A. Steinhoff"); MODULE_DESCRIPTION("UIO Janus-D CAN driver"); ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: UIO and Fedora 13 (kernel 33.6) 2010-08-30 10:49 ` UIO and Fedora 13 (kernel 33.6) Armin Steinhoff @ 2010-08-30 16:24 ` Hans J. Koch 2010-08-31 6:57 ` Armin Steinhoff 0 siblings, 1 reply; 21+ messages in thread From: Hans J. Koch @ 2010-08-30 16:24 UTC (permalink / raw) To: Armin Steinhoff; +Cc: Linux Kernel Mailing List, Hans J. Koch On Mon, Aug 30, 2010 at 12:49:10PM +0200, Armin Steinhoff wrote: > Hi, > > I'm writing an UIO driver for a plain PC/104 board (ISA bus). > After insmod <my_driver_mod> I don't see an entry of uio0 in /dev > and also no entries in /sys/class. There are no error messages at > module load. Are you sure your probe() function is called? After a successfull uio_register_device() there is both a /dev/uioX and a directory /sys/class/uio/uioX/. > > The same happens after loading the module uio.ko and uio_pdrv.ko ... > no entries at all, no error messages. uio_pdrv needs platform data set up somewhere, did you do that? See docs in Documentation/DocBook/ for more details. > > In the attachment is the kernel part of the driver. What could be > the problem? Some comments below. > > --Armin > > a-steinhoff-at-web-de > /* > * UIO CAN L2 > * > * (C) Armin Steinhoff <as@steinhoff-automation.com> > * (C) 2007 Hans J. Koch <hjk@linutronix.de> > * Original code (C) 2005 Benedikt Spranger <b.spranger@linutronix.de> > * > * Licensed under GPL version 2 only. > * > */ > > #include <linux/device.h> > #include <linux/module.h> > #include <linux/uio_driver.h> > #include <linux/platform_device.h> > #include <linux/moduleparam.h> > #include <asm/io.h> #include <linux/io.h>, please. > > #define DEBUG 1 What's that used for? > #define DRIVER_MAJOR 240 not needed. > #define INT_QUEUE_SIZE 64 What's that used for? > > static struct uio_info *info; Are you sure you can have only one instance of this driver? > static unsigned char int_x[2], * int_q[2]; No space between * and variable name. There are more cases below. Please run your patch through checkpatch.pl and fix the issues. > static void __iomem *isr[2]; > > static unsigned int irq = 11; > module_param (irq, uint, 11); > MODULE_PARM_DESC (irq, "IRQ (default 11)"); > > static unsigned long base_addr = 0xd00000; > module_param (base_addr, ulong, 0xd00000); > MODULE_PARM_DESC (base_addr, "Base address (default 0xD0000)"); > > static unsigned long base_len; > module_param (base_len, ulong, 0x1); > MODULE_PARM_DESC (base_len, "Base length (default 0x1)"); > > static struct platform_device * uio_jand_device; > static int jand_probe(struct device *dev); > static int jand_remove(struct device *dev); These declarations are not neeeded... > > static struct device_driver uio_jand_driver = > { > .name = "uio_jand", > .bus = &platform_bus_type, > .probe = jand_probe, > .remove = jand_remove, > }; ...if you move this struct to the end of the file. > > static irqreturn_t int_handler(int irq, struct uio_info *dev_info) > { > int irq_flag = 0; > unsigned char ISRstat; > > ISRstat = readb(isr[0]); > if(ISRstat & 0x02) > { > int_q[0][int_x[0]] = ISRstat; > int_x[0] = (int_x[0] + 1) & 0xF ; // modulo 16 > > irq_flag = 1; > } > > ISRstat = readb(isr[1]); > if(ISRstat & 0x02) > { > int_q[1][int_x[1]] = ISRstat; > int_x[1] = (int_x[1] + 1) & 0xF ; // modulo 16 > irq_flag = 1; > } > > if(irq_flag) > return(IRQ_HANDLED); > else > return(IRQ_NONE); > } > > static int jand_probe(struct device *dev) > { > info = kzalloc(sizeof(struct uio_info), GFP_KERNEL); info should be a local variable. If you probe the driver twice you'll overwrite the previous value of info and cause a memory leak. > if (!info) > { > return -ENOMEM; > } > > info->mem[0].addr = base_addr; > info->mem[0].size = base_len; > info->mem[0].memtype = UIO_MEM_PHYS; > > info->mem[0].internal_addr = ioremap(info->mem[0].addr,info->mem[0].size); > if (!info->mem[0].internal_addr) > goto out_release; > > /* interrupt queue */ What does this comment mean? > info->mem[1].addr = (unsigned long)kmalloc(64, GFP_KERNEL); > if (!info->mem[1].addr) > goto out_release1; > > int_q[0] = (unsigned char * )info->mem[1].addr; > int_q[1] = (unsigned char * )info->mem[1].addr +32; > > memset(&int_q[0], 0x00, 16); > int_x[0] = 0; > memset(&int_q[1], 0x00, 16); > int_x[1] = 0; > > info->mem[1].memtype = UIO_MEM_LOGICAL; > info->mem[1].size = 64; > > isr[0] = info->mem[0].internal_addr + 3; /* interrupt reg channel 1 */ > isr[1] = info->mem[0].internal_addr + 3 + 0x200; /* interrupt reg channel 2 */ > > info->name = "uio_jand"; > info->version = "0.0.1"; > info->irq = irq; > info->irq_flags = 0; > info->handler = int_handler; > > if (uio_register_device(dev, info)) > goto out_release2; > printk("uio_jand started!\n"); please use dev_info instead of printk > return 0; > > > out_release2: > kfree((void *)info->mem[1].addr); > printk("uio_register_device failed!\n"); dev_err please. > out_release1: > free_irq( irq, "uio_jand" ); > iounmap(info->mem[0].internal_addr); > release_mem_region( base_addr, base_len); > out_release: > kfree (info); > printk("Error exit ENODEV! \n"); dev_err and correct indentation, please. > return -ENODEV; > } > > static int jand_remove(struct device *dev) > { > uio_unregister_device(info); > iounmap(info->mem[0].internal_addr); > release_mem_region( base_addr, base_len); > free_irq( irq, "uio_jand" ); > kfree((void *)info->mem[1].addr); > kfree (info); > return 0; > } > > > static int __init uio_jand_init(void) > { > uio_jand_device = platform_device_register_simple("uio_jand", -1,NULL, 0); > return driver_register(&uio_jand_driver); Please check the return value of both *_register calls. > } > > static void __exit uio_jand_exit(void) > { > platform_device_unregister(uio_jand_device); > driver_unregister(&uio_jand_driver); > } > > module_init( uio_jand_init ); > module_exit( uio_jand_exit ); > > MODULE_LICENSE("GPL"); > MODULE_AUTHOR("A. Steinhoff"); > MODULE_DESCRIPTION("UIO Janus-D CAN driver"); If "CAN" means "Controller Area Network" it should probably be a socketcan driver instead of UIO... Thanks, Hans ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: UIO and Fedora 13 (kernel 33.6) 2010-08-30 16:24 ` Hans J. Koch @ 2010-08-31 6:57 ` Armin Steinhoff 2010-08-31 10:35 ` Hans J. Koch 0 siblings, 1 reply; 21+ messages in thread From: Armin Steinhoff @ 2010-08-31 6:57 UTC (permalink / raw) To: Hans J. Koch; +Cc: Linux Kernel Mailing List Hans J. Koch wrote: > On Mon, Aug 30, 2010 at 12:49:10PM +0200, Armin Steinhoff wrote: >> Hi, >> >> I'm writing an UIO driver for a plain PC/104 board (ISA bus). >> After insmod<my_driver_mod> I don't see an entry of uio0 in /dev >> and also no entries in /sys/class. There are no error messages at >> module load. > Are you sure your probe() function is called? That's the case. > After a successfull > uio_register_device() there is both a /dev/uioX and a directory > /sys/class/uio/uioX/. Seems not be possible after a kernel ooops ... >> The same happens after loading the module uio.ko and uio_pdrv.ko ... >> no entries at all, no error messages. >> uio_pdrv needs platform data set up somewhere, did you do that? >> See docs in Documentation/DocBook/ for more details. uio_pdrv.ko was provided unmodified and precompiles by the Fedora distro. This example seems more or less incomplete ... it seems also the case with the uio_pdrv_genirq example However, it seems so I have to go back 2 steps and restart after reading more details of the concept of platform devices ... Thanks --Armin ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: UIO and Fedora 13 (kernel 33.6) 2010-08-31 6:57 ` Armin Steinhoff @ 2010-08-31 10:35 ` Hans J. Koch 2010-08-31 13:23 ` Armin Steinhoff 2010-09-01 7:31 ` Armin Steinhoff 0 siblings, 2 replies; 21+ messages in thread From: Hans J. Koch @ 2010-08-31 10:35 UTC (permalink / raw) To: Armin Steinhoff; +Cc: Hans J. Koch, Linux Kernel Mailing List On Tue, Aug 31, 2010 at 08:57:40AM +0200, Armin Steinhoff wrote: > Hans J. Koch wrote: > >On Mon, Aug 30, 2010 at 12:49:10PM +0200, Armin Steinhoff wrote: > >> Hi, > >> > >>I'm writing an UIO driver for a plain PC/104 board (ISA bus). > >>After insmod<my_driver_mod> I don't see an entry of uio0 in /dev > >>and also no entries in /sys/class. There are no error messages at > >>module load. > >Are you sure your probe() function is called? > That's the case. OK. > > > After a successfull > >uio_register_device() there is both a /dev/uioX and a directory > >/sys/class/uio/uioX/. > Seems not be possible after a kernel ooops ... You get an oops? What does it say? > >>The same happens after loading the module uio.ko and uio_pdrv.ko ... > >>no entries at all, no error messages. > >>uio_pdrv needs platform data set up somewhere, did you do that? > >>See docs in Documentation/DocBook/ for more details. > > uio_pdrv.ko was provided unmodified and precompiles by the Fedora > distro. That doesn't make sense. uio_pdrv/uio_pdrv_genirq both need some help from a board support file/driver to work. > This example seems more or less incomplete ... it seems also the > case with the uio_pdrv_genirq example Yes, of course. It doesn't make sense for distros to ship these modules. Both are useful only for developers who build there own kernels and add the data or irq handler needed by these drivers. > > However, it seems so I have to go back 2 steps and restart after > reading more details of the concept of platform devices ... What you did was in general the right thing. Find the reason for that oops and fix it. Thanks, Hans ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: UIO and Fedora 13 (kernel 33.6) 2010-08-31 10:35 ` Hans J. Koch @ 2010-08-31 13:23 ` Armin Steinhoff 2010-09-01 7:31 ` Armin Steinhoff 1 sibling, 0 replies; 21+ messages in thread From: Armin Steinhoff @ 2010-08-31 13:23 UTC (permalink / raw) To: Hans J. Koch; +Cc: Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 802 bytes --] Hans J. Koch wrote: > After a successfull uio_register_device() there is both a /dev/uioX > and a directory /sys/class/uio/uioX/. In the attachment is an updated version of uio_jand. The module uio_jand.ko can be inserted and removed, no messages visible by dmesg, no kernel oops, no dev/uio* and no class entries available. There are only entries of uio_jand in /sys/module, /sys/bus/platform/drivers and /sys/uio/holders ... I'm really confused =:-/ It's completely unclear how to write the initial platform_data of the platform device in the example uio_smx.c : regs = platform_get_resource(dev, IORESOURCE_MEM, 0); if (!regs) { dev_err(&dev->dev, "No memory resource specified\n"); goto out_free; Same issue in uio_platform_genirq ... Cheers --Armin [-- Attachment #2: uio_jand.c --] [-- Type: text/x-csrc, Size: 4315 bytes --] /* * UIO CAN L2 * * (C) Armin Steinhoff <as@steinhoff-automation.com> * (C) 2007 Hans J. Koch <hjk@linutronix.de> * Original code (C) 2005 Benedikt Spranger <b.spranger@linutronix.de> * * Licensed under GPL version 2 only. * */ #include <linux/device.h> #include <linux/module.h> #include <linux/ioport.h> #include <linux/device.h> #include <linux/uio_driver.h> #include <linux/platform_device.h> #include <linux/moduleparam.h> #include <linux/io.h> #define INT_QUEUE_SIZE 64 static unsigned char int_x[2], * int_q[2]; static void __iomem *isr[2]; static unsigned int irq = 11; module_param (irq, uint, 0); MODULE_PARM_DESC (irq, "IRQ (default 11)"); static unsigned long base_addr = 0xd00000; module_param (base_addr, ulong, 0); MODULE_PARM_DESC (base_addr, "Base address (default 0xD0000)"); static unsigned long base_len; module_param (base_len, ulong, 0); MODULE_PARM_DESC (base_len, "Base length (default 0x1)"); static irqreturn_t int_handler(int irq, struct uio_info *dev_info) { int irq_flag = 0; unsigned char ISRstat; ISRstat = readb(isr[0]); if(ISRstat & 0x02) { int_q[0][int_x[0]] = ISRstat; int_x[0] = (int_x[0] + 1) & 0xF ; // modulo 16 irq_flag = 1; } ISRstat = readb(isr[1]); if(ISRstat & 0x02) { int_q[1][int_x[1]] = ISRstat; int_x[1] = (int_x[1] + 1) & 0xF ; // modulo 16 irq_flag = 1; } if(irq_flag) return(IRQ_HANDLED); else return(IRQ_NONE); } static int jand_probe(struct platform_device *dev) { struct uio_info *info; dev_info(&dev->dev, "start probe %d\n", 1); info = kzalloc(sizeof(struct uio_info), GFP_KERNEL); if (!info) { return -ENOMEM; } info->mem[0].addr = base_addr; info->mem[0].size = base_len; info->mem[0].memtype = UIO_MEM_PHYS; if(request_mem_region( info->mem[0].addr, info->mem[0].size, "uio_jand")) { dev_err(&dev->dev, "request_mem_region failed %d\n", 2); goto out_release; } info->mem[0].internal_addr = ioremap(info->mem[0].addr,info->mem[0].size); if (!info->mem[0].internal_addr) { dev_err(&dev->dev, "ioremap failed %d\n", 3); goto out_release; } /* interrupt queue */ info->mem[1].addr = (unsigned long)kmalloc(64, GFP_KERNEL); if (!info->mem[1].addr) goto out_release1; int_q[0] = (unsigned char * )info->mem[1].addr; int_q[1] = (unsigned char * )info->mem[1].addr +32; memset(&int_q[0], 0x00, 16); int_x[0] = 0; memset(&int_q[1], 0x00, 16); int_x[1] = 0; info->mem[1].memtype = UIO_MEM_LOGICAL; info->mem[1].size = 64; isr[0] = info->mem[0].internal_addr + 3; /* interrupt reg channel 1 */ isr[1] = info->mem[0].internal_addr + 3 + 0x200; /* interrupt reg channel 2 */ if( request_irq(irq, int_handler, IRQF_DISABLED,"uio_jand", NULL) ) { goto out_release2; } info->name = "uio_jand"; info->version = "0.0.2"; info->irq = irq; info->irq_flags = 0; info->handler = int_handler; // different ptr types ? platform_set_drvdata(dev, info); if (uio_register_device(&dev->dev, info)) { dev_err(&dev->dev, "uio_register_device failed %d\n", 4); goto out_release2; } dev_info(&dev->dev, "uio_jand started! %d\n", 5); return 0; out_release2: kfree((void *)info->mem[1].addr); dev_err(&dev->dev, "uio_register_device failed %d \n", 6); out_release1: free_irq( irq, "uio_jand" ); iounmap(info->mem[0].internal_addr); release_mem_region( base_addr, base_len); out_release: kfree (info); dev_err(&dev->dev, "Error exit ENODEV! %d\n", 7); return -ENODEV; } static int jand_remove(struct platform_device *dev) { struct uio_info *info = platform_get_drvdata(dev); uio_unregister_device(info); iounmap(info->mem[0].internal_addr); release_mem_region( base_addr, base_len); free_irq( irq, "uio_jand" ); kfree((void *)info->mem[1].addr); kfree (info); return 0; } static struct platform_driver uio_jand_driver = { .probe = jand_probe, .remove = jand_remove, .driver = { .name = "uio_jand", .owner = THIS_MODULE, }, }; static int __init uio_jand_init(void) { return platform_driver_register(&uio_jand_driver); } static void __exit uio_jand_exit(void) { platform_driver_unregister(&uio_jand_driver); } module_init( uio_jand_init ); module_exit( uio_jand_exit ); MODULE_LICENSE("GPL"); MODULE_AUTHOR("A. Steinhoff"); MODULE_DESCRIPTION("UIO Janus-D CAN driver"); ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: UIO and Fedora 13 (kernel 33.6) 2010-08-31 10:35 ` Hans J. Koch 2010-08-31 13:23 ` Armin Steinhoff @ 2010-09-01 7:31 ` Armin Steinhoff 2010-09-01 18:56 ` Hans J. Koch 1 sibling, 1 reply; 21+ messages in thread From: Armin Steinhoff @ 2010-09-01 7:31 UTC (permalink / raw) To: Hans J. Koch; +Cc: Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 936 bytes --] Small correction ... I don't mean the "initial platform_data" but the initial resource data of the platform driver. --Armin Hans J. Koch wrote: > After a successfull uio_register_device() there is both a /dev/uioX > and a directory /sys/class/uio/uioX/. In the attachment is an updated version of uio_jand. The module uio_jand.ko can be inserted and removed, no messages visible by dmesg, no kernel oops, no dev/uio* and no class entries available. There are only entries of uio_jand in /sys/module, /sys/bus/platform/drivers and /sys/uio/holders ... I'm really confused =:-/ It's completely unclear how to write the initial platform_data of the platform device in the example uio_smx.c : regs = platform_get_resource(dev, IORESOURCE_MEM, 0); if (!regs) { dev_err(&dev->dev, "No memory resource specified\n"); goto out_free; Same issue in uio_platform_genirq ... Cheers --Armin [-- Attachment #2: uio_jand.c --] [-- Type: text/x-csrc, Size: 4316 bytes --] /* * UIO CAN L2 * * (C) Armin Steinhoff <as@steinhoff-automation.com> * (C) 2007 Hans J. Koch <hjk@linutronix.de> * Original code (C) 2005 Benedikt Spranger <b.spranger@linutronix.de> * * Licensed under GPL version 2 only. * */ #include <linux/device.h> #include <linux/module.h> #include <linux/ioport.h> #include <linux/device.h> #include <linux/uio_driver.h> #include <linux/platform_device.h> #include <linux/moduleparam.h> #include <linux/io.h> #define INT_QUEUE_SIZE 64 static unsigned char int_x[2], * int_q[2]; static void __iomem *isr[2]; static unsigned int irq = 11; module_param (irq, uint, 0); MODULE_PARM_DESC (irq, "IRQ (default 11)"); static unsigned long base_addr = 0xd00000; module_param (base_addr, ulong, 0); MODULE_PARM_DESC (base_addr, "Base address (default 0xD0000)"); static unsigned long base_len; module_param (base_len, ulong, 0); MODULE_PARM_DESC (base_len, "Base length (default 0x1)"); static irqreturn_t int_handler(int irq, struct uio_info *dev_info) { int irq_flag = 0; unsigned char ISRstat; ISRstat = readb(isr[0]); if(ISRstat & 0x02) { int_q[0][int_x[0]] = ISRstat; int_x[0] = (int_x[0] + 1) & 0xF ; // modulo 16 irq_flag = 1; } ISRstat = readb(isr[1]); if(ISRstat & 0x02) { int_q[1][int_x[1]] = ISRstat; int_x[1] = (int_x[1] + 1) & 0xF ; // modulo 16 irq_flag = 1; } if(irq_flag) return(IRQ_HANDLED); else return(IRQ_NONE); } static int jand_probe(struct platform_device *dev) { struct uio_info *info; dev_info(&dev->dev, "start probe %d\n", 1); info = kzalloc(sizeof(struct uio_info), GFP_KERNEL); if (!info) { return -ENOMEM; } info->mem[0].addr = base_addr; info->mem[0].size = base_len; info->mem[0].memtype = UIO_MEM_PHYS; if(request_mem_region( info->mem[0].addr, info->mem[0].size, "uio_jand")) { dev_err(&dev->dev, "request_mem_region failed %d\n", 2); goto out_release; } info->mem[0].internal_addr = ioremap(info->mem[0].addr,info->mem[0].size); if (!info->mem[0].internal_addr) { dev_err(&dev->dev, "ioremap failed %d\n", 3); goto out_release; } /* interrupt queue */ info->mem[1].addr = (unsigned long)kmalloc(64, GFP_KERNEL); if (!info->mem[1].addr) goto out_release1; int_q[0] = (unsigned char * )info->mem[1].addr; int_q[1] = (unsigned char * )info->mem[1].addr +32; memset(&int_q[0], 0x00, 16); int_x[0] = 0; memset(&int_q[1], 0x00, 16); int_x[1] = 0; info->mem[1].memtype = UIO_MEM_LOGICAL; info->mem[1].size = 64; isr[0] = info->mem[0].internal_addr + 3; /* interrupt reg channel 1 */ isr[1] = info->mem[0].internal_addr + 3 + 0x200; /* interrupt reg channel 2 */ if( request_irq(irq, int_handler, IRQF_DISABLED,"uio_jand", NULL) ) { goto out_release2; } info->name = "uio_jand"; info->version = "0.0.2"; info->irq = irq; info->irq_flags = 0; info->handler = int_handler; // different ptr types ? platform_set_drvdata(dev, info); if (uio_register_device(&dev->dev, info)) { dev_err(&dev->dev, "uio_register_device failed %d\n", 4); goto out_release2; } dev_info(&dev->dev, "uio_jand started! %d\n", 5); return 0; out_release2: kfree((void *)info->mem[1].addr); dev_err(&dev->dev, "uio_register_device failed %d \n", 6); out_release1: free_irq( irq, "uio_jand" ); iounmap(info->mem[0].internal_addr); release_mem_region( base_addr, base_len); out_release: kfree (info); dev_err(&dev->dev, "Error exit ENODEV! %d\n", 7); return -ENODEV; } static int jand_remove(struct platform_device *dev) { struct uio_info *info = platform_get_drvdata(dev); uio_unregister_device(info); iounmap(info->mem[0].internal_addr); release_mem_region( base_addr, base_len); free_irq( irq, "uio_jand" ); kfree((void *)info->mem[1].addr); kfree (info); return 0; } static struct platform_driver uio_jand_driver = { .probe = jand_probe, .remove = jand_remove, .driver = { .name = "uio_jand", .owner = THIS_MODULE, }, }; static int __init uio_jand_init(void) { return platform_driver_register(&uio_jand_driver); } static void __exit uio_jand_exit(void) { platform_driver_unregister(&uio_jand_driver); } module_init( uio_jand_init ); module_exit( uio_jand_exit ); MODULE_LICENSE("GPL"); MODULE_AUTHOR("A. Steinhoff"); MODULE_DESCRIPTION("UIO Janus-D CAN driver"); ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: UIO and Fedora 13 (kernel 33.6) 2010-09-01 7:31 ` Armin Steinhoff @ 2010-09-01 18:56 ` Hans J. Koch 2010-09-01 21:40 ` Armin Steinhoff 0 siblings, 1 reply; 21+ messages in thread From: Hans J. Koch @ 2010-09-01 18:56 UTC (permalink / raw) To: Armin Steinhoff; +Cc: Hans J. Koch, Linux Kernel Mailing List On Wed, Sep 01, 2010 at 09:31:39AM +0200, Armin Steinhoff wrote: > > Small correction ... I don't mean the "initial platform_data" but > the initial resource data of the platform driver. > > --Armin > > > Hans J. Koch wrote: > >After a successfull uio_register_device() there is both a /dev/uioX > >and a directory /sys/class/uio/uioX/. > > In the attachment is an updated version of uio_jand. > > The module uio_jand.ko can be inserted and removed, no messages > visible by dmesg, no kernel oops, no dev/uio* and no class entries > available. > > There are only entries of uio_jand in /sys/module, > /sys/bus/platform/drivers and /sys/uio/holders ... I'm really > confused =:-/ > > It's completely unclear how to write the initial platform_data of > the platform device in the example uio_smx.c : > > regs = platform_get_resource(dev, IORESOURCE_MEM, 0); > if (!regs) { > dev_err(&dev->dev, "No memory resource specified\n"); > goto out_free; > > Same issue in uio_platform_genirq ... You only seem to be working on x86 ... ;-) If you register a platform driver, you also need to register a platform device with the same name, otherwise your driver's probe() function will never be called. In struct platform_device you can also specify an array of resources (e.g. memory, interrupts) which can be queried by the driver in the way you quoted above. The ARM architecture (for example) uses a specific board support file for each board that sets up (among other things) these platform devices. (See arch/arm/mach-xxx/board-yyy.c for examples) Other archs like PowerPC use the OpenFirmware/DeviceTree interface to set up such board specific things. On x86, there's no real solution yet since all such boards used to be more or less "PC compatible". Platform devices exist only in low level arch code, all special devices (or those added by the user) announce themselves as PCI devices, are controllable from userspace (e.g. I2C, SPI) or have another interface that allows auto probing (e.g. USB). The first version of your driver did the right thing by using platform_device_register_simple() and driver_register(). That avoids the need for a separate file which calls platform_device_register(). So, go back to your first version, and fix the real bugs. Thanks, Hans ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: UIO and Fedora 13 (kernel 33.6) 2010-09-01 18:56 ` Hans J. Koch @ 2010-09-01 21:40 ` Armin Steinhoff 2010-09-01 22:14 ` Hans J. Koch 0 siblings, 1 reply; 21+ messages in thread From: Armin Steinhoff @ 2010-09-01 21:40 UTC (permalink / raw) To: Hans J. Koch; +Cc: Linux Kernel Mailing List Hi, many thanks for your support ... I have in the meantime a working version. Would you please implement your advices into the misleading examples of UIO ? Cheers --Armin Hans J. Koch wrote: > On Wed, Sep 01, 2010 at 09:31:39AM +0200, Armin Steinhoff wrote: >> Small correction ... I don't mean the "initial platform_data" but >> the initial resource data of the platform driver. >> >> --Armin >> >> >> Hans J. Koch wrote: >>> After a successfull uio_register_device() there is both a /dev/uioX >>> and a directory /sys/class/uio/uioX/. >> In the attachment is an updated version of uio_jand. >> >> The module uio_jand.ko can be inserted and removed, no messages >> visible by dmesg, no kernel oops, no dev/uio* and no class entries >> available. >> >> There are only entries of uio_jand in /sys/module, >> /sys/bus/platform/drivers and /sys/uio/holders ... I'm really >> confused =:-/ >> >> It's completely unclear how to write the initial platform_data of >> the platform device in the example uio_smx.c : >> >> regs = platform_get_resource(dev, IORESOURCE_MEM, 0); >> if (!regs) { >> dev_err(&dev->dev, "No memory resource specified\n"); >> goto out_free; >> >> Same issue in uio_platform_genirq ... > You only seem to be working on x86 ... ;-) > > If you register a platform driver, you also need to register a platform > device with the same name, otherwise your driver's probe() function will > never be called. In struct platform_device you can also specify an array > of resources (e.g. memory, interrupts) which can be queried by the driver > in the way you quoted above. > > The ARM architecture (for example) uses a specific board support file for > each board that sets up (among other things) these platform devices. > (See arch/arm/mach-xxx/board-yyy.c for examples) > > Other archs like PowerPC use the OpenFirmware/DeviceTree interface to set up > such board specific things. On x86, there's no real solution yet since all > such boards used to be more or less "PC compatible". Platform devices exist > only in low level arch code, all special devices (or those added by the user) > announce themselves as PCI devices, are controllable from userspace > (e.g. I2C, SPI) or have another interface that allows auto probing (e.g. USB). > > The first version of your driver did the right thing by using > platform_device_register_simple() and driver_register(). That avoids the > need for a separate file which calls platform_device_register(). > > So, go back to your first version, and fix the real bugs. > > Thanks, > Hans > > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: UIO and Fedora 13 (kernel 33.6) 2010-09-01 21:40 ` Armin Steinhoff @ 2010-09-01 22:14 ` Hans J. Koch 0 siblings, 0 replies; 21+ messages in thread From: Hans J. Koch @ 2010-09-01 22:14 UTC (permalink / raw) To: Armin Steinhoff; +Cc: Hans J. Koch, Linux Kernel Mailing List On Wed, Sep 01, 2010 at 11:40:05PM +0200, Armin Steinhoff wrote: > > Hi, > > many thanks for your support ... I have in the meantime a working version. > Would you please implement your advices into the misleading examples > of UIO ? What "misleading examples" are you talking about? Thanks, Hans ^ permalink raw reply [flat|nested] 21+ messages in thread
* UIO and Fedora 13 (kernel 33.6) / kernel module corrected 2010-02-15 6:46 ` Bret Towe 2010-08-30 10:49 ` UIO and Fedora 13 (kernel 33.6) Armin Steinhoff @ 2010-08-30 11:07 ` Armin Steinhoff 1 sibling, 0 replies; 21+ messages in thread From: Armin Steinhoff @ 2010-08-30 11:07 UTC (permalink / raw) To: Linux Kernel Mailing List; +Cc: Hans J. Koch [-- Attachment #1: Type: text/plain, Size: 418 bytes --] Hi, I'm writing an UIO driver for a plain PC/104 board (ISA bus). After insmod <my_driver_mod> I don't see an entry of uio0 in /dev and also no entries in /sys/class. There are no error messages at module load. The same happens after loading the module uio.ko and uio_pdrv.ko ... no entries at all, no error messages. In the attachment is the kernel part of the driver. What could be the problem? --Armin [-- Attachment #2: uio_jand.c --] [-- Type: text/x-csrc, Size: 3900 bytes --] /* * UIO CAN L2 * * (C) Armin Steinhoff <as@steinhoff-automation.com> * (C) 2007 Hans J. Koch <hjk@linutronix.de> * Original code (C) 2005 Benedikt Spranger <b.spranger@linutronix.de> * * Licensed under GPL version 2 only. * */ #include <linux/device.h> #include <linux/module.h> #include <linux/uio_driver.h> #include <linux/platform_device.h> #include <linux/moduleparam.h> #include <asm/io.h> #define DEBUG 1 #define DRIVER_MAJOR 240 #define INT_QUEUE_SIZE 64 static struct uio_info *info; static unsigned char int_x[2], * int_q[2]; static void __iomem *isr[2]; static unsigned int irq = 11; module_param (irq, uint, 0); MODULE_PARM_DESC (irq, "IRQ (default 11)"); static unsigned long base_addr = 0xd00000; module_param (base_addr, ulong, 0); MODULE_PARM_DESC (base_addr, "Base address (default 0xD0000)"); static unsigned long base_len; module_param (base_len, ulong, 0); MODULE_PARM_DESC (base_len, "Base length (default 0x1)"); static struct platform_device * uio_jand_device; static int jand_probe(struct device *dev); static int jand_remove(struct device *dev); static struct device_driver uio_jand_driver = { .name = "uio_jand", .bus = &platform_bus_type, .probe = jand_probe, .remove = jand_remove, }; static irqreturn_t int_handler(int irq, struct uio_info *dev_info) { int irq_flag = 0; unsigned char ISRstat; ISRstat = readb(isr[0]); if(ISRstat & 0x02) { int_q[0][int_x[0]] = ISRstat; int_x[0] = (int_x[0] + 1) & 0xF ; // modulo 16 irq_flag = 1; } ISRstat = readb(isr[1]); if(ISRstat & 0x02) { int_q[1][int_x[1]] = ISRstat; int_x[1] = (int_x[1] + 1) & 0xF ; // modulo 16 irq_flag = 1; } if(irq_flag) return(IRQ_HANDLED); else return(IRQ_NONE); } static int jand_probe(struct device *dev) { info = kzalloc(sizeof(struct uio_info), GFP_KERNEL); if (!info) { return -ENOMEM; } info->mem[0].addr = base_addr; info->mem[0].size = base_len; info->mem[0].memtype = UIO_MEM_PHYS; info->mem[0].internal_addr = ioremap(info->mem[0].addr,info->mem[0].size); if (!info->mem[0].internal_addr) goto out_release; /* interrupt queue */ info->mem[1].addr = (unsigned long)kmalloc(64, GFP_KERNEL); if (!info->mem[1].addr) goto out_release1; int_q[0] = (unsigned char * )info->mem[1].addr; int_q[1] = (unsigned char * )info->mem[1].addr +32; memset(&int_q[0], 0x00, 16); int_x[0] = 0; memset(&int_q[1], 0x00, 16); int_x[1] = 0; info->mem[1].memtype = UIO_MEM_LOGICAL; info->mem[1].size = 64; isr[0] = info->mem[0].internal_addr + 3; /* interrupt reg channel 1 */ isr[1] = info->mem[0].internal_addr + 3 + 0x200; /* interrupt reg channel 2 */ info->name = "uio_jand"; info->version = "0.0.1"; info->irq = irq; info->irq_flags = 0; info->handler = int_handler; if (uio_register_device(dev, info)) goto out_release2; printk("uio_jand started!\n"); return 0; out_release2: kfree((void *)info->mem[1].addr); printk("uio_register_device failed!\n"); out_release1: free_irq( irq, "uio_jand" ); iounmap(info->mem[0].internal_addr); release_mem_region( base_addr, base_len); out_release: kfree (info); printk("Error exit ENODEV! \n"); return -ENODEV; } static int jand_remove(struct device *dev) { uio_unregister_device(info); iounmap(info->mem[0].internal_addr); release_mem_region( base_addr, base_len); free_irq( irq, "uio_jand" ); kfree((void *)info->mem[1].addr); kfree (info); return 0; } static int __init uio_jand_init(void) { uio_jand_device = platform_device_register_simple("uio_jand", -1,NULL, 0); return driver_register(&uio_jand_driver); } static void __exit uio_jand_exit(void) { platform_device_unregister(uio_jand_device); driver_unregister(&uio_jand_driver); } module_init( uio_jand_init ); module_exit( uio_jand_exit ); MODULE_LICENSE("GPL"); MODULE_AUTHOR("A. Steinhoff"); MODULE_DESCRIPTION("UIO Janus-D CAN driver"); ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: reiserfs issue with 2.6.32.8 2010-02-15 6:39 ` Christian Kujau [not found] ` <dda83e781002142245l5c95d08bu214a796be289eb22@mail.gmail.com> @ 2010-02-24 5:31 ` Bret Towe 2010-02-24 7:03 ` Christian Kujau 1 sibling, 1 reply; 21+ messages in thread From: Bret Towe @ 2010-02-24 5:31 UTC (permalink / raw) To: Christian Kujau; +Cc: Linux Kernel Mailing List [-- Attachment #1: Type: text/plain, Size: 1617 bytes --] On Sun, Feb 14, 2010 at 10:39 PM, Christian Kujau <lists@nerdbynature.de> wrote: > On Sun, 14 Feb 2010 at 10:23, Bret Towe wrote: >> I recently attempted upgrading from 2.6.31.6 to 2.6.32.8 on a local server >> that runs several filesystems and when trying to move or copy or create a file >> on a reiserfs system that was sitting on lvm over raid5(not sure if >> that matters) >> I would get mv or cp to return Invalid Argument and not doing anything >> moving files from xfs to xfs worked fine tho > > I'm running 2.6.32 (and now 2.6.33) with reiserfs filesystems too and > cannot reproduce what you're seeing. Can you run mv/cp through strace and > provide the output? Also, if you can: maybe setting REISERFS_CHECK in your > kernel config might reveal something useful. > > Is this reproducible with 2.6.33-rcX as well? If so, I'd recommend to try > again with plain 2.6.32 and if it's still there, I see no other way to > narrow it down but with a git bisection (man git-bisect). > ok attached is strace log of cp on 2.6.32.9 the reiserfs_check doesn't spew anything that I could see and 2.6.33-rc also didn't help now I've had a hd drop out of raid (running checks on it atm) and seen some other issues that make me wonder about the quality of the hardware the 2.6.32.9 was compiled on a different computer to eliminate that possibility but didn't help alas I intend to replace this computers motherboard if I still see the issue I will start doing bisect at that point but the issue might go away as some configuration I have will change (dropping the raid5) time frame will be probably a few weeks at best [-- Attachment #2: strace-cp.log --] [-- Type: text/x-log, Size: 6516 bytes --] execve("/bin/cp", ["cp", "downloads/[DB]_Bleach_258_[27104"..., "/mdhd/media/Episodes/unwatched/"], [/* 24 vars */]) = 0 brk(0) = 0xf80000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1d75bbc000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1d75bba000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=44611, ...}) = 0 mmap(NULL, 44611, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f1d75baf000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libselinux.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340X\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=117592, ...}) = 0 mmap(NULL, 2217480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f1d75781000 mprotect(0x7f1d7579d000, 2093056, PROT_NONE) = 0 mmap(0x7f1d7599c000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b000) = 0x7f1d7599c000 mmap(0x7f1d7599e000, 1544, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f1d7599e000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libacl.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\35\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=31128, ...}) = 0 mmap(NULL, 2126288, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f1d75579000 mprotect(0x7f1d75580000, 2093056, PROT_NONE) = 0 mmap(0x7f1d7577f000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x7f1d7577f000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libattr.so.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0p\21\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=18608, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1d75bae000 mmap(NULL, 2113736, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f1d75374000 mprotect(0x7f1d75378000, 2093056, PROT_NONE) = 0 mmap(0x7f1d75577000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3000) = 0x7f1d75577000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\353\1\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=1490312, ...}) = 0 mmap(NULL, 3598344, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f1d75005000 mprotect(0x7f1d7516b000, 2093056, PROT_NONE) = 0 mmap(0x7f1d7536a000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x165000) = 0x7f1d7536a000 mmap(0x7f1d7536f000, 18440, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f1d7536f000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libdl.so.2", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\r\0\0\0\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0644, st_size=14696, ...}) = 0 mmap(NULL, 2109696, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f1d74e01000 mprotect(0x7f1d74e03000, 2097152, PROT_NONE) = 0 mmap(0x7f1d75003000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f1d75003000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1d75bad000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1d75bac000 arch_prctl(ARCH_SET_FS, 0x7f1d75bac790) = 0 mprotect(0x7f1d75003000, 4096, PROT_READ) = 0 mprotect(0x7f1d7536a000, 16384, PROT_READ) = 0 mprotect(0x7f1d75577000, 4096, PROT_READ) = 0 mprotect(0x7f1d7599c000, 4096, PROT_READ) = 0 mprotect(0x618000, 4096, PROT_READ) = 0 mprotect(0x7f1d75bbd000, 4096, PROT_READ) = 0 munmap(0x7f1d75baf000, 44611) = 0 statfs("/selinux", {f_type=0x58465342, f_bsize=4096, f_blocks=3659264, f_bfree=2063344, f_bavail=2063344, f_files=14647296, f_ffree=14523978, f_fsid={64512, 0}, f_namelen=255, f_frsize=4096}) = 0 brk(0) = 0xf80000 brk(0xfa1000) = 0xfa1000 open("/proc/filesystems", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1d75bb9000 read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tb"..., 1024) = 341 read(3, "", 1024) = 0 close(3) = 0 munmap(0x7f1d75bb9000, 4096) = 0 open("/proc/filesystems", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f1d75bb9000 read(3, "nodev\tsysfs\nnodev\trootfs\nnodev\tb"..., 1024) = 341 read(3, "", 1024) = 0 close(3) = 0 munmap(0x7f1d75bb9000, 4096) = 0 geteuid() = 1000 stat("/mdhd/media/Episodes/unwatched/", {st_mode=S_IFDIR|0755, st_size=1976, ...}) = 0 stat("downloads/[DB]_Bleach_258_[27104F7A].avi", {st_mode=S_IFREG|0644, st_size=178308328, ...}) = 0 stat("/mdhd/media/Episodes/unwatched/[DB]_Bleach_258_[27104F7A].avi", 0x7fffac46baf0) = -1 ENOENT (No such file or directory) open("downloads/[DB]_Bleach_258_[27104F7A].avi", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=178308328, ...}) = 0 open("/mdhd/media/Episodes/unwatched/[DB]_Bleach_258_[27104F7A].avi", O_WRONLY|O_CREAT|O_EXCL, 0644) = -1 EINVAL (Invalid argument) write(2, "cp: ", 4) = 4 write(2, "cannot create regular file `/mdh"..., 90) = 90 write(2, ": Invalid argument", 18) = 18 write(2, "\n", 1) = 1 close(3) = 0 close(0) = 0 close(1) = 0 close(2) = 0 exit_group(1) = ? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: reiserfs issue with 2.6.32.8 2010-02-24 5:31 ` reiserfs issue with 2.6.32.8 Bret Towe @ 2010-02-24 7:03 ` Christian Kujau 2010-02-25 2:17 ` Bret Towe 2010-03-04 3:00 ` Bret Towe 0 siblings, 2 replies; 21+ messages in thread From: Christian Kujau @ 2010-02-24 7:03 UTC (permalink / raw) To: Bret Towe; +Cc: Linux Kernel Mailing List, reiserfs-devel On Tue, 23 Feb 2010 at 21:31, Bret Towe wrote: > ok attached is strace log of cp on 2.6.32.9 I've run cp through strace as well (copying something from an XFS partition to a reiserfs partition, I guess that's what you did too), and noticed a small difference at the end: < open("/home/foo/1", O_RDONLY) = 3 < fstat(3, {st_mode=S_IFREG|0640, st_size=755, ...}) = 0 < open("2", O_WRONLY|O_CREAT|O_EXCL, 0640) = 4 While your cp(1) did: > open("downloads/[DB]_Bleach_258_[27104F7A].avi", O_RDONLY) = 3 > fstat(3, {st_mode=S_IFREG|0644, st_size=178308328, ...}) = 0 > open("/mdhd/media/Episodes/unwatched/[DB]_Bleach_258_[27104F7A].avi", O_WRONLY|O_CREAT|O_EXCL, 0644) = -1 EINVAL (Invalid argument) And open(2) will return -EINVAL when: - The implementation does not support synchronised I/O for this file. - The value of the oflag argument is not valid. As we're not passing O_SYNC, it's the latter, if I read this correctly. Which still doesn't explain *why* (the filesystem?) returns "invalid flag". > now I've had a hd drop out of raid (running checks on it atm) Hm, maybe it's all hardware related after all, let's see what these checks turn up. Strange though, that nothing gets reported in dmesg... Christian. -- BOFH excuse #159: Stubborn processes ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: reiserfs issue with 2.6.32.8 2010-02-24 7:03 ` Christian Kujau @ 2010-02-25 2:17 ` Bret Towe 2010-03-04 3:00 ` Bret Towe 1 sibling, 0 replies; 21+ messages in thread From: Bret Towe @ 2010-02-25 2:17 UTC (permalink / raw) To: Christian Kujau; +Cc: Linux Kernel Mailing List, reiserfs-devel On Tue, Feb 23, 2010 at 11:03 PM, Christian Kujau <lists@nerdbynature.de> wrote: > On Tue, 23 Feb 2010 at 21:31, Bret Towe wrote: >> ok attached is strace log of cp on 2.6.32.9 > > I've run cp through strace as well (copying something from an XFS > partition to a reiserfs partition, I guess that's what you did too), and > noticed a small difference at the end: > > < open("/home/foo/1", O_RDONLY) = 3 > < fstat(3, {st_mode=S_IFREG|0640, st_size=755, ...}) = 0 > < open("2", O_WRONLY|O_CREAT|O_EXCL, 0640) = 4 > > While your cp(1) did: > >> open("downloads/[DB]_Bleach_258_[27104F7A].avi", O_RDONLY) = 3 >> fstat(3, {st_mode=S_IFREG|0644, st_size=178308328, ...}) = 0 >> open("/mdhd/media/Episodes/unwatched/[DB]_Bleach_258_[27104F7A].avi", O_WRONLY|O_CREAT|O_EXCL, 0644) = -1 EINVAL (Invalid argument) > > > And open(2) will return -EINVAL when: > - The implementation does not support synchronised I/O for this file. > - The value of the oflag argument is not valid. > > As we're not passing O_SYNC, it's the latter, if I read this correctly. Which > still doesn't explain *why* (the filesystem?) returns "invalid flag". > >> now I've had a hd drop out of raid (running checks on it atm) > > Hm, maybe it's all hardware related after all, let's see what these checks > turn up. Strange though, that nothing gets reported in dmesg... > perhaps related perhaps just more hardware issues I desided to try making another reiserfs logical volume in the same volume group as the xfs source file just out of curiosity and when I tried to mount the filesystem i just formated mount said Killed and in dmesg I had the following appear [75435.452373] REISERFS (device dm-12): found reiserfs format "3.6" with standard journal [75435.452401] REISERFS (device dm-12): using ordered data mode [75435.462446] REISERFS (device dm-12): journal params: device dm-12, size 8192, journal first block 18, max trans len 1024, max batch 900, max commit age 30, max trans age 30 [75435.464979] REISERFS (device dm-12): checking transaction log (dm-12) [75436.068056] REISERFS (device dm-12): Using r5 hash to sort names [75436.068139] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010 [75436.068182] IP: [<ffffffff81155d4e>] reiserfs_security_init+0xfe/0x110 [75436.068219] PGD 8fa7067 PUD 396aa067 PMD 0 [75436.068243] Oops: 0000 [#1] SMP [75436.068264] last sysfs file: /sys/devices/virtual/block/dm-12/range [75436.068287] CPU 1 [75436.068304] Modules linked in: ipmi_msghandler i2c_nforce2 k8temp psmouse serio_raw raid10 raid0 multipath linear r8169 mii pata_amd forcedeth [75436.068372] Pid: 11675, comm: mount Not tainted 2.6.32.9-server #49 [75436.068394] RIP: 0010:[<ffffffff81155d4e>] [<ffffffff81155d4e>] reiserfs_security_init+0xfe/0x110 [75436.068435] RSP: 0018:ffff880004639b58 EFLAGS: 00010246 [75436.068455] RAX: 0000000000000000 RBX: ffff880004639be8 RCX: ffff88002497d700 [75436.068479] RDX: 0000000000000002 RSI: 0000000000000002 RDI: ffff880025051400 [75436.068502] RBP: ffff880004639b78 R08: ffff880001b0dd20 R09: ffff880000b99280 [75436.068525] R10: 0000000000000000 R11: 000001f400000001 R12: ffff8800069bc600 [75436.068548] R13: 0000000000000000 R14: ffff880008e34cc0 R15: 00000000fffffff4 [75436.068572] FS: 00007f99bd9667d0(0000) GS:ffff880001b00000(0000) knlGS:0000000000000000 [75436.068606] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [75436.068627] CR2: 0000000000000010 CR3: 000000003990c000 CR4: 00000000000006e0 [75436.068651] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [75436.068675] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [75436.068699] Process mount (pid: 11675, threadinfo ffff880004638000, task ffff88001ae64230) [75436.068732] Stack: [75436.068747] 0000000e04639be8 ffff8800244f34c0 ffff8800069bc600 00000000000041c0 [75436.068774] <0> ffff880004639c38 ffffffff811340c4 fffffffffffffff4 0000000000000000 [75436.068812] <0> ffff880004639bc8 ffff880000000000 ffff880004639c38 ffff8800244f34c0 [75436.068862] Call Trace: [75436.068886] [<ffffffff811340c4>] reiserfs_mkdir+0xb4/0x2e0 [75436.068914] [<ffffffff810d84ea>] ? __lookup_hash+0xfa/0x150 [75436.068936] [<ffffffff8115417e>] T.421+0x1e/0x30 [75436.068958] [<ffffffff81154e32>] reiserfs_xattr_init+0x162/0x260 [75436.068983] [<ffffffff811419f6>] reiserfs_fill_super+0x8f6/0xb10 [75436.069007] [<ffffffff810cf270>] ? test_bdev_super+0x0/0x20 [75436.069032] [<ffffffff810d06f4>] get_sb_bdev+0x174/0x1b0 [75436.069054] [<ffffffff81141100>] ? reiserfs_fill_super+0x0/0xb10 [75436.069078] [<ffffffff8113f0b3>] get_super_block+0x13/0x20 [75436.069100] [<ffffffff810d0196>] vfs_kern_mount+0x76/0x1a0 [75436.069123] [<ffffffff810d032d>] do_kern_mount+0x4d/0x130 [75436.069147] [<ffffffff810e8131>] do_mount+0x2d1/0x850 [75436.069172] [<ffffffff810a978f>] ? strndup_user+0x5f/0xb0 [75436.069194] [<ffffffff810e873b>] sys_mount+0x8b/0xe0 [75436.069221] [<ffffffff8100beab>] system_call_fastpath+0x16/0x1b [75436.069242] Code: 0f 44 c5 48 c7 43 10 00 00 00 00 e9 50 ff ff ff 0f 1f 44 00 00 49 8b bc 24 00 01 00 00 48 8b 8f 80 02 00 00 48 8b 81 d0 00 00 00 <48> 83 78 10 01 19 c0 83 e0 36 83 c0 6c e9 76 ff ff ff 48 8b 87 [75436.069405] RIP [<ffffffff81155d4e>] reiserfs_security_init+0xfe/0x110 [75436.069431] RSP <ffff880004639b58> [75436.069448] CR2: 0000000000000010 [75436.069860] ---[ end trace d53dc3730bc1fcd2 ]--- ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: reiserfs issue with 2.6.32.8 2010-02-24 7:03 ` Christian Kujau 2010-02-25 2:17 ` Bret Towe @ 2010-03-04 3:00 ` Bret Towe 2010-03-04 21:37 ` Christian Kujau 1 sibling, 1 reply; 21+ messages in thread From: Bret Towe @ 2010-03-04 3:00 UTC (permalink / raw) To: Christian Kujau; +Cc: Linux Kernel Mailing List, reiserfs-devel On Tue, Feb 23, 2010 at 11:03 PM, Christian Kujau <lists@nerdbynature.de> wrote: > On Tue, 23 Feb 2010 at 21:31, Bret Towe wrote: >> ok attached is strace log of cp on 2.6.32.9 > > I've run cp through strace as well (copying something from an XFS > partition to a reiserfs partition, I guess that's what you did too), and > noticed a small difference at the end: > > < open("/home/foo/1", O_RDONLY) = 3 > < fstat(3, {st_mode=S_IFREG|0640, st_size=755, ...}) = 0 > < open("2", O_WRONLY|O_CREAT|O_EXCL, 0640) = 4 > > While your cp(1) did: > >> open("downloads/[DB]_Bleach_258_[27104F7A].avi", O_RDONLY) = 3 >> fstat(3, {st_mode=S_IFREG|0644, st_size=178308328, ...}) = 0 >> open("/mdhd/media/Episodes/unwatched/[DB]_Bleach_258_[27104F7A].avi", O_WRONLY|O_CREAT|O_EXCL, 0644) = -1 EINVAL (Invalid argument) > > > And open(2) will return -EINVAL when: > - The implementation does not support synchronised I/O for this file. > - The value of the oflag argument is not valid. > > As we're not passing O_SYNC, it's the latter, if I read this correctly. Which > still doesn't explain *why* (the filesystem?) returns "invalid flag". > >> now I've had a hd drop out of raid (running checks on it atm) > > Hm, maybe it's all hardware related after all, let's see what these checks > turn up. Strange though, that nothing gets reported in dmesg... well the hardware update ended up changing more than I thought it would now on 32bit from 64bit so config is completely new also for the kernel end result tho is I'm on a 2.6.33 kernel and no issues ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: reiserfs issue with 2.6.32.8 2010-03-04 3:00 ` Bret Towe @ 2010-03-04 21:37 ` Christian Kujau 2010-03-04 22:53 ` Bret Towe 0 siblings, 1 reply; 21+ messages in thread From: Christian Kujau @ 2010-03-04 21:37 UTC (permalink / raw) To: Bret Towe; +Cc: Linux Kernel Mailing List, reiserfs-devel, rjw On Wed, 3 Mar 2010 at 19:00, Bret Towe wrote: > well the hardware update ended up changing more than I thought it would > now on 32bit from 64bit so config is completely new also for the kernel > end result tho is I'm on a 2.6.33 kernel and no issues If there are still no issues after some time, maybe we can then close the bugzilla ticket? http://bugzilla.kernel.org/show_bug.cgi?id=15309 Thanks, Christian. -- BOFH excuse #351: PEBKAC (Problem Exists Between Keyboard And Chair) ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: reiserfs issue with 2.6.32.8 2010-03-04 21:37 ` Christian Kujau @ 2010-03-04 22:53 ` Bret Towe 2010-03-05 7:36 ` Christian Kujau 0 siblings, 1 reply; 21+ messages in thread From: Bret Towe @ 2010-03-04 22:53 UTC (permalink / raw) To: Christian Kujau; +Cc: Linux Kernel Mailing List, reiserfs-devel, rjw On Thu, Mar 4, 2010 at 1:37 PM, Christian Kujau <lists@nerdbynature.de> wrote: > On Wed, 3 Mar 2010 at 19:00, Bret Towe wrote: >> well the hardware update ended up changing more than I thought it would >> now on 32bit from 64bit so config is completely new also for the kernel >> end result tho is I'm on a 2.6.33 kernel and no issues > > If there are still no issues after some time, maybe we can then close the > bugzilla ticket? > > http://bugzilla.kernel.org/show_bug.cgi?id=15309 how long would you consider 'some time'? ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: reiserfs issue with 2.6.32.8 2010-03-04 22:53 ` Bret Towe @ 2010-03-05 7:36 ` Christian Kujau 0 siblings, 0 replies; 21+ messages in thread From: Christian Kujau @ 2010-03-05 7:36 UTC (permalink / raw) To: Bret Towe; +Cc: Linux Kernel Mailing List, reiserfs-devel, rjw On Thu, 4 Mar 2010 at 14:53, Bret Towe wrote: > > If there are still no issues after some time, maybe we can then close the > > bugzilla ticket? > > > > http://bugzilla.kernel.org/show_bug.cgi?id=15309 > > how long would you consider 'some time'? Well, until you're confident that these "reiserfs issues" are gone. After all, it's your bugreport and nobody was able to reproduce it yet - so it's up to you to decide when to close it :-) If the problems reappear with newer kernels, we can always open a new report. Christian. -- BOFH excuse #393: Interference from the Van Allen Belt. ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2010-09-01 22:14 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-14 18:23 reiserfs issue with 2.6.32.8 Bret Towe
2010-02-14 23:27 ` Rafael J. Wysocki
2010-02-15 6:39 ` Christian Kujau
[not found] ` <dda83e781002142245l5c95d08bu214a796be289eb22@mail.gmail.com>
2010-02-15 6:46 ` Bret Towe
2010-08-30 10:49 ` UIO and Fedora 13 (kernel 33.6) Armin Steinhoff
2010-08-30 16:24 ` Hans J. Koch
2010-08-31 6:57 ` Armin Steinhoff
2010-08-31 10:35 ` Hans J. Koch
2010-08-31 13:23 ` Armin Steinhoff
2010-09-01 7:31 ` Armin Steinhoff
2010-09-01 18:56 ` Hans J. Koch
2010-09-01 21:40 ` Armin Steinhoff
2010-09-01 22:14 ` Hans J. Koch
2010-08-30 11:07 ` UIO and Fedora 13 (kernel 33.6) / kernel module corrected Armin Steinhoff
2010-02-24 5:31 ` reiserfs issue with 2.6.32.8 Bret Towe
2010-02-24 7:03 ` Christian Kujau
2010-02-25 2:17 ` Bret Towe
2010-03-04 3:00 ` Bret Towe
2010-03-04 21:37 ` Christian Kujau
2010-03-04 22:53 ` Bret Towe
2010-03-05 7:36 ` Christian Kujau
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).