Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Matthew == Matthew Wilcox [EMAIL PROTECTED] writes: Matthew On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote: Then let's see some acts. We (lkml) are not the ones with the percieved problem, or the ones discussing it. Matthew Actually, there are some legitimate problems with some of the Matthew files in the Linux source base. Last time this came up, the Matthew Acenic firmware was mentioned: Matthew http://lists.debian.org/debian-legal/2004/12/msg00078.html Matthew Seems to me that situation is still not resolved. Well whoever wrote that seems to have taken the stand that the openfirmware package was were the firmware came from. The person obviously made a lot of statements without bothering checking out the real source. Well it didn't come from there, I got it from Alteon under a written agreement stating I could distribute the image under the GPL. Since the firmware is simply data to Linux, hence keeping it under the GPL should be just fine. If someone wishes to post a patch adding a GPL header to the acenic_firmware.h file, fine with me. But beyond that I consider the case closed. Regards, Jes -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#278887: marked as done (does not include megaraid2 module on initrd, which makes booting fail after debian install on several Dell machines)
Your message dated Thu, 7 Apr 2005 09:37:48 +0200 with message-id [EMAIL PROTECTED] and subject line Closing PowerEdge 1850/megaraid2 initrd-tools bugs 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; 29 Oct 2004 17:12:06 + From [EMAIL PROTECTED] Fri Oct 29 10:12:06 2004 Return-path: [EMAIL PROTECTED] Received: from c2cpc2.camptocamp.com [128.179.66.3] by spohr.debian.org with smtp (Exim 3.35 1 (Debian)) id 1CNaII-0004JD-00; Fri, 29 Oct 2004 10:12:06 -0700 Received: (qmail 15320 invoked by uid 1000); 29 Oct 2004 17:12:03 - Date: Fri, 29 Oct 2004 19:12:03 +0200 From: Marc Fournier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: debian-installer Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: Package: installation-reports Debian-installer-version: 27 0ct 04, from http://cdimage.debian.org/pub/cdimage-testing/sid_d-i/i386/pre-rc2/sarge-i386-netinst.iso uname -a: Linux eiger 2.4.27 #2 SMP Fri Oct 29 19:09:45 CEST 2004 i686 GNU/Linux Date: thursday 28 october Method: How did you install? netinst CD What did you boot off? CD If network install, from where? ftp.de.debian.org Proxied? no Machine: DELL PowerEdge 2850 Processor: Intel(R) Xeon(TM) CPU 3.00GHz (2 processors with Hyper-Threading) Memory: 1033060 Root Device: SCSI (/dev/sda1) Root Size/partition table: Disk /dev/sda: 146.5 GB, 146548981760 bytes 255 heads, 63 sectors/track, 17816 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 * 1 122 979933+ 83 Linux /dev/sda2 123 244 979965 82 Linux swap /dev/sda3 245 17816 141147090 8e Linux LVM Output of lspci and lspci -n: eiger:~# lspci :00:00.0 Host bridge: Intel Corp. Server Memory Controller Hub (rev 09) :00:02.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port A0 (rev 09) :00:04.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port B0 (rev 09) :00:05.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port B1 (rev 09) :00:06.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Port C0 (rev 09) :00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #1 (rev 02) :00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #2 (rev 02) :00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI #3 (rev 02) :00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller (rev 02) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2) :00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (rev 02) :00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA 100 Storage Controller (rev 02) :01:00.0 PCI bridge: Intel Corp. 80332 [Dobson] I/O processor (rev 06) :01:00.2 PCI bridge: Intel Corp. 80332 [Dobson] I/O processor (rev 06) :02:0e.0 RAID bus controller: Dell PowerEdge Expandable RAID controller 4 (rev 06) :05:00.0 PCI bridge: Intel Corp. PCI Bridge Hub A (rev 09) :05:00.2 PCI bridge: Intel Corp. PCI Bridge Hub B (rev 09) :06:07.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller (rev 05) :07:08.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet Controller (rev 05) :08:00.0 PCI bridge: Intel Corp. PCI Bridge Hub A (rev 09) :08:00.2 PCI bridge: Intel Corp. PCI Bridge Hub B (rev 09) :0b:0d.0 VGA compatible controller: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE] eiger:~# lspci -n :00:00.0 0600: 8086:3590 (rev 09) :00:02.0 0604: 8086:3595 (rev 09) :00:04.0 0604: 8086:3597 (rev 09) :00:05.0 0604: 8086:3598 (rev 09) :00:06.0 0604: 8086:3599 (rev 09) :00:1d.0 0c03: 8086:24d2 (rev 02) :00:1d.1 0c03: 8086:24d4 (rev 02) :00:1d.2 0c03: 8086:24d7 (rev 02) :00:1d.7 0c03: 8086:24dd (rev 02) :00:1e.0 0604: 8086:244e (rev c2) :00:1f.0 0601: 8086:24d0 (rev 02) :00:1f.1 0101: 8086:24db (rev 02) :01:00.0 0604:
Bug#284230: marked as done (megaraid2 issue)
Your message dated Thu, 7 Apr 2005 09:37:48 +0200 with message-id [EMAIL PROTECTED] and subject line Closing PowerEdge 1850/megaraid2 initrd-tools bugs 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; 4 Dec 2004 19:14:51 + From [EMAIL PROTECTED] Sat Dec 04 11:14:51 2004 Return-path: [EMAIL PROTECTED] Received: from mail1.bluewin.ch [195.186.1.74] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1CafMp-0003WJ-00; Sat, 04 Dec 2004 11:14:51 -0800 Received: from mylap (62.202.199.125) by mail1.bluewin.ch (Bluewin AG 7.0.030.2) id 41863EE90034066F for [EMAIL PROTECTED]; Sat, 4 Dec 2004 19:14:19 + From: =?iso-8859-1?Q?Mike_M=FCller?= [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: megaraid2 issue Date: Sat, 4 Dec 2004 20:14:14 +0100 Message-ID: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Transfer-Encoding: Quoted-Printable Delivered-To: [EMAIL PROTECTED] X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-3.9 required=4.0 tests=BAYES_44,FROM_ENDS_IN_NUMS, HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: Package: debian-installer Version: testing (sarge) i386 build 1.12.2004 Hi sarge net-inst daily build from 1.12.2004: this version (as all versions before) of the new sarge installer can't be installed on a dell poweredge 2850 with megaraid2 controller. this bug was reported before from Zachary Schneider, see http://lists.debian.org/debian-boot/2004/10/msg02129.html actualy he mailed me that this issue should be fixed and because it's not, I decided to send the message again... the installer loads the megaraid2 module but after the reboot he decides to get the megaraid module instead of megaraid2, so the systems crashs with a kernel panic best regards mike m=FCller --- Received: (at 278887-done) by bugs.debian.org; 7 Apr 2005 07:37:53 + From [EMAIL PROTECTED] Thu Apr 07 00:37:53 2005 Return-path: [EMAIL PROTECTED] Received: from postfix4-2.free.fr [213.228.0.176] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DJRaK-0005ID-00; Thu, 07 Apr 2005 00:37:52 -0700 Received: from bee.dooz.org (levallois.dooz.org [81.57.180.178]) by postfix4-2.free.fr (Postfix) with ESMTP id 47BC9319290; Thu, 7 Apr 2005 09:37:50 +0200 (CEST) Received: by bee.dooz.org (Postfix, from userid 1000) id 3E14E6818A69; Thu, 7 Apr 2005 09:37:48 +0200 (CEST) Date: Thu, 7 Apr 2005 09:37:48 +0200 From: =?iso-8859-1?Q?Lo=EFc?= Minier [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], Debian kernel team debian-kernel@lists.debian.org Subject: Closing PowerEdge 1850/megaraid2 initrd-tools bugs Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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-Status: No, hits=-2.0 required=4.0 tests=BAYES_00,SORTED_RECIPS autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Hi, Yesterday, I successfully installed a PowerEdge 1850 server with megaraid2 (the same type of machine I described in #299055) with Debian Installer RC 3. This was to be expected as I couldn't reproduce the initrd problems I had in #299055 when I tried to debug it (something like 10 days ago). Reporters of bugs #278887, #282109, #282793, #284230, and #287019: please try with a newer initrd-tools or debian-installer or report any remaining problems I might have overseen! Regards, --=20 Lo=EFc Minier [EMAIL PROTECTED] Neutral President: I have no strong feelings one way or the other. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299055: marked as done (megaraid2/megaraid initrd problem on Dell PowerEdge 1850)
Your message dated Thu, 7 Apr 2005 09:37:48 +0200 with message-id [EMAIL PROTECTED] and subject line Closing PowerEdge 1850/megaraid2 initrd-tools bugs 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; 11 Mar 2005 13:14:20 + From [EMAIL PROTECTED] Fri Mar 11 05:14:20 2005 Return-path: [EMAIL PROTECTED] Received: from smtp8.wanadoo.fr [193.252.22.23] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1D9jy7-00046b-00; Fri, 11 Mar 2005 05:14:20 -0800 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0803.wanadoo.fr (SMTP Server) with ESMTP id 347231C001B3 for [EMAIL PROTECTED]; Fri, 11 Mar 2005 14:13:48 +0100 (CET) Received: from bee.dooz.org (LNeuilly-152_21-10-39.w82-127.abo.wanadoo.fr [82.127.73.39]) by mwinf0803.wanadoo.fr (SMTP Server) with ESMTP id D21321C001B2 for [EMAIL PROTECTED]; Fri, 11 Mar 2005 14:13:47 +0100 (CET) X-ME-UUID: [EMAIL PROTECTED] Received: by bee.dooz.org (Postfix, from userid 1000) id 8C4A06807600; Fri, 11 Mar 2005 14:13:47 +0100 (CET) Date: Fri, 11 Mar 2005 14:13:47 +0100 From: =?iso-8859-1?Q?Lo=EFc?= Minier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Installation report for Dell PowerEdge 1850 Message-ID: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Package: installation-reports Hi, INSTALL REPORT Debian-installer-version: Debian Installer RC2 disc1 for i386, from http://www.debian.org/devel/debian-installer/ uname -a: Linux fw 2.4.27-2-686-smp #1 SMP Thu Jan 20 11:02:39 JST 2005 i= 686 GNU/Linux Date: 2005/02/28 Method: I installed Debian with the bootable CD set. I did not use any n= etwork connection until the base system was installed. Then I setuped a classical ADSL connection via PPPoE and updated my Sarge system. Machine: PowerEdge 1850 Processor: Intel(R) Xeon(TM) CPU 2.80GHz (this machine is SMP capable, bu= t was bought wis a single CPU) Memory: 1 GB Root Device: /dev/mapper/vg0-root, this is an ext3 filesystem created on a LVM LV named root, in the LVM VG named vg0 of format LVM2 with PV /dev/sda2 /dev/sda is a RAID 1 array provided by module megaraid2 Root Size/partition table: here's the output of fdisk -l /dev/sda: Disk /dev/sda: 73.2 GB, 73274490880 bytes 255 heads, 63 sectors/track, 8908 cylinders Units =3D cylinders of 16065 * 512 =3D 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 1 31 248976 83 Linux /dev/sda2 32890871304502+ 8e Linux LVM Here's the output of mount -l -t ext3: /dev/mapper/vg0-root on / type ext3 (rw,errors=3Dremount-ro) /dev/sda1 on /boot type ext3 (rw) /dev/mapper/vg0-home on /home type ext3 (rw) /dev/mapper/vg0-srv on /srv type ext3 (rw) /dev/mapper/vg0-usr on /usr type ext3 (rw) /dev/mapper/vg0-var on /var type ext3 (rw) /dev/mapper/vg0-var--log on /var/log type ext3 (rw) Output of lspci and lspci -n: Here's the output of lspci: :00:00.0 Host bridge: Intel Corp. Server Memory Controller Hub (rev 0= 9) :00:02.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Po= rt A0 (rev 09) :00:04.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Po= rt B0 (rev 09) :00:05.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Po= rt B1 (rev 09) :00:06.0 PCI bridge: Intel Corp. Memory Controller Hub PCI Express Po= rt C0 (rev 09) :00:1d.0 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI= #1 (rev 02) :00:1d.1 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI= #2 (rev 02) :00:1d.2 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB UHCI= #3 (rev 02) :00:1d.7 USB Controller: Intel Corp. 82801EB/ER (ICH5/ICH5R) USB2 EHC= I Controller (rev 02) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev c2) :00:1f.0 ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Bridge (= rev 02) :00:1f.1 IDE interface: Intel Corp. 82801EB/ER (ICH5/ICH5R) Ultra ATA= 100 Storage Controller
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thursday 07 April 2005 09:25, Jes Sorensen wrote: [snip] I got it from Alteon under a written agreement stating I could distribute the image under the GPL. Since the firmware is simply data to Linux, hence keeping it under the GPL should be just fine. Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. Regards, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Le jeudi 07 avril 2005 10:04 +0200, David Schmitt a crit : Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. VHDL is a hardware description language. You don't code firmware in VHDL. Xav
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Arjan van de Ven [EMAIL PROTECTED] writes: On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote: On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote: I don't think you did get a rejection, a few people said that _they_ weren't going to do it, but if you want to then go ahead. I think people are just fed up of people bringing up the issue and then failing to do anything about it -- so prove them wrong ;-) Actually patches to add firmware loader support to tg3 got rejected. I think they will be accepted if they first introduce a transition period where tg3 will do request_firmware() and only use the built-in firmware if that fails. Second step is to make the built-in firmware a config option and then later on when the infrastructure matures for firmware loading/providing firmware it can be removed from the driver entirely. For tg3 a transition period shouldn't be needed as firmware loading is only needed on old/buggy hardware which is not the common case. Or to support advanced features which can be disabled. I am fairly certain in that case the firmware came from the bcm5701 broadcom driver for the tg3 which I think is gpl'd. So the firmware may legitimately be under the GPL. Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 10:17:15AM +0200, Xavier Bestel wrote: Le jeudi 07 avril 2005 à 10:04 +0200, David Schmitt a écrit : Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. VHDL is a hardware description language. You don't code firmware in VHDL. If the firmware, or part of it, is uploaded to a fpga you do (or Verilog instead of VHDL, same difference). OG. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Le jeudi 07 avril 2005 10:32 +0200, Olivier Galibert a crit : On Thu, Apr 07, 2005 at 10:17:15AM +0200, Xavier Bestel wrote: Le jeudi 07 avril 2005 10:04 +0200, David Schmitt a crit : Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. VHDL is a hardware description language. You don't code firmware in VHDL. If the firmware, or part of it, is uploaded to a fpga you do (or Verilog instead of VHDL, same difference). Oh yes, I was dense. Xav
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Eric W. Biederman wrote: Arjan van de Ven [EMAIL PROTECTED] writes: On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote: On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote: I don't think you did get a rejection, a few people said that _they_ weren't going to do it, but if you want to then go ahead. I think people are just fed up of people bringing up the issue and then failing to do anything about it -- so prove them wrong ;-) Actually patches to add firmware loader support to tg3 got rejected. I think they will be accepted if they first introduce a transition period where tg3 will do request_firmware() and only use the built-in firmware if that fails. Second step is to make the built-in firmware a config option and then later on when the infrastructure matures for firmware loading/providing firmware it can be removed from the driver entirely. For tg3 a transition period shouldn't be needed as firmware loading is only needed on old/buggy hardware which is not the common case. Or to support advanced features which can be disabled. TSO firmware is commonly used these days. I am fairly certain in that case the firmware came from the bcm5701 broadcom driver for the tg3 which I think is gpl'd. So the firmware may legitimately be under the GPL. It is. Jeff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291386: creates initrd that cannot use lvm2 volumes if both lvm2 and lvm10 are installed
On Tue, 05 Apr 2005 11:28:22 -0700, Steve Langasek wrote: tags 291386 unreproducible moreinfo thanks Hi Eric, I've tried to pin down this bug, but I find that the current version of initrd-tools builds correct (matching) initrds whether or not the lvm10 package is installed. Is it possible that the broken initrd was built with an old version of initrd-tools, or was somehow built on a system that did not have lvm2 installed? Can you still recreate this broken initrd problem if you install lvm10 on the system? What version of initrd-tools do you currently have installed? Thanks, -- Steve Langasek postmodern programmer Hi, It does occur all the same for me with initrd-tools 0.1.77... Do you have the root filesystem on lvm2 ? I attach the output of diff -rub /mnt/initrd1 /mnt/initrd2, with on /mnt/initrd1 a mount of the initrd without lvm10, and on /mnt/initrd2 a mount of the initrd with lvm10 I also verified that the initrd with lvm10 still does not boot my box properly... Regards. -- Eric Deplagne Only in /mnt/initrd1/bin: mkdir Only in /mnt/initrd1/bin2: mkdir diff: /mnt/initrd1/dev/cciss: No such file or directory diff: /mnt/initrd2/dev/cciss: No such file or directory File /mnt/initrd1/dev/console is a character special file while file /mnt/initrd2/dev/console is a character special file diff: /mnt/initrd1/dev/ida: No such file or directory diff: /mnt/initrd2/dev/ida: No such file or directory diff: /mnt/initrd1/dev/ide: No such file or directory diff: /mnt/initrd2/dev/ide: No such file or directory Only in /mnt/initrd2/dev: lvm diff: /mnt/initrd1/dev/mapper: No such file or directory diff: /mnt/initrd2/dev/mapper: No such file or directory diff: /mnt/initrd1/dev/md: No such file or directory diff: /mnt/initrd2/dev/md: No such file or directory File /mnt/initrd1/dev/null is a character special file while file /mnt/initrd2/dev/null is a character special file diff: /mnt/initrd1/dev/scsi: No such file or directory diff: /mnt/initrd2/dev/scsi: No such file or directory diff: /mnt/initrd1/dev/vg: No such file or directory diff: /mnt/initrd2/dev/vg: No such file or directory Only in /mnt/initrd1/etc: lvm Only in /mnt/initrd1/lib: libdevmapper.so.1.01 Only in /mnt/initrd1/lib: libdl.so.2 Only in /mnt/initrd2/lib: liblvm-10.so.1 Only in /mnt/initrd2/lib: lvm-10 Only in /mnt/initrd1/lib: lvm-200 diff -rub /mnt/initrd1/loadmodules /mnt/initrd2/loadmodules --- /mnt/initrd1/loadmodules1970-01-01 01:00:00.0 +0100 +++ /mnt/initrd2/loadmodules1970-01-01 01:00:00.0 +0100 @@ -29,4 +29,4 @@ modprobe -k via82cxxx /dev/null 21 modprobe -k ide-detect modprobe -k ide-disk -modprobe -k dm-mod +modprobe -k lvm-mod Only in /mnt/initrd2/sbin: vgscan diff -rub /mnt/initrd1/script /mnt/initrd2/script --- /mnt/initrd1/script 1970-01-01 01:00:00.0 +0100 +++ /mnt/initrd2/script 1970-01-01 01:00:00.0 +0100 @@ -1,16 +1,7 @@ ROOT=/dev/mapper/vg-root unload_unused_ide 'yes' pdc202xx_new adma100 aec62xx alim15x3 amd74xx atiixp cmd640 cmd64x cs5530 cy82c693 generic hpt34x hpt366 ns87415 opti621 pdc202xx_old piix rz1000 sc1200 serverworks siimage sis5513 slc90e66 triflex trm290 via82cxxx -mkdir /devfs/vg -mount_tmpfs /var -if [ -f /etc/lvm/lvm.conf ]; then -cat /etc/lvm/lvm.conf /var/lvm.conf -fi -mount_tmpfs /etc/lvm -if [ -f /var/lvm.conf ]; then -cat /var/lvm.conf /etc/lvm/lvm.conf -fi -mount -nt devfs devfs /dev +[ -c /dev/lvm ] || mknod /dev/lvm c 109 0 +mount_tmpfs /etc +vgscan vgchange -a y vg -umount /dev -umount -n /var -umount -n /etc/lvm +umount -n /etc signature.asc Description: Digital signature
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 05:34:56AM -0400, Jeff Garzik wrote: For tg3 a transition period shouldn't be needed as firmware loading is only needed on old/buggy hardware which is not the common case. Or to support advanced features which can be disabled. TSO firmware is commonly used these days. Because our TSO support has been totally broken for a long time? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Is there a serious NPTL problem with sarge?
Hi, a colleague observed crashes in some heavily multi-threaded Python applications. He is running Debian sarge with stock kernel 2.6.8-2-686. Using LD_ASSUME_KERNEL fixes the crash, so it seems to be an NPTL issue. (Maybe stupid) questions: - Is it relevant, whether Python is compiled on a system with 2.6 or 2.4 kernel? If so, how can I find out on which kernel the Debian package has been built? In http://mail.python.org/pipermail/python-bugs-list/2005-February/027693.html Martin von Loewis wrote: The real problem is that, apparently, linuxthreads and NPTL are not binary-compatible. So in fact, an installation with NPTL should be considered as a different operating system, and you cannot expect to move binaries from one operating system to another. Instead, you have to recompile the binaries. - Is the Debian stock 2.4 kernel patched to be compatible with NPTL? If not, isn't there a problem for some multi-threaded applications to switch between 2.4 and 2.6? (Note: AFAIK, RH, Mdk, and SuSE use some patch, at least Fedora seems to have nptl in the 2.4 kernel version number.) Thanks in advance for any clarification. Cheers, WB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303547: kernel-image-2.6.11-1-686-smp: MEGARAID_NEWGEN wanted
Package: kernel-image-2.6.11-1-686-smp Severity: wishlist Why it is not included? I compiled kernel 2.6.9 and 2.6.10 with this dirtier: CONFIG_MEGARAID_NEWGEN=y CONFIG_MEGARAID_MM=y CONFIG_MEGARAID_MAILBOX=y for LSI Logic / Symbios Logic MegaRAID 520 SCSI 320-1 Controller It is working on our production Internet server for a half of year without any problems. Did You plan include this driver into the package? -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.10 Locale: LANG=C, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote: Arjan van de Ven [EMAIL PROTECTED] writes: On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote: On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote: I don't think you did get a rejection, a few people said that _they_ weren't going to do it, but if you want to then go ahead. I think people are just fed up of people bringing up the issue and then failing to do anything about it -- so prove them wrong ;-) Actually patches to add firmware loader support to tg3 got rejected. I think they will be accepted if they first introduce a transition period where tg3 will do request_firmware() and only use the built-in firmware if that fails. Second step is to make the built-in firmware a config option and then later on when the infrastructure matures for firmware loading/providing firmware it can be removed from the driver entirely. For tg3 a transition period shouldn't be needed as firmware loading is only needed on old/buggy hardware which is not the common case. Or to support advanced features which can be disabled. I am fairly certain in that case the firmware came from the bcm5701 broadcom driver for the tg3 which I think is gpl'd. So the firmware may legitimately be under the GPL. So, where is the source for it ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303550: kernel-image-2.6.11-1-686: irq11 makes eth0 problems
Package: kernel-image-2.6.11-1-686
Version: 2.6.11-2
Severity: normal
hi all,
my network is not operational ; i did'nt had such problem with 2.6.10
I go back to 2.4 because i have also burning timeout problems with
2.6.10.
here is the corresponding /var/log/kern.log:
Apr 6 19:54:47 ile kernel: Linux version 2.6.11-1-686 ([EMAIL PROTECTED]) (gcc
version 3.3.5 (Debian 1:3.3.5-8)) #1 Sun Apr 3 06:20:48 EDT 2005
Apr 6 19:54:47 ile kernel: BIOS-provided physical RAM map:
Apr 6 19:54:47 ile kernel: BIOS-e801: - 0009f000
(usable)
Apr 6 19:54:47 ile kernel: BIOS-e801: 0010 - 0800
(usable)
Apr 6 19:54:47 ile kernel: 0MB HIGHMEM available.
Apr 6 19:54:47 ile kernel: 128MB LOWMEM available.
Apr 6 19:54:47 ile kernel: On node 0 totalpages: 32768
Apr 6 19:54:47 ile kernel: DMA zone: 4096 pages, LIFO batch:1
Apr 6 19:54:47 ile kernel: Normal zone: 28672 pages, LIFO batch:7
Apr 6 19:54:47 ile kernel: HighMem zone: 0 pages, LIFO batch:1
Apr 6 19:54:47 ile kernel: DMI not present.
Apr 6 19:54:47 ile kernel: Allocating PCI resources starting at 0800 (gap:
0800:f800)
Apr 6 19:54:47 ile kernel: Built 1 zonelists
Apr 6 19:54:47 ile kernel: Kernel command line: root=/dev/hda2
video=vesafb:ywrap,mtrr vga=791 noapic acpi=off ro
Apr 6 19:54:47 ile kernel: Local APIC disabled by BIOS -- you can enable it
with lapic
Apr 6 19:54:47 ile kernel: mapped APIC to d000 (01101000)
Apr 6 19:54:47 ile kernel: Initializing CPU#0
Apr 6 19:54:47 ile kernel: PID hash table entries: 1024 (order: 10, 16384
bytes)
Apr 6 19:54:47 ile kernel: Detected 300.711 MHz processor.
Apr 6 19:54:47 ile kernel: Using tsc for high-res timesource
Apr 6 19:54:47 ile kernel: Console: colour dummy device 80x25
Apr 6 19:54:47 ile kernel: Dentry cache hash table entries: 32768 (order: 5,
131072 bytes)
Apr 6 19:54:47 ile kernel: Inode-cache hash table entries: 16384 (order: 4,
65536 bytes)
Apr 6 19:54:47 ile kernel: Memory: 121952k/131072k available (1629k kernel
code, 8552k reserved, 716k data, 172k init, 0k highmem)
Apr 6 19:54:47 ile kernel: Checking if this processor honours the WP bit even
in supervisor mode... Ok.
Apr 6 19:54:47 ile kernel: Calibrating delay loop... 591.87 BogoMIPS
(lpj=295936)
Apr 6 19:54:47 ile kernel: Security Framework v1.0.0 initialized
Apr 6 19:54:47 ile kernel: SELinux: Disabled at boot.
Apr 6 19:54:47 ile kernel: Mount-cache hash table entries: 512 (order: 0, 4096
bytes)
Apr 6 19:54:47 ile kernel: CPU: After generic identify, caps: 0183f9ff
Apr 6 19:54:47 ile kernel: CPU: After vendor identify, caps: 0183f9ff
Apr 6 19:54:47 ile kernel: CPU: L1 I cache: 16K, L1 D cache: 16K
Apr 6 19:54:47 ile kernel: CPU: L2 cache: 512K
Apr 6 19:54:47 ile kernel: CPU: After all inits, caps: 0183f9ff
0040
Apr 6 19:54:47 ile kernel: Intel machine check architecture supported.
Apr 6 19:54:47 ile kernel: Intel machine check reporting enabled on CPU#0.
Apr 6 19:54:47 ile kernel: CPU: Intel Pentium II (Deschutes) stepping 02
Apr 6 19:54:47 ile kernel: Enabling fast FPU save and restore... done.
Apr 6 19:54:47 ile kernel: Checking 'hlt' instruction... OK.
Apr 6 19:54:47 ile kernel: checking if image is initramfs...it isn't (bad gzip
magic numbers); looks like an initrd
Apr 6 19:54:47 ile kernel: Freeing initrd memory: 4556k freed
Apr 6 19:54:47 ile kernel: NET: Registered protocol family 16
Apr 6 19:54:47 ile kernel: PCI: PCI BIOS revision 2.10 entry at 0xeb080, last
bus=0
Apr 6 19:54:47 ile kernel: PCI: Using configuration type 1
Apr 6 19:54:47 ile kernel: mtrr: v2.0 (20020519)
Apr 6 19:54:47 ile kernel: ACPI: Subsystem revision 20050211
Apr 6 19:54:47 ile kernel: ACPI: Interpreter disabled.
Apr 6 19:54:47 ile kernel: Linux Plug and Play Support v0.97 (c) Adam Belay
Apr 6 19:54:47 ile kernel: pnp: PnP ACPI: disabled
Apr 6 19:54:47 ile kernel: PnPBIOS: Scanning system for PnP BIOS support...
Apr 6 19:54:47 ile kernel: PnPBIOS: Found PnP BIOS installation structure at
0xc00ff020
Apr 6 19:54:47 ile kernel: PnPBIOS: PnP BIOS version 1.0, entry
0xec000:0x3d18, dseg 0xec000
Apr 6 19:54:47 ile kernel: PnPBIOS: 19 nodes reported by PnP BIOS; 19 recorded
by driver
Apr 6 19:54:47 ile kernel: PCI: Probing PCI hardware
Apr 6 19:54:47 ile kernel: PCI: Probing PCI hardware (bus 00)
Apr 6 19:54:47 ile kernel: PCI: Using IRQ router PIIX/ICH [8086/7110] at
:00:07.0
Apr 6 19:54:47 ile kernel: pnp: 00:01: ioport range 0xcf8-0xcff could not be
reserved
Apr 6 19:54:47 ile kernel: pnp: 00:01: ioport range 0x4d0-0x4d1 has been
reserved
Apr 6 19:54:47 ile kernel: pnp: 00:01: ioport range 0x3f0-0x3f1 has been
reserved
Apr 6 19:54:47 ile kernel: pnp: 00:01: ioport range 0x3f3-0x3f3 has been
reserved
Apr 6 19:54:47 ile kernel: pnp: 00:01: ioport range 0x3f7-0x3f7 has
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
David Schmitt wrote: On Thursday 07 April 2005 09:25, Jes Sorensen wrote: [snip] I got it from Alteon under a written agreement stating I could distribute the image under the GPL. Since the firmware is simply data to Linux, hence keeping it under the GPL should be just fine. Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. First, there is *NOT* any requirement in the GPL at all that requires making compilers available. Otherwise it would not be possible, for instance, have a Visual Basic GPL'd application. And yes, it is possible. Second, up until the present day I have personal experience with hardware producers that do not have enough money to buy expensive toolchains and used a lot of hand-work to code hardware parameters. So, at least for them, hand-hexcoding-days are still going. HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, 7 Apr 2005, Humberto Massa wrote: David Schmitt wrote: On Thursday 07 April 2005 09:25, Jes Sorensen wrote: [snip] I got it from Alteon under a written agreement stating I could distribute the image under the GPL. Since the firmware is simply data to Linux, hence keeping it under the GPL should be just fine. Then I would like to exercise my right under the GPL to aquire the source code for the firmware (and the required compilers, starting with genfw.c which is mentioned in acenic_firmware.h) since - as far as I know - firmware is coded today in VHDL, C or some assembler and the days of hexcoding are long gone. First, there is *NOT* any requirement in the GPL at all that requires making compilers available. Otherwise it would not be possible, for instance, have a Visual Basic GPL'd application. And yes, it is possible. Second, up until the present day I have personal experience with hardware producers that do not have enough money to buy expensive toolchains and used a lot of hand-work to code hardware parameters. So, at least for them, hand-hexcoding-days are still going. HTH, Massa Well it doesn't make any difference. If GPL has degenerated to where one can't upload microcode to a device as part of its initialization, without having the source that generated that microcode, we are in a lot of hurt. Intel isn't going to give their designs away. Last time I checked, GPL was about SOFTware, not FIRMware, and not MICROcode. If somebody has decided to rename FIRMware to SOFTware, then they need to complete the task and call it DORKware, named after themselves. This whole thread and gotten truly bizarre. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Richard == Richard B Johnson [EMAIL PROTECTED] writes: Richard Last time I checked, GPL was about SOFTware, not FIRMware, Richard and not MICROcode. Oh be real, there's no real difference between them and you know it. It's all about where the bits are stored and what they tend to do in a system design that makes the difference. This entire arguement is meaningless until someone posts the patches to move firmware out of the kernel, and until I see that, it's not worth re-hashing. And no, I don't have the time or knowledge to do this. John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Richard B. Johnson [EMAIL PROTECTED] writes: Last time I checked, GPL was about SOFTware, not FIRMware, and not MICROcode. If somebody has decided to rename FIRMware to SOFTware, Debian has undertaken to change the meaning of a whole lot of words, including software and free. This whole thread and gotten truly bizarre. Surprised? -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Richard B. Johnson wrote: Well it doesn't make any difference. If GPL has degenerated to where one can't upload microcode to a device as part of its initialization, without having the source that generated that microcode, we are in a lot of hurt. Intel isn't going to give their designs away. I don't recall anyone asking Intel to give theirs designs away. This thread is about: 1. (mainly) some firmware hexdumps present in the kernel source tree are either expicitly marked as being GPL'd or unmarked, in which case one would assume that they would be GPL'd; 1a. this means that those firmware hexdumps are not legally distributable by any person besides the firmware copyright holder, because any other person could not comply with the terms of the Section 3 of the GPL (IOW, a third party cannot give you a source code they don't have); 1b. [1a], for its turn, means that the current pristine kernel tree is not legally distributable and that any distributor is an easy prey for lawyer attacks. 2. (collaterally) some firmware hexdumps present in the kernel source tree are marked with (C) Holder All Rights Reserved; 2a. copyright law FORBIDS anyone to distribute such pieces of information without proper authorization. 3. (corolary) for each of the problematic hexdumps, the following steps should be taken: 3a. the copyright holder should be asked for the source code to the firmware -- if they do this, it would be great for a lot of Free Software reasons; 3b. if the copyright holder declines, it should be asked for a license to freely redistribute the firmware; and 3c. if the copyright holder declines, the firmware *must* be yanked from the pristine kernel tree; 3d. furthermore, all of this *should* be properly documented, IMHO, both in a centralized file, and in the file where the firmware hexdump appears. Last time I checked, GPL was about SOFTware, not FIRMware, and not MICROcode. If somebody has decided to rename FIRMware to SOFTware, then they need to complete the task and call it DORKware, named after themselves. Last time I checked, the GPL was a COPYRIGHT LICENSE and, as such, not about anything in particular. Yes, it was idealized to be used for the licensing of computer programs and libraries. OTOH, many works of many other kinds (music, literary works, etc) were licensed under the GPL. This whole thread and gotten truly bizarre. Nah, it has a good reason to exist... With the passing of time, Debian, that is supposed to be a Free Software OS, is depending more and more of non-Free components. And yes, as it is today, the pristine kernel tree is non-free. Regards, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Le jeudi 07 avril 2005 à 09:03 -0400, Richard B. Johnson a écrit : Well it doesn't make any difference. If GPL has degenerated to where one can't upload microcode to a device as part of its initialization, without having the source that generated that microcode, we are in a lot of hurt. Intel isn't going to give their designs away. The GPL doesn't forbid that. The GPL forbids to put this microcode directly in the same binary as the GPL code. Of course, nothing forbids some GPL'ed code to take a binary elsewhere and to upload it into the hardware. At least that's my opinion; AIUI, Sven Luther believes it is possible if the firmware has a decent (but not necessarily free) license. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Bug#294349: marked as done (kernel-image-2.6.10-1-686: Unable to mount USB2.0 drives with default .config)
Your message dated Thu, 7 Apr 2005 16:36:52 +0200 (CEST) with message-id [EMAIL PROTECTED] and subject line Solved in 2.6.11 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; 9 Feb 2005 10:52:37 + From [EMAIL PROTECTED] Wed Feb 09 02:52:37 2005 Return-path: [EMAIL PROTECTED] Received: from web42004.mail.yahoo.com [66.218.93.172] by spohr.debian.org with smtp (Exim 3.35 1 (Debian)) id 1CypSX-0006oN-00; Wed, 09 Feb 2005 02:52:37 -0800 Received: (qmail 47703 invoked by uid 60001); 9 Feb 2005 10:52:06 - Message-ID: [EMAIL PROTECTED] Received: from [161.116.81.18] by web42004.mail.yahoo.com via HTTP; Wed, 09 Feb 2005 11:52:06 CET Date: Wed, 9 Feb 2005 11:52:06 +0100 (CET) From: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Subject: kernel-image-2.6.10-1-686: Unable to mount USB2.0 drives with default .config To: [EMAIL PROTECTED] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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-Status: No, hits=-6.4 required=4.0 tests=BAYES_00,HAS_PACKAGE, NO_REAL_NAME autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Package: kernel-image-2.6.10-1-686 Version: 2.6.10-4 Severity: normal Dear Debian Kernel Developers, Using kernel-image-2.6.10-i-686 from Debian, I am not able to use my USB 2.0 Flash drive. Upon plugging in the USB 2.0 Flash Drive, I am not able to mount it, and dmesg shows errors: usb 5-5: new high speed USB device using ehci_hcd and address 3 usb 3-1: new full speed USB device using uhci_hcd and address 2 usb 3-1: device descriptor read/64, error -71 usb 3-1: device descriptor read/64, error -71 As a workaround I can remove the module ehci-hcd $ modprobe -r ehci-hcd then the module uhci-hcd takes over, and the drive works correctly. I have checked, that compiling a new kernel, with the following options disabled: CONFIG_USB_EHCI_SPLIT_ISO=n CONFIG_USB_EHCI_ROOT_HUB_TT=n (the kernel-image-2.6.10 package from Debian has CONFIG_USB_EHCI_SPLIT_ISO=y CONFIG_USB_EHCI_ROOT_HUB_TT=y ) the new compiled kernel has no problems seeing and mounting the USB Flash drive. Since the above options are marked EXPERIMENTAL: config USB_EHCI_SPLIT_ISO bool Full speed ISO transactions (EXPERIMENTAL) depends on USB_EHCI_HCD EXPERIMENTAL default n ---help--- This code is new and hasn't been used with many different EHCI or USB 2.0 transaction translator implementations. It should work for ISO-OUT transfers, like audio. config USB_EHCI_ROOT_HUB_TT bool Root Hub Transaction Translators (EXPERIMENTAL) depends on USB_EHCI_HCD EXPERIMENTAL ---help--- Some EHCI chips have vendor-specific extensions to integrate transaction translators, so that no OHCI or UHCI companion controller is needed. It's safe to say y even if your controller doesn't support this feature. This supports the EHCI implementation from ARC International. I would suggest to compile the Debian Kernel images with the above options disabled. Best regards, and thank you for your work. Jaume -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing'), (105, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.9-2-686-smp Locale: LANG=C, [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages kernel-image-2.6.10-1-686 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii initrd-tools 0.1.77 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo __ Renovamos el Correo Yahoo!: ¡250 MB GRATIS! Nuevos servicios, más seguridad http://correo.yahoo.es --- Received: (at 294349-done) by bugs.debian.org; 7 Apr 2005 14:37:23 + From [EMAIL PROTECTED] Thu Apr 07 07:37:23 2005 Return-path: [EMAIL PROTECTED] Received: from web42002.mail.yahoo.com [66.218.93.170] by spohr.debian.org with smtp (Exim 3.35 1 (Debian)) id 1DJY8J-0003U2-00; Thu, 07 Apr 2005 07:37:23 -0700 Received: (qmail 38316 invoked by uid 60001); 7 Apr 2005 14:36:52 - Message-ID: [EMAIL PROTECTED] Received:
Bug#303569: please include CONFIG_SOUND_AWE32_SYNTH in kernel config
Package: kernel-image-2.6.8-2-686 Version: 2.6.8-13 The configuration of the stock Debian kernels does not include CONFIG_SOUND_AWE32_SYNTH. It should. Not all SB AWE32 sound cards work with ALSA (cf. a post which I recently made to the alsa-user mailing-list, which will be available as soon as moderated) whereas the OSS driver generally works. So it should not be disabled. -- David A. Madore ([EMAIL PROTECTED], http://www.eleves.ens.fr:8080/home/madore/ ) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Oliver Neukum wrote: As this has been discussed numerous times and consensus never achieved and is unlikely to be achieved, I suggest that you keep this discussion internal to Debian until at least you have patches which can be evaluated and discussed. Until then Debian may do to its kernel whatever it pleases and should be prepared to explain to its users why it removed or altered drivers. Regards Oliver Hi, Oliver. You seemed to answer my e-mail without reading it; what I was explaining in it was: this is not a matter of patches, but of asking Where are the copyrights notices, Who are the copyright owners, and Which license are the firmwares under, and AFTER that, patching what should be patched. Those three questions (Where, Who, Which) can only be answered by the kernel maintainers, and this is in *NO* way a Debian-only discussion. As I mentioned before, kernel.org kernel tree is, as of today, non-free and undistributable IMHO. HTH, Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Am Donnerstag, 7. April 2005 16:30 schrieb Humberto Massa: I don't recall anyone asking Intel to give theirs designs away. This thread is about: 1. (mainly) some firmware hexdumps present in the kernel source tree are either expicitly marked as being GPL'd or unmarked, in which case one would assume that they would be GPL'd; 1a. this means that those firmware hexdumps are not legally distributable by any person besides the firmware copyright holder, because any other person could not comply with the terms of the Section 3 of the GPL (IOW, a third party cannot give you a source code they don't have); As this has been discussed numerous times and consensus never achieved and is unlikely to be achieved, I suggest that you keep this discussion internal to Debian until at least you have patches which can be evaluated and discussed. Until then Debian may do to its kernel whatever it pleases and should be prepared to explain to its users why it removed or altered drivers. Regards Oliver -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Am Donnerstag, 7. April 2005 17:01 schrieb Humberto Massa: Oliver Neukum wrote: As this has been discussed numerous times and consensus never achieved and is unlikely to be achieved, I suggest that you keep this discussion internal to Debian until at least you have patches which can be evaluated and discussed. Until then Debian may do to its kernel whatever it pleases and should be prepared to explain to its users why it removed or altered drivers. Regards Oliver Hi, Oliver. You seemed to answer my e-mail without reading it; what I was explaining in it was: this is not a matter of patches, but of asking Where are the copyrights notices, Who are the copyright owners, and Which license are the firmwares under, and AFTER that, patching what should be patched. Those three questions (Where, Who, Which) can only be answered by the kernel maintainers, and this is in *NO* way a Debian-only discussion. As I mentioned before, kernel.org kernel tree is, as of today, non-free and undistributable IMHO. Those who care got you after the second message at the latest. Anything more just annoys people. Some even pay for their online time. Who doesn't care will not start caring. Your oppinion on that matter frankly is exactly that. If you care that deeply about it you'll have to track down copyright holders yourself. Good luck. Regards Oliver -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#282793: Closing PowerEdge 1850/megaraid2 initrd-tools bugs
Am Donnerstag 07 April 2005 09:37 schrieb Loïc Minier: Hi, Yesterday, I successfully installed a PowerEdge 1850 server with megaraid2 (the same type of machine I described in #299055) with Debian Installer RC 3. This was to be expected as I couldn't reproduce the initrd problems I had in #299055 when I tried to debug it (something like 10 days ago). Reporters of bugs #278887, #282109, #282793, #284230, and #287019: please try with a newer initrd-tools or debian-installer or report any remaining problems I might have overseen! Regards, Hi, I reported bug #282793. I retried an installation with a PE2850 which has the same SCSI controller in it and with sarge-i386-netinst.iso (build from 20050403). I can also say my bug is fixed. But when booting linux26, hardware detection fails. No disks are found. I can report another bug, if anybody considers this as important. Kind regards, Timo
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Sven Luther [EMAIL PROTECTED] writes: On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote: For tg3 a transition period shouldn't be needed as firmware loading is only needed on old/buggy hardware which is not the common case. Or to support advanced features which can be disabled. I am fairly certain in that case the firmware came from the bcm5701 broadcom driver for the tg3 which I think is gpl'd. So the firmware may legitimately be under the GPL. So, where is the source for it ? The GPL'd driver that broadcom distributes. The history of tg3.c is that broadcom's bcm57xx driver drove the hardware correctly but not linux so it was rewritten from scratch. Beyond that you need to talk to Broadcom. But if the originator of the bits distributes them gpl from a redistribution point the kernel is fine. It sounds like you are now looking at the question of are the huge string of hex characters the preferred form for making modifications to firmware. Personally I would be surprised but those hunks are small enough it could have been written in machine code. So I currently have no reason to believe that anything has been done improperly with that code. Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 05:46:27AM -0600, Eric W. Biederman wrote: Sven Luther [EMAIL PROTECTED] writes: On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote: For tg3 a transition period shouldn't be needed as firmware loading is only needed on old/buggy hardware which is not the common case. Or to support advanced features which can be disabled. I am fairly certain in that case the firmware came from the bcm5701 broadcom driver for the tg3 which I think is gpl'd. So the firmware may legitimately be under the GPL. So, where is the source for it ? The GPL'd driver that broadcom distributes. The history of tg3.c is that broadcom's bcm57xx driver drove the hardware correctly but not linux so it was rewritten from scratch. Ok, thanks for that clarification. Beyond that you need to talk to Broadcom. But if the originator of the bits distributes them gpl from a redistribution point the kernel is fine. As you may know, i have contacted Broadcom about this issue, the information passed from the driver support contact to their linux developers, but i have not heard from them yet. It sounds like you are now looking at the question of are the huge string of hex characters the preferred form for making modifications to firmware. Personally I would be surprised but those hunks are small enough it could have been written in machine code. Yep, i also think it is in broadcom's best interest to modify the licencing text accordyingly, since i suppose someone could technicaly come after them legally to obtain said source code to this firmware. Unprobable though. So I currently have no reason to believe that anything has been done improperly with that code. Well, it all depends if you consider this firmware blob as software, which i feel it is without doubt, or we have not the same definition of software, i.e., the program which runs on the hardware, or not. We cannot claim this is data, since there should be at least some kind of executable code in it, independenlty of the fact that we claim that data is also software. Thanks for the info, i will add it to the Wiki. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303640: kernel-image-2.6.8-10-amd64-k8: Xfree86 fails to find a VESA chipset
Subject: kernel-image-2.6.8-10-amd64-k8: Xfree86 fails to find a VESA chipset Package: kernel-image-2.6.8-10-amd64-k8 Version: 2.6.8-11 Severity: important *** Please type your report below this line *** Hi, I just installed Debian testing on a new Athlon64/nForce4 machine. This machine boots correctly with the default i386 (2.6.8-2) kernel installed by d-i, and XFree86 correctly connects to a VESA chip. Nevertheless, if I boot on the 2.6.8-10-amd64-k8 kernel, then XFree86 can not find a VESA interface anymore, and thus fails to provide the graphic mode. - /etc/X11/XF86Config-4 was not changed - The graphic chipset is a GeForce 6600GT, integrated on the Gigabyte NX6600 128MB Vivo board. The complete /var/log/XFree86.0.log file is sent as an attachment. Regards, David. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-386 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages kernel-image-2.6.8-10-amd64-k8 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii initrd-tools 0.1.77 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo -- no debconf information XFree86 Version 4.3.0.1 (Debian 4.3.0.dfsg.1-12.0.1 20050223080930 [EMAIL PROTECTED]) Release Date: 15 August 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.6.9 i686 [ELF] Build Date: 23 February 2005 This version of XFree86 has been extensively modified by the Debian Project, and is not supported by the XFree86 Project, Inc., in any way. Bugs should be reported to the Debian Bug Tracking System; see URL: http://www.debian.org/Bugs/Reporting . We strongly encourage the use of the reportbug package and command to ensure that bug reports contain as much useful information as possible. Before filing a bug report, you may want to consult the Debian X FAQ: XHTML version: file:///usr/share/doc/xfree86-common/FAQ.xhtml plain text version: file:///usr/share/doc/xfree86-common/FAQ.gz Module Loader present OS Kernel: Linux version 2.6.8-10-amd64-k8 ([EMAIL PROTECTED]) (gcc versión 3.4.4 20041218 (prerelease) (Debian 3.4.3-6)) #1 Sun Jan 30 03:54:49 CET 2005 Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Thu Apr 7 21:16:29 2005 (==) Using config file: /etc/X11/XF86Config-4 (==) ServerLayout Default Layout (**) |--Screen Default Screen (0) (**) | |--Monitor ViewSonic P95f+ (**) | |--Device Generic Video Card (**) |--Input Device Generic Keyboard (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout fr (**) XKB: layout: fr (==) Keyboard: CustomKeycode disabled (**) |--Input Device Configured Mouse (**) |--Input Device Generic Mouse (WW) The directory /usr/lib/X11/fonts/cyrillic does not exist. Entry deleted from font path. (WW) The directory /usr/lib/X11/fonts/CID does not exist. Entry deleted from font path. (**) FontPath set to unix/:7100,/usr/lib/X11/fonts/misc,/usr/lib/X11/fonts/100dpi/:unscaled,/usr/lib/X11/fonts/75dpi/:unscaled,/usr/lib/X11/fonts/Type1,/usr/lib/X11/fonts/Speedo,/usr/lib/X11/fonts/100dpi,/usr/lib/X11/fonts/75dpi (==) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (++) using VT number 7 (WW) Open APM failed (/dev/apm_bios) (No such file or directory) (II) Module ABI versions: XFree86 ANSI C Emulation: 0.2 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.4 XFree86 Server Extension : 0.2 XFree86 Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.3.0.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.3.0.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 10de,005e card 1462,7125 rev a3 class 05,80,00 hdr 00 (II) PCI: 00:01:0: chip 10de,0050 card 1462,7125 rev a3 class 06,01,00 hdr 80 (II) PCI: 00:01:1: chip 10de,0052 card 1462,7125 rev a2 class 0c,05,00 hdr 80 (II) PCI: 00:02:0: chip 10de,005a card 1462,7125 rev a2 class 0c,03,10 hdr 80 (II) PCI: 00:02:1: chip 10de,005b card 1462,7125 rev a3 class 0c,03,20 hdr 80 (II) PCI: 00:04:0: chip 10de,0059 card
Re: Is there a serious NPTL problem with sarge?
[W. Borgert] - Is it relevant, whether Python is compiled on a system with 2.6 or 2.4 kernel? If so, how can I find out on which kernel the Debian package has been built? Might or might not be relevant - depends on whether the python build scripts attempt to detect the kernel capabilities at compile time. (Which is a broken thing to do, but I can see why people occasionally feel it's a necessary workaround for other problems.) The glibc in unstable / testing certainly can handle compiling programs for NPTL, no matter what kernel you're running. If python itself doesn't store config info about the details of the system it was compiled on, you probably can't get that info at all. Packages are built by maintainers on their own systems, or on Debian systems, or autobuilt by the autobuilder network. These machines could be running any kernel. Martin von Loewis wrote: The real problem is that, apparently, linuxthreads and NPTL are not binary-compatible. I just read that thread - the issue he's referring to only affects your apps if they're compiled against a different version of glibc than your libraries. Which won't be the case here. - Is the Debian stock 2.4 kernel patched to be compatible with NPTL? If not, isn't there a problem for some multi-threaded applications to switch between 2.4 and 2.6? No, it's not. Multithreaded apps that want to support kernel 2.4 must be prepared to accept the quirks of the old linuxthreads system. Peter signature.asc Description: Digital signature
Bug#296963: Also applies to 2.6.8-2-k7, 2.6.11-1-k7
Package: kernel-image-2.6.10-1-k7 Version: 2.6.10-6 Followup-For: Bug #296963 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 clone 296963 -1 -2 reassign -1 kernel-image-2.6.8-2-k7 reassign -2 kernel-image-2.6.11-1-k7 merge 296963 -1 -2 thanks I've tested this on k-i-2.6.8-2-k7 and k-i-2.6.11-1-k7 and still happens. thanks Luca - -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.11-1-k7 Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) Versions of packages kernel-image-2.6.10-1-k7 depends on: ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii initrd-tools 0.1.77 tools to create initrd image for p ii module-init-tools 3.2-pre1-2 tools for managing Linux kernel mo - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCVZ0/CUBS9R84wJERAhieAKDC7fP5GuarsLKKtCYaszpq8INw/gCglTSQ nBSoDFIyU8F19M96k6AXUXo= =LPW9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 04:05:07PM +0200, Josselin Mouette wrote: Le lundi 04 avril 2005 à 21:32 +0200, Adrian Bunk a écrit : On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote: On Apr 04, Greg KH [EMAIL PROTECTED] wrote: What if we don't want to do so? I know I personally posted a solution Then probably the extremists in Debian will manage to kill your driver, like they did with tg3 and others. And as they are doing with e.g. the complete gcc documentation. No documentation for the C compiler (not even a documentation of the options) will be neither fun for the users of Debian nor for the Debian maintainers - but it's the future of Debian... You are mixing apples and oranges. The fact that the GFDL sucks has nothing to do with the firmware issue. With the current situation of firmwares in the kernel, it is illegal to redistribute binary images of the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still be willing to distribute such binary images, but it isn't our problem. ... It's a grey area. debian-legal did pick one of the possible opinions on this matter. The similarities between the GFDL and the firmware discussion can be described with the following two questions: Is it true, that the removal of much of the documentation in Debian is scheduled soon because it's covered by the GFDL, that this is called an editorial change, and that Debian doesn't actually care that this will e.g. remove all documentation about available options of the standard C compiler used by and shipped with Debian? Is it true, that Debian will leave users with hardware affected by the firmware problem without a working installer in Debian 3.1? The point is simply, that Debian does more and more look dogmatic at it's definition of free software without caring about the effects to it's users. As a contrast, read the discussion between Christoph and Arjan in a part of this thread how to move firmware out of kernel drivers without problems for the users. This might not happen today, but it's better for the users. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#270376: PCMCIA Nic stops working after upgrading to 2.6.6/7/8
On Tuesday 05 April 2005 08:56, Jefferson Cowart wrote:
Sorry for the delay in sending this. I ended up getting back later than
expected. In any case the hexdumps are below. Please let me know if you need
anything else.
also sorry for the delay :)
Under 2.6.5-bk1
===
(/proc/bus/pci/00/07.0)
000 104c ac17 0007 0210 0002 0607 a820 0082
010 8000 000c 00a0 0200 0100 b004 1000
020 f000 103f 1040 f000 107f 4400
030 44fc 4800 48fc 010a 0540
040 0001
050
*
080 7020 2800 3822 0ba4
^
there you go. the intrtie bit is set. this means that both functions
use INTA to signal the interrupts. but the BIOS is broken and assigned
a different irq to function 1 compared to function 0.
so the reason it broke when the irq-routing patch was merged is that
irqs are actually probed to see if they work or if the routing needs
some tuning...
the attached patch should fix it. it's untested 'cos i don't have a
laptop with TI bridge anymore...but it's simple
rgds
-daniel
-
[PATCH] yenta TI: align irq of func1 to func0 if INTRTIE is set
make sure that if the INTRTIE bit is set both functions of the
cardbus bridge use the same IRQ before doing any probing...
[ yes i hate the TI bridges for the fact that they are very flexible
so that so many BIOS vendors get it wrong. ]
Signed-off-by: Daniel Ritz [EMAIL PROTECTED]
--- 1.22/drivers/pcmcia/ti113x.h2005-03-11 21:32:12 +01:00
+++ edited/drivers/pcmcia/ti113x.h 2005-04-07 23:14:40 +02:00
@@ -442,6 +442,25 @@
}
+/* changes the irq of func1 to match that of func0 */
+static int ti12xx_align_irqs(struct yenta_socket *socket, int *old_irq)
+{
+ struct pci_dev *func0;
+
+ /* find func0 device */
+ func0 = pci_get_slot(socket-dev-bus, socket-dev-devfn ~0x07);
+ if (!func0)
+ return 0;
+
+ if (old_irq)
+ *old_irq = socket-cb_irq;
+ socket-cb_irq = socket-dev-irq = func0-irq;
+
+ pci_dev_put(func0);
+
+ return 1;
+}
+
/*
* ties INTA and INTB together. also changes the devices irq to that of
* the function 0 device. call from func1 only.
@@ -449,26 +468,22 @@
*/
static int ti12xx_tie_interrupts(struct yenta_socket *socket, int *old_irq)
{
- struct pci_dev *func0;
u32 sysctl;
+ int ret;
sysctl = config_readl(socket, TI113X_SYSTEM_CONTROL);
if (sysctl TI122X_SCR_INTRTIE)
return 0;
- /* find func0 device */
- func0 = pci_get_slot(socket-dev-bus, socket-dev-devfn ~0x07);
- if (!func0)
+ /* align */
+ ret = ti12xx_align_irqs(socket, old_irq);
+ if (!ret)
return 0;
- /* change the interrupt to match func0, tie 'em up */
- *old_irq = socket-cb_irq;
- socket-cb_irq = socket-dev-irq = func0-irq;
+ /* tie */
sysctl |= TI122X_SCR_INTRTIE;
config_writel(socket, TI113X_SYSTEM_CONTROL, sysctl);
- pci_dev_put(func0);
-
return 1;
}
@@ -489,7 +504,7 @@
*/
static void ti12xx_irqroute_func1(struct yenta_socket *socket)
{
- u32 mfunc, mfunc_old, devctl;
+ u32 mfunc, mfunc_old, devctl, sysctl;
int pci_irq_status;
mfunc = mfunc_old = config_readl(socket, TI122X_MFUNC);
@@ -497,6 +512,11 @@
printk(KERN_INFO Yenta TI: socket %s, mfunc 0x%08x, devctl 0x%02x\n,
pci_name(socket-dev), mfunc, devctl);
+ /* if IRQs are configured as tied, align irq of func1 with func0 */
+ sysctl = config_readl(socket, TI113X_SYSTEM_CONTROL);
+ if (sysctl TI122X_SCR_INTRTIE)
+ ti12xx_align_irqs(socket, NULL);
+
/* make sure PCI interrupts are enabled before probing */
ti_init(socket);
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#270376: PCMCIA Nic stops working after upgrading to 2.6.6/7/8
On Thu, 07 Apr 2005, Daniel Ritz wrote: On Tuesday 05 April 2005 08:56, Jefferson Cowart wrote: Sorry for the delay in sending this. I ended up getting back later than expected. In any case the hexdumps are below. Please let me know if you need anything else. also sorry for the delay :) Under 2.6.5-bk1 === (/proc/bus/pci/00/07.0) 000 104c ac17 0007 0210 0002 0607 a820 0082 010 8000 000c 00a0 0200 0100 b004 1000 020 f000 103f 1040 f000 107f 4400 030 44fc 4800 48fc 010a 0540 040 0001 050 * 080 7020 2800 3822 0ba4 ^ there you go. the intrtie bit is set. this means that both functions use INTA to signal the interrupts. but the BIOS is broken and assigned a different irq to function 1 compared to function 0. so the reason it broke when the irq-routing patch was merged is that irqs are actually probed to see if they work or if the routing needs some tuning... the attached patch should fix it. it's untested 'cos i don't have a laptop with TI bridge anymore...but it's simple rgds -daniel thanks a lot for your explenations and the provided patch. i need some sleep right now, but i'll build a kernel tommorow for jefferson - bug reporter - to test. a++ maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295422: e2fsprogs for Sarge
On Thu, Apr 07, 2005 at 12:33:53PM +0900, Horms wrote: Normally this would just be a matter of waiting for the new versions to filter down to testing, but as part of the attempts to get sarge released, testing was fozen a little while ago, so changes aren't propogating, while unstable marches on (bit of a process problem is an understatement, but lets save that discussion for another day). Indeed, the real problem, but what can we do? Nothing, for the sarge release... The real problem for Debian is that we need a to update e2fsprogs in testing, but we are unsure of the best version to use. I notice that the version in testing is quite a lot newer, e2fsprogs 1.37-1. This presents two issues, firstly I've been advised by Steve Langasek that small incremental changes are quite desirable at this point. And secondly, there is a pending issue with e2fsprogs 1.37-1 wherby mke2fs fails on ia64, bug 302200. Correct, although that patch is really minor (it's a one line patch to add #include stdlib.h), and I will be uploading it shortly. I've just been completely swamped the past few weeks trying to get everything done before I head off to Annaheim for Usenix Annual Tech in 3 days and then from there, to Linux.conf.au In short, we are looking for your advice on which version of e2fsprogs to include in sarge. My understanding is that appart from this issue, 0.35-6 seems to be quite fine. Here are some ideas that I have. I am not sure of the versining gymnastics that need to occur to make this happen, perhaps none, Steve Langasek can advise. * Inculde 0.35-7 verbatim in sarge * Include 0.35-8 verbatim in sarge * Include 0.35-6 + just the fix for 302200 in sarge * Include 1.37-2 (as yet unreleased) in sarge this would require some considerable review and is thus likely the slowest option. There are a whole bunch of changes besides this one that probably ought to be merged into 0.35-6, and I was assuming that the Release Team wouldn't permit anything other than backporting fixes into 0.35-6, because of the small fixes requirements. The problem is that there more than a few rather critical bug fixes and/or improvements that have taken place since 0.35-6. Some of the ones which I'd most like to get into e2fsprogs 0.35-6 include: * Fix a double-free problem in resize2fs. (Red Hat Bugzilla #132707) * Make sure e2fsck doesn't crash if /proc/acpi/ac_adapter does not exist * Add -s option to e2image which scrambles directory entries when making raw image files * Add support for online resizing via the resize inode, including allowing e2fsck to work correctly on filesystems created on Fedora Core 3 or RHEL 4 systems. * Make sure that we don't write garbage when writing a large inode. The first two are bugs that result in core dumps in resize2fs and e2fsck, respectively, with the second guaranting a crash and preventing a system from booting if /proc is not mounted. The 3rd is makes it a lot easier from a suppor standpoint since it allows me to get compressed, metadata-only e2image dumps from users when debugging a problem, since in some cases the directory names might reveal what kind of p0rn they might be collecitng, which might make them uncomfortable. And the 4th is important for interoperability with newer Linux distributions. (But the changes to support this are quite a bit larger than the other patches). Other potential patches to consider including are: * Fixed a bug in e2fsck so it would notice if a file with an extended attribute block was exactly 2**32 blocks, such that i_blocks wrapped to zero. * Force compile_et and mk_cmds to use /usr/bin/awk so that we will work on any Debian system regardless of which version of awk is installed. (Closes: #299341) (Otherwise you can't build packages that depend on compile_et, such as Kerberos and Zephyr on platforms that use a different version of awk than the one used to build the e2fsprogs .debs, because of autoconf issues) I just haven't had the time to backport the patches into 0.35-6 yet, and then more importantly, test and build an dpkg on a testing system and then upload it to T-P-U. So what needs to be done? 1. Extract the necessasry changes out of my Bitkeeper repository 2. Run the proposed changes by the release team to make sure they are OK with them. 3. Integrate them with e2fsprogs 0.35-6.1 (probably using a set of quilt-managed patches that are applied via dpatch) 4. Build on a testing system to avoid accidental dependencies on sid. Anyone interested in helping me, since it's clear I don't have time to do this until after I get back from Linux.conf.au and a vacation in New Zealand? (i.e., in early May). I can do step #1, and if someone is willing to do the rest of the steps, that would be great. I'd ask whoever did this to send me
Bug#270376: PCMCIA Nic stops working after upgrading to 2.6.6/7/8
Thanks for the response. maximilian attems - Let me know when the kernel is built and I'll go ahead and try that. Thanks Jefferson Cowart [EMAIL PROTECTED] -Original Message- From: maximilian attems [mailto:[EMAIL PROTECTED] Sent: Thursday, April 07, 2005 16:26 To: Daniel Ritz Cc: Jefferson Cowart; 'Dominik Brodowski'; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Bug#270376: PCMCIA Nic stops working after upgrading to 2.6.6/7/8 On Thu, 07 Apr 2005, Daniel Ritz wrote: On Tuesday 05 April 2005 08:56, Jefferson Cowart wrote: Sorry for the delay in sending this. I ended up getting back later than expected. In any case the hexdumps are below. Please let me know if you need anything else. also sorry for the delay :) Under 2.6.5-bk1 === (/proc/bus/pci/00/07.0) 000 104c ac17 0007 0210 0002 0607 a820 0082 010 8000 000c 00a0 0200 0100 b004 1000 020 f000 103f 1040 f000 107f 4400 030 44fc 4800 48fc 010a 0540 040 0001 050 * 080 7020 2800 3822 0ba4 ^ there you go. the intrtie bit is set. this means that both functions use INTA to signal the interrupts. but the BIOS is broken and assigned a different irq to function 1 compared to function 0. so the reason it broke when the irq-routing patch was merged is that irqs are actually probed to see if they work or if the routing needs some tuning... the attached patch should fix it. it's untested 'cos i don't have a laptop with TI bridge anymore...but it's simple rgds -daniel thanks a lot for your explenations and the provided patch. i need some sleep right now, but i'll build a kernel tommorow for jefferson - bug reporter - to test. a++ maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 11:05:05PM +0200, Sven Luther wrote: On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote: ... If your statement was true that Debian must take more care regarding legal risks than commercial distributions, can you explain why Debian exposes the legal risks of distributing software capable of decoding MP3's to all of it's mirrors? I don't know and don't really care. I don't maintain any mp3 player (err, actually i do, i package quark, but use it mostly to play .oggs, maybe i should think twice about this now that you made me aware of it), but in any case, i am part of the debian kernel maintainer team, and as such have a responsability to get those packages uploaded and past the screening of the ftp-masters. I believe the planned solution is vastly superior to the current one of simply removing said firmware blobs from the drivers, which caused more harm than helped, which is why we are set to clarifying this for the post-sarge kernels. Debian doesn't seem to care much about the possible legal problems of patents. The firmware issues are an urgent real problem? Debian should define how much legal risk they are willing to impose on their mirrors and distributors and should act accordingly in all areas. But ignoring some areas while being more religious than RMS in other areas is simply silly. That said, i was under the understanding that after the SCO disaster, clarification of licencing issues and copyright attributions was a welcome thing here, but maybe i misunderstood those whole issues. SCO disaster? It is a disaster for SCO. Friendly, Sven Luther cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295422: e2fsprogs for Sarge
Hi Ted, thanks for your detailed reply. If you could get the bk patches and send them to this thread I will look into getting them reviewed and the package built. I will also be at LCA, so I look forward to seeing you there. Best wishes -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Sven Luther [EMAIL PROTECTED] writes: It sounds like you are now looking at the question of are the huge string of hex characters the preferred form for making modifications to firmware. Personally I would be surprised but those hunks are small enough it could have been written in machine code. Yep, i also think it is in broadcom's best interest to modify the licencing text accordyingly, since i suppose someone could technicaly come after them legally to obtain said source code to this firmware. Unprobable though. Possibly. It sounds like that is what you want to do. So I currently have no reason to believe that anything has been done improperly with that code. Well, it all depends if you consider this firmware blob as software, which i feel it is without doubt, or we have not the same definition of software, i.e., the program which runs on the hardware, or not. We cannot claim this is data, since there should be at least some kind of executable code in it, independenlty of the fact that we claim that data is also software. Do you have any evidence that ``software'' was not written directly in machine code? Software is written directly in machine code when a programmer looks at the instruction set and writes down the binary representation of the instructions. I know ISC dhcpd has packet filter code that was written in that manner, so it is not a lost art. And it is done often enough when an assembler will not cooperate, and generate the correct instruction. Without evidence that we don't have the preferred form of the software for making modifications I don't see how you can complain. Eric -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
help: i can't reboot linux
hello: i configure a very small kernel, compile it and install, when i reboot, it stop after print Rebooting system... i don't know what was missing from the kernel, can any body help me? linux kernel: 2.6.9 machine: IBM T23 laptop lspci: :00:00.0 Host bridge: Intel Corp. 82830 830 Chipset Host Bridge (rev 04) :00:01.0 PCI bridge: Intel Corp. 82830 830 Chipset AGP Bridge (rev 04) :00:1d.0 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #1) (rev 02) :00:1d.1 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #2) (rev 02) :00:1d.2 USB Controller: Intel Corp. 82801CA/CAM USB (Hub #3) (rev 02) :00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 42) :00:1f.0 ISA bridge: Intel Corp. 82801CAM ISA Bridge (LPC) (rev 02) :00:1f.1 IDE interface: Intel Corp. 82801CAM IDE U100 (rev 02) :00:1f.3 SMBus: Intel Corp. 82801CA/CAM SMBus Controller (rev 02) :00:1f.5 Multimedia audio controller: Intel Corp. 82801CA/CAM AC'97 Audio Controller (rev 02) :01:00.0 VGA compatible controller: S3 Inc. SuperSavage IX/C SDR (rev 05) :02:00.0 CardBus bridge: Texas Instruments PCI1420 :02:00.1 CardBus bridge: Texas Instruments PCI1420 :02:02.0 Communication controller: Lucent Microelectronics WinModem 56k (rev 01) :02:08.0 Ethernet controller: Intel Corp. 82801CAM (ICH3) PRO/100 VE (LOM) Ethernet Controller (rev 42) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 291386
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.8.14 tags 291386 - unreproducible moreinfo Bug#291386: creates initrd that cannot use lvm 2 volumes if both lvm2 and lvm10 are installed Tags were: moreinfo unreproducible Tags removed: unreproducible, moreinfo 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#291386: creates initrd that cannot use lvm2 volumes if both lvm2 and lvm10 are installed
On Thu, Apr 07, 2005 at 12:05:31PM +0200, Eric Deplagne wrote: On Tue, 05 Apr 2005 11:28:22 -0700, Steve Langasek wrote: I've tried to pin down this bug, but I find that the current version of initrd-tools builds correct (matching) initrds whether or not the lvm10 package is installed. Is it possible that the broken initrd was built with an old version of initrd-tools, or was somehow built on a system that did not have lvm2 installed? Can you still recreate this broken initrd problem if you install lvm10 on the system? What version of initrd-tools do you currently have installed? It does occur all the same for me with initrd-tools 0.1.77... Hmm. Do you have the root filesystem on lvm2 ? Yes, of course; there's no reason to expect any lvm support in the initrd otherwise. I attach the output of diff -rub /mnt/initrd1 /mnt/initrd2, with on /mnt/initrd1 a mount of the initrd without lvm10, and on /mnt/initrd2 a mount of the initrd with lvm10 I also verified that the initrd with lvm10 still does not boot my box properly... Ok, got it -- this is only a problem with 2.4 kernels, where lvm-mod.o is available, and did not happen when testing against a 2.6 kernel. Now to figure out how to fix the check, so that it can distinguish between a volume that requires lvm2 and one that works with lvm1. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Bug#282793: Closing PowerEdge 1850/megaraid2 initrd-tools bugs
On Thu, Apr 07, 2005 at 05:31:01PM +0200, Timo Veith wrote: Am Donnerstag 07 April 2005 09:37 schrieb Loïc Minier: Hi, Yesterday, I successfully installed a PowerEdge 1850 server with megaraid2 (the same type of machine I described in #299055) with Debian Installer RC 3. This was to be expected as I couldn't reproduce the initrd problems I had in #299055 when I tried to debug it (something like 10 days ago). Reporters of bugs #278887, #282109, #282793, #284230, and #287019: please try with a newer initrd-tools or debian-installer or report any remaining problems I might have overseen! Regards, Hi, I reported bug #282793. I retried an installation with a PE2850 which has the same SCSI controller in it and with sarge-i386-netinst.iso (build from 20050403). I can also say my bug is fixed. But when booting linux26, hardware detection fails. No disks are found. I can report another bug, if anybody considers this as important. Good news, does this imply that we should be thinking about closing these bugs? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: sarge kernel frozen (2.4.27 and 2.6.8), and plans for post-sarge powerpc kernels.
On Tue, Apr 05, 2005 at 10:12:39AM +0200, Sven Luther wrote: On Tue, Apr 05, 2005 at 05:04:20PM +0900, Horms wrote: [snip] Are there debian machines that are suitable for doing such a build should the need arise? It seems that if it is just a matter of running a build and watching bugs, then whoever updates kernel-source could do the ppc build. That is assuming someone like yourself who knows a bit more about ppc is available for consultation of problems arise. There should. At least on ppc, i offered a pegasos machine to the debian-admins and it got rejected because there really wasn't need, so ... Many folk have got free pegasos ppc hardware from genesi, including Christoph and Jens, so there should be no lack of such boards. Ok, I'll try and be a little more specific. Do you know of any machines that are available to kernel team members, or more generally debian developers, to do ppc builds? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#296963: Also applies to 2.6.8-2-k7, 2.6.11-1-k7
Processing commands for [EMAIL PROTECTED]: reassign 296963 kernel-source-2.6.8 Bug#296963: USB mouse continuously disconnecting Bug reassigned from package `kernel-image-2.6.10-1-k7' to `kernel-source-2.6.8'. reassign 303652 kernel-source-2.6.8 Bug#303652: USB mouse continuously disconnecting Bug reassigned from package `kernel-image-2.6.8-2-k7' to `kernel-source-2.6.8'. reassign 303653 kernel-source-2.6.8 Bug#303653: USB mouse continuously disconnecting Bug reassigned from package `kernel-image-2.6.11-1-k7' to `kernel-source-2.6.8'. merge 296963 303652 303653 Bug#296963: USB mouse continuously disconnecting Bug#303652: USB mouse continuously disconnecting Bug#303653: USB mouse continuously disconnecting Merged 296963 303652 303653. 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]
Bug#296963: Also applies to 2.6.8-2-k7, 2.6.11-1-k7
reassign 296963 kernel-source-2.6.8 reassign 303652 kernel-source-2.6.8 reassign 303653 kernel-source-2.6.8 merge 296963 303652 303653 thanks The bug almost certainly lies in the source code, which is contained in kernel-source-2.6.8, lets track it there rather than fragmenting the bug report. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295422: e2fsprogs for Sarge
Hi Ted, It seems that I missunderstood the preferences expressed by Steve Langasek in my discussions with him. As it turns out he feels that it would be best to get 0.37-2 ready, as 0.37-1 is currently in sarge and has been beaten upon by users quite a bit. This should mittigate most of the need for review. And hopefully make your life a bit easier too. So, my question for the day is, what do you think needs to be done to release a sarge-worthy 0.37-2? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
