Drivers for Puppy 5.1-5.2.8 with 2.6.33.2 kernel

For drivers and kernel modules.
Post Reply
Message
Author
User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

Analog Dialup Modem Drivers - Most of them

#81 Post by rerwin »

Here (and in next message) are all of the previously available analog dialup modem drivers other than for the SmartLink PCI and USB modems and the HCFPCI modems. The versions are the same as in Wary 5.1.2. The packages can be installed only as needed or all together for a complete set.

The SmartLink modem drivers appear to be almost abandoned by the responsible parties. While work continues on an Ubuntu version of the drivers, the latest from the technion site (3/21/2011, slamr) still fails to connect, spewing "NO CARRIER" messages until stopped manually. As for the USB version, support has apparently been ended altogether. Furthermore, the proprietary component has not kept up with kernel developments and cannot be maintained by anyone but LSI.

Although Barry has included both drivers in Wary, the PCI driver spews "NO CARRIER" and the USB driver spews initialization and shutdown "disaster" messages and may corrupt the data (pupsave) file. Beyond those issues, the PCI modems apparently require reloading of the slamr module and restarting of the user-space daemon (slmodemd) for each connection after the first in a bootup session. Omitting those drivers avoids subjecting users to those risks, which would damage Lucid Pup's reputation for stability.

Note, however, that ALSA modems that use the slmodemd user-space component are still supported.

The HCFPCI driver is omitted because it requires each user to pay the developers US$15 to activate a usable data rate beyond 14.4 kbs. If anyone needs or can use the HCFPCI driver at that speed (or can pay), please tell me and I can add it. My thinking, though, is to avoid suggesting that HCF modems are usable without making the payment, which might be difficult from some parts of the world.

I have tested examples of all of the modems except for HDA modems, modems requiring the non-HDA Agere (agrsm) drivers, and the Intel 537s. Note that the newest driver for the 537s does not support the Dell version of 537EP, making mine useful only for verifying that the variant selector still works.

Regarding the HSF- and Agere HDA drivers: I have my doubts whether they can work, but have no way to experiment with them. There may be mismatches between the versions of ALSA used by Lupu and those expected by the drivers. I believe I saw that the Agere was coded for ALSA 1.0.20 and that the HSF may need a patch to the Intel HDA driver(s) associated with the target ALSA version. Lucid Pup has 1.0.24. Although we could experiment with patching for the HSF HDA driver, my only hope for the Agere is that the newly released version of the HDA driver might help. Beyond that, I have no idea what to do about the Agere HDA mismatch, other than wait for further updates from the developer. Advice from ALSA experts is hereby requested.

EDIT: Peebee reports that the Agere HDA driver works in all recent warys, including 5.1.4.1, but still does not work in Lucid Pup. They all use ALSA 1.0.21a. Unless there is something I have missed about setting up the driver, it appears that the difference in ALSA versions and possibly kernel versions might account for the different behavior.

EDIT: I have concluded that the Agere HDA modem driver cannot be used in lucid pup 5.2.8 because the current ALSA version is different from the version that came with kernel 2.6.33.2 (1.0.24.2 vs. 1.0.21). The driver requires the versions to match. For the future (Three-Headed Dog), we should avoid changing the ALSA version from that of the kernel if we are to have working Agere HDA modem support.

I think I will add logic to the packages containing the Agere 11c11040 driver to prevent installation of the driver if the ALSA versions differ, as shown by these commands:
  • cat /proc/asound/version
    alsactl --version
That way, the modem simply will not be detected (because it is not supported) rather than tease the user by detecting it and making it appear to work up to a point.
Richard
Last edited by rerwin on Sat 17 Sep 2011, 02:21, edited 6 times in total.

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

The 4 variants of the Intel 537 driver.

#82 Post by rerwin »

(Continuation of previous posting.)

If you know which driver variant you need, you can skip installation of the others, unless you want the complete set.

I changed the .pet names to reflect the origin of the source code. The content is unchanged.
Last edited by rerwin on Thu 15 Sep 2011, 23:34, edited 1 time in total.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#83 Post by PaulBx1 »

1a. If you still cannot get a successful wifi connection, you may need to force the b43 driver into PIO mode, which slows down the transfer rate.
Open /etc/modprobe.conf
On the b43 driver, I got my Dell Mini 9 working with only the first step - but only temporarily. Now it again does not connect.

I was going to try your step 1a quoted above, but in 5.2.8 we seem to be in a new regime, as there is no /etc/modprobe.conf to modify. Perhaps your instruction should be updated for late puppies?

User avatar
peebee
Posts: 4370
Joined: Sun 21 Sep 2008, 12:31
Location: Worcestershire, UK
Contact:

Re: Analog Dialup Modem Drivers - Most of them

#84 Post by peebee »

rerwin wrote:I have tested examples of all of the modems except for HDA modems, modems requiring the non-HDA Agere (agrsm) drivers, and the Intel 537s. Note that the newest driver for the 537s does not support the Dell version of 537EP, making mine useful only for verifying that the variant selector still works.
Richard
Hi Richard

Started with a pristine frugal install of 528.
Rebooted to create savefile.
Install the Instant Update 001 pet and then
the Agere HDA modem pet dialup_modem_drivers-hda-hsf-k2.6.33.2-20110913.pet

dmesg seemed to suggest the ttyAGS3 had been correctly loaded however when I went into pupdial to test it the driver crashed:

Code: Select all

serial8250_register_ports: BaseAddress 0x4004 Irq 29 
ttyAGS3 at I/O 0x4004 (irq = 29) is a AgereModem
agrserial - ret_val 0, call: lt_modem_ops.init_modem
Loading module Agere Modem Interface driver version 2.1.80.0 (2007-10-01)
==> codecType = 0x32
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<f8f6c9bb>] AzlDmaAllocation+0x81/0x2f9 [agrmodem]
*pde = 00000000 
Oops: 0002 [#1] SMP 
last sysfs file: /sys/devices/pci0000:00/0000:00:1c.1/0000:10:00.0/ssb0:0/net/wlan0/statistics/tx_bytes
Modules linked in: agrserial agrmodem i915 drm_kms_helper drm i2c_algo_bit i2c_core snd_hda_codec_analog arc4 ecb snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss b43 snd_pcm mac80211 cfg80211 led_class snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd ohci_hcd soundcore snd_page_alloc serio_raw fbcon tileblit font bitblit softcursor pcspkr shpchp pci_hotplug sg e1000e intel_agp agpgart hp_wmi wmi battery fan container video output thermal evdev button processor ac fuse aufs nls_iso8859_1 nls_cp437 usbhid usb_storage squashfs ssb uhci_hcd ehci_hcd usbcore

Pid: 13479, comm: modem-stats Tainted: P           2.6.33.2 #1 3618/HP 550
EIP: 0060:[<f8f6c9bb>] EFLAGS: 00010202 CPU: 0
EIP is at AzlDmaAllocation+0x81/0x2f9 [agrmodem]
EAX: 00000001 EBX: 00000000 ECX: f4b4d920 EDX: 00000000
ESI: f81e00c4 EDI: f81e0028 EBP: ece5bd34 ESP: ece5bd0c
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process modem-stats (pid: 13479, ti=ece5a000 task=f4ac83c0 task.ti=ece5a000)
Stack:
 00000000 f81ea5f5 f81ea5d8 f81ea5e0 ece5bd28 ece5bda3 000000ff f81e00c4
 f81e00c4 f81e0028 ece5bd54 f8f6d2ad f81e00c4 00000000 f81e0028 ece5bdc4
 c128a594 ece5bda3 ece5bdc4 f8f561e1 f81e00c4 f8151048 00000008 00000001
Call Trace:
 [<f8f6d2ad>] ? CAzlIntelInit+0x381/0x3c4 [agrmodem]
 [<c128a594>] ? printk+0xe/0x11
 [<f8f561e1>] ? LXHardwareStart+0x11de/0x13fb [agrmodem]
 [<c1055bcd>] ? __alloc_pages_nodemask+0xd6/0x470
 [<f8f51998>] ? linux_modem_open+0x45/0x10e [agrmodem]
 [<c102c857>] ? mod_timer+0xea/0xf3
 [<f8eabc0f>] ? modemPortOpen+0x5/0xe [agrmodem]
 [<f8155a6f>] ? serial8250_startup+0x74/0x250 [agrserial]
 [<c11a9348>] ? uart_startup+0x68/0xff
 [<c11a9acd>] ? uart_open+0x10b/0x302
 [<c119a53a>] ? tty_ldisc_setup+0x50/0x58
 [<c11969b9>] ? tty_init_dev+0x17c/0x1e9
 [<c1196d17>] ? tty_open+0x2f1/0x43e
 [<c1073ab0>] ? chrdev_open+0x11f/0x135
 [<c1073991>] ? chrdev_open+0x0/0x135
 [<c107041a>] ? __dentry_open+0x10c/0x1f0
 [<c107058e>] ? nameidata_to_filp+0x29/0x39
 [<c107a6d3>] ? do_filp_open+0x44b/0x82e
 [<c106028a>] ? __do_fault+0x301/0x331
 [<c10616be>] ? handle_mm_fault+0x238/0x4d6
 [<c108168d>] ? alloc_fd+0x52/0xb4
 [<c1070211>] ? do_sys_open+0x49/0xe7
 [<c10184ae>] ? do_page_fault+0x25f/0x275
 [<c10702f3>] ? sys_open+0x1e/0x23
 [<c1002694>] ? sysenter_do_call+0x12/0x26
Code: a5 00 00 89 44 24 08 8d 86 31 a5 00 00 89 44 24 04 c7 04 24 00 00 00 00 e8 63 57 01 00 85 c0 0f 84 71 02 00 00 8b 9e 14 a5 00 00 <c7> 03 01 00 00 00 c7 44 24 04 01 00 00 00 89 34 24 e8 f4 fe fe 
EIP: [<f8f6c9bb>] AzlDmaAllocation+0x81/0x2f9 [agrmodem] SS:ESP 0068:ece5bd0c
CR2: 0000000000000000
---[ end trace b84ea72f8dcf64c4 ]---
wlan0: deauthenticated from 94:44:52:0e:80:f3 (Reason: 3)
Let me know if there is anything else I can do to help you test....

Regards
peebee[/code]
ImageLxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

Agere HDA modem issue

#85 Post by rerwin »

peebee,
This agrsm-HDA thing is maddening, isn't it. I found a posting from a year ago (from someone else) describing the same problem, but with no responses to it. There is a new version of the driver out there, but I do not see any code change that would improve things. You can try it, but don't expect much. You can install it on top of what you have, or start fresh and use it instead of the HDA-HSF combo package.

I see your statements of a year ago about success with wary 060 or 070, or such. Where did all that end up? Does wary 5.12 work for you?

BTW, to keep this thread dedicated to providing drivers without the clutter of debugging conversations, we should take this discussion elsewhere. How about to your original thread on this subject?
http://www.murga-linux.com/puppy/viewto ... 455#322455
Richard
Last edited by rerwin on Fri 16 Sep 2011, 00:49, edited 1 time in total.

User avatar
rerwin
Posts: 2017
Joined: Wed 24 Aug 2005, 22:50
Location: Maine, USA

#86 Post by rerwin »

tempestuous wrote:Now open one of the "modprobe" configuration files, this will depend on which version of Puppy 5.x you have;
for older versions of Puppy it will be /etc/modprobe.conf
and for newer versions it will be /etc/modprobe.d/puppy.conf
The /etc/modprobe.d directory lets us avoid having multiple people maintaining the same file (e.g., puppy.conf, controlled by BK). Any additional module-specific configuration statements should go into separate .conf files named to identify the module(s) affected.

So, the line:
  • options ath9k override_eeprom_regdomain=value
might go into ath9k.conf. There are probably other naming schemes that would be good, but the point is to use separate .conf files where appropriate.
Richard

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#87 Post by PaulBx1 »

Tempestuous, still looking for a modification of your b43 post to take into account the /etc/modprobe.d arrangement in newer Puppies. I cannot see where to put those pio commands. I definitely need to use PIO because dmesg gives "This device does not support DMA on your system. Please use PIO instead." It also says, "ERROR: CONFIG_B43_FORCE_PIO must be set in your kernel configuration."

Anyone?

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#88 Post by tempestuous »

PaulBx1 wrote:It also says, "ERROR: CONFIG_B43_FORCE_PIO must be set in your kernel configuration."
I can't see where that kernel configuration can be set in the 2.6.33.2 kernel.
Are you really using Puppy 5.2.8? Could it be 529 or Wary?

I really need your full dmesg output. You can do this -

Code: Select all

cd /root
dmesg > dmesg.txt
gzip dmesg.txt
Now you will have a file in /root called "dmesg.txt.gz" which you can attach to the forum.
Last edited by tempestuous on Sat 17 Sep 2011, 06:01, edited 1 time in total.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#89 Post by PaulBx1 »

Well, I thought I was running 528. :) At least, in PUPSTATE it says "PUPSFS='sdb1,vfat,/lupu_528.sfs'". There is a 529? Sheesh, I can never keep up.

I too wondered about all those downloads. Did people try your fix, and it works most of the time? I did mention that your fix actually made it work for a short while on my machine. Maybe there is a timing issue or race condition that mostly works out OK? There does seem to be a lot of confusion and difficulty in the forum with this bcmxxxx hardware...

As to the message, doesn't that come from the driver, so it doesn't matter what kernel it is running under? I also thought it was strange the driver wouldn't just fall back to PIO automatically, with maybe a note to the log about it. Yes, I do want to get serious about diagnosing it. Here is the dmesg:
Attachments
dmesg.txt.gz
(8.02 KiB) Downloaded 612 times

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#90 Post by tempestuous »

PaulBx1, I have done some digging, and it appears that I need to recompile the b43 wifi driver with PIO mode explicitly (and permanently) enabled ...
... but in the meantime, I have a feeling that the standard b43 driver might "behave" better if it's reloaded after boot up. Pleas try this - once booted, run these two commands:

Code: Select all

rmmod b43
modprobe b43
Now run the "dmesg" command, and see if it looks more healthy - what I'm hoping is that you won't see this -

Code: Select all

b43-phy0 ERROR: This device does not support DMA on your system. Please use PIO instead.
If you do not see this error, then go ahead and run the Network Wizard, and hopefully you will get a successful connection.

But if the error remains, I will have a modified b43 driver shortly.

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#91 Post by tempestuous »

I made another discovery - the b43-firmware-LP-PHY dotpet package is wrong; it installs the firmware to the wrong location.
Please go ahead and try the driver reload experiment, but then we should try with the LP-PHY firmware - I have just sent you a PM with details.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#92 Post by PaulBx1 »

I tested as you said, just reloading the driver (with your old b43-firmware-LP-PHY still installed) after a fresh boot. Just reloading did not give me any more errors than there was from the boot. However after trying the network wizard to get a connection, it failed the scan and after that there was another error message in the log.

I then removed the old b43-firmware-LP-PHY and installed the new one. This produced exactly the same result. That is, removing and reloading b43 caused no more errors in dmesg, but attempting a scan of the network failed and did give a new error message.

I am attaching /var/log/messages instead of dmesg so you have the timestamps too. I will try a reboot just to be sure.

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#93 Post by tempestuous »

PaulBx1, I really need to see those logs.
PaulBx1 wrote:I am attaching /var/log/messages
The forum will only accept attachments with certain file extensions - so you will need to gzip the "messages" files before attaching them.
PaulBx1 wrote:just reloading the driver (with your old b43-firmware-LP-PHY still installed)
There's no need to worry about the old b43-firmware-LP-PHY files - they're in the wrong location, so will not be seen by the b43 driver, and will obviously have no effect.
PaulBx1 wrote:Just reloading did not give me any more errors than there was from the boot.
What I'm looking for is fewer errors - I'm hoping that the "PIO" error won't be there. If so, that's a win, and it means there's no need for me to compile a PIO-enabled version of the driver.
PaulBx1 wrote:I then removed the old b43-firmware-LP-PHY and installed the new one. This produced exactly the same result.
Again, I need more specific information - there will be a line "Loading firmware version xxx" - I need to know what that version number is, and I need to know the lines that immediately follow it.

We should not be overly concerned about the driver failing to scan - this does not necessarily define driver failure. Even without scanning, it's perfectly feasible to go ahead and specify your wifi access point details (SSID, encryption type, password) then connect.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#94 Post by PaulBx1 »

Sorry, I forgot to verify the attachment got across. Here it is, now two days worth of log I guess. Kind of a pain we are on opposite sides of the world, only get one shot a day at moving this forward. If you need a quicker turn-around let me know and I'll stay up all night.

Just to elaborate, if my previous post was not clear, loading the driver did not generate any errors. Only scanning did.

I had a profile set up for my access point, and at least the network wizard does a scan when connecting from a profile first thing. So to connect without a scan apparently means doing it with another tool or from the command line.
Attachments
messages.gz
(15.11 KiB) Downloaded 601 times

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#95 Post by tempestuous »

OK, I'm seeing similar results on 3 separate occasions. It seems that the LP-PHY firmware makes little or no difference to the behaviour of the b43 driver ... at least with your particular wifi device, anyway.

So I have compiled the PIO-enabled b43 driver, and to avoid spurious downloading I have sent you a PM with the download link.
After installing the dotpet, no need to reboot, just reload the driver -

Code: Select all

rmmod b43
modprobe b43
Run the Network Wizard.
Attach dmesg results if still problems.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#96 Post by PaulBx1 »

This does work! :) I'll post dmesg in any case:

Code: Select all

b43-phy1: Broadcom 4312 WLAN found (core revision 15)
b43-phy1 debug: Found PHY: Analog 6, Type 5, Revision 1
b43-phy1 debug: Found Radio: Manuf 0x17F, Version 0x2062, Revision 2
b43-phy1 debug: DebugFS (CONFIG_DEBUG_FS) not enabled in kernel config
phy1: Selected rate control algorithm 'minstrel'
Registered led device: b43-phy1::tx
Registered led device: b43-phy1::rx
Registered led device: b43-phy1::radio
Broadcom 43xx driver loaded [ Features: PML, Firmware-ID: FW13 ]
b43 ssb0:0: firmware: requesting b43/ucode15.fw
b43 ssb0:0: firmware: requesting b43/lp0initvals15.fw
b43 ssb0:0: firmware: requesting b43/lp0bsinitvals15.fw
b43-phy1: Loading firmware version 478.104 (2008-07-01 00:50:23)
b43-phy1 debug: b2062: Using crystal tab entry 19200 kHz.
b43-phy1 debug: Chip initialized
b43-phy1 debug: PIO initialized
b43-phy1 debug: QoS enabled
b43-phy1 debug: Wireless interface started
b43-phy1 debug: Adding Interface type 2
wlan0: direct probe to AP 00:1a:70:65:23:4a (try 1)
wlan0: direct probe to AP 00:1a:70:65:23:4a (try 1)
wlan0: direct probe responded
wlan0: authenticate with AP 00:1a:70:65:23:4a (try 1)
wlan0: authenticated
wlan0: associate with AP 00:1a:70:65:23:4a (try 1)
wlan0: RX AssocResp from 00:1a:70:65:23:4a (capab=0x411 status=0 aid=3)
wlan0: associated
Couple of things occur to me. First, if debug messages are turned on, the log might fill up, although the frequency of this occurrence might be very low so we don't have to worry...

It's weird to use PIO for this. Having the CPU involved in every byte transferred is crazy; we are talking about a crapload of data, and it is not a very powerful CPU in the first place. We were using DMA back in the '70's, it's not like that is something exotic. Set up a few registers and an interrupt, and let 'er rip. I'm getting DMA with ethernet, right?

Or is that device simply not wired to do DMA?

I'm curious what this driver looks like; could I see the source code? I used to write drivers ages ago...

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#97 Post by tempestuous »

PaulBx1, that's great.
There's just one thing I want to be check on - are you using the same installation as before, unchanged?
Because I understand that the current state of your installation is with the "LP-PHY" firmware installed, and if so, we should really check that you still have success with the "standard" firmware. This is easy to do; use ROX to rename the /lib/firmware/b43 directory to something different ("b43-LPY-PHY" would make sense)
then rename /lib/firmware/b43-original to /lib/firmware/b43
Now reload the b43 driver, or reboot.
Does it still work OK?

Regarding the source code, I have just sent you a PM with the download link. It's nothing special - it's the standard b43 source code from the 2.6.33.2 kernel source ... but with "B43_DEBUG" and "B43_FORCE_PIO" enabled.

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#98 Post by PaulBx1 »

Yes, it works with the original firmware. Thanks for getting this wireless going, it makes me much happier with this machine (as in, I no longer think it was a mistake to buy it!)

If I look at that driver and see something I want to try (to get DMA working), I will have to nag you to tell me how to build it. :) But don't worry, it may be forever before I get around to it, and maybe never if PIO doesn't ruin the performance. I'm still amazed PIO is even an option.

tempestuous
Posts: 5464
Joined: Fri 10 Jun 2005, 05:12
Location: Australia

#99 Post by tempestuous »

Thanks. I have just updated the Broadcom driver section on page 1 of this forum thread.

As an after-note to this exercise, I make these points:

- it's a shame that it took a full year after the release of Puppy 5.1.x before someone with your reporting ability was able to troubleshoot the b43 driver issue. At Sep 20 2011 there have been 755 downloads of the b43-LP-PHY firmware that I provided, and it's likely that most of the people who downloaded that firmware failed to fix their non-functioning b43 driver.

- in most cases where the b43 driver fails, a simple fix is to install the proprietary Broadcom wifi driver. PaulBx1, this would have been your easiest solution! Full points for your determination to stick with the opensource driver.

- the next release of Puppy Lucid is likely to be 5.2.9 with upgraded kernel, and the b43 driver problems are likely now solved with the introduction of the new brcmfmac/brcmsmac drivers - which have just been proven to work in Spup. The new driver is likely to appear in the next beta release of 529.
So we have fixed the Broadcom b43 driver problem too late in the release cycle!!

PaulBx1
Posts: 2312
Joined: Sat 17 Jun 2006, 03:11
Location: Wyoming, USA

#100 Post by PaulBx1 »

Well, as I said earlier I suspect the spotty reporting of problems may be because others don't see those problems. Even my netbook did have internet access for a day or so. Probably a race condition.

Post Reply