Bug#607495: linux-image-2.6.32-5-amd64: kernel freeze

[Philip Ashmore]

Sorry - you need to invoke the script as
   sh reproduce-bug.sh v3c-repo



-- 
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/4d0d7c30.9020...@philipashmore.com

Bug#607495: linux-image-2.6.32-5-amd64: kernel freeze

[Philip Ashmore]

Attached file "reproduce-bug.sh".

Philip


reproduce-bug.sh
Description: Bourne shell script

Bug#607495: linux-image-2.6.32-5-amd64: kernel freeze

[Philip Ashmore]

Package: linux-2.6
Version: 2.6.32-29
Severity: normal

I put together a script called reproduce-bug.sh that does all the work for you.
I will attach it when I get the Debian bug number by email.

This script doesn't require sudo or other enhanced proviledges to run.
Basically you run the script in an empty directory writeable by you, and
it will git clone v3c, treedb, meta-treedb and v3c-repo into their own
folders and create a "sandbox" folder to install them to.
Then it will "make && make install" the packages into the sandbox.

The problem stage is running "make check" in v3c-repo, so there's a warning
that you may experience a machine freeze and asking you to -C to
abort, enter to proceed.

If you reproduced the problem then you will need to hold the power-off button
on your laptop down for five seconds or power off your machine (desktop).



-- Package-specific info:
** Version:
Linux version 2.6.32-5-amd64 (Debian 2.6.32-29) (b...@decadent.org.uk) (gcc 
version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Fri Dec 10 15:35:08 UTC 2010

** Command line:
BOOT_IMAGE=/vmlinuz-2.6.32-5-amd64 root=/dev/mapper/VgCompaq-squeeze ro quiet 
vga=0x317 
cryptopts=target=sda4_crypt,source=UUID=41d45178-c0d4-4d8f-a190-1c56b6328318,key=none,rootdev,lvm=VgCompaq-squeeze

** Not tainted

** Kernel log:
[   12.960808]  (523 KHz - 533 KHz @ 4 KHz), (600 mBi, 2300 mBm)
[   12.960811]  (5735000 KHz - 5835000 KHz @ 4 KHz), (600 mBi, 3000 mBm)
[   12.960824] cfg80211: Calling CRDA for country: US
[   12.988969] input: PC Speaker as /devices/platform/pcspkr/input/input2
[   12.989956] i801_smbus :00:1f.3: PCI INT D -> GSI 19 (level, low) -> IRQ 
19
[   13.160327] Linux video capture interface: v2.00
[   13.247102] udev[435]: renamed network interface eth0 to eth1
[   13.268163] ACPI: AC Adapter [AC] (on-line)
[   13.268414] input: Power Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input3
[   13.268477] ACPI: Power Button [PWRB]
[   13.268564] ACPI: WMI: Mapper loaded
[   13.268846] input: Lid Switch as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0D:00/input/input4
[   13.268964] ACPI: Lid Switch [LID0]
[   13.269034] input: Sleep Button as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0E:00/input/input5
[   13.269080] ACPI: Sleep Button [SLPB]
[   13.269167] input: Power Button as 
/devices/LNXSYSTM:00/LNXPWRBN:00/input/input6
[   13.269201] ACPI: Power Button [PWRF]
[   13.632312] [drm] Initialized drm 1.1.0 20060810
[   13.634457] uvcvideo: Found UVC 1.00 device CNF7041 (04f2:b057)
[   13.638331] input: CNF7041 as 
/devices/pci:00/:00:1d.7/usb1/1-6/1-6:1.0/input/input7
[   13.638398] usbcore: registered new interface driver uvcvideo
[   13.638401] USB Video Class driver (v0.1.0)
[   13.672704] input: PS/2 Mouse as /devices/platform/i8042/serio1/input/input8
[   13.709297] input: AlpsPS/2 ALPS GlidePoint as 
/devices/platform/i8042/serio1/input/input9
[   13.946884] i915 :00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   13.946891] i915 :00:02.0: setting latency timer to 64
[   13.951194] ath5k :01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[   13.951213] ath5k :01:00.0: setting latency timer to 64
[   13.951318] ath5k :01:00.0: registered as 'phy0'
[   13.961964]   alloc irq_desc for 26 on node -1
[   13.961968]   alloc kstat_irqs on node -1
[   13.961983] i915 :00:02.0: irq 26 for MSI/MSI-X
[   13.961991] [drm] set up 7M of stolen space
[   14.102093] [drm] initialized overlay support
[   14.451511] ath: EEPROM regdomain: 0x67
[   14.451514] ath: EEPROM indicates we should expect a direct regpair map
[   14.451518] ath: Country alpha2 being used: 00
[   14.451519] ath: Regpair used: 0x67
[   14.721603] phy0: Selected rate control algorithm 'minstrel'
[   14.722351] Registered led device: ath5k-phy0::rx
[   14.722369] Registered led device: ath5k-phy0::tx
[   14.722372] ath5k phy0: Atheros AR2425 chip found (MAC: 0xe2, PHY: 0x70)
[   14.830551] Console: switching to colour frame buffer device 180x56
[   14.834503] fb0: inteldrmfb frame buffer device
[   14.834505] registered panic notifier
[   14.834575] [Firmware Bug]: ACPI: ACPI brightness control misses _BQC 
function
[   14.835879] [Firmware Bug]: ACPI: ACPI brightness control misses _BQC 
function
[   14.846138] acpi device:15: registered as cooling_device2
[   14.846408] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input10
[   14.846475] ACPI: Video Device [OVGA] (multi-head: yes  rom: no  post: no)
[   14.846502] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0
[   14.846555]   alloc irq_desc for 22 on node -1
[   14.846557]   alloc kstat_irqs on node -1
[   14.846566] HDA Intel :00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 
22
[   14.846639] HDA Intel :00:1b.0: setting latency timer to 64
[   14.932842] input: HDA Intel Mic as 
/devices/pci:00/:00:1b.0/sound/card0/input11
[   14.932960] input: HDA Intel Mic as 
/devices/pci:00/:0

Bug#607487: linux-image-2.6.32-5-amd64: Kernel will freeze sometimes during booting

[Ben Hutchings]

On Sun, 2010-12-19 at 02:15 +0200, Prekates Alexandros wrote:
> Package: linux-2.6
> Version: 2.6.32-29
> Severity: normal
> Tags: squeeze
> 
> I installed two days ago debian squeeze beta from dvd. Installation went ok,
> but some times during boot up system will freeze with messages like:
> BUG: soft lockup - CPU#0 stuck for 61s! [khubd.s] or
> BUG: Unable to handle kernel paging request at .
> 
> The last time i managed to take a screenshot.
> 
> I give two links of images from the screenshot.
> http://www.freeimagehosting.net/image.php?fc2d7b1d7a.jpg> src=http://www.freeimagehosting.net/uploads/th.fc2d7b1d7a.jpg alt="Free Image
> Hosting by FreeImageHosting.net">
> 
> http://www.freeimagehosting.net/image.php?a5ab47edf7.jpg> src=http://www.freeimagehosting.net/uploads/th.a5ab47edf7.jpg alt="Free Image
> Hosting by FreeImageHosting.net">

Please send images as attachments, not links which are likely to break.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Bug#607416: Device table incorrect for drivers/s390/block/dasd_eckd.c: 3880/3390 should be 3880/3380

[Stephen Powell]

Hello upstream,

This is a bug report for drivers/s390/block/dasd_eckd.c in the
Linux kernel source code.  The device table indicates that a
combination of a 3880 storage control unit and a 3390 DASD device
type is valid.  This is incorrect.  A 3880 storage control unit
cannot support a 3390 device type.  However, it can support a
3380 device type, and that is not present in the table.
See Debian bug report number 607416 for details.

   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607416

I have made the one-line change indicated in the bug report and
created a custom kernel, which runs with no apparent ill effects.
However, you might want to look things over to see if anything
needs to be changed in the code logic as well.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-



-- 
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/1841269051.1165093.1292720340853.javamail.r...@md01.wow.synacor.com

Bug#607487: linux-image-2.6.32-5-amd64: Kernel will freeze sometimes during booting

[Prekates Alexandros]

Package: linux-2.6
Version: 2.6.32-29
Severity: normal
Tags: squeeze

I installed two days ago debian squeeze beta from dvd. Installation went ok,
but some times during boot up system will freeze with messages like:
BUG: soft lockup - CPU#0 stuck for 61s! [khubd.s] or
BUG: Unable to handle kernel paging request at .

The last time i managed to take a screenshot.

I give two links of images from the screenshot.
http://www.freeimagehosting.net/image.php?fc2d7b1d7a.jpg>http://www.freeimagehosting.net/uploads/th.fc2d7b1d7a.jpg alt="Free Image
Hosting by FreeImageHosting.net">

http://www.freeimagehosting.net/image.php?a5ab47edf7.jpg>http://www.freeimagehosting.net/uploads/th.a5ab47edf7.jpg alt="Free Image
Hosting by FreeImageHosting.net">




-- Package-specific info:
** Version:
Linux version 2.6.32-5-amd64 (Debian 2.6.32-29) (b...@decadent.org.uk) (gcc 
version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Fri Dec 10 15:35:08 UTC 2010

** Command line:
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 
root=UUID=e2205fab-0b56-41a6-8f2f-5bccb43ea074 ro quiet

** Not tainted

** Kernel log:
[8.887476] hub 4-2:1.0: 4 ports detected
[9.044019] hda-intel: azx_get_response timeout, switching to polling mode: 
last cmd=0x300f
[9.132030] usb 5-2: new full speed USB device using uhci_hcd and address 2
[9.317692] usb 5-2: New USB device found, idVendor=046d, idProduct=c318
[9.317695] usb 5-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[9.317697] usb 5-2: Product: Logitech Illuminated Keyboard
[9.317698] usb 5-2: Manufacturer: Logitech
[9.31] usb 5-2: configuration #1 chosen from 1 choice
[9.325900] input: Logitech Logitech Illuminated Keyboard as 
/devices/pci:00/:00:1a.2/usb5/5-2/5-2:1.0/input/input5
[9.325961] generic-usb 0003:046D:C318.0002: input,hidraw1: USB HID v1.11 
Keyboard [Logitech Logitech Illuminated Keyboard] on usb-:00:1a.2-2/input0
[9.328759] input: Logitech Logitech Illuminated Keyboard as 
/devices/pci:00/:00:1a.2/usb5/5-2/5-2:1.1/input/input6
[9.328827] generic-usb 0003:046D:C318.0003: input,hiddev1,hidraw2: USB HID 
v1.11 Device [Logitech Logitech Illuminated Keyboard] on 
usb-:00:1a.2-2/input1
[9.568029] usb 6-2: new low speed USB device using uhci_hcd and address 2
[9.819855] usb 6-2: New USB device found, idVendor=1241, idProduct=1603
[9.819857] usb 6-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[9.819859] usb 6-2: Product: USB Keyboard
[9.819861] usb 6-2: Manufacturer:  
[9.819940] usb 6-2: configuration #1 chosen from 1 choice
[9.870057] input:   USB Keyboard as 
/devices/pci:00/:00:1d.0/usb6/6-2/6-2:1.0/input/input7
[9.870137] generic-usb 0003:1241:1603.0004: input,hidraw3: USB HID v1.10 
Keyboard [  USB Keyboard] on usb-:00:1d.0-2/input0
[9.959918] input:   USB Keyboard as 
/devices/pci:00/:00:1d.0/usb6/6-2/6-2:1.1/input/input8
[9.959968] generic-usb 0003:1241:1603.0005: input,hidraw4: USB HID v1.10 
Device [  USB Keyboard] on usb-:00:1d.0-2/input1
[   10.048023] hda-intel: Codec #3 probe error; disabling it...
[   10.121622] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1b.0/input/input9
[   10.138629] input: HDA Intel Mic at Ext Front Jack as 
/devices/pci:00/:00:1b.0/sound/card0/input10
[   10.138686] input: HDA Intel Mic at Ext Rear Jack as 
/devices/pci:00/:00:1b.0/sound/card0/input11
[   10.138739] input: HDA Intel Speaker at Ext Rear Jack as 
/devices/pci:00/:00:1b.0/sound/card0/input12
[   10.138796] input: HDA Intel Speaker at Ext Rear Jack as 
/devices/pci:00/:00:1b.0/sound/card0/input13
[   10.138854] input: HDA Intel Speaker at Ext Rear Jack as 
/devices/pci:00/:00:1b.0/sound/card0/input14
[   10.138910] input: HDA Intel Speaker at Ext Rear Jack as 
/devices/pci:00/:00:1b.0/sound/card0/input15
[   10.138965] input: HDA Intel HP Out at Ext Front Jack as 
/devices/pci:00/:00:1b.0/sound/card0/input16
[   10.776389] Adding 8193108k swap on /dev/sda5.  Priority:-1 extents:1 
across:8193108k 
[   10.789510] Adding 7815612k swap on /dev/sdb2.  Priority:-2 extents:1 
across:7815612k 
[   11.128906] loop: module loaded
[   13.244179] usb-storage: device scan complete
[   13.244653] scsi 4:0:0:0: Direct-Access HP   Photosmart D5400 1.00 
PQ: 0 ANSI: 5
[   13.245146] sd 4:0:0:0: Attached scsi generic sg4 type 0
[   13.247267] sd 4:0:0:0: [sdd] Attached SCSI removable disk
[   16.120949] EXT4-fs (sda14): mounted filesystem with ordered data mode
[   17.068177] fuse init (API version 7.13)
[   17.895619] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   18.925281] wlan0: direct probe to AP 00:1d:19:88:cb:0a (try 1)
[   19.124038] wlan0: direct probe to AP 00:1d:19:88:cb:0a (try 2)
[   19.125296] wlan0: direct probe responded
[   19.125301] wlan0: authenticate with AP 00:1d:19:88:cb:0a (try 1)
[   19.126428] wlan0: authenticated
[   19.126446] wlan0: associ

Bug#607484: upgrade-reports: unusable on intel i810

[relative]

> That output just says the gpu is hung, which can have an infinite number
> of different causes.

I realize that, but there is no more information in it. it is the only message 
since booting.

> 
> > lspci:
> > 00:02.0 VGA compatible controller: Intel Corporation
> 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device (rev 01)
> > 
> > Xorg.log:
> > 
> That's still not the full X log, and you didn't provide the full dmesg.

?
except for some redacting that`s the full log.


I understand that this is not a lot of information to reproduce the bug, but 
please consider that this appears to be a KNOWN bug, so all debian has to do is 
to ship a version that doesn`t have this bug and/or disable kernel mode 
switching.
-- 

DEREFER
http://www.gmx.net/?status=hinweis";>


http://www.gmx.net/?status=hinweis";>Einen Moment bitte, die angeforderte Seite 
wird geladen...



GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt auch mit 
gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl



-- 
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/20101218234556.46...@gmx.net

Processed: reassign 607484 to linux-2.6, retitle 607484 to i915: [845G] gpu hangs

[Debian Bug Tracking System]

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

> reassign 607484 linux-2.6 2.6.32-29
Bug #607484 [upgrade-reports] upgrade-reports: unusable on intel i810
Bug reassigned from package 'upgrade-reports' to 'linux-2.6'.
Bug #607484 [linux-2.6] upgrade-reports: unusable on intel i810
There is no source info for the package 'linux-2.6' at version '2.6.32-29' with 
architecture ''
Unable to make a source version for version '2.6.32-29'
Bug Marked as found in versions 2.6.32-29.
> retitle 607484 i915: [845G] gpu hangs
Bug #607484 [linux-2.6] upgrade-reports: unusable on intel i810
Changed Bug title to 'i915: [845G] gpu hangs' from 'upgrade-reports: unusable 
on intel i810'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
607484: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607484
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.129271381214397.transcr...@bugs.debian.org

Bug#607368: marked as done (linux-2.6: silent ABI change in 2.6.32.26 breaks external modules (smp_ops changes))

[Debian Bug Tracking System]

Your message dated Sat, 18 Dec 2010 20:35:25 +
with message-id <20101218203525.gg17...@vostochny.stro.at>
and subject line Re: Bug#607368: Kernel ABI management
has caused the Debian Bug report #607368,
regarding linux-2.6: silent ABI change in 2.6.32.26 breaks external modules 
(smp_ops changes)
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.)


-- 
607368: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607368
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Source: linux-2.6
Version: 2.6.32-28
Severity: serious

Hi,

smp_ops was changed in a rather incompatible way in 2.6.32.26, breaking 
the kernel ABI:

diff --git a/arch/x86/include/asm/smp.h b/arch/x86/include/asm/smp.h
index 4cfc908..4c2f63c 100644
--- a/arch/x86/include/asm/smp.h
+++ b/arch/x86/include/asm/smp.h
@@ -50,7 +50,7 @@ struct smp_ops {
void (*smp_prepare_cpus)(unsigned max_cpus);
void (*smp_cpus_done)(unsigned max_cpus);
 
-   void (*smp_send_stop)(void);
+   void (*stop_other_cpus)(int wait);
void (*smp_send_reschedule)(int cpu);
 
int (*cpu_up)(unsigned cpu);

This change was, in turn, willfully ignored (SVN rev 16598) and the kernel 
ABI remained at 5.

This breaks external modules like VMware (vmmon) that use the smp_ops 
symbol.

Please revert or bump the kernel ABI to 6 to reflect this ABI change.

Thanks,

JB.

-- 
Consultant INTM - Debian Developer - TMI Calibre
EDF - DSP - CSP IT - ITS Rhône Alpes - C4S - CCNPS
04 69 65 68 56




Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à 
l'intention exclusive des destinataires et les informations qui y figurent sont 
strictement confidentielles. Toute utilisation de ce Message non conforme à sa 
destination, toute diffusion ou toute publication totale ou partielle, est 
interdite sauf autorisation expresse.

Si vous n'êtes pas le destinataire de ce Message, il vous est interdit de le 
copier, de le faire suivre, de le divulguer ou d'en utiliser tout ou partie. Si 
vous avez reçu ce Message par erreur, merci de le supprimer de votre système, 
ainsi que toutes ses copies, et de n'en garder aucune trace sur quelque support 
que ce soit. Nous vous remercions également d'en avertir immédiatement 
l'expéditeur par retour du message.

Il est impossible de garantir que les communications par messagerie 
électronique arrivent en temps utile, sont sécurisées ou dénuées de toute 
erreur ou virus.


This message and any attachments (the 'Message') are intended solely for the 
addressees. The information contained in this Message is confidential. Any use 
of information contained in this Message not in accord with its purpose, any 
dissemination or disclosure, either whole or partial, is prohibited except 
formal approval.

If you are not the addressee, you may not copy, forward, disclose or use any 
part of it. If you have received this message in error, please delete it and 
all copies from your system and notify the sender immediately by return message.

E-mail communication cannot be guaranteed to be timely secure, error or 
virus-free.



--- End Message ---
--- Begin Message ---
On Sat, Dec 18, 2010 at 06:23:20PM +0100, Julien BLACHE wrote:
> Ben Hutchings  wrote:
> 
> >> This is reinforced by reading the packaging scripts and realizing they
> >> check the whole ABI, prior to -28.
> >
> > This is not correct.  We have ignored many changes since 2.6.32-12 when
> > the ABI number was bumped to 5.  In 2.6.32-27 the symbol version files
> > were refreshed and the ignore list was reset.
> 
> This is even more troubling.

no it is reality, please wakeup.

We never supported oot binary crap, nor do we intend to do.
closing, as you already got all the explanations.

-- 
maks

--- End Message ---

Bug#607368: Kernel ABI management

[Ben Hutchings]

On Sat, 2010-12-18 at 18:23 +0100, Julien BLACHE wrote:
> Ben Hutchings  wrote:
> 
> Hi Ben,
> 
> >> This is reinforced by reading the packaging scripts and realizing they
> >> check the whole ABI, prior to -28.
> >
> > This is not correct.  We have ignored many changes since 2.6.32-12 when
> > the ABI number was bumped to 5.  In 2.6.32-27 the symbol version files
> > were refreshed and the ignore list was reset.
> 
> This is even more troubling.
> 
> > The upstream policy is that symbol exports may be removed when there are
> > no in-tree users.  So that export could even be made conditional on
> > CONFIG_KVM_MODULE (or whatever it's called).
> 
> Upstream policy doesn't break your setup from one kernel package
> revision to the other.

Actually it does.  The ABI change was part of a stable update.

> > Maybe I should find a way to limit that export so OOT users won't make
> > this mistake.
> 
> Good luck with that, it's been tried already with EXPORT_SYMBOL_GPL()
> and people still do work around that.

That is probably copyright infringement.

> >> See the top of this mail where you state that no list of symbols covered
> >> by the ABI was ever published for Debian kernels. It isn't unreasonable
> >> under these circumstances to assume that all symbols are covered.
> >
> > It is extremely stupid.
> 
> We obviously disagree.
> 
> >> VMware, nVidia, various drivers and infrastructure for communications
> >> hardware (been there, done that), ...
> >
> > VMware - use KVM.
> 
> Not possible. We require 3D pass-through that KVM doesn't offer. Windows
> virtio drivers failed us on Vista/Seven (can't remember, not my
> area), plain old IDE emulation is too slow to be usable. Also, issues
> with moving a VM from one host to another from a Windows licensing
> standpoint (still researching this one, though).

It sounds like you should really be using ESX/vSphere on the host,
rather than VMware Server on Debian.  I mean, VMware Server is basically
demo-ware.

> > nvidia - use nouveau, report a bug if it doesn't work.
> 
> Doesn't work with our cards, not by a long shot. Probably won't work for
> another decade or so, so not an option. We do need working and fast 3D.
> 
> Switching to AMD - oh yeah, we tried that. I have a drawer full of test
> cards. Not a single one has working 3D with free drivers, and here again
> it won't happen for another year or two *best case*. Not an option.
> 
> Once again: not that we wouldn't like to use free drivers, but we just
> can't. And I'm the one backporting and testing the nVidia drivers, so
> believe me when I tell you I'd be using Nouveau if it was an option.

Where are your bug reports on nouveau?

> We are limited by our user's requirements on the one hand and by what
> hardware vendors can sell us on the other hand - and they can't sell us
> yesteryear's tech forever, especially on high-end mobile workstations.
> 
> Anybody doing this type of large-scale deployment faces the same issues.
> 
> > random drivers - send them to the maintainer of crap (Greg K-H, for the
> > staging tree).
> 
> :-) That being said, not every out of tree driver comes with
> source. Although pure crap has made it to staging in the past, I'm
> pretty sure multi-megabyte binary blobs don't stand a chance.

Binary-only drivers for Linux are generally copyright infringements.  If
we break them: good.  (I know nvidia provides a Linux-specific stub as
source and it might be an exception to this.)

> I'm pretty disappointed by the way you're handling this; it feels like
> you have little care for what your users actually need.

We do, just not all of what *you* (one of our users) want.

Ben.

> I find it a bit
> sad, given all the very good work you've been doing with the kernel
> otherwise.
> 
> As I wrote already, it's not like VMware is some obscure piece of
> software that nobody knows about.



-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Bug#607471: linux-image-2.6.32-5-686: resume from ram won't work on T42 with radeon driver

[kloana]

Package: linux-2.6
Version: 2.6.32-29
Severity: important

When i resume my laptop from ram i always get a black screen. Resume won't
work. The Laptop is a Thinkpad T42 with Radeon Mobility 7500.

As a workaround i have found following solution:
change in /etc/modprobe.d/radeon-kms.conf following line from "options radeon
modeset=1" to "options radeon modeset=0".

After this workaround resuming the laptop is working without any problems!

regards
Herbert



-- Package-specific info:
** Version:
Linux version 2.6.32-5-686 (Debian 2.6.32-29) (b...@decadent.org.uk) (gcc 
version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Fri Dec 10 16:12:40 UTC 2010

** Command line:
BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 
root=UUID=25687e1e-be6e-40b5-b24f-242b9dd1e795 ro quiet

** Not tainted

** Kernel log:
[  261.667356] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  263.667092] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  265.667170] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  267.667067] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  269.667230] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  271.667123] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  273.667095] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  275.667240] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  277.666995] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  279.666988] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  281.666946] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  283.666951] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  285.667016] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  287.666961] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  289.667078] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  291.667106] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  293.667114] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  294.973996] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  295.666918] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  297.666962] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  299.666979] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  301.667079] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  303.666932] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  305.506071] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  305.666908] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  307.666861] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  309.666825] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  311.666716] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  313.666878] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  315.666790] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  317.24] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  319.666775] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  321.669732] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  323.52] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  325.20] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  327.666863] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  329.666587] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  331.59] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  333.23] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  335.59] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  341.666745] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  343.39] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  345.07] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  347.666854] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  349.96] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  351.666490] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  353.40] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  353.893656] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  354.993779] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  355.666392] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  357.666588] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  359.666448] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  361.666406] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  363.55] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  365.98] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  367.666374] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  369.666564] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  371.666494] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  373.666368] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  375.666465] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  377.666357] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  379.666366] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  381.666475] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  383.666375] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  385.669048] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  387.16] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  389.666325] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  391.666432] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  393.666279] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  395.666356] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  397.666200] CCMP: decrypt failed: STA=0a:0f:b5:df:1e:a5
[  399.666225] CCMP: 

Bug#607368: Kernel ABI management

[Bastian Blank]

On Sat, Dec 18, 2010 at 06:23:20PM +0100, Julien BLACHE wrote:
> Ben Hutchings  wrote:
> > This is not correct.  We have ignored many changes since 2.6.32-12 when
> > the ABI number was bumped to 5.  In 2.6.32-27 the symbol version files
> > were refreshed and the ignore list was reset.
> This is even more troubling.

It is reality. We settled for a best-effort implementation and this
suites 99% of our users. If you have problem with that, go ask the CTTE.

> > The upstream policy is that symbol exports may be removed when there are
> > no in-tree users.  So that export could even be made conditional on
> > CONFIG_KVM_MODULE (or whatever it's called).
> Upstream policy doesn't break your setup from one kernel package
> revision to the other.

Yes, it does.

> > Maybe I should find a way to limit that export so OOT users won't make
> > this mistake.
> Good luck with that, it's been tried already with EXPORT_SYMBOL_GPL()
> and people still do work around that.

And? If they do, it is clearly visible.

Bastian

-- 
You!  What PLANET is this!
-- McCoy, "The City on the Edge of Forever", stardate 3134.0



-- 
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/20101218175010.ga27...@wavehammer.waldi.eu.org

Bug#607368: Kernel ABI management

[Julien BLACHE]

Ben Hutchings  wrote:

Hi Ben,

>> This is reinforced by reading the packaging scripts and realizing they
>> check the whole ABI, prior to -28.
>
> This is not correct.  We have ignored many changes since 2.6.32-12 when
> the ABI number was bumped to 5.  In 2.6.32-27 the symbol version files
> were refreshed and the ignore list was reset.

This is even more troubling.

> The upstream policy is that symbol exports may be removed when there are
> no in-tree users.  So that export could even be made conditional on
> CONFIG_KVM_MODULE (or whatever it's called).

Upstream policy doesn't break your setup from one kernel package
revision to the other.

> Maybe I should find a way to limit that export so OOT users won't make
> this mistake.

Good luck with that, it's been tried already with EXPORT_SYMBOL_GPL()
and people still do work around that.

>> See the top of this mail where you state that no list of symbols covered
>> by the ABI was ever published for Debian kernels. It isn't unreasonable
>> under these circumstances to assume that all symbols are covered.
>
> It is extremely stupid.

We obviously disagree.

>> VMware, nVidia, various drivers and infrastructure for communications
>> hardware (been there, done that), ...
>
> VMware - use KVM.

Not possible. We require 3D pass-through that KVM doesn't offer. Windows
virtio drivers failed us on Vista/Seven (can't remember, not my
area), plain old IDE emulation is too slow to be usable. Also, issues
with moving a VM from one host to another from a Windows licensing
standpoint (still researching this one, though).

It's not that using KVM wouldn't ease our (and our user's) life
considerably, it's that we *cannot* use it, and there are real reasons
why we cannot (and I'm not even speaking of getting that solution
approved internally, it's really a detail given the above).

As you can see on my blog, I'm the one responsible for packaging
VMware. My life would be better if we could just use KVM, believe
me. Packaging VMware 7 was a nightmare.

> nvidia - use nouveau, report a bug if it doesn't work.

Doesn't work with our cards, not by a long shot. Probably won't work for
another decade or so, so not an option. We do need working and fast 3D.

Switching to AMD - oh yeah, we tried that. I have a drawer full of test
cards. Not a single one has working 3D with free drivers, and here again
it won't happen for another year or two *best case*. Not an option.

Once again: not that we wouldn't like to use free drivers, but we just
can't. And I'm the one backporting and testing the nVidia drivers, so
believe me when I tell you I'd be using Nouveau if it was an option.

We are limited by our user's requirements on the one hand and by what
hardware vendors can sell us on the other hand - and they can't sell us
yesteryear's tech forever, especially on high-end mobile workstations.

Anybody doing this type of large-scale deployment faces the same issues.

> random drivers - send them to the maintainer of crap (Greg K-H, for the
> staging tree).

:-) That being said, not every out of tree driver comes with
source. Although pure crap has made it to staging in the past, I'm
pretty sure multi-megabyte binary blobs don't stand a chance.

I'm pretty disappointed by the way you're handling this; it feels like
you have little care for what your users actually need. I find it a bit
sad, given all the very good work you've been doing with the kernel
otherwise.

As I wrote already, it's not like VMware is some obscure piece of
software that nobody knows about.

JB.

-- 
 Julien BLACHE   |  Debian, because code matters more 
 Debian & GNU/Linux Developer|   
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 



-- 
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/87zks3dmgn@sonic.technologeek.org

Bug#607368: Kernel ABI management

[Ben Hutchings]

On Sat, 2010-12-18 at 16:20 +0100, Julien BLACHE wrote:
> Ben Hutchings  wrote:
> 
> Hi,
> 
> > Some distributions provide a list all exported symbols which can be
> > depended on not to change.  We haven't done that but we do consider
> 
> What you're saying here is very important: you haven't done that yet,
> which implies that all symbols are covered by the ABI.
> 
> This is reinforced by reading the packaging scripts and realizing they
> check the whole ABI, prior to -28.

This is not correct.  We have ignored many changes since 2.6.32-12 when
the ABI number was bumped to 5.  In 2.6.32-27 the symbol version files
were refreshed and the ignore list was reset.

> > where symbols are used before deciding a change can be ignored.
> 
> I can perfectly imagine that you weren't aware of VMware's reliance upon
> this symbol before, but you are now.
> 
> No need to tell you that quite a few of our users out there will use
> VMware on Squeeze and be impacted by this change.
>
> > (As an example, there are several sets of drivers for related hardware
> > in which one core module exports symbols to the specific driver modules.
> > Those exports should in no way be depended on by OOT modules.)
> 
> As smp_ops is exported by the core kernel and not by the common core of
> a self-contained set of drivers, I don't think this argument holds here.
> 
> Reviewing the kernel revision history, smp_ops was indeed exported to
> allow building KVM as a module. The commit message certainly doesn't
> claim that KVM should be the sole user of this exported symbol.

The upstream policy is that symbol exports may be removed when there are
no in-tree users.  So that export could even be made conditional on
CONFIG_KVM_MODULE (or whatever it's called).

> I fail to see a reason why VMware or anybody else should refrain from
> using smp_ops if they need it.

Because it's a low-level implementation detail.

Maybe I should find a way to limit that export so OOT users won't make
this mistake.

> >> We would not accept that behaviour from a shared library, I don't see
> >> any reason why we would accept it from the kernel.
> >
> > This is not true; for example, the interface between libc and NSS is not
> > stable.
> 
> And it's been widely recognized as a design flaw and a royal pain in the
> ass for, like, forever. Not exactly an example you want to follow.
> 
> > If someone claims to certify something about future Debian kernels
> > without talking to the kernel team, they are a fraud.
> 
> See the top of this mail where you state that no list of symbols covered
> by the ABI was ever published for Debian kernels. It isn't unreasonable
> under these circumstances to assume that all symbols are covered.

It is extremely stupid.

> >> Out of tree modules exist and you can't just ignore them; in some
> >> environments they are necessary to make things work and you won't have a
> >> way around that.
> >
> > Example?
> 
> VMware, nVidia, various drivers and infrastructure for communications
> hardware (been there, done that), ...

VMware - use KVM.
nvidia - use nouveau, report a bug if it doesn't work.
random drivers - send them to the maintainer of crap (Greg K-H, for the
staging tree).

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Processed: Re: Bug#607442: reportbug: kernel 2.6.32-5-amd64 #1 SMP Fri Dec 10 15:35:08 UTC 2010 x86_64 GNU/Linux crashed

[Debian Bug Tracking System]

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

> reassign 607442 linux-image-2.6.32-5-amd64
Bug #607442 [reportbug] reportbug: kernel 2.6.32-5-amd64 #1 SMP Fri Dec 10 
15:35:08 UTC 2010 x86_64 GNU/Linux crashed
Bug reassigned from package 'reportbug' to 'linux-image-2.6.32-5-amd64'.
Bug No longer marked as found in versions reportbug/4.12.6.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
607442: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607442
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.129268957529025.transcr...@bugs.debian.org

Processed: tagging 607368

[Debian Bug Tracking System]

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

> tags 607368 + wontfix
Bug #607368 [src:linux-2.6] linux-2.6: silent ABI change in 2.6.32.26 breaks 
external modules (smp_ops changes)
Added tag(s) wontfix.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
607368: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607368
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.129268920427441.transcr...@bugs.debian.org

Bug#607368: Kernel ABI management

[Julien BLACHE]

Ben Hutchings  wrote:

Hi,

> Some distributions provide a list all exported symbols which can be
> depended on not to change.  We haven't done that but we do consider

What you're saying here is very important: you haven't done that yet,
which implies that all symbols are covered by the ABI.

This is reinforced by reading the packaging scripts and realizing they
check the whole ABI, prior to -28.

> where symbols are used before deciding a change can be ignored.

I can perfectly imagine that you weren't aware of VMware's reliance upon
this symbol before, but you are now.

No need to tell you that quite a few of our users out there will use
VMware on Squeeze and be impacted by this change.

> (As an example, there are several sets of drivers for related hardware
> in which one core module exports symbols to the specific driver modules.
> Those exports should in no way be depended on by OOT modules.)

As smp_ops is exported by the core kernel and not by the common core of
a self-contained set of drivers, I don't think this argument holds here.

Reviewing the kernel revision history, smp_ops was indeed exported to
allow building KVM as a module. The commit message certainly doesn't
claim that KVM should be the sole user of this exported symbol.

I fail to see a reason why VMware or anybody else should refrain from
using smp_ops if they need it.

>> We would not accept that behaviour from a shared library, I don't see
>> any reason why we would accept it from the kernel.
>
> This is not true; for example, the interface between libc and NSS is not
> stable.

And it's been widely recognized as a design flaw and a royal pain in the
ass for, like, forever. Not exactly an example you want to follow.

> If someone claims to certify something about future Debian kernels
> without talking to the kernel team, they are a fraud.

See the top of this mail where you state that no list of symbols covered
by the ABI was ever published for Debian kernels. It isn't unreasonable
under these circumstances to assume that all symbols are covered.

>> Out of tree modules exist and you can't just ignore them; in some
>> environments they are necessary to make things work and you won't have a
>> way around that.
>
> Example?

VMware, nVidia, various drivers and infrastructure for communications
hardware (been there, done that), ...

JB.

-- 
 Julien BLACHE   |  Debian, because code matters more 
 Debian & GNU/Linux Developer|   
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 



-- 
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/877hf7f6q2@sonic.technologeek.org

Bug#607368: Kernel ABI management

[Ben Hutchings]

On Sat, 2010-12-18 at 09:26 +0100, Julien BLACHE wrote:
> reopen 607368
> submitter 607368 !
> thanks
> 
> Hi,
> 
> I am sorry that I have to reopen this bug, but first this is about more
> than just smp_ops and second the outcome isn't satisfactory.
> 
> Whether a symbol is exported for a specific purpose or for general
> usage, whether you like it or not, every symbol that is exported is part
> of the ABI. If it changes, the ABI changes and it changes for everybody,
> regardless of whether they're supposed to be using that symbol or not.

No distribution promises that all exported symbols will be unchanged.

Some distributions provide a list all exported symbols which can be
depended on not to change.  We haven't done that but we do consider
where symbols are used before deciding a change can be ignored.

(As an example, there are several sets of drivers for related hardware
in which one core module exports symbols to the specific driver modules.
Those exports should in no way be depended on by OOT modules.)

> We would not accept that behaviour from a shared library, I don't see
> any reason why we would accept it from the kernel.

This is not true; for example, the interface between libc and NSS is not
stable.

> As it stands, the kernel ABI number has just been rendered useless; I
> can no longer trust it nor rely on it. Every kernel revision will have
> to be tested to make sure all modules are still compatible with the new
> ABI, given the ABI will change silently without bumping the ABI number.
> 
> Unsuspecting users will have their setup break upon reboot after
> updating their kernel packages without any obvious clue as to what
> caused the breakage.
> 
> This is a big deal as it puts a big question mark where the kernel ABI
> number used to be. This is a problem for users, admins, ISV, vendors
> higher up the chain, everybody. It's no longer possible to offer
> certified modules for Debian kernels given the kernel ABI number cannot
> be relied upon anymore.

If someone claims to certify something about future Debian kernels
without talking to the kernel team, they are a fraud.

> Out of tree modules exist and you can't just ignore them; in some
> environments they are necessary to make things work and you won't have a
> way around that.

Example?

> So I am asking you to reconsider your position and go back to strictly
> maintaining the kernel ABI number. This situation is a big step backward
> for the Debian kernel packages and I hope it'll be fixed soon.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.


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

Bug#607439: linux-image-2.6.32-5-686: sony_laptop doesn't handle some keys on vaio tx3

[John Hughes]

Package: linux-2.6
Version: 2.6.32-29
Severity: normal


On my aging sony vaio tx3 sony_laptop doesn't tell anyone about the EJECT key
and gets the VOLUME UP/VOLUME DOWN buttons wrong.

For the EJECT key the sony_laptop debugging info shows:

sony-laptop: event ([32] [21]) at port 0x1080(+0x12)

(acpid debug shows nothing)

For the volume up:

sony-laptop: event ([5c] [31]) at port 0x1080(+0x12)
sony-laptop: sony_pic_call1(0xa0): 0x5c0a
sony-laptop: event ([02] [05]) at port 0x1080(+0x12)
sony-laptop: event ([5c] [31]) at port 0x1080(+0x12)
sony-laptop: sony_pic_call1(0xa0): 0x5c0a
sony-laptop: event ([00] [05]) at port 0x1080(+0x12)

(acpid debug shows nothing)

for the volume down

sony-laptop: event ([5c] [31]) at port 0x1080(+0x12)
sony-laptop: sony_pic_call1(0xa0): 0x5c0a
sony-laptop: event ([01] [05]) at port 0x1080(+0x12)
sony-laptop: event ([5c] [31]) at port 0x1080(+0x12)
sony-laptop: sony_pic_call1(0xa0): 0x5c0a
sony-laptop: event ([00] [05]) at port 0x1080(+0x12)

acpid thinks that volume down is button/prog1, the same as AV MODE

the sony_laptop debug for AV MODE is very slightly different from volume down:

sony-laptop: event ([5c] [31]) at port 0x1080(+0x12)
sony-laptop: sony_pic_call1(0xa0): 0x5c0a
sony-laptop: event ([20] [05]) at port 0x1080(+0x12)
sony-laptop: event ([5c] [31]) at port 0x1080(+0x12)
sony-laptop: sony_pic_call1(0xa0): 0x5c0a
sony-laptop: event ([00] [05]) at port 0x1080(+0x12)

(Note volume down is event 01 05, AV MODE is 20 05).

The lack of the EJECT button is annoying as the hardware eject on the DVD
drive is tiny and difficult to find.

-- Package-specific info:
** Version:
Linux version 2.6.32-5-686 (Debian 2.6.32-29) (b...@decadent.org.uk) (gcc 
version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Fri Dec 10 16:12:40 UTC 2010

** Command line:
BOOT_IMAGE=/vmlinuz-2.6.32-5-686 root=/dev/mapper/carbon_vg-root ro quiet

** Not tainted

** Kernel log:
[   13.427757] Registered led device: iwl-phy0::RX
[   13.428477] Registered led device: iwl-phy0::TX
[   13.430735] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[   13.465297] ADDRCONF(NETDEV_UP): eth0: link is not ready
[   13.468157] e100: eth0 NIC Link is Up 100 Mbps Full Duplex
[   13.469034] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   13.497146] input: ACPI Virtual Keyboard Device as 
/devices/virtual/input/input11
[   13.955003] Bluetooth: L2CAP ver 2.14
[   13.955008] Bluetooth: L2CAP socket layer initialized
[   13.993458] Bluetooth: RFCOMM TTY layer initialized
[   13.993465] Bluetooth: RFCOMM socket layer initialized
[   13.993468] Bluetooth: RFCOMM ver 1.11
[   14.004585] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   14.004589] Bluetooth: BNEP filters: protocol multicast
[   14.040762] Bridge firewalling registered
[   14.083159] Bluetooth: SCO (Voice Link) ver 0.6
[   14.083164] Bluetooth: SCO socket layer initialized
[   14.225973] lp: driver loaded but no devices found
[   14.242695] ppdev: user-space parallel port driver
[   23.900029] eth0: no IPv6 routers present
[   36.212113] wlan0: direct probe to AP 32:64:1a:ec:f4:c4 (try 1)
[   36.412040] wlan0: direct probe to AP 32:64:1a:ec:f4:c4 (try 2)
[   36.612049] wlan0: direct probe to AP 32:64:1a:ec:f4:c4 (try 3)
[   36.615371] wlan0: direct probe responded
[   36.615376] wlan0: authenticate with AP 32:64:1a:ec:f4:c4 (try 1)
[   36.620598] wlan0: authenticated
[   36.620628] wlan0: associate with AP 32:64:1a:ec:f4:c4 (try 1)
[   36.623591] wlan0: RX AssocResp from 32:64:1a:ec:f4:c4 (capab=0x411 status=0 
aid=1)
[   36.623597] wlan0: associated
[   36.626759] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[   45.142701] wlan0: deauthenticated from 32:64:1a:ec:f4:c4 (Reason: 1)
[   46.684029] wlan0: no IPv6 routers present
[   47.928455] wlan0: direct probe to AP 32:64:1a:ec:f4:c4 (try 1)
[   47.931436] wlan0: direct probe responded
[   47.931443] wlan0: authenticate with AP 32:64:1a:ec:f4:c4 (try 1)
[   47.933787] wlan0: authenticated
[   47.933815] wlan0: associate with AP 32:64:1a:ec:f4:c4 (try 1)
[   47.937006] wlan0: RX AssocResp from 32:64:1a:ec:f4:c4 (capab=0x411 status=0 
aid=1)
[   47.937011] wlan0: associated
[   50.340992] wlan0: deauthenticated from 32:64:1a:ec:f4:c4 (Reason: 1)
[   53.064579] wlan0: direct probe to AP 32:64:1a:ec:f4:c4 (try 1)
[   53.068763] wlan0: direct probe responded
[   53.068769] wlan0: authenticate with AP 32:64:1a:ec:f4:c4 (try 1)
[   53.073474] wlan0: authenticated
[   53.073497] wlan0: associate with AP 32:64:1a:ec:f4:c4 (try 1)
[   53.078214] wlan0: RX AssocResp from 32:64:1a:ec:f4:c4 (capab=0x411 status=0 
aid=1)
[   53.078220] wlan0: associated
[   77.822287] sony-laptop: Sony Programmable IO Control Driver v0.6.
[   77.822304] sony-laptop: detected Type3 model
[   77.822307] sony-laptop: Evaluating _STA
[   77.822628] sony-laptop: Device disabled
[   77.822631] sony-laptop: Evaluating _PRS
[   77.822649] sony-laptop: IO1 at 0x1080 (0x20)
[   77.822653] sony-laptop: IO1 at 0x10a0 (0x20)
[   77.822656] sony-laptop:

Bug#591031: Bug still in 2.6.37-rc5-686

[John Hughes]

j...@carbon:~$ uname -a
Linux carbon 2.6.37-rc5-686 #1 SMP Sat Dec 11 20:11:38 UTC 2010 i686
GNU/Linux

dpkg -l | grep linux-image
ii  linux-image-2.6.37-rc5-686   2.6.37~rc5-1~experimental.3
Linux 2.6.37-rc5 for modern PCs





-- 
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/1292675710.5905.1.ca...@carbon.atlantech.com

Bug#606237: linux-kernel: poweroff-button fails on 2.6.32-5-openvz-686

[Ola Lundqvist]

Hi Richard

On Fri, Dec 17, 2010 at 11:26:41PM +0100, Richard Landsman - Rimote Media wrote:
>Hello Ola,
>Both commands work like expected. Nothing special. Although the
>vzeventd is new for me.

vzeventd is new in latest kernel and latest vzctl. It is a new (improved) way
for a VE to restart itself.

>Stopping OpenVZ: ..done
>Starting OpenVZ: ..done
>Checking vzevent kernel module .done
>Starting vzeventd: Started

Ok. And what was the kernel modules after that?
You should have this module loaded "vzevent".

You should also have the value 1 in /sys/module/vzevent/parameters/reboot_event.

But actually I do not think the power button should use vzevent but I just
want to check that things are working as expected anyway.

>Just to know sure, the powerbutton normally should work on almost any
>kernel? Is that correct?

Yes.

// Ola

>Best regards,
>Richard
>Op 17-12-2010 16:21, Ola Lundqvist schreef:
> 
>  /etc/init.d/vzeventd start

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comAnnebergsslingan 37\
|  o...@debian.org   654 65 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---



-- 
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/20101218105249.ga14...@inguza.net

Bug#607428: linux-image-2.6.32-5-686: sound problem

[Gérard Robin]

Package: linux-2.6
Version: 2.6.32-29
Severity: minor

I upgraded from lenny (xfce4) to squeeze on my laptop (acer aspire 5102 wlmi) 
I installed linux-image-2.6.32-5-686.
All works fine except the sound :
"alsamixer" doesn't give the option CD and "cdcd" works but no sound.
(however sound-juicer works fine)
lspci:
00:14.2 Audio device: ATI Technologies Inc IXP SB4x0 High Definition Audio 
Controller (rev 01)

When I boot on the kernel 2.6.30 instead of the kernel 2.6.32-5-686, I
get the option CD with "alsamixer" and "cdcd" works fine (with sound)

And on the other hand I did the same upgrade (lenny -> squeeze with
kernel 2.6.32-5-686) on a desktop and I didn't encounter this problem.  

I would like the sound on my laptop to work fine with the kernel  2.6.32-5-686.
How can I do that ?

Thanks in advance.

-- Package-specific info:
** Version:
Linux version 2.6.32-5-686 (Debian 2.6.32-29) (b...@decadent.org.uk) (gcc 
version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Fri Dec 10 16:12:40 UTC 2010

** Command line:
root=UUID=1505c8bd-c890-4c4c-93e0-3fe16b2e6df0 ro quiet

** Not tainted

** Kernel log:
[9.735593] [drm] radeon kernel modesetting enabled.
[9.735691] radeon :01:05.0: power state changed by ACPI to D0
[9.735700] radeon :01:05.0: power state changed by ACPI to D0
[9.735717] radeon :01:05.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[9.737899] [drm] radeon: Initializing kernel modesetting.
[9.738021] [drm] register mmio base: 0xC010
[9.738024] [drm] register mmio size: 65536
[9.738399] [drm] GPU reset succeed (RBBM_STATUS=0x0140)
[9.738424] [drm:rs400_gart_adjust_size] *ERROR* Forcing to 32M GART size 
(because of ASIC bug ?)
[9.738480] [drm] Generation 2 PCI interface, using max accessible memory
[9.738484] [drm] radeon: VRAM 128M
[9.738486] [drm] radeon: VRAM from 0x7800 to 0x7FFF
[9.738489] [drm] radeon: GTT 32M
[9.738491] [drm] radeon: GTT from 0x8000 to 0x81FF
[9.738524] [drm] radeon: irq initialized.
[9.738664] [drm] Detected VRAM RAM=128M, BAR=128M
[9.738670] [drm] RAM width 128bits DDR
[9.738766] [TTM] Zone  kernel: Available graphics memory: 441954 kiB.
[9.738770] [TTM] Zone highmem: Available graphics memory: 971654 kiB.
[9.738794] [drm] radeon: 128M of VRAM memory ready
[9.738796] [drm] radeon: 32M of GTT memory ready.
[9.738819] [drm] GART: num cpu pages 8192, num gpu pages 8192
[9.739482] [drm] radeon: 4 quad pipes, 1 z pipes initialized.
[9.739498] [drm] radeon: cp idle (0x1C03)
[9.739544] [drm] Loading R300 Microcode
[9.739547] platform radeon_cp.0: firmware: requesting radeon/R300_cp.bin
[9.777003] phy0: Selected rate control algorithm 'minstrel'
[9.777900] ath5k phy0: Atheros AR2413 chip found (MAC: 0x78, PHY: 0x45)
[9.830823] radeon_cp: Failed to load firmware "radeon/R300_cp.bin"
[9.830874] [drm:r100_cp_init] *ERROR* Failed to load firmware!
[9.830920] radeon :01:05.0: failled initializing CP (-2).
[9.830964] radeon :01:05.0: Disabling GPU acceleration
[9.831011] [drm] radeon: cp finalized
[9.831148] [drm] Default TV standard: NTSC
[9.831150] [drm] 14.31818 MHz TV ref clk
[9.831232] [drm] Panel ID String: QDS 
[9.831236] [drm] Panel Size 1280x800
[9.831288] [drm] Radeon Display Connectors
[9.831291] [drm] Connector 0:
[9.831293] [drm]   VGA
[9.831296] [drm]   DDC: 0x68 0x68 0x68 0x68 0x68 0x68 0x68 0x68
[9.831299] [drm]   Encoders:
[9.831301] [drm] CRT1: INTERNAL_DAC2
[9.831303] [drm] Connector 1:
[9.831305] [drm]   LVDS
[9.831309] [drm]   DDC: 0x198 0x198 0x19c 0x19c 0x1a0 0x1a0 0x1a4 0x1a4
[9.831311] [drm]   Encoders:
[9.831313] [drm] LCD1: INTERNAL_LVDS
[9.920684] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3af: 
clean.
[9.923094] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x3e0-0x4ff: 
clean.
[9.924101] pcmcia_socket pcmcia_socket0: cs: IO port probe 0x820-0x8ff: 
clean.
[9.924921] pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcf7: 
clean.
[9.925884] pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: 
clean.
[9.975239] [drm] fb mappable at 0xC804
[9.975243] [drm] vram apper at 0xC800
[9.975246] [drm] size 4096000
[9.975248] [drm] fb depth is 24
[9.975250] [drm]pitch is 5120
[   10.016948] Console: switching to colour frame buffer device 160x50
[   10.027029] fb0: radeondrmfb frame buffer device
[   10.027031] registered panic notifier
[   10.027039] [drm] Initialized radeon 2.0.0 20080528 for :01:05.0 on 
minor 0
[   10.120694] HDA Intel :00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 
16
[   10.236838] hda_codec: ALC883: BIOS auto-probing.
[   10.237876] input: HDA Digital PCBeep as 
/devices/pci:00/:00:14.2/input/input9
[   10.849592] Adding 979924k swap on /dev/sda5.  Priority:-1 extents:1 
across:979924k 
[  

Processed: Kernel ABI management

[Debian Bug Tracking System]

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

> reopen 607368
Bug #607368 {Done: Ben Hutchings } [src:linux-2.6] 
linux-2.6: silent ABI change in 2.6.32.26 breaks external modules (smp_ops 
changes)
> submitter 607368 !
Bug #607368 [src:linux-2.6] linux-2.6: silent ABI change in 2.6.32.26 breaks 
external modules (smp_ops changes)
Changed Bug submitter to 'Julien BLACHE ' from 
'Julien-externe BLACHE '
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
607368: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607368
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.129266078924931.transcr...@bugs.debian.org

Bug#607368: Kernel ABI management

[Julien BLACHE]

reopen 607368
submitter 607368 !
thanks

Hi,

I am sorry that I have to reopen this bug, but first this is about more
than just smp_ops and second the outcome isn't satisfactory.

Whether a symbol is exported for a specific purpose or for general
usage, whether you like it or not, every symbol that is exported is part
of the ABI. If it changes, the ABI changes and it changes for everybody,
regardless of whether they're supposed to be using that symbol or not.

We would not accept that behaviour from a shared library, I don't see
any reason why we would accept it from the kernel.

As it stands, the kernel ABI number has just been rendered useless; I
can no longer trust it nor rely on it. Every kernel revision will have
to be tested to make sure all modules are still compatible with the new
ABI, given the ABI will change silently without bumping the ABI number.

Unsuspecting users will have their setup break upon reboot after
updating their kernel packages without any obvious clue as to what
caused the breakage.

This is a big deal as it puts a big question mark where the kernel ABI
number used to be. This is a problem for users, admins, ISV, vendors
higher up the chain, everybody. It's no longer possible to offer
certified modules for Debian kernels given the kernel ABI number cannot
be relied upon anymore.

Out of tree modules exist and you can't just ignore them; in some
environments they are necessary to make things work and you won't have a
way around that.

So I am asking you to reconsider your position and go back to strictly
maintaining the kernel ABI number. This situation is a big step backward
for the Debian kernel packages and I hope it'll be fixed soon.

Thanks,

JB.

-- 
 Julien BLACHE   |  Debian, because code matters more 
 Debian & GNU/Linux Developer|   
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 



-- 
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/87tyibh4fy@sonic.technologeek.org