Bug#439188:
Package: linux-image-2.6.18-5-k7 Version: 2.6.18.dfsg.1-13etch1 BUG: unable to handle kernel NULL pointer dereference at virtual address 0074 printing eip: c016be39 *pde = Oops: [#2] SMP Modules linked in: ipt_TCPMSS ipt_recent xt_limit xt_tcpudp ip_nat_irc ip_nat_ftp iptable_nat iptable_mangle ipt_LOG ipt_MASQUERADE ip_nat ipt_TOS ipt_REJECT ip_conntrack_irc ip_conntrack_ftp xt_state ip_conntrack nfnetlink iptable_filter ip_tables x_tables button ac battery dm_crypt dm_snapshot dm_mirror dm_mod tsdev via_agp shpchp pci_hotplug agpgart rtc parport_pc via_ircc parport psmouse irda serio_raw crc_ccitt evdev pcspkr ext3 jbd mbcache ide_generic ide_cd cdrom ide_disk generic uhci_hcd usbcore via82cxxx ide_core thermal processor fan raid10 raid456 xor raid1 md_mod 3c59x mii CPU:0 EIP:0060:[c016be39]Tainted: G SVLI EFLAGS: 00010206 (2.6.18-5-k7 #1) EIP is at time_out_leases+0x33/0x45 eax: db4fce9c ebx: 0048 ecx: dfa694dc edx: esi: db4fcf40 edi: ebp: dfa694dc esp: c3717ea4 ds: 007b es: 007b ss: 0068 Process find (pid: 10213, ti=c3716000 task=f7a6b550 task.ti=c3716000) Stack: 00018801 c016cc42 00018801 db4fce9c db4fce9c c3717f3c c0165b1a db4fce9c f89418fa 0004 c0165c38 db4fce9c 00018801 c3717f3c c0166adb db4f7784 c3717f3c 00018801 c3717f3c c0168af6 Call Trace: [c016cc42] __break_lease+0x55/0x2bf [c0165b1a] generic_permission+0x57/0xcc [f89418fa] ext3_permission+0x0/0xa [ext3] [c0165c38] permission+0xa9/0xbc [c0166adb] may_open+0x131/0x20e [c0168af6] open_namei+0x23d/0x5b3 [c01592d0] do_filp_open+0x1c/0x31 [c01624f1] sys_lstat64+0x1e/0x23 [c0159323] do_sys_open+0x3e/0xb3 [c01593c5] sys_open+0x16/0x18 [c0102bed] sysenter_past_esp+0x56/0x79 Code: eb 23 8b 4b 44 85 c9 74 09 a1 80 11 31 c0 39 c8 79 04 89 de eb 0f 83 e2 ef 89 f0 e8 cb fe ff ff 3b 1e 0f 44 f3 8b 1e 85 db 74 0f f6 43 2c 20 74 09 0f b6 53 2d f6 c2 10 75 c8 5b 5e c3 53 89 c3 EIP: [c016be39] time_out_leases+0x33/0x45 SS:ESP 0068:c3717ea4 CPU: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(tm) XP 2000+ stepping: 2 cpu MHz : 1673.820 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts bogomips: 3350.52 PCI: 00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333] 00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP] 00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) 00:0b.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30) 00:11.0 ISA bridge: VIA Technologies, Inc. VT8233A ISA Bridge 00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) 00:11.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 23) 00:11.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 23) 01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Root on LVM bug
On Wed, Aug 22, 2007 at 08:35:08PM -0400, Adam C Powell IV wrote: I recently installed etch on an amd64 box which previously had Fedora. It had a small ext2 /boot and large LVM, so I shrunk Fedora's volume and made a new one for Debian, where I installed everything. I included the LVM modules in /etc/initramfs-tools/modules . Then I added the following section to /boot/grub/menu.lst : title Debian root (hd0,0) kernel /vmlinuz-2.6.18-4-amd64 root=/dev/VolGroup00/LogVol02 initrd /initrd.img-2.6.18-4-amd64 known bug see #378332, #402931; When I booted, it sat at Begin: Waiting for root file system... but the Fedora 2.6.11 kernel started right up with otherwise identical options (except that it couldn't load the Fedora modules in Debian). After a few hours of messing around, on a whim I tried changing the root= parameter to /dev/mapper/VolGroup00-LogVol02 , which worked! this is the real root dev So I believe something is wrong with either mount or udev used in the initramfs, such that it either doesn't create the /dev/groupname entries, or can't mount them. I did a ton of searching and couldn't find anything, so I don't think this is a known issue. no it is not an udev trouble. so the root arg you were passing is a symlink, it is only created after vgchange run. it is an chicken egg trouble, once you pass root=/dev/mapper/vg-lv it is certain to be an lvm2. unlinke to mdadm we can't enable all vg as lvm2 is prone to data corruption with empty vg. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [etch] driver updates for 2.6.18?
On Mon, Aug 20, 2007 at 04:53:15PM +0200, Frederik Schueler wrote: I would like to update a few drivers in 2.6.18 for the next point release of etch: I have a large update for xen. It is taken from the 3.1 branch, which seems to work fine with the xen in etch (better than the released version from Fedora). The summary of the functional changes is | 244 files changed, 11100 insertions(+), 6047 deletions(-) The complete one | 351 files changed, 18610 insertions(+), 7485 deletions(-) Most of the changes are different ways of porting the same functionalty to the version. The following problems should be fixed: - Event channel code is oopsy on smp systems. - PCI backend is broken. - Network backend looses all running connections after some months (this may be also a hypervisor problem). - Incorrect license specifications in the xen headers. Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, The Paradise Syndrome, stardate 4842.6 signature.asc Description: Digital signature
Bug#439219: linux-2.6: Update to forcedeth driver
Package: linux-2.6 Version: 2.6.18.dfsg.1-13etch1 Severity: wishlist Tags: patch Attached find a patch series to update the forcedeth driver in 2.6.18.dfsg.1-13etch1 to the version found in upstream kernel 2.6.22.3. Although the initial reason for this patch vanised by an bios update I am still running it on a Supermicro H8DM8-2 without any problem on the system below (i.e. currently forcedeth as shipped with 2.6.18.dfsg.1-13etch1/amd64 works for me, thus filed with severity wishlist). - Norbert -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/dash forcedeth-update-20070824.tar.gz Description: forcedeth-update-20070824.tar.gz
Processed: tagging 419197
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 tags 419197 + pending Bug#419197: CONFIG_USB_SUSPEND is experimental and breaks applications There were no tags set. Bug#419198: kooka seems to be scanning, but isn't Bug#419199: kooka seems to be scanning, but isn't 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]
Processed: tagging 439020
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 tags 439020 + pending Bug#439020: Please could CONFIG_TCG_TPM be set to '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]
Processed: tagging 435257
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 tags 435257 + pending Bug#435257: linux-image-2.6.22-1-686 doesn't detect Samsung ML-2010 USB printer 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]
initramfs-tools_0.90a_i386.changes ACCEPTED
Accepted: initramfs-tools_0.90a.dsc to pool/main/i/initramfs-tools/initramfs-tools_0.90a.dsc initramfs-tools_0.90a.tar.gz to pool/main/i/initramfs-tools/initramfs-tools_0.90a.tar.gz initramfs-tools_0.90a_all.deb to pool/main/i/initramfs-tools/initramfs-tools_0.90a_all.deb Override entries for your package: initramfs-tools_0.90a.dsc - source utils initramfs-tools_0.90a_all.deb - optional utils Announcing to [EMAIL PROTECTED] Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reopening 439188
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.7 reopen 439188 Bug#439188: 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: Root on LVM bug
On Thu, 2007-08-23 at 11:41 +0200, maximilian attems wrote: On Wed, Aug 22, 2007 at 08:35:08PM -0400, Adam C Powell IV wrote: I recently installed etch on an amd64 box which previously had Fedora. It had a small ext2 /boot and large LVM, so I shrunk Fedora's volume and made a new one for Debian, where I installed everything. I included the LVM modules in /etc/initramfs-tools/modules . Then I added the following section to /boot/grub/menu.lst : title Debian root (hd0,0) kernel /vmlinuz-2.6.18-4-amd64 root=/dev/VolGroup00/LogVol02 initrd /initrd.img-2.6.18-4-amd64 known bug see #378332, #402931; I see. Sorry I didn't see these bugs in my search. Thank you for the detailed explanation. -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe! http://www.take6.com/albums/greatesthits.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initramfs-tools / cryptoroot
hello Daniel,
On Wed, 22 Aug 2007, Daniel Reichelt wrote:
I'm administering several linux hosts, which are all set up to boot from a
luks-encrypted partition (which partly live in LVM). I was hacked off to have
to go down to the basement and enter the passwords manually on each and every
reboot. So why not let this be managed by a central boot server? So I've set
up the following process:
- included sshd/dhclient3 in initrd by a hook
why are you not using ipconfig, the klibc dhclient equiv.
if it doesn't work for you i'd be happy to know why!?
Please let me know what you think. If you like it, I'd gladly document
it further.
adding sshd to initramfs sounds not like a general way for the cryptsetup
guys to go. ;) anyway thanks for your creative way of using
initramfs-tools and showing it off. i glanced over the code and have some
small remarks.
#ensure boot scripts are executable
find $DESTDIR/scripts -name remoteunlock -exec chmod 755 {} \;
the scripts itself need to be executable on installation,
no need to rerun that on any update-initramfs.
you add more binaries than you actually use, i saw no mv and rm invocation
for example. for rm you can use nuke from klibc. for ifconfig use
ipconfig (yes can also set static dev). also bash seems quite redundant
and chown superfluous.
happy hacking
--
maks
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439242: ipw3945-modules-2.6.21-2-686: Older prebuilt package takes precedence over newer package built with m-a
Package: ipw3945-modules-2.6.21-2-686 Version: 1.2.2-1+2.6.21-6 Severity: normal The versioning info of the prebuilt packages seems to be different from the versioning used by module-assistant, so that after auto-install'ing the ipw3945-1.2.2-1 kernel module, aptitude wants to upgrade it to Debian's own ipw3945-1.2.1-3: ~-0# aptitude upgrade W: The upgrade command is deprecated; use safe-upgrade instead. Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Reading task descriptions... Done Building tag database... Done The following packages have been kept back: libgmp3-dev libgmp3c2 tzdata The following packages will be upgraded: ipw3945-modules-2.6.21-2-686 ipw3945-modules-2.6.22-1-686 2 packages upgraded, 0 newly installed, 0 to remove and 3 not upgraded. Need to get 0B/595kB of archives. After unpacking 81.9kB will be freed. Do you want to continue? [Y/n/?] (Reading database ... 190131 files and directories currently installed.) Preparing to replace ipw3945-modules-2.6.21-2-686 1.2.2-1+2.6.21-6 (using .../ipw3945-modules-2.6.21-2-686_2.6.21+1.2.1-3_i386.deb) ... Maybe this is not specific to ipw3945 but to module-assistant, tho: I don't use it nearly often enough to be able to tell. Stefan -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.21-2-686 (SMP w/2 CPU cores) Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ipw3945-modules-2.6.21-2-686 depends on: hi linux-image-2.6.21-2-686 [lin 2.6.21-6 Linux 2.6.21 image on PPro/Celeron ipw3945-modules-2.6.21-2-686 recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Root on LVM bug
maximilian attems wrote: lvm2 is prone to data corruption with empty vg. Is this recorded in the BTS? -- Alexander E. Patrakov -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [etch] driver updates for 2.6.18?
On Thu, Aug 23, 2007 at 01:34:26PM +0200, Bastian Blank wrote: On Mon, Aug 20, 2007 at 04:53:15PM +0200, Frederik Schueler wrote: I would like to update a few drivers in 2.6.18 for the next point release of etch: I have a large update for xen. It is taken from the 3.1 branch, which seems to work fine with the xen in etch (better than the released version from Fedora). The summary of the functional changes is | 244 files changed, 11100 insertions(+), 6047 deletions(-) The complete one | 351 files changed, 18610 insertions(+), 7485 deletions(-) Most of the changes are different ways of porting the same functionalty to the version. The following problems should be fixed: - Event channel code is oopsy on smp systems. - PCI backend is broken. - Network backend looses all running connections after some months (this may be also a hypervisor problem). - Incorrect license specifications in the xen headers. Each of those sounds like a reasonable thing to fix in a point release, but such a large change does not. I don't see how we can demonstrate confidence that such a change will not cause regressions. For 2.6.18, I'd prefer to see a bug/fix per issue with some explanation about why the bug is = important severity and why the fix is unlikely to cause regressions. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439072: snd-intel8x0 line-in not working in later 2.6.x kernels
On Wed, Aug 22, 2007 at 08:10:19PM +0200, Josip Rodin wrote: Hi Adrian, On Wed, Aug 22, 2007 at 04:13:19AM +0200, Josip Rodin wrote: I'm reporting this bug that I have been seeing for a while and which is a regression from a few months/years ago - the line-in input simply doesn't work right. arecord(1) just doesn't record anything with it, it doesn't show any errors, it records silence. The recording from the same external source works just fine with the microphone input. I re-selected the old-style i810_audio driver in 2.6.21 and compiled it, unloaded the ALSA driver, loaded the old driver, and voila, everything went back to normal, I can hear the TV sound just fine. So, it might be that this is an OSS-ALSA regression that slipped through the cracks? While browsing kernel options, I noticed: Please contact Adrian Bunk [EMAIL PROTECTED] if you had to say Y here because your hardware is not properly supported by ALSA. ...in the description of CONFIG_OSS_OBSOLETE, so, here I am :) This is Debian bug #439072 (and #384933 also looks suspiciously similar, if I might add). Please do the following: - check at the ALSA bug tracking system [1] whether your problem was already reported - if there isn't already a bug for it, open a new bug - in any case, tell me the bug number so that I can track this issue TIA Adrian [1] http://bugtrack.alsa-project.org/alsa-bug/ -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 439224, tagging 439225
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.7 tags 439224 security Bug#439224: CVE-2007-2172 kernel-source-2.4.27 There were no tags set. Tags added: security tags 439225 security Bug#439225: CVE-2007-2172 kernel-source-2.6.8 There were no tags set. Tags added: security 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: Reorganizing packages
Steve Langasek [EMAIL PROTECTED] writes: For that matter, if someone in the project decides that they have need for a different kernel than the one the kernel team wants to ship (for a particular port, or to support older hardware, or to support a newer cutting-edge kernel design, or for some other reason), the kernel team doesn't have the authority to prohibit this. Yes, kernel team has no authorit to prohibit it but at same time, since there's not need for it now and neither in a near future, kernel team can also do the package renaming and ignore this possibility. -- 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]
Re: [etch] driver updates for 2.6.18?
On Thu, Aug 23, 2007 at 10:51:01AM -0600, dann frazier wrote: Each of those sounds like a reasonable thing to fix in a point release, but such a large change does not. I don't see how we can demonstrate confidence that such a change will not cause regressions. Known and ignored because of the amount of problems with the current used patch. For 2.6.18, I'd prefer to see a bug/fix per issue with some explanation about why the bug is = important severity and why the fix is unlikely to cause regressions. This means someone have to find the cause of the problems and isolate the necessary changes to fix it. I won't do it because I have better things to do. I already roll out my own kernels with the Xen 3.1 patch because of the problems for my priviledged domains. This means I'm not longer able to do any tests anyway. Bastian -- Power is danger. -- The Centurion, Balance of Terror, stardate 1709.2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux-latest-2.6_6etch2_ia64.changes ACCEPTED
Accepted: kernel-image-2.6-itanium-smp_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/kernel-image-2.6-itanium-smp_2.6.18+6etch2_ia64.deb kernel-image-2.6-itanium_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/kernel-image-2.6-itanium_2.6.18+6etch2_ia64.deb kernel-image-2.6-mckinley-smp_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/kernel-image-2.6-mckinley-smp_2.6.18+6etch2_ia64.deb kernel-image-2.6-mckinley_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/kernel-image-2.6-mckinley_2.6.18+6etch2_ia64.deb linux-headers-2.6-itanium_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-headers-2.6-itanium_2.6.18+6etch2_ia64.deb linux-headers-2.6-mckinley_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-headers-2.6-mckinley_2.6.18+6etch2_ia64.deb linux-image-2.6-itanium-smp_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-image-2.6-itanium-smp_2.6.18+6etch2_ia64.deb linux-image-2.6-itanium_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-image-2.6-itanium_2.6.18+6etch2_ia64.deb linux-image-2.6-mckinley-smp_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-image-2.6-mckinley-smp_2.6.18+6etch2_ia64.deb linux-image-2.6-mckinley_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-image-2.6-mckinley_2.6.18+6etch2_ia64.deb linux-image-itanium_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-image-itanium_2.6.18+6etch2_ia64.deb linux-image-mckinley_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-image-mckinley_2.6.18+6etch2_ia64.deb linux-latest-2.6_6etch2.dsc to pool/main/l/linux-latest-2.6/linux-latest-2.6_6etch2.dsc linux-latest-2.6_6etch2.tar.gz to pool/main/l/linux-latest-2.6/linux-latest-2.6_6etch2.tar.gz Override entries for your package: kernel-image-2.6-itanium-smp_2.6.18+6etch2_ia64.deb - extra admin kernel-image-2.6-itanium_2.6.18+6etch2_ia64.deb - extra admin kernel-image-2.6-mckinley-smp_2.6.18+6etch2_ia64.deb - extra admin kernel-image-2.6-mckinley_2.6.18+6etch2_ia64.deb - extra admin linux-headers-2.6-itanium_2.6.18+6etch2_ia64.deb - optional devel linux-headers-2.6-mckinley_2.6.18+6etch2_ia64.deb - optional devel linux-image-2.6-itanium-smp_2.6.18+6etch2_ia64.deb - extra admin linux-image-2.6-itanium_2.6.18+6etch2_ia64.deb - optional admin linux-image-2.6-mckinley-smp_2.6.18+6etch2_ia64.deb - extra admin linux-image-2.6-mckinley_2.6.18+6etch2_ia64.deb - optional admin linux-image-itanium_2.6.18+6etch2_ia64.deb - optional admin linux-image-mckinley_2.6.18+6etch2_ia64.deb - optional admin linux-latest-2.6_6etch2.dsc - optional admin Announcing to [EMAIL PROTECTED] Closing bugs: 438617 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438617: marked as done (linux-image-2.6-ixp4xx: Still depends on vulnerable kernel image linux-image-2.6.18-4*)
Your message dated Thu, 23 Aug 2007 19:56:15 + with message-id [EMAIL PROTECTED] and subject line Bug#438617: fixed in linux-latest-2.6 6etch2 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) ---BeginMessage--- Package: linux-image-2.6-ixp4xx Version: 2.6.18+6 Severity: important This is basically the same as bug 438325 but for arm (ipx4xx). It's been two days since 438325 was closed, and while the i386 page on packages.debian.org shows the updated package, the ipx4xx page does not, so maybe it slipped through the cracks. If it's just that ARM packages are uploaded after the 4.0r1 release announcement, then I'm sorry to waste your time. (http://packages.debian.org/stable/admin/linux-image-2.6-ixp4xx vs http://packages.debian.org/stable/admin/linux-image-2.6-686) This kernel package still depends on the 2.6.18-4-* image, so the updated 2.6.18-5-* is not pulled in with apt-get. Cheers -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: arm (armv5tel) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-ixp4xx Locale: LANG=C, LC_CTYPE=no_NO.ISO8859-1 (charmap=ISO-8859-1) Versions of packages linux-image-2.6-ixp4xx depends on: ii linux-image-2.6.18 2.6.18.dfsg.1-12etch2 Linux 2.6.18 image on IXP4xx linux-image-2.6-ixp4xx recommends no packages. -- no debconf information ---End Message--- ---BeginMessage--- Source: linux-latest-2.6 Source-Version: 6etch2 We believe that the bug you reported is fixed in the latest version of linux-latest-2.6, which is due to be installed in the Debian FTP archive: kernel-image-2.6-itanium-smp_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/kernel-image-2.6-itanium-smp_2.6.18+6etch2_ia64.deb kernel-image-2.6-itanium_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/kernel-image-2.6-itanium_2.6.18+6etch2_ia64.deb kernel-image-2.6-mckinley-smp_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/kernel-image-2.6-mckinley-smp_2.6.18+6etch2_ia64.deb kernel-image-2.6-mckinley_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/kernel-image-2.6-mckinley_2.6.18+6etch2_ia64.deb linux-headers-2.6-itanium_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-headers-2.6-itanium_2.6.18+6etch2_ia64.deb linux-headers-2.6-mckinley_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-headers-2.6-mckinley_2.6.18+6etch2_ia64.deb linux-image-2.6-itanium-smp_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-image-2.6-itanium-smp_2.6.18+6etch2_ia64.deb linux-image-2.6-itanium_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-image-2.6-itanium_2.6.18+6etch2_ia64.deb linux-image-2.6-mckinley-smp_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-image-2.6-mckinley-smp_2.6.18+6etch2_ia64.deb linux-image-2.6-mckinley_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-image-2.6-mckinley_2.6.18+6etch2_ia64.deb linux-image-itanium_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-image-itanium_2.6.18+6etch2_ia64.deb linux-image-mckinley_2.6.18+6etch2_ia64.deb to pool/main/l/linux-latest-2.6/linux-image-mckinley_2.6.18+6etch2_ia64.deb linux-latest-2.6_6etch2.dsc to pool/main/l/linux-latest-2.6/linux-latest-2.6_6etch2.dsc linux-latest-2.6_6etch2.tar.gz to pool/main/l/linux-latest-2.6/linux-latest-2.6_6etch2.tar.gz A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. dann frazier [EMAIL PROTECTED] (supplier of updated linux-latest-2.6 package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 20 Aug 2007 17:01:18 -0600 Source: linux-latest-2.6 Binary: linux-image-xen-vserver-686 linux-image-2.6-powerpc-miboot linux-headers-2.6-vserver-alpha linux-image-2.6-footbridge linux-image-2.6-amd64-generic linux-headers-2.6-xen-vserver-686 linux-image-2.6-parisc64 linux-headers-2.6-xen-686 kernel-image-2.6-686-smp linux-image-2.6-486 linux-headers-2.6-atari linux-headers-2.6-vserver-686 kernel-image-2.6-386 linux-headers-2.6-s390 linux-image-qemu linux-image-2.6-amd64-k8-smp linux-image-itanium
linux/types.h - glibc interferences
Hi folks
linux/types.h exports some POSIX types. It can be asked to stop this
with __KERNEL_STRICT_NAMES. features.h defines this. So currently
anything works if features.h is included before linux/types.h.
This is not properly fixable by the glibc. The attached patch fixes it
in linux, but I'm unsure if this will not break other things like
alternative libc.
Bastian
--
You can't evaluate a man by logic alone.
-- McCoy, I, Mudd, stardate 4513.3
diff --git a/include/linux/types.h b/include/linux/types.h
index 0351bf2..a9779d6 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -14,10 +14,10 @@
#include linux/posix_types.h
#include asm/types.h
-#ifndef __KERNEL_STRICT_NAMES
-
typedef __u32 __kernel_dev_t;
+#ifdef __KERNEL__
+
typedef __kernel_fd_set fd_set;
typedef __kernel_dev_t dev_t;
typedef __kernel_ino_t ino_t;
@@ -32,7 +32,6 @@ typedef __kernel_timer_t timer_t;
typedef __kernel_clockid_t clockid_t;
typedef __kernel_mqd_t mqd_t;
-#ifdef __KERNEL__
typedef _Bool bool;
typedef __kernel_uid32_t uid_t;
@@ -46,51 +45,14 @@ typedef __kernel_old_uid_t old_uid_t;
typedef __kernel_old_gid_t old_gid_t;
#endif /* CONFIG_UID16 */
-/* libc5 includes this file to define uid_t, thus uid_t can never change
- * when it is included by non-kernel code
- */
-#else
-typedef __kernel_uid_t uid_t;
-typedef __kernel_gid_t gid_t;
-#endif /* __KERNEL__ */
-
-#if defined(__GNUC__) !defined(__STRICT_ANSI__)
typedef __kernel_loff_t loff_t;
-#endif
-/*
- * The following typedefs are also protected by individual ifdefs for
- * historical reasons:
- */
-#ifndef _SIZE_T
-#define _SIZE_T
typedef __kernel_size_t size_t;
-#endif
-
-#ifndef _SSIZE_T
-#define _SSIZE_T
typedef __kernel_ssize_t ssize_t;
-#endif
-
-#ifndef _PTRDIFF_T
-#define _PTRDIFF_T
typedef __kernel_ptrdiff_t ptrdiff_t;
-#endif
-
-#ifndef _TIME_T
-#define _TIME_T
typedef __kernel_time_t time_t;
-#endif
-
-#ifndef _CLOCK_T
-#define _CLOCK_T
typedef __kernel_clock_t clock_t;
-#endif
-
-#ifndef _CADDR_T
-#define _CADDR_T
typedef __kernel_caddr_t caddr_t;
-#endif
/* bsd */
typedef unsigned char u_char;
@@ -104,27 +66,18 @@ typedef unsigned short ushort;
typedef unsigned int uint;
typedef unsigned long ulong;
-#ifndef __BIT_TYPES_DEFINED__
-#define __BIT_TYPES_DEFINED__
-
+typedef __u8 uint8_t;
typedef __u8 u_int8_t;
typedef __s8 int8_t;
+typedef __u16 uint16_t;
typedef __u16 u_int16_t;
typedef __s16 int16_t;
+typedef __u32 uint32_t;
typedef __u32 u_int32_t;
typedef __s32 int32_t;
-
-#endif /* !(__BIT_TYPES_DEFINED__) */
-
-typedef __u8 uint8_t;
-typedef __u16 uint16_t;
-typedef __u32 uint32_t;
-
-#if defined(__GNUC__) !defined(__STRICT_ANSI__)
typedef __u64 uint64_t;
typedef __u64 u_int64_t;
typedef __s64 int64_t;
-#endif
/* this is a special 64bit data type that is 8-byte aligned */
#define aligned_u64 unsigned long long __attribute__((aligned(8)))
@@ -160,7 +113,7 @@ typedef unsigned long blkcnt_t;
#define pgoff_t unsigned long
#endif
-#endif /* __KERNEL_STRICT_NAMES */
+#endif /* __KERNEL__ */
/*
* Below are truly Linux-specific types that should never collide with
@@ -182,10 +135,8 @@ typedef __u16 __bitwise __le16;
typedef __u16 __bitwise __be16;
typedef __u32 __bitwise __le32;
typedef __u32 __bitwise __be32;
-#if defined(__GNUC__) !defined(__STRICT_ANSI__)
-typedef __u64 __bitwise __le64;
-typedef __u64 __bitwise __be64;
-#endif
+__extension__ typedef __u64 __bitwise __le64;
+__extension__ typedef __u64 __bitwise __be64;
typedef __u16 __bitwise __sum16;
typedef __u32 __bitwise __wsum;
@@ -198,8 +149,6 @@ typedef u64 resource_size_t;
typedef u32 resource_size_t;
#endif
-#endif /* __KERNEL__ */
-
struct ustat {
__kernel_daddr_t f_tfree;
__kernel_ino_t f_tinode;
@@ -207,4 +156,6 @@ struct ustat {
char f_fpack[6];
};
+#endif /* __KERNEL__ */
+
#endif /* _LINUX_TYPES_H */
Processed: Re: Bug#436166: [Pkg-lirc-maint] Bug#436166: Progress notes
Processing commands for [EMAIL PROTECTED]: reassign 436166 lirc Bug#436166: Please ship bttv.h in linux-headers-* Bug reassigned from package `linux-2.6' to `lirc'. stop 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#436166: [Pkg-lirc-maint] Bug#436166: Progress notes
reassign 436166 lirc stop On Sat, Aug 11, 2007, Stephen Gran wrote: bttv.h is a 'private' header, and not included in the kernel headers shipped in Debian. This is why there is an attempt at versioned bttv.h headers in lirc itself. It's a bad hack, but I'm not sure what else can be done. Ok, thanks for the explanations. I guess there are different ways to handle this issue: 1) make the header public and ship it in the kernel headers; not sure this is likely to happen, no idea of the policy for such stuff 2) ship the header in lirc; doesn't sound like a good idea 3) document that you need a full kernel tree -- and not just kernel headers -- to build the lirc modules; wouldn't help our users that much I'm afraid 4) 3 + automatically select the modules that can be built I think it would be best to prepare the newest upstream release first, and see what upstream recommends on this matter. I was happy to cleanup the packaging of lirc, but I can't really prepare an upstream myself as I don't own any lirc-supported hardware; I hope another person of the lirc team can prepare the new upstream release and test it until we revisit this issue. -- Loïc Minier
Re: [kernel] r9352 - in dists/etch/linux-2.6/debian: . patches/features/all/drivers patches/series
On Thu, Aug 23, 2007 at 10:07:32AM +, Frederik Sch??ler wrote: Author: fs Date: Thu Aug 23 10:07:32 2007 New Revision: 9352 Log: Add support for 3ware 9650SE controllers. Where's the bug report for this, and how do you know it doesn't regress anything with other controllers? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439072: snd-intel8x0 line-in not working in later 2.6.x kernels
On Thu, Aug 23, 2007 at 07:04:13PM +0200, Adrian Bunk wrote: While browsing kernel options, I noticed: Please contact Adrian Bunk [EMAIL PROTECTED] if you had to say Y here because your hardware is not properly supported by ALSA. ...in the description of CONFIG_OSS_OBSOLETE, so, here I am :) This is Debian bug #439072 (and #384933 also looks suspiciously similar, if I might add). Please do the following: - check at the ALSA bug tracking system [1] whether your problem was already reported - if there isn't already a bug for it, open a new bug - in any case, tell me the bug number so that I can track this issue I found several bug reports that sounded familiar, but none of them described this exact issue. This is the new ticket I just filed: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3335 -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux/types.h - glibc interferences
On Thu, Aug 23, 2007 at 10:08:44PM +0200, Bastian Blank wrote: linux/types.h exports some POSIX types. It can be asked to stop this with __KERNEL_STRICT_NAMES. features.h defines this. So currently anything works if features.h is included before linux/types.h. This is not properly fixable by the glibc. The attached patch fixes it in linux, but I'm unsure if this will not break other things like alternative libc. Is there some specific reported issue that this change is intended to fix? I haven't noticed any complaints about the current behavior. I assume this isn't intended as the fix for 429064, since 429064 is reporting an issue with a kernel type which is currently *not* guarded with __KERNEL_STRICT_NAMES; your patch fixes this, but only as a side-effect. Anyway, it's my understanding that userspace apps are never supposed to define __KERNEL__ and doing so with linux-libc-dev gives broken includes, so in terms of overall design this change looks wrong to me (or at least, gratuitously strict). If there's userspace code that wants to get the kernel types under the standard posix names, why break that? (For an example of code that probably breaks with this change, I offer you aboot, the alpha bootloader; it's not great code, but we have to maintain it all the same...) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [etch] driver updates for 2.6.18?
On Thu, 23 Aug 2007, dann frazier wrote: On Thu, Aug 23, 2007 at 01:34:26PM +0200, Bastian Blank wrote: seems to work fine with the xen in etch (better than the released version from Fedora). The summary of the functional changes is | 244 files changed, 11100 insertions(+), 6047 deletions(-) The complete one | 351 files changed, 18610 insertions(+), 7485 deletions(-) Most of the changes are different ways of porting the same functionalty to the version. The following problems should be fixed: - Event channel code is oopsy on smp systems. - PCI backend is broken. - Network backend looses all running connections after some months (this may be also a hypervisor problem). - Incorrect license specifications in the xen headers. Each of those sounds like a reasonable thing to fix in a point release, but such a large change does not. I don't see how we can demonstrate confidence that such a change will not cause regressions. xen in etch is way beyond broken. i don't even start looking when the bug report mentions xen. the bts has *way* too much xen bugs. i doubt it is worth the effort to isolate them to some specific changesets. please take the bts fact in consideration for the etch update xen decision. -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: linux/types.h - glibc interferences
On Thu, Aug 23, 2007 at 02:46:14PM -0700, Steve Langasek wrote: Is there some specific reported issue that this change is intended to fix? I haven't noticed any complaints about the current behavior. #434040 and a hand full of packages on the buildd. Anyway, it's my understanding that userspace apps are never supposed to define __KERNEL__ and doing so with linux-libc-dev gives broken includes, so in terms of overall design this change looks wrong to me (or at least, gratuitously strict). __KERNEL__-only parts of the headers are filtered out for linux-libc-dev. If there's userspace code that wants to get the kernel types under the standard posix names, why break that? Please provide a less strict fix which works. Userspace code can only use this definitions within a freestanding compiler without libc. (For an example of code that probably breaks with this change, I offer you aboot, the alpha bootloader; it's not great code, but we have to maintain it all the same...) Thats what I expected. Bastian -- A little suffering is good for the soul. -- Kirk, The Corbomite Maneuver, stardate 1514.0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: severity of 402562 is important
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.7 # SRM considers lack of hardware support to be important severity 402562 important Bug#402562: Please support newer 3ware controllers Severity set to `important' from `wishlist' 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]
Processed: tagging 402562
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.26 tags 402562 + pending Bug#402562: Please support newer 3ware controllers Tags were: patch Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initramfs-tools / cryptoroot
Hi Max,
why are you not using ipconfig, the klibc dhclient equiv.
if it doesn't work for you i'd be happy to know why!?
1) I've overlooked udphcpc is compiled into initramfs-tools' busybox
2) I've tried (roughly) this afternoon to use udhcpc, it just says it's missing
some script. Gotta look deeper into this when I've some spare time...
#ensure boot scripts are executable
find $DESTDIR/scripts -name remoteunlock -exec chmod 755 {} \;
the scripts itself need to be executable on installation,
no need to rerun that on any update-initramfs.
noted
you add more binaries than you actually use, i saw no mv and rm invocation
for example. for rm you can use nuke from klibc. for ifconfig use
ipconfig (yes can also set static dev). also bash seems quite redundant
and chown superfluous.
I know...but dhclient3 requires these commands to be available as real
binaries, not just as busy-box commands, otherwise it complains and ceases
functioning. Of course, this issue will be obsolete as soon as I have udhcpc
working.
Cu,
Daniel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [etch] driver updates for 2.6.18?
On Thu, Aug 23, 2007 at 07:53:49PM +0200, maximilian attems wrote: xen in etch is way beyond broken. i don't even start looking when the bug report mentions xen. the bts has *way* too much xen bugs. i doubt it is worth the effort to isolate them to some specific changesets. please take the bts fact in consideration for the etch update xen decision. Though I certainly empathize, accepting such a large patch is in conflict with SRM policy. My interpretation of this policy is that breaking existing users is the worst possible outcome. If we accept this patch and enable 100 new people to run Xen, but at the same time introduce some corner-case regression that breaks 10 previously-stable users, then we've failed. Our primary goal in a stable release is to keep existing happy users happy. Enabling new users and fixing bugs for existing users are good things, but secondary. I want users to have no reason to think that rebooting their computer after a point release is going to cause them any downtime - after all, they really don't have the option of staying on their old/working bits if they want to accept future security updates. I think the only option to get such a large patch into etch at this point would be w/ etch 1/2, though I've no clue if upstream Xen is at all caught up w/ recent 2.6. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: initramfs-tools / cryptoroot
hello daniel, On Fri, Aug 24, 2007 at 12:28:22AM +0200, Daniel Reichelt wrote: why are you not using ipconfig, the klibc dhclient equiv. if it doesn't work for you i'd be happy to know why!? 1) I've overlooked udphcpc is compiled into initramfs-tools' busybox 2) I've tried (roughly) this afternoon to use udhcpc, it just says it's missing some script. Gotta look deeper into this when I've some spare time... wasn't talking about udphcpc but ipconfig see usage in /usr/share/initramfs-tools/scripts/nfs boils down to ipconfig device -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439295: linux-image-2.6.21-2-686: System fails to boot
Package: linux-image-2.6.21-2-686 Version: 2.6.21-6 Severity: critical Justification: breaks the whole system *** Please type your report below this line *** After upgrading from linux-image-2.6.18-4-686 to linux-image-2.6.21-2-686, the system fails to boot because the kernel now suddenly sees hard drive as /dev/sda while linux-image-2.6.18-4-686 saw the same hard drive as /dev/hda. After editing /boot/grub/menu.lst and changing /dev/hda5 to /dev/sda5, ( title Debian GNU/Linux, kernel 2.6.22-1-686 root(hd0,4) kernel /boot/vmlinuz-2.6.22-1-686 root=/dev/sda5 ro vga=791 video=vesa:ywrap,mtrr initrd /boot/initrd.img-2.6.22-1-686 savedefault ) the system boots O.K with linux-image-2.6.21-2-686, but fails to enable dma for /dev/sda. So I installed linux-source-2.6.22 and compiled a new kernel with my own custom configuration, which saw the hard drive again as /dev/hda and enabled dma without problems. Still, I'd much prefer to use Debian's linux-image packages instead of custom compiled kernels. I also tried linux-image-2.6.22-1-686, which acts just like linux-image-2.6.21-2-686. Vesa lspci: 00:00.0 Host bridge: Silicon Integrated Systems [SiS] Unknown device 0649 (rev 10) 00:01.0 PCI bridge: Silicon Integrated Systems [SiS] PCI-to-PCI bridge 00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS965 [MuTIOL Media IO] (rev 48) 00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev 01) 00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] AC'97 Sound Controller (rev a0) 00:03.0 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) 00:03.1 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) 00:03.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 0f) 00:03.3 USB Controller: Silicon Integrated Systems [SiS] USB 2.0 Controller 00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] 191 Gigabit Ethernet Adapter 00:05.0 IDE interface: Silicon Integrated Systems [SiS] 182 SATA/RAID Controller (rev 01) 00:06.0 PCI bridge: Silicon Integrated Systems [SiS] PCI-to-PCI bridge 00:07.0 PCI bridge: Silicon Integrated Systems [SiS] PCI-to-PCI bridge 00:0b.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) 03:00.0 VGA compatible controller: nVidia Corporation NV44 [GeForce 6200 SE TurboCache (TM)] (rev a1) dmesg for linux-image-2.6.21-2-686 after editing /boot/grub/menu.lst (as described above): Linux version 2.6.21-2-686 (Debian 2.6.21-6) ([EMAIL PROTECTED]) (gcc version 4.1.3 20070629 (prerelease) (Debian 4.1.2-13)) # BIOS-provided physical RAM map: sanitize start sanitize end copy_e820_map() start: size: 0009fc00 end: 0009fc00 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 0009fc00 size: 0400 end: 000a type: 2 copy_e820_map() start: 000e size: 0002 end: 0010 type: 2 copy_e820_map() start: 0010 size: 3fe1 end: 3ff1 type: 1 copy_e820_map() type is E820_RAM copy_e820_map() start: 3ff1 size: 0001 end: 3ff2 type: 3 copy_e820_map() start: 3ff2 size: 000e end: 4000 type: 4 copy_e820_map() start: ff7c size: 0084 end: 0001 type: 2 BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - 3ff1 (usable) BIOS-e820: 3ff1 - 3ff2 (ACPI data) BIOS-e820: 3ff2 - 4000 (ACPI NVS) BIOS-e820: ff7c - 0001 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000ff780 Entering add_active_range(0, 0, 261904) 0 entries of 256 used Zone PFN ranges: DMA 0 - 4096 Normal 4096 - 229376 HighMem229376 - 261904 early_node_map[1] active PFN ranges 0:0 - 261904 On node 0 totalpages: 261904 DMA zone: 32 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4064 pages, LIFO batch:0 Normal zone: 1760 pages used for memmap Normal zone: 223520 pages, LIFO batch:31 HighMem zone: 254 pages used for memmap HighMem zone: 32274 pages, LIFO batch:7 DMI 2.3 present. ACPI: RSDP 000FB510, 0024 (r2 ACPIAM) ACPI: XSDT 3FF10100, 003C (r1 A M I OEMXSDT 7000511 MSFT 97) ACPI: FACP 3FF10290, 00F4 (r3 A M I OEMFACP 7000511 MSFT 97) ACPI: DSDT 3FF10430, 4054 (r1 A0231 A02310000 INTL 2002026) ACPI: FACS 3FF2, 0040 ACPI: APIC 3FF10390, 005C (r1 A M I OEMAPIC 7000511 MSFT 97) ACPI: MCFG 3FF103F0, 003C (r1 A M I OEMMCFG 7000511 MSFT 97) ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01]
Re: initramfs-tools / cryptoroot
Hi, On Fri, Aug 24, 2007 at 12:28:22AM +0200, Daniel Reichelt wrote: why are you not using ipconfig, the klibc dhclient equiv. if it doesn't work for you i'd be happy to know why!? wasn't talking about udphcpc but ipconfig see usage in /usr/share/initramfs-tools/scripts/nfs boils down to ipconfig device not udphcpc, but udhcpc (I caused the typo :-) Ah ok. Well, because I wouldn't want to mix static/dynamic IP address assigning in a larger network. Admittedly, I haven't implemented that completely consitent (yet), e.g. the DHCP-option send-hostname is missing (this works for me 'cause I'm practically not assigning IPs from the dynamic pool, thus having them in static DNS). To get back to your question: if you use s.th. like cryptopts=...,ip=192.168.5.2, just that IP will be set, no dhcpc started etc. What's still missing here is passing the netmask via kernel cmdline. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#439072: snd-intel8x0 line-in not working in later 2.6.x kernels
forwarded 439072 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3335 thanks On Thu, Aug 23, 2007 at 11:17:28PM +0200, Josip Rodin wrote: On Thu, Aug 23, 2007 at 07:04:13PM +0200, Adrian Bunk wrote: While browsing kernel options, I noticed: Please contact Adrian Bunk [EMAIL PROTECTED] if you had to say Y here because your hardware is not properly supported by ALSA. ...in the description of CONFIG_OSS_OBSOLETE, so, here I am :) This is Debian bug #439072 (and #384933 also looks suspiciously similar, if I might add). Please do the following: - check at the ALSA bug tracking system [1] whether your problem was already reported - if there isn't already a bug for it, open a new bug - in any case, tell me the bug number so that I can track this issue I found several bug reports that sounded familiar, but none of them described this exact issue. This is the new ticket I just filed: https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3335 Thanks for doing this. The SOUND_ICH option is currently removed in 2.6.23-rc, but I'll get this reverted if this bug won't be fixed soon. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#439072: snd-intel8x0 line-in not working in later 2.6.x kernels
Processing commands for [EMAIL PROTECTED]: forwarded 439072 https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3335 Bug#439072: snd-intel8x0 line-in not working in later 2.6.x kernels Noted your statement that Bug has been forwarded to https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3335. 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]
Processed: retitle 389807 to xen modules packages make debsums fail
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.7 retitle 389807 xen modules packages make debsums fail Bug#389807: Breaks debsums Changed Bug title to `xen modules packages make debsums fail' from `Breaks debsums'. 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]
Processed: reassign 425692 to linux-2.6
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.7 reassign 425692 linux-2.6 Bug#425692: enabling CONFIG_PARAVIRT causes fglrx and vmware to be unusable Warning: Unknown package 'linux-image-2.6.21-1-686' Bug reassigned from package `linux-image-2.6.21-1-686' to `linux-2.6'. 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]
Processed: forcibly merging 419943 425692
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.10.7 forcemerge 419943 425692 Bug#419943: linux-2.6: CONFIG_PARAVIRT breaks some external modules Bug#425692: enabling CONFIG_PARAVIRT causes fglrx and vmware to be unusable Forcibly Merged 419943 425692. 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]
