date:20080220

On Wednesday, February 20, 2008 9:17 am Jeff Chua wrote:
 On Feb 20, 2008 2:19 PM, Jeff Chua

  I'll try the idle=poll to see if that works and will try some printk

 I don't know what exactly the i915_suspend() and i915_resume() are
 supposed to do because it works better without them.

 After inserting return 0; right at the top of those two functions,
 suspend (and power-off properly), and resume (without green screen) works
 just fine.

 I would like to know what they're for.

They're for saving and restoring GPU state across suspend/resume.  They're 
particularly useful if your machine doesn't re-POST at resume time.  In that 
case your GPU may be totally uninitialized, so either the kernel or X has to 
set it up for you (X only does that partially).

 Tested suspend-to-ram, and suspend-to-disk, both console and X on notebook
 internal LCD display, all works without these two functions.

 But, anyway, got down to just one line in i915_drv.c causing the hang
 during suspend. pci_set_power_state(dev-pdev, PCI_D3hot);.

Interesting, which chipset do you have?  AFAIK that shouldn't cause a hang.

 And green screen problem during resume is caused by i915_restore_vga(dev);

I know I fixed that problem in at least one configuration...  Can you try:
  # echo test  /sys/power/disk
  # echo disk  /sys/power/state
and see if that also turns your screen green?

Also, getting a GPU register dump would be helpful.  The intel_reg_dumper tool 
is built as part of the xf86-video-driver build 
(git://anongit.freedesktop.org/git/xorg/driver/xf86-video-intel), can you 
pull that down and try it out?

Thanks,
Jesse
--
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.25-rc2: ohci1394 problem

2008-02-20 Thread Stefan Richter

I wrote:
 Thomas Meyer wrote at LKML:
 With 2.6.25-rc2 my kernel log consists mainly of:

 ohci1394: fw-host0: Unhandled interrupt(s) 0xfc7cfe0c
 
 There are junk interrupt events sent to ohci1394's IRQ handler.

PS, do you still have the log lines which come from ohci1394's
initialization?
-- 
Stefan Richter
-=-==--- --=- =-=--
http://arcgraph.de/sr/
--
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] x86: add the debugfs interface for the sysprof tool

2008-02-20 Thread Peter Zijlstra

On Tue, 2008-02-19 at 12:37 -0800, Arjan van de Ven wrote:
 From: Soren Sandmann [EMAIL PROTECTED]
 Subject: [PATCH] x86: add the debugfs interface for the sysprof tool

 The sysprof tool is a very easy to use GUI tool to find out where
 userspace is spending CPU time. See
 http://www.daimi.au.dk/~sandmann/sysprof/
 for more information and screenshots on this tool.

 Sysprof needs a 200 line kernel module to do it's work, this
 module puts some simple profiling data into debugfs.

What is the added value over oprofile?

--
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] x86: make cpu/proc|_64.c similar

From: Hiroshi Shimamoto [EMAIL PROTECTED]

clean up for unification.

Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
 arch/x86/kernel/cpu/proc.c|  120 +++-
 arch/x86/kernel/cpu/proc_64.c |   63 -
 2 files changed, 105 insertions(+), 78 deletions(-)

diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index af11d31..9bc3b04 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -8,75 +8,90 @@
 /*
  * Get CPU information for use by the procfs.
  */
+static void show_cpuinfo_core(struct seq_file *m, struct cpuinfo_x86 *c,
+ unsigned int cpu)
+{
+#ifdef CONFIG_X86_HT
+   if (c-x86_max_cores * smp_num_siblings  1) {
+   seq_printf(m, physical id\t: %d\n, c-phys_proc_id);
+   seq_printf(m, siblings\t: %d\n,
+  cpus_weight(per_cpu(cpu_core_map, cpu)));
+   seq_printf(m, core id\t\t: %d\n, c-cpu_core_id);
+   seq_printf(m, cpu cores\t: %d\n, c-booted_cores);
+   }
+#endif
+}
+
+static void show_cpuinfo_misc(struct seq_file *m, struct cpuinfo_x86 *c)
+{
+   /*
+* We use exception 16 if we have hardware math and we've either seen
+* it or the CPU claims it is internal
+*/
+   int fpu_exception = c-hard_math  (ignore_fpu_irq || cpu_has_fpu);
+   seq_printf(m,
+  fdiv_bug\t: %s\n
+  hlt_bug\t\t: %s\n
+  f00f_bug\t: %s\n
+  coma_bug\t: %s\n
+  fpu\t\t: %s\n
+  fpu_exception\t: %s\n
+  cpuid level\t: %d\n
+  wp\t\t: %s\n,
+  c-fdiv_bug ? yes : no,
+  c-hlt_works_ok ? no : yes,
+  c-f00f_bug ? yes : no,
+  c-coma_bug ? yes : no,
+  c-hard_math ? yes : no,
+  fpu_exception ? yes : no,
+  c-cpuid_level,
+  c-wp_works_ok ? yes : no);
+}
+
 static int show_cpuinfo(struct seq_file *m, void *v)
 {
struct cpuinfo_x86 *c = v;
-   int i, n = 0;
-   int fpu_exception;
+   unsigned int cpu = 0;
+   int i;
 
 #ifdef CONFIG_SMP
-   n = c-cpu_index;
+   cpu = c-cpu_index;
 #endif
-   seq_printf(m, processor\t: %d\n
-   vendor_id\t: %s\n
-   cpu family\t: %d\n
-   model\t\t: %d\n
-   model name\t: %s\n,
-   n,
-   c-x86_vendor_id[0] ? c-x86_vendor_id : unknown,
-   c-x86,
-   c-x86_model,
-   c-x86_model_id[0] ? c-x86_model_id : unknown);
+   seq_printf(m, processor\t: %u\n
+  vendor_id\t: %s\n
+  cpu family\t: %d\n
+  model\t\t: %u\n
+  model name\t: %s\n,
+  cpu,
+  c-x86_vendor_id[0] ? c-x86_vendor_id : unknown,
+  c-x86,
+  c-x86_model,
+  c-x86_model_id[0] ? c-x86_model_id : unknown);
 
if (c-x86_mask || c-cpuid_level = 0)
seq_printf(m, stepping\t: %d\n, c-x86_mask);
else
seq_printf(m, stepping\t: unknown\n);
 
-   if ( cpu_has(c, X86_FEATURE_TSC) ) {
-   unsigned int freq = cpufreq_quick_get(n);
+   if (cpu_has(c, X86_FEATURE_TSC)) {
+   unsigned int freq = cpufreq_quick_get(cpu);
+
if (!freq)
freq = cpu_khz;
seq_printf(m, cpu MHz\t\t: %u.%03u\n,
-   freq / 1000, (freq % 1000));
+  freq / 1000, (freq % 1000));
}
 
/* Cache size */
if (c-x86_cache_size = 0)
seq_printf(m, cache size\t: %d KB\n, c-x86_cache_size);
-#ifdef CONFIG_X86_HT
-   if (c-x86_max_cores * smp_num_siblings  1) {
-   seq_printf(m, physical id\t: %d\n, c-phys_proc_id);
-   seq_printf(m, siblings\t: %d\n,
-   cpus_weight(per_cpu(cpu_core_map, n)));
-   seq_printf(m, core id\t\t: %d\n, c-cpu_core_id);
-   seq_printf(m, cpu cores\t: %d\n, c-booted_cores);
-   }
-#endif
-   
-   /* We use exception 16 if we have hardware math and we've either seen 
it or the CPU claims it is internal */
-   fpu_exception = c-hard_math  (ignore_fpu_irq || cpu_has_fpu);
-   seq_printf(m, fdiv_bug\t: %s\n
-   hlt_bug\t\t: %s\n
-   f00f_bug\t: %s\n
-   coma_bug\t: %s\n
-   fpu\t\t: %s\n
-   fpu_exception\t: %s\n
-   cpuid level\t: %d\n
-   wp\t\t: %s\n
-   flags\t\t:,
-c-fdiv_bug ? yes : no,
-c-hlt_works_ok ? no : yes,
-c-f00f_bug ? yes : no,
-

Re: [PATCH] x86: add the debugfs interface for the sysprof tool

2008-02-20 Thread Arjan van de Ven

On Wed, 20 Feb 2008 19:16:15 +0100
Peter Zijlstra [EMAIL PROTECTED] wrote:

 On Tue, 2008-02-19 at 12:37 -0800, Arjan van de Ven wrote:
  From: Soren Sandmann [EMAIL PROTECTED]
  Subject: [PATCH] x86: add the debugfs interface for the sysprof tool

  The sysprof tool is a very easy to use GUI tool to find out where
  userspace is spending CPU time. See
  http://www.daimi.au.dk/~sandmann/sysprof/
  for more information and screenshots on this tool.

  Sysprof needs a 200 line kernel module to do it's work, this
  module puts some simple profiling data into debugfs.

 What is the added value over oprofile?

it actually works and is usable by humans ;)

what oprofile doesn't do is the nice userland hierarchy of where cpu time is 
spend.
(and that is also what makes it mostly useless in practice)

-- 
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings, 
visit http://www.lesswatts.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: USB regression (and other failures) in 2.6.2[45]* - mostly resolved

2008-02-20 Thread Andrew Buehler


On 2/20/2008 12:15 PM, Alan Stern wrote:


On Wed, 20 Feb 2008, Andrew Buehler wrote:



Hmm. One thing which just sprang to mind, in the stab-in-the-dark
category: in 2.6.24.2, launching the program on some machines gave
warnings along the lines of this program is using a deprecated
ioctl, please convert it to SG_IO (which I naturally cannot do
since it's closed and I don't have the source),


You can ask the program's author to update it.


It's provided by Novell, with whom I have no direct contact and am not
presently authorized to speak on behalf of my organization. From what I
have read about the history of their support on this program and these
discs, I do not expect that they would be willing to support it except
in environments which they provide in monolithic form; it would be
possible for me to copy an updated version of the program out of such an
environment to use in my own customized one, but I am not certain that
they have even created such an updated version, and in any case
obtaining it would almost certainly require buying the latest version of
Novell ZENworks - which my organization is certainly not prepared to do
at the present time.

In other words: I don't think that's likely to be practical in the
present instance. If you have reason to believe otherwise (past positive
experience with Novell, for instance), I'd be glad to hear it.


I'm not sure I expressed myself clearly. I do not think the problem
is with the different kernels. I think the problem is with the
different configurations. I am asking if there are any established
techniques for comparing differences between config files from
widely different kernels.


Not as far as I know.


Oh, well... thanks anyway.

Is there any place (aside from maybe the kernel changelog, which
contains a whole lot - if not several lots - of unrelated information)
where I could find a list of config-symbol name additions, changes,
deletions and meaning changes by version or by date? That would at least
let me build a mapping between the symbols in the older config and the
ones in the new one, which is about where I would have to start.

--
   Andrew Buehler
--
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: Plans for mISDN?

2008-02-20 Thread Tilman Schmidt


Am 20.02.2008 17:54 schrieb Andi Kleen:

mISDN has two problems, which are of course interrelated:

a) complete lack of documentation for the in-kernel driver interface
   (equivalent of Documentation/isdn/INTERFACE)


Most subsystems in the kernel would disqualify under that rule


I beg to differ. Most subsystems do have at least rudimentary
documentation. (I'm spoiled by the USB subsystem, of course. :-)


Did you ever look for full documentation on how to write Ethernet
drivers for example? Some bits are documented, but far from all


I am not asking for full documentation. Some bits would amply
suffice. Documentation/isdn/INTERFACE, the interface description
for the old isdn4linux subsystem, is far from complete, either.
But it contains enough hints so that I knew where to start.


(maintainer of an isdn4linux driver, waiting desperately for
documentation on how to convert to the new CAPI/mISDN world
but tired of asking for it in vain)


My advice is that you just read the source of some existing drivers
for examples and copy them and of the subsystem itself if anything is
unclear. That is how Linux drivers are usually written.


Usually, yes. But I find it unusually hard in this particular case.
In fact I have been trying to do that for two years now, without
getting anywhere. Reading code without a hint of what the authors
are trying to do is terribly time-consuming, to put it mildly.

Thanks,
T.

--
Tilman Schmidt  E-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)



signature.asc
Description: OpenPGP digital signature

[PATCH 3/5] x86_32: add power management line in /proc/cpuinfo

From: Hiroshi Shimamoto [EMAIL PROTECTED]

Change /proc/cpuinfo. It will look like x86_64's.
'power management' line is added and power management information
will be printed at the line.

Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
 arch/x86/kernel/cpu/proc.c |   14 +-
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index 9bc3b04..fd3823a 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -94,7 +94,13 @@ static int show_cpuinfo(struct seq_file *m, void *v)
if (cpu_has(c, i)  x86_cap_flags[i] != NULL)
seq_printf(m,  %s, x86_cap_flags[i]);
 
-   for (i = 0; i  32; i++)
+   seq_printf(m, \nbogomips\t: %lu.%02lu\n,
+  c-loops_per_jiffy/(50/HZ),
+  (c-loops_per_jiffy/(5000/HZ)) % 100);
+   seq_printf(m, clflush size\t: %u\n, c-x86_clflush_size);
+
+   seq_printf(m, power management:);
+   for (i = 0; i  32; i++) {
if (c-x86_power  (1  i)) {
if (i  ARRAY_SIZE(x86_power_flags) 
x86_power_flags[i])
@@ -104,11 +110,9 @@ static int show_cpuinfo(struct seq_file *m, void *v)
else
seq_printf(m,  [%d], i);
}
+   }
 
-   seq_printf(m, \nbogomips\t: %lu.%02lu\n,
-  c-loops_per_jiffy/(50/HZ),
-  (c-loops_per_jiffy/(5000/HZ)) % 100);
-   seq_printf(m, clflush size\t: %u\n\n, c-x86_clflush_size);
+   seq_printf(m, \n\n);
 
return 0;
 }
-- 
1.5.3.8


--
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] Document huge memory/cache overhead of memory controller in Kconfig

2008-02-20 Thread Pavel Machek

Hi!

  I know this is a pedantic comment, but why the heck is it called such
  a generic term as Memory Controller which doesn't give any
  indication of what it does.
  
  Shouldn't it be something like Memory Quota Controller, or Memory
  Limits Controller?
 
 It's called the memory controller since it controls the amount of
 memory that a user can allocate (via limits). The generic term for
 any resource manager plugged into cgroups is a controller.
 
 For ordinary desktop people, memory controller is what developers
 know as MMU or sometimes even some other mysterious piece of silicon
 inside the heavy box.

Actually I'd guess 'memory controller' == 'DRAM controller' == part of
northbridge that talks to DRAM.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: [PATCH] Document huge memory/cache overhead of memory controller in Kconfig

2008-02-20 Thread Jan Engelhardt


On Feb 20 2008 18:19, Pavel Machek wrote:
 
 For ordinary desktop people, memory controller is what developers
 know as MMU or sometimes even some other mysterious piece of silicon
 inside the heavy box.

Actually I'd guess 'memory controller' == 'DRAM controller' == part of
northbridge that talks to DRAM.

Yeah that must have been it when Windows says it found a new controller
after changing the mainboard underneath.
--
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.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

2008-02-20 Thread Linus Torvalds



On Thu, 21 Feb 2008, Jeff Chua wrote:
 
  That said, before you do anything else, try if suspend-to-RAM works.
 
 Linus, guess I missed this part ... so before touch anything, I did
 tried suspend-to-ram, and it works on console and in X.

Ok, so this is with clean current -git, and nothing disabled?

 And suspend-to-disk hangs, but I can still press and hold the power
 button to power it off.

The press and hold for five seconds is actually a hardware feature of 
the southbridge (well, I guess there is software in there too, but it's 
the embedded kind). So the fact that it powers off at that point means 
nothing, it just means that ok, your kernel is hung, but the hardware
still works ;)

This *sounds* like some part of the suspend-to-disk sequence is doing 
something stupid like trying to access the screen after it has been turned 
off, which doesn't surprise me at all. My oft-stated opinion has been that 
suspend-to-disk isn't a suspend at all, and should never have been 
confused with suspending anything.

It's snapshot-and-restore, and my opinion is that:

 - it should *never* call suspend()/resume() at all (that should be
   reserved purely for suspend-to-RAM and has real power management 
   issues!)

 - it should have a totally separate halt/unhalt/restore thing 
   that has nothing what-so-ever to do with power management, and is 
   purely about stopping the hardware for things like USB and network 
   cards (which otherwise do things like scan their command lists 
   asynchronously) and making sure that the driver state is consistent 
   with that stopped hw state.

 - the people who confuse snapshot/restore with suspend/resume are 
   horrible people that cause problems exactly because driver people then 
   get those things mixed up, and something like the video suspend/resume 
   should probably never have impacted suspend-to-disk in the first place!

HOWEVER, that's a separate fight I've had, and in the meantime:

 Then upon powering on and resume, I get the ugly green console screen. 
 I can still type and move around. Starting X runs fine. Ctrl-Alt-Del or 
 switching back to console will get back to the green screen.

.. so this implies that while the laptop apparently hung at the end of the 
snapshotting, the snapshotting did actually work, and it must have hung at 
the very end, presumably when it tried to actually turn the power off.

So there seems to be two (probably largely independent) problems:

 - the hang at shutdown that requires you to press-and-hold the power 
   button to actually cut power.

   At a guess: putting the VGA device into D3hot makes the ACPI code that 
   actually does the shutoff unhappy. Probably because it wants to access 
   the device, and ends up not ever getting the replies it wants, since 
   the hardware has been turned off.

 - the fact that we restore something wrong for you and the screen is 
   green.

   At a guess: the restore_vga ends up restoring some state that wasn't 
   correctly and fully saved.

IOW, I think your patch that disables the two lines actually ends up 
pretty much matching the two *different* problems. Can you confirm that 
doing those two parts of that patch individually actually does 
individually fix the two issues? (Ie disabling D3hot makes it shut down 
nicely but resume with green text, while disabling just restore_vga() ends 
up with shutdown problems, but once you press-and-hold the power button, 
the thing will then restore nicely)+

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 1/5] x86_64: split cpuinfo from setup_64.c into cpu/proc_64.c

From: Hiroshi Shimamoto [EMAIL PROTECTED]

x86 /proc/cpuinfo code can be unified.
This is the first step of unification.

Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
 arch/x86/kernel/cpu/Makefile  |1 +
 arch/x86/kernel/cpu/proc_64.c |  126 +
 arch/x86/kernel/setup_64.c|  120 ---
 3 files changed, 127 insertions(+), 120 deletions(-)
 create mode 100644 arch/x86/kernel/cpu/proc_64.c

diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index a0c4d7c..8ba7d28 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_X86_32)  += transmeta.o
 obj-$(CONFIG_X86_32)   += intel.o
 obj-$(CONFIG_X86_32)   += nexgen.o
 obj-$(CONFIG_X86_32)   += umc.o
+obj-$(CONFIG_X86_64)   += proc_64.o
 
 obj-$(CONFIG_X86_MCE)  += mcheck/
 obj-$(CONFIG_MTRR) += mtrr/
diff --git a/arch/x86/kernel/cpu/proc_64.c b/arch/x86/kernel/cpu/proc_64.c
new file mode 100644
index 000..bf4a94b
--- /dev/null
+++ b/arch/x86/kernel/cpu/proc_64.c
@@ -0,0 +1,126 @@
+#include linux/smp.h
+#include linux/timex.h
+#include linux/string.h
+#include asm/semaphore.h
+#include linux/seq_file.h
+#include linux/cpufreq.h
+
+/*
+ * Get CPU information for use by the procfs.
+ */
+
+static int show_cpuinfo(struct seq_file *m, void *v)
+{
+   struct cpuinfo_x86 *c = v;
+   int cpu = 0, i;
+
+#ifdef CONFIG_SMP
+   cpu = c-cpu_index;
+#endif
+
+   seq_printf(m, processor\t: %u\n
+  vendor_id\t: %s\n
+  cpu family\t: %d\n
+  model\t\t: %d\n
+  model name\t: %s\n,
+  (unsigned)cpu,
+  c-x86_vendor_id[0] ? c-x86_vendor_id : unknown,
+  c-x86,
+  (int)c-x86_model,
+  c-x86_model_id[0] ? c-x86_model_id : unknown);
+
+   if (c-x86_mask || c-cpuid_level = 0)
+   seq_printf(m, stepping\t: %d\n, c-x86_mask);
+   else
+   seq_printf(m, stepping\t: unknown\n);
+
+   if (cpu_has(c, X86_FEATURE_TSC)) {
+   unsigned int freq = cpufreq_quick_get((unsigned)cpu);
+
+   if (!freq)
+   freq = cpu_khz;
+   seq_printf(m, cpu MHz\t\t: %u.%03u\n,
+  freq / 1000, (freq % 1000));
+   }
+
+   /* Cache size */
+   if (c-x86_cache_size = 0)
+   seq_printf(m, cache size\t: %d KB\n, c-x86_cache_size);
+
+#ifdef CONFIG_SMP
+   if (smp_num_siblings * c-x86_max_cores  1) {
+   seq_printf(m, physical id\t: %d\n, c-phys_proc_id);
+   seq_printf(m, siblings\t: %d\n,
+  cpus_weight(per_cpu(cpu_core_map, cpu)));
+   seq_printf(m, core id\t\t: %d\n, c-cpu_core_id);
+   seq_printf(m, cpu cores\t: %d\n, c-booted_cores);
+   }
+#endif
+
+   seq_printf(m,
+  fpu\t\t: yes\n
+  fpu_exception\t: yes\n
+  cpuid level\t: %d\n
+  wp\t\t: yes\n
+  flags\t\t:,
+  c-cpuid_level);
+
+   for (i = 0; i  32*NCAPINTS; i++)
+   if (cpu_has(c, i)  x86_cap_flags[i] != NULL)
+   seq_printf(m,  %s, x86_cap_flags[i]);
+
+   seq_printf(m, \nbogomips\t: %lu.%02lu\n,
+  c-loops_per_jiffy/(50/HZ),
+  (c-loops_per_jiffy/(5000/HZ)) % 100);
+
+   if (c-x86_tlbsize  0)
+   seq_printf(m, TLB size\t: %d 4K pages\n, c-x86_tlbsize);
+   seq_printf(m, clflush size\t: %d\n, c-x86_clflush_size);
+   seq_printf(m, cache_alignment\t: %d\n, c-x86_cache_alignment);
+
+   seq_printf(m, address sizes\t: %u bits physical, %u bits virtual\n,
+  c-x86_phys_bits, c-x86_virt_bits);
+
+   seq_printf(m, power management:);
+   for (i = 0; i  32; i++) {
+   if (c-x86_power  (1  i)) {
+   if (i  ARRAY_SIZE(x86_power_flags) 
+   x86_power_flags[i])
+   seq_printf(m, %s%s,
+  x86_power_flags[i][0]? :,
+  x86_power_flags[i]);
+   else
+   seq_printf(m,  [%d], i);
+   }
+   }
+
+   seq_printf(m, \n\n);
+
+   return 0;
+}
+
+static void *c_start(struct seq_file *m, loff_t *pos)
+{
+   if (*pos == 0)  /* just in case, cpu 0 is not the first */
+   *pos = first_cpu(cpu_online_map);
+   if ((*pos)  NR_CPUS  cpu_online(*pos))
+   return cpu_data(*pos);
+   return NULL;
+}
+
+static void *c_next(struct seq_file *m, void *v, loff_t *pos)
+{
+   *pos = next_cpu(*pos, cpu_online_map);
+   return c_start(m, pos);
+}
+
+static void c_stop(struct seq_file *m, void *v)
+{
+}
+
+const struct seq_operations cpuinfo_op = {
+

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

2008-02-20 Thread Mark Lord


Jeff Chua wrote:



On Feb 20, 2008 2:19 PM, Jeff Chua

I'll try the idle=poll to see if that works and will try some printk


I don't know what exactly the i915_suspend() and i915_resume() are 
supposed to do because it works better without them.


After inserting return 0; right at the top of those two functions, 
suspend (and power-off properly), and resume (without green screen) 
works just fine.

..

Does this machine have more than one CPU core?  If so..
Does your kernel have CONFIG_HOTPLUG_CPU=y (if not, enable it).

??
--
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.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

2008-02-20 Thread Jeff Chua

On Feb 21, 2008 1:50 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
  I would like to know what they're for.
 They're for saving and restoring GPU state across suspend/resume.  They're
 particularly useful if your machine doesn't re-POST at resume time.  In that
 case your GPU may be totally uninitialized, so either the kernel or X has to
 set it up for you (X only does that partially).

Ok. A lot to digest.


 Interesting, which chipset do you have?  AFAIK that shouldn't cause a hang.

(II) intel(0): Integrated Graphics Chipset: Intel(R) 945GM


 I know I fixed that problem in at least one configuration...  Can you try:
   # echo test  /sys/power/disk
   # echo disk  /sys/power/state
 and see if that also turns your screen green?

Yes, still green. But I got it to actual reboot with ...

echo reboot  /sys/power/disk

So, next I'll try shutdown to see if it work. I was using platform.


 Also, getting a GPU register dump would be helpful.  The intel_reg_dumper tool

Attached are the two dumps from console. One prior to suspend, and one
after resume.

Thanks,
Jeff.
(II): DumpRegsBegin
(II):VCLK_DIVISOR_VGA0: 0x00031108 (n = 3, m1 = 17, m2 = 8)
(II):VCLK_DIVISOR_VGA1: 0x00031406 (n = 3, m1 = 20, m2 = 6)
(II):VCLK_POST_DIV: 0x00020002 (vga0 p1 = 4, p2 = 2, vga1 p1 = 2, p2 = 
2)
(II):DPLL_TEST: 0x00010001 ()
(II): CACHE_MODE_0: 0x6820
(II):  D_STATE: 0x
(II):DSPCLK_GATE_D: 0x1000 (clock gates disabled: DPLUNIT)
(II):   RENCLK_GATE_D1: 0x
(II):   RENCLK_GATE_D2: 0x
(II):SDVOB: 0x0048 (disabled, pipe A, stall disabled, not 
detected)
(II):SDVOC: 0x0048 (disabled, pipe A, stall disabled, not 
detected)
(II):  SDVOUDI: 0x0077
(II):   DSPARB: 0x1d9c
(II):   DSPFW1: 0x
(II):   DSPFW2: 0x
(II):   DSPFW3: 0x
(II): ADPA: 0x40008c18 (disabled, pipe B, +hsync, +vsync)
(II): LVDS: 0xc300 (enabled, pipe B, 18 bit, 1 channel)
(II): DVOA: 0x (disabled, pipe A, no stall, -hsync, 
-vsync)
(II): DVOB: 0x0048 (disabled, pipe A, no stall, -hsync, 
-vsync)
(II): DVOC: 0x0048 (disabled, pipe A, no stall, -hsync, 
-vsync)
(II):  DVOA_SRCDIM: 0x
(II):  DVOB_SRCDIM: 0x
(II):  DVOC_SRCDIM: 0x
(II):   PP_CONTROL: 0x0001 (power target: on)
(II):PP_STATUS: 0xc008 (on, ready, sequencing idle)
(II): PFIT_CONTROL: 0x80002668
(II):  PFIT_PGM_RATIOS: 0x
(II):  PORT_HOTPLUG_EN: 0x0020
(II):PORT_HOTPLUG_STAT: 0x
(II): DSPACNTR: 0x (disabled, pipe A)
(II):   DSPASTRIDE: 0x (0 bytes)
(II):  DSPAPOS: 0x (0, 0)
(II): DSPASIZE: 0x (1, 1)
(II): DSPABASE: 0x
(II): DSPASURF: 0x
(II):  DSPATILEOFF: 0x
(II):PIPEACONF: 0x (disabled, single-wide)
(II): PIPEASRC: 0x027f01df (640, 480)
(II):PIPEASTAT: 0x8203 (status: FIFO_UNDERRUN VSYNC_INT_STATUS 
VBLANK_INT_STATUS OREG_UPDATE_STATUS)
(II): FBC_CFB_BASE: 0x
(II):  FBC_LL_BASE: 0x
(II):  FBC_CONTROL: 0x
(II):  FBC_COMMAND: 0x
(II):   FBC_STATUS: 0x2000
(II): FBC_CONTROL2: 0x
(II):FBC_FENCE_OFF: 0x
(II):  FBC_MOD_NUM: 0x
(II): FPA0: 0x00031108 (n = 3, m1 = 17, m2 = 8)
(II): FPA1: 0x00031108 (n = 3, m1 = 17, m2 = 8)
(II):   DPLL_A: 0x0483 (disabled, non-dvo, VGA, default clock, 
DAC/serial mode, p1 = 8, p2 = 10, SDVO mult 1)
(II):DPLL_A_MD: 0x
(II): HTOTAL_A: 0x031f027f (640 active, 800 total)
(II): HBLANK_A: 0x03170287 (648 start, 792 end)
(II):  HSYNC_A: 0x02ef028f (656 start, 752 end)
(II): VTOTAL_A: 0x020c01df (480 active, 525 total)
(II): VBLANK_A: 0x020401e7 (488 start, 517 end)
(II):  VSYNC_A: 0x01eb01e9 (490 start, 492 end)
(II):BCLRPAT_A: 0x
(II): VSYNCSHIFT_A: 0x
(II): DSPBCNTR: 0x4900 (disabled, pipe B)
(II):   DSPBSTRIDE: 0x0280 (640 bytes)
(II):  DSPBPOS: 0x (0, 0)
(II): DSPBSIZE: 0x018f02cf (720, 400)
(II): DSPBBASE: 0x
(II): DSPBSURF: 0x
(II):  DSPBTILEOFF: 0x
(II):PIPEBCONF: 0x8000 (enabled, single-wide)
(II): PIPEBSRC: 0x027f018f (640, 400)
(II):PIPEBSTAT: 0x8202 (status: FIFO_UNDERRUN VSYNC_INT_STATUS 
VBLANK_INT_STATUS)
(II): FPB0: 0x00020e09 (n = 2, m1 = 14, m2 = 9)
(II): FPB1: 0x00031108 (n = 3, m1 =

Re: [2.6.25-rc2] e100: Trying to free already-free IRQ 11 during suspend ...

2008-02-20 Thread Kok, Auke

Kok, Auke wrote:
 Andrew Morton wrote:
 On Sun, 17 Feb 2008 15:36:50 +0300 Andrey Borzenkov [EMAIL PROTECTED] 
 wrote:

 ... and possibly reboot/poweroff (it flows by too fast to be legible).

 [ 8803.850634] ACPI: Preparing to enter system sleep state S3
 [ 8803.853141] Suspending console(s)
 [ 8805.287505] serial 00:09: disabled
 [ 8805.291564] Trying to free already-free IRQ 11
 [ 8805.291579] Pid: 6920, comm: pm-suspend Not tainted 2.6.25-rc2-1avb #2
 [ 8805.291628]  [c0152127] free_irq+0xb7/0x130
 [ 8805.291675]  [c024bd80] e100_suspend+0xc0/0x100
 [ 8805.291724]  [c01eaa36] pci_device_suspend+0x26/0x70
 [ 8805.291747]  [c0243674] suspend_device+0x94/0xd0
 [ 8805.291763]  [c02439a3] device_suspend+0x153/0x240
 [ 8805.291784]  [c014314f] suspend_devices_and_enter+0x4f/0xf0
 [ 8805.291808]  [c0143a5f] ? freeze_processes+0x3f/0x80
 [ 8805.291825]  [c01432fa] enter_state+0xaa/0x140
 [ 8805.291840]  [c014341f] state_store+0x8f/0xd0
 [ 8805.291852]  [c0143390] ? state_store+0x0/0xd0
 [ 8805.291866]  [c01d3404] kobj_attr_store+0x24/0x30
 [ 8805.291901]  [c01b547b] sysfs_write_file+0xbb/0x110
 [ 8805.291936]  [c0177d79] vfs_write+0x99/0x130
 [ 8805.291963]  [c01b53c0] ? sysfs_write_file+0x0/0x110
 [ 8805.291979]  [c01782fd] sys_write+0x3d/0x70
 [ 8805.291998]  [c010409a] sysenter_past_esp+0x5f/0xa5
 [ 8805.292038]  ===
 [ 8805.347640] ACPI: PCI interrupt for device :00:06.0 disabled
 [ 8805.361128] ACPI: PCI interrupt for device :00:02.0 disabled
 [ 8805.376670]  hwsleep-0322 [00] enter_sleep_state : Entering sleep 
 state [S3]
 [ 8805.376670] Back to C!

 Interface is unused normally (only for netconsole sometimes). dmesg and 
 config
 attached.
 Does reverting this:

 commit 8543da6672b0994921f014f2250e27ae81645580
 Author: Auke Kok [EMAIL PROTECTED]
 Date:   Wed Dec 12 16:30:42 2007 -0800

 e100: free IRQ to remove warningwhenrebooting
 
 with this patch:

 --- a/drivers/net/e100.c~revert-1
 +++ a/drivers/net/e100.c
 @@ -2804,9 +2804,8 @@ static int e100_suspend(struct pci_dev *
  pci_enable_wake(pdev, PCI_D3cold, 0);
  }
  
 -free_irq(pdev-irq, netdev);
 -
  pci_disable_device(pdev);
 +free_irq(pdev-irq, netdev);
  pci_set_power_state(pdev, PCI_D3hot);
  
  return 0;
 @@ -2848,8 +2847,6 @@ static void e100_shutdown(struct pci_dev
  pci_enable_wake(pdev, PCI_D3cold, 0);
  }
  
 -free_irq(pdev-irq, netdev);
 -
  pci_disable_device(pdev);
  pci_set_power_state(pdev, PCI_D3hot);
  }
 _

 fix it?

 Hmm ... after resume device has disappeared at all ...

 {pts/1}% cat /proc/interrupts
CPU0
   0:1290492XT-PIC-XTtimer
   1:   6675XT-PIC-XTi8042
   2:  0XT-PIC-XTcascade
   3:  2XT-PIC-XT
   4:  2XT-PIC-XT
   5:  3XT-PIC-XT
   7:  4XT-PIC-XTirda0
   8:  0XT-PIC-XTrtc0
   9:583XT-PIC-XTacpi
  10:  2XT-PIC-XT
  11:  31483XT-PIC-XTyenta, yenta, yenta, ohci_hcd:usb1, ALI 
 5451, pcmcia0.0
  12:  28070XT-PIC-XTi8042
  14:  21705XT-PIC-XTide0
  15:  82123XT-PIC-XTide1
 NMI:  0   Non-maskable interrupts
 TRM:  0   Thermal event interrupts
 SPU:  0   Spurious interrupts
 ERR:  0
 I hope that's not a separate bug...
 
 I'll take a look at this as well. thanks for reporting.

ok, I just had a repro - on a regular shutdown even.

this always worked before - I'm not blaming anything yet but something in the 
pci
shutdown code must now be freeing our irq for us (I'm not using anything fancy 
to
autoconfigure my network here).

I definately do not see this with 2.6.24 either.

Auke
--
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: tty pid problems

2008-02-20 Thread Jiri Slaby


On 02/20/2008 05:28 PM, Oleg Nesterov wrote:

I think you can revert the tty-bkl-pushdown.patch. Or, as Eric suggested, just
revert this

@@ -1222,7 +1221,7 @@ static const struct file_operations tty_
.read   = tty_read,
.write  = tty_write,
.poll   = tty_poll,
-   .ioctl  = tty_ioctl,
+   .unlocked_ioctl = tty_ioctl,
.compat_ioctl   = tty_compat_ioctl,
.open   = tty_open,
.release= tty_release,
@@ -1235,7 +1234,7 @@ static const struct file_operations ptmx
.read   = tty_read,
.write  = tty_write,
.poll   = tty_poll,
-   .ioctl  = tty_ioctl,
+   .unlocked_ioctl = tty_ioctl,
.compat_ioctl   = tty_compat_ioctl,
.open   = ptmx_open,
.release= tty_release,
@@ -1248,7 +1247,7 @@ static const struct file_operations cons
.read   = tty_read,
.write  = redirected_tty_write,
.poll   = tty_poll,
-   .ioctl  = tty_ioctl,
+   .unlocked_ioctl = tty_ioctl,
.compat_ioctl   = tty_compat_ioctl,
.open   = tty_open,
.release= tty_release,
@@ -1260,7 +1259,7 @@ static const struct file_operations hung
.read   = hung_up_tty_read,
.write  = hung_up_tty_write,
.poll   = hung_up_tty_poll,
-   .ioctl  = hung_up_tty_ioctl,
+   .unlocked_ioctl = hung_up_tty_ioctl,
.compat_ioctl   = hung_up_tty_compat_ioctl,
.release= tty_release,
 };

chunk.


This would result in unpredictable behaviour. If I left locking apart, ioctl 
prototype != unlocked_ioctl prototype.

--
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.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

On Wednesday, February 20, 2008 10:29 am Jeff Chua wrote:
  I know I fixed that problem in at least one configuration...  Can you
  try: # echo test  /sys/power/disk
# echo disk  /sys/power/state
  and see if that also turns your screen green?

 Yes, still green. But I got it to actual reboot with ...

 echo reboot  /sys/power/disk

 So, next I'll try shutdown to see if it work. I was using platform.

Ok, that would be good to try.

  Also, getting a GPU register dump would be helpful.  The intel_reg_dumper
  tool

 Attached are the two dumps from console. One prior to suspend, and one
 after resume.

Looks like the AR registers are hosed, which is what I thought I fixed...  Can 
you attach your i915_drv.c file just so I can sanity check it?

Thanks,
Jesse
--
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: Plans for mISDN? Was: [PATCH 00/14] [ISDN] ...

2008-02-20 Thread Gregory Nietsky



did someone say interface/API documentation ooops ... DUCK seriously
this is lacking and im sure as time goes on some volenteer (sucker) will
get it up and running.this is not a show stoper but a nice to have.ill 
perhaps even help out a bit with things, i have some comments on useage 
and module parameters that could be usefull to the would be 
users.remember mISDN is just the kernel bits there is a user lib that 
takes care of userland bits.



 b) still doesn't support all the hardware isdn4linux supports.

 That's a show stopper of course.

of course not all hardware is supported and in some cases more hardware 
is supported ... there is a precident for this OSS/ALSA where the one is 
 marked as DEPRICATED and the other promoted initialy as EXPERMENTAL ...


over all the most common devices are better supported under mISDN than 
isdn4linux.


and as with OSS/ALSA both can coexist on the system as modules (only one 
can be loaded at a time or else they dont play nice).


i really think this is a storm in a tea cup been blown into a hurricane
after all if it were mainlined (in -mm even) the result would be better 
support and more choice there are far worse supported drivers than the 
mISDN stack.the reality is that isdn4linux is dead idealy unsuported 
drivers need to be ported to mISDN or kept on life support.


--

This message has been scanned for viruses and

dangerous content by Superset Technology, and 


is believed to be clean.

http://www.superset.co.za


--
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.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

2008-02-20 Thread Jeff Chua

On Feb 21, 2008 2:53 AM, Jesse Barnes [EMAIL PROTECTED] wrote:

  So, next I'll try shutdown to see if it work. I was using platform.
 Ok, that would be good to try.

shutdown does power down properly. But still green on resume.


 Looks like the AR registers are hosed, which is what I thought I fixed...  Can
 you attach your i915_drv.c file just so I can sanity check it?

Attached.

Thanks,
Jeff.
/* i915_drv.c -- i830,i845,i855,i865,i915 driver -*- linux-c -*-
 */
/*
 *
 * Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas.
 * All Rights Reserved.
 *
 * Permission is hereby granted, free of charge, to any person obtaining a
 * copy of this software and associated documentation files (the
 * Software), to deal in the Software without restriction, including
 * without limitation the rights to use, copy, modify, merge, publish,
 * distribute, sub license, and/or sell copies of the Software, and to
 * permit persons to whom the Software is furnished to do so, subject to
 * the following conditions:
 *
 * The above copyright notice and this permission notice (including the
 * next paragraph) shall be included in all copies or substantial portions
 * of the Software.
 *
 * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS
 * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
 * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT.
 * IN NO EVENT SHALL TUNGSTEN GRAPHICS AND/OR ITS SUPPLIERS BE LIABLE FOR
 * ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
 * TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
 * SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
 *
 */

#include drmP.h
#include drm.h
#include i915_drm.h
#include i915_drv.h

#include drm_pciids.h

static struct pci_device_id pciidlist[] = {
i915_PCI_IDS
};

enum pipe {
PIPE_A = 0,
PIPE_B,
};

static bool i915_pipe_enabled(struct drm_device *dev, enum pipe pipe)
{
struct drm_i915_private *dev_priv = dev-dev_private;

if (pipe == PIPE_A)
return (I915_READ(DPLL_A)  DPLL_VCO_ENABLE);
else
return (I915_READ(DPLL_B)  DPLL_VCO_ENABLE);
}

static void i915_save_palette(struct drm_device *dev, enum pipe pipe)
{
struct drm_i915_private *dev_priv = dev-dev_private;
unsigned long reg = (pipe == PIPE_A ? PALETTE_A : PALETTE_B);
u32 *array;
int i;

if (!i915_pipe_enabled(dev, pipe))
return;

if (pipe == PIPE_A)
array = dev_priv-save_palette_a;
else
array = dev_priv-save_palette_b;

for(i = 0; i  256; i++)
array[i] = I915_READ(reg + (i  2));
}

static void i915_restore_palette(struct drm_device *dev, enum pipe pipe)
{
struct drm_i915_private *dev_priv = dev-dev_private;
unsigned long reg = (pipe == PIPE_A ? PALETTE_A : PALETTE_B);
u32 *array;
int i;

if (!i915_pipe_enabled(dev, pipe))
return;

if (pipe == PIPE_A)
array = dev_priv-save_palette_a;
else
array = dev_priv-save_palette_b;

for(i = 0; i  256; i++)
I915_WRITE(reg + (i  2), array[i]);
}

static u8 i915_read_indexed(u16 index_port, u16 data_port, u8 reg)
{
outb(reg, index_port);
return inb(data_port);
}

static u8 i915_read_ar(u16 st01, u8 reg, u16 palette_enable)
{
inb(st01);
outb(palette_enable | reg, VGA_AR_INDEX);
return inb(VGA_AR_DATA_READ);
}

static void i915_write_ar(u8 st01, u8 reg, u8 val, u16 palette_enable)
{
inb(st01);
outb(palette_enable | reg, VGA_AR_INDEX);
outb(val, VGA_AR_DATA_WRITE);
}

static void i915_write_indexed(u16 index_port, u16 data_port, u8 reg, u8 val)
{
outb(reg, index_port);
outb(val, data_port);
}

static void i915_save_vga(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
int i;
u16 cr_index, cr_data, st01;

/* VGA color palette registers */
dev_priv-saveDACMASK = inb(VGA_DACMASK);
/* DACCRX automatically increments during read */
outb(0, VGA_DACRX);
/* Read 3 bytes of color data from each index */
for (i = 0; i  256 * 3; i++)
dev_priv-saveDACDATA[i] = inb(VGA_DACDATA);

/* MSR bits */
dev_priv-saveMSR = inb(VGA_MSR_READ);
if (dev_priv-saveMSR  VGA_MSR_CGA_MODE) {
cr_index = VGA_CR_INDEX_CGA;
cr_data = VGA_CR_DATA_CGA;
st01 = VGA_ST01_CGA;
} else {
cr_index = VGA_CR_INDEX_MDA;
cr_data = VGA_CR_DATA_MDA;
st01 = VGA_ST01_MDA;
}

/* CRT controller regs */
i915_write_indexed(cr_index, cr_data, 0x11,
   i915_read_indexed(cr_index, cr_data, 0x11) 
   (~0x80));

Re: Disk schedulers

2008-02-20 Thread Lukas Hejtmanek

On Sat, Feb 16, 2008 at 05:20:49PM +, Pavel Machek wrote:
 Is cat /dev/zero  file enough to reproduce this?

yes.


 ext3 filesystem?

yes.
 
 Will cat /etc/passwd work while machine is unresponsive?

yes.

while find does not work:
time find /
/
/etc
/etc/manpath.config
/etc/update-manager
/etc/update-manager/release-upgrades
/etc/gshadow-
/etc/inputrc
/etc/openalrc
/etc/bonobo-activation
/etc/bonobo-activation/bonobo-activation-config.xml
/etc/gnome-vfs-2.0
/etc/gnome-vfs-2.0/modules
/etc/gnome-vfs-2.0/modules/obex-module.conf
/etc/gnome-vfs-2.0/modules/extra-modules.conf
/etc/gnome-vfs-2.0/modules/theme-method.conf
/etc/gnome-vfs-2.0/modules/font-method.conf
/etc/gnome-vfs-2.0/modules/default-modules.conf
^C

real0m7.982s
user0m0.003s
sys 0m0.000s


i.e., it took 8 seconds to list just 17 dir entries.

It looks like I have this problem:
http://www.linuxinsight.com/first_benchmarks_of_the_ext4_file_system.html#comment-619
(the last comment with title: Sustained writes 2 or more times the amount of
memfree)

-- 
Lukáš Hejtmánek
--
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] Document huge memory/cache overhead of memory controller in Kconfig

2008-02-20 Thread Pavel Machek

On Wed 2008-02-20 19:28:03, Jan Engelhardt wrote:
 
 On Feb 20 2008 18:19, Pavel Machek wrote:
  
  For ordinary desktop people, memory controller is what developers
  know as MMU or sometimes even some other mysterious piece of silicon
  inside the heavy box.
 
 Actually I'd guess 'memory controller' == 'DRAM controller' == part of
 northbridge that talks to DRAM.
 
 Yeah that must have been it when Windows says it found a new controller
 after changing the mainboard underneath.

Just for fun... this option really has to be renamed:

Memory controller
~
From Wikipedia, the free encyclopedia

The memory controller is a chip on a computer's motherboard or CPU die
which manages the flow of data going to and from the memory.

Most computers based on an Intel processor have a memory controller
implemented on their motherboard's north bridge, though some modern
microprocessors, such as AMD's Athlon 64 and Opteron processors, IBM's
POWER5, and Sun Microsystems UltraSPARC T1 have a memory controller on
the CPU die to reduce the memory latency. 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/

[PATCH 4/5] x86: cosmetic unification cpu/proc|_64.c

From: Hiroshi Shimamoto [EMAIL PROTECTED]

make cpu/proc.c and cpu/proc_64.c same.

Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
 arch/x86/kernel/cpu/proc.c|   36 ++
 arch/x86/kernel/cpu/proc_64.c |   49 +++-
 2 files changed, 83 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index fd3823a..15043a3 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -8,6 +8,7 @@
 /*
  * Get CPU information for use by the procfs.
  */
+#ifdef CONFIG_X86_32
 static void show_cpuinfo_core(struct seq_file *m, struct cpuinfo_x86 *c,
  unsigned int cpu)
 {
@@ -47,6 +48,31 @@ static void show_cpuinfo_misc(struct seq_file *m, struct 
cpuinfo_x86 *c)
   c-cpuid_level,
   c-wp_works_ok ? yes : no);
 }
+#else
+static void show_cpuinfo_core(struct seq_file *m, struct cpuinfo_x86 *c,
+ unsigned int cpu)
+{
+#ifdef CONFIG_SMP
+   if (c-x86_max_cores * smp_num_siblings  1) {
+   seq_printf(m, physical id\t: %d\n, c-phys_proc_id);
+   seq_printf(m, siblings\t: %d\n,
+  cpus_weight(per_cpu(cpu_core_map, cpu)));
+   seq_printf(m, core id\t\t: %d\n, c-cpu_core_id);
+   seq_printf(m, cpu cores\t: %d\n, c-booted_cores);
+   }
+#endif
+}
+
+static void show_cpuinfo_misc(struct seq_file *m, struct cpuinfo_x86 *c)
+{
+   seq_printf(m,
+  fpu\t\t: yes\n
+  fpu_exception\t: yes\n
+  cpuid level\t: %d\n
+  wp\t\t: yes\n,
+  c-cpuid_level);
+}
+#endif
 
 static int show_cpuinfo(struct seq_file *m, void *v)
 {
@@ -97,7 +123,17 @@ static int show_cpuinfo(struct seq_file *m, void *v)
seq_printf(m, \nbogomips\t: %lu.%02lu\n,
   c-loops_per_jiffy/(50/HZ),
   (c-loops_per_jiffy/(5000/HZ)) % 100);
+
+#ifdef CONFIG_X86_64
+   if (c-x86_tlbsize  0)
+   seq_printf(m, TLB size\t: %d 4K pages\n, c-x86_tlbsize);
+#endif
seq_printf(m, clflush size\t: %u\n, c-x86_clflush_size);
+#ifdef CONFIG_X86_64
+   seq_printf(m, cache_alignment\t: %d\n, c-x86_cache_alignment);
+   seq_printf(m, address sizes\t: %u bits physical, %u bits virtual\n,
+  c-x86_phys_bits, c-x86_virt_bits);
+#endif
 
seq_printf(m, power management:);
for (i = 0; i  32; i++) {
diff --git a/arch/x86/kernel/cpu/proc_64.c b/arch/x86/kernel/cpu/proc_64.c
index ce1b08f..15043a3 100644
--- a/arch/x86/kernel/cpu/proc_64.c
+++ b/arch/x86/kernel/cpu/proc_64.c
@@ -8,6 +8,47 @@
 /*
  * Get CPU information for use by the procfs.
  */
+#ifdef CONFIG_X86_32
+static void show_cpuinfo_core(struct seq_file *m, struct cpuinfo_x86 *c,
+ unsigned int cpu)
+{
+#ifdef CONFIG_X86_HT
+   if (c-x86_max_cores * smp_num_siblings  1) {
+   seq_printf(m, physical id\t: %d\n, c-phys_proc_id);
+   seq_printf(m, siblings\t: %d\n,
+  cpus_weight(per_cpu(cpu_core_map, cpu)));
+   seq_printf(m, core id\t\t: %d\n, c-cpu_core_id);
+   seq_printf(m, cpu cores\t: %d\n, c-booted_cores);
+   }
+#endif
+}
+
+static void show_cpuinfo_misc(struct seq_file *m, struct cpuinfo_x86 *c)
+{
+   /*
+* We use exception 16 if we have hardware math and we've either seen
+* it or the CPU claims it is internal
+*/
+   int fpu_exception = c-hard_math  (ignore_fpu_irq || cpu_has_fpu);
+   seq_printf(m,
+  fdiv_bug\t: %s\n
+  hlt_bug\t\t: %s\n
+  f00f_bug\t: %s\n
+  coma_bug\t: %s\n
+  fpu\t\t: %s\n
+  fpu_exception\t: %s\n
+  cpuid level\t: %d\n
+  wp\t\t: %s\n,
+  c-fdiv_bug ? yes : no,
+  c-hlt_works_ok ? no : yes,
+  c-f00f_bug ? yes : no,
+  c-coma_bug ? yes : no,
+  c-hard_math ? yes : no,
+  fpu_exception ? yes : no,
+  c-cpuid_level,
+  c-wp_works_ok ? yes : no);
+}
+#else
 static void show_cpuinfo_core(struct seq_file *m, struct cpuinfo_x86 *c,
  unsigned int cpu)
 {
@@ -31,6 +72,7 @@ static void show_cpuinfo_misc(struct seq_file *m, struct 
cpuinfo_x86 *c)
   wp\t\t: yes\n,
   c-cpuid_level);
 }
+#endif
 
 static int show_cpuinfo(struct seq_file *m, void *v)
 {
@@ -82,13 +124,16 @@ static int show_cpuinfo(struct seq_file *m, void *v)
   c-loops_per_jiffy/(50/HZ),
   (c-loops_per_jiffy/(5000/HZ)) % 100);
 
+#ifdef CONFIG_X86_64
if (c-x86_tlbsize  0)
seq_printf(m, TLB size\t: %d 4K pages\n, c-x86_tlbsize);
-

Re: [QUESTION] FRV: linking error?

2008-02-20 Thread Sam Ravnborg

On Wed, Feb 20, 2008 at 09:15:00PM +0300, Cyrill Gorcunov wrote:
 [David Howells - Wed, Feb 20, 2008 at 06:13:15PM +]
 | Cyrill Gorcunov [EMAIL PROTECTED] wrote:
 | 
 |  Sam, maybe we should just eliminate this section at least for FRV?
 | 
 | You should have a patch in your inbox to do just that.
 | 
 | David
 | 
 
 Thanks David! I've got them all.
 I think Sam will take care of them to be included in mainline.

arch stuff like this is preferably going via the arch maintainer.
Sometimes I do all-arch patches but when they are independent
like this one they should go via the arch maintainer.

Cyrill - I would like you to do the same cleanup for
m32r + mn10300 + s390
and send the patch to the respective maintainers with a cc to me.

Thanks,
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 10030] Suspend doesn't work when SD card is inserted

2008-02-20 Thread Alan Stern

On Wed, 20 Feb 2008, Pierre Ossman wrote:

 Not really. But you have some things confused. What it checks is if
 the mmc bus handler (not a proper driver model, just a way of
 separating the MMC, SD and SDIO stuff) has a resume function. And if
 it doesn't, it removes the card (since it cannot revive it at
 resume).
 
 So the only thing I can think of is to delay the removal until the
 resume routine, if that is safer.

Do I understand this correctly?  You've got special handling for the 
case where a bus handler doesn't have a resume routine, but no special 
handling for the case where it doesn't have a suspend routine?  Why 
bother to remove the device if neither routine exists (there won't be 
any need to revive it since the bus never got suspended)?

And why not simply fail the suspend if the resume routine doesn't exist
and the suspend routine does?  Maybe with an error message in the
system log.

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: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

2008-02-20 Thread Matthew Garrett

On Thu, Feb 21, 2008 at 02:49:39AM +0800, Jeff Chua wrote:

 Here's an interesting discovery. After I found that echo reboot 
 /sys/power/disk does reboot, I tried echo shutdown 
 /sys/power/disk, it does shutdown properly.
 
 With platform it refuses to shutdown. Both reboot and shutdown still
 end up with Mr. Green at resume.

That kind of suggests that the ACPI platform code is hitting the 
hardware directly - we've seen similar issues with PATA controllers. The 
right thing to do here is almost certainly just to avoid explicitly 
powering down hardware on hibernation.

-- 
Matthew Garrett | [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] x86: add the debugfs interface for the sysprof tool

2008-02-20 Thread Peter Zijlstra

On Wed, 2008-02-20 at 19:53 +0100, Peter Zijlstra wrote:
 On Wed, 2008-02-20 at 10:39 -0800, Arjan van de Ven wrote:
  On Wed, 20 Feb 2008 19:16:15 +0100
  Peter Zijlstra [EMAIL PROTECTED] wrote:

   On Tue, 2008-02-19 at 12:37 -0800, Arjan van de Ven wrote:
From: Soren Sandmann [EMAIL PROTECTED]
Subject: [PATCH] x86: add the debugfs interface for the sysprof tool

The sysprof tool is a very easy to use GUI tool to find out where
userspace is spending CPU time. See
http://www.daimi.au.dk/~sandmann/sysprof/
for more information and screenshots on this tool.

Sysprof needs a 200 line kernel module to do it's work, this
module puts some simple profiling data into debugfs.

   What is the added value over oprofile?

  it actually works and is usable by humans ;)

 # sysprof

 (sysprof:12480): Gtk-WARNING **: cannot open display:

 -ENOX

Usable for me is a cli interface. Also, I absolutely love opannotate.

For a fact, most of my professional userspace development days, I had to
profile on remote machines with no X.

--
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] x86: add the debugfs interface for the sysprof tool

2008-02-20 Thread Peter Zijlstra

On Wed, 2008-02-20 at 10:39 -0800, Arjan van de Ven wrote:
 On Wed, 20 Feb 2008 19:16:15 +0100
 Peter Zijlstra [EMAIL PROTECTED] wrote:

  On Tue, 2008-02-19 at 12:37 -0800, Arjan van de Ven wrote:
   From: Soren Sandmann [EMAIL PROTECTED]
   Subject: [PATCH] x86: add the debugfs interface for the sysprof tool

   The sysprof tool is a very easy to use GUI tool to find out where
   userspace is spending CPU time. See
   http://www.daimi.au.dk/~sandmann/sysprof/
   for more information and screenshots on this tool.

   Sysprof needs a 200 line kernel module to do it's work, this
   module puts some simple profiling data into debugfs.

  What is the added value over oprofile?

 it actually works and is usable by humans ;)

# sysprof

(sysprof:12480): Gtk-WARNING **: cannot open display:

-ENOX

 what oprofile doesn't do is the nice userland hierarchy of where cpu time is 
 spend.
 (and that is also what makes it mostly useless in practice)

so why not fix oprofile callgraph output and build a GUI on top of
oprofile for those of us who really want RSI from mouse movement :-)

--
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 5/5] x86: unify cpu/proc|_64.c

From: Hiroshi Shimamoto [EMAIL PROTECTED]

Now cpu/proc.c and cpu/proc_64.c are same.
So cpu/proc_64.c can be removed.

Signed-off-by: Hiroshi Shimamoto [EMAIL PROTECTED]
---
 arch/x86/kernel/cpu/Makefile  |5 +-
 arch/x86/kernel/cpu/proc_64.c |  180 -
 2 files changed, 2 insertions(+), 183 deletions(-)
 delete mode 100644 arch/x86/kernel/cpu/proc_64.c

diff --git a/arch/x86/kernel/cpu/Makefile b/arch/x86/kernel/cpu/Makefile
index 8ba7d28..ee7c452 100644
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -3,9 +3,9 @@
 #
 
 obj-y  := intel_cacheinfo.o addon_cpuid_features.o
-obj-y  += feature_names.o
+obj-y  += proc.o feature_names.o
 
-obj-$(CONFIG_X86_32)   += common.o proc.o bugs.o
+obj-$(CONFIG_X86_32)   += common.o bugs.o
 obj-$(CONFIG_X86_32)   += amd.o
 obj-$(CONFIG_X86_32)   += cyrix.o
 obj-$(CONFIG_X86_32)   += centaur.o
@@ -13,7 +13,6 @@ obj-$(CONFIG_X86_32)  += transmeta.o
 obj-$(CONFIG_X86_32)   += intel.o
 obj-$(CONFIG_X86_32)   += nexgen.o
 obj-$(CONFIG_X86_32)   += umc.o
-obj-$(CONFIG_X86_64)   += proc_64.o
 
 obj-$(CONFIG_X86_MCE)  += mcheck/
 obj-$(CONFIG_MTRR) += mtrr/
diff --git a/arch/x86/kernel/cpu/proc_64.c b/arch/x86/kernel/cpu/proc_64.c
deleted file mode 100644
index 15043a3..000
--- a/arch/x86/kernel/cpu/proc_64.c
+++ /dev/null
@@ -1,180 +0,0 @@
-#include linux/smp.h
-#include linux/timex.h
-#include linux/string.h
-#include asm/semaphore.h
-#include linux/seq_file.h
-#include linux/cpufreq.h
-
-/*
- * Get CPU information for use by the procfs.
- */
-#ifdef CONFIG_X86_32
-static void show_cpuinfo_core(struct seq_file *m, struct cpuinfo_x86 *c,
- unsigned int cpu)
-{
-#ifdef CONFIG_X86_HT
-   if (c-x86_max_cores * smp_num_siblings  1) {
-   seq_printf(m, physical id\t: %d\n, c-phys_proc_id);
-   seq_printf(m, siblings\t: %d\n,
-  cpus_weight(per_cpu(cpu_core_map, cpu)));
-   seq_printf(m, core id\t\t: %d\n, c-cpu_core_id);
-   seq_printf(m, cpu cores\t: %d\n, c-booted_cores);
-   }
-#endif
-}
-
-static void show_cpuinfo_misc(struct seq_file *m, struct cpuinfo_x86 *c)
-{
-   /*
-* We use exception 16 if we have hardware math and we've either seen
-* it or the CPU claims it is internal
-*/
-   int fpu_exception = c-hard_math  (ignore_fpu_irq || cpu_has_fpu);
-   seq_printf(m,
-  fdiv_bug\t: %s\n
-  hlt_bug\t\t: %s\n
-  f00f_bug\t: %s\n
-  coma_bug\t: %s\n
-  fpu\t\t: %s\n
-  fpu_exception\t: %s\n
-  cpuid level\t: %d\n
-  wp\t\t: %s\n,
-  c-fdiv_bug ? yes : no,
-  c-hlt_works_ok ? no : yes,
-  c-f00f_bug ? yes : no,
-  c-coma_bug ? yes : no,
-  c-hard_math ? yes : no,
-  fpu_exception ? yes : no,
-  c-cpuid_level,
-  c-wp_works_ok ? yes : no);
-}
-#else
-static void show_cpuinfo_core(struct seq_file *m, struct cpuinfo_x86 *c,
- unsigned int cpu)
-{
-#ifdef CONFIG_SMP
-   if (c-x86_max_cores * smp_num_siblings  1) {
-   seq_printf(m, physical id\t: %d\n, c-phys_proc_id);
-   seq_printf(m, siblings\t: %d\n,
-  cpus_weight(per_cpu(cpu_core_map, cpu)));
-   seq_printf(m, core id\t\t: %d\n, c-cpu_core_id);
-   seq_printf(m, cpu cores\t: %d\n, c-booted_cores);
-   }
-#endif
-}
-
-static void show_cpuinfo_misc(struct seq_file *m, struct cpuinfo_x86 *c)
-{
-   seq_printf(m,
-  fpu\t\t: yes\n
-  fpu_exception\t: yes\n
-  cpuid level\t: %d\n
-  wp\t\t: yes\n,
-  c-cpuid_level);
-}
-#endif
-
-static int show_cpuinfo(struct seq_file *m, void *v)
-{
-   struct cpuinfo_x86 *c = v;
-   unsigned int cpu = 0;
-   int i;
-
-#ifdef CONFIG_SMP
-   cpu = c-cpu_index;
-#endif
-   seq_printf(m, processor\t: %u\n
-  vendor_id\t: %s\n
-  cpu family\t: %d\n
-  model\t\t: %u\n
-  model name\t: %s\n,
-  cpu,
-  c-x86_vendor_id[0] ? c-x86_vendor_id : unknown,
-  c-x86,
-  c-x86_model,
-  c-x86_model_id[0] ? c-x86_model_id : unknown);
-
-   if (c-x86_mask || c-cpuid_level = 0)
-   seq_printf(m, stepping\t: %d\n, c-x86_mask);
-   else
-   seq_printf(m, stepping\t: unknown\n);
-
-   if (cpu_has(c, X86_FEATURE_TSC)) {
-   unsigned int freq = cpufreq_quick_get(cpu);
-
-   if (!freq)
-   freq = cpu_khz;
-   seq_printf(m, cpu MHz\t\t: %u.%03u\n,
-

Re: [PATCH 1/2] x86_64: Fold pda into per cpu area v3

2008-02-20 Thread Mike Travis

Ingo Molnar wrote:
 * Mike Travis [EMAIL PROTECTED] wrote:
 
   * Declare the pda as a per cpu variable. This will move the pda area
 to an address accessible by the x86_64 per cpu macros.  
 Subtraction of __per_cpu_start will make the offset based from the 
 beginning of the per cpu area.  Since %gs is pointing to the pda, 
 it will then also point to the per cpu variables and can be 
 accessed thusly:

  %gs:[per_cpu_ - __per_cpu_start]
 
 randconfig QA on x86.git found a crash on x86.git#testing with 
 nmi_watchdog=2 (config attached) - and i bisected it down to this patch.
 
 config and crashlog attached. You can pick up x86.git#testing via:
 
   http://people.redhat.com/mingo/x86.git/README
 
 (since i had to hand-merge the patch when integrating it, i've attached 
 the merged version below.)
 
   Ingo
 

I must need some different test machines as my AMD box does not fail with
either yours or Thomas's configs, and the Intel box complains about the
PCI-e e1000 driver and dies.  I'll see about configuring a new box.

Did you try Eric's patch to see if that fixed the failure?

Thanks,
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.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

On Wednesday, February 20, 2008 10:37 am Linus Torvalds wrote:
 This *sounds* like some part of the suspend-to-disk sequence is doing
 something stupid like trying to access the screen after it has been turned
 off, which doesn't surprise me at all. My oft-stated opinion has been that
 suspend-to-disk isn't a suspend at all, and should never have been
 confused with suspending anything.

 It's snapshot-and-restore, and my opinion is that:

  - it should *never* call suspend()/resume() at all (that should be
reserved purely for suspend-to-RAM and has real power management
issues!)

  - it should have a totally separate halt/unhalt/restore thing
that has nothing what-so-ever to do with power management, and is
purely about stopping the hardware for things like USB and network
cards (which otherwise do things like scan their command lists
asynchronously) and making sure that the driver state is consistent
with that stopped hw state.

  - the people who confuse snapshot/restore with suspend/resume are
horrible people that cause problems exactly because driver people then
get those things mixed up, and something like the video suspend/resume
should probably never have impacted suspend-to-disk in the first place!

Totally agreed.  I remember when I started getting hibernation bug reports 
against this new code and boggling at how hibernate was actually done.  The 
driver actually gets its -suspend routine called twice with two different 
pm_message_t values.  We tried to do different stuff depending on the 
pm_message_t (like only putting the device in D3hot if PM_EVENT_SUSPEND), but 
it appears we're not doing enough...

 So there seems to be two (probably largely independent) problems:

  - the hang at shutdown that requires you to press-and-hold the power
button to actually cut power.

At a guess: putting the VGA device into D3hot makes the ACPI code that
actually does the shutoff unhappy. Probably because it wants to access
the device, and ends up not ever getting the replies it wants, since
the hardware has been turned off.

Sounds like a good theory... now if we could just use set_power_state in the 
suspend case only.  That's what the latest code *tries* to do...

JEsse
--
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/3] kgdb: fixes and ARCH=arm support

Here are 3 more patches against the kgdb-light.  Porting kgdb-light to
another arch has found 2 regressions, which are fixed in the first patch.

The second patch adds hooks for an additional kgdboc uart driver which
was required to complete the testing with real hardware.

The third patch adds the ARCH=arm support for kgdb-light.

For initial merge of kgdb-light targeted at 2.6.26, the first patch in
this series is required.  The other patches are there for further
community review and to show the effort of integrating kgdb into
another arch with the API provided in the kgdb-light patch series.

Jason.

The following changes since commit 4ce04a959ef2ba9338217966013b832ff0ff9003:
  Jason Wessel (1):
kgdb-light-v10: x86 HW breakpoints

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jwessel/linux-2.6-kgdb.git 
for_ingo

Jason Wessel (3):
  kgdb: fix optional arch functions and probe_kernel_*
  kgdb: kgdboc pl011 I/O module
  kgdb: support for ARCH=arm

 arch/arm/Kconfig|1 +
 arch/arm/kernel/Makefile|1 +
 arch/arm/kernel/kgdb.c  |  219 +++
 arch/arm/kernel/setup.c |5 +
 arch/arm/kernel/traps.c |   11 ++
 drivers/serial/amba-pl011.c |   30 ++
 include/asm-arm/kgdb.h  |  101 
 include/asm-arm/traps.h |2 +
 kernel/kgdb.c   |   11 ++
 mm/maccess.c|6 +
 10 files changed, 387 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/kernel/kgdb.c
 create mode 100644 include/asm-arm/kgdb.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/3] kgdb: fix optional arch functions and probe_kernel_*

Fix two regressions dealing with the kgdb core.

1) kgdb_skipexception and kgdb_post_primary_code are optional
functions that are only required on archs that need special exception
fixups.

2) The kernel address space scope must be set on any probe_kernel_*
function or archs such as ARCH=arm will not allow access to the kernel
memory space.  As an example, it is required to allow the full kernel
address space is when you the kernel debugger to inspect a system
call.

Signed-off-by: Jason Wessel [EMAIL PROTECTED]
---
 kernel/kgdb.c |   11 +++
 mm/maccess.c  |6 ++
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/kernel/kgdb.c b/kernel/kgdb.c
index 68aea78..31425e0 100644
--- a/kernel/kgdb.c
+++ b/kernel/kgdb.c
@@ -200,6 +200,17 @@ int __weak kgdb_arch_init(void)
return 0;
 }
 
+int __weak kgdb_skipexception(int exception, struct pt_regs *regs)
+{
+   return 0;
+}
+
+void __weak
+kgdb_post_primary_code(struct pt_regs *regs, int e_vector, int err_code)
+{
+   return;
+}
+
 /**
  * kgdb_disable_hw_debug - Disable hardware debugging while we in kgdb.
  * @regs: Current struct pt_regs.
diff --git a/mm/maccess.c b/mm/maccess.c
index 24f81b9..ac40796 100644
--- a/mm/maccess.c
+++ b/mm/maccess.c
@@ -17,11 +17,14 @@
 long probe_kernel_read(void *dst, void *src, size_t size)
 {
long ret;
+   mm_segment_t old_fs = get_fs();
 
+   set_fs(KERNEL_DS);
pagefault_disable();
ret = __copy_from_user_inatomic(dst,
(__force const void __user *)src, size);
pagefault_enable();
+   set_fs(old_fs);
 
return ret ? -EFAULT : 0;
 }
@@ -39,10 +42,13 @@ EXPORT_SYMBOL_GPL(probe_kernel_read);
 long probe_kernel_write(void *dst, void *src, size_t size)
 {
long ret;
+   mm_segment_t old_fs = get_fs();
 
+   set_fs(KERNEL_DS);
pagefault_disable();
ret = __copy_to_user_inatomic((__force void __user *)dst, src, size);
pagefault_enable();
+   set_fs(old_fs);
 
return ret ? -EFAULT : 0;
 }
-- 
1.5.4

--
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/3] kgdb: kgdboc pl011 I/O module

Implement the serial polling hooks for the pl011 uart for use with
kgdboc.

This patch was specifically tested on the ARM Versatile AB reference
platform.

Signed-off-by: Jason Wessel [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
---
 drivers/serial/amba-pl011.c |   30 ++
 1 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/drivers/serial/amba-pl011.c b/drivers/serial/amba-pl011.c
index 40604a0..ecd3dad 100644
--- a/drivers/serial/amba-pl011.c
+++ b/drivers/serial/amba-pl011.c
@@ -314,6 +314,32 @@ static void pl011_break_ctl(struct uart_port *port, int 
break_state)
spin_unlock_irqrestore(uap-port.lock, flags);
 }
 
+#ifdef CONFIG_CONSOLE_POLL
+static int pl010_get_poll_char(struct uart_port *port)
+{
+   struct uart_amba_port *uap = (struct uart_amba_port *)port;
+   unsigned int status;
+   int ch;
+   do {
+   status = readw(uap-port.membase + UART01x_FR);
+   } while (status  UART01x_FR_RXFE);
+   ch = readw(uap-port.membase + UART01x_DR);
+
+   return ch;
+}
+
+static void pl010_put_poll_char(struct uart_port *port,
+unsigned char ch)
+{
+   struct uart_amba_port *uap = (struct uart_amba_port *)port;
+
+   while (readw(uap-port.membase + UART01x_FR)  UART01x_FR_TXFF)
+   barrier();
+   writew(ch, uap-port.membase + UART01x_DR);
+}
+
+#endif /* CONFIG_CONSOLE_POLL */
+
 static int pl011_startup(struct uart_port *port)
 {
struct uart_amba_port *uap = (struct uart_amba_port *)port;
@@ -572,6 +598,10 @@ static struct uart_ops amba_pl011_pops = {
.request_port   = pl010_request_port,
.config_port= pl010_config_port,
.verify_port= pl010_verify_port,
+#ifdef CONFIG_CONSOLE_POLL
+   .poll_get_char = pl010_get_poll_char,
+   .poll_put_char = pl010_put_poll_char,
+#endif
 };
 
 static struct uart_amba_port *amba_ports[UART_NR];
-- 
1.5.4

--
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/3] kgdb: support for ARCH=arm

This patch adds the ARCH=arm specific a kgdb backend, originally
written by Deepak Saxena [EMAIL PROTECTED] and George Davis
[EMAIL PROTECTED].  Geoff Levand [EMAIL PROTECTED],
Nicolas Pitre, and Manish Lachwani have contributed various fixups
here as well.

The changes to setup the traps earlier allow for early debugging with
a uart based KGDB I/O driver.  The do_undefinstr() routine also needed
to allow the lookup of kernel address space in order for the debugger
to plant undefined instructions in kernel memory space and receive the
correct notification.

Signed-off-by: Jason Wessel [EMAIL PROTECTED]
---
 arch/arm/Kconfig |1 +
 arch/arm/kernel/Makefile |1 +
 arch/arm/kernel/kgdb.c   |  219 ++
 arch/arm/kernel/setup.c  |5 +
 arch/arm/kernel/traps.c  |   11 +++
 include/asm-arm/kgdb.h   |  101 +
 include/asm-arm/traps.h  |2 +
 7 files changed, 340 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/kernel/kgdb.c
 create mode 100644 include/asm-arm/kgdb.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 9619c43..9e2e631 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -11,6 +11,7 @@ config ARM
select RTC_LIB
select SYS_SUPPORTS_APM_EMULATION
select HAVE_OPROFILE
+   select HAVE_ARCH_KGDB
select HAVE_KPROBES if (!XIP_KERNEL)
help
  The ARM series is a line of low-power-consumption RISC chip designs
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index 00d44c6..9bb17e6 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -22,6 +22,7 @@ obj-$(CONFIG_KEXEC)   += machine_kexec.o 
relocate_kernel.o
 obj-$(CONFIG_KPROBES)  += kprobes.o kprobes-decode.o
 obj-$(CONFIG_ATAGS_PROC)   += atags.o
 obj-$(CONFIG_OABI_COMPAT)  += sys_oabi-compat.o
+obj-$(CONFIG_KGDB) += kgdb.o
 
 obj-$(CONFIG_CRUNCH)   += crunch.o crunch-bits.o
 AFLAGS_crunch-bits.o   := -Wa,-mcpu=ep9312
diff --git a/arch/arm/kernel/kgdb.c b/arch/arm/kernel/kgdb.c
new file mode 100644
index 000..4f5b297
--- /dev/null
+++ b/arch/arm/kernel/kgdb.c
@@ -0,0 +1,219 @@
+/*
+ * arch/arm/kernel/kgdb.c
+ *
+ * ARM KGDB support
+ *
+ * Copyright (c) 2002-2004 MontaVista Software, Inc
+ * Copyright (c) 2008 Wind River Systems, Inc.
+ *
+ * Authors:  George Davis [EMAIL PROTECTED]
+ *   Deepak Saxena [EMAIL PROTECTED]
+ */
+#include linux/types.h
+#include linux/kernel.h
+#include linux/signal.h
+#include linux/sched.h
+#include linux/mm.h
+#include linux/spinlock.h
+#include linux/personality.h
+#include linux/ptrace.h
+#include linux/elf.h
+#include linux/interrupt.h
+#include linux/init.h
+#include linux/kgdb.h
+#include linux/io.h
+#include linux/uaccess.h
+#include linux/unistd.h
+
+#include asm/atomic.h
+#include asm/pgtable.h
+#include asm/system.h
+#include asm/traps.h
+
+/* Make a local copy of the registers passed into the handler (bletch) */
+void pt_regs_to_gdb_regs(unsigned long *gdb_regs, struct pt_regs *kernel_regs)
+{
+   int regno;
+
+   /* Initialize all to zero. */
+   for (regno = 0; regno  GDB_MAX_REGS; regno++)
+   gdb_regs[regno] = 0;
+
+   gdb_regs[_R0] = kernel_regs-ARM_r0;
+   gdb_regs[_R1] = kernel_regs-ARM_r1;
+   gdb_regs[_R2] = kernel_regs-ARM_r2;
+   gdb_regs[_R3] = kernel_regs-ARM_r3;
+   gdb_regs[_R4] = kernel_regs-ARM_r4;
+   gdb_regs[_R5] = kernel_regs-ARM_r5;
+   gdb_regs[_R6] = kernel_regs-ARM_r6;
+   gdb_regs[_R7] = kernel_regs-ARM_r7;
+   gdb_regs[_R8] = kernel_regs-ARM_r8;
+   gdb_regs[_R9] = kernel_regs-ARM_r9;
+   gdb_regs[_R10] = kernel_regs-ARM_r10;
+   gdb_regs[_FP] = kernel_regs-ARM_fp;
+   gdb_regs[_IP] = kernel_regs-ARM_ip;
+   gdb_regs[_SPT] = kernel_regs-ARM_sp;
+   gdb_regs[_LR] = kernel_regs-ARM_lr;
+   gdb_regs[_PC] = kernel_regs-ARM_pc;
+   gdb_regs[_CPSR] = kernel_regs-ARM_cpsr;
+}
+
+/* Copy local gdb registers back to kgdb regs, for later copy to kernel */
+void gdb_regs_to_pt_regs(unsigned long *gdb_regs, struct pt_regs *kernel_regs)
+{
+   kernel_regs-ARM_r0 = gdb_regs[_R0];
+   kernel_regs-ARM_r1 = gdb_regs[_R1];
+   kernel_regs-ARM_r2 = gdb_regs[_R2];
+   kernel_regs-ARM_r3 = gdb_regs[_R3];
+   kernel_regs-ARM_r4 = gdb_regs[_R4];
+   kernel_regs-ARM_r5 = gdb_regs[_R5];
+   kernel_regs-ARM_r6 = gdb_regs[_R6];
+   kernel_regs-ARM_r7 = gdb_regs[_R7];
+   kernel_regs-ARM_r8 = gdb_regs[_R8];
+   kernel_regs-ARM_r9 = gdb_regs[_R9];
+   kernel_regs-ARM_r10 = gdb_regs[_R10];
+   kernel_regs-ARM_fp = gdb_regs[_FP];
+   kernel_regs-ARM_ip = gdb_regs[_IP];
+   kernel_regs-ARM_sp = gdb_regs[_SPT];
+   kernel_regs-ARM_lr = gdb_regs[_LR];
+   kernel_regs-ARM_pc = gdb_regs[_PC];
+   kernel_regs-ARM_cpsr = gdb_regs[_CPSR];
+}
+
+void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs,
+

Re: [BUG] 2.6.25-rc2-mm1 - Kernel panic while bootup caused by signal_group_exit()

2008-02-20 Thread Rik van Riel

On Sun, 17 Feb 2008 09:40:33 +0530
Kamalesh Babulal [EMAIL PROTECTED] wrote:

 [   25.512919] BUG: unable to handle kernel paging request at 9d74e37b
 [   25.514926] IP: [c04a8fac] proc_flush_task+0x5b/0x223

I wonder if this one is related.   Also with 2.6.25-rc2-mm1 on x86_64:

BUG: unable to handle kernel paging request at 00200200
IP: [81043d3c] free_pid+0x35/0x90
PGD 43c00c067 PUD 43e5f1067 PMD 0 
Oops: 0002 [1] SMP 
last sysfs file: /sys/devices/pnp0/00:0b/id
CPU 7 
Modules linked in: dm_multipath qla2xxx bnx2 iTCO_wdt iTCO_vendor_support 
serio_raw rtc_cmos pcspkr watchdog_core scsi_transport_fc watchdog_dev 
i5000_edac edac_core button dcdbas joydev sg sr_mod cdrom usb_storage ata_piix 
libata dm_snapshot dm_zero dm_mirror dm_mod shpchp megaraid_sas sd_mod scsi_mod 
ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode]
Pid: 1992, comm: S05kudzu Not tainted 2.6.25-rc2-mm1 #4
RIP: 0010:[81043d3c]  [81043d3c] free_pid+0x35/0x90
RSP: 0018:81043c895e58  EFLAGS: 00010046
RAX:  RBX: 81043dd31440 RCX: 81043e5ffb08
RDX: 00200200 RSI: 0046 RDI: 
RBP: 81043b9703c0 R08:  R09: 0001
R10: 81043d1a R11:  R12: 81043e5ffac0
R13:  R14:  R15: 008cd530
FS:  7f68f99786f0() GS:81043e7100c0() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 00200200 CR3: 000436c1f000 CR4: 06e0
DR0:  DR1:  DR2: 
DR3:  DR6: 0ff0 DR7: 0400
Process S05kudzu (pid: 1992, threadinfo 81043c894000, task 81043b9acb40)
Stack:  81043dd31440 81043b9703c0 81043c84ae40 81035a6d
 81043b9703c0  07cd 810362b7
 81043c895f18 81051316  7fff01989514
Call Trace:
 [81035a6d] ? release_task+0x1be/0x346
 [810362b7] ? do_wait+0x6c2/0xa0e
 [81051316] ? trace_hardirqs_on_caller+0xf2/0x115
 [8102ac72] ? default_wake_function+0x0/0xe
 [81051316] ? trace_hardirqs_on_caller+0xf2/0x115
 [8103668d] ? sys_wait4+0x8a/0xa1
 [8100be3b] ? system_call_after_swapgs+0x7b/0x80

-- 
All Rights Reversed
--
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: [RFC] [PATCH] Fix b43 driver build for arm

2008-02-20 Thread Sam Ravnborg

On Wed, Feb 20, 2008 at 03:44:04PM +0100, Michael Buesch wrote:
On Wednesday 20 February 2008 01:44:38 Gordon Farquharson wrote:
Hi Michael

On Feb 19, 2008 3:41 AM, Michael Buesch [EMAIL PROTECTED] wrote:

[2]
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7492d4a416d68ab4bd254b36ffcc4e0138daa8ff

That doesn't cause me to magically sign off this sort of patches, too.
The sanity check is clearly broken in file2alias.c, as it checks something
from the target kernel against the host environment it is compiled on.
That doesn't make any sense at all.

I think that you make some good points, but I'm at a loss as to how to
fix the problem. Do you have any suggestions?

Remove the broken sanity check, if it's not possible the check there.
The check is valid for 99% of the kernel builds as
cross compile builds are not that typical.
And the check is there for the sake of modutils.

The details I do not remember.
So we have a few possiblities:

1) Remove the consistency check and try to deal with the
rare cases where it fails and spend many hours investigating
before we realise it is difference in layout of data.

2) Pad a few structures with a few bytes so this consitency
check works even in cross build environments.

3) Detect that we are doing cross builds and skip the check
in this case.

Option 1) is the worst of the three as that can cost
of many hours bug-hunting.
Option 3) may seem optimal but I do not like to add more
complexity to this part of the build. And really I do not
know a reliable way to detech when we do cross builds anyway.

Leaving us with option 2) that is simple, strighforward and harmless.

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: [PATCH] Tasklets: Avoid duplicating __tasklet_{,hi_}schedule() code

2008-02-20 Thread Ahmed S. Darwish

On Wed, Feb 20, 2008 at 03:20:52PM +0100, Dmitry Adamushko wrote:
 On 20/02/2008, Ahmed S. Darwish [EMAIL PROTECTED] wrote:
  On Wed, Feb 20, 2008 at 11:41:13AM +0100, Ingo Molnar wrote:
  
   * Ahmed S. Darwish [EMAIL PROTECTED] wrote:
  
  -   local_irq_disable();
  -   t-next = __get_cpu_var(tasklet_vec).list;
  -   __get_cpu_var(tasklet_vec).list = t;
  -   __raise_softirq_irqoff(TASKLET_SOFTIRQ);
  -   local_irq_enable();
  +   /* We were not lucky enough to run, reschedule. */
  +   __tasklet_schedule(t);

 i think there's a subtle difference that you missed: this one does
 __raise_softirq_irqoff(), while __tasklet_schedule() does a
 raise_softirq_irqoff(). (note the lack of undescores)

 the reason is to avoid infinitely self-activating tasklets.
   
Indeed, thanks a lot for the explanation. (maybe it's time to check
for new eyeglasses ;)).
  
   nah, it's rather subtle and the code looked good to me at first but i
   remembered that there was some small detail here to watch out for.
  
   i really dont like tasklets due to their many, arbitrary scheduling
   limitations, we should really use the turn tasklets into kthreads
   patch i posted last year.
  
 
  While we are at it, there's a small question that is bothering me
  for a while (and I'm really thankful for help).
 
  I keep reading that softirqs (and naturally, tasklets) got executed
  in interrupt context at the return from hardirq code path.
 
  Checking entry_32.S, I find no mentioning of softirqs on the return
  path (beginning from ret_from_intr: to restore_all: )
 
  The only invocation I'm able to find is from local_bh_enable() and
  from ksoftirqd/n threads (by calling do_softirq()). AFAIK, both
  invocations occur in a _nont-interrupt_ context (exception context).
 
  So, where does the interrupt-context tasklets invocation really
  occur ?
 
 Look at irq_exit() in softirq.c.
 
 The common sequence is ... - do_IRQ() -- irq_exit() -- invoke_softirq()
 
 

Great, this was the last missing block in my understanding of softirqs :).
Thank you.

[btw, your MUA broke the CC list]

-- 
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.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/

[patch 1/3] m32r: cleanup - drop .data.idt section in vmlinux.lds script

The section .data.idt is not used at all - so drop it.

Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED]
---

 vmlinux.lds.S |3 ---
 1 file changed, 3 deletions(-)

Index: linux-2.6.git/arch/m32r/kernel/vmlinux.lds.S
===
--- linux-2.6.git.orig/arch/m32r/kernel/vmlinux.lds.S   2008-02-10 
10:46:37.0 +0300
+++ linux-2.6.git/arch/m32r/kernel/vmlinux.lds.S2008-02-20 
22:23:46.0 +0300
@@ -60,9 +60,6 @@ SECTIONS
   . = ALIGN(4096);
   __nosave_end = .;
 
-  . = ALIGN(4096);
-  .data.page_aligned : { *(.data.idt) }
-
   . = ALIGN(32);
   .data.cacheline_aligned : { *(.data.cacheline_aligned) }
 

-- 
--
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/3] s390: cleanup - drop .data.idt section in vmlinux.lds script

The section .data.idt is not used at all - so drop it.

Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED]
---

 vmlinux.lds.S |5 -
 1 file changed, 5 deletions(-)

Index: linux-2.6.git/arch/s390/kernel/vmlinux.lds.S
===
--- linux-2.6.git.orig/arch/s390/kernel/vmlinux.lds.S   2008-02-06 
23:15:14.0 +0300
+++ linux-2.6.git/arch/s390/kernel/vmlinux.lds.S2008-02-20 
22:30:30.0 +0300
@@ -71,11 +71,6 @@ SECTIONS
. = ALIGN(PAGE_SIZE);
__nosave_end = .;
 
-   . = ALIGN(PAGE_SIZE);
-   .data.page_aligned : {
-   *(.data.idt)
-   }
-
. = ALIGN(0x100);
.data.cacheline_aligned : {
*(.data.cacheline_aligned)

-- 
--
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/3] eliminate .data.idt section for the archs which do not use it

This patch series do a small clean up over vmlinux.lds script for several
architectures where the section .data.idt is not used.

Please review.
Thanks.

- Cyrill -

-- 
--
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/3] mn10300: cleanup - drop .data.idt section in vmlinux.lds script

The section .data.idt is not used at all - so drop it.

Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED]
---

 vmlinux.lds.S |3 ---
 1 file changed, 3 deletions(-)

Index: linux-2.6.git/arch/mn10300/kernel/vmlinux.lds.S
===
--- linux-2.6.git.orig/arch/mn10300/kernel/vmlinux.lds.S2008-02-10 
10:46:37.0 +0300
+++ linux-2.6.git/arch/mn10300/kernel/vmlinux.lds.S 2008-02-20 
22:26:01.0 +0300
@@ -61,9 +61,6 @@ SECTIONS
   . = ALIGN(4096);
   __nosave_end = .;
 
-  . = ALIGN(4096);
-  .data.page_aligned : { *(.data.idt) }
-
   . = ALIGN(32);
   .data.cacheline_aligned : { *(.data.cacheline_aligned) }
 

-- 
--
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: [QUESTION] FRV: linking error?

2008-02-20 Thread Cyrill Gorcunov

[Sam Ravnborg - Wed, Feb 20, 2008 at 08:19:38PM +0100]
| On Wed, Feb 20, 2008 at 09:15:00PM +0300, Cyrill Gorcunov wrote:
|  [David Howells - Wed, Feb 20, 2008 at 06:13:15PM +]
|  | Cyrill Gorcunov [EMAIL PROTECTED] wrote:
|  | 
|  |  Sam, maybe we should just eliminate this section at least for FRV?
|  | 
|  | You should have a patch in your inbox to do just that.
|  | 
|  | David
|  | 
|  
|  Thanks David! I've got them all.
|  I think Sam will take care of them to be included in mainline.
| 
| arch stuff like this is preferably going via the arch maintainer.
| Sometimes I do all-arch patches but when they are independent
| like this one they should go via the arch maintainer.
| 
| Cyrill - I would like you to do the same cleanup for
| m32r + mn10300 + s390
| and send the patch to the respective maintainers with a cc to me.
| 
| Thanks,
|   Sam
| 

ok, I will do it

- Cyrill -
--
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: USB regression (and other failures) in 2.6.2[45]* - mostly resolved

2008-02-20 Thread Alan Stern

On Wed, 20 Feb 2008, Andrew Buehler wrote:

 In other words: I don't think that's likely to be practical in the
 present instance. If you have reason to believe otherwise (past positive
 experience with Novell, for instance), I'd be glad to hear it.

Greg KH may be able to help in that respect.

 Is there any place (aside from maybe the kernel changelog, which
 contains a whole lot - if not several lots - of unrelated information)
 where I could find a list of config-symbol name additions, changes,
 deletions and meaning changes by version or by date? That would at least
 let me build a mapping between the symbols in the older config and the
 ones in the new one, which is about where I would have to start.

Not as far as I know.

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: [PATCH] x86: add the debugfs interface for the sysprof tool

2008-02-20 Thread Arjan van de Ven

On Wed, 20 Feb 2008 19:53:42 +0100
Peter Zijlstra [EMAIL PROTECTED] wrote:

 
 On Wed, 2008-02-20 at 10:39 -0800, Arjan van de Ven wrote:
  On Wed, 20 Feb 2008 19:16:15 +0100
  Peter Zijlstra [EMAIL PROTECTED] wrote:
  
   
   On Tue, 2008-02-19 at 12:37 -0800, Arjan van de Ven wrote:
From: Soren Sandmann [EMAIL PROTECTED]
Subject: [PATCH] x86: add the debugfs interface for the sysprof
tool

The sysprof tool is a very easy to use GUI tool to find out
where userspace is spending CPU time. See
http://www.daimi.au.dk/~sandmann/sysprof/
for more information and screenshots on this tool.

Sysprof needs a 200 line kernel module to do it's work, this
module puts some simple profiling data into debugfs.
   
   What is the added value over oprofile?
  
  it actually works and is usable by humans ;)
 
 # sysprof
 
 (sysprof:12480): Gtk-WARNING **: cannot open display:
 
 -ENOX
 
  what oprofile doesn't do is the nice userland hierarchy of where
  cpu time is spend. (and that is also what makes it mostly useless
  in practice)
 
 so why not fix oprofile callgraph output and build a GUI on top of
 oprofile for those of us who really want RSI from mouse movement :-)

feel free to reinvent a whole GUI just to avoid a 200 line kernel module.
sysprof is here. it works. the gui is REALLY nice.
I think it's the wrong tradeoff though... oprofile exists for how long?


-- 
If you want to reach me at my work email, use [EMAIL PROTECTED]
For development, discussion and tips for power savings, 
visit http://www.lesswatts.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: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
 On Feb 21, 2008 2:53 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
   So, next I'll try shutdown to see if it work. I was using platform.
 
  Ok, that would be good to try.

 shutdown does power down properly. But still green on resume.

Ok, so Linus' theory about something later in the resume path trying to touch 
video is looking good.

Rafael, is there anyway to prevent the device shutdown in the hibernate path?

  Looks like the AR registers are hosed, which is what I thought I fixed...
   Can you attach your i915_drv.c file just so I can sanity check it?

 Attached.

Hm, looks right.  Let me see if I can reproduce this on my T61.

Thanks,
Jesse
--
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] 2.6.25-rc2-mm1 - Kernel panic while bootup caused by signal_group_exit()

2008-02-20 Thread Oleg Nesterov

On 02/20, Rik van Riel wrote:

 On Sun, 17 Feb 2008 09:40:33 +0530
 Kamalesh Babulal [EMAIL PROTECTED] wrote:
 
  [   25.512919] BUG: unable to handle kernel paging request at 9d74e37b
  [   25.514926] IP: [c04a8fac] proc_flush_task+0x5b/0x223
 
 I wonder if this one is related.   Also with 2.6.25-rc2-mm1 on x86_64:
 
 BUG: unable to handle kernel paging request at 00200200
 IP: [81043d3c] free_pid+0x35/0x90
 ...
 Call Trace:
  [81035a6d] ? release_task+0x1be/0x346
  [810362b7] ? do_wait+0x6c2/0xa0e
  [81051316] ? trace_hardirqs_on_caller+0xf2/0x115
  [8102ac72] ? default_wake_function+0x0/0xe
  [81051316] ? trace_hardirqs_on_caller+0xf2/0x115
  [8103668d] ? sys_wait4+0x8a/0xa1
  [8100be3b] ? system_call_after_swapgs+0x7b/0x80

Yes, please look at http://marc.info/?t=12030984056

Btw. The bug in tty_io.c _can_ explain this trace, but it would be nice
to ensure we don't have other problems. Could you try this

http://marc.info/?l=linux-kernelm=120352655031911

patch?

(I can't understand why this happens at the boot time, and it is not
 reproducable on my side).

Oleg.

--
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.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

On Wednesday, February 20, 2008 11:18 am Jesse Barnes wrote:
 On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
  On Feb 21, 2008 2:53 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
So, next I'll try shutdown to see if it work. I was using
platform.
  
   Ok, that would be good to try.
 
  shutdown does power down properly. But still green on resume.

 Ok, so Linus' theory about something later in the resume path trying to
 touch video is looking good.

 Rafael, is there anyway to prevent the device shutdown in the hibernate
 path?

Given the way the PM core works, do we need to set a flag like this?  I really 
hope there's a better way of doing this...

Thanks,
Jesse

diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
index 4048f39..a2d6242 100644
--- a/drivers/char/drm/i915_drv.c
+++ b/drivers/char/drm/i915_drv.c
@@ -238,6 +238,13 @@ static void i915_restore_vga(struct drm_device *dev)
 
 }
 
+/*
+ * If we're doing a suspend to disk, we don't want to power off the device.
+ * Unfortunately, the PM core doesn't tell us if we're headed for a regular
+ * S3 state or that it's about to shut down the machine, so we use this flag.
+ */
+static int i915_hibernate;
+
 static int i915_suspend(struct drm_device *dev, pm_message_t state)
 {
struct drm_i915_private *dev_priv = dev-dev_private;
@@ -252,6 +259,9 @@ static int i915_suspend(struct drm_device *dev, 
pm_message_t state)
if (state.event == PM_EVENT_PRETHAW)
return 0;
 
+   if (state.event == PM_EVENT_FREEZE)
+   i915_hibernate = 1;
+
pci_save_state(dev-pdev);
pci_read_config_byte(dev-pdev, LBB, dev_priv-saveLBB);
 
@@ -366,7 +376,7 @@ static int i915_suspend(struct drm_device *dev, 
pm_message_t state)
 
i915_save_vga(dev);
 
-   if (state.event == PM_EVENT_SUSPEND) {
+   if (!i915_hibernate) {
/* Shut down the device */
pci_disable_device(dev-pdev);
pci_set_power_state(dev-pdev, PCI_D3hot);
@@ -385,6 +395,8 @@ static int i915_resume(struct drm_device *dev)
if (pci_enable_device(dev-pdev))
return -1;
 
+   i915_hibernate = 0;
+
pci_write_config_byte(dev-pdev, LBB, dev_priv-saveLBB);
 
/* Pipe  plane A info */
--
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] nfs: fix sparse warning in nfs4state.c

fs/nfs/nfs4state.c:788:34: warning: Using plain integer as NULL pointer

Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
 fs/nfs/nfs4state.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index 6233eb5..b962397 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -785,7 +785,7 @@ static int nfs4_reclaim_locks(struct 
nfs4_state_recovery_ops *ops, struct nfs4_s
struct file_lock *fl;
int status = 0;
 
-   for (fl = inode-i_flock; fl != 0; fl = fl-fl_next) {
+   for (fl = inode-i_flock; fl != NULL; fl = fl-fl_next) {
if (!(fl-fl_flags  (FL_POSIX|FL_FLOCK)))
continue;
if (nfs_file_open_context(fl-fl_file)-state != state)
-- 
1.5.4.2.200.g99e75


--
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/4] nfs: fix sparse warning in delegation.c

fs/nfs/delegation.c:52:34: warning: Using plain integer as NULL pointer

Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
 fs/nfs/delegation.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c
index b9eadd1..00a5e44 100644
--- a/fs/nfs/delegation.c
+++ b/fs/nfs/delegation.c
@@ -49,7 +49,7 @@ static int nfs_delegation_claim_locks(struct nfs_open_context 
*ctx, struct nfs4_
struct file_lock *fl;
int status;
 
-   for (fl = inode-i_flock; fl != 0; fl = fl-fl_next) {
+   for (fl = inode-i_flock; fl != NULL; fl = fl-fl_next) {
if (!(fl-fl_flags  (FL_POSIX|FL_FLOCK)))
continue;
if (nfs_file_open_context(fl-fl_file) != ctx)
-- 
1.5.4.2.200.g99e75


--
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/4] nfs: fix sparse warning in idmap.c

fs/nfs/idmap.c:312:12: warning: Using plain integer as NULL pointer

Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
 fs/nfs/idmap.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/fs/nfs/idmap.c b/fs/nfs/idmap.c
index 8ae5dba..86147b0 100644
--- a/fs/nfs/idmap.c
+++ b/fs/nfs/idmap.c
@@ -309,7 +309,7 @@ nfs_idmap_name(struct idmap *idmap, struct idmap_hashtable 
*h,
mutex_lock(idmap-idmap_im_lock);
 
he = idmap_lookup_id(h, id);
-   if (he != 0) {
+   if (he) {
memcpy(name, he-ih_name, he-ih_namelen);
ret = he-ih_namelen;
goto out;
-- 
1.5.4.2.200.g99e75


--
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] firewire: fix NULL pointer deref. and resource leak

2008-02-20 Thread Stefan Richter

By supplying ioctl()s in the wrong order, a userspace client was able to
trigger NULL pointer dereferences.  Furthermore, by calling
ioctl_create_iso_context more than once, new contexts could be created
without ever freeing the previously created contexts.

Thanks to Anders Blomdell for the report.

Signed-off-by: Stefan Richter [EMAIL PROTECTED]
---
 drivers/firewire/fw-cdev.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

Index: linux/drivers/firewire/fw-cdev.c
===
--- linux.orig/drivers/firewire/fw-cdev.c
+++ linux/drivers/firewire/fw-cdev.c
@@ -646,6 +646,10 @@ static int ioctl_create_iso_context(stru
struct fw_cdev_create_iso_context *request = buffer;
struct fw_iso_context *context;
 
+   /* We only support one context at this time. */
+   if (client-iso_context != NULL)
+   return -EBUSY;
+
if (request-channel  63)
return -EINVAL;
 
@@ -792,8 +796,9 @@ static int ioctl_start_iso(struct client
 {
struct fw_cdev_start_iso *request = buffer;
 
-   if (request-handle != 0)
+   if (client-iso_context == NULL || request-handle != 0)
return -EINVAL;
+
if (client-iso_context-type == FW_ISO_CONTEXT_RECEIVE) {
if (request-tags == 0 || request-tags  15)
return -EINVAL;
@@ -810,7 +815,7 @@ static int ioctl_stop_iso(struct client 
 {
struct fw_cdev_stop_iso *request = buffer;
 
-   if (request-handle != 0)
+   if (client-iso_context == NULL || request-handle != 0)
return -EINVAL;
 
return fw_iso_context_stop(client-iso_context);

-- 
Stefan Richter
-=-==--- --=- =-=--
http://arcgraph.de/sr/

--
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] nfs: fix sparse warnings in callback_xdr.c

fs/nfs/callback_xdr.c:257:6: warning: Using plain integer as NULL pointer
fs/nfs/callback_xdr.c:270:6: warning: Using plain integer as NULL pointer
fs/nfs/callback_xdr.c:281:6: warning: Using plain integer as NULL pointer

Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
---
 fs/nfs/callback_xdr.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/nfs/callback_xdr.c b/fs/nfs/callback_xdr.c
index c63eb72..13619d2 100644
--- a/fs/nfs/callback_xdr.c
+++ b/fs/nfs/callback_xdr.c
@@ -254,7 +254,7 @@ static __be32 encode_attr_change(struct xdr_stream *xdr, 
const uint32_t *bitmap,
if (!(bitmap[0]  FATTR4_WORD0_CHANGE))
return 0;
p = xdr_reserve_space(xdr, 8);
-   if (unlikely(p == 0))
+   if (unlikely(!p))
return htonl(NFS4ERR_RESOURCE);
p = xdr_encode_hyper(p, change);
return 0;
@@ -267,7 +267,7 @@ static __be32 encode_attr_size(struct xdr_stream *xdr, 
const uint32_t *bitmap, u
if (!(bitmap[0]  FATTR4_WORD0_SIZE))
return 0;
p = xdr_reserve_space(xdr, 8);
-   if (unlikely(p == 0))
+   if (unlikely(!p))
return htonl(NFS4ERR_RESOURCE);
p = xdr_encode_hyper(p, size);
return 0;
@@ -278,7 +278,7 @@ static __be32 encode_attr_time(struct xdr_stream *xdr, 
const struct timespec *ti
__be32 *p;
 
p = xdr_reserve_space(xdr, 12);
-   if (unlikely(p == 0))
+   if (unlikely(!p))
return htonl(NFS4ERR_RESOURCE);
p = xdr_encode_hyper(p, time-tv_sec);
*p = htonl(time-tv_nsec);
-- 
1.5.4.2.200.g99e75

--
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] documentation: fix firmware_sample_firmware_class to build

2008-02-20 Thread Randy Dunlap


Greg KH wrote:

On Mon, Feb 18, 2008 at 04:22:16PM -0800, Randy Dunlap wrote:

From: Randy Dunlap [EMAIL PROTECTED]

Fix firmware_sample_firmware_class module to build without error.
sysfs.h already has the function prototypes and has them correctly.

Documentation/firmware_class/firmware_sample_firmware_class.c:37: error: 
conflicting types for 'sysfs_remove_bin_file'
include/linux/sysfs.h:100: error: previous declaration of 
'sysfs_remove_bin_file' was here

Signed-off-by: Randy Dunlap [EMAIL PROTECTED]
---
 Documentation/firmware_class/firmware_sample_firmware_class.c |3 ---
 1 file changed, 3 deletions(-)


Can we move this file to the samples/ directory, so the build will catch
stuff like this?

What's the final version of this patch?


I've moved it to samples/, but it (still) has a build problem:

ERROR: firmware_class 
[samples/firmware_class/firmware_sample_firmware_class.ko] undefined!

Can you give me hint(s) about how to fix that?

--
~Randy
--
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-kernel] Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver

2008-02-20 Thread David P. Reed

Actually, disparaging things as one idiotic system doesn't seem like a 
long-term thoughtful process - it's not even accurate.  There are more 
such systems that are running code today than the total number of 486 
systems ever manufactured.  The production rate is $1M/month.


a) ENE chips are documented to receive port 80, and also it is the 
case that modern chipsets will happily diagnose writes to non-existent 
ports as MCE's.   Using side effects that depend on non-existent ports 
just creates a brittle failure mode down the road.  And it's not just 
post ACPI initialization.   The pcspkr use of port 80 caused solid 
freezes if you typed tab to complete a command line and there were 
more than one choice, leading to beeps.


b) sad to say, Linux is not what hardware vendors use as the system that 
their BIOSes MUST work with.  That's Windows, and Windows, whether we 
like it or not does not require hardware vendors to stay away from port 80.


IMHO, calling something idiotic is hardly evidence-based decision 
making.   Maybe you love to hate Microsoft, but until Intel writes an 
architecture standard that says explicitly that a standard PC must not 
use port 80 for any peripheral, the port 80 thing is folklore, and one 
that is solely Linux-defined.


Rene Herman wrote:

On 20-02-08 18:05, H. Peter Anvin wrote:
 

Rene Herman wrote:


_Something_ like this would seem to be the only remaining option. It 
seems fairly unuseful to #ifdef around that switch statement for 
kernels without support for the earlier families, but if you insist...




Only remaining option other than the one we've had all along.  Even 
on the one idiotic set of systems which break, it only breaks 
post-ACPI intialization, IIRC.


Linus vetoed the DMI switch.

Rene.


--
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.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

2008-02-20 Thread Rafael J. Wysocki

On Wednesday, 20 of February 2008, Jesse Barnes wrote:
 On Wednesday, February 20, 2008 11:18 am Jesse Barnes wrote:
  On Wednesday, February 20, 2008 11:10 am Jeff Chua wrote:
   On Feb 21, 2008 2:53 AM, Jesse Barnes [EMAIL PROTECTED] wrote:
 So, next I'll try shutdown to see if it work. I was using
 platform.
   
Ok, that would be good to try.
  
   shutdown does power down properly. But still green on resume.
 
  Ok, so Linus' theory about something later in the resume path trying to
  touch video is looking good.
 
  Rafael, is there anyway to prevent the device shutdown in the hibernate
  path?
 
 Given the way the PM core works, do we need to set a flag like this?  I 
 really 
 hope there's a better way of doing this...

I think we should export the target sleep state somehow.

 diff --git a/drivers/char/drm/i915_drv.c b/drivers/char/drm/i915_drv.c
 index 4048f39..a2d6242 100644
 --- a/drivers/char/drm/i915_drv.c
 +++ b/drivers/char/drm/i915_drv.c
 @@ -238,6 +238,13 @@ static void i915_restore_vga(struct drm_device *dev)
  
  }
  
 +/*
 + * If we're doing a suspend to disk, we don't want to power off the device.
 + * Unfortunately, the PM core doesn't tell us if we're headed for a regular
 + * S3 state or that it's about to shut down the machine, so we use this flag.
 + */
 +static int i915_hibernate;
 +
  static int i915_suspend(struct drm_device *dev, pm_message_t state)
  {
   struct drm_i915_private *dev_priv = dev-dev_private;
 @@ -252,6 +259,9 @@ static int i915_suspend(struct drm_device *dev, 
 pm_message_t state)
   if (state.event == PM_EVENT_PRETHAW)
   return 0;
  
 + if (state.event == PM_EVENT_FREEZE)
 + i915_hibernate = 1;
 +
   pci_save_state(dev-pdev);
   pci_read_config_byte(dev-pdev, LBB, dev_priv-saveLBB);
  
 @@ -366,7 +376,7 @@ static int i915_suspend(struct drm_device *dev, 
 pm_message_t state)
  
   i915_save_vga(dev);
  
 - if (state.event == PM_EVENT_SUSPEND) {
 + if (!i915_hibernate) {
   /* Shut down the device */
   pci_disable_device(dev-pdev);
   pci_set_power_state(dev-pdev, PCI_D3hot);
 @@ -385,6 +395,8 @@ static int i915_resume(struct drm_device *dev)
   if (pci_enable_device(dev-pdev))
   return -1;
  
 + i915_hibernate = 0;
 +
   pci_write_config_byte(dev-pdev, LBB, dev_priv-saveLBB);
  
   /* Pipe  plane A info */

Then, the .resume() called after the image creation will clear the flag and I
don't think it's safe to allow it to survive i915_resume() ...

Thanks,
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: [PATCH 00/37] Permit filesystem local caching

2008-02-20 Thread Serge E. Hallyn

Quoting David Howells ([EMAIL PROTECTED]):
 
 
 These patches add local caching for network filesystems such as NFS.
 
 The patches can roughly be broken down into a number of sets:
 
   (*) 01-keys-inc-payload.diff
   (*) 02-keys-search-keyring.diff
   (*) 03-keys-callout-blob.diff
 
   Three patches to the keyring code made to help the CIFS people.
   Included because of patches 05-08.
 
   (*) 04-keys-get-label.diff
 
   A patch to allow the security label of a key to be retrieved.
   Included because of patches 05-08.
 
   (*) 05-security-current-fsugid.diff
   (*) 06-security-separate-task-bits.diff

Seems *really* weird that every time you send this, patch 6 doesn't seem
to reach me in any of my mailboxes...  (did get it from the url
you listed)

I'm sorry if I miss where you explicitly state this, but is it safe to
assume, as perusing the patches suggests, that

1. tsk-sec never changes other than in task_alloc_security()?  

2. tsk-act_as is only ever dereferenced from (a) current-
   except (b) in do_coredump?

(thereby carefully avoiding locking issues)

I'd still like to see some performance numbers.  Not to object to
these patches, just to make sure there's no need to try and optimize
more of the dereferences away when they're not needed.

Oh, manually copied from patch 6, I see you have in the task_security
struct definition:

kernel_cap_tcap_bset;   /* ? */

That comment can be filled in with 'capability bounding set' (for this
task and all its future descendents).

thanks,
-serge

   (*) 07-security-subjective.diff
   (*) 08-security-kernel_service-class.diff
   (*) 09-security-kernel-service.diff
   (*) 10-security-nfsd.diff
 
   Patches to permit the subjective security of a task to be overridden.
   All the security details in task_struct are decanted into a new struct
   that task_struct then has two pointers two: one that defines the
   objective security of that task (how other tasks may affect it) and one
   that defines the subjective security (how it may affect other objects).
 
   Note that I have dropped the idea of struct cred for the moment.  With
   the amount of stuff that was excluded from it, it wasn't actually any
   use to me.  However, it can be added later.
 
   Required for cachefiles.
 
   (*) 11-release-page.diff
   (*) 12-fscache-page-flags.diff
   (*) 13-add_wait_queue_tail.diff
   (*) 14-fscache.diff
 
   Patches to provide a local caching facility for network filesystems.
 
   (*) 15-cachefiles-ia64.diff
   (*) 16-cachefiles-ext3-f_mapping.diff
   (*) 17-cachefiles-write.diff
   (*) 18-cachefiles-monitor.diff
   (*) 19-cachefiles-export.diff
   (*) 20-cachefiles.diff
 
   Patches to provide a local cache in a directory of an already mounted
   filesystem.
 
   (*) 21-nfs-comment.diff
   (*) 22-nfs-fscache-option.diff
   (*) 23-nfs-fscache-kconfig.diff
   (*) 24-nfs-fscache-top-index.diff
   (*) 25-nfs-fscache-server-obj.diff
   (*) 26-nfs-fscache-super-obj.diff
   (*) 27-nfs-fscache-inode-obj.diff
   (*) 28-nfs-fscache-use-inode.diff
   (*) 29-nfs-fscache-invalidate-pages.diff
   (*) 30-nfs-fscache-iostats.diff
   (*) 31-nfs-fscache-page-management.diff
   (*) 32-nfs-fscache-read-context.diff
   (*) 33-nfs-fscache-read-fallback.diff
   (*) 34-nfs-fscache-read-from-cache.diff
   (*) 35-nfs-fscache-store-to-cache.diff
   (*) 36-nfs-fscache-mount.diff
   (*) 37-nfs-fscache-display.diff
 
   Patches to provide NFS with local caching.
 
   A couple of questions on the NFS iostat changes: (1) Should I update the
   iostat version number; (2) is it permitted to have conditional iostats?
 
 
 I've brought the patchset up to date with respect to the 2.6.25-rc1 merge
 window, in particular altering Smack to handle the split in objective and
 subjective security in the task_struct.
 
 --
 A tarball of the patches is available at:
 
   
 http://people.redhat.com/~dhowells/fscache/patches/nfs+fscache-30.tar.bz2
 
 
 To use this version of CacheFiles, the cachefilesd-0.9 is also required.  It
 is available as an SRPM:
 
   http://people.redhat.com/~dhowells/fscache/cachefilesd-0.9-1.fc7.src.rpm
 
 Or as individual bits:
 
   http://people.redhat.com/~dhowells/fscache/cachefilesd-0.9.tar.bz2
   http://people.redhat.com/~dhowells/fscache/cachefilesd.fc
   http://people.redhat.com/~dhowells/fscache/cachefilesd.if
   http://people.redhat.com/~dhowells/fscache/cachefilesd.te
   http://people.redhat.com/~dhowells/fscache/cachefilesd.spec
 
 The .fc, .if and .te files are for manipulating SELinux.
 
 David
 -
 To unsubscribe from this list: send the line unsubscribe linux-fsdevel 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

[PATCH 1/2] ide: fix enabling DMA on it821x in smart mode

2008-02-20 Thread Bartlomiej Zolnierkiewicz

ide_tune_dma() should return '1' if IDE_HFLAG_NO_SET_MODE host flag is set.

Cc: Sergei Shtylyov [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
I wonder how this could have slipped in :(

Sergei, please double-check this patch.  Thanks!

 drivers/ide/ide-dma.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: b/drivers/ide/ide-dma.c
===
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -757,7 +757,7 @@ static int ide_tune_dma(ide_drive_t *dri
}
 
if (hwif-host_flags  IDE_HFLAG_NO_SET_MODE)
-   return 0;
+   return 1;
 
if (ide_set_dma_mode(drive, speed))
return 0;
--
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] ide: remove IDE_HFLAG_CY82C693 host flag

2008-02-20 Thread Bartlomiej Zolnierkiewicz

Sergei suggested that it shouldn't be necessary + it had no effect
anyway since ide_id_dma_bug() is called earlier in ide_tune_dma().

Cc: Sergei Shtylyov [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
I went ahead since I urgently needed to re-cycle one host flag.

 drivers/ide/ide-dma.c  |   10 ++
 drivers/ide/pci/cy82c693.c |2 +-
 include/linux/ide.h|2 --
 3 files changed, 3 insertions(+), 11 deletions(-)

Index: b/drivers/ide/ide-dma.c
===
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -747,14 +747,8 @@ static int ide_tune_dma(ide_drive_t *dri
 
speed = ide_max_dma_mode(drive);
 
-   if (!speed) {
-/* is this really correct/needed? */
-   if ((hwif-host_flags  IDE_HFLAG_CY82C693) 
-   ide_dma_good_drive(drive))
-   return 1;
-   else
-   return 0;
-   }
+   if (!speed)
+   return 0;
 
if (hwif-host_flags  IDE_HFLAG_NO_SET_MODE)
return 1;
Index: b/drivers/ide/pci/cy82c693.c
===
--- a/drivers/ide/pci/cy82c693.c
+++ b/drivers/ide/pci/cy82c693.c
@@ -410,7 +410,7 @@ static const struct ide_port_info cy82c6
.init_iops  = init_iops_cy82c693,
.init_hwif  = init_hwif_cy82c693,
.chipset= ide_cy82c693,
-   .host_flags = IDE_HFLAG_SINGLE | IDE_HFLAG_CY82C693,
+   .host_flags = IDE_HFLAG_SINGLE,
.pio_mask   = ATA_PIO4,
.swdma_mask = ATA_SWDMA2,
.mwdma_mask = ATA_MWDMA2,
Index: b/include/linux/ide.h
===
--- a/include/linux/ide.h
+++ b/include/linux/ide.h
@@ -1089,8 +1089,6 @@ enum {
/* unmask IRQs */
IDE_HFLAG_UNMASK_IRQS   = (1  25),
IDE_HFLAG_ABUSE_SET_DMA_MODE= (1  26),
-   /* host is CY82C693 */
-   IDE_HFLAG_CY82C693  = (1  27),
/* force host out of simplex mode */
IDE_HFLAG_CLEAR_SIMPLEX = (1  28),
/* DSC overlap is unsupported */
--
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] amiserial: Prepare for locking relaxation in caller.


Just wrap this one in a lock_kernel. As I understand it there is no M68K
SMP anyway.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/amiserial.c 
linux-2.6.25-rc2-mm1/drivers/char/amiserial.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/amiserial.c   2008-02-19 
11:01:44.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/amiserial.c   2008-02-20 
11:45:28.0 +
@@ -1074,6 +1074,7 @@
if (!retinfo)
return -EFAULT;
memset(tmp, 0, sizeof(tmp));
+   lock_kernel();
tmp.type = state-type;
tmp.line = state-line;
tmp.port = state-port;
@@ -1084,6 +1085,7 @@
tmp.close_delay = state-close_delay;
tmp.closing_wait = state-closing_wait;
tmp.custom_divisor = state-custom_divisor;
+   unlock_kernel();
if (copy_to_user(retinfo,tmp,sizeof(*retinfo)))
return -EFAULT;
return 0;
@@ -1099,13 +1101,17 @@
 
if (copy_from_user(new_serial,new_info,sizeof(new_serial)))
return -EFAULT;
+   
+   lock_kernel();
state = info-state;
old_state = *state;
   
change_irq = new_serial.irq != state-irq;
change_port = (new_serial.port != state-port);
-   if(change_irq || change_port || (new_serial.xmit_fifo_size != 
state-xmit_fifo_size))
+   if(change_irq || change_port || (new_serial.xmit_fifo_size != 
state-xmit_fifo_size)) {
+ unlock_kernel();
  return -EINVAL;
+   }
   
if (!serial_isroot()) {
if ((new_serial.baud_base != state-baud_base) ||
@@ -1122,8 +1128,10 @@
goto check_and_exit;
}
 
-   if (new_serial.baud_base  9600)
+   if (new_serial.baud_base  9600) {
+   unlock_kernel();
return -EINVAL;
+   }
 
/*
 * OK, past this point, all the error checking has been done.
@@ -1157,6 +1165,7 @@
}
} else
retval = startup(info);
+   unlock_kernel();
return retval;
 }
 
--
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] cyclades: Prepare for relaxed locking in callers

Basically wrap it in lock_kernel where it is hard to prove the locking is
ok. 

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/cyclades.c 
linux-2.6.25-rc2-mm1/drivers/char/cyclades.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/cyclades.c2008-02-19 
11:01:43.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/cyclades.c2008-02-20 
11:45:28.0 +
@@ -3464,6 +3464,8 @@
if (serial_paranoia_check(info, tty-name, __FUNCTION__))
return -ENODEV;
 
+   lock_kernel();
+   
card = info-card;
channel = info-line - card-first_line;
if (!IS_CYC_Z(*card)) {
@@ -3506,10 +3508,12 @@
((lstatus  C_RS_CTS) ? TIOCM_CTS : 0);
} else {
result = 0;
+   unlock_kernel();
return -ENODEV;
}
 
}
+   unlock_kernel();
return result;
 }  /* cy_tiomget */
 
@@ -3880,6 +3884,7 @@
printk(KERN_DEBUG cyc:cy_ioctl ttyC%d, cmd = %x arg = %lx\n,
info-line, cmd, arg);
 #endif
+   lock_kernel();
 
switch (cmd) {
case CYGETMON:
@@ -3988,47 +3993,47 @@
p_cuser = argp;
ret_val = put_user(cnow.cts, p_cuser-cts);
if (ret_val)
-   return ret_val;
+   break;
ret_val = put_user(cnow.dsr, p_cuser-dsr);
if (ret_val)
-   return ret_val;
+   break;
ret_val = put_user(cnow.rng, p_cuser-rng);
if (ret_val)
-   return ret_val;
+   break;
ret_val = put_user(cnow.dcd, p_cuser-dcd);
if (ret_val)
-   return ret_val;
+   break;
ret_val = put_user(cnow.rx, p_cuser-rx);
if (ret_val)
-   return ret_val;
+   break;
ret_val = put_user(cnow.tx, p_cuser-tx);
if (ret_val)
-   return ret_val;
+   break;
ret_val = put_user(cnow.frame, p_cuser-frame);
if (ret_val)
-   return ret_val;
+   break;
ret_val = put_user(cnow.overrun, p_cuser-overrun);
if (ret_val)
-   return ret_val;
+   break;
ret_val = put_user(cnow.parity, p_cuser-parity);
if (ret_val)
-   return ret_val;
+   break;
ret_val = put_user(cnow.brk, p_cuser-brk);
if (ret_val)
-   return ret_val;
+   break;
ret_val = put_user(cnow.buf_overrun, p_cuser-buf_overrun);
if (ret_val)
-   return ret_val;
+   break;
ret_val = 0;
break;
default:
ret_val = -ENOIOCTLCMD;
}
+   unlock_kernel();
 
 #ifdef CY_DEBUG_OTHER
printk(KERN_DEBUG cyc:cy_ioctl done\n);
 #endif
-
return ret_val;
 }  /* cy_ioctl */
 
--
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] lguest: fix undefined asm-offsets symbols

2008-02-20 Thread Kyle McMartin

lguest uses asm-offsets to generate ... offsets, obviously, for use
in the lguest switcher code. When the hypervisor code is built as a
module though, the asm offsets it needs won't be generated since
CONFIG_LGUEST will be undefined.

Signed-off-by: Kyle McMartin [EMAIL PROTECTED]

---
diff --git a/arch/x86/kernel/asm-offsets_32.c b/arch/x86/kernel/asm-offsets_32.c
index a33d530..44bafdd 100644
--- a/arch/x86/kernel/asm-offsets_32.c
+++ b/arch/x86/kernel/asm-offsets_32.c
@@ -134,7 +134,7 @@ void foo(void)
OFFSET(LGUEST_DATA_pgdir, lguest_data, pgdir);
 #endif
 
-#ifdef CONFIG_LGUEST
+#if defined(CONFIG_LGUEST) || defined(CONFIG_LGUEST_MODULE)
BLANK();
OFFSET(LGUEST_PAGES_host_gdt_desc, lguest_pages, state.host_gdt_desc);
OFFSET(LGUEST_PAGES_host_idt_desc, lguest_pages, state.host_idt_desc);
--
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 00/37] Permit filesystem local caching

2008-02-20 Thread David Howells

Serge E. Hallyn [EMAIL PROTECTED] wrote:

 Seems *really* weird that every time you send this, patch 6 doesn't seem
 to reach me in any of my mailboxes...  (did get it from the url
 you listed)

It's the largest of the patches, so that's not entirely surprising.  Hence why
I included the URL to the tarball also.

 I'm sorry if I miss where you explicitly state this, but is it safe to
 assume, as perusing the patches suggests, that
 
   1. tsk-sec never changes other than in task_alloc_security()?  

Correct.

   2. tsk-act_as is only ever dereferenced from (a) current-

That ought to be correct.

  except (b) in do_coredump?

Actually, do_coredump() only deals with current-act_as.

 (thereby carefully avoiding locking issues)

That's the idea.

 I'd still like to see some performance numbers.  Not to object to
 these patches, just to make sure there's no need to try and optimize
 more of the dereferences away when they're not needed.

I hope that the performance impact is minimal.  The kernel should spend very
little time looking at the security data.  I'll try and get some though.

 Oh, manually copied from patch 6, I see you have in the task_security
 struct definition:
 
   kernel_cap_tcap_bset;   /* ? */
 
 That comment can be filled in with 'capability bounding set' (for this
 task and all its future descendents).

Thanks.

David
--
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] epca: lock_kernel push down

Prepare epca for removing the lock from above. Most of epca is internally
locked so we can trivially push it down to a few bits of code. Drop the 
TIOCG/SSOFTCAR handling as that is done *properly* with locks by the mid layer.

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/epca.c 
linux-2.6.25-rc2-mm1/drivers/char/epca.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/epca.c2008-02-19 
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/epca.c2008-02-20 11:45:43.0 
+
@@ -2206,21 +2206,6 @@
tty_wait_until_sent(tty, 0);
digi_send_break(ch, arg ? arg*(HZ/10) : HZ/4);
return 0;
-   case TIOCGSOFTCAR:
-   if (put_user(C_CLOCAL(tty)?1:0, (unsigned long __user *)arg))
-   return -EFAULT;
-   return 0;
-   case TIOCSSOFTCAR:
-   {
-   unsigned int value;
-
-   if (get_user(value, (unsigned __user *)argp))
-   return -EFAULT;
-   tty-termios-c_cflag =
-   ((tty-termios-c_cflag  ~CLOCAL) |
-(value ? CLOCAL : 0));
-   return 0;
-   }
case TIOCMODG:
mflag = pc_tiocmget(tty, file);
if (put_user(mflag, (unsigned long __user *)argp))
@@ -2253,6 +2238,7 @@
break;
case DIGI_SETAW:
case DIGI_SETAF:
+   lock_kernel();
if (cmd == DIGI_SETAW) {
/* Setup an event to indicate when the transmit buffer 
empties */
spin_lock_irqsave(epca_lock, flags);
@@ -2264,6 +2250,7 @@
if (tty-ldisc.flush_buffer)
tty-ldisc.flush_buffer(tty);
}
+   unlock_kernel();
/* Fall Thru */
case DIGI_SETA:
if (copy_from_user(ch-digiext, argp, sizeof(digi_t)))
--
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] esp: lock_kernel push down

Push the BKL down into a few internal bits of code in this driver.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/esp.c 
linux-2.6.25-rc2-mm1/drivers/char/esp.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/esp.c 2008-02-19 
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/esp.c 2008-02-20 11:45:43.0 
+
@@ -1355,6 +1355,7 @@
 {
struct serial_struct tmp;
   
+   lock_kernel();
memset(tmp, 0, sizeof(tmp));
tmp.type = PORT_16550A;
tmp.line = info-line;
@@ -1367,6 +1368,7 @@
tmp.closing_wait = info-closing_wait;
tmp.custom_divisor = info-custom_divisor;
tmp.hub6 = 0;
+   unlock_kernel();
if (copy_to_user(retinfo,tmp,sizeof(*retinfo)))
return -EFAULT;
return 0;
@@ -1381,6 +1383,7 @@
return -EFAULT;
 
memset(tmp, 0, sizeof(tmp));
+   lock_kernel();
tmp.rx_timeout = info-config.rx_timeout;
tmp.rx_trigger = info-config.rx_trigger;
tmp.tx_trigger = info-config.tx_trigger;
@@ -1388,7 +1391,8 @@
tmp.flow_on = info-config.flow_on;
tmp.pio_threshold = info-config.pio_threshold;
tmp.dma_channel = (info-stat_flags  ESP_STAT_NEVER_DMA ? 0 : dma);
-
+   unlock_kernel();
+   
return copy_to_user(retinfo, tmp, sizeof(*retinfo)) ? -EFAULT : 0;
 }
 
@@ -1766,6 +1770,7 @@
struct serial_icounter_struct __user *p_cuser;  /* user space */
void __user *argp = (void __user *)arg;
unsigned long flags;
+   int ret;
 
if (serial_paranoia_check(info, tty-name, rs_ioctl))
return -ENODEV;
@@ -1783,7 +1788,10 @@
case TIOCGSERIAL:
return get_serial_info(info, argp);
case TIOCSSERIAL:
-   return set_serial_info(info, argp);
+   lock_kernel();
+   ret = set_serial_info(info, argp);
+   unlock_kernel();
+   return ret;
case TIOCSERCONFIG:
/* do not reconfigure after initial configuration */
return 0;
@@ -1855,11 +1863,13 @@
return -EFAULT;
 
return 0;
-   case TIOCGHAYESESP:
-   return get_esp_config(info, argp);
-   case TIOCSHAYESESP:
-   return set_esp_config(info, argp);
-
+   case TIOCGHAYESESP:
+   return get_esp_config(info, argp);
+   case TIOCSHAYESESP:
+   lock_kernel();
+   ret = set_esp_config(info, argp);
+   unlock_kernel();
+   return ret;
default:
return -ENOIOCTLCMD;
}
--
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] falconide: fix resources reservation

2008-02-20 Thread Bartlomiej Zolnierkiewicz

On Wednesday 20 February 2008, Geert Uytterhoeven wrote:
 On Wed, 20 Feb 2008, Bartlomiej Zolnierkiewicz wrote:
  * Tell IDE layer to not manage resources by setting
hwif-mmio flag and request resources in falconide_init().
  
  * Use request_mem_region() for resources reservation.
  
  * Use driver name for resources reservation.
  
  Cc: Geert Uytterhoeven [EMAIL PROTECTED]
  Cc: Michael Schmitz [EMAIL PROTECTED]
  Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
  ---
   drivers/ide/legacy/falconide.c |7 +++
   1 file changed, 7 insertions(+)
  
  Index: b/drivers/ide/legacy/falconide.c
  ===
  --- a/drivers/ide/legacy/falconide.c
  +++ b/drivers/ide/legacy/falconide.c
  @@ -22,6 +22,7 @@
   #include asm/atariints.h
   #include asm/atari_stdma.h
   
  +#define DRV_NAME falconide
   
   /*
*  Base of the IDE interface
  @@ -74,6 +75,11 @@ static int __init falconide_init(void)
   
  printk(KERN_INFO ide: Falcon IDE controller\n);
   
  +   if (!request_mem_region(ATA_HD_BASE, 0x40, DRV_NAME)) {
  +   printk(KERN_ERR %s: resources busy\n);
  ^^
 Woops, missing parameter?

thanks, fixed

 pr_error()?

dunno...

From: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
Subject: [PATCH] falconide: fix resources reservation (take 2)

* Tell IDE layer to not manage resources by setting
  hwif-mmio flag and request resources in falconide_init().

* Use request_mem_region() for resources reservation.

* Use driver name for resources reservation.

v2:
* Fix missing printk() parameter. (Noticed by Geert Uytterhoeven)

Cc: Geert Uytterhoeven [EMAIL PROTECTED]
Cc: Michael Schmitz [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
 drivers/ide/legacy/falconide.c |7 +++
 1 file changed, 7 insertions(+)

Index: b/drivers/ide/legacy/falconide.c
===
--- a/drivers/ide/legacy/falconide.c
+++ b/drivers/ide/legacy/falconide.c
@@ -22,6 +22,7 @@
 #include asm/atariints.h
 #include asm/atari_stdma.h
 
+#define DRV_NAME falconide
 
 /*
  *  Base of the IDE interface
@@ -74,6 +75,11 @@ static int __init falconide_init(void)
 
printk(KERN_INFO ide: Falcon IDE controller\n);
 
+   if (!request_mem_region(ATA_HD_BASE, 0x40, DRV_NAME)) {
+   printk(KERN_ERR %s: resources busy\n, DRV_NAME);
+   return -EBUSY;
+   }
+
falconide_setup_ports(hw);
 
hwif = ide_find_port();
@@ -83,6 +89,7 @@ static int __init falconide_init(void)
 
ide_init_port_data(hwif, index);
ide_init_port_hw(hwif, hw);
+   hwif-mmio = 1;
 
ide_get_lock(NULL, NULL);
ide_device_add(idx, NULL);
--
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] (linus git 02/19/08) Smack update for file capabilities

2008-02-20 Thread Casey Schaufler


--- Serge E. Hallyn [EMAIL PROTECTED] wrote:

 Quoting Casey Schaufler ([EMAIL PROTECTED]):
  From: Casey Schaufler [EMAIL PROTECTED]
 
  Update the Smack LSM to allow the registration of the capability
  module as a secondary LSM. Integrate the new hooks required for
  file based capabilities.
 
 Hi Casey,
 
 to help people keep their mailboxes straight it'd be good to have a
 changelog here pointing out that you addressed Stephen's point.

Thanks for the reminder.

 Looks good to me.  It's too bad the logic has to be quite so convoluted
 between the two, but I'm not sure it can be improved upon...

It's not so bad.

 And thanks Stephen, I well might have missed the issue you pointed out.

Indeed. The careful review is much appreciated.


Casey Schaufler
[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/

[PATCH] isicom: prepare for lock_kernel push down

Again lock the bits we can't trivially prove are safe without the BKL and
remove the broken TIOCS/GSOFTCAR handler.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/isicom.c 
linux-2.6.25-rc2-mm1/drivers/char/isicom.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/isicom.c  2008-02-19 
11:01:44.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/isicom.c  2008-02-20 11:45:50.0 
+
@@ -1258,6 +1258,8 @@
if (copy_from_user(newinfo, info, sizeof(newinfo)))
return -EFAULT;
 
+   lock_kernel();
+   
reconfig_port = ((port-flags  ASYNC_SPD_MASK) !=
(newinfo.flags  ASYNC_SPD_MASK));
 
@@ -1265,8 +1267,10 @@
if ((newinfo.close_delay != port-close_delay) ||
(newinfo.closing_wait != port-closing_wait) ||
((newinfo.flags  ~ASYNC_USR_MASK) !=
-   (port-flags  ~ASYNC_USR_MASK)))
+   (port-flags  ~ASYNC_USR_MASK))) {
+   unlock_kernel();
return -EPERM;
+   }
port-flags = ((port-flags  ~ ASYNC_USR_MASK) |
(newinfo.flags  ASYNC_USR_MASK));
}
@@ -1282,6 +1286,7 @@
isicom_config_port(port);
spin_unlock_irqrestore(port-card-card_lock, flags);
}
+   unlock_kernel();
return 0;
 }
 
@@ -1290,6 +1295,7 @@
 {
struct serial_struct out_info;
 
+   lock_kernel();
memset(out_info, 0, sizeof(out_info));
 /* out_info.type = ? */
out_info.line = port - isi_ports;
@@ -1299,6 +1305,7 @@
 /* out_info.baud_base = ? */
out_info.close_delay = port-close_delay;
out_info.closing_wait = port-closing_wait;
+   unlock_kernel();
if (copy_to_user(info, out_info, sizeof(out_info)))
return -EFAULT;
return 0;
@@ -1331,19 +1338,6 @@
tty_wait_until_sent(tty, 0);
isicom_send_break(port, arg ? arg * (HZ/10) : HZ/4);
return 0;
-
-   case TIOCGSOFTCAR:
-   return put_user(C_CLOCAL(tty) ? 1 : 0,
-   (unsigned long __user *)argp);
-
-   case TIOCSSOFTCAR:
-   if (get_user(arg, (unsigned long __user *) argp))
-   return -EFAULT;
-   tty-termios-c_cflag =
-   ((tty-termios-c_cflag  ~CLOCAL) |
-   (arg ? CLOCAL : 0));
-   return 0;
-
case TIOCGSERIAL:
return isicom_get_serial_info(port, argp);
 
--
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] 2.6.25-rc2-mm1 - Kernel panic while bootup caused by signal_group_exit()

On Wed, 20 Feb 2008 14:34:17 -0500
Rik van Riel [EMAIL PROTECTED] wrote:

 On Sun, 17 Feb 2008 09:40:33 +0530
 Kamalesh Babulal [EMAIL PROTECTED] wrote:
 
  [   25.512919] BUG: unable to handle kernel paging request at 9d74e37b
  [   25.514926] IP: [c04a8fac] proc_flush_task+0x5b/0x223
 
 I wonder if this one is related.   Also with 2.6.25-rc2-mm1 on x86_64:

Probably - am testing some locking patches 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/

[PATCH] isicom: istallion prepare for lock_kernel pushdown

This is an ancient driver so just wrap it in lock_kernel internally and
be done.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/istallion.c 
linux-2.6.25-rc2-mm1/drivers/char/istallion.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/istallion.c   2008-02-19 
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/istallion.c   2008-02-20 
11:45:50.0 +
@@ -4433,6 +4433,8 @@
done = 0;
rc = 0;
 
+   lock_kernel();
+   
switch (cmd) {
case COM_GETPORTSTATS:
rc = stli_getportstats(NULL, argp);
@@ -4455,7 +4457,8 @@
done++;
break;
}
-
+   unlock_kernel();
+   
if (done)
return rc;
 
@@ -4472,6 +4475,8 @@
if (brdp-state == 0)
return -ENODEV;
 
+   lock_kernel();
+   
switch (cmd) {
case STL_BINTR:
EBRDINTR(brdp);
@@ -4494,6 +4499,7 @@
rc = -ENOIOCTLCMD;
break;
}
+   unlock_kernel();
return rc;
 }
 
--
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] moxa: prepare for BKL pushdown

Moxa needs a few routines wrapping with the BKL for now. It also snoops
the TIOCG/SSOFTCAR function so needs its own implementation for now. That
wants fixing by turning it into a termios set downcall into the drivers
later.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/moxa.c 
linux-2.6.25-rc2-mm1/drivers/char/moxa.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/moxa.c2008-02-19 
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/moxa.c2008-02-20 11:45:50.0 
+
@@ -686,8 +686,8 @@
int flag = 0, dtr, rts;
 
port = tty-index;
-   if ((port != MAX_PORTS)  (!ch))
-   return (-EINVAL);
+   if (port != MAX_PORTS  !ch)
+   return -EINVAL;
 
MoxaPortGetLineOut(ch-port, dtr, rts);
if (dtr)
@@ -712,9 +712,10 @@
int dtr, rts;
 
port = tty-index;
-   if ((port != MAX_PORTS)  (!ch))
-   return (-EINVAL);
+   if (port != MAX_PORTS  !ch)
+   return -EINVAL;
 
+   lock_kernel();
MoxaPortGetLineOut(ch-port, dtr, rts);
if (set  TIOCM_RTS)
rts = 1;
@@ -725,6 +726,7 @@
if (clear  TIOCM_DTR)
dtr = 0;
MoxaPortLineCtrl(ch-port, dtr, rts);
+   unlock_kernel();
return 0;
 }
 
@@ -734,52 +736,56 @@
struct moxa_port *ch = (struct moxa_port *) tty-driver_data;
register int port;
void __user *argp = (void __user *)arg;
-   int retval;
-
+   int retval = 0;
+   
port = tty-index;
-   if ((port != MAX_PORTS)  (!ch))
-   return (-EINVAL);
+   if (port != MAX_PORTS  !ch)
+   return -EINVAL;
 
switch (cmd) {
case TCSBRK:/* SVID version: non-zero arg -- no break */
retval = tty_check_change(tty);
if (retval)
-   return (retval);
+   break;
moxa_setup_empty_event(tty);
tty_wait_until_sent(tty, 0);
if (!arg)
MoxaPortSendBreak(ch-port, 0);
-   return (0);
+   break;
case TCSBRKP:   /* support for POSIX tcsendbreak() */
retval = tty_check_change(tty);
if (retval)
-   return (retval);
+   break;
moxa_setup_empty_event(tty);
tty_wait_until_sent(tty, 0);
MoxaPortSendBreak(ch-port, arg);
-   return (0);
-   case TIOCGSOFTCAR:
-   return put_user(C_CLOCAL(tty) ? 1 : 0, (unsigned long __user *) 
argp);
+   break;
case TIOCSSOFTCAR:
if(get_user(retval, (unsigned long __user *) argp))
return -EFAULT;
arg = retval;
+   mutex_lock(tty-termios_mutex);
tty-termios-c_cflag = ((tty-termios-c_cflag  ~CLOCAL) |
 (arg ? CLOCAL : 0));
if (C_CLOCAL(tty))
ch-asyncflags = ~ASYNC_CHECK_CD;
else
ch-asyncflags |= ASYNC_CHECK_CD;
-   return (0);
+   mutex_unlock(tty-termios_mutex);
+   break;
case TIOCGSERIAL:
return moxa_get_serial_info(ch, argp);
-
case TIOCSSERIAL:
-   return moxa_set_serial_info(ch, argp);
+   lock_kernel();
+   retval = moxa_set_serial_info(ch, argp);
+   unlock_kernel();
+   break;
default:
+   lock_kernel();
retval = MoxaDriverIoctl(cmd, arg, port);
+   unlock_kernel();
}
-   return (retval);
+   return retval;
 }
 
 static void moxa_throttle(struct tty_struct *tty)
@@ -2414,6 +2420,7 @@
struct serial_struct tmp;
 
memset(tmp, 0, sizeof(tmp));
+   lock_kernel();
tmp.type = info-type;
tmp.line = info-port;
tmp.port = 0;
@@ -2424,6 +2431,7 @@
tmp.closing_wait = info-closing_wait;
tmp.custom_divisor = 0;
tmp.hub6 = 0;
+   unlock_kernel();
if(copy_to_user(retinfo, tmp, sizeof(*retinfo)))
return -EFAULT;
return (0);
--
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] serial167: prepare to push BKL down into drivers

Kill the softcar handlers again, wrap the ioctl handler in the BKL

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/serial167.c 
linux-2.6.25-rc2-mm1/drivers/char/serial167.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/serial167.c   2008-02-19 
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/serial167.c   2008-02-20 
11:48:49.0 +
@@ -1539,6 +1539,8 @@
printk(cy_ioctl %s, cmd = %x arg = %lx\n, tty-name, cmd, arg);   
/* */
 #endif
 
+   lock_kernel();
+
switch (cmd) {
case CYGETMON:
ret_val = get_mon_info(info, argp);
@@ -1584,18 +1586,6 @@
break;
 
 /* The following commands are incompletely implemented!!! */
-   case TIOCGSOFTCAR:
-   ret_val =
-   put_user(C_CLOCAL(tty) ? 1 : 0,
-(unsigned long __user *)argp);
-   break;
-   case TIOCSSOFTCAR:
-   ret_val = get_user(val, (unsigned long __user *)argp);
-   if (ret_val)
-   break;
-   tty-termios-c_cflag =
-   ((tty-termios-c_cflag  ~CLOCAL) | (val ? CLOCAL : 0));
-   break;
case TIOCGSERIAL:
ret_val = get_serial_info(info, argp);
break;
@@ -1605,6 +1595,7 @@
default:
ret_val = -ENOIOCTLCMD;
}
+   unlock_kernel();
 
 #ifdef SERIAL_DEBUG_OTHER
printk(cy_ioctl done\n);
--
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/3] x86_64: CPA, fix cache attribute inconsistency bug, v2.6.22 backport

2008-02-20 Thread Vivek Goyal

On Fri, Feb 15, 2008 at 08:58:22PM +0100, Ingo Molnar wrote:
 
 fix CPA cache attribute bug in v2.6.23. When phys_base is nonzero
 (when CONFIG_RELOCATABLE=y) then change_page_attr_addr() miscalculates
 the secondary alias address by -14 MB (depending on the configured
 offset).
 
 The default 64-bit kernels of Fedora and Ubuntu are affected:
 
$ grep RELOCA /boot/config-2.6.23.9-85.fc8
  CONFIG_RELOCATABLE=y
 
$ grep RELOC /boot/config-2.6.22-14-generic
  CONFIG_RELOCATABLE=y
 
 and probably on many other distros as well.
 
 the bug affects all pages in the first 40 MB of physical RAM that
 are allocated by some subsystem that does ioremap_nocache() on them:
 
if (__pa(address)  KERNEL_TEXT_SIZE) {
 
 Hence we might leave page table entries with inconsistent cache
 attributes around (pages mapped at both UnCacheable and Write-Back),
 and we can also set the wrong kernel text pages to UnCacheable.
 
 the effects of this bug can be random slowdowns and other misbehavior.
 If for example AGP allocates its aperture pages into the first 40 MB
 of physical RAM, then the -14 MB bug might mark random kernel texto
 pages as uncacheable, slowing down a random portion of the 64-bit
 kernel until the AGP driver is unloaded.
 
 Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
 Acked-by: Thomas Gleixner [EMAIL PROTECTED]
 ---
  arch/x86_64/mm/pageattr.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 Index: linux-tmp/arch/x86_64/mm/pageattr.c
 ===
 --- linux-tmp.orig/arch/x86_64/mm/pageattr.c
 +++ linux-tmp/arch/x86_64/mm/pageattr.c
 @@ -204,7 +204,7 @@ int change_page_attr_addr(unsigned long 
   if (__pa(address)  KERNEL_TEXT_SIZE) {

Hi Ingo,

Should we change above condition also to something like following.

kernel_phys_start = __pa(__START_KERNEL_map) + phys_base
kernel_phys_end = kernel_phys_start + KERNEL_TEXT_SIZE

if (__pa(address) = kernel_phys_start
 __pa(address) = kernel_phys_end)  

Looks like we are trying to see if a physical page has been mapped
by kernel text/data region also then change the caching attributes there too.

In case of relocatable kernel, not necessarily first 40MB will be mapped by
the kernel text/data region, If boot loader decides to load kernel
at a higher address and phys_base is non-zero.

Thanks
Vivek
--
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/4] make dev_to_node return online node

2008-02-20 Thread Yinghai Lu

please use this one instead. this one is less intrusive, and pcibus_to_node 
will work too
and don't need other changes.

YH

---

[PATCH] make dev_to_node return online node v2

some numa system ( with multi HT chains) may return node without ram. aka it
is not online.
try to get one online node, otherwise return -1

Signed-off-by: Yinghai Lu [EMAIL PROTECTED]

diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
index c163ad1..2c1a651 100644
--- a/arch/x86/pci/acpi.c
+++ b/arch/x86/pci/acpi.c
@@ -213,6 +213,9 @@ struct pci_bus * __devinit pci_acpi_scan_root(struct 
acpi_device *device, int do
set_mp_bus_to_node(busnum, node);
else
node = get_mp_bus_to_node(busnum);
+
+   if (node != -1  !node_online(node))
+   node = -1;
 #endif
 
/* Allocate per-root-bus (not per bus) arch-specific data.
--
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] rocket: Prepare for BKL pushdown

Wrap the ioctl code in lock_kernel calls

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/rocket.c 
linux-2.6.25-rc2-mm1/drivers/char/rocket.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/rocket.c  2008-02-19 
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/rocket.c  2008-02-20 11:48:44.0 
+
@@ -1432,29 +1432,38 @@
 {
struct r_port *info = (struct r_port *) tty-driver_data;
void __user *argp = (void __user *)arg;
+   int ret = 0;
 
if (cmd != RCKP_GET_PORTS  rocket_paranoia_check(info, rp_ioctl))
return -ENXIO;
 
+   lock_kernel();
+
switch (cmd) {
case RCKP_GET_STRUCT:
if (copy_to_user(argp, info, sizeof (struct r_port)))
-   return -EFAULT;
-   return 0;
+   ret = -EFAULT;
+   break;
case RCKP_GET_CONFIG:
-   return get_config(info, argp);
+   ret = get_config(info, argp);
+   break;
case RCKP_SET_CONFIG:
-   return set_config(info, argp);
+   ret = set_config(info, argp);
+   break;
case RCKP_GET_PORTS:
-   return get_ports(info, argp);
+   ret = get_ports(info, argp);
+   break;
case RCKP_RESET_RM2:
-   return reset_rm2(info, argp);
+   ret = reset_rm2(info, argp);
+   break;
case RCKP_GET_VERSION:
-   return get_version(info, argp);
+   ret = get_version(info, argp);
+   break;
default:
-   return -ENOIOCTLCMD;
+   ret = -ENOIOCTLCMD;
}
-   return 0;
+   unlock_kernel();
+   return ret;
 }
 
 static void rp_send_xchar(struct tty_struct *tty, char ch)
--
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] mxser: prepare for BKL pushdown

Push the BKL down into various internal routines in the driver ready to
remove it from the break, ioctl and other call points.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/mxser.c 
linux-2.6.25-rc2-mm1/drivers/char/mxser.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/mxser.c   2008-02-19 
11:03:26.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/mxser.c   2008-02-20 11:45:57.0 
+
@@ -1658,6 +1658,7 @@
struct mxser_port *port;
int result, status;
unsigned int i, j;
+   int ret = 0;
 
switch (cmd) {
case MOXA_GET_MAJOR:
@@ -1665,18 +1666,21 @@
 
case MOXA_CHKPORTENABLE:
result = 0;
-
+   lock_kernel();
for (i = 0; i  MXSER_BOARDS; i++)
for (j = 0; j  MXSER_PORTS_PER_BOARD; j++)
if (mxser_boards[i].ports[j].ioaddr)
result |= (1  i);
-
+   unlock_kernel();
return put_user(result, (unsigned long __user *)argp);
case MOXA_GETDATACOUNT:
+   lock_kernel();
if (copy_to_user(argp, mxvar_log, sizeof(mxvar_log)))
-   return -EFAULT;
-   return 0;
+   ret = -EFAULT;
+   unlock_kernel();
+   return ret;
case MOXA_GETMSTATUS:
+   lock_kernel();
for (i = 0; i  MXSER_BOARDS; i++)
for (j = 0; j  MXSER_PORTS_PER_BOARD; j++) {
port = mxser_boards[i].ports[j];
@@ -1713,6 +1717,7 @@
else
GMStatus[i].cts = 0;
}
+   unlock_kernel();
if (copy_to_user(argp, GMStatus,
sizeof(struct mxser_mstatus) * MXSER_PORTS))
return -EFAULT;
@@ -1722,7 +1727,8 @@
unsigned long opmode;
unsigned cflag, iflag;
 
-   for (i = 0; i  MXSER_BOARDS; i++)
+   lock_kernel();
+   for (i = 0; i  MXSER_BOARDS; i++) {
for (j = 0; j  MXSER_PORTS_PER_BOARD; j++) {
port = mxser_boards[i].ports[j];
if (!port-ioaddr)
@@ -1787,13 +1793,14 @@
mon_data_ext.iftype[i] = opmode;
 
}
-   if (copy_to_user(argp, mon_data_ext,
-   sizeof(mon_data_ext)))
-   return -EFAULT;
-
-   return 0;
-
-   } default:
+   }
+   unlock_kernel();
+   if (copy_to_user(argp, mon_data_ext,
+   sizeof(mon_data_ext)))
+   return -EFAULT;
+   return 0;
+   }
+   default:
return -ENOIOCTLCMD;
}
return 0;
@@ -1849,16 +1856,20 @@
opmode != RS422_MODE 
opmode != RS485_4WIRE_MODE)
return -EFAULT;
+   lock_kernel();
mask = ModeMask[p];
shiftbit = p * 2;
val = inb(info-opmode_ioaddr);
val = mask;
val |= (opmode  shiftbit);
outb(val, info-opmode_ioaddr);
+   unlock_kernel();
} else {
+   lock_kernel();
shiftbit = p * 2;
opmode = inb(info-opmode_ioaddr)  shiftbit;
opmode = OP_MODE_MASK;
+   unlock_kernel();
if (put_user(opmode, (int __user *)argp))
return -EFAULT;
}
@@ -1885,19 +1896,18 @@
tty_wait_until_sent(tty, 0);
mxser_send_break(info, arg ? arg * (HZ / 10) : HZ / 4);
return 0;
-   case TIOCGSOFTCAR:
-   return put_user(!!C_CLOCAL(tty), (unsigned long __user *)argp);
-   case TIOCSSOFTCAR:
-   if (get_user(arg, (unsigned long __user *)argp))
-   return -EFAULT;
-   tty-termios-c_cflag = ((tty-termios-c_cflag  ~CLOCAL) | 
(arg ? CLOCAL : 0));
-   return 0;
case TIOCGSERIAL:
-   return mxser_get_serial_info(info, argp);
+   lock_kernel();
+   retval = mxser_get_serial_info(info, argp);
+   unlock_kernel();
+   return retval;
case TIOCSSERIAL:
-   return mxser_set_serial_info(info, argp);
+   lock_kernel();
+

Re: USB OOPS 2.6.25-rc2-git1

2008-02-20 Thread Andre Tomt


David Brownell wrote:

On Tuesday 19 February 2008, Andre Tomt wrote:

Can you try this diagnostic patch, to see if it reports any messages
about IAA and/or IAAD oddities?  There's surely a quick workaround
for this, but I'd rather understand the root cause before patching.
Doesn't seem to have triggered anything. dmesg attached in case I missed 
anything.


You don't seem to have enabled CONFIG_USB_DEBUG, as the patch instructions
say is needed to get such diagnostics ... I can tell because the startup
messages from USB are pretty minimal.  (See appended, vs what you sent...)

Please try again with USB debugging enabled.


Argh, silly me. Here you go (attached). It has not crashed yet with the 
patch though.
Initializing cgroup subsys cpuset
Linux version 2.6.25-rc2-git1 ([EMAIL PROTECTED]) (gcc version 4.2.3 (Debian 
4.2.3-1)) #5 SMP Wed Feb 20 09:40:27 CET 2008
Command line: root=/dev/sda1 ro rootflags=noatime rootfstype=ext2 
console=ttyS0,38400 verbose 
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009bc00 (usable)
 BIOS-e820: 0009bc00 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 7fee (usable)
 BIOS-e820: 7fee - 7fee3000 (ACPI NVS)
 BIOS-e820: 7fee3000 - 7fef (ACPI data)
 BIOS-e820: 7fef - 7ff0 (reserved)
 BIOS-e820: e000 - f000 (reserved)
 BIOS-e820: fec0 - 0001 (reserved)
Entering add_active_range(0, 0, 155) 0 entries of 3200 used
Entering add_active_range(0, 256, 524000) 1 entries of 3200 used
end_pfn_map = 1048576
DMI 2.4 present.
ACPI: RSDP 000F7850, 0014 (r0 IntelR)
ACPI: RSDT 7FEE3040, 0038 (r1 IntelR AWRDACPI 42302E31 AWRD0)
ACPI: FACP 7FEE30C0, 0074 (r1 IntelR AWRDACPI 42302E31 AWRD0)
ACPI: DSDT 7FEE3180, 463D (r1 INTELR AWRDACPI 1000 MSFT  300)
ACPI: FACS 7FEE, 0040
ACPI: HPET 7FEE7900, 0038 (r1 IntelR AWRDACPI 42302E31 AWRD   98)
ACPI: MCFG 7FEE7980, 003C (r1 IntelR AWRDACPI 42302E31 AWRD0)
ACPI: APIC 7FEE7800, 0084 (r1 IntelR AWRDACPI 42302E31 AWRD0)
ACPI: SSDT 7FEE8020, 02F1 (r1  PmRefCpuPm 3000 INTL 20040311)
No NUMA configuration found
Faking a node at -7fee
Entering add_active_range(0, 0, 155) 0 entries of 3200 used
Entering add_active_range(0, 256, 524000) 1 entries of 3200 used
Bootmem setup node 0 -7fee
  NODE_DATA [c000 - 00012fff]
  bootmap [00013000 -  00022fdf] pages 10
early res: 0 [0-fff] BIOS data page
early res: 1 [6000-7fff] SMP_TRAMPOLINE
early res: 2 [20-565977] TEXT DATA BSS
early res: 3 [37a43000-37fef4eb] RAMDISK
early res: 4 [9bc00-abbff] EBDA
early res: 5 [8000-bfff] PGTABLE
 [e200-e21f] PMD -81000120 on node 0
 [e220-e23f] PMD -81000160 on node 0
 [e240-e25f] PMD -810001a0 on node 0
 [e260-e27f] PMD -810001e0 on node 0
 [e280-e29f] PMD -81000220 on node 0
 [e2a0-e2bf] PMD -81000260 on node 0
 [e2c0-e2df] PMD -810002a0 on node 0
 [e2e0-e2ff] PMD -810002e0 on node 0
 [e2000100-e200011f] PMD -81000320 on node 0
 [e2000120-e200013f] PMD -81000360 on node 0
 [e2000140-e200015f] PMD -810003a0 on node 0
 [e2000160-e200017f] PMD -810003e0 on node 0
 [e2000180-e200019f] PMD -81000420 on node 0
 [e20001a0-e20001bf] PMD -81000460 on node 0
Zone PFN ranges:
  DMA 0 - 4096
  DMA324096 -  1048576
  Normal1048576 -  1048576
Movable zone start PFN for each node
early_node_map[2] active PFN ranges
0:0 -  155
0:  256 -   524000
On node 0 totalpages: 523899
  DMA zone: 56 pages used for memmap
  DMA zone: 894 pages reserved
  DMA zone: 3045 pages, LIFO batch:0
  DMA32 zone: 7108 pages used for memmap
  DMA32 zone: 512796 pages, LIFO batch:31
  Normal zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x408
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] disabled)
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x03] disabled)
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])
ACPI: IOAPIC (id[0x04] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 4, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0

Re: 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

2008-02-20 Thread Linus Torvalds



On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
 
 I think we should export the target sleep state somehow.

Yeah. By *not* using -suspend() for freezing or hibernate.

Please, Rafael - just make the f*cking suspend-to-disk use other routines 
already. 99% of all hardware needs to do exactly *nothing* on 
suspend-to-disk, and the ones that really do need things tend to need to 
not do a whole lot.

For example, the freeze action for USB (which is one of the hardest 
things to suspend) should literally be something like just setting the 
controller STOP bit, and waiting for it to have stopped. The unfreeze 
should be to just clear the stop bit, while the restart should be just a 
controller reset to use the current memory image.

NONE OF THIS HAS ABSOLUTELY ANYTHING TO DO WITH SUSPEND.

It never did. I've told people so for years. Maybe actually seeing the 
problems will make people realize.

So please, we shouldn't call -suspend[_late] or -resume[_early] at 
all. Not with PMSG_FREEZE, not with PMSG_*anything*.

Can we please get this fixed some day? 

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: 2.6.25-rc[1,2]: failed to setup dm-crypt key mapping

2008-02-20 Thread Michael S. Tsirkin

On Feb 20, 2008 7:58 PM, Herbert Xu [EMAIL PROTECTED] wrote:
 On Wed, Feb 20, 2008 at 06:47:58PM +0100, Milan Broz wrote:
 
  I just tested one affected configuration and problem was in missing
  chainiv.ko module on ramdisk.

 Ah OK.  We probably should merge chainiv into the blkcipher
 module too since it's the default IV generator.  I'll take
 care of it.

Right. Manually adding chainiv.ko to initramfs makes it boot again.
--
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: [Rt2400-devel] 2.6.25-rc2 regression in rt61pci wireless driver

2008-02-20 Thread Chris Vine


On Wed, 2008-02-20 at 11:05 -0500, Dan Williams wrote: 
 On Tue, 2008-02-19 at 23:04 +, Chris Vine wrote:
  On Tue, 2008-02-19 at 20:46 +0100, Ivo van Doorn wrote:
   Hi,
   
   [added rt2400-devel (rt2x00 development mailinglist) to the CC list.]
   
   I have a series of tests I would like to request from you,
   you mentioned you already enabled debugfs, and that is just what 
   we need. ;)
   Please use attached script to create dumps of the hardware 
   register contents.
   
   There are specific moments that should be dumped:
   - kernel 2.6.24 (last known working version for you).
   - kernel 2.6.25-rc2 (after ifup, before TX dies)
   - kernel 2.6.25-rc2 (after ifup, after TX dies)

  
  These diagnostics are attached, with obvious filenames.
 
 Thanks. I think I found something, please test below patch:
 

I've tried the patch but, unfortunately, my wireless LAN still dies 
after a few pings.
  
  rt2x00 2.0.14 is broken with my rt73 stick in the vanilla 2.6.25-rc2
  kernel (not wireless-2.6/rt2x00 git).  The modules load when I plug the
  stick in but I then get a complete kernel lock up with two flashing
  leds.  Nothing is recorded to system logs.  The last logged messages are
  that usbcore has registered new interface driver rt73usb, and that the
  rate control algorithm has been selected on phy0.  This happens whether
  the simple or pid mac80211 rate control algorithms have been chosen.
  
  This is a shame because 2.0.14 was working really well for me until the
  mac80211 changes 2 or 3 weeks ago broke it.  (Shortly followed by the
  release of 2.1.*).
 
 Switch to a VT with Ctl+Alt+1, then plug the stick in, and take a
 picture of the panic if one shows up.  _Something_ should show up on the
 VT.

I did that yesterday and it just reported a kernel panic on the terminal
with the message:

  Kernel panic - not syncing: Aiee, killing interrupt handler!

There is a complete lock up.  Even the two leds don't send a dump in
morse code (if that is still a feature of the 2.6 kernels).  They just
flash together at 1 second intervals.

However, I do not have debugging enabled on 2.6.25-rc2 (I was just
interested to see how it worked).  If it is thought to be useful I can
recompile the kernel with debugging enabled, but this should be
reproducible by anyone with a rt73 stick.

By way of a further data point, I can scan OK using 2.6.25-rc2 and it
will report all the available access points in my area.  But as soon as
association is attempted, it blows up.

Chris


--
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] nozomi: Prepare for BKL pushdown

We leave the BKL around the rts/dtr handler because there is *no* locking
of any kind on this in the driver. It's not right with this change but
it's the same wrong as before..

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/nozomi.c 
linux-2.6.25-rc2-mm1/drivers/char/nozomi.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/nozomi.c  2008-02-19 
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/nozomi.c  2008-02-20 11:45:57.0 
+
@@ -1716,6 +1716,7 @@
 static int ntty_tiocmset(struct tty_struct *tty, struct file *file,
unsigned int set, unsigned int clear)
 {
+   lock_kernel();  /* FIXME: Add internal locking */
if (set  TIOCM_RTS)
set_rts(tty, 1);
else if (clear  TIOCM_RTS)
@@ -1725,7 +1726,7 @@
set_dtr(tty, 1);
else if (clear  TIOCM_DTR)
set_dtr(tty, 0);
-
+   unlock_kernel();
return 0;
 }
 
--
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] specialix: Prepare for BKL pushdown

Lock the ioctl handlers and remove bogus softcar handling.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/specialix.c 
linux-2.6.25-rc2-mm1/drivers/char/specialix.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/specialix.c   2008-02-19 
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/specialix.c   2008-02-20 
11:48:55.0 +
@@ -1924,29 +1924,13 @@
int change_speed;
 
func_enter();
-   /*
-   if (!access_ok(VERIFY_READ, (void *) newinfo, sizeof(tmp))) {
-   func_exit();
-   return -EFAULT;
-   }
-   */
+
if (copy_from_user(tmp, newinfo, sizeof(tmp))) {
func_enter();
return -EFAULT;
}
-
-#if 0
-   if ((tmp.irq != bp-irq) ||
-   (tmp.port != bp-base) ||
-   (tmp.type != PORT_CIRRUS) ||
-   (tmp.baud_base != (SX_OSCFREQ + CD186x_TPC/2) / CD186x_TPC) ||
-   (tmp.custom_divisor != 0) ||
-   (tmp.xmit_fifo_size != CD186x_NFIFO) ||
-   (tmp.flags  ~SPECIALIX_LEGAL_FLAGS)) {
-   func_exit();
-   return -EINVAL;
-   }
-#endif
+   
+   lock_kernel();
 
change_speed = ((port-flags  ASYNC_SPD_MASK) !=
(tmp.flags  ASYNC_SPD_MASK));
@@ -1958,6 +1942,7 @@
((tmp.flags  ~ASYNC_USR_MASK) !=
 (port-flags  ~ASYNC_USR_MASK))) {
func_exit();
+   unlock_kernel();
return -EPERM;
}
port-flags = ((port-flags  ~ASYNC_USR_MASK) |
@@ -1974,6 +1959,7 @@
sx_change_speed(bp, port);
}
func_exit();
+   unlock_kernel();
return 0;
 }
 
@@ -1986,12 +1972,8 @@
 
func_enter();
 
-   /*
-   if (!access_ok(VERIFY_WRITE, (void *) retinfo, sizeof(tmp)))
-   return -EFAULT;
-   */
-
memset(tmp, 0, sizeof(tmp));
+   lock_kernel();
tmp.type = PORT_CIRRUS;
tmp.line = port - sx_port;
tmp.port = bp-base;
@@ -2002,6 +1984,7 @@
tmp.closing_wait = port-closing_wait * HZ/100;
tmp.custom_divisor =  port-custom_divisor;
tmp.xmit_fifo_size = CD186x_NFIFO;
+   unlock_kernel();
if (copy_to_user(retinfo, tmp, sizeof(tmp))) {
func_exit();
return -EFAULT;
@@ -2047,23 +2030,6 @@
sx_send_break(port, arg ? arg*(HZ/10) : HZ/4);
func_exit();
return 0;
-case TIOCGSOFTCAR:
-if (put_user(C_CLOCAL(tty)?1:0, (unsigned long __user *)argp)) 
{
-func_exit();
-return -EFAULT;
-}
-func_exit();
-   return 0;
-case TIOCSSOFTCAR:
-if (get_user(arg, (unsigned long __user *) argp)) {
-func_exit();
-return -EFAULT;
-}
-   tty-termios-c_cflag =
-   ((tty-termios-c_cflag  ~CLOCAL) |
-   (arg ? CLOCAL : 0));
-   func_exit();
-   return 0;
 case TIOCGSERIAL:
 func_exit();
return sx_get_serial_info(port, argp);
--
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] stallion: Prepare for BKL push down

Remove broken softcar functions, wrap ioctl handler in BKL

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/stallion.c 
linux-2.6.25-rc2-mm1/drivers/char/stallion.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/stallion.c2008-02-19 
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/stallion.c2008-02-20 
11:49:03.0 +
@@ -1273,18 +1273,9 @@
 
rc = 0;
 
+   lock_kernel();
+   
switch (cmd) {
-   case TIOCGSOFTCAR:
-   rc = put_user(((tty-termios-c_cflag  CLOCAL) ? 1 : 0),
-   (unsigned __user *) argp);
-   break;
-   case TIOCSSOFTCAR:
-   if (get_user(ival, (unsigned int __user *) arg))
-   return -EFAULT;
-   tty-termios-c_cflag =
-   (tty-termios-c_cflag  ~CLOCAL) |
-   (ival ? CLOCAL : 0);
-   break;
case TIOCGSERIAL:
rc = stl_getserial(portp, argp);
break;
@@ -1308,7 +1299,7 @@
rc = -ENOIOCTLCMD;
break;
}
-
+   unlock_kernel();
return rc;
 }
 
--
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] Re: [PATCH 4/12] riscom8: fix SMP brokenness

2008-02-20 Thread Jeff Garzik


Ingo Molnar wrote:

* Jeff Garzik [EMAIL PROTECTED] wrote:

After analyzing the elements that save_flags/cli/sti/restore_flags 
were protecting, convert their usages to a global spinlock (the 
easiest and most obvious next-step).  There were some usages of flags 
being intentionally cached, because the code already knew the state of 
interrupts.  These have been taken into account.


This allows us to remove CONFIG_BROKEN_ON_SMP.  Completely untested.


regression for sale :-) The above patch, after sitting in -mm for 
approximately 3 months, just went upstream today via commit 
d9afa43532adf8a31b93c4c7601f and promptly broke tonight's x86.git 
randconfig qa run via tons of these messages:


[3.768431] BUG: scheduling while atomic: swapper/1/0x0002
[3.769430] 1 lock held by swapper/1:
[3.770437]  #0:  (riscom_lock){--..}, at: [80389ceb] 
rc_release_drivers+0xe/0x33
[3.776430] Pid: 1, comm: swapper Not tainted 2.6.24 #14
[3.777428]  [801167d3] __schedule_bug+0x6e/0x75
[3.779427]  [80756065] schedule+0x35c/0x429
[3.781427]  [80103a0b] ? restore_nocheck+0x12/0x15
[3.784427]  [80103a0b] ? restore_nocheck+0x12/0x15
[3.786426]  [80756381] schedule_timeout+0x69/0xa2
[3.788426]  [80758337] ? _spin_unlock_irq+0x25/0x40
[3.790426]  [80755c0e] wait_for_common+0x96/0x10d
[3.792425]  [80115edc] ? default_wake_function+0x0/0xd
[3.794425]  [80755d07] wait_for_completion+0x12/0x14
[3.796425]  [801282fe] call_usermodehelper_exec+0x78/0x8c
[3.798424]  [8015a041] ? slob_alloc+0xd8/0x1ad
[3.800424]  [80301640] kobject_uevent_env+0x3ae/0x3c5
[3.802424]  [803ac361] ? dev_uevent+0x0/0x25a
[3.804424]  [80301661] kobject_uevent+0xa/0xc
[3.806423]  [803acc06] device_del+0x139/0x15d
[3.808423]  [803acc58] device_unregister+0x2e/0x3b
[3.810423]  [803acc8e] device_destroy+0x29/0x2f
[3.812422]  [8035965f] tty_unregister_device+0x18/0x1a
[3.814422]  [8035970b] tty_unregister_driver+0xaa/0xf6
[3.816422]  [80389cf7] rc_release_drivers+0x1a/0x33
[3.818421]  [80ac5e16] riscom8_init_module+0x4ff/0x539
[3.820421]  [8012e76f] ? ktime_get_ts+0x44/0x49
[3.822421]  [80aaf701] kernel_init+0x9a/0x263
[3.824421]  [80ac5917] ? riscom8_init_module+0x0/0x539
[3.827420]  [80aaf667] ? kernel_init+0x0/0x263
[3.829420]  [8010455f] kernel_thread_helper+0x7/0x18
[3.831419]  ===


This is unfortunately very low on the priority stack.  I was a bit 
surprised when it went in, honestly, since I hadn't gotten any it 
works test reports yet...  but that's my fault for not keeping akpm up 
to date.


We'll want to revert this for 2.6.25 release, if it doesn't get fixed up.

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/

[PATCH] sx: prepare for BKL pushdown

Wrap the ioctl handler, and in this case the break handler also in the
BKL. Remove bogus softcar handlers.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/sx.c 
linux-2.6.25-rc2-mm1/drivers/char/sx.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/sx.c  2008-02-19 
11:01:44.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/sx.c  2008-02-20 11:49:03.0 
+
@@ -1844,6 +1844,7 @@
int rv;
 
func_enter();
+   lock_kernel();
 
if (flag)
rv = sx_send_command(port, HS_START, -1, HS_IDLE_BREAK);
@@ -1852,7 +1853,7 @@
if (rv != 1)
printk(KERN_ERR sx: couldn't send break (%x).\n,
read_sx_byte(port-board, CHAN_OFFSET(port, hi_hstat)));
-
+   unlock_kernel();
func_exit();
 }
 
@@ -1888,23 +1889,12 @@
int rc;
struct sx_port *port = tty-driver_data;
void __user *argp = (void __user *)arg;
-   int ival;
 
/* func_enter2(); */
 
rc = 0;
+   lock_kernel();
switch (cmd) {
-   case TIOCGSOFTCAR:
-   rc = put_user(((tty-termios-c_cflag  CLOCAL) ? 1 : 0),
-   (unsigned __user *)argp);
-   break;
-   case TIOCSSOFTCAR:
-   if ((rc = get_user(ival, (unsigned __user *)argp)) == 0) {
-   tty-termios-c_cflag =
-   (tty-termios-c_cflag  ~CLOCAL) |
-   (ival ? CLOCAL : 0);
-   }
-   break;
case TIOCGSERIAL:
rc = gs_getserial(port-gs, argp);
break;
@@ -1915,6 +1905,7 @@
rc = -ENOIOCTLCMD;
break;
}
+   unlock_kernel();
 
/* func_exit(); */
return rc;
--
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 patches] net driver updates

2008-02-20 Thread Jeff Garzik


Divy Le Ray wrote:

Jeff Garzik wrote:

Mostly fixes, a few cleanups (generally assisting fixes), and an
exception for PS3 wireless because it had been posted, reviewed and
acked for a while, just not committed.

Please pull from 'upstream-davem' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git 
upstream-davem


to receive the following updates:

 
 drivers/net/cxgb3/sge.c  |   35 +-
   
diff --git a/drivers/net/cxgb3/sge.c b/drivers/net/cxgb3/sge.c

index 9ca8c66..979f3fc 100644
--- a/drivers/net/cxgb3/sge.c
+++ b/drivers/net/cxgb3/sge.c
@@ -1059,6 +1059,14 @@ static void write_tx_pkt_wr(struct adapter 
*adap, struct sk_buff *skb,

  htonl(V_WR_TID(q-token)));
 }
 
+static inline void t3_stop_queue(struct net_device *dev, struct 
sge_qset *qs,

+ struct sge_txq *q)
+{
+netif_stop_queue(dev);
+set_bit(TXQ_ETH, qs-txq_stopped);
+q-stops++;
+}
+
 /**
  *eth_xmit - add a packet to the Ethernet Tx queue
  *@skb: the packet
@@ -1090,31 +1098,18 @@ int t3_eth_xmit(struct sk_buff *skb, struct 
net_device *dev)

 ndesc = calc_tx_descs(skb);
 
 if (unlikely(credits  ndesc)) {

-if (!netif_queue_stopped(dev)) {
-netif_stop_queue(dev);
-set_bit(TXQ_ETH, qs-txq_stopped);
-q-stops++;
-dev_err(adap-pdev-dev,
-%s: Tx ring %u full while queue awake!\n,
-dev-name, q-cntxt_id  7);
-}
+t3_stop_queue(dev, qs, q);
+dev_err(adap-pdev-dev,
+%s: Tx ring %u full while queue awake!\n,
+dev-name, q-cntxt_id  7);
 spin_unlock(q-lock);
 return NETDEV_TX_BUSY;
 }
 
 q-in_use += ndesc;

-if (unlikely(credits - ndesc  q-stop_thres)) {
-q-stops++;
-netif_stop_queue(dev);
-set_bit(TXQ_ETH, qs-txq_stopped);
-#if !USE_GTS
-if (should_restart_tx(q) 
-test_and_clear_bit(TXQ_ETH, qs-txq_stopped)) {
-q-restarts++;
-netif_wake_queue(dev);
-}
-#endif
-}
+if (unlikely(credits - ndesc  q-stop_thres))
+if (USE_GTS || !should_restart_tx(q))
+t3_stop_queue(dev, qs, q);
 
 gen = q-gen;

 q-unacked += ndesc;
  

Hi Jeff,

I thought I had NAK'ed the patch modifying sge.c from Krishna Kumar.
Looking back at my answer at the time, I was obviously unclear.
Can you please revert the drivers/net/cxgb3sge.c change ?


Explain why, so I can include it in the changelog please...

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: [Linux-fbdev-devel] [PATCH 1/2] fb: add support for foreign endianness

2008-02-20 Thread Benjamin Herrenschmidt


On Wed, 2008-02-20 at 15:18 +0300, Anton Vorontsov wrote:
 On Wed, Feb 20, 2008 at 11:56:35AM +1100, Paul Mackerras wrote:
  Andrew Morton writes:
  
   Bizarrely, the original author of the patch (Anton) has fallen off the 
   cc. 
   Could whoever did that please thwap himself?
   
   Anyway, my head is now officially spinning.  Did anyone actually have a
   reason why we shouldn't proceed with Anton's patch?
  
  I was wondering if it would be sufficient to provide alternative
  versions of fb_readl, fb_writel etc. that do byte-swapping.
 
 This is of course viable alternative. And I was considering this, but
 later I abandoned the idea: that way we'll end up doing math in the
 native endianness and then converting it to the foreign. This feels
 ugly in contrast when we can do the right math in the first place, per
 framebuffer.

Also, the type of swap to do in fb_readl/writel would have to depend
on the bit depth which is kind of ugly.

  That
  would mean that all framebuffers would have to have the same
  endianness,
 
 Yup, another downside of changing the code to fix some narrow
 problem. Plus, this means things will break if/when we'll attach
 PCI video card into the MPC8360E-RDK.

Right.

Ben.

--
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] synclink series: Prepare for BKL pushdown

As these are quite complex I've simply pushed the BKL down into the ioctl
handler not tried to do anything neater. 

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/synclink.c 
linux-2.6.25-rc2-mm1/drivers/char/synclink.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/synclink.c2008-02-19 
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/synclink.c2008-02-20 
11:49:03.0 +
@@ -2945,6 +2945,7 @@
unsigned int cmd, unsigned long arg)
 {
struct mgsl_struct * info = (struct mgsl_struct *)tty-driver_data;
+   int ret;

if (debug_level = DEBUG_LEVEL_INFO)
printk(%s(%d):mgsl_ioctl %s cmd=%08X\n, __FILE__,__LINE__,
@@ -2959,7 +2960,10 @@
return -EIO;
}
 
-   return mgsl_ioctl_common(info, cmd, arg);
+   lock_kernel();
+   ret = mgsl_ioctl_common(info, cmd, arg);
+   unlock_kernel();
+   return ret;
 }
 
 static int mgsl_ioctl_common(struct mgsl_struct *info, unsigned int cmd, 
unsigned long arg)
diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/synclink_gt.c 
linux-2.6.25-rc2-mm1/drivers/char/synclink_gt.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/synclink_gt.c 2008-02-19 
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/synclink_gt.c 2008-02-20 
11:49:09.0 +
@@ -1098,6 +1098,7 @@
struct serial_icounter_struct __user *p_cuser;  /* user space */
unsigned long flags;
void __user *argp = (void __user *)arg;
+   int ret;
 
if (sanity_check(info, tty-name, ioctl))
return -ENODEV;
@@ -1108,38 +1109,55 @@
if (tty-flags  (1  TTY_IO_ERROR))
return -EIO;
}
+   
+   lock_kernel();
 
switch (cmd) {
case MGSL_IOCGPARAMS:
-   return get_params(info, argp);
+   ret = get_params(info, argp);
+   break;
case MGSL_IOCSPARAMS:
-   return set_params(info, argp);
+   ret = set_params(info, argp);
+   break;
case MGSL_IOCGTXIDLE:
-   return get_txidle(info, argp);
+   ret = get_txidle(info, argp);
+   break;
case MGSL_IOCSTXIDLE:
-   return set_txidle(info, (int)arg);
+   ret = set_txidle(info, (int)arg);
+   break;
case MGSL_IOCTXENABLE:
-   return tx_enable(info, (int)arg);
+   ret = tx_enable(info, (int)arg);
+   break;
case MGSL_IOCRXENABLE:
-   return rx_enable(info, (int)arg);
+   ret = rx_enable(info, (int)arg);
+   break;
case MGSL_IOCTXABORT:
-   return tx_abort(info);
+   ret = tx_abort(info);
+   break;
case MGSL_IOCGSTATS:
-   return get_stats(info, argp);
+   ret = get_stats(info, argp);
+   break;
case MGSL_IOCWAITEVENT:
-   return wait_mgsl_event(info, argp);
+   ret = wait_mgsl_event(info, argp);
+   break;
case TIOCMIWAIT:
-   return modem_input_wait(info,(int)arg);
+   ret = modem_input_wait(info,(int)arg);
+   break;
case MGSL_IOCGIF:
-   return get_interface(info, argp);
+   ret = get_interface(info, argp);
+   break;
case MGSL_IOCSIF:
-   return set_interface(info,(int)arg);
+   ret = set_interface(info,(int)arg);
+   break;
case MGSL_IOCSGPIO:
-   return set_gpio(info, argp);
+   ret = set_gpio(info, argp);
+   break;
case MGSL_IOCGGPIO:
-   return get_gpio(info, argp);
+   ret = get_gpio(info, argp);
+   break;
case MGSL_IOCWAITGPIO:
-   return wait_gpio(info, argp);
+   ret = wait_gpio(info, argp);
+   break;
case TIOCGICOUNT:
spin_lock_irqsave(info-lock,flags);
cnow = info-icount;
@@ -1156,12 +1174,14 @@
put_user(cnow.parity, p_cuser-parity) ||
put_user(cnow.brk, p_cuser-brk) ||
put_user(cnow.buf_overrun, p_cuser-buf_overrun))
-   return -EFAULT;
-   return 0;
+   ret = -EFAULT;
+   ret = 0;
+   break;
default:
-   return -ENOIOCTLCMD;
+   ret = -ENOIOCTLCMD;
}
-   return 0;
+   unlock_kernel();
+   return ret;
 }
 
 /*
diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/synclinkmp.c 
linux-2.6.25-rc2-mm1/drivers/char/synclinkmp.c
---

[PATCH] viocons: BKL locking

For some weird reason I can't ascertain (translation I think its
broken) the viocons driver calls directly into the n_tty ldisc code even
if another ldisc is in use. It'll probably break if you do that but I'm
just fixing the locking and adding a comment that its horked.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/viocons.c 
linux-2.6.25-rc2-mm1/drivers/char/viocons.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/viocons.c 2008-02-19 
11:01:44.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/viocons.c 2008-02-20 11:49:24.0 
+
@@ -704,8 +704,11 @@
case KDSKBLED:
return 0;
}
-
-   return n_tty_ioctl(tty, file, cmd, arg);
+   /* FIXME: WTF is this being called for ??? */
+   lock_kernel();
+   ret =  n_tty_ioctl(tty, file, cmd, arg);
+   unlock_kernel();
+   return ret;
 }
 
 /*
--
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.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

On Wednesday, February 20, 2008 12:29 pm Linus Torvalds wrote:
 On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
  I think we should export the target sleep state somehow.

 Yeah. By *not* using -suspend() for freezing or hibernate.

 Please, Rafael - just make the f*cking suspend-to-disk use other routines
 already. 99% of all hardware needs to do exactly *nothing* on
 suspend-to-disk, and the ones that really do need things tend to need to
 not do a whole lot.

In talking with Rafael on IRC about this, I think we're agreed that we need 
separate entry points.  Even with a kexec based hibernate, we'll probably 
want -hibernate callbacks so we don't end up shutting down the device.

The current callback system looks like this (according to Rafael and the last 
time I looked):
  -suspend(PMSG_FREEZE)
  -resume()
  -suspend(PMSG_SUSPEND)
  *enter S3 or power off*
  -resume()
The fact that we get suspend/resume called once before suspend again in the 
hibernate case is somewhat obnoxious, but it's even worse that we don't know 
what we're about to enter after -suspend(PMSG_SUSPEND).  So in the short 
term it would be nice to at least get the target state exported.

And in the long term we could have:
  -suspend()
  *enter S3*
  -resume()
or:
  -hibernate()
  *kexec to another kernel to save image*
  *power off*
  -return_from_hibernate() (or somesuch)

Jesse
--
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/4] nfs: fix sparse warning in nfs4state.c

2008-02-20 Thread Trond Myklebust


On Wed, 2008-02-20 at 12:10 -0800, Harvey Harrison wrote:
 fs/nfs/nfs4state.c:788:34: warning: Using plain integer as NULL pointer
 
 Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
 ---
  fs/nfs/nfs4state.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)
 
 diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
 index 6233eb5..b962397 100644
 --- a/fs/nfs/nfs4state.c
 +++ b/fs/nfs/nfs4state.c
 @@ -785,7 +785,7 @@ static int nfs4_reclaim_locks(struct 
 nfs4_state_recovery_ops *ops, struct nfs4_s
   struct file_lock *fl;
   int status = 0;
  
 - for (fl = inode-i_flock; fl != 0; fl = fl-fl_next) {
 + for (fl = inode-i_flock; fl != NULL; fl = fl-fl_next) {
   if (!(fl-fl_flags  (FL_POSIX|FL_FLOCK)))
   continue;
   if (nfs_file_open_context(fl-fl_file)-state != state)

Could you please just wrap these 4 up into a single patch? They are all
fixing up the same issue, and they are trivial to review, so there is
very little benefit in separating them.

Thanks
  Trond
--
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] vt_ioctl: Prepare for BKL push down

This one could do with some eyeballs on it. In theory it simply wraps the
ioctl handler in lock/unlock_kernel ready for the lock/unlocks to be
pushed into specific switch values. To do that means changing the code to
return via a common exit path not all over the place as it does now,
hence the big diff

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/char/vt_ioctl.c 
linux-2.6.25-rc2-mm1/drivers/char/vt_ioctl.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/char/vt_ioctl.c2008-02-19 
11:01:43.0 +
+++ linux-2.6.25-rc2-mm1/drivers/char/vt_ioctl.c2008-02-20 
11:49:34.0 +
@@ -373,11 +373,17 @@
unsigned char ucval;
void __user *up = (void __user *)arg;
int i, perm;
-   
+   int ret = 0;
+
console = vc-vc_num;
+   
+   lock_kernel();
 
-   if (!vc_cons_allocated(console))/* impossible? */
-   return -ENOIOCTLCMD;
+   if (!vc_cons_allocated(console)) {  /* impossible? */
+   ret = -ENOIOCTLCMD;
+   goto out;
+   }
+   
 
/*
 * To have permissions to do most of the vt ioctls, we either have
@@ -391,15 +397,15 @@
switch (cmd) {
case KIOCSOUND:
if (!perm)
-   return -EPERM;
+   goto eperm;
if (arg)
arg = CLOCK_TICK_RATE / arg;
kd_mksound(arg, 0);
-   return 0;
+   break;
 
case KDMKTONE:
if (!perm)
-   return -EPERM;
+   goto eperm;
{
unsigned int ticks, count;

@@ -412,7 +418,7 @@
if (count)
count = CLOCK_TICK_RATE / count;
kd_mksound(count, ticks);
-   return 0;
+   break;
}
 
case KDGKBTYPE:
@@ -435,14 +441,18 @@
 * KDADDIO and KDDELIO may be able to add ports beyond what
 * we reject here, but to be safe...
 */
-   if (arg  GPFIRST || arg  GPLAST)
-   return -EINVAL;
-   return sys_ioperm(arg, 1, (cmd == KDADDIO)) ? -ENXIO : 0;
+   if (arg  GPFIRST || arg  GPLAST) {
+   ret = -EINVAL;
+   break;
+   }
+   ret = sys_ioperm(arg, 1, (cmd == KDADDIO)) ? -ENXIO : 0;
+   break;
 
case KDENABIO:
case KDDISABIO:
-   return sys_ioperm(GPFIRST, GPNUM,
+   ret = sys_ioperm(GPFIRST, GPNUM,
  (cmd == KDENABIO)) ? -ENXIO : 0;
+   break;
 #endif
 
/* Linux m68k/i386 interface for setting the keyboard delay/repeat rate 
*/
@@ -450,19 +460,20 @@
case KDKBDREP:
{
struct kbd_repeat kbrep;
-   int err;

if (!capable(CAP_SYS_TTY_CONFIG))
-   return -EPERM;
+   goto eperm;
 
-   if (copy_from_user(kbrep, up, sizeof(struct kbd_repeat)))
-   return -EFAULT;
-   err = kbd_rate(kbrep);
-   if (err)
-   return err;
+   if (copy_from_user(kbrep, up, sizeof(struct kbd_repeat))) {
+   ret =  -EFAULT;
+   break;
+   }
+   ret = kbd_rate(kbrep);
+   if (ret)
+   break;
if (copy_to_user(up, kbrep, sizeof(struct kbd_repeat)))
-   return -EFAULT;
-   return 0;
+   ret = -EFAULT;
+   break;
}
 
case KDSETMODE:
@@ -475,7 +486,7 @@
 * need to restore their engine state. --BenH
 */
if (!perm)
-   return -EPERM;
+   goto eperm;
switch (arg) {
case KD_GRAPHICS:
break;
@@ -485,13 +496,14 @@
case KD_TEXT:
break;
default:
-   return -EINVAL;
+   ret = -EINVAL;
+   goto out;
}
if (vc-vc_mode == (unsigned char) arg)
-   return 0;
+   break;
vc-vc_mode = (unsigned char) arg;
if (console != fg_console)
-   return 0;
+   break;
/*
 * explicitly blank/unblank the screen if switching modes
 */
@@ -501,7 +513,7 @@
else
do_blank_screen(1);
release_console_sem();
-   return 0;
+

Re: [patch 1/3] x86_64: CPA, fix cache attribute inconsistency bug, v2.6.22 backport

2008-02-20 Thread Vivek Goyal

On Wed, Feb 20, 2008 at 03:30:18PM -0500, Vivek Goyal wrote:
 On Fri, Feb 15, 2008 at 08:58:22PM +0100, Ingo Molnar wrote:
  
  fix CPA cache attribute bug in v2.6.23. When phys_base is nonzero
  (when CONFIG_RELOCATABLE=y) then change_page_attr_addr() miscalculates
  the secondary alias address by -14 MB (depending on the configured
  offset).
  
  The default 64-bit kernels of Fedora and Ubuntu are affected:
  
 $ grep RELOCA /boot/config-2.6.23.9-85.fc8
   CONFIG_RELOCATABLE=y
  
 $ grep RELOC /boot/config-2.6.22-14-generic
   CONFIG_RELOCATABLE=y
  
  and probably on many other distros as well.
  
  the bug affects all pages in the first 40 MB of physical RAM that
  are allocated by some subsystem that does ioremap_nocache() on them:
  
 if (__pa(address)  KERNEL_TEXT_SIZE) {
  
  Hence we might leave page table entries with inconsistent cache
  attributes around (pages mapped at both UnCacheable and Write-Back),
  and we can also set the wrong kernel text pages to UnCacheable.
  
  the effects of this bug can be random slowdowns and other misbehavior.
  If for example AGP allocates its aperture pages into the first 40 MB
  of physical RAM, then the -14 MB bug might mark random kernel texto
  pages as uncacheable, slowing down a random portion of the 64-bit
  kernel until the AGP driver is unloaded.
  
  Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
  Acked-by: Thomas Gleixner [EMAIL PROTECTED]
  ---
   arch/x86_64/mm/pageattr.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  Index: linux-tmp/arch/x86_64/mm/pageattr.c
  ===
  --- linux-tmp.orig/arch/x86_64/mm/pageattr.c
  +++ linux-tmp/arch/x86_64/mm/pageattr.c
  @@ -204,7 +204,7 @@ int change_page_attr_addr(unsigned long 
  if (__pa(address)  KERNEL_TEXT_SIZE) {
 
 Hi Ingo,
 
 Should we change above condition also to something like following.
 
 kernel_phys_start = __pa(__START_KERNEL_map) + phys_base


Oops. Just noticed that __pa() is already taking care of adding phys_base.
So it should probably be.

kernel_phys_start = __pa(__START_KERNEL_map);
kernel_phys_end = kernel_phys_start + KERNEL_TEXT_SIZE;

if (__pa(address) = kernel_phys_start
 __pa(address) = kernel_phys_end)  

Thanks
Vivek
--
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] isdn_tty: Prepare for BKL push down

Three things here
- Remove softcar handler
- Correct termios change detection logic
- Wrap break/ioctl in lock_kernel ready to drop it in the caller

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/isdn/i4l/isdn_tty.c 
linux-2.6.25-rc2-mm1/drivers/isdn/i4l/isdn_tty.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/isdn/i4l/isdn_tty.c2008-02-19 
11:03:00.0 +
+++ linux-2.6.25-rc2-mm1/drivers/isdn/i4l/isdn_tty.c2008-02-20 
11:50:10.0 +
@@ -1352,12 +1352,14 @@
if (tty-flags  (1  TTY_IO_ERROR))
return -EIO;
 
+   lock_kernel();
 #ifdef ISDN_DEBUG_MODEM_IOCTL
printk(KERN_DEBUG ttyI%d ioctl TIOCMGET\n, info-line);
 #endif
 
control = info-mcr;
status = info-msr;
+   unlock_kernel();
return ((control  UART_MCR_RTS) ? TIOCM_RTS : 0)
| ((control  UART_MCR_DTR) ? TIOCM_DTR : 0)
| ((status  UART_MSR_DCD) ? TIOCM_CAR : 0)
@@ -1381,6 +1383,7 @@
printk(KERN_DEBUG ttyI%d ioctl TIOCMxxx: %x %x\n, info-line, set, 
clear);
 #endif
 
+   lock_kernel();
if (set  TIOCM_RTS)
info-mcr |= UART_MCR_RTS;
if (set  TIOCM_DTR) {
@@ -1402,6 +1405,7 @@
isdn_tty_modem_hup(info, 1);
}
}
+   unlock_kernel();
return 0;
 }
 
@@ -1435,21 +1439,6 @@
return retval;
tty_wait_until_sent(tty, 0);
return 0;
-   case TIOCGSOFTCAR:
-#ifdef ISDN_DEBUG_MODEM_IOCTL
-   printk(KERN_DEBUG ttyI%d ioctl TIOCGSOFTCAR\n, 
info-line);
-#endif
-   return put_user(C_CLOCAL(tty) ? 1 : 0, (ulong __user *) 
arg);
-   case TIOCSSOFTCAR:
-#ifdef ISDN_DEBUG_MODEM_IOCTL
-   printk(KERN_DEBUG ttyI%d ioctl TIOCSSOFTCAR\n, 
info-line);
-#endif
-   if (get_user(arg, (ulong __user *) arg))
-   return -EFAULT;
-   tty-termios-c_cflag =
-   ((tty-termios-c_cflag  ~CLOCAL) |
-(arg ? CLOCAL : 0));
-   return 0;
case TIOCSERGETLSR: /* Get line status register */
 #ifdef ISDN_DEBUG_MODEM_IOCTL
printk(KERN_DEBUG ttyI%d ioctl TIOCSERGETLSR\n, 
info-line);
@@ -1472,13 +1461,14 @@
if (!old_termios)
isdn_tty_change_speed(info);
else {
-   if (tty-termios-c_cflag == old_termios-c_cflag)
+   if (tty-termios-c_cflag == old_termios-c_cflag 
+   tty-termios-c_ispeed == old_termios-c_ispeed 
+   tty-termios-c_ospeed == old_termios-c_ospeed)
return;
isdn_tty_change_speed(info);
if ((old_termios-c_cflag  CRTSCTS) 
-   !(tty-termios-c_cflag  CRTSCTS)) {
+   !(tty-termios-c_cflag  CRTSCTS))
tty-hw_stopped = 0;
-   }
}
 }
 
--
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: [Suspend-devel] 2.6.25-rc2 System no longer powers off after suspend-to-disk. Screen becomes green.

2008-02-20 Thread Rafael J. Wysocki

On Wednesday, 20 of February 2008, Linus Torvalds wrote:
 
 On Wed, 20 Feb 2008, Rafael J. Wysocki wrote:
  
  I think we should export the target sleep state somehow.
 
 Yeah. By *not* using -suspend() for freezing or hibernate.
 
 Please, Rafael - just make the f*cking suspend-to-disk use other routines 
 already.

Okay, I think I'll just start sending patches for that, but rather not earlier
than in the 2.6.27 time frame.  No one else works on that and I've been busy
with other things recently.  Besides, I'm not even a full time kernel
developer ...

 99% of all hardware needs to do exactly *nothing* on suspend-to-disk, and the
 ones that really do need things tend to need to not do a whole lot.
 
 For example, the freeze action for USB (which is one of the hardest 
 things to suspend) should literally be something like just setting the 
 controller STOP bit, and waiting for it to have stopped. The unfreeze 
 should be to just clear the stop bit, while the restart should be just a 
 controller reset to use the current memory image.
 
 NONE OF THIS HAS ABSOLUTELY ANYTHING TO DO WITH SUSPEND.
 
 It never did. I've told people so for years. Maybe actually seeing the 
 problems will make people realize.

I think so.

 So please, we shouldn't call -suspend[_late] or -resume[_early] at 
 all. Not with PMSG_FREEZE, not with PMSG_*anything*.
 
 Can we please get this fixed some day? 

Yes, we can (hopefully).

Thanks,
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] 68360serial: Note that there isn't any info-mcr locking

Noticed while auditing the code for the BKL elimination project

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.25-rc2-mm1/drivers/serial/68360serial.c 
linux-2.6.25-rc2-mm1/drivers/serial/68360serial.c
--- linux.vanilla-2.6.25-rc2-mm1/drivers/serial/68360serial.c   2008-02-19 
11:01:44.0 +
+++ linux-2.6.25-rc2-mm1/drivers/serial/68360serial.c   2008-02-20 
11:52:17.0 +
@@ -1281,7 +1281,7 @@
 
if (tty-flags  (1  TTY_IO_ERROR))
return -EIO;
-
+   /* FIXME: locking on info-mcr */
if (set  TIOCM_RTS)
info-mcr |= UART_MCR_RTS;
if (set  TIOCM_DTR)
--
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] nfsd: fix sparse warnings