Bug#685360: [PATCH 1/1] HID: Fix missing Unifying device issue
Josip, this is a different issue from the one addressed with the patch. 1) Can you try it on a 3.2 kernel ? 2) The problem you describe, does it happen all the time ? Thanks, Nestor. On Sun, Sep 23, 2012 at 12:23 PM, Josip Rodin j...@debbugs.entuzijast.netwrote: On Fri, Sep 21, 2012 at 12:21:34PM +0200, Nestor Lopez Casado wrote: This patch fixes an issue introduced after commit 4ea5454203d991ec After that commit, hid-core silently discards any incoming packet that arrives while any hid driver's probe function is being executed. I managed to test this now, on top of Linux 3.5, but it didn't fix my keyboard. I still get the same sequence of messages with hid.debug=1: +usb 5-2: new full-speed USB device number 3 using ohci_hcd +drivers/hid/usbhid/hid-core.c: HID probe called for ifnum 0 +drivers/hid/hid-logitech-dj.c: logi_dj_probe called for ifnum 0 +drivers/hid/hid-logitech-dj.c: logi_dj_probe: ignoring ifnum 0 +drivers/hid/usbhid/hid-core.c: HID probe called for ifnum 1 +drivers/hid/hid-logitech-dj.c: logi_dj_probe called for ifnum 1 +drivers/hid/hid-logitech-dj.c: logi_dj_probe: ignoring ifnum 1 +drivers/hid/usbhid/hid-core.c: HID probe called for ifnum 2 +drivers/hid/hid-logitech-dj.c: logi_dj_probe called for ifnum 2 +drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0110 wIndex=0x0002 wLength=7 +drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0111 wIndex=0x0002 wLength=20 +drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0120 wIndex=0x0002 wLength=15 +drivers/hid/usbhid/hid-core.c: submitting ctrl urb: Get_Report wValue=0x0121 wIndex=0x0002 wLength=32 +logitech-djreceiver 0003:046D:C52B.0005: claimed by neither input, hiddev nor hidraw +logitech-djreceiver 0003:046D:C52B.0005: logi_dj_probe:hid_hw_start returned error -- 2. That which causes joy or happiness.
Bug#684265: Still with us
On 09/24/2012 05:04 AM, Rick Thomas wrote: On Sep 13, 2012, at 2:58 PM, Rick Thomas wrote: 1) It seems likely that adding a udeb for fuse-modules will allow os-prober to identify other Linux OS root partitions and get them added to the boot-loader config file... But only as long as those partitions are not LVM partitions. I have not performed definitive experiments to verify either half of this assertion, but the evidence so far does point in that direction. When can I expect the udeb for fuse fix to be included in an upcoming daily iso? I'll be happy to test it when it's available. I tried a test installation with the following: Debian GNU/Linux testing Wheezy - Official Snapshot amd64 NETINST Binary-1 20120923-03:20 which seems to have the necessary module: $ find /mnt -name '*fuse*' -print /mnt/pool/main/f/fuse /mnt/pool/main/f/fuse/fuse-udeb_2.9.1-1_amd64.udeb /mnt/pool/main/f/fuse/libfuse2_2.9.0-2_amd64.deb /mnt/pool/main/f/fuse/libfuse2-udeb_2.9.1-1_amd64.udeb /mnt/pool/main/l/linux/fuse-modules-3.2.0-4-amd64-di_3.2.29-1_amd64.udeb However, it still doesn't find the other OS partitions... They are located in /dev/mapper/monk-root2 and /dev/mapper/monk-root3. The partition being installed to is in /dev/mapper/monk-root. I'm attaching the (gzipped) installer logs. Rick Please file a separate debian-installer bug report for problems related to finding other OS's on LVM partitions. Milan signature.asc Description: OpenPGP digital signature
Bug#679545: [RFC/PATCH v2] ia64, SR870, EFI bug breaks ata_piix, uninitialized ICH4 IDE EXBAR mem resource
Mpfff, there aren't many replies; seems I didn't satisfy what you want
to have...
At first I want to mention that I just want to help the Debian project
and started testing Debian Wheezy my old ia64 box.
Since these are my first messages on the kernel lists, I really don't
feel me in a position to tell you what's right or wrong for the Kernel
- I guess you have much more Linux Kernel knowledge than me.
The firmware left the memory BAR at 0x24 cleared (0x), but it
also left the MEM bit in the command register disabled. So it seems
like a Linux bug that we're trying to use that zero address from the
BAR. If the firmware left the MEM or IO decode enable bit cleared,
why would we assume it put anything useful in the corresponding BARs?
Your idea would be a fundamental change in the Kernel; I just want to
fix the ata_piix problem in Debian Wheezy.
I can't tell you whether the developer of the EFI thought this. Maybe
it is simply a bug.
If you would evaluate the command registers, which the BIOS or EFI has
initialized, you would work around some wrong BARs. You might run into
trouble due to wrong command register values instead.
Are you sure that any BIOS or EFI sets the command registers correctly?
Currently the Linux Kernel sets and clears the IORESOURCE_MEM and
IORESOURCE_IO bits in the command registers as needed.
Windows reconfigures any PCI device. The settings of the BIOS or EFI
do not matter at all; the user doesn't experience any BIOS bug at all.
This still isn't very generic. It only looks at BAR 5 and only for
IDE controllers, so it fixes the problem for this device and this
BIOS, but there's no reason the same problem couldn't happen on other
devices and other BARs.
My proposal was basically:
pci_read_config_word(dev, PCI_COMMAND, cmd);
for (i = 0; i 6; i++) {
/* read BAR i here */
r = dev-resource[i];
if (((r-flags IORESOURCE_MEM) (cmd PCI_COMMAND_MEMORY)) ||
((r-flags IORESOURCE_IO) (cmd PCI_COMMAND_IO))) {
/* treat resource as valid */
} else {
/* treat resource as unassigned; try to assign it later */
}
}
Both of my two patches hide the BAR5 when we know that BAR5 is not functional.
The first patch makes sure that the PCI device id matches; the second
one checks whether it is an ide controller in legacy mode. The
associated ide/piix or ata/ata_piix doesn't need the BAR5 memory
resource at all.
The other BARs are functional and needed.
I don't know what regression can occur when you hide *any*
uninitialized BAR of *any* pci device. Some drivers might be screwed
up when a needed mem resource is absend - after pci_enable_device() or
pcim_enable_device() returned success.
Ben Hutchings of the Debian project pointed to some interesting detail
about ide/piix:
By the way, the reason the old IDE driver worked is that
drivers/ide/setup-pci.c has a fallback for this:
if (pci_enable_device(dev)) {
ret = pci_enable_device_io(dev);
It was added almost exactly 10 years ago without any specific comment.
Debian had both ide/piix and ata/ata_piix in the past. When ata_piix
didn't initialize, ide/piix took over the device. The user didn't
experience any problem.
The old ide/piix has been removed with recent Debian versions (due to
problems with shared interrupts). Thus, the ICH4 problem is on the
table again.
Since you don't want to take my patches, I need some new ideas. The
patch shouldn't be a fundamental, experimental change with the risk of
regression because it is intended for a *stable* Debian release.
Suggestions or comments are appreciated.
Stephan
--
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/20120924190912.horde.qznuiqgzi1vqyjo46heg...@webmail.df.eu
Re: Squeeze point release (6.0.6)
On Mon, 2012-09-24 at 09:01 +0900, dann frazier wrote: On Sun, Sep 23, 2012 at 05:39:21PM +0100, Adam D. Barratt wrote: Thanks for the upload; the builds seem to be going well. There don't seem to be any new d-i changes in git, so I assume we just need lkdi, a round of d-i binNMUs and then a d-i-n-i upload? afaik, that's correct. Cool; thanks. All of the kernel builds are (finally) in now; would you have time to take care of the lkdi uploads? Cheers, Adam -- 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/1348523640.6724.21.ca...@jacala.jungle.funky-badger.org
Processed: Re: [3.4.4 - 3.5 regression] fails to find root device (Unable to find LVM volume data/root)
Processing commands for cont...@bugs.debian.org: found 688711 linux/3.5-1~experimental.1 Bug #688711 [src:linux] [3.4.4 - 3.5 regression] fails to find root device (Unable to find LVM volume data/root) Marked as found in versions linux/3.5-1~experimental.1. End of message, stopping processing here. Please contact me if you need assistance. -- 688711: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688711 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.134852795524979.transcr...@bugs.debian.org
Bug#567591: marked as done (linux-image-2.6.32-trunk-amd64: kernel package should conflict with lvm2 package from Lenny)
Your message dated Mon, 24 Sep 2012 16:08:56 -0700 with message-id 20120924230856.GA30488@elie.Belkin and subject line Re: [squeeze] kernel package should conflict with lvm2 package from Lenny has caused the Debian Bug report #567591, regarding linux-image-2.6.32-trunk-amd64: kernel package should conflict with lvm2 package from Lenny 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.) -- 567591: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567591 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: linux-image-2.6.32-trunk-amd64 Version: 2.6.32-5 Severity: normal I have just done an upgrade from Lenny to Testing. When I ran apt-get dist-upgrade it aborted because it tried to upgrade udev first and the kernel wasn't new enough. So I ran apt-get install linux-image-2.6.32-trunk-amd64 which worked but then it didn't recognise the LVM volumes. I had to run apt-get install lvm2 to get newer lvm modules to allow the kernel to mount an LVM based root filesystem. It seems that either the newer kernel packages should conflict with old versions of LVM, or the kernel should just work with the older LVM utilities. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (700, 'stable'), (500, 'lenny-backports'), (350, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686 (SMP w/1 CPU core) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash ---End Message--- ---BeginMessage--- Hi, In January, 2010, Russell Coker wrote: On Sat, 30 Jan 2010, Ben Hutchings b...@decadent.org.uk wrote: When I ran apt-get dist-upgrade it aborted because it tried to upgrade udev first and the kernel wasn't new enough. So I ran apt-get install linux-image-2.6.32-trunk-amd64 which worked but then it didn't recognise the LVM volumes. I had to run apt-get install lvm2 to get newer lvm modules to allow the kernel to mount an LVM based root filesystem. I wasn't aware of this problem. What is the failure mode? It just doesn't find the LVs. Sorry I didn't take better notes. Closing because I do not see us getting closer to understanding and fixing this one, but I'd be happy to revisit it if you run into it again (the lenny - squeeze upgrade path is still supported). Thanks, Jonathan---End Message---
Bug#679545: [RFC/PATCH v2] ia64, SR870, EFI bug breaks ata_piix, uninitialized ICH4 IDE EXBAR mem resource
On Mon, Sep 24, 2012 at 07:09:12PM +0200, Stephan Schreiber wrote:
Mpfff, there aren't many replies; seems I didn't satisfy what you
want to have...
At first I want to mention that I just want to help the Debian
project and started testing Debian Wheezy my old ia64 box.
Thanks, I really appreciate that, and you've done a huge amount of
debugging and testing already. It's very normal to iterate on the
resolution as we're doing now.
The firmware left the memory BAR at 0x24 cleared (0x), but it
also left the MEM bit in the command register disabled. So it seems
like a Linux bug that we're trying to use that zero address from the
BAR. If the firmware left the MEM or IO decode enable bit cleared,
why would we assume it put anything useful in the corresponding BARs?
Your idea would be a fundamental change in the Kernel; I just want
to fix the ata_piix problem in Debian Wheezy.
Right. I think you've tripped over a rather fundamental issue, and
I'm hoping we can fix that. If we can, that will help many users,
not just the handful who have this ia64 box.
If you would evaluate the command registers, which the BIOS or EFI
has initialized, you would work around some wrong BARs. You might
run into trouble due to wrong command register values instead.
Are you sure that any BIOS or EFI sets the command registers correctly?
We can't be 100% sure about things like that, of course. But we do
know that if the MEM or IO bits are set in the command register, the
device will claim transactions that match whatever is in the BARs.
So setting the MEM or IO bit is a pretty strong statement that the
BAR contains a valid address. If the BIOS leaves those bits clear,
we really can't conclude anything about the BAR contents.
Currently the Linux Kernel sets and clears the IORESOURCE_MEM and
IORESOURCE_IO bits in the command registers as needed.
Windows reconfigures any PCI device. The settings of the BIOS or EFI
do not matter at all; the user doesn't experience any BIOS bug at
all.
On x86, Windows normally doesn't reconfigure PCI devices unless it
finds a problem with the configuration done by the BIOS. I suspect
it works similarly on ia64. I would guess that Windows noticed that
the MEM bit was not set, and therefore ignored the MEM BAR contents.
Can you try the following patch? It's based on 3.6-rc5+, but I think
it will apply to your 3.2.23 kernel with minor conflicts that shouldn't
be too hard to resolve.
It's not quite right because we really shouldn't turn on the MEM or IO
decode bit unless *all* of the corresponding BARs have been set, but
in your case, I think there is only one MEM BAR that is an issue.
Bjorn
commit 9038dd3b3c4c9e4c7ca0118c8df398c4c646ab58
Author: Bjorn Helgaas bhelg...@google.com
Date: Mon Sep 24 17:16:28 2012 -0600
vsprintf: Add support for IORESOURCE_UNSET in %pR
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 0e33754..b6c 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -600,7 +600,7 @@ char *resource_string(char *buf, char *end, struct resource
*res,
* 64-bit res (sizeof==8): 20 chars in dec, 18 in hex (0x + 16) */
#define RSRC_BUF_SIZE ((2 * sizeof(resource_size_t)) + 4)
#define FLAG_BUF_SIZE (2 * sizeof(res-flags))
-#define DECODED_BUF_SIZE sizeof([mem - 64bit pref window disabled])
+#define DECODED_BUF_SIZE sizeof([mem - 64bit pref window unset
disabled])
#define RAW_BUF_SIZE sizeof([mem - flags 0x])
char sym[max(2*RSRC_BUF_SIZE + DECODED_BUF_SIZE,
2*RSRC_BUF_SIZE + FLAG_BUF_SIZE + RAW_BUF_SIZE)];
@@ -642,6 +642,8 @@ char *resource_string(char *buf, char *end, struct resource
*res,
p = string(p, pend, pref, str_spec);
if (res-flags IORESOURCE_WINDOW)
p = string(p, pend, window, str_spec);
+ if (res-flags IORESOURCE_UNSET)
+ p = string(p, pend, unset, str_spec);
if (res-flags IORESOURCE_DISABLED)
p = string(p, pend, disabled, str_spec);
} else {
commit f4795a79dc370b6f4106768b16a4a9edba4df933
Author: Bjorn Helgaas bhelg...@google.com
Date: Mon Sep 24 17:15:30 2012 -0600
PCI: Ignore BAR contents when firmware left decoding disabled
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 2396111..6926dcb 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -175,9 +175,10 @@ int __pci_read_base(struct pci_dev *dev, enum pci_bar_type
type,
mask = type ? PCI_ROM_ADDRESS_MASK : ~0;
+ pci_read_config_word(dev, PCI_COMMAND, orig_cmd);
+
/* No printks while decoding is disabled! */
if (!dev-mmio_always_on) {
- pci_read_config_word(dev, PCI_COMMAND, orig_cmd);
pci_write_config_word(dev, PCI_COMMAND,
orig_cmd ~(PCI_COMMAND_MEMORY | PCI_COMMAND_IO));
}
@@ -211,9 +212,13 @@ int
Bug#688711: [3.4.4 - 3.5 regression] fails to find root device (Unable to find LVM volume data/root)
Jonathan Nieder wrote: [ 1.949115] sda: sda1 sda2 sda3 sda5 [ 1.949751] sd 0:0:0:0: [sda] Attached SCSI disk Volume group data not found [...] Bisects to v3.5-rc1~164 [...] I'm retesting its second and first parent now. Both parents test ok, so looks like something bad happened during that merge. Next step is to linearize it, unless someone has a nicer idea. -- 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/20120925000723.GA2916@elie.Belkin
Re: Squeeze point release (6.0.6)
On Mon, Sep 24, 2012 at 10:54:00PM +0100, Adam D. Barratt wrote: On Mon, 2012-09-24 at 09:01 +0900, dann frazier wrote: On Sun, Sep 23, 2012 at 05:39:21PM +0100, Adam D. Barratt wrote: Thanks for the upload; the builds seem to be going well. There don't seem to be any new d-i changes in git, so I assume we just need lkdi, a round of d-i binNMUs and then a d-i-n-i upload? afaik, that's correct. Cool; thanks. All of the kernel builds are (finally) in now; would you have time to take care of the lkdi uploads? Yep, should after work today. -- 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/20120925002142.ga26...@dannf.org
Bug#684265: Still with us
On Sep 24, 2012, at 6:26 AM, Milan Kupcevic wrote: Please file a separate debian-installer bug report for problems related to finding other OS's on LVM partitions. Milan Well... I tried it on a machine that was not using LVM, and got the same results. So the bug isn't fixed yet. Rick -- 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/803060d4-01ca-410d-b797-10ebe8216...@pobox.com
[PATCH kernel-wedge 0/3]
I'm intending to commit the following changes and upload a new version
of kernel-wedge. Let me know if you see any problems with them.
Ben.
Ben Hutchings (3):
gen-deps: Ignore default dependencies that are overridden
per-architecture
List the unpackaged modules
install-files: Include modules.{builtin,order} in Linux kernel-image
udebs
commands/find-unpackaged | 35 +++
commands/find-unpackaged.txt |5 +
commands/gen-deps|4
commands/install-files | 32 +++-
debian/changelog | 10 ++
5 files changed, 77 insertions(+), 9 deletions(-)
create mode 100755 commands/find-unpackaged
create mode 100644 commands/find-unpackaged.txt
signature.asc
Description: Digital signature
[PATCH 1/3] gen-deps: Ignore default dependencies that are overridden per-architecture
Ignore dependencies in default package-list that are overridden by the
architecture package-list, consistent with gen-control (Closes: #678587)
The previous behaviour masked incomplete dependency lists for some of
the Linux udebs.
---
The incomplete dependencies were fixed in linux 3.2.21-2, so this
should have no immediate effect on Linux. However it is possible that
kFreeBSD has the same problem and would fail to build after this.
Ben.
commands/gen-deps |4
debian/changelog |7 +++
2 files changed, 11 insertions(+)
diff --git a/commands/gen-deps b/commands/gen-deps
index c637375..f596c4c 100755
--- a/commands/gen-deps
+++ b/commands/gen-deps
@@ -39,6 +39,10 @@ sub read_package_list
$modlistdir = $configdir/modules/$arch;
}
next unless -e $modlistdir/$package;
+
+ # Override previously defined dependencies
+ @out = grep(!/^$package\t/, @out);
+
foreach my $dep (@depends) {
# Skip depends that are not built for this
# architecture.
diff --git a/debian/changelog b/debian/changelog
index fece32d..6bebe43 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+kernel-wedge (2.85) UNRELEASED; urgency=low
+
+ * gen-deps: Ignore dependencies in default package-list that are
+overridden by the architecture package-list (Closes: #678587)
+
+ -- Ben Hutchings b...@decadent.org.uk Sun, 24 Jun 2012 19:34:25 +0100
+
kernel-wedge (2.84) unstable; urgency=low
[ Joey Hess ]
signature.asc
Description: Digital signature
[PATCH 2/3] List the unpackaged modules
find-unpackaged: New sub-command lists modules not packaged in a udeb
install-files: Call find-unpackaged
---
I hope this information will help us to update the module lists. At
some point I would like to add the ability to include modules by
subdirectory, though.
Ben.
commands/find-unpackaged | 35 +++
commands/find-unpackaged.txt |5 +
commands/install-files |1 +
debian/changelog |2 ++
4 files changed, 43 insertions(+)
create mode 100755 commands/find-unpackaged
create mode 100644 commands/find-unpackaged.txt
diff --git a/commands/find-unpackaged b/commands/find-unpackaged
new file mode 100755
index 000..a7bcf6d
--- /dev/null
+++ b/commands/find-unpackaged
@@ -0,0 +1,35 @@
+#!/usr/bin/perl
+# Find unpackaged modules. Pass the kernel name and installed name
+# (normally the same).
+use strict;
+use warnings;
+use File::Find ();
+use File::Spec;
+
+my $kernel = $ARGV[0];
+my $installedname = $ARGV[1];
+
+my $moddir = /lib/modules/$installedname;
+my $sourcedir = $ENV{SOURCEDIR} || '';
+
+my %unpackaged;
+my $dir = $sourcedir$moddir;
+File::Find::find(
+sub {
+ $unpackaged{File::Spec-abs2rel($File::Find::name, $dir)} = 1
+ if /\.k?o$/;
+},
+$dir);
+for my $dir (glob(debian/*-modules-$kernel-di$moddir)) {
+File::Find::find(
+ sub {
+ delete $unpackaged{File::Spec-abs2rel($File::Find::name, $dir)}
+ if /\.k?o$/;
+ },
+ $dir);
+}
+
+print These modules from $kernel are unpackaged:\n;
+for my $path (sort(keys(%unpackaged))) {
+print \t\t$path\n;
+}
diff --git a/commands/find-unpackaged.txt b/commands/find-unpackaged.txt
new file mode 100644
index 000..5aae086
--- /dev/null
+++ b/commands/find-unpackaged.txt
@@ -0,0 +1,5 @@
+find-unpackaged kernel-name
+
+List modules that are not packaged in a udeb. Pass the kernel name.
+
+Always return 0.
diff --git a/commands/install-files b/commands/install-files
index 039a812..2241b1b 100755
--- a/commands/install-files
+++ b/commands/install-files
@@ -129,6 +129,7 @@ while (KVERS) {
doit(kernel-wedge, copy-modules, $kernelversion, $flavour,
$installedname);
doit(kernel-wedge, find-dups, $kernelversion-$flavour);
+ doit(kernel-wedge, find-unpackaged, $kernelversion-$flavour,
$installedname);
doit(kernel-wedge, strip-modules, $kernelversion-$flavour);
}
close KVERS;
diff --git a/debian/changelog b/debian/changelog
index 6bebe43..1959853 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,8 @@ kernel-wedge (2.85) UNRELEASED; urgency=low
* gen-deps: Ignore dependencies in default package-list that are
overridden by the architecture package-list (Closes: #678587)
+ * find-unpackaged: New sub-command lists modules not packaged in a udeb
+ * install-files: Call find-unpackaged
-- Ben Hutchings b...@decadent.org.uk Sun, 24 Jun 2012 19:34:25 +0100
signature.asc
Description: Digital signature
[PATCH 3/3] install-files: Include modules.{builtin,order} in Linux kernel-image udebs
---
libkmod expects these files to be present. However they are not
being installed in the s390 tape image packages, so this probably
should be made conditional. That might be a bug in the linux package
though. Bastian?
Ben.
commands/install-files | 31 ++-
debian/changelog |1 +
2 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/commands/install-files b/commands/install-files
index 2241b1b..eddd5d2 100755
--- a/commands/install-files
+++ b/commands/install-files
@@ -11,6 +11,8 @@ sub doit {
my $hostarch=`dpkg-architecture -qDEB_HOST_ARCH`;
chomp $hostarch;
+my $hostos=`dpkg-architecture -qDEB_HOST_ARCH_OS`;
+chomp $hostos;
my $configdir = ($ENV{KW_CONFIG_DIR} || '.');
my $fixsourcedir = $ENV{SOURCEDIR};
@@ -84,15 +86,26 @@ while (KVERS) {
if (! -e $modlistdir/kernel-image) {
# copy no kernel
}
- elsif (-e $sourcedir/boot/vmlinux-$installedname) {
- doit(install, -D, -m, 644,
- $sourcedir/boot/vmlinux-$installedname,
-
debian/kernel-image-$kernelversion-$flavour-di/boot/vmlinux$extraname);
- }
- elsif (-e $sourcedir/boot/vmlinuz-$installedname) {
- doit(install, -D, -m, 644,
- $sourcedir/boot/vmlinuz-$installedname,
-
debian/kernel-image-$kernelversion-$flavour-di/boot/vmlinuz$extraname);
+ elsif ($hostos eq 'linux') {
+ if (-e $sourcedir/boot/vmlinux-$installedname) {
+ doit(install, -D, -m, 644,
+$sourcedir/boot/vmlinux-$installedname,
+
debian/kernel-image-$kernelversion-$flavour-di/boot/vmlinux$extraname);
+ }
+ elsif (-e $sourcedir/boot/vmlinuz-$installedname) {
+ doit(install, -D, -m, 644,
+$sourcedir/boot/vmlinuz-$installedname,
+
debian/kernel-image-$kernelversion-$flavour-di/boot/vmlinuz$extraname);
+ }
+ else {
+ die could not find kernel image;
+ }
+ doit(install, -d,
+
debian/kernel-image-$kernelversion-$flavour-di/lib/modules/$installedname/);
+ doit(install, -m, 644,
+$sourcedir/lib/modules/$installedname/modules.builtin,
+$sourcedir/lib/modules/$installedname/modules.order,
+
debian/kernel-image-$kernelversion-$flavour-di/lib/modules/$installedname/);
}
elsif (-e $sourcedir/boot/kfreebsd-$installedname.gz) {
doit(install, -D, -m, 644,
diff --git a/debian/changelog b/debian/changelog
index 1959853..3fb4257 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,7 @@ kernel-wedge (2.85) UNRELEASED; urgency=low
overridden by the architecture package-list (Closes: #678587)
* find-unpackaged: New sub-command lists modules not packaged in a udeb
* install-files: Call find-unpackaged
+ * install-files: Include modules.{builtin,order} in Linux kernel-image udebs
-- Ben Hutchings b...@decadent.org.uk Sun, 24 Jun 2012 19:34:25 +0100
signature.asc
Description: Digital signature
Bug#686939: linux-image-3.2.0-3-686-pae: fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
On 2012/9/19 上午 11:46, Ben Hutchings wrote: Does /etc/modprobe.d/i915-kms.conf exist in the live system? I put /etc/modprobe.d/i915-kms.conf in the live CD filesystem.squashfs, with its contents: options i915 modeset=1 and even when I put nomodeset vga=788 in the boot parameters, now the live system would enter KMS mode directly. On the other hand, I added nomodeset vga=788 i915.blacklist=yes in the boot parameter, and apparently it entered framebuffer mode 800x600. So my question is, how can I let Debian Sid honor nomodeset vga=788 without i915.blacklist=yes in the boot parameter and without /etc/modprobe.d/i915-kms.conf inside the live system? Steven. -- Steven Shiau steven _at_ nchc org tw steven _at_ stevenshiau org National Center for High-performance Computing, Taiwan. http://www.nchc.org.tw Public Key Server PGP Key ID: 1024D/9762755A Fingerprint: A2A1 08B7 C22C 3D06 34DB F4BC 08B3 E3D7 9762 755A -- 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/5061160b.5020...@nchc.org.tw
