First let me start by a thanks: it was the last piece of my P5W de luxe
machine based that has not its driver from stock kernel.
It works like a charm when used as a module:
lsusb
Bus 005 Device 001: ID 0000:0000
Bus 003 Device 001: ID 0000:0000
Bus 004 Device 001: ID 0000:0000
Bus 002 Device 001: ID 0000:0000
Bus 001 Device 007: ID 0bda:8187 Realtek Semiconductor Corp. <=========
Bus 001 Device 005: ID 05e3:0606 Genesys Logic, Inc. D-Link DUB-H4 USB
2.0 Hub
Bus 001 Device 004: ID 03f0:c202 Hewlett-Packard
Bus 001 Device 006: ID 058f:6362 Alcor Micro Corp. Hi-Speed Internal
Multi-Card Reader/Writer
Bus 001 Device 001: ID 0000:0000
Bus 001 Device 003: ID 05e3:0606 Genesys Logic, Inc. D-Link DUB-H4 USB
2.0 Hub
Bus 001 Device 002: ID 05e3:0606 Genesys Logic, Inc. D-Link DUB-H4 USB
2.0 Hub
wlan0 IEEE 802.11g ESSID:"xxxxxxxx"
Mode:Managed Frequency:2.437 GHz Access Point: 00:18:E7:15:2B:2A
Bit Rate=11 Mb/s
Retry min limit:7 RTS thr:off Fragment thr=2346 B
Encryption key:xxxxxxxxx
Link Quality=43/64 Signal level=39/65
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
wlan0 Lien encap:Ethernet HWaddr 00:15:AF:0A:BE:A9
inet adr:192.168.1.11 Bcast:192.168.1.255 Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:637 errors:0 dropped:0 overruns:0 frame:0
TX packets:562 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:373558 (364.8 KiB) TX bytes:88216 (86.1 KiB)
However, when I compile it directly inside the kernel, I get a panic
with a backtrace at usb initilialisation. The backtrace points to
registering things in /proc (make-directory or something)!
I can probably take a picture of the backtrace if you want.
Config: Asus P5W de luxe, Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz, pure
64 bits install.
-- eric
Eric Valette wrote:
> I can probably take a picture of the backtrace if you want.
Just saw that just above my message in the LKML web interface, someone
posted a backtrace. Mine is different but at least, we are at least two
to have the crash.
-- eric
Hi Eric,
On Sat, 15 Sep 2007 16:27:30 +0200
Eric Valette <[email protected]> wrote:
> Eric Valette wrote:
>
> > I can probably take a picture of the backtrace if you want.
>
> Just saw that just above my message in the LKML web interface, someone
> posted a backtrace. Mine is different but at least, we are at least two
> to have the crash.
Well, I have it when compiling rtl8187 inside the kernel, but I still have to
try it as a module, to confirm we are facing the same bug...
Please allow me some time for that, I'll post an update.
Regards,
Paul
--
Paul Rolland E-Mail : rol(at)witbe.net
Witbe.net SA Tel. +33 (0)1 47 67 77 77
Les Collines de l'Arche Fax. +33 (0)1 47 67 77 99
F-92057 Paris La Defense RIPE : PR12-RIPE
Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur
"Some people dream of success... while others wake up and work hard at it"
"I worry about my child and the Internet all the time, even though she's too
young to have logged on yet. Here's what I worry about. I worry that 10 or 15
years from now, she will come to me and say 'Daddy, where were you when they
took freedom of the press away from the Internet?'"
--Mike Godwin, Electronic Frontier Foundation
On 9/15/07, Eric Valette <[email protected]> wrote:
> Eric Valette wrote:
>
> > I can probably take a picture of the backtrace if you want.
>
> Just saw that just above my message in the LKML web interface, someone
> posted a backtrace. Mine is different but at least, we are at least two
> to have the crash.
This is the same thing I said to Paul Rolland, since I think your
problems are the same:
I had this problem as well. It has to do with mac80211, cfg80211 and
the rate control algorithm not initializing early enough in the boot
process. These two patches should fix it:
[PATCH] mac80211: fix initialisation when built-in
http://article.gmane.org/gmane.linux.kernel.wireless.general/5710/match=patch+mac80211+initialisation
[PATCH] cfg80211: fix initialisation if built-in
http://article.gmane.org/gmane.linux.network/71326/match=patch+cfg80211+initialisation
Regards,
Rob
Hi Rob,
On Sat, 15 Sep 2007 12:28:36 -0400
"Rob Hussey" <[email protected]> wrote:
> On 9/15/07, Eric Valette <[email protected]> wrote:
> > Eric Valette wrote:
> >
> > > I can probably take a picture of the backtrace if you want.
> >
> > Just saw that just above my message in the LKML web interface, someone
> > posted a backtrace. Mine is different but at least, we are at least two
> > to have the crash.
>
> This is the same thing I said to Paul Rolland, since I think your
> problems are the same:
> I had this problem as well. It has to do with mac80211, cfg80211 and
> the rate control algorithm not initializing early enough in the boot
> process. These two patches should fix it:
>
> [PATCH] mac80211: fix initialisation when built-in
> http://article.gmane.org/gmane.linux.kernel.wireless.general/5710/match=patch+mac80211+initialisation
>
> [PATCH] cfg80211: fix initialisation if built-in
> http://article.gmane.org/gmane.linux.network/71326/match=patch+cfg80211+initialisation
>
Too bad gmane patches can't be applied directly, they seems to contain
very strange <at> inside....
However, manually patching seems to be Ok. Kernel is now booting
correctly, and I have :
...
802.1Q VLAN Support v1.8 Ben Greear <[email protected]>
All bugs added by David S. Miller <[email protected]>
ieee80211: 802.11 data/management/control stack, git-1.1.13
ieee80211: Copyright (C) 2004-2005 Intel Corporation
<[email protected]>
ieee80211_crypt: registered algorithm 'NULL'
ieee80211_crypt: registered algorithm 'WEP'
ieee80211_crypt: registered algorithm 'CCMP'
ieee80211_crypt: registered algorithm 'TKIP'
...
and after some iwconfig configuration steps, I have :
wlan0 Link encap:Ethernet HWaddr
00:15:AF:0F:D7:90 inet addr:192.168.1.34 Bcast:192.168.1.255
Mask:255.255.255.0 inet6 addr: fe80::215:afff:fe0f:d790/64
Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500
Metric:1 RX packets:15 errors:0 dropped:0 overruns:0
frame:0 TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0
txqueuelen:1000 RX bytes:4798 (4.6 KiB) TX bytes:4566 (4.4
KiB)
These two patches are a "must be" for 2.6.23 !!!
Eric, feel confident, it seems really to do the trick, and the changes are
subtle and mostly harmless.
Regards,
Paul
Rob Hussey wrote:
> On 9/15/07, Eric Valette <[email protected]> wrote:
>> Eric Valette wrote:
>>
>>> I can probably take a picture of the backtrace if you want.
>> Just saw that just above my message in the LKML web interface, someone
>> posted a backtrace. Mine is different but at least, we are at least two
>> to have the crash.
>
> This is the same thing I said to Paul Rolland, since I think your
> problems are the same:
> I had this problem as well. It has to do with mac80211, cfg80211 and
> the rate control algorithm not initializing early enough in the boot
> process. These two patches should fix it:
>
> [PATCH] mac80211: fix initialisation when built-in
> http://article.gmane.org/gmane.linux.kernel.wireless.general/5710/match=patch+mac80211+initialisation
>
> [PATCH] cfg80211: fix initialisation if built-in
> http://article.gmane.org/gmane.linux.network/71326/match=patch+cfg80211+initialisation
>
> Regards,
> Rob
Thanks for your help: it does indeed fix the problem.
Now I have two side questions:
- the code is no more symetric "subsys_initcall" -> "module_exit". Do
not know if it is "normal" but I love symmetry in code :-). Did not test
it still works as a module...
- Who takes the responsability to push a patch to Linus? I guess it is
urgent unless he plans a rc7
-- eric
Hi Eric,
On Sat, 15 Sep 2007 20:30:14 +0200
Eric Valette <[email protected]> wrote:
> Rob Hussey wrote:
> > On 9/15/07, Eric Valette <[email protected]> wrote:
> >> Eric Valette wrote:
> >>
>
> Thanks for your help: it does indeed fix the problem.
Nice it works for you too !
> Now I have two side questions:
> - the code is no more symetric "subsys_initcall" -> "module_exit".
> Do not know if it is "normal" but I love symmetry in code :-). Did not test
> it still works as a module...
Symmetry is not broken, as we have :
#define subsys_initcall(fn) module_init(fn)
in include/linux/init.h where compiling as a module, and when not compiling
as a module, I doubt the exit function is called unless you are shuting
down your machine...
> - Who takes the responsability to push a patch to Linus? I guess it
> is urgent unless he plans a rc7
Good point ! I expect the patches to be already in some queue waiting to be
pulled !
Paul Rolland (ポール・ロラン) wrote:
> Hi Eric,
>> Now I have two side questions:
>> - the code is no more symetric "subsys_initcall" -> "module_exit".
>> Do not know if it is "normal" but I love symmetry in code :-). Did not test
>> it still works as a module...
> Symmetry is not broken, as we have :
> #define subsys_initcall(fn) module_init(fn)
> in include/linux/init.h where compiling as a module, and when not compiling
> as a module, I doubt the exit function is called unless you are shuting
> down your machine...
I came to this conclusion too. But I would have preferred to have
#define subsys_exit(fn) modules_exit(fn)
in the case of a module and nop in the non module case...
-- eric
On 9/15/07, $B%]!<%k!&%m%i%s(B Paul Rolland <[email protected]> wrote:
> Hi Eric,
>
> On Sat, 15 Sep 2007 20:30:14 +0200
> Eric Valette <[email protected]> wrote:
>
> > Rob Hussey wrote:
> > > On 9/15/07, Eric Valette <[email protected]> wrote:
> > >> Eric Valette wrote:
> > >>
> >
> > Thanks for your help: it does indeed fix the problem.
> Nice it works for you too !
>
> > Now I have two side questions:
> > - the code is no more symetric "subsys_initcall" -> "module_exit".
> > Do not know if it is "normal" but I love symmetry in code :-). Did not test
> > it still works as a module...
> Symmetry is not broken, as we have :
> #define subsys_initcall(fn) module_init(fn)
> in include/linux/init.h where compiling as a module, and when not compiling
> as a module, I doubt the exit function is called unless you are shuting
> down your machine...
>
> > - Who takes the responsability to push a patch to Linus? I guess it
> > is urgent unless he plans a rc7
> Good point ! I expect the patches to be already in some queue waiting to be
> pulled !
The patches are on their way to making it into 2.6.23:
http://marc.info/?l=linux-netdev&m=118986368303529&w=2
Regards,
Rob
On Sa, 2007-09-15 at 21:00 +0200, Eric Valette wrote:
> I came to this conclusion too. But I would have preferred to have
> #define subsys_exit(fn) modules_exit(fn)
>
> in the case of a module and nop in the non module case...
module_exit is a no-op anyway in the non-modular case, it's never
called, so what's the point?
johannes
Johannes Berg wrote:
> On Sa, 2007-09-15 at 21:00 +0200, Eric Valette wrote:
>
>
>> I came to this conclusion too. But I would have preferred to have
>> #define subsys_exit(fn) modules_exit(fn)
>>
>> in the case of a module and nop in the non module case...
>>
>
> module_exit is a no-op anyway in the non-modular case, it's never
> called, so what's the point?
>
That I would have prefered to see subsys_exit in front of
subsys_initcall instead of module_exit because
1) it made me wonder if it still works in the module case
2) If you see the comment in init.h (/* Don't use these in modules,
but some people do... */), you should not use it in module. The comment
is, at least misleading, because for code that can be used as module or
directly embedded in some cases you are indeed forced to use it (did a
grep and found a lot)
3) Non symetrical code frequently points to errors or bad design.
YMMV :-)
4) If someone someday find something to do when shutting down
(hotrestart, fault tolerance, or something equivalent), we would have a
place to hook. C++ has destructors called after main and before __exit...
NB : This has nothing to do with the proposed patch that is definitively
correct given current init.h.
Personally, I would certainly add:
#define subsys_exit(fn) in init.h
But would rate it myself as a cosmetic change as it *only* makes the code more obvious to read :-)
-- eric
Rob Hussey wrote:
> On 9/15/07, ポール・ロラン Paul Rolland <[email protected]> wrote:
>
>> Hi Eric,
>>
>> On Sat, 15 Sep 2007 20:30:14 +0200
>> Eric Valette <[email protected]> wrote:
>>
>>
>>> Rob Hussey wrote:
>>>
>>>> On 9/15/07, Eric Valette <[email protected]> wrote:
>>>>
>>>>> Eric Valette wrote:
>>>>>
>>>>>
>>> Thanks for your help: it does indeed fix the problem.
>>>
>> Nice it works for you too !
>>
>>
>>> Now I have two side questions:
>>> - the code is no more symetric "subsys_initcall" -> "module_exit".
>>> Do not know if it is "normal" but I love symmetry in code :-). Did not test
>>> it still works as a module...
>>>
>> Symmetry is not broken, as we have :
>> #define subsys_initcall(fn) module_init(fn)
>> in include/linux/init.h where compiling as a module, and when not compiling
>> as a module, I doubt the exit function is called unless you are shuting
>> down your machine...
>>
>>
>>> - Who takes the responsability to push a patch to Linus? I guess it
>>> is urgent unless he plans a rc7
>>>
>> Good point ! I expect the patches to be already in some queue waiting to be
>> pulled !
>>
>
> The patches are on their way to making it into 2.6.23:
> http://marc.info/?l=linux-netdev&m=118986368303529&w=2
>
> Regards,
> Rob
>
I'm a little bit worried as rc8 is out and ots still not in git.
-- eric