All of lore.kernel.org
 help / color / mirror / Atom feed
* 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ messages in thread

* 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ messages in thread

* Re: reiserfs issue with 2.6.32.8
@ 2010-02-25  2:17         ` Bret Towe
  0 siblings, 0 replies; 23+ 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 ]---
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: reiserfs issue with 2.6.32.8
  2010-02-24  7:03     ` Christian Kujau
@ 2010-03-04  3:00         ` Bret Towe
  2010-03-04  3:00         ` Bret Towe
  1 sibling, 0 replies; 23+ 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] 23+ messages in thread

* Re: reiserfs issue with 2.6.32.8
@ 2010-03-04  3:00         ` Bret Towe
  0 siblings, 0 replies; 23+ 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
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 23+ 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
  -1 siblings, 1 reply; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ 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; 23+ 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] 23+ messages in thread

end of thread, other threads:[~2010-09-01 22:14 UTC | newest]

Thread overview: 23+ 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-02-25  2:17         ` Bret Towe
2010-03-04  3:00       ` 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.