* Florian wrote:
Norbert Tretkowski wrote:
Hmm... what's the output of 'lspci' on your system?
Here it is:
:00:03.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43 (rev 30)
:00:07.0 ISA bridge: Contaq Microsystems 82c693
:00:07.1 IDE interface: Contaq
On Mon, Apr 04, 2005 at 08:41:58AM +0200, Sven Luther wrote:
Hello,
It seems as the 2.4.27 and 2.6.8 kernels which are sarge release candidates
are now frozen, and will be part of sarge as is, complete with all the bugs
and problems present in them, and maybe even some security issues which
On Tue, Apr 05, 2005 at 03:15:00PM +0900, Horms wrote:
On Mon, Apr 04, 2005 at 08:41:58AM +0200, Sven Luther wrote:
Hello,
It seems as the 2.4.27 and 2.6.8 kernels which are sarge release candidates
are now frozen, and will be part of sarge as is, complete with all the bugs
and
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.
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
I have the same problem here.
And when I start the computer with capidrv in /etc/modules, it's
hanging completely at running /etc/init.d/isdnutils. Only hard reset
helps.
ciao, Dirk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Tue, Apr 05, 2005 at 09:03:01AM +0200, Sven Luther wrote:
On Tue, Apr 05, 2005 at 03:15:00PM +0900, Horms wrote:
On Mon, Apr 04, 2005 at 08:41:58AM +0200, Sven Luther wrote:
Hello,
It seems as the 2.4.27 and 2.6.8 kernels which are sarge release
candidates
are now frozen,
On Tue, Apr 05, 2005 at 05:04:20PM +0900, Horms wrote:
On Tue, Apr 05, 2005 at 09:03:01AM +0200, Sven Luther wrote:
On Tue, Apr 05, 2005 at 03:15:00PM +0900, Horms wrote:
On Mon, Apr 04, 2005 at 08:41:58AM +0200, Sven Luther wrote:
Hello,
It seems as the 2.4.27 and 2.6.8 kernels
On Tue, Apr 05, 2005 at 09:19:24AM +0100, Ian Campbell wrote:
On Mon, 2005-04-04 at 23:19 +0200, Sven Luther wrote:
I am only saying that the tg3.c and other file are under the GPL, and
that the firmware included in it is *NOT* intented to be under the
GPL, so why not say it explicitly ?
On Mon, 2005-04-04 at 23:19 +0200, Sven Luther wrote:
I am only saying that the tg3.c and other file are under the GPL, and
that the firmware included in it is *NOT* intented to be under the
GPL, so why not say it explicitly ?
I don't think anyone here has disagreed. What almost everyone has
On Mon, 2005-04-04 at 23:51 -0500, Dmitry Torokhov wrote:
On Monday 04 April 2005 23:23, Jan Harkes wrote:
On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
Mmm, probably that 2001 discussion about the keyspan firmware,
Package: kernel-source-2.6.8
Version: 2.6.8-16
Severity: important
Tags: security
Ubuntu reported a DoS in the tmpfs driver:
| A Denial of Service vulnerability was found in the tmpfs driver, which
| is commonly used to mount RAM disks below /dev/shm and /tmp. The
| shm_nopage() did not properly
On Tue, 2005-04-05 at 10:32 +0200, Sven Luther wrote:
On Tue, Apr 05, 2005 at 09:19:24AM +0100, Ian Campbell wrote:
On Mon, 2005-04-04 at 23:19 +0200, Sven Luther wrote:
I am only saying that the tg3.c and other file are under the GPL, and
that the firmware included in it is *NOT*
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
On Tue, Apr 05, 2005 at 11:28:07AM +0200, Arjan van de Ven wrote:
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.
Fine with me.
Second step is to make the built-in firmware a
Hello Jeff, ...
If i can believe what i see in :
http://linux.bkbits.net:8080/linux-2.6/anno/drivers/net/[EMAIL
PROTECTED]|src/|src/drivers|src/drivers/net|related/drivers/net/tg3.c|[EMAIL
PROTECTED]
(which may or may not be correct and complete, since i am not really familiar
with bk and
On Tue, Apr 05, 2005 at 11:36:58AM +0200, Arjan van de Ven wrote:
One of the options is to even ship the firmware in the kernel tarbal but
from a separate directory with a clear license clarification text in it.
I think that's what we should do. I currently don't have any firmware
requiring
Hi Jan,
Mmm, probably that 2001 discussion about the keyspan firmware, right ?
http://lists.debian.org/debian-legal/2001/04/msg00145.html
Can you summarize the conclusion of the thread, or what you did get
from it,
please ?
That people didn't like the
On Tue, Apr 05, 2005 at 10:30:47AM +0100, Ian Campbell wrote:
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
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
On Tue, Apr 05, 2005 at 11:36:58AM +0200, Arjan van de Ven wrote:
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.
I think the
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.
I think the infrasturcture is quite mature. We have a lot of drivers
that require it to
On Tue, 05 Apr 2005 11:39:02 +0200, Christoph Hellwig wrote:
On Tue, Apr 05, 2005 at 11:36:58AM +0200, Arjan van de Ven wrote:
One of the options is to even ship the firmware in the kernel tarbal but
from a separate directory with a clear license clarification text in it.
I think that's
Raul Miller wrote:
On Apr 04, Sven Luther [EMAIL PROTECTED] wrote:
is waiting for NEW processing, but i also believe that the dubious
copyright assignement will not allow the ftp-masters to let it pass
into the archive, since it *IS* a GPL violation, and thus i am doing
this in order to solve
On Tue, Apr 05, 2005 at 10:32:38AM +0200, Kay Sievers wrote:
On Mon, 2005-04-04 at 23:51 -0500, Dmitry Torokhov wrote:
Firmware loader is format-agnostic, I think having IHEX parser in a separate
file would be better...
Why should this be in-kernel at all? Convert the firmware into a
On Tue, Apr 05, 2005 at 11:22:06AM +0200, Marcel Holtmann wrote:
I agree with Dmitry on this point. The IHEX parser should not be inside
firmware_class.c. What about using keyspan_ihex.[ch] for it?
That's what I had originally, actually called firmware_ihex.ko, since
the IHEX format parser is
Theodore Ts'o wrote:
You know, the fact that Red Hat, SuSE, Ubuntu, and pretty much all
other commercial distributions have not been worried about getting
sued for this alleged GPL'ed violation makes it a lot harder for me
(and others, I'm sure) take Debian's concerns seriously.
I said in
Subject: kernel-image-2.6.10-1-686: kernel BUG at fs/reiserfs/file.c:534!
Package: kernel-image-2.6.10-1-686
Version: 2.6.10-6
Severity: critical
Justification: breaks the whole system
*** Please type your report below this line ***
When the following occurs:
Apr 3 21:59:31 localhost kernel:
Christoph Hellwig wrote:
On Tue, Apr 05, 2005 at 11:28:07AM +0200, Arjan van de Ven wrote:
One of the sticking points will be how people get the firmware; I can
see the point of a kernel-distributable-firmware project related to the
kernel (say on kernel.org) which would provide a nice collection
I agree. And that really doesn't need a lot of infrastructure,
basically just a tarball that unpacks to /lib/firmware, maybe a specfile
and debian/ dir in addition.
At the moment there is -zero- infrastructure that would allow my tg3 to
continue working, when I upgrade to a tg3
Humberto Massa wrote:
But, the question made here was a subtler one and you are all biting
around the bush: there *are* some misrepresentations of licenses to the
firmware blobs in the kernel (-- ok, *if* you consider that hex dumps
are not source code). What Sven asked was: Hey, can I state
On Tue, Apr 05, 2005 at 09:03:21AM -0300, Humberto Massa wrote:
Theodore Ts'o wrote:
You know, the fact that Red Hat, SuSE, Ubuntu, and pretty much all
other commercial distributions have not been worried about getting
sued for this alleged GPL'ed violation makes it a lot harder for me
On Tue, Apr 05, 2005 at 08:16:48AM -0400, Jeff Garzik wrote:
Humberto Massa wrote:
But, the question made here was a subtler one and you are all biting
around the bush: there *are* some misrepresentations of licenses to the
firmware blobs in the kernel (-- ok, *if* you consider that hex
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
Hi,
i've read here http://lists.debian.org/debian-kern...3/msg00412.html
that the Debian team has decided to wipe out the Broadcom tg3 module
from the 2.6.11 and following releases. I've a laptop which uses this
card to connect to a LAN. Since i must work in a LAN the problem arises.
Is there
Hi,
i've read here http://lists.debian.org/debian-kern...3/msg00412.html
that the Debian team has decided to wipe out the Broadcom tg3 module
from the 2.6.11 and following releases. I've a laptop which uses this
card to connect to a LAN. Since i must work in a LAN the problem arises.
Is there
Jeff Garzik wrote:
We do not add comments to the kernel source code which simply state the
obvious.
Jeff
Whoa, kind of harsh, isn't it? I'm just trying to help.
Anyway, the problem at hand is: people do *not* think there is anything
obvious.
For instance: many, many people do not consider
Sven Luther wrote:
On Tue, Apr 05, 2005 at 09:03:21AM -0300, Humberto Massa wrote:
Theodore Ts'o wrote:
You know, the fact that Red Hat, SuSE, Ubuntu, and pretty much all
other commercial distributions have not been worried about getting
sued for this alleged GPL'ed violation makes it a lot
Hi,
this bug is fixed in kernel 2.6.10. Should I let this bug open as long
as Debian provides a default kernel with this bug ?
--
Laurent Bonnaud.
http://www.lis.inpg.fr/pages_perso/bonnaud/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
Hi,
here is an update:
# modprobe i82365
FATAL: Error inserting i82365
(/lib/modules/2.6.10-1-686/kernel/drivers/pcmcia/i82365.ko): No such device
$ dmesg
[...]
Device 'i823650' does not have a release() function, it is broken and must be
fixed.
Badness in device_release at
Sven Luther wrote:
On Tue, Apr 05, 2005 at 12:23:29AM -0400, Jan Harkes wrote:
This ofcourse doesn't actually solve Debian's distribution issues since
the keyspan firmware can only be distributed as part of 'Linux or other
Open Source operating system kernel'.
Well, if this is the case, it
Hi,
here is an update:
# rmmod vesafb
$ dmesg
Device 'vesafb0' does not have a release() function, it is broken and must be
fixed.
Badness in device_release at drivers/base/core.c:85
[c01bba68] kobject_cleanup+0x98/0xa0
[c01bba70] kobject_release+0x0/0x10
[c01bc519] kref_put+0x39/0xa0
On Tue, Apr 05, 2005 at 09:19:24AM +0100, Ian Campbell wrote:
On Mon, 2005-04-04 at 23:19 +0200, Sven Luther wrote:
I am only saying that the tg3.c and other file are under the GPL, and
that the firmware included in it is *NOT* intented to be under the
GPL, so why not say it explicitly ?
On Apr 5, 2005 9:36 AM, Marcel Holtmann [EMAIL PROTECTED] wrote:
People are also working on a replacement for the
current request_firmware(), because the needs are changing. Try to keep
it close with the usb-serial for now.
Could you elaborate on what do you think is needed? I have some of
On Tue, Apr 05, 2005 at 04:36:31PM +0200, Marcel Holtmann wrote:
I agree with Dmitry on this point. The IHEX parser should not be inside
firmware_class.c. What about using keyspan_ihex.[ch] for it?
That's what I had originally, actually called firmware_ihex.ko, since
the IHEX format
On Tue, Apr 05, 2005 at 04:45:30PM +0200, Marco Calviani wrote:
Hi,
i've read here http://lists.debian.org/debian-kern...3/msg00412.html
http://lists.debian.org/debian-kernel/2005/03/msg00412.html that the
Debian team has decided to wipe out the Broadcom tg3 module from the
2.6.11 and
Hi,
I cannot reproduce this bug with this Debian kernel:
Linux video1 2.6.10-1-686-smp #1 SMP Fri Mar 11 01:49:45 EST 2005 i686 GNU/Linux
However, since the bug in bugzilla.kernel.org has not been closed, I
don't know if this IRQ problem is fixed or if it is just not triggered
by the current
Hi Dmitry,
People are also working on a replacement for the
current request_firmware(), because the needs are changing. Try to keep
it close with the usb-serial for now.
Could you elaborate on what do you think is needed? I have some of
patches to firmware loader and wondering if we
On Tue, 5 Apr 2005, Humberto Massa wrote:
Josselin Mouette wrote:
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.
On Apr 5, 2005 6:45 AM, Jan Harkes [EMAIL PROTECTED] wrote:
On Tue, Apr 05, 2005 at 11:22:06AM +0200, Marcel Holtmann wrote:
I agree with Dmitry on this point. The IHEX parser should not be inside
firmware_class.c. What about using keyspan_ihex.[ch] for it?
That's what I had originally,
Richard B. Johnson wrote:
On Tue, 5 Apr 2005, Humberto Massa wrote:
Josselin Mouette wrote:
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
Hi Jan,
I agree with Dmitry on this point. The IHEX parser should not be inside
firmware_class.c. What about using keyspan_ihex.[ch] for it?
That's what I had originally, actually called firmware_ihex.ko, since
the IHEX format parser is not in any way keyspan specific and there
Sven Luther [EMAIL PROTECTED] said:
On Tue, Apr 05, 2005 at 08:16:48AM -0400, Jeff Garzik wrote:
Humberto Massa wrote:
But, the question made here was a subtler one and you are all biting
around the bush: there *are* some misrepresentations of licenses to the
firmware blobs in the
Le mardi 05 avril 2005 11:50 -0400, Richard B. Johnson a crit :
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
Processing commands for [EMAIL PROTECTED]:
tags 291386 unreproducible moreinfo
Bug#291386: creates initrd that cannot use lvm 2 volumes if both lvm2 and lvm10
are installed
There were no tags set.
Tags added: unreproducible, moreinfo
thanks
Stopping processing here.
Please contact me if you
On Tue, 5 Apr 2005, Josselin Mouette wrote:
Le mardi 05 avril 2005 ÿÿ 11:50 -0400, Richard B. Johnson a ÿÿcrit :
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
Le mardi 05 avril 2005 14:17 -0400, Richard B. Johnson a crit :
You are completely missing the point. I don't care whether the firmwares
should be free, or whether they could be free. The fact is they are not
free, and Debian doesn't distribute non-free software in the main
archive. The
Accepted:
kernel-headers-2.6.11-1-386_2.6.11-2_i386.deb
to
pool/main/k/kernel-image-2.6.11-i386/kernel-headers-2.6.11-1-386_2.6.11-2_i386.deb
kernel-headers-2.6.11-1-686-smp_2.6.11-2_i386.deb
to
pool/main/k/kernel-image-2.6.11-i386/kernel-headers-2.6.11-1-686-smp_2.6.11-2_i386.deb
Accepted:
kernel-build-2.6.10-1_2.6.10-6_sparc.deb
to
pool/main/k/kernel-image-2.6.10-sparc/kernel-build-2.6.10-1_2.6.10-6_sparc.deb
kernel-headers-2.6.10-1-sparc32_2.6.10-6_sparc.deb
to
pool/main/k/kernel-image-2.6.10-sparc/kernel-headers-2.6.10-1-sparc32_2.6.10-6_sparc.deb
Accepted:
kernel-headers-2.6.11-1-s390_2.6.11-1_s390.deb
to
pool/main/k/kernel-image-2.6.11-s390/kernel-headers-2.6.11-1-s390_2.6.11-1_s390.deb
kernel-headers-2.6.11-1-s390x_2.6.11-1_s390.deb
to
pool/main/k/kernel-image-2.6.11-s390/kernel-headers-2.6.11-1-s390x_2.6.11-1_s390.deb
Accepted:
kernel-build-2.6.11-power3-smp_2.6.11-1_powerpc.deb
to
pool/main/k/kernel-patch-powerpc-2.6.11/kernel-build-2.6.11-power3-smp_2.6.11-1_powerpc.deb
kernel-build-2.6.11-power3_2.6.11-1_powerpc.deb
to
Le mardi 05 avril 2005 12:50 -0600, Chris Friesen a crit :
Josselin Mouette wrote:
The fact is also that mixing them with a GPLed software gives
an result you can't redistribute - although it seems many people
disagree with that assertion now.
This is only true if the result is
Josselin Mouette wrote:
It merely depends on the definition of aggregation. I'd say that two
works that are only aggregated can be easily distinguished and
separated. This is not the case for a binary kernel module, from which
you cannot easily extract the firmware and code parts.
Not really...
Josselin Mouette wrote:
The fact is also that mixing them with a GPLed software gives
an result you can't redistribute - although it seems many people
disagree with that assertion now.
This is only true if the result is considered a derivative work of the
gpl'd code.
The GPL states In addition,
Package: initrd-tools
Version: 0.1.77
Severity: grave
Tags: experimental patch
It's not exactly a patch, just the regular expression I've found to work
with libc6 2.3.4:
sed -n 's/.*\(=\)\?[[:blank:]]\+\(\/[^[:blank:]]*\).*/\2/p'
See bug #301455
George Cristian Birzan wrote:
Package: initrd-tools
Version: 0.1.77
Severity: grave
Tags: experimental patch
It's not exactly a patch, just the regular expression I've found to work
with libc6 2.3.4:
sed -n 's/.*\(=\)\?[[:blank:]]\+\(\/[^[:blank:]]*\).*/\2/p'
Something like '[:blank:]'
Package: kernel-source-2.4.27
Severity: important
Tags: security
CAN-2005-0400 reports that an information leak occurs in the ext2 mkdir():
See http://linux.bkbits.net:8080/linux-2.4/[EMAIL PROTECTED]|[EMAIL PROTECTED]
for a description and a patch.
Cheers,
Moritz
-- System
[MFT set to -legal, as this is becoming legal arcana probably not
particularly interesting to any other list.]
On Tue, 05 Apr 2005, Sven Luther wrote:
There are two solutions to this issue, either you abide by the GPL
and provide also the source code of those firmware binaries (the
prefered
Package: kernel-image-2.6.11-1-686
Version: 2.6.11-2
Severity: normal
My sound card worked fine in 2.6.10, but I don't get any sound output in
2.6.11. The driver is loaded and appears in /proc:
jester:~ lsmod|grep snd
snd_usb_audio 67392 0
snd_usb_lib13088 1
On Tue, Apr 05, 2005 at 08:56:09PM +0200, Josselin Mouette wrote:
Le mardi 05 avril 2005 à 12:50 -0600, Chris Friesen a écrit :
Josselin Mouette wrote:
The fact is also that mixing them with a GPLed software gives
an result you can't redistribute - although it seems many people
reassign 234365 kernel-source-2.6.8
thanks
On Tue, Apr 05, 2005 at 05:32:39PM +0200, Laurent Bonnaud wrote:
Hi,
I cannot reproduce this bug with this Debian kernel:
Linux video1 2.6.10-1-686-smp #1 SMP Fri Mar 11 01:49:45 EST 2005 i686
GNU/Linux
However, since the bug in
tag 303177 +pending
thanks
On Tue, Apr 05, 2005 at 11:03:23AM +0200, Moritz Muehlenhoff wrote:
Package: kernel-source-2.6.8
Version: 2.6.8-16
Severity: important
Tags: security
Ubuntu reported a DoS in the tmpfs driver:
| A Denial of Service vulnerability was found in the tmpfs driver,
Processing commands for [EMAIL PROTECTED]:
tags 303294 +pending
Bug#303294: CAN-2005-0400: ext2 mkdir() leaks kernel data
Tags were: security
Tags added: pending
thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
Processing commands for [EMAIL PROTECTED]:
tag 303177 +pending
Bug#303177: kernel-source-2.6.8: DoS vulnerability in tmpfs
Tags were: security
Tags added: pending
tag 302704 +pending
Bug#302704: CAN-2005-0750: Possible local root exploit through insufficient
range checking in af_bluetooth
73 matches
Mail list logo
