Drivers for Puppy 5.1-5.2.8 with 2.6.33.2 kernel
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
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.
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.
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
PaulBx1, I really need to see those logs.
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.
The forum will only accept attachments with certain file extensions - so you will need to gzip the "messages" files before attaching them.PaulBx1 wrote:I am attaching /var/log/messages
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 the driver (with your old b43-firmware-LP-PHY still installed)
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:Just reloading did not give me any more errors than there was from the boot.
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.PaulBx1 wrote:I then removed the old b43-firmware-LP-PHY and installed the new one. This produced exactly the same result.
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.
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.
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 603 times
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
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 -
Run the Network Wizard.
Attach dmesg results if still problems.
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
Attach dmesg results if still problems.
This does work! I'll post dmesg in any case:
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...
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
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...
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
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.
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.
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.
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.
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
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!!
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!!
-
- Posts: 30
- Joined: Sun 07 Aug 2011, 17:13
I took your idea, and compiled the XHCI on a Macpup 5.2.8 ( it's based on puppy 5.2.8 without the 001 update ) with kernel 2.6.33.2 as this post relates.tempestuous wrote:Here is the USB 3.0 Linux driver, which was not enabled in the standard Puppy 5.1.x kernel.
The driver is called xhci
I have also included the upgraded isp1760 USB driver, which is apparently USB 3.0 compatible, though very few Puppy users will ever use this driver because the relevant interface is found on embedded devices.
After installing this dotpet, reboot, and the xhci driver should automatically load for any compatible interface detected at boot up.
Then I packed ONLY the XHCI.KO driver file and added to the install script the following command that you've missed: "modeprobe xhci" in order to enable immidiatly the driver after it is installed.
I have USB 3.0 PCI-Express card (54mm), and this driver woke it up alive !
( apparently Puppy has "PCI-E host card module" driver already installed, which also needed to run this type of card )
P.S - As tempestuous wrote, just to be sure, after the installation process - REBOOT !
- Attachments
-
- USB3_XHCI_Driver_Support.pet
- (21 KiB) Downloaded 639 times
Last edited by night_mare007 on Thu 22 Sep 2011, 19:03, edited 1 time in total.
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
When posting additional drivers in this thread, I consider it a practice fraught with risk to manually load the new driver as part of the installation process. Instead, I usually advise users to reboot, since this takes Puppy through the full auto-detection process, and they can then know for sure whether the new driver will auto-load.night_mare007 wrote:... and added to the install script the following command that you've missed: "modeprobe xhci" in order to enable immidiatly the driver after it is installed.
In that regard, and for good reason, I didn't "miss" a manual load command as part of the installer package.
In the earlier post in question, I wrote this:
I know this to be true, in theory, because when I query the driver, it returns this:tempestuous wrote:After installing this dotpet, reboot, and the xhci driver should automatically load for any compatible interface detected at boot up.
Code: Select all
alias: pci:v*d*sv*sd*bc0Csc03i30*
That's a far more serious (and relevant) issue, and if true, affected users should have reported this.
-
- Posts: 30
- Joined: Sun 07 Aug 2011, 17:13
You got me me wrong...tempestuous wrote:So are you saying that the xhci driver is not automatically loaded at boot up?
Just to be sure I made a restart and just after the puppy completely logged in I plugged in a usb-flash-card, and after 3-4 sec the flashcard started to blink as it should.
Then I opened Pmount - and the device was recognized correctly, as well as mounting and ROXing R/W commands.
So IT DOES AUTO LOAD and work as expected.
P.S
Pardon me if what I wrote sound a bit like I criticize your work...
it was not my intentions.
You gave me the final solution and extractions about how to install the .KO driver. - so THANKS !
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
-
- Posts: 2
- Joined: Fri 16 Mar 2007, 20:23
Puppy 5.2.8 2.6.33.2 RT5370 woes
Loaded pet for the RT5370 on my puppy distro 5.2.8 kernel 2.6.33.2. Tried WPA and WPA2 encryption. Driver loads fine, sees device as RA0 as it should. Sees my ssid and connects, receives the proper dhcp supplied IP address (also tried static) . Testing by pinging website.com and it will resolve to the proper IP address. When I try to open any browser it does not go to any web page. The device itself is fine as ive used it on an ubuntu 11.04 laptop. Ive tried to statically assign dns servers and that doesnt seem to make a difference. Ping times although work sometimes have erratic ping responses IE 200ms,150ms,1900ms,2500ms 50ms and so on.
Please throw this puppy a knowledge bone?
Please throw this puppy a knowledge bone?
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
The cdc-acm driver in Puppy 5.1.x recognises 43 different Nokia phone device ID's.
Using the 2.6.39 kernel source as a reference, I have just patched this driver to recognise an additional 14 Nokia telephone models. This updated driver should now be suitable for the two specific requests on the forum to date:
Nokia N8 - forum member Dave_G
Nokia C5 - forum member rameshiyer
Plug in your phone after you have installed this dotpet, and the new cdc-acm driver should load automatically.
EDIT:
Your phone must be set to the correct mode. A forum user with recent model Nokia C5 reported that the mode-options in the phone's menu are:
1. PC Suite
2. Mass Storage
3. Image Transfer
4. Media Transfer
5. PC to Web
The PC to Web setting failed, but the PC Suite setting was successful.
Using the 2.6.39 kernel source as a reference, I have just patched this driver to recognise an additional 14 Nokia telephone models. This updated driver should now be suitable for the two specific requests on the forum to date:
Nokia N8 - forum member Dave_G
Nokia C5 - forum member rameshiyer
Plug in your phone after you have installed this dotpet, and the new cdc-acm driver should load automatically.
EDIT:
Your phone must be set to the correct mode. A forum user with recent model Nokia C5 reported that the mode-options in the phone's menu are:
1. PC Suite
2. Mass Storage
3. Image Transfer
4. Media Transfer
5. PC to Web
The PC to Web setting failed, but the PC Suite setting was successful.
- Attachments
-
- cdc-acm-update-k2.6.33.2.pet
- for Puppy 5.1 - 5.2.8
- (10.62 KiB) Downloaded 1216 times
Last edited by tempestuous on Thu 03 Nov 2011, 11:10, edited 1 time in total.
Nokia Connection
Dear Sir
Thank you very much. I will try with your pet and let you know the status. Anyway thank you very much for extending your knowledge with me.
Thank you very much. I will try with your pet and let you know the status. Anyway thank you very much for extending your knowledge with me.
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
Well I just compiled the AMD/ATI Catalyst 11.10 graphics driver ... but I see it's not necessary -Hammerknight wrote:Drivers for ATI RADEON 9200 pro
playdayz already provided version 10.10 here -
http://www.murga-linux.com/puppy/viewto ... 993#467993
I'm talking about Puppy Lucid 5.1 - 5.2.8, of course.
I'm glad you did. I have been meaning to do it myself. It is not necessary for the 9200 but it should cover any brand new ATI cards. Could you provide a link and I will post it. Thanks.I just compiled the AMD/ATI Catalyst 11.10 graphics driver but I see it's not necessary -
playdayz already provided version 10.10 here -
http://www.murga-linux.com/puppy/viewto ... 993#467993
I'm talking about Puppy Lucid 5.1 - 5.2.8, of course.
In Lucid, users can also get the ati and nvidia proprietary drivers as well as the open source glx driver (Xorg_High) in Quickpet -> Drivers.