Bug#347177: system Hang on linux-image-2.6.15-1-k7
Package: linux-image-2.6.15 Version: 2.6.15-1-k7-1 System hangs on send/revc data with dialup connection. Simply connect with a dialup connection (configured with pppconfig, connected with pon), open a Firefox browser window and open few tabs. System hangs. Sometimes I have the same problem when receiving data in gnome-terminal aith apt-get. There is no problem with kernel: 2.6.14-2-k7-6. Kernel: 2.6.15-1-k7-1 libc6: 2.3.5-11 Same problem with 2 different machines: PC#1: AMD athlon thunderbird 1333MHz Gigabyte 7ZXE M/B 256 MB SD-RAM PC133 Gforce2 MX440 DDR 64MB G/C PC#2: AMD athlon thunderbird 1333MHz Gigabyte 7VM M/B 512 MB DDR 400 RAM ATI Radeon 7000 64 MB
Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer
Package: linux-2.6 Version: 2.6.14-7 Severity: important Sigh, can't get a break with alpha kernel support around here. After upgrading to 2.6.14 (from 2.4.27), the Matrox framebuffer no longer works correctly on my alpha with a Matrox Millenium II. The matroxfb_base module loads without error, but gives me corrupt video output only. Card info from lspci: :00:05.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] and lspci -n: :00:05.0 0300: 102b:051b dmesg output: matroxfb: Matrox Millennium II (PCI) detected PInS memtype = 0 matroxfb: 640x480x8bpp (virtual: 640x6553) matroxfb: framebuffer at 0x900, mapped to 0xfc880900, size 4194304 fb0: MATROX frame buffer device fb0: initializing hardware Happy to test potential driver fixes, though due to issues with *other* hardware in this system I didn't test the framebuffer with any previous 2.6 kernels and can't tell you whether it worked with them. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Processed: Re: Bug#347177: system Hang on linux-image-2.6.15-1-k7
Processing commands for [EMAIL PROTECTED]: reassign 347177 linux-2.6 Bug#347177: system Hang on linux-image-2.6.15-1-k7 Warning: Unknown package 'linux-image-2.6.15' Bug reassigned from package `linux-image-2.6.15' to `linux-2.6'. -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer
On Mon, Jan 09, 2006 at 01:08:49AM -0800, Steve Langasek wrote: Package: linux-2.6 Version: 2.6.14-7 Severity: important Sigh, can't get a break with alpha kernel support around here. After upgrading to 2.6.14 (from 2.4.27), the Matrox framebuffer no longer works correctly on my alpha with a Matrox Millenium II. The matroxfb_base module loads without error, but gives me corrupt video output only. Try turning off acceleration. matroxfb is problematic, since the matroxfb maintainer didn't agree on the 2.4-2.6 fbdev API change, and thus things broke all over, and has a huge patch that reverses the new fbdev stuff. At least this was the case a year or two back at least. Card info from lspci: :00:05.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2164W [Millennium II] and lspci -n: :00:05.0 0300: 102b:051b dmesg output: matroxfb: Matrox Millennium II (PCI) detected PInS memtype = 0 matroxfb: 640x480x8bpp (virtual: 640x6553) matroxfb: framebuffer at 0x900, mapped to 0xfc880900, size 4194304 fb0: MATROX frame buffer device fb0: initializing hardware Happy to test potential driver fixes, though due to issues with *other* hardware in this system I didn't test the framebuffer with any previous 2.6 kernels and can't tell you whether it worked with them. It probably was always so, and matroxfb is problematic. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#346246: acknowledged by developer (Re: Bug#346246: Can't install nvidia drivers)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Debian Bug Tracking System wrote:
This is an automatic notification regarding your Bug report
#346246: Can't install nvidia drivers, which was filed against the
linux-source-2.6.15 package.
It has been closed by one of the developers, namely maximilian
attems [EMAIL PROTECTED].
Their explanation is attached below. If this explanation is
unsatisfactory and you have not received a better one in a separate
message then please contact the developer, by replying to this
email.
Debian bug tracking system administrator (administrator, Debian
Bugs database)
Received: (at 346246-done) by bugs.debian.org; 7 Jan 2006 10:52:35
+
From [EMAIL PROTECTED] Sat Jan 07 02:52:35 2006
Return-path: [EMAIL PROTECTED] Received: from baikonur.stro.at
([213.239.196.228]) by spohr.debian.org with esmtp (Exim 4.50) id
1EvBgY-0001J9-QK for [EMAIL PROTECTED]; Sat, 07 Jan 2006
02:52:34 -0800 Received: from nancy (stallburg.stro.at
[128.131.216.190]) by baikonur.stro.at (Postfix) with ESMTP id
8BF9B5C00B for [EMAIL PROTECTED]; Sat, 7 Jan 2006
11:53:10 +0100 (CET) Received: from max by nancy with local (Exim
4.60) (envelope-from [EMAIL PROTECTED]) id 1EvBgK-00035L-HG for
[EMAIL PROTECTED]; Sat, 07 Jan 2006 11:52:20 +0100 Date:
Sat, 7 Jan 2006 11:52:20 +0100 From: maximilian attems
[EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re:
Bug#346246: Can't install nvidia drivers Message-ID:
[EMAIL PROTECTED] References:
[EMAIL PROTECTED] MIME-Version: 1.0 Content-Type:
text/plain; charset=us-ascii Content-Disposition: inline
In-Reply-To: [EMAIL PROTECTED] User-Agent:
Mutt/1.5.11 X-Virus-Scanned: by Amavis (ClamAV) at stro.at
X-Spam-Checker-Version: SpamAssassin
2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on
spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-6.0
required=4.0 tests=BAYES_00,HAS_BUG_NUMBER autolearn=no
version=2.60-bugs.debian.org_2005_01_02
On Fri, 06 Jan 2006, [EMAIL PROTECTED] wrote:
Package: linux-source-2.6.15 Version: 2.6.15-1
Can't install nvidia drivers version 1.0-8178*:
*Using: nvidia-installer ncurses user interface - - License
accepted. - - There appears to already be a driver installed on
your system (version: 1.0- 7664). As part of installing this
driver (version: 1.0-8178), the existing driver will be
uninstalled. Are you sure you want to continue? ('no' will a
bort installation) (Answer: Yes) - - No precompiled kernel
interface was found to match your kernel; would you li ke the
installer to attempt to download a kernel interface for your
kernel f rom the NVIDIA ftp site (ftp://download.nvidia.com)?
(Answer: Yes) - - No matching precompiled kernel interface was
found on the NVIDIA ftp site; this means that the installer will
need to compile a kernel interface for your kernel. - -
Performing CC test with CC=cc. - - Kernel source path:
'/usr/src/linux' - - Kernel output path: '/usr/src/linux' - -
Performing rivafb check. ERROR: Your kernel was configured to
include rivafb support!
The rivafb driver conflicts with the NVIDIA driver, please
reconfigure your kernel and *disable* rivafb support, then try
installing the NVIDIA kernel module again. ERROR: Installation
has failed. Please see the file '/var/log/nvidia-installer.log'
for details. You may find suggestions on fixing installation
problems in the README available on the Linux driver download
page at www.nvidia.com.
beside the error message beeing *crystal* clear, we don't support
closed source binary drivers
closing
I know it's crystal, it's all about compiling for rivafb support! And
don't tell me that i can make my custom kernel!
This rivafb support on Debian kernel start on 2.6.14 and still exist
on 2.6.15.
For my servers boxes it's great, but for my desktop boxes no.
Is there a way that server boxes and game boxes are both happy!?
Many thanks.
João
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Debian - http://enigmail.mozdev.org
iD8DBQFDwi+Va72iljGeL5gRAu30AKDBfDILWsyD5g4MEEjN86u3srnrxgCgr5LN
etiB73KHo3cremzmm+ssZ5g=
=YYwI
-END PGP SIGNATURE-
Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer
On Mon, Jan 09, 2006 at 10:35:18AM +0100, Sven Luther wrote: On Mon, Jan 09, 2006 at 01:08:49AM -0800, Steve Langasek wrote: Package: linux-2.6 Version: 2.6.14-7 Severity: important Sigh, can't get a break with alpha kernel support around here. After upgrading to 2.6.14 (from 2.4.27), the Matrox framebuffer no longer works correctly on my alpha with a Matrox Millenium II. The matroxfb_base module loads without error, but gives me corrupt video output only. Try turning off acceleration. Doesn't make a difference. What did make a difference was, after googling, loading fbcon manually before loading matroxfb_base. Given that I'm loading matroxfb_base by hand (/etc/modules), it's not getting loaded via udev or anything like that, it seems to me that it's my responsibility to load fbcon by hand as well, but it's still something of an unexpected change from 2.4. It might be nice to have these modules all autoloaded by something, but it's not strictly necessary, and some users may not want the framebuffer activated automatically? The other issue (and the first thing I was trying to get work, which led me to believe the fb was completely broken) is that, even though console works on the framebuffer now, X does not. This breakage corresponds to the kernel upgrade, not to any changes in X, so still looks like a kernel bug to me. If I turn off UseFBDev in my xorg.conf, X displays correctly. I haven't poked yet to see what this does performance-wise. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer
* Sven Luther wrote: matroxfb is problematic, since the matroxfb maintainer didn't agree on the 2.4-2.6 fbdev API change, and thus things broke all over, and has a huge patch that reverses the new fbdev stuff. At least this was the case a year or two back at least. Last time I tried matroxfb on alpha (IIRC it was with 2.5.68), this patch helped to get it working correctly: ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/ I thought that patch was integrated upstream already, but there's a patch against 2.6.15-rc4, so I don't think it was integrated already. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347186: linux-image-2.6.14-2-alpha-generic: garbled Matrox framebuffer
On Mon, Jan 09, 2006 at 02:51:46AM -0800, Steve Langasek wrote: On Mon, Jan 09, 2006 at 10:35:18AM +0100, Sven Luther wrote: On Mon, Jan 09, 2006 at 01:08:49AM -0800, Steve Langasek wrote: Package: linux-2.6 Version: 2.6.14-7 Severity: important Sigh, can't get a break with alpha kernel support around here. After upgrading to 2.6.14 (from 2.4.27), the Matrox framebuffer no longer works correctly on my alpha with a Matrox Millenium II. The matroxfb_base module loads without error, but gives me corrupt video output only. Try turning off acceleration. Doesn't make a difference. What did make a difference was, after googling, loading fbcon manually before loading matroxfb_base. Given that I'm loading matroxfb_base by hand (/etc/modules), it's not getting loaded via udev or anything like that, it seems to me that it's my responsibility to load fbcon by hand as well, but Indeed, if you load it by hand, you need to load fbcon also. Maybe there should be a dependency between matroxfb and fbcon, which modprobe would then take care of, but i guess it also makes sense to use matroxfb without fbcon, or something. it's still something of an unexpected change from 2.4. It might be nice to have these modules all autoloaded by something, but it's not strictly necessary, and some users may not want the framebuffer activated automatically? I think that if you configure yaird to load in matroxfb, it should then also load fbcon. The other issue (and the first thing I was trying to get work, which led me to believe the fb was completely broken) is that, even though console works on the framebuffer now, X does not. This breakage corresponds to the kernel upgrade, not to any changes in X, so still looks like a kernel bug to me. What X version are you using ? If I turn off UseFBDev in my xorg.conf, X displays correctly. I haven't poked yet to see what this does performance-wise. Should not make a difference. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345129: linux-image-2.6.14-2-686 and ALI5451 module
Bonjour Max|Maks maximilian attems wrote: c'est une trop belle langue .. non ?? oui, j'imagine difficile a apprendre car tres riche, mais tres belle, effectivement... Merci ! :-) please test against linux-image-2.6.15 in the archive? aboves mentioned option is disabled. Yes I did it this morning (away from my laptop these 3 last days...). I was about to answer you, as expected. Unfortunately behavior is just the same with this official debian release than with the RC of last week. Logical BTW, when RC is approved it's switched to unstable without (many) changes I guess. Alsa module for ALI5451 is still providing the same errors, but as you said I guess I should report it to alsa developpers. Do you have the email address to contact them please ? However you might be more directly concerned by the USB point. As I mentionned in one of my previous email my integrated touchpas and keyboard are now working, my external USB mouse is still working too, but my external PS/2 keyboard, linked to the laptop in USB via a PS2-2-USB device is no longer working. The logs in 2.6.14 boot vs. 2.5.15 are attached. Don't worry too much for that behavior, I can work fine running 2.6.14. I just report that point to help developpers knowing what's happening with special configs. How to work if nobody's telling you something's wrong somewhere ? That's a problem I often have in my sysadmin job... I wish you a good day, best regards, Laurent-the-frenchie-with-a-very-weird-laptop ;-) 2.6.15 - external keyboard not working : Jan 9 11:35:55 laptop syslogd 1.4.1#17: restart. Jan 9 11:35:55 laptop kernel: klogd 1.4.1#17, log source = /proc/kmsg started. Jan 9 11:35:55 laptop kernel: Inspecting /boot/System.map-2.6.15-1-686 Jan 9 11:35:56 laptop kernel: Loaded 21545 symbols from /boot/System.map-2.6.15-1-686. Jan 9 11:35:56 laptop kernel: Symbols match kernel version 2.6.15. Jan 9 11:35:56 laptop kernel: No module symbols loaded - kernel modules not enabled. [snip] Jan 9 11:35:56 laptop kernel: hub 2-0:1.0: USB hub found Jan 9 11:35:56 laptop kernel: hub 2-0:1.0: 2 ports detected Jan 9 11:35:56 laptop kernel: usb 1-1: new low speed USB device using ohci_hcd and address 2 Jan 9 11:35:56 laptop kernel: usb 1-2: new low speed USB device using ohci_hcd and address 3 Jan 9 11:35:56 laptop kernel: usbcore: registered new driver hiddev Jan 9 11:35:56 laptop kernel: input: Logitech USB Mouse as /class/input/input1 Jan 9 11:35:56 laptop kernel: input: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-:00:02.0-1 Jan 9 11:35:56 laptop kernel: input: Composite USB PS2 Converter USB to PS2 Adaptor v1.09 as /class/input/input2 Jan 9 11:35:56 laptop kernel: input: USB HID v1.10 Keyboard [Composite USB PS2 Converter USB to PS2 Adaptor v1.09] on usb-:00:02.0-2 Jan 9 11:35:56 laptop kernel: input: Composite USB PS2 Converter USB to PS2 Adaptor v1.09 as /class/input/input3 Jan 9 11:35:56 laptop kernel: input: USB HID v1.10 Mouse [Composite USB PS2 Converter USB to PS2 Adaptor v1.09] on usb-:00:02.0-2 Jan 9 11:35:56 laptop kernel: usbcore: registered new driver usbhid Jan 9 11:35:56 laptop kernel: drivers/usb/input/hid-core.c: v2.6:USB HID core driver Jan 9 11:35:56 laptop kernel: mice: PS/2 mouse device common for all mice 2.6.14 boot - external kbd mouse OK - internal kbd touchpad disabled Jan 9 11:49:20 laptop syslogd 1.4.1#17: restart. Jan 9 11:49:20 laptop kernel: klogd 1.4.1#17, log source = /proc/kmsg started. Jan 9 11:49:20 laptop kernel: Inspecting /boot/System.map-2.6.14-2-686 Jan 9 11:49:20 laptop kernel: Loaded 21230 symbols from /boot/System.map-2.6.14-2-686. Jan 9 11:49:20 laptop kernel: Symbols match kernel version 2.6.14. Jan 9 11:49:20 laptop kernel: No module symbols loaded - kernel modules not enabled. Jan 9 11:49:20 laptop kernel: (Debian 2.6.14-7) ([EMAIL PROTECTED]) (gcc version 4.0.3 20051201 (prerelease) (Debian 4.0.2-5)) #1 Wed Dec 28 18:21:03 UTC 2005 [snip] Jan 9 11:49:21 laptop kernel: hub 2-0:1.0: USB hub found Jan 9 11:49:21 laptop kernel: hub 2-0:1.0: 2 ports detected Jan 9 11:49:21 laptop kernel: usb 1-1: new low speed USB device using ohci_hcd and address 2 Jan 9 11:49:21 laptop kernel: usb 1-2: new low speed USB device using ohci_hcd and address 3 Jan 9 11:49:21 laptop kernel: usbcore: registered new driver hiddev Jan 9 11:49:21 laptop kernel: input: USB HID v1.10 Mouse [Logitech USB Mouse] on usb-:00:02.0-1 Jan 9 11:49:21 laptop kernel: input: USB HID v1.10 Keyboard [Composite USB PS2 Converter USB to PS2 Adaptor v1.09] on usb-:00:02.0-2 Jan 9 11:49:21 laptop kernel: input: USB HID v1.10 Mouse [Composite USB PS2 Converter USB to PS2 Adaptor v1.09] on usb-:00:02.0-2 Jan 9 11:49:21 laptop kernel: usbcore: registered new driver usbhid Jan 9 11:49:21 laptop kernel: drivers/usb/input/hid-core.c: v2.6:USB HID core driver Jan 9 11:49:21 laptop kernel: mice: PS/2 mouse device
Re: Preparing 2.5.15-2
On Sunday 08 January 2006 22:50, Frederik Schueler wrote: Hallo, On Sun, Jan 08, 2006 at 10:23:54PM +, David Goodenough wrote: Could you put in the change that was in the hostap-source since 2003 and is not in the in kernel version of hostap. Line 31 (a #define) is commented in hostap_config.h. If it is uncommented then hostap will be able to flash new firmware. Please see my earlier post on the subject. Can you please file a bug against linux-2.6 on this and possibly add a patch for 2.6.15? Is this change likely to be included upstream, or was it already rejected? Best regards Frederik Schueler I will raise a bug against this, and try to construct a patch. There does seem to be a group upstream who want this, but it is not unanimous. Maybe I should talk to the old maintainer of the hostap-source module and get his opinion. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329284: linux-2.6: Failed to bring up eth1.
On Tue, Jan 03, 2006 at 05:27:09PM +0100, Maximilian Attems wrote: please try against lastest 2.6.14 in unstable, yes, eth1394 works fine now on 2.6.14 thanks, piem tomorrow 2.6.15 should be available. is the bug still reproducible? -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347231: kernel-image-2.6.8: Problems with mouse on latitude series
Package: kernel-image-2.6.8-2-686 Version: 2.6.8-16sarge1 Severity: wishlist File: kernel-image-2.6.8 The double click on touchpad mouse's don't function to notebook Dell Latitude CSx model. (The same problem don't occur with kernel-image-2.4). -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) Versions of packages kernel-image-2.6.8-2-686 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii initrd-tools 0.1.81.1 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo -- no debconf information Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Leandro Cristante de Oliveira [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: kernel-image-2.6.8: Problems with mouse on latitude series X-Mailer: reportbug 3.8 Date: Mon, 09 Jan 2006 01:40:58 -0200 X-Debbugs-Cc: [EMAIL PROTECTED] Package: kernel-image-2.6.8-2-686 Version: 2.6.8-16sarge1 Severity: wishlist File: kernel-image-2.6.8 The double click on touchpad mouse's don't function to notebook Dell Latitude CSx model. (The same problem don't occur with kernel-image-2.4). -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=pt_BR, LC_CTYPE=pt_BR (charmap=ISO-8859-1) Versions of packages kernel-image-2.6.8-2-686 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii initrd-tools 0.1.81.1 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo -- no debconf information
Bug#329284: marked as done (linux-2.6: Failed to bring up eth1.)
Your message dated Mon, 9 Jan 2006 16:37:17 +0100 with message-id [EMAIL PROTECTED] and subject line linux-2.6: Failed to bring up eth1. has caused the attached Bug report 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 I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -- Received: (at submit) by bugs.debian.org; 20 Sep 2005 22:11:56 + From [EMAIL PROTECTED] Tue Sep 20 15:11:56 2005 Return-path: [EMAIL PROTECTED] Received: from 81-178-108-244.dsl.pipex.com (peche) [81.178.108.244] by spohr.debian.org with esmtp (Exim 3.36 1 (Debian)) id 1EHqLE-0005p7-00; Tue, 20 Sep 2005 15:11:56 -0700 Received: from [10.0.10.35] (helo=localhost.localdomain) by peche with esmtp (Exim 4.50) id 1EHqNQ-0001rG-Qp; Tue, 20 Sep 2005 23:14:12 +0100 Received: from piem by localhost.localdomain with local (Exim 4.52) id 1EHqLN-0003rz-HM; Tue, 20 Sep 2005 23:12:05 +0100 Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Paul Brossier [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: linux-2.6: Failed to bring up eth1. X-Mailer: reportbug 3.17 Date: Tue, 20 Sep 2005 23:12:05 +0100 Message-Id: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 Package: linux-2.6 Version: 2.6.12-6 Severity: important When trying to bring up a firewire interface on a G5 running a 2.6.12-1-powerpc64 (well, a fixed one, see 323724), i get the following message: $ ifup eth1 SIOCSIFFLAGS: Resource temporarily unavailable SIOCSIFFLAGS: Resource temporarily unavailable Failed to bring up eth1. $ tail -n1 /var/log/syslog Sep 20 23:08:35 localhost kernel: eth1394: eth1: Could not allocate isochronous receive context for the broadcast channel $ ifconfig eth1 eth1 Link encap:UNSPEC HWaddr 00-0A-95-FF-FE-BE-FE-28-00-00-00-00-00-00-00-00 inet addr:10.11.12.36 Bcast:10.11.12.255 Mask:255.255.255.0 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) i have the following in /etc/network/interfaces auto eth1 iface eth1 inet static address 10.11.12.36 netmask 255.255.255.0 broadcast 10.11.12.255o the same configuration works nicely on an ibook running 2.6.12-1-powerpc. i can reproduce the bug on 2.6.11-power4-smp. cheers, piem -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-powerpc64def Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.12-1-powerpc64 depends on: ii coreutils [fileutils] 5.2.1-2.1 The GNU core utilities ii initrd-tools 0.1.82 tools to create initrd image for p ii module-init-tools 3.2-pre8-1 tools for managing Linux kernel mo linux-image-2.6.12-1-powerpc64 recommends no packages. -- no debconf information --- Received: (at 329284-done) by bugs.debian.org; 9 Jan 2006 15:36:38 + From [EMAIL PROTECTED] Mon Jan 09 07:36:38 2006 Return-path: [EMAIL PROTECTED] Received: from baikonur.stro.at ([213.239.196.228]) by spohr.debian.org with esmtp (Exim 4.50) id 1Evz4Y-00073L-7Y for [EMAIL PROTECTED]; Mon, 09 Jan 2006 07:36:38 -0800 Received: by baikonur.stro.at (Postfix, from userid 1001) id 5DB035C014; Mon, 9 Jan 2006 16:37:17 +0100 (CET) Date: Mon, 9 Jan 2006 16:37:17 +0100 From: Maximilian Attems [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: linux-2.6: Failed to bring up eth1. Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: [EMAIL PROTECTED] User-Agent: Mutt/1.5.9i X-Virus-Scanned: by Amavis (ClamAV) at stro.at X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_00 autolearn=no version=2.60-bugs.debian.org_2005_01_02 Version:
Re: non-free firmware
On Sun, Jan 08, 2006 at 11:58:16PM +0100, Sven Luther wrote: On Sun, Jan 08, 2006 at 09:50:47PM +0100, Frederik Schueler wrote: Hallo, On Sun, Jan 08, 2006 at 11:10:46AM +0100, Sven Luther wrote: On Sun, Jan 08, 2006 at 10:04:45AM +0100, Andreas Barth wrote: Now, my question is: Is there still work open? If so, what? Or is the current removal of firmware enough, and we can relax on this topic? From my point of view, the situation currently looks like this: 1. tg3 and qla2xxx driver status has been solved: upstream has relicensed the drivers - the sourcecode is licensed under the GPL, the firmware data is freely distributable as an aggregate work. The firmware is still source-less, and it is not data, as it represents microcode destined to be run on the controller it is uploaded to. we all agree that a line needs to be drawn. The stripped firmwares have questionable licenses and needs to be put in non-free. kernel.org is distributing all of them. i'm sure that a user expects a package called linux-image to contain tg3 for example. in an ideal world the line could be drawn much tighter, at the moment there is not much of a gain. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#346543: udev netlink problems with kernel 2.6.15 on alpha
Processing commands for [EMAIL PROTECTED]: reassign 346543 linux-2.6 Bug#346543: udev netlink problems with kernel 2.6.15 on alpha Bug reassigned from package `udev' to `linux-2.6'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
On Mon, Jan 09, 2006 at 04:35:40PM +0100, maximilian attems wrote: On Sun, Jan 08, 2006 at 11:58:16PM +0100, Sven Luther wrote: On Sun, Jan 08, 2006 at 09:50:47PM +0100, Frederik Schueler wrote: Hallo, On Sun, Jan 08, 2006 at 11:10:46AM +0100, Sven Luther wrote: On Sun, Jan 08, 2006 at 10:04:45AM +0100, Andreas Barth wrote: Now, my question is: Is there still work open? If so, what? Or is the current removal of firmware enough, and we can relax on this topic? From my point of view, the situation currently looks like this: 1. tg3 and qla2xxx driver status has been solved: upstream has relicensed the drivers - the sourcecode is licensed under the GPL, the firmware data is freely distributable as an aggregate work. The firmware is still source-less, and it is not data, as it represents microcode destined to be run on the controller it is uploaded to. we all agree that a line needs to be drawn. The stripped firmwares have questionable licenses and needs to be put in non-free. the problem is that there are two issues : 1) non-distributable modules, because the licence was messy. 2) distributable modules with non-free firmware. tg3 and qla2xxx used to be in the first class, and due to relicencing they now are in the second class, that don't make them free by any stretch of the imagination. so, right now, if we are true to ourselves and follow the GR, we would have to put tg3 and qla2xxx modules in non-free, and totally remove the messed up licenced modules. If we don't want to do that, the most honest way to handle it is to get another GR out the door,explaining that this is not easily possible or convenient at this time, and asking for an explicit exception for kernel firmware. I would second such a GR. kernel.org is distributing all of them. i'm sure that a user expects a package called linux-image to contain tg3 for example. Sure, but what has this to do with anything ? Also, distributing those from non-free, and having d-i seamlessly manage this, is probably not such a problem for our users, and they can then chose to have the non-free firmware or not. That is why we voted to keep non-free after all, isn't it ? in an ideal world the line could be drawn much tighter, at the moment there is not much of a gain. Sure, but because we chose to keep the non-free firmware or not, where we draw the line, well, this doesn't change a thing about whether the firmware in question is a source-less binary-hexdump or true free software. Just call things by their name and concentrate on going the real arguments out, instead of playing with words in order to justify yourself. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware
On Mon, Jan 09, 2006 at 07:00:00PM +0100, Maximilian Attems wrote: On Mon, Jan 09, 2006 at 06:24:34PM +0100, Sven Luther wrote: On Mon, Jan 09, 2006 at 04:35:40PM +0100, maximilian attems wrote: On Sun, Jan 08, 2006 at 11:58:16PM +0100, Sven Luther wrote: On Sun, Jan 08, 2006 at 09:50:47PM +0100, Frederik Schueler wrote: Hallo, On Sun, Jan 08, 2006 at 11:10:46AM +0100, Sven Luther wrote: On Sun, Jan 08, 2006 at 10:04:45AM +0100, Andreas Barth wrote: Now, my question is: Is there still work open? If so, what? Or is the current removal of firmware enough, and we can relax on this topic? From my point of view, the situation currently looks like this: 1. tg3 and qla2xxx driver status has been solved: upstream has relicensed the drivers - the sourcecode is licensed under the GPL, the firmware data is freely distributable as an aggregate work. The firmware is still source-less, and it is not data, as it represents microcode destined to be run on the controller it is uploaded to. we all agree that a line needs to be drawn. The stripped firmwares have questionable licenses and needs to be put in non-free. the problem is that there are two issues : 1) non-distributable modules, because the licence was messy. 2) distributable modules with non-free firmware. tg3 and qla2xxx used to be in the first class, and due to relicencing they now are in the second class, that don't make them free by any stretch of the imagination. the current stripping is chosen randomly by Xu. the stripped usb acenic drivers license is not that bad, it is distributable. Can you please back those claims with some reality ? I believe that the stripping has been done by Andres and some others a bit under a way ago, when they wrote the prune-non-free script. current fact is that the qlaxxx firmware is gpl, so on has all it's right in main. It is GPL, except for the binary blob of firmware, as the two constitute separate work, this is not a violation of the GPL. The exact licence, that this one comes under, as pointed out by Frederik and Andres on irc is in Documentation/scsi/LICENSE.qla2xxx : This program includes a device driver for Linux 2.6 that may be distributed with QLogic hardware specific firmware binary file. You may modify and redistribute the device driver code under the GNU General Public License as published by the Free Software Foundation (version 2 or a later version). You may redistribute the hardware specific firmware binary file under the following terms: 1. Redistribution of source code (only if applicable), must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistribution in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name of QLogic Corporation may not be used to endorse or promote products derived from this software without specific prior written permission Which unless someone released a heavily modified GPL licence silently in out back, very very far from the GPL itself. Notice how this licence speaks of source code of the firmware, and that if you where to have had a copy of it, you are bound under the same licence, and it clearly mentions redistribution as binary only, as opposed to with source. So, now that the facts are there, i would think you would be very very hardpressed to actually claim this to be DFSG free, don't you think ? so, right now, if we are true to ourselves and follow the GR, we would have to put tg3 and qla2xxx modules in non-free, and totally remove the messed up licenced modules. If we don't want to do that, the most honest way to handle it is to get another GR out the door,explaining that this is not easily possible or convenient at this time, and asking for an explicit exception for kernel firmware. I would second such a GR. that's one outcome if one follows you radical thoughts. Ah, no ? I mean, i would be happy with saying that despit this being non-free, it still make sense to keep it in main, but i doubt even the most lenient people would claim the above licence is DFSG free. nobody else seem to back your non-free position, Well, who is backing your position ? I guess they are only bored by this topic or haven't come to write on this one yet. so i'm far from certain that it's the one shared by the d-k team. Well, shall we have a vote ? kernel.org is distributing all of them. i'm sure that a user expects a package called linux-image to contain tg3 for example. Sure, but what has this to do with anything ? yes if you care about what you are distributing, you shouldn't
Re: bits from the release team
On Tue, Jan 03, 2006 at 06:43:28PM -0500, Brian Nelson wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Jan 04, Adam Heath [EMAIL PROTECTED] wrote: Not to mention that 2.6.15 requires a newer udev. Who knows what other newer things newer kernels might require. OTOH, old kernel are buggy and out of date wrt modern hardware, and we lack the manpower to backport for years fixes and new features RHEL-style. Do you have a better solution? Why don't we use RHEL's kernel, or collaborate with them to maintain a stable kernel tree, or something? or http://members.optusnet.com.au/ckolivas/kernel/ -- Chris. == Reproduction if desired may be handled locally. -- rfc3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347284: linux-doc-2.6.14: get the latest linux-doc
Package: linux-doc-2.6.14 Severity: wishlist It's neat, all I have to do is install linux-image-686 which will get linux-image-2.6-686, which will get the latest image. Alas, there is no similar way to get the latest linux-doc. One must do it by hand. install linux-doc-2.6 doesn't work like the above. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
Hi all, I am cross posting to debian-release and debian-boot, since this will affect them too. On Sun, Jan 08, 2006 at 10:04:45AM +0100, Andreas Barth wrote: Hi, at least I lost track a bit, so this mail is basically a question to bring me up to speed. Ok, we had a long discussion on #debian-kernel, and altough not all participated (Manoj, maks, fs, dilinger, kyle and me mostly), i think it sums up well the current situation. In 2004, there was a GR that decided to put everything in main under the DFSG. We had some discussions, but in the end, the result was that all the non-free firmware bits have to be removed from main before we can release etch. Now, my question is: Is there still work open? If so, what? Or is the current removal of firmware enough, and we can relax on this topic? Basically, the situation is like this : 1) there where drivers under implicit GPL licence with binary only firmware. Since there was no explicit licence for this firmware, it was GPL, and since it was sourceless, it was non-distributable. We started work to get upstreams to relicence their code, which happened with the tg3 and qla2xxx drivers, but failed for others, like the acenic one, partly because of the demise of the company producing them and various acquisitions which left the IP in an unknown state nobody seems to bother with. 2) there are now drivers which contains non-free firmware blobs, with explicit licence, and these are thus distributable. A quick search for fw_ revealed 159 such files in 2.6.15. 3) an effort seems to be happening inside the upstream kernel to use the request_firmware infrastructure which allows to load firmware code from userland through an hotplug mechanism. There seem to be more and more drivers going this way, since there aare more in current git than in 2.6.15 which was released a week ago, qla2xxx being among them. Here is a link to the relevant wiki page about the cleaning up of messy licences : http://wiki.debian.org/KernelFirmwareLicensing So, basically this means we have the following options : a) we move the whole kernel to non-free :) b) we move the affected modules to non-free. Well those that have their licencing solved, the others will simply no more be distributed, or distributed form an unofficial source. c) we move the firmware in non-free, and actively use the request_firmware mechanism. d) we go for a new GR, asking for an exception for the linux kernel, in order to still stay in main, even though the firmware is non-free, arguing that said firmware is more akin to hardware, since it replaces firmware on a prom or flash on the expansion card, and you thus lose no freedom if we distribute it, and the pain the other solutions will cause to ourselves and our users. I think everyone agrees that a) is not a possibility. Both b) and c) require a non-negligible amount of work, altough b) is less work than c), but c) is the better solution, and also to the best of my knowledge the one which upstream seems to favour, altough both may mean a long-term additional work for the kernel-team, work which the kernel team is not really prepared to make, which leaves d). Not sure if d) is politically right right now with regard to the GFDL situation, but that is another issue, which will then need to be debated. So, Andreas, you proposed help and bug squasing parties focused on this, i guess it is now clear what needs done :), and i can only stress that this needs an additional comitment of help, since any patch which will come up will probably have to be maintained by the debian kernel team for a long time. Also, if we go the BSP way, it has to make clear that it had to be a long standing and coordinated effort, since random patches of dubious quality will probably only make matters worse for the kernel team.. I also CCed the debian-boot team, since it becomes evident that this will mean some work on the d-i part, either to move the whole of d-i into nonfree (case a), or to modify d-i to use non-free .udebs for certain modules or firmware. Ok, i believe this summarizes the discussion of this evening, a log of the irc discussion can be found at : http://people.debian.org/~fs/firmware-irc-log.html Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in the linux kernel
On Mon, Jan 09, 2006 at 11:03:13PM +0100, Sven Luther wrote: I think everyone agrees that a) is not a possibility. Both b) and c) require a non-negligible amount of work, altough b) is less work than c), but c) is the better solution, and also to the best of my knowledge the one which upstream seems to favour, altough both may mean a long-term additional work for the kernel-team, work which the kernel team is not really prepared to make, which leaves d). Not sure if d) is politically right right now with regard to the GFDL situation, but that is another issue, which will then need to be debated. Oh, i forgot, this also means, if we go either b) or c), to create a new non-free-but-distribuable section in out archive, which would more easily be included on CD medias and such, or it will be ways more painful than needed on our users. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 339080
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.10 tags 339080 + pending Bug#339080: Frequent crash in handle_IRQ_event on alpha with kernel 2.6 Tags were: pending patch Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347328: Please disable kernel pwc (Philips USB webcam) module by default
On Tue, Jan 10, 2006 at 01:31:50AM -0330, Lawrence Williams wrote: Package: linux-2.6 Severity: important Hi, I am asking for the in-kernel pwc module (Philips USB webcam) to be disabled by default, as it doesn't work with the majority of their webcam chipsets Nope wrong, they just don't uncompress the data flow, which should be uncompressed in userland. The problem is that none of the userland tools do this yet. commonly in use. More importantly, it also conflicts with the resulting package built from the source contained in the pwc-source package (two different pwc.ko files placed in 2 different modules dir for the same kernel version... during modprobe, kernel picks their version always ). The third-party pwc module is supposed to provide pre-built modules for official kernels, which do the right with regard to packaging and diverts the kernel pwc module so everything works fine. If this is not the case, then it is a pwc bug, but i believe this not to be the case. It would save pwc users alot of time, as no kernel rebuild would be needed, and a pwc-modules package could work from a fresh install :) Just install the right package should do the trick. Having a userland library for uncompressing the data from the kernel pwc module and passing it transparently to the other userland apps would be the better solution though, not sure how this works though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
