Re: 2.6.23-rc1: no setup signature found...
On Sun, Jul 29, 2007 at 06:50:32AM -0700, H. Peter Anvin wrote: Borislav Petkov wrote: Right, this was too easy to be true. I now did: qemu -hda /dev/hda -snapshot and booted from the hd using the installed grub and the same kernel and it _didn't_ boot showing again no setup signature found... Okay, so it's an algorithmic problem. This is quite important to know. Is /boot a separate partition on your disk by any chance? Either way, this means we can use qemu to debug this, which will make it a lot easier. This is what I'd like you to do next: - run qemu in one window with the -S -s options. - in another window, do: gdb target remote localhost:1234 set architecture i8086 disp/i ($cs 4)+$eip br *0x10200 br *0x20200 br *0x30200 br *0x40200 br *0x50200 br *0x60200 br *0x70200 br *0x80200 br *0x90200 c # ... hopefully you're now stopped at a jump instruction p/x $ds # Hopefully this is showing, say, 0x9000 if you're stopped # at 0x90200 # Where X is the first digit of the address stopped at: dump memory setup.dump 0xX 0xX8000 Please send me setup.dump plus your vmlinuz file. Thanks, -hpa Here's a complete log of what i did: qemu -hda /dev/hda -snapshot -S -s and then in another window: --- []# gdb GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu. (gdb) target remote localhost:1234 Remote debugging using localhost:1234 0xfff0 in ?? () (gdb) set architecture i8086 The target architecture is assumed to be i8086 (gdb) disp/i ($cs 4)+$eip 1: x/i ($cs 4) + $eip 0x0: ljmp $0xf000,$0xe05b (gdb) br *0x10200 Breakpoint 1 at 0x10200 (gdb) br *0x20200 Breakpoint 2 at 0x20200 (gdb) br *0x30200 Breakpoint 3 at 0x30200 (gdb) br *0x40200 Breakpoint 4 at 0x40200 (gdb) br *0x50200 Breakpoint 5 at 0x50200 (gdb) br *0x60200 Breakpoint 6 at 0x60200 (gdb) br *0x70200 Breakpoint 7 at 0x70200 (gdb) br *0x80200 Breakpoint 8 at 0x80200 (gdb) br *0x90200 Breakpoint 9 at 0x90200 (gdb) c Continuing. Breakpoint 4, 0x00040200 in ?? () 1: x/i ($cs 4) + $eip 0x40300: lea(%si),%dx (gdb) p/x $ds $1 = 0x18 (gdb) dump memory setup.dump 0x4 0x48000 (gdb) q The program is running. Exit anyway? (y or n) y ---EOF--- Please find the setup.dump file attached. And by vmlinuz you meant bzImage, right? Anyways, due to the fact that its size will not fit in vger's size limits i'm sending it to you in a private mail. -- Regards/Gruß, Boris. setup.dump Description: Binary data
Re: [ck] Re: Linus 2.6.23-rc1
Am Sonntag 29 Juli 2007 schrieb Satyam Sharma: Hi Martin, Hi Satyam, I believe that Ingo did not meant any bad at all. I think its just the way he works, he likes to have code before saying anything. But still I believe before I'd go about replacing someone else code completely I would inform that developer beforehand, even if it then turns out not to be feasible at all. No need to anounce it to the world already, but I would have informed that developer. IMHO, what you're suggesting is: (1) not the way development normally happens in Linux, and, (2) not the way it /should/ happen, either. If there's something (subsystem, any code big or small) I think I can do better or have an idea for, I /should/ be able to just hack on it a bit and then send it out so everybody can comment on it. Why should I be forced to dance/discuss around with some other people, when the faster and more effective way would be just present the code/patch that I have in my mind as an RFC? Hmmm, that email would have taken how long? 5 minutes maybe? I just feel that I would have written it if I happen to know that another developer spent lots of time and effort into a subsystem I plan to rewrite. Its just human logic to me. Especially when I happen to know that the other developer may be new to the kernel development process as I know it from a internal view point. The current kernel development process tries to pretend that there is no human involvement. Which is plain inaccurate: It is *all* human involvement, without a human not a single bit of kernel code would change. I always believed that kernel developers are human beings and no robots. And thus the kernel development process IMHO should be designed with human developers in mind instead of robots which take no offence out of anything. Otherwise things like what happened here will happen again and again and again and talent is lost. It is damn good to take technical merits into full account! But ignoring human aspects of development actually will hinder this. Cause then in the end its not about technical merits anymore that do the decision, but that human aspects that have been ignored and are floating around unconsiously. Actually I do believe that this discussion already took more resources than actually writing a few more mails and doing a bit more communication here and there... IMHO the fact that this discussion exists already shows that something in the process of submitting kernel patches and supporting involvement in kernel development can be improved upon. See, Martin, in the end it's not about developer A vs developer B. It's about making the kernel the best out there -- that's what the users want, anyway. Yes, I fully understand (and have said so earlier myself) that there's a very important social aspect to development on such projects, but it's best if developer B understands that this is the way things do (and should) happen and adapt to it. [ It's not like I've been around for long, however, but the above is still my opinion, fwiw. ] I am not saying that developer B (Con) does not have his share in how it all happened. As written before I got the impression that Con reacted hurt where from my point of view no offence was meant - and I told him that. But from what I know it would have been possible to actually deal with that quite a bit better than has happened. And it would not have taken much effort. Well actually I think it would have been quite easy to take the talent that has offered itself. Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, Jul 29, 2007 at 08:23:31PM +0200, Martin Steigerwald wrote: Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: On Sun, Jul 29, 2007 at 12:56:28PM +0200, Martin Steigerwald wrote: Am Sonntag 29 Juli 2007 schrieb Sam Ravnborg: I actually also think that the communication between Ingo and Con could have been better especially when Ingo decided to write CFS while Con was still working hard on SD. You realize that Ingo posted his code for anyone to look at/comment at about 48 hours after he started to work on CFS? Yes. So whats wrong then? Ingo decides to do a better scheduler - to some extent inspired by Con's work. And after 48 hours he publish first version that _anyone_ can see and comment on. Whats wrong with that? Did you expect some lengthy discussion before the coding phase started or what? Just trying to understand what you are arguing about. If I tried to rewrite a kernel subsystem - should I ever happen to dig that deep into kernel matters - while I actually know that someone already spent countless hours on exactly rewriting the exact same subsystem, I think I would have told that other developer about it as soon as I started coding on it. The usual way to communicate such things on lkml are with patches as also happened in this case. It's not like Ingo had secretly developing a scheduler in parallel for weeks or months but. But I assume all the fuzz is about something else - it cannot be about a these 48 hours - I hope.. Enough on this - back to work. Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [bug] pcwd_init_module(): WARNING: at lib/kref.c:33 kref_get()
Hi All, On Sun, 22 Jul 2007 20:23:20 +0530, Satyam Sharma [EMAIL PROTECTED] wrote: On 7/22/07, Ingo Molnar [EMAIL PROTECTED] wrote: enabling CONFIG_PCWATCHDOG=y crashes bzImage bootup, see below. Tested on latest -git. ... Might be some ordering problem (bus not registered yet). Is the isa bus already up? Changing link order or initcall levels might help. See below fix. Please test it. Thanks in advance, Wim. [WATCHDOG] Fix pcwd_init_module crash Fix for the problem detected by Ingo Molnar: enabling CONFIG_PCWATCHDOG=y crashes bzImage bootup. The reason for this can be found in drivers/makefile We first do: obj-y += char/ and later we do: obj-y += base/ block/ misc/ mfd/ net/ media/ So if we put a platform or isa or usb bus driver in char/watchdog (which is called from the Makefile in drivers/char/Makefile) then we didn't have the different device drivers initialized yet (they are in drivers/base and drivers/usb and ...) This fix makes sure that we compile the watchdog drivers after drivers/base, drivers/misc, drivers/pci and drivers/usb. We also do the compile after hwmon because in the future the watchdog temperature support will use the hwmon system. Signed-off-by: Wim Van Sebroeck [EMAIL PROTECTED] diff --git a/drivers/Makefile b/drivers/Makefile index a9e4c5f..f0878b2 100644 --- a/drivers/Makefile +++ b/drivers/Makefile @@ -66,6 +66,7 @@ obj-y += i2c/ obj-$(CONFIG_W1) += w1/ obj-$(CONFIG_POWER_SUPPLY) += power/ obj-$(CONFIG_HWMON)+= hwmon/ +obj-$(CONFIG_WATCHDOG) += char/watchdog/ obj-$(CONFIG_PHONE)+= telephony/ obj-$(CONFIG_MD) += md/ obj-$(CONFIG_BT) += bluetooth/ diff --git a/drivers/char/Makefile b/drivers/char/Makefile index 8fecaf4..2bc3a55 100644 --- a/drivers/char/Makefile +++ b/drivers/char/Makefile @@ -97,7 +97,6 @@ obj-$(CONFIG_GPIO_VR41XX) += vr41xx_giu.o obj-$(CONFIG_GPIO_TB0219) += tb0219.o obj-$(CONFIG_TELCLOCK) += tlclk.o -obj-$(CONFIG_WATCHDOG) += watchdog/ obj-$(CONFIG_MWAVE)+= mwave/ obj-$(CONFIG_AGP) += agp/ obj-$(CONFIG_DRM) += drm/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] remove mm/filemap.c:file_send_actor()
On Sun, Jul 29 2007, Adrian Bunk wrote: This patch removes the no longer used file_send_actor(). Good catch, applied! -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] make struct sdio_dev_attrs[] static
On Sun, 29 Jul 2007 16:58:09 +0200 Adrian Bunk [EMAIL PROTECTED] wrote: On Wed, Jul 25, 2007 at 04:03:04AM -0700, Andrew Morton wrote: ... Changes since 2.6.22-rc6-mm1: ... git-mmc.patch ... git trees ... sdio_dev_attrs[] can become static. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Thanks, applied. Rgds Pierre signature.asc Description: PGP signature
Re: [2.6 patch] kernel/audit.c: change the exports to EXPORT_SYMBOL_GPL
On Sun, Jul 29, 2007 at 11:40:33AM -0700, Arjan van de Ven wrote: On Sun, 2007-07-29 at 17:02 +0200, Adrian Bunk wrote: This patch changes some completely unused audit exports from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL. They are still completely unused, but hopefully some of the theoretical code that might use it will appear in the kernel in the near future... AppArmor uses the audit_log_* functions. (But it is GPL, so no worries). Ciao, Marcus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
Ray wrote: a log structured scheme, where the writeout happens to sequential spaces on the drive instead of scattered about. If the problem is reading stuff back in from swap quickly when needed, then this likely helps, by reducing the seeks needed. If the problem is reading stuff back in from swap at the *same time* that the application is reading stuff from some user file system, and if that user file system is on the same drive as the swap partition (typical on laptops), then interleaving the user file system accesses with the swap partition accesses might overwhelm all other performance problems, due to the frequent long seeks between the two. In that case, swap layout and swap i/o block size are secondary. However, pre-fetching, so that swap read back is not interleaved with application file accesses, could help dramatically. === Perhaps we could have a 'wake-up' command, analogous to the various sleep and hibernate commands. The 'wake-up' command could do whatever of the following it knew to do, in order to optimize for an anticipated change in usage patterns: 1) pre-fetch swap 2) clean (write out) dirty pages 3) maximize free memory 4) layout swap nicely 5) pre-fetch a favorite set of apps Stumble out of bed in the morning, press 'wake-up', start boiling the water for your coffee, and in another ten minutes, one is ready to rock and roll. In case Andrew is so bored he read this far -- yes this wake-up sounds like user space code, with minimal kernel changes to support any particular lower level operation that we can't do already. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.925.600.0401 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG] undefined reference to `kobject_actions'
Many ARM platforms fail to build with the following: drivers/built-in.o: In function `store_uevent': hid-input.c:(.text+0x19c4c): undefined reference to `kobject_actions' It appears that if hotplug is disabled, kobject_actions is ifdef'd away but hid-input still references it. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] undefined reference to `kobject_actions'
On Sun, Jul 29, 2007 at 08:34:01PM +0100, Russell King wrote: Many ARM platforms fail to build with the following: drivers/built-in.o: In function `store_uevent': hid-input.c:(.text+0x19c4c): undefined reference to `kobject_actions' It appears that if hotplug is disabled, kobject_actions is ifdef'd away but hid-input still references it. What I also meant to say is that it looks like it's caused by commit 60a96a59569bab85571d0089682109bd3324e896. Presumably if hotplug is disabled, we want store_uevent to be removed as well? (Also added Kay to the recipients.) -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] undefined reference to `kobject_actions'
Russell King wrote: Many ARM platforms fail to build with the following: drivers/built-in.o: In function `store_uevent': hid-input.c:(.text+0x19c4c): undefined reference to `kobject_actions' It appears that if hotplug is disabled, kobject_actions is ifdef'd away but hid-input still references it. Is already fixed in -mm , try patch from : http://lkml.org/lkml/2007/7/29/206 Regards, Gabriel - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] kernel/audit.c: change the exports to EXPORT_SYMBOL_GPL
On Sun, 2007-07-29 at 21:33 +0200, Marcus Meissner wrote: On Sun, Jul 29, 2007 at 11:40:33AM -0700, Arjan van de Ven wrote: On Sun, 2007-07-29 at 17:02 +0200, Adrian Bunk wrote: This patch changes some completely unused audit exports from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL. They are still completely unused, but hopefully some of the theoretical code that might use it will appear in the kernel in the near future... AppArmor uses the audit_log_* functions. but it's not in the tree. So marking them _UNUSED_ in the tree is still appropriate. They're there for the people who want them, they're not there for those who want to save the space -- if you want to mail me at work (you don't), use arjan (at) linux.intel.com Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] undefined reference to `kobject_actions'
On Sun, 2007-07-29 at 20:37 +0100, Russell King wrote: On Sun, Jul 29, 2007 at 08:34:01PM +0100, Russell King wrote: Many ARM platforms fail to build with the following: drivers/built-in.o: In function `store_uevent': hid-input.c:(.text+0x19c4c): undefined reference to `kobject_actions' It appears that if hotplug is disabled, kobject_actions is ifdef'd away but hid-input still references it. What I also meant to say is that it looks like it's caused by commit 60a96a59569bab85571d0089682109bd3324e896. Presumably if hotplug is disabled, we want store_uevent to be removed as well? Does this patch fix it? http://lkml.org/lkml/2007/7/20/143 Thanks, Kay - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ACPI on Averatec 2370
Your work around seems to do the trick. I took out SMP support, added ACPI and now it boots normally. On 7/29/07, Frank Hale [EMAIL PROTECTED] wrote: Frank, can you try a non-SMP build with ACPI and see if you still have the problem? I certainly will, I never tried it without it so now I am curious. Thanks a bunch! - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On 7/29/07, Paul Jackson [EMAIL PROTECTED] wrote: If the problem is reading stuff back in from swap at the *same time* that the application is reading stuff from some user file system, and if that user file system is on the same drive as the swap partition (typical on laptops), then interleaving the user file system accesses with the swap partition accesses might overwhelm all other performance problems, due to the frequent long seeks between the two. Ah, so in a normal scenario where a working-set is getting faulted back in, we have the swap storage as well as the file-backed stuff that needs to be read as well. So even if swap is organized perfectly, we're still seeking. Damn. On the other hand, that explains another thing that swap prefetch could be helping with -- if it preemptively faults the swap back in, then the file-backed stuff can be faulted back more quickly, just by the virtue of not needing to seek back and forth to swap for its stuff. Hadn't thought of that. That also implies that people running with swap files rather than swap partitions will see less of an issue. I should dig out my old compact flash card and try putting swap on that for a week. In that case, swap layout and swap i/o block size are secondary. However, pre-fetching, so that swap read back is not interleaved with application file accesses, could help dramatically. Nod Perhaps we could have a 'wake-up' command, analogous to the various sleep and hibernate commands. [...] In case Andrew is so bored he read this far -- yes this wake-up sounds like user space code, with minimal kernel changes to support any particular lower level operation that we can't do already. He'd suggested using, uhm, ptrace_peek or somesuch for just such a purpose. The second half of the issue is to know when and what to target. Ray - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] Char: cyclades, remove bottom half processing
cyclades, remove bottom half processing
The work done in bottom half doesn't cost much cpu time (e.g. tty_hangup
itself schedules its own bottom half), it's possible to do the work in isr
directly and save hence some .text.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 3fc1c2f3f8414d72e12e8d6aed1c36ddb1f19567
tree 071c1c5998332b01ac34ad262b55c2334d6e2392
parent f0d76dfb19957f269687e89a62ba75ecd7339e03
author Jiri Slaby [EMAIL PROTECTED] Sat, 28 Jul 2007 10:32:14 +0200
committer Jiri Slaby [EMAIL PROTECTED] Sat, 28 Jul 2007 10:32:14 +0200
drivers/char/cyclades.c | 111 --
include/linux/cyclades.h | 15 --
2 files changed, 20 insertions(+), 106 deletions(-)
diff --git a/drivers/char/cyclades.c b/drivers/char/cyclades.c
index d6d37c3..6aa91f2 100644
--- a/drivers/char/cyclades.c
+++ b/drivers/char/cyclades.c
@@ -897,71 +897,6 @@ static inline int serial_paranoia_check(struct
cyclades_port *info,
return 0;
} /* serial_paranoia_check */
-/*
- * This routine is used by the interrupt handler to schedule
- * processing in the software interrupt portion of the driver
- * (also known as the bottom half). This can be called any
- * number of times for any channel without harm.
- */
-static inline void cy_sched_event(struct cyclades_port *info, int event)
-{
- info-event |= 1 event; /* remember what kind of event and who */
- schedule_work(info-tqueue);
-} /* cy_sched_event */
-
-/*
- * This routine is used to handle the bottom half processing for the
- * serial driver, known also the software interrupt processing.
- * This processing is done at the kernel interrupt level, after the
- * cy#/_interrupt() has returned, BUT WITH INTERRUPTS TURNED ON. This
- * is where time-consuming activities which can not be done in the
- * interrupt driver proper are done; the interrupt driver schedules
- * them using cy_sched_event(), and they get done here.
- *
- * This is done through one level of indirection--the task queue.
- * When a hardware interrupt service routine wants service by the
- * driver's bottom half, it enqueues the appropriate tq_struct (one
- * per port) to the keventd work queue and sets a request flag
- * that the work queue be processed.
- *
- * Although this may seem unwieldy, it gives the system a way to
- * pass an argument (in this case the pointer to the cyclades_port
- * structure) to the bottom half of the driver. Previous kernels
- * had to poll every port to see if that port needed servicing.
- */
-static void
-do_softint(struct work_struct *work)
-{
- struct cyclades_port *info =
- container_of(work, struct cyclades_port, tqueue);
- struct tty_struct*tty;
-
- tty = info-tty;
- if (!tty)
- return;
-
- if (test_and_clear_bit(Cy_EVENT_HANGUP, info-event)) {
- tty_hangup(info-tty);
- wake_up_interruptible(info-open_wait);
- info-flags = ~ASYNC_NORMAL_ACTIVE;
- }
- if (test_and_clear_bit(Cy_EVENT_OPEN_WAKEUP, info-event))
- wake_up_interruptible(info-open_wait);
-#ifdef CONFIG_CYZ_INTR
- if (test_and_clear_bit(Cy_EVENT_Z_RX_FULL, info-event)
- !timer_pending(cyz_rx_full_timer[info-line]))
- mod_timer(cyz_rx_full_timer[info-line], jiffies + 1);
-#endif
- if (test_and_clear_bit(Cy_EVENT_DELTA_WAKEUP, info-event))
- wake_up_interruptible(info-delta_msr_wait);
- tty_wakeup(tty);
-#ifdef Z_WAKE
- if (test_and_clear_bit(Cy_EVENT_SHUTDOWN_WAKEUP, info-event))
- complete(info-shutdown_wait);
-#endif
-} /* do_softint */
-
-
/***/
/* Start of block of Cyclom-Y specific code /
@@ -1243,7 +1178,7 @@ static void cyy_intr_chip(struct cyclades_card *cinfo,
int chip,
cy_writeb(base_addr + (CySRER index),
readb(base_addr + (CySRER index))
~CyTxRdy);
- goto txdone;
+ goto txend;
}
/* load the on-chip space for outbound data */
@@ -1334,9 +1269,7 @@ static void cyy_intr_chip(struct cyclades_card *cinfo,
int chip,
}
txdone:
- if (info-xmit_cnt WAKEUP_CHARS) {
- cy_sched_event(info, Cy_EVENT_WRITE_WAKEUP);
- }
+ tty_wakeup(info-tty);
txend:
/* end of service */
cy_writeb(base_addr + (CyTIR index), (save_xir 0x3f));
@@ -1369,17 +1302,16 @@ txend:
if (mdm_change CyRI)
info-icount.rng++;
- cy_sched_event(info, Cy_EVENT_DELTA_WAKEUP);
+
[PATCH 2/4] Char: cyclades, make the isr code readable
cyclades, make the isr code readable
due to large indent the code was wrapped and unreadable. Create 3 function
instead of one and reorder the code, so it is readable now.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 681fc4c7f1aa79a001d5ebe5f09bc7b63fa9dd16
tree ebc2e2807988e00b7a2aa0cff3bccfdbd51e201a
parent 3fc1c2f3f8414d72e12e8d6aed1c36ddb1f19567
author Jiri Slaby [EMAIL PROTECTED] Sat, 28 Jul 2007 11:08:53 +0200
committer Jiri Slaby [EMAIL PROTECTED] Sat, 28 Jul 2007 11:08:53 +0200
drivers/char/cyclades.c | 617 ++-
1 files changed, 292 insertions(+), 325 deletions(-)
diff --git a/drivers/char/cyclades.c b/drivers/char/cyclades.c
index 6aa91f2..698e90c 100644
--- a/drivers/char/cyclades.c
+++ b/drivers/char/cyclades.c
@@ -980,378 +980,342 @@ static unsigned detect_isa_irq(void __iomem * address)
}
#endif /* CONFIG_ISA */
-static void cyy_intr_chip(struct cyclades_card *cinfo, int chip,
- void __iomem * base_addr, int status, int index)
+static void cyy_chip_rx(struct cyclades_card *cinfo, int chip,
+ void __iomem *base_addr)
{
struct cyclades_port *info;
struct tty_struct *tty;
int char_count;
- int j, len, mdm_change, mdm_status, outch;
+ int j, len, index = cinfo-bus_index;
int save_xir, channel, save_car;
char data;
- if (status CySRReceive) { /* reception interrupt */
#ifdef CY_DEBUG_INTERRUPTS
- printk(KERN_DEBUG cyy_interrupt: rcvd intr, chip %d\n, chip);
+ printk(KERN_DEBUG cyy_interrupt: rcvd intr, chip %d\n, chip);
#endif
- /* determine the channel change to that context */
- spin_lock(cinfo-card_lock);
- save_xir = (u_char) readb(base_addr + (CyRIR index));
- channel = (u_short) (save_xir CyIRChannel);
- info = cinfo-ports[channel + chip * 4];
- save_car = readb(base_addr + (CyCAR index));
- cy_writeb(base_addr + (CyCAR index), save_xir);
-
- /* if there is nowhere to put the data, discard it */
- if (info-tty == NULL) {
- j = (readb(base_addr + (CyRIVR index))
- CyIVRMask);
- if (j == CyIVRRxEx) { /* exception */
- data = readb(base_addr + (CyRDSR index));
- } else {/* normal character reception */
- char_count = readb(base_addr +
- (CyRDCR index));
- while (char_count--) {
- data = readb(base_addr +
- (CyRDSR index));
- }
- }
- } else {/* there is an open port for this data */
- tty = info-tty;
- j = (readb(base_addr + (CyRIVR index))
- CyIVRMask);
- if (j == CyIVRRxEx) { /* exception */
+ /* determine the channel change to that context */
+ spin_lock(cinfo-card_lock);
+ save_xir = (u_char) readb(base_addr + (CyRIR index));
+ channel = (u_short) (save_xir CyIRChannel);
+ info = cinfo-ports[channel + chip * 4];
+ save_car = readb(base_addr + (CyCAR index));
+ cy_writeb(base_addr + (CyCAR index), save_xir);
+
+ /* if there is nowhere to put the data, discard it */
+ if (info-tty == NULL) {
+ j = (readb(base_addr + (CyRIVR index)) CyIVRMask);
+ if (j == CyIVRRxEx) { /* exception */
+ data = readb(base_addr + (CyRDSR index));
+ } else {/* normal character reception */
+ char_count = readb(base_addr + (CyRDCR index));
+ while (char_count--)
data = readb(base_addr + (CyRDSR index));
-
- /* For statistics only */
- if (data CyBREAK)
- info-icount.brk++;
- else if (data CyFRAME)
- info-icount.frame++;
- else if (data CyPARITY)
- info-icount.parity++;
- else if (data CyOVERRUN)
- info-icount.overrun++;
-
- if (data info-ignore_status_mask) {
+ }
+ goto end;
+ }
+ /* there is an open port for this data */
+ tty = info-tty;
+ j = readb(base_addr + (CyRIVR index)) CyIVRMask;
+ if (j == CyIVRRxEx) { /* exception */
+ data = readb(base_addr +
[PATCH 3/4] Char: cyclades, move spin_lock to one place
cyclades, move spin_lock to one place
lock whole processing in isr, avoid error-prone locking/unlocking in rx/tx
esp. on fail paths (there was a bug in the past yet).
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit 93fc0dd73bb407b773506ec8d756317de9098d53
tree 6a1c1cfde015d095c6c94f21ea9b04e038787207
parent 681fc4c7f1aa79a001d5ebe5f09bc7b63fa9dd16
author Jiri Slaby [EMAIL PROTECTED] Sat, 28 Jul 2007 11:28:53 +0200
committer Jiri Slaby [EMAIL PROTECTED] Sat, 28 Jul 2007 11:28:53 +0200
drivers/char/cyclades.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/char/cyclades.c b/drivers/char/cyclades.c
index 698e90c..a83524a 100644
--- a/drivers/char/cyclades.c
+++ b/drivers/char/cyclades.c
@@ -994,7 +994,6 @@ static void cyy_chip_rx(struct cyclades_card *cinfo, int
chip,
printk(KERN_DEBUG cyy_interrupt: rcvd intr, chip %d\n, chip);
#endif
/* determine the channel change to that context */
- spin_lock(cinfo-card_lock);
save_xir = (u_char) readb(base_addr + (CyRIR index));
channel = (u_short) (save_xir CyIRChannel);
info = cinfo-ports[channel + chip * 4];
@@ -1031,7 +1030,6 @@ static void cyy_chip_rx(struct cyclades_card *cinfo, int
chip,
if (data info-ignore_status_mask) {
info-icount.rx++;
- spin_unlock(cinfo-card_lock);
return;
}
if (tty_buffer_request_room(tty, 1)) {
@@ -1116,7 +1114,6 @@ end:
/* end of service */
cy_writeb(base_addr + (CyRIR index), save_xir 0x3f);
cy_writeb(base_addr + (CyCAR index), save_car);
- spin_unlock(cinfo-card_lock);
}
static void cyy_chip_tx(struct cyclades_card *cinfo, int chip,
@@ -1135,7 +1132,6 @@ static void cyy_chip_tx(struct cyclades_card *cinfo, int
chip,
#endif
/* determine the channel change to that context */
- spin_lock(cinfo-card_lock);
save_xir = (u_char) readb(base_addr + (CyTIR index));
channel = (u_short) (save_xir CyIRChannel);
save_car = readb(base_addr + (CyCAR index));
@@ -1240,7 +1236,6 @@ end:
/* end of service */
cy_writeb(base_addr + (CyTIR index), save_xir 0x3f);
cy_writeb(base_addr + (CyCAR index), save_car);
- spin_unlock(cinfo-card_lock);
}
static void cyy_chip_modem(struct cyclades_card *cinfo, int chip,
@@ -1251,7 +1246,6 @@ static void cyy_chip_modem(struct cyclades_card *cinfo,
int chip,
int save_xir, channel, save_car, index = cinfo-bus_index;
/* determine the channel change to that context */
- spin_lock(cinfo-card_lock);
save_xir = (u_char) readb(base_addr + (CyMIR index));
channel = (u_short) (save_xir CyIRChannel);
info = cinfo-ports[channel + chip * 4];
@@ -1315,7 +1309,6 @@ end:
/* end of service */
cy_writeb(base_addr + (CyMIR index), save_xir 0x3f);
cy_writeb(base_addr + (CyCAR index), save_car);
- spin_unlock(cinfo-card_lock);
}
/* The real interrupt service routine is called
@@ -1367,12 +1360,14 @@ static irqreturn_t cyy_interrupt(int irq, void *dev_id)
*/
if (1000 too_many++)
break;
+ spin_lock(cinfo-card_lock);
if (status CySRReceive) /* rx intr */
cyy_chip_rx(cinfo, chip, base_addr);
if (status CySRTransmit) /* tx intr */
cyy_chip_tx(cinfo, chip, base_addr);
if (status CySRModem) /* modem intr */
cyy_chip_modem(cinfo, chip, base_addr);
+ spin_unlock(cinfo-card_lock);
}
}
} while (had_work);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] Char: cyclades, fix some -W warnings
cyclades, fix some -W warnings
most of them are signedness, the rest unused function parameters.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
---
commit c5b48bcb1d32983ffa85a351c6d24ee92c5b8446
tree dd74dc5d8fac41e70251b34a947f389e531a27cd
parent 93fc0dd73bb407b773506ec8d756317de9098d53
author Jiri Slaby [EMAIL PROTECTED] Sun, 29 Jul 2007 21:36:27 +0200
committer Jiri Slaby [EMAIL PROTECTED] Sun, 29 Jul 2007 21:36:27 +0200
drivers/char/cyclades.c | 84 --
include/linux/cyclades.h | 12 +++
2 files changed, 43 insertions(+), 53 deletions(-)
diff --git a/drivers/char/cyclades.c b/drivers/char/cyclades.c
index a83524a..7025a28 100644
--- a/drivers/char/cyclades.c
+++ b/drivers/char/cyclades.c
@@ -662,7 +662,7 @@
static void cy_throttle(struct tty_struct *tty);
static void cy_send_xchar(struct tty_struct *tty, char ch);
-#define IS_CYC_Z(card) ((card).num_chips == -1)
+#define IS_CYC_Z(card) ((card).num_chips == (unsigned int)-1)
#define Z_FPGA_CHECK(card) \
((readl(((struct RUNTIME_9060 __iomem *) \
@@ -985,25 +985,23 @@ static void cyy_chip_rx(struct cyclades_card *cinfo, int
chip,
{
struct cyclades_port *info;
struct tty_struct *tty;
- int char_count;
- int j, len, index = cinfo-bus_index;
- int save_xir, channel, save_car;
- char data;
+ int len, index = cinfo-bus_index;
+ u8 save_xir, channel, save_car, data, char_count;
#ifdef CY_DEBUG_INTERRUPTS
printk(KERN_DEBUG cyy_interrupt: rcvd intr, chip %d\n, chip);
#endif
/* determine the channel change to that context */
- save_xir = (u_char) readb(base_addr + (CyRIR index));
- channel = (u_short) (save_xir CyIRChannel);
+ save_xir = readb(base_addr + (CyRIR index));
+ channel = save_xir CyIRChannel;
info = cinfo-ports[channel + chip * 4];
save_car = readb(base_addr + (CyCAR index));
cy_writeb(base_addr + (CyCAR index), save_xir);
/* if there is nowhere to put the data, discard it */
if (info-tty == NULL) {
- j = (readb(base_addr + (CyRIVR index)) CyIVRMask);
- if (j == CyIVRRxEx) { /* exception */
+ if ((readb(base_addr + (CyRIVR index)) CyIVRMask) ==
+ CyIVRRxEx) {/* exception */
data = readb(base_addr + (CyRDSR index));
} else {/* normal character reception */
char_count = readb(base_addr + (CyRDCR index));
@@ -1014,8 +1012,8 @@ static void cyy_chip_rx(struct cyclades_card *cinfo, int
chip,
}
/* there is an open port for this data */
tty = info-tty;
- j = readb(base_addr + (CyRIVR index)) CyIVRMask;
- if (j == CyIVRRxEx) { /* exception */
+ if ((readb(base_addr + (CyRIVR index)) CyIVRMask) ==
+ CyIVRRxEx) {/* exception */
data = readb(base_addr + (CyRDSR index));
/* For statistics only */
@@ -1116,13 +1114,12 @@ end:
cy_writeb(base_addr + (CyCAR index), save_car);
}
-static void cyy_chip_tx(struct cyclades_card *cinfo, int chip,
+static void cyy_chip_tx(struct cyclades_card *cinfo, unsigned int chip,
void __iomem *base_addr)
{
struct cyclades_port *info;
- int char_count;
- int outch;
- int save_xir, channel, save_car, index = cinfo-bus_index;
+ int char_count, index = cinfo-bus_index;
+ u8 save_xir, channel, save_car, outch;
/* Since we only get here when the transmit buffer
is empty, we know we can always stuff a dozen
@@ -1132,8 +1129,8 @@ static void cyy_chip_tx(struct cyclades_card *cinfo, int
chip,
#endif
/* determine the channel change to that context */
- save_xir = (u_char) readb(base_addr + (CyTIR index));
- channel = (u_short) (save_xir CyIRChannel);
+ save_xir = readb(base_addr + (CyTIR index));
+ channel = save_xir CyIRChannel;
save_car = readb(base_addr + (CyCAR index));
cy_writeb(base_addr + (CyCAR index), save_xir);
@@ -1242,12 +1239,12 @@ static void cyy_chip_modem(struct cyclades_card *cinfo,
int chip,
void __iomem *base_addr)
{
struct cyclades_port *info;
- int mdm_change, mdm_status;
- int save_xir, channel, save_car, index = cinfo-bus_index;
+ int index = cinfo-bus_index;
+ u8 save_xir, channel, save_car, mdm_change, mdm_status;
/* determine the channel change to that context */
- save_xir = (u_char) readb(base_addr + (CyMIR index));
- channel = (u_short) (save_xir CyIRChannel);
+ save_xir = readb(base_addr + (CyMIR index));
+ channel = save_xir CyIRChannel;
info = cinfo-ports[channel + chip * 4];
save_car = readb(base_addr + (CyCAR index));
cy_writeb(base_addr + (CyCAR index), save_xir);
@@ -1320,10
[PATCH] fix runtogether printk's in cmd64x IDE driver
Fix a couple of runtogether printks in cmd64x.c IDE driver by adding
proper newlines.
Signed-off-by: Meelis Roos [EMAIL PROTECTED]
diff --git a/drivers/ide/pci/cmd64x.c b/drivers/ide/pci/cmd64x.c
index 19633c5..0e3b5de 100644
--- a/drivers/ide/pci/cmd64x.c
+++ b/drivers/ide/pci/cmd64x.c
@@ -475,11 +475,11 @@ static unsigned int __devinit init_chipset_cmd64x(struct
pci_dev *dev, const cha
switch (rev) {
case 0x07:
case 0x05:
- printk(%s: UltraDMA capable, name);
+ printk(%s: UltraDMA capable\n, name);
break;
case 0x03:
default:
- printk(%s: MultiWord DMA force limited, name);
+ printk(%s: MultiWord DMA force limited\n, name);
break;
case 0x01:
printk(%s: MultiWord DMA limited,
--
Meelis Roos ([EMAIL PROTECTED])
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lib: move kasprintf to a separate file
On Sat, Jul 28, 2007 at 03:48:32PM -0700, Jeremy Fitzhardinge wrote: Sam Ravnborg wrote: kasprintf pulls in kmalloc which proved to be fatal for at least bootimage target on alpha. Move it to a separate file so only users of kasprintf are exposed to the dependency on kmalloc. OK by me (that's what my original patch did), but it might be worth documenting what environmental constraints vsprintf.c is under. I didn't realize it was used by non-kernel code. Looking for other users I saw that i386 iboot had included a minimal printf implmentation which could also be a possibility for alpha. Now the i386 printf does not support 64 bit - but I dunno if this is a problem for alpha. Actually I would prefer the local printf solution for alpha to keep dependencies on the functions in lib/ as one may expect them (kernel only - not boot). Sam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.23 1/2] Make the iw_cxgb3 module parameters writable.
Make the iw_cxgb3 module parameters writable.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_cm.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c
b/drivers/infiniband/hw/cxgb3/iwch_cm.c
index 9574088..fa95dce 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cm.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c
@@ -63,37 +63,37 @@ static char *states[] = {
};
static int ep_timeout_secs = 10;
-module_param(ep_timeout_secs, int, 0444);
+module_param(ep_timeout_secs, int, 0644);
MODULE_PARM_DESC(ep_timeout_secs, CM Endpoint operation timeout
in seconds (default=10));
static int mpa_rev = 1;
-module_param(mpa_rev, int, 0444);
+module_param(mpa_rev, int, 0644);
MODULE_PARM_DESC(mpa_rev, MPA Revision, 0 supports amso1100,
1 is spec compliant. (default=1));
static int markers_enabled = 0;
-module_param(markers_enabled, int, 0444);
+module_param(markers_enabled, int, 0644);
MODULE_PARM_DESC(markers_enabled, Enable MPA MARKERS (default(0)=disabled));
static int crc_enabled = 1;
-module_param(crc_enabled, int, 0444);
+module_param(crc_enabled, int, 0644);
MODULE_PARM_DESC(crc_enabled, Enable MPA CRC (default(1)=enabled));
static int rcv_win = 256 * 1024;
-module_param(rcv_win, int, 0444);
+module_param(rcv_win, int, 0644);
MODULE_PARM_DESC(rcv_win, TCP receive window in bytes (default=256));
static int snd_win = 32 * 1024;
-module_param(snd_win, int, 0444);
+module_param(snd_win, int, 0644);
MODULE_PARM_DESC(snd_win, TCP send window in bytes (default=32KB));
static unsigned int nocong = 0;
-module_param(nocong, uint, 0444);
+module_param(nocong, uint, 0644);
MODULE_PARM_DESC(nocong, Turn off congestion control (default=0));
static unsigned int cong_flavor = 1;
-module_param(cong_flavor, uint, 0444);
+module_param(cong_flavor, uint, 0644);
MODULE_PARM_DESC(cong_flavor, TCP Congestion control flavor (default=1));
static void process_work(struct work_struct *work);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.23 2/2] iw_cxgb3: Always call low level send function via cxgb3_ofld_send().
iw_cxgb3: Always call low level send function via cxgb3_ofld_send().
Avoids deadlocks.
Signed-off-by: Steve Wise [EMAIL PROTECTED]
---
drivers/infiniband/hw/cxgb3/iwch_cm.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c
b/drivers/infiniband/hw/cxgb3/iwch_cm.c
index fa95dce..20ba372 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cm.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c
@@ -139,7 +139,7 @@ static void release_tid(struct t3cdev *t
req-wr.wr_hi = htonl(V_WR_OP(FW_WROPCODE_FORWARD));
OPCODE_TID(req) = htonl(MK_OPCODE_TID(CPL_TID_RELEASE, hwtid));
skb-priority = CPL_PRIORITY_SETUP;
- tdev-send(tdev, skb);
+ cxgb3_ofld_send(tdev, skb);
return;
}
@@ -161,7 +161,7 @@ int iwch_quiesce_tid(struct iwch_ep *ep)
req-val = cpu_to_be64(1 S_TCB_RX_QUIESCE);
skb-priority = CPL_PRIORITY_DATA;
- ep-com.tdev-send(ep-com.tdev, skb);
+ cxgb3_ofld_send(ep-com.tdev, skb);
return 0;
}
@@ -183,7 +183,7 @@ int iwch_resume_tid(struct iwch_ep *ep)
req-val = 0;
skb-priority = CPL_PRIORITY_DATA;
- ep-com.tdev-send(ep-com.tdev, skb);
+ cxgb3_ofld_send(ep-com.tdev, skb);
return 0;
}
@@ -784,7 +784,7 @@ static int update_rx_credits(struct iwch
OPCODE_TID(req) = htonl(MK_OPCODE_TID(CPL_RX_DATA_ACK, ep-hwtid));
req-credit_dack = htonl(V_RX_CREDITS(credits) | V_RX_FORCE_ACK(1));
skb-priority = CPL_PRIORITY_ACK;
- ep-com.tdev-send(ep-com.tdev, skb);
+ cxgb3_ofld_send(ep-com.tdev, skb);
return credits;
}
@@ -1152,7 +1152,7 @@ static int listen_start(struct iwch_list
req-opt1 = htonl(V_CONN_POLICY(CPL_CONN_POLICY_ASK));
skb-priority = 1;
- ep-com.tdev-send(ep-com.tdev, skb);
+ cxgb3_ofld_send(ep-com.tdev, skb);
return 0;
}
@@ -1186,7 +1186,7 @@ static int listen_stop(struct iwch_liste
req-cpu_idx = 0;
OPCODE_TID(req) = htonl(MK_OPCODE_TID(CPL_CLOSE_LISTSRV_REQ, ep-stid));
skb-priority = 1;
- ep-com.tdev-send(ep-com.tdev, skb);
+ cxgb3_ofld_send(ep-com.tdev, skb);
return 0;
}
@@ -1264,7 +1264,7 @@ static void reject_cr(struct t3cdev *tde
rpl-opt0l_status = htonl(CPL_PASS_OPEN_REJECT);
rpl-opt2 = 0;
rpl-rsvd = rpl-opt2;
- tdev-send(tdev, skb);
+ cxgb3_ofld_send(tdev, skb);
}
}
@@ -1557,7 +1557,7 @@ static int peer_abort(struct t3cdev *tde
rpl-wr.wr_lo = htonl(V_WR_TID(ep-hwtid));
OPCODE_TID(rpl) = htonl(MK_OPCODE_TID(CPL_ABORT_RPL, ep-hwtid));
rpl-cmd = CPL_ABORT_NO_RST;
- ep-com.tdev-send(ep-com.tdev, rpl_skb);
+ cxgb3_ofld_send(ep-com.tdev, rpl_skb);
if (state != ABORTING) {
state_set(ep-com, DEAD);
release_ep_resources(ep);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
Ray wrote: Ah, so in a normal scenario where a working-set is getting faulted back in, we have the swap storage as well as the file-backed stuff that needs to be read as well. So even if swap is organized perfectly, we're still seeking. Damn. Perhaps this applies in some cases ... perhaps. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson [EMAIL PROTECTED] 1.925.600.0401 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reading a bad sector does not report failure as 'read error' but hangs PC with 'Machine Check Exception'
How can I do this? I have installed mcelog but I cannot run it after the MCE error because the whole PC hangs. If I try it after a reboot with 'mcelog --k8 --ascii' or whatever parameter, there is no output at You could type error back in from the email ? Isn't it strange to say that the controller does something bad if there is just a bad sector on the drive that is reported and handled correctly in an older kernel Not really. Its very strange it gives an MCE at all but this is a known failure path (and should be a fixed known failure path) for the Nvidia SATA. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On 7/29/07, Paul Jackson [EMAIL PROTECTED] wrote: Ray wrote: Ah, so in a normal scenario where a working-set is getting faulted back in, we have the swap storage as well as the file-backed stuff that needs to be read as well. So even if swap is organized perfectly, we're still seeking. Damn. Perhaps this applies in some cases ... perhaps. Yeah, point taken: better data would make this a lot easier to figure out and target fixes. Ray - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
* Satyam Sharma [EMAIL PROTECTED] wrote: So whats wrong then? Ingo decides to do a better scheduler - to some extent inspired by Con's work. And after 48 hours he publish first version that _anyone_ can see and comment on. Whats wrong with that? Did you expect some lengthy discussion before the coding phase started or what? Just trying to understand what you are arguing about. If I tried to rewrite a kernel subsystem - should I ever happen to dig that deep into kernel matters - while I actually know that someone already spent countless hours on exactly rewriting the exact same subsystem, I think I would have told that other developer about it as soon as I started coding on it. And if it just was a Hi Con, I reconsidered the scheduling ideas again you brought to the Linux kernel world. Instead of using your scheduler tough I like to try to write a new one with fairness in mind, cause I think this, this and this can be improved upon. I would like to hear your ideas about that as soon as possible and would like you to contribute your ideas and also code, where you see hit. You can find the git / bazaar / whatever repository where I do my developments at: someurl. Regards, Ingo Sending out the code (and early enough, 48 hours /is/ early enough) *is* the normal (and good) way to do exactly the communication you described above, IMHO. yeah. And note that the time from the ok, this approach might work point to releasing CFS was even less than the original ~62 hours of CFS development. I dont typically write code because i'm particularly convinced about an idea or because i believe in an idea, i mostly write code to _check_ whether an idea is worth advancing or not. Writing code is my form of thinking, and releasing patches is my form of telling others about my thoughts. I might have guesses about how well something will work out in practice (and i'd certainly be a fool to go out coding blindly), but surprises happen almost always, both in positive and in negative direction, and even with relatively simple patches. CFS started out as an experiment to simplify the scheduler, to clean up the after-effects of a better-desktop-scheduling patch Mike Galbraith sent me. Had anyone told me at that time that i'd end up writing a new scheduler i'd have laughed at the suggestion and i'd have pointed to the large number of pending patches of mine in forms of the -rt tree, the syslet/threadlet code and other stuff that needs fixing a lot more urgent than the task scheduler. During that cleanup work did i realize how a policy-modularized scheduler would allow the bridging of the seemingly unreconcilable friction between the O(1) data structures that things like RT scheduling needs and the binary tree that fair share scheduling concepts dictate. (most of the complexity in kernel code like the scheduler derives from complexity in data structures, so you start writing code by thinking about your data structures.) And the time from the point where i thought ok, this fair-share thing behaves pretty well and it certainly looks simpler than the current code to the announcement on lkml was more on the order of hours than days - much of the 62 hours were spent on ripping out the old code and on getting the new design up and running. There was simply no code in existence before CFS which has proven the code simplicity/design virtues of 'fair scheduling' - SD was more of an argument _against_ it than for it. I think maybe even Con might have been surprised by that simplicity: in his first lkml reaction to CFS he also wrote that he finds the CFS code beautiful: http://lkml.org/lkml/2007/4/14/199 and my reply to Con's mail: http://lkml.org/lkml/2007/4/15/64 still addresses a good number of points raised in this thread i think. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, 2007-07-29 at 16:31 +0200, Diego Calleja wrote: El Sat, 28 Jul 2007 18:00:39 -0700, Bill Huey (hui) [EMAIL PROTECTED] escribió: The scheduler could have and still can undertake good solid transformation, but getting folks to listen is another story which is why Con quit. CFS basically locks him and his ideas out, not just from a technical stand This is just wrong: AFAIK nobody is stopping Con or any other people from continuing developing SD or any other scheduler, and CFS certainly is subject to criticism. The idea that Linux can't use other innovative ideas in the scheduler is only in your mind. Absolutely. Con quit for his own reasons. Given that Con himself has said that CFS was _not_ why he quite, please discard this... bait. Anyone who's name isn't Con Kolivas, who pretends to speak for him is at the very least overstepping his bounds, and that is being _very_ generous. -Mike - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] kernel/audit.c: change the exports to EXPORT_SYMBOL_GPL
On Sun, Jul 29, 2007 at 05:02:33PM +0200, Adrian Bunk wrote: This patch changes some completely unused audit exports from EXPORT_SYMBOL to EXPORT_SYMBOL_GPL. They are still completely unused, but hopefully some of the theoretical code that might use it will appear in the kernel in the near future... Please kill them. We can add exports back once people add users for them. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with reading DVD using 2.6.21.5
As remounting fixes the problem, I think it doesn't have to do anything with the IDE driver, right? The device node should always be connected with the physical device, even if unmount. So the problem seems to be The IDE driver handles retries, although for IDE the drive itself also handles them too by default. So the question is: What exactly will this ISO 9660 driver do, if there is a read error? Will it mark this failed byte as unreadable and will never try again, or will it try again for at least one ore more times? It knows nothing about retry - that happens lower down. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5 v3] Add the platform device support with RapidIO to MPC8641HPCN platform.
On Thursday 26 July 2007, Zhang Wei wrote:
+
+static struct of_device_id mpc86xx_of_ids[] = {
+ { .type = soc, },
+ { .compatible = fsl,rapidio-delta, },
+ {},
+};
With the device tree source you have posted in 2/5, the rapidio node is
a child of the soc bus, and it doesn't have any children of its own.
Therefore it is completely equivalent to _only_ add the soc type
to mpc86xx_of_ids[], as in
static struct of_device_id mpc86xx_of_ids[] = {
{ .type = soc, },
{},
};
Even if you intend to add children to the rapidio node in the future,
I'd think it would be more appropriate to have those scanned by
the rapidio bus driver, not by of_platform.
Arnd
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Introduce CONFIG_SUSPEND
On Sun, Jul 29, 2007 at 02:38:05PM +0200, Rafael J. Wysocki wrote: ... +config SUSPEND + bool Suspend Suspend to RAM ... config HIBERNATION bool Hibernation ... Hibernation (Suspend to disk) 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 from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] undefined reference to `kobject_actions'
On Sun, Jul 29, 2007 at 09:59:05PM +0200, Kay Sievers wrote: On Sun, 2007-07-29 at 20:37 +0100, Russell King wrote: On Sun, Jul 29, 2007 at 08:34:01PM +0100, Russell King wrote: Many ARM platforms fail to build with the following: drivers/built-in.o: In function `store_uevent': hid-input.c:(.text+0x19c4c): undefined reference to `kobject_actions' It appears that if hotplug is disabled, kobject_actions is ifdef'd away but hid-input still references it. What I also meant to say is that it looks like it's caused by commit 60a96a59569bab85571d0089682109bd3324e896. Presumably if hotplug is disabled, we want store_uevent to be removed as well? Does this patch fix it? http://lkml.org/lkml/2007/7/20/143 Yup, thanks. Any idea when this fix will hit mainline? Looks like it's 9 days old, and it fixes real build errors. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: SD still better than CFS for 3d ?(was Re: 2.6.23-rc1)
* John [EMAIL PROTECTED] wrote: Ingo- Why not perform the same test using the native linux Q3 client to compare numbers to wine? [...] I regularly test native Linux games on CFS, and they all behave well. While waiting for more detailed data from Kasper i was looking for atypical stuff in Kasper's description about what his workload involves, and what looked a bit atypical was that Kasper's workload also involved gaming under Wine: my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. [...] and Wine is a more complex server/client scenario instead of a single (and simple) standalone Quake3 binary that the Linux binary does. So it looked more interesting from a scheduler workload (and scheduler regression) POV. In any case i'll need more info from Kasper. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sb1000: prevent a potential NULL pointer dereference in sb1000_dev_ioctl()
On Sunday 29 July 2007 21:09, Satyam Sharma wrote: Hi Michael, On Sun, 29 Jul 2007, Michael Buesch wrote: On Sunday 29 July 2007 20:34:46 Satyam Sharma wrote: (2) !(dev-flags IFF_UP) is bogus because the functions of this ioctl can (and should) be allowed even when the interface is not up and running. Are you _sure_? This function does poke with the device hardware. It might return crap or even machinecheck when not initialized. Hardware is probably powered down, if not IFF_UP. (I don't know if that's the case here, though). IFF_UP checks if the _interface_ is up -- the hardware / card could still be powered up, but the interface down (ifconfing eth0 down or ip link set eth0 down). Well, that is device/driver dependent and I don't know what's the case for this driver. It's encouraged to shutdown hardware completely (except the WOL parts) when the interface is down. Dunno if this driver does it. But _if_ it does it, it could cause problems to poke with the hardware while down. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sparc32 not working:2.6.23-rc1 (git commit 1e4dcd22efa7d24f637ab2ea3a77dd65774eb005)
On Sun, Jul 29, 2007 at 07:26:29PM +0100, Mark Fortescue wrote: ... I am going to try to cherry pick a set of commits to see if I can't get a better idear of where the memory corruption on sun4c is coming from. Build problems sue to the DMA changes make git bisecting un-usable untill I have found out which patches fix the DMA build issues. You have any known-good kernel? Boot back into this kernel for bisecting and compiling the kernels for bisecting there. 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 from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] arch/powerpc/Kconfig: fix the EMBEDDED6xx dependencies
On Saturday 28 July 2007, Adrian Bunk wrote: On Mon, Dec 04, 2006 at 02:06:34PM +1100, Paul Mackerras wrote: Adrian Bunk writes: This patch changes the EMBEDDED6xx dependencies to the equivalent dependency that seems to have been intended. Nack - CONFIG_EMBEDDED6xx is going away entirely, soon. Still there - and still with this strange dependency. The last time I sent my patch to clean up CONFIG_EMBEDDED6xx and a few other Kconfig options I still left it intact, but it becomes unnecessary after that. I still think that having high-level options like * embedded6xx * MPC7448HPC2 * holly * linkstation * PPC_83xx * MPC8313_RDB * MPC832x_MDS * MPC832x_RDB helps keep the platform selection more structured and readable, but the dependency on !SMP should probably go into the individual platforms that are actually broken, if any, not into the high-level option. Arnd - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On Sunday 29 July 2007 16:00:22 Ray Lee wrote: On 7/29/07, Paul Jackson [EMAIL PROTECTED] wrote: If the problem is reading stuff back in from swap at the *same time* that the application is reading stuff from some user file system, and if that user file system is on the same drive as the swap partition (typical on laptops), then interleaving the user file system accesses with the swap partition accesses might overwhelm all other performance problems, due to the frequent long seeks between the two. Ah, so in a normal scenario where a working-set is getting faulted back in, we have the swap storage as well as the file-backed stuff that needs to be read as well. So even if swap is organized perfectly, we're still seeking. Damn. That is one reason why I try to have swap on a device dedicated just for it. It helps keep the system from having to seek all over the drive for data. (I remember that this was recommended years ago with Windows - back when you could tell Windows where to put the swap file) On the other hand, that explains another thing that swap prefetch could be helping with -- if it preemptively faults the swap back in, then the file-backed stuff can be faulted back more quickly, just by the virtue of not needing to seek back and forth to swap for its stuff. Hadn't thought of that. For it to really help swap-prefetch would have to be more aggressive. At the moment (if I'm reading the code correctly) the system has to have close to zero for it to kick in. A tunable knob controlling how much activity is too much for the prefetch to kick in would help with finding a sane default. IMHO it should be the one that provides the most benefit with the least hit to performance. That also implies that people running with swap files rather than swap partitions will see less of an issue. I should dig out my old compact flash card and try putting swap on that for a week. Maybe. It all depends on how much seeking is needed to track down the pages in the swapfile and such. What would really help make the situation even better would be doing the log structured swap + cleaner. The log structured swap + cleaner should provide a performance boost by itself - add in the prefetch mechanism and the benefits are even more visible. Another way to improve performance would require making the page replacement mechanism more intelligent. There are bounds to what can be done in the kernel without negatively impacting performance, but, if I've read the code correctly, there might be a better way to decide which pages to evict. One way to do this would be to implement some mechanism that allows the system to choose a single group of contiguous pages (or, say, a large soft-page) over swapping out a single page at a time. (some form of memory defrag would also be nice, but I can't think of a way to do that without massively breaking everything) snip In case Andrew is so bored he read this far -- yes this wake-up sounds like user space code, with minimal kernel changes to support any particular lower level operation that we can't do already. He'd suggested using, uhm, ptrace_peek or somesuch for just such a purpose. The second half of the issue is to know when and what to target. The userspace suggestion that was thrown out earlier would have been as error-prone and problematic as FUSE. A solution like you suggest would be workable - its small and does a task that is best done in userspace (IMHO). (IIRC, the original suggestion involved merging maps2 and another patchset into mainline and using that, combined with PEEKTEXT to provide for a userspace swap daemon. Swap, IMHO, should never be handled outside the kernel) What might be useful is a userspace daemon that tracks memory pressure and uses a concise API to trigger various levels of prefetch and/or swap aggressiveness. DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Introduce CONFIG_SUSPEND
On Sunday, 29 July 2007 22:40, Adrian Bunk wrote: On Sun, Jul 29, 2007 at 02:38:05PM +0200, Rafael J. Wysocki wrote: ... +config SUSPEND + bool Suspend Suspend to RAM Not only. This also includes standby. ... config HIBERNATION bool Hibernation ... Hibernation (Suspend to disk) cu Adrian Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
cpufreq scaling appears not to work on overclocked systems
This is not new, but exists as far back as 2.6.17. I haven't reported it before because I figured that surely someone else had noticed it, but since it's still unfixed and I cannot find any mention of it on LKML, here we go. I'm running a Core2 Duo 1.86GHz overclocked to 2.56GHz. Everything is normal with cpufreq scaling disabled. With cpufreq scaling enabled in the kernel, using any governor, /proc/cpuinfo indicates a maximum of the rated frequency rather than the actual frequency. Here it is under 100% utilization, with userspace governor and powernowd: [EMAIL PROTECTED]:~$ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 6 cpu MHz : 1862.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 5134.39 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 CPU 6300 @ 1.86GHz stepping: 6 cpu MHz : 1862.000 cache size : 2048 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr lahf_lm bogomips: 5131.64 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: At idle it drops down to 1596.000 MHz reported. At boot the kernel doest report the correct frequency (2564.907), which agrees with the bogomips reported by /proc/cpuinfo as well. I haven't done any benchmarking to try to determine if perhaps freq scaling works as it should and just the reported frequency is incorrect. Berck - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] sched: introduce SD_BALANCE_FORK for ht/mc/smp domains
* Siddha, Suresh B [EMAIL PROTECTED] wrote: They might be doing more exec's and probably covered by exec balance. There was a small pthread test case which was calculating the time to create all the threads and how much time each thread took to start running. It appeared as if the threads ran sequentially one after another on a DP system with four cores leading to this SD_BALANCE_FORK observation. would be nice to dig out that testcase i suspect and quantify the benefits of your patch. Another workload which might perform better would be linpack: it benefits from fast and immediate 'spreading' of freshly forked threads. Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] sched: make cpu_clock() not use the rq clock
* Jeremy Fitzhardinge [EMAIL PROTECTED] wrote: Ingo Molnar wrote: Subject: sched: make cpu_clock() not use the rq clock This subject doesn't make much sense to me. All this patch does is get the rq's current time under irq_disable rather than spinlock, right? i typoed it: s/clock/lock Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Introduce CONFIG_SUSPEND
On Sun, Jul 29, 2007 at 11:17:20PM +0200, Rafael J. Wysocki wrote: On Sunday, 29 July 2007 22:40, Adrian Bunk wrote: On Sun, Jul 29, 2007 at 02:38:05PM +0200, Rafael J. Wysocki wrote: ... +config SUSPEND + bool Suspend Suspend to RAM Not only. This also includes standby. Whatever it includes - please tell it to the user in the prompt. Technical issues are important, but it's often forgotten how many problems people run into because the description of a kconfig option could have been better. ... config HIBERNATION bool Hibernation ... Hibernation (Suspend to disk) cu Adrian Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth 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 from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] Introduce CONFIG_SUSPEND (updated)
From: Rafael J. Wysocki [EMAIL PROTECTED] Introduce CONFIG_SUSPEND representing the ability to enter system sleep states, such as the ACPI S3 state, and allow the user to choose SUSPEND and HIBERNATION independently of each other. Make HOTPLUG_CPU be selected automatically if SUSPEND or HIBERNATION has been chosen and the kernel is intended for SMP systems. Also, introduce CONFIG_PM_SLEEP which is automatically selected if CONFIG_SUSPEND or CONFIG_HIBERNATION is set and use it to select the code needed for both suspend and hibernation. The top-level power management headers and the ACPI code related to suspend and hibernation are modified to use the new definitions (the changes in drivers/acpi/sleep/main.c are, mostly, moving code to reduce the number of ifdefs). Still, there are many other files in which CONFIG_PM can be replaced with CONFIG_PM_SLEEP or even with CONFIG_SUSPEND, but they can be updated in the future. Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] --- drivers/acpi/Kconfig|8 +++ drivers/acpi/sleep/Makefile |2 drivers/acpi/sleep/main.c | 94 +++- drivers/acpi/sleep/proc.c | 10 ++-- drivers/acpi/sleep/sleep.h |2 drivers/base/power/Makefile |2 drivers/base/power/power.h |4 - include/acpi/acpi_bus.h |9 include/acpi/acpi_drivers.h |4 + include/linux/freezer.h |6 +- include/linux/pm.h | 15 +-- include/linux/suspend.h | 10 ++-- kernel/power/Kconfig| 39 ++ kernel/power/Makefile |3 - kernel/power/main.c | 26 kernel/power/power.h| 10 mm/page_alloc.c |4 - 17 files changed, 163 insertions(+), 85 deletions(-) Index: linux-2.6/kernel/power/Kconfig === --- linux-2.6.orig/kernel/power/Kconfig 2007-07-29 19:06:26.0 +0200 +++ linux-2.6/kernel/power/Kconfig 2007-07-29 19:06:48.0 +0200 @@ -46,7 +46,7 @@ config PM_VERBOSE config DISABLE_CONSOLE_SUSPEND bool Keep console(s) enabled during suspend/resume (DANGEROUS) - depends on PM_DEBUG + depends on PM_DEBUG PM_SLEEP default n ---help--- This option turns off the console suspend mechanism that prevents @@ -57,7 +57,7 @@ config DISABLE_CONSOLE_SUSPEND config PM_TRACE bool Suspend/resume event tracing - depends on PM_DEBUG X86 EXPERIMENTAL + depends on PM_DEBUG X86 PM_SLEEP EXPERIMENTAL default n ---help--- This enables some cheesy code to save the last PM event point in the @@ -72,9 +72,37 @@ config PM_TRACE CAUTION: this option will cause your machine's real-time clock to be set to an invalid time after a resume. +config SUSPEND_SMP_POSSIBLE + bool + depends on (X86 !X86_VOYAGER) || (PPC64 (PPC_PSERIES || PPC_PMAC)) + depends on SMP + default y + +config SUSPEND_SMP + bool + depends on SUSPEND_SMP_POSSIBLE PM_SLEEP + select HOTPLUG_CPU + default y + +config PM_SLEEP + bool + depends on SUSPEND || HIBERNATION + default y + +config SUSPEND + bool Suspend to RAM and standby + depends on PM + depends on !SMP || SUSPEND_SMP_POSSIBLE + default y + ---help--- + Allow the system to enter sleep states in which main memory is + powered and thus its contents are preserved, such as the + suspend-to-RAM state (i.e. the ACPI S3 state). + config HIBERNATION bool Hibernation - depends on PM SWAP (((X86 || PPC64_SWSUSP) (!SMP || SUSPEND_SMP)) || ((FRV || PPC32) !SMP)) + depends on PM SWAP + depends on ((X86 || PPC64_SWSUSP || FRV || PPC32) !SMP) || SUSPEND_SMP_POSSIBLE ---help--- Enable the suspend to disk (STD) functionality, which is usually called hibernation in user interfaces. STD checkpoints the @@ -132,11 +160,6 @@ config PM_STD_PARTITION suspended image to. It will simply pick the first available swap device. -config SUSPEND_SMP - bool - depends on HOTPLUG_CPU (X86 || PPC64) PM - default y - config APM_EMULATION tristate Advanced Power Management Emulation depends on PM SYS_SUPPORTS_APM_EMULATION Index: linux-2.6/kernel/power/Makefile === --- linux-2.6.orig/kernel/power/Makefile2007-07-29 19:06:26.0 +0200 +++ linux-2.6/kernel/power/Makefile 2007-07-29 19:06:48.0 +0200 @@ -3,8 +3,9 @@ ifeq ($(CONFIG_PM_DEBUG),y) EXTRA_CFLAGS += -DDEBUG endif -obj-y := main.o process.o console.o +obj-y := main.o obj-$(CONFIG_PM_LEGACY)+= pm.o +obj-$(CONFIG_PM_SLEEP) += process.o console.o obj-$(CONFIG_HIBERNATION) +=
Re: RFT: updatedb morning after problem [was: Re: -mm merge plans for 2.6.23]
On Sun, 29 Jul 2007, Rene Herman wrote: On 07/29/2007 01:41 PM, [EMAIL PROTECTED] wrote: I agree that tinkering with the core VM code should not be done lightly, but this has been put through the proper process and is stalled with no hints on how to move forward. It has not. Concerns that were raised (by specifically Nick Piggin) weren't being addressed. I may have missed them, but what I saw from him weren't specific issues, but instead a nebulous 'something better may come along later' forget the nightly cron jobs for the moment. think of this scenerio. you have your memory fairly full with apps that you have open (including firefox with many tabs), you receive a spreadsheet you need to look at, so you fire up openoffice to look at it. then you exit openoffice and try to go back to firefox (after a pause while you walk to the printer to get the printout of the spreadsheet) And swinging a dead rat from its tail facing east-wards while reciting Documentation/CodingStyle. Okay, very very sorry, that was particularly childish, but that walking to the printer is ofcourse completely constructed and this _is_ something to take into account. yes it was contrived for simplicity. the same effect would happen if instead of going back to firefox the user instead went to their e-mail software and read some mail. doing so should still make the machine idle enough to let prefetch kick in. Swap-prefetch wants to be free, which (also again) it is doing a good job at it seems, but this also means that it waits for the VM to be _very_ idle before it does anything and as such, we cannot just forget the nightly scenario and pretend it's about something else entirely. As long as the machine's being used, swap-prefetch doesn't kick in. how long does the machine need to be idle? if someone spends 30 seconds reading an e-mail that's an incredibly long time for the system and I would think it should be enough to let the prefetch kick in. -- 3: no serious consideration of possible alternatives Tweaking existing use-oce logic is one I've heard but if we consider the i/dcache issue dead, I believe that one is as well. Going to userspace is another one. Largest theoretical potential. I myself am extremely sceptical about the Linux userland, and largely equate it with smallest _practical_ potential -- but that might just be me. A larger swap granularity, possible even a self-training granularity. Up to now, seeks only get costlier and costlier with respect to reads with every generation of disk (flash would largely overcome it though) and doing more in one read/write _greatly_ improves throughput, maybe up to the point that swap-prefetch is no longer very useful. I myself don't know about the tradeoffs involved. larger swap granularity may help, but waiting for the user to need the ram and have to wait for it to be read back in is always going to be worse for the user then pre-populating the free memory (for the case where the pre-population is right, for other cases it's the same). so I see this as a red herring I saw Chris Snook make a good post here and am going to defer this part to that discussion: http://lkml.org/lkml/2007/7/27/421 But no, it's not a red herring if _practically_ speaking the swapin is fast enough once started that people don't actually mind anymore since in that case you could simply do without yet more additional VM complexity (and kernel daemon). swapin will always require disk access, and avoiding doing disk access while the user is waiting for it by doing it when the system isn't useing the disk will always be a win (possibly not as large of a win, but still a win) on slow laptop drives where you may only get 20MB/second of reads under optimal situations it doesn't take much reading to be noticed by the user. there are fully legitimate situations where this is useful, the 'papering over' effect is not referring to these, it's referring to other possible problems in the future. No, it's not just future. Just look at the various things under discussion now such as improved use-once and better swapin. and these thing do not conflict with prefetch, they compliment it. improved use-once will avoid pushing things out to swap in the first place. this will help during normal workloads so is valuble in any case. better swapin (I assume you are talking about things like larger swap granularity) will also help during normal workloads when you are thrashing into swap. prefetch will help when you have pushed things out to swap and now have free memory and a momentarily idle system. David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ppc: chipsfb.c build fix for CONFIG_PM
On Sunday, 29 July 2007 19:50, Mariusz Kozlowski wrote: Hello, This patch fixes the following build error on powerpc: CC drivers/video/chipsfb.o drivers/video/chipsfb.c: In function 'chipsfb_pci_suspend': drivers/video/chipsfb.c:461: error: 'PM_SUSPEND_MEM' undeclared (first use in this function) drivers/video/chipsfb.c:461: error: (Each undeclared identifier is reported only once drivers/video/chipsfb.c:461: error: for each function it appears in.) make[2]: *** [drivers/video/chipsfb.o] Blad 1 make[1]: *** [drivers/video] Blad 2 make: *** [drivers] Blad 2 Already fixed in the right way. Please see: http://www.mail-archive.com/[EMAIL PROTECTED]/msg22171.html Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] Introduce CONFIG_HIBERNATION and CONFIG_SUSPEND (updated)
On Sunday, 29 July 2007 12:20, Rafael J. Wysocki wrote: On Saturday, 28 July 2007 20:31, Linus Torvalds wrote: On Sat, 28 Jul 2007, Rafael J. Wysocki wrote: OK, I'll prepare a patch to introduce CONFIG_SUSPEND, but that will require quite a bit of (compilation) testing on different architectures. Sure. I'm not too worried, the fallout should be of the trivial kind. Also, mind basing it on the (independent) cleanups that Adrian already sent out. This is all intertwined.. OK, it took more time than I had hoped, but I wanted CONFIG_HIBERNATION and CONFIG_SUSPEND to be really independent of each other. The two patches in the next messages implement the idea: * replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION * introduce CONFIG_SUSPEND that selects CONFIG_HOTPLUG_CPU, if necessary, and make it possible to choose suspend and hibernation independently of each other. Unfortunately, the patches that I have posted are against 2.6.23-rc1 with the suspend and hibernation patchset applied (http://www.sisk.pl/kernel/hibernation_and_suspend/2.6.23-rc1/patches/) . Sorry for that. The corresponding patches on top of the current -git are in the next two messages. They do the following: * replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION * introduce CONFIG_SUSPEND that selects CONFIG_HOTPLUG_CPU, if necessary, and make it possible to choose suspend and hibernation independently of each other * update the top-level PM-related headers and the ACPI code related to suspend and hibernation to use the new definitions Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] undefined reference to `kobject_actions'
On Sun, Jul 29, 2007 at 09:41:10PM +0100, Russell King wrote: On Sun, Jul 29, 2007 at 09:59:05PM +0200, Kay Sievers wrote: On Sun, 2007-07-29 at 20:37 +0100, Russell King wrote: On Sun, Jul 29, 2007 at 08:34:01PM +0100, Russell King wrote: Many ARM platforms fail to build with the following: drivers/built-in.o: In function `store_uevent': hid-input.c:(.text+0x19c4c): undefined reference to `kobject_actions' It appears that if hotplug is disabled, kobject_actions is ifdef'd away but hid-input still references it. What I also meant to say is that it looks like it's caused by commit 60a96a59569bab85571d0089682109bd3324e896. Presumably if hotplug is disabled, we want store_uevent to be removed as well? Does this patch fix it? http://lkml.org/lkml/2007/7/20/143 Yup, thanks. Any idea when this fix will hit mainline? Looks like it's 9 days old, and it fixes real build errors. I've been at OSCON all last week, this will go to Linus on Monday. Sorry for the delay, conference season sucks at times... thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] Replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION (updated)
From: Rafael J. Wysocki [EMAIL PROTECTED] Replace CONFIG_SOFTWARE_SUSPEND with CONFIG_HIBERNATION to avoid confusion (among other things, with CONFIG_SUSPEND introduced in the next patch). Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] --- arch/i386/Kconfig.debug |4 ++-- arch/i386/kernel/e820.c |2 +- arch/i386/mm/init.c |2 +- arch/i386/power/Makefile|2 +- arch/powerpc/Kconfig.debug |2 +- arch/powerpc/configs/lite5200_defconfig |2 +- arch/powerpc/configs/pmac32_defconfig |2 +- arch/powerpc/kernel/Makefile|6 +++--- arch/ppc/configs/TQM8540_defconfig |2 +- arch/ppc/configs/TQM8541_defconfig |2 +- arch/ppc/configs/TQM8555_defconfig |2 +- arch/ppc/configs/TQM8560_defconfig |2 +- arch/ppc/configs/ev64360_defconfig |2 +- arch/ppc/configs/ml300_defconfig|2 +- arch/ppc/configs/ml403_defconfig|2 +- arch/ppc/configs/mpc834x_sys_defconfig |2 +- arch/ppc/configs/prep_defconfig |2 +- arch/sparc64/Kconfig.debug |2 +- arch/x86_64/defconfig |2 +- arch/x86_64/kernel/Makefile |2 +- arch/x86_64/kernel/suspend.c|4 ++-- drivers/acpi/sleep/main.c |6 +++--- drivers/acpi/sleep/proc.c |2 +- drivers/i2c/chips/tps65010.c|2 +- include/asm-i386/e820.h |2 +- include/linux/suspend.h |8 kernel/power/Kconfig|6 +++--- kernel/power/Makefile |2 +- kernel/power/main.c |2 +- kernel/power/power.h|2 +- kernel/sys.c|2 +- mm/Kconfig |4 ++-- mm/swapfile.c |6 +++--- 33 files changed, 47 insertions(+), 47 deletions(-) Index: linux-2.6/arch/i386/Kconfig.debug === --- linux-2.6.orig/arch/i386/Kconfig.debug 2007-05-10 21:34:50.0 +0200 +++ linux-2.6/arch/i386/Kconfig.debug 2007-07-29 18:49:05.0 +0200 @@ -36,11 +36,11 @@ config DEBUG_STACK_USAGE This option will slow down process creation somewhat. comment Page alloc debug is incompatible with Software Suspend on i386 - depends on DEBUG_KERNEL SOFTWARE_SUSPEND + depends on DEBUG_KERNEL HIBERNATION config DEBUG_PAGEALLOC bool Debug page memory allocations - depends on DEBUG_KERNEL !SOFTWARE_SUSPEND !HUGETLBFS + depends on DEBUG_KERNEL !HIBERNATION !HUGETLBFS help Unmap pages from the kernel linear mapping after free_pages(). This results in a large slowdown, but helps to find certain types Index: linux-2.6/arch/i386/kernel/e820.c === --- linux-2.6.orig/arch/i386/kernel/e820.c 2007-07-27 21:34:36.0 +0200 +++ linux-2.6/arch/i386/kernel/e820.c 2007-07-29 18:49:05.0 +0200 @@ -321,7 +321,7 @@ static int __init request_standard_resou subsys_initcall(request_standard_resources); -#if defined(CONFIG_PM) defined(CONFIG_SOFTWARE_SUSPEND) +#if defined(CONFIG_PM) defined(CONFIG_HIBERNATION) /** * e820_mark_nosave_regions - Find the ranges of physical addresses that do not * correspond to e820 RAM areas and mark the corresponding pages as nosave for Index: linux-2.6/arch/i386/mm/init.c === --- linux-2.6.orig/arch/i386/mm/init.c 2007-07-27 21:34:36.0 +0200 +++ linux-2.6/arch/i386/mm/init.c 2007-07-29 18:49:05.0 +0200 @@ -432,7 +432,7 @@ static void __init pagetable_init (void) paravirt_pagetable_setup_done(pgd_base); } -#if defined(CONFIG_SOFTWARE_SUSPEND) || defined(CONFIG_ACPI) +#if defined(CONFIG_HIBERNATION) || defined(CONFIG_ACPI) /* * Swap suspend friends need this for resume because things like the intel-agp * driver might have split up a kernel 4MB mapping. Index: linux-2.6/arch/i386/power/Makefile === --- linux-2.6.orig/arch/i386/power/Makefile 2007-05-10 21:34:50.0 +0200 +++ linux-2.6/arch/i386/power/Makefile 2007-07-29 18:49:05.0 +0200 @@ -1,2 +1,2 @@ obj-$(CONFIG_PM) += cpu.o -obj-$(CONFIG_SOFTWARE_SUSPEND) += swsusp.o suspend.o +obj-$(CONFIG_HIBERNATION) += swsusp.o suspend.o Index: linux-2.6/arch/powerpc/Kconfig.debug === --- linux-2.6.orig/arch/powerpc/Kconfig.debug 2007-07-27 21:34:36.0 +0200 +++ linux-2.6/arch/powerpc/Kconfig.debug2007-07-29 18:49:05.0 +0200 @@ -20,7 +20,7 @@ config DEBUG_STACK_USAGE config DEBUG_PAGEALLOC
Re: [PATCH 2/2] Introduce CONFIG_SUSPEND
On Sunday, 29 July 2007 23:18, Adrian Bunk wrote: On Sun, Jul 29, 2007 at 11:17:20PM +0200, Rafael J. Wysocki wrote: On Sunday, 29 July 2007 22:40, Adrian Bunk wrote: On Sun, Jul 29, 2007 at 02:38:05PM +0200, Rafael J. Wysocki wrote: ... +config SUSPEND + bool Suspend Suspend to RAM Not only. This also includes standby. Whatever it includes - please tell it to the user in the prompt. Technical issues are important, but it's often forgotten how many problems people run into because the description of a kconfig option could have been better. Sure. Please see the updated patch I've just sent. :-) Greetings, Rafael - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] use mutex instead of semaphore in several drivers
This patchset converts semaphores that are used as mutexes to the mutex API in the following drivers/code: Host AP driver OnStream SCSI Tape driver SCSI Tape driver ISDN subsystem common functions DVB frontend tuning interface -- Matthias Kaehlcke Linux Application Developer Barcelona Representation of the world, like the world itself, is the work of men; they describe it from their own point of view, which they confuse with the absolute truth (Simone de Beauvoir) .''`. using free software / Debian GNU/Linux | http://debian.org : :' : `. `'` gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ppc: chipsfb.c build fix for CONFIG_PM
This patch fixes the following build error on powerpc: CC drivers/video/chipsfb.o drivers/video/chipsfb.c: In function 'chipsfb_pci_suspend': drivers/video/chipsfb.c:461: error: 'PM_SUSPEND_MEM' undeclared (first use in this function) drivers/video/chipsfb.c:461: error: (Each undeclared identifier is reported only once drivers/video/chipsfb.c:461: error: for each function it appears in.) make[2]: *** [drivers/video/chipsfb.o] Blad 1 make[1]: *** [drivers/video] Blad 2 make: *** [drivers] Blad 2 Already fixed in the right way. Please see: http://www.mail-archive.com/[EMAIL PROTECTED]/msg22171.html Ah... ok. Didn't see that. Thanks, Mariusz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] Use mutex instead of semaphore in the Host AP driver
The Host AP driver uses a semaphore as mutex. Use the mutex API
instead of the (binary) semaphore.
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
--
- res = down_interruptible(local-rid_bap_sem);
+ res = mutex_lock_interruptible(local-rid_bap_mtx);
if (res)
return res;
@@ -834,7 +834,7 @@ static int hfa384x_get_rid(struct net_device *dev, u16 rid,
void *buf, int len,
printk(KERN_DEBUG %s: hfa384x_get_rid: CMDCODE_ACCESS failed
(res=%d, rid=%04x, len=%d)\n,
dev-name, res, rid, len);
- up(local-rid_bap_sem);
+ mutex_unlock(local-rid_bap_mtx);
return res;
}
@@ -861,7 +861,7 @@ static int hfa384x_get_rid(struct net_device *dev, u16 rid,
void *buf, int len,
res = hfa384x_from_bap(dev, BAP0, buf, len);
spin_unlock_bh(local-baplock);
- up(local-rid_bap_sem);
+ mutex_unlock(local-rid_bap_mtx);
if (res) {
if (res != -ENODATA)
@@ -902,7 +902,7 @@ static int hfa384x_set_rid(struct net_device *dev, u16 rid,
void *buf, int len)
/* RID len in words and +1 for rec.rid */
rec.len = cpu_to_le16(len / 2 + len % 2 + 1);
- res = down_interruptible(local-rid_bap_sem);
+ res = mutex_lock_interruptible(local-rid_bap_mtx);
if (res)
return res;
@@ -917,12 +917,12 @@ static int hfa384x_set_rid(struct net_device *dev, u16
rid, void *buf, int len)
if (res) {
printk(KERN_DEBUG %s: hfa384x_set_rid (rid=%04x, len=%d) -
failed - res=%d\n, dev-name, rid, len, res);
- up(local-rid_bap_sem);
+ mutex_unlock(local-rid_bap_mtx);
return res;
}
res = hfa384x_cmd(dev, HFA384X_CMDCODE_ACCESS_WRITE, rid, NULL, NULL);
- up(local-rid_bap_sem);
+ mutex_unlock(local-rid_bap_mtx);
if (res) {
printk(KERN_DEBUG %s: hfa384x_set_rid: CMDCODE_ACCESS_WRITE
@@ -3171,7 +3171,7 @@ prism2_init_local_data(struct prism2_helper_functions
*funcs, int card_idx,
spin_lock_init(local-cmdlock);
spin_lock_init(local-baplock);
spin_lock_init(local-lock);
- init_MUTEX(local-rid_bap_sem);
+ mutex_init(local-rid_bap_mtx);
if (card_idx 0 || card_idx = MAX_PARM_DEVICES)
card_idx = 0;
diff --git a/drivers/net/wireless/hostap/hostap_wlan.h
b/drivers/net/wireless/hostap/hostap_wlan.h
index 87a54aa..a42325c 100644
--- a/drivers/net/wireless/hostap/hostap_wlan.h
+++ b/drivers/net/wireless/hostap/hostap_wlan.h
@@ -3,6 +3,7 @@
#include linux/wireless.h
#include linux/netdevice.h
+#include linux/mutex.h
#include net/iw_handler.h
#include hostap_config.h
@@ -641,7 +642,7 @@ struct local_info {
* when removing entries from the list.
* TX and RX paths can use read lock. */
spinlock_t cmdlock, baplock, lock;
- struct semaphore rid_bap_sem;
+ struct mutex rid_bap_mtx;
u16 infofid; /* MAC buffer id for info frame */
/* txfid, intransmitfid, next_txtid, and next_alloc are protected by
* txfidlock */
--
Matthias Kaehlcke
Linux Application Developer
Barcelona
Si deseas mantener tu libertad, debes estar preparado para defenderla
(Richard Stallman)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Introduce CONFIG_SUSPEND
On Sun, 2007-07-29 at 23:36 +0200, Rafael J. Wysocki wrote: On Sunday, 29 July 2007 23:18, Adrian Bunk wrote: On Sun, Jul 29, 2007 at 11:17:20PM +0200, Rafael J. Wysocki wrote: On Sunday, 29 July 2007 22:40, Adrian Bunk wrote: On Sun, Jul 29, 2007 at 02:38:05PM +0200, Rafael J. Wysocki wrote: ... +config SUSPEND + bool Suspend Suspend to RAM Not only. This also includes standby. Whatever it includes - please tell it to the user in the prompt. Technical issues are important, but it's often forgotten how many problems people run into because the description of a kconfig option could have been better. Sure. Please see the updated patch I've just sent. :-) So are you guys using: standby = idle state, ~0.5 seconds suspend = sleep to ram, ~10 seconds hibernate = sleep to disk, ~30 seconds If so - you rock. This is the common nomenclature I've been pushing for a few months now in GNOME, KDE and general userspace. I've written up a spec here: http://cvs.gnome.org/viewcvs/*checkout*/gnome-power-manager/docs/sleep-names.html Richard. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] Use mutex instead of semaphore in the OnStream SCSI Tape driver
The OnStream SCSI Tape driver uses a semaphore as mutex. Use the mutex
API instead of the (binary) semaphore.
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
--
diff --git a/drivers/scsi/osst.c b/drivers/scsi/osst.c
index 08060fb..0e2452c 100644
--- a/drivers/scsi/osst.c
+++ b/drivers/scsi/osst.c
@@ -3298,7 +3298,7 @@ static ssize_t osst_write(struct file * filp, const char
__user * buf, size_t co
char* name = tape_name(STp);
- if (down_interruptible(STp-lock))
+ if (mutex_lock_interruptible(STp-lock))
return (-ERESTARTSYS);
/*
@@ -3600,7 +3600,7 @@ if (SRpnt) printk(KERN_ERR %s:A: Not supposed to have
SRpnt at line %d\n, name
out:
if (SRpnt != NULL) osst_release_request(SRpnt);
- up(STp-lock);
+ mutex_unlock(STp-lock);
return retval;
}
@@ -3619,7 +3619,7 @@ static ssize_t osst_read(struct file * filp, char __user
* buf, size_t count, lo
char* name = tape_name(STp);
- if (down_interruptible(STp-lock))
+ if (mutex_lock_interruptible(STp-lock))
return (-ERESTARTSYS);
/*
@@ -3785,7 +3785,7 @@ static ssize_t osst_read(struct file * filp, char __user
* buf, size_t count, lo
out:
if (SRpnt != NULL) osst_release_request(SRpnt);
- up(STp-lock);
+ mutex_unlock(STp-lock);
return retval;
}
@@ -4852,7 +4852,7 @@ static int osst_ioctl(struct inode * inode,struct file *
file,
char* name = tape_name(STp);
void__user * p = (void __user *)arg;
- if (down_interruptible(STp-lock))
+ if (mutex_lock_interruptible(STp-lock))
return -ERESTARTSYS;
#if DEBUG
@@ -5163,14 +5163,14 @@ static int osst_ioctl(struct inode * inode,struct file
* file,
}
if (SRpnt) osst_release_request(SRpnt);
- up(STp-lock);
+ mutex_unlock(STp-lock);
return scsi_ioctl(STp-device, cmd_in, p);
out:
if (SRpnt) osst_release_request(SRpnt);
- up(STp-lock);
+ mutex_unlock(STp-lock);
return retval;
}
@@ -5866,7 +5866,7 @@ static int osst_probe(struct device *dev)
tpnt-modes[2].defined = 1;
tpnt-density_changed = tpnt-compression_changed =
tpnt-blksize_changed = 0;
- init_MUTEX(tpnt-lock);
+ mutex_init(tpnt-lock);
osst_nr_dev++;
write_unlock(os_scsi_tapes_lock);
diff --git a/drivers/scsi/osst.h b/drivers/scsi/osst.h
index 2cc7b5a..5aa2274 100644
--- a/drivers/scsi/osst.h
+++ b/drivers/scsi/osst.h
@@ -4,6 +4,7 @@
#include asm/byteorder.h
#include linux/completion.h
+#include linux/mutex.h
/* FIXME - rename and use the following two types or delete them!
* and the types really should go to st.h anyway...
@@ -532,7 +533,7 @@ struct osst_tape {
struct scsi_driver *driver;
unsigned capacity;
struct scsi_device *device;
- struct semaphore lock; /* for serialization */
+ struct mutex lock; /* for serialization */
struct completion wait; /* for SCSI commands */
struct osst_buffer * buffer;
--
Matthias Kaehlcke
Linux Application Developer
Barcelona
Don't walk behind me, I may not lead
Don't walk in front of me, I may not follow
Just walk beside me and be my friend
(Albert Camus)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] Use mutex instead of semaphore in the SCSI Tape driver
The SCSI Tape driver uses a semaphore as mutex. Use the mutex API
instead of the (binary) semaphore.
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
--
diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c
index a4f7b84..73c44cb 100644
--- a/drivers/scsi/st.c
+++ b/drivers/scsi/st.c
@@ -1485,7 +1485,7 @@ st_write(struct file *filp, const char __user *buf,
size_t count, loff_t * ppos)
struct st_buffer *STbp;
char *name = tape_name(STp);
- if (down_interruptible(STp-lock))
+ if (mutex_lock_interruptible(STp-lock))
return -ERESTARTSYS;
retval = rw_checks(STp, filp, count);
@@ -1736,7 +1736,7 @@ st_write(struct file *filp, const char __user *buf,
size_t count, loff_t * ppos)
if (SRpnt != NULL)
st_release_request(SRpnt);
release_buffering(STp, 0);
- up(STp-lock);
+ mutex_unlock(STp-lock);
return retval;
}
@@ -1942,7 +1942,7 @@ st_read(struct file *filp, char __user *buf, size_t
count, loff_t * ppos)
struct st_buffer *STbp = STp-buffer;
DEB( char *name = tape_name(STp); )
- if (down_interruptible(STp-lock))
+ if (mutex_lock_interruptible(STp-lock))
return -ERESTARTSYS;
retval = rw_checks(STp, filp, count);
@@ -2069,7 +2069,7 @@ st_read(struct file *filp, char __user *buf, size_t
count, loff_t * ppos)
release_buffering(STp, 1);
STbp-buffer_bytes = 0;
}
- up(STp-lock);
+ mutex_unlock(STp-lock);
return retval;
}
@@ -3226,7 +3226,7 @@ static int st_ioctl(struct inode *inode, struct file
*file,
char *name = tape_name(STp);
void __user *p = (void __user *)arg;
- if (down_interruptible(STp-lock))
+ if (mutex_lock_interruptible(STp-lock))
return -ERESTARTSYS;
DEB(
@@ -3537,7 +3537,7 @@ static int st_ioctl(struct inode *inode, struct file
*file,
retval = (-EFAULT);
goto out;
}
- up(STp-lock);
+ mutex_unlock(STp-lock);
switch (cmd_in) {
case SCSI_IOCTL_GET_IDLUN:
case SCSI_IOCTL_GET_BUS_NUMBER:
@@ -3563,7 +3563,7 @@ static int st_ioctl(struct inode *inode, struct file
*file,
return retval;
out:
- up(STp-lock);
+ mutex_unlock(STp-lock);
return retval;
}
@@ -4029,7 +4029,7 @@ static int st_probe(struct device *dev)
tpnt-density_changed = tpnt-compression_changed =
tpnt-blksize_changed = 0;
- init_MUTEX(tpnt-lock);
+ mutex_init(tpnt-lock);
st_nr_dev++;
write_unlock(st_dev_arr_lock);
diff --git a/drivers/scsi/st.h b/drivers/scsi/st.h
index 50f3deb..6c80757 100644
--- a/drivers/scsi/st.h
+++ b/drivers/scsi/st.h
@@ -3,6 +3,7 @@
#define _ST_H
#include linux/completion.h
+#include linux/mutex.h
#include linux/kref.h
#include scsi/scsi_cmnd.h
@@ -98,7 +99,7 @@ struct st_partstat {
struct scsi_tape {
struct scsi_driver *driver;
struct scsi_device *device;
- struct semaphore lock; /* For serialization */
+ struct mutex lock; /* For serialization */
struct completion wait; /* For SCSI commands */
struct st_buffer *buffer;
--
Matthias Kaehlcke
Linux Application Developer
Barcelona
Ma patrie est où je suis, où personne ne me dérange, où personne
ne me demande que je suis, d'où je viens et ce que je fais
(B. Traven)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] Use mutex instead of semaphore in ISDN subsystem common functions
The ISDN subsystem common functions use a semaphore as mutex. Use the
mutex API instead of the (binary) semaphore.
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
--
diff --git a/drivers/isdn/i4l/isdn_common.c b/drivers/isdn/i4l/isdn_common.c
index c97330b..a5d3db4 100644
--- a/drivers/isdn/i4l/isdn_common.c
+++ b/drivers/isdn/i4l/isdn_common.c
@@ -1364,7 +1364,7 @@ isdn_ioctl(struct inode *inode, struct file *file, uint
cmd, ulong arg)
} else {
s = NULL;
}
- ret = down_interruptible(dev-sem);
+ ret = mutex_lock_interruptible(dev-mtx);
if( ret ) return ret;
if ((s = isdn_net_new(s, NULL))) {
if (copy_to_user(argp, s, strlen(s) +
1)){
@@ -1374,7 +1374,7 @@ isdn_ioctl(struct inode *inode, struct file *file, uint
cmd, ulong arg)
}
} else
ret = -ENODEV;
- up(dev-sem);
+ mutex_unlock(dev-mtx);
return ret;
case IIOCNETASL:
/* Add a slave to a network-interface */
@@ -1383,7 +1383,7 @@ isdn_ioctl(struct inode *inode, struct file *file, uint
cmd, ulong arg)
return -EFAULT;
} else
return -EINVAL;
- ret = down_interruptible(dev-sem);
+ ret = mutex_lock_interruptible(dev-mtx);
if( ret ) return ret;
if ((s = isdn_net_newslave(bname))) {
if (copy_to_user(argp, s, strlen(s) +
1)){
@@ -1393,17 +1393,17 @@ isdn_ioctl(struct inode *inode, struct file *file, uint
cmd, ulong arg)
}
} else
ret = -ENODEV;
- up(dev-sem);
+ mutex_unlock(dev-mtx);
return ret;
case IIOCNETDIF:
/* Delete a network-interface */
if (arg) {
if (copy_from_user(name, argp,
sizeof(name)))
return -EFAULT;
- ret = down_interruptible(dev-sem);
+ ret =
mutex_lock_interruptible(dev-mtx);
if( ret ) return ret;
ret = isdn_net_rm(name);
- up(dev-sem);
+ mutex_unlock(dev-mtx);
return ret;
} else
return -EINVAL;
@@ -1432,10 +1432,10 @@ isdn_ioctl(struct inode *inode, struct file *file, uint
cmd, ulong arg)
if (arg) {
if (copy_from_user(phone, argp,
sizeof(phone)))
return -EFAULT;
- ret = down_interruptible(dev-sem);
+ ret =
mutex_lock_interruptible(dev-mtx);
if( ret ) return ret;
ret = isdn_net_addphone(phone);
- up(dev-sem);
+ mutex_unlock(dev-mtx);
return ret;
} else
return -EINVAL;
@@ -1444,10 +1444,10 @@ isdn_ioctl(struct inode *inode, struct file *file, uint
cmd, ulong arg)
if (arg) {
if (copy_from_user(phone, argp,
sizeof(phone)))
return -EFAULT;
- ret = down_interruptible(dev-sem);
+ ret =
mutex_lock_interruptible(dev-mtx);
if( ret ) return ret;
ret = isdn_net_getphones(phone, argp);
- up(dev-sem);
+ mutex_unlock(dev-mtx);
return ret;
} else
return -EINVAL;
@@ -1456,10 +1456,10 @@ isdn_ioctl(struct inode *inode, struct
[PATCH 5/5] Use mutex instead of semaphore in the DVB frontend tuning interface
The DVB frontend tuning interface uses a semaphore as mutex. Use the
mutex API instead of the (binary) semaphore.
Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED]
--
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index b6c7f66..e35dd17 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -138,7 +138,7 @@ static void dvb_frontend_add_event(struct dvb_frontend *fe,
fe_status_t status)
dprintk (%s\n, __FUNCTION__);
- if (down_interruptible (events-sem))
+ if (mutex_lock_interruptible (events-mtx))
return;
wp = (events-eventw + 1) % MAX_EVENT;
@@ -159,7 +159,7 @@ static void dvb_frontend_add_event(struct dvb_frontend *fe,
fe_status_t status)
events-eventw = wp;
- up (events-sem);
+ mutex_unlock(events-mtx);
e-status = status;
@@ -197,7 +197,7 @@ static int dvb_frontend_get_event(struct dvb_frontend *fe,
return ret;
}
- if (down_interruptible (events-sem))
+ if (mutex_lock_interruptible (events-mtx))
return -ERESTARTSYS;
memcpy (event, events-events[events-eventr],
@@ -205,7 +205,7 @@ static int dvb_frontend_get_event(struct dvb_frontend *fe,
events-eventr = (events-eventr + 1) % MAX_EVENT;
- up (events-sem);
+ mutex_unlock(events-mtx);
return 0;
}
@@ -1080,7 +1080,7 @@ int dvb_register_frontend(struct dvb_adapter* dvb,
init_MUTEX (fepriv-sem);
init_waitqueue_head (fepriv-wait_queue);
init_waitqueue_head (fepriv-events.wait_queue);
- init_MUTEX (fepriv-events.sem);
+ mutex_init(fepriv-events.mtx);
fe-dvb = dvb;
fepriv-inversion = INVERSION_OFF;
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h
b/drivers/media/dvb/dvb-core/dvb_frontend.h
index a770a87..f95de63 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -35,6 +35,7 @@
#include linux/module.h
#include linux/errno.h
#include linux/delay.h
+#include linux/mutex.h
#include linux/dvb/frontend.h
@@ -142,7 +143,7 @@ struct dvb_fe_events {
int eventr;
int overflow;
wait_queue_head_t wait_queue;
- struct semaphore sem;
+ struct mutex mtx;
};
struct dvb_frontend {
--
Matthias Kaehlcke
Linux Application Developer
Barcelona
El camino se hace al andar
(Antonio Machado)
.''`.
using free software / Debian GNU/Linux | http://debian.org : :' :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4 `-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm26: remove duplicate include of linux/module.h
Hi, This patch removes the duplicate inclusion of linux/module.h from arm26. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- arch/arm26/kernel/armksyms.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/arm26/kernel/armksyms.c b/arch/arm26/kernel/armksyms.c index fe1e3ce..0ddda4d 100644 --- a/arch/arm26/kernel/armksyms.c +++ b/arch/arm26/kernel/armksyms.c @@ -8,7 +8,6 @@ * published by the Free Software Foundation. */ #include linux/module.h -#include linux/module.h #include linux/user.h #include linux/string.h #include linux/fs.h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: nvidia installer DIW with 2.6.23-rc1
On Jul 29 2007 14:12, Mike Houston wrote:
I know it's off topic here, but this will help people.
When that happens, check their forum. Chances are someone has
posted, and the nvidia developers have answered with a patch, code
snippet, quick instructions to get it to compile or advice to try a
beta driver if applicable.
At least for solidarity for those stuck with it, patch below.
To build nvidia kernel module failed in
kernel-2.6.23-0.41.rc0.git14.fc8
http://www.nvnews.net/vbulletin/showthread.php?t=95296
Jan
===
---
nv-linux.h |2 +-
nv.c |6 ++
2 files changed, 3 insertions(+), 5 deletions(-)
Index: nv_kernel-100.14.11/nv-linux.h
===
--- nv_kernel-100.14.11.orig/nv-linux.h
+++ nv_kernel-100.14.11/nv-linux.h
@@ -533,7 +533,7 @@ static inline unsigned long nv_virt_to_p
#define NV_KMEM_CACHE_CREATE(kmem_cache, name, type)\
{ \
kmem_cache = kmem_cache_create(name, sizeof(type), \
-0, 0, NULL, NULL); \
+0, 0, NULL); \
}
#define NV_KMEM_CACHE_DESTROY(kmem_cache) \
Index: nv_kernel-100.14.11/nv.c
===
--- nv_kernel-100.14.11.orig/nv.c
+++ nv_kernel-100.14.11/nv.c
@@ -1566,8 +1566,7 @@ failed:
if (apm_nv_dev[i] != NULL) pm_unregister(apm_nv_dev[i]);
#endif
-if (unregister_chrdev(nv_major, nvidia) 0)
-nv_printf(NV_DBG_ERRORS, NVRM: unregister nv chrdev failed\n);
+unregister_chrdev(nv_major, nvidia);
for (i = 0; i num_nv_devices; i++)
{
@@ -1598,8 +1597,7 @@ static void __exit nvidia_exit_module(vo
nv_printf(NV_DBG_INFO, NVRM: nvidia_exit_module\n);
-if (unregister_chrdev(nv_major, nvidia) 0)
-nv_printf(NV_DBG_ERRORS, NVRM: unregister nv chrdev failed\n);
+unregister_chrdev(nv_major, nvidia);
for (i = 0; i num_nv_devices; i++)
{
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Reading a bad sector does not report failure as 'read error' but hangs PC with 'Machine Check Exception'
hangs. If I try it after a reboot with 'mcelog --k8 --ascii' or whatever parameter, there is no output at You could type error back in from the email ? Ok I copied it into the tool, it gives me: CPU 0 4 northbridge TSC b7d4a144d0 Northbridge ECC error ECC syndrome = 0 STATUS 0 MCGSTATUS 4 This is a bit strange because I repeatedly tested the RAM yesterday and it gives no problems. And even more interesting: the error occurs at a reproducible moment: when reading the bad sector from the Seagate harddisk. And with an older kernel I was able to just copy all stuff from the drive using dd_rescue... I do not have ECC RAM in my PC by the way. Isn't it strange to say that the controller does something bad if there is just a bad sector on the drive that is reported and handled correctly in an older kernel Not really. Its very strange it gives an MCE at all but this is a known failure path (and should be a fixed known failure path) for the Nvidia SATA. So how to proceed in tackling this problem now? Is there anything I can do to (help you guys ;)) fix it? At this moment it unfortunately does not look to me as a fixed failure path... Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos more. http://mobile.yahoo.com/go?refer=1GNXIC - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ck] Re: Linus 2.6.23-rc1
On Sun, Jul 29, 2007 at 10:25:42PM +0200, Mike Galbraith wrote: Absolutely. Con quit for his own reasons. Given that Con himself has said that CFS was _not_ why he quite, please discard this... bait. Anyone who's name isn't Con Kolivas, who pretends to speak for him is at the very least overstepping his bounds, and that is being _very_ generous. I know Con personally and I completely identify with his circumstance. This is precisely why he quit the project because of a generally perceived ignorance and disconnect from end users. Since you side with Ingo on many issues politically, this response from you is no surprise. Again, the choices that have been currently made with CFS basically locks him out of development. If you don't understand that, then you don't understand the technical issues he's struggled to pursue. He has a large following which is why this has been a repeated and issue between end users of his tree and a number of current Linux kernel developers. bill - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Blackfin: Remove duplicate inclusion of linux/irq.h
Hi, arch/blackfin/mach-bf548/boards/ezkit.c includes linux/irq.h twice. This patch removes the duplicate. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- arch/blackfin/mach-bf548/boards/ezkit.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/blackfin/mach-bf548/boards/ezkit.c b/arch/blackfin/mach-bf548/boards/ezkit.c index 96ad95f..9e00ada 100644 --- a/arch/blackfin/mach-bf548/boards/ezkit.c +++ b/arch/blackfin/mach-bf548/boards/ezkit.c @@ -35,7 +35,6 @@ #include linux/spi/spi.h #include linux/spi/flash.h #include linux/irq.h -#include linux/irq.h #include linux/interrupt.h #include asm/bfin5xx_spi.h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm26: remove duplicate include of linux/module.h
On Sun, 29 Jul 2007, Jesper Juhl wrote: Hi, This patch removes the duplicate inclusion of linux/module.h from arm26. is it really worth doing any cleanup of arm26 given the recent discussion of tossing it entirely? rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] m68knommu: Get rid of duplicate include
Hi, This patch removes the duplicate inclusion of asm/irq.h from arch/m68knommu/platform/5206e/config.c Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- arch/m68knommu/platform/5206e/config.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/m68knommu/platform/5206e/config.c b/arch/m68knommu/platform/5206e/config.c index 4ab614f..425703f 100644 --- a/arch/m68knommu/platform/5206e/config.c +++ b/arch/m68knommu/platform/5206e/config.c @@ -20,7 +20,6 @@ #include asm/mcftimer.h #include asm/mcfsim.h #include asm/mcfdma.h -#include asm/irq.h /***/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] core_pattern: allow passing of arguments to user mode helper when core_pattern is a pipe
On Sun, Jul 29, 2007 at 09:03:29PM +0800, Eugene Teo wrote:
Neil Horman wrote:
[...]
+ /* core limit size */
+ case 'c':
+ rc = snprintf(out_ptr, out_end - out_ptr,
+ %lu,
current-signal-rlim[RLIMIT_CORE].rlim_cur);
Trailing space.
[...]
- if(call_usermodehelper_pipe(corename+1, NULL, NULL, file)) {
+ if(call_usermodehelper_pipe(corename+1, helper_argv, NULL,
file)) {
^
Use tabs, and a missing space after '('.
I think your reader is screwing up the patch. The version that I sent, which I
have here, shows that as all tabs, no spaces.
As for the '(', yeah, that looks like its been there for awhile. I'll clean it
all up when I address macro expansion, as per the conversation Martin and I have
been holding.
Regards
Neil
Eugene
--
/***
*Neil Horman
*Software Engineer
*Red Hat, Inc.
[EMAIL PROTECTED]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] Power Management framework proposal
sorry for the delay in responding On Wed, 25 Jul 2007, Jerome Glisse wrote: [EMAIL PROTECTED] wrote: On Wed, 25 Jul 2007, Jerome Glisse wrote: On 7/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: For instance on graphics card you could do the following (maybe more): -change GPU clock -change memory clock -disable part of engine -disable unit i truly don't think you can make a common interface for all this, more over there might be constraint on how you can change things (GPU memory clock might need to follow a given ratio). So you definitely need knowledge in the user space program to handle this. sure you can, just enumerate all the options the driver writer wants to offer as options. yes this could be a lengthy list, so what? My point was that your interface by trying to fit square pegs into round hole will fail to expose all subtility of each device which might in the end bring to wrong power management decision. So i believe we can't sum up power management to list of mode whose attribute are power consumption capacity. it's possible (which is part of the reason I started the thread), but so far there hasn't been anything identified that is a really bad fit. Tell me how i do this in your model: GPU/VRAM memory clock change power consumption of the card and the power consumption is often not a trivial function of both of this parameters (i even here simplify the problem by omitting pipeline shutdown). So how with two different separate mode list (one for GPU speed another one for VRAM speed) can you provide consumption information while this consumption depends on the others settings. Then if you give as a solution to make only one list you end up with a more bigger list than previously needed (nrGPUmodes * nrVRAMmodes) do you expect the user to go through a lengthy list to find what he wants ? (remember that we will have to add pipeline power off, pll tweaking or many others way of saving power on such card). yes I expect that it would be a large list in some conditions. but one purpose of this API is to make these options able to be discovered by software. right now nothing could be done at all without driver specific knowledge. even a lengthy list can be better then that. presenting the list to the user directly is a last resort, only for experimentation or when nothing else wants to deal with devices of that type. with a description field (which I didn't include initially, but seems obviously needed now) it should be fairly easy to create descriptions that let the software see that there are multiple factors involved. So by choosing this power consumption as a unit of measure you end up in non trivial case. There is also the question of overclocking if the driver supports overclocking then list it in the modes (nothing says that % capacity couldn't go over 100% for example) , and other points already identified where unfortunately a global design such as your proposal does not seems to fit properly: local power decision (ethernet, wifi card, ... can power down them self is they are doing nothings but the place where you can know this is the driver) if they power themselves down with no notice to the system they should power themselves back up with no need for the rest of the system to tell them either. so this ca either be ignored or presented as a mode between off and on that enables this behavior. , there is also the child/parent relation, how to estimate power usage (on some configuration one device consumption can be marginal toward all others things while on other this same device can be the most power hungry device)... I see all this as bad fit. ahh, here we see a disconnect. I was not intending for the power field to be that exact. there are just too many variables. for example: even for a cpu, the power used isn't exactly tied to the clock speed and voltage, the mix of commands that the cpu is running will affect the power it eats, sometimes by a significant amount. it was intended to be an ordering factor and approximate the power used so that things could make a peroformance/power tradeoff with a good chance of makeing a reasonable choice. it's not intended for 'make this laptop use 24w of power instead of 25w of power' And there is no way to design an abstraction given that all hw we will have to deal with are too much different and do not follow any standard things (beside ACPI there is other way to save power brightness, gpu/memory clock, pll, ...) so i don't see how one might give a common view of things which are fundamentally different in how they affect consumption (same end result with many different paths leading to it). so you are saying that the power management software must know the details of each and every driver, and if you add a new driver you must change the power management software
[PATCH] pci_ids: additional NFORCE MCP61 devices - (resend)
This patch adds the following 7 Nforce devices: - LPC Bridge (MCP61_LPC_BRG) - Memory Controller (MCP61_MC1) - High Definition Audio (MCP61_HDA) - USB Controller (MCP61_OHCI) - USB Controller (MCP61_EHCI) - PCI bridge (MCP61_PCI_BRG) - Memory Controller (MCP61_MC2) to the pci_ids.h file. Signed-off-by: Indrek Kruusa [EMAIL PROTECTED] lspci output on Gigabyte GA-M61SME-S2 (GF6100/NF405) can be seen from [1],[2] thanks, Indrek __ [1] http://www.hot.ee/bzmeez/nv_mcp61_lspci-n.txt [2] http://www.hot.ee/bzmeez/nv_mcp61_lspci-vv.txt diff -pur linux-2.6.git1/include/linux/pci_ids.h linux-2.6_p/include/linux/pci_ids.h --- linux-2.6.git1/include/linux/pci_ids.h 2007-07-29 20:48:28.0 +0300 +++ linux-2.6_p/include/linux/pci_ids.h 2007-07-29 20:54:21.0 +0300 @@ -1206,13 +1206,20 @@ #define PCI_DEVICE_ID_NVIDIA_QUADRO_FX_1100 0x034E #define PCI_DEVICE_ID_NVIDIA_NVENET_14 0x0372 #define PCI_DEVICE_ID_NVIDIA_NVENET_15 0x0373 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_LPC_BRG 0x03E0 #define PCI_DEVICE_ID_NVIDIA_NVENET_16 0x03E5 #define PCI_DEVICE_ID_NVIDIA_NVENET_17 0x03E6 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA 0x03E7 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_MC1 0x03EA #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SMBUS0x03EB #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_IDE 0x03EC #define PCI_DEVICE_ID_NVIDIA_NVENET_18 0x03EE #define PCI_DEVICE_ID_NVIDIA_NVENET_19 0x03EF +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_HDA 0x03F0 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_OHCI 0x03F1 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_EHCI 0x03F2 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_PCI_BRG 0x03F3 +#define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_MC2 0x03F5 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA2 0x03F6 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP61_SATA3 0x03F7 #define PCI_DEVICE_ID_NVIDIA_NFORCE_MCP65_SMBUS0x0446 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mips: remove some duplicate includes
Hi, This patch removes some duplicate includes from arch/mips/ Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- arch/mips/kernel/signal32.c |1 - arch/mips/lemote/lm2e/irq.c |1 - arch/mips/mipssim/sim_setup.c |1 - 3 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index 486b8e5..64b612a 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -18,7 +18,6 @@ #include linux/errno.h #include linux/wait.h #include linux/ptrace.h -#include linux/compat.h #include linux/suspend.h #include linux/compiler.h #include linux/uaccess.h diff --git a/arch/mips/lemote/lm2e/irq.c b/arch/mips/lemote/lm2e/irq.c index 05693bc..3e0b7be 100644 --- a/arch/mips/lemote/lm2e/irq.c +++ b/arch/mips/lemote/lm2e/irq.c @@ -25,7 +25,6 @@ */ #include linux/delay.h #include linux/io.h -#include linux/irq.h #include linux/init.h #include linux/interrupt.h #include linux/irq.h diff --git a/arch/mips/mipssim/sim_setup.c b/arch/mips/mipssim/sim_setup.c index 17819b5..d012719 100644 --- a/arch/mips/mipssim/sim_setup.c +++ b/arch/mips/mipssim/sim_setup.c @@ -22,7 +22,6 @@ #include linux/io.h #include linux/irq.h #include linux/ioport.h -#include linux/serial.h #include linux/tty.h #include linux/serial.h #include linux/serial_core.h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sparc32 not working:2.6.23-rc1 (git commit 1e4dcd22efa7d24f637ab2ea3a77dd65774eb005)
On Sun, 29 Jul 2007, Adrian Bunk wrote: On Sun, Jul 29, 2007 at 07:26:29PM +0100, Mark Fortescue wrote: ... I am going to try to cherry pick a set of commits to see if I can't get a better idear of where the memory corruption on sun4c is coming from. Build problems sue to the DMA changes make git bisecting un-usable untill I have found out which patches fix the DMA build issues. You have any known-good kernel? Boot back into this kernel for bisecting and compiling the kernels for bisecting there. As I said, bisecting does not work if you can't build the kernel because of un-defined symbols spanning most of the revisions you are interested in. I have isolated the revisions that do not build so I should be able to cerry pick a commit/commits that fixes the build issues. Once done, I will be able to investigate the original issue. If it were practical to do a build test on all supported platforms before submitting patches then this would not be so much of an issue but ... 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 from this list: send the line unsubscribe sparclinux in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Power Management framework proposal
On Fri, 27 Jul 2007, Pavel Machek wrote: Hi! example 1: a laptop screen mode capacity power description 000off 1 100 100full brightness 2 70 60half power to the backlight 3 50 35quarter power to the backlight 4 30 25eighth power to the backlight 55 10backlight off. example 2: a front-panel display on a server (no variable backlight control) mode capacity power description 0 00 off 1 100 100 backlight on 2 50 10 backlight off the problem is: the person who SETS these needs to know what they mean. that's what the description is for. this info can be provided by the driver as part of the list_modes() function. That's what /sys/class/backlight/ is for :-). yes it is, and each type of device is growing it's own, incompatible, interfaces for controlling things like this. I was aiming to do two things. 1. head this off and try and get a more common api 2. simplify the confusion that there is with multiple functions needing to be implemented during the suspend/resume cycle by chaning them from independant suspend-only functions to being just part of the device settings as someone who wrote (part of) a power policy manager; sorry but you take away information I need, and in addition the different API's are absolutely no big deal. assuming that nobody else chimes in to disagree with you I'll accept your judgement and drop the issue. Just for the record, I agree with Arjan here. oh well. sorry to take up everyone's time. David Lang - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/5] Use mutex instead of semaphore in the Host AP driver
On Sunday 29 July 2007 23:34, Matthias Kaehlcke wrote: The Host AP driver uses a semaphore as mutex. Use the mutex API instead of the (binary) semaphore. Signed-off-by: Matthias Kaehlcke [EMAIL PROTECTED] -- - res = down_interruptible(local-rid_bap_sem); + res = mutex_lock_interruptible(local-rid_bap_mtx); if (res) return res; @@ -902,7 +902,7 @@ static int hfa384x_set_rid(struct net_device *dev, u16 rid, void *buf, int len) /* RID len in words and +1 for rec.rid */ rec.len = cpu_to_le16(len / 2 + len % 2 + 1); - res = down_interruptible(local-rid_bap_sem); + res = mutex_lock_interruptible(local-rid_bap_mtx); if (res) return res; Is res returned to userspace? If yes, that's not right. On a interrupted mutex allocation you should return -ERESTARTSYS to userspace. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] Introduce CONFIG_SUSPEND
On Sunday, 29 July 2007 23:30, Richard Hughes wrote: On Sun, 2007-07-29 at 23:36 +0200, Rafael J. Wysocki wrote: On Sunday, 29 July 2007 23:18, Adrian Bunk wrote: On Sun, Jul 29, 2007 at 11:17:20PM +0200, Rafael J. Wysocki wrote: On Sunday, 29 July 2007 22:40, Adrian Bunk wrote: On Sun, Jul 29, 2007 at 02:38:05PM +0200, Rafael J. Wysocki wrote: ... +config SUSPEND + bool Suspend Suspend to RAM Not only. This also includes standby. Whatever it includes - please tell it to the user in the prompt. Technical issues are important, but it's often forgotten how many problems people run into because the description of a kconfig option could have been better. Sure. Please see the updated patch I've just sent. :-) So are you guys using: standby = idle state, ~0.5 seconds suspend = sleep to ram, ~10 seconds hibernate = sleep to disk, ~30 seconds Something like this, but suspend is not reserved as a name of specific state. The second state is usually referred to as suspend to RAM or STR and is denoted by mem in /sys/power/state, if implemented. Moreover, standby and mem are both entered using the same code path, so they may generally be referred to as suspend states. The times aren't strictly defined for mem and standby, too. The general rule is that the times for mem are greater then for standby and the power drawn in mem is smaller than the power drawn in standby, but the exact values will always depend on the platform. Apart from this, if the platform supports only one suspend state, it decides if that's mem or standby. On ACPI systems standby and mem correspond to the S1 and S3 sleep states, respectively. Greetings, Rafael -- Premature optimization is the root of all evil. - Donald Knuth - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Reading a bad sector does not report failure as 'read error' but hangs PC with 'Machine Check Exception'
Ok, I did actually not copy the coreret code in the mcelog, leaving me some errors about the Northbridge. If I do it again it gives me something else. I made 2 digital photo's of 2 lockups when it happened and this is the result of the tool, the TSC is different in both errors, the rest is the same: CPU 0 4 northbridge TSC b7d4a144d0 Northbridge Watchdog error bit57 = processor context corrupt bit61 = error uncorrected bus error 'generic participation, request timed out generic error mem transaction generic access, level generic' STATUS b2070f0f MCGSTATUS 4 This is not a software problem! CPU 0 4 northbridge TSC c4dd3a549f Northbridge Watchdog error bit57 = processor context corrupt bit61 = error uncorrected bus error 'generic participation, request timed out generic error mem transaction generic access, level generic' STATUS b2070f0f MCGSTATUS 4 This is not a software problem! It's a bit strange but if I copy the results from my first post I get the Northbridge error, perhaps because there is an 'enter' between the first line with the 'bank 4' and the 'b2070f0f' line. The mcelog tool handles this different from the error in 1 line. Regards, Hendrik Got a little couch potato? Check out fun summer activities for kids. http://search.yahoo.com/search?fr=oni_on_mailp=summer+activities+for+kidscs=bz - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] powerpc: clean out a bunch of duplicate includes
Hi, Here's a patch to clean out a bunch of duplicate includes from arch/powerpc/ Please consider for inclusion. Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- arch/powerpc/kernel/btext.c|1 - arch/powerpc/kernel/crash.c|1 - arch/powerpc/kernel/iommu.c|1 - arch/powerpc/kernel/prom.c |1 - arch/powerpc/kernel/time.c |1 - arch/powerpc/mm/hash_utils_64.c|1 - arch/powerpc/mm/hugetlbpage.c |3 --- arch/powerpc/mm/init_32.c |1 - arch/powerpc/mm/mem.c |1 - arch/powerpc/platforms/52xx/mpc52xx_pic.c |1 - arch/powerpc/platforms/chrp/setup.c|1 - arch/powerpc/platforms/chrp/smp.c |1 - arch/powerpc/platforms/iseries/setup.c |1 - arch/powerpc/platforms/powermac/low_i2c.c |1 - arch/powerpc/platforms/powermac/udbg_adb.c |1 - arch/powerpc/platforms/pseries/lpar.c |1 - 16 files changed, 0 insertions(+), 18 deletions(-) diff --git a/arch/powerpc/kernel/btext.c b/arch/powerpc/kernel/btext.c index e7b6846..3ef51fb 100644 --- a/arch/powerpc/kernel/btext.c +++ b/arch/powerpc/kernel/btext.c @@ -11,7 +11,6 @@ #include asm/sections.h #include asm/prom.h #include asm/btext.h -#include asm/prom.h #include asm/page.h #include asm/mmu.h #include asm/pgtable.h diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c index 37658ea..77c749a 100644 --- a/arch/powerpc/kernel/crash.c +++ b/arch/powerpc/kernel/crash.c @@ -24,7 +24,6 @@ #include linux/init.h #include linux/irq.h #include linux/types.h -#include linux/irq.h #include asm/processor.h #include asm/machdep.h diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c index c08ceca..e4ec6ee 100644 --- a/arch/powerpc/kernel/iommu.c +++ b/arch/powerpc/kernel/iommu.c @@ -30,7 +30,6 @@ #include linux/spinlock.h #include linux/string.h #include linux/dma-mapping.h -#include linux/init.h #include linux/bitops.h #include asm/io.h #include asm/prom.h diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c index a38197b..0028fe6 100644 --- a/arch/powerpc/kernel/prom.c +++ b/arch/powerpc/kernel/prom.c @@ -52,7 +52,6 @@ #include asm/pSeries_reconfig.h #include asm/pci-bridge.h #include asm/kexec.h -#include asm/system.h #ifdef DEBUG #define DBG(fmt...) printk(KERN_ERR fmt) diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index 727a669..c85d9b0 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -72,7 +72,6 @@ #include asm/iseries/it_lp_queue.h #include asm/iseries/hv_call_xm.h #endif -#include asm/smp.h /* keep track of when we need to update the rtc */ time_t last_rtc_update; diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c index bc7b0ce..c2bf404 100644 --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -49,7 +49,6 @@ #include asm/tlb.h #include asm/cacheflush.h #include asm/cputable.h -#include asm/abs_addr.h #include asm/sections.h #include asm/spu.h diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c index 4835f73..ba5f12a 100644 --- a/arch/powerpc/mm/hugetlbpage.c +++ b/arch/powerpc/mm/hugetlbpage.c @@ -22,11 +22,8 @@ #include asm/mmu_context.h #include asm/machdep.h #include asm/cputable.h -#include asm/tlb.h #include asm/spu.h -#include linux/sysctl.h - #define NUM_LOW_AREAS (0x1UL SID_SHIFT) #define NUM_HIGH_AREAS (PGTABLE_RANGE HTLB_AREA_SHIFT) diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c index e1f5ded..d65995a 100644 --- a/arch/powerpc/mm/init_32.c +++ b/arch/powerpc/mm/init_32.c @@ -41,7 +41,6 @@ #include asm/machdep.h #include asm/btext.h #include asm/tlb.h -#include asm/prom.h #include asm/lmb.h #include asm/sections.h diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index f0e7eed..32dcfc9 100644 --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -42,7 +42,6 @@ #include asm/machdep.h #include asm/btext.h #include asm/tlb.h -#include asm/prom.h #include asm/lmb.h #include asm/sections.h #include asm/vdso.h diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c b/arch/powerpc/platforms/52xx/mpc52xx_pic.c index fbfff95..8c464c5 100644 --- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c +++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c @@ -22,7 +22,6 @@ #include linux/init.h #include linux/sched.h #include linux/signal.h -#include linux/stddef.h #include linux/delay.h #include linux/irq.h #include linux/hardirq.h diff --git a/arch/powerpc/platforms/chrp/setup.c b/arch/powerpc/platforms/chrp/setup.c index 373de4c..dde5ef4 100644 --- a/arch/powerpc/platforms/chrp/setup.c +++ b/arch/powerpc/platforms/chrp/setup.c @@ -32,7 +32,6 @@ #include linux/seq_file.h #include linux/root_dev.h #include linux/initrd.h -#include linux/module.h #include linux/timer.h
[PATCH] ia64: Remove a few duplicate includes
(sorry about the duplicate mail, forgot a recipient first time) Hi, This patch removes a few duplicate includes from arch/ia64/ Please consider merging :-) Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- arch/ia64/ia32/sys_ia32.c |1 - arch/ia64/kernel/setup.c|1 - arch/ia64/sn/kernel/setup.c |1 - 3 files changed, 0 insertions(+), 3 deletions(-) diff --git a/arch/ia64/ia32/sys_ia32.c b/arch/ia64/ia32/sys_ia32.c index af10462..a3405b3 100644 --- a/arch/ia64/ia32/sys_ia32.c +++ b/arch/ia64/ia32/sys_ia32.c @@ -34,7 +34,6 @@ #include linux/uio.h #include linux/nfs_fs.h #include linux/quota.h -#include linux/syscalls.h #include linux/sunrpc/svc.h #include linux/nfsd/nfsd.h #include linux/nfsd/cache.h diff --git a/arch/ia64/kernel/setup.c b/arch/ia64/kernel/setup.c index 7cecd29..cd9a37a 100644 --- a/arch/ia64/kernel/setup.c +++ b/arch/ia64/kernel/setup.c @@ -60,7 +60,6 @@ #include asm/smp.h #include asm/system.h #include asm/unistd.h -#include asm/system.h #if defined(CONFIG_SMP) (IA64_CPU_SIZE PAGE_SIZE) # error struct cpuinfo_ia64 too big! diff --git a/arch/ia64/sn/kernel/setup.c b/arch/ia64/sn/kernel/setup.c index 684b1c9..1f38a3a 100644 --- a/arch/ia64/sn/kernel/setup.c +++ b/arch/ia64/sn/kernel/setup.c @@ -25,7 +25,6 @@ #include linux/interrupt.h #include linux/acpi.h #include linux/compiler.h -#include linux/sched.h #include linux/root_dev.h #include linux/nodemask.h #include linux/pm.h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Remove fs.h from mm.h
0) Remove fs.h from mm.h. For this, 1) Uninline vma_wants_writenotify(). It's pretty huge anyway. 2) Add back fs.h or less bloated headers (err.h) to files that need it. As result, on x86_64 allyesconfig, fs.h dependencies cut down from 3929 files rebuilt down to 3444 (-12.3%). Cross-compile tested without regressions on my two usual configs and (sigh): alpha arm-mx1adsmips-bigsur powerpc-ebony alpha-allnoconfig arm-neponset mips-capcellapowerpc-g5 alpha-defconfigarm-netwinder mips-cobalt powerpc-holly alpha-up arm-netx mips-db1000 powerpc-iseries armarm-ns9xxxmips-db1100 powerpc-linkstation arm-assabetarm-omap_h2_1610 mips-db1200 powerpc-lite5200 arm-at91rm9200dk arm-onearmmips-db1500 powerpc-maple arm-at91rm9200ek arm-picotux200mips-db1550 powerpc-mpc7448_hpc2 arm-at91sam9260ek arm-pleb mips-ddb5477 powerpc-mpc8272_ads arm-at91sam9261ek arm-pnx4008 mips-decstation powerpc-mpc8313_rdb arm-at91sam9263ek arm-pxa255-idpmips-e55 powerpc-mpc832x_mds arm-at91sam9rlek arm-realview mips-emma2rh powerpc-mpc832x_rdb arm-ateb9200 arm-realview-smp mips-excite powerpc-mpc834x_itx arm-badge4 arm-rpc mips-fulong powerpc-mpc834x_itxgp arm-carmevaarm-s3c2410 mips-ip22powerpc-mpc834x_mds arm-cerfcube arm-shannon mips-ip27powerpc-mpc836x_mds arm-clps7500 arm-shark mips-ip32powerpc-mpc8540_ads arm-collie arm-simpadmips-jazzpowerpc-mpc8544_ds arm-corgi arm-spitz mips-jmr3927 powerpc-mpc8560_ads arm-csb337 arm-trizeps4 mips-malta powerpc-mpc8568mds arm-csb637 arm-versatile mips-mipssim powerpc-mpc85xx_cds arm-ebsa110i386 mips-mpc30x powerpc-mpc8641_hpcn arm-edb7211i386-allnoconfig mips-msp71xx powerpc-mpc866_ads arm-em_x270i386-defconfigmips-ocelot powerpc-mpc885_ads arm-ep93xx i386-up mips-pb1100 powerpc-pasemi arm-footbridge ia64 mips-pb1500 powerpc-pmac32 arm-fortunet ia64-allnoconfig mips-pb1550 powerpc-ppc64 arm-h3600 ia64-bigsur mips-pnx8550-jbs powerpc-prpmc2800 arm-h7201 ia64-defconfigmips-pnx8550-stb810 powerpc-ps3 arm-h7202 ia64-gensparsemips-qemupowerpc-pseries arm-hackkitia64-sim mips-rbhma4200 powerpc-up arm-integrator ia64-sn2 mips-rbhma4500 s390 arm-iop13xxia64-tigermips-rm200 s390-allnoconfig arm-iop32x ia64-up mips-sb1250-swarms390-defconfig arm-iop33x ia64-zx1 mips-seads390-up arm-ixp2000m68k mips-tb0219 sparc arm-ixp23xxm68k-amigamips-tb0226 sparc-allnoconfig arm-ixp4xx m68k-apollo mips-tb0287 sparc-defconfig arm-jornada720 m68k-atarimips-workpad sparc-up arm-kafa m68k-bvme6000 mips-wrppmc sparc64 arm-kb9202 m68k-hp300mips-yosemitesparc64-allnoconfig arm-ks8695 m68k-mac parisc sparc64-defconfig arm-lart m68k-mvme147 parisc-allnoconfig sparc64-up arm-lpd270 m68k-mvme16x parisc-defconfig um-x86_64 arm-lpd7a400 m68k-q40 parisc-upx86_64 arm-lpd7a404 m68k-sun3 powerpc x86_64-allnoconfig arm-lubbockm68k-sun3xpowerpc-cell x86_64-defconfig arm-lusl7200 mips powerpc-celleb x86_64-up arm-mainstone mips-atlaspowerpc-chrp32 Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] --- arch/alpha/kernel/smp.c|1 arch/arm/kernel/setup.c|1 arch/arm/kernel/smp.c |1 arch/frv/kernel/sys_frv.c |1 arch/i386/kernel/microcode.c |1 arch/i386/kernel/sys_i386.c|1 arch/i386/kernel/sysenter.c|1 arch/ia64/kernel/init_task.c |1 arch/m68k/kernel/process.c |1 arch/m68k/kernel/sys_m68k.c|1 arch/mips/kernel/smp.c |1 arch/mips/kernel/syscall.c |1 arch/parisc/hpux/fs.c |1 arch/parisc/kernel/init_task.c |1 arch/parisc/kernel/process.c |1 arch/parisc/kernel/smp.c |1 arch/powerpc/kernel/syscalls.c |1 arch/powerpc/lib/rheap.c |1 arch/powerpc/oprofile/cell/spu_task_sync.c |1
[PATCH] sh64: arch/sh64/kernel/signal.h - duplicate include removal
Hi, This patch removes the duplicate inclusion of linux/personality.h from arch/sh64/kernel/signal.c Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- diff --git a/arch/sh64/kernel/signal.c b/arch/sh64/kernel/signal.c index 0bb4a8f..79fc48c 100644 --- a/arch/sh64/kernel/signal.c +++ b/arch/sh64/kernel/signal.c @@ -25,7 +25,6 @@ #include linux/ptrace.h #include linux/unistd.h #include linux/stddef.h -#include linux/personality.h #include asm/ucontext.h #include asm/uaccess.h #include asm/pgtable.h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-usb-users] [REGRESSION] 2.6.23-rc1: uhci_hcd. irq 4: nobody cared
On Sun, 29 Jul 2007, Mark Hindley wrote: On Sun, Jul 29, 2007 at 11:19:47AM -0400, Alan Stern wrote: On Sun, 29 Jul 2007, Mark Hindley wrote: Hi, I have just tried 2.6.23-rc1 on my Acer Aspire 1350. On boot I get the following error as the uhci_hcd module is loaded: Jul 28 18:23:20 mercury kernel: ACPI: PCI Interrupt :00:10.0[A] - Link [LNKA] - GSI 4 (level, low) - IRQ 4 Jul 28 18:23:20 mercury kernel: uhci_hcd :00:10.0: UHCI Host Controller Jul 28 18:23:20 mercury kernel: uhci_hcd :00:10.0: new USB bus registered, assigned bus number 2 Jul 28 18:23:20 mercury kernel: irq 4: nobody cared (try booting with the irqpoll option) Did it work okay with older kernels? What does /proc/interrupts say in both 2.6.23-rc1 and in a working kernel? No boot error with 2.6.22.1. On 2.6.22.1: CPU0 0: 12312XT-PIC-XTtimer 1:286XT-PIC-XTi8042 2: 0XT-PIC-XTcascade 4:434XT-PIC-XTuhci_hcd:usb2, [EMAIL PROTECTED]::01:00.0 5: 2000XT-PIC-XTyenta, uhci_hcd:usb3, wifi0 6: 3XT-PIC-XTfloppy 7: 3XT-PIC-XTparport0 8: 4XT-PIC-XTrtc 9: 0XT-PIC-XTuhci_hcd:usb4, VIA82XX-MODEM, VIA8233 10:843XT-PIC-XTacpi 11: 0XT-PIC-XTehci_hcd:usb1 12:123XT-PIC-XTi8042 14: 10951XT-PIC-XTide0 15: 53XT-PIC-XTide1 NMI:770 LOC: 120091 ERR: 0 MIS: 0 On 2.6.23-rc1: CPU0 0: 8616XT-PIC-XTtimer 1:183XT-PIC-XTi8042 2: 0XT-PIC-XTcascade 4: 8233XT-PIC-XTuhci_hcd:usb1, [EMAIL PROTECTED]::01:00.0 5: 4948XT-PIC-XTuhci_hcd:usb2, yenta, wifi0 6: 3XT-PIC-XTfloppy 7: 22XT-PIC-XTparport0 8: 4XT-PIC-XTrtc 9: 0XT-PIC-XTuhci_hcd:usb3, VIA82XX-MODEM, VIA8233 10:854XT-PIC-XTacpi 11: 0XT-PIC-XTehci_hcd:usb4 12:123XT-PIC-XTi8042 14: 12202XT-PIC-XTide0 15: 53XT-PIC-XTide1 NMI:809 LOC: 150284 ERR: 1 MIS: 0 No significant differences. :-( Well, about all I can suggest is bisection. And don't assume that this problem was caused by a change to the USB stack. It could be a change in the interrupt-handling core or a change to the driver for one of the other devices sharing the IRQ. It might even be caused by a change in the order the modules are loaded, which has nothing to do with the kernel directly. In fact, it might be worth checking this possibility first. For example, it's clear that 2.6.22 loaded ehci-hcd before uhci-hcd whereas 2.6.23-rc1 did the reverse. And yenta vs. uhci-hcd is different. Alan Stern - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [PATCH] Reboot Dreamcast under software control
On Sun, Jul 29, 2007 at 07:25:21PM +0100, Adrian McMenamin wrote:
diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c
index 6334a4c..6f5e9e4 100644
--- a/arch/sh/kernel/process.c
+++ b/arch/sh/kernel/process.c
@@ -97,6 +97,11 @@ void cpu_idle(void)
void machine_restart(char * __unused)
{
+
+#ifdef CONFIG_SH_DREAMCAST
+ /*reboot the Dreamcast under software control*/
+ writel(0x7611, 0xA05F6890);
+#endif
/* SR.BL=1 and invoke address error to let CPU reset (manual reset) */
asm volatile(ldc %0, sr\n\t
mov.l @%1, %0 : : r (0x1000), r (0x8001));
No, if you want to do this, at least use a function pointer and leave
this as the default implementation. The dreamcast presumably only needs
this magic write anyways, rather than the SR.BL trick.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] SCSI bug fixes for 2.6.23-rc1
James Bottomley wrote: This is basically a set of bug fixes with a few minor cleanups thrown in. There are also a few bsg fixes we're taking through this tree because SCSI is the current sole consumer. The reason for the huge size is the lindent of the advansys driver along with a few cleanups. The patch is available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git You missed [SCSI] arcmsr: Fix hardware wait loops Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sh64: arch/sh64/kernel/signal.h - duplicate include removal
On Mon, Jul 30, 2007 at 12:44:00AM +0200, Jesper Juhl wrote: This patch removes the duplicate inclusion of linux/personality.h from arch/sh64/kernel/signal.c Signed-off-by: Jesper Juhl [EMAIL PROTECTED] Acked-by: Paul Mundt [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/bluetooth/hci_ldisc.c: fix possible NULL dereferences
Hi Marcel,
Marcel Holtmann wrote:
Commit 22ad42033b7d2b3d7928fba9f89d1c7f8a3c9581 did not completely fix all
the possible NULL dereferences. Besides hci_uart_close(), we also need to
make sure that hdev is valid before calling hci_{unregister,free}_dev().
I don't see any issue. Without HCI_UART_PROTO_SET, the hdev will never
be registered. So no need to protect it twice.
Correct me if I am wrong. HCI_UART_PROTO_SET bit is only set if
hci_uart_tty_ioctl()
is called with HCIUARTSETPROTO. Is it possible for the HCI device to be
registered
and then unregistered without setting the HCI_UART_PROTO_SET bit in hdev-flags?
Thanks,
Eugene
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc: clean out a bunch of duplicate includes
On Mon, 2007-07-30 at 00:18 +0200, Jesper Juhl wrote: Hi, Here's a patch to clean out a bunch of duplicate includes from arch/powerpc/ Please consider for inclusion. Ah.. historical stuff stacking up :-) Signed-off-by: Jesper Juhl [EMAIL PROTECTED] Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- arch/powerpc/kernel/btext.c|1 - arch/powerpc/kernel/crash.c|1 - arch/powerpc/kernel/iommu.c|1 - arch/powerpc/kernel/prom.c |1 - arch/powerpc/kernel/time.c |1 - arch/powerpc/mm/hash_utils_64.c|1 - arch/powerpc/mm/hugetlbpage.c |3 --- arch/powerpc/mm/init_32.c |1 - arch/powerpc/mm/mem.c |1 - arch/powerpc/platforms/52xx/mpc52xx_pic.c |1 - arch/powerpc/platforms/chrp/setup.c|1 - arch/powerpc/platforms/chrp/smp.c |1 - arch/powerpc/platforms/iseries/setup.c |1 - arch/powerpc/platforms/powermac/low_i2c.c |1 - arch/powerpc/platforms/powermac/udbg_adb.c |1 - arch/powerpc/platforms/pseries/lpar.c |1 - 16 files changed, 0 insertions(+), 18 deletions(-) diff --git a/arch/powerpc/kernel/btext.c b/arch/powerpc/kernel/btext.c index e7b6846..3ef51fb 100644 --- a/arch/powerpc/kernel/btext.c +++ b/arch/powerpc/kernel/btext.c @@ -11,7 +11,6 @@ #include asm/sections.h #include asm/prom.h #include asm/btext.h -#include asm/prom.h #include asm/page.h #include asm/mmu.h #include asm/pgtable.h diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c index 37658ea..77c749a 100644 --- a/arch/powerpc/kernel/crash.c +++ b/arch/powerpc/kernel/crash.c @@ -24,7 +24,6 @@ #include linux/init.h #include linux/irq.h #include linux/types.h -#include linux/irq.h #include asm/processor.h #include asm/machdep.h diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c index c08ceca..e4ec6ee 100644 --- a/arch/powerpc/kernel/iommu.c +++ b/arch/powerpc/kernel/iommu.c @@ -30,7 +30,6 @@ #include linux/spinlock.h #include linux/string.h #include linux/dma-mapping.h -#include linux/init.h #include linux/bitops.h #include asm/io.h #include asm/prom.h diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c index a38197b..0028fe6 100644 --- a/arch/powerpc/kernel/prom.c +++ b/arch/powerpc/kernel/prom.c @@ -52,7 +52,6 @@ #include asm/pSeries_reconfig.h #include asm/pci-bridge.h #include asm/kexec.h -#include asm/system.h #ifdef DEBUG #define DBG(fmt...) printk(KERN_ERR fmt) diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c index 727a669..c85d9b0 100644 --- a/arch/powerpc/kernel/time.c +++ b/arch/powerpc/kernel/time.c @@ -72,7 +72,6 @@ #include asm/iseries/it_lp_queue.h #include asm/iseries/hv_call_xm.h #endif -#include asm/smp.h /* keep track of when we need to update the rtc */ time_t last_rtc_update; diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c index bc7b0ce..c2bf404 100644 --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -49,7 +49,6 @@ #include asm/tlb.h #include asm/cacheflush.h #include asm/cputable.h -#include asm/abs_addr.h #include asm/sections.h #include asm/spu.h diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c index 4835f73..ba5f12a 100644 --- a/arch/powerpc/mm/hugetlbpage.c +++ b/arch/powerpc/mm/hugetlbpage.c @@ -22,11 +22,8 @@ #include asm/mmu_context.h #include asm/machdep.h #include asm/cputable.h -#include asm/tlb.h #include asm/spu.h -#include linux/sysctl.h - #define NUM_LOW_AREAS(0x1UL SID_SHIFT) #define NUM_HIGH_AREAS (PGTABLE_RANGE HTLB_AREA_SHIFT) diff --git a/arch/powerpc/mm/init_32.c b/arch/powerpc/mm/init_32.c index e1f5ded..d65995a 100644 --- a/arch/powerpc/mm/init_32.c +++ b/arch/powerpc/mm/init_32.c @@ -41,7 +41,6 @@ #include asm/machdep.h #include asm/btext.h #include asm/tlb.h -#include asm/prom.h #include asm/lmb.h #include asm/sections.h diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c index f0e7eed..32dcfc9 100644 --- a/arch/powerpc/mm/mem.c +++ b/arch/powerpc/mm/mem.c @@ -42,7 +42,6 @@ #include asm/machdep.h #include asm/btext.h #include asm/tlb.h -#include asm/prom.h #include asm/lmb.h #include asm/sections.h #include asm/vdso.h diff --git a/arch/powerpc/platforms/52xx/mpc52xx_pic.c b/arch/powerpc/platforms/52xx/mpc52xx_pic.c index fbfff95..8c464c5 100644 --- a/arch/powerpc/platforms/52xx/mpc52xx_pic.c +++ b/arch/powerpc/platforms/52xx/mpc52xx_pic.c @@ -22,7 +22,6 @@ #include linux/init.h #include linux/sched.h #include linux/signal.h -#include linux/stddef.h #include linux/delay.h #include linux/irq.h #include linux/hardirq.h diff --git
Re: RFC: Remove the arm26 port
On Sun, 2007-07-29 at 13:50 +0200, Adrian Bunk wrote: Considering the state of the arm26 port, I do hereby suggest to remove it from the Linx kernel since it's far from a usable state and doesn't seem to come back into a usable state. If anyone wants to work on getting this port back into a usable state in the forseeable future he should speak up now. Hi guys. Obviously I havent had time to work on the port in some time now - I am ok with it being dropped - the work of splitting it out wont be lost and until its fixed up, its just in other peoples way. If I get time to work on it in future, I'll let you all know. -Ian - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
* Kasper Sandberg [EMAIL PROTECTED] wrote: [...] As far as im concerned, i may be forced to unofficially maintain SD for my own systems(allthough lots in the gaming community is bound to be interrested, as it does make games lots better) On 30/07/07, Ingo Molnar [EMAIL PROTECTED] wrote: i'd encourage you to do it - in fact i already tried to prod Peter Williams into doing exactly that ;) The more reality checks a scheduler has, the better. [ Btw., after the obvious initial merging trouble it should be much easier to keep SD maintained against future upstream kernels due to the policy modularity that CFS introduces. (and which policy-modularity should also help reduce the size and complexity of the SD patch.) ] chuckle You're advocating plugsched now? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [PATCH] Reboot Dreamcast under software control
On Mon, 2007-07-30 at 07:50 +0900, Paul Mundt wrote:
On Sun, Jul 29, 2007 at 07:25:21PM +0100, Adrian McMenamin wrote:
diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c
index 6334a4c..6f5e9e4 100644
--- a/arch/sh/kernel/process.c
+++ b/arch/sh/kernel/process.c
@@ -97,6 +97,11 @@ void cpu_idle(void)
void machine_restart(char * __unused)
{
+
+#ifdef CONFIG_SH_DREAMCAST
+ /*reboot the Dreamcast under software control*/
+ writel(0x7611, 0xA05F6890);
+#endif
/* SR.BL=1 and invoke address error to let CPU reset (manual reset)
*/
asm volatile(ldc %0, sr\n\t
mov.l @%1, %0 : : r (0x1000), r
(0x8001));
No, if you want to do this, at least use a function pointer and leave
this as the default implementation. The dreamcast presumably only needs
this magic write anyways, rather than the SR.BL trick.
Well, when I tested it, it did have a return in after the call and it
worked - but I took that out as it looked like code bloat to me :)
Explain what you mean by using a function pointer and I'll do that.
Adrian
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Mon, 30 Jul 2007, George Sescher wrote: chuckle You're advocating plugsched now? I'd suggest people here take a look at the code. It's not what Ingo was saying, and it's not what the code is set up to do. He's just stating that the way he split up the files, it's actually easier from a patching standpoint to just create a new file to include instead of kernel/sched_fair.c. But quite frankly, I've seen a lot of totally stupid flamage, and very little actual sense in this discussion. People probably didn't even look at the patches. Did you? For example, how hard is it for people to just admit that CFS actually does better than SD on a number of things? Including very much on the desktop. Ingo posted numbers. Look at those numbers, and then I would suggest some people could seriously consider just shutting up. I've seen too many idiotic people who claim that Con got treated unfairly, without those people admitting that maybe I had a point when I said that we have had a scheduler maintainer for years that actually knows what he's doing. And no, it has never been about desktop vs servers, or similar claptrap. It's been about improving the scheduler. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Fwd: [PATCH] Reboot Dreamcast under software control
On Mon, Jul 30, 2007 at 12:05:31AM +0100, Adrian McMenamin wrote:
On Mon, 2007-07-30 at 07:50 +0900, Paul Mundt wrote:
On Sun, Jul 29, 2007 at 07:25:21PM +0100, Adrian McMenamin wrote:
diff --git a/arch/sh/kernel/process.c b/arch/sh/kernel/process.c
index 6334a4c..6f5e9e4 100644
--- a/arch/sh/kernel/process.c
+++ b/arch/sh/kernel/process.c
@@ -97,6 +97,11 @@ void cpu_idle(void)
void machine_restart(char * __unused)
{
+
+#ifdef CONFIG_SH_DREAMCAST
+ /*reboot the Dreamcast under software control*/
+ writel(0x7611, 0xA05F6890);
+#endif
/* SR.BL=1 and invoke address error to let CPU reset (manual
reset) */
asm volatile(ldc %0, sr\n\t
mov.l @%1, %0 : : r (0x1000), r
(0x8001));
No, if you want to do this, at least use a function pointer and leave
this as the default implementation. The dreamcast presumably only needs
this magic write anyways, rather than the SR.BL trick.
Well, when I tested it, it did have a return in after the call and it
worked - but I took that out as it looked like code bloat to me :)
Explain what you mean by using a function pointer and I'll do that.
Look at the other implementations that are overloaded by the boards.
machine_power_off, the idle loop, etc.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq scaling appears not to work on overclocked systems
On Sun, Jul 29, 2007 at 03:16:45PM -0600, Berck E. Nash wrote: I'm running a Core2 Duo 1.86GHz overclocked to 2.56GHz. Everything is normal with cpufreq scaling disabled. With cpufreq scaling enabled in the kernel, using any governor, /proc/cpuinfo indicates a maximum of the rated frequency rather than the actual frequency. FAQ. The BIOS contains hard coded tables of frequencies. Just because you changed the clocks on which those tables are based doesn't mean the tables will change. Not a bug. Dave -- http://www.codemonkey.org.uk - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Mon, 30 Jul 2007, George Sescher wrote: chuckle You're advocating plugsched now? On 30/07/07, Linus Torvalds [EMAIL PROTECTED] wrote: I'd suggest people here take a look at the code. It's not what Ingo was saying, and it's not what the code is set up to do. He's just stating that the way he split up the files, it's actually easier from a patching standpoint to just create a new file to include instead of kernel/sched_fair.c. snip long other discussion unrelated to my question Ingo's origiinal comment: On 30/07/07, Ingo Molnar [EMAIL PROTECTED] wrote: i'd encourage you to do it - in fact i already tried to prod Peter Williams into doing exactly that ;) The more reality checks a scheduler has, the better. He said having reality checks is a good thing. He's encouraging some poor bastard to maintain plugsched out of mainline to have SD or whatever to compare to. I did not say I advocated anything whatsoever. I was asking if this is what Ingo is suggesting people use their energy doing. Not good enough for mainline, but definitely worth keeping around and good enough for... no idea what. I was asking Ingo that. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] core_pattern: cleaned up repost/continuing post of core_pattern enhancements
Hi Martin, Martin Pitt wrote: Eugene Teo [2007-07-29 21:03 +0800]: Also, it is probably good to think how we can drop privileges while piping the core dump output to an external program. A malicious user can potentially use it as a possible backdoor since anything that is executed by |program will be executed with root privileges. It was my understanding that apport already did this. I haven't looked at apport yet, but are you talking about the userspace portion of apport or the kernel changes in the Ubuntu kernel? Similarly to Neil's patches, the Ubuntu kernel calls the userspace helper as root, too. Apport drops privileges to the target process as soon as possible (there are a few things it needs to do before, like opening an fd to the crash file in /var/crash/ if that is only writeable by root). Just sharing some thoughts. Wouldn't it be more logical to drop the privileges first, then call the userspace helper program? I know that this will limit tools like apport to be able to read and/or write files that are only writable by root, but there ought to be a better way to do this? What if the program piped is not a legitimate program? Also, maybe it is good to make this portion of the code optional too, so that if no one is using this ispipe feature, we just turn it off. Eugene - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linus 2.6.23-rc1
On Mon, 30 Jul 2007, George Sescher wrote: He said having reality checks is a good thing. He's encouraging some poor bastard to maintain plugsched out of mainline to have SD or whatever to compare to. My bad, it was me who misread that (I didn't react to the name, I was thinking people were talking about maintaining SD that way). Mea culpa. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] m68knommu: Get rid of duplicate include
Hi Jesper, Jesper Juhl wrote: This patch removes the duplicate inclusion of asm/irq.h from arch/m68knommu/platform/5206e/config.c You can add my acked by: Acked-by: Greg Ungerer [EMAIL PROTECTED] Signed-off-by: Jesper Juhl [EMAIL PROTECTED] --- arch/m68knommu/platform/5206e/config.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/m68knommu/platform/5206e/config.c b/arch/m68knommu/platform/5206e/config.c index 4ab614f..425703f 100644 --- a/arch/m68knommu/platform/5206e/config.c +++ b/arch/m68knommu/platform/5206e/config.c @@ -20,7 +20,6 @@ #include asm/mcftimer.h #include asm/mcfsim.h #include asm/mcfdma.h -#include asm/irq.h /***/ -- Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED] Secure Computing CorporationPHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Remove fs.h from mm.h
On Mon, 30 Jul 2007, Alexey Dobriyan wrote: Cross-compile tested without regressions on my two usual configs and (sigh): alpha arm-mx1adsmips-bigsur powerpc-ebony .. Heh. Kudos for going above and beyond. But where is blackfin and frv? Thanks, Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Introduce CONFIG_HIBERNATION and CONFIG_SUSPEND (updated)
Ok, I took this, and modified Len's patch to re-introduce ACPI_SLEEP on top of it (I took the easy way out, and just made PM_SLEEP imply ACPI_SLEEP, which should make everything come out right. I could have dropped ACPI_SLEEP entirely in favour of PM_SLEEP, but that would have implied changing more of Len's patch than I was really comfy with). Len, Rafael, please do check that the end result looks ok. I suspect ACPI could now take the PM_SLEEP/SUSPEND/HIBERNATE details into account, and that some of the code is not necessary when HIBERNATE is not selected, for example, but I'm not at all sure that it's worth it being very fine-grained. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Make lguest compile with CONFIG_BLOCK=n and CONFIG_NET=n
On Sun, 2007-07-29 at 17:18 +0200, Gabriel C wrote: Hi Rusty, Lguest should depend on BLOCK too , without BLOCK set I get this error: Hi Gabriel, Thanks for the report! It's probably better to fix this properly rather than hack it as I did for NET. Linus, please apply: Gabriel C reports lguest doesn't compile with CONFIG_BLOCK=n. Fix this by introducing a config var for the block device, which depends on LGUEST BLOCK. Do the same for the net driver, rather then depending gratuitously on CONFIG_NET. Signed-off-by: Rusty Russell [EMAIL PROTECTED] diff -r 9e987fcabb16 drivers/block/Makefile --- a/drivers/block/MakefileMon Jul 30 09:47:25 2007 +1000 +++ b/drivers/block/MakefileMon Jul 30 10:02:32 2007 +1000 @@ -31,4 +31,4 @@ obj-$(CONFIG_BLK_DEV_UB) += ub.o obj-$(CONFIG_BLK_DEV_UB) += ub.o obj-$(CONFIG_XEN_BLKDEV_FRONTEND) += xen-blkfront.o -obj-$(CONFIG_LGUEST_GUEST) += lguest_blk.o +obj-$(CONFIG_LGUEST_BLOCK) += lguest_blk.o diff -r 9e987fcabb16 drivers/lguest/Kconfig --- a/drivers/lguest/KconfigMon Jul 30 09:47:25 2007 +1000 +++ b/drivers/lguest/KconfigMon Jul 30 10:03:39 2007 +1000 @@ -1,6 +1,6 @@ config LGUEST config LGUEST tristate Linux hypervisor example code - depends on X86 PARAVIRT NET EXPERIMENTAL !X86_PAE + depends on X86 PARAVIRT EXPERIMENTAL !X86_PAE select LGUEST_GUEST select HVC_DRIVER ---help--- @@ -18,3 +18,11 @@ config LGUEST_GUEST The guest needs code built-in, even if the host has lguest support as a module. The drivers are tiny, so we build them in too. + +config LGUEST_NET + tristate + depends on LGUEST_GUEST NET + +config LGUEST_BLOCK + tristate + depends on LGUEST_GUEST BLOCK diff -r 9e987fcabb16 drivers/net/Makefile --- a/drivers/net/Makefile Mon Jul 30 09:47:25 2007 +1000 +++ b/drivers/net/Makefile Mon Jul 30 10:02:22 2007 +1000 @@ -177,7 +177,7 @@ obj-$(CONFIG_HPLANCE) += hplance.o 7990. obj-$(CONFIG_HPLANCE) += hplance.o 7990.o obj-$(CONFIG_MVME147_NET) += mvme147.o 7990.o obj-$(CONFIG_EQUALIZER) += eql.o -obj-$(CONFIG_LGUEST_GUEST) += lguest_net.o +obj-$(CONFIG_LGUEST_NET) += lguest_net.o obj-$(CONFIG_MIPS_JAZZ_SONIC) += jazzsonic.o obj-$(CONFIG_MIPS_AU1X00_ENET) += au1000_eth.o obj-$(CONFIG_MIPS_SIM_NET) += mipsnet.o - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/68] 0 - NULL, for arch/m68knommu
Hi Yoann,
Yoann Padioleau wrote:
When comparing a pointer, it's clearer to compare it to NULL than to 0.
Signed-off-by: Yoann Padioleau [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Acked-by: Greg Ungerer [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
---
comempci.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/m68knommu/kernel/comempci.c b/arch/m68knommu/kernel/comempci.c
index 6ee00ef..528517e 100644
--- a/arch/m68knommu/kernel/comempci.c
+++ b/arch/m68knommu/kernel/comempci.c
@@ -736,7 +736,7 @@ #endif
/* Find a free spot to put this handler */
for (i = 0; (i COMEM_MAXPCI); i++) {
- if (pci_irqlist[i].handler == 0) {
+ if (pci_irqlist[i].handler == NULL) {
pci_irqlist[i].handler = handler;
pci_irqlist[i].device = device;
pci_irqlist[i].dev_id = dev_id;
--
Greg Ungerer -- Chief Software Dude EMAIL: [EMAIL PROTECTED]
Secure Computing CorporationPHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make lguest compile with CONFIG_BLOCK=n and CONFIG_NET=n
On 7/30/07, Rusty Russell [EMAIL PROTECTED] wrote: [...] Gabriel C reports lguest doesn't compile with CONFIG_BLOCK=n. Fix this by introducing a config var for the block device, which depends on LGUEST BLOCK. Do the same for the net driver, rather then depending gratuitously on CONFIG_NET. [...] diff -r 9e987fcabb16 drivers/lguest/Kconfig --- a/drivers/lguest/KconfigMon Jul 30 09:47:25 2007 +1000 +++ b/drivers/lguest/KconfigMon Jul 30 10:03:39 2007 +1000 @@ -1,6 +1,6 @@ config LGUEST config LGUEST tristate Linux hypervisor example code - depends on X86 PARAVIRT NET EXPERIMENTAL !X86_PAE + depends on X86 PARAVIRT EXPERIMENTAL !X86_PAE select LGUEST_GUEST select HVC_DRIVER ---help--- @@ -18,3 +18,11 @@ config LGUEST_GUEST The guest needs code built-in, even if the host has lguest support as a module. The drivers are tiny, so we build them in too. + +config LGUEST_NET + tristate + depends on LGUEST_GUEST NET default y ? + +config LGUEST_BLOCK + tristate + depends on LGUEST_GUEST BLOCK default y ? I /think/ the default y would also automatically become m if any of the dependencies are modules ... probably need to test this, though. Satyam - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] SCSI bug fixes for 2.6.23-rc1
On Sun, 2007-07-29 at 18:51 -0400, Jeff Garzik wrote: James Bottomley wrote: This is basically a set of bug fixes with a few minor cleanups thrown in. There are also a few bsg fixes we're taking through this tree because SCSI is the current sole consumer. The reason for the huge size is the lindent of the advansys driver along with a few cleanups. The patch is available here: master.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git You missed [SCSI] arcmsr: Fix hardware wait loops Waiting for maintainer ack ... msleep_interruptible - ssleep is a change with zero practical impact for this driver, so I think we can afford to wait. Nick is usually pretty good ... but I'll add it to scsi-pending just in case. James - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
