Hi, Some device drivers register CPU hotplug notifiers and use them to destroy device objects when removing the corresponding CPUs and to create these objects when adding the CPUs back. Unfortunately, this is not the right thing to do during suspend/hibernation, since in that cases the CPU hotplug notifiers are called after suspending devices and before resuming them, so the operations in question are carried out on the objects representing suspended devices which shouldn't be unregistered behin...

From: Rafael J. Wysocki <rjw@sisk.pl> It sometimes is necessary to destroy a device object during a suspend or hibernation, but the PM core is supposed to control all device objects in that cases. For this reason, it is necessary to introduce a mechanism allowing one to ask the PM core to remove a device object corresponding to a suspended device on one's behalf. Define function destroy_suspended_device() that will schedule the removal of a device object corresponding to a suspended device...

From: Rafael J. Wysocki <rjw@sisk.pl> The x86-64 MCE driver should not attempt to destroy/create a suspended device, unless it corresponds to a nonboot CPU that failed to go online during a resume. Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl> --- arch/x86/kernel/cpu/mcheck/mce_64.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Index: linux-2.6/arch/x86/kernel/cpu/mcheck/mce_64.c =================================================================== --- linux-2.6.orig...

Well, I think I still have a bug, though it is possibly a mainline problem and it's not a showstopper. After a suspend/resume cycle the reboot does not work. The system hangs with "Rebooting system" (or similar). After that you have to hard reset the system, which is not really a problem as filesystems have been unmounted before. Reboot without a suspend cycle before and halt with and without suspend cycle work without problems. I'm using toi 3.0-rc3 with kernel 2.6.24-rc6 and beside the proble...

I would also like the TuxOnIce issues related to drivers, ACPI, etc. to go to one of the kernel-related lists, but I think linux-pm may be better for that Have you finished the support for freezing filesystems before freezing tasks that we talked about some time ago? Greetings, Rafael --

Hi! On kohjinsha, wakeup code does not seem to be reached at all. I tried looking around FACS, but it seems very empty: (none):/data/l/kohji# acpidump -t FACS FACS @ 0x1f7bffc0 0000: 46 41 43 53 40 00 00 00 00 00 00 00 00 00 00 00 FACS@........... 0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ (none):/data/l/kohji# ia...

Hi, I'm trying to figure out a problem that I have with 2 different motherboards. Both have the Intel G965 chipset, an Intel DG965WH and a Gigabyte 965G-DS3. What happens is, that datacommunication, either through normal receiving bytes and via fiddling with signalling lines (for a dcf-77 radio clock) don't work. To be honest I used a vendor kernel, a Debian 2.6.22-3-amd64 image. Is this a known problem? Folkert van Heusden -- MultiTail cok yonlu kullanimli bir program, loglari okumak, ve...

From: Julia Lawall <julia@diku.dk> The file drivers/media/video/videodev.c defines both video_device_alloc and video_device_release. These are essentially just kzmalloc and kfree, respectively, but it seems better to use video_device_release, as done in the other media files, rather than kfree, in case the implementation some day changes. The problem was found using the following semantic match. (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ type T,T1,T2; identifier E; ...

From: Julia Lawall <julia@diku.dk> of_iomap calls ioremap, and so should be matched with an iounmap. At the two error returns, the result of calling of_iomap is only stored in a local variable, so these error paths need to call iounmap. Furthermore, this function ultimately stores the result of of_iomap in an array that is local to the file. These values should be iounmapped at some point. I have added a corresponding call to iounmap at the end of the function m8xx_remove. The probl...

From: Julia Lawall <julia@diku.dk> Of_get_parent and of_find_compatible_node do a of_node_get, and thus a corresponding of_code_put is needed in both the error case and the normal return case. The problem was found using the following semantic match. (http://www.emn.fr/x-info/coccinelle/) // <smpl> @@ type T,T1,T2; identifier E; statement S; expression x1,x2,x3; int ret; @@ T E; ... * E = \(of_get_parent\|of_find_compatible_node\)(...); if (E == NULL) S ... wh...

[Empty message]

Hello everybody and happy new year, I have ported linux 0.01 to gcc-4.x, and bach-3.2 (and few others programs) can run on it. so you will find binary Image of linux 0.01 floppy and qemu hdd here: http://draconux.free.fr/download/os-dev/linux0.01/Image/ nb : also work with bochs, and I have not tested it (yet) on real computer. ---------------- kernel source code : http://draconux.free.fr/download/os-dev/linux0.01/linux-0.01-rm-3.x/linux-0.01-rm-3.3.... to see change from original lin...

Heip! I recently moved to 64-bit kernel, but mixed sounds (ie. mpegs played with a media player) don't work with optical S/PDIF connection. AC3/DTS passthrough still works, and I can hear the mixed sounds on analog connector. And yes, I have unmuted the IEC958 mixer setting. Tested kernels: ALSA 1.0.14: 2.6.23.1 32bit: works 2.6.23.1 64bit: broken 2.6.23.12 64bit: broken 2.6.23.12 64bit kernel, 32bit userspace: broken ALSA 1.0.15: 2.6.24-rc6 64bit: broken (and half of the mixer sett...

Hi Berthold. If you can reproduce it, would you please send the information to the USB maintainers? I don't modify USB drivers, so it will be an issue in vanilla. Even if you can't reproduce it immediately, they may well like to see this report. Regards, Nigel --

there seems some weird interference between l440gx and parport_pc modules i can reproduceable crash my box by either: modprobe parport_pc;modprobe l440gx;rmmod parport_pc or modprobe l440gx; modprobe parport_pc;rmmod parport_pc this happens on 2.6.24rc6 and also older kernel (2.6.22) because i haven`t appropriate hardware. don`t know if this is a bug in parport_pc or l440gx but maybe its worth reporting. regards roland _____________________________________________________________...

Hi, Please attach the information below to the Bugzilla entry at: http://bugzilla.kernel.org/show_bug.cgi?id=9673 Thanks, -- "Premature optimization is the root of all evil." - Donald Knuth --

Delete filenames from comments. While at it: * Delete versions from comments in ide-dma.c, ide-iops.c, ide-probe.c, ide-proc.c, ide-taskfile.c, and setup-pci.c (all these files are a part of IDE core module), and also ide-timing.h. Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> --- drivers/ide/arm/bast-ide.c | 3 +-- drivers/ide/arm/icside.c | 2 -- drivers/ide/arm/rapide.c | 2 -- drivers/ide/cris/ide-cris.c | 3 +-- drivers/ide/h8...

* Replace driver versions in comments by DRV_VERSION define. * Add MODULE_VERSION(DRV_VERSION) to drivers defining DRV_VERSION. While at it: * Replace local version defines by DRV_VERSION. * Bump driver version in ide-floppy to match generic format ("0.99.newide" -> "1.00"). * Change printk() level in ide-floppy banner message to KERN_INFO. * Bump driver version in IDE core module to match generic format ("Id: ide.c 7.00a2 20020906" -> "7.00"). * Remove unused REVISION def...

Good point. On the second thought: maybe we will be better off with limiting MODULE_VERSION() to the device drivers and the IDE core module for now, and just removing all these private version numbers from host drivers (with one or two exceptions they are not printed or exported currently, moreover exceptions are the cases like stale version numbers from 199x)? Bart --

Linus, Could you please pull from: git://git.o-hand.com/linux-rpurdie-leds for-linus for a couple of LED oops fixes for 2.6.24. Thanks, Richard drivers/leds/led-class.c | 8 ++++---- drivers/leds/led-core.c | 4 ++-- drivers/leds/led-triggers.c | 8 ++++---- drivers/leds/leds-locomo.c | 2 +- drivers/leds/leds.h | 3 ++- 5 files changed, 13 insertions(+), 12 deletions(-) Richard Purdie (2): leds: Fix leds_list_lock locking issues leds: Fix...

Nick: http://lkml.org/lkml/2006/4/20/196 It doesn't seem like those made it into mainline - was there a reason why? (I looked around and didn't see anything). Thanks -Robin --

Hi, this doesn't look like the same problem, although I'm in no way an expert. It is -rc6 (I had to change -rc6 to -rcx in Makefile to support the fallacy of not having to compile everything from scratch, but had to make mrproper to get This one? 00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4) 00: b9 10 29 52 05 00 90 02 c4 b0 01 01 00 20 00 00 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20: 81 80 00 00 00 00 00 00 00 00 00 00 3c 10 24 00 30: 00 00 00 00 60 00 00 00 00...

There's nothing easier than always writing 0 to the 0x80 to check if it hangs in such case...? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

That does imply some muppet 'extended' the debug interface for power management on your laptop. Also pretty much proves that for such systems we do have to move from port 0x80 to another delay approach. Ingo - the fact that so many ISA bus devices need _p to mean "ISA bus clocks" says to me we should keep the _p port 0x80 using variant for old systems/device combinations (eg ISA ethernet cards) which won't show up in any problem system (we know this from 15 odd years of testing), but stop using i...

[Empty message]