http://blog.gmane.org/gmane.linux.kernel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.linux.kernel/724597 Hi all, (please Cc) I have read through quite some threads on lkml and bug reports regarding the hangs/freezes of the kernel when hwclock is called. I still see that behaviour on 2.6.27-rc4 with CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_HPET=y CONFIG_HPET_MMAP=y CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y CONFIG_RTC_HCTOSYS=y CONFIG_RTC_HCTOSYS_DEVICE="rtc0" CONFIG_RTC_INTF_SYSFS=y CONFIG_RTC_INTF_PROC=y CONFIG_RTC_INTF_DEV=y CONFIG_RTC_DRV_CMOS=y (all rtc and hpet related config vars). My normal dmesg boot log of a successful boot is attached. What is the recommended way to fix that, or do you need some more information? Best wishes Norbert ------------------------------------------------------------------------------- Dr. Norbert Preining <preining< at >logic.at> Vienna University of Technology Debian Developer <preining< at >debian.org> Debian TeX Group gpg DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094 ------------------------------------------ Norbert Preining 2008-08-21T16:39:20 http://comments.gmane.org/gmane.linux.kernel/724575 In latest 2.6.27(git) enabling dynamic ftrace makes resume from a suspend to ram reboot instead of resuming. Queued for 2.6.28 is a new method of recording mcount callers at compile time that does not have this issue. But the new method is still too "green" to be pulled into 27, so the old ftraced (daemon method) needs to be fixed for 27. The way dynamic ftrace works with the daemon method is this. On boot up the mcount function simply returns. When ftrace is initialized, it calls kstop_machine to modify the mcount function to call another function called "ftrace_record_ip". This new function will record in a preallocated hash (allocated by the ftrace initializer) all the callers of mcount. A check is made to see if the caller has already been put into the hash, and if so, it is not recorded again. Later on a kernel thread ftraced is created. This kernel thread wakes up once a second and checks to see if any new functions were added to the hash. If so, it then calls kstop_machine and modifies Steven Rostedt 2008-08-21T15:49:45 http://comments.gmane.org/gmane.linux.kernel/724562 Hi all, I've written a prove of concept patch that implements some ideas that Paul and I have discussed in the last few days: Attached is both a patch and a copy of the rcuclassic.c file, the patch is probably fully unreadable because it's rewriting 80% of the code. Unfortunately, the patch removes the new debug features that Ingo just added, they must be added back... The patch boots qemu with 8 cpus, although there is a random crash somewhere [memory overwritten by 0xcc] >>>> Right now, each cpu locally decides what it does, the only global thing is the bitmap that keeps track of grace periods. What this grace period means is defined by the cpu: it's possible that some cpus interpret a grace period as the sign for calling the rcu callbacks, other cpus just interpret it as the sign that it should look for the next grace period. The patch reverses that: Now there is a global state. The system is either collecting pointers for the next grace period, or it's waiting for a grace period to complete. Al Manfred Spraul 2008-08-21T15:27:37 http://comments.gmane.org/gmane.linux.kernel/724553 Is this a known problem? SYMLINK arch/um/include/kern_constants.h SYMLINK arch/um/include/sysdep make[2]: `arch/um/sys-i386/user-offsets.s' is up to date. CHK arch/um/include/user_constants.h Using /usr/projects/linux/ext4 as source for kernel GEN /usr/projects/linux/uml/Makefile CHK include/linux/version.h CHK include/linux/utsrelease.h CALL /usr/projects/linux/ext4/scripts/checksyscalls.sh CHK include/linux/compile.h CC arch/um/kernel/ptrace.o /usr/projects/linux/ext4/arch/um/kernel/ptrace.c:230: error: static declaration of ‘send_sigtrap’ follows non-static declaration include2/asm/ptrace-generic.h:51: error: previous declaration of ‘send_sigtrap’ was here make[2]: *** [arch/um/kernel/ptrace.o] Error 1 make[1]: *** [arch/um/kernel] Error 2 make: *** [sub-make] Error 2 Theodore Ts'o 2008-08-21T15:19:00 http://comments.gmane.org/gmane.linux.kernel/724544 Hi, I just got this on v2.6.27-rc4 (+ unrelated fix): ACPI: Preparing to enter system sleep state S5 ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.27-rc4-00003-ga798564 #28 ------------------------------------------------------- events/0/10 is trying to acquire lock: (cpu_add_remove_lock){--..}, at: [<c013bd9f>] cpu_maps_update_begin+0xf/0x20 but task is already holding lock: (poweroff_work){--..}, at: [<c014ae17>] run_workqueue+0x107/0x200 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (poweroff_work){--..}: [<c015f9e6>] validate_chain+0x976/0xe90 [<c0160159>] __lock_acquire+0x259/0xa00 [<c0160989>] lock_acquire+0x89/0xc0 [<c014ae75>] run_workqueue+0x165/0x200 [<c014b9bd>] worker_thread+0x7d/0xe0 [<c014e252>] kthread+0x42/0x70 [<c0105cf3>] kernel_thread_helper+0x7/0x14 [<ffffffff>] 0xffffffff -> #1 (events){--..}: [<c Vegard Nossum 2008-08-21T15:04:51 http://comments.gmane.org/gmane.linux.kernel/724502 Document the credential API's (ab)use of const pointers. Various pointers to credentials, such as those in the task_struct, are declared const. The purpose of this is to compile-time discouragement of altering credentials through those pointers. Once a set of credentials has been made public through one of these pointers, it may not be modified, except under special circumstances: (1) Its reference count may incremented and decremented. (2) The keyrings to which it points may be modified, but not replaced. The only safe way to modify anything else is to create a replacement and commit using the functions described in Documentation/credentials.txt. Signed-off-by: David Howells <dhowells< at >redhat.com> --- Documentation/credentials.txt | 19 +++++++++++++++++++ include/linux/cred.h | 12 +++++++++++- kernel/cred.c | 2 +- 3 files changed, 31 insertions(+), 2 deletions(-) diff --git a/Documentation/credentials.txt b/Documentation/credentials.txt index d1f1391..df03169 David Howells 2008-08-21T13:52:24 http://comments.gmane.org/gmane.linux.kernel/724496 reduce size by 8 bytes from 1160 to 1152 allowing it to fit in 1 fewer cachelines. Signed-off-by: Richard Kennedy <richard< at >rsk.demon.co.uk> --- patch against 2.6.27-rc4 compiled & run on AMD64. Richard diff --git a/include/linux/libata.h b/include/linux/libata.h index 06b8033..84a7a0d 100644 --- a/include/linux/libata.h +++ b/include/linux/libata.h < at >< at > -553,8 +553,8 < at >< at > struct ata_ering { struct ata_device { struct ata_link*link; unsigned intdevno;/* 0 or 1 */ -unsigned longflags;/* ATA_DFLAG_xxx */ unsigned inthorkage;/* List of broken features */ +unsigned longflags;/* ATA_DFLAG_xxx */ struct scsi_device*sdev;/* attached SCSI device */ #ifdef CONFIG_ATA_ACPI acpi_handleacpi_handle; Richard Kennedy 2008-08-21T13:47:00 http://comments.gmane.org/gmane.linux.kernel/724489 This is a resend. The last patch went to Russell King with lkml cc'd as I wasn't subscribed to the linux-arm list. However, I haven't heard it being picked up so trying linux-arm this time. === Ordinarily, memory holes in flatmem still have a valid memmap and is safe to use. However, an architecture (ARM) frees up the memmap backing memory holes on the assumption it is never used. /proc/pagetypeinfo reads the whole range of pages in a zone believing that the memmap is valid and that pfn_valid will return false if it is not. On ARM, freeing the memmap breaks the page->zone linkages even though pfn_valid() returns true and the kernel can oops shortly afterwards due to accessing a bogus struct zone *. This patch lets architectures say when FLATMEM can have holes in the memmap. Rather than an expensive check for valid memory, /proc/pagetypeinfo will confirm that the page linkages are still valid by checking page->zone is still the expected zone. The lookup of page_zone is safe as there is a limited range of m Mel Gorman 2008-08-21T13:28:05 http://comments.gmane.org/gmane.linux.kernel/724488 early_io{re,un}map() are __init and hence can't be called from __meminit functions. Signed-off-by: Jan Beulich <jbeulich< at >novell.com> --- arch/x86/mm/init_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-2.6.27-rc4/arch/x86/mm/init_64.c2008-08-21 15:02:41.000000000 +0200 +++ 2.6.27-rc4-x86_64-modpost-mm-init/arch/x86/mm/init_64.c2008-08-21 11:49:44.000000000 +0200 < at >< at > -241,7 +241,7 < at >< at > static unsigned long __initdata table_st static unsigned long __meminitdata table_end; static unsigned long __meminitdata table_top; -static __meminit void *alloc_low_page(unsigned long *phys) +static __ref void *alloc_low_page(unsigned long *phys) { unsigned long pfn = table_end++; void *adr; < at >< at > -262,7 +262,7 < at >< at > static __meminit void *alloc_low_page(un return adr; } -static __meminit void unmap_low_page(void *adr) +static __ref void unmap_low_page(void *adr) { if (after_bootmem) return; Jan Beulich 2008-08-21T13:28:42 http://comments.gmane.org/gmane.linux.kernel/724487 While I don't have a hotplug capable system at hand, I think two issues need fixing: - pud_phys (in kernel_physical_ampping_init()) would remain uninitialized in the after_bootmem case - the locking done just around phys_pmd_{init,update}() would leave out pgd updates, and it was needlessly covering code portions that do allocations (perhaps using a more friendly gfp value in alloc_low_page() would then be possible) Signed-off-by: Jan Beulich <jbeulich< at >novell.com> --- arch/x86/mm/init_64.c | 32 ++++++++++++++++++-------------- 1 file changed, 18 insertions(+), 14 deletions(-) --- linux-2.6.27-rc4/arch/x86/mm/init_64.c2008-08-21 15:02:41.000000000 +0200 +++ 2.6.27-rc4-x86_64-init-mem-map/arch/x86/mm/init_64.c2008-08-21 11:49:44.000000000 +0200 < at >< at > -336,9 +336,12 < at >< at > phys_pmd_init(pmd_t *pmd_page, unsigned } if (pmd_val(*pmd)) { -if (!pmd_large(*pmd)) +if (!pmd_large(*pmd)) { +spin_lock(&init_mm.page_table_lock); last_map_addr = phys_pte_update(pmd, address, - end Jan Beulich 2008-08-21T13:27:22 http://comments.gmane.org/gmane.linux.kernel/724484 2女高中生在廁所用馬桶刷挖菊花喲 ▽買A片可不 能隨便買!!▽ ×劣質畫面充斥,字幕不 清,劇情枯燥.... ◇ ↑本站站長所挑選上架的產品每一片都仔細從頭看到尾← ⊕正港讓男人女人都會看到受不了◇ ﹥市場惡劣競爭還是苦苦經營 -- 現在流血促銷當中 ~~ 收藏送禮皆可⊙ 網址在這：myewebbuy.idv.st (把網址複製到網址列貼上即可) 2008/8/21 - 21:20:46 a4b8tRRQ2vwRv 廖尚安 2008-08-21T13:20:24 http://comments.gmane.org/gmane.linux.kernel/724481 I'm the maintainer of the Ultra-Wideband (UWB) radio, Certified Wireless USB (WUSB) and WiMedia LLC Protocol (WLP) subsystems. These are now in a state were I consider them suitable for inclusion into the kernel. UWB is a new high speed, short range radio technology (480 Mbit/s at 1 m, 53.3 Mbit/s at 10 m). The specifications are freely available and are managed by the WiMedia Alliance. For more information see http://www.wimedia.org/. Various protocols run on top of the UWB radio: Certified Wireless USB (WUSB); WiMedia LLC Protocol (WLP), for IP (etc) networks; and (in the future) high speed Bluetooth. The code is some 35,000 lines so I won't be posting it to this list but you can view the patch set here: http://www.davidvrabel.org.uk/~david/linux/uwb/ Or you can pull the changes from the uwb branch of git://pear.davidvrabel.org.uk/git/uwb.git (Please don't clone the entire tree from here as I have very limited bandwidth.) Or you can view the patches in the linux-usb archive here: http://thread David Vrabel 2008-08-21T13:17:36 http://comments.gmane.org/gmane.linux.kernel/724470 Kedves Érdeklődő! "Azt hiszed, hogy mindennap ugyanarra a munkahelyre kell bemenned, ugyanazokat a tevékenységeket végezned, ugyanazokat a gondolatokat gondolnod, ugyanazokat az érzéseket érezned, ugyanabban a valóságban vergődnöd? Hááát, gondold át újra!" A Mi a ...(füttyöt) tudunk!? nem a határozott válaszok, hanem a borzongató tudattágító kérdések könyve. Ez egy olyan könyv, ami nem az utat mutatja meg, hanem a végtelen lehetőségeket. Kész vagy rá? Ha szeretnél erről ismertetőt irj egy akár üres e-mailt a kerekmeg< at >gmail.com címre. Ha nem szeretnél tőlünk több levelet, írj a nemkerekmeg< at >gmail.com címre. Üdvözlettel: www.ezvankiado.hu EzVanKiadó 2008-08-21T12:05:07 http://comments.gmane.org/gmane.linux.kernel/724467 Even worse - this would even try to access the MSR on non-AMD CPUs (currently probably prevented just by the fact that only AMD ones use family values of 0x10 or higher). Jan Jan Beulich 2008-08-21T12:59:33 http://comments.gmane.org/gmane.linux.kernel/724460 Fix warnings of the form: arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f1' may be used uninitialized in this function arch/powerpc/math-emu/fsubs.c:15: warning: 'R_f0' may be used uninitialized in this function Signed-off-by: Kumar Gala <galak< at >kernel.crashing.org> --- I intend these patches to go via the powerpc.git tree if no one has issues. - k include/math-emu/op-2.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/math-emu/op-2.h b/include/math-emu/op-2.h index e193fb0..4f26ecc 100644 --- a/include/math-emu/op-2.h +++ b/include/math-emu/op-2.h < at >< at > -25,7 +25,7 < at >< at > #ifndef __MATH_EMU_OP_2_H__ #define __MATH_EMU_OP_2_H__ -#define _FP_FRAC_DECL_2(X)_FP_W_TYPE X##_f0, X##_f1 +#define _FP_FRAC_DECL_2(X)_FP_W_TYPE X##_f0 = 0, X##_f1 = 0 #define _FP_FRAC_COPY_2(D,S)(D##_f0 = S##_f0, D##_f1 = S##_f1) #define _FP_FRAC_SET_2(X,I)__FP_FRAC_SET_2(X, I) #define _FP_FRAC_HIGH_2(X)(X##_f1) Kumar Gala 2008-08-21T12:50:20 http://comments.gmane.org/gmane.linux.kernel/724458 Converting __cpuinit functions called out of init_amd() (and similar others) to __init (and making them subject of xxx_initcall() handling isn't valid, as they would no longer be called for hot plugged CPUs. Further, since it's likely that in virtualized environments the MSR write would at best be ignored, I'd also recommend using the fault-safe accessors here *and* check that the bit actually got set before setting PCI_HAS_IO_ECS (one would obviously have to BUG() when hot-plugged CPUs fail to set the bit when those available at boot successfully did so). Jan Jan Beulich 2008-08-21T12:45:20 http://comments.gmane.org/gmane.linux.kernel/724425 sisusbvga: add USB ID for 0711:0918 Magic Control Technology Corp. usb 1-2: new high speed USB device using ehci_hcd and address 4 usb 1-2: configuration #1 chosen from 1 choice usb 1-2: USB2VGA dongle found at address 4 usb 1-2: Allocated 8 output buffers usb 1-2: 8MB 1 ch/1 r SDR SDRAM, bus width 32 usb 1-2: New USB device found, idVendor=0711, idProduct=0918 usb 1-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Signed-off-by: Stefan Lippers-Hollmann <s.L-H< at >gmx.de> diff --git a/drivers/usb/misc/sisusbvga/sisusb.c b/drivers/usb/misc/sisusbvga/sisusb.c index fbace41..69c34a5 100644 --- a/drivers/usb/misc/sisusbvga/sisusb.c +++ b/drivers/usb/misc/sisusbvga/sisusb.c < at >< at > -3270,6 +3270,7 < at >< at > static struct usb_device_id sisusb_table [] = { { USB_DEVICE(0x0711, 0x0900) }, { USB_DEVICE(0x0711, 0x0901) }, { USB_DEVICE(0x0711, 0x0902) }, +{ USB_DEVICE(0x0711, 0x0918) }, { USB_DEVICE(0x182d, 0x021c) }, { USB_DEVICE(0x182d, 0x0269) }, { } Stefan Lippers-Hollmann 2008-08-21T11:46:11 http://comments.gmane.org/gmane.linux.kernel/724417 From: Alex Nixon <alex.nixon< at >citrix.com> Date: Thu, 21 Aug 2008 12:30:54 +0100 Subject: [PATCH] Xen: Fix warning when hot-unplugging virtual block devices WARNING: at kernel/softirq.c:136 local_bh_enable+0x3f/0x8a() del_gendisk needs IRQs enabled, as the code path eventually reaches local_bh_enable. blk_stop_queue needs them disabled - so do so temporarily. It shouldn't matter if an interrupt comes in whilst blkif_io_lock is held, as it will block on the lock. Upon acquisition, it'll realise the device is down and exit cleanly. Signed-off-by: Alex Nixon <alex.nixon< at >citrix.com> --- drivers/block/xen-blkfront.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c index d5e7532..95cee2c 100644 --- a/drivers/block/xen-blkfront.c +++ b/drivers/block/xen-blkfront.c < at >< at > -899,16 +899,18 < at >< at > static void blkfront_closing(struct xenbus_device *dev) if (info->rq == NULL) goto out; -spin_lock_irqsave(&blkif_io_lock, flags); + Alex Nixon 2008-08-21T11:37:23 http://comments.gmane.org/gmane.linux.kernel/724382 Hi, I found a possible kobject reference counter leak problem in kobject_rename(). The following patch will fix it. Thanks, Kenji Kaneshige Fix possible kobject reference counter leak in kobject_rename(). If kobject_rename() failed because of name collision, we must call kobject_put() for specified kobject before return. Signed-off-by: Kenji Kaneshige <kaneshige.kenji< at >jp.fujitsu.com> --- lib/kobject.c | 1 + 1 file changed, 1 insertion(+) Index: linux-2.6.27-rc4/lib/kobject.c =================================================================== --- linux-2.6.27-rc4.orig/lib/kobject.c +++ linux-2.6.27-rc4/lib/kobject.c < at >< at > -411,6 +411,7 < at >< at > int kobject_rename(struct kobject *kobj, "to '%s' as '%s' is already in existence.\n", kobject_name(kobj), new_name, new_name); kobject_put(temp_kobj); +kobject_put(kobj); return -EINVAL; } } Kenji Kaneshige 2008-08-21T10:31:48 http://comments.gmane.org/gmane.linux.kernel/724381 This patch clarifies a usage of irq_chip->startup() callback: 1. The "if (startup) startup(); else enabled();" code in setup_irq() is unnecessary, as startup() falls back to enabled() via default callbacks, set by irq_chip_set_defaults(). 2. When using set_irq_chained_handler() the startup() was never called, which is not good at all... Fixed. And again - when startup() is not defined the call will fall back to enable() than to unmask() via default callbacks. Signed-off-by: Pawel Moll <pawel.moll< at >st.com> Cc: Ingo Molnar <mingo< at >elte.hu> --- kernel/irq/chip.c | 2 +- kernel/irq/manage.c | 5 +---- 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c index 7279484..a32c337 100644 --- a/kernel/irq/chip.c +++ b/kernel/irq/chip.c < at >< at > -595,7 +595,7 < at >< at > __set_irq_handler(unsigned int irq, irq_flow_handler_t handle, int is_chained, desc->status &= ~IRQ_DISABLED; desc->status |= IRQ_NOREQUEST | IRQ_NOPROBE; desc->depth = 0; -desc->chip Pawel MOLL 2008-08-21T10:14:15 http://comments.gmane.org/gmane.linux.kernel/724358 I have a desktop system that has started having problems booting up in the morning. It appears to just happen on more recent kernels. I was having unrelated CDROM problems with a driver in an old kernel and decided to test 2.6.27-rcX The CDROM problem is fine now. However I started having problems on -rc1. I found that the machine was hanging soon after booting and needed a reboot. After a reboot it would work fine for the rest of the day. When -rc3 came out I tried that and the problem still appears to be there. The normal process is now to boot to single-user, ctrl-alt-sysreq-SUB and then reboot to multi-user. This isn't ideal. If I cold boot 2.6.25.3 the problem doesn't occur. I will try different versions over the next few days. Sample log from a few days back. (2.6.27-rc1 I think) The problem does cause filesystem crashes so I'm cautious about messing around unguided. Happy to try any suggestions. David PS I've run memtest and it's fine. Aug 12 09:49:10 (none) syslogd 1.5.0#5: restart. Aug 12 David Greaves 2008-08-21T09:45:05 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.kernel