Re: Linux 3.2 in wheezy
The only featureset provided will be 'rt' (realtime), currently built for amd64 only. If there is interest in realtime support for other architectures, we may be able to add that. We at MSU are definitly interested in -rt for 32-bit x86 (with pae). Before now, we have been building packages locally, however using distribution packages is definitly better. Nikita -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201201292255.57264@blacky.localdomain
Bug#542250: repeatable crashes while copying 500G from NFS mount to local logical volume
Is there any chance to get this fix into lenny? AFAIU, this bug may affect both i386 and amd64, both dom0 and domU [if domU is running -xen flavour], almost on any hardware with 1 CPUs, and cause system crash... Yes, I have added it to the lenny branch. Hi I don't see any mention of this fix in the changelog of linux-2.6 2.6.26-19 package, included in the just-released lenny update. Is that for a reason? I'm asking because if 2.6.26-19 still contains #542250, I should not allow it into our servers. Nikita signature.asc Description: This is a digitally signed message part.
Bug#542250: Another backtrace of the same
Here is one more backtrace of the same crash.
[ 9199.462928] Call Trace:
[ 9199.462928] IRQ [80435886] ? _spin_lock+0x3a/0x42
[ 9199.462928] [a00964f4] ? :sata_sil:sil_interrupt+0x2b/0x275
[ 9199.462928] [8025f0e6] ? handle_IRQ_event+0x47/0x8e
[ 9199.462928] [802605a2] ? handle_level_irq+0xae/0x116
[ 9199.462928] [8020e13e] ? do_IRQ+0x4e/0x9a
[ 9199.462928] [8037d4cc] ? evtchn_do_upcall+0x13c/0x1fc
[ 9199.462928] [8020bbde] ? do_hypervisor_callback+0x1e/0x30
[ 9199.462928] EOI [802e48d1] ? dummy_inode_permission+0x0/0x3
[ 9199.462928] [8037cbf9] ? xen_poll_irq+0x67/0x74
[ 9199.462928] [8037fb06] ? xen_spin_wait+0xfa/0x139
[ 9199.462928] [80435cfd] ? lock_kernel+0x4f/0x63
[ 9199.462928] [a04327b4] ? :nfs:nfs_permission+0xb0/0x15f
[ 9199.462928] [80291e65] ? permission+0xb5/0x118
[ 9199.462928] [80293469] ? __link_path_walk+0x145/0xdfa
[ 9199.462928] [a044020a] ? :nfs:nfs_sync_mapping_wait+0x151/0x33f
[ 9199.462928] [80294164] ? path_walk+0x46/0x8b
[ 9199.462928] [80294490] ? do_path_lookup+0x158/0x1ce
[ 9199.462928] [80294fd3] ? __path_lookup_intent_open+0x56/0x97
[ 9199.462928] [80295109] ? do_filp_open+0x9c/0x7c4
[ 9199.462928] [802888ff] ? get_unused_fd_flags+0x74/0x13f
[ 9199.462928] [80288a10] ? do_sys_open+0x46/0xc3
[ 9199.462928] [8020b528] ? system_call+0x68/0x6d
[ 9199.462928] [8020b4c0] ? system_call+0x0/0x6d
What is similar in all instances - it enters
... - lock_kernel() - xen_spin_wait() - xen_poll_irq(),
then gets an interrupt, then enters
... - :sata_sil:sil_interrupt() - _spin_lock()
and gets kernel BUG at drivers/xen/core/spinlock.c:74
which is xen_spin_wait():
...
66 /* announce we're spinning */
67 spinning = __get_cpu_var(spinning);
68 if (spinning-lock) {
69 BUG_ON(spinning-lock == lock);
70 if(raw_irqs_disabled()) {
71 BUG_ON(__get_cpu_var(spinning_bh).lock == lock);
72 spinning = __get_cpu_var(spinning_irq);
73 } else {
74 BUG_ON(!in_softirq());
75 spinning = __get_cpu_var(spinning_bh);
76 }
77 BUG_ON(spinning-lock);
78 }
...
So code thies to take BKL and spins there.
While spinning, interrupt arrives.
Interrupt handler tries to take another lock.
But xen_spin_wait() is not expecting attempt to take another lock when
not raw_irqs_disabled() and not in_softirq().
Here we are in interrupt handler, bit hard irq are not disabled.
Looks like check in line 70 is wrong.
Nikita
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#542250: repeatable crashes while copying 500G from NFS mount to local logical volume
This asserts that if we spin on a lock after interrupting another spin,
and interrupts are enabled, we must be in a softirq.
Looking at the bottom of the same file drivers/xen/core/spinlock.c:
void xen_spin_kick(raw_spinlock_t *lock, unsigned int token)
{
unsigned int cpu;
token = (1U TICKET_SHIFT) - 1;
for_each_online_cpu(cpu) {
if (spinning(per_cpu(spinning, cpu), cpu, lock, token))
return;
if (in_interrupt()
spinning(per_cpu(spinning_bh, cpu), cpu, lock, token))
return;
if (raw_irqs_disabled()
spinning(per_cpu(spinning_irq, cpu), cpu, lock, token))
return;
}
}
EXPORT_SYMBOL(xen_spin_kick);
... I may guess that line 74 should check for in_interrupt() instead of
in_softirq().
However it is just a guess based on analogy.
I don't currently understand the logic of that code.
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#542250: repeatable crashes while copying 500G from NFS mount to local logical volume
tags 542250 +patch
thanks
... I may guess that line 74 should check for in_interrupt() instead of
in_softirq().
I've tried that and it really fixed the problem. Server already runs the
same backup procedure for several hours. Previously it crashed within 15
minutes.
Here is the patch I've applied:
--- a/drivers/xen/core/spinlock.c 2009-08-19 16:20:17.0 +0400
+++ b/drivers/xen/core/spinlock.c 2009-08-19 17:36:55.0 +0400
@@ -71,7 +71,7 @@
BUG_ON(__get_cpu_var(spinning_bh).lock == lock);
spinning = __get_cpu_var(spinning_irq);
} else {
- BUG_ON(!in_softirq());
+ BUG_ON(!in_interrupt());
spinning = __get_cpu_var(spinning_bh);
}
BUG_ON(spinning-lock);
signature.asc
Description: This is a digitally signed message part.
Re: Bug#542250: repeatable crashes while copying 500G from NFS mount to local logical volume
On Wed, 2009-08-19 at 22:36 +0400, Nikita V. Youshchenko wrote:
tags 542250 +patch
thanks
... I may guess that line 74 should check for in_interrupt() instead
of in_softirq().
I've tried that and it really fixed the problem. Server already runs
the same backup procedure for several hours. Previously it crashed
within 15 minutes.
Here is the patch I've applied:
--- a/drivers/xen/core/spinlock.c 2009-08-19 16:20:17.0
+0400 +++ b/drivers/xen/core/spinlock.c 2009-08-19
17:36:55.0 +0400 @@ -71,7 +71,7 @@
BUG_ON(__get_cpu_var(spinning_bh).lock ==
lock); spinning = __get_cpu_var(spinning_irq); } else {
- BUG_ON(!in_softirq());
+ BUG_ON(!in_interrupt());
spinning = __get_cpu_var(spinning_bh);
}
BUG_ON(spinning-lock);
I'm glad it works for you, but it isn't a proper fix.
Could you please explain? How that code line cod hit if not in interrupt
handler?
Here is my understanding of the logic of that code. They try to track
spinlocks CPU currently spins at. CPU spinning may be interrupted only by
irq. There normal (not SA_NODELAY) interrupt handlers can't be active at
the same CPU at the same time. That leads to maximum 3 spinings:
- one from process context,
- one from normal irq handler that interrupted that process context,
- and one from SA_NODELAY irq handler that interrupted normal irq handler.
This one can't be interrupted since it runs with interrupts disabled.
If such, the code path in question corresponds to normal interrupt
handler starting to spin. Thus it should be in_interrupt().
How this is wrong?
Perhaps softirq handler could be activated at exit of the normal handler?
Maybe better check is BUG_ON(!in_interrupt() !in_softrq()). Need to
check the code ...
Nikita
signature.asc
Description: This is a digitally signed message part.
Bug#542250: repeatable crashes while copying 500G from NFS mount to local logical volume
Package: linux-image-2.6.26-2-xen-amd64 Version: 2.6.26-17lenny2 Severity: normal I'm running several servers (Dual Core AMD Opteron, 16G of ram) with Xen. Dom0 is debian lenny adm64. Today I tried to run a large backup in dom0 - copy NFS-mounted partition to a local volume group. buki:~# cd backup/ buki:~/backup# mount homes:/srv/homes src buki:~/backup# mount /dev/vg/homes-backup dst buki:~/backup# (cd src tar cpf - .) | (cd dst tar xpf -) This resulted into server crash in a few minutes. Crash is reproducible - if after reboot I try the same, same crash happens soon with similary-looking backtrace. [ 712.450538] [ cut here ] [ 712.450538] kernel BUG at drivers/xen/core/spinlock.c:74! [ 712.450538] invalid opcode: [1] SMP [ 712.450538] CPU 0 [ 712.450538] Modules linked in: nfs nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs sctp libcrc32c ipv6 lock_dlm gfs2 dlm configfs bridge 8021q dm_emc dm_round_robin dm_multipath loop psmouse pcspkr serio_raw k8temp i2c_amd8111 i2c_amd756 i2c_core button amd_rng rng_core shpchp pci_hotplug evdev reiserfs dm_mirror dm_log dm_snapshot dm_mod raid456 async_xor async_memcpy async_tx xor raid1 md_mod ide_cd_mod cdrom ide_pci_generic sd_mod amd74xx ide_core floppy lpfc scsi_transport_fc scsi_tgt tg3 e100 mii sata_sil ata_generic ohci_hcd libata scsi_mod dock thermal processor fan thermal_sys [ 712.450538] Pid: 5636, comm: tar Not tainted 2.6.26-2-xen-amd64 #1 [ 712.450538] RIP: e030:[8037fa9c] [8037fa9c] xen_spin_wait+0x90/0x139 [ 712.450538] RSP: e02b:80595e38 EFLAGS: 00010246 [ 712.450538] RAX: 88001b1adfd8 RBX: 880001bbda20 RCX: 88008162e000 [ 712.450538] RDX: ff5f7000 RSI: 8483 RDI: [ 712.450538] RBP: 0103 R08: dc38d979 R09: [ 712.450538] R10: R11: 0246 R12: [ 712.450538] R13: 88001fe7f698 R14: 88001fe7f698 R15: [ 712.450538] FS: 7f3ef40eb6e0() GS:80539000() knlGS: [ 712.450538] CS: e033 DS: ES: [ 712.450538] DR0: DR1: DR2: [ 712.450538] DR3: DR6: 0ff0 DR7: 0400 [ 712.450538] Process tar (pid: 5636, threadinfo 88001b1ac000, task 88001e270280) [ 712.450538] Stack: 88001da47480 88001fe7f698 8483 [ 712.450538] 0013 80435886 88001d8f8700 [ 712.450538] a00854f4 c201ac00 [ 712.450538] Call Trace: [ 712.450538] IRQ [80435886] ? _spin_lock+0x3a/0x42 [ 712.450538] [a00854f4] ? :sata_sil:sil_interrupt+0x2b/0x275 [ 712.450538] [8025f0e6] ? handle_IRQ_event+0x47/0x8e [ 712.450538] [802605a2] ? handle_level_irq+0xae/0x116 [ 712.450538] [8020e13e] ? do_IRQ+0x4e/0x9a [ 712.450538] [8037d4cc] ? evtchn_do_upcall+0x13c/0x1fc [ 712.450538] [8020bbde] ? do_hypervisor_callback+0x1e/0x30 [ 712.450538] EOI [802e48d4] ? dummy_inode_setattr+0x0/0x3 [ 712.450538] [8037cbf9] ? xen_poll_irq+0x67/0x74 [ 712.450538] [8037fb06] ? xen_spin_wait+0xfa/0x139 [ 712.450538] [80435cfd] ? lock_kernel+0x4f/0x63 [ 712.450538] [a01dcd12] ? :reiserfs:reiserfs_setattr+0x25/0x27d [ 712.450538] [8031156f] ? __up_read+0x13/0x8a [ 712.450538] [a01f4064] ? :reiserfs:reiserfs_getxattr+0xa9/0xbe [ 712.450538] [8029e7e3] ? notify_change+0x174/0x2f5 [ 712.450538] [80288db5] ? chown_common+0x8c/0xa1 [ 712.450538] [802a1923] ? mnt_want_write+0x31/0x86 [ 712.450538] [80288f83] ? sys_chown+0x4b/0x6f [ 712.450538] [8029a9d8] ? dput+0x35/0x13e [ 712.450538] [802ab10e] ? sys_futimesat+0x88/0x9e [ 712.450538] [8020b528] ? system_call+0x68/0x6d [ 712.450538] [8020b4c0] ? system_call+0x0/0x6d [ 712.450538] [ 712.450538] [ 712.450538] Code: 30 fa 58 80 4c 39 2c 08 75 04 0f 0b eb fe 48 c7 c0 40 fa 58 80 eb 1f 65 48 8b 04 25 10 00 00 00 66 f7 80 44 e0 ff ff 00 ff 75 04 0f 0b eb fe 48 c7 c0 30 fa 58 80 48 8d 1c 08 48 83 3b 00 74 04 [ 712.450538] RIP [8037fa9c] xen_spin_wait+0x90/0x139 [ 712.450538] RSP 80595e38 [ 712.450538] ---[ end trace 73e60cdc01c1f34c ]--- [ 712.450538] Kernel panic - not syncing: Aiee, killing interrupt handler! Server info: buki:~# cat /proc/version Linux version 2.6.26-2-xen-amd64 (Debian 2.6.26-17lenny2) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Fri Aug 14 10:19:53 UTC 2009 buki:~# cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 33 model name : Dual Core AMD Opteron(tm) Processor 280 stepping: 2 cpu MHz :
Bug#542250: Looks like same issue as #516479
This looks like the same issue as reported in #516479 - although not sure. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#513072: update-initramfs: please support running external hooks
right those hooks should be set up by linux-2.6 not initramfs-tools. kernel-package uses /etc/kernel and linux-2.6 should use that structure too. closing as this has no relation with initramfs-tools Sorry, but what linux-2.6 has to do with initramfs update trigged by e.g. mdadm (or random kernel module) package upgrade? Those do call update-initramfs, not whatever linux-2.6 hooks ... signature.asc Description: This is a digitally signed message part.
Bug#513072: update-initramfs: please support running external hooks
Package: initramfs-tools Version: 0.92o Severity: wishlist There are different things that could be required to do after initramfs image was created or updated, depending on system setup. That may include copying initramfs to xen dom0 (or external bootserver), updating non-standard bootloader (think all sorts of embedded systems), or whatever. Currently run_bootloader() routine tries to guess what it should do. But it does not (and it can not) cover all posible cases. It would be better to just add a hooks, configured in /etc/kernel-img.conf or whereever else, that will run before and after image create, update or remove. Hooks should get information about action, kernel version, and initramfs filename. Hooks may coexist with current run_bootloader(), or eventually replace it. -- Package-specific info: -- /proc/cmdline root=/dev/mapper/vg-root ro -- /proc/filesystems reiserfs iso9660 ext3 -- lsmod Module Size Used by nls_utf86272 1 ext3 125072 0 jbd51240 1 ext3 mbcache12804 1 ext3 isofs 35880 1 nls_base 12932 2 nls_utf8,isofs tun14084 1 kvm_amd29580 1 kvm 127464 1 kvm_amd ppdev 11656 0 lp 14724 0 autofs424200 1 ppp_deflate 9216 0 zlib_deflate 23960 1 ppp_deflate zlib_inflate 18944 2 isofs,ppp_deflate bsd_comp9600 0 nfsd 248360 17 auth_rpcgss47520 1 nfsd exportfs8704 1 nfsd nfs 251696 1 lockd 68560 2 nfsd,nfs nfs_acl 7552 2 nfsd,nfs sunrpc197480 17 nfsd,auth_rpcgss,nfs,lockd,nfs_acl ipt_ULOG 13736 2 xt_state6656 1 ipt_MASQUERADE 7296 1 xt_TCPMSS 8448 1 xt_tcpmss 6656 1 ipt_REJECT 7552 3 xt_tcpudp 7680 144 iptable_nat 9872 1 nf_nat 23192 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 19352 4 iptable_nat,nf_nat nf_conntrack 71440 5 xt_state,ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4 iptable_filter 7424 1 ip_tables 21520 2 iptable_nat,iptable_filter x_tables 25224 9 ipt_ULOG,xt_state,ipt_MASQUERADE,xt_TCPMSS,xt_tcpmss,ipt_REJECT,xt_tcpudp,iptable_nat,ip_tables bridge 53544 0 ppp_async 13056 1 crc_ccitt 6528 1 ppp_async ppp_generic27816 7 ppp_deflate,bsd_comp,ppp_async slhc 10112 1 ppp_generic ipv6 288328 70 loop 19468 2 psmouse42268 0 parport_pc 31016 1 parport41776 3 ppdev,lp,parport_pc pcspkr 7040 0 k8temp 9216 0 button 11680 0 i2c_nforce210752 0 i2c_core 27936 1 i2c_nforce2 evdev 14208 3 reiserfs 211072 5 dm_mirror 20608 0 dm_log 13956 1 dm_mirror dm_snapshot19400 2 dm_mod 58864 31 dm_mirror,dm_log,dm_snapshot raid456 125984 1 async_xor 8448 1 raid456 async_memcpy6912 1 raid456 async_tx 11764 3 raid456,async_xor,async_memcpy xor 9744 2 raid456,async_xor raid1 24192 1 md_mod 80164 4 raid456,raid1 ide_cd_mod 36360 0 cdrom 37928 1 ide_cd_mod sd_mod 29376 12 amd74xx13448 0 [permanent] ide_pci_generic 9220 0 [permanent] ide_core 128284 3 ide_cd_mod,amd74xx,ide_pci_generic sata_nv27528 8 8139cp 23808 0 ata_generic10116 0 libata165472 2 sata_nv,ata_generic scsi_mod 160760 2 sd_mod,libata forcedeth 54032 0 ohci1394 32564 0 dock 14112 1 libata 8139too28288 0 ieee1394 93816 1 ohci1394 ehci_hcd 36108 0 mii 9856 2 8139cp,8139too ohci_hcd 25092 0 thermal22688 0 processor 42304 1 thermal fan 9352 0 thermal_sys17728 3 thermal,processor,fan -- /etc/kernel-img.conf Do_Symlinks = no do_initrd = Yes postinst_hook = update-grub postrm_hook = update-grub do_bootloader = no -- /etc/initramfs-tools/initramfs.conf MODULES=most BUSYBOX=y KEYMAP=n BOOT=local DEVICE=eth0 NFSROOT=auto -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (620, 'testing'), (600, 'unstable'), (550, 'experimental') Architecture: i386 (x86_64) Kernel:
Bug#501383: This bug is not there with hypervisor/dom0 from lenny
Hello. At last we upgraded hypervisor and dom0 of our servers to lenny/amd64. Now our 32bit domUs correctly see more than 4G of memory. So this bug may be closed. signature.asc Description: This is a digitally signed message part.
Bug#511412: clocksource/0: Time went backwards
Package: linux-image-2.6.26-1-xen-686 Version: 2.6.26-12 Severity: normal After upgrading a domU from etch to lenny kernel, I've faced a hard domU lockup that very looks like http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1098 after severak hours f running. I've applied the workaround descried there at comment 13, and since then domU worked several days under high load without issues. Maybe make debian kernels not to use xen clocksource until the issue is fixed? -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (620, 'testing'), (600, 'unstable'), (550, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501383: domU with 2.6.26 does not see more than 4G of RAM
Hypervisor version is 3.2.0-3~bpo4+2 (from backports.org). xen-utils-3.2-1 in dom0 is 3.2.0-3~bpo4+2. This version is not supported. At least upgrade the hypervisor to 3.2.1 from Lenny. Thanks for your reply. I can't upgrade now, since system in question is running several domUs that are used in production. I will search for an upgrade window. Cristmas holidays is the most likely possibility. Nikita signature.asc Description: This is a digitally signed message part.
Bug#501383: domU with 2.6.26 does not see more than 4G of RAM
Package: linux-image-2.6.26-1-xen-686 Version: 2.6.26-5 Severity: normal I've just tried to start kernel from linux-image-2.6.26-1-xen-686 instead of etch xen kernel in a domU. Since that domU runs an application server with 50 KDE session nortmally active, it required much RAM. Current setup is 15G. That works with etch 2.6.18-6-xen kernel. However, kernel from linux-image-2.6.26-1-xen-686 recognized only 4G. Hypervisor version is 3.2.0-3~bpo4+2 (from backports.org). xen-utils-3.2-1 in dom0 is 3.2.0-3~bpo4+2. Both hypervisor and domU are 32bit. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (640, 'stable'), (620, 'testing'), (600, 'unstable'), (580, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-xen-686 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464953: ptpatch2008.c does not work
but seems to be another solution which apparently compiles to a kernel module which will catch and report attempts to (ab)use vmsplice at http://home.powertech.no/oystein/ptpatch2008/ptpatch2008.c I've just tried to compile this module. It successfully insmod'ed: Feb 11 12:54:29 zigzag kernel: ptpatch2008: init, (c) 2008 [EMAIL PROTECTED] Feb 11 12:54:29 zigzag kernel: ptpatch2008: syscalls c02ea3c0 Feb 11 12:54:29 zigzag kernel: hooked sys_vmsplice However exploit code from the top of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=464953 still works: [EMAIL PROTECTED]:~/adm/hotfix ./exploit --- Linux vmsplice Local Root Exploit By qaaz --- [+] mmap: 0x0 .. 0x1000 [+] page: 0x0 [+] page: 0x20 [+] mmap: 0x4000 .. 0x5000 [+] page: 0x4000 [+] page: 0x4020 [+] mmap: 0x1000 .. 0x2000 [+] page: 0x1000 [+] mmap: 0xb7d97000 .. 0xb7dc9000 [+] root [EMAIL PROTECTED]:~/adm/hotfix whoami root -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395288: closed by Bastian Blank [EMAIL PROTECTED] (asm/system.h not exported)
asm/system.h is not on the exported headers list. This means that it is usually not save to use it from userspace. A quick check looks like this is the case. Don't even think about using it. Could you please explain what is 'exported headers list', who maintains it, etc? Also, what is *proper* way to get cmpxchg() definition, if not #include asm/systm.h as it was before? Nikita -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unexpected diff between -686 and -k7 config
I've just found that debian/arch/i386/config.686 and
debian/arch/i386/config.k7 differ not only in cpu-related keys:
[EMAIL PROTECTED]:/ svn diff
svn://svn.debian.org/kernel/dists/trunk/linux-2.6/debian/arch/i386/config.
{686,k7}
...
@@ -41,6 +42,12 @@
# CONFIG_PCMCIA_XIRTULIP is not set
# CONFIG_ISDN_DRV_LOOP is not set
# CONFIG_HYSDN is not set
+CONFIG_ISDN_DRV_AVMB1_B1ISA=m
+CONFIG_ISDN_DRV_AVMB1_B1PCI=m
+CONFIG_ISDN_DRV_AVMB1_T1ISA=m
+CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m
+CONFIG_ISDN_DRV_AVMB1_T1PCI=m
+CONFIG_ISDN_DRV_AVMB1_C4=m
# CONFIG_COMPUTONE is not set
# CONFIG_DIGIEPCA is not set
# CONFIG_MOXA_INTELLIO is not set
@@ -49,7 +56,7 @@
# CONFIG_ISTALLION is not set
# CONFIG_I2C_ELEKTOR is not set
CONFIG_I2C_STUB=m
-# CONFIG_USB_W9968CF is not set
+CONFIG_USB_W9968CF=m
# CONFIG_USB_SERIAL_WHITEHEAT is not set
CONFIG_FS_MBCACHE=m
CONFIG_LOG_BUF_SHIFT=15
Why support for some ISDN and USB modules is only in -k7 and not in -686?
Looks like a bug.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403905: initramfs-tools: update-initramfs depends on outside environment
Package: initramfs-tools Version: 0.85c Severity: minor While browsing /usr/sbin/update-initramfs script, I've found that it does not clear 'mode' environment variable that could come from environment. Although nothing serious, better to fix it by adding something like 'unset mode' or 'mode=' before command-line parsing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403905: initramfs-tools: update-initramfs depends on outside environment
While browsing /usr/sbin/update-initramfs script, I've found that it does not clear 'mode' environment variable that could come from environment. Although nothing serious, better to fix it by adding something like 'unset mode' or 'mode=' before command-line parsing. And same with 'version' variable. pgpPk8myehzQU.pgp Description: PGP signature
Bug#390862: -bigmem version of xen kernels is really needed
What about idea not to *add* pae versions of xen kernels, but to *replace* non-pae versions with pae versions? Rationale: - not increase in archive size or linux-2.6 package build time, - this will improve compatimility with other distros (consider scenario when running FC or RHEL in domU; these distros do ship only pae xen kernels, according to http://lists.alioth.debian.org/pipermail/pkg-xen-devel/2006-December/000998.html) - pae kernels are ok for any x86 machines; slowdown caused by enabling pae on machines with less than 3.%G of memory, if any at all, is hardly measurable on machines where using xen makes sence (anyone using xen on Pentium-I with 128M of ram?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400439: RFC: initramfs-tools postinst causes system inconsistency?
Current suituation - when initramfs for one semi-randomly selected
linux-image package is updated, and others are not, and even administrator
is not notified in any way, leads to system inconsistensy.
Which I believe is against debian quality standards.
I'm forwarding this to debian-devel for futher discussion.
On Sun, 26 Nov 2006, Nikita V. Youshchenko wrote:
Looks line postinst script of initramfs-tools package just runs
'update-initramfs -u'
yes and it will stay like this.
This looks to update initramfs image for one of installed linux-image
packages, while keeping it as-is for all other packages. This could
lead to different sorts of inconsistency.
E.g. on one of systems, I have linux-image-2.6.18-2-xen-k7 and
linux-image-2.6.18-2-k7 packages installed. Normally xen version is
running, but non-xen version is kept for the case if things will go
wrong.
this is a known case where the sorting gets wrong,
but power user, who have several kernels installed can
take care of that.
So what is stated in the man page ('update-initramfs -u updates
the initramfs of the newest kernel') is not true. 2.6.18-2-xen-k7 *is*
newest, but it's initramfs image is not updated.
I think that '-u' whthout '-k' in it's current implementation does not
make sence at all, because aclually it updates initramfs of
semi-random kernel.
just if you install several kernels of the same version,
than it picks the image on alphabetical order.
I thinks that tho things should be done
- postinst should be changed either to call 'update-initramfs -u -k
all', or to ask somehow what images should be updated,
- update-initramfs should be modified either to require -k, or to use
better logic to find out what kernel image is the 'latest'.
the sorting algorythm could be refined,
but needs to take into account that the current running
is not the latest..
postetch material anyway.
pgpcthOrOkMIw.pgp
Description: PGP signature
Bug#390862: -bigmem version of xen kernels is really needed
severity 390862 wishlist thanks On Thu, Nov 30, 2006 at 03:08:15PM +0300, Nikita V. Youshchenko wrote: Currently, debian does not provide any xen kernel with pae enabled. And? I've written why it's bad. By this decision, you are breaking important usage scenario, effectively making debian xen to be a toy. It is similar to e.g. packaging mysql without support for tcp connections - system will still be usable in simple cases when everything could be local, but not for serious production. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390862: -bigmem version of xen kernels is really needed
severity 390862 important thanks Hello. Currently, debian does not provide any xen kernel with pae enabled. This forces to use xen hypervisor without pae support, which in turn makes it impossible to use more than 3.5G of system RAM. But the very idea of virtualization is to provide better usage of big resources! And in current state debian makes it impossible (unles local rebuilds, which is a pain, because of secury updates, etc). So I'm raising severity of this bug. Please fix it before etch, by providing pae versions of both -686 and -k7 kernel flavours. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400439: initramfs-tools: postinst may not update initramfs
Package: initramfs-tools
Version: 0.85b
Severity: normal
Looks line postinst script of initramfs-tools package just runs
'update-initramfs -u'
This looks to update initramfs image for one of installed linux-image
packages, while keeping it as-is for all other packages. This could lead
to different sorts of inconsistency.
E.g. on one of systems, I have linux-image-2.6.18-2-xen-k7 and
linux-image-2.6.18-2-k7 packages installed. Normally xen version is
running, but non-xen version is kept for the case if things will go
wrong.
When I upgrade initramfs-tools, it rebuilds initrd.img-2.6.18-2-k7 (that
is image for kernel that normally does not run), but does not rebuild
initrd.img-2.6.18-2-xen-k7 (image for kernel that normally runs).
This does not look like correct behaviour.
So what is stated in the man page ('update-initramfs -u updates
the initramfs of the newest kernel') is not true. 2.6.18-2-xen-k7 *is*
newest, but it's initramfs image is not updated.
I think that '-u' whthout '-k' in it's current implementation does not
make sence at all, because aclually it updates initramfs of semi-random
kernel.
I thinks that tho things should be done
- postinst should be changed either to call 'update-initramfs -u -k all',
or to ask somehow what images should be updated,
- update-initramfs should be modified either to require -k, or to use
better logic to find out what kernel image is the 'latest'.
-- Package-specific info:
-- /proc/cmdline
root=/dev/sda1 ro
-- /proc/filesystems
cramfs
reiserfs
vfat
-- lsmod
Module Size Used by
nls_koi8_r 5696 0
nls_cp866 5696 0
nls_iso8859_1 4544 0
nls_cp437 6208 0
vfat 12416 0
fat47260 1 vfat
usb_storage72768 0
xt_tcpudp 3456 2
iptable_nat 7428 1
ip_nat 17260 1 iptable_nat
ip_conntrack 49504 2 iptable_nat,ip_nat
nfnetlink 7128 2 ip_nat,ip_conntrack
ip_tables 13412 1 iptable_nat
x_tables 13636 3 xt_tcpudp,iptable_nat,ip_tables
nfs 203980 1
nfsd 199792 17
exportfs6080 1 nfsd
lockd 55240 3 nfs,nfsd
nfs_acl 3904 2 nfs,nfsd
sunrpc139772 13 nfs,nfsd,lockd,nfs_acl
ppdev 8964 0
lp 11300 0
button 6928 0
ac 5508 0
battery 9924 0
ipv6 228064 48
sk98lin 133344 0
snd_intel8x0 30620 0
snd_ac97_codec 83360 1 snd_intel8x0
snd_ac97_bus2688 1 snd_ac97_codec
snd_pcm_oss39200 0
snd_pcm68996 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss
snd_mixer_oss 15552 1 snd_pcm_oss
snd_seq_dummy 4164 0
evdev 9408 0
snd_seq_oss29120 0
snd_seq_midi_event 7488 1 snd_seq_oss
snd_seq46224 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_timer 21316 2 snd_pcm,snd_seq
snd_seq_device 8140 3 snd_seq_dummy,snd_seq_oss,snd_seq
i2c_nforce2 7232 0
psmouse35336 0
snd47524 9
snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_pcm,snd_mixer_oss,snd_seq_oss,snd_seq,snd_timer,snd_seq_device
i2c_core 20096 1 i2c_nforce2
serio_raw 6980 0
parport_pc 32612 1
parport33672 3 ppdev,lp,parport_pc
soundcore 9568 1 snd
irtty_sir 8128 0
sir_dev15940 1 irtty_sir
pcspkr 3392 0
snd_page_alloc 9928 2 snd_intel8x0,snd_pcm
rtc12788 0
irda 163580 2 irtty_sir,sir_dev
floppy 53668 0
crc_ccitt 2560 1 irda
reiserfs 214080 4
dm_mirror 19600 0
dm_snapshot15840 0
dm_mod 50776 9 dm_mirror,dm_snapshot
sd_mod 19456 4
amd74xx13340 0 [permanent]
generic 5316 0 [permanent]
ide_core 110984 3 usb_storage,amd74xx,generic
ohci_hcd 18564 0
ehci_hcd 28488 0
usbcore 113412 4 usb_storage,ohci_hcd,ehci_hcd
forcedeth 38596 0
sata_nv11332 3
libata 90644 1 sata_nv
scsi_mod 124872 3 usb_storage,sd_mod,libata
skge 35152 0
thermal13896 0
processor 29128 1 thermal
fan 5124 0
-- kernel-img.conf
Do_Symlinks = no
do_initrd = Yes
postinst_hook = update-grub
postrm_hook = update-grub
do_bootloader = no
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (620, 'testing'), (600, 'unstable'), (550, 'experimental')
Bug#349354: initramfs-tools - kernel -udev dependency loop
Package: initramfs-tools,kernel,udev Currently: - recent linux-image packages depend on 'initramfs-tools | yaird | linux-initramfs-tool', so initramfs-tools is the 'default' alternative - initramfs-tools depends on recent udev - recent udev refuses to install unless recent kernel is running This loop needs to be broken somehow. pgpsFbAczG4Wk.pgp Description: PGP signature
Bug#250984: 2.6.7 no longer has this bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I've upgraded to debian 2.6.7 kernel; it seems not to have this bug. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA78q6sTbPknTfAB4RAqk6AJ9EFOxEzy9cwsoS6SLRUUqPf7cWkACcD7Vc CU+24JJmyxsT3N8ySk+U6XU= =2lg+ -END PGP SIGNATURE-
Re: debian kernel oops on usb bluetooth dongle disconnect
On Wed, May 26, 2004 at 01:12:03AM +0400, Nikita V. Youshchenko wrote: Hello. After upgrading kernel from 2.4 to debian 2.6.6-1-686 package, I suffered 100% reproducable kernel oops whn I unplugged my usb bluetooth dongle. After some search, I found that the problem is known, and may be fixed by applying patch-2.6.6-mh2 from http://www.bluez.org/patches.html. I tried this patch and it really fixed oops, now my bluetooth device works again. I don't know what is the policy on such bugs, but maybe this patch should be applied to the next version of kernel packages? One of our goals is to get more debian kernel patches into the upstream kernel.org sources. Can you reproduce this with a stock 2.6.6 from kernel.org? If so, please report it directly at bugzilla.kernel.org. I probably can, but is that really needed? The problem is not debian-specific, it was discussed in linux-usb-mailing list in april. It probably ought to be in debian's BTS as well. I'll let someone else say if the patch is appropriate. It's already there (bug #250984)
Re: debian kernel oops on usb bluetooth dongle disconnect
On Wed, May 26, 2004 at 01:12:03AM +0400, Nikita V. Youshchenko wrote: Hello. Hello Nikita, After upgrading kernel from 2.4 to debian 2.6.6-1-686 package, I suffered 100% reproducable kernel oops whn I unplugged my usb bluetooth dongle. This kind of stuff belongs not to this list, but to a proper bug report against the package providing your kernel. Sending this info to this list will only mean that it may get lost in the mail traffic, or not reach the right person. Having a bug report is the way to go for bug reports. Ok, I will report this to BTS. I first decided to write to this list because, unlike other packages, there are tons of different kernel bugs, patches and flavours around, that work for one people and don't work for other. So I thought that a wish to apply the patch that happens to fix my particular problem will just pollute BTS.
debian kernel oops on usb bluetooth dongle disconnect
Hello. After upgrading kernel from 2.4 to debian 2.6.6-1-686 package, I suffered 100% reproducable kernel oops whn I unplugged my usb bluetooth dongle. After some search, I found that the problem is known, and may be fixed by applying patch-2.6.6-mh2 from http://www.bluez.org/patches.html. I tried this patch and it really fixed oops, now my bluetooth device works again. I don't know what is the policy on such bugs, but maybe this patch should be applied to the next version of kernel packages?
