Kernel-package, fix version 2 ...
Hello, Apparently the initramfs-tools guys are refusing to implement the --supported-* policy, and as such, the current packages will not allow to use initramfs-tools, even though i designed it so that there should be no problem. Well, after it almost came to blow and bad blood with maks about this yesterday evening, Jonas made a proposal to change the way it works in an even nicer way, which would allow the intiramfs-tools guys to stay in their stuborn isolated ways, and still allow the users to use it. Thanks Jonas, you are a great guys, and your idea is a good one, i believe. Anyway, it goes like this : We now allow the ramdisk to contain either of : 1) undefined 2) a single field 3) a space separated list of fields. I will go at this in reverse. In case 3), we do as we do now, namely : prune the scripts which are not exectuable from the list and those who do not claim to work in the kernel version ocnfiguration we are trying to use, and then use the first one. Notice that currently initramfs-tools will probably return usage, and maybe fail, so it will be excluded here. In case 2), we modify the thing a bit : If there is only one ramdisk executable, we assume the user knows what he does. We thus do the --supported call, and if it returns true, we fallback to case 3), while if it is not, we issue a big fat warning and ask the user if he really wants to use a tool which claims not to be supported and thus potentially break the system, reply defaulting to no. In case 1) We use some heuristic to chose the tool. This is currently a simple conditional on the version, hard-coded in the postinst, chosing initrd-tools or yaird (i didn't consider initramfs-tools, as it does not build yet on all arches and was having some problems, but it may happen in the future, once the transition is done right, and we take a decision on the tools, but seriously, given the way the initramfs-tools guys are cooperating on this plan, i have some doubt on the wisdom of making it the default). In any case, i think the best idea would no more be to make a hard choice, but maybe use some kind of heuristic, or even make it configurable at package build time, so that it can be overiden. I need to think about this a bit more. Coments are welcome (and anyone not caring to reply, kind of loses the right to complain afterward, particularly if they claim i am not communicating on this). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
2.6.14-rc5 and version number thingy ...
Hello, ...
I have upgraded SVN to 2.6.14-rc5, and did a powerpc build. The only
difference was CONFIG_AIRO, and the build completed fine, and i saw that
CONFIG_AIRO was enabled in other arches, so i suppose powerpc was added or
something such, not sure, but in general things will work out fine so the next
upload will be of 2.6.14-rc5, if nobody objects.
This brings us to the version number mess. the previous packages where :
kernel version : 2.6.14-rc4
debian version : 2.6.13+2.6.14-rc4-0experimental.1
But apparently this caused build problems in the arch-indep part, which was
fixed one time by Simon Horman, and then refixed another way by Bastian Blank.
Still, it failed for external modules, since make-kpkg complains that the
version is not policy compliant.
Andres Salomon proposed another approach, and namely to do :
kernel version : 2.6.14rc5-1
debian version : 2.6.13+2.6.14rc5-0experimental.1
Which has the advantage of not differing from the normal way of handling
things, but currently dies with :
make[1]: Entering directory
`/home/sven/debian/kernel/trunk/build/linux-2.6-2.6.13+2.6.14rc5'
chmod +x debian/bin/gencontrol.py
debian/bin/gencontrol.py
Traceback (most recent call last):
File "debian/bin/gencontrol.py", line 462, in ?
main()
File "debian/bin/gencontrol.py", line 446, in main
changelog = read_changelog()
File "debian/bin/gencontrol.py", line 51, in read_changelog
version = parse_version(match.group('header_version'))
File "debian/bin/gencontrol.py", line 118, in parse_version
ret = match.groupdict()
AttributeError: 'NoneType' object has no attribute 'groupdict'
make[1]: *** [debian/control-real] Error 1
Well, what do you think about those choices ? Anyone volunteers to fix this
last problem ? Bastian ? Maybe i should learn python, i got some python book
at debconf'03 that is lying around somewhere here :)
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335154: linux-2.6: need to include fbcon in initrds
clone 335154 -1 -2
reassign -1 yaird
reassign -2 initramfs-tools
thanks
On Sat, Oct 22, 2005 at 05:09:07AM +0200, Adeodato Simó wrote:
> Package: linux-2.6
> Version: 2.6.13+2.6.14-rc4-0experimental.1
>
> Hello,
>
> This is related to #333003, but I'm filing a separate bug report as
> requested on irc.
>
> 2.6.13-1 had CONFIG_FB_VESA=n, while 2.6.14-rc4 has CONFIG_FB_VESA=y.
> Still, the obtained behavior is the same (blank screen), because the
> created initrd does not include the 'fbcon' module.
>
> I've checked that adding that module to the initrd solves the issue,
> so it seems the packages should make sure it is included ("
> we need to include it").
Ah, easier than that, you need to include fbcon in the kernel, not as module.
In any case, the initrd handling is something that is a bug in yaird and/or
initramfs-tools, cloning and reassigning.
Friendly,
Sven Luther
Re: Bug#333856: Removing the pending tag, since the initramfs-tools maintainers seem to have no intention to upload a fixed version
On Sat, Oct 22, 2005 at 12:41:32AM +0200, Marco Amadori wrote: > > > The situation right now is that a user cannot chose initramfs-tools, which > is > > not what i had planed, expecting initramfs-tools to follow the proposal > > shortly, which is partly a good thing since jonas proposed an even cleverer > > method that should satisfy everyone, but it would have still been nice to > have > > some more support and feedback from you guys about this. I mean i asked for > > comments, and if you disliked the proposal why didn't you comment about it, > so > > a better solution could have been found ? > > Meanwhile, can we access to the svn and build ourselves initramfs-tools > package? It is needed for kernel >= 2.6.13 with the root on evms (supported > by mkinitrd so far). Well, i am planing another kernel-package upload where you can force the thing. That said, yes, the fix is in the kernel svn, but they maintain initramfs in bazaar or something. Maybe you can just apply the patch above to your installed copy of initramfs-tools, or grab it from SVN or something. Alternatively, please help bringing evms support to yaird, so you can use that one, i have some doubts about depending on a packages whose maintainers don't really cooperate with the kernel team, and then claim i don't communicate about the issue, but then i guess we have many other packages in this case in the archive :) > An svn url leaved here should be enough for the impatient following the BTS. svn://svn.debian.org/svn/kernel/dists/trunk/utils/initramfs-tools, i think. From memory though, so maybe typoed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335154: linux-2.6: need to include fbcon in initrds
Package: linux-2.6
Version: 2.6.13+2.6.14-rc4-0experimental.1
Hello,
This is related to #333003, but I'm filing a separate bug report as
requested on irc.
2.6.13-1 had CONFIG_FB_VESA=n, while 2.6.14-rc4 has CONFIG_FB_VESA=y.
Still, the obtained behavior is the same (blank screen), because the
created initrd does not include the 'fbcon' module.
I've checked that adding that module to the initrd solves the issue,
so it seems the packages should make sure it is included ("
we need to include it").
Cheers,
--
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
He who has not a good memory should never take upon himself the trade of lying.
-- Michel de Montaigne
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#296011: marked as done (kernel hardware autodetection fails to detect the SupraExpress 56i Sp Intl )
Your message dated Sat, 22 Oct 2005 04:43:37 +0200
with message-id <[EMAIL PROTECTED]>
and subject line kernel hardware autodetection fails to detect the SupraExpress
56i Sp Intl
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; 19 Feb 2005 17:27:32 +
>From [EMAIL PROTECTED] Sat Feb 19 09:27:32 2005
Return-path: <[EMAIL PROTECTED]>
Received: from fep02-0.kolumbus.fi (fep02-app.kolumbus.fi) [193.229.0.44]
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1D2YOB-0001V8-00; Sat, 19 Feb 2005 09:27:31 -0800
Received: from saempy ([81.197.35.158]) by fep02-app.kolumbus.fi with SMTP
id <[EMAIL PROTECTED]>
for <[EMAIL PROTECTED]>; Sat, 19 Feb 2005 19:27:29 +0200
Message-ID: <[EMAIL PROTECTED]>
From: "Sami Aario" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Subject: kernel hardware autodetection fails to detect the SupraExpress 56i Sp
Intl
Date: Sat, 19 Feb 2005 19:18:52 +0200
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
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.5 required=4.0 tests=BAYES_10,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level:
Package: kernel-source-2.6.8
Version: 2.6.8-7
Severity: normal
The kernel hardware autodetection fails to detect my SupraExpress 56i Sp
Intl
modem. Adding the appropriate hardware identification string into
drivers/serial/8250_pnp.c fixes this problem. Here's the patch:
--- drivers/serial/8250_pnp.c 2005-02-10 20:55:36.0 +0200
+++ /home/saempy/8250_pnp.c 2005-02-10 20:55:04.0 +0200
@@ -276,6 +276,8 @@
{ "SUP1590", 0 },
/* SupraExpress 33.6 Data/Fax PnP modem */
{ "SUP1760", 0 },
+ /* SupraExpress 56i Sp Intl */
+ { "SUP2171", 0 },
/* Phoebe Micro */
/* Phoebe Micro 33.6 Data Fax 1433VQH Plug & Play */
{ "TEX0011", 0 },
I didn't use a Tags: patch line because this patch might cause other
problems with hardware configuration: resource conflicts etc. But the modem
works.
--
Sami Aario
---
Received: (at 296011-done) by bugs.debian.org; 22 Oct 2005 02:43:37 +
>From [EMAIL PROTECTED] Fri Oct 21 19:43:37 2005
Return-path: <[EMAIL PROTECTED]>
Received: from baikonur.stro.at [213.239.196.228]
by spohr.debian.org with esmtp (Exim 3.36 1 (Debian))
id 1ET9M8-0003jV-00; Fri, 21 Oct 2005 19:43:37 -0700
Received: from sputnik (stallburg.stro.at [128.131.216.190])
by baikonur.stro.at (Postfix) with ESMTP id 011585C01A
for <[EMAIL PROTECTED]>; Sat, 22 Oct 2005 04:43:42 +0200 (CEST)
Received: from max by sputnik with local (Exim 4.54)
id 1ET9M9-0008K1-L1
for [EMAIL PROTECTED]; Sat, 22 Oct 2005 04:43:37 +0200
Date: Sat, 22 Oct 2005 04:43:37 +0200
From: maximilian attems <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Re: kernel hardware autodetection fails to detect the SupraExpress 56i
Sp Intl
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.9i
X-Virus-Scanned: by Amavis (ClamAV) at stro.at
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_00 autolearn=no
version=2.60-bugs.debian.org_2005_01_02
Version: linux-source-2.6.14
thanks for your bug report, your patch landed in 2.6.14 upstream.
sorry that nobody followed up ealier.
should work with this image as soon as it lands in unstable.
--
maks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333856: Removing the pending tag, since the initramfs-tools maintainers seem to have no intention to upload a fixed version
> The situation right now is that a user cannot chose initramfs-tools, which is > not what i had planed, expecting initramfs-tools to follow the proposal > shortly, which is partly a good thing since jonas proposed an even cleverer > method that should satisfy everyone, but it would have still been nice to have > some more support and feedback from you guys about this. I mean i asked for > comments, and if you disliked the proposal why didn't you comment about it, so > a better solution could have been found ? Meanwhile, can we access to the svn and build ourselves initramfs-tools package? It is needed for kernel >= 2.6.13 with the root on evms (supported by mkinitrd so far). > > Friendly, > > Sven Luther An svn url leaved here should be enough for the impatient following the BTS. -- ESC:wq -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330583: Bug 330583: maybe an issue of pdc202xx_new driver with seagate ST330621A HDD?
As my harddisk is for testing purposes only, I tried to install Ubuntu Linux 5.10 (which uses a 2.6.12 kernel too) to verify, whether the error comes on other debian based distributions. Indeed after installing the base packages the system doesn't boot anymore, showing the same error messages as mentioned above, but there were only messages from the hdh harddisk (Seagate ST330621A - the slave on the second port of the Promise Ultra 133 TX2 [pdc202xx_new driver]). So I took the HDD from the controller and rebooted. Surprisingly the system started without any error messages. Maybe this is an issue of the pdc202xx_new driver used with Seagate ST330621A HDD in the 2.6.12-kernel? Boris -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#335088: linux-patch-debian-2.6.12: dot in Description
Package: linux-patch-debian-2.6.12 Severity: wishlist $ apt-cache show linux-patch-debian-2.6.12 Description: Debian patches to version 2.6.12 of the Linux kernel ... linux-source-2.6.12_2.6.12.orig.tar.gz from the Debian archive. . This I see a " . " -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333856: Removing the pending tag, since the initramfs-tools maintainers seem to have no intention to upload a fixed version
tags 333856 - pending thanks Jeff and Maximilian, i don't really understand what is happening here, the plan i proposed on october 9 was sent to d-k as well as to the initramfs-tools package, and i have seen no comment from you on this, and i even implemented the solution in the svn repo, and jonas cleaned it up, so why have we seen two uploads pass without it being applied, and at the same time seeing no explanation, reasons, critics of the chosen plan, whatever ? Not even a followup to this bug report. The situation right now is that a user cannot chose initramfs-tools, which is not what i had planed, expecting initramfs-tools to follow the proposal shortly, which is partly a good thing since jonas proposed an even cleverer method that should satisfy everyone, but it would have still been nice to have some more support and feedback from you guys about this. I mean i asked for comments, and if you disliked the proposal why didn't you comment about it, so a better solution could have been found ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334278: linux-image-2.6.12-1-parisc64-smp: Unknown symbols in sound drivers
On Fri, 21 Oct 2005, Thibaut VARENE wrote: > On 10/16/05, Maximilian Attems <[EMAIL PROTECTED]> wrote: > > > there will be soon a 2.6.14 in exeperimental, would be cool to check > > that too before bugging alsa upstream. > > I highly doubt this is an alsa-upstream bug. I wrote this driver, > which didn't make it into upstream until 2.6.14-rc2, so it looks much > more to me like a backport problem. *wonderfull* why didn't you tell that earlier. anyway 2.6.14 contains all the fixes of the previous -rc and will soon land in unstable as soon as it gets released. anyway we aren't already in stabilization phase with backporting business. > this is what it looks like when it actually works: > > [EMAIL PROTECTED]:~$ uname -a > Linux Esperanza 2.6.14-rc5-pa1 #13 SMP Fri Oct 21 14:27:21 CEST 2005 > parisc64 GNU/Linux ok. the -pa patch is still an out of tree pain, but that should evolve hopefully.. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333052: Bug#333522: possible problem cause: wait4(-1)
On Oct 21, Horms <[EMAIL PROTECTED]> wrote: > I did a bit of a poke around this symbols problem. > I puzzeled over it for a while. I began to wonder > if it might be caused byudevsynthesize[1] which seems > to be the major change between -2 and -4, and I completely > failed in all my attempts to reproduce the problem. It's *exposed* by udevsynthesize because it makes udevd try to load in parallel a big number of modules at the same time. I expect that you should be able to reproduce the bug with: for m in $MODULES; do /sbin/modprobe $m &; done > I then chatted it over with some people, and they suggested > that it might actually be a problem with a bogus depmod run. No, it's not. I checked my modules.dep and it's correct, and anyway if it were broken loading the same modules with modprobe from the command line would not work. > Alternateively, its seems there is a high correlation between > this problem and loading uhci_hcd. Providing lspci -vv might help a bit. Also 8250, but I can't see how this could be related to the hardware at all... All of this happens before the drivers are even initialised. Do not forget that the bug is not reliably reproducible, some days on my system may fail one of 8250, 8250_pnp, uhci_hcd or nothing at all. -- ciao, Marco signature.asc Description: Digital signature
Re: update kernel
Hello SuperrrLeha, Thursday, October 20, 2005, 4:21:03 PM, you wrote: S> How i can update kernel? I hope that is good steps: 1. download kernel 2.6.12 from http://www.kernel.org or from disk of linuxforum magazin 2. unpack archive to /usr/src/ 3. cd /usr/src/*new_src_kernel* 4. make clean 5. make xconfig or make menuconfig 6. make bzImage 7. make modules 8. mkdir /lib/modules/2.6.12 9. make modules_install 10. mkinitrd -o /boot/initrd-2.6.12.img 11. cp /usr/src/*new_src_kernel*/arch/i386/boot/bzImage /boot/vmlinuz-2.6.12 12. ln -s /boot/vmlinuz-2.6.12 /vmlinuz-2.6.12 13. add new position to /boot/grub/menu.lst 14. reboot && enjoy! -- Best regards, my_mailmailto: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.13+2.6.14-rc4-0experimental.1
* Horms wrote: > I've put the packages in > http://packages.vergenet.net/testing/linux-2.6-2.6.13+2.6.14-rc4/ > incase they dissapear from other sources. The ABI revision in the version number is missing in those packages. Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
linux-2.6_2.6.13+2.6.14-rc4-0experimental.1_powerpc.changes is NEW
kernel-image-2.6-power3-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/kernel-image-2.6-power3-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-power3_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/kernel-image-2.6-power3_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-power4-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/kernel-image-2.6-power4-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-power4_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/kernel-image-2.6-power4_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/kernel-image-2.6-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/kernel-image-2.6-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-power3-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/kernel-image-power3-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-power3_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/kernel-image-power3_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-power4-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/kernel-image-power4-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-power4_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/kernel-image-power4_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/kernel-image-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/kernel-image-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-2.6_2.6.13+2.6.14-rc4-0experimental.1.diff.gz to pool/main/l/linux-2.6/linux-2.6_2.6.13+2.6.14-rc4-0experimental.1.diff.gz linux-2.6_2.6.13+2.6.14-rc4-0experimental.1.dsc to pool/main/l/linux-2.6/linux-2.6_2.6.13+2.6.14-rc4-0experimental.1.dsc linux-2.6_2.6.13+2.6.14-rc4.orig.tar.gz to pool/main/l/linux-2.6/linux-2.6_2.6.13+2.6.14-rc4.orig.tar.gz (new) linux-doc-2.6.14_2.6.13+2.6.14-rc4-0experimental.1_all.deb optional doc Linux kernel specific documentation for version 2.6.14 This package provides the various README files and HTML documentation for the Linux kernel version 2.6.14. Plenty of information, including the descriptions of varios kernel subsystems, filesystems, driver-specific notes and the like. Consult the file . /usr/share/doc/linux-doc-2.6.14/Documentation/00-INDEX . for the detailed description of the contents. . This packages is produced using an updated kernel packaging system and replaces older kernel-doc packages linux-headers-2.6-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/linux-headers-2.6-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/linux-headers-2.6-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/linux-headers-2.6-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb to pool/main/l/linux-2.6/linux-headers-2.6-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb (new) linux-headers-2.6.14-rc4-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb optional devel Header files for Linux kernel 2.6.14 on powerpc-miboot-class machines This package provides the architecture-specific kernel header files for Linux kernel 2.6.14 on powerpc-miboot-class machines, generally used for building out-of-tree kernel modules. These files are going to be installed into /usr/src/linux-headers-2.6.14-rc4-powerpc-miboot, and can be used for building modules that load into the kernel provided by the linux-image-2.6.14-rc4-powerpc-miboot package. . This packages is produced using an updated kernel packaging system and replaces older kernel-headers packages (new) linux-headers-2.6.14-rc4-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb optional devel Header files for Linux kernel 2.6.14 on powerpc-smp-class machines This package provides the architecture-specific kernel header files for Linux kernel 2.6.14 on powerpc-smp-class machines, generally used for building out-of-tree kernel modules. These files are going to be installed into /usr/src/linux-headers-2.6.14-rc4-powerpc-smp, and can be used for building modules that load into the kernel provided by the linux-image-2.6.14-rc4-powerpc-smp package. . This package
Processing of linux-2.6_2.6.13+2.6.14-rc4-0experimental.1_powerpc.changes
linux-2.6_2.6.13+2.6.14-rc4-0experimental.1_powerpc.changes uploaded successfully to localhost along with the files: linux-2.6_2.6.13+2.6.14-rc4-0experimental.1.dsc linux-2.6_2.6.13+2.6.14-rc4.orig.tar.gz linux-2.6_2.6.13+2.6.14-rc4-0experimental.1.diff.gz linux-doc-2.6.14_2.6.13+2.6.14-rc4-0experimental.1_all.deb linux-manual-2.6.14_2.6.13+2.6.14-rc4-0experimental.1_all.deb linux-patch-debian-2.6.14_2.6.13+2.6.14-rc4-0experimental.1_all.deb linux-source-2.6.14_2.6.13+2.6.14-rc4-0experimental.1_all.deb linux-tree-2.6.14_2.6.13+2.6.14-rc4-0experimental.1_all.deb linux-headers-2.6.14_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6.14-rc4_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6.14-rc4-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6.14-rc4-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6.14-rc4-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6.14-rc4-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6.14-rc4-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6.14-rc4-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6.14-rc4-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6.14-rc4-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-power3_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-power3_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-power3-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-power3-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-power4_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-power4_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-power4-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-power4-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#67718: Platinum stock Reports
WE TOLD YOU TO WATCH!!! IT'S STILL NOT TOO LATE! TRADING ALERT!!! Timing is everything!!! Profits of 200-400% EXPECTED TRADING COMPANY:China Digital Media Corporation SYMB0L: CDGT.OB Opening Price: 1.70 About China Digital Media Corporation China Digital Media Corporation (OTC Bulletin Board: CDGT - News) focuses its business in three main areas: Cable Television Operations, Programs Production and Advertising Sales. Arcotect (Guangzhou) Technology Limited, a wholly owned subsidiary of CDGT in China, is the sole contractor and operator of digital television services in Nanhai, a city with 400,000 cable television subscribers. As of today, Nanhai's cable television operation provides 130 television channels which comprises of 38 basic channels and 92 pay channels. The pay channels are categorized into various value added packages. The digital broadcasting system could offer more than 800 digital channels of pay television programs and value added multimedia services. The Group is seeking to establish similar models elsewhere in China. Yes, it is Starting To MOVE, Friday could be HUGH!!! 10 Day Projectiont: $4-$6 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334278: linux-image-2.6.12-1-parisc64-smp: Unknown symbols in sound drivers
On 10/16/05, Maximilian Attems <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 16, 2005 at 09:49:10PM +0200, Thibaut VARENE wrote:
>
>
> ok, for documetentation please post full dmesg of your machine after boot
> and especially the output of lsmod.
there you go:
[EMAIL PROTECTED]:~$ dmesg
Linux version 2.6.12-1-parisc64-smp ([EMAIL PROTECTED]) (gcc version 4.0.2
(Debian 4.0.1-9)) #1 SMP Tue Sep 27 13:23:52 UTC 2005
FP[0] enabled: Rev 1 Model 16
The 64-bit Kernel has started...
Initialized PDC Console for debugging.
Determining PDC firmware type: System Map.
model 5d40 0491 0002 77ec06ff 10f0 0008
00b2 00b2
vers 0301
CPUID vers 17 rev 11 (0x022b)
capabilities 0x3
model 9000/785/J6000
Memory Ranges:
0) Start 0x End 0xefff Size 3840 MB
1) Start 0x0001 End 0x0001 Size 4096 MB
2) Start 0x0010f000 End 0x0010 Size256 MB
Total Memory: 8192 MB
initrd: 4fe29000-4ffee000
initrd: reserving 3fe29000-3ffee000 (mem_max 2)
On node 0 totalpages: 983040
DMA zone: 983040 pages, LIFO batch:31
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
On node 1 totalpages: 1048576
DMA zone: 1048576 pages, LIFO batch:31
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
On node 2 totalpages: 65536
DMA zone: 65536 pages, LIFO batch:31
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
LCD display at fff0f05d0008,fff0f05d registered
SMP: bootstrap CPU ID is 0
Built 3 zonelists
Kernel command line: root=/dev/sda3 HOME=/ console=ttyS0 TERM=vt102
palo_kernel=2/vmlinux
PID hash table entries: 4096 (order: 12, 131072 bytes)
Console: colour dummy device 160x64
Dentry cache hash table entries: 2097152 (order: 12, 16777216 bytes)
Inode-cache hash table entries: 1048576 (order: 11, 8388608 bytes)
Memory: 8388608k available
Calibrating delay loop... 1097.72 BogoMIPS (lpj=548864)
Security Framework v1.0.0 initialized
Capability LSM initialized
Mount-cache hash table entries: 256
Brought up 1 CPUs
CPU0 attaching sched-domain:
domain 0: span 0001
groups: 0001
checking if image is initramfs...it isn't (bad gzip magic numbers);
looks like an initrd
NET: Registered protocol family 16
EISA bus registered
Searching for devices...
Found devices:
1. Astro BC Runway Port at 0xfed0 [10] { 12, 0x0, 0x582, 0xb }
2. Elroy PCI Bridge at 0xfed3 [10/0] { 13, 0x0, 0x782, 0xa }
3. Elroy PCI Bridge at 0xfed34000 [10/2] { 13, 0x0, 0x782, 0xa }
4. Elroy PCI Bridge at 0xfed38000 [10/4] { 13, 0x0, 0x782, 0xa }
5. Elroy PCI Bridge at 0xfed3c000 [10/6] { 13, 0x0, 0x782, 0xa }
6. Duet W+ at 0xfffa [32] { 0, 0x0, 0x5d4, 0x4 }
7. Duet W+ at 0xfffa2000 [34] { 0, 0x0, 0x5d4, 0x4 }
8. Memory at 0xfed10200 [49] { 1, 0x0, 0x00a, 0x9 }
CPU0 attaching sched-domain:
domain 0: does not load-balance
Releasing cpu 1 now, hpa=fffa2000
FP[1] enabled: Rev 1 Model 16
CPU0 attaching sched-domain:
domain 0: span 0003
groups: 0001 0002
CPU1 attaching sched-domain:
domain 0: span 0003
groups: 0002 0001
CPU(s): 2 x PA8600 (PCX-W+) at 552.00 MHz
Whole cache flush 315143 cycles, flushing 275015576 bytes 41443791 cycles
Setting cache flush threshold to 1fe900 (2 CPUs online)
SBA found Astro 2.1 at 0xfed0
LBA version TR4.0 (0x5) found at 0xfed3
PCI: Enabled native mode for NS87415 (pif=0x8f)
LBA version TR4.0 (0x5) found at 0xfed34000
LBA version TR4.0 (0x5) found at 0xfed38000
LBA version TR4.0 (0x5) found at 0xfed3c000
SCSI subsystem initialized
TC classifier action (bugs to netdev@vger.kernel.org cc [EMAIL PROTECTED])
unwind_init: start = 0x10427c40, end = 0x104487d0, entries = 8377
Performance monitoring counters enabled for Duet W+
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
devfs: 2004-01-31 Richard Gooch ([EMAIL PROTECTED])
devfs: boot_options: 0x0
Initializing Cryptographic API
SuperIO: Found NS87560 Legacy I/O device at :00:0e.1 (IRQ 68)
SuperIO: Serial port 1 at 0x3f8
SuperIO: Serial port 2 at 0x2f8
SuperIO: Parallel port at 0x378
SuperIO: Floppy controller at 0x3f0
SuperIO: ACPI at 0x7e0
SuperIO: USB regulator enabled
PDC Stable Storage facility v0.09
Soft power switch enabled, polling @ 0xfff0f0400804.
STI GSC/PCI core graphics driver Version 0.9a
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 13 ports, IRQ sharing enabled
ttyS0 at I/O 0x3f8 (irq = 3) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 4) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP: routing cache h
Bug#334961: kernel-image: kernel BUG at return value of cciss_ioctl()
On Fri, 21 Oct 2005 18:53:03 +0900
"Simon Horman [Horms]" <[EMAIL PROTECTED]> wrote:
> On Fri, Oct 21, 2005 at 06:43:14PM +0900, MAENO Masaki wrote:
> > On Fri, 21 Oct 2005 16:06:23 +0900
> > "Simon Horman [Horms]" <[EMAIL PROTECTED]> wrote:
> > >
> > > On Fri, Oct 21, 2005 at 03:39:38PM +0900, MAENO Masaki wrote:
> > > > Package: kernel-image
> > > > Version: 2.6.8-2
> > > > Severity: normal
> > > >
> > > > "fsync_bdev()" cannot be executed in issuing "ioctl(BLKFLSBUF)" to disk
> > > > drive using cciss driver.
> > > > (When return value of "ioctl(BLKFLSBUF)" is only "-EINVAL",
> > > > "fsync_bdev()" is executed.
> > > >But "fsync_bdev()" isn't executed bacause its value is "-EBADRQC".)
> > > >
> > > > I suggest that you correct source as follows:
> > > > drivers/block/cciss.c:1093
> > > > - return -EBADRQC;
> > > > + return -EINVAL;
> > >
> > > I took a look at the upstream tree, and it seems that the return
> > > value is now -ENOTTY. Do you think that return value is correct?
> >
> > I know that the thing to return -EINVAL is an old specification.
> > I think the preferable value is -ENOTTY, but influence on other
> > parts is large.
> > I confirmed that it works good by fix above-mentioned in my
> > environment, tentatively...
>
> Ok, so you would recommend -EINVAL for 2.6.8?
No, I recommend following patch (in my last mail):
drivers/block/ioctl.c:197
-if (ret != -EINVAL)
+if (ret != -EINVAL && ret != -EBADRQC)
drivers/block/cciss.c:1093
no change
I confirmed that it also works good by fix above-mentioned in my
another environment, tentatively...
> > > Also, as 2.6.8 is now in the deep-freeze as the kernel for sarge,
> > > can you comment on if this patch is critical enough to warrant inclusion
> > > in a sarge update?
> >
> > You are correct. So, I suggest that it isn't influence other parts
> > easily to correct as follows(return errno is no change bacause of
> > user application):
> > drivers/block/ioctl.c:197
> > -if (ret != -EINVAL)
> > +if (ret != -EINVAL && ret != -EBADRQC)
> >
> > I tried to verify whether this patch was safe about the part where -EBADRQC
> > is used by ioctl(BLKFLSBUF).
> >
> > ==
> > * filename and linenum using BLKFLSBUF searched by grep:
> > drivers/mtd/mtd_blkdevs.c, line 206 -- case BLKFLSBUF:
> > - no return -EBADRQC.
> > drivers/block/ioctl.c, line 192 -- case BLKFLSBUF:
> > - patch part.
> > drivers/block/nbd.c, line 111 -- case BLKFLSBUF: return
> > "flush-buffer-cache";
> > - no return -EBADRQC.
> > drivers/block/rd.c, line 306 -- if (cmd != BLKFLSBUF)
> > - no return -EBADRQC (-EBUSY only).
> > include/linux/fs.h, line 190 -- #define BLKFLSBUF _IO(0x12,97)
> > - no problem.
> > include/linux/compat_ioctl.h, line 100 -- COMPATIBLE_IOCTL(BLKFLSBUF)
> > - no problem.
> > init/do_mounts_initrd.c, line 96 -- error = sys_ioctl(fd, BLKFLSBUF, 0);
> > - no problem.
> >
> > == Reference
> > * filename and linenum using EBADRQC searched by grep:
> > drivers/block/cciss.c, line 1093 -- return -EBADRQC;
> > drivers/scsi/ch.c, line 174 -- .errno = EBADRQC,
> > drivers/message/fusion/mptctl.c, line 903 -- return -EBADRQC;
> > fs/afs/vlclient.c, line 74 -- case AFSVL_BADVOLOPER: err = -EBADRQC; break;
> > fs/afs/vlocation.c, line 812 -- case -EBADRQC:
> > fs/cifs/netmisc.c, line 94 -- {ERRsmbcmd, -EBADRQC},
> > fs/ncpfs/ioctl.c, line 116 -- return -EBADRQC;
> > fs/ncpfs/ioctl.c, line 132 -- return -EBADRQC;
> > net/bluetooth/lib.c, line 95 -- return EBADRQC;
> > ==
> >
> > I think OK, please point it out to me if there is a problem.
>
> I think that looks fine, though I will have to check the code.
Thanks. Check it, please.
> Do you think this bug is imporatnt enough for inclusion
> in a sarge update?
I hope so.
> Could you describe what breaks?
I cannot judge it.
But, I will look after within the range that I can do if the problem
occurs.
Thanks.
--
MAENO, Masaki <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
linux-2.6_2.6.13+2.6.14-rc4-0experimental.1_powerpc.changes REJECTED
Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-headers-2.6.14-rc4-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (kernel-image-2.6-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-headers-2.6-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-image-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (kernel-image-2.6-power4-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-image-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-image-2.6.14-rc4-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-image-2.6-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-image-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-image-2.6-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-image-2.6-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-image-2.6.14-rc4-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (kernel-image-power4-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (kernel-image-power3-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (kernel-image-2.6-power4_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (kernel-image-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (kernel-image-power4_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-headers-2.6.14-rc4-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (kernel-image-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-headers-2.6.14-rc4-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-headers-2.6-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-image-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (kernel-image-2.6-power3_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-headers-2.6.14-rc4_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (kernel-image-2.6-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (kernel-image-2.6-power3-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-image-2.6.14-rc4-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-image-2.6.14-rc4-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-headers-2.6-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-image-2.6-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (kernel-image-power3_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-headers-2.6-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb). Rejected: no source found for linux-2.6 2.6.13+2.6.14-rc4-0experimental.1 (linux-headers-2.6.14-rc4-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_po
linux-2.6_2.6.13+2.6.14-rc4-0experimental.1_i386.changes REJECTED
Rejected: linux-2.6_2.6.13+2.6.14-rc4-0experimental.1.dsc refers to linux-2.6_2.6.13+2.6.14-rc4.orig.tar.gz, but I can't find it in the queue or in the pool. === If you don't understand why your files were rejected, or if the override file requires editing, reply to this email. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of linux-2.6_2.6.13+2.6.14-rc4-0experimental.1_powerpc.changes
linux-2.6_2.6.13+2.6.14-rc4-0experimental.1_powerpc.changes uploaded successfully to localhost along with the files: linux-headers-2.6.14_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6.14-rc4_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6.14-rc4-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6.14-rc4-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6.14-rc4-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6.14-rc4-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6.14-rc4-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6.14-rc4-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6-powerpc-miboot_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6.14-rc4-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6.14-rc4-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-image-2.6-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb linux-headers-2.6-powerpc64_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-powerpc_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-powerpc-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-power3_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-power3_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-power3-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-power3-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-power4_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-power4_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-power4-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb kernel-image-2.6-power4-smp_2.6.13+2.6.14-rc4-0experimental.1_powerpc.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of linux-2.6_2.6.13+2.6.14-rc4-0experimental.1_i386.changes
linux-2.6_2.6.13+2.6.14-rc4-0experimental.1_i386.changes uploaded successfully to localhost along with the files: linux-2.6_2.6.13+2.6.14-rc4-0experimental.1.dsc linux-2.6_2.6.13+2.6.14-rc4-0experimental.1.diff.gz linux-doc-2.6.14_2.6.13+2.6.14-rc4-0experimental.1_all.deb linux-manual-2.6.14_2.6.13+2.6.14-rc4-0experimental.1_all.deb linux-patch-debian-2.6.14_2.6.13+2.6.14-rc4-0experimental.1_all.deb linux-source-2.6.14_2.6.13+2.6.14-rc4-0experimental.1_all.deb linux-tree-2.6.14_2.6.13+2.6.14-rc4-0experimental.1_all.deb linux-headers-2.6.14_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-headers-2.6.14-rc4_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-headers-2.6.14-rc4-386_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-image-2.6.14-rc4-386_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-image-386_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-image-2.6-386_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-headers-2.6-386_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-headers-2.6.14-rc4-686_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-image-2.6.14-rc4-686_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-image-686_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-image-2.6-686_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-headers-2.6-686_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-headers-2.6.14-rc4-686-smp_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-image-2.6.14-rc4-686-smp_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-image-686-smp_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-image-2.6-686-smp_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-headers-2.6-686-smp_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-headers-2.6.14-rc4-k7_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-image-2.6.14-rc4-k7_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-image-k7_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-image-2.6-k7_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-headers-2.6-k7_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-headers-2.6.14-rc4-k7-smp_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-image-2.6.14-rc4-k7-smp_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-image-k7-smp_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-image-2.6-k7-smp_2.6.13+2.6.14-rc4-0experimental.1_i386.deb linux-headers-2.6-k7-smp_2.6.13+2.6.14-rc4-0experimental.1_i386.deb kernel-image-2.6-386_2.6.13+2.6.14-rc4-0experimental.1_i386.deb kernel-image-2.6-686_2.6.13+2.6.14-rc4-0experimental.1_i386.deb kernel-image-2.6-686-smp_2.6.13+2.6.14-rc4-0experimental.1_i386.deb kernel-image-2.6-k7_2.6.13+2.6.14-rc4-0experimental.1_i386.deb kernel-image-2.6-k7-smp_2.6.13+2.6.14-rc4-0experimental.1_i386.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
2.6.13+2.6.14-rc4-0experimental.1
After consultation on #debain-kernel, I've uploaded 2.6.13+2.6.14-rc4-0experimental.1 for i386 and powerpc to experimental. I guess they have to go through new now, but that doesn't take very long these days. The next move is probably to move the tree to 2.6.14-rc5, and hopefully 2.6.14 will appear, we can merge that, and put everything into sid. Hopefully the changes for porters have died down, though I do expect a large number of FTBFS on this release. Please help! (m68k, I know your life is hard, its ok for you to hold back until after 2.6.14, and even after that goes into sid if that works for you, lets chat about that some more.) I'm offline in Korea from now until Tuesday, Sven will handle anything if this upload falls off the rails. I've put the packages in http://packages.vergenet.net/testing/linux-2.6-2.6.13+2.6.14-rc4/ incase they dissapear from other sources. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334961: kernel-image: kernel BUG at return value of cciss_ioctl()
On Fri, Oct 21, 2005 at 06:43:14PM +0900, MAENO Masaki wrote:
> On Fri, 21 Oct 2005 16:06:23 +0900
> "Simon Horman [Horms]" <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, Oct 21, 2005 at 03:39:38PM +0900, MAENO Masaki wrote:
> > > Package: kernel-image
> > > Version: 2.6.8-2
> > > Severity: normal
> > >
> > > "fsync_bdev()" cannot be executed in issuing "ioctl(BLKFLSBUF)" to disk
> > > drive using cciss driver.
> > > (When return value of "ioctl(BLKFLSBUF)" is only "-EINVAL",
> > > "fsync_bdev()" is executed.
> > >But "fsync_bdev()" isn't executed bacause its value is "-EBADRQC".)
> > >
> > > I suggest that you correct source as follows:
> > > drivers/block/cciss.c:1093
> > > - return -EBADRQC;
> > > + return -EINVAL;
> >
> > I took a look at the upstream tree, and it seems that the return
> > value is now -ENOTTY. Do you think that return value is correct?
>
> I know that the thing to return -EINVAL is an old specification.
> I think the preferable value is -ENOTTY, but influence on other
> parts is large.
> I confirmed that it works good by fix above-mentioned in my
> environment, tentatively...
Ok, so you would recommend -EINVAL for 2.6.8?
> > Also, as 2.6.8 is now in the deep-freeze as the kernel for sarge,
> > can you comment on if this patch is critical enough to warrant inclusion
> > in a sarge update?
>
> You are correct. So, I suggest that it isn't influence other parts
> easily to correct as follows(return errno is no change bacause of
> user application):
> drivers/block/ioctl.c:197
> -if (ret != -EINVAL)
> +if (ret != -EINVAL && ret != -EBADRQC)
>
>
> I tried to verify whether this patch was safe about the part where -EBADRQC
> is used by ioctl(BLKFLSBUF).
>
> ==
> * filename and linenum using BLKFLSBUF searched by grep:
> drivers/mtd/mtd_blkdevs.c, line 206 -- case BLKFLSBUF:
> - no return -EBADRQC.
> drivers/block/ioctl.c, line 192 -- case BLKFLSBUF:
> - patch part.
> drivers/block/nbd.c, line 111 -- case BLKFLSBUF: return "flush-buffer-cache";
> - no return -EBADRQC.
> drivers/block/rd.c, line 306 -- if (cmd != BLKFLSBUF)
> - no return -EBADRQC (-EBUSY only).
> include/linux/fs.h, line 190 -- #define BLKFLSBUF _IO(0x12,97)
> - no problem.
> include/linux/compat_ioctl.h, line 100 -- COMPATIBLE_IOCTL(BLKFLSBUF)
> - no problem.
> init/do_mounts_initrd.c, line 96 -- error = sys_ioctl(fd, BLKFLSBUF, 0);
> - no problem.
>
> == Reference
> * filename and linenum using EBADRQC searched by grep:
> drivers/block/cciss.c, line 1093 -- return -EBADRQC;
> drivers/scsi/ch.c, line 174 -- .errno = EBADRQC,
> drivers/message/fusion/mptctl.c, line 903 -- return -EBADRQC;
> fs/afs/vlclient.c, line 74 -- case AFSVL_BADVOLOPER: err = -EBADRQC; break;
> fs/afs/vlocation.c, line 812 -- case -EBADRQC:
> fs/cifs/netmisc.c, line 94 -- {ERRsmbcmd, -EBADRQC},
> fs/ncpfs/ioctl.c, line 116 -- return -EBADRQC;
> fs/ncpfs/ioctl.c, line 132 -- return -EBADRQC;
> net/bluetooth/lib.c, line 95 -- return EBADRQC;
> ==
>
> I think OK, please point it out to me if there is a problem.
I think that looks fine, though I will have to check the code.
Do you think this bug is imporatnt enough for inclusion
in a sarge update? Could you describe what breaks?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334961: kernel-image: kernel BUG at return value of cciss_ioctl()
On Fri, 21 Oct 2005 16:06:23 +0900
"Simon Horman [Horms]" <[EMAIL PROTECTED]> wrote:
>
> On Fri, Oct 21, 2005 at 03:39:38PM +0900, MAENO Masaki wrote:
> > Package: kernel-image
> > Version: 2.6.8-2
> > Severity: normal
> >
> > "fsync_bdev()" cannot be executed in issuing "ioctl(BLKFLSBUF)" to disk
> > drive using cciss driver.
> > (When return value of "ioctl(BLKFLSBUF)" is only "-EINVAL",
> > "fsync_bdev()" is executed.
> >But "fsync_bdev()" isn't executed bacause its value is "-EBADRQC".)
> >
> > I suggest that you correct source as follows:
> > drivers/block/cciss.c:1093
> > - return -EBADRQC;
> > + return -EINVAL;
>
> I took a look at the upstream tree, and it seems that the return
> value is now -ENOTTY. Do you think that return value is correct?
I know that the thing to return -EINVAL is an old specification.
I think the preferable value is -ENOTTY, but influence on other
parts is large.
I confirmed that it works good by fix above-mentioned in my
environment, tentatively...
> Also, as 2.6.8 is now in the deep-freeze as the kernel for sarge,
> can you comment on if this patch is critical enough to warrant inclusion
> in a sarge update?
You are correct. So, I suggest that it isn't influence other parts
easily to correct as follows(return errno is no change bacause of
user application):
drivers/block/ioctl.c:197
-if (ret != -EINVAL)
+if (ret != -EINVAL && ret != -EBADRQC)
I tried to verify whether this patch was safe about the part where -EBADRQC
is used by ioctl(BLKFLSBUF).
==
* filename and linenum using BLKFLSBUF searched by grep:
drivers/mtd/mtd_blkdevs.c, line 206 -- case BLKFLSBUF:
- no return -EBADRQC.
drivers/block/ioctl.c, line 192 -- case BLKFLSBUF:
- patch part.
drivers/block/nbd.c, line 111 -- case BLKFLSBUF: return "flush-buffer-cache";
- no return -EBADRQC.
drivers/block/rd.c, line 306 -- if (cmd != BLKFLSBUF)
- no return -EBADRQC (-EBUSY only).
include/linux/fs.h, line 190 -- #define BLKFLSBUF _IO(0x12,97)
- no problem.
include/linux/compat_ioctl.h, line 100 -- COMPATIBLE_IOCTL(BLKFLSBUF)
- no problem.
init/do_mounts_initrd.c, line 96 -- error = sys_ioctl(fd, BLKFLSBUF, 0);
- no problem.
== Reference
* filename and linenum using EBADRQC searched by grep:
drivers/block/cciss.c, line 1093 -- return -EBADRQC;
drivers/scsi/ch.c, line 174 -- .errno = EBADRQC,
drivers/message/fusion/mptctl.c, line 903 -- return -EBADRQC;
fs/afs/vlclient.c, line 74 -- case AFSVL_BADVOLOPER: err = -EBADRQC; break;
fs/afs/vlocation.c, line 812 -- case -EBADRQC:
fs/cifs/netmisc.c, line 94 -- {ERRsmbcmd, -EBADRQC},
fs/ncpfs/ioctl.c, line 116 -- return -EBADRQC;
fs/ncpfs/ioctl.c, line 132 -- return -EBADRQC;
net/bluetooth/lib.c, line 95 -- return EBADRQC;
==
I think OK, please point it out to me if there is a problem.
Thanks.
--
MAENO, Masaki <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333052: Bug#333522: possible problem cause: wait4(-1)
I did a bit of a poke around this symbols problem. I puzzeled over it for a while. I began to wonder if it might be caused byudevsynthesize[1] which seems to be the major change between -2 and -4, and I completely failed in all my attempts to reproduce the problem. [1] http://marc.theaimsgroup.com/?t=11248247225&r=1&w=2 I then chatted it over with some people, and they suggested that it might actually be a problem with a bogus depmod run. Can people who are seeing this run depmod manually and see if the problem goes away? Alternateively, its seems there is a high correlation between this problem and loading uhci_hcd. Providing lspci -vv might help a bit. Also, what kind of usb devices do the people who are seeing this have plugged in. I tried with a few I found lying around the office, but to no avail. -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: kernel-image: kernel BUG at return value of cciss_ioctl()
Processing commands for [EMAIL PROTECTED]: > reassign 334961 kernel-source-2.6.8 Bug#334961: kernel-image: kernel BUG at return value of cciss_ioctl() Warning: Unknown package 'kernel-image' Bug reassigned from package `kernel-image' to `kernel-source-2.6.8'. > tag 334961 +sarge Bug#334961: kernel-image: kernel BUG at return value of cciss_ioctl() There were no tags set. Tags added: sarge > tag 334961 +upstream Bug#334961: kernel-image: kernel BUG at return value of cciss_ioctl() Tags were: sarge Tags added: upstream > tag 334961 +patch Bug#334961: kernel-image: kernel BUG at return value of cciss_ioctl() Tags were: upstream sarge Tags added: patch > 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]
