Processed (with 1 errors): Re: udev loading radeon drivers garbles screen output

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> severity 627497 important
Bug #627497 [linux-2.6] linux-headers-2.6.38-bpo.2-amd64: "Unable to handle 
kernel paging request" with radeon KMS without non-free firmware
Severity set to 'important' from 'normal'

> tags 637943 + upstream
Bug #637943 [linux-2.6] RV635 [Radeon HD 3600 series]: white, grey, and black 
stripes with snow on bottom unless firmware is loaded
Added tag(s) upstream.
> tags 627497 + upstream
Bug #627497 [linux-2.6] linux-headers-2.6.38-bpo.2-amd64: "Unable to handle 
kernel paging request" with radeon KMS without non-free firmware
Added tag(s) upstream.
> merge 607194 627497 637943 649448
Bug#607194: radeon: random general protection faults when RV620 firmware not 
installed
Bug#627497: linux-headers-2.6.38-bpo.2-amd64: "Unable to handle kernel paging 
request" with radeon KMS without non-free firmware
Mismatch - only Bugs in same state can be merged:
Values for `package' don't match:
 #607194 has `src:linux-2.6';
 #627497 has `linux-2.6'

> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
627497: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627497
637943: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=637943
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.13218613924976.transcr...@bugs.debian.org

Bug#649448: udev loading radeon drivers garbles screen output

[Jonathan Nieder]

severity 627497 important
tags 637943 + upstream
tags 627497 + upstream
merge 607194 627497 637943 649448
quit

Martin von Gagern wrote:

> Here you go, everything after the modprobe:

Thanks.

[...]
> On 21.11.2011 02:02, Jonathan Nieder wrote:

>> and from
>> "/usr/share/bug/xserver-xorg-video-radeon/script 3>&1" after
>> reproducing the problem.
>
> No xorg installed on that machine, and I'd like to keep it that way.

Makes sense.  No problem.



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

Bug#649448: udev loading radeon drivers garbles screen output

[Martin von Gagern]

On 21.11.2011 02:02, Jonathan Nieder wrote:
> Yes, the radeon driver currently copes poorly when firmware is missing.
> Compare [1], [2], [3].
> [1] http://bugs.debian.org/607194
> [2] http://bugs.debian.org/637943
> [3] http://bugs.debian.org/627497

[2] sounds a lot like what I see.

> Thanks for reporting it.  If you can (for example by ssh-ing in),
> please attach full output from "dmesg"

Here you go, everything after the modprobe:
> [  380.238466] [drm] Initialized drm 1.1.0 20060810
> [  380.274651] [drm] radeon defaulting to kernel modesetting.
> [  380.274654] [drm] radeon kernel modesetting enabled.
> [  380.274692] radeon :00:01.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> [  380.274696] radeon :00:01.0: setting latency timer to 64
> [  380.274851] [drm] initializing kernel modesetting (SUMO2 0x1002:0x9644 
> 0x1849:0x9640).
> [  380.275171] [drm] register mmio base: 0xFEB0
> [  380.275173] [drm] register mmio size: 262144
> [  380.275320] ATOM BIOS: General
> [  380.275348] radeon :00:01.0: VRAM: 32M 0x - 
> 0x01FF (32M used)
> [  380.275351] radeon :00:01.0: GTT: 512M 0x0200 - 
> 0x21FF
> [  380.275357] mtrr: type mismatch for fc00,200 old: write-back new: 
> write-combining
> [  380.275360] [drm] Detected VRAM RAM=32M, BAR=32M
> [  380.275361] [drm] RAM width 32bits DDR
> [  380.275532] [TTM] Zone  kernel: Available graphics memory: 2002580 kiB.
> [  380.275535] [TTM] Initializing pool allocator.
> [  380.275563] [drm] radeon: 32M of VRAM memory ready
> [  380.275565] [drm] radeon: 512M of GTT memory ready.
> [  380.275581] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [  380.275582] [drm] Driver supports precise vblank timestamp query.
> [  380.275618] radeon :00:01.0: irq 55 for MSI/MSI-X
> [  380.275623] radeon :00:01.0: radeon: using MSI.
> [  380.275656] [drm] radeon: irq initialized.
> [  380.275661] [drm] GART: num cpu pages 131072, num gpu pages 131072
> [  380.276516] [drm] Loading SUMO2 Microcode
> [  380.296057] r600_cp: Failed to load firmware "radeon/SUMO2_pfp.bin"
> [  380.296099] [drm:evergreen_startup] *ERROR* Failed to load firmware!
> [  380.296134] radeon :00:01.0: disabling GPU acceleration
> [  380.297203] radeon :00:01.0: 880114d75400 unpin not necessary
> [  380.297205] radeon :00:01.0: 880114d75400 unpin not necessary
> [  380.297229] failed to evaluate ATIF got AE_BAD_PARAMETER
> [  380.297411] [drm] Radeon Display Connectors
> [  380.297413] [drm] Connector 0:
> [  380.297414] [drm]   DVI-D
> [  380.297415] [drm]   HPD2
> [  380.297417] [drm]   DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 
> 0x644c
> [  380.297419] [drm]   Encoders:
> [  380.297420] [drm] DFP2: INTERNAL_UNIPHY2
> [  380.297422] [drm] Connector 1:
> [  380.297423] [drm]   DVI-D
> [  380.297424] [drm]   HPD1
> [  380.297426] [drm]   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 
> 0x643c
> [  380.297427] [drm]   Encoders:
> [  380.297428] [drm] DFP1: INTERNAL_UNIPHY2
> [  380.776030] [drm] Radeon display connector DVI-D-1: No monitor connected 
> or invalid EDID
> [  380.830275] [drm] Radeon display connector DVI-D-2: Found valid EDID
> [  380.830311] [drm] Internal thermal controller without fan control
> [  380.830348] [drm] radeon: power management initialized
> [  380.985119] [drm] fb mappable at 0xFC04
> [  380.985120] [drm] vram apper at 0xFC00
> [  380.985122] [drm] size 1892352
> [  380.985123] [drm] fb depth is 8
> [  380.985124] [drm]pitch is 1792
> [  380.985182] fbcon: radeondrmfb (fb0) is primary device
> [  381.003344] Console: switching to colour frame buffer device 210x65
> [  381.004682] fb0: radeondrmfb frame buffer device
> [  381.004683] drm: registered panic notifier
> [  381.004690] [drm] Initialized radeon 2.10.0 20080528 for :00:01.0 on 
> minor 0

> and from
> "/usr/share/bug/xserver-xorg-video-radeon/script 3>&1" after
> reproducing the problem.

No xorg installed on that machine, and I'd like to keep it that way.

Greetings,
 Martin



signature.asc
Description: OpenPGP digital signature

Re: Squeeze on USB

[sfjro]

Ben Hutchings:
> I was hoping you would be able to identify the most important fixes,
> dealing with data loss and security bugs.  This long list of changes
> appears to include cleanup and new features, which would not be

No, such changes are removed.
You may be able to see what I have removed if you run
$ cd aufs2-2.6.git
$ git log --no-merges --since=2010/01/24 aufs2.1-32
$ git log --no-merges aufs2.1-32..aufs2.2-35 fs/aufs

Most of the list will surely cause deadlock or crash in certain
circumstances.
You may want to ask "what is certain circumstance? how often will users
meet such problem?"
When I write "possible bugfix", it means there are some conditions to
reproduce the bug, for instance,
- enable CONFIG_AUFS_xxx.
- run processA which issues systemcallA.
- run processB which issues systemcallB.
- when aufs operates systemcallA and systemcallB at the same time, a
  deadlock will happen.

In other words, if you disable CONFIG_AUFS_xxx, or issue both of
systemcallA/B but their timing is different, then you will never meet
the problem. It is totally up to your configuration and operation (or
others).

For security fixes, it is also up to you.
For example,
dcb6ad5 2011-03-01 Fix aufs call of security_path_mknod
Author: John Johansen 
is to fix an incorrect parameter for security_path_mknod().
As you know, security_path_mknod() has its meaning only when
- you configure kernel to do so.
- and users sets something to do so.
Again, if one of these conditions are not true, security_path_mknod()
becomes empty and the commit has no meaning.

Finally, I'd suggest you to
- make aufs in debian as the last aufs2.1-32 unconditionally.
- and choose the commits in aufs2.2 (the last part of my previous mail).


J. R. Okajima


-- 
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/10732.1321855726@jrobl

Processed: tagging 649365

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 649365 + moreinfo
Bug #649365 [linux-2.6] linux-image-3.1.0-1-amd64: Broadcom USB adapter not 
recognised
Added tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
649365: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649365
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.132185521832465.transcr...@bugs.debian.org

Bug#649365: linux-image-3.1.0-1-amd64: Broadcom USB adapter not recognised

[Ben Hutchings]

On Sun, 2011-11-20 at 12:34 +, Sam Morris wrote:
> Package: linux-2.6
> Version: 3.1.1-1
> Severity: normal
> 
> I have the following usb adapter:
> 
> Bus 007 Device 002: ID 0a5c:2101 Broadcom Corp. Bluetooth Controller
> 
> That used to be recognised by the hci_usb module in 2.6.26, then the btusb 
> module
> in 2.6.38. As of 3.1.1, however, btusb is loaded but 'hcitool dev'
> reports that there are no Bluetooth devices in the system.
[...]

Please provide a kernel log covering initialisation of the btusb driver.

Ben.

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


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

Processed: tagging 649449

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 649449 + moreinfo
Bug #649449 [src:linux-2.6] firmware-iwlwifi: "Card state received: HW:Kill 
SW:On" and "Not sending command - RF KILL"
Added tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
649449: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649449
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.132185439428054.transcr...@bugs.debian.org

Re: Squeeze on USB

[Ben Hutchings]

On Mon, 2011-11-21 at 14:02 +0900, sf...@users.sourceforge.net wrote:
> (While I don't know this mail is delivered expectedly, I am sending to
> debian-live and debian-kernel ML too since Ben Hutchings requested me to
> do so. Note that aufs-users ML is members only and your reply may be
> rejected.)
> 
> 
> Hello Ben,
> 
> Ben Hutchings:
> > If there are important bug fixes that aren't in Debian 6.0 (squeeze)
> > then please inform debian-l...@lists.debian.org,
> > debian-kernel@lists.debian.org.  The current version in squeeze is based
> > on:
> 
> Ok,
> On debian squeeze, /lib/modules/2.6.32-5-686/kernel/fs/aufs/aufs.ko
> shows 2-standalone.tree-32-20100125 as its version.
> There are many commits in aufs2-2.6.git#aufs2.1-32 after 2010/01/25.
> You may not want to see all 312 commits, so I'd try pick some of them
> which looks important by dropping the commits which titled as "tiny" or
> "minor". There still exist about 150 commits.
[...]

I was hoping you would be able to identify the most important fixes,
dealing with data loss and security bugs.  This long list of changes
appears to include cleanup and new features, which would not be
acceptable in a update to a stable release.  (The only new features
allowed are for supporting new hardware.)

I understand if you don't want to spend time doing that for what you
consider an obsolete release, but if you can then it would really be
appreciated.

Ben.

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


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

Re: Squeeze on USB

[sfjro]

(While I don't know this mail is delivered expectedly, I am sending to
debian-live and debian-kernel ML too since Ben Hutchings requested me to
do so. Note that aufs-users ML is members only and your reply may be
rejected.)


Hello Ben,

Ben Hutchings:
> If there are important bug fixes that aren't in Debian 6.0 (squeeze)
> then please inform debian-l...@lists.debian.org,
> debian-kernel@lists.debian.org.  The current version in squeeze is based
> on:

Ok,
On debian squeeze, /lib/modules/2.6.32-5-686/kernel/fs/aufs/aufs.ko
shows 2-standalone.tree-32-20100125 as its version.
There are many commits in aufs2-2.6.git#aufs2.1-32 after 2010/01/25.
You may not want to see all 312 commits, so I'd try pick some of them
which looks important by dropping the commits which titled as "tiny" or
"minor". There still exist about 150 commits.

I am not sure where you can apply them separately in safe or not.
If you requested me before closing aufs2.1-32, I would strongly suggest
applying all 312 commits. But currently, as you know, aufs2.1-32 is not
maintained, and I am not testing aufs2.1-32 for these several months.
So you may want to see and back-port 40 commits after aufs2.1-32 until
latest aufs2.2-35 (attached too).
Additionally you may need to update aufs2-utils too.


c5a88fc 2011-07-30 aufs: possible bugfix, race between remount and sysrq
26724b6 2011-07-25 aufs: possible bugfix, always force cpup to pass workqueue
2fe06c7 2011-07-25 aufs: allow hnotify to call another nowait task
8c0c4f7 2011-07-12 aufs: another support for loopback mount in aufs
eead3519 2011-07-07 aufs doc: proc_map.patch
4bb0454 2011-07-04 for aufs, vm_prfile supports NUMA
326b883 2011-06-30 aufs: new mmapping, support for AUFS_PROC_MAP and vm_prfile
602f6ab 2011-06-30 introduce vm_prfile for aufs
38293de 2011-06-30 aufs: new mmapping, remove obsoleted things
82d0272 2011-06-30 aufs: new mmapping
1234731 2011-06-21 aufs: bugfix, maintain /debug/aufs/si_* in an error path
0268739 2011-04-14 aufs: possible bugfix, aufs_link supports for a flushed plink
ad8f42b 2011-04-14 aufs: possible bugfix, decode_by_ino support for obsolete 
dentry
1c0c29f 2011-03-02 aufs: refine a mutex for mmap 3/3, add a condition
6c4dbe7 2011-03-02 aufs: refine a mutex for mmap 2/3, replace lockdep_off by 
dep_map
dcdfe3b 2011-03-02 aufs: refine a mutex for mmap 1/3, move functions and make 
them static
dcb6ad5 2011-03-01 Fix aufs call of security_path_mknod
65835da 2011-02-03 aufs: possible bugfix, exclude the freeing file
845a9e8 2011-02-03 aufs: test bad inode in d_revalidate
5caa666 2011-01-28 aufs: force the hardest test for remote branch
2175d65 2011-01-28 aufs: bugfix, test in rename
90ea0a0 2011-01-22 aufs: possible bugfix, protect d_unhashed() by di_write_lock
97bf43f 2011-01-21 aufs: testing, stop unhashing in hnotify
f996d6b 2011-01-10 aufs: bugfix, valid ptr in radix tree instead of dummy 1
05a6d71 2011-01-07 aufs: bugfix, O_CLOEXEC for the plink maintenance mode
c502151 2010-12-16 aufs: bugfix, missign test for branch management
9784a82 2010-12-16 aufs: possible bugfix, protect branch from deleting in nfsd 
fh_to_dentry()
8c017b9 2010-12-16 aufs: possible bugfix, br_count in async rmdir
0de8fbc 2010-12-10 aufs: possible bugfix, walk in dcache limited to aufs
52f9727 2010-12-10 aufs: d_instantiate in link(2)
6b0be66 2010-12-10 aufs: bugfix, lock subclass in copying-up a dir hierarchy
e1d13b7 2010-12-10 aufs: bugfix, restore the internal array after special copyup
b69574a 2010-12-10 aufs: bugfix, assign inode number for hardlink
3e17bf4 2010-12-10 aufs: bugfix, hfsnotify for multiple aufs 2/2
fec63cf 2010-12-10 aufs: bugfix, hfsnotify for multiple aufs 1/2
1341643 2010-12-10 aufs: bugfix, return value of au_do_refresh_d()
38fe851 2010-12-02 aufs: refreshing, replace functions for remount time
f822af6 2010-12-02 aufs: refreshing, new functions for remount time
85a3a78 2010-12-02 aufs: refreshing, replace old function by new one
8724722 2010-12-02 aufs: refreshing, new functions to refresh dentry
92dcda8 2010-12-02 aufs: refreshing, refine au_do_refresh_hdentry
db0c0d6 2010-12-02 aufs: refreshing, stop updating iigen in test_inode_busy()
48c759b 2010-12-02 aufs: refreshing, consolidate REFRESH macros
40058d7 2010-12-02 aufs: new strategy for refreshing, refresh negative dentries
97f1369 2010-12-02 aufs: keep dinfo valid by temp dinfo
381ba01 2010-12-02 aufs: temporary dinfo
ca7dc22 2010-12-02 aufs: store br_id in dinfo
4473449 2010-12-02 aufs: bugfix, write to a removed file more than once
24dddc5 2010-12-02 aufs: split au_refresh_hinode_self()
d954281 2010-12-02 aufs: refine au_update_ibrange()
bbc392a 2010-12-02 aufs: keep dinfo valid
49b3e86 2010-12-02 aufs: use a generic warpper dbrange_test()
e3d0c8e 2010-12-02 aufs: use a generic warpper [di]i_gen_test()
6680a2c 2010-12-02 aufs: bugfix, missing unlock in an error path
f1abf5b 2010-12-02 aufs: possible bugfix, the generation of dentry 3/3
69e55ee 2010-12-02 aufs: possible bugfix, the generation of dentry 2/

Processed: reassign 649449 to src:linux-2.6

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 649449 src:linux-2.6 3.0.0-3
Bug #649449 [firmware-iwlwifi] firmware-iwlwifi: "Card state received: HW:Kill 
SW:On" and "Not sending command - RF KILL"
Bug reassigned from package 'firmware-iwlwifi' to 'src:linux-2.6'.
Bug No longer marked as found in versions firmware-nonfree/0.34.
Bug #649449 [src:linux-2.6] firmware-iwlwifi: "Card state received: HW:Kill 
SW:On" and "Not sending command - RF KILL"
Bug Marked as found in versions linux-2.6/3.0.0-3.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
649449: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649449
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.132185338223340.transcr...@bugs.debian.org

Bug#649449: firmware-iwlwifi: "Card state received: HW:Kill SW:On" and "Not sending command - RF KILL"

[Ben Hutchings]

On Mon, 2011-11-21 at 00:32 +0100, dayer wrote:
> Package: firmware-iwlwifi
> Version: 0.34
> Severity: important
> 
> Hi,
> 
> I'm using a Toshiba laptop model U200-191 with a wireless card "Intel
> Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)"
> (according to lspci). My laptop has several disconnections, it depends on the
> network and this situation happens randomly. A day the connection goes very
> well, without cuts, but next day, with the same network, position and power
> signal, there're several disconnections. Now, for example, according on
> iwconfig the network has Link Quality=54/70  and Signal level=-56 dBm, and it
> has been several cuts.
> 
> I paste the dmesg ouput using Network Manager and with Network Manager stopped
> and using only a shell to configure the wireless lan. I've left out the BSSID.
[...]
> Sometimes the solution is turn off and turn on again the Wi-Fi switch. I know
> the problem six or eight months ago.

The firmware for this device was last changed 2 years ago; therefore
this is not likely to be a firmware bug.  It might be a bug in the
driver, or a hardware problem (the wifi switch not making a good
connection).  Could you test the kernel package from stable
(linux-image-2.6.32-5-amd64)?

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

[Ben Hutchings]

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.

Ben.

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


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

Processed: Re: udev loading radeon drivers garbles screen output

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 649448 src:linux-2.6 linux-2.6/3.0.0-3
Bug #649448 [linux-image-3.0.0-1-amd64] udev loading radeon drivers garbles 
screen output
Bug reassigned from package 'linux-image-3.0.0-1-amd64' to 'src:linux-2.6'.
Bug No longer marked as found in versions linux-2.6/3.0.0-3.
Bug #649448 [src:linux-2.6] udev loading radeon drivers garbles screen output
Bug Marked as found in versions linux-2.6/3.0.0-3.
> severity 649448 important
Bug #649448 [src:linux-2.6] udev loading radeon drivers garbles screen output
Severity set to 'important' from 'normal'

> retitle 649448 radeon (evergreen): random-looking pattern of pixels when 
> firmware not installed
Bug #649448 [src:linux-2.6] udev loading radeon drivers garbles screen output
Changed Bug title to 'radeon (evergreen): random-looking pattern of pixels when 
firmware not installed' from 'udev loading radeon drivers garbles screen output'
> tags 649448 + upstream
Bug #649448 [src:linux-2.6] radeon (evergreen): random-looking pattern of 
pixels when firmware not installed
Added tag(s) upstream.
> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
649448: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649448
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.132183738515246.transcr...@bugs.debian.org

Bug#649448: udev loading radeon drivers garbles screen output

[Jonathan Nieder]

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.

Thanks for reporting it.  If you can (for example by ssh-ing in),
please attach full output from "dmesg" and from
"/usr/share/bug/xserver-xorg-video-radeon/script 3>&1" after
reproducing the problem.

Sincerely,
Jonathan

[1] http://bugs.debian.org/607194
[2] http://bugs.debian.org/637943
[3] http://bugs.debian.org/627497



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

Bug#649449: firmware-iwlwifi: "Card state received: HW:Kill SW:On" and "Not sending command - RF KILL"

[dayer]

Package: firmware-iwlwifi
Version: 0.34
Severity: important

Hi,

I'm using a Toshiba laptop model U200-191 with a wireless card "Intel
Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)"
(according to lspci). My laptop has several disconnections, it depends on the
network and this situation happens randomly. A day the connection goes very
well, without cuts, but next day, with the same network, position and power
signal, there're several disconnections. Now, for example, according on
iwconfig the network has Link Quality=54/70  and Signal level=-56 dBm, and it
has been several cuts.

I paste the dmesg ouput using Network Manager and with Network Manager stopped
and using only a shell to configure the wireless lan. I've left out the BSSID.

With Network Manager (two cuts):
-
[31806.069228] iwl3945 :02:00.0: Card state received: HW:Kill SW:On
[31806.069416] iwl3945 :02:00.0: Not sending command - RF KILL
[31806.069422] iwl3945 :02:00.0: Error sending REPLY_QOS_PARAM:
enqueue_hcmd failed: -5
[31806.069446] iwl3945 :02:00.0: Not sending command - RF KILL
[31806.069451] iwl3945 :02:00.0: Error sending REPLY_RXON_ASSOC:
enqueue_hcmd failed: -5
[31806.069459] iwl3945 :02:00.0: Not sending command - RF KILL
[31806.069480] iwl3945 :02:00.0: Error sending REPLY_RXON: enqueue_hcmd
failed: -5
[31806.069484] iwl3945 :02:00.0: Error setting new configuration (-5).
[31806.069489] iwl3945 :02:00.0: Not sending command - RF KILL
[31806.069510] iwl3945 :02:00.0: Error sending REPLY_RXON_ASSOC:
enqueue_hcmd failed: -5
[31806.069516] wlan0: deauthenticating from xx:xx:xx:xx:xx:xx by local choice
(reason=3)
[31806.092075] iwl3945 :02:00.0: Not sending command - RF KILL
[31806.092079] iwl3945 :02:00.0: Error sending REPLY_REMOVE_STA:
enqueue_hcmd failed: -5
[31806.092101] iwl3945 :02:00.0: Error removing station xx:xx:xx:xx:xx:xx
[31806.100185] iwl3945 :02:00.0: Not sending command - RF KILL
[31806.100192] iwl3945 :02:00.0: Error sending REPLY_RXON_ASSOC:
enqueue_hcmd failed: -5
[31806.100220] iwl3945 :02:00.0: Not sending command - RF KILL
[31806.100226] iwl3945 :02:00.0: Error sending REPLY_LEDS_CMD: enqueue_hcmd
failed: -5
[31806.100253] iwl3945 :02:00.0: Not sending command - RF KILL
[31806.100259] iwl3945 :02:00.0: Error sending REPLY_RXON: enqueue_hcmd
failed: -5
[31806.100282] iwl3945 :02:00.0: Error setting new configuration (-5).
[31806.100354] cfg80211: Calling CRDA to update world regulatory domain
[31806.116188] iwl3945 :02:00.0: Not sending command - RF KILL
[31806.116214] iwl3945 :02:00.0: Error sending REPLY_RXON: enqueue_hcmd
failed: -5
[31806.116221] iwl3945 :02:00.0: Error setting new configuration (-5).
[31806.120091] iwl3945 :02:00.0: MAC is in deep sleep!.  CSR_GP_CNTRL =
0x040003DD
[31817.434865] wlan0: authenticate with xx:xx:xx:xx:xx:xx (try 1)
[31817.436629] wlan0: authenticated
[31817.440387] wlan0: associate with xx:xx:xx:xx:xx:xx (try 1)
[31817.449451] wlan0: RX AssocResp from xx:xx:xx:xx:xx:xx (capab=0x471 status=0
aid=1)
[31817.449455] wlan0: associated
[31896.713864] iwl3945 :02:00.0: Card state received: HW:Kill SW:On
[31896.714089] iwl3945 :02:00.0: Not sending command - RF KILL
[31896.714096] iwl3945 :02:00.0: Error sending REPLY_QOS_PARAM:
enqueue_hcmd failed: -5
[31896.714123] iwl3945 :02:00.0: Not sending command - RF KILL
[31896.714128] iwl3945 :02:00.0: Error sending REPLY_RXON_ASSOC:
enqueue_hcmd failed: -5
[31896.714156] iwl3945 :02:00.0: Not sending command - RF KILL
[31896.714179] iwl3945 :02:00.0: Error sending REPLY_RXON: enqueue_hcmd
failed: -5
[31896.714185] iwl3945 :02:00.0: Error setting new configuration (-5).
[31896.714191] iwl3945 :02:00.0: Not sending command - RF KILL
[31896.714214] iwl3945 :02:00.0: Error sending REPLY_RXON_ASSOC:
enqueue_hcmd failed: -5
[31896.714222] wlan0: deauthenticating from xx:xx:xx:xx:xx:xx by local choice
(reason=3)
[31896.748067] iwl3945 :02:00.0: Not sending command - RF KILL
[31896.748072] iwl3945 :02:00.0: Error sending REPLY_REMOVE_STA:
enqueue_hcmd failed: -5
[31896.748094] iwl3945 :02:00.0: Error removing station xx:xx:xx:xx:xx:xx
[31896.761516] iwl3945 :02:00.0: Not sending command - RF KILL
[31896.761524] iwl3945 :02:00.0: Error sending REPLY_RXON_ASSOC:
enqueue_hcmd failed: -5
[31896.761551] iwl3945 :02:00.0: Not sending command - RF KILL
[31896.761556] iwl3945 :02:00.0: Error sending REPLY_LEDS_CMD: enqueue_hcmd
failed: -5
[31896.761586] iwl3945 :02:00.0: Not sending command - RF KILL
[31896.761609] iwl3945 :02:00.0: Error sending REPLY_RXON: enqueue_hcmd
failed: -5
[31896.761615] iwl3945 :02:00.0: Error setting new configuration (-5).
[31896.761706] cfg80211: Calling CRDA to update world regulatory domain
[31896.776127] iwl3945 :02:00.0: Not sending command - RF KILL
[31896.776154] 

Bug#649448: udev loading radeon drivers garbles screen output

[Martin von Gagern]

Package: linux-image-3.0.0-1-amd64
Version: 3.0.0-3

This is to inform you of a possible problem. I've solved it to my own
satisfaction, so if I'm the only one, feel free to ignore this report.

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.

Passing "init=/bin/bash" on the kernel command line, I could get a
working text console. Manually executing the udev init script from there
has the same effect.

Possible workarounds seem to include:
- removing the kernel/drivers/gpu/drm/radeon/radeon.ko kernel module
  from the kernel module tree
- Adding a line "blacklist radeon" to /etc/modprobe.d/blacklist.conf,
  followed by running "depmod -a". Seems I forgot that on my first
  attempt, causing me hours of unnecessary work.
Adding "video=vga16fb" to the kernel command line didn't help.

It seems that the radeon.ko module itself is to blame, neither one of
its dependencies nor some other module depending on it. After moving the
file back in place, a "modprobe -v radeon" prints the following commands
(over ssh):
> insmod /lib/modules/3.0.0-1-amd64/kernel/drivers/power/power_supply.ko 
> insmod /lib/modules/3.0.0-1-amd64/kernel/drivers/i2c/algos/i2c-algo-bit.ko 
> insmod /lib/modules/3.0.0-1-amd64/kernel/drivers/gpu/drm/drm.ko 
> insmod /lib/modules/3.0.0-1-amd64/kernel/drivers/gpu/drm/drm_kms_helper.ko 
> insmod /lib/modules/3.0.0-1-amd64/kernel/drivers/gpu/drm/ttm/ttm.ko 
> insmod /lib/modules/3.0.0-1-amd64/kernel/drivers/gpu/drm/radeon/radeon.ko 

Running those commands manually gives me this (over netconsole):
> [  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
The middle line doesn't seem to occur every time.

Not having GPU accelleration due to lack of free firmware is acceptable.
Not having a usable text console can be a real problem. Particularly as
that makes fixing the problem a real challenge.

The controller in question is located on my motherboard, an ASrock A75
Extreme6. "lspci -vvv" describes it like this:
> 00:01.0 VGA compatible controller: ATI Technologies Inc Device 9644 (prog-if 
> 00 [VGA controller])
> Subsystem: ASRock Incorporation Device 9640
> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- 
> SERR-  Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 11
> Region 0: Memory at fc00 (32-bit, prefetchable) [size=32M]
> Region 1: I/O ports at f000 [size=256]
> Region 2: Memory at feb0 (32-bit, non-prefetchable) [size=256K]
> Expansion ROM at  [disabled]
> Capabilities: [50] Power Management version 3
> Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
> Capabilities: [58] Express (v2) Root Complex Integrated Endpoint, MSI 
> 00
> DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <4us, 
> L1 unlimited
> ExtTag+ RBE+ FLReset-
> DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
> Unsupported-
> RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
> MaxPayload 128 bytes, MaxReadReq 128 bytes
> DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- 
> TransPend-
> LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, 
> Latency L0 <64ns, L1 <1us
> ClockPM- Surprise- LLActRep- BwNot-
> LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
> LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- 
> DLActive- BWMgmt- ABWMgmt-
> DevCap2: Completion Timeout: Not Supported, TimeoutDis-
> DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
> LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- 
> SpeedDis-, Selectable De-emphasis: -6dB
>  Transmit Margin: Normal Operating Range, 
> EnterModifiedCompliance- ComplianceSOS-
>  Compliance De-emphasis: -6dB
> LnkSta2: Current De-emphasis Level: -6dB
> Capabilities: [a0] MSI: Enable- Count=1/1 Maskable- 64bit+
> Address:   Data: 
> Capabilities: [100 v1] Vendor Specific Infor

Re: Increasing minimum 'i386' processor

[David Goodenough]

On Sunday 20 Nov 2011, Ben Hutchings wrote:
> On Sun, 2011-11-20 at 19:43 +, David Goodenough wrote:
> > On Sunday 20 Nov 2011, Ben Hutchings wrote:
> > > On Sun, 2011-11-20 at 10:10 +, David Goodenough wrote:
> > > > On Saturday 19 Nov 2011, 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.
> > > > > 
> > > > > The 486-class processors that would no longer be supported are:
> > > > > 1. All x86 processors with names including '486'
> > > > > 2. AMD Am5x86
> > > > > 3. Cyrix/IBM/ST 5x86, 6x86 and MediaGX
> > > > > 4. UMC U5D and U5S
> > > > > 5. AMD/NSC Geode GX1, Geode SC1100, Elan SC4xx and SC5xx
> > > > 
> > > > I am still running a bunch of systems with SC1100 processors on them.
> > > > They are (and always have been) running off the shelf Debian kernels
> > > > and I would much rather keep it that way.
> > > 
> > > [...]
> > > 
> > > Then keep them running.  'squeeze' should continue to receive security
> > > updates until late 2013.
> > > 
> > > Ben.
> > 
> > Actually I am currently in the process of upgrading them because the
> > wireless cards they had are no longer available and I am having to
> > replace them with new ath5k compatible ones.  I also need to work them
> > in frequencies where I need DFS support, and that is only just being
> > added to the driver.
> > 
> > So I have to upgrade them.
> > 
> > And this could/will happen again in the future.
> 
> Whatever is decided, you should have some years' warning that you either
> need to upgrade the hardware or hire someone to continue support (though
> I doubt it'll be worth it).
> 
> Ben.
Actually I do not generally find out that I can not get more of a part
until I come to order it.  I then have to look for new hardware and make
sure that it is supported.  I am having to rebuild these boxes with sid
packages as those are the only ones with the relevant support.  

While I can build my own debs (and have done so in the past) if I can 
avoid it I would much rather do so as it is one less thing to do.

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/20202240.14331.david.goodeno...@btconnect.com

Processed: tagging 649406

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 649406 + moreinfo
Bug #649406 [linux-2.6] usb-storage: System freezes after attaching Huawei 
E156g usb modem
Added tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
649406: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649406
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.132182387211934.transcr...@bugs.debian.org

Bug#649406: usb-storage: System freezes after attaching Huawei E156g usb modem

[Ben Hutchings]

On Sun, 2011-11-20 at 19:22 +0100, Mateusz Zalega wrote:
> Package: linux-2.6
> 
> Version: 3.1.1-1
> File: usb-storage
> Severity: important
> 
> Connecting a Huawei E156g completely freezes my system for 5-7 seconds every 
> 10-15 seconds. I've had to remove usb-storage module to get it to work. The
> problem appeared when I switched to 3.1.0-1 kernel from 2.6.32-5.
> 
> 
> -- Package-specific info:
> ** Version:
> 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
> 
> ** Command line:
> BOOT_IMAGE=/boot/vmlinuz-3.1.0-1-amd64 
> root=UUID=1c1e57ee-69c1-45e3-a67f-93b994d55a49 ro quiet
> 
> ** Tainted: WO (4608)
>  * Taint on warning.

Please provide the first 'WARNING' log messages.

>  * Out-of-tree module has been loaded.
[...]

I doubt that it's relevant, but please test without VirtualBox loaded.

Ben.

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
  - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'


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

Re: Increasing minimum 'i386' processor

[Ben Hutchings]

On Sun, 2011-11-20 at 19:43 +, David Goodenough wrote:
> On Sunday 20 Nov 2011, Ben Hutchings wrote:
> > On Sun, 2011-11-20 at 10:10 +, David Goodenough wrote:
> > > On Saturday 19 Nov 2011, 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.
> > > > 
> > > > The 486-class processors that would no longer be supported are:
> > > > 1. All x86 processors with names including '486'
> > > > 2. AMD Am5x86
> > > > 3. Cyrix/IBM/ST 5x86, 6x86 and MediaGX
> > > > 4. UMC U5D and U5S
> > > > 5. AMD/NSC Geode GX1, Geode SC1100, Elan SC4xx and SC5xx
> > > 
> > > I am still running a bunch of systems with SC1100 processors on them.
> > > They are (and always have been) running off the shelf Debian kernels
> > > and I would much rather keep it that way.
> > 
> > [...]
> > 
> > Then keep them running.  'squeeze' should continue to receive security
> > updates until late 2013.
> > 
> > Ben.
> Actually I am currently in the process of upgrading them because the
> wireless cards they had are no longer available and I am having to replace
> them with new ath5k compatible ones.  I also need to work them in frequencies
> where I need DFS support, and that is only just being added to the driver.
> 
> So I have to upgrade them.
> 
> And this could/will happen again in the future.

Whatever is decided, you should have some years' warning that you either
need to upgrade the hardware or hire someone to continue support (though
I doubt it'll be worth it).

Ben.

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
  - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'


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

Re: Increasing minimum 'i386' processor

[David Goodenough]

On Sunday 20 Nov 2011, Ben Hutchings wrote:
> On Sun, 2011-11-20 at 10:10 +, David Goodenough wrote:
> > On Saturday 19 Nov 2011, 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.
> > > 
> > > The 486-class processors that would no longer be supported are:
> > > 1. All x86 processors with names including '486'
> > > 2. AMD Am5x86
> > > 3. Cyrix/IBM/ST 5x86, 6x86 and MediaGX
> > > 4. UMC U5D and U5S
> > > 5. AMD/NSC Geode GX1, Geode SC1100, Elan SC4xx and SC5xx
> > 
> > I am still running a bunch of systems with SC1100 processors on them.
> > They are (and always have been) running off the shelf Debian kernels
> > and I would much rather keep it that way.
> 
> [...]
> 
> Then keep them running.  'squeeze' should continue to receive security
> updates until late 2013.
> 
> Ben.
Actually I am currently in the process of upgrading them because the
wireless cards they had are no longer available and I am having to replace
them with new ath5k compatible ones.  I also need to work them in frequencies
where I need DFS support, and that is only just being added to the driver.

So I have to upgrade them.

And this could/will happen again in the future.

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/20201943.23753.david.goodeno...@btconnect.com

Bug#648939: USB mouse stops work on battery power

[Erik de Castro Lopo]

Jonathan Nieder wrote:

> found 648939 linux-2.6/2.6.33-1~experimental.5
> quit
> 
> Erik de Castro Lopo wrote:
> 
> > Here are two more data points (version numbers from /proc/version):
> >
> > Good2.6.32-5-amd64 (Debian 2.6.32-39)
> > Bad 2.6.33-2-amd64 (Debian 2.6.33-1~experimental.5)
> 
> Ah, that's a much more manageable range.
> 
> > Are those two close enough?
> 
> I assume 2.6.33-1~experimental.3 reproduces it, too?

Yes, problem was reproduced in 2.6.33-1~experimental.3. No problem
with 2.6.32-39.

> If so, that's as much as we can learn from the pre-compiled packages,
> yes.  I'll try to find time tomorrow to look through the package list
> and see if any of the changes in 2.6.33 jumps out at me.

Great. Thanks.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/



-- 
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/2021061702.b93295bb2c3a26c73f8af...@mega-nerd.com

Bug#649412: linux-image-3.1.0-1-amd64: "No route to host" after some time with iwlagn and kernel 3.1

[Fernando Tarlá Cardoso Lemos]

Package: linux-2.6

Version: 3.1.1-1
Severity: normal

After upgrading to 3.1, I get somewhat periodic network problems with iwlagn.
This is a Dell laptop (Vostro 3450) with a Centrino 1030 BGN interface. I'm
using a 802.11g (not 802.11n) router with WPA2 authentication. The router
advertises the SSID. I haven't had the opportunity to test this with other
routers yet.

I boot up, and after a few minutes (usually between 400 and 1000 seconds after
I've connected), I get "Destination Host Unreachable" network errors:


>From 192.168.0.102 icmp_seq=343 Destination Host Unreachable
>From 192.168.0.102 icmp_seq=344 Destination Host Unreachable
>From 192.168.0.102 icmp_seq=345 Destination Host Unreachable
>From 192.168.0.102 icmp_seq=346 Destination Host Unreachable
>From 192.168.0.102 icmp_seq=347 Destination Host Unreachable
>From 192.168.0.102 icmp_seq=348 Destination Host Unreachable
>From 192.168.0.102 icmp_seq=349 Destination Host Unreachable
>From 192.168.0.102 icmp_seq=350 Destination Host Unreachable


192.168.0.102 is my current IP address:

$ ifconfig wlan0
wlan0 Link encap:Ethernet  HWaddr bc:77:37:b3:6a:cd  
  inet addr:192.168.0.102  Bcast:192.168.0.255  Mask:255.255.255.0
  inet6 addr: fe80::be77:37ff:feb3:6acd/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:4293 errors:0 dropped:0 overruns:0 frame:0
  TX packets:4326 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000 
  RX bytes:3687812 (3.5 MiB)  TX bytes:530060 (517.6 KiB)

>From then on, the network connectivity isn't re-established unless I
disconnect and reconnect (either by rebooting the router, using rfkill to
disconnect and reconnect or simply disconnecting and reconnecting via the NM
applet).

This issue does NOT happen with kernel 3.0. I'm 100% sure it's not a
configuration issue. If I switch back to 3.0, I can continue connected the
whole day. Then I boot into 3.1 and the problems resume.



My routing table is fine:

$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric RefUse Iface
0.0.0.0 192.168.0.1 0.0.0.0 UG0  00 wlan0
192.168.0.0 0.0.0.0 255.255.255.0   U 2  00 wlan0

This is iwconfig output while I'm still connected:

wlan0 IEEE 802.11bgn  ESSID:"fernandotcl"  
  Mode:Managed  Frequency:2.427 GHz  Access Point: 00:21:91:34:BB:6B   
  Bit Rate=54 Mb/s   Tx-Power=15 dBm   
  Retry  long limit:7   RTS thr:off   Fragment thr:off
  Power Management:off
  Link Quality=70/70  Signal level=-27 dBm  
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:11   Missed beacon:0

And when I get the above mentioned problems:

wlan0 IEEE 802.11bgn  ESSID:"fernandotcl"  
  Mode:Managed  Frequency:2.427 GHz  Access Point: 00:21:91:34:BB:6B   
  Bit Rate=48 Mb/s   Tx-Power=15 dBm   
  Retry  long limit:7   RTS thr:off   Fragment thr:off
  Power Management:off
  Link Quality=70/70  Signal level=-26 dBm  
  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
  Tx excessive retries:0  Invalid misc:79   Missed beacon:0

The number of "Invalid misc" keeps growing. Other than that, everything seems
normal. As you can see, I'm still associated to the AP.


I couldn't find anything that stands out in dmesg, messages or daemon.log.
Likewise, I didn't notice anything special when comparing dmesg, messages and
daemon.log between 3.0 and 3.1.


Finally the stable kernel 3.1.1 has two fixes for iwlagn, but I think one of
them is related to firmware loading, not sure about the other. Please let me
know if I should file the bug upstream (is
http://bugzilla.intellinuxwireless.org/ the right place?). I looked for
upstream bug reports, but didn't find anything that matched the problem I'm
facing.

Also please let me know of any tests you might want me to perform.


I didn't have pciutils installed by the time I started composing this report,
so here's the lspci -nn output, for the sake of completeness:

00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor 
Family DRAM Controller [8086:0104] (rev 09)
00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core 
Processor Family Integrated Graphics Controller [8086:0116] (rev 09)
00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series 
Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
00:1a.0 USB Controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset 
Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 05)
00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset 
Family High Definition Audio Controller [8086:1c20] (rev 05)
00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset 
Family PCI Express Root Po

Bug#649406: usb-storage: System freezes after attaching Huawei E156g usb modem

[Mateusz Zalega]

Package: linux-2.6

Version: 3.1.1-1
File: usb-storage
Severity: important

Connecting a Huawei E156g completely freezes my system for 5-7 seconds every 
10-15 seconds. I've had to remove usb-storage module to get it to work. The
problem appeared when I switched to 3.1.0-1 kernel from 2.6.32-5.


-- Package-specific info:
** Version:
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

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.1.0-1-amd64 
root=UUID=1c1e57ee-69c1-45e3-a67f-93b994d55a49 ro quiet

** Tainted: WO (4608)
 * Taint on warning.
 * Out-of-tree module has been loaded.

** Kernel log:
[ 4424.484120] usb 1-5: new high speed USB device number 9 using ehci_hcd
[ 4424.627486] usb 1-5: New USB device found, idVendor=12d1, idProduct=1003
[ 4424.627496] usb 1-5: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[ 4424.627503] usb 1-5: Product: HUAWEI Mobile
[ 4424.627509] usb 1-5: Manufacturer: HUAWEI Technology
[ 4424.631650] scsi17 : usb-storage 1-5:1.0
[ 4424.632957] usb 1-5: USB disconnect, device number 9
[ 4432.004088] usb 1-5: new high speed USB device number 10 using ehci_hcd
[ 4432.147614] usb 1-5: New USB device found, idVendor=12d1, idProduct=1003
[ 4432.147624] usb 1-5: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[ 4432.147632] usb 1-5: Product: HUAWEI Mobile
[ 4432.147637] usb 1-5: Manufacturer: HUAWEI Technology
[ 4432.152255] option 1-5:1.0: GSM modem (1-port) converter detected
[ 4432.153466] usb 1-5: GSM modem (1-port) converter now attached to ttyUSB0
[ 4432.153790] option 1-5:1.1: GSM modem (1-port) converter detected
[ 4432.154014] usb 1-5: GSM modem (1-port) converter now attached to ttyUSB1
[ 4432.154779] scsi20 : usb-storage 1-5:1.2
[ 4432.156943] scsi21 : usb-storage 1-5:1.3
[ 4433.155603] scsi 20:0:0:0: CD-ROMHUAWEI   Mass Storage 2.31 
PQ: 0 ANSI: 2
[ 4433.155697] scsi: killing requests for dead queue
[ 4433.155768] scsi: killing requests for dead queue
[ 4433.155826] scsi: killing requests for dead queue
[ 4433.155883] scsi: killing requests for dead queue
[ 4433.155938] scsi: killing requests for dead queue
[ 4433.155994] scsi: killing requests for dead queue
[ 4433.156228] scsi: killing requests for dead queue
[ 4433.156285] scsi: killing requests for dead queue
[ 4433.163238] scsi 21:0:0:0: Direct-Access HUAWEI   MMC Storage  2.31 
PQ: 0 ANSI: 2
[ 4433.163322] scsi: killing requests for dead queue
[ 4433.163414] scsi: killing requests for dead queue
[ 4433.163499] scsi: killing requests for dead queue
[ 4433.163581] scsi: killing requests for dead queue
[ 4433.163676] scsi: killing requests for dead queue
[ 4433.163760] scsi: killing requests for dead queue
[ 4433.163844] scsi: killing requests for dead queue
[ 4433.163918] scsi: killing requests for dead queue
[ 4433.166590] sr0: scsi-1 drive
[ 4433.166839] sr 20:0:0:0: Attached scsi CD-ROM sr0
[ 4433.167026] sr 20:0:0:0: Attached scsi generic sg1 type 5
[ 4433.167428] sd 21:0:0:0: Attached scsi generic sg2 type 0
[ 4433.176599] sd 21:0:0:0: [sdb] Attached SCSI removable disk
[ 4443.000292] option: option_instat_callback: error -108
[ 4443.000582] option1 ttyUSB0: GSM modem (1-port) converter now disconnected 
from ttyUSB0
[ 4443.000634] option 1-5:1.0: device disconnected
[ 4447.373546] usb 1-5: USB disconnect, device number 10
[ 4447.380844] option1 ttyUSB1: GSM modem (1-port) converter now disconnected 
from ttyUSB1
[ 4447.380877] option 1-5:1.1: device disconnected
[ 4447.384627] scsi: killing requests for dead queue
[ 4447.389877] scsi: killing requests for dead queue
[ 4464.732112] usb 1-7: new high speed USB device number 11 using ehci_hcd
[ 4464.875368] usb 1-7: New USB device found, idVendor=12d1, idProduct=1003
[ 4464.875379] usb 1-7: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[ 4464.875386] usb 1-7: Product: HUAWEI Mobile
[ 4464.875391] usb 1-7: Manufacturer: HUAWEI Technology
[ 4464.879552] scsi22 : usb-storage 1-7:1.0
[ 4464.880166] usb 1-7: USB disconnect, device number 11
[ 4472.256164] usb 1-7: new high speed USB device number 12 using ehci_hcd
[ 4472.399624] usb 1-7: New USB device found, idVendor=12d1, idProduct=1003
[ 4472.399634] usb 1-7: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[ 4472.399642] usb 1-7: Product: HUAWEI Mobile
[ 4472.399647] usb 1-7: Manufacturer: HUAWEI Technology
[ 4472.404215] option 1-7:1.0: GSM modem (1-port) converter detected
[ 4472.404535] usb 1-7: GSM modem (1-port) converter now attached to ttyUSB0
[ 4472.404825] option 1-7:1.1: GSM modem (1-port) converter detected
[ 4472.405079] usb 1-7: GSM modem (1-port) converter now attached to ttyUSB1
[ 4472.408749] scsi25 : usb-storage 1-7:1.2
[ 4472.410669] scsi26 : usb-storage 1-7:1.3
[ 4473.411844] scsi 25:0:0:0: CD-ROMHUAWEI   Mass Storage 2.31 
PQ: 0 ANSI: 2
[ 4473.411901] scsi: killing requests for dead queue
[ 4473.411966] scsi: killing requests for dead

Bug#649394: marked as done (linux-source-2.6.32: can't build 2.6.32-5 using 2.6_2.6.32-34squeeze1)

[Debian Bug Tracking System]

Your message dated Sun, 20 Nov 2011 18:09:13 +
with message-id <1321812553.2839.40.camel@deadeye>
and subject line Re: Bug#649394: linux-source-2.6.32: can't build 2.6.32-5 
using 2.6_2.6.32-34squeeze1
has caused the Debian Bug report #649394,
regarding linux-source-2.6.32: can't build 2.6.32-5 using 2.6_2.6.32-34squeeze1
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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
649394: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649394
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-source-2.6.32
Version: 2.6.32-38
Severity: normal

I'm running 2.6.32-5-xen-amd64 and I'd like to compile a new vmlinuz
with enhanced errno reporting (distinguish between ENOMEM returns
in fork.c).  When I try to build 2.6.32-5, it applies all the patches
through 34squeeze1 (and actually fails to do that as one of the
later patches conflicts with my change).

What I did:

dpkg-source -x linux-2.6_2.6.32-34squeeze1.dsc
/usr/src/kernel-patches/all/2.6.32/apply/debian 5
cd linux-2.6-2.6.32
vi kernel/fork.c
fakeroot make -f debian/rules.gen binary-arch_amd64_xen

What happened:

(all the rest of the patches started to apply, and failed at version
14 where there was another edit to fork.c, so the build
failed)

What I expected:

A build without all the rest of the patches being applied.



Variant:

in "What I did", I tried this also, and all the patches still got
applied:

dpkg-source -x linux-2.6_2.6.32-34squeeze1.dsc
/usr/src/kernel-patches/all/2.6.32/apply/debian 5
cd linux-2.6-2.6.32
vi kernel/fork.c
fakeroot make -f debian/rules.gen build_amd64_xen_amd64_real


I looked in the makefiles, and noted that in debian/rules.real, the
apply-patch command definition has no way to specify the patch-level:

define patch_cmd
cd '$(DIR)'; python '$(CURDIR)/debian/bin/patch.apply' 
--overwrite-home='$(CURDIR)/debian/patches'
endef

Maybe the $(ABINAME) could be used to produce a "patch-level" for this
command?

I'm not all that familiar with building Debian kernels from source, I'd
be happy to learn the "right way" if I was doing it wrong.  I was
following instructions from
http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage
and supplemented it by reading the makefiles.

bjb





-- System Information:
Debian Release: 6.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages linux-source-2.6.32 depends on:
ii  binutils  2.20.1-16  The GNU assembler, linker and bina
ii  bzip2 1.0.5-6high-quality block-sorting file co

Versions of packages linux-source-2.6.32 recommends:
ii  gcc   4:4.4.5-1  The GNU C compiler
ii  libc6-dev [libc-dev]  2.11.2-10  Embedded GNU C Library: Developmen
ii  make  3.81-8 An utility for Directing compilati

Versions of packages linux-source-2.6.32 suggests:
ii  kernel-package12.036+nmu1A utility for building Linux kerne
ii  libncurses5-dev [ncurses- 5.7+20100313-5 developer's libraries and docs for
pn  libqt3-mt-dev  (no description available)

-- no debconf information


--- End Message ---
--- Begin Message ---
Not a bug.

See
.

Ben.

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
  - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'


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

Re: Increasing minimum 'i386' processor

[Ben Hutchings]

On Sun, 2011-11-20 at 10:10 +, David Goodenough wrote:
> On Saturday 19 Nov 2011, 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.
> > 
> > The 486-class processors that would no longer be supported are:
> > 1. All x86 processors with names including '486'
> > 2. AMD Am5x86
> > 3. Cyrix/IBM/ST 5x86, 6x86 and MediaGX
> > 4. UMC U5D and U5S
> > 5. AMD/NSC Geode GX1, Geode SC1100, Elan SC4xx and SC5xx
> I am still running a bunch of systems with SC1100 processors on them.
> They are (and always have been) running off the shelf Debian kernels
> and I would much rather keep it that way.
[...]

Then keep them running.  'squeeze' should continue to receive security
updates until late 2013.

Ben.

-- 
Ben Hutchings
Usenet is essentially a HUGE group of people passing notes in class.
  - Rachel Kadel, `A Quick Guide to Newsgroup Etiquette'


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

Bug#649394: linux-source-2.6.32: can't build 2.6.32-5 using 2.6_2.6.32-34squeeze1

[Brenda J. Butler]

I see with further experimentation that the ABINAME being 5 and
the patch-release that I want being 5 is probably just a coincidence.

I added 5 (literal) as an argument to patch_command and it seems to be
building without the extra patches.  I haven't tried putting in
my change yet ... will report on whether that succeeds later.

bjb


On Sun, Nov 20, 2011 at 11:28:45AM -0500, Brenda J. Butler wrote:
> Package: linux-source-2.6.32
> Version: 2.6.32-38
> Severity: normal
> 
> I'm running 2.6.32-5-xen-amd64 and I'd like to compile a new vmlinuz
> with enhanced errno reporting (distinguish between ENOMEM returns
> in fork.c).  When I try to build 2.6.32-5, it applies all the patches
> through 34squeeze1 (and actually fails to do that as one of the
> later patches conflicts with my change).
> 
> What I did:
> 
> dpkg-source -x linux-2.6_2.6.32-34squeeze1.dsc
> /usr/src/kernel-patches/all/2.6.32/apply/debian 5
> cd linux-2.6-2.6.32
> vi kernel/fork.c
> fakeroot make -f debian/rules.gen binary-arch_amd64_xen
> 
> What happened:
> 
> (all the rest of the patches started to apply, and failed at version
> 14 where there was another edit to fork.c, so the build
> failed)
> 
> What I expected:
> 
> A build without all the rest of the patches being applied.
> 
> 
> 
> Variant:
> 
> in "What I did", I tried this also, and all the patches still got
> applied:
> 
> dpkg-source -x linux-2.6_2.6.32-34squeeze1.dsc
> /usr/src/kernel-patches/all/2.6.32/apply/debian 5
> cd linux-2.6-2.6.32
> vi kernel/fork.c
> fakeroot make -f debian/rules.gen build_amd64_xen_amd64_real
> 
> 
> I looked in the makefiles, and noted that in debian/rules.real, the
> apply-patch command definition has no way to specify the patch-level:
> 
> define patch_cmd
> cd '$(DIR)'; python '$(CURDIR)/debian/bin/patch.apply' 
> --overwrite-home='$(CURDIR)/debian/patches'
> endef
> 
> Maybe the $(ABINAME) could be used to produce a "patch-level" for this
> command?
> 
> I'm not all that familiar with building Debian kernels from source, I'd
> be happy to learn the "right way" if I was doing it wrong.  I was
> following instructions from
> http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage
> and supplemented it by reading the makefiles.
> 
> bjb
> 
> 
> 
> 
> 
> -- System Information:
> Debian Release: 6.0.3
>   APT prefers stable
>   APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/8 CPU cores)
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages linux-source-2.6.32 depends on:
> ii  binutils  2.20.1-16  The GNU assembler, linker and 
> bina
> ii  bzip2 1.0.5-6high-quality block-sorting file 
> co
> 
> Versions of packages linux-source-2.6.32 recommends:
> ii  gcc   4:4.4.5-1  The GNU C compiler
> ii  libc6-dev [libc-dev]  2.11.2-10  Embedded GNU C Library: 
> Developmen
> ii  make  3.81-8 An utility for Directing 
> compilati
> 
> Versions of packages linux-source-2.6.32 suggests:
> ii  kernel-package12.036+nmu1A utility for building Linux 
> kerne
> ii  libncurses5-dev [ncurses- 5.7+20100313-5 developer's libraries and docs 
> for
> pn  libqt3-mt-dev  (no description available)
> 
> -- no debconf information
> 
> 
---end quoted text---



-- 
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/2020180018.gf7...@sourcerer.ca

Bug#649399: initramfs-tools: please mark Multi-Arch: foreign

[Colin Watson]

Package: initramfs-tools
Version: 0.99
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch precise

Hi,

It would be useful for initramfs-tools to be marked "Multi-Arch:
foreign", to indicate that it can satisfy dependencies of packages of
other architectures.  Although Debian's dpkg doesn't yet do anything
special with this, it's safe to add this tag in advance of package
manager support.

In Ubuntu, this is an early step in being able to crossgrade from i386
to amd64, because we don't have an -amd64 kernel flavour on i386 and (of
course) our kernel packages depend on initramfs-tools.  While Debian
does have an -amd64 flavour on i386, it still wouldn't hurt to add this
tag.

If you're wondering why this tag is needed on an Architecture: all
package, see the multiarch specification:

  
https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages

diff --git a/debian/control b/debian/control
index 75bf493..8ca8827 100644
--- a/debian/control
+++ b/debian/control
@@ -10,6 +10,7 @@ Vcs-Git: git://git.debian.org/git/kernel/initramfs-tools.git
 
 Package: initramfs-tools
 Architecture: all
+Multi-Arch: foreign
 Recommends: busybox (>= 1:1.01-3) | busybox-initramfs
 Depends: klibc-utils (>= 1.5.23-2~), cpio, module-init-tools, udev, findutils 
(>= 4.2.24), ${misc:Depends}
 Suggests: bash-completion

Thanks,

-- 
Colin Watson   [cjwat...@ubuntu.com]



-- 
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/2020174109.gg3...@riva.dynamic.greenend.org.uk

Bug#649394: linux-source-2.6.32: can't build 2.6.32-5 using 2.6_2.6.32-34squeeze1

[Brenda J . Butler]

Package: linux-source-2.6.32
Version: 2.6.32-38
Severity: normal

I'm running 2.6.32-5-xen-amd64 and I'd like to compile a new vmlinuz
with enhanced errno reporting (distinguish between ENOMEM returns
in fork.c).  When I try to build 2.6.32-5, it applies all the patches
through 34squeeze1 (and actually fails to do that as one of the
later patches conflicts with my change).

What I did:

dpkg-source -x linux-2.6_2.6.32-34squeeze1.dsc
/usr/src/kernel-patches/all/2.6.32/apply/debian 5
cd linux-2.6-2.6.32
vi kernel/fork.c
fakeroot make -f debian/rules.gen binary-arch_amd64_xen

What happened:

(all the rest of the patches started to apply, and failed at version
14 where there was another edit to fork.c, so the build
failed)

What I expected:

A build without all the rest of the patches being applied.



Variant:

in "What I did", I tried this also, and all the patches still got
applied:

dpkg-source -x linux-2.6_2.6.32-34squeeze1.dsc
/usr/src/kernel-patches/all/2.6.32/apply/debian 5
cd linux-2.6-2.6.32
vi kernel/fork.c
fakeroot make -f debian/rules.gen build_amd64_xen_amd64_real


I looked in the makefiles, and noted that in debian/rules.real, the
apply-patch command definition has no way to specify the patch-level:

define patch_cmd
cd '$(DIR)'; python '$(CURDIR)/debian/bin/patch.apply' 
--overwrite-home='$(CURDIR)/debian/patches'
endef

Maybe the $(ABINAME) could be used to produce a "patch-level" for this
command?

I'm not all that familiar with building Debian kernels from source, I'd
be happy to learn the "right way" if I was doing it wrong.  I was
following instructions from
http://wiki.debian.org/HowToRebuildAnOfficialDebianKernelPackage
and supplemented it by reading the makefiles.

bjb





-- System Information:
Debian Release: 6.0.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages linux-source-2.6.32 depends on:
ii  binutils  2.20.1-16  The GNU assembler, linker and bina
ii  bzip2 1.0.5-6high-quality block-sorting file co

Versions of packages linux-source-2.6.32 recommends:
ii  gcc   4:4.4.5-1  The GNU C compiler
ii  libc6-dev [libc-dev]  2.11.2-10  Embedded GNU C Library: Developmen
ii  make  3.81-8 An utility for Directing compilati

Versions of packages linux-source-2.6.32 suggests:
ii  kernel-package12.036+nmu1A utility for building Linux kerne
ii  libncurses5-dev [ncurses- 5.7+20100313-5 developer's libraries and docs for
pn  libqt3-mt-dev  (no description available)

-- 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/87bos6kbb6@blueeyes.sourcerer.ca

Bug#648751: linux-image-3.0.0-1-rt-amd64: rcu_preempt_state whileshutdown

[Uwe Kleine-König]

Hello Flávio,

you reported this bug against version 3.0.0-3 which contains 3.0.1-rt11.
Could you please retry with the most recent rt patch?

As the 3.0 kernels are not in Debian any more, you can download an image
from


http://debian.pengutronix.de/debian/pool/main/l/linux-2.6/linux-image-3.0.0-2-rt-amd64_3.0.0-6ptx1_amd64.deb

(once the public archive is completely synced). 3.0.0-6ptx1 contains
3.0.9-rt25.

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |



-- 
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/2020145033.ga30...@pengutronix.de

Re: Increasing minimum 'i386' processor

[Marco d'Itri]

On Nov 19, Ben Hutchings  wrote:

> I think it is time to increase the minimum requirement to 586-class, if
> not for wheezy then immediately after.
I agree, it's time to weight the costs and benefits of supporting
obsolete hardware at the expense of most users.

> (Later it should be increased
> further, and eventually i386 should be reduced to a partial architecture
> that may be installed on amd64 systems.)
Yes, but how much later? :-)

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#649365: linux-image-3.1.0-1-amd64: Broadcom USB adapter not recognised

[Sam Morris]

Package: linux-2.6
Version: 3.1.1-1
Severity: normal

I have the following usb adapter:

Bus 007 Device 002: ID 0a5c:2101 Broadcom Corp. Bluetooth Controller

That used to be recognised by the hci_usb module in 2.6.26, then the btusb 
module
in 2.6.38. As of 3.1.1, however, btusb is loaded but 'hcitool dev'
reports that there are no Bluetooth devices in the system.

-- Package-specific info:
** Version:
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

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.1.0-1-amd64 root=/dev/mapper/durandal-root ro quiet 
splash init=/bin/systemd

** Not tainted

** Kernel log:
[42848.201595] dbus-daemon[975]: ** (polkitd:1449): DEBUG:   0x7f2d20026120
[42848.201611] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  subject is in 
session /org/freedesktop/ConsoleKit/Session2 (local=1 active=1)
[42848.201871] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  is authorized (has 
implicit authorization local=1 active=1)
[42848.201885] dbus-daemon[975]: ** (polkitd:1449): DEBUG:
[42853.567886] dbus-daemon[975]: ** (polkitd:1449): DEBUG: 
system-bus-name::1.42 is inquiring whether system-bus-name::1.51 is authorized 
for org.freedesktop.upower.suspend
[42853.569157] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  user of caller is 
unix-user:root
[42853.570101] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  user of subject is 
unix-user:sam
[42853.570184] dbus-daemon[975]: ** (polkitd:1449): DEBUG: checking whether 
system-bus-name::1.51 is authorized for org.freedesktop.upower.suspend
[42853.574463] dbus-daemon[975]: ** (polkitd:1449): DEBUG:   0x7f2d20024430
[42853.574558] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  subject is in 
session /org/freedesktop/ConsoleKit/Session2 (local=1 active=1)
[42853.574814] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  is authorized (has 
implicit authorization local=1 active=1)
[42853.574884] dbus-daemon[975]: ** (polkitd:1449): DEBUG:
[42853.577591] dbus-daemon[975]: ** (polkitd:1449): DEBUG: 
system-bus-name::1.42 is inquiring whether system-bus-name::1.51 is authorized 
for org.freedesktop.upower.hibernate
[42853.578514] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  user of caller is 
unix-user:root
[42853.579372] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  user of subject is 
unix-user:sam
[42853.579449] dbus-daemon[975]: ** (polkitd:1449): DEBUG: checking whether 
system-bus-name::1.51 is authorized for org.freedesktop.upower.hibernate
[42853.582711] dbus-daemon[975]: ** (polkitd:1449): DEBUG:   0x7f2d20024700
[42853.582797] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  subject is in 
session /org/freedesktop/ConsoleKit/Session2 (local=1 active=1)
[42853.583019] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  is authorized (has 
implicit authorization local=1 active=1)
[42853.583086] dbus-daemon[975]: ** (polkitd:1449): DEBUG:
[42853.587734] dbus-daemon[975]: ** (polkitd:1449): DEBUG: 
system-bus-name::1.42 is inquiring whether system-bus-name::1.51 is authorized 
for org.freedesktop.upower.suspend
[42853.588864] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  user of caller is 
unix-user:root
[42853.589814] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  user of subject is 
unix-user:sam
[42853.589893] dbus-daemon[975]: ** (polkitd:1449): DEBUG: checking whether 
system-bus-name::1.51 is authorized for org.freedesktop.upower.suspend
[42853.594190] dbus-daemon[975]: ** (polkitd:1449): DEBUG:   0x7f2d20024730
[42853.594292] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  subject is in 
session /org/freedesktop/ConsoleKit/Session2 (local=1 active=1)
[42853.594697] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  is authorized (has 
implicit authorization local=1 active=1)
[42853.594775] dbus-daemon[975]: ** (polkitd:1449): DEBUG:
[42853.598209] dbus-daemon[975]: ** (polkitd:1449): DEBUG: 
system-bus-name::1.42 is inquiring whether system-bus-name::1.51 is authorized 
for org.freedesktop.upower.hibernate
[42853.599438] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  user of caller is 
unix-user:root
[42853.600601] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  user of subject is 
unix-user:sam
[42853.600675] dbus-daemon[975]: ** (polkitd:1449): DEBUG: checking whether 
system-bus-name::1.51 is authorized for org.freedesktop.upower.hibernate
[42853.603829] dbus-daemon[975]: ** (polkitd:1449): DEBUG:   0x7f2d20025400
[42853.603921] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  subject is in 
session /org/freedesktop/ConsoleKit/Session2 (local=1 active=1)
[42853.604265] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  is authorized (has 
implicit authorization local=1 active=1)
[42853.604332] dbus-daemon[975]: ** (polkitd:1449): DEBUG:
[42853.608229] dbus-daemon[975]: ** (polkitd:1449): DEBUG: 
system-bus-name::1.42 is inquiring whether system-bus-name::1.51 is authorized 
for org.freedesktop.upower.suspend
[42853.608992] dbus-daemon[975]: ** (polkitd:1449): DEBUG:  user of caller is 
unix-user:roo

Bug#649359: marked as done (linux-image-3.0.0-1-686-pae: Both hibernate and suspend stopped working)

[Debian Bug Tracking System]

Your message dated Sun, 20 Nov 2011 06:02:44 -0600
with message-id <2020120244.ga20...@elie.hsd1.il.comcast.net>
and subject line Re: Both hibernate and suspend stopped working
has caused the Debian Bug report #649359,
regarding linux-image-3.0.0-1-686-pae: Both hibernate and suspend stopped 
working
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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
649359: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649359
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-2.6

Version: 3.0.0-3
Severity: important

Dear Maintainer,

Hibernate/suspend used to work on my Lenovo Thinkpad x220 in the past with the
same kernel. Last time when I updated (gnome2->gnome3 was part of it, but i
doubt this is the cause), I rebooted the system and since then neither
hibernate nor suspend work. I did not make any changes that I would suspect to
cause them to stop working.

When I start hibernation/suspend (by clicking in GUI, pm-hibernate/pm-suspend,
or closing the lid), the laptop freezes going to sleep. Black screen with
cursor appears, sleep-LED starts blinking and I have to use the hardware power
off then. This is perfectly repeatable and happens on every sleep. I suspect
this could be a kernel panic(?).

I tried to regenerate the initrd image and to swapoff/swapon, and to check the
resume device ID, but with no success.

Thank you for any help.

Tomas

---

dmesg | grep 'PM:':
[0.00] PM: Registered nosave memory: 0009d000 -
0009e000
[0.00] PM: Registered nosave memory: 0009e000 -
000a
[0.00] PM: Registered nosave memory: 000a -
000e
[0.00] PM: Registered nosave memory: 000e -
0010
[0.477677] PM: Registering ACPI NVS region at dae9f000 (1048576 bytes)
[1.266207] PM: Hibernation image not present or could not be loaded.
[3.415927] PM: Starting manual resume from disk
[3.415930] PM: Hibernation image partition 8:6 present
[3.415931] PM: Looking for hibernation image.
[3.416077] PM: Image not found (code -22)
[3.416082] PM: Hibernation image not present or could not be loaded.
[3.418773] PM: Marking nosave pages: 0009d000 - 0010
[3.418777] PM: Basic memory bitmaps created
[3.433451] PM: Basic memory bitmaps freed

tail pm-suspend.log:
/usr/lib/pm-utils/sleep.d/95packagekit suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/98video-quirk-db-handler suspend
suspend:
Kernel modesetting video driver detected, not using quirks.

/usr/lib/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/99video suspend suspend:

/usr/lib/pm-utils/sleep.d/99video suspend suspend: success.
Sun Nov 20 11:15:44 CET 2011: performing suspend




-- Package-specific info:
** Version:
Linux version 3.0.0-1-686-pae (Debian 3.0.0-3) (b...@decadent.org.uk) (gcc 
version 4.5.3 (Debian 4.5.3-8) ) #1 SMP Sat Aug 27 16:41:03 UTC 2011

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.0.0-1-686-pae 
root=UUID=0eec03b4-9071-41b5-82a7-ee52330d921c ro quiet

** Not tainted

** Kernel log:
[6.505934] iwlagn :03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[6.505943] iwlagn :03:00.0: setting latency timer to 64
[6.505970] iwlagn :03:00.0: Detected Intel(R) Centrino(R) Advanced-N 
6205 AGN, REV=0xB0
[6.514946] iwlagn :03:00.0: device EEPROM VER=0x715, CALIB=0x6
[6.514947] iwlagn :03:00.0: Device SKU: 0Xb
[6.514949] iwlagn :03:00.0: Valid Tx ant: 0X3, Valid Rx ant: 0X3
[6.515034] iwlagn :03:00.0: Tunable channels: 13 802.11bg, 24 802.11a 
channels
[6.515102] iwlagn :03:00.0: irq 42 for MSI/MSI-X
[6.553098] input: PC Speaker as /devices/platform/pcspkr/input/input6
[6.573323] i801_smbus :00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 
18
[6.614738] iwlagn :03:00.0: loaded firmware version 17.168.5.3 build 
42301
[6.615085] Registered led device: phy0-led
[6.651117] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[6.778963] [drm] Initialized drm 1.1.0 20060810
[6.879172] thinkpad_acpi: ThinkPad ACPI Extras v0.24
[6.879175] thinkpad_acpi: http://ibm-acpi.sf.net/
[6.879176] thinkpad_acpi: ThinkPad BIOS 8DET46WW (1.16 ), EC unknown
[6.879178] thinkpad_acpi: Lenovo ThinkPad X220, model 42872SG
[6.879647] thinkpad_acpi: detected a 8-level brightness capable ThinkPad
[6.879878] thinkpad_acpi: radio switch found; radios are enabled
[6.880010] thinkpad_acpi: possible tabl

Bug#649359: marked as done (linux-image-3.0.0-1-686-pae: Both hibernate and suspend stopped working)

[Debian Bug Tracking System]

Your message dated Sun, 20 Nov 2011 12:42:59 +0100
with message-id 

and subject line linux-image-3.0.0-1-686-pae: Both hibernate and suspend 
stopped working
has caused the Debian Bug report #649359,
regarding linux-image-3.0.0-1-686-pae: Both hibernate and suspend stopped 
working
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.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
649359: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649359
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: linux-2.6

Version: 3.0.0-3
Severity: important

Dear Maintainer,

Hibernate/suspend used to work on my Lenovo Thinkpad x220 in the past with the
same kernel. Last time when I updated (gnome2->gnome3 was part of it, but i
doubt this is the cause), I rebooted the system and since then neither
hibernate nor suspend work. I did not make any changes that I would suspect to
cause them to stop working.

When I start hibernation/suspend (by clicking in GUI, pm-hibernate/pm-suspend,
or closing the lid), the laptop freezes going to sleep. Black screen with
cursor appears, sleep-LED starts blinking and I have to use the hardware power
off then. This is perfectly repeatable and happens on every sleep. I suspect
this could be a kernel panic(?).

I tried to regenerate the initrd image and to swapoff/swapon, and to check the
resume device ID, but with no success.

Thank you for any help.

Tomas

---

dmesg | grep 'PM:':
[0.00] PM: Registered nosave memory: 0009d000 -
0009e000
[0.00] PM: Registered nosave memory: 0009e000 -
000a
[0.00] PM: Registered nosave memory: 000a -
000e
[0.00] PM: Registered nosave memory: 000e -
0010
[0.477677] PM: Registering ACPI NVS region at dae9f000 (1048576 bytes)
[1.266207] PM: Hibernation image not present or could not be loaded.
[3.415927] PM: Starting manual resume from disk
[3.415930] PM: Hibernation image partition 8:6 present
[3.415931] PM: Looking for hibernation image.
[3.416077] PM: Image not found (code -22)
[3.416082] PM: Hibernation image not present or could not be loaded.
[3.418773] PM: Marking nosave pages: 0009d000 - 0010
[3.418777] PM: Basic memory bitmaps created
[3.433451] PM: Basic memory bitmaps freed

tail pm-suspend.log:
/usr/lib/pm-utils/sleep.d/95packagekit suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/98video-quirk-db-handler suspend
suspend:
Kernel modesetting video driver detected, not using quirks.

/usr/lib/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/99video suspend suspend:

/usr/lib/pm-utils/sleep.d/99video suspend suspend: success.
Sun Nov 20 11:15:44 CET 2011: performing suspend




-- Package-specific info:
** Version:
Linux version 3.0.0-1-686-pae (Debian 3.0.0-3) (b...@decadent.org.uk) (gcc 
version 4.5.3 (Debian 4.5.3-8) ) #1 SMP Sat Aug 27 16:41:03 UTC 2011

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.0.0-1-686-pae 
root=UUID=0eec03b4-9071-41b5-82a7-ee52330d921c ro quiet

** Not tainted

** Kernel log:
[6.505934] iwlagn :03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[6.505943] iwlagn :03:00.0: setting latency timer to 64
[6.505970] iwlagn :03:00.0: Detected Intel(R) Centrino(R) Advanced-N 
6205 AGN, REV=0xB0
[6.514946] iwlagn :03:00.0: device EEPROM VER=0x715, CALIB=0x6
[6.514947] iwlagn :03:00.0: Device SKU: 0Xb
[6.514949] iwlagn :03:00.0: Valid Tx ant: 0X3, Valid Rx ant: 0X3
[6.515034] iwlagn :03:00.0: Tunable channels: 13 802.11bg, 24 802.11a 
channels
[6.515102] iwlagn :03:00.0: irq 42 for MSI/MSI-X
[6.553098] input: PC Speaker as /devices/platform/pcspkr/input/input6
[6.573323] i801_smbus :00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 
18
[6.614738] iwlagn :03:00.0: loaded firmware version 17.168.5.3 build 
42301
[6.615085] Registered led device: phy0-led
[6.651117] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[6.778963] [drm] Initialized drm 1.1.0 20060810
[6.879172] thinkpad_acpi: ThinkPad ACPI Extras v0.24
[6.879175] thinkpad_acpi: http://ibm-acpi.sf.net/
[6.879176] thinkpad_acpi: ThinkPad BIOS 8DET46WW (1.16 ), EC unknown
[6.879178] thinkpad_acpi: Lenovo ThinkPad X220, model 42872SG
[6.879647] thinkpad_acpi: detected a 8-level brightness capable ThinkPad
[6.879878] thinkpad_acpi: radio switch found; radios are enabled
[6.880010] thinkpad_acpi: possible tablet mode switch found; 

Re: Increasing minimum 'i386' processor

[Goswin von Brederlow]

Guillem Jover  writes:

> 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:
>
>   
>   
>
> regards,
> guillem

While I agree that the triplet should be unique for all the reasons
stated in the two mails I have to disagree with your conclusion to
change the gcc triplet to i386-linux-gnu.

A gcc compiling for i486-linux-gnu, i585-linux-gnu or even
i686-linux-gnu is not compiling for the i386-linux-gnu ABI. You would be
making the same mistake that arm does on i*86 too, making the triplet
not unique. You could have a "normal" gcc and a i386-linux-gnu-gcc
on your system.

MfG
Goswin


-- 
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/87y5vbf2f8.fsf@frosties.localnet

Bug#649359: Both hibernate and suspend stopped working

[Tomas Kazmar]

Hi Jonathan,

I installed the 3.1.0-1-686-pae kernel from unstable. Both suspend and
hibernate work now.

Thank you a lot for such a quick reply. I spend good three hours yesterday
night debugging why it does not work with no success. With your help now it
took just under an hour and sleep works as it should:)

Tomas

On Sun, Nov 20, 2011 at 12:08 PM, Jonathan Nieder wrote:

> Hi Tomas,
>
> Tomas Kazmar wrote:
>
> > Version: 3.0.0-3
> [...]
> > Hibernate/suspend used to work on my Lenovo Thinkpad x220 in the past
> with the
> > same kernel. Last time when I updated (gnome2->gnome3 was part of it,
> but i
> > doubt this is the cause), I rebooted the system and since then neither
> > hibernate nor suspend work. I did not make any changes that I would
> suspect to
> > cause them to stop working.
>
> Thanks.
>
> There has been an X220 suspend fix in v3.1 (namely v3.1-rc1~22^2~10^2~7^2,
> 2011-07-26).  Please test with a 3.1.y kernel from unstable.
>
> If that doesn't work, your best bet is to follow the instructions from
> [1], and if it turns out to be an i915 bug, let us know the bug number
> so we can track it.
>
> Sincerely,
> Jonathan
>
> [1] http://intellinuxgraphics.org/how_to_report_bug.html
>

Bug#648939: USB mouse stops work on battery power

[Jonathan Nieder]

Jonathan Nieder wrote:

> If so, that's as much as we can learn from the pre-compiled packages,
> yes.  I'll try to find time tomorrow to look through the package list
> and see if any of the changes in 2.6.33 jumps out at me.

By "package list" I meant "upstream changelog".  Sorry for the thinko.

Sleepily,
Jonathan



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

Processed: Re: USB mouse stops work on battery power

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> found 648939 linux-2.6/2.6.33-1~experimental.5
Bug #648939 [linux-2.6] USB mouse stops work on battery power
Bug Marked as found in versions linux-2.6/2.6.33-1~experimental.5.
> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
648939: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648939
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.13217887381659.transcr...@bugs.debian.org

Bug#648939: USB mouse stops work on battery power

[Jonathan Nieder]

found 648939 linux-2.6/2.6.33-1~experimental.5
quit

Erik de Castro Lopo wrote:

> Here are two more data points (version numbers from /proc/version):
>
> Good2.6.32-5-amd64 (Debian 2.6.32-39)
> Bad 2.6.33-2-amd64 (Debian 2.6.33-1~experimental.5)

Ah, that's a much more manageable range.

> Are those two close enough?

I assume 2.6.33-1~experimental.3 reproduces it, too?

If so, that's as much as we can learn from the pre-compiled packages,
yes.  I'll try to find time tomorrow to look through the package list
and see if any of the changes in 2.6.33 jumps out at me.



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

Bug#648939: USB mouse stops work on battery power

[Erik de Castro Lopo]

Jonathan Nieder wrote:

> found 648939 linux-2.6/2.6.37-2
> quit
> 
> Erik de Castro Lopo wrote:
> 
> > Both 2.6.37-2-amd64 and 2.6.38-2-amd64 have the same problem.
> 
> BTW, a more useful version number is that shown in parentheses by
> "cat /proc/version" (also shown by "dpkg-query -W
> linux-image-$(uname -r)"), since it changes more often than the
> package name.

Noted.

Here are two more data points (version numbers from /proc/version):

Good2.6.32-5-amd64 (Debian 2.6.32-39)
Bad 2.6.33-2-amd64 (Debian 2.6.33-1~experimental.5)

Are those two close enough?

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/



-- 
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/2020222310.730e83d8cd0f2bd1007ba...@mega-nerd.com

Bug#649359: Both hibernate and suspend stopped working

[Jonathan Nieder]

Hi Tomas,

Tomas Kazmar wrote:

> Version: 3.0.0-3
[...]
> Hibernate/suspend used to work on my Lenovo Thinkpad x220 in the past with the
> same kernel. Last time when I updated (gnome2->gnome3 was part of it, but i
> doubt this is the cause), I rebooted the system and since then neither
> hibernate nor suspend work. I did not make any changes that I would suspect to
> cause them to stop working.

Thanks.

There has been an X220 suspend fix in v3.1 (namely v3.1-rc1~22^2~10^2~7^2,
2011-07-26).  Please test with a 3.1.y kernel from unstable.

If that doesn't work, your best bet is to follow the instructions from
[1], and if it turns out to be an i915 bug, let us know the bug number
so we can track it.

Sincerely,
Jonathan

[1] http://intellinuxgraphics.org/how_to_report_bug.html



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

Processed: Re: USB mouse stops work on battery power

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> found 648939 linux-2.6/2.6.37-2
Bug #648939 [linux-2.6] USB mouse stops work on battery power
Bug Marked as found in versions linux-2.6/2.6.37-2.
> quit
Stopping processing here.

Please contact me if you need assistance.
-- 
648939: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648939
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.132178682425844.transcr...@bugs.debian.org

Bug#648939: USB mouse stops work on battery power

[Jonathan Nieder]

found 648939 linux-2.6/2.6.37-2
quit

Erik de Castro Lopo wrote:

> Both 2.6.37-2-amd64 and 2.6.38-2-amd64 have the same problem.

BTW, a more useful version number is that shown in parentheses by
"cat /proc/version" (also shown by "dpkg-query -W
linux-image-$(uname -r)"), since it changes more often than the
package name.

> Trying to find more kernels to test.

The list of available versions is at [1].  Thanks for your patience.

Sincerely,
Jonathan

[1] http://snapshot.debian.org/package/linux-2.6/



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

Bug#649359: linux-image-3.0.0-1-686-pae: Both hibernate and suspend stopped working

[Tomas Kazmar]

Package: linux-2.6

Version: 3.0.0-3
Severity: important

Dear Maintainer,

Hibernate/suspend used to work on my Lenovo Thinkpad x220 in the past with the
same kernel. Last time when I updated (gnome2->gnome3 was part of it, but i
doubt this is the cause), I rebooted the system and since then neither
hibernate nor suspend work. I did not make any changes that I would suspect to
cause them to stop working.

When I start hibernation/suspend (by clicking in GUI, pm-hibernate/pm-suspend,
or closing the lid), the laptop freezes going to sleep. Black screen with
cursor appears, sleep-LED starts blinking and I have to use the hardware power
off then. This is perfectly repeatable and happens on every sleep. I suspect
this could be a kernel panic(?).

I tried to regenerate the initrd image and to swapoff/swapon, and to check the
resume device ID, but with no success.

Thank you for any help.

Tomas

---

dmesg | grep 'PM:':
[0.00] PM: Registered nosave memory: 0009d000 -
0009e000
[0.00] PM: Registered nosave memory: 0009e000 -
000a
[0.00] PM: Registered nosave memory: 000a -
000e
[0.00] PM: Registered nosave memory: 000e -
0010
[0.477677] PM: Registering ACPI NVS region at dae9f000 (1048576 bytes)
[1.266207] PM: Hibernation image not present or could not be loaded.
[3.415927] PM: Starting manual resume from disk
[3.415930] PM: Hibernation image partition 8:6 present
[3.415931] PM: Looking for hibernation image.
[3.416077] PM: Image not found (code -22)
[3.416082] PM: Hibernation image not present or could not be loaded.
[3.418773] PM: Marking nosave pages: 0009d000 - 0010
[3.418777] PM: Basic memory bitmaps created
[3.433451] PM: Basic memory bitmaps freed

tail pm-suspend.log:
/usr/lib/pm-utils/sleep.d/95packagekit suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/98video-quirk-db-handler suspend
suspend:
Kernel modesetting video driver detected, not using quirks.

/usr/lib/pm-utils/sleep.d/98video-quirk-db-handler suspend suspend: success.
Running hook /usr/lib/pm-utils/sleep.d/99video suspend suspend:

/usr/lib/pm-utils/sleep.d/99video suspend suspend: success.
Sun Nov 20 11:15:44 CET 2011: performing suspend




-- Package-specific info:
** Version:
Linux version 3.0.0-1-686-pae (Debian 3.0.0-3) (b...@decadent.org.uk) (gcc 
version 4.5.3 (Debian 4.5.3-8) ) #1 SMP Sat Aug 27 16:41:03 UTC 2011

** Command line:
BOOT_IMAGE=/boot/vmlinuz-3.0.0-1-686-pae 
root=UUID=0eec03b4-9071-41b5-82a7-ee52330d921c ro quiet

** Not tainted

** Kernel log:
[6.505934] iwlagn :03:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[6.505943] iwlagn :03:00.0: setting latency timer to 64
[6.505970] iwlagn :03:00.0: Detected Intel(R) Centrino(R) Advanced-N 
6205 AGN, REV=0xB0
[6.514946] iwlagn :03:00.0: device EEPROM VER=0x715, CALIB=0x6
[6.514947] iwlagn :03:00.0: Device SKU: 0Xb
[6.514949] iwlagn :03:00.0: Valid Tx ant: 0X3, Valid Rx ant: 0X3
[6.515034] iwlagn :03:00.0: Tunable channels: 13 802.11bg, 24 802.11a 
channels
[6.515102] iwlagn :03:00.0: irq 42 for MSI/MSI-X
[6.553098] input: PC Speaker as /devices/platform/pcspkr/input/input6
[6.573323] i801_smbus :00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 
18
[6.614738] iwlagn :03:00.0: loaded firmware version 17.168.5.3 build 
42301
[6.615085] Registered led device: phy0-led
[6.651117] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[6.778963] [drm] Initialized drm 1.1.0 20060810
[6.879172] thinkpad_acpi: ThinkPad ACPI Extras v0.24
[6.879175] thinkpad_acpi: http://ibm-acpi.sf.net/
[6.879176] thinkpad_acpi: ThinkPad BIOS 8DET46WW (1.16 ), EC unknown
[6.879178] thinkpad_acpi: Lenovo ThinkPad X220, model 42872SG
[6.879647] thinkpad_acpi: detected a 8-level brightness capable ThinkPad
[6.879878] thinkpad_acpi: radio switch found; radios are enabled
[6.880010] thinkpad_acpi: possible tablet mode switch found; ThinkPad in 
laptop mode
[6.881768] thinkpad_acpi: rfkill switch tpacpi_bluetooth_sw: radio is 
unblocked
[6.882121] Registered led device: tpacpi::thinklight
[6.882161] Registered led device: tpacpi::power
[6.882186] Registered led device: tpacpi::standby
[6.882211] Registered led device: tpacpi::thinkvantage
[6.882306] thinkpad_acpi: Standard ACPI backlight interface available, not 
loading native one
[6.882366] thinkpad_acpi: Console audio control enabled, mode: monitor 
(read only)
[6.883376] input: ThinkPad Extra Buttons as 
/devices/platform/thinkpad_acpi/input/input7
[6.918281] i915 :00:02.0: power state changed by ACPI to D0
[6.918285] i915 :00:02.0: power state changed by ACPI to D0
[6.918290] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[6.918293] i915 :00:02.0: setting laten

Bug#649211: linux-image-486: /sys/devices/system/cpu/cpu0/crash_notes and no topology

[Marcus Osdoba]

Am 18.11.2011 23:55, schrieb Ben Hutchings:

On Fri, Nov 18, 2011 at 10:25:39PM +0100, Marcus Osdoba wrote:

Package: linux-image-486
Version: 3.1.1
Severity: important

Hi,
I have tested virt-manager on my Debian Squeeze on several installations.
Unfortunatly it does not work with 486 variant of the kernel [1]. When running
the 686 variant, the topology is found in /sys/devices/system/cpu/cpu0/ , but
not with 486 [2].


The 486 flavour only supports a single processor (since all SMP-
capable processors also support PAE) so the CPU topology is never
very interesting and the code to expose it in sysfs is not built.
Maybe it should be, for consistency.

Beyond Squeeze, one is forced to use 486 for systems without PAE 
(physically not available or not choosen to be activated for some 
reason). On these 32bit systems it is still possible to test and create 
qemu-vms and lxc-containers with virt-manager.


But the standard kernel is not able to do so. If possible, please enable 
memory_cgroup controller in Squeeze kernel (activated with kernel 
commandline like in 2.6.39+) -> so it is possible to use 686 from 
Squeeze then.


I think, one should know, that the 486 does not provide cputopology 
anymore (for consistency it should, yes). Since some of my boxes are not 
able/not want to use 686-PAE, I'm in a gap.


Marcus

P.S.: Booting version 3.1.1-486 on X40 is another bug for me ;-)



--
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/4ec8db3c.2010...@googlemail.com

Bug#648939: USB mouse stops work on battery power

[Erik de Castro Lopo]

Jonathan Nieder wrote:

> Intermediate versions are at .  Sorry,
> I should have mentioned so before.

Both 2.6.37-2-amd64 and 2.6.38-2-amd64 have the same problem.

Trying to find more kernels to test.

Erik
-- 
--
Erik de Castro Lopo
http://www.mega-nerd.com/



-- 
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/2020214745.1c245fd8cbea11e49d421...@mega-nerd.com

Re: Increasing minimum 'i386' processor

[David Goodenough]

On Saturday 19 Nov 2011, 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.
> 
> The 486-class processors that would no longer be supported are:
> 1. All x86 processors with names including '486'
> 2. AMD Am5x86
> 3. Cyrix/IBM/ST 5x86, 6x86 and MediaGX
> 4. UMC U5D and U5S
> 5. AMD/NSC Geode GX1, Geode SC1100, Elan SC4xx and SC5xx
I am still running a bunch of systems with SC1100 processors on them.
They are (and always have been) running off the shelf Debian kernels
and I would much rather keep it that way.

David
> Also possibly:
> 6. DM&P/SiS Vortex86 and Vortex86SX.  These supposedly have all
>586-class features except an FPU, and we could probably keep FPU
>emulation for them.
> 
> So far as I know, all processors in groups 1-5 have been out of
> production for several years.  Soekris still advertises boards using the
> Geode SC1100 and Elan SC520, but they seem quite uncompetitive with
> ARM-based systems and at least the SC1100-based products are being
> EOL'd.
> 
> Starting from version 2.6.24 or earlier (early 2008), Debian '486'
> kernel packages had a bug that caused them to crash on boot on 486-class
> processors, but this was not reported until early 2009 (#511703),
> suggesting that there were few users with such systems.  Debian 7.0
> 'wheezy' should be released in late 2012 or early 2013 and in the
> intervening 4 years the numbers of running systems with such a processor
> will have declined still further.
> 
> Ben.


-- 
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/20201010.21696.david.goodeno...@btconnect.com