Extras for Puppy 4.3 with 2.6.30.5 kernel
eee-snd-hda-intel-patched
@tempestuous
Hope I have not missed it but have you complied a version of your eee-snd-hda-intel-patched-k2.6.25.16 (which I use in 412) but for the 2.6.30.5 kernel? The reason I ask is that I have problems (reported in the 431 bug thread) with ALSA on 431 in that there is no master slider in the alsamixer and the system tray volume icon does not work and in any case is always muted on a reboot. Others have also reported these problems as well. Just wondered if the patch would fix these problems?
Rgds Mike
Hope I have not missed it but have you complied a version of your eee-snd-hda-intel-patched-k2.6.25.16 (which I use in 412) but for the 2.6.30.5 kernel? The reason I ask is that I have problems (reported in the 431 bug thread) with ALSA on 431 in that there is no master slider in the alsamixer and the system tray volume icon does not work and in any case is always muted on a reboot. Others have also reported these problems as well. Just wondered if the patch would fix these problems?
Rgds Mike
Re: eee-snd-hda-intel-patched
Yeah i am having the exact same issues.mawebb88 wrote:@tempestuous
Hope I have not missed it but have you complied a version of your eee-snd-hda-intel-patched-k2.6.25.16 (which I use in 412) but for the 2.6.30.5 kernel? The reason I ask is that I have problems (reported in the 431 bug thread) with ALSA on 431 in that there is no master slider in the alsamixer and the system tray volume icon does not work and in any case is always muted on a reboot. Others have also reported these problems as well. Just wondered if the patch would fix these problems?
Rgds Mike
Fn keys for volume and mute dont work after i applied all pets from this thread, probley cuzz of the volume issues.
EeePc 900a
AP kernel support?
I want to use Puppy 4.3.0. everyday, but I can't because, as I read, this kernel doesn't support AP (access point) mode or it has to be activated in compiling.
My wifi cards (Atheros AR5BXB63 in both computers: one Extensa5620z, the other eeepc701) use ath5k in Puppy 4.3.0. and can't be AP as in 4.2.1 official one with madwifi-hal (no problems using ath5k with this kernel if machine is a client).
Please note that I need an "ad hoc" wlan because 3G mobile radio signal, my ISP, is only upstairs, but I need it downstairs, too.
Thanks in advance for help.
Bye.
My wifi cards (Atheros AR5BXB63 in both computers: one Extensa5620z, the other eeepc701) use ath5k in Puppy 4.3.0. and can't be AP as in 4.2.1 official one with madwifi-hal (no problems using ath5k with this kernel if machine is a client).
Please note that I need an "ad hoc" wlan because 3G mobile radio signal, my ISP, is only upstairs, but I need it downstairs, too.
Thanks in advance for help.
Bye.
[b][i][color=darkred][size=134]*.* Snow *.*[/size][/color][/i][/b] :wink:
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
mawebb88 and scabz, the patched version of the ALSA driver was only for older versions of ALSA, and was specifically to add support for the Eee internal microphone.
My understanding is that the more modern version of ALSA in Puppy 4.3 (v1.0.20) should support the internal mic, and the patch is irrelevant.
But if you are having audio problems, there's probably some other reason. It might simply be that ALSA v1.0.20 is not playing well with your device, and you may need to upgrade or downgrade to a different version.
My understanding is that the more modern version of ALSA in Puppy 4.3 (v1.0.20) should support the internal mic, and the patch is irrelevant.
But if you are having audio problems, there's probably some other reason. It might simply be that ALSA v1.0.20 is not playing well with your device, and you may need to upgrade or downgrade to a different version.
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
I presume you're referring to the ath5k wifi driver.magerlab wrote:strange but in puppy 4.3 with 30 kernel i have very slow speed with wifi connection
I see at linuxwireless -
http://linuxwireless.org/en/users/Drivers/ath5k
that the ath5k has problems with rate control, so you may need to force the driver to a higher rate, as such -
Code: Select all
iwconfig wlan0 rate 11M
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
Yes, the ath5k driver cannot be used in AP mode with kernel 2.6.30 ...Whitesnow wrote:I want to use Puppy 4.3.0. everyday, but I can't because, as I read, this kernel doesn't support AP (access point) mode
so you could install the MADWiFi (ath_pci) driver from earlier in this thread. The ath_pci driver supports AP mode, regardless of kernel version.
Be aware that ad-hoc mode is completely different to AP mode. I will post an ad-hoc HOWTO soon.Whitesnow wrote:Please note that I need an "ad hoc" wlan because 3G mobile radio signal, my ISP, is only upstairs, but I need it downstairs, too.
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
I just added a driver for the new Realtek RTL819x wifi devices, in the earlier post -
http://www.murga-linux.com/puppy/viewto ... 457#346457
http://www.murga-linux.com/puppy/viewto ... 457#346457
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
Regarding audio problems with Eee models, see the post I just made in
"ALSA configuration for Intel HD Audio"
http://www.murga-linux.com/puppy/viewto ... 603#354603
"ALSA configuration for Intel HD Audio"
http://www.murga-linux.com/puppy/viewto ... 603#354603
I didn't know. Thank you, I'll try.tempestuous wrote:you could install the MADWiFi (ath_pci) driver from earlier in this thread. The ath_pci driver supports AP mode, regardless of kernel version.
For ad-hoc net I mean two PC linked by wifi without a DHCP server. IPs set manually. If I don't set one of these computers as AP, I can't link.tempestuous wrote:Be aware that ad-hoc mode is completely different to AP mode. I will post an ad-hoc HOWTO soon.
Formally, I know you right.
OT: I have download 4.3.1, but I have seen that bootmanager, like 4.3.0., can still boot not more than 6 sfs and cannot find kernel src mirrored (virtualbox refuses to run without).
Someone can indicate me where I can find information about these topics?
[b][i][color=darkred][size=134]*.* Snow *.*[/size][/color][/i][/b] :wink:
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
That's not ad-hoc. It's a situation where one of your computers is an access point (wifi master mode) and the other computer is a conventional client (wifi station mode).Whitesnow wrote:For ad-hoc net I mean two PC linked by wifi without a DHCP server. IPs set manually. If I don't set one of these computers as AP, I can't link.
In ad-hoc mode, both computers are equal peers. I just posted an ad-hoc HOWTO here -
http://www.murga-linux.com/puppy/viewto ... 929#159929
The 2.6.30.5 kernel has Atheros drivers atl1c and atl1e, but some atheros cards will not work with the default driver, notably the EEE 1005HA, and possibly others. I've attached a pet file of the manufacturer's driver, downloaded from the Atheros site. http://partner.atheros.com/Drivers.aspx
Edit: I've uploaded a new version of 1.0.0.10 and added 1.0.0.11-test. It's been mentioned to me that the test version is required for some newer cards; it seems more stable on my machine as well.
Edit: updated both pets for bug tempestuous found
Edit: 12/29/09 updated both pets to include preflist hotfix
Edit: I've uploaded a new version of 1.0.0.10 and added 1.0.0.11-test. It's been mentioned to me that the test version is required for some newer cards; it seems more stable on my machine as well.
Edit: updated both pets for bug tempestuous found
Edit: 12/29/09 updated both pets to include preflist hotfix
- Attachments
-
- atl1e-1.0.0.11-test.pet
- (34.81 KiB) Downloaded 1360 times
-
- atl1e-1.0.0.10.pet
- (34.63 KiB) Downloaded 1349 times
Last edited by jemimah on Tue 29 Dec 2009, 15:41, edited 3 times in total.
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
EDIT November 17 2010
Latest Atheros/Attansic atl1e ethernet driver now available later in this thread -
http://www.murga-linux.com/puppy/viewto ... 846#467846
EDIT Dec 30 2009
jemimah's atl1e dotpets in the previous post compete with the standard atl1c driver in Puppy 4.3.x
so you must also install the modules-preference fix from here -
http://www.murga-linux.com/puppy/viewto ... 659#371659
(as mentioned in the first post in this thread)
Latest Atheros/Attansic atl1e ethernet driver now available later in this thread -
http://www.murga-linux.com/puppy/viewto ... 846#467846
EDIT Dec 30 2009
jemimah's atl1e dotpets in the previous post compete with the standard atl1c driver in Puppy 4.3.x
so you must also install the modules-preference fix from here -
http://www.murga-linux.com/puppy/viewto ... 659#371659
(as mentioned in the first post in this thread)
Last edited by tempestuous on Wed 17 Nov 2010, 00:58, edited 2 times in total.
Thanks, I had been meaning to update that pet as some people had troubles with it. There's also a newer 1.0.0.11-test version should probably be packaged. I'll post a new pet when I get a chance.
Although, the atl1c driver will try to load on my ethernet card, so adding it to the preflist will probably prevent the correct atl1e driver from loading.
Although, the atl1c driver will try to load on my ethernet card, so adding it to the preflist will probably prevent the correct atl1e driver from loading.
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
When configured properly, the PREFLIST (which is referenced by Puppy's version of udev) sets the preference/priority of one module over another.jemimah wrote:the atl1c driver will try to load on my ethernet card, so adding it to the preflist will probably prevent the correct atl1e driver from loading.
Ok, I just did a test with the standard kernel. On my hardware, the old atl1c driver loads, but it's the wrong driver and will not work; dhcp fails to obtain an IP. When I install the new atl1e driver pet, the old atl1c driver continues to load. If I add atl1c:atl1e to the preflist, atl1c still loads. If I blacklist atl1c, then neither driver loads. So the only way it works is if if I add atl1e to the whitelist and add atl1c to the blacklist. Hope that clarifies things. YMMV on different hardware.
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
Then PREFLIST (or udev/pup_event) is not working as designed. This, then, is a bug and should probably be reported to Barry.jemimah wrote:If I add atl1c:atl1e to the preflist, atl1c still loads.
This situation might explain a few other problems reported on the forum involving conflicting modules.
EDIT:
I just reported this in the "Puppy 4.3.1 -- bug reports and suggestions" thread.
tempestuous, jemimah,
Could you re-run your original attempt to set the preference (with no atl1? added or blacklist entries)? But please do not edit any files for this -- use the BootManager to set the preference and be sure the two names are separated only by a colon and no spaces. Once rebooted, please tell me which atl1? lsmod shows as loaded, what the /etc/rc.d/MODULESCONFIG file has for the PREFLIST= data, and whether the /etc/modprobe.conf file contains an entry: "blacklist atl1c" near the end. Also, please save and then attach file /tmp/udevtrace.log to your posting. Then reboot again to see if the preference is fulfilled. (The idea is that maybe the blacklist entry is only added on the first reboot, so is not effective the first time; when present, there might be different behavior.) The udevtrace file might be interesting at that point, too.
To address your concern that by setting the preference you would be unable to use another NIC that takes the old atl!c module, there is a way to specify the preference for only certain hardware IDs. That fix would be to edit-add two items to the "PCI_OVERRIDES=" variable in /etc/rc.d/MODULESCONFIG, as:
atl1e 0x00001969 0x00001062
atl1e 0x00001969 0x00001063
This assumes that the NIC is not USB and that the override will always be valid for those NICs -- at least until the drivers change further.
But I am really concerned about the appearance that the preference listing in not effective. If the information I requested above is indeed present/correct, I will need to provide a "wired" version of the pup_event script to see where things go wrong. But first we need to verify that the preference was entered correctly when it failed.
Richard
Since I am already modifying pup_event_backend_modprobe, I would like to include a fix for this problem in my updated version.Then PREFLIST (or udev/pup_event) is not working as designed. This, then, is a bug and should probably be reported to Barry.
Could you re-run your original attempt to set the preference (with no atl1? added or blacklist entries)? But please do not edit any files for this -- use the BootManager to set the preference and be sure the two names are separated only by a colon and no spaces. Once rebooted, please tell me which atl1? lsmod shows as loaded, what the /etc/rc.d/MODULESCONFIG file has for the PREFLIST= data, and whether the /etc/modprobe.conf file contains an entry: "blacklist atl1c" near the end. Also, please save and then attach file /tmp/udevtrace.log to your posting. Then reboot again to see if the preference is fulfilled. (The idea is that maybe the blacklist entry is only added on the first reboot, so is not effective the first time; when present, there might be different behavior.) The udevtrace file might be interesting at that point, too.
To address your concern that by setting the preference you would be unable to use another NIC that takes the old atl!c module, there is a way to specify the preference for only certain hardware IDs. That fix would be to edit-add two items to the "PCI_OVERRIDES=" variable in /etc/rc.d/MODULESCONFIG, as:
atl1e 0x00001969 0x00001062
atl1e 0x00001969 0x00001063
This assumes that the NIC is not USB and that the override will always be valid for those NICs -- at least until the drivers change further.
But I am really concerned about the appearance that the preference listing in not effective. If the information I requested above is indeed present/correct, I will need to provide a "wired" version of the pup_event script to see where things go wrong. But first we need to verify that the preference was entered correctly when it failed.
Richard