Bug#649567: linux-2.6: Please enable BCMA and BCMA_HOST_PCI

2011-11-22 Thread Geoff Simmons 
On Tue, Nov 22, 2011 at 02:44:13PM +, Ben Hutchings wrote:
> On Tue, 2011-11-22 at 19:20 +1100, Geoff Simmons wrote:
> > Enabling these would allow the b43 driver to receive BCMA bus support
> > (B43_BCMA, enabled by default) and operate Broadcom BCM43224 and
> > BCM43225 based PCIe wireless LAN devices; BCM4331 (HT-PHY) support is
> > anticipated for Linux 3.2.
> >
> > A consequence of enabling BCMA_HOST_PCI is the addition of device IDs to
> > the produced bcma module, four of these are claimed by the brcmsmac part
> > of the brcm80211 staging driver.
>
> brcmsmac apparently has better support for these devices, and is moving
> out of staging in 3.2.
>
> So whatever we do, we shouldn't enable those device IDs in b43 as well.

OK.  Could only the BCM4331 device ID (14e4:4331) be referenced in
bcma/host_pci.c as an alternative?

This device is found in the MacBookPro8,1/2/3 and TTBOMK is not currently
supported by brcmsmac (per "recognized PCI IDs" in brcmsmac/mac80211_if.c)
or the out-of-tree broadcom-sta driver.

Geoff



-- 
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/2023034839.gf4...@chmmr.gsimmons.org

Bug#649673: [powerpc] fails to boot - immediate oops

2011-11-22 Thread Jonathan Nieder 
Hi,

cfr wrote:

> Kernel oops. Boot failed. Turned machine off at switch. Restarted
> choosing to boot the 2.6 kernel at the second prompt.
[...]
> I don't have access to a digital camera right now though I can try to
> get a shot with one if required. I don't have any idea how to use a
> serial or net console - or even what these are. If somebody points me to
> a document, I will try to figure it out, though.

Thanks!  See [1].

A serial console would presumably require a USB-to-serial converter,
so that's likely to be more fussy[2].

[1] http://www.kernel.org/doc/Documentation/networking/netconsole.txt
[2] http://www.kernel.org/doc/Documentation/serial-console.txt



-- 
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/2023031433.ga15...@elie.hsd1.il.comcast.net

Bug#649673: linux-image-3.1.0-1-powerpc: fails to boot - immediate oops

2011-11-22 Thread cfr 
Package: linux-2.6

Version: 3.1.1-1
Severity: important

What led up to the situation?

Updated default kernel from testing to linux-image-3.1.0-1-powerpc.

Received warning messages regarding possible missing firmware for
wireless card and graphics driver (broadcom and nouveau). It warned me
that I might need to enable contrib and/or non-free. These are already
enabled - I had to enable them to get the broadcom card to work. As far
as I can tell, my wireless firmware is up to date. Even if it was
missing, it would not (should not) prevent booting. I'm not convinced I
am using non-free firmware for my nvidia graphics card. If I am, it will
be the first time nvidia show any sign of support for their cards on PPC
under linux!

I clicked on the restart-required icon for the package manager in the
system tray. (I'd call it a menubar but that's refugees from Apple for
you. So I might have the term wrong.)

I chose to restart immediately.

System went down, restarted.

Choose Linux at the first boot prompt; default at the second.

Kernel oops. Boot failed. Turned machine off at switch. Restarted
choosing to boot the 2.6 kernel at the second prompt.

Before restarting after the upgrade, the only thing I fiddled with was
that I changed the symlinks under /boot so that the two for the "old"
image pointed at the 2.6 series kernel rather than the previous 3.0
series kernel. I did this because the latter has proved very unstable
and panics frequently whereas the former seems much more tolerant.

What exactly did you do (or not do) that was effective (or
 ineffective)?

Booting with the 2.6 series kernel was effective.

What was the outcome of this action?

Machine booted, is usable. But obviously this is a different kernel and
not the one I'm reporting a bug against.

What outcome did you expect instead?

That's what I expected. I expected the 2.6 series kernel to boot OK
because it worked fine before and I knew I could access it using "old"
because I'd changed the symlinks as explained above. (I know it is
possible to boot another image but I didn't want to have to figure this
out if the new 3.0 kernel proved as problematic as the previous one - I
wanted a safety net I could rely on and access easily.)

Note that BTS could not be contacted so I have no way of knowing if this
is already reported.

I don't have access to a digital camera right now though I can try to
get a shot with one if required. I don't have any idea how to use a
serial or net console - or even what these are. If somebody points me to
a document, I will try to figure it out, though.

The two things which reliably caused the previous kernel to panic were
certain USB devices and some kind of issue with upgrading bluetooth
modules. (I don't actually use bluetooth but it seemed impossible not to
have them and impossible to have them. Essentially the kernel module
could only be updated by booting into the 2.6 series kernel.) But this
one panicked on boot so I am not even getting that far.

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
revision: 1.2 (pvr 8003 0102)
platform: PowerMac
model   : PowerBook6,8
machine : PowerBook6,8
motherboard : PowerBook6,8 MacRISC3 Power Macintosh 

** PCI devices:
:00:0b.0 Host bridge [0600]: Apple Computer Inc. UniNorth 2 AGP [106b:0034]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: agpgart-uninorth

:00:10.0 VGA compatible controller [0300]: nVidia Corporation NV34M 
[GeForce FX Go5200] [10de:0329] (rev a1) (prog-if 00 [VGA controller])
Subsystem: nVidia Corporation Powerbook G4 [10de:0010]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: nouveau

0001:10:0b.0 Host bridge [0600]: Apple Computer Inc. UniNorth 2 PCI [106b:0035]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- SERR- 
Kernel driver in use: b43-pci-bridge

0001:10:17.0 Unassigned class [ff00]: Apple Computer Inc. KeyLargo/Intrepid Mac 
I/O [106b:003e]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- TAbort- 
SERR- 
Kernel driver in use: ohci_hcd

0001:10:1b.1 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 43) 
(prog-if 10 [OHCI])
Subsystem: NEC Corporation Hama USB 2.0 CardBus [1033:0035]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWIN

Re: Increasing minimum 'i386' processor

2011-11-22 Thread Matthias Klose 
On 11/20/2011 01:08 AM, Guillem Jover wrote:
> Hi!
> 
> On Sat, 2011-11-19 at 22:42:11 +, Ben Hutchings wrote:
>> The i386 architecture was the first in Linux and in Debian, but we have
>> long since dropped support for the original i386-compatible processors
>> and now require a minimum of a 486-class processor.
>>
>> I think it is time to increase the minimum requirement to 586-class, if
>> not for wheezy then immediately after.  (Later it should be increased
>> further, and eventually i386 should be reduced to a partial architecture
>> that may be installed on amd64 systems.)  This would allow the use of
>> optimisations and new instructions throughout userland that improve
>> performance for the vast majority of users.
> 
> It seems gcc has been targetting i586 instruction set by default since
> gcc 4.4.0-1~exp1, although the triplet was not changed to match. On the
> discussion regarding multiarch tuples I proposed we should switch the
> triplet back to i386-linux-gnu to avoid this kind of confusion, fix the
> internal inconsistency and the one with other architectures (which do
> not track the base instruction set in the triplet) and so that we can
> use them directly as the multiarch tuples.
> 
> For more details please see:
> 
>   
>   

No, that's wrong. i386-linux-gnu has a different ABI for at least some libraries
(libstdc++) than i486-linux-gnu.  Unfortunately the proposal to use
ix86-linux-gnu for the i386 multiarch triplet didn't find a consensus.

  Matthias


-- 
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/4ecc34e9.6090...@debian.org

Re: Increasing minimum 'i386' processor

2011-11-22 Thread Matthias Klose 
On 11/19/2011 11:42 PM, Ben Hutchings wrote:
> The i386 architecture was the first in Linux and in Debian, but we have
> long since dropped support for the original i386-compatible processors
> and now require a minimum of a 486-class processor.
> 
> I think it is time to increase the minimum requirement to 586-class, if
> not for wheezy then immediately after.

note that squeeze is built this way, and single packages like openjdk only build
for 586.

> (Later it should be increased
> further, and eventually i386 should be reduced to a partial architecture
> that may be installed on amd64 systems.)  This would allow the use of
> optimisations and new instructions throughout userland that improve
> performance for the vast majority of users.

could you give numbers what kind of improvements you would expect?  The biggest
burden for i386 is the register pressure, which you won't fix with targeting a
newer processor.  The better approach would be a new port, the x32 architecture;
I don't know if anybody did look into building a distribution for this
architecture yet.  The next thing could be to default to sse2 math instead of
x87 (didn't look if this is already the default for x32).

  Matthias


-- 
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/4ecc33cd.7040...@debian.org

Bug#649540: ACPI failures on Dell Latitude E6220

2011-11-22 Thread Juliusz Chroboczek 
Hi,

[CC-ing the relevant Debian bug report.]

Running on a Dell Latitude E6220 with BIOS A03, battery life is
surprisingly low, the thermal zone is always at 25 degrees (although
both coretemp and i8k indicate reasonable values), and reboot hangs
without reboot=pci.

With no parameters, the kernel complains:

> [  227.525937] ACPI Exception: AE_TIME, Returned by Handler for 
> [EmbeddedControl] (20110623/evregion-478)
> [  227.525946] ACPI Error: Method parse/execution failed 
> [\_SB_.PCI0.LPCB.ECDV.ECR1] (Node 880128e7a3d0), AE_TIME 
> (20110623/psparse-536)
> [  227.525957] ACPI Error: Method parse/execution failed [\ECRB] (Node 
> 880128e7a268), AE_TIME (20110623/psparse-536)
> [  227.525963] ACPI Error: Method parse/execution failed [\ECGB] (Node 
> 880128e7adf8), AE_TIME (20110623/psparse-536)
> [  227.525968] ACPI Error: Method parse/execution failed 
> [\_SB_.PCI0.VID_.LCD_._ADR] (Node 880128e7e470), AE_TIME 
> (20110623/psparse-536)
> [  227.526053] parport_pc 00:08: disabled
> [  228.025281] ACPI: EC: input buffer is not empty, aborting transaction

A full log is attached; the output of acpidump is on

  http://www.pps.jussieu.fr/~jch/private/latitude-e6220-acpidump.txt

(I cannot attach it since it apparently trips a virus scanner somewhere.)

Adding acpi_serialize causes udev to hang; if you wait for long enough,
udev enters a timeout loop (repeatedly timing out when trying to call
modprobe).

Adding reboot=pci makes reboot work.

Adding ec_delay=1000 has no apparent effect.

Adding pcie_aspm=force has no apparent effect.

-- Juliusz Chroboczek

[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.1.0-1-amd64 (Debian 3.1.1-1) 
(b...@decadent.org.uk) (gcc version 4.6.2 (Debian 4.6.2-4) ) #1 SMP Mon Nov 14 
08:02:25 UTC 2011
[0.00] Command line: BOOT_IMAGE=/vmlinuz-3.1.0-1-amd64 
root=/dev/mapper/pirx-root ro reboot=pci pcie_aspm=force quiet
[0.00] BIOS-provided physical RAM map:
[0.00]  BIOS-e820:  - 00091400 (usable)
[0.00]  BIOS-e820: 00091400 - 000a (reserved)
[0.00]  BIOS-e820: 000e - 0010 (reserved)
[0.00]  BIOS-e820: 0010 - 2000 (usable)
[0.00]  BIOS-e820: 2000 - 2020 (reserved)
[0.00]  BIOS-e820: 2020 - 4000 (usable)
[0.00]  BIOS-e820: 4000 - 4020 (reserved)
[0.00]  BIOS-e820: 4020 - caa29000 (usable)
[0.00]  BIOS-e820: caa29000 - caa6d000 (reserved)
[0.00]  BIOS-e820: caa6d000 - cadb7000 (usable)
[0.00]  BIOS-e820: cadb7000 - cade7000 (reserved)
[0.00]  BIOS-e820: cade7000 - cafe7000 (ACPI NVS)
[0.00]  BIOS-e820: cafe7000 - cafff000 (ACPI data)
[0.00]  BIOS-e820: cafff000 - cb00 (usable)
[0.00]  BIOS-e820: cb80 - cfa0 (reserved)
[0.00]  BIOS-e820: fed1c000 - fed2 (reserved)
[0.00]  BIOS-e820: ffc0 - ffc2 (reserved)
[0.00]  BIOS-e820: 0001 - 00012e00 (usable)
[0.00] NX (Execute Disable) protection: active
[0.00] DMI 2.6 present.
[0.00] DMI: Dell Inc. Latitude E6220/0R97MN, BIOS A03 09/19/2011
[0.00] e820 update range:  - 0001 (usable) 
==> (reserved)
[0.00] e820 remove range: 000a - 0010 (usable)
[0.00] No AGP bridge found
[0.00] last_pfn = 0x12e000 max_arch_pfn = 0x4
[0.00] MTRR default type: uncachable
[0.00] MTRR fixed ranges enabled:
[0.00]   0-9 write-back
[0.00]   A-B uncachable
[0.00]   C-F write-protect
[0.00] MTRR variable ranges enabled:
[0.00]   0 base 0 mask F8000 write-back
[0.00]   1 base 08000 mask FC000 write-back
[0.00]   2 base 0C000 mask FF800 write-back
[0.00]   3 base 0C800 mask FFC00 write-back
[0.00]   4 base 0CB00 mask FFF00 uncachable
[0.00]   5 base 1 mask FE000 write-back
[0.00]   6 base 12000 mask FF000 write-back
[0.00]   7 base 12E00 mask FFE00 uncachable
[0.00]   8 disabled
[0.00]   9 disabled
[0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[0.00] e820 update range: cb00 - 0001 (usable) 
==> (reserved)
[0.00] last_pfn = 0xcb000 max_arch_pfn = 0x4
[0.00] found SMP MP-table at [880f1c40] f1c40
[0.00] initial memory mapped : 0 - 2000
[0.00] Base memory trampoline at [8808c000] 8c000 size 20480
[

Bug#649534: Kernel panic while doing nothing much in particular, after hibernating twice and suspending once

2011-11-22 Thread Jonathan Nieder 
Sam Morris wrote:

> The backtrace definitely didn't make it to syslog. It did appear on the
> screen however; photo attached.

Thanks.  Here's the call chain:

 system_call_fastpath -> sys_pipe2 -> do_pipe_flags ->
  create_write_pipe -> recalc_sigpending ->
  new_inode_pseudo -> alloc_inode -> kmem_cache_alloc ->
  cache_alloc

The NULL pointer dereference is at list_del+0x1b/0x2a.

 Code: 24 e8 df ff ff ff 48 8b 04 24 5a c3 0f 18 0f c3 48 0b 17 48 8b 47 08 48 
b9 00 01 10 00 00 00 ad de 48 be 00 02 20 00 00 00 ad dc
  89 42 08 48 89 10 40 89 0f 48 89 77 08 c3 48 8b 07 40 89 c2

Some of the 8s might be 0s and vice versa, etc.  RIP doesn't seem to
be marked.

Is this reproducible?



-- 
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/2022210229.gb6...@elie.hsd1.il.comcast.net

Bug#631664: [PATCH v2] x86: Add amilo-rfkill driver for some Fujitsu-Siemens Amilo laptops

2011-11-22 Thread Matthew Garrett 
On Sun, Nov 13, 2011 at 07:06:42PM +, Ben Hutchings wrote:

> +#define A1655_STATE_PORT 0x64
> +#define A1655_COMMAND_PORT   0x64
> +#define A1655_DATA_PORT  0x60

You'll need to synchronise with the i8042 driver here, otherwise things 
could go horribly wrong.

> +#define M7440_PORT1  0x118f
> +#define M7440_PORT2  0x118e

These ports are defined in the DSDT for one of these systems, but not 
referenced. I think a hardware-banging driver like this is probably the 
only interface.

Should be fine as long as you make sure you're not racing with the 
keyboard controller.

-- 
Matthew Garrett | mj...@srcf.ucam.org



-- 
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/2022193044.ge5...@srcf.ucam.org

Re: Increasing minimum 'i386' processor

2011-11-22 Thread Ben Hutchings 
On Tue, Nov 22, 2011 at 04:47:20PM +, Ian Jackson wrote:
> Ben Hutchings writes ("Increasing minimum 'i386' processor"):
> > The 486-class processors that would no longer be supported are:
> > 1. All x86 processors with names including '486'
> 
> I'm still running the machine below, and it would be irritating to
> have to replace it.

As Bastian says, this does not look like a 486.  The flags include
tsc msr cx8.

> Perhaps a better approach would be to suggest that people with shiny
> new hardware should be running amd64 kernels with i386 userland, or
> even amd64 (with multiarch i386 for proprietary crap that isn't
> available for amd64) ?
[...]

I believe Debian should now treat amd64 as the default architecture
for PCs.  The i386 installer does provide it as an option in expert
mode (though it's not on CD 1) but I'm not sure we're quite at the
point where it should be automatically selected.

In any case this is irrelevant to the question of optimising userland.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/2022183646.gr3...@decadent.org.uk

Re: Increasing minimum 'i386' processor

2011-11-22 Thread Vincent Bernat 
OoO Lors de  la soirée naissante du mardi 22  novembre 2011, vers 18:28,
Bastian Blank  disait :

>> > The 486-class processors that would no longer be supported are:
>> > 1. All x86 processors with names including '486'
>> I'm still running the machine below, and it would be irritating to
>> have to replace it.

>> vendor_id: CentaurHauls
>> model name   : VIA Samuel 2

> I don't see any 486 in this name.

This processor  does not run with a  686 kernel and needs  a 486 kernel.
If   I  remember   correctly,   it   is  because   the   lack  of   CMOV
instruction. Therefore, no problem with 586.
-- 
Vincent Bernat ☯ http://vincent.bernat.im

Indent to show the logical structure of a program.
- The Elements of Programming Style (Kernighan & Plauger)


pgpjR0ImIUXpH.pgp
Description: PGP signature

Re: Increasing minimum 'i386' processor

2011-11-22 Thread Ian Jackson 
Ben Hutchings writes ("Increasing minimum 'i386' processor"):
> The 486-class processors that would no longer be supported are:
> 1. All x86 processors with names including '486'

I'm still running the machine below, and it would be irritating to
have to replace it.

Perhaps a better approach would be to suggest that people with shiny
new hardware should be running amd64 kernels with i386 userland, or
even amd64 (with multiarch i386 for proprietary crap that isn't
available for amd64) ?

Ian.

processor   : 0
vendor_id   : CentaurHauls
cpu family  : 6
model   : 7
model name  : VIA Samuel 2
stepping: 3
cpu MHz : 533.401
cache size  : 64 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu de tsc msr cx8 mtrr pge mmx 3dnow
bogomips: 1066.80
clflush size: 32
cache_alignment : 32
address sizes   : 32 bits physical, 32 bits virtual
power management:


-- 
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/20171.53784.119523.574...@chiark.greenend.org.uk

Re: Increasing minimum 'i386' processor

2011-11-22 Thread Bastian Blank 
On Tue, Nov 22, 2011 at 04:47:20PM +, Ian Jackson wrote:
> Ben Hutchings writes ("Increasing minimum 'i386' processor"):
> > The 486-class processors that would no longer be supported are:
> > 1. All x86 processors with names including '486'
> I'm still running the machine below, and it would be irritating to
> have to replace it.

> vendor_id : CentaurHauls
> model name: VIA Samuel 2

I don't see any 486 in this name.

Bastian

-- 
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
   stardate unknown.


-- 
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/2022172828.ga31...@wavehammer.waldi.eu.org

Bug#645308: tg3 broken for NetXtreme 5714S in squeeze 6.0.3 installer

2011-11-22 Thread Marc Haber 
On Mon, Nov 21, 2011 at 06:36:49AM +, Ben Hutchings wrote:
> On Sat, 2011-11-19 at 21:13 +0100, Marc Haber wrote:
> > On Sat, Nov 19, 2011 at 07:37:16PM +, Ben Hutchings wrote:
> > > But I can provide you with a rebuilt tg3.ko so you can test just that
> > > change in the installer like you did previously.
> > 
> > Already forgot about that. Yes, of course, that would be a way to go.
> > No need to hurry, I won't be on site before tuesday.
> 
> Here it is.

Thank you very much. This module seems to drive the HS12 tg3 4714S
without need for our workaround.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 31958062



-- 
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/2022161136.gs4...@torres.zugschlus.de

Bug#649606: Kernel bug while umounting partition.

2011-11-22 Thread Tomasz Gemza 
Package: linux-image-2.6-xen-amd64
Version: 2.6.32+29

After taring image of the partition umount hangs. I've used following
commands:

on #1 terminal:

$ mount -r -o loop /root/image.img /mnt/work
$ cd /mnt/work
$ nice -n 15 ionice -n 7 tar -pczf /root/image.tar.gz ./

on #2 terminal:

$ cpulimit -e gzip -z -l 50

after finnish, on #1 termina:
umount /mnt/work

Umount command hangs (system is still running). Here is dmesg output:


[1297561.793377] EXT4-fs error (device loop0): ext4_ext_find_extent: bad
header/extent in inode #4436213: invalid magic - magic 3951, entries
13611, max 25957(0), depth 22612(0)
[1297561.793511] [ cut here ]
[1297561.793541] kernel BUG at
/build/buildd-linux-2.6_2.6.32-35squeeze2-amd64-OT816k/linux-2.6-2.6.32/debian/build/source_amd64_xen/fs/ext4/extents.c:1873!
[1297561.793612] invalid opcode:  [#1] SMP
[1297561.793649] last sysfs file:
/sys/devices/vbd-22-51714/statistics/wr_sect
[1297561.793681] CPU 1
[1297561.793707] Modules linked in: virtio_balloon virtio usb_storage
nf_conntrack_netlink nfnetlink xt_tcpudp nf_conntrack_ipv4
nf_defrag_ipv4 xt_state nf_conntrack xt_physdev iptable_filter ip_tables
x_tables bridge stp xen_evtchn xenfs ext3 jbd dm_snapshot coretemp
ipmi_si ipmi_msghandler loop radeon snd_pcm ttm snd_timer drm_kms_helper
i5000_edac processor snd drm edac_core soundcore snd_page_alloc
i2c_algo_bit acpi_processor i2c_core i5k_amb rng_core dcdbas psmouse
evdev serio_raw pcspkr joydev button shpchp pci_hotplug ext4 mbcache
jbd2 crc16 dm_mod usbhid hid sg sr_mod ses cdrom sd_mod crc_t10dif
enclosure ata_generic uhci_hcd ata_piix ehci_hcd libata megaraid_sas
bnx2 usbcore nls_base scsi_mod thermal thermal_sys [last unloaded:
scsi_wait_scan]
[1297561.794228] Pid: 13884, comm: tar Not tainted 2.6.32-5-xen-amd64 #1
PowerEdge 1950
[1297561.794275] RIP: e030:[]  []
ext4_ext_get_blocks+0x277/0x19a5 [ext4]
[1297561.794344] RSP: e02b:880120cfb768  EFLAGS: 00010246
[1297561.794373] RAX:  RBX: 704e4a4a RCX:

[1297561.794420] RDX: 8801c928ddb0 RSI: 8801988c RDI:
704e4a4a
[1297561.794467] RBP: 8801988cbff8 R08: aa00 R09:
8801988cbff8
[1297561.794514] R10:  R11: a01a0340 R12:

[1297561.794561] R13:  R14: 8800772fcc48 R15:

[1297561.794611] FS:  7f016e2e9700() GS:88000ae62000()
knlGS:
[1297561.794659] CS:  e033 DS:  ES:  CR0: 8005003b
[1297561.794689] CR2: 7f2f2565e1d0 CR3: 000139615000 CR4:
2660
[1297561.794736] DR0:  DR1:  DR2:

[1297561.794784] DR3:  DR6: 0ff0 DR7:
0400
[1297561.794831] Process tar (pid: 13884, threadinfo 880120cfa000,
task 8801c92a3170)
[1297561.794879] Stack:
[1297561.794902]  0002277a 020002c0 0ae740b0
88013879d770
[1297561.794943] <0> 0001a018bdcc  8801c928dd80
8801988b8000
[1297561.795004] <0> 704e4a4a 0001 
8800772fcb88
[1297561.795083] Call Trace:
[1297561.795114]  [] ?
ext4_ext_get_blocks+0x17b/0x19a5 [ext4]
[1297561.795151]  [] ? ext4_ext_get_blocks+0x66/0x19a5
[ext4]
[1297561.795188]  [] ? xen_force_evtchn_callback+0x9/0xa
[1297561.795220]  [] ? xen_force_evtchn_callback+0x9/0xa
[1297561.795252]  [] ? check_events+0x12/0x20
[1297561.795287]  [] ? ext4_get_blocks+0x82/0x253 [ext4]
[1297561.795319]  [] ? xen_restore_fl_direct_end+0x0/0x1
[1297561.795352]  [] ? kmem_cache_alloc+0x8c/0xf0
[1297561.795387]  [] ? ext4_get_block+0xa5/0xe2 [ext4]
[1297561.795420]  [] ? block_read_full_page+0xf4/0x1ea
[1297561.795456]  [] ? ext4_get_block+0x0/0xe2 [ext4]
[1297561.795491]  [] ? ext4_get_block+0xa5/0xe2 [ext4]
[1297561.795523]  [] ? do_mpage_readpage+0x41f/0x421
[1297561.795568]  [] ? ext4_get_block+0x0/0xe2 [ext4]
[1297561.795603]  [] ? ext4_get_block+0x0/0xe2 [ext4]
[1297561.795636]  [] ? add_to_page_cache_locked+0x98/0xc1
[1297561.795671]  [] ? ext4_get_block+0x0/0xe2 [ext4]
[1297561.795703]  [] ? mpage_readpages+0xcc/0x112
[1297561.795737]  [] ? ext4_get_block+0x0/0xe2 [ext4]
[1297561.795773]  [] ? __ext4_ext_check+0x136/0x1ba [ext4]
[1297561.795807]  [] ? bit_waitqueue+0x10/0xa0
[1297561.795837]  [] ? wake_up_bit+0x11/0x22
[1297561.795869]  [] ?
__do_page_cache_readahead+0x11b/0x1b4
[1297561.795901]  [] ? ra_submit+0x1c/0x20
[1297561.795931]  [] ? generic_file_aio_read+0x1ff/0x536
[1297561.795966]  [] ? ext4_file_open+0x0/0xe8 [ext4]
[1297561.795999]  [] ? do_sync_read+0xce/0x113
[1297561.796030]  [] ? cp_new_stat+0xe9/0xfc
[1297561.796060]  [] ? autoremove_wake_function+0x0/0x2e
[1297561.796092]  [] ? xen_force_evtchn_callback+0x9/0xa
[1297561.796126]  [] ? cap_dentry_open+0x0/0x3
[1297561.796156]  [] ? do_sys_open+0xec/0xfc
[1297561.796186]  [] ? xen_force_evtchn_callback+0x9/0xa
[1297561.796218]  [] ? check_events

Bug#649567: linux-2.6: Please enable BCMA and BCMA_HOST_PCI

2011-11-22 Thread Ben Hutchings 
On Tue, 2011-11-22 at 19:20 +1100, Geoff Simmons wrote:
> Source: linux-2.6
> Version: 3.1.1-1
> Severity: wishlist
> 
> Hi,
> 
> Please consider enabling BCMA ("BCMA support") as a module, along with
> BCMA_HOST_PCI ("Support for BCMA on PCI-host bus").  BCMA was explicitly
> disabled for linux-2.6 in its subversion repository at revision 17519.
> 
> Enabling these would allow the b43 driver to receive BCMA bus support
> (B43_BCMA, enabled by default) and operate Broadcom BCM43224 and BCM43225
> based PCIe wireless LAN devices; BCM4331 (HT-PHY) support is anticipated for
> Linux 3.2.
> 
> A consequence of enabling BCMA_HOST_PCI is the addition of device IDs to the
> produced bcma module, four of these are claimed by the brcmsmac part of the
> brcm80211 staging driver.

brcmsmac apparently has better support for these devices, and is moving
out of staging in 3.2.

So whatever we do, we shouldn't enable those device IDs in b43 as well.

Ben.

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.


signature.asc
Description: This is a digitally signed message part

Bug#649448: udev loading radeon drivers garbles screen output

2011-11-22 Thread Alex Deucher 
On Tue, Nov 22, 2011 at 7:08 AM, Touko Korpela  wrote:
> On Mon, Nov 21, 2011 at 09:33:28AM -0500, Alex Deucher wrote:
>> On Sun, Nov 20, 2011 at 10:12 PM, Ben Hutchings  wrote:
>> > On Sun, 2011-11-20 at 19:02 -0600, Jonathan Nieder wrote:
>> >> reassign 649448 src:linux-2.6 linux-2.6/3.0.0-3
>> >> severity 649448 important
>> >> retitle 649448 radeon (evergreen): random-looking pattern of pixels when 
>> >> firmware not installed
>> >> tags 649448 + upstream
>> >> quit
>> >>
>> >> Hi Martin,
>> >>
>> >> Martin von Gagern wrote:
>> >>
>> >> > Version: 3.0.0-3
>> >> [...]
>> >> > Just installed a wheezy setup using debootstrap, adding grub-pc and
>> >> > linux-image-amd64 after the chroot was created. The kernel boots, the
>> >> > initrd seems all right. When the main system boots up, udev gets launced
>> >> > pretty early. Soon after it is started, the screen turns into a pretty
>> >> > random-looking pattern of pixels, making the console pretty unusable.
>> >> > This also happens in "recovery" i.e. single-user mode.
>> >> [...]
>> >> > Possible workarounds seem to include:
>> >> [...]
>> >> > - Adding a line "blacklist radeon" to /etc/modprobe.d/blacklist.conf,
>> >> >   followed by running "depmod -a".
>> >> [...]
>> >> >> [  150.125768] r600_cp: Failed to load firmware "radeon/SUMO2_pfp.bin"
>> >> >> [  150.125818] [drm:evergreen_startup] *ERROR* Failed to load firmware!
>> >> >> [  150.125859] radeon :00:01.0: disabling GPU acceleration
>> >>
>> >> Yes, the radeon driver currently copes poorly when firmware is missing.
>> >> Compare [1], [2], [3].
>> >>
>> >> [...]
>> >> > Not having GPU accelleration due to lack of free firmware is acceptable.
>> >> > Not having a usable text console can be a real problem.
>> >>
>> >> Agreed.  The radeon driver should be bailing out when firmware is
>> >> missing for cards that need it, but that is not working for some
>> >> reason.
>> > [...]
>> >
>> > At the time I converted the radeon driver to load external firmware, it
>> > was apparently only required for 3D acceleration and both KMS and 2D
>> > acceleration of X worked without it, at least on those systems I tested
>> > (which were quite old, R100-R300 families).  Therefore failure to load
>> > firmware would only result in DRM (3D acceleration support) being
>> > disabled.
>> >
>> > However, it looks like driver support for the R600 family onward now
>> > absolutely requires the 'RLC' firmware blobs:
>> >
>> > commit d8f60cfc93452d0554f6a701aa8e3236cbee4636
>> > Author: Alex Deucher 
>> > Date:   Tue Dec 1 13:43:46 2009 -0500
>> >
>> >    drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)
>> >
>> > And the 'Northern Islands' GPUs and 'Fusion' APUs appear to require the
>> > 'MC' firmware blobs:
>> >
>> > commit 0af62b0168043896a042b005ff88caa77dd94d04
>> > Author: Alex Deucher 
>> > Date:   Thu Jan 6 21:19:31 2011 -0500
>> >
>> >    drm/radeon/kms: add ucode loader for NI
>> >
>> > Therefore I think that at least r600_init(), rv770_init(),
>> > evergreen_init() and cayman_init() should be treating failure to load
>> > firmware as a fatal error.
>> >
>>
>> R6xx, r7xx should work ok without the RLC ucode, you just won't get
>> acceleration.  With chips that require the MC ucode, the driver will
>> bail if the MC ucode is not available.
>
> In what kernel versions should that be true?
> These bugs are reported that question it (some are reported against older
> kernels).
> http://bugs.debian.org/607194
> http://bugs.debian.org/637943
> http://bugs.debian.org/627497
> and also my report:
> http://bugs.debian.org/646306
>

Should work and well tested are different things.

Alex



--
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/cadnq5_mcwnzfbuykudwa7meqxkdgnankcmb8gpums8mmt3p...@mail.gmail.com

Bug#648678: module bcm5974 is not being loaded on mac book pro

2011-11-22 Thread David Roguin 
On Mon, Nov 14, 2011 at 8:52 AM, David Roguin  wrote:
> On Mon, Nov 14, 2011 at 12:49 AM, Ben Hutchings  wrote:
>> On Sun, 2011-11-13 at 22:06 -0300, David Roguin wrote:
>>> Package: linux-image-3.1.0-1-amd64
>>> Status: install ok installed
>>> Priority: optional
>>> Section: kernel
>>> Installed-Size: 100967
>>> Maintainer: Debian Kernel Team 
>>> Architecture: amd64
>>> Source: linux-2.6
>>> Version: 3.1.0-1~experimental.1
>>> Provides: linux-image, linux-modules-3.1.0-1-amd64
>>> Depends: module-init-tools, linux-base (>= 3~), initramfs-tools (>=
>>> 0.99~) | linux-initramfs-tool
>>> Pre-Depends: debconf | debconf-2.0
>>> Recommends: firmware-linux-free (>= 3~)
>>> Suggests: linux-doc-3.1, grub-pc | extlinux | lilo (>= 22.8-8.2~)
>>> Breaks: initramfs-tools (<< 0.99~), lilo (<< 22.8-8.2~)
>>>
>>>
>>> The bcm5974 module is not being loaded on a mac book pro with Debian Wheezy.
>>> According to 'lsusb -t' usbhid module is handling the trackpad making
>>> the multitouch unusable.
>>
>> Please don't open a new bug report if you disagree with closing of
>> another.  We can always reopen that.
> Understood, but I've incorrected filled the previous bug against
> linux-3.0 when i meant linux-3.1
>
>> If I understand you correctly, usbhid can bind to the trackpad device
>> and should not.  Since usbhid is a class device (it works with most USB
>> 'human interface' devices, but not necessarily covering all their
>> features) we would need to add this device to a blacklist to prevent it
>> from doing that.  We will *not* fix this by making any driver built-in!
>
> I wasn't suggesting making the drivers built-in to fix the problem, I
> was just trying to note that building the custom kernel with those
> params made the trackpad work with multitouch capabilities.
> If I blacklist that module, should bcm5974 be loaded at start?
>
>> Please send the 'lsusb' output for this system, and the content of
>> '/sys/devices/virtual/dmi/id/product_name'.
>
> lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
> Bus 001 Device 002: ID 0424:2513 Standard Microsystems Corp.
> Bus 001 Device 003: ID 05ac:8509 Apple, Inc.
> Bus 002 Device 002: ID 0424:2513 Standard Microsystems Corp.
> Bus 001 Device 004: ID 0a5c:4500 Broadcom Corp. BCM2046B1 USB 2.0 Hub
> (part of BCM2046 Bluetooth)
> Bus 001 Device 005: ID 05ac:0252 Apple, Inc.
> Bus 002 Device 003: ID 05ac:8242 Apple, Inc. IR Receiver [built-in]
> Bus 001 Device 008: ID 05ac:821a Apple, Inc.
> Bus 002 Device 004: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
> Bus 002 Device 005: ID 0458:003a KYE Systems Corp. (Mouse Systems)
> NetScroll+ Mini Traveler / Genius NetScroll 120
> Bus 002 Device 006: ID 04f2:0833 Chicony Electronics Co., Ltd
>
>
> cat '/sys/devices/virtual/dmi/id/product_name'
> MacBookPro8,1
>
> Cheers!
>
> --
> David
>

It's fixed on Version: 3.1.1-1
Thanks!


-- 
David



--
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/CAGaJj4L1kaLRV5h-NpjeTYX=ag38ymobckzxnimfextcizc...@mail.gmail.com

Bug#649448: udev loading radeon drivers garbles screen output

2011-11-22 Thread Touko Korpela 
On Mon, Nov 21, 2011 at 09:33:28AM -0500, Alex Deucher wrote:
> On Sun, Nov 20, 2011 at 10:12 PM, Ben Hutchings  wrote:
> > On Sun, 2011-11-20 at 19:02 -0600, Jonathan Nieder wrote:
> >> reassign 649448 src:linux-2.6 linux-2.6/3.0.0-3
> >> severity 649448 important
> >> retitle 649448 radeon (evergreen): random-looking pattern of pixels when 
> >> firmware not installed
> >> tags 649448 + upstream
> >> quit
> >>
> >> Hi Martin,
> >>
> >> Martin von Gagern wrote:
> >>
> >> > Version: 3.0.0-3
> >> [...]
> >> > Just installed a wheezy setup using debootstrap, adding grub-pc and
> >> > linux-image-amd64 after the chroot was created. The kernel boots, the
> >> > initrd seems all right. When the main system boots up, udev gets launced
> >> > pretty early. Soon after it is started, the screen turns into a pretty
> >> > random-looking pattern of pixels, making the console pretty unusable.
> >> > This also happens in "recovery" i.e. single-user mode.
> >> [...]
> >> > Possible workarounds seem to include:
> >> [...]
> >> > - Adding a line "blacklist radeon" to /etc/modprobe.d/blacklist.conf,
> >> >   followed by running "depmod -a".
> >> [...]
> >> >> [  150.125768] r600_cp: Failed to load firmware "radeon/SUMO2_pfp.bin"
> >> >> [  150.125818] [drm:evergreen_startup] *ERROR* Failed to load firmware!
> >> >> [  150.125859] radeon :00:01.0: disabling GPU acceleration
> >>
> >> Yes, the radeon driver currently copes poorly when firmware is missing.
> >> Compare [1], [2], [3].
> >>
> >> [...]
> >> > Not having GPU accelleration due to lack of free firmware is acceptable.
> >> > Not having a usable text console can be a real problem.
> >>
> >> Agreed.  The radeon driver should be bailing out when firmware is
> >> missing for cards that need it, but that is not working for some
> >> reason.
> > [...]
> >
> > At the time I converted the radeon driver to load external firmware, it
> > was apparently only required for 3D acceleration and both KMS and 2D
> > acceleration of X worked without it, at least on those systems I tested
> > (which were quite old, R100-R300 families).  Therefore failure to load
> > firmware would only result in DRM (3D acceleration support) being
> > disabled.
> >
> > However, it looks like driver support for the R600 family onward now
> > absolutely requires the 'RLC' firmware blobs:
> >
> > commit d8f60cfc93452d0554f6a701aa8e3236cbee4636
> > Author: Alex Deucher 
> > Date:   Tue Dec 1 13:43:46 2009 -0500
> >
> >    drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)
> >
> > And the 'Northern Islands' GPUs and 'Fusion' APUs appear to require the
> > 'MC' firmware blobs:
> >
> > commit 0af62b0168043896a042b005ff88caa77dd94d04
> > Author: Alex Deucher 
> > Date:   Thu Jan 6 21:19:31 2011 -0500
> >
> >    drm/radeon/kms: add ucode loader for NI
> >
> > Therefore I think that at least r600_init(), rv770_init(),
> > evergreen_init() and cayman_init() should be treating failure to load
> > firmware as a fatal error.
> >
> 
> R6xx, r7xx should work ok without the RLC ucode, you just won't get
> acceleration.  With chips that require the MC ucode, the driver will
> bail if the MC ucode is not available.

In what kernel versions should that be true?
These bugs are reported that question it (some are reported against older
kernels).
http://bugs.debian.org/607194
http://bugs.debian.org/637943
http://bugs.debian.org/627497
and also my report:
http://bugs.debian.org/646306



--
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/2022120853.GA17965@tiikeri.vuoristo.local

Re: Bug#649563: linux-image-3.1.0-1-amd64 can't load initial ramdisk anymore

2011-11-22 Thread Friedemann Stoyan 
On 22.11.11 01:40, Jonathan Nieder wrote:

> > Loading Linux 3.1.0-1-amd64 ...
> > Loading initial ramdisk ...
> > error: couldn't read file.
> [...]
> > load_video
> > set gfxpayload=keep
> > insmod gzio
> > insmod lvm
> > insmod part_msdos
> > insmod xfs
> > set root='(vg0-root)'
> > search --no-floppy --fs-uuid --set=root 
> > af14a1aa-52e2-4a95-8d49-733722fe7949
> > echo'Loading Linux 3.1.0-1-amd64 ...'
> > linux   /boot/vmlinuz-3.1.0-1-amd64 root=/dev/mapper/vg0-root ro 
> > rootdelay=9
> > echo'Loading initial ramdisk ...'
> > initrd  /boot/initrd.img-3.1.0-1-amd64
> 
> Looks ok...
> 
> [...]
> > pn  grub-pc1.99-12
> 
> Wait, not ok at all.  Do you have a bootloader installed?
> 
> Thanks for writing,
> Jonathan

I have booted Kernel 3.0.0-1-amd64 again, which works. No clue why reportbug
shows grub-pc as purged. When I query with dpkg everything looks fine:

$ dpkg -l "grub*"
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version   
Description
+++-=-=-==
un  grub  
(no description available)
ii  grub-common   1.99-12   
GRand Unified Bootloader (common files)
un  grub-coreboot 
(no description available)
un  grub-doc  
(no description available)
un  grub-efi  
(no description available)
un  grub-efi-amd64
(no description available)
un  grub-efi-ia32 
(no description available)
un  grub-emu  
(no description available)
un  grub-ieee1275 
(no description available)
un  grub-legacy   
(no description available)
un  grub-legacy-doc   
(no description available)
un  grub-linuxbios
(no description available)
ii  grub-pc   1.99-12   
GRand Unified Bootloader, version 2 (PC/BIOS version)
ii  grub-pc-bin   1.99-12   
GRand Unified Bootloader, version 2 (PC/BIOS binaries)
un  grub-yeeloong 
(no description available)
un  grub2 
(no description available)
ii  grub2-common  1.99-12   
GRand Unified Bootloader (common files for version 2)

Again, I can boot with kernel 3.0.0-1-amd64 without problems, but
3.1.0-1-amd64 doesn't work.

/-Filesystem (XFS) is at an Logical Volume and /boot is on it. As far as I can
see, everything in /boot looks good:

$ ls -l /boot/
total 46976
-rw-r--r-- 1 root root   124738 Jul  5 05:09 config-2.6.39-2-amd64
-rw-r--r-- 1 root root   125263 Aug 27 19:54 config-3.0.0-1-amd64
-rw-r--r-- 1 root root   127216 Nov 14 09:35 config-3.1.0-1-amd64
drwxr-xr-x 3 root root 8192 Nov 22 06:27 grub
-rw-r--r-- 1 root root 11073606 Aug  7 06:07 initrd.img-2.6.39-2-amd64
-rw-r--r-- 1 root root 11230400 Nov 21 17:18 initrd.img-3.0.0-1-amd64
-rw-r--r-- 1 root root 11332592 Nov 22 06:27 initrd.img-3.1.0-1-amd64
-rw-r--r-- 1 root root  1887188 Jul  5 05:09 System.map-2.6.39-2-amd64
-rw-r--r-- 1 root root  2007368 Aug 27 19:54 System.map-3.0.0-1-amd64
-rw-r--r-- 1 root root  2033352 Nov 14 09:35 System.map-3.1.0-1-amd64
-rw-r--r-- 1 root root  2690384 Jul  5 05:04 vmlinuz-2.6.39-2-amd64
-rw-r--r-- 1 root root  2705680 Aug 27 19:49 vmlinuz-3.0.0-1-amd64
-rw-r--r-- 1 root root  2725040 Nov 14 09:21 vmlinuz-3.1.0-1-amd64

Really no clue what happens here.

Regards
Friedemann


-- 
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/2022095055.ga5...@excelsior.lab.swapon.de

Bug#649567: linux-2.6: Please enable BCMA and BCMA_HOST_PCI

2011-11-22 Thread Geoff Simmons 
Source: linux-2.6
Version: 3.1.1-1
Severity: wishlist

Hi,

Please consider enabling BCMA ("BCMA support") as a module, along with
BCMA_HOST_PCI ("Support for BCMA on PCI-host bus").  BCMA was explicitly
disabled for linux-2.6 in its subversion repository at revision 17519.

Enabling these would allow the b43 driver to receive BCMA bus support
(B43_BCMA, enabled by default) and operate Broadcom BCM43224 and BCM43225
based PCIe wireless LAN devices; BCM4331 (HT-PHY) support is anticipated for
Linux 3.2.

A consequence of enabling BCMA_HOST_PCI is the addition of device IDs to the
produced bcma module, four of these are claimed by the brcmsmac part of the
brcm80211 staging driver.

Geoff

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.1.0-1-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
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/2022082000.7308.45731.report...@acer.lan.gsimmons.org