Thread: [Ndiswrapper-general] Finally
Status: Beta
Brought to you by:
pgiri
From: David G. M. <da...@da...> - 2007-05-01 20:53:24
|
OK. I finally got my laptop (HP Pavilion zv6000 series with a Broadcom BCM4306 wireless NIC) running *stably* with ndiswrapper but therein lies the tale. First off, I dropped back from FC6 to CentOS 5 (both x86_64) but this didn't seem to make any difference. I still got frequent spontaneous reboots if I tried to leave the wireless up for any length of time. I also tried the native BCM43xx driver but the system wouldn't boot with it. I decided to approach the problem from the "other side" and stopped ndiswrapper, NetworkManager, NetworkManagerDispatcher and wpa_supplicant. In this configuration the system ran stably for a couple of days so I started adding things back in. Just starting ndiswrapper didn't seem to make a difference and I could "iwlist eth1 scan" to get a list of nearby access points which confirmed ndiswrapper was actually working. I next wanted to be able to actually connect to my AP which meant I needed a way to have the system authenticate using WPA and pre-shared keys. I fiddled with wpa_supplicant.conf long enough to get the wireless authenticating but this got me back to where I was before. The system would spontaneously reboot or lock up after a few hours. Not sure why but I decided to try the current "plain vanilla" kernel (2.6.21) from kernel.org. The system now stays up with no problems and, frosting on the cake, my laptop's secure digital card reader now works. Does anyone have any idea why I would get spontaneous reboots and lock ups with a RHEL or FC6 kernel but the un-patched kernel from kernel.org works fine? Also, just so the information gets recorded somewhere, the worst problem I had configuring wpa_supplicant to work with ndiswrapper was wpa_supplicant kept complaining about: Driver does not support WPA. I knew this was incorrect since I had wpa_supplicant working previously using NetworkManager. The system would reboot within an hour or so but the connection was definitely there. I chased this down to telling wpa_supplicant that the driver was ndiswrapper instead of wext. Once I switched /etc/sysconfig/wpa_supplicant to use "DRIVERS=-Dwext" my system authenticated and I could bring up the wireless interface, ping other boxes, etc. Kind of strange that wext works better than ndiswrapper as the wpa_supplicant driver. Cheers, Dave -- Politics, n. Strife of interests masquerading as a contest of principles. -- Ambrose Bierce |
From: Bob S. <sm...@c-...> - 2007-05-01 22:52:53
|
On Tue, 2007-05-01 at 14:53 -0600, David G. Miller wrote: <snip> > Not sure why but I decided to try the current "plain vanilla" kernel > (2.6.21) from kernel.org. The system now stays up with no problems and, > frosting on the cake, my laptop's secure digital card reader now works. This is a pure guess - but could it be related to the stack? If I recall, ndiswrapper needs a kernel with a deeper than normal stack (16K?). Not sure why the stock kernel would work, but might be worth looking into. HTH, -- Bob Smither <sm...@c-...> |
From: David G. M. <da...@da...> - 2007-05-01 23:41:58
|
Bob Smither wrote: > On Tue, 2007-05-01 at 14:53 -0600, David G. Miller wrote: > > <snip> > > >> Not sure why but I decided to try the current "plain vanilla" kernel >> (2.6.21) from kernel.org. The system now stays up with no problems and, >> frosting on the cake, my laptop's secure digital card reader now works. >> > > This is a pure guess - but could it be related to the stack? If I > recall, ndiswrapper needs a kernel with a deeper than normal stack > (16K?). Not sure why the stock kernel would work, but might be worth > looking into. > > HTH, > What's weird is that the x86_64 kernel doesn't seem to optionally constrain the stack. If I dig in the config file for my desktop (32-bit Athlon), I see: ... CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_DEBUG_STACK_USAGE=y # # Page alloc debug is incompatible with Software Suspend on i386 # CONFIG_DEBUG_RODATA=y CONFIG_4KSTACKS=y <-- Here's the culprit for 32bit kernels CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_DOUBLEFAULT=y # # Security options # ...<end 32 bit kernel config> But when I look for the comparable section in the x86_64 config file on my laptop I see: ... CONFIG_DEBUG_RODATA=y # CONFIG_IOMMU_DEBUG is not set CONFIG_DEBUG_STACKOVERFLOW=y # CONFIG_DEBUG_STACK_USAGE is not set # # Security options # ... There is no CONFIG_4KSTACKS option for the x86_64 kernel. I made my 2.6.21 kernel by copying the Red Hat config file for their most recent kernel from /boot and just did a "make oldconfig" with it to make my 2.6.21 config file. I basically just accepted the defaults for anything new unless I knew something wasn't applicable to my laptop. Also, I know I would have noticed if there had been a "CONFIG_4K_STACKS" option since I was aware that this can cause problems with ndiswrapper. It's possible that one of the stack debug options (see the config fragments above) is causing the problem. That's why I posted my results. Maybe someone running a different distro's x86_64 kernel can check their kernel config file. Cheers, Dave -- Politics, n. Strife of interests masquerading as a contest of principles. -- Ambrose Bierce |