Opened 14 years ago
Closed 14 years ago
#6679 closed bug (fixed)
KDL on boot with Intel wifi 2100
Reported by: | vercu | Owned by: | mmlr |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Network & Internet/Wireless | Version: | R1/Development |
Keywords: | ipw2100 | Cc: | |
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
For some time now my Sony PCG-Z1XEP notebook goes to KDL during boot. It always works with Haiku. The ipw2100 wifi never worked out of the box. Thought ticket 6521 will fix this but it doesn't. Tested with hrev38849.
Attachments (1)
Change History (13)
by , 14 years ago
Attachment: | r38849-no_boot.jpg added |
---|
comment:1 by , 14 years ago
comment:2 by , 14 years ago
The ipw2100 driver does not use the FreeBSD compatibility layer, and is therefore independent from that fix. Furthermore, setwep will also not work with it, as it does not support any of the standard mac80211 commands.
comment:5 by , 14 years ago
Long time ago mmlr tried to find the problem with the native ipw2100 driver on my machine. With no success. As i recall he suspected an IRQ problem. The notebook did not went to KDL. That is a recent problem. Alpha 2 works. I think the problem starts when axeld worked on the network stack this summer.
comment:6 by , 14 years ago
Using hrev41080 (gcc2hybrid) on a first generation centrino notebook (Acer Travelmate 800LCi).
What about removing ipw2100 driver from default nightly (or at least alpha3) image files? After more than 6 months I'm tired of disabling this driver by renaming /system/add-ons/kernel/drivers/bin/ipw2100 every time I update haiku. Even when booting in safe mode my system freezes randomly. If this driver doesn't work for anyone, why not get rid of it completely (or move it to the experimental section)?
comment:7 by , 14 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Assigning to mmlr for a decision on this issue.
comment:8 by , 14 years ago
Problem seems that as soon as the ipw2100 driver is loaded it also needs its firmware files - no matter if wlan adapter is activated or not. However, the firmware files are not yet installed (extracted) during the first boot because the user has to acknowledge the licence file before the firmware can be extracted (e.g. by running the install-wifi-firmwares.sh script).
Only after installation of firmware files haiku boots without visiting KDL. So, maybe, instead of removing ipw2100 completely the following idea might work: a default haiku image mustn't use the ipw2100 driver; after the first boot - if an Intel PRO/Wireless 2100 adapter is found - the user is asked if they want to use their wlan adapter; if yes, driver and firmware are installed at the same time; during the next reboot there would be no KDL.
comment:9 by , 14 years ago
It is plain simply a bug. The driver doesn't require the firmware files, it should fail gracefully if they aren't there and the network interface would simply be unavailable. It did that back then, but it doesn't do that anymore due to the change of the kernel heap which uncovers obvious laziness on my part back in 2006. The heap back then would return either NULL or a normally freeable address when it is supposed to allocate an invalid amount of memory and would not fail to free() such an address. It doesn't seem the new heap does that too, either returning an invalid address or failing to take this into account on free (IMO that should be fixed as well). But in any case the driver just needs to check for one of the numerous error conditions that lead up to this (failing to open the file, failing to seek to the end, getting an invalid size and failing to allocate a buffer) which will cure this. I can change that tonight.
comment:10 by , 14 years ago
Should be fixed in hrev41144. Please test and confirm. As mentioned in the commit message it should probably be checked why the assert is triggered in the first place (some pointers in the comment above already).
comment:12 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Closing as fixed in hrev41144, thanks for the feedback.
There is currently a bug with the nightly builds, the version number is not correct. The 38849 builds are actually 38837 (look in the About window to make sure), which of course doesn't contain axeld's fix in hrev38838 - which in turn hopefully would fix your problem.