Bug#797779: brcmfmac4330-sdio.txt from OpenElec fixes the issue
Hi On 2015-09-02, Rainer Dorsch wrote: > Hi, > > I copied brcmfmac4330-sdio.txt from OpenElec > > https://github.com/OpenELEC/wlan-firmware/blob/master/firmware/brcm/brcmfmac4330-sdio.txt > > to /lib/firmware/brcm > > which fixes the issue [...] brcmfmac4330-sdio.txt is OEM, respectively even device specific[1], nothing that would be generic enough (for all bcm4330 devices) to be shipped by Debian's firmware packages. On x86 systems this blob is typically provided in a UEFI variable (but not found automatically by the kernel, so you need to copy it from the UEFI variable to /lib/firmware). On embedded devices it needs to be provided by the manufacturer (not Broadcom, but the OEM vendor) of your wlan card (respectively the devboard). Regards Stefan Lippers-Hollmann [1] These blobs contain calibration data, regulatory domain settings and similar information, which is highly specific to your exact device. Using data from a different device would make it run out of its specifications (getting you in trouble with FCC, ETSI, etc.) and could even physically damage your device. pgpZZ7tpUCJd3.pgp Description: Digitale Signatur von OpenPGP
Bug#797779: brcmfmac4330-sdio.txt from OpenElec fixes the issue
Hi
On 2015-09-02, Rainer Dorsch wrote:
> Hi Stefan,
>
> I copied the debian-arm list, because this should be an issue which is
> present
> on almost any ARM based SoC and there might exist solutions for other SoCs
> already.
It's not really arm specific, as this particular SDIO based wlan chipset
is used on multiple architectures (including many windows 8.x based Intel
Atom tablets).
> On Wednesday 02 September 2015 19:37:13 Stefan Lippers-Hollmann wrote:
> > On 2015-09-02, Rainer Dorsch wrote:
[...]
> Are you saying that I opened the bugreport against the wrong package or that
> this is not a bug at all?
As far as I see it, this is not a /software/ bug and not actionable
from within Debian, the data blob in question can only be provided
by the OEM/ systems integrator manufacturing the devboard or the
vendor producing the wlan card in question (e.g. AMPAK for the AP6120
wlan/ BT daughterboard using the Broadcom BCM4329 SDIO chipset found
on many armhf devboards). It is calibration data for your particular
wlan card and not a generic firmware image.
At best (and this is pretty questionable as well) you could create a
dedicated firmware image providing brcmfmac4329-sdio.txt for each
particular devboard, conflicting with all other providers of this
file.
If I were the Debian maintainer for firmware-brcm80211, I'd see no
other option than to close this bug - likewise I don't think that it
can be re-assigned to any other package in Debian.
On more traditional PCI/ PCIe or USB wlan cards, this type of
calibration data is typically stored in a small EEPROM chip, together
with the device's MAC address, but in the embedded space, vendors try
to save the last cent and reuse other kinds of (independent) storage.
- on x86 Atom Baytrail-T tablets (many of which use this exact,
bcm4329, wlan chipset), this calibration data is usually stored in
the mainboard firmware (vulgo BIOS) and exposed to the Windows driver
as UEFI (nvram-) variable; brcmfmac does not look there on its own.
- on Atheros based (mips) routers, the calibration data usually goes
into a dedicated mtd partition of the main flash ("ART", aka Atheros
Radio Test), here it is unique (based on the OEM calibration) to each
specific router (or at least small batches of the production).
- on most armhf devices originally shipping with Android, it is usually
presented as firmware file shipped in the original Android system
partition (e.g. /system/etc/wifi/nvram_net.txt) and then used by the
bcmhd driver on Android, respectively its mainline counterpart and
successor brcmfmac via /lib/firmware/brcm/brcmfmac4329-sdio.txt.
you need to extract /system/etc/wifi/nvram_net.txt from your original
Android image and copy it to /lib/firmware/brcm/brcmfmac4329-sdio.txt
or ask the manufacturer of your board for it.
> Doesn't on an ARM system the device tree file contain embedded device
> specific
> information, which is shipped with the kernel itself? And would this txt file
> not fit perfectly in this category of information?
I'm not a specialist on device tree syntax, but I'd guess that it's a
bit too much information to be injected via DT.
> How is this issue addressed for other ARM SoCs?
Many ARM devboards go a simpler route, by simply using a USB based
daughterboard (which includes all these implementation details in an
EEPROM of the USB daughterboard itself). Android smartphones, which
are more likely to use SDIO based wlan cards (and bcmhd as its driver),
store it as /system/etc/wifi/nvram_net.txt and alternative firmwares
either need to take care of not overwriting it, or to ship it
themselves.
The few devboards using SDIO based BCM4329 wlan cards either provide
nvram_net.txt/ brcmfmac4329-sdio.txt somewhere (which is specific to
their particular device, respectively production batch) or punt the
task of extracting it from the original Android based firmware to the
user.
See the situation for x86 tablets and mips routers above.
Regards
Stefan Lippers-Hollmann
pgpLmLgIe1bOH.pgp
Description: Digitale Signatur von OpenPGP
Re: Bug#760712: WEP vs WPA2
packages, both look identical… linux-image-3.16-1-amd64_3.16.2-3_amd64.deb kernel-image-3.16-1-amd64-di_3.16.2-3_amd64.udeb so that might be something different anyway. This is less of a configuration (as in kernel .config) problem, but more likely to be caused by some (newly) required kernel modules providing the functionality for wpa modes missing from the udebs for d-i. Taking a simple mac80211 based wlan card (ar5523, USB) as example, forced into wext mode mode, I see these wireless modules as required for wpa2-psk/ ccmp - this is not using the Debian kernel, which might be slightly less modular: plugging in ar5523, unconfigured: + arc4 + ar5523 (well, this is the particular module only require for ar5523) + mac80211 + cfg80211 + rfkill after starting wpa_supplicant in (forced) wext mode: + ctr + ccm + af_packet For ath9k, the required module needed on top of the ones above seam to be (less reliably, as I can't hotplug PCIe): + ath9k + ath9k_common + ath9k_hw + ath Depending on your particular wlan card and how its driver is divided into sub-modules (or how well it is integrated into other kernel subsystems), you might need additional modules as well. [with my wpa maintainer hat on] Semi-related, I have a pending upload for wpa (wpasupplicant-udeb), can you give me a rough guide when it's safe to upload in order not to interfere with d-i beta2[6]? There are no behavioural changes, besides many bugfixes[7]. If you want to test it for d-i, the packaging is ready (besides the changelog entries) in the normal VCS location[8]. Regards Stefan Lippers-Hollmann [1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/feature-removal-schedule.txt?id=v3.6#n422 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=683281#10 [4] https://dev.openwrt.org/browser/trunk/package/network/utils/iwinfo it only needs trivial modifications to the buildsystem to work in Debian. A pure nl80211 example implementation would be found in iw. [6] https://lists.debian.org/debian-cd/2014/09/msg00027.html Subject: (Almost) Time for Jessie Beta 2? [7] probably particularly important to eduroam setups, although this particular configuration isn't supported by netcfg and can only be used in a full installation [8] Vcs-Browser: http://anonscm.debian.org/viewvc/pkg-wpa/wpa/trunk/ Vcs-Svn: svn://anonscm.debian.org/pkg-wpa/wpa/trunk/ http://aptosid.com/slh/wpa/wpa_2.2-0~svnr1884.0.dsc http://aptosid.com/slh/wpa/wpa_2.2-0~svnr1884.0.debian.tar.xz http://aptosid.com/slh/wpa/wpa_2.2.orig.tar.xz signature.asc Description: This is a digitally signed message part.
Re: Bug#760712: WEP vs WPA2
Hi On Monday 15 September 2014, Cyril Brulebois wrote: Stefan Lippers-Hollmann s@gmx.de (2014-09-15): [...] Seeing that the actual problem are missing kernel modules for CCMP (AES), and probably TKIP as well, I'll concentrate on your new questions only Based on your answer, I'm wondering whether there might be some CONFIG_* differences between wpasupplicant and its udeb, which might explain? There are significant CONFIG_* differences between the regular wpasupplicant and wpasupplicant-udeb, both to get it smaller and to avoid dependencies on packages not providing udebs, but the udeb should support: - no encryption - WEP64 - WEP128 - WPAPSK v1 TKIP/ CCMP - WPAPSK2 TKIP/ CCMP More advanced setups, like IEEE8021X (using certificates and per-user encryption, e.g. eduroam and other commercial setups), smartcards and are not supported by the udeb (nor would netcfg know how to configure these). [ o.k., the following three paragraphs have been obsoleted by your other mail ] |As a quick test I have bind-mounted the wpa_supplicant binary from |wpasupplicant-udeb over /sbin/wpa_supplicant of a full installation |and successfully tested: | |# wpa_supplicant -iwlan0 -c/etc/wpa_supplicant/wpa_supplicant.conf |Successfully initialized wpa_supplicant |wlan0: CTRL-EVENT-SCAN-STARTED |wlan0: SME: Trying to authenticate with 01:23:45:67:89:ab (SSID='test' freq=2472 MHz) |wlan0: Trying to associate with 01:23:45:67:89:ab (SSID='test' freq=2472 MHz) |wlan0: Associated with 01:23:45:67:89:ab |wlan0: WPA: Key negotiation completed with 01:23:45:67:89:ab [PTK=CCMP GTK=CCMP] |wlan0: CTRL-EVENT-CONNECTED - Connection to 01:23:45:67:89:ab completed [id=4 id_str=test_aes] |wlan0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=DE |wlan0: WPA: Group rekeying completed with 01:23:45:67:89:ab [GTK=CCMP] | |# wpa_cli status |Selected interface 'wlan0' |bssid=01:23:45:67:89:ab |ssid=test |id=4 |id_str=test_aes |mode=station |pairwise_cipher=CCMP |group_cipher=CCMP |key_mgmt=WPA2-PSK |wpa_state=COMPLETED |ip_address=10.20.27.0 |address=ba:98:76:54:43:21 | |This is 802.11bgn, using WPA2PSK and CCMP (AES) encryption with an |Atheros AR9285 (ath9k) wlan card, so relatively comparable to the |original submitter (while I have rtl8192du, I currently don't have |access to any wlan card supported by rtl8192cu). Accordingly the udeb |config for wpasupplicant (at least on linux) should be fine. This reminds me, without regulatory domain support (iw(semi-optional), crda, wireless-regdb) only the channels allowed for world-roaming (slightly depending on what the individual wlan drivers and firmwares understand under world-roaming) would be available, which means channel 1-11 (no access to 12/13) and very little, if anything, in the 5 GHz band. [...] [with my wpa maintainer hat on] Semi-related, I have a pending upload for wpa (wpasupplicant-udeb), can you give me a rough guide when it's safe to upload in order not to interfere with d-i beta2[6]? There are no behavioural changes, besides many bugfixes[7]. If you want to test it for d-i, the packaging is ready (besides the changelog entries) in the normal VCS location[8]. Well currently, as far as I can see/test, WPA support in d-i isn't exactly working nicely, so I don't think a wpa upload is going to hurt much. Quite the contrary, hopefully. Thanks, I'll do some final testing (and add CONFIG_DEBUG_SYSLOG=y, as requested in your other mail) and will try to get the new version sponsored quickly. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#756207: postinst requires perl-modules but doesn't depend on it
Package: src:linux Version: 3.14.13-2 Severity: normal linux-image-$KVER's postinst requires perl-modules (use File::stat;), but only perl-base is essential, accordingly the postinst fails in a minimal environment: # cdebootstrap --arch=amd64 --flavour=minimal sid /mnt/ http://ftp.debian.org/debian/ # chroot /mnt/ /bin/bash # apt update # apt install linux-image-3.14-2-amd64 Setting up linux-image-3.14-2-amd64 (3.14.13-2) ... debconf: unable to initialize frontend: Dialog debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.) debconf: falling back to frontend: Readline debconf: unable to initialize frontend: Readline debconf: (Can't locate Term/ReadLine.pm in @INC (you may need to install the Term::ReadLine module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at /usr/share/perl5/Debconf/FrontEnd/Readline.pm line 7.) debconf: falling back to frontend: Teletype Can't locate File/stat.pm in @INC (you may need to install the File::stat module) (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at /var/lib/dpkg/info/linux-image-3.14-2-amd64.postinst line 8. BEGIN failed--compilation aborted at /var/lib/dpkg/info/linux-image-3.14-2-amd64.postinst line 8. dpkg: error processing package linux-image-3.14-2-amd64 (--configure): subprocess installed post-installation script returned error exit status 2 Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Re: Bug#710686: base: Wireless card stops working out of nothing.
Hi On Sunday 16 June 2013, Ben Hutchings wrote: On Sun, 2013-06-16 at 09:44 +0200, Holger Levsen wrote: reassign 710686 firmware-atheros thanks How wid you decide that? Besides this clearly not being a firmware issue, ath5k doesn't use any to begin with, I'd be quite confident to call this a hardware issue. Based on my own experience with the very similar Acer Aspire One 110L (which uses an identical chassis), the rfkill slide switch is mechanically extremely fragile and misfires easily when looking at it (or slightly bumping the netbook anywhere). It may help to physically lock the rfkill switch in its ON-position, to prevent vibrations from triggering it accidentally. Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201306161730.31840.s@gmx.de
Bug#701777: please enable AR5523 for kernel = 3.8
Control: found -1 3.8.12-1 Control: found 700826 0.38 Hi On Wednesday 27 February 2013, Stefan Lippers-Hollmann wrote: […] Please enable the ar5523 kernel module for kernel = 3.8, it is needed for the QCA Atheros AR5005UG (USB 2.0, IEEE802.11G/ Turbo G) wlan chipset. Popular devices using this chipset are early revisions of Netgear WG111T, WG111U, WPN111 and the TP-Link TL-WN620G, which were commonly sold between late 2004 and mid 2009. Please consider that this kernel module requires a redistributable, but non-free binary firmware, see http://bugs.debian.org/700826 Please enable ar5523 for kernel 3.8+. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#701777: please enable AR5523 for kernel = 3.8
) [ 2264.762884] cfg80211: (515 KHz - 525 KHz @ 4 KHz), (N/A, 2000 mBm) [ 2264.762889] cfg80211: (525 KHz - 535 KHz @ 4 KHz), (N/A, 2000 mBm) [ 2264.762894] cfg80211: (547 KHz - 5725000 KHz @ 4 KHz), (N/A, 2698 mBm) Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#700826: please add ar5523.bin to firmware-atheros
[ 2210.491402] usb 2-7: Cap: CAP_TWICE_ANTENNAGAIN_5G=0x0001 [ 2210.491768] usb 2-7: Cap: CAP_TWICE_ANTENNAGAIN_2G=0x0004 [ 2210.492049] usb 2-7: Cap: CAP_CIPHER_AES_CCM=0x0001 [ 2210.492403] usb 2-7: Cap: CAP_CIPHER_TKIP=0x [ 2210.492645] usb 2-7: Cap: CAP_MIC_TKIP=0x [ 2210.493402] usb 2-7: MAC/BBP AR5523, RF AR2112 [ 2210.494079] usb 2-7: Found and initialized AR5523 device [ 2227.819108] IPv6: ADDRCONF(NETDEV_UP): wlan1: link is not ready [ 2264.734197] wlan1: authenticate with [MAC address redacted] [ 2264.737737] wlan1: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded [ 2264.742985] wlan1: send auth to [MAC address redacted] (try 1/3) [ 2264.745102] wlan1: authenticated [ 2264.746054] wlan1: associate with [MAC address redacted] (try 1/3) [ 2264.750097] wlan1: RX AssocResp from [MAC address redacted] (capab=0x411 status=0 aid=1) [ 2264.751084] wlan1: associated [ 2264.751145] IPv6: ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready [ 2264.751265] cfg80211: Calling CRDA for country: DE [ 2264.762834] ath: regdomain 0x8114 updated by CountryIE [ 2264.762844] ath: EEPROM regdomain: 0x8114 [ 2264.762848] ath: EEPROM indicates we should expect a country code [ 2264.762853] ath: doing EEPROM country-regdmn map search [ 2264.762857] ath: country maps to regdmn code: 0x37 [ 2264.762861] ath: Country alpha2 being used: DE [ 2264.762865] ath: Regpair used: 0x37 [ 2264.762870] cfg80211: Regulatory domain changed to country: DE [ 2264.762874] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 2264.762879] cfg80211: (240 KHz - 2483500 KHz @ 4 KHz), (N/A, 2000 mBm) [ 2264.762884] cfg80211: (515 KHz - 525 KHz @ 4 KHz), (N/A, 2000 mBm) [ 2264.762889] cfg80211: (525 KHz - 535 KHz @ 4 KHz), (N/A, 2000 mBm) [ 2264.762894] cfg80211: (547 KHz - 5725000 KHz @ 4 KHz), (N/A, 2698 mBm) Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#635840: carl9170 firmware missing from debian
Hi On Monday 14 January 2013, Ben Hutchings wrote: On Tue, 2012-09-04 at 10:07 +0300, Riku Voipio wrote: Hi, This is sad, someone actually releases their wireless card firmware under GPL and we fail to get it included in Debian. Way to encourage manufacturers to open source their firmwares and end users to buy hardware with open firmware... This is quite classic case where perfect has beome the enemy of good. Could we just put the binary firmware file linux-wireless website[1],[2] to firmware-linux-free for now, and do the build-from-sources firmware for Jessie if if deemed neccesary? I don't believe it's absolutely necessary to build from sources during the package build, and indeed none of the other free firmware images are rebuilt. The problem has been that I couldn't quite reproduce the binary and the person submitting the firmware for linux-firmware.git didn't respond to my request for information. I haven't checked the current binary versions, but previously default settings and making sure to use similar (cross-)toolchain versions achieved bit-identical results. Anyway, I had another look and worked out the undocumented build steps and I can now build a bit-identical firmware image, so I'm going to add it. As mentioned in [1], I'd be willing to maintain or co-maintain a firmware packages for carl9170, but this would need coordination (and an ack) from you (as linux-firmware maintainer) and the kernel-team, given that driver and firmware are both under development (and require minimum versions of each). My preliminary packaging[2] (which I'm using personally for quite a while) does build the cross-toolchain from Debian's source packages for gcc/ newlib/ binutils during the package build process[3]. This procedure is certainly not nice and needs adapting whenever gcc changes (minor) versions, but it does build everything from source - adding a formal sh-2/ newlib based cross-toolchain would imho be overkill, especially as this wouldn't be useful for anything else. Regards Stefan Lippers-Hollmann [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=635840#40 [2] Vcs-Svn: svn://svn.berlios.de/fullstory/firmware-carl9170/trunk/ Vcs-Browser: http://svn.berlios.de/wsvn/fullstory/firmware-carl9170/trunk/ http://aptosid.com/slh/carl9170/ using build concurrency is recommended, as this significantly reduces the build time for the cross toolchain. [3] http://aptosid.com/slh/carl9170/_build.log.gz -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201301141833.28185.s@gmx.de
Bug#696664: uapi/asm-generic missing from linux-headers-3.7
Hi On Wednesday 26 December 2012, Evgeni Golov wrote: […] tp-smapi builds fine for me then, virtualbox needs some love, but that is 3.7 related (error: ‘VM_RESERVED’ undeclared (first use in this function)). I've supplied the patches needed for virtualbox in #696011, http://bugs.debian.org/696011 Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
please add support for the IguanaWorks USB IR Transceiver
retitle 524403 please add support for the IguanaWorks USB IR Transceiver reassign 524403 src:linux found 524403 3.6.4-1~experimental.1 tags 524403 + patch thanks Hi On Wednesday 01 August 2012, Stefan Lippers-Hollmann wrote: Hi Today this patch has been merged into the linux kernel (3.6.0~rc0): commit 26ff63137c45886169ed102bddd6e90d6c27f00d Author: Sean Young s...@mess.org Date: Sun Jul 15 13:31:00 2012 -0300 [media] Add support for the IguanaWorks USB IR Transceiver Signed-off-by: Sean Young s...@mess.org Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=26ff63137c45886169ed102bddd6e90d6c27f00d While I can not confirm if, or how well it works (no IguanIR hardware), I'd suggest to give it a try and discuss success/ failure with Debian's kernel maintainers. Looking through the patch, it should be rather easy to backport it to kernel 3.2/ wheezy as well (probably no changes needed). Therefore I'd suggest to close or reassign src:_linux/ retitle please 'Add support for the IguanaWorks USB IR Transceiver' this bugreport. With my lirc maintainer hat, this kernel driver should work as-is, configured as dev/input, using the new(ish) RC_CORE subsystem. You can check the supported IR protocols with: $ cat /sys/class/rc/rc0/protocols rc-5 nec rc-6 jvc sony sanyo mce_kbd [lirc] [this output is taken from a mceusb device] The iguanair userspace tools should not be necessary anymore, depending on your use case even lirc might not be strictly required anymore, as the defaults -if left unconfigured- are to expose a normal input device. In case there are problems, an additional follow-up patch has been submitted a few days ago[1], but didn't make it into 3.6.0~rc0 yet. Feel free to contact me/ the lirc maintainer team, if you have problems with configuring lirc for using this new kernel driver. Regards Stefan Lippers-Hollmann [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg49730.html Please set CONFIG_IR_IGUANA=m for kernel = 3.6, to enable RC_CORE support for IguanaIR USB IR receivers. Although this patch should be trivial to backport to kernel 3.2 without any actual code changes, I'd suggest to wait for feedback about this module first, given that I can neither test this particular hardware myself nor were able to solicit any feedback from the affected persons yet. While reviewing the RC_CORE configuration, it might make sense to enable these Kconfig symbols as well: CONFIG_IR_ITE_CIR=m -- CIR header on some Asus x86 Mainboards CONFIG_IR_SANYO_DECODER=m -- just another IR protocol CONFIG_IR_FINTEK=m -- CIR header on some Jetway x86 mainboards CONFIG_IR_NUVOTON=m -- CIR header on some ASRock x86 mainboards CONFIG_IR_WINBOND_CIR=m -- CIR header on some Intel x86 mainboards CONFIG_IR_GPIO_CIR=m-- probably less common Regards Stefan Lippers-Hollmann Index: debian/config/config === --- debian/config/config (Revision 19473) +++ debian/config/config (Arbeitskopie) @@ -1177,6 +1177,7 @@ # CONFIG_IR_NUVOTON is not set CONFIG_IR_REDRAT3=m CONFIG_IR_STREAMZAP=m +CONFIG_IR_IGUANA=m CONFIG_RC_LOOPBACK=m ## Index: debian/changelog === --- debian/changelog (Revision 19473) +++ debian/changelog (Arbeitskopie) @@ -1,7 +1,11 @@ linux (3.6.4-1~experimental.2) UNRELEASED; urgency=low + [ Uwe Kleine-König ] * [rt] bump to 3.6.4-rt10 + [ Stefan Lippers-Hollmann ] + * media/rc: Enable IR_IGUANA as module (Closes: #524403). + -- Uwe Kleine-König u...@kleine-koenig.org Mon, 29 Oct 2012 15:50:12 +0100 linux (3.6.4-1~experimental.1) experimental; urgency=low signature.asc Description: This is a digitally signed message part.
Bug#680762: [stable 2.6.36+] lirc_sir: make device registration work
Hi Please consider adding [media] lirc_sir: make device registration work to stable: formletter This probably needs to get acked by the subsystem maintainer. /formletter commit 4b71ca6bce8fab3d08c61bf330e781f957934ae1 Author: Jarod Wilson ja...@redhat.com Date: Mon Jun 4 13:05:24 2012 -0300 [media] lirc_sir: make device registration work For one, the driver device pointer needs to be filled in, or the lirc core will refuse to load the driver. And we really need to wire up all the platform_device bits. This has been tested via the lirc sourceforge tree and verified to work, been sitting there for months, finally getting around to sending it. :\ CC: Josh Boyer jwbo...@redhat.com Signed-off-by: Jarod Wilson ja...@redhat.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com [backporting to = v3.1, needed for 3.0-longterm] The lirc subdirectory moved from drivers/staging/lirc/ to drivers/staging/media/lirc/ in kernel v3.2, for older kernels this can simply be backported with: sed -i 's|drivers/staging/media/lirc/|drivers/staging/lirc/|g' media-lirc_sir-make-device-registration-work.patch no other changes are required for v3.0-longterm, build-tested. This commit fixes loading the lirc_sir module, which previously wouldn't load/ be usable at all (since its introduction in v2.6.36). serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A smsc_superio_flat(): fir: 0x230, sir: 0x2f8, dma: 03, irq: 3, mode: 0x0e smsc_ircc_present: can't get sir_base of 0x2f8 […] lirc_dev: IR Remote Control driver registered, major 251 lirc_sir: module is from the staging directory, the quality is unknown, you have been warned. lirc_register_driver: dev pointer not filled in! lirc_sir: init_chrdev() failed. The afforementioned commit fixes this problem and makes lirc_sir usable: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A smsc_superio_flat(): fir: 0x230, sir: 0x2f8, dma: 03, irq: 3, mode: 0x0e smsc_ircc_present: can't get sir_base of 0x2f8 […] lirc_dev: IR Remote Control driver registered, major 251 lirc_sir: module is from the staging directory, the quality is unknown, you have been warned. platform lirc_dev.0: lirc_dev: driver lirc_sir registered at minor = 0 lirc_sir: I/O port 0x02f8, IRQ 3. lirc_sir: Installed Without this patch lirc_sir can't even get loaded, the alternative would be to mark it as BROKEN for 3.6. Bug references: - RedHat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=557210 [2.6.31.9-174.fc12.i686.PAE] - Ubuntu launchpad: https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/912251 [3.0.0-12-generic] - Debian BTS: http://bugs.debian.org/680762 [3.2+] Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201208011551.16364.s@gmx.de
Bug#680762: [media] lirc_sir: make device registration work
Hi On Monday 04 June 2012, Jarod Wilson wrote: For one, the driver device pointer needs to be filled in, or the lirc core will refuse to load the driver. And we really need to wire up all the platform_device bits. This has been tested via the lirc sourceforge tree and verified to work, been sitting there for months, finally getting around to sending it. :\ Please consider pushing this[1] patch to 3.5 and -stable (at least 3.0+ is affected, most likely everything = 2.6.37[2]). I can confirm bug - and this patch fixing it on 3.4.4: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A smsc_superio_flat(): fir: 0x230, sir: 0x2f8, dma: 03, irq: 3, mode: 0x0e smsc_ircc_present: can't get sir_base of 0x2f8 […] lirc_dev: IR Remote Control driver registered, major 251 lirc_sir: module is from the staging directory, the quality is unknown, you have been warned. lirc_register_driver: dev pointer not filled in! lirc_sir: init_chrdev() failed. After applying this patch lirc_sir loads find and is usable with irrecord and lirc. serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A smsc_superio_flat(): fir: 0x230, sir: 0x2f8, dma: 03, irq: 3, mode: 0x0e smsc_ircc_present: can't get sir_base of 0x2f8 […] lirc_dev: IR Remote Control driver registered, major 251 lirc_sir: module is from the staging directory, the quality is unknown, you have been warned. platform lirc_dev.0: lirc_dev: driver lirc_sir registered at minor = 0 lirc_sir: I/O port 0x02f8, IRQ 3. lirc_sir: Installed Without this patch lirc_sir can't even get loaded, the alternative would be to mark it as BROKEN for 3.6. Regards Stefan Lippers-Hollmann [1] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=4b71ca6bce8fab3d08c61bf330e781f957934ae1 http://patchwork.linuxtv.org/patch/11579/ [2] RedHat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=557210 [2.6.31.9-174.fc12.i686.PAE] Ubuntu launchpad: https://bugs.launchpad.net/ubuntu/+source/lirc/+bug/912251 [3.0.0-12-generic] Debian BTS: http://bugs.debian.org/680762 [3.2+] -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201207082246.16413.s@gmx.de
Bug#656813: [PATCH] net/wireless: ipw2200: Fix WARN_ON occurring in wiphy_register called by ipw_pci_probe
Hi On Monday 16 April 2012, Stanislav Yakovlev wrote: The problem was found by Stefan Lippers-Hollmann http://marc.info/?l=linux-wirelessm=132720334512946w=2 WARNING: at /tmp/buildd/linux-aptosid-3.2/debian/build/source_i386_none/net/wireless/core.c:562 wiphy_register+0x45/0x38d [cfg80211]() Hardware name: TravelMate 290 \x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x Modules linked in: ipw2200(+) iTCO_wdt libipw joydev drm snd_seq snd_timer snd_seq_device iTCO_vendor_support yenta_socket snd intel_agp i2c_i801 pcmcia_rsrc cfg80211 soundcore parport_pc psmouse parport rng_core snd_page_alloc serio_raw pcspkr i2c_algo_bit intel_gtt pcmcia_core evdev irda crc_ccitt rfkill lib80211 processor container ac battery shpchp pci_hotplug button ext4 mbcache jbd2 crc16 dm_mod sd_mod sr_mod crc_t10dif cdrom ata_generic pata_acpi ata_piix libata scsi_mod firewire_ohci firewire_core crc_itu_t 8139too 8139cp mii uhci_hcd ehci_hcd usbcore usb_common [last unloaded: scsi_wait_scan] Pid: 328, comm: modprobe Not tainted 3.2-1.slh.4-aptosid-686 #1 Call Trace: [c012eaf4] ? warn_slowpath_common+0x7c/0x8f [e0ff0b3e] ? wiphy_register+0x45/0x38d [cfg80211] [e0ff0b3e] ? wiphy_register+0x45/0x38d [cfg80211] [c012eb22] ? warn_slowpath_null+0x1b/0x1f [e0ff0b3e] ? wiphy_register+0x45/0x38d [cfg80211] [c01f89d7] ? internal_create_group+0xf5/0xff [e0a2de1c] ? ipw_pci_probe+0xa9a/0xbd0 [ipw2200] […] This warning appears only if we apply Ben Hutchings' fix http://marc.info/?l=linux-wirelessm=132720195012653w=2 for the bug reported by Cesare Leonardi http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656813 with cfg80211 warning during device registration (cfg80211: failed to add phy80211 symlink to netdev!). We separate device bring up and registration with network stack to avoid the problem. After that Ben Hutchings' fix can be applied to fix the bug. Cc: sta...@kernel.org Signed-off-by: Stanislav Yakovlev stas.yakov...@gmail.com --- Stefan, can you test it once again? […] I've successfully tested this patch on its own and with Ben Hutching's patch (Bug#656813: [PATCH 1/2] ipw2200: Fix order of device registration, Message-ID: 1327201775.8004.83.camel@deadeye) applied on top, it's working fine in both cases. The cfg80211: failed to add phy80211 symlink to netdev! warning disappears after applying both patches to kernel 3.3.2. Feel free to add a tested-by tag, if you like: Tested-by: Stefan Lippers-Hollmann s@gmx.de Tested using: 02:02.0 Network controller [0280]: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection [8086:4220] (rev 05) Subsystem: Intel Corporation Device [8086:2701] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 128 (750ns min, 6000ns max) Interrupt: pin A routed to IRQ 10 Region 0: Memory at d000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=1 PME- Kernel driver in use: ipw2200 Thanks a lot for your efforts! Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201204161945.08522.s@gmx.de
Bug#656813: [PATCH 1/2] ipw2200: Fix order of device registration
[5.785661] [c017cd50] ? jump_label_module_notify+0xec/0x167 [5.785666] [e099d000] ? 0xe099cfff [5.785670] [c0253017] ? __pci_register_driver+0x32/0x87 [5.785675] [e099d000] ? 0xe099cfff [5.785687] [e099d02e] ? ipw_init+0x2e/0x72 [ipw2200] [5.785693] [c0101173] ? do_one_initcall+0x7d/0x132 [5.785699] [c0145016] ? __blocking_notifier_call_chain+0x47/0x4f [5.785705] [c0154a73] ? sys_init_module+0x13a4/0x159c [5.785718] [c03a639f] ? sysenter_do_call+0x12/0x28 [5.785722] ---[ end trace d5a4597cc4a1d28f ]--- [5.785724] ipw2200: failed to register wireless device [5.785795] ipw2200 :02:02.0: PCI INT A disabled [5.785820] ipw2200: probe of :02:02.0 failed with error -5 [acerhk is loaded much later than ipw2200 through /etc/modules, so it can't interfere at this stage] I can try to give it some further checking tomorrow. Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201201220432.34482.s@gmx.de
Bug#655941: iwlagn: my wifi card doesn't works - Intel Corporation Centrino Wireless-N 1000 [8086:0084]
Hi On Sunday 15 January 2012, Jonathan Nieder wrote: [...] apt-get install iw iproute for completeness, you need wpasupplicant as well for the 3rd stanza of /etc/network/interfaces to work (and you want crda (= wheezy) to access channel 11-13/ most of the 5 GHz band): # apt-get install iw iproute wpasupplicant crda ip link set wlan0 up iw dev wlan0 scan iw dev wlan0 connect -w myfavoriteaccesspoint cat /etc/network/interfaces -\EOF iface library inet dhcp wireless-essid CPLWIFI iface home inet dhcp wireless-essid Elephant wireless-key Mouse iface cafe inet dhcp Small syntax fix wpa-driver nl This should read wpa-driver nl80211 the only valid choices here are: - nl80211 all modern mac80211 based drivers. - wext legacy and staging drivers - don't use, unless you have to. it's preferred to just leave out wpa-driver over hardcoding it to wext, because staging drivers will switch to nl80211, once they leave staging. - wired only for encrypted wired ethernet, basically not used in practice. Setting wpa-driver explicitly is no longer necessary since wpasupplicant 0.7.x (= wheezy), it will default to nl80211 and fall back to wext as needed). However it was needed for wpasupplicant =0.6.x from squeeze and earlier (well, at least lenny and squeeze). wpa-ssid Cafe Foo Bar wpa-psk secretsecretpassword EOF ip link set wlan0 down ifup wlan0=cafe While I have no personal experience with iwlagn/ iwlwifi, it might help to load the module with 11n_disable=1, as there've been a couple of problems with both the firmware and the kernel module in recent times. Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201201150410.30984.s@gmx.de
Re: Bug#648367: device-mapper devices such as dm-crypt always have rotational=1; should inherit rotational setting from underlying devices
Hi On Monday 14 November 2011, Josh Triplett wrote: Source: linux-2.6 Version: 3.1.0-1~experimental.1 Severity: normal I use dm-crypt on my system, and I have an SSD. The underlying disk device, sda, has rotational=0: ~$ cat /sys/block/sda/queue/rotational 0 However, the device-mapper devices have rotational=1: ~$ head /sys/block/dm-*/queue/rotational == /sys/block/dm-0/queue/rotational == 1 [...] The device-mapper devices should inherit the setting for rotational from their underlying devices. - Josh Triplett While I don't know about dm-crypt specifically, that issue should be fixed in 3.2~rc1: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=4693c9668fdcec229825b3763876b4744f9e6d5e (it is for plain lvm2, at least) Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140218.55716.s@gmx.de
Re: gcc-4.6
Hi On Friday 28 October 2011, Ben Hutchings wrote: On Fri, Oct 28, 2011 at 06:39:13PM +0200, Bastian Blank wrote: Hi We need to bump the compiler before the Wheezy release to 4.6. Preliminary tests shows that it works fine with Linux 3.1. Now is the question, when do we want to do it? We don't yet have an aufs patch for 3.1, and there will be no rt [...] aufs 3.x-rcN-20111024 (aufs3.x-rcN branch) is working fine with 3.1, also if compiled by gcc-4.6. Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201110282053.14668.s@gmx.de
Bug#646284: dropping applets-fallback breaks initramfs images
Package: busybox
Version: 1:1.19.2-1
Severity: grave
Justification: Breaks system booting using initramfs-tools in non-trivial ways.
Tags: patch
X-Debbugs-CC: Debian kernel team debian-kernel@lists.debian.org
Hi
Initramfs images generated by initramfs-tools 0.99 after busybox got
upgraded to 1:1.19.2-1 fail to boot with the following error messages:
Loading, please wait...
/init: line 11: mount: not found
/init: line 12: mount: not found
/init: line 25: mount: not found
W: devtmpfs not available, falling back to tmpfs for /devtmpfs
/init: line 25: mount: not found
/init: line 27: mount: not found
/init: line 28: mount: not found
cat: can't open '/proc/cmdline': No such file or directory
cat: can't open '/proc/cmdline': No such file or directory
/scripts/init-top/udev: line 14: can't create /sys/kernel/uevent_helper:
nonexistent directory
Begin: Loading essential drivers ... done
Begin: Running /scripts/init-premount ... done
Begin: Mounting root file system .. Begin: Running /scripts/local-top .. [
0.742185] device-mapper: uevent: version 1.0.3
[0.746854] device-mapper: ioctl 4.21.0-ioctl (2011-07-06) initialised:
dm-de...@redhat.com
done.
Begin: Running /scripts/local-premount ... [ 0.765009] Btrfs loaded
done.
/init: line 5: mount: not found
Begin: Running /scripts/local-bottom ... done
done.
Begin: Running /scripts/init-bottom ... done
/init: line 239: mv: not found
/init: line 239: umount: not found
/init: line 242: mount: not found
/init: line 243: mount: not found
Target filesystem doesn't have requested /sbin/init.
/init: line 291: chvt: not found
No init found. Try passing init= bootarg.
BusyBox v1.19.2 (Debian 1:1.19.2-1) built-in shell (ash)
Enter 'help' for a list of built-in commands.
/bin/sh: can't access tty; job control turned off
(initramfs)
needed initramfs-tools hooks on this system:
$ dpkg -S /usr/share/initramfs-tools/hooks/*
initramfs-tools: /usr/share/initramfs-tools/hooks/busybox
dmsetup: /usr/share/initramfs-tools/hooks/dmsetup
initramfs-tools: /usr/share/initramfs-tools/hooks/keymap
initramfs-tools: /usr/share/initramfs-tools/hooks/klibc
lvm2: /usr/share/initramfs-tools/hooks/lvm2
initramfs-tools: /usr/share/initramfs-tools/hooks/thermal
udev: /usr/share/initramfs-tools/hooks/udev
Re-instating applets-fallback.patch in busybox 1:1.19.2-1 however fixes
this reproducable boot failure, quick'n'dirty rediff (tested on
amd64 i386, using systems with mdadm, lvm2 or nothing special at
all) attached.
Regards
Stefan Lippers-Hollmann
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.1-rc10-aptosid-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages busybox depends on:
ii libc6 2.13-21
busybox recommends no packages.
busybox suggests no packages.
-- no debconf information
--- a/shell/ash.c
+++ b/shell/ash.c
@@ -7394,23 +7394,8 @@ static int builtinloc = -1; /* index
static void
-tryexec(IF_FEATURE_SH_STANDALONE(int applet_no,) char *cmd, char **argv, char **envp)
+tryexec(char *cmd, char **argv, char **envp)
{
-#if ENABLE_FEATURE_SH_STANDALONE
- if (applet_no = 0) {
- if (APPLET_IS_NOEXEC(applet_no)) {
- clearenv();
- while (*envp)
-putenv(*envp++);
- run_applet_no_and_exit(applet_no, argv);
- }
- /* re-exec ourselves with the new arguments */
- execve(bb_busybox_exec_path, argv, envp);
- /* If they called chroot or otherwise made the binary no longer
- * executable, fall through */
- }
-#endif
-
repeat:
#ifdef SYSV
do {
@@ -7465,24 +7450,21 @@ shellexec(char **argv, const char *path,
int e;
char **envp;
int exerrno;
-#if ENABLE_FEATURE_SH_STANDALONE
- int applet_no = -1;
-#endif
clearredir(/*drop:*/ 1);
envp = listvars(VEXPORT, VUNSET, /*end:*/ NULL);
- if (strchr(argv[0], '/') != NULL
-#if ENABLE_FEATURE_SH_STANDALONE
- || (applet_no = find_applet_by_name(argv[0])) = 0
-#endif
- ) {
- tryexec(IF_FEATURE_SH_STANDALONE(applet_no,) argv[0], argv, envp);
+ if (strchr(argv[0], '/') != NULL) {
+ tryexec(argv[0], argv, envp);
e = errno;
} else {
+#if ENABLE_FEATURE_SH_STANDALONE
+ bb_execv_applet(argv[0], argv, envp);
+#endif
+
e = ENOENT;
while ((cmdname = path_advance(path, argv[0])) != NULL) {
if (--idx 0 pathopt == NULL) {
-tryexec(IF_FEATURE_SH_STANDALONE(-1,) cmdname, argv, envp);
+tryexec(cmdname, argv, envp);
if (errno != ENOENT errno != ENOTDIR)
e = errno;
}
--- a/libbb/execable.c
+++ b/libbb/execable.c
@@ -9,6 +9,9 @@
#include libbb.h
+#include alloca.h
+#include stdarg.h
+
/* check if path points to an executable file;
* return 1 if found;
* return 0 otherwise;
@@ -68,13 +71,60 @@ int FAST_FUNC exists_execable(const char
}
#if ENABLE_FEATURE_PREFER_APPLETS
+int FAST_FUNC bb_execv_applet(const char *name, char *const argv[], char *const envp
Bug#635840: TP-Link TL-WN821N v2 doesn't work with kernel 3.0
Hi
On Wednesday 31 August 2011, Ben Hutchings wrote:
On Fri, 2011-08-12 at 21:55 +0200, Stefan Lippers-Hollmann wrote:
On Friday 12 August 2011, Ben Hutchings wrote:
On Mon, 2011-08-01 at 19:36 -0300, Willian Gustavo Veiga wrote:
[...]
Given that the licensing for carl9170fw is a bit special[1] for a
firmware image targetted at a different architecture and not easy to
fulfill in a way that avoids wget on the buildds or code duplication,
I've started some preliminary packaging for it at:
Vcs-Svn: svn://svn.berlios.de/fullstory/firmware-carl9170/trunk
Vcs-Browser:
http://svn.berlios.de/svnroot/repos/fullstory/firmware-carl9170/trunk/
While this should meet upstream license conditions in wording and
spirit and may pass ftp-master checking, its strong dependencies
on packaging structures of binutils-source, newlib-source and the
versioned gcc-$(GCC_VER)-source make it rather fragile and high
maintenance, not to say downright ugly (looking at the list of
build-depends). This packaging compiles the sh-2 cross-compiling
environment at build-time, as introducing a newlib based sh-2
cross-compiling toolchain for this single package is hardly a preferred
option for Debian and binutils/ newlib/ gcc maintainers.
[...]
I suggest that you ask the FTP team whether they consider it necessary
for the package to be built in this way.
In case of carl9170fw, license compliance isn't the only reason that
made me building it and its toolchain from source. carl9170fw upstream
doesn't provide binary firmware images and neither release (source-)
tarballs for carl9170fw, the only distribution is through git tags on
git://git.kernel.org/pub/scm/linux/kernel/git/chr/carl9170fw.git
http://git.kernel.org/pub/scm/linux/kernel/git/chr/carl9170fw.git
https://git.kernel.org/pub/scm/linux/kernel/git/chr/carl9170fw.git
which means any packager will regularly have to build the firmware on
his own, in order to make it available for distribution. Binaries made
available from
http://wireless.kernel.org/en/users/Drivers/carl9170#Firmware-1
are rarely updated and often only from third parties (it's a wiki).
While using the upstream provided toolchain target works well (and is
much faster for subsequent builds, as the toochain won't have to get
rebuilt all the time), I chose this route of using
{binutils,newlib,gcc-4.6}-source in order to get carl9170fw into main,
instead of contrib.
firmware-free includes source code but does not actually use it at
package build time. It is rather taken on trust that the source code
can actually be built, though you have prompted me to actually check
this...
In case of carl9170fw, the upstream toolchain target works reliably and
is kept up to date with upstream toolchain changes, so maybe it would
qualify for the same treatment as shipped PDF files or similar
documentation, if it can be rebuilt, but isn't as part of the standard
buildsystem. However the git/source-only distribution for carl9170fw
didn't actually make me look into this.
Regards
Stefan Lippers-Hollmann
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201108311430.13945.s@gmx.de
Bug#635840: TP-Link TL-WN821N v2 doesn't work with kernel 3.0
Hi
On Friday 12 August 2011, Ben Hutchings wrote:
On Mon, 2011-08-01 at 19:36 -0300, Willian Gustavo Veiga wrote:
Ben, probably you're right. I've missed some information, sorry about that:
# dmesg
[ 312.484057] usb 1-5: new high speed USB device number 9 using ehci_hcd
[ 312.664228] usb 1-5: New USB device found, idVendor=0cf3, idProduct=1002
[ 312.664233] usb 1-5: New USB device strings: Mfr=16, Product=32,
SerialNumber=48
[ 312.664237] usb 1-5: Product: USB2.0 WLAN
[ 312.664239] usb 1-5: Manufacturer: ATHER
[ 312.664241] usb 1-5: SerialNumber: 12345
[ 312.780058] usb 1-5: reset high speed USB device number 9 using ehci_hcd
[ 312.954434] usb 1-5: firmware not found.
This driver requires the wireless controller to run different firmware,
which must be installed as /lib/firmware/carl9170-1.fw. That file
should be included in the firmware-free package, but it isn't yet. See
http://linuxwireless.org/en/users/Drivers/carl9170#Firmware-1.
Given that the licensing for carl9170fw is a bit special[1] for a
firmware image targetted at a different architecture and not easy to
fulfill in a way that avoids wget on the buildds or code duplication,
I've started some preliminary packaging for it at:
Vcs-Svn: svn://svn.berlios.de/fullstory/firmware-carl9170/trunk
Vcs-Browser:
http://svn.berlios.de/svnroot/repos/fullstory/firmware-carl9170/trunk/
While this should meet upstream license conditions in wording and
spirit and may pass ftp-master checking, its strong dependencies
on packaging structures of binutils-source, newlib-source and the
versioned gcc-$(GCC_VER)-source make it rather fragile and high
maintenance, not to say downright ugly (looking at the list of
build-depends). This packaging compiles the sh-2 cross-compiling
environment at build-time, as introducing a newlib based sh-2
cross-compiling toolchain for this single package is hardly a preferred
option for Debian and binutils/ newlib/ gcc maintainers.
Please regard this as an initial attempt to solve this issue and feel
free to re-use this or parts of it at your convenience. While I'd
volunteer to co-maintain this (or derivatives of this packaging), it
still needs an active Debian uploader due to its rather high
maintenance requirements (adaptions to future {binutils,newlib}-source
versions or bumping the versioned build-requirements whenever old
gcc-$(GCC_VER)-source versions get removed from the archive).
Warning, system requirements for building this package are quite high:
- ~140 MB build-dependencies
- ~3.4 GB temporary build space
- a good half hour compilation time (mostly spent on the toolchain) on
fast computers, allowing parallel building through DEBBUILDOPTS helps
significantly.
+ build-tested on amd64 and kfreebsd-amd64, providing bit-identical
results
+ functionality confirmed with 0cf3:9170 Atheros Communications, Inc.
AR9170 802.11n on kernel 3.0.1.
Regards
Stefan Lippers-Hollmann
[1] GPL-2: The source code for a work means the preferred form of the
work for making modifications to it. For an executable work,
complete source code means all the source code for all modules
it contains, plus any associated interface definition files,
plus the scripts used to control compilation and installation
of the executable.
signature.asc
Description: This is a digitally signed message part.
Bug#628844: module-init-tools: breaks modinfo -F firmware module
Package: module-init-tools Version: 3.13-1 Severity: normal X-Debbugs-CC: debian-kernel@lists.debian.org Hi After updating to module-init-tools 3.13-1, querying module information through modinfo -F starts to fail: $ /sbin/modinfo -F firmware ath9k_htc debug:Debugging mask (uint) nohwcrypt:Disable hardware encryption (int) $ /sbin/modinfo -F firmware /lib/modules/2.6.39-1-amd64/kernel/drivers/net/wireless/ath/ath9k/ath9k_htc.ko debug:Debugging mask (uint) nohwcrypt:Disable hardware encryption (int) The same procedure is used by linux-image's postinst, to query for missing firmware images: # dpkg -i ./linux-image-2.6.39-1-amd64_2.6.39-1_amd64.deb [...] Running depmod. Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.39-1-amd64 /boot/vmlinuz-2.6.39-1-amd64 update-initramfs: Generating /boot/initrd.img-2.6.39-1-amd64 W: Possible missing firmware /lib/firmware/usbfs_snoop:true for module usbcore W: Possible missing firmware /lib/firmware/to for module usbcore W: Possible missing firmware /lib/firmware/log for module usbcore W: Possible missing firmware /lib/firmware/all for module usbcore W: Possible missing firmware /lib/firmware/usbfs for module usbcore W: Possible missing firmware /lib/firmware/traffic for module usbcore W: Possible missing firmware /lib/firmware/(bool) for module usbcore W: Possible missing firmware /lib/firmware/blinkenlights:true for module usbcore [...] W: Possible missing firmware /lib/firmware/sectors for module sata_sil W: Possible missing firmware /lib/firmware/(0=off, for module sata_sil W: Possible missing firmware /lib/firmware/1=on) for module sata_sil W: Possible missing firmware /lib/firmware/(int) for module sata_sil W: Possible missing firmware /lib/firmware/all_generic_ide: for module ata_generic W: Possible missing firmware /lib/firmware/(int) for module ata_generic run-parts: executing /etc/kernel/postinst.d/pm-utils 2.6.39-1-amd64 /boot/vmlinuz-2.6.39-1-amd64 run-parts: executing /etc/kernel/postinst.d/zz-update-grub 2.6.39-1-amd64 /boot/vmlinuz-2.6.39-1-amd64 Generating grub.cfg ... [...] These problems disappear after reverting to module-init-tools 3.12-1: $ /sbin/modinfo -F firmware ath9k_htc ar9271.fw ar7010_1_1.fw ar7010.fw $ /sbin/modinfo -F firmware /lib/modules/2.6.39-1-amd64/kernel/drivers/net/wireless/ath/ath9k/ath9k_htc.ko ar9271.fw ar7010_1_1.fw ar7010.fw # dpkg -i ./linux-image-2.6.39-1-amd64_2.6.39-1_amd64.deb [...] Running depmod. Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/initramfs-tools 2.6.39-1-amd64 /boot/vmlinuz-2.6.39-1-amd64 update-initramfs: Generating /boot/initrd.img-2.6.39-1-amd64 run-parts: executing /etc/kernel/postinst.d/pm-utils 2.6.39-1-amd64 /boot/vmlinuz-2.6.39-1-amd64 run-parts: executing /etc/kernel/postinst.d/zz-update-grub 2.6.39-1-amd64 /boot/vmlinuz-2.6.39-1-amd64 Generating grub.cfg ... [...] Regards Stefan Lippers-Hollmann -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages module-init-tools depends on: ii libc6 2.13-4 Embedded GNU C Library: Shared lib ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip module-init-tools recommends no packages. module-init-tools suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201106012125.19813.s@gmx.de
Bug#596626: marked as done (linux-image-2.6: Please support Linksys WUSB600N v2 WiFi USB stick)
Hi On Thursday 02 June 2011, Debian Bug Tracking System wrote: Your message dated Wed, 01 Jun 2011 22:35:15 + with message-id e1qru0r-0005nz...@franck.debian.org and subject line Bug#596626: fixed in linux-2.6 3.0.0~rc1-1~experimental.1 has caused the Debian Bug report #596626, regarding linux-image-2.6: Please support Linksys WUSB600N v2 WiFi USB stick to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. This is not actually true for 3.0(-rc1), as some of the required patches missed the merge window and have only been merged into wireless-next today: From 65f31b5e7029e55d4f7020a1d0b0658a50ea73cb Mon Sep 17 00:00:00 2001 From: Gertjan van Wingerde gwinge...@gmail.com Date: Wed, 18 May 2011 20:25:05 +0200 Subject: [PATCH 1/7] rt2x00: Enable PA_PE bits in TX_PIN_CFG according to active band. From 8f96e91fa53761fd63dceedac6bbe4b39e5c5072 Mon Sep 17 00:00:00 2001 From: Gertjan van Wingerde gwinge...@gmail.com Date: Wed, 18 May 2011 20:25:18 +0200 Subject: [PATCH 2/7] rt2x00: Don't disable G0 PA_PE bit in case of BT coexistence. From 872834dfb38edc6f72cfc783a5ce78f2a9f36ec5 Mon Sep 17 00:00:00 2001 From: Gertjan van Wingerde gwinge...@gmail.com Date: Wed, 18 May 2011 20:25:31 +0200 Subject: [PATCH 3/7] rt2x00: Add support for RT3572/RT3592/RT3592+Bluetooth combo card ^--- this is the essential change (which however depends on the previous patches), because the Linksys WUSB600N v2 uses the RaLink RT3572 chipset Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201106020224.05333.s@gmx.de
Bug#622971: ath9k: Ath9K wireless quite unreliable since upgrade to 2.6.38
Hi
Neither crda nor wpasupplicant are responsible for such a behaviour,
but this bug is likely fixed by the attached patch, which will end up
in the upcoming 2.6.38.5 kernel.
Regards
Stefan Lippers-Hollmann
-- Forwarded Message --
Betreff: Patch ath9k_hw: partially revert fix dma descriptor rx error bit
parsing has been added to the 2.6.38-stable tree
Date: Monday 25 April 2011
From: gre...@suse.de
To: n...@openwrt.org, gre...@suse.de, linvi...@tuxdriver.com
This is a note to let you know that I've just added the patch titled
ath9k_hw: partially revert fix dma descriptor rx error bit parsing
to the 2.6.38-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
ath9k_hw-partially-revert-fix-dma-descriptor-rx-error-bit-parsing.patch
and it can be found in the queue-2.6.38 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let sta...@kernel.org know about it.
From 115dad7a7f42e68840392767323ceb9306dbdb36 Mon Sep 17 00:00:00 2001
From: Felix Fietkau n...@openwrt.org
Date: Fri, 14 Jan 2011 00:06:27 +0100
Subject: ath9k_hw: partially revert fix dma descriptor rx error bit parsing
From: Felix Fietkau n...@openwrt.org
commit 115dad7a7f42e68840392767323ceb9306dbdb36 upstream.
The rx error bit parsing was changed to consider PHY errors and various
decryption errors separately. While correct according to the documentation,
this is causing spurious decryption error reports in some situations.
Fix this by restoring the original order of the checks in those places,
where the errors are meant to be mutually exclusive.
If a CRC error is reported, then MIC failure and decryption errors
are irrelevant, and a PHY error is unlikely.
Signed-off-by: Felix Fietkau n...@openwrt.org
Signed-off-by: John W. Linville linvi...@tuxdriver.com
Signed-off-by: Greg Kroah-Hartman gre...@suse.de
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c |8
drivers/net/wireless/ath/ath9k/mac.c| 14 ++
2 files changed, 14 insertions(+), 8 deletions(-)
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -615,7 +615,7 @@ int ath9k_hw_process_rxdesc_edma(struct
*/
if (rxsp-status11 AR_CRCErr)
rxs-rs_status |= ATH9K_RXERR_CRC;
- if (rxsp-status11 AR_PHYErr) {
+ else if (rxsp-status11 AR_PHYErr) {
phyerr = MS(rxsp-status11, AR_PHYErrCode);
/*
* If we reach a point here where AR_PostDelimCRCErr is
@@ -638,11 +638,11 @@ int ath9k_hw_process_rxdesc_edma(struct
rxs-rs_phyerr = phyerr;
}
- }
- if (rxsp-status11 AR_DecryptCRCErr)
+ } else if (rxsp-status11 AR_DecryptCRCErr)
rxs-rs_status |= ATH9K_RXERR_DECRYPT;
- if (rxsp-status11 AR_MichaelErr)
+ else if (rxsp-status11 AR_MichaelErr)
rxs-rs_status |= ATH9K_RXERR_MIC;
+
if (rxsp-status11 AR_KeyMiss)
rxs-rs_status |= ATH9K_RXERR_DECRYPT;
}
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -690,17 +690,23 @@ int ath9k_hw_rxprocdesc(struct ath_hw *a
rs-rs_flags |= ATH9K_RX_DECRYPT_BUSY;
if ((ads.ds_rxstatus8 AR_RxFrameOK) == 0) {
+ /*
+* Treat these errors as mutually exclusive to avoid spurious
+* extra error reports from the hardware. If a CRC error is
+* reported, then decryption and MIC errors are irrelevant,
+* the frame is going to be dropped either way
+*/
if (ads.ds_rxstatus8 AR_CRCErr)
rs-rs_status |= ATH9K_RXERR_CRC;
- if (ads.ds_rxstatus8 AR_PHYErr) {
+ else if (ads.ds_rxstatus8 AR_PHYErr) {
rs-rs_status |= ATH9K_RXERR_PHY;
phyerr = MS(ads.ds_rxstatus8, AR_PHYErrCode);
rs-rs_phyerr = phyerr;
- }
- if (ads.ds_rxstatus8 AR_DecryptCRCErr)
+ } else if (ads.ds_rxstatus8 AR_DecryptCRCErr)
rs-rs_status |= ATH9K_RXERR_DECRYPT;
- if (ads.ds_rxstatus8 AR_MichaelErr)
+ else if (ads.ds_rxstatus8 AR_MichaelErr)
rs-rs_status |= ATH9K_RXERR_MIC;
+
if (ads.ds_rxstatus8 AR_KeyMiss)
rs-rs_status |= ATH9K_RXERR_DECRYPT;
}
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org
Bug#621737: linux-image-2.6.32-5-powerpc: ath ignores regulatory domain setting
Hi On Sunday 10 April 2011, Anton Ivanov wrote: On 04/10/11 00:55, Ben Hutchings wrote: On Fri, 2011-04-08 at 13:39 +0100, Anton Ivanov wrote: [...] ath driver ignores reg domain setting passed via cfg80211 and uses one from EEPROM instead. This setting a lot of cheap cards is CN. As a result the reg domain is set incorrectly (and for some countries illegally). [...] What do you mean by 'passed via cfg80211'? Are you setting the ieee80211_regdom module parameter? [...] Yes. No effect. ath still reads from eeprom. The EEPROM settings are authoritative, you can only restrict the regulatory settings further to aid regulatory compliance in different regions, but never relax them. Tools like crda always intersect the EEPROM's (OTP in newer chipset generations) with the chosen regulatory domain as provided by wireless-regdb or the in-kernel regdb; regulatory hints like IEEE 802.11d may also restrict the allowed frequencies even further. http://wireless.kernel.org/en/users/Drivers/ath#Regulatory This is intended beaviour and required for FCC compliance (keep in mind that calibration data is also only validated for the given regdomain), not a bug. Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201104101723.38192.s@gmx.de
Bug#621737: linux-image-2.6.32-5-powerpc: ath ignores regulatory domain setting
Hi On Sunday 10 April 2011, Anton Ivanov wrote: On 04/10/11 16:23, Stefan Lippers-Hollmann wrote: Hi On Sunday 10 April 2011, Anton Ivanov wrote: On 04/10/11 00:55, Ben Hutchings wrote: On Fri, 2011-04-08 at 13:39 +0100, Anton Ivanov wrote: [...] Yes. No effect. ath still reads from eeprom. The EEPROM settings are authoritative, you can only restrict the regulatory settings further to aid regulatory compliance in different regions, but never relax them. Tools like crda always intersect the EEPROM's (OTP in newer chipset generations) with the chosen regulatory domain as provided by wireless-regdb or the in-kernel regdb; regulatory hints like IEEE 802.11d may also restrict the allowed frequencies even further. http://wireless.kernel.org/en/users/Drivers/ath#Regulatory This is intended beaviour and required for FCC compliance (keep in mind that calibration data is also only validated for the given regdomain), not a bug. So a card that returns only CN from EEPROM is basically intended to be sold _ONLY_ in China. Right? [...] Correct, it's arguably even illegal to sell in ETSI regions. Although it's technically a little more complex as Atheros groups regdom regions with identical mappings together[1], which makes reading the EEPROM based regulatory domain code a bit strange (the alphabetically first match corresponding to the regdom group gets printed to dmesg). In your particular case, with a 2.4 GHz-only AR2417 PHY, 0x52 (APL1_WORLD vs ETSI1_WORLD, GB) doesn't actually do any harm, as 'CN' allows channel 1-13 just as well as the most permissive regdomains (ch14 in Japan is only allowed for CSMA/CA == 11 MBit/s, not the more common OFDM rates (= 54 MBit/s)). So even though your device is wrongly programmed, it doesn't actually limit your abilities (unless you'd add an additional 5 GHz capable card, which would suffer from an 'unfortunate' intersection) - and neither allows you to access non-public frequency bands. This situation would be seriously worse (both technically and legally) for 5 GHz operations, but your device doesn't support that anyways. country CN: (2402 - 2482 @ 40), (N/A, 20) (5735 - 5835 @ 40), (N/A, 30) country GB: (2402 - 2482 @ 40), (N/A, 20) (5170 - 5250 @ 40), (N/A, 20) (5250 - 5330 @ 40), (N/A, 20), DFS (5490 - 5710 @ 40), (N/A, 27), DFS However I'm aware of the sad truth that most commonly sold cards are wrongly programmed for CN or (worse for 2.4 GHz operations) US... Regards Stefan Lippers-Hollmann [1] http://wireless.kernel.org/en/users/Drivers/ath#line-28 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201104102108.14911.s@gmx.de
Bug#616426: linux-source-2.6.37: fails to build using make-kpkg
Hi On Friday 04 March 2011, Ben Hutchings wrote: On Fri, 2011-03-04 at 11:37 +, rob wrote: Package: linux-source-2.6.37 Version: 2.6.37-2 Severity: important AS arch/x86/kernel/entry_64.o arch/x86/kernel/entry_64.S: Assembler messages: arch/x86/kernel/entry_64.S:1531: Error: .size expression does not evaluate to a constant make[4]: *** [arch/x86/kernel/entry_64.o] Error 1 make[3]: *** [arch/x86/kernel] Error 2 make[2]: *** [arch/x86] Error 2 make[2]: Leaving directory `/usr/src/linux-source-2.6.37' make[1]: *** [debian/stamp/build/kernel] Error 2 make[1]: Leaving directory `/usr/src/linux-source-2.6.37' make: *** [debian/stamp/do-build-arch] Error 2 Oddly enough, this code did build in the official packages! May be a bug in binutils (#616357). Yes, it is related to #616357 (and official packages are affected just as well, if built with the new binutils). Patch needed for 2.6.37 and 2.6.38-rc7(-git2): - http://git.kernel.org/?p=linux/kernel/git/hjl/linux-2.6.37.y.git;a=commitdiff_plain;h=2c5ce9c1b8eb927c131a31d4466e24e00647e9cb Patch only needed for 2.6.38-rc7(-git2), in addition to the one above: - https://patchwork.kernel.org/patch/606241/ Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201103041431.55175.s@gmx.de
Re: [kernel] r16958 - in dists/trunk/linux-2.6/debian: . bin config
Hi
On Tue, Mar 01, 2011 at 05:44:42AM +, Ben Hutchings wrote:
[...]
Modified: dists/trunk/linux-2.6/debian/changelog
==
--- dists/trunk/linux-2.6/debian/changelogTue Mar 1 02:19:31 2011
(r16957)
+++ dists/trunk/linux-2.6/debian/changelogTue Mar 1 05:44:42 2011
(r16958)
@@ -1,3 +1,12 @@
+linux-2.6 (2.6.38~rc6-1~experimental.2) UNRELEASED; urgency=low
+
+ [ Ben Hutchings ]
+ * postinst: Remove specific support for running a ramdisk creator;
+warn users that specify one in /etc/kernel-img.conf
+ * Require initramfs-tools = 0.94, which installs a postinst hook
initramfs-tools = 0.94 installs a postinst hook, however it
unfortunately appears to bail out early, if called from an official
Debian kernel image (/etc/kernel/postinst.d/initramfs-tools):
# kernel-package passes an extra arg
if [ -n $2 ]; then
if [ -n ${KERNEL_PACKAGE_VERSION} ]; then
# exit if custom kernel does not need an initramfs
[ $INITRD = 'No' ] exit 0
bootdir=$(dirname $2)
bootopt=-b ${bootdir}
else
# official Debian linux-images take care themself
exit 0
fi
fi
and therefore doesn't actually create an initramfs image anymore, after
the corresponding code ($ramdisk_cmd et al.) has been pulled from
debian/templates/temp.image.plain/postinst.
[...]
Modified: dists/trunk/linux-2.6/debian/templates/temp.image.plain/postinst
==
--- dists/trunk/linux-2.6/debian/templates/temp.image.plain/postinst Tue Mar
1 02:19:31 2011(r16957)
+++ dists/trunk/linux-2.6/debian/templates/temp.image.plain/postinst Tue Mar
1 05:44:42 2011(r16958)
[...]
@@ -821,6 +793,10 @@
die Error asking debconf question $question: $seen if $ret $ret !=
30;
}
+if ($initrd ! -e initrd.img-$version) {
I think this needs to be prepended by the full install path, like:
if ($initrd ! -e ${realimageloc}initrd.img-$version) {
+ die Failed to create initrd image.\n;
+}
+
exit 0;
__END__
Regards
Stefan Lippers-Hollmann
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110304.50400.s@gmx.de
Re: [kernel] r16958 - in dists/trunk/linux-2.6/debian: . bin config
Hi
On Friday 04 March 2011, Ben Hutchings wrote:
On Fri, Mar 04, 2011 at 12:00:48AM +0100, Stefan Lippers-Hollmann wrote:
[...]
Modified: dists/trunk/linux-2.6/debian/templates/temp.image.plain/postinst
==
--- dists/trunk/linux-2.6/debian/templates/temp.image.plain/postinst
Tue Mar 1 02:19:31 2011(r16957)
+++ dists/trunk/linux-2.6/debian/templates/temp.image.plain/postinst
Tue Mar 1 05:44:42 2011(r16958)
[...]
@@ -821,6 +793,10 @@
die Error asking debconf question $question: $seen if $ret $ret
!= 30;
}
+if ($initrd ! -e initrd.img-$version) {
I think this needs to be prepended by the full install path, like:
if ($initrd ! -e ${realimageloc}initrd.img-$version) {
[...]
We have already chdir()'d to that directory.
I'm certainly not overly fluent in perl, but I'm pretty sure that cwd
is / at that stage
[...]
#known variables
my $image_dest = /;
my $realimageloc= /boot/;
my $have_conffile = ;
[...]
# Do some preliminary sanity checks here to ensure we actually have an
# valid image dir
chdir('/') or die could not chdir to /:$!\n;
[...]
# most of our work is done in $image_dest (nominally /)
chdir($image_dest) or die could not chdir to $image_dest:$!\n;
[...]
the only remaining chdir() call is in test_relative() and doesn't
appear to have an effect on the cwd.
Likewise extending the afforementioned check with a quick and dirty call to
getcwd() seems to agree with / being the cwd at that stage:
[...]
if ($initrd ! -e initrd.img-$version) {
use Cwd;
print STDERR Current working directory: . getcwd() . \n;
die Failed to create initrd image.\n;
}
[...]
Which results in:
[...]
run-parts: executing /etc/kernel/postinst.d/initramfs-tools
2.6.38-rc7-amd64 /boot/vmlinuz-2.6.38-rc7-amd64
update-initramfs: Generating /boot/initrd.img-2.6.38-rc7-amd64
run-parts: executing /etc/kernel/postinst.d/zz-update-grub
2.6.38-rc7-amd64 /boot/vmlinuz-2.6.38-rc7-amd64
Generating grub.cfg ...
[...]
Current working directory: /
Failed to create initrd image.
dpkg: error processing linux-image-2.6.38-rc7-amd64 (--configure):
subprocess installed post-installation script returned error exit
status 2
While it succeeds correctly with (after convincing
/etc/kernel/postinst.d/initramfs-tools to generate initrds for official
Debian kernels as well) by using:
if ($initrd ! -e ${realimageloc}initrd.img-$version) {
Regards
Stefan Lippers-Hollmann
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201103040427.21095.s@gmx.de
Re: eglibc: Broken ldd due to wrong path for ld.so
Hi On Monday 28 February 2011, Guillem Jover wrote: Package: libc-bin Version: 2.11.2-12 Severity: serious Hi! It might seem the latest multiarch patches broke somehow at least ldd, which is missing the prefix path to the ld.so binary. $ grep RTLDLIST /usr/bin/ldd RTLDLIST=/ld-linux-x86-64.so.2 It then fails to work properly on binaries: $ file /bin/ls /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped $ ldd /bin/ls not a dynamic executable This also affects initramfs generation, as initramfs-tools relies heavily on ldd to determine which libraries need to be pulled in to satisfy the needs of binaries (/sbin/init !) embedded into the initramfs. A comparison between an initramfs generated with eglibc 2.11.2-11 (a) and eglibc 2.11.2-12 (b) installed shows the result, which breaks booting with the newly (re-)generated initramfs. --- a 2011-02-28 03:38:36.950032034 +0100 +++ b 2011-02-28 03:38:39.937032034 +0100 @@ -60,8 +60,6 @@ etc/udev etc/udev/udev.conf init lib -lib64 -lib64/ld-linux-x86-64.so.2 lib/firmware lib/firmware/3com lib/firmware/3com/typhoon.bin @@ -90,18 +88,6 @@ lib/firmware/tigon/tg3.bin lib/firmware/tigon/tg3_tso5.bin lib/firmware/tigon/tg3_tso.bin lib/klibc-r1_A6R6EwMsdze5h5xz93JiNuoM.so -lib/libblkid.so.1 -lib/libc.so.6 -lib/libdevmapper.so.1.02.1 -lib/libdl.so.2 -lib/libm.so.6 -lib/libncurses.so.5 -lib/libpthread.so.0 -lib/libreadline.so.5 -lib/librt.so.1 -lib/libselinux.so.1 -lib/libudev.so.0 -lib/libuuid.so.1 lib/modules Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102280343.53740.s@gmx.de
Re: rt2860 driver, linux-image-2.6.37-1-686, firmware-ralink
using plain firmware-ralink 0.28. Bus 001 Device 002: ID 148f:2770 Ralink Technology, Corp. RT2770 Wireless Adapter [1.769064] usb 1-3: new high speed USB device using ehci_hcd and address 2 [1.902427] usb 1-3: New USB device found, idVendor=148f, idProduct=2770 [1.902434] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [1.902440] usb 1-3: Product: 802.11 n WLAN [1.902444] usb 1-3: Manufacturer: Ralink [1.902449] usb 1-3: SerialNumber: 1.0 [5.585687] cfg80211: Calling CRDA to update world regulatory domain [6.661347] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht' [6.663252] Registered led device: rt2800usb-phy0::radio [6.663400] Registered led device: rt2800usb-phy0::assoc [6.663538] Registered led device: rt2800usb-phy0::quality [6.663929] usbcore: registered new interface driver rt2800usb [6.986433] cfg80211: Calling CRDA for country: DE [7.146658] cfg80211: Disabling freq 2484 MHz [7.146668] cfg80211: Regulatory domain changed to country: DE [7.146672] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [7.146679] (240 KHz - 2483500 KHz @ 4 KHz), (N/A, 2000 mBm) [7.146684] (515 KHz - 525 KHz @ 4 KHz), (N/A, 2000 mBm) [7.146690] (525 KHz - 535 KHz @ 4 KHz), (N/A, 2000 mBm) [7.146695] (547 KHz - 5725000 KHz @ 4 KHz), (N/A, 2698 mBm) [ 992.643135] ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 993.473531] cfg80211: Found new beacon on frequency: 2472 MHz (Ch 13) on phy0 [ 994.088522] wlan0: authenticate with 00:27:19:fe:47:84 (try 1) [ 994.090674] wlan0: authenticated [ 994.117521] wlan0: associate with 00:27:19:fe:47:84 (try 1) [ 994.121052] wlan0: RX AssocResp from 00:27:19:fe:47:84 (capab=0x411 status=0 aid=1) [ 994.121059] wlan0: associated [ 994.142004] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 994.142267] cfg80211: Calling CRDA for country: DE [ 994.153326] cfg80211: Disabling freq 2484 MHz [ 994.153336] cfg80211: Regulatory domain changed to country: DE [ 994.153341] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp) [ 994.153347] (240 KHz - 2483500 KHz @ 4 KHz), (N/A, 2000 mBm) [ 994.153353] (515 KHz - 525 KHz @ 4 KHz), (N/A, 2000 mBm) [ 994.153358] (525 KHz - 535 KHz @ 4 KHz), (N/A, 2000 mBm) [ 994.153364] (547 KHz - 5725000 KHz @ 4 KHz), (N/A, 2698 mBm) [ 994.295153] padlock: VIA PadLock not detected. [ 994.346433] Intel AES-NI instructions are not detected. [ 1004.818026] wlan0: no IPv6 routers present There have been several attempts of the rt2x00 developers to update rt2860.bin/ rt2870.bin in firmware-linux.git (and to remove rt3070.bin, rt3071.bin, rt3090.bin - which are just more current versions of rt2860.bin and rt2870.bin under different names, erroneously introduced when rt3070/ rt3090 were merged into staging (and still needlessly used by the staging rt2860sta/ rt2870sta drivers)) [2], [3]. Regards Stefan Lippers-Hollmann [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601416#15 [2] http://www.spinics.net/lists/linux-wireless/msg48780.html ff. [3] http://www.spinics.net/lists/linux-wireless/msg64834.html ff. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201102201737.05137.s@gmx.de
Bug#602450: directory does not match with driver needs
Hi On Friday 21 January 2011, Ben Hutchings wrote: On Mon, 2011-01-10 at 19:31 +0100, mourad wrote: Package: firmware-realtek Version: 0.28 Severity: normal Hi, The lastest version solved only partially the problem. The driver is looking for the firmware in the rtl8712u firmware directory and not in rtlwifi as created by 0.28 package... [...] Larry, can you decide which of these paths is correct: rtlwifi/rtl8712u.bin rtl8712u/rtl8712u.bin Greg Kroah-Hartman has just merged http://git.kernel.org/?p=linux/kernel/git/gregkh/staging-2.6.git;a=commitdiff;h=b54a28a418b2730bf61554864fee3fb24f79e182 into staging-next (which will be in tomorrow's linux-next and end up in 2.6.39): MODULE_FIRMWARE(rtlwifi/rtl8712u.bin); So rtlwifi/rtl8712u.bin, as already used in firmware-linux.git and Debian's firmware-realtek package is the correct firmware location. Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201101212308.23753.s@gmx.de
Bug#602450: firmware-nonfree: Please add rtlwifi/rtl8712u.bin, needed by r8712u = 2.6.37, to firmware-realtek
Package: firmware-nonfree
Version: 0.27
Severity: wishlist
Hi
Starting with kernel 2.6.37, rtl8192su/ r8192s_usb will be replaced by
the new staging driver rtl8712/ r8712u. It would be nice if its firmware,
which has been added to firmware-linux.git this week, could be added to
the firmware-realtek package.
http://lkml.indiana.edu/hypermail/linux/kernel/1011.0/00610.html
Message-ID: 4cd014ec.e0ho4xdm0+tov1xt%larry.fin...@lwfinger.net
http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=tree;f=rtlwifi
The firmware license appears to be acceptable for firmware-nonfree
http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git;a=blob;f=LICENCE.rtlwifi_firmware.txt
--
Hints for linux-2.6 2.6.37~
r8712u as merged mainline for 2.6.37 does not use this external firmware
yet, but still compiles it into the r8712u kernel module through
drivers/staging/rtl8712/farray.h (rm)
Patches to employ request_firmware() are pending
http://www.spinics.net/lists/linux-wireless/msg58214.html
Message-ID: 4cc9f4be.7070...@lwfinger.net
and a minor (updated in this attachment) fixup attached
http://www.spinics.net/lists/linux-wireless/msg58240.html
Message-Id: 201010292203.39953.s@gmx.de
I can confirm that rtl8712/ r8712u with split out firmware using
request_firmware() is working with RealTek RTL8188S and RTL8191S
devices and a decent replacement/ update for rtl8192su/ r8192s_usb.
http://www.spinics.net/lists/linux-wireless/msg58239.html
Message-Id: 201010292202.25486.s@gmx.de
Regards
Stefan Lippers-Hollmann
staging: r8712u: Fix external firmware loading
* select FW_LOADER
* declare MODULE_FIRMWARE for r8712u
* change firmware location to represent published linux-fimware.git
Signed-off-by: Stefan Lippers-Hollmann s@gmx.de
---
drivers/staging/rtl8712/Kconfig|1 +
drivers/staging/rtl8712/hal_init.c |3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/staging/rtl8712/Kconfig
+++ b/drivers/staging/rtl8712/Kconfig
@@ -3,6 +3,7 @@ config R8712U
depends on WLAN USB
select WIRELESS_EXT
select WEXT_PRIV
+ select FW_LOADER
default N
---help---
This option adds the Realtek RTL8712 USB device such as the D-Link DWA-130.
--- a/drivers/staging/rtl8712/hal_init.c
+++ b/drivers/staging/rtl8712/hal_init.c
@@ -40,7 +40,7 @@ static u32 rtl871x_open_fw(struct _adapt
const u8 **ppmappedfw)
{
int rc;
- const char firmware_file[] = rtl8712u/rtl8712u.bin;
+ const char firmware_file[] = rtlwifi/rtl8712u.bin;
const struct firmware **praw = (const struct firmware **)
(pphfwfile_hdl);
struct dvobj_priv *pdvobjpriv = (struct dvobj_priv *)
@@ -58,6 +58,7 @@ static u32 rtl871x_open_fw(struct _adapt
*ppmappedfw = (u8 *)((*praw)-data);
return (*praw)-size;
}
+MODULE_FIRMWARE(rtlwifi/rtl8712u.bin);
static void fill_fwpriv(struct _adapter *padapter, struct fw_priv *pfwpriv)
{
signature.asc
Description: This is a digitally signed message part.
Bug#601416: firmware-ralink: newer images available
Hi
On Tuesday 26 October 2010, Ben Hutchings wrote:
On Mon, Oct 25, 2010 at 02:30:03PM -0700, Matt Taggart wrote:
Package: firmware-ralink
Version: 0.27
I was looking at ralink's website
http://www.ralinktech.com/support.php?s=2
there are some newer versions of firmware for ralink devices available.
Here is a table comparing what's in the current 0.27 version and what's on
the website (as of 2010-10-25). Hopefully my ascii art makes sense
Yes, but what I don't get is how these single images are supposed to
work with so many different controllers. The current drivers will try
to load different files for different chips:
[...]
2760/2790/2860/2890 11\
3060/3062/3562/2790 n/a| 26
3090 19/
These are currently covered by rt2860.bin and rt3090.bin, but the new
archive only contains rt2860.bin.
2870 12\
2770/3572 n/a| 22
3070 17/
3071 17 /
[...]
These are covered by rt2870.bin, rt3070.bin and rt3071.bin. The new
archive only contains rt2870.bin.
If you can confirm that the new images really do work with all the
controllers they are claimed to, and with the current drivers, then we
should update the package and David Woodhouse's linux-firmware
repository. Without that, I'm hesitant to make any changes.
This is what rt2x00 upstream said about it in april,
http://www.spinics.net/lists/linux-wireless/msg48780.html
namely that there is only rt2860.bin for PCI/ PCIe devices and rt2870.bin
for USB ones, depending on your chipset (rt3xxx) merely a minimum firmware
revision, which is backwards compatible, needs to be met.
Personally I can confirm that that RT2770 (148f:2770) works fine with
rev 22 of Firmware RT28XX/RT30XX USB series (RT2870/RT2770/RT3572/RT3070)
2bb89af3a7d446deb4695c9a3daa7f9d */lib/firmware/rt2870.bin
in both rt2870sta from 2.6.32 and rt2800usb in =2.6.35.
Likewise (original) RT2860 (1814:0781) works fine with rev 26 of Firmware
RT28XX/RT30XX PCI/mPCI/PCIe/CardBus series (RT2760/RT2790/RT2860/RT2890/
RT3060/RT3062/RT3562/RT2860/RT2760/RT2890/RT2790/RT3090)
66332d7636ee78db31b056aa0e44b097 */lib/firmware/rt2860.bin
in both rt2860sta from 2.6.32.x and rt2800pci in =2.6.35.
rt2800pci/ rt2800usb require at least kernel 2.6.35 to function, in earlier
kernels too many packets got dropped for successful operations (both auth
and dhcp). Starting with 2.6.36 HT40 operations are supported, actual
802.11n performance isn't supported by neither rt28[67]0sta nor
rt2800{pci,usb} (as of 2.6.36) yet, but under development for rt2x00.
Recent rt2800{pci,usb} appears to be a lot more stable than rt28[67]sta
to me.
Regards
Stefan Lippers-Hollmann
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201010260204.55050.s@gmx.de
Bug#599465: brcm80211 module missing
Hi On Thursday 07 October 2010, Joerg Friedrich wrote: Package: linux-2.6 Version: 2.6.36~rc6-1~experimental.1 Severity: normal Tags: experimental module is missing from linux-image-2.6.36-rc6-amd64 linux-image-2.6.32-5-amd64 (2.6.32-23) has it and changelog says its included since 2.6.36~rc5-1~experimental.1 config has included r...@gucky:~# grep -i brcm80211 /boot/config-2.6.36-rc6-amd64 CONFIG_BRCM80211=m CONFIG_BRCM80211_PCI=y but the module seems not to be built [...] I actually fell over the same issue when cherry picking brcm8211 myself, the bug is a extraneous closing paranthesis in debian/patches/features/all/staging-Add-initial-release-of-brcm80211.patch [...] diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile index cad2574..2e82589 100644 --- a/drivers/staging/Makefile +++ b/drivers/staging/Makefile @@ -14,6 +14,7 @@ obj-$(CONFIG_W35UND) += winbond/ obj-$(CONFIG_PRISM2_USB) += wlan-ng/ obj-$(CONFIG_ECHO) += echo/ obj-$(CONFIG_OTUS) += otus/ +obj-$(CONFIG_BRCM80211)) += brcm80211/ obj-$(CONFIG_RT2860) += rt2860/ obj-$(CONFIG_RT2870) += rt2870/ obj-$(CONFIG_COMEDI) += comedi/ [...] Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201010072248.36710.s@gmx.de
[PATCH]: linux-2.6: use string operators instead of numeric ones for string concatenation
Revision 16224 of svn://svn.debian.org/svn/kernel/dists/trunk/linux-2.6
enabled use strict; and use warnings; for the perl based maintainer
scripts of linux-ima...@upstreamversion@@abiname@@localversion@, this in
turn exposed that the numeric '+=' operator is used to concatenate
$message and $dir_message variables; this patch fixes this by using the
string operator '.='.
Argument Module sub-directories were detected.\n isn't numeric in addition
(+) at /var/lib/dpkg/tmp.ci/preinst line 100.
Argument isn't numeric in addition (+) at /var/lib/dpkg/tmp.ci/preinst line
100.
Signed-off-by: Stefan Lippers-Hollmann s@gmx.de
---
debian/templates/temp.image.plain/preinst |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff -Nrup a/debian/templates/temp.image.plain/preinst
b/debian/templates/temp.image.plain/preinst
--- a/debian/templates/temp.image.plain/preinst
+++ b/debian/templates/temp.image.plain/preinst
@@ -97,7 +97,7 @@ sub check {
unless $dir_message;
}
}
-$message += $dir_message if $dir_message;
+$message .= $dir_message if $dir_message;
}
my @links = grep { -l $lib_modules/$_ } @children;
@@ -108,10 +108,10 @@ sub check {
next if ($link =~ /^source$/);
$links_message = Symbolic links were detected in
$modules_base/$version.\n;
}
-$message += $links_message if $links_message;
+$message .= $links_message if $links_message;
}
my @files = grep { -f $lib_modules/$_ } @children;
- $message += Additional files also exist in $modules_base/$version.\n
+ $message .= Additional files also exist in $modules_base/$version.\n
if ($#files -1);
}
}
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201009030942.20493.s@gmx.de
Bug#586457: [linux-2.6] hda-intel: spurious response... message flood and no sound
Hi On Saturday 19 June 2010, debian.iw...@ncf.ca wrote: Package: linux-2.6 Version: 2.6.32-5-amd64 Severity: important I have an Intel D945GCLF2D motherboard with Realtek ALC662 audio codec. On booting the system the console is flooded with messages like: hda-intel: spurious response 0x0:0x0, last cmd=0x00 and also the message: hda-intel: nocodecs initialized And of course sound doesn't work when the desktop loads. I've tried supplying different models for the ALC662 via the model parameter in the snd_hda_intel module, but to no avail. Also tried the probe_mask parameter with no luck either. The audio worked fine with kernel 2.6.30-2-amd64 and the bug was introduced sometime after that version. I tried the 2.6.34 kernel in experimental and the bug is still present there - sound still doesn't work but there are far fewer spurious response messages. Log messages: [3.027053] HDA Intel :00:1b.0: PCI INT A - GSI 22 (level, low) - IRQ 22 [3.027171] HDA Intel :00:1b.0: setting latency timer to 64 [3.057555] hda-intel: spurious response 0x0:0x0, last cmd=0x00 [...] [3.089682] hda-intel: spurious response 0x0:0x1, last cmd=0x00 [3.089688] hda-intel: spurious response 0x0:0x2, last cmd=0x200f0004 [3.089784] HDA Intel :00:1b.0: PCI INT A disabled --- System information. --- Architecture: amd64 Kernel: Linux 2.6.32-5-amd64 Make sure to set IGD Aperture Size to 256 MB in the BIOS, with less, the mainboard reacts *very* picky to PCI and USB devices, independent of the OS. While that setting should avoid most issues, the mainboard's ACPI implementation seems to be quite fragile at best. (Further) Experiments with snd_hda_intel module parameters don't really improve the situation (on the contrary), the real problems seem to be hidden way deeper. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#581554: firmware-realtek: Incorrect firmware
Hi On Saturday 15 May 2010, Ben Hutchings wrote: On Fri, 2010-05-14 at 08:56 +0200, Miguel J.Jiménez wrote: The firmware seems to have uploaded correctly to the device. My mistake... that was 68533bf8078a9e00966a78c9f2da4b9b firmware and not the one provided with the deb package. [...] OK, I've found this file - not on the Realtek site but on a random file-sharing site! Since I've now collected quite a few Realtek driver packages which aren't easily available, I've uploaded all those that are redistributable to http://people.debian.org/~benh/rtl-wlan/. Stefan, please download http://people.debian.org/~benh/rtl-wlan/rtl8192su_linux_2.6.0002.0708.2009.tar.gz and check whether the firmware blob in there (which should be the same one Miguel has used) works for you as well. 68533bf8078a9e00966a78c9f2da4b9b */lib/firmware/RTL8192SU/rtl8192sfw.bin Does work for me as well: [ 69.922023] usb 1-3: new high speed USB device using ehci_hcd and address 4 [ 70.038440] usb 1-3: New USB device found, idVendor=0bda, idProduct=8171 [ 70.038443] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 70.038445] usb 1-3: Product: RTL8188S WLAN Adapter [ 70.038447] usb 1-3: Manufacturer: Manufacturer Realtek [ 70.038449] usb 1-3: SerialNumber: 00e04c01 [ 70.131710] r8192s_usb: module is from the staging directory, the quality is unknown, you have been warned. [ 70.135003] ieee80211_crypt: registered algorithm 'NULL' [ 70.135006] ieee80211_crypt: registered algorithm 'TKIP' [ 70.135007] ieee80211_crypt: registered algorithm 'CCMP' [ 70.135009] ieee80211_crypt: registered algorithm 'WEP' [ 70.135010] [ 70.135011] Linux kernel driver for RTL8192 based WLAN cards [ 70.135012] Copyright (c) 2007-2008, Realsil Wlan [ 70.135274] ==ep_num:4, in_ep_num:1, out_ep_num:3 [ 70.135276] ==RtInPipes:3 [ 70.135278] ==RtOutPipes:4 6 13 [ 70.135281] ==txqueue_to_outpipemap for BK, BE, VI, VO, HCCA, TXCMD, MGNT, HIGH, BEACON: [ 70.135282] 1 1 0 0 2 2 2 2 2 [ 70.345766] usbcore: registered new interface driver rtl819xU [ 84.803010] usb 1-3: firmware: requesting RTL8192SU/rtl8192sfw.bin [ 87.528569] ADDRCONF(NETDEV_UP): wlan2: link is not ready [ 87.802108] Linking with surveyor,channel:1, qos:1, myHT:1, networkHT:1, mode:10 [ 87.802121] Linking with surveyor,channel:1, qos:1, myHT:1, networkHT:1, mode:10 [ 87.863184] Associated successfully [ 87.863187] Using G rates:108 [ 87.863189] Successfully associated, ht enabled [ 87.929515] ADDRCONF(NETDEV_CHANGE): wlan2: link becomes ready [ 88.053026] padlock: VIA PadLock not detected. [ 88.117882] Intel AES-NI instructions are not detected. [ 89.528564] dm_check_edca_turbo():iot peer is 0x0:unknown, bssid:00:27:19:fe:47:84 [ 98.065009] wlan2: no IPv6 routers present It is slightly slower though, ~5130 KB/s (a5ad703551efb108ba012b4b8a830d93) compared to 4970 KB/s (68533bf8078a9e00966a78c9f2da4b9b) for a 65 MB kernel tarball served by vsftpd from a local server (access point using Atheros AR9100 MAC/BB Rev:0 AR2133 RF Rev:a2 with ath9k, local server connected via GBit/s ethernet). Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#581554: firmware-realtek: Incorrect firmware
Hi On Thursday 13 May 2010, Miguel J. Jiménez wrote: [...] Firmware provided with the package does not allow wireless connection on Belkin F5D8053 N Wireless USB Adapter v6000. The right firmware I certainly have a device supported by rtl8192su/ r8192s_usb that works well with: a5ad703551efb108ba012b4b8a830d93 /lib/firmware/RTL8192SU/rtl8192sfw.bin Therefore it would be very interesting to find out what exactly the kernel/ module says when loading rtl8192sfw.bin and which exact device you're using (the model doesn't really tell anything), for me it is: [ 7274.035016] usb 1-3: new high speed USB device using ehci_hcd and address 5 [ 7274.151421] usb 1-3: New USB device found, idVendor=0bda, idProduct=8171 [ 7274.151425] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 7274.151427] usb 1-3: Product: RTL8188S WLAN Adapter [ 7274.151429] usb 1-3: Manufacturer: Manufacturer Realtek [ 7274.151431] usb 1-3: SerialNumber: 00e04c01 [ 7274.159714] r8192s_usb: module is from the staging directory, the quality is unknown, you have been warned. [ 7274.163139] ieee80211_crypt: registered algorithm 'NULL' [ 7274.163141] ieee80211_crypt: registered algorithm 'TKIP' [ 7274.163143] ieee80211_crypt: registered algorithm 'CCMP' [ 7274.163145] ieee80211_crypt: registered algorithm 'WEP' [ 7274.163146] [ 7274.163147] Linux kernel driver for RTL8192 based WLAN cards [ 7274.163148] Copyright (c) 2007-2008, Realsil Wlan [ 7274.164067] ==ep_num:4, in_ep_num:1, out_ep_num:3 [ 7274.164069] ==RtInPipes:3 [ 7274.164072] ==RtOutPipes:4 6 13 [ 7274.164075] ==txqueue_to_outpipemap for BK, BE, VI, VO, HCCA, TXCMD, MGNT, HIGH, BEACON: [ 7274.164077] 1 1 0 0 2 2 2 2 2 [ 7274.376646] usbcore: registered new interface driver rtl819xU ...and it certainly works well (your output will be a lot more verbose, as I'm preparing/ using some patches to tune down the excessive function tracing). that does do have a md5sum of 68533bf8078a9e00966a78c9f2da4b9b . This is the one included in rtl8192su_linux_2.6.0002.0708.2009.tar.gz from Realtek. Here starts the big problem, where does RealTek offer that firmware (and not random 3rd parties) and where the license for that firmware images? When I looked for a matching firmware (what led me to #579694), I couldn't find rtl8192su_linux_2.6.0002.0708.2009.tar.gz from any official source, and those obtainable from shady sources didn't include any license for the firmware. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#581554: firmware-realtek: Incorrect firmware
= 2,0 May 13 19:42:14 localhost kernel: [ 5681.465012] May 13 19:42:14 localhost kernel: [ 5681.465023] rtl819xU:qos active process with associate response received May 13 19:42:14 localhost kernel: [ 5681.465025] May 13 19:42:14 localhost kernel: [ 5681.465033] Associated successfully May 13 19:42:14 localhost kernel: [ 5681.465035] Using G rates:108 May 13 19:42:14 localhost kernel: [ 5681.465037] Successfully associated, ht not enabled(0, 0) seems to associate correctly May 13 19:42:14 localhost kernel: [ 5681.465040] =rtl8192SU_link_change 1 May 13 19:42:14 localhost kernel: [ 5681.467626] =ARFR0+rate_index*4:0xfff May 13 19:42:14 localhost kernel: [ 5681.475624] =rtl8192SU_link_change 2 May 13 19:42:14 localhost kernel: [ 5681.475626] normal associate May 13 19:42:14 localhost kernel: [ 5681.476344] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready May 13 19:42:14 localhost kernel: [ 5681.484084] alg name:TKIP May 13 19:42:14 localhost kernel: [ 5681.484100] rtl819xU:EnableHWSecurityConfig8192:, hwsec:1, pairwise_key:2, SECR_value:c May 13 19:42:14 localhost kernel: [ 5681.484102] May 13 19:42:14 localhost kernel: [ 5681.484259] rtl819xU:to setKey(), dev:88004bfb, EntryNo:4, KeyIndex:0, KeyType:2, MacAddr64:68:0c:2f:71:0a May 13 19:42:14 localhost kernel: [ 5681.484261] May 13 19:42:14 localhost kernel: [ 5681.488260] alg name:TKIP May 13 19:42:14 localhost kernel: [ 5681.488275] rtl819xU:to setKey(), dev:88004bfb, EntryNo:1, KeyIndex:1, KeyType:2, MacAddrff:ff:ff:ff:ff:ff May 13 19:42:14 localhost kernel: [ 5681.488277] May 13 19:42:16 localhost kernel: [ 5683.169621] dm_check_edca_turbo():iot peer is 0x0:unknown, bssid:64:68:0c:2f:71:0a May 13 19:42:24 localhost kernel: [ 5691.936010] wlan0: no IPv6 routers present Now it even got an IPv4 address. Hope it helps a bit. Judging from the log, the firmware uploads and works correctly up to the point of obtaining an IPv4 address - nothing unexpected to be seen. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#579694: firmware-nonfree: Please include rtl8192su/ r8192s_usb firmware into the (unreleased) firmware-realtek binary package.
Hi On Monday 03 May 2010, jida...@jidanni.org wrote: BH The driver is already there. To install the firmware right now: OK, very good. Now what I wish to do is essentially all the remaining steps of http://blog.xff.lt/2009/12/28/canyon-cnp-wf518n2-usb-wireless-linux/ but with only modprobe, no kernel compiling. With 2.6.33-2-686 all the .ko files seem to be there, but no matter how much I modprobe, ifconfig -a never shows the device. The USB ID might be missing, Greg has pushed many new ones into 2.6.34-rc over the weekend. A quick way to check if a previously unknown USB ID would be supported by a given kernel module is: $ lsusb [...] Bus 001 Device 004: ID 0bda:8171 Realtek Semiconductor Corp. [...] # modprobe r8192s_usb # echo 0bda 8171 /sys/bus/usb/drivers/r8192s_usb/new_id (ideally you connect/ hotplug the USB device only after this step) In my case http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c0087580b8d414f6874cfe93d2653212842fcb44 but there are also http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d615da093eb0f691a73a754589e2a4a24a6f1ca7 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=12840c63b0679f7fab88ea1cc26b52db8b574ce7 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=64a5a09218626464be35e0229d85b2ab0fcf03fd and one more between 2.6.32 and 2.6.33 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=488d3749620779ab2668c0dba2962836e51e3cd6 Be aware that r8192s_usb is a staging driver: r8192s_usb: module is from the staging directory, the quality is unknown, you have been warned. ...and this really applies. While it works quite well, unless you unplug, it is pretty noisy with debug and function tracing enabled. Furthermore even ignoring the mandatory porting to mac80211, it would have a long way to go, until it may get a chance to move out of staging into net/wireless/. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Bug#579694: firmware-nonfree: Please include rtl8192su/ r8192s_usb firmware into the (unreleased) firmware-realtek binary package.
Package: firmware-nonfree Version: 0.23 Severity: wishlist Hi The staging driver rtl8192su/ r8192s_usb, needed for the Longshine LCS-8131N2 0bda:8171 [1] USB wlan device, requires a binary firmware to function: a5ad703551efb108ba012b4b8a830d93 */lib/firmware/RTL8192SU/rtl8192sfw.bin [1.255016] usb 1-3: new high speed USB device using ehci_hcd and address 4 [1.371383] usb 1-3: New USB device found, idVendor=0bda, idProduct=8171 [1.371385] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [1.371387] usb 1-3: Product: RTL8188S WLAN Adapter [1.371389] usb 1-3: Manufacturer: Manufacturer Realtek [1.371391] usb 1-3: SerialNumber: 00c06d03 [...] [8.903762] r8192s_usb: module is from the staging directory, the quality is unknown, you have been warned. [8.906143] ieee80211_crypt: registered algorithm 'NULL' [8.906149] ieee80211_crypt: registered algorithm 'TKIP' [8.906150] ieee80211_crypt: registered algorithm 'CCMP' [8.906152] ieee80211_crypt: registered algorithm 'WEP' [8.906153] [8.906153] Linux kernel driver for RTL8192 based WLAN cards [8.906154] Copyright (c) 2007-2008, Realsil Wlan [8.907270] i801_smbus :00:1f.3: PCI INT C - GSI 18 (level, low) - IRQ 18 [...] [41118.440246] usb 1-3: firmware: requesting RTL8192SU/rtl8192sfw.bin It would be great, if the according firmware image could be added to firmware-nonfree as part of the new/unreleased firmware-realtek binary package. Please note that this had already been added to firmware-nonfree before, but was removed again as not confirmed to be working. [...] r15397 | benh | 2010-03-16 13:45:45 +0100 (Tue, 16 Mar 2010) | 1 line Revert r15379; this firmware is used by yet another Realtek driver r15379 | benh | 2010-03-15 14:54:31 +0100 (Mon, 15 Mar 2010) | 5 lines Add firmware-realtek package Initially contains Realtek RTL8192 firmware for use with rtl8192su driver. [...] It would be nice if revision r15379 could be reinstated, but please note that the kernel (or rather rtl8192su/ r8192s_usb) looks for the firmware under: $ /sbin/modinfo r8192s_usb | grep ^firmware firmware: RTL8192SU/rtl8192sfw.bin and not RTL8192/rtl8192sfw.bin, as previously assumed in r15379. Regards Stefan Lippers-Hollmann [1] http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=a2637855d16e8d9d7eb1a45081421a315982ddf0 From: Pavel Roskin pro...@gnu.org Date: Wed, 10 Mar 2010 04:11:07 + (-0500) Subject: Staging: rtl8192su: add USB ID for 0bda:8171 X-Git-Tag: next-20100429~4^2~25 X-Git-Url: http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fnext%2Flinux-next.git;a=commitdiff_plain;h=a2637855d16e8d9d7eb1a45081421a315982ddf0 -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.34-rc5-sidux-amd64 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash signature.asc Description: This is a digitally signed message part.
Bug#579694: firmware-nonfree: Please include rtl8192su/ r8192s_usb firmware into the (unreleased) firmware-realtek binary package.
Hi On Friday 30 April 2010, Ben Hutchings wrote: On Thu, 2010-04-29 at 23:45 +0200, Stefan Lippers-Hollmann wrote: Package: firmware-nonfree Version: 0.23 Severity: wishlist Hi The staging driver rtl8192su/ r8192s_usb, needed for the Longshine LCS-8131N2 0bda:8171 [1] USB wlan device, requires a binary firmware to function: [...] It would be great, if the according firmware image could be added to firmware-nonfree as part of the new/unreleased firmware-realtek binary package. Please note that this had already been added to firmware-nonfree before, but was removed again as not confirmed to be working. [...] It would be nice if revision r15379 could be reinstated, but please note that the kernel (or rather rtl8192su/ r8192s_usb) looks for the firmware under: $ /sbin/modinfo r8192s_usb | grep ^firmware firmware: RTL8192SU/rtl8192sfw.bin and not RTL8192/rtl8192sfw.bin, as previously assumed in r15379. The firmware I added in r15379 is apparently used with the rtl8192u driver. Since Debian doesn't distribute that driver I didn't see any point in distributing the corresponding firmware. Do you know where the firmware for rtl8192su is supposed to be available? Back in March I grabbed everything I could from Realtek's FTP site and didn't find it in there. I have to admit that I had quite some problems in finding the firmware image for rtl8192su/ r8192s_usb as well, but just tried the version you commited to svn://svn.debian.org/kernel/dists/trunk/firmware-nonfree/ in r15379 first - and found it to be working reliably with 6.5 MB/s (distance: 2 metres, little interference, wget(r8192s_usb) -- Atheros AR9100 MAC/BB Rev:0 AR2133 RF Rev:a2, ath9k, ath9k_rate_control -- GBit/s ethernet -- vsftpd(RTL8168d/8111d) from a local server). Looking at the RealTek server, I find this firmware image inside the RTL8192SE driver http://www.realtek.com.tw/downloads/downloadsView.aspx?Langid=1PNid=48PFid=48Level=5Conn=4DownTypeID=3GetDown=falseDownloads=true#2302 which currently resolves to rtl8192se_linux_2.6.0015.0127.2010.tar.gz 972eca3225a018e949a097ad7b91567f *rtl8192se_linux_2.6.0015.0127.2010/firmware/RTL8192SE/Realtek-Firmware-License.txt 70ff412e813567ee331ce5edf05f4ddc *rtl8192se_linux_2.6.0015.0127.2010/firmware/RTL8192SE/rtl8192sfw492.bin a65de7d458c00adbe96893341a3ff151 *rtl8192se_linux_2.6.0015.0127.2010/firmware/RTL8192SE/rtl8192sfw74.bin a5ad703551efb108ba012b4b8a830d93 *rtl8192se_linux_2.6.0015.0127.2010/firmware/RTL8192SE/rtl8192sfw.bin and I've been operating my RTL8188S successfully with rtl8192su/ r8192s_usb a5ad703551efb108ba012b4b8a830d93 */lib/firmware/RTL8192SU/rtl8192sfw.bin Searching for the term 'rtl8192sfw.bin' certainly suggests different results as well, the most prominent having a md5sum of 68533bf8078a9e00966a78c9f2da4b9b, which seems to originate from a driver version called rtl8192su_linux_2.6.0002.0708.2009, however I haven't found any legitimate source (nor copyright info for the supplied firmware images) for this tarball yet - while I didn't test that version, a clarification about the preferred firmware for rtl8192su/ r8192s_usb would be very appreciated. Regarding the firmware-nonfree/ firmware-realtek Debian package, it seems to be safe to add a5ad703551efb108ba012b4b8a830d93 *rtl8192se_linux_2.6.0015.0127.2010/firmware/RTL8192SE/rtl8192sfw.bin as known working (at least for me) origin for a5ad703551efb108ba012b4b8a830d93 */lib/firmware/RTL8192SU/rtl8192sfw.bin given that 972eca3225a018e949a097ad7b91567f *rtl8192se_linux_2.6.0015.0127.2010/firmware/RTL8192SE/Realtek-Firmware-License.txt is (sans whitespace changes) identical to http://svn.debian.org/wsvn/kernel/dists/trunk/firmware-nonfree/realtek/LICENSE Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004300255.04624.s@gmx.de
Re: Bug#561309: firmware-linux-nonfree: needs firmware for module r8169 (/rtl8168d-{1, 2}.fw)
Hi
On Saturday 19 December 2009, Ben Hutchings wrote:
It seems RTL8168D version 1 (but not version 2) was previously supported
without the need for this firmware update (rtl8168d-1.fw). So perhaps
the driver should carry on without it if it is missing. Please try
applying the following patch, which implements that behaviour.
[...]
This works for me, although it delays the system boot for 60s - waiting
for the non-existing firmware file to appear. Maybe the module should
additionally complain if the firmware couldn't be found or allow some other
method to avoid waiting for a non-existing firmware image?
$ dmesg | grep -i -e firmware -e eth0 -e 8169 -e 8168
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 :01:00.0: PCI INT A - GSI 16 (level, low) - IRQ 16
r8169 :01:00.0: setting latency timer to 64
r8169 :01:00.0: irq 28 for MSI/MSI-X
eth0: RTL8168d/8111d at 0xf7c6e000, 00:1c:c0:ee:22:88, XID 081000c0 IRQ 28
r8169 :01:00.0: firmware: requesting rtl8168d-1.fw
r8169: eth0: link up
r8169: eth0: link up
eth0: no IPv6 routers present
[...]
diff -u b/drivers/net/r8169.c b/drivers/net/r8169.c
--- b/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
[...]
@@ -1801,15 +1796,15 @@
mdio_plus_minus(ioaddr, 0x02, 0x0100, 0x0600);
mdio_plus_minus(ioaddr, 0x03, 0x, 0xe000);
- rtl_phy_write_fw(ioaddr, fw);
-
- release_firmware(fw);
- return 0;
+ if (request_firmware(fw, rtl8168d-1.fw, tp-pci_dev-dev) == 0) {
+ rtl_phy_write_fw(ioaddr, fw);
+ release_firmware(fw);
} else {
printk(KERN_INFO %s:
Failed to load rtl8168d-1.fw.\n, dev-name);
+ }
}
MODULE_FIRMWARE(rtl8168d-1.fw);
-static int rtl8168d_2_hw_phy_config(struct rtl8169_private *tp)
+static void rtl8168d_2_hw_phy_config(struct rtl8169_private *tp)
{
static struct phy_reg phy_reg_init_0[] = {
{ 0x1f, 0x0001 },
[...]
perhaps?
Would it be possible to provide some kind of firmware-cutter, to let the
user generate the required firmwares from a vanilla kernel checkout on the
target system, if needed (and if no copyright statement can be achieved)?
Regards
Stefan Lippers-Hollmann
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558316: netinstall fails with a Realtek RTL8169 Gigabit Ethernet card
Hi On Saturday 28 November 2009, Emmanuel Blot wrote: Package: netinstall Version: sorry, don't know how to obtain that info, see below for the package reference and date. Hardware: Intel D945GSEJT, Atom processor N270 @1.60Ghz, 1GB DDR2 Technical specs: http://downloadmirror.intel.com/17597/eng/D945GSEJT_TechProdSpec.pdf Software: Debian netinstall dated 05-09-09 04:25, downloaded from http://ftp.nl.debian.org/debian/dists/lenny/main/installer-i386/current/images/netboot/ Linux kernel: 2.6.26-2-486 #1 Wed Aug 19 05:40:02 UTC 2009 [...] The Intel D945GSEJT mainboard ships with a RealTek rtl8168d network card, which wasn't supported before kernel 2.6.31. Be aware that starting with Debian's kernel 2.6.32, you'll need a binary firmware as well (rtl8168d-1.fw and rtl8168d-2.fw), which are not available yet. :eth0: RTL8169 at 0xf882, 00:1c:c0:xx:xx:xx, XID 281000c0 IRQ 219 this seems to be a rtl8168d-2. r8169: eth0: link down, while the physical link is actually plugged in: * status leds on Ethernet socket are green, * status leds on the peer switch device to which the device is connected are green as well lspci reports: 01.00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03) I don't think the issue is related to the environment, as on the very same hardware environment and the same PXE/DHCP server, the Ubuntu 9.10 net installation successfully completes under the same conditions. Let me know if you need more details. Regards Stefan Lippers-Hollmann signature.asc Description: This is a digitally signed message part.
Re: 2.6.32 experimental
Hi On Friday 20 November 2009, Ben Hutchings wrote: I intend to upload 2.6.32-rc8 to experimental today. [...] Just a heads up, drivers/staging/rtl8192e/r819xE_phy.c (a newly merged staging driver in 2.6.32) may have introduced new firmware blobs: - Rtl8190PciAGCTAB_Array - Rtl8190PciPHY_REGArray - Rtl8190PciPHY_REG_1T2RArray - Rtl8190PciRadioA_Array - Rtl8190PciRadioB_Array - Rtl8190PciRadioC_Array - Rtl8190PciRadioD_Array - Rtl8192PciEAGCTAB_Array - Rtl8192PciEPHY_REG_1T2RArray - Rtl8192PciERadioA_Array - Rtl8192PciERadioB_Array - possibly more basically the same content which was pruned from drivers/staging/rtl8192su/r8192S_FwImgDTM.h (dropped in 2.6.32) drivers/staging/rtl8192su/r8192SU_HWImg.c drivers/staging/rtl8192su/r819xU_firmware_img.c (dropped in 2.6.32) in 2.6.31, therefore I'd suggest to add the following patch (applies to r14655 of dists/trunk/linux-2.6/): Signed-off-by: Stefan Lippers-Hollmann s@gmx.de Index: debian/patches/debian/dfsg/drivers-staging-rtl8192e-disable.patch === --- debian/patches/debian/dfsg/drivers-staging-rtl8192e-disable.patch (revision 0) +++ debian/patches/debian/dfsg/drivers-staging-rtl8192e-disable.patch (revision 0) @@ -0,0 +1,9 @@ +--- a/drivers/staging/rtl8192e/Kconfig b/drivers/staging/rtl8192e/Kconfig +@@ -1,5 +1,6 @@ + config RTL8192E + tristate RealTek RTL8192E Wireless LAN NIC driver ++ depends on BROKEN + depends on PCI WLAN + depends on WIRELESS_EXT + default N Index: debian/patches/debian/dfsg/files-1 === --- debian/patches/debian/dfsg/files-1 (revision 14655) +++ debian/patches/debian/dfsg/files-1 (working copy) @@ -56,10 +56,10 @@ rm drivers/staging/rt3090/firmware.h -rm drivers/staging/rtl8192su/r8192S_FwImgDTM.h rm drivers/staging/rtl8192su/r8192SU_HWImg.c -rm drivers/staging/rtl8192su/r819xU_firmware_img.c +rm drivers/staging/rtl8192e/r819xE_phy.c + rm drivers/staging/sxg/sxgphycode-1.2.h rm drivers/staging/vt6656/firmware.c -- By the way, is there some kind of description how to extract rtl8168d-1.fw and rtl8168d-2.fw from the vanilla kernel source? I would have access to a RTL8168d/8111d, RTL_GIGA_MAC_VER_25 device and it seems to be pretty common on newer mainboards). eth0: RTL8168d/8111d at 0xf7e1a000, 00:1c:c0:ee:12:58, XID 081000c0 IRQ 28 Please consider applying http://bugs.debian.org/555680#15 as well, to remove some additional means of providing a wlan password from bugreports. Regards Stefan Lippers-Hollmann -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#555680: System information in bug reports may be security-sensitive
Hi
r14441 [1], hide wireless keys and wake-on-LAN password when including
network configuration in bug reports (bug #555680).
It is unfortunately not enough to prune wireless-key from bugreports, as
wpasupplicant defines additional means to configure passwords for wireless
links[2], namely wpa-psk and wpa-password. Additionally I suggest to prune
commented out lines as well, as these might contain passwords or other
sensitive information and have no relevance for bugreporting.
The attached, valid, /etc/network/interfaces example illustrates the
problem with these means of configuration. The following patch applies to
sid and trunk of linux-2.6 (r14649).
[1]
http://svn.debian.org/viewsvn/kernel/dists/sid/linux-2.6/debian/templates/image.plain.bug/include-network?r1=14441r2=14597
[2]
http://svn.debian.org/viewsvn/pkg-wpa/wpasupplicant/trunk/debian/README.Debian?view=markup
Signed-off-by: Stefan Lippers-Hollmann s@gmx.de
Index: debian/templates/image.plain.bug/include-network
===
--- debian/templates/image.plain.bug/include-network(revision 14649)
+++ debian/templates/image.plain.bug/include-network(working copy)
@@ -5,7 +5,10 @@
echo '** Network interface configuration:' 3
# Hide passwords/keys
awk '$1 ~ /^wireless-key/ { gsub(., *, $2); }
+ $1 ~ /^wpa-psk/ { gsub(., *, $2); }
+ $1 ~ /^wpa-password/ { gsub(., *, $2); }
$1 == ethtool-wol { gsub(., *, $3); }
+ !/^\#/
{ print; }
' /etc/network/interfaces 3
echo 3
# Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or
# /usr/share/doc/ifupdown/examples for more information.
auto lo
iface lo inet loopback
allow-hotplug eth0
iface eth0 inet dhcp
allow-hotplug wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface linksys_aes inet dhcp
iface default inet dhcp
auto wlan1
iface wlan1 inet dhcp
wpa-ssid something
wpa-psk 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
# wpa-psk 2123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
auto wlan2
iface wlan2 inet dhcp
wpa-ssid somethingelse
wpa-password myplaintextpassword
# wpa-password yourplaintextpassword
auto wlan3
iface wlan3 inet dhcp
wireless-essid somethingveryelse
wireless-key mypassword
# wireless-key yourpassword
Bug#533357: linux-2.6: please add b43: Add fw capabilities, to support OpenFWWF 5.1
).
-- manual modprobe overrides required, regressing performance with the
proprietary firmware and introducing potential upgrade hassles.
- starting with 2.6.31 (or depending on your decision linux-2.6 2.6.30-2),
openfwwf would make many b43 based wlan devices work with only dfsg-free
components required - the proprietary firmware can be transparently
coinstalled and supersedes openfwwf, if present.
Regards
Stefan Lippers-Hollmann
[1] BUG #513974: ITP: openfwwf -- Open Firmware for Broadcom b43 wlan
devices
Vcs-Svn: svn://svn.berlios.de/fullstory/openfwwf/trunk
Vcs-Browser:
http://svn.berlios.de/svnroot/repos/fullstory/openfwwf/trunk/
[2] BUG #513973: ITP: b43-asm -- assembler and disassembler for Broadcom
BCM43xx firmware
Vcs-Svn: svn://svn.berlios.de/fullstory/b43-asm/trunk
Vcs-Browser:
http://svn.berlios.de/svnroot/repos/fullstory/b43-asm/trunk/
[3] http://www.ing.unibs.it/openfwwf/
[4] Broadcom wlan chipsets currently supported by OpenFWWF 5.1:
- BCM4306
- BCM4311 revision 1
- BCM4318
- BCM4320
[5]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=403a3a136122457165321e90b7569a321cc9ac12
[6]
http://svn.berlios.de/svnroot/repos/fullstory/openfwwf/trunk/debian/README.Debian
[7] options b43 nohwcrypt=1 qos=0
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-0.slh.2-sidux-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
From 403a3a136122457165321e90b7569a321cc9ac12 Mon Sep 17 00:00:00 2001
From: Michael Buesch m...@bu3sch.de
Date: Mon, 8 Jun 2009 21:04:57 +0200
Subject: [PATCH 16394/17325] b43: Add fw capabilities
Add automagic feature flags, so the firmware can tell the driver
about supported features and the driver can switch features on/off as
needed.
Signed-off-by: Michael Buesch m...@bu3sch.de
Signed-off-by: Stefan Lippers-Hollmann s@gmx.de
Tested-by: Stefan Lippers-Hollmann s@gmx.de
Signed-off-by: John W. Linville linvi...@tuxdriver.com
---
drivers/net/wireless/b43/b43.h | 14 +
drivers/net/wireless/b43/dma.c |2 +-
drivers/net/wireless/b43/main.c | 56 +++---
drivers/net/wireless/b43/main.h |1 -
drivers/net/wireless/b43/pio.c |2 +-
5 files changed, 61 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/b43/b43.h b/drivers/net/wireless/b43/b43.h
index 75aede0..f580c28 100644
--- a/drivers/net/wireless/b43/b43.h
+++ b/drivers/net/wireless/b43/b43.h
@@ -163,6 +163,7 @@ enum {
#define B43_SHM_SH_WLCOREREV 0x0016 /* 802.11 core revision */
#define B43_SHM_SH_PCTLWDPOS 0x0008
#define B43_SHM_SH_RXPADOFF 0x0034 /* RX Padding data offset (PIO only) */
+#define B43_SHM_SH_FWCAPA 0x0042 /* Firmware capabilities (Opensource firmware only) */
#define B43_SHM_SH_PHYVER 0x0050 /* PHY version */
#define B43_SHM_SH_PHYTYPE 0x0052 /* PHY type */
#define B43_SHM_SH_ANTSWAP 0x005C /* Antenna swap threshold */
@@ -297,6 +298,10 @@ enum {
#define B43_HF_MLADVW 0x0010ULL /* N PHY ML ADV workaround (rev = 13 only) */
#define B43_HF_PR45960W 0x0800ULL /* PR 45960 workaround (rev = 13 only) */
+/* Firmware capabilities field in SHM (Opensource firmware only) */
+#define B43_FWCAPA_HWCRYPTO 0x0001
+#define B43_FWCAPA_QOS 0x0002
+
/* MacFilter offsets. */
#define B43_MACFILTER_SELF 0x
#define B43_MACFILTER_BSSID 0x0003
@@ -596,6 +601,13 @@ struct b43_wl {
/* Pointer to the ieee80211 hardware data structure */
struct ieee80211_hw *hw;
+ /* The number of queues that were registered with the mac80211 subsystem
+ * initially. This is a backup copy of hw-queues in case hw-queues has
+ * to be dynamically lowered at runtime (Firmware does not support QoS).
+ * hw-queues has to be restored to the original value before unregistering
+ * from the mac80211 subsystem. */
+ u16 mac80211_initially_registered_queues;
+
struct mutex mutex;
spinlock_t irq_lock;
/* R/W lock for data transmission.
@@ -749,6 +761,8 @@ struct b43_wldev {
bool dfq_valid; /* Directed frame queue valid (IBSS PS mode, ATIM) */
bool radio_hw_enable; /* saved state of radio hardware enabled state */
bool suspend_in_progress; /* TRUE, if we are in a suspend/resume cycle */
+ bool qos_enabled; /* TRUE, if QoS is used. */
+ bool hwcrypto_enabled; /* TRUE, if HW crypto acceleration is enabled. */
/* PHY/Radio device. */
struct b43_phy phy;
diff --git a/drivers/net/wireless/b43/dma.c b/drivers/net/wireless/b43/dma.c
index eae680b..7964cc3 100644
--- a/drivers/net/wireless/b43/dma.c
+++ b/drivers/net/wireless/b43/dma.c
@@ -1285,7 +1285,7 @@ static struct b43_dmaring *select_ring_by_priority(struct b43_wldev *dev,
{
struct b43_dmaring *ring;
- if (b43_modparam_qos) {
+ if (dev
Re: Forthcoming changes in kernel-package
Hi On Montag, 9. Februar 2009, Michael Tautschnig wrote: [...] c. his means there will be no need for /etc/kernel-img.conf file any more. [...] Isn't this file also read in the postinst of the official kernels? In FAI we had several issues when kernel-img.conf was missing or hadn't had the proper values in there. [...] As of yet kernel-package is still used in the official kernel builds[1], by using make-kpkg to build and create the linux-image packages (linux-headers is assembled manually). linux-2.6/debian/rules.real [...] kpkg_image := $(setup_env) ifdef DEBIAN_KERNEL_JOBS kpkg_image += CONCURRENCY_LEVEL=$(DEBIAN_KERNEL_JOBS) endif kpkg_image += make-kpkg --arch '$(firstword $(KPKG_ARCH) $(ARCH))' --cross-compile=- --stem linux --config silentoldconfig ifneq ($(INITRAMFS),False) kpkg_image += --initrd endif ifdef KPKG_SUBARCH kpkg_image += --subarch '$(KPKG_SUBARCH)' endif [...] Which is called from the following targets: $(STAMPS_DIR)/setup_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_kernel-package: [...]$(kpkg_image) configure [...] $(STAMPS_DIR)/build_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_kernel-package: [...]$(kpkg_image) build [...] install-image_$(ARCH)_$(FEATURESET)_$(FLAVOUR)_kernel-package: [...]$(kpkg_image) kernel-image [...] Due to this, the bootloader setup relies on postinst_hook/ postrm_hook and do_initrd in /etc/kernel-img.conf and honours the rest of the settings. Regards Stefan Lippers-Hollmann [1] http://svn.debian.org/viewsvn/kernel/dists/trunk/linux-2.6/debian/rules.real?view=markup signature.asc Description: This is a digitally signed message part.
Bug#497505: virtualbox-ose doesn't work with linux 2.6.26
Hi Just as a status update, Ubuntu has added a patch[1], disabling interrupts in the critical boot up path, to their kernel today, which avoids this issue from triggering - and after initial testing, it seems to succeed. On the other hand, looking at the VirtualBox bug tracker[2], it seems to have been identified as a real bug in VirtualBox' recompiler (which is supposed to have been fixed in VirtualBox 2.0.2). Given the circumstances that this patch to the kernel only seems to paper around the real issue, I do not recommend to add it to Debian's kernel though. Regards Stefan Lippers-Hollmann [1] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-intrepid.git;a=commitdiff;h=00d6c877bc34ff6e2705385764f6e7426cd362a8 [2] http://www.virtualbox.org/ticket/1875#comment:7 signature.asc Description: This is a digitally signed message part.
Bug#479271: linux-kbuild-2.6.25: custom modpost breaks building external modules
Package: linux-kbuild-2.6.25
Version: 2.6.25-1
Severity: important
Tags: patch
modpost has gained additional cli parameters in 2.6.25, while the custom
wrapper included in linux-kbuild-2.6 hasn't been adapted to those yet.
This breaks compiling any external module package with/ against it (this
is not specific to lirc or amd64):
$ LANG= m-a --kvers-list 2.6.25-1-amd64 --kernel-dir
/usr/src/linux-headers-2.6.25-1-amd64/ --userdir /tmp/pkg/ --text-mode build
lirc
[...]
mkdir -p /tmp/pkg/usr_src/modules/lirc/drivers/lirc_dev/.tmp_versions ; rm -f
/tmp/pkg/usr_src/modules/lirc/drivers/lirc_dev/.tmp_versions/*
/usr/bin/make -f scripts/Makefile.build
obj=/tmp/pkg/usr_src/modules/lirc/drivers/lirc_dev
gcc-4.1 -Wp,-MD,/tmp/pkg/usr_src/modules/lirc/drivers/lirc_dev/.lirc_dev.o.d
-nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.1.3/include -D__KERNEL__
-Iinclude -include include/linux/autoconf.h -Wall -Wundef -Wstrict-prototypes
-Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Os -fno-stack-protector -m64
-mtune=generic -mno-red-zone -mcmodel=kernel -funit-at-a-time
-maccumulate-outgoing-args-pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
-fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign
-DIRCTL_DEV_MAJOR=61 -DEXPORT_SYMTAB -DHAVE_CONFIG_H -I. -I. -I../..
-I/tmp/pkg/usr_src/modules/lirc/drivers/lirc_dev/../..
-I/usr/src/linux-headers-2.6.25-1-amd64//include/
-I/usr/src/linux-headers-2.6.25-1-amd64//drivers/media/video/ -DMODULE
-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(lirc_dev)
-DKBUILD_MODNAME=KBUILD_STR(lirc_dev) -c -o
/tmp/pkg/usr_src/modules/lirc/drivers/lirc_dev/.tmp_lirc_dev.o
/tmp/pkg/usr_src/modules/lirc/drivers/lirc_dev/lirc_dev.c
(cat /dev/null; echo
kernel//tmp/pkg/usr_src/modules/lirc/drivers/lirc_dev/lirc_dev.ko;)
/tmp/pkg/usr_src/modules/lirc/drivers/lirc_dev/modules.order
Building modules, stage 2.
/usr/bin/make -f /usr/src/linux-headers-2.6.25-1-amd64/scripts/Makefile.modpost
scripts/mod/modpost -m -i
/usr/src/linux-headers-2.6.25-1-amd64/Module.symvers -I
/tmp/pkg/usr_src/modules/lirc/drivers/lirc_dev/Module.symvers -o
/tmp/pkg/usr_src/modules/lirc/drivers/lirc_dev/Module.symvers -S -w -c -s
scripts/mod/modpost: invalid option -- S
make[6]: *** [__modpost] Error 1
make[5]: *** [modules] Error 2
Please apply the attached patch, which tells linux-kbuild-2.6's custom
modpost wrapper about the newly added cli parameters supported, and
required, by kernel 2.6.25's modpost. Successfully tested on amd64/ i386
and using module-assistant/ a linux-modules-extra-2.6 variant with several
different ${modules}-source packages.
Regards
Stefan Lippers-Hollmann
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.25-1.slh.2-sidux-amd64 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages linux-kbuild-2.6.25 depends on:
ii libc6 2.7-10 GNU C Library: Shared libraries
linux-kbuild-2.6.25 recommends no packages.
-- no debconf information
diff -Nrup a/src/mod/modpost.c b/src/mod/modpost.c
--- a/src/mod/modpost.c 2008-05-04 00:48:29.0 +0200
+++ b/src/mod/modpost.c 2008-05-04 00:49:15.0 +0200
@@ -13,17 +13,21 @@ int main (int argc, char *argv[])
int opt;
FILE *file;
- while ((opt = getopt (argc, argv, ai:I:mo:sw)) != -1)
+ while ((opt = getopt (argc, argv, i:I:cmsSo:awM:K:)) != -1)
{
switch(opt)
{
- case 'a':
case 'i':
case 'I':
+ case 'c':
case 'm':
- case 'o':
case 's':
+ case 'S':
+ case 'o':
+ case 'a':
case 'w':
+ case 'M':
+ case 'K':
break;
default:
return EXIT_FAILURE;
signature.asc
Description: This is a digitally signed message part.
busybox: no longer falles back to busybox applets if no executable if found
Package: busybox
Version: 1:1.9.1-3
Severity: important
CC'ing initramfs-tools maintainer, as it directly affects hooks into
initramfs-tools.
BusyBox 1.1.3 implemented a fallback to its own applets in case no
executable could be found:
BusyBox v1.1.3 (Debian 1:1.1.3-5) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
~ $ printf foo\n
foo
~ $ PATH=
~ $ export PATH
~ $ printf foo\n
foo
while BusyBox 1.9.1 just throws an error
BusyBox v1.9.1 (2008-03-22 22:06:19 UTC) built-in shell (ash)
Enter 'help' for a list of built-in commands.
~ $ printf foo\n
foo
~ $ PATH=
~ $ export PATH
~ $ printf foo\n
ash: printf: not found
Even though this behaviour is understandable, it does break hooks into
current initramfs-tools making use of functionality neither provided by
klibc nor busybox built-ins (but only as applets for busybox), because
initramfs-tools doesn't create {hard,sym}links to busybox (#338405).
Potentially affected packages (not checked in depths):
- bootcd-mkinitramfs (it seems to use grep)
- cryptsetup (it does use basename #466240 and seems to use grep)
- evms (it seems to use grep)
- initramfs-tools (it does use printf and seems to use awk as well)
- live-initramfs (it seems to use awk, basename, grep and printf)
- loop-aes-utils (it seems to use grep)
- ltsp-client-core (it seems to use grep
- mdadm (it seems to use grep)
- nbd-client (it seems to use grep)
- splashy (it seems to use grep)
- uswsusp (it seems to use grep)
A workaround seems to be enabling
CONFIG_FEATURE_PREFER_APPLETS=y
CONFIG_FEATURE_SH_STANDALONE=y
FEATURE_SH_STANDALONE was enabled in busybox 1.1.3, even though it prefers
busybox applets in favour of shipped executables (unless called with full
path names), it might be needed until a better long term solution can be found.
Regards
Stefan Lippers-Hollmann
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.24-2.6.24.3.slh.11-sidux-amd64 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages busybox depends on:
ii libc6 2.7-9 GNU C Library: Shared libraries
busybox recommends no packages.
-- no debconf information
signature.asc
Description: This is a digitally signed message part.
