2010-02-14 18:23:52

by Bret Towe

[permalink] [raw]
Subject: reiserfs issue with 2.6.32.8

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


2010-02-14 23:26:10

by Rafael J. Wysocki

[permalink] [raw]
Subject: Re: reiserfs issue with 2.6.32.8

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

2010-02-15 06:39:21

by Christian Kujau

[permalink] [raw]
Subject: Re: reiserfs issue with 2.6.32.8

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!

2010-02-15 06:46:36

by Bret Towe

[permalink] [raw]
Subject: Re: reiserfs issue with 2.6.32.8

On Sun, Feb 14, 2010 at 10:45 PM, Bret Towe <[email protected]> wrote:
> On Sun, Feb 14, 2010 at 10:39 PM, Christian Kujau <[email protected]> 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

2010-02-24 05:31:08

by Bret Towe

[permalink] [raw]
Subject: Re: reiserfs issue with 2.6.32.8

On Sun, Feb 14, 2010 at 10:39 PM, Christian Kujau <[email protected]> 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


Attachments:
strace-cp.log (6.36 kB)

2010-02-24 07:03:54

by Christian Kujau

[permalink] [raw]
Subject: Re: reiserfs issue with 2.6.32.8

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

2010-02-25 02:17:16

by Bret Towe

[permalink] [raw]
Subject: Re: reiserfs issue with 2.6.32.8

On Tue, Feb 23, 2010 at 11:03 PM, Christian Kujau <[email protected]> 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 ]---

2010-08-30 10:48:53

by Armin Steinhoff

[permalink] [raw]
Subject: UIO and Fedora 13 (kernel 33.6)

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


Attachments:
uio_jand.c (3.82 kB)

2010-08-30 11:07:46

by Armin Steinhoff

[permalink] [raw]
Subject: UIO and Fedora 13 (kernel 33.6) / kernel module corrected

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




Attachments:
uio_jand.c (3.81 kB)

2010-08-30 16:24:50

by Hans J. Koch

[permalink] [raw]
Subject: Re: UIO and Fedora 13 (kernel 33.6)

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 <[email protected]>
> * (C) 2007 Hans J. Koch <[email protected]>
> * Original code (C) 2005 Benedikt Spranger <[email protected]>
> *
> * 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

2010-08-31 06:57:17

by Armin Steinhoff

[permalink] [raw]
Subject: Re: UIO and Fedora 13 (kernel 33.6)

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


2010-08-31 10:35:35

by Hans J. Koch

[permalink] [raw]
Subject: Re: UIO and Fedora 13 (kernel 33.6)

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

2010-08-31 13:22:39

by Armin Steinhoff

[permalink] [raw]
Subject: Re: UIO and Fedora 13 (kernel 33.6)

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





Attachments:
uio_jand.c (4.21 kB)