Hi,
I ran into the same problem and made a backport of ipt_recent.c for
Sarge's 2.6.8. It was actually pretty simple to backport. Attached is
the diff against the ipt_recent.c source file from Philipp's comment of
6 Jul 2006.
The backported module is already running in one of my systems. Works
I apologize for having been so silent. The ipw2200 problem is gone
(hasn't been reproducable) since I upgraded to kernel 2.6.16-2. As far
as it regards my initial bu report, the bug can be closed.
Martin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
Package: linux-image-2.6.15-1-686
Version: 2.6.15-1
Severity: important
I just got the following BUG. I copied the message by hand so it's not a
perfect backtrace; I apologize for that.
comm: ipw2200
EIP is at __queue_work+3e
EFLAGS 00200246 Not tainted
eax: f4ba5650 ebx: f44db268 ECX: 0001
Rusty Russell wrote:
Martin Wilck [EMAIL PROTECTED] wrote:
0. the module loading tool runs during boot with PID 1.
I do not understand how this can happen. request_module() cannot occur
until usermodehelper_init() is called. This is only done once the init
thread is spawned, which should
symbols
Possible workarounds:
a) check PID returned by wait4() and only continue if it matches the
forked insmod's PID
b) fork() right after tool startup so that the calling tool isn't
running with PID 1.
Could this be the problem cause here, too?
Regards
Martin
--
Martin Wilck
5 matches
Mail list logo