linux-modules-extra-2.6 override disparity
There are disparities between your recently accepted upload and the override file for the following file(s): eeepc-acpi-modules-2.6-686_2.6.25-4_i386.deb: package says section is admin, override says misc. Either the package or the override file is incorrect. If you think the override is correct and the package wrong please fix the package so that this disparity is fixed in the next upload. If you feel the override is incorrect then please reply to this mail and explain why. Please INCLUDE the list of packages as seen above, or we won't be able to deal with your mail due to missing information. [NB: this is an automatically generated mail; if you replied to one like it before and have not received a response yet, please ignore this mail. Your reply needs to be processed by a human and will be in due course, but until then the installer will send these automated mails; sorry.] -- Debian distribution maintenance software (This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux-modules-extra-2.6_2.6.25-4_i386.changes ACCEPTED
Accepted: atl2-modules-2.6-486_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/atl2-modules-2.6-486_2.6.25-4_i386.deb atl2-modules-2.6-686-bigmem_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/atl2-modules-2.6-686-bigmem_2.6.25-4_i386.deb atl2-modules-2.6-686_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/atl2-modules-2.6-686_2.6.25-4_i386.deb atl2-modules-2.6-amd64_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/atl2-modules-2.6-amd64_2.6.25-4_i386.deb atl2-modules-2.6-vserver-686_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/atl2-modules-2.6-vserver-686_2.6.25-4_i386.deb atl2-modules-2.6.25-2-486_2.6.25+2.0.3-4_i386.deb to pool/main/l/linux-modules-extra-2.6/atl2-modules-2.6.25-2-486_2.6.25+2.0.3-4_i386.deb atl2-modules-2.6.25-2-686-bigmem_2.6.25+2.0.3-4_i386.deb to pool/main/l/linux-modules-extra-2.6/atl2-modules-2.6.25-2-686-bigmem_2.6.25+2.0.3-4_i386.deb atl2-modules-2.6.25-2-686_2.6.25+2.0.3-4_i386.deb to pool/main/l/linux-modules-extra-2.6/atl2-modules-2.6.25-2-686_2.6.25+2.0.3-4_i386.deb atl2-modules-2.6.25-2-amd64_2.6.25+2.0.3-4_i386.deb to pool/main/l/linux-modules-extra-2.6/atl2-modules-2.6.25-2-amd64_2.6.25+2.0.3-4_i386.deb atl2-modules-2.6.25-2-vserver-686_2.6.25+2.0.3-4_i386.deb to pool/main/l/linux-modules-extra-2.6/atl2-modules-2.6.25-2-vserver-686_2.6.25+2.0.3-4_i386.deb aufs-modules-2.6-486_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/aufs-modules-2.6-486_2.6.25-4_i386.deb aufs-modules-2.6-686-bigmem_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/aufs-modules-2.6-686-bigmem_2.6.25-4_i386.deb aufs-modules-2.6-686_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/aufs-modules-2.6-686_2.6.25-4_i386.deb aufs-modules-2.6-amd64_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/aufs-modules-2.6-amd64_2.6.25-4_i386.deb aufs-modules-2.6-vserver-686_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/aufs-modules-2.6-vserver-686_2.6.25-4_i386.deb aufs-modules-2.6-xen-686_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/aufs-modules-2.6-xen-686_2.6.25-4_i386.deb aufs-modules-2.6.25-2-486_2.6.25+0+20080609-4_i386.deb to pool/main/l/linux-modules-extra-2.6/aufs-modules-2.6.25-2-486_2.6.25+0+20080609-4_i386.deb aufs-modules-2.6.25-2-686-bigmem_2.6.25+0+20080609-4_i386.deb to pool/main/l/linux-modules-extra-2.6/aufs-modules-2.6.25-2-686-bigmem_2.6.25+0+20080609-4_i386.deb aufs-modules-2.6.25-2-686_2.6.25+0+20080609-4_i386.deb to pool/main/l/linux-modules-extra-2.6/aufs-modules-2.6.25-2-686_2.6.25+0+20080609-4_i386.deb aufs-modules-2.6.25-2-amd64_2.6.25+0+20080609-4_i386.deb to pool/main/l/linux-modules-extra-2.6/aufs-modules-2.6.25-2-amd64_2.6.25+0+20080609-4_i386.deb aufs-modules-2.6.25-2-vserver-686_2.6.25+0+20080609-4_i386.deb to pool/main/l/linux-modules-extra-2.6/aufs-modules-2.6.25-2-vserver-686_2.6.25+0+20080609-4_i386.deb aufs-modules-2.6.25-2-xen-686_2.6.25+0+20080609-4_i386.deb to pool/main/l/linux-modules-extra-2.6/aufs-modules-2.6.25-2-xen-686_2.6.25+0+20080609-4_i386.deb btrfs-modules-2.6-486_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/btrfs-modules-2.6-486_2.6.25-4_i386.deb btrfs-modules-2.6-686-bigmem_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/btrfs-modules-2.6-686-bigmem_2.6.25-4_i386.deb btrfs-modules-2.6-686_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/btrfs-modules-2.6-686_2.6.25-4_i386.deb btrfs-modules-2.6-amd64_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/btrfs-modules-2.6-amd64_2.6.25-4_i386.deb btrfs-modules-2.6-vserver-686_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/btrfs-modules-2.6-vserver-686_2.6.25-4_i386.deb btrfs-modules-2.6-xen-686_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/btrfs-modules-2.6-xen-686_2.6.25-4_i386.deb btrfs-modules-2.6.25-2-486_2.6.25+0.15-4_i386.deb to pool/main/l/linux-modules-extra-2.6/btrfs-modules-2.6.25-2-486_2.6.25+0.15-4_i386.deb btrfs-modules-2.6.25-2-686-bigmem_2.6.25+0.15-4_i386.deb to pool/main/l/linux-modules-extra-2.6/btrfs-modules-2.6.25-2-686-bigmem_2.6.25+0.15-4_i386.deb btrfs-modules-2.6.25-2-686_2.6.25+0.15-4_i386.deb to pool/main/l/linux-modules-extra-2.6/btrfs-modules-2.6.25-2-686_2.6.25+0.15-4_i386.deb btrfs-modules-2.6.25-2-amd64_2.6.25+0.15-4_i386.deb to pool/main/l/linux-modules-extra-2.6/btrfs-modules-2.6.25-2-amd64_2.6.25+0.15-4_i386.deb btrfs-modules-2.6.25-2-vserver-686_2.6.25+0.15-4_i386.deb to pool/main/l/linux-modules-extra-2.6/btrfs-modules-2.6.25-2-vserver-686_2.6.25+0.15-4_i386.deb btrfs-modules-2.6.25-2-xen-686_2.6.25+0.15-4_i386.deb to pool/main/l/linux-modules-extra-2.6/btrfs-modules-2.6.25-2-xen-686_2.6.25+0.15-4_i386.deb drbd8-modules-2.6-486_2.6.25-4_i386.deb to pool/main/l/linux-modules-extra-2.6/drbd8-modules-2.6-486_2.6.25-4_i386.deb drbd8-modules-2.6-686-bigmem_2.6.25-4_i386.deb to
Bug#487634: linux-image-2.6.24-1-686: computer freezes when idle
On Mon, Jun 23, 2008 at 01:23:41PM +0400, Alexander Polakov wrote: Package: linux-image-2.6.24-1-686 Version: 2.6.24-7 Severity: important Computer freezes after a period of inactivity. Jun 22 06:47:04 pinnsvin syslogd 1.5.0#4: restart. Jun 22 06:50:37 pinnsvin kernel: 060:[c02bdbe9] EFLAGS: 0293 CPU: 0 Jun 22 06:50:37 pinnsvin kernel: EIP is at _spin_unlock_irqrestore+0xa/0x13 Jun 22 06:50:37 pinnsvin kernel: EAX: 0293 EBX: 0001 ECX: 0293 EDX: 0200 Jun 22 06:50:37 pinnsvin kernel: ESI: EDI: da313808 EBP: ESP: c0373f40 Jun 22 06:50:37 pinnsvin kernel: DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Jun 22 06:50:37 pinnsvin kernel: CR0: 8005003b CR2: b757f000 CR3: 1a72e000 CR4: 06d0 Jun 22 06:50:37 pinnsvin kernel: DR0: DR1: DR2: DR3: Jun 22 06:50:37 pinnsvin kernel: DR6: 0ff0 DR7: 0400 Jun 22 06:50:37 pinnsvin kernel: [c013c4b2] tick_notify+0x1ce/0x2e4 Jun 22 06:50:37 pinnsvin kernel: [c011da71] __update_rq_clock+0x1a/0xf3 Jun 22 06:50:37 pinnsvin kernel: [c0138d3c] notifier_call_chain+0x2a/0x47 Jun 22 06:50:37 pinnsvin kernel: [c0138d9f] raw_notifier_call_chain+0x17/0x1a Jun 22 06:50:37 pinnsvin kernel: [c013bfd2] clockevents_notify+0x19/0x50 Jun 22 06:50:37 pinnsvin kernel: [dc829625] acpi_idle_enter_simple+0x1a1/0x1f0 [processor] Jun 22 06:50:37 pinnsvin kernel: [c024fa50] cpuidle_idle_call+0x5c/0x80 Jun 22 06:50:37 pinnsvin kernel: [c024f9f4] cpuidle_idle_call+0x0/0x80 Jun 22 06:50:37 pinnsvin kernel: [c01025f3] cpu_idle+0xab/0xcc Jun 22 06:50:37 pinnsvin kernel: [c0377942] start_kernel+0x338/0x340 Jun 22 06:50:37 pinnsvin kernel: [c03770db] unknown_bootoption+0x0/0x195 Jun 22 06:50:37 pinnsvin kernel: === Jun 22 06:50:37 pinnsvin kernel: Jun 22 06:50:37 pinnsvin kernel: Pid: 0, comm: swapper Not tainted (2.6.24-1-686 #1) hmm please try 2.6.25 from unstable, afaik those oopses are hard to trace and not yet fixed upstream. best regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Switch to 2.6.25
Frans Pop [EMAIL PROTECTED] writes: On Sunday 22 June 2008, Otavio Salvador wrote: I've prepared a set of patches against current kernel-wedge to update it. Thanks. - ide-generic-pci I haven't add it since I found no reference about it being used by other distros and then I prefer to still use ide-generic for now, so near of release I'm still not sure about this one. Current support for ide-generic in D-I and initramfs-tools is far from perfect and could still be considered a regression from Etch. It could well be that ide-generic-pci fills an important gap here. We really should discuss this with the kernel team. Kernel Team, please give us some guidance on that. Should we use ide-generic-pci or ide-generic? cdrom-core-modules: add ide-cd_mod. ide-modules: add ide-pnp. Some more explanation for these would be nice. Please remember that the changelog is not only _what_ you do, but also _why_ you do it. Looking again, I think we could skip ide-pnp. At least from the source it looks to be ISA related and I think we doesn't need to include it until we get complains about non-working systems. Kernel Team, any guidance here too? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: what's the status of this bug?
Processing commands for [EMAIL PROTECTED]: found 473180 2.6.25-5 Bug#473180: linux-2.6: please build with CONFIG_FB_UVESA=m Bug marked as found in version 2.6.25-5. found 473180 2.6.24-7 Bug#473180: linux-2.6: please build with CONFIG_FB_UVESA=m Bug marked as found in version 2.6.24-7. block 473176 by 473180 Bug#473180: linux-2.6: please build with CONFIG_FB_UVESA=m Bug#473176: ITP: v86d -- execute x86 BIOS code in a controlled environment Was not blocked by any bugs. Blocking bugs of 473176 added: 473180 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#473180: what's the status of this bug?
found 473180 2.6.25-5 found 473180 2.6.24-7 block 473176 by 473180 thanks Hi, I just wanted to hear if there is any progress on building Debian's kernels with CONFIG_FB_UVESA=m? Regards Evgeni -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473180: what's the status of this bug?
On Mon, Jun 23, 2008 at 03:08:47PM +0200, Evgeni Golov wrote: found 473180 2.6.25-5 found 473180 2.6.24-7 block 473176 by 473180 thanks Hi, I just wanted to hear if there is any progress on building Debian's kernels with CONFIG_FB_UVESA=m? not sure if we want that close to the release, might give some bad fb regressions.. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473180: what's the status of this bug?
On Mon, Jun 23, 2008 at 03:26:59PM +0200, maximilian attems wrote: I just wanted to hear if there is any progress on building Debian's kernels with CONFIG_FB_UVESA=m? not sure if we want that close to the release, might give some bad fb regressions.. Thats should not give any regressions. It coexists fine with vesafb and radeonfb on my boxes. 1. It's a module, so users will have to load it themself. 2. It just prints an error until v86d[1] is installed. Regards Evgeni [1] http://dev.gentoo.org/~spock/projects/uvesafb/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 473180
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 tags 473180 + pending Bug#473180: linux-2.6: please build with CONFIG_FB_UVESA=m There were no tags set. Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473180: what's the status of this bug?
On Mon, Jun 23, 2008 at 03:53:56PM +0200, Evgeni Golov wrote: On Mon, Jun 23, 2008 at 03:26:59PM +0200, maximilian attems wrote: I just wanted to hear if there is any progress on building Debian's kernels with CONFIG_FB_UVESA=m? not sure if we want that close to the release, might give some bad fb regressions.. Thats should not give any regressions. It coexists fine with vesafb and radeonfb on my boxes. 1. It's a module, so users will have to load it themself. 2. It just prints an error until v86d[1] is installed. right due to not beeing autoloaded enabled in trunk for 2.6.26 Lenny release on x86. thanks for report -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#487672: linux-image-2.6.26-rc7-686: freeze when closing laptop panel lid, in dual screen mode.
Processing commands for [EMAIL PROTECTED]: reassign 487672 linux-2.6 Bug#487672: linux-image-2.6.26-rc7-686: freeze when closing laptop panel lid, in dual screen mode. Warning: Unknown package 'linux-image-2.6.26-rc7-686' Bug reassigned from package `linux-image-2.6.26-rc7-686' to `linux-2.6'. -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 487594
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 tags 487594 + pending Bug#487594: bttv: deadlock when using v4l interface There were no tags set. Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487421: Early boot-time kernel panic with linux-image-2.6.25-2-amd64 (2.6.25-5).
before jumping to strange conlcusions. this looks very much like a dup. did you set MODULES=dep *and* regenerated the initramfs with update-initramfs -u -k kernelversion *and* tried to boot that. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487409: initramfs-tools: plase put get_fstype() to funtions
On Sat, 21 Jun 2008, Christoph Anton Mitterer wrote: Could you please move the get_fstype() from /usr/share/initramfs-tools/scripts/local to /usr/share/initramfs-tools/scripts/functions so that other scripts can use it, too? (My problem is, that I have a script in local-top, that tries to mount a n usb-stick,... but busybox' mount doesn't seem to handle -t auto or specifying -t not at all). that shouldn't be needed, did you try booting with rootdelay=X ? please post that boot hook. it is klibc mount that wants a -t invocation on mounting an fs. thanks -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487672: linux-image-2.6.26-rc7-686: freeze when closing laptop panel lid, in dual screen mode.
bts forwarded 487672 http://bugzilla.kernel.org/show_bug.cgi?id=10965 thanks I forgot to mention : If I switch to either screen completely (crt=on + lvds=off OR crt=off + lvds=on), the problem doesn't occurs ! I have tried xserver-xorg-video-intel 2:2.3.2-1 , but it didn't help. I have tried to remove libgl1-mesa-dri , but it didn't help. Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479709: Confirmation
I applied that patch given in this bugreport and recompiled the Debian packges. It seems that this successfully solved my problem as well as I'm using the kernel for about one day now without a problem. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: unarchiving 404927, reopening 404927
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.27 unarchive 404927 Unarchived Bug 404927 # reopen bug that missed getting reopened on the kernel reopen 404927 Bug#404927: udev believes hardware raid devices are removable and sets the permissions to group floppy Bug reopened, originator not changed. 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]
Re: Bug#385553: linux-modules-extra-2.6: ndiswrapper requires rules target override
On Mon, Jun 23, 2008 at 12:19:18AM +0200, Bastian Blank wrote: ndiswrapper is a module loader. But it does not take the appropriate actions while handling non-free modules. It sure tries. | /* | * ndiswrapper is under GPL by itself, but loads proprietary modules. | * Don't use add_taint_module(), as it would prevent ndiswrapper from | * using GPL-only symbols it needs. | */ | if (strcmp(mod-name, ndiswrapper) == 0) | add_taint(TAINT_PROPRIETARY_MODULE); There is nothing accidentally. ndiswrapper loader.c: #if LINUX_VERSION_CODE = KERNEL_VERSION(2,6,10) add_taint(TAINT_PROPRIETARY_MODULE); /* older kernels don't seem to have a way to set * tainted information */ #endif Seems it does try to do the taint itself when needed. That also matches what I understood from the lkml discussions on the issue. And nothing prevents ndiswrapper from changing its name which makes that in kernel check fail. Also the comment in the kernel clearly says (as you even included yourself): /* * ndiswrapper is under GPL by itself, but loads proprietary modules. * Don't use add_taint_module(), as it would prevent ndiswrapper from * using GPL-only symbols it needs. */ So that seems to indicate the kernel has no problem with ndiswrapper using GPL-only symbols, so ndiswrapper itself must be GPL and hence free. -- Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404927: Fw: ICP/Adaptec 5085BR emits similar symptoms (group floppy)
On Mon, Jun 23, 2008 at 01:27:15PM +0200, Bernhard Stoeckner wrote:
sorry for forwarding this to you directly; the bugtracking system
seems to dislike my mail (does not show up in the web interface),
because the bug in question is already flagged as closed, and I thought
it might be of interest to you, and I don't know who else to bother.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=404927
I've reopened the bug, which wasn't meant to have been closed the way it
was, and am forwarding your message there now.
Begin forwarded message:
Date: Mon, 23 Jun 2008 13:03:07 +0200
From: Bernhard Stoeckner [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: ICP/Adaptec 5085BR emits similar symptoms
Hi,
I am seeing the same issue on a recent debian etch, with udev.
brw-rw 1 root floppy 8, 64 2008-06-23 10:05 /dev/sde
brw-rw 1 root floppy 8, 65 2008-06-23 10:05 /dev/sde1
brw-rw 1 root floppy 8, 66 2008-06-23 10:05 /dev/sde2
The patch that excludes aacraid from the floppies group does
not apply to my card (a ICP Vortex 5085BR).
looking at device '/block/sde':
KERNEL==sde
SUBSYSTEM==block
DRIVER==
ATTR{dev}==8:64
ATTR{range}==16
ATTR{removable}==1
ATTR{size}==8749240320
ATTR{stat}== 2228010170 15301778412411589
82721 75569632288074092 116412
ATTR{capability}==13
As can be seen, then DRIVER thing is empty. Thought I'd mention it,
even though I am unsure why DRIVER is empty in the first place.
Using 2.6.24-1-686 (from etch-backports).
Bernhard
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487409: initramfs-tools: plase put get_fstype() to funtions
On Mon, 2008-06-23 at 17:36 +0200, maximilian attems wrote: that shouldn't be needed, did you try booting with rootdelay=X ? No,... but isn't rootdelay a delay for mounting the root-filesystem? I'm temporarily mounting another filesystem (USB-stick) where the key for dm-crypt/cryptsetup lies. please post that boot hook. Please look here: http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/2008-June/002101.html It's the mount_boot_usb_stick script. it is klibc mount that wants a -t invocation on mounting an fs. Don't know,... busybox wasn't able to mount hoewever ;) Thanks, Chris. smime.p7s Description: S/MIME cryptographic signature
Bug#487725: linux-image-2.6.25-2-amd64: Got much trouble and message 'ehci_hcd: HC died' when scanning image from 'Canon PIXMA MP150'.
Package: linux-image-2.6.25-2-amd64 Version: 2.6.25-5 Severity: normal Hello, all. While scanning (with SANE) a document from my 'Canon PIXMA MP150' scanner/printer combo, I stumbled upon a grave problem. I discovered that my configuration - out-of-the-box up-to-date lenny - was using module 'ehci_hcd' (possibly amongst others) to dialog with my scanner. And I discovered that there was some activity on IRQ_7, which was 'listened-to' by module 'ehci_hcd', when I queried scanner list typing: scanimage -L and when I put my scanner ON or OFF. I was able to query this list 3 times without a problem ; this step did no hurt. But a grave problem suddenly arose when I typed: scanimage -T which is a scanner/communication test which consist in scanning a full line - equivalent to effectively scanning a small part of the document. Not only the test failed, but 3 more very bad things happened: - I got alarming messages on console (and in 'dmesg' below) : ehci_hdc: ... HC died, and kernel said it would forget about IRQ_7 (which 'ehci_hcd' was 'listening-to' earlier). - I became unable to query the list of scanners anymore : the scanner ceased to respond. - The kernel no longer notified (eg on console) when I put my scanner OFF, ON, and OFF again. Fortunately, I discovered that in this situation, I had just to unload module 'ehci_hcd' to get my scanner+SANE functional (including scanner power ON/OFF notifications). But a few points draw my attention: I retried this scenario, implying scanner OFF, PC reboot, delay, scanner ON. A few times the scenario showed to be exactly like I described above. While the other times, symptoms of the bug (alarming messages + unability to communicate with the scanner) happened merely whenever I chose to put my scanner OFF (alarm) and ON (no comm.) instead of doing the scanner test (via scanimage -T). Again, unloading module 'ehci_hcd' got my scanner+SANE functional. I found very strange that IRQ_7 would just be used for some handchecking and not for the transfer phase. But it's obvious: 'ehci_hcd', which was the sole user of IRQ_7, succeeded at handchecking and broke on scanning/transfer attempts. So, when I unloaded 'ehci_hcd', the transfer phase likely falled back to some non-IRQ (polling) method. I was sorry that my new Debian pre-packaged linux-image-2.6.25-2-amd64 (ver 2.6.25-5) made my scanning experience so tricky. And I asked myself what it would have been if module 'echi_hcd' didn't broke. Would 'ehci_hcd' be usefull after all ? Would IRQ_7 be used ? With many interruptions in scanning/transfer phase ? And would transfers get faster ? So, I decided to repeat the whole thing with Debian pre-packaged linux-image-2.6.24-1-amd64 (ver 2.6.24-7). You can't believe it ! Scanning (scanner+SANE) functioned right out of the box, without having root to unload module 'ehci_hcd' (it was effectively loaded). And I was witnessing an intensive use of IRQ_7 by module 'ehci_hcd' ; transfers were similar than with 2.6.25 : certainly no far from perfect. And whenever I put my scanner ON or OFF, I got the matching notifications on console and in dmesg. And whenever I wanted to scan some paper, all was good and perfect. To help you understand what happened, and in the case the piece of dmesg below would not be enough, I give you a pointer to my full dmesg log: http://pagesperso-orange.fr/mandolosse/logs/2008-06-23__dmesg__ehci_hcd__died.txt I also captured 'scanimage', 'lsmod' output and snapshots of '/proc/interrupts' at different times. I plan to scrutinize all this data, to comment the relevant parts and to post them later. In hope my report will prove useful. Sincerely, Valentin QUEQUET -- Package-specific info: ** Version: Linux version 2.6.25-2-amd64 (Debian 2.6.25-5) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080420 (prerelease) (Debian 4.1.2-22)) #1 SMP Thu Jun 12 15:38:32 UTC 2008 ** Command line: BOOT_IMAGE=252k8c ro root=1641 acpi=off bootkbd=fr ** Not tainted ** Kernel log: [ 26.186050] sd 4:0:0:0: [sdb] Attached SCSI removable disk [ 26.226053] sd 4:0:0:1: [sdc] Attached SCSI removable disk [ 26.235133] sd 4:0:0:2: [sdd] Attached SCSI removable disk [ 26.257114] sd 4:0:0:3: [sde] Attached SCSI removable disk [ 28.474762] loop: AES key scrubbing enabled [ 28.474762] loop: loaded (max 8 devices) [ 84.509321] fuse init (API version 7.9) [ 84.649334] ReiserFS: hdd2: found reiserfs format 3.6 with standard journal [ 84.649334] ReiserFS: hdd2: using ordered data mode [ 84.649334] ReiserFS: hdd2: journal params: device hdd2, size 8125, journal first block 66, max trans len 256, max batch 225, max commit age 30, max trans age 30 [ 84.650872] ReiserFS: hdd2: checking transaction log (hdd2) [ 84.709413] ReiserFS: hdd2: Using r5 hash to sort names [ 84.927097] NTFS driver 2.1.29 [Flags: R/W MODULE]. [ 84.996773] NTFS volume version 3.1. [ 84.996819] NTFS-fs warning (device sda1):
Bug#487721: linux-2.6: ipw2200 wrongly claims it can scan for hidden ESSIDs
Package: linux-2.6 Version: 2.6.25-5 Severity: normal Tags: patch -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since I upgraded from Linux 2.6.24, NetworkManager cannot associate my Intel wireless card, handled by the ipw2200 driver, with my AP, which has a hidden SSID. NetworkManager thinks that wpa_supplicant should be able to scan for specific hidden SSIDs if the underlying driver advertises IW_SCAN_CAPA_ESSID, which ipw2200 does since 2.6.25. However, this doesn't work. I have confirmed that NetworkManager is interpreting this capability flag correctly and checked that wpa_supplicant has the patch that I was referred to - see the thread on linux-wireless http://thread.gmane.org/gmane.linux.kernel.wireless.general/15560. Therefore I believe the driver is at fault. This should be fixable by removing the capability flag: diff --git a/drivers/net/wireless/ipw2200.c b/drivers/net/wireless/ipw2200.c index 6e70460..457c078 100644 - --- a/drivers/net/wireless/ipw2200.c +++ b/drivers/net/wireless/ipw2200.c @@ -8973,7 +8973,7 @@ static int ipw_wx_get_range(struct net_device *dev, range-enc_capa = IW_ENC_CAPA_WPA | IW_ENC_CAPA_WPA2 | IW_ENC_CAPA_CIPHER_TKIP | IW_ENC_CAPA_CIPHER_CCMP; - - range-scan_capa = IW_SCAN_CAPA_ESSID | IW_SCAN_CAPA_TYPE; + range-scan_capa = IW_SCAN_CAPA_TYPE; IPW_DEBUG_WX(GET Range\n); return 0; - --- END --- Ben. - -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (100, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFIX/n079ZNCRIGYgcRAtTDAJ0QJkA9bMRF6l9AEr5X6TukLEyq9ACfW+YL rCQutbYqXk8u8vZP8Zawka0= =pip+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487257: linux-image-2.6.24: SGI GBE framebuffer colormap broken
On Fri, Jun 20, 2008 at 06:24:24PM +0200, Martin Michlmayr wrote: Thomas, have you seen this problem? I've never tried grafics. I need to find a cable extension to connect the O2 to a TFT. I'll try to test this week. Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea.[ RFC1925, 2.3 ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263169: What would a PhD title do for your resume?
What would a PhD title do for your resume? A degree with no classes or test in your spare time Call 24/7 on For US: 1-419-735-9250 Outside US: +1-419-735-9250 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487421: Early boot-time kernel panic with linux-image-2.6.25-2-amd64 (2.6.25-5).
Hello, Maks and others. before jumping to strange conlcusions. this looks very much like a dup. did you set MODULES=dep *and* regenerated the initramfs with update-initramfs -u -k kernelversion *and* tried to boot that. You're right, Maks, i_DID a mistake ! I'm not even able to describe what I did, but when I looked-at my 'MODULES=dep' - see 3) below - initrd I realized how ugly it was ; it really contained evil things ! Strangely enough, my 'customized-dep' - see 4) below - initrd version was completely fine !!! If I didn't have made this mistake, I would have saved a few hours guessing which few modules I had to add to this base. Now - a few dozens minutes ago - I've rebuilt my 4 different versions of initrd for linux-image-2.6.25-2-amd64 (ver 2.6.25-5) : 1) The default one (= Simply with MODULES=most) 2) A custom gently stripped-down version of the previous one 3) The 'dep' one (= Simply with MODULES=dep) 4) A (now useless) custom slighlty enhanced version of the previous one And LILO knows them all very well ;-) I've tried them all in order: 1) and 2) lead to an early kernel panic 3) and 4) are all fine wrt all one can expect from an initrd. Now, that matter boils down to tree cases: 1) Linux has a problem with large initrd files. 2) LILO has a problem with large initrd files. 3) BOTH have a problem with large initrd files. I know a snake who bites its tail ... And now let's see my initrd sizes: 1) 7275892 bytes 2) 5738810 bytes 3) 3485038 bytes 4) 3686321 bytes Note: vmlinuz is 1727488 bytes But I can boot linux-image-2.6.24-1-amd64 (ver 2.6.24-7) without any problem and using an initrd of 7090895 bytes, and vmlinuz is 1668248 bytes. So, why had I an early kernel panic with version 2) (see above) of my initrd for linux-image-2.6.25-2-amd64 (ver 2.6.25-5) which is smaller ? In hope my report will prove useful. I'm looking forward to hearing from you. Sincerely, Valentin QUEQUET -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369298: Improve your resume in less than 40 days
A degree with no classes or test in your spare time Special accredited university program for working adults Call 24/7 on For US: 1-419-735-9250 Outside US: +1-419-735-9250 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487586: linux-image-2.6.25-2-686: Realtek / r8169 drivers do not properly detect link status or work at 1000BaseT (gigabit)
maximilian attems wrote, on 6/22/2008 5:31 PM: On Sun, Jun 22, 2008 at 04:51:45PM -0400, adam wrote: Package: linux-image-2.6.25-2-686 Version: 2.6.25-5 Severity: normal There is a widely-reported problem with the r8169 driver in certain configurations. Auto-link detection does not work, and while the device comes up it can't connect and the physical link light on the device turns off during the bootup process (maybe when the r8169 module is loaded). have you tried newer linux images based on 2.6.26-rcX ? see apt trunk lines http://wiki.debian.org/DebianKernel if you can reproduce there please report upstream on bugzilla.kernel.org and marc the bug as forwarded to this one. Works perfectly with 2.6.26-rc5. Thanks! Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#276500: #276500: utimensat added as syscall
For what it's worth, coreutils 6.12 and newer now use utimensat if available; and when coupled with a new enough kernel, no longer demonstrate the original issue reported against touch(1). However, in testing the coreutils patch to use utimensat, it was discovered that at least some versions of the kernel have a buggy utimensat syscall that return a bogus positive number instead of -1 on failure: http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=9840199 -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
