Bug#608865: initramfs-tools: postinst fails if /tmp is mounted noexec

[Martin Gerdes]

Package: initramfs-tools
Version: 0.98.7
Severity: normal


Installing initramfs-tools version 0.98.7 on squeeze (=debian testing) I get 
the following error messages:

/usr/sbin/mkinitramfs: 296: 
/tmp/mkinitramfs_6qmV4K/scripts/init-top/all_generic_ide: Permission denied
/usr/sbin/mkinitramfs: 296: /tmp/mkinitramfs_6qmV4K/scripts/init-top/blacklist: 
Permission denied
/usr/sbin/mkinitramfs: 296: /tmp/mkinitramfs_6qmV4K/scripts/init-top/keymap: 
Permission denied
/usr/sbin/mkinitramfs: 296: /tmp/mkinitramfs_6qmV4K/scripts/init-top/udev: 
Permission denied
/usr/sbin/mkinitramfs: 296: /tmp/mkinitramfs_6qmV4K/scripts/init-bottom/udev: 
Permission denied
/usr/sbin/mkinitramfs: 296: 
/tmp/mkinitramfs_6qmV4K/scripts/local-premount/resume: Permission denied
/usr/sbin/mkinitramfs: 296: 
/tmp/mkinitramfs_6qmV4K/scripts/local-bottom/cryptopensc: Permission denied
/usr/sbin/mkinitramfs: 296: 
/tmp/mkinitramfs_6qmV4K/scripts/local-top/cryptopensc: Permission denied
/usr/sbin/mkinitramfs: 296: 
/tmp/mkinitramfs_6qmV4K/scripts/local-top/cryptroot: Permission denied
/usr/sbin/mkinitramfs: 296: /tmp/mkinitramfs_6qmV4K/scripts/local-top/lvm2: 
Permission denied

->the postinst fails because /tmp is mounted noexec, and the script can't set 
the executable bit for the listed files
Found this thread which indicates that m...@sro.at fixed the problem:
http://lists.debian.org/debian-kernel/2010/04/msg00481.html

I can work around this for now given the hints in the thread (I'll just point 
$TMPDIR to another director for the install), but would like to know if this 
will get fixed for final sqeeze? I'll definitely run into problems otherwise, 
as /tmp is set to noexec on all servers...

Many thanks in advance, and a happy new year 



-- 
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/20110104073027.4990.14640.report...@localhost

Bug#608861: unblock: firmware-nonfree/0.28

[Ben Hutchings]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package firmware-nonfree.  This includes several
important fixes for network hardware:

- Added firmware patches for some Realtek network controllers that
  allow them to work at 1G with a wider variety of cables and link
  partners.  These patches were included in the upstream driver for a
  long time but were not properly licenced.  Currently users may have to
  disable 1G operation. (#564628, #587960, #596390)

- Added firmware for Atheros wifi controllers. (#558740)

- Update for Netxen NICs, fixes a bug that can crash the NIC. (#606289)

- Update for Atheros AR3011, described as 'Fix EEPROM radio table
  issue and change PID to 3005'.

unblock firmware-nonfree/0.28

-- System Information:
Debian Release: 6.0
  APT prefers proposed-updates
  APT policy: (500, 'proposed-updates'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110104053513.3426.53296.report...@localhost

Bug#608858: linux-image-2.6.32-bpo.5-amd64: smbd kernel bug copying large file

[Ben Hutchings]

Can you reproduce this without VMware modules loaded?

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

Re: Bug#607368: Please decide how kernel ABI should be managed

[Don Armstrong]

On Mon, 27 Dec 2010, Ben Hutchings wrote:
> On Sun, 2010-12-26 at 15:55 -0800, Don Armstrong wrote:
> > Ok. And am I correct in assuming that if the ABI change would
> > break an OOT module, you would normally change the ABI number?
> 
> In the time I've been involved in the kernel team, I haven't yet
> seen a case where a bug fix required an ABI change that I knew would
> break an OOT module.

So in this case, if it was clear that the change would have broken an
OOT module, the kernel team would normally either postpone the change,
or change the ABI number.

> Anything distributed by Debian should meet those qualifications, but
> users such as Julien also care about modules from other sources. I
> normally use Google Code Search to check for OOT modules using
> symbols that have changed ABI and which I think might be ignorable.

Ok. For some reason, I hadn't originally noticed that this was
concerning an OOT module which Debian itself didn't actually
distribute. [Julien: I'm correct in that, right?] But that's probably
fine.
 
> > How are the symbols that those OOT modules use communicated to the
> > kernel team?
> 
> They aren't.

Would putting the onus on OOT maintainers to maintain such a list be
of benefit to the kernel maintainer team?

> > What does the kernel maintainer team feel should be done by the
> > maintainer in this case to ensure continuity of upgrades and rebuilds
> > of the OOT modules?
> [...]
> 
> We recommend that OOT module package makes use of DKMS. DKMS
> includes hook scripts to trigger rebuilding OOT modules
> automatically for each new kernel ABI version, if the end user or
> administrator installs the module source and the appropriate
> linux-headers package. In a more tightly controlled environment
> where such packages should not be installed on production servers,
> the administrator must rebuild modules elsewhere and deploy them
> along with the kernel upgrade. DKMS provides various means for this.

Makes sense. What about this case? What should Julien do?

Julien: Are you currently shipping a kernel in production which would
be affected by this change if we don't change the ABI number? Or does
this only affect cases where you are testing squeeze? Could it be
worked around by using DKMS or similar with prebuilt binaries and
requiring exact kernel version dependencies?


Don Armstrong

-- 
I don't care how poor and inefficient a little country is; they like
to run their own business.  I know men that would make my wife a
better husband than I am; but, darn it, I'm not going to give her to
'em.
 -- The Best of Will Rogers

http://www.donarmstrong.com  http://rzlab.ucr.edu


-- 
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/20110104045638.gg5...@teltox.donarmstrong.com

Bug#608858: linux-image-2.6.32-bpo.5-amd64: smbd kernel bug copying large file

[Gregg]

Package: linux-2.6
Version: 2.6.32-29~bpo50+1
Severity: important



-- Package-specific info:
** Version:
Linux version 2.6.32-bpo.5-amd64 (Debian 2.6.32-28~bpo50+1) 
(norb...@tretkowski.de) (gcc version 4.3.2 (Debian 4.3.2-1.1) ) #1 SMP Wed Dec 
1 21:46:07 UTC 2010

** Command line:
root=UUID=62ff30d3-77c3-4eef-bbd1-231819cb87bb ro 

** Tainted: D (128)
 * Kernel has oopsed before.

** Kernel log:
[   51.333039] /dev/vmnet: port on hub 8 successfully opened
[   51.356845] /dev/vmnet: open called by PID 3306 (vmnet-natd)
[   51.356864] /dev/vmnet: port on hub 8 successfully opened
[   53.700902] cx25840 1-0044: loaded v4l-cx25840.fw firmware (16382 bytes)
[   58.492883] /dev/vmmon[3807]: PTSC: initialized at 1994246000 Hz using TSC
[   58.498766] /dev/vmmon[3807]: Vmx86_InitNUMAInfo : numaNumMemRanges=4 and 
numaNumNodes=2
[   59.221035] /dev/vmnet: open called by PID 3810 (vmware-vmx)
[   59.221060] device eth1 entered promiscuous mode
[   59.221190] bridge-eth1: enabled promiscuous mode
[   59.221302] /dev/vmnet: port on hub 0 successfully opened
[   60.718876] /dev/vmnet: open called by PID 3813 (vmnet-netifup)
[   60.718898] /dev/vmnet: port on hub 1 successfully opened
[   61.237004] /dev/vmnet: open called by PID 3831 (vmnet-netifup)
[   61.237027] /dev/vmnet: port on hub 8 successfully opened
[1224233.234497] /dev/vmnet: open called by PID 27897 (vmware-vmx)
[1224233.234537] /dev/vmnet: port on hub 0 successfully opened
[1387784.950567] vmmon: Had to deallocate locked 97788 pages from vm driver 
88013f151400
[1387784.957115] vmmon: Had to deallocate AWE 7092 pages from vm driver 
88013f151400
[1393758.348153] EXT3-fs error (device dm-5): ext3_valid_block_bitmap: Invalid 
block bitmap - block_group = 1211, block = 39682050
[1393758.348639] EXT3-fs error (device dm-5): ext3_new_block: Allocating block 
in system zone - blocks from 39682055, length 1
[1393758.358189] EXT3-fs error (device dm-5): ext3_valid_block_bitmap: Invalid 
block bitmap - block_group = 1212, block = 39714818
[1393758.358564] EXT3-fs error (device dm-5): ext3_new_block: Allocating block 
in system zone - blocks from 39714822, length 1
[1393760.652245] EXT3-fs error (device dm-5): ext3_valid_block_bitmap: Invalid 
block bitmap - block_group = 1213, block = 39747584
[1393760.652848] EXT3-fs error (device dm-5): ext3_new_block: Allocating block 
in system zone - blocks from 39747584, length 1
[1393760.699782] EXT3-fs error (device dm-5): ext3_valid_block_bitmap: Invalid 
block bitmap - block_group = 1215, block = 39813122
[1393760.700244] EXT3-fs error (device dm-5): ext3_new_block: Allocating block 
in system zone - blocks from 39813123, length 1
[1393760.706494] EXT3-fs error (device dm-5): ext3_valid_block_bitmap: Invalid 
block bitmap - block_group = 1217, block = 39878658
[1393760.706889] EXT3-fs error (device dm-5): ext3_new_block: Allocating block 
in system zone - blocks from 39878749, length 1
[1393760.714641] EXT3-fs error (device dm-5): ext3_valid_block_bitmap: Invalid 
block bitmap - block_group = 1218, block = 39911426
[1393760.715014] EXT3-fs error (device dm-5): ext3_new_block: Allocating block 
in system zone - blocks from 39911613, length 1
[1393760.720552] EXT3-fs error (device dm-5): ext3_valid_block_bitmap: Invalid 
block bitmap - block_group = 1220, block = 39976961
[1393760.720931] EXT3-fs error (device dm-5): ext3_new_block: Allocating block 
in system zone - blocks from 39976976, length 1
[1393760.729925] EXT3-fs error (device dm-5): ext3_valid_block_bitmap: Invalid 
block bitmap - block_group = 1222, block = 40042498
[1393760.730315] EXT3-fs error (device dm-5): ext3_new_block: Allocating block 
in system zone - blocks from 40042600, length 1
[1393760.735353] EXT3-fs error (device dm-5): ext3_valid_block_bitmap: Invalid 
block bitmap - block_group = 1223, block = 40075266
[1393760.735726] EXT3-fs error (device dm-5): ext3_new_block: Allocating block 
in system zone - blocks from 40075267, length 1
[1393760.745867] EXT3-fs error (device dm-5): ext3_valid_block_bitmap: Invalid 
block bitmap - block_group = 1224, block = 40108033
[1393760.746255] EXT3-fs error (device dm-5): ext3_new_block: Allocating block 
in system zone - blocks from 40108048, length 1
[1393760.754616] EXT3-fs error (device dm-5): ext3_valid_block_bitmap: Invalid 
block bitmap - block_group = 1225, block = 40140802
[1393760.755004] EXT3-fs error (device dm-5): ext3_new_block: Allocating block 
in system zone - blocks from 40140802, length 1
[1393760.761827] EXT3-fs error (device dm-5): ext3_valid_block_bitmap: Invalid 
block bitmap - block_group = 1226, block = 40173570
[1393760.762284] EXT3-fs error (device dm-5): ext3_new_block: Allocating block 
in system zone - blocks from 40173672, length 1
[1393760.770746] EXT3-fs error (device dm-5): ext3_valid_block_bitmap: Invalid 
block bitmap - block_group = 1227, block = 40206338
[1393760.77] EXT3-fs error (device dm-5): ext3_new_block: Allocating block 
in system zone - blocks from 40

Processing of firmware-nonfree_0.28_i386.changes

[Debian FTP Masters]

firmware-nonfree_0.28_i386.changes uploaded successfully to localhost
along with the files:
  firmware-nonfree_0.28.dsc
  firmware-nonfree_0.28.tar.gz
  firmware-linux_0.28_all.deb
  firmware-atheros_0.28_all.deb
  firmware-bnx2_0.28_all.deb
  firmware-bnx2x_0.28_all.deb
  firmware-brcm80211_0.28_all.deb
  firmware-intelwimax_0.28_all.deb
  firmware-ipw2x00_0.28_all.deb
  firmware-ivtv_0.28_all.deb
  firmware-iwlwifi_0.28_all.deb
  firmware-linux-nonfree_0.28_all.deb
  firmware-netxen_0.28_all.deb
  firmware-qlogic_0.28_all.deb
  firmware-ralink_0.28_all.deb
  firmware-realtek_0.28_all.deb

Greetings,

Your Debian queue daemon (running on host franck.debian.org)


-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1pzxfw-0005g6...@franck.debian.org

Bug#608538: btrfs root installation results in initramfs busybox prompt

[Ben Hutchings]

On Mon, 2011-01-03 at 19:31 -0700, Tim Gardner wrote:
> On 01/03/2011 03:32 PM, Ben Hutchings wrote:
> >
> > Try this.  I've made it reasonably generic so you can easily add other
> > hidden dependencies like tg3 ->  broadcom.
> >
> > Ben.
> >
> 
> I wrote a couple of macros for Karmic to solve a race problem that might 
> be applicable here.
[...]

There are (at least) three different though similar problems:

1. The GART/GPU initialisation ordering problem.  The artificial symbol
dependency works for i915, but the problem remains for other GPU drivers
which can't depend on a specific GART driver.  Our solution was to
build-in all the GART drivers, as they are quite small.

2. Network driver dependency on a PHY driver.  There's no ordering
problem because we now generate and use module aliases based on MDIO
IDs.  However, the PHY module dependency is discovered dynamically, so
it is hidden from initramfs-tools.  (This is not a problem when
MODULES=most, because mkinitramfs then includes all modules under
drivers/net/phy.)  The artifical symbol dependency can be used as a
workaround, at the cost of loading modules that aren't needed.

3. For crypto users and drivers, the dependency is discovered
dynamically, so again it is hidden from initramfs-tools.  The artifical
symbol dependency can be used as a workaround, but optimised drivers
will not be loaded automatically.  (Though for the specific case of
crc32c this is broken anyway.)

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#608538: btrfs root installation results in initramfs busybox prompt

[Tim Gardner]

On 01/03/2011 03:32 PM, Ben Hutchings wrote:


Try this.  I've made it reasonably generic so you can easily add other
hidden dependencies like tg3 ->  broadcom.

Ben.



I wrote a couple of macros for Karmic to solve a race problem that might 
be applicable here. I think there are several areas of the kernel that 
suffer from this type of indirect runtime registration issue. 
Unfortunately, this patch requires that you hack the macro values into 
the offending modules.


rtg

--
Tim Gardner tim.gard...@canonical.com
>From 3a9048b7ebc1aefd539290238cfd4d2dfafbfa0a Mon Sep 17 00:00:00 2001
From: Tim Gardner 
Date: Tue, 6 Oct 2009 17:28:34 -0600
Subject: [PATCH] UBUNTU: SAUCE: Created MODULE_EXPORT/MODULE_IMPORT macros

BugLink: http://bugs.launchpad.net/bugs/430694

Create a macro pair that can be used to symbolicly link two modules
if they  are not already directly linked.
This relationship uses the facilities of depmod and modprobe to
get soft dependencies loaded in the correct order.

Examples of soft dependencies are:
1) i915 and intel_agp (agp _must_ be loaded before i915)
2) any net driver that uses phylib modules.

Signed-off-by: Tim Gardner 
---
 include/linux/module.h |9 +
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/include/linux/module.h b/include/linux/module.h
index 8b17fd8..9733e7f 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -712,4 +712,13 @@ static inline void module_bug_finalize(const Elf_Ehdr *hdr,
 static inline void module_bug_cleanup(struct module *mod) {}
 #endif	/* CONFIG_GENERIC_BUG */
 
+/*
+ * Establish a symbolic link between 2 modules so that depmod
+ * and modprobe do the heavy lifting of loading the modules in the
+ * correct dependency order.
+ */
+#define MODULE_EXPORT(mod_name) int sym_link_##mod_name; EXPORT_SYMBOL(sym_link_##mod_name);
+#define MODULE_IMPORT(mod_name) extern int sym_link_##mod_name; int func_sym_link_##mod_name(void) {sym_link_##mod_name=1;}; EXPORT_SYMBOL(func_sym_link_##mod_name);
+
+
 #endif /* _LINUX_MODULE_H */
-- 
1.7.0.4

Processed: tagging 598470

[Debian Bug Tracking System]

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

> # Automatically generated email from bts, devscripts version 2.10.35lenny7
> tags 598470 + pending
Bug #598470 [firmware-bnx2] bnx2-mips-06-5.0.0.j6.fw file not included in 
"firmware-bnx2"
Ignoring request to alter tags of bug #598470 to the same tags previously set
>
End of message, stopping processing here.

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

Bug#603775: marked as done (firmware-linux: please include ihex2fw tool into one of linux-* packages)

[Debian Bug Tracking System]

Your message dated Tue, 04 Jan 2011 01:50:53 +
with message-id <1294105853.3167.257.ca...@localhost>
and subject line Re: firmware-linux: please include ihex2fw tool into one of 
linux-* packages
has caused the Debian Bug report #603775,
regarding firmware-linux: please include ihex2fw tool into one of linux-* 
packages
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.)


-- 
603775: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603775
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: firmware-linux
Version: 0.27
Severity: wishlist


To at least ease life of those urgently needing to get proper firmware
out of vanilla linux source tree firmware/, it would be great to have 
ihex2fw available (source for which are under firmware/ directory in
linux sources)

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages firmware-linux depends on:
ii  firmware-linux-free   2.6.32-27  Binary firmware for various driver
ii  firmware-linux-nonfree0.27   Binary firmware for various driver

firmware-linux recommends no packages.

firmware-linux suggests no packages.

-- no debconf information


--- End Message ---
--- Begin Message ---
On Tue, 2010-11-16 at 23:44 -0500, Yaroslav Halchenko wrote:
> Package: firmware-linux
> Version: 0.27
> Severity: wishlist
> 
> 
> To at least ease life of those urgently needing to get proper firmware
> out of vanilla linux source tree firmware/, it would be great to have 
> ihex2fw available (source for which are under firmware/ directory in
> linux sources)

If you have a vanilla source tree then you can build the ihex2fw tool
and all separate firmware blobs with:

make defconfig
make firmware_install

Therefore I don't see any point in packaging the ihex2fw tool.

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
--- End Message ---

Processed: tagging 598470

[Debian Bug Tracking System]

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

> # Automatically generated email from bts, devscripts version 2.10.35lenny7
> tags 598470 + pending
Bug #598470 [firmware-bnx2] bnx2-mips-06-5.0.0.j6.fw file not included in 
"firmware-bnx2"
Ignoring request to alter tags of bug #598470 to the same tags previously set
>
End of message, stopping processing here.

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

Processed: tagging 602450

[Debian Bug Tracking System]

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

> # Automatically generated email from bts, devscripts version 2.10.35lenny7
> tags 602450 + pending
Bug #602450 [firmware-nonfree] firmware-nonfree: Please add 
rtlwifi/rtl8712u.bin, needed by r8712u >= 2.6.37, to firmware-realtek
Added tag(s) pending.
>
End of message, stopping processing here.

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

Processed: tagging 564628

[Debian Bug Tracking System]

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

> # Automatically generated email from bts, devscripts version 2.10.35lenny7
> tags 564628 + pending
Bug #564628 [src:firmware-nonfree] Add Realtek RTL8168D firmware
Bug #587960 [src:firmware-nonfree] [Debian] Where can I find rtl81638d-2.fw 
firmware for Realtek  8168D NIC?
Added tag(s) pending.
Added tag(s) pending.
>
End of message, stopping processing here.

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

Bug#608538: btrfs root installation results in initramfs busybox prompt

[Ben Hutchings]

On Mon, 2011-01-03 at 22:57 +0100, Michael Prokop wrote:
> * Ben Hutchings  [Mon Jan 03, 2011 at 09:50:46PM +]:
> > On Mon, 2011-01-03 at 22:16 +0100, Michael Prokop wrote:
> > > * Ben Hutchings  [Mon Jan 03, 2011 at 09:03:37PM 
> > > +]:
> > > > On Mon, 2011-01-03 at 16:37 -0400, Joey Hess wrote:
> 
> > > > > So, at least a workaround would be for the initramfs to have crc32c 
> > > > > added to
> > > > > it whenever libcrc32c is. Attached patch just adds it to the base 
> > > > > modules
> > > > > list; since btrfs is already there that seems like an ok quick fix.
> 
> > > > This is stupid.  Without a declared module dependency, a MODULES=dep
> > > > configuration will remain broken.  I think this needs to be fixed in the
> > > > kernel instead.
> 
> > > > > Note that it would probably be better to try first loading hardware 
> > > > > optimised
> > > > > versions like crc32c-intel, and only load crc32c if they fail to load.
> 
> > > > I believe that happens automatically, as the hardware-optimised modules
> > > > provide an alias of 'crc32c'.
> 
> > > > > (BTW, this bug probably also breaks netbooting with certian ethernet 
> > > > > cards
> > > > > whose drivers also use libcrc32c.)
> 
> > > > Right.
> 
> > > Thanks for showing up, would be nice to see this fixed.
> 
> > > I just want to make sure you're aware of my bugreport #602254
> > > (which Joey seemed to have noticed already according to its
> > > BTS history).
> 
> > > Ben, do you think this could be fixed at the kernel side?
> 
> > Eventually, yes, but unfortunately it turns out that we can't fix it
> > immediately.  'depmod' only looks at symbol dependencies; there is no
> > way for modules to declare explicit dependencies through module
> > information.  We can bodge it by exporting a specific symbol from crc32c
> > and referring to that from libcrc32c, but since the optimised version
> > doesn't satisfy that dependency it will not be loaded.
> 
> Ok, that's what I expected.

Actually, 'modprobe' will completely ignore aliases if there is a module
whose real name matches the requested name.  So currently crc32c-intel
will never be automatically loaded!

> > So I'm afraid this will have to be worked around in initramfs-tools for
> > now: whenever you add libcrc32c, add crc32c as well (no matter how
> > libcrc32c was selected).
> 
> So we should just add crc32c-intel, libcrc32c and crc32c by default
> via initramfs-tools for now, ACK?

Try this.  I've made it reasonably generic so you can easily add other
hidden dependencies like tg3 -> broadcom.

Ben.

From: Ben Hutchings 
Date: Mon, 3 Jan 2011 21:58:24 +
Subject: [PATCH] Handle hidden dependency of libcrc32c on crc32c

'depmod' only looks at symbol dependencies; there is no way for
modules to declare explicit dependencies through module information,
so dependencies on e.g. crypto providers are hidden.  Until this is
fixed, we need to handle those hidden dependencies.

Signed-off-by: Ben Hutchings 
---
 hook-functions |   14 ++
 mkinitramfs|3 +++
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/hook-functions b/hook-functions
index c559651..d77c295 100644
--- a/hook-functions
+++ b/hook-functions
@@ -484,6 +484,20 @@ auto_add_modules()
esac
 }
 
+# 'depmod' only looks at symbol dependencies; there is no way for
+# modules to declare explicit dependencies through module information,
+# so dependencies on e.g. crypto providers are hidden.  Until this is
+# fixed, we need to handle those hidden dependencies.
+hidden_dep_add_modules()
+{
+   for dep in "lib/libcrc32c crc32c"; do
+   set -- $dep
+   if [ -f "${DESTDIR}/lib/modules/${version}/kernel/$1.ko" ]; then
+   manual_add_modules "$2"
+   fi
+   done
+}
+
 # mkinitramfs help message
 usage()
 {
diff --git a/mkinitramfs b/mkinitramfs
index 0bb7806..40eb35b 100755
--- a/mkinitramfs
+++ b/mkinitramfs
@@ -232,6 +232,9 @@ list)
;;
 esac
 
+# Resolve hidden dependencies
+hidden_dep_add_modules
+
 # Have to do each file, because cpio --dereference doesn't recurse down
 # symlinks.
 
-- 
1.7.2.3

-- 
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#587014: screen brightness can't be modified on some Panasonic laptops

[Matthew Garrett]

Well, that's odd. There's certainly support for ACPI backlight control 
in your firmware, and it goes via opregion so it should work correctly. 
I think the thing to do here is to have the panasonic driver bail if 
there's ACPI backlight support, and then figure out why the ACPI video 
driver isn't working for you.

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



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110103223240.ga6...@srcf.ucam.org

Bug#587014: screen brightness can't be modified on some Panasonic laptops

[Matthew Garrett]

On Tue, Jan 04, 2011 at 06:14:40AM +0800, Cristopher Camacho wrote:
> No, there is no. Only the /sys/class/backlight/panasonic/ directory is 
> present.

Can you attach the output of the acpidump command on your system?

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



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110103221821.ga5...@srcf.ucam.org

Bug#587014: screen brightness can't be modified on some Panasonic laptops

[Matthew Garrett]

Is there a /sys/class/backlight/acpi_video0 directory as well as the 
Panasonic one?

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



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110103213339.ga5...@srcf.ucam.org

Bug#587014: screen brightness can't be modified on some Panasonic laptops

[Cristopher Camacho]

No, there is no. Only the /sys/class/backlight/panasonic/ directory is present.

Cristopher

On Tue, Jan 4, 2011 at 5:33 AM, Matthew Garrett  wrote:
> Is there a /sys/class/backlight/acpi_video0 directory as well as the
> Panasonic one?
>
> --
> Matthew Garrett | mj...@srcf.ucam.org
>



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktinvwtsfmfx2q9fjfwhyt6=_vtsszsbfad3k-...@mail.gmail.com

Bug#608538: btrfs root installation results in initramfs busybox prompt

[Michael Prokop]

* Ben Hutchings  [Mon Jan 03, 2011 at 09:50:46PM +]:
> On Mon, 2011-01-03 at 22:16 +0100, Michael Prokop wrote:
> > * Ben Hutchings  [Mon Jan 03, 2011 at 09:03:37PM 
> > +]:
> > > On Mon, 2011-01-03 at 16:37 -0400, Joey Hess wrote:

> > > > So, at least a workaround would be for the initramfs to have crc32c 
> > > > added to
> > > > it whenever libcrc32c is. Attached patch just adds it to the base 
> > > > modules
> > > > list; since btrfs is already there that seems like an ok quick fix.

> > > This is stupid.  Without a declared module dependency, a MODULES=dep
> > > configuration will remain broken.  I think this needs to be fixed in the
> > > kernel instead.

> > > > Note that it would probably be better to try first loading hardware 
> > > > optimised
> > > > versions like crc32c-intel, and only load crc32c if they fail to load.

> > > I believe that happens automatically, as the hardware-optimised modules
> > > provide an alias of 'crc32c'.

> > > > (BTW, this bug probably also breaks netbooting with certian ethernet 
> > > > cards
> > > > whose drivers also use libcrc32c.)

> > > Right.

> > Thanks for showing up, would be nice to see this fixed.

> > I just want to make sure you're aware of my bugreport #602254
> > (which Joey seemed to have noticed already according to its
> > BTS history).

> > Ben, do you think this could be fixed at the kernel side?

> Eventually, yes, but unfortunately it turns out that we can't fix it
> immediately.  'depmod' only looks at symbol dependencies; there is no
> way for modules to declare explicit dependencies through module
> information.  We can bodge it by exporting a specific symbol from crc32c
> and referring to that from libcrc32c, but since the optimised version
> doesn't satisfy that dependency it will not be loaded.

Ok, that's what I expected.

> So I'm afraid this will have to be worked around in initramfs-tools for
> now: whenever you add libcrc32c, add crc32c as well (no matter how
> libcrc32c was selected).

So we should just add crc32c-intel, libcrc32c and crc32c by default
via initramfs-tools for now, ACK?

Thanks.

regards,
-mika-


signature.asc
Description: Digital signature

Bug#608538: btrfs root installation results in initramfs busybox prompt

[Ben Hutchings]

On Mon, 2011-01-03 at 22:16 +0100, Michael Prokop wrote:
> * Ben Hutchings  [Mon Jan 03, 2011 at 09:03:37PM +]:
> > On Mon, 2011-01-03 at 16:37 -0400, Joey Hess wrote:
> > > I hope this can be dealt with, it seems to be the only remaining
> > > issue in getting Debian to support btrfs root filesystems. 
> 
> > > This is easily reproducible, I installed from a recent daily build
> > > netinst, put /boot on ext3 and / on btrfs and same problem on boot.
> 
> > > The problem is that btrfs depends on libcrc32c, which demand loads
> > > any of several crc32c implementations, depending on hardware. Those
> > > modules are not declared as dependencies, so initramfs-tools does not
> > > include them.
> 
> > > So, another way to see the same problem:
> 
> > > r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>mv crc32c.ko ~  
> > > r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>insmod 
> > > ../lib/libcrc32c.ko 
> > > insmod: error inserting '../lib/libcrc32c.ko': -1 Unknown symbol in module
> > > r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>mv ~/crc32c.ko .
> > > r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>insmod 
> > > ../lib/libcrc32c.ko
> > > r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>
> 
> > > So, at least a workaround would be for the initramfs to have crc32c added 
> > > to
> > > it whenever libcrc32c is. Attached patch just adds it to the base modules
> > > list; since btrfs is already there that seems like an ok quick fix.
> 
> > This is stupid.  Without a declared module dependency, a MODULES=dep
> > configuration will remain broken.  I think this needs to be fixed in the
> > kernel instead.
> 
> > > Note that it would probably be better to try first loading hardware 
> > > optimised
> > > versions like crc32c-intel, and only load crc32c if they fail to load.
> 
> > I believe that happens automatically, as the hardware-optimised modules
> > provide an alias of 'crc32c'.
> 
> > > (BTW, this bug probably also breaks netbooting with certian ethernet cards
> > > whose drivers also use libcrc32c.)
> 
> > Right.
> 
> Thanks for showing up, would be nice to see this fixed.
> 
> I just want to make sure you're aware of my bugreport #602254
> (which Joey seemed to have noticed already according to its
> BTS history).
> 
> Ben, do you think this could be fixed at the kernel side?

Eventually, yes, but unfortunately it turns out that we can't fix it
immediately.  'depmod' only looks at symbol dependencies; there is no
way for modules to declare explicit dependencies through module
information.  We can bodge it by exporting a specific symbol from crc32c
and referring to that from libcrc32c, but since the optimised version
doesn't satisfy that dependency it will not be loaded.

So I'm afraid this will have to be worked around in initramfs-tools for
now: whenever you add libcrc32c, add crc32c as well (no matter how
libcrc32c was selected).

Ben.

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


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

Bug#606950: sd_mod: Unknown symbol blk_queue_physical_block_size_fixed

[Martin Michlmayr]

* Mikko Tuumanen  [2011-01-03 20:57]:
> Should this bug report then be filed against the installer?

A new version of the installer is currently in preparation.  When a
new version is in preparation, the old version of the netboot images
are broken since the kernel and modules get out of sync.  Until the
new version of the installer is out, you can use the daily installer
image from http://people.debian.org/~joeyh/d-i/armel/images/daily/

-- 
Martin Michlmayr
http://www.cyrius.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/20110103213057.gb27...@jirafa.cyrius.com

Bug#608538: btrfs root installation results in initramfs busybox prompt

[Michael Prokop]

* Ben Hutchings  [Mon Jan 03, 2011 at 09:03:37PM +]:
> On Mon, 2011-01-03 at 16:37 -0400, Joey Hess wrote:
> > I hope this can be dealt with, it seems to be the only remaining
> > issue in getting Debian to support btrfs root filesystems. 

> > This is easily reproducible, I installed from a recent daily build
> > netinst, put /boot on ext3 and / on btrfs and same problem on boot.

> > The problem is that btrfs depends on libcrc32c, which demand loads
> > any of several crc32c implementations, depending on hardware. Those
> > modules are not declared as dependencies, so initramfs-tools does not
> > include them.

> > So, another way to see the same problem:

> > r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>mv crc32c.ko ~  
> > r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>insmod ../lib/libcrc32c.ko 
> > insmod: error inserting '../lib/libcrc32c.ko': -1 Unknown symbol in module
> > r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>mv ~/crc32c.ko .
> > r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>insmod ../lib/libcrc32c.ko
> > r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>

> > So, at least a workaround would be for the initramfs to have crc32c added to
> > it whenever libcrc32c is. Attached patch just adds it to the base modules
> > list; since btrfs is already there that seems like an ok quick fix.

> This is stupid.  Without a declared module dependency, a MODULES=dep
> configuration will remain broken.  I think this needs to be fixed in the
> kernel instead.

> > Note that it would probably be better to try first loading hardware 
> > optimised
> > versions like crc32c-intel, and only load crc32c if they fail to load.

> I believe that happens automatically, as the hardware-optimised modules
> provide an alias of 'crc32c'.

> > (BTW, this bug probably also breaks netbooting with certian ethernet cards
> > whose drivers also use libcrc32c.)

> Right.

Thanks for showing up, would be nice to see this fixed.

I just want to make sure you're aware of my bugreport #602254
(which Joey seemed to have noticed already according to its
BTS history).

Ben, do you think this could be fixed at the kernel side?

regards,
-mika-


signature.asc
Description: Digital signature

Bug#608538: btrfs root installation results in initramfs busybox prompt

[Ben Hutchings]

On Mon, 2011-01-03 at 16:37 -0400, Joey Hess wrote:
> I hope this can be dealt with, it seems to be the only remaining
> issue in getting Debian to support btrfs root filesystems. 
> 
> This is easily reproducible, I installed from a recent daily build
> netinst, put /boot on ext3 and / on btrfs and same problem on boot.
> 
> The problem is that btrfs depends on libcrc32c, which demand loads
> any of several crc32c implementations, depending on hardware. Those
> modules are not declared as dependencies, so initramfs-tools does not
> include them.
> 
> So, another way to see the same problem:
> 
> r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>mv crc32c.ko ~  
> r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>insmod ../lib/libcrc32c.ko 
> insmod: error inserting '../lib/libcrc32c.ko': -1 Unknown symbol in module
> r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>mv ~/crc32c.ko .
> r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>insmod ../lib/libcrc32c.ko
> r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>
> 
> So, at least a workaround would be for the initramfs to have crc32c added to
> it whenever libcrc32c is. Attached patch just adds it to the base modules
> list; since btrfs is already there that seems like an ok quick fix.

This is stupid.  Without a declared module dependency, a MODULES=dep
configuration will remain broken.  I think this needs to be fixed in the
kernel instead.

> Note that it would probably be better to try first loading hardware optimised
> versions like crc32c-intel, and only load crc32c if they fail to load.

I believe that happens automatically, as the hardware-optimised modules
provide an alias of 'crc32c'.

> (BTW, this bug probably also breaks netbooting with certian ethernet cards
> whose drivers also use libcrc32c.)

Right.

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: tagging 608138

[Debian Bug Tracking System]

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

> # Automatically generated email from bts, devscripts version 2.10.35lenny7
> tags 608138 + pending
Bug #608138 [linux-2.6] Annoying warning "NMI watchdog failed to create perf 
event on cpu0"
Added tag(s) pending.
>
End of message, stopping processing here.

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

Bug#608538: btrfs root installation results in initramfs busybox prompt

[Joey Hess]

I hope this can be dealt with, it seems to be the only remaining
issue in getting Debian to support btrfs root filesystems. 

This is easily reproducible, I installed from a recent daily build
netinst, put /boot on ext3 and / on btrfs and same problem on boot.

The problem is that btrfs depends on libcrc32c, which demand loads
any of several crc32c implementations, depending on hardware. Those
modules are not declared as dependencies, so initramfs-tools does not
include them.

So, another way to see the same problem:

r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>mv crc32c.ko ~  
r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>insmod ../lib/libcrc32c.ko 
insmod: error inserting '../lib/libcrc32c.ko': -1 Unknown symbol in module
r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>mv ~/crc32c.ko .
r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>insmod ../lib/libcrc32c.ko
r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto>

So, at least a workaround would be for the initramfs to have crc32c added to
it whenever libcrc32c is. Attached patch just adds it to the base modules
list; since btrfs is already there that seems like an ok quick fix.

Note that it would probably be better to try first loading hardware optimised
versions like crc32c-intel, and only load crc32c if they fail to load.

(BTW, this bug probably also breaks netbooting with certian ethernet cards
whose drivers also use libcrc32c.)

-- 
see shy jo
--- hook-functions.orig 2011-01-03 16:20:26.705813570 -0400
+++ hook-functions  2011-01-03 16:20:30.278780384 -0400
@@ -412,7 +412,7 @@
for x in ehci-hcd ohci-hcd uhci-hcd usbhid xhci hid-apple \
hid-cherry hid-logitech hid-microsoft \
btrfs ext2 ext3 ext4 ext4dev isofs jfs nfs reiserfs udf xfs \
-   af_packet atkbd i8042 virtio_pci; do
+   af_packet atkbd i8042 virtio_pci crc32c; do
manual_add_modules "${x}"
done
;;


signature.asc
Description: Digital signature

Processed: tagging 608804

[Debian Bug Tracking System]

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

> tags 608804 + moreinfo
Bug #608804 [linux-2.6] linux-image-amd64: /sys/class/power_supply/ACAD/online 
is 1 without power cable plugged in
Added tag(s) moreinfo.
> thanks
Stopping processing here.

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

Bug#608804: linux-image-amd64: /sys/class/power_supply/ACAD/online is 1 without power cable plugged in

[Ben Hutchings]

On Mon, 2011-01-03 at 17:04 +0100, Martin Kraus wrote:
> Package: linux-image-amd64
> Version: 2.6.32+28
> Severity: normal
> Tags: upstream
> 
> 
> After cold boot without power cable plugged in 
> /sys/class/power_supply/ACAD/online is 1 which 
> leaves on_ac_power returning wrong information for packages like 
> laptop-mode-tools. 
> 
> Hardware used is Lenovo ThinkPad SL410. 
> 
> modprobe -r ac; modprobe ac 
> solves this problem as does plugging the power cable in and out again.
> 
> I've tested this with vanila kernel version 2.6.37-rc5 and this problem is 
> still present.

Please report this upstream at  under
product ACPI, component Power-Battery.  Let us know the bug number or
URL so we can track it.

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#608278: linux-image-2.6.32-5-amd64: Random general protection faults at boot

[Ben Hutchings]

On Mon, 2011-01-03 at 15:19 +0100, Andrea Spadaccini wrote:
> Hi,
> 
> >>> This is presumably caused by a bug in rtl8187.  However, it is not a
> >>> general protection fault so there may be two different bugs here.
> >>
> >> Yes, the GPF is around sec 30. After that bug, I blacklisted rtl8187,
> >> and resulted in the other GPFs at boot time that are not logged.
> >
> > Can you try blacklisting the radeon driver?
> 
> If I blacklist the radeon driver, I don't get any GPFs anymore.
> 
> I did 10 reboots, and no problems.
> 
> Can I help you anymore in diagnosing the problem?

Please test the package of Linux 2.6.37-rc7 from experimental, with
radeon enabled again.

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#597658: linux-headers-2.6.32-5-amd64: Missing aesni-intel module in kernel

[Ben Hutchings]

On Mon, 2011-01-03 at 10:12 -0700, dann frazier wrote:
> On Mon, Jan 03, 2011 at 05:05:32AM +, Ben Hutchings wrote:
> > On Sun, 2011-01-02 at 21:30 -0700, dann frazier wrote:
> > > On Sun, Jan 02, 2011 at 08:57:19PM +, Ben Hutchings wrote:
> > [...]
> > > > Please can you test whether aesni-intel loads and works in:
> > > > 
> > > > 1. Package version 2.6.32-12
> > > > .  This was the
> > > > last version with aesni-intel included.
> > > > 
> > > > 2. Package version 2.6.32-29, modified to reenable aesni-intel.  See the
> > > > instructions at
> > > > .
> > > > a. Follow section 4.2.1.
> > > > b. Change '# CONFIG_CRYPTO_AES_NI_INTEL is not set' to
> > > >'CONFIG_CRYPTO_AES_NI_INTEL=m' in
> > > >debian/config/kernelarch-x86/config-arch-64.
> > > > c. Follow section 4.2.4.
> > > 
> > > fyi, 2.6.32-12 & 2.6.32-29 w/ CONFIG_CRYPTO_AES_NI_INTEL=m both boot
> > > successfully w/ the aesni_intel module on my Lenovo T410.
> > 
> > I'm guessing you don't have an AES-encrypted hard drive though...
> 
> I do:
> 
> $ sudo cryptsetup status sda5_crypt 
> /dev/mapper/sda5_crypt is active:
>   cipher:  aes-cbc-essiv:sha256
> [...]
> 
> Though I don't know how to verify that the hardware implementation is
> actually being used.

I think that trying to remove the module is a valid test.

> fwiw, the init messages do differ for me between -12 & -29 (as the git
> log suggests it should):
> 
> -12:
> [   13.565523] alg: No test for __aes-aesni (__driver-aes-aesni)
> [   13.565542] alg: No test for __ecb-aes-aesni (__driver-ecb-aes-aesni)
> [   13.565559] alg: No test for __cbc-aes-aesni (__driver-cbc-aes-aesni)
> [   13.566877] alg: No test for __ecb-aes-aesni 
> (cryptd(__driver-ecb-aes-aesni))
> [   13.569514] alg: No test for __cbc-aes-aesni 
> (cryptd(__driver-cbc-aes-aesni))
> 
> -29:
> [   10.766143] alg: No test for __cbc-aes-aesni 
> (cryptd(__driver-cbc-aes-aesni))

Hmm, I wonder why this last one is not given a null test like the
others.

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: tagging 608538, reassign 608538 to initramfs-tools

[Debian Bug Tracking System]

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

> tags 608538 + d-i
Bug #608538 [btrfs-tools] Didn't include required module in initramfs
Bug #602254 [btrfs-tools] Didn't include required module in initramfs
Added tag(s) d-i.
Added tag(s) d-i.
> reassign 608538 initramfs-tools
Bug #608538 [btrfs-tools] Didn't include required module in initramfs
Bug #602254 [btrfs-tools] Didn't include required module in initramfs
Bug reassigned from package 'btrfs-tools' to 'initramfs-tools'.
Bug reassigned from package 'btrfs-tools' to 'initramfs-tools'.
> thanks
Stopping processing here.

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

Bug#606950: sd_mod: Unknown symbol blk_queue_physical_block_size_fixed

[Mikko Tuumanen]

> Those are the installer kernel and initrd, which are an older version
> than the kernel and modules that get installed in the filesystem.  You

I want to install to a usb stick and I can't because sd_mod doesn't load.

# modprobe sd_mod
FATAL: Error inserting sd_mod (/lib/modules/2.6.32-5-
kirkwood/kernel/drivers/scsi/sd_mod.ko): Unknown symbol in module, or unknown 
parameter (see dmesg)

[  374.383993] sd_mod: Unknown symbol blk_queue_physical_block_size_fixed

Should this bug report then be filed against the installer?



-- 
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/201101032057.09824.mikko.tuuma...@utu.fi

Bug#606950: sd_mod: Unknown symbol blk_queue_physical_block_size_fixed

[Ben Hutchings]

On Mon, 2011-01-03 at 19:36 +0200, Mikko Tuumanen wrote:
> I have the same problem when trying to install with
> 
> http://ftp.fi.debian.org/debian/dists/testing/main/installer-
> armel/current/images/kirkwood/netboot/marvell/sheevaplug/uImage
> and
> http://ftp.fi.debian.org/debian/dists/testing/main/installer-
> armel/current/images/kirkwood/netboot/marvell/sheevaplug/uInitrd
> 
> (the files are dated 28-Nov-2010 04:12)

Those are the installer kernel and initrd, which are an older version
than the kernel and modules that get installed in the filesystem.  You
then need to run flash-kernel to copy the kernel into the proper flash
partition.  (I don't know why that isn't being done automatically but
it's unlikely to be a kernel bug.)

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#606950: sd_mod: Unknown symbol blk_queue_physical_block_size_fixed

[Mikko Tuumanen]

I have the same problem when trying to install with

http://ftp.fi.debian.org/debian/dists/testing/main/installer-
armel/current/images/kirkwood/netboot/marvell/sheevaplug/uImage
and
http://ftp.fi.debian.org/debian/dists/testing/main/installer-
armel/current/images/kirkwood/netboot/marvell/sheevaplug/uInitrd

(the files are dated 28-Nov-2010 04:12)



-- 
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/201101031936.28734.mikko.tuuma...@utu.fi

Bug#597658: linux-headers-2.6.32-5-amd64: Missing aesni-intel module in kernel

[dann frazier]

On Mon, Jan 03, 2011 at 05:05:32AM +, Ben Hutchings wrote:
> On Sun, 2011-01-02 at 21:30 -0700, dann frazier wrote:
> > On Sun, Jan 02, 2011 at 08:57:19PM +, Ben Hutchings wrote:
> [...]
> > > Please can you test whether aesni-intel loads and works in:
> > > 
> > > 1. Package version 2.6.32-12
> > > .  This was the
> > > last version with aesni-intel included.
> > > 
> > > 2. Package version 2.6.32-29, modified to reenable aesni-intel.  See the
> > > instructions at
> > > .
> > > a. Follow section 4.2.1.
> > > b. Change '# CONFIG_CRYPTO_AES_NI_INTEL is not set' to
> > >'CONFIG_CRYPTO_AES_NI_INTEL=m' in
> > >debian/config/kernelarch-x86/config-arch-64.
> > > c. Follow section 4.2.4.
> > 
> > fyi, 2.6.32-12 & 2.6.32-29 w/ CONFIG_CRYPTO_AES_NI_INTEL=m both boot
> > successfully w/ the aesni_intel module on my Lenovo T410.
> 
> I'm guessing you don't have an AES-encrypted hard drive though...

I do:

$ sudo cryptsetup status sda5_crypt 
/dev/mapper/sda5_crypt is active:
  cipher:  aes-cbc-essiv:sha256
[...]

Though I don't know how to verify that the hardware implementation is
actually being used.

fwiw, the init messages do differ for me between -12 & -29 (as the git
log suggests it should):

-12:
[   13.565523] alg: No test for __aes-aesni (__driver-aes-aesni)
[   13.565542] alg: No test for __ecb-aes-aesni (__driver-ecb-aes-aesni)
[   13.565559] alg: No test for __cbc-aes-aesni (__driver-cbc-aes-aesni)
[   13.566877] alg: No test for __ecb-aes-aesni (cryptd(__driver-ecb-aes-aesni))
[   13.569514] alg: No test for __cbc-aes-aesni (cryptd(__driver-cbc-aes-aesni))

-29:
[   10.766143] alg: No test for __cbc-aes-aesni (cryptd(__driver-cbc-aes-aesni))



-- 
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/20110103171252.gb12...@dannf.org

Processed: reassign 608804 to linux-2.6

[Debian Bug Tracking System]

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

> reassign 608804 linux-2.6 2.6.32-29
Bug #608804 [linux-image-amd64] linux-image-amd64: 
/sys/class/power_supply/ACAD/online is 1 without power cable plugged in
Bug reassigned from package 'linux-image-amd64' to 'linux-2.6'.
Bug No longer marked as found in versions linux-latest-2.6/28.
Bug #608804 [linux-2.6] linux-image-amd64: /sys/class/power_supply/ACAD/online 
is 1 without power cable plugged in
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.
> thanks
Stopping processing here.

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

Bug#608804: linux-image-amd64: /sys/class/power_supply/ACAD/online is 1 without power cable plugged in

[Martin Kraus]

Package: linux-image-amd64
Version: 2.6.32+28
Severity: normal
Tags: upstream


After cold boot without power cable plugged in 
/sys/class/power_supply/ACAD/online is 1 which 
leaves on_ac_power returning wrong information for packages like 
laptop-mode-tools. 

Hardware used is Lenovo ThinkPad SL410. 

modprobe -r ac; modprobe ac 
solves this problem as does plugging the power cable in and out again.

I've tested this with vanila kernel version 2.6.37-rc5 and this problem is 
still present.


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages linux-image-amd64 depends on:
ii  linux-image-2.6.32-5-amd642.6.32-29  Linux 2.6.32 for 64-bit PCs

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110103160408.4077.60412.report...@localhost

Bug#602418: Debian Squeeze Xen with Nouveau or Radeon: Test packages

[Lionel Elie Mamane]

On Thu, Dec 23, 2010 at 02:14:13PM +, Ian Campbell wrote:

> I have put some test packages with the patches discussed further up the
> bug (less the pte_flags one as mentioned) at:
> http://xenbits.xen.org/people/ianc/2.6.32-29+xen0/

> Please could you test and let me know how you get on. In particular
> if you use Nouveau, since I only have Radeon cards to hand.

This combination works for me:

ii  firmware-linux-free  2.6.32-29+xen0 
  Binary firmware for various drivers in the Linux kernel
ii  linux-base   2.6.32-29+xen0 
  Linux image base package
ii  linux-image-2.6.32-5-xen-amd64   2.6.32-29+xen0 
  Linux 2.6.32 for 64-bit PCs, Xen dom0 support
ii  linux-libc-dev   2.6.32-26  
  Linux support headers for userspace development
ii  linux-support-2.6.32-5   2.6.32-29+xen0 
  Support files for Linux 2.6.32
ii  xen-linux-system-2.6.32-5-xen-amd64  2.6.32-29+xen0 
  Xen system with Linux 2.6.32 on 64-bit PCs (meta-package)

ii  libdrm-nouveau1  2.4.21-1~squeeze3  
  Userspace interface to nouveau-specific kernel DRM services -- 
runtime
ii  xserver-xorg-video-nouveau   
1:0.0.15+git20100329+7858345-5   X.Org X server -- Nouveau display driver 
(experimental)

ii  xorg 1:7.5+8
  X.Org X Window System
ii  xserver-xorg 1:7.5+8
  the X.Org X server
ii  xserver-xorg-core2:1.7.7-8  
  Xorg X server - core server

ii  libxenstore3.0   4.0.1-1
  Xenstore communications library for Xen
ii  xen-hypervisor-4.0-amd64 4.0.1-1
  The Xen Hypervisor on AMD64
ii  xen-qemu-dm-4.0  4.0.1-1
  Xen Qemu Device Model virtual machine hardware emulator
ii  xen-utils-4.04.0.1-1
  XEN administrative tools
ii  xen-utils-common 4.0.0-1
  XEN administrative tools - common files

01:00.0 VGA compatible controller: nVidia Corporation G84 [Quadro FX 370] (rev 
a1) (prog-if 00 [VGA controller])
Subsystem: nVidia Corporation Device 0491


-- 
Lionel



-- 
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/20110103145101.ga26...@capsaicin.mamane.lu

Bug#608278: linux-image-2.6.32-5-amd64: Random general protection faults at boot

[Andrea Spadaccini]

Hi,


This is presumably caused by a bug in rtl8187.  However, it is not a
general protection fault so there may be two different bugs here.


Yes, the GPF is around sec 30. After that bug, I blacklisted rtl8187,
and resulted in the other GPFs at boot time that are not logged.


Can you try blacklisting the radeon driver?


If I blacklist the radeon driver, I don't get any GPFs anymore.

I did 10 reboots, and no problems.

Can I help you anymore in diagnosing the problem?

Thanks,
Andrea



--
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/4d21dad4.9030...@gmail.com

Bug#608138: [PATCH v2] watchdog: Improve initialisation error message and documentation

[Don Zickus]

On Sun, Jan 02, 2011 at 11:02:42PM +, Ben Hutchings wrote:
> The error message 'NMI watchdog failed to create perf event...'  does
> not make it clear that this is a fatal error for the watchdog.  It
> also currently prints the error value as a pointer, rather than
> extracting the error code with PTR_ERR().  Fix that.
> 
> Add a note to the description of the 'nowatchdog' kernel parameter to
> associate it with this message.
> 
> Reported-by: Cesare Leonardi 
> Signed-off-by: Ben Hutchings 

Looks good, thanks.  I'll add it to my queue.

Cheers,
Don



-- 
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/20110103135602.go3...@redhat.com

Bug#587014: screen brightness can't be modified on some Panasonic laptops

[Nicolas Limare]

On Mon, Jan 03, 2011 at 10:40:03AM +0100, Thomas Renninger wrote:
> On Wednesday 29 December 2010 16:24:28 Nicolas Limare wrote:
> > I also received a message reportin for this bug on a Panasonic CF-52.
> > 
> > Can I in any way help this bug get more attention?
> > 
> What is Bug#587014? Do you have a link?

Debian bug report #587014
-> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587014

Linked to the Ubuntu bug report #588983 
-> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/588983 

Thanks a lot for your help Thomas.
I can't confirm your diagnostics, because I'm not in a position to
recompile the kernel, but hopefully these hints will help others
resolve this bug.
 
-- 
Nicolas LIMARE
http://nicolas.limare.net/ pgp:0xFA423F4F


signature.asc
Description: Digital signature

Bug#587014: screen brightness can't be modified on some Panasonic laptops

[Thomas Renninger]

On Wednesday 29 December 2010 16:24:28 Nicolas Limare wrote:
> I also received a message reportin for this bug on a Panasonic CF-52.
> 
> Can I in any way help this bug get more attention?
> 
What is Bug#587014? Do you have a link?

Panasonic is the only driver which will always try to use
native backlight switching (may conflict with video.ko?).

drivers/platform/x86/panasonic-laptop.c misses a line like:
if (acpi_video_backlight_support()

The reason panasonic was not changed to differ acpi/native
switching was because ACPI based switching resulted in 2 missing
backlight states. But this was fixed by better (more Windows compatible) 
parsing the backlight ACPI states and they should be all availeable
with ACPI as well. Len Brown has/had such a machine.

> Just in case, I am at 27C3 now, with my laptop, so if anyone there
> wants to directly investigate the issue just let me know.
No idea whether it's above, there is not much info about the issue,
but you could try in this direction. Tell me if it helps or if
you need assistance to try things out.

Ah, and there is the "global methods execution is broken":
https://bugzilla.kernel.org/show_bug.cgi?id=19462
which very much affects Panasonics.
Make sure your kernel has the git commit mentioned in the
last comment.

Thomas



-- 
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/201101031040.03797.tr...@suse.de

Bug#606964: linux-image-2.6.32-5-xen-amd64: Xen fails to boot dom0 kernel on system with, lots of RAM

[Rik Theys]

Hi,

On 12/22/2010 10:34 AM, Ian Campbell wrote:

I was wondering about clamping something in the kernel to correspond to
CONFIG_XEN_MAX_DOMAIN_MEMORY and avoid the issue but you say the crash
is after "x VCPUS" and before "Scrubbing Free RAM" so I'm surprised the
dom0 kernel has run at this point and hence changing it would not help.
The hypervisor doesn't know about this guest configuration item so there
isn't much which can be done there.

To try and confirm what is going on is there any chance you could you
collect a serial console log with verbose debugging enabled by using the
command line parameters described in "Are there more debugging options I
could enable to troubleshoot booting problems?" of
http://wiki.xensource.com/xenwiki/XenParavirtOps (without the
recommended dom0_mem).


The console log is attached.


Assuming that shows that the domain 0 kernel did actually get a chance
to run and crash I'll take a look at what else needs to be clamped to
have it just work.


From what I can see in the log, the dom0 kernel doesn't seem to get 
started.


Hope this helps.

Regards,

Rik
(XEN) Xen version 4.0.1 (Debian 4.0.1-1) (wa...@debian.org) (gcc version 4.4.5 
20100824 (prerelease) (Debian 4.4.4-11) ) Fri Sep  3 15:38:12 UTC 2010
(XEN) Console output is synchronous.
(XEN) Bootloader: GRUB 1.98+20100804-10
(XEN) Command line: placeholder loglvl=all guest_loglvl=all sync_console 
console_to_ring com1=115200,8n1 console=com1
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: none; EDID transfer time: 0 seconds
(XEN)  EDID info not retrieved because no DDC retrieval method detected
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Xen-e820 RAM map:
(XEN)   - 000a (usable)
(XEN)  0010 - bf379000 (usable)
(XEN)  bf379000 - bf38f000 (reserved)
(XEN)  bf38f000 - bf3ce000 (ACPI data)
(XEN)  bf3ce000 - c000 (reserved)
(XEN)  e000 - f000 (reserved)
(XEN)  fe00 - 0001 (reserved)
(XEN)  0001 - 00124000 (usable)
(XEN) ACPI: RSDP 000F1240, 0024 (r2 DELL  )
(XEN) ACPI: XSDT 000F1344, 009C (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: FACP BF3B3F9C, 00F4 (r3 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: DSDT BF38F000, 3D72 (r1 DELL   PE_SC3  1 INTL 20050624)
(XEN) ACPI: FACS BF3B6000, 0040
(XEN) ACPI: APIC BF3B3478, 015E (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: SPCR BF3B35D8, 0050 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: HPET BF3B362C, 0038 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: DMAR BF3B3668, 01C0 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: MCFG BF3B38C4, 003C (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: WD__ BF3B3904, 0134 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: SLIC BF3B3A3C, 0024 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: ERST BF392EF4, 0270 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: HEST BF393164, 03A8 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: BERT BF392D74, 0030 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: EINJ BF392DA4, 0150 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: SRAT BF3B3BC0, 0370 (r1 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: TCPA BF3B3F34, 0064 (r2 DELL   PE_SC3  1 DELL1)
(XEN) ACPI: SSDT BF3B7000, 6C0C (r1  INTEL PPM RCM  8001 INTL 20061109)
(XEN) System RAM: 73715MB (75484260kB)
(XEN) SRAT: PXM 1 -> APIC 32 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 0 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 34 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 2 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 36 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 4 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 48 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 16 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 50 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 18 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 52 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 20 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 33 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 1 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 35 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 3 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 37 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 5 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 49 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 17 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 51 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 19 -> Node 1
(XEN) SRAT: PXM 1 -> APIC 53 -> Node 0
(XEN) SRAT: PXM 2 -> APIC 21 -> Node 1
(XEN) SRAT: Node 1 PXM 2 0-c000
(XEN) SRAT: Node 1 PXM 2 1-94000
(XEN) SRAT: Node 0 PXM 1 94000-124000
(XEN) NUMA: Allocated memnodemap from 123fdfe000 - 123fdff000
(XEN) NUMA: Using 18 for the hash shift.
(XEN) Domain heap initialised DMA width 32 bits
(XEN) found SMP MP-table at 000fe710
(XEN) DMI 2.6 present.
(XEN) Using APIC driver default
(XEN) ACPI: PM-Timer IO Port: 0x808
(XEN) ACPI: ACPI SLEEP INFO: pm1x_cnt[804,0], pm1x_evt[80