Bug#618006: [PATCH 2.6.32.y] Input: bcm5974 - add support for MacBookPro8
Jonathan Nieder jrnie...@gmail.com wrote: Hi, The attached commit, taken from Dmitry Torokhov's input tree, adds input support for the MacBookPro8,* released in March 2011. Only build tested. Julien: have you tested[2] that the patch works correctly on top of v2.6.32.y? No; IIRC I was made aware of the patches with the mention that they do work, and then they went upstream. I went fishing for the patches on request from the kernel team. This patch only adds IDs to the drivers, there's no reason why it wouldn't work if it applies. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: FA1E 5292 GPG Fingerprint : CC1A 2FE4 76FE 444A CD23 A5CD 26E9 8AEA FA1E 5292 -- 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/8739ha35q6@sonic.technologeek.org
Bug#618006: [PATCH 2.6.32.y] Input: bcm5974 - add support for MacBookPro8
Jonathan Nieder jrnie...@gmail.com wrote: This patch only adds IDs to the drivers, there's no reason why it wouldn't work if it applies. Do you have (or know anyone who has) hardware to test? Of course the patch only enables the driver on that hardware, which is what it would be useful to test. :) Andy has the hardware, or at least had access to the hardware back then. I have the hardware too now, but I don't have time to run the tests. Plus, it's really wasted time for this patch as far as I remember. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: FA1E 5292 GPG Fingerprint : CC1A 2FE4 76FE 444A CD23 A5CD 26E9 8AEA FA1E 5292 -- 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/87y5z21plc@sonic.technologeek.org
Bug#605083: linux-2.6: MacBookAir3,* support: USB fixes
Ben Hutchings b...@decadent.org.uk wrote: Hi Ben, USB: ehci: disable LPM and PPCD for nVidia MCP89 chips I'll look at backporting this to squeeze as well. It appears that it is not needed in squeeze because these features were not used by the ehci driver in 2.6.32. Thanks for tracking this. There are HID patches for the new MacBook Pro, I'll file a wishlist for that later. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vczn1jp6@sonic.technologeek.org
Bug#618006: Input support for MacBookPro8,*
Source: linux-2.6
Version: 2.6.32-30
Severity: wishlist
Tags: patch
Hi,
The attached commit, taken from Dmitry Torokhov's input tree, adds
input support for the MacBookPro8,* released in March 2011.
Ideally the patch should be applied to both 2.6.32 in Squeeze and
2.6.37/2.6.38 in Sid. It may need some backporting work for 2.6.32 for
the trackpad part, not sure about that, shouldn't be anything major,
though.
Thanks,
JB.
--
Julien BLACHE jbla...@debian.org | Debian, because code matters more
Debian GNU/Linux Developer| http://www.debian.org
Public key available on http://www.jblache.org - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
From 47340bd9fefb57136da942b5aee0e85e959c Mon Sep 17 00:00:00 2001
From: Andy Botting a...@andybotting.com
Date: Sat, 12 Mar 2011 20:27:22 -0800
Subject: [PATCH] Input: bcm5974 - add support for MacBookPro8
This patch add multitouch support for the MacBookPro8,1 and
MacBookPro8,2 models.
Cc: sta...@kernel.org
Signed-off-by: Andy Botting a...@andybotting.com
Signed-off-by: Henrik Rydberg rydb...@euromail.se
Acked-by: Jiri Kosina jkos...@suse.cz
Signed-off-by: Dmitry Torokhov d...@mail.ru
---
drivers/hid/hid-apple.c |6 ++
drivers/hid/hid-core.c|6 ++
drivers/hid/hid-ids.h |3 +++
drivers/input/mouse/bcm5974.c | 20
4 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 61aa712..b85744f 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -481,6 +481,12 @@ static const struct hid_device_id apple_devices[] = {
.driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4A_JIS),
.driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING5_ANSI),
+ .driver_data = APPLE_HAS_FN },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING5_ISO),
+ .driver_data = APPLE_HAS_FN | APPLE_ISO_KEYBOARD },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING5_JIS),
+ .driver_data = APPLE_HAS_FN | APPLE_RDESC_JIS },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI),
.driver_data = APPLE_NUMLOCK_EMULATION | APPLE_HAS_FN },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO),
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index d678cf3..48a0a2f 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1302,6 +1302,9 @@ static const struct hid_device_id hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4A_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4A_ISO) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4A_JIS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING5_ANSI) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING5_ISO) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING5_JIS) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS) },
@@ -1801,6 +1804,9 @@ static const struct hid_device_id hid_mouse_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4A_ANSI) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4A_ISO) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING4A_JIS) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING5_ANSI) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING5_ISO) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_WELLSPRING5_JIS) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_FOUNTAIN_TP_ONLY) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_GEYSER1_TP_ONLY) },
{ }
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 92a0d61..ca32ecb 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -103,6 +103,9 @@
#define USB_DEVICE_ID_APPLE_WELLSPRING4A_ANSI 0x0242
#define USB_DEVICE_ID_APPLE_WELLSPRING4A_ISO 0x0243
#define USB_DEVICE_ID_APPLE_WELLSPRING4A_JIS 0x0244
+#define USB_DEVICE_ID_APPLE_WELLSPRING5_ANSI 0x0245
+#define USB_DEVICE_ID_APPLE_WELLSPRING5_ISO 0x0246
+#define USB_DEVICE_ID_APPLE_WELLSPRING5_JIS 0x0247
#define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ANSI 0x0239
#define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_ISO 0x023a
#define USB_DEVICE_ID_APPLE_ALU_WIRELESS_2009_JIS 0x023b
diff --git a/drivers/input/mouse/bcm5974.c b/drivers/input/mouse/bcm5974.c
index ee82851..3185314 100644
Bug#615888: Please add USB HID quirk for Cypress barcode scanner
Source: linux-2.6
Version: 2.6.32-30
Severity: wishlist
Tags: patch
Hi,
The attached patch, commit e8d0eab4d9eda9f5e97852f780f020bfb134f9f0 from
upstream, adds support for a Cypress chip commonly used in a number of
barcode scanners.
Without this patch, the devices are rejected by the USB layer due to a
bug in their USB descriptors and can't be used at all.
Patch applies as is to 2.6.32 and is attached below for convenience.
Please apply,
JB.
--
Julien BLACHE jbla...@debian.org | Debian, because code matters more
Debian GNU/Linux Developer| http://www.debian.org
Public key available on http://www.jblache.org - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
commit e8d0eab4d9eda9f5e97852f780f020bfb134f9f0
Author: Jiri Kosina jkos...@suse.cz
Date: Wed Dec 2 22:54:11 2009 +0100
HID: add support for Acan FG-8100 barcode reader
Acan FG-8100 barcode reader (0x04b4/0xbca1) has vendor ID of
cypress and requires the same MIN/MAX swap descriptor quirk
as other barcode readers from cypress.
Reported-by: Stijn Ghesquiere st...@applesnail.net
Signed-off-by: Jiri Kosina jkos...@suse.cz
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 7d05c4b..e2e8741 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1294,6 +1294,7 @@ static const struct hid_device_id hid_blacklist[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_CHICONY, USB_DEVICE_ID_CHICONY_TACTICAL_PAD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_2) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_MOUSE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, 0x0006) },
{ HID_USB_DEVICE(USB_VENDOR_ID_EZKEY, USB_DEVICE_ID_BTC_8193) },
diff --git a/drivers/hid/hid-cypress.c b/drivers/hid/hid-cypress.c
index 62e9cb1..998b6f4 100644
--- a/drivers/hid/hid-cypress.c
+++ b/drivers/hid/hid-cypress.c
@@ -126,6 +126,8 @@ static const struct hid_device_id cp_devices[] = {
.driver_data = CP_RDESC_SWAPPED_MIN_MAX },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_2),
.driver_data = CP_RDESC_SWAPPED_MIN_MAX },
+ { HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_BARCODE_3),
+ .driver_data = CP_RDESC_SWAPPED_MIN_MAX },
{ HID_USB_DEVICE(USB_VENDOR_ID_CYPRESS, USB_DEVICE_ID_CYPRESS_MOUSE),
.driver_data = CP_2WHEEL_MOUSE_HACK },
{ }
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index adbef5d..656c015 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -145,6 +145,7 @@
#define USB_DEVICE_ID_CYPRESS_ULTRAMOUSE 0x7417
#define USB_DEVICE_ID_CYPRESS_BARCODE_1 0xde61
#define USB_DEVICE_ID_CYPRESS_BARCODE_2 0xde64
+#define USB_DEVICE_ID_CYPRESS_BARCODE_3 0xbca1
#define USB_VENDOR_ID_DEALEXTREAME 0x10c5
#define USB_DEVICE_ID_DEALEXTREAME_RADIO_SI4701 0x819a
Re: Bug#607368: Please decide how kernel ABI should be managed
Don Armstrong d...@debian.org wrote: Hi, Ok. My main concern here is what exactly would happen if we were to ignore the ABI change for this particular issue, and then put in place some kind of a process where the kernel team could be informed of downstream users of the ABI. The harm is done now, reverting or bumping the ABI at this point only makes things worse. Full deployment involves over a thousand workstations. But presumably they're not running a testing version affected by this. At this time I have no assurance that this issue or a similar issue with another symbol won't happen again during the Squeeze lifetime, so they are potentially affected until proven otherwise as far as I'm concerned. To the thousand machines given above, you can add several hundred machines part of several HPC clusters; the nodes use external InfiniBand drivers from ofa-kernel 1.5.2 in the pkg-ofed repository. Having the cluster fail to come online after a kernel upgrade would be interesting. We also have servers using the Brocade FC HBA/CNA drivers from Brocade, due to the 2.6.32 drivers being way out of date (2.6.32-2.6.37 is ca. 100 commits and needs new firmware files with new names, if anyone is interested). package is upgraded, we'd still have issues with on-disk modules not matching the running kernel ABI until the machine is rebooted. This can sometimes take two or three weeks if a long-running computation is running on the machine. Presumably this wouldn't be much of an issue, unless users are going to be newly loading these modules. [Which I would hope wouldn't be the case if you were running a long-running computation.] Modules get loaded automatically pretty much all the time on a workstation: filesystem modules for a USB key or when upgrading grub, drivers for USB devices, you name it. And I'll ask again: what's the point of the kernel ABI number if we have to use strict dependencies? Some modules may need strict dependencies if they are using symbols not covered by the ABI; this is one possible way that we can resolve this issue. The issue I have with that, other than the fact that it is just plain wrong, is that all the module packaging tools were built on the premise that changes to the kernel ABI are reflected by the ABI number. None of the tools work if that premise doesn't hold true. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871v4rwpv1@sonic.technologeek.org
Re: Bug#607368: Please decide how kernel ABI should be managed
Don Armstrong d...@debian.org wrote: Hi, 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. You are correct. 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 I have 30 beta-testers that are affected by this issue on the workstations they have started using for their everyday work. Although it's still a beta phase, at this point, these workstations are to be considered in production given the users have basically made the switch now. Full deployment involves over a thousand workstations. worked around by using DKMS or similar with prebuilt binaries and requiring exact kernel version dependencies? DKMS is useless if the ABI number doesn't change, in its current form. If DKMS was changed to rebuild all modules when the kernel package is upgraded, we'd still have issues with on-disk modules not matching the running kernel ABI until the machine is rebooted. This can sometimes take two or three weeks if a long-running computation is running on the machine. We switched to DKMS to reduce the maintenance cost associated with prebuilt binaries. We'd rather not come back to that if we can help it. It also adds a delay to kernel updates that we'd rather avoid. As to using strict dependencies... it makes all of the above even worse. And I'll ask again: what's the point of the kernel ABI number if we have to use strict dependencies? Seriously? We need a kernel ABI numbering we can rely on. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87oc7wgb6x@sonic.technologeek.org
Bug#607368: Kernel ABI management
Ben Hutchings b...@decadent.org.uk wrote: Hi, Good luck with that, it's been tried already with EXPORT_SYMBOL_GPL() and people still do work around that. That is probably copyright infringement. Maybe, maybe not. Nobody actually really knows. It sounds like you should really be using ESX/vSphere on the host, rather than VMware Server on Debian. I mean, VMware Server is basically demo-ware. That's VMware Player/Workstation running on workstations, not servers, actually. So no, we don't need ESX/vSphere. Where are your bug reports on nouveau? I don't think there is any value in reporting that an nVidia card that was released last month doesn't work with nouveau. I think the nouveau folks do know it's not supported without me telling them. Binary-only drivers for Linux are generally copyright infringements. If Says you. Again, nobody really knows. Some may very well be infringing copyrights, sure. we break them: good. (I know nvidia provides a Linux-specific stub as source and it might be an exception to this.) You can be assured that I share your feelings towards binary-only drivers. I'm pretty disappointed by the way you're handling this; it feels like you have little care for what your users actually need. We do, just not all of what *you* (one of our users) want. Yeah, I'm probably the only Debian folk out there that has to support a thousand workstations with VMware. We should definitely move to RedHat, or something. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871v5e14kx@sonic.technologeek.org
Bug#607368: closed by maximilian attems m...@stro.at (Re: Bug#607368: Kernel ABI management)
ow...@bugs.debian.org (Debian Bug Tracking System) wrote: We never supported oot binary crap, nor do we intend to do. closing, as you already got all the explanations. For the record, VMware modules come as source. JB. -- Julien BLACHE - Debian GNU/Linux Developer - jbla...@debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wrn6yu4w@sonic.technologeek.org
Bug#607368: Please decide how kernel ABI should be managed
reopen 607368 tags 607368 - wontfix reassign 607368 tech-ctte retitle 607368 Please decide how kernel ABI should be managed thanks Hi, I am hereby asking the tech-ctte to decide how the kernel ABI should be managed. Case in point: the kernel team decided to ignore changes to the smp_ops symbol in 2.6.32-28 which broke external modules (vmware) without any prior warning. I am worried that this is going to happen again during the lifetime of Squeeze, silently breaking working setups upon reboot after a kernel update, even though the new kernel carries the same ABI number as the previous one. I do agree that it is fine to ignore changes to symbols that are only exported and used inside a self-contained group of modules to which no additional modules will ever need to be added. I disagree with the kernel team's take that it is OK for them to ignore symbol changes in all other cases, especially for symbols exported by the core kernel (like smp_ops). This kind of silent breakage is a nightmare from an ops standpoint and it does have a cost for our users. The ABI number should guarantee that upgrading from a revision of linux-image to another carrying the same ABI number will not cause any breakage with external modules built for this ABI. As the kernel team made it clear that they make their decision partly based on symbol usage, I'd like to highlight once again, for the specific case of smp_ops, that VMware modules aren't exactly pet modules that only a few of our users care about. There is ample proof of this on several web forums and mailing-lists dedicated to either VMware or Debian. I am seeking a generic ruling by the tech-ctte to ensure that the kernel ABI number remains meaningful and dependable. I think it would be best if this matter would be decided upon before the release of Squeeze, or not too long after it, so as to avoid further breakages in early kernel updates for Squeeze. Thanks, JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zks1ty1p@sonic.technologeek.org
Bug#607368: Kernel ABI management
reopen 607368 submitter 607368 ! thanks Hi, I am sorry that I have to reopen this bug, but first this is about more than just smp_ops and second the outcome isn't satisfactory. Whether a symbol is exported for a specific purpose or for general usage, whether you like it or not, every symbol that is exported is part of the ABI. If it changes, the ABI changes and it changes for everybody, regardless of whether they're supposed to be using that symbol or not. We would not accept that behaviour from a shared library, I don't see any reason why we would accept it from the kernel. As it stands, the kernel ABI number has just been rendered useless; I can no longer trust it nor rely on it. Every kernel revision will have to be tested to make sure all modules are still compatible with the new ABI, given the ABI will change silently without bumping the ABI number. Unsuspecting users will have their setup break upon reboot after updating their kernel packages without any obvious clue as to what caused the breakage. This is a big deal as it puts a big question mark where the kernel ABI number used to be. This is a problem for users, admins, ISV, vendors higher up the chain, everybody. It's no longer possible to offer certified modules for Debian kernels given the kernel ABI number cannot be relied upon anymore. Out of tree modules exist and you can't just ignore them; in some environments they are necessary to make things work and you won't have a way around that. So I am asking you to reconsider your position and go back to strictly maintaining the kernel ABI number. This situation is a big step backward for the Debian kernel packages and I hope it'll be fixed soon. Thanks, JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87tyibh4fy@sonic.technologeek.org
Bug#607368: Kernel ABI management
Ben Hutchings b...@decadent.org.uk wrote: Hi, Some distributions provide a list all exported symbols which can be depended on not to change. We haven't done that but we do consider What you're saying here is very important: you haven't done that yet, which implies that all symbols are covered by the ABI. This is reinforced by reading the packaging scripts and realizing they check the whole ABI, prior to -28. where symbols are used before deciding a change can be ignored. I can perfectly imagine that you weren't aware of VMware's reliance upon this symbol before, but you are now. No need to tell you that quite a few of our users out there will use VMware on Squeeze and be impacted by this change. (As an example, there are several sets of drivers for related hardware in which one core module exports symbols to the specific driver modules. Those exports should in no way be depended on by OOT modules.) As smp_ops is exported by the core kernel and not by the common core of a self-contained set of drivers, I don't think this argument holds here. Reviewing the kernel revision history, smp_ops was indeed exported to allow building KVM as a module. The commit message certainly doesn't claim that KVM should be the sole user of this exported symbol. I fail to see a reason why VMware or anybody else should refrain from using smp_ops if they need it. We would not accept that behaviour from a shared library, I don't see any reason why we would accept it from the kernel. This is not true; for example, the interface between libc and NSS is not stable. And it's been widely recognized as a design flaw and a royal pain in the ass for, like, forever. Not exactly an example you want to follow. If someone claims to certify something about future Debian kernels without talking to the kernel team, they are a fraud. See the top of this mail where you state that no list of symbols covered by the ABI was ever published for Debian kernels. It isn't unreasonable under these circumstances to assume that all symbols are covered. Out of tree modules exist and you can't just ignore them; in some environments they are necessary to make things work and you won't have a way around that. Example? VMware, nVidia, various drivers and infrastructure for communications hardware (been there, done that), ... JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877hf7f6q2@sonic.technologeek.org
Bug#607368: Kernel ABI management
Ben Hutchings b...@decadent.org.uk wrote: Hi Ben, This is reinforced by reading the packaging scripts and realizing they check the whole ABI, prior to -28. This is not correct. We have ignored many changes since 2.6.32-12 when the ABI number was bumped to 5. In 2.6.32-27 the symbol version files were refreshed and the ignore list was reset. This is even more troubling. The upstream policy is that symbol exports may be removed when there are no in-tree users. So that export could even be made conditional on CONFIG_KVM_MODULE (or whatever it's called). Upstream policy doesn't break your setup from one kernel package revision to the other. Maybe I should find a way to limit that export so OOT users won't make this mistake. Good luck with that, it's been tried already with EXPORT_SYMBOL_GPL() and people still do work around that. See the top of this mail where you state that no list of symbols covered by the ABI was ever published for Debian kernels. It isn't unreasonable under these circumstances to assume that all symbols are covered. It is extremely stupid. We obviously disagree. VMware, nVidia, various drivers and infrastructure for communications hardware (been there, done that), ... VMware - use KVM. Not possible. We require 3D pass-through that KVM doesn't offer. Windows virtio drivers failed us on Vista/Seven (can't remember, not my area), plain old IDE emulation is too slow to be usable. Also, issues with moving a VM from one host to another from a Windows licensing standpoint (still researching this one, though). It's not that using KVM wouldn't ease our (and our user's) life considerably, it's that we *cannot* use it, and there are real reasons why we cannot (and I'm not even speaking of getting that solution approved internally, it's really a detail given the above). As you can see on my blog, I'm the one responsible for packaging VMware. My life would be better if we could just use KVM, believe me. Packaging VMware 7 was a nightmare. nvidia - use nouveau, report a bug if it doesn't work. Doesn't work with our cards, not by a long shot. Probably won't work for another decade or so, so not an option. We do need working and fast 3D. Switching to AMD - oh yeah, we tried that. I have a drawer full of test cards. Not a single one has working 3D with free drivers, and here again it won't happen for another year or two *best case*. Not an option. Once again: not that we wouldn't like to use free drivers, but we just can't. And I'm the one backporting and testing the nVidia drivers, so believe me when I tell you I'd be using Nouveau if it was an option. We are limited by our user's requirements on the one hand and by what hardware vendors can sell us on the other hand - and they can't sell us yesteryear's tech forever, especially on high-end mobile workstations. Anybody doing this type of large-scale deployment faces the same issues. random drivers - send them to the maintainer of crap (Greg K-H, for the staging tree). :-) That being said, not every out of tree driver comes with source. Although pure crap has made it to staging in the past, I'm pretty sure multi-megabyte binary blobs don't stand a chance. I'm pretty disappointed by the way you're handling this; it feels like you have little care for what your users actually need. I find it a bit sad, given all the very good work you've been doing with the kernel otherwise. As I wrote already, it's not like VMware is some obscure piece of software that nobody knows about. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87zks3dmgn@sonic.technologeek.org
Bug#605083: linux-2.6: MacBookAir3,* support: USB fixes
Package: linux-2.6 Severity: wishlist Hi, Following the previous set of patches, attached is another patch needed for proper support of the new MacBook Air machines. USB seems troublesome and doesn't work properly without this patch. Thanks, JB. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.35 (SMP w/2 CPU cores) Locale: LANG=C, lc_ctype=fr...@euro (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash Tested on MacBookAir3,1. Without this, we get EPROTO errors when fetching device config descriptors. Signed-off-by: Brian Tarricone br...@tarricone.org Reported-by: Benoit Gschwind gschw...@gnu-log.net Tested-by: Edgar Hucek gi...@dark-green.com Cc: Greg Kroah-Hartman g...@kroah.com --- drivers/usb/host/ehci-pci.c | 12 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c index a1e8d27..8d24d1c 100644 --- a/drivers/usb/host/ehci-pci.c +++ b/drivers/usb/host/ehci-pci.c @@ -148,6 +148,18 @@ static int ehci_pci_setup(struct usb_hcd *hcd) if (pdev-revision 0xa4) ehci-no_selective_suspend = 1; break; + + /* MCP89 chips on the MacBookAir3,1 give EPROTO when + * fetching device descriptors unless LPM is disabled. + * There are also intermittent problems enumerating + * devices with PPCD enabled. + */ + case 0x0d9d: + ehci_info(ehci, disable lpm/ppcd for nvidia mcp89); + ehci-has_lpm = 0; + ehci-has_ppcd = 0; + ehci-command = ~CMD_PPCEE; + break; } break; case PCI_VENDOR_ID_VIA: -- 1.7.3.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bug#603395: linux-2.6: add support for MacBookAir3,1 and MacBookAir3,2
Package: linux-2.6
Severity: wishlist
Hi,
As requested, here are the patches needed to support the new MacBook Air
machines. I went patch-hunting in various trees patchwork to get the
latest patches.
All patches are in maintainer's trees except the bcm5974 patch which
is lagging behind a bit but is in its final form; just waiting to be
picked up.
I'm also throwing in a patch for backlight support on the MacBookPro7,1
while I'm here; it's not been picked up in any tree yet.
Thanks,
JB.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.35 (SMP w/2 CPU cores)
Locale: LANG=C, lc_ctype=fr...@euro (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash
From 87232dd49aeb6b7d1af291edca8bd129a82ef4b5 Mon Sep 17 00:00:00 2001
From: Edgar (gimli) Hucek gi...@dark-green.com
Date: Wed, 3 Nov 2010 08:14:10 +0100
Subject: [PATCH] ALSA: hda - MacBookAir3,1(3,2) alsa support
This patch add support for the MacBookAir3,1 and MacBookAir3,2 to the alsa
sound system.
Signed-off-by: Edgar (gimli) Hucek gi...@dark-green.com
Signed-off-by: Takashi Iwai ti...@suse.de
---
sound/pci/hda/patch_cirrus.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/sound/pci/hda/patch_cirrus.c b/sound/pci/hda/patch_cirrus.c
index 460fb2e..18af38e 100644
--- a/sound/pci/hda/patch_cirrus.c
+++ b/sound/pci/hda/patch_cirrus.c
@@ -1166,6 +1166,7 @@ static const char *cs420x_models[CS420X_MODELS] = {
static struct snd_pci_quirk cs420x_cfg_tbl[] = {
SND_PCI_QUIRK(0x10de, 0x0ac0, MacBookPro 5,3, CS420X_MBP53),
+ SND_PCI_QUIRK(0x10de, 0x0d94, MacBookAir 3,1(2), CS420X_MBP55),
SND_PCI_QUIRK(0x10de, 0xcb79, MacBookPro 5,5, CS420X_MBP55),
SND_PCI_QUIRK(0x10de, 0xcb89, MacBookPro 7,1, CS420X_MBP55),
SND_PCI_QUIRK(0x8086, 0x7270, IMac 27 Inch, CS420X_IMAC27),
--
1.7.3.2
From 189133503586b9df88201ac7c61e9b44cde70677 Mon Sep 17 00:00:00 2001
From: Edgar Hucek gi...@dark-green.com
Date: Tue, 9 Nov 2010 15:15:01 +
Subject: [PATCH] hwmon: (applesmc) Add MacBookAir3,1(3,2) support
This patch add support for the MacBookAir3,1 and MacBookAir3,2 to the
applesmc driver.
[rydb...@euromail.se: minor cleanup]
Cc: sta...@kernel.org
Signed-off-by: Edgar Hucek gi...@dark-green.com
Signed-off-by: Henrik Rydberg rydb...@euromail.se
Signed-off-by: Guenter Roeck guenter.ro...@ericsson.com
---
drivers/hwmon/applesmc.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c
index b6598aa..d616174 100644
--- a/drivers/hwmon/applesmc.c
+++ b/drivers/hwmon/applesmc.c
@@ -162,6 +162,10 @@ static const char *temperature_sensors_sets[][41] = {
/* Set 22: MacBook Pro 7,1 */
{ TB0T, TB1T, TB2T, TC0D, TC0P, TN0D, TN0P, TN0S,
TN1D, TN1F, TN1G, TN1S, Th1H, Ts0P, Ts0S, NULL },
+/* Set 23: MacBook Air 3,1 */
+ { TB0T, TB1T, TB2T, TC0D, TC0E, TC0P, TC1E, TCZ3,
+ TCZ4, TCZ5, TG0E, TG1E, TG2E, TGZ3, TGZ4, TGZ5,
+ TH0F, TH0O, TM0P },
};
/* List of keys used to read/write fan speeds */
@@ -1524,11 +1528,17 @@ static __initdata struct dmi_match_data
applesmc_dmi_data[] = {
{ .accelerometer = 1, .light = 1, .temperature_set = 21 },
/* MacBook Pro 7,1: accelerometer, backlight and temperature set 22 */
{ .accelerometer = 1, .light = 1, .temperature_set = 22 },
+/* MacBook Air 3,1: accelerometer, backlight and temperature set 23 */
+ { .accelerometer = 0, .light = 0, .temperature_set = 23 },
};
/* Note that DMI_MATCH(...,MacBook) will match MacBookPro1,1.
* So we need to put Apple MacBook Pro before Apple MacBook. */
static __initdata struct dmi_system_id applesmc_whitelist[] = {
+ { applesmc_dmi_match, Apple MacBook Air 3, {
+ DMI_MATCH(DMI_BOARD_VENDOR, Apple),
+ DMI_MATCH(DMI_PRODUCT_NAME, MacBookAir3) },
+ applesmc_dmi_data[23]},
{ applesmc_dmi_match, Apple MacBook Air 2, {
DMI_MATCH(DMI_BOARD_VENDOR, Apple),
DMI_MATCH(DMI_PRODUCT_NAME, MacBookAir2) },
--
1.7.3.2
From bd760e1e5b34351e0705705e5163cb89c1316d71 Mon Sep 17 00:00:00 2001
From: Edgar (gimli) Hucek gi...@dark-green.com
Date: Thu, 11 Nov 2010 14:05:30 -0800
Subject: [PATCH] backlight: MacBookAir3,1(3,2) mbp-nvidia-bl support
Add support for the MacBookAir3,1 and MacBookAir3,2 to the mbp-nvidia-bl
driver.
Signed-off-by: Edgar (gimli) Hucek gi...@dark-green.com
Acked-by: Richard Purdie rpur...@linux.intel.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
---
drivers/video/backlight/mbp_nvidia_bl.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/video/backlight/mbp_nvidia_bl.c
b/drivers/video/backlight/mbp_nvidia_bl.c
index 9fb533f..1485f73 100644
--- a/drivers/video/backlight/mbp_nvidia_bl.c
+++
Re: [libimobiledevice-devel] ipheth
Martin S. i...@sukimashita.com wrote: Hi, Why not add an udev rule to the ipheth package which checks for the USBMUX_SUPPORTED flag and the ipheth module being added, then calls the idevicepairing tool to pair? Thus the ipheth module would simply depend on libimobiledevice-tools/-utils and the ipheth-pair package thingy would be gone. Then all that's left is an arch:all ipheth-support package containing only the udev rules and depending on an imobiledevice-tools package providing the pairing utility/agent. I'm not sure everything is in place today for this to happen, can someone sum up what is already there, what isn't and what needs to happen? Paul and I will work from there on the Debian side of things as soon as everything required will be in shape in Debian. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ljc9i1oi@sonic.technologeek.org
Re: [libimobiledevice-devel] ipheth
Olivier Galibert galib...@pobox.com wrote: Hi, Why can't ipheth just depend on libimobiledevice-utils ? It *is* a functional dependency after all, even if they're not communicating directly with each other. The ipheth-dkms package will disappear because ipheth has been accepted upstream and the kernel team added it to our 2.6.32 packages. So there's only ipheth-utils left, containing the udev rules and the pairing utility. If a pairing utility is also distributed as part of libimobiledevice, we're left with just the udev rules, and at that point it's just sane to ask ourselves where the udev rules belong. I think it's going to end up in libimobiledevice-utils at that point, unless there's a compelling reason not to do that. A package for a single very small file is a big no-no. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d3xkkfxp@sonic.technologeek.org
Re: ipheth
Paul McEnery pmcen...@gmail.com wrote: Hi, My initial thoughts are to simply drop the dependency on the dkms package, but ipheth will now be in every kernel going forward, so there will not be any need for it. Any advice would be much appreciated. Please include me in any reply as I'm not on the list. I think the dkms package can be dropped entirely. The only use case I can see for it going forward is for people building their own kernels from upstream sources, but by the time Squeeze is released the latest upstream release will have it integrated, so... JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vdbhl3mc@sonic.technologeek.org
Bug#507557: linux-image-2.6.26-1-r4k-ip22: hangs early at boot on Indigo2
Martin Michlmayr t...@cyrius.com wrote: Hi, no progress in fixing the problem itself, so turning off EARLY_PRINTK would be the best workaround. Julien, Bernhard: can you please test the following kernel: http://merkel.debian.org/~tbm/tmp/kernel/linux-image-2.6.26-2-r4k-ip22_2.6.26-20_mips.deb At the moment I have half of my I2 hardware at one place and the other half at another, so don't expect anything MIPS-related from me until 2-3 weeks if I can bring back the hardware with me at that time. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507557: linux-image-2.6.26-1-r4k-ip22: hangs early at boot on Indigo2
Thiemo Seufer t...@networkno.de wrote: Hi, ok, do you have a chance to test something newer preferred git-current ? If you have a kernel I can try, sure. Building one is another story, this machine isn't exactly fast nor quiet, as you probably know... you could cross-build upstream kernels, e.g. with my cross-toolchain for lenny: http://people.debian.org/~ths/toolchain/ I wish you had it built for amd64 :) I have a gcc 4.1 cross-compiler set up on another host, so I'm going to use that. I'm building a stock 2.6.27 kernel ip22_defconfig now. If that doesn't work, next step is a bisect between 2.6.24 and 2.6.26 on the linux-mips git tree (is that OK for you Thomas? or should I be doing something else?) JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507557: linux-image-2.6.26-1-r4k-ip22: hangs early at boot on Indigo2
Martin Michlmayr t...@cyrius.com wrote: [0.00] early_node_map[1] active PFN ranges [0.00] 0:32768 -98304 Working 2.6.26 vanilla gives: [0.00] early_node_map[1] active PFN ranges [0.00] 0:32768 -98304 [17179569.184000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 64640 Which indicates a timer-related issue, most probably. JB. -- Julien BLACHE jbla...@debian.org | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507557: linux-image-2.6.26-1-r4k-ip22: hangs early at boot on Indigo2
[EMAIL PROTECTED] (Thomas Bogendoerfer) wrote: Hi, no idea, yet. Does an older or newer kernel boot ? If yes, which kernel version ? I have a 2.6.24 kernel up running, stock debian kernel from back then. JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507557: linux-image-2.6.26-1-r4k-ip22: hangs early at boot on Indigo2
[EMAIL PROTECTED] (Thomas Bogendoerfer) wrote: Hi, ok, do you have a chance to test something newer preferred git-current ? If you have a kernel I can try, sure. Building one is another story, this machine isn't exactly fast nor quiet, as you probably know... JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#507557: linux-image-2.6.26-1-r4k-ip22: hangs early at boot on Indigo2
Package: linux-image-2.6.26-1-r4k-ip22 Version: 2.6.26-11 Hi, The kernel hangs early at boot on an Indigo2: [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.26-1-r4k-ip22 (Debian 2.6.26-11) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)) #1 Thu Nov 27 03:36:47 UTC 2008 [0.00] ARCH: SGI-IP22 [0.00] PROMLIB: ARC firmware Version 1 Revision 10 [0.00] console [early0] enabled [0.00] CPU revision is: 0460 (R4400SC) [0.00] FPU revision is: 0500 [0.00] Checking for the multiply/shift bug... no. [0.00] Checking for the daddiu bug... no. [0.00] MC: SGI memory controller Revision 3 [0.00] MC: Probing memory configuration: [0.00] bank0: 128M @ 0800 [0.00] bank1: 128M @ 1000 [0.00] Determined physical RAM map: [0.00] memory: 1000 @ 0800 (usable) [0.00] Wasting 1835008 bytes for tracking 32768 unused pages [0.00] Initrd not found or empty - disabling initrd [0.00] Zone PFN ranges: [0.00] Normal 32768 -98304 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:32768 -98304 JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: CONFIG_LEGACY_PTYS is not set on PowerPC
Vincent Lefevre [EMAIL PROTECTED] wrote: Hi, OK. But CONFIG_LEGACY_PTYS was defined in official Debian x86 kernels, so that most maintainers probably could not see the problems, and it could take months/years to get them fixed. Err, switching for BSD PTYs to POSIX PTYs is not hard at all, so if packages take years to get fixed it's either because they're unmaintained or nobody cares about them. In both cases they should be removed from the distribution. JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419197: sane-backends with CONFIG_USB_SUSPEND workaround uploaded to unstable
Hi, FYI: I've just uploaded to unstable a new version of sane-backends which includes a workaround for CONFIG_USB_SUSPEND. This workaround only works with Linux 2.6.22 up, though. As far as sane-backends (and sane-backends-extras) is concerned, this bug can be closed; the problems we've seen are in fact hardware bugs related to the improper support of USB suspend by most (if not all) USB scanners. The workaround included in sane-backends is only active for scanners supported by sane-backends; other packages like hpoj/hplip or libgphoto may still encounter this problem until they apply a similar workaround. JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#419197: libsane: xsane fails with kooka 2.6.20-1-686 works with 2.6.18-4-686
reassign 419197 linux-2.6 retitle 419197 CONFIG_USB_SUSPEND is experimental and breaks applications severity 419197 important thanks Stuart Pook [EMAIL PROTECTED] wrote: Hi, Xsane works fine when running Linux 2.6.18-4-686 however when I boot 2.6.20-1-686 I have the problem described by Michael Burschik. Xsane appears to sane but the scanner does not react and xsane receives a black scan. I have xsane 0.99+0.991-3. This is due to CONFIG_USB_SUSPEND=y added in Linux 2.6.20, this feature is still experimental and obviously it doesn't work that well just yet. Please disable this feature in the Debian kernel until this get fixed somehow. As to why scanimage works and the graphical frontends don't, either: - the device node associated to the scanner changes everytime it's put to sleep and woken up again - the scanner doesn't like to be put to sleep for some reason scanimage identifies the scanner and immediately proceeds with a scan, leaving no time for the kernel to suspend the scanner. The graphical frontends, on the other hand, identify the scanner(s) and then wait for the user to start a scan. Once the scanner is identified, it's identified using a SANE device string: backend:libusb:bus:dev. If the identifier for the scanner changes (the device number on the bus), like I suspect it might do, then we have a problem. One that we'll have a hard time fixing, and I guess that we won't be the only ones. That's only a somewhat educated guess, all that still needs to be confirmed. In any case, please Cc me on replies. Thanks, JB. -- Julien BLACHE - Debian GNU/Linux Developer - [EMAIL PROTECTED] Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354718: linux-2.6: AVM C4 driver not built for -smp kernels; config discrepancies ?
Package: linux-2.6 Severity: normal Hi, It looks like there are some discrepancies between the kernel config for up/smp kernels. According to pdo.debian.net: lib/modules/2.6.15-1-486/kernel/drivers/isdn/hardware/avm/c4.ko base/linux-image-2.6.15-1-486 lib/modules/2.6.15-1-686/kernel/drivers/isdn/hardware/avm/c4.ko base/linux-image-2.6.15-1-686 lib/modules/2.6.15-1-k7/kernel/drivers/isdn/hardware/avm/c4.ko base/linux-image-2.6.15-1-k7 Is there a reason why the AVM modules aren't built in the SMP kernels ? The same goes for the Eicon drivers which aren't enabled in all of the SMP kernels. Thanks, JB. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#354718: linux-2.6: AVM C4 driver not built for -smp kernels; config discrepancies ?
Bastian Blank [EMAIL PROTECTED] wrote: Those drivers depend on the BROKEN_ON_SMP option set, which obviously is not set on SMP kernels. No, this CAPI drivers are not broken in this respect, only i4l. So they can be re-enabled ? (not having the 2.6.15 sources at hand to check right now ...) JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Add back beep support to snd-powermac]
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: This is also the way other distro works except in critical release situations which isn't the case for a patch like that. It's not critical for sure, however I'd point out that it's nice to have your PB/iBook beep before going to sleep because the battery is too low :) JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Re: Add back beep support to snd-powermac]
Christoph Hellwig [EMAIL PROTECTED] wrote: Hi, We don't give it 100% out of hand. We can still decide what to take and what not. But I'm very much against patches where the authors haven't even bothered to post them upstream because that will lead to a huge amount of patches we'll have to carry along. Just in case you were referring to my patch: I mailed the patch to the maintainer of the sound subsystem as listed in the MAINTAINERS file. JB. -- Julien BLACHE [EMAIL PROTECTED] | Debian, because code matters more Debian GNU/Linux Developer| http://www.debian.org Public key available on http://www.jblache.org - KeyID: F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
