FUSE version for Linux 2.6.22-19

[Jorgen Lundman]

Hello list,

I can not change the kernel, just compile modules for it.


When I compile the FUSE version that comes with a pure 2.6.22-19 kernel version,
I get the following panic:

NTFS volume version 3.1.
CPU 0 Unable to handle kernel paging request at virtual address 000000c0, epc ==
84088e7c, ra == c023038c
Oops[#1]:

epc   : 84088e7c kmem_cache_zalloc+0x24/0xa0     Tainted: PF
ra    : c023038c fuse_fill_super+0x2e0/0x650 [fuse]
Status: 11001c02    KERNEL EXL

Process ntfs-3g (pid: 17079, threadinfo=8a3d4000, task=898d2278)

Call Trace:
[<84088e7c>] kmem_cache_zalloc+0x24/0xa0
[<c023038c>] fuse_fill_super+0x2e0/0x650 [fuse]
[<8408fe30>] get_sb_bdev+0x26c/0x2cc
[<c022f9d4>] fuse_get_sb_blk+0x28/0x34 [fuse]
[<8408e1c8>] vfs_kern_mount+0x5c/0x120
[<8408e2e8>] do_kern_mount+0x4c/0x134
[<840ae918>] do_mount+0x19c/0x76c
[<840aefb0>] sys_mount+0xc8/0x1c8
[<84012be4>] stack_done+0x20/0x3c


If I fetch the latest fuse package, I find the kernel sources are no longer
included. Oh well.

If I get the kernel sources from the latest/stable kernel 2.6.31.5 it does not
compile:

In file included from fs/fuse/dev.c:9:
fs/fuse/fuse_i.h:264: error: field 'cuse_init_in' has incomplete type
fs/fuse/fuse_i.h:265: error: field 'cuse_init_out' has incomplete type


Is there a recommended FUSE version that may fix the panic problem, but might
also still compile on 2.6.22-19 ?

Please advice,

Lund

--
Jorgen Lundman       | <lundman@...>
Unix Administrator   | [phone] ext 1017 (work)
Shibuya-ku, Tokyo    | [phone]          (cell)
Japan                | [phone]          (home)

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Jorgen Lundman]

Actually, tried a few versions and they all die in the same way. So, back to
original 2.6.22-19 fuse kernel sources, and peppered prints all over the place
to figure out where it dies;


     printk("fill_super: 3\n");

     fc = new_conn();
     if (!fc)
         return -ENOMEM;

     printk("fill_super: 3.1\n");



static struct fuse_conn *new_conn(void)
{
     struct fuse_conn *fc;

     printk("new_conn: enter\n");
     fc = kzalloc(sizeof(*fc), GFP_KERNEL);
     printk("new_conn: 1\n");



fill_super: 3
new_conn: enter
CPU 0 Unable to handle kernel paging request at virtual address 000000c0, epc ==
84088e7c, ra == c02683cc

Which is strange. That is a fairly vanilla call to kzalloc, so I do not
understand why it would crash. Plenty other modules call this function, so it is
somewhat confusing it would mind so much.



Jorgen Lundman wrote:

>
> Hello list,
>
> I can not change the kernel, just compile modules for it.
>
>
> When I compile the FUSE version that comes with a pure 2.6.22-19 kernel version,
> I get the following panic:
>
> NTFS volume version 3.1.
> CPU 0 Unable to handle kernel paging request at virtual address 000000c0, epc ==
> 84088e7c, ra == c023038c
> Oops[#1]:
>
> epc   : 84088e7c kmem_cache_zalloc+0x24/0xa0     Tainted: PF
> ra    : c023038c fuse_fill_super+0x2e0/0x650 [fuse]
> Status: 11001c02    KERNEL EXL
>
> Process ntfs-3g (pid: 17079, threadinfo=8a3d4000, task=898d2278)
>
> Call Trace:
> [<84088e7c>] kmem_cache_zalloc+0x24/0xa0
> [<c023038c>] fuse_fill_super+0x2e0/0x650 [fuse]
> [<8408fe30>] get_sb_bdev+0x26c/0x2cc
> [<c022f9d4>] fuse_get_sb_blk+0x28/0x34 [fuse]
> [<8408e1c8>] vfs_kern_mount+0x5c/0x120
> [<8408e2e8>] do_kern_mount+0x4c/0x134
> [<840ae918>] do_mount+0x19c/0x76c
> [<840aefb0>] sys_mount+0xc8/0x1c8
> [<84012be4>] stack_done+0x20/0x3c
>
>
> If I fetch the latest fuse package, I find the kernel sources are no longer
> included. Oh well.
>
> If I get the kernel sources from the latest/stable kernel 2.6.31.5 it does not
> compile:
>
> In file included from fs/fuse/dev.c:9:
> fs/fuse/fuse_i.h:264: error: field 'cuse_init_in' has incomplete type
> fs/fuse/fuse_i.h:265: error: field 'cuse_init_out' has incomplete type
>
>
> Is there a recommended FUSE version that may fix the panic problem, but might
> also still compile on 2.6.22-19 ?
>
> Please advice,
>
> Lund
>

--
Jorgen Lundman       | <lundman@...>
Unix Administrator   | [phone] ext 1017 (work)
Shibuya-ku, Tokyo    | [phone]          (cell)
Japan                | [phone]          (home)

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Jorgen Lundman]

Ah I see. I have CONFIG_SLAB defined, and it should be CONFIG_SLOB apparently.
Great feedback there, Linux!

So now it passes all of the fuse_fill_super and does not panic. It does appear
to hang, but i will have to explore why that is next.


Jorgen Lundman wrote:

> Actually, tried a few versions and they all die in the same way. So, back to
> original 2.6.22-19 fuse kernel sources, and peppered prints all over the place
> to figure out where it dies;
>
>
>       printk("fill_super: 3\n");
>
>       fc = new_conn();
>       if (!fc)
>           return -ENOMEM;
>
>       printk("fill_super: 3.1\n");
>
>
>
> static struct fuse_conn *new_conn(void)
> {
>       struct fuse_conn *fc;
>
>       printk("new_conn: enter\n");
>       fc = kzalloc(sizeof(*fc), GFP_KERNEL);
>       printk("new_conn: 1\n");
>
>
>
> fill_super: 3
> new_conn: enter
> CPU 0 Unable to handle kernel paging request at virtual address 000000c0, epc ==
> 84088e7c, ra == c02683cc
>
> Which is strange. That is a fairly vanilla call to kzalloc, so I do not
> understand why it would crash. Plenty other modules call this function, so it is
> somewhat confusing it would mind so much.
>
>
>
> Jorgen Lundman wrote:
>>
>> Hello list,
>>
>> I can not change the kernel, just compile modules for it.
>>
>>
>> When I compile the FUSE version that comes with a pure 2.6.22-19 kernel version,
>> I get the following panic:
>>
>> NTFS volume version 3.1.
>> CPU 0 Unable to handle kernel paging request at virtual address 000000c0, epc ==
>> 84088e7c, ra == c023038c
>> Oops[#1]:
>>
>> epc   : 84088e7c kmem_cache_zalloc+0x24/0xa0     Tainted: PF
>> ra    : c023038c fuse_fill_super+0x2e0/0x650 [fuse]
>> Status: 11001c02    KERNEL EXL
>>
>> Process ntfs-3g (pid: 17079, threadinfo=8a3d4000, task=898d2278)
>>
>> Call Trace:
>> [<84088e7c>] kmem_cache_zalloc+0x24/0xa0
>> [<c023038c>] fuse_fill_super+0x2e0/0x650 [fuse]
>> [<8408fe30>] get_sb_bdev+0x26c/0x2cc
>> [<c022f9d4>] fuse_get_sb_blk+0x28/0x34 [fuse]
>> [<8408e1c8>] vfs_kern_mount+0x5c/0x120
>> [<8408e2e8>] do_kern_mount+0x4c/0x134
>> [<840ae918>] do_mount+0x19c/0x76c
>> [<840aefb0>] sys_mount+0xc8/0x1c8
>> [<84012be4>] stack_done+0x20/0x3c
>>
>>
>> If I fetch the latest fuse package, I find the kernel sources are no longer
>> included. Oh well.
>>
>> If I get the kernel sources from the latest/stable kernel 2.6.31.5 it does not
>> compile:
>>
>> In file included from fs/fuse/dev.c:9:
>> fs/fuse/fuse_i.h:264: error: field 'cuse_init_in' has incomplete type
>> fs/fuse/fuse_i.h:265: error: field 'cuse_init_out' has incomplete type
>>
>>
>> Is there a recommended FUSE version that may fix the panic problem, but might
>> also still compile on 2.6.22-19 ?
>>
>> Please advice,
>>
>> Lund
>>
>

--
Jorgen Lundman       | <lundman@...>
Unix Administrator   | [phone] ext 1017 (work)
Shibuya-ku, Tokyo    | [phone]          (cell)
Japan                | [phone]          (home)

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Jorgen Lundman]

Moving further a field, I find that if I mount "hello", and then do a "df", it
hangs here:


struct fuse_req *fuse_get_req(struct fuse_conn *fc)
{
     struct fuse_req *req;
     sigset_t oldset;
     int intr;
     int err;

     atomic_inc(&fc->num_waiting);
     block_sigs(&oldset);
     intr = wait_event_interruptible(fc->blocked_waitq, !fc->blocked);



I'm not sure if there are any CONFIG options that determine how
wait_event_interruptible works. But tracing the "fc->blocked" mutex, I get the
following output:

# hello /tmp/a -d -f &
26502
<4>fill_super: 1
<4>new_conn: enter
<4>new_conn: blocked = 1
<4>new_conn: exit
<4>fill_super: finished
FUSE library version: 2.8.1
nullpath_ok: 0

# df -h
fuse_statfs: enter
<4>fuse_statfs: 0.5
<4>fuse_get_req: enter
<4>fuse_get_req: 1
<4>fuse_get_req: 2

So blocked is set in fill_super(new_conn()), and never cleared.

At my best guess, fuse_send_init() calls request_send_background() with ".end =
process_init_reply",

and process_init_reply() will set "blocked = 0" if it were to be called.

I'm using kernel 2.6.22-19 fuse.ko, but userland fuse-2.8.1. I was under the
impression that it should be capable of talking to an older kernel.





Jorgen Lundman wrote:

> Ah I see. I have CONFIG_SLAB defined, and it should be CONFIG_SLOB apparently.
> Great feedback there, Linux!
>
> So now it passes all of the fuse_fill_super and does not panic. It does appear
> to hang, but i will have to explore why that is next.
>
>
> Jorgen Lundman wrote:
>> Actually, tried a few versions and they all die in the same way. So, back to
>> original 2.6.22-19 fuse kernel sources, and peppered prints all over the place
>> to figure out where it dies;
>>
>>
>>        printk("fill_super: 3\n");
>>
>>        fc = new_conn();
>>        if (!fc)
>>            return -ENOMEM;
>>
>>        printk("fill_super: 3.1\n");
>>
>>
>>
>> static struct fuse_conn *new_conn(void)
>> {
>>        struct fuse_conn *fc;
>>
>>        printk("new_conn: enter\n");
>>        fc = kzalloc(sizeof(*fc), GFP_KERNEL);
>>        printk("new_conn: 1\n");
>>
>>
>>
>> fill_super: 3
>> new_conn: enter
>> CPU 0 Unable to handle kernel paging request at virtual address 000000c0, epc ==
>> 84088e7c, ra == c02683cc
>>
>> Which is strange. That is a fairly vanilla call to kzalloc, so I do not
>> understand why it would crash. Plenty other modules call this function, so it is
>> somewhat confusing it would mind so much.
>>
>>
>>
>> Jorgen Lundman wrote:
>>>
>>> Hello list,
>>>
>>> I can not change the kernel, just compile modules for it.
>>>
>>>
>>> When I compile the FUSE version that comes with a pure 2.6.22-19 kernel version,
>>> I get the following panic:
>>>
>>> NTFS volume version 3.1.
>>> CPU 0 Unable to handle kernel paging request at virtual address 000000c0, epc ==
>>> 84088e7c, ra == c023038c
>>> Oops[#1]:
>>>
>>> epc   : 84088e7c kmem_cache_zalloc+0x24/0xa0     Tainted: PF
>>> ra    : c023038c fuse_fill_super+0x2e0/0x650 [fuse]
>>> Status: 11001c02    KERNEL EXL
>>>
>>> Process ntfs-3g (pid: 17079, threadinfo=8a3d4000, task=898d2278)
>>>
>>> Call Trace:
>>> [<84088e7c>] kmem_cache_zalloc+0x24/0xa0
>>> [<c023038c>] fuse_fill_super+0x2e0/0x650 [fuse]
>>> [<8408fe30>] get_sb_bdev+0x26c/0x2cc
>>> [<c022f9d4>] fuse_get_sb_blk+0x28/0x34 [fuse]
>>> [<8408e1c8>] vfs_kern_mount+0x5c/0x120
>>> [<8408e2e8>] do_kern_mount+0x4c/0x134
>>> [<840ae918>] do_mount+0x19c/0x76c
>>> [<840aefb0>] sys_mount+0xc8/0x1c8
>>> [<84012be4>] stack_done+0x20/0x3c
>>>
>>>
>>> If I fetch the latest fuse package, I find the kernel sources are no longer
>>> included. Oh well.
>>>
>>> If I get the kernel sources from the latest/stable kernel 2.6.31.5 it does not
>>> compile:
>>>
>>> In file included from fs/fuse/dev.c:9:
>>> fs/fuse/fuse_i.h:264: error: field 'cuse_init_in' has incomplete type
>>> fs/fuse/fuse_i.h:265: error: field 'cuse_init_out' has incomplete type
>>>
>>>
>>> Is there a recommended FUSE version that may fix the panic problem, but might
>>> also still compile on 2.6.22-19 ?
>>>
>>> Please advice,
>>>
>>> Lund
>>>
>>
>

--
Jorgen Lundman       | <lundman@...>
Unix Administrator   | [phone] ext 1017 (work)
Shibuya-ku, Tokyo    | [phone]          (cell)
Japan                | [phone]          (home)

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Jorgen Lundman]

So following the initial thread:

# hello /tmp/a -d -f &
<4>fill_super: 1
<4>new_conn: enter
<4>new_conn: blocked = 1
<4>new_conn: exit
<4>fuse_send_init: calling request_send_background
<4>request_send_nowait: enter
<4>request_send_nowait: 2
<4>request_send_nowait: 3
<4>queue_request: enter
<4>queue_request: 2
<4>queue_request: 3
<4>queue_request: 4
<4>queue_request: leave
<4>request_send_nowait: 4
<4>request_send_nowait: 5
<4>request_send_nowait: leave
<4>fill_super: finished
FUSE library version: 2.8.1

How annoying. So the posting of the event all goes according to plan, but
unfortunately, process_init_reply() is never called.

Not I have no idea what's wrong, if it hangs somewhere I can dig deeper, but if
everything goes ok, I'm not entirely sure why the queue is never emptied.

I suspect even if I clear "->blocked" there is larger issues at play, if a
simple lock/wait does not work, it will probably not work in the greater scheme
of things. Presumably it must be some difference in CONFIG for.. linked list?
locking? threads? Hmmm




Jorgen Lundman wrote:

>
> Moving further a field, I find that if I mount "hello", and then do a "df", it
> hangs here:
>
>
> struct fuse_req *fuse_get_req(struct fuse_conn *fc)
> {
>       struct fuse_req *req;
>       sigset_t oldset;
>       int intr;
>       int err;
>
>       atomic_inc(&fc->num_waiting);
>       block_sigs(&oldset);
>       intr = wait_event_interruptible(fc->blocked_waitq, !fc->blocked);
>
>
>
> I'm not sure if there are any CONFIG options that determine how
> wait_event_interruptible works. But tracing the "fc->blocked" mutex, I get the
> following output:
>
> # hello /tmp/a -d -f&
> 26502
> <4>fill_super: 1
> <4>new_conn: enter
> <4>new_conn: blocked = 1
> <4>new_conn: exit
> <4>fill_super: finished
> FUSE library version: 2.8.1
> nullpath_ok: 0
>
> # df -h
> fuse_statfs: enter
> <4>fuse_statfs: 0.5
> <4>fuse_get_req: enter
> <4>fuse_get_req: 1
> <4>fuse_get_req: 2
>
> So blocked is set in fill_super(new_conn()), and never cleared.
>
> At my best guess, fuse_send_init() calls request_send_background() with ".end =
> process_init_reply",
>
> and process_init_reply() will set "blocked = 0" if it were to be called.
>
> I'm using kernel 2.6.22-19 fuse.ko, but userland fuse-2.8.1. I was under the
> impression that it should be capable of talking to an older kernel.
>
>
>
>
>
> Jorgen Lundman wrote:
>> Ah I see. I have CONFIG_SLAB defined, and it should be CONFIG_SLOB apparently.
>> Great feedback there, Linux!
>>
>> So now it passes all of the fuse_fill_super and does not panic. It does appear
>> to hang, but i will have to explore why that is next.
>>
>>
>> Jorgen Lundman wrote:
>>> Actually, tried a few versions and they all die in the same way. So, back to
>>> original 2.6.22-19 fuse kernel sources, and peppered prints all over the place
>>> to figure out where it dies;
>>>
>>>
>>>         printk("fill_super: 3\n");
>>>
>>>         fc = new_conn();
>>>         if (!fc)
>>>             return -ENOMEM;
>>>
>>>         printk("fill_super: 3.1\n");
>>>
>>>
>>>
>>> static struct fuse_conn *new_conn(void)
>>> {
>>>         struct fuse_conn *fc;
>>>
>>>         printk("new_conn: enter\n");
>>>         fc = kzalloc(sizeof(*fc), GFP_KERNEL);
>>>         printk("new_conn: 1\n");
>>>
>>>
>>>
>>> fill_super: 3
>>> new_conn: enter
>>> CPU 0 Unable to handle kernel paging request at virtual address 000000c0, epc ==
>>> 84088e7c, ra == c02683cc
>>>
>>> Which is strange. That is a fairly vanilla call to kzalloc, so I do not
>>> understand why it would crash. Plenty other modules call this function, so it is
>>> somewhat confusing it would mind so much.
>>>
>>>
>>>
>>> Jorgen Lundman wrote:
>>>>
>>>> Hello list,
>>>>
>>>> I can not change the kernel, just compile modules for it.
>>>>
>>>>
>>>> When I compile the FUSE version that comes with a pure 2.6.22-19 kernel version,
>>>> I get the following panic:
>>>>
>>>> NTFS volume version 3.1.
>>>> CPU 0 Unable to handle kernel paging request at virtual address 000000c0, epc ==
>>>> 84088e7c, ra == c023038c
>>>> Oops[#1]:
>>>>
>>>> epc   : 84088e7c kmem_cache_zalloc+0x24/0xa0     Tainted: PF
>>>> ra    : c023038c fuse_fill_super+0x2e0/0x650 [fuse]
>>>> Status: 11001c02    KERNEL EXL
>>>>
>>>> Process ntfs-3g (pid: 17079, threadinfo=8a3d4000, task=898d2278)
>>>>
>>>> Call Trace:
>>>> [<84088e7c>] kmem_cache_zalloc+0x24/0xa0
>>>> [<c023038c>] fuse_fill_super+0x2e0/0x650 [fuse]
>>>> [<8408fe30>] get_sb_bdev+0x26c/0x2cc
>>>> [<c022f9d4>] fuse_get_sb_blk+0x28/0x34 [fuse]
>>>> [<8408e1c8>] vfs_kern_mount+0x5c/0x120
>>>> [<8408e2e8>] do_kern_mount+0x4c/0x134
>>>> [<840ae918>] do_mount+0x19c/0x76c
>>>> [<840aefb0>] sys_mount+0xc8/0x1c8
>>>> [<84012be4>] stack_done+0x20/0x3c
>>>>
>>>>
>>>> If I fetch the latest fuse package, I find the kernel sources are no longer
>>>> included. Oh well.
>>>>
>>>> If I get the kernel sources from the latest/stable kernel 2.6.31.5 it does not
>>>> compile:
>>>>
>>>> In file included from fs/fuse/dev.c:9:
>>>> fs/fuse/fuse_i.h:264: error: field 'cuse_init_in' has incomplete type
>>>> fs/fuse/fuse_i.h:265: error: field 'cuse_init_out' has incomplete type
>>>>
>>>>
>>>> Is there a recommended FUSE version that may fix the panic problem, but might
>>>> also still compile on 2.6.22-19 ?
>>>>
>>>> Please advice,
>>>>
>>>> Lund
>>>>
>>>
>>
>

--
Jorgen Lundman       | <lundman@...>
Unix Administrator   | [phone] ext 1017 (work)
Shibuya-ku, Tokyo    | [phone]          (cell)
Japan                | [phone]          (home)

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Miklos Szeredi]

On Thu, 29 Oct 2009, Jorgen Lundman wrote:

> Hello list,
>
> I can not change the kernel, just compile modules for it.
>
>
> When I compile the FUSE version that comes with a pure 2.6.22-19 kernel version,
> I get the following panic:
>
> NTFS volume version 3.1.
> CPU 0 Unable to handle kernel paging request at virtual address 000000c0, epc ==
> 84088e7c, ra == c023038c
> Oops[#1]:
>
> epc   : 84088e7c kmem_cache_zalloc+0x24/0xa0     Tainted: PF
> ra    : c023038c fuse_fill_super+0x2e0/0x650 [fuse]
> Status: 11001c02    KERNEL EXL
>
> Process ntfs-3g (pid: 17079, threadinfo=8a3d4000, task=898d2278)
>
> Call Trace:
> [<84088e7c>] kmem_cache_zalloc+0x24/0xa0
> [<c023038c>] fuse_fill_super+0x2e0/0x650 [fuse]
> [<8408fe30>] get_sb_bdev+0x26c/0x2cc
> [<c022f9d4>] fuse_get_sb_blk+0x28/0x34 [fuse]
> [<8408e1c8>] vfs_kern_mount+0x5c/0x120
> [<8408e2e8>] do_kern_mount+0x4c/0x134
> [<840ae918>] do_mount+0x19c/0x76c
> [<840aefb0>] sys_mount+0xc8/0x1c8
> [<84012be4>] stack_done+0x20/0x3c

Weird, not seen this reported before.

> If I fetch the latest fuse package, I find the kernel sources are no longer
> included. Oh well.
>
> If I get the kernel sources from the latest/stable kernel 2.6.31.5 it does not
> compile:
>
> In file included from fs/fuse/dev.c:9:
> fs/fuse/fuse_i.h:264: error: field 'cuse_init_in' has incomplete type
> fs/fuse/fuse_i.h:265: error: field 'cuse_init_out' has incomplete type
>
>
> Is there a recommended FUSE version that may fix the panic problem, but might
> also still compile on 2.6.22-19 ?

It is probably easier to debug the panic, than to try to backport a
later version of the fuse module.

What sort of kernel is this (which distribution does it come from)?

Thanks,
Miklos

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Jorgen Lundman]

> It is probably easier to debug the panic, than to try to backport a
> later version of the fuse module.
>
> What sort of kernel is this (which distribution does it come from)?
>

Thanks for replying, as you can see I solved this panic later, by guessing I
should use CONFIG_SLOB and not CONFIG_SLAB. Unfortunately, I have no way to get
the original config as of yet, but I am working on decrypting their kernel in
the hopes that config is attached at the end.

However, in my later emails, you can see the wait_event_interruptible() stalls
forever, which was tracked down to "fc->blocked" being true.

This was due to process_init_reply() never getting called. This I do not know
how to explore.

The kernel is for the new SMP8643 Sigma boards used in, for example, Popcornhour
C200. It is Linux 2.6.22-19-Sigma.


--
Jorgen Lundman       | <lundman@...>
Unix Administrator   | [phone] ext 1017 (work)
Shibuya-ku, Tokyo    | [phone]          (cell)
Japan                | [phone]          (home)

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Miklos Szeredi]

On Mon, 09 Nov 2009, Jorgen Lundman wrote:

> > It is probably easier to debug the panic, than to try to backport a
> > later version of the fuse module.
> >
> > What sort of kernel is this (which distribution does it come from)?
> >
>
> Thanks for replying, as you can see I solved this panic later, by
> guessing I should use CONFIG_SLOB and not
> CONFIG_SLAB. Unfortunately, I have no way to get the original config
> as of yet, but I am working on decrypting their kernel in the hopes
> that config is attached at the end.

You can ask for source code (including the config) from whoever is
distributing the kernel binaries.  It is their obligation under the
GPL, and refusing it is in violation of the kernel's license.

Thanks,
Miklos

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Jorgen Lundman]

>
> You can ask for source code (including the config) from whoever is
> distributing the kernel binaries.  It is their obligation under the
> GPL, and refusing it is in violation of the kernel's license.
>

Oh yes, of course you can ask, and with the previous model they did eventually
do so, but for the next ~9 months or so, I might be able to get it to run before
then.. :)

Or not, I'm not sure.  Even settings ->blocked=1 in the last bit of
request_send_nowait() did not work either. There is just something fundamentally
different.



--
Jorgen Lundman       | <lundman@...>
Unix Administrator   | [phone] ext 1017 (work)
Shibuya-ku, Tokyo    | [phone]          (cell)
Japan                | [phone]          (home)

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel

[Miklos Szeredi]

On Tue, 17 Nov 2009, Jorgen Lundman wrote:
> >
> > You can ask for source code (including the config) from whoever is
> > distributing the kernel binaries.  It is their obligation under the
> > GPL, and refusing it is in violation of the kernel's license.
> >
>
> Oh yes, of course you can ask, and with the previous model they did
> eventually do so, but for the next ~9 months or so, I might be able
> to get it to run before then.. :)

Or you can contact http://gpl-violations.org/

They can help with raising awareness of GPL compliance issues,
possibly speeding up the process.

Thanks,
Miklos

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
fuse-devel mailing list
fuse-devel@...
https://lists.sourceforge.net/lists/listinfo/fuse-devel