[PATCH] ACPI: fix processor throttling set error

[Yi Yang]

Subject: ACPI: fix processor throttling set error
From: Yi Yang <[EMAIL PROTECTED]>

When echo some invalid values to /proc/acpi/processor/*/throttling,
there isn't any error info returned, on the contray, it sets
throttling value to some T* successfully, obviously, this is incorrect,
a correct way should be to let it fail and return error info.

This patch fixed the aforementioned issue, it also enables
/proc/acpi/processor/*/throttling to accept such values as 't0' and 'T0',
it also strictly limits /proc/acpi/processor/*/throttling only to accept
 "*", "t*" and "T*", "*" is the throttling state value the processor can
support, current, it is 0 - 7.

Before applying this patch, the test result is below:

[EMAIL PROTECTED] acpi]# cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state:T1
state available: T0 to T7
states:
T0:  100%
   *T1:  87%
T2:  75%
T3:  62%
T4:  50%
T5:  37%
T6:  25%
T7:  12%
[EMAIL PROTECTED] acpi]# echo "1xx" > /proc/acpi/processor/CPU0/throttling
[EMAIL PROTECTED] acpi]# cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state:T1
state available: T0 to T7
states:
T0:  100%
   *T1:  87%
T2:  75%
T3:  62%
T4:  50%
T5:  37%
T6:  25%
T7:  12%
[EMAIL PROTECTED] acpi]# echo "0" > /proc/acpi/processor/CPU0/throttling
[EMAIL PROTECTED] acpi]# cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state:T0
state available: T0 to T7
states:
   *T0:  100%
T1:  87%
T2:  75%
T3:  62%
T4:  50%
T5:  37%
T6:  25%
T7:  12%
[EMAIL PROTECTED] acpi]# cd /
[EMAIL PROTECTED] /]# cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state:T0
state available: T0 to T7
states:
   *T0:  100%
T1:  87%
T2:  75%
T3:  62%
T4:  50%
T5:  37%
T6:  25%
T7:  12%
[EMAIL PROTECTED] /]# echo "T0" > /proc/acpi/processor/CPU0/throttling
[EMAIL PROTECTED] /]# cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state:T0
state available: T0 to T7
states:
   *T0:  100%
T1:  87%
T2:  75%
T3:  62%
T4:  50%
T5:  37%
T6:  25%
T7:  12%
[EMAIL PROTECTED] /]# echo "T7" > /proc/acpi/processor/CPU0/throttling
[EMAIL PROTECTED] /]# cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state:T0
state available: T0 to T7
states:
   *T0:  100%
T1:  87%
T2:  75%
T3:  62%
T4:  50%
T5:  37%
T6:  25%
T7:  12%
[EMAIL PROTECTED] /]# echo "T100" > /proc/acpi/processor/CPU0/throttling
[EMAIL PROTECTED] /]# cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state:T0
state available: T0 to T7
states:
   *T0:  100%
T1:  87%
T2:  75%
T3:  62%
T4:  50%
T5:  37%
T6:  25%
T7:  12%
[EMAIL PROTECTED] /]# echo "xxx" > /proc/acpi/processor/CPU0/throttling
[EMAIL PROTECTED] /]# cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state:T0
state available: T0 to T7
states:
   *T0:  100%
T1:  87%
T2:  75%
T3:  62%
T4:  50%
T5:  37%
T6:  25%
T7:  12%
[EMAIL PROTECTED] /]# echo "2" > /proc/acpi/processor/CPU0/throttling
[EMAIL PROTECTED] /]# cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state:T2
state available: T0 to T7
states:
T0:  100%
T1:  87%
   *T2:  75%
T3:  62%
T4:  50%
T5:  37%
T6:  25%
T7:  12%
[EMAIL PROTECTED] /]# echo "" > /proc/acpi/processor/CPU0/throttling
[EMAIL PROTECTED] /]# cat /proc/acpi/processor/CPU0/throttling
state count: 8
active state:T0
state available: T0 to T7
states:
   *T0:  100%
T1: 

Re: Module for simulating network default

[Paul Rolland]

Hello,

On Sun, 06 Jan 2008 23:42:07 -0800 (PST)
David Miller <[EMAIL PROTECTED]> wrote:

> From: Paul Rolland <[EMAIL PROTECTED]>
> Date: Mon, 7 Jan 2008 08:37:04 +0100
> 
> > I remember reading some time ago about a network driver to "simulate"
> > network default, for example packet loss...
> > Unfortunately, I can't find the post, neither in my mailbox nor in
> > archives...
> > 
> > Does anyone has an URL that you could send me ?
> 
> You want the "netem" packet scheduler, and you'll get better
> answers to networking questions on the networking list
> [EMAIL PROTECTED]

Thanks David, I'll have a look at this. 

For netdev, as I'm not subscribed, please don't forget to copy me on reply ;)

Regards,
Paul
--
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: Module for simulating network default

[David Miller]

From: Paul Rolland <[EMAIL PROTECTED]>
Date: Mon, 7 Jan 2008 08:37:04 +0100

> I remember reading some time ago about a network driver to "simulate"
> network default, for example packet loss...
> Unfortunately, I can't find the post, neither in my mailbox nor in
> archives...
> 
> Does anyone has an URL that you could send me ?

You want the "netem" packet scheduler, and you'll get better
answers to networking questions on the networking list
[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/

Module for simulating network default

[Paul Rolland]

Hello,

I remember reading some time ago about a network driver to "simulate"
network default, for example packet loss...
Unfortunately, I can't find the post, neither in my mailbox nor in
archives...

Does anyone has an URL that you could send me ?

Regards,
Paul
--
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/

[RFC] netns / sysfs interaction

[Al Viro]

As much as I hate to touch either subject, let alone both at
once...  Eric, would you mind explaining what exactly do you want
sysfs to do in presense of your "namespaces"?  On the "what does user
see if we do <...>" level.

a) what happens if I do chdir("/sys/class/net/eth42/") and then
migrate?

b) what happens to /sys/class/net/eth0/device visibility/things
it points to/etc.?

c) what happens to open files?  E.g. to /sys/class/net - say it,
if migration happens between two getdents(2).

d) what happens to visibility in other parts of sysfs?  E.g. to
things like
$ ls  /sys/devices/pci\:00/\:00\:0a.0/
bus device  local_cpus  power  resource1 uevent
class   driver  modaliasresource   subsystem_device  vendor
config  irq net:eth0resource0  subsystem_vendor
$
See that net:eth0 in there?  Are all such suckers seen?

e) while we are at it, wouldn't seeing the information in
/sys/devices/pci in general defeat whatever purpose you have in mind
for your stuff?

Context: we need sane locking for sysfs.  I think I have a more or less
workable scheme, but its feasibility depends big way on what netns needs
to have.
--
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: + restore-missing-sysfs-max_cstate-attr.patch added to -mm tree

[Andrew Morton]

On Sun, 06 Jan 2008 16:34:16 -0500 Mark Lord <[EMAIL PROTECTED]> wrote:

> Venki Pallipadi wrote:
> > Reintroduce run time configurable max_cstate for !CPU_IDLE case.
> > 
> > Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
> > 
> > Index: linux-2.6.24-rc/drivers/acpi/processor_idle.c
> > ===
> > --- linux-2.6.24-rc.orig/drivers/acpi/processor_idle.c
> > +++ linux-2.6.24-rc/drivers/acpi/processor_idle.c
> > @@ -76,7 +76,11 @@ static void (*pm_idle_save) (void) __rea
> >  #define PM_TIMER_TICKS_TO_US(p)(((p) * 
> > 1000)/(PM_TIMER_FREQUENCY/1000))
> >  
> >  static unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER;
> > +#ifdef CONFIG_CPU_IDLE
> >  module_param(max_cstate, uint, );
> > +#else
> > +module_param(max_cstate, uint, 0644);
> > +#endif
> >  static unsigned int nocst __read_mostly;
> >  module_param(nocst, uint, );
> >  
> ..
> 
> Can we get this patch upstream so that a stock 2.6.24 will work here?
> 

umm, OK, I queued it for 2.6.24.  I'll give people a day or so to comment
on this.

I had to invent some silly changlelog for it.  Please review it for
accuracy and completeness?

It isn't complete, really.  How come we only make max_cstate writeable if
CONFIG_CPU_IDLE=n?  What happens to people who were reliant upon writeable
max_cstate who now enable CPU_IDLE?  Things still break?  What is the
rationale behind this?  What constraints led us to this decision?




From: Venki Pallipadi <[EMAIL PROTECTED]>

This was writeable in 2.6.23 but the cpuidle merge made it read-only.  But
some people's scripts (ie: Mark's) were writing to it.

As an unhappy compromise, make max_cstate writeable again if the kernel was
configured without CONFIG_CPU_IDLE.

Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]>
Cc: Mark Lord <[EMAIL PROTECTED]>
Cc: Arjan van de Ven <[EMAIL PROTECTED]>
Cc: Len Brown <[EMAIL PROTECTED]>
Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: "Rafael J. Wysocki" <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---

 drivers/acpi/processor_idle.c |4 
 1 file changed, 4 insertions(+)

diff -puN 
drivers/acpi/processor_idle.c~reintroduce-run-time-configurable-max_cstate-for-cpu_idle-case
 drivers/acpi/processor_idle.c
--- 
a/drivers/acpi/processor_idle.c~reintroduce-run-time-configurable-max_cstate-for-cpu_idle-case
+++ a/drivers/acpi/processor_idle.c
@@ -76,7 +76,11 @@ static void (*pm_idle_save) (void) __rea
 #define PM_TIMER_TICKS_TO_US(p)(((p) * 
1000)/(PM_TIMER_FREQUENCY/1000))
 
 static unsigned int max_cstate __read_mostly = ACPI_PROCESSOR_MAX_POWER;
+#ifdef CONFIG_CPU_IDLE
 module_param(max_cstate, uint, );
+#else
+module_param(max_cstate, uint, 0644);
+#endif
 static unsigned int nocst __read_mostly;
 module_param(nocst, uint, );
 
_

--
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: regression: sysctl_check changes in 2.6.24 are O(n) resulting in slow creation of 10000 network interfaces

[David Miller]

From: [EMAIL PROTECTED] (Eric W. Biederman)
Date: Sun, 06 Jan 2008 23:57:57 -0700

> Why do we need 1 interfaces?  Why isn't network device creation a
> slow path?

Because people create virtual devices like mad.

> So is this a bug report telling me that there are users with
> 10k or 100k interfaces that care.  So we need to fix sysctl.

Unquestionably, we do, it's a major regression.

People create thousands of VLAN devices, as one of many examples, all
the time.

That's why we even bother hashing network devices in the network code.
--
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 4/8] CRIS: Remove 'TOPDIR' from Makefiles

[Mikael Starvik]

>PS. Mikael - should Jesper be mentioned in MAINTAINERS?

Yes, that is a good idea. Down the road Jesper will take over maintainership
I guess.

-Original Message-
From: Sam Ravnborg [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, January 01, 2008 11:20 AM
To: WANG Cong
Cc: Mikael Starvik; LKML; [EMAIL PROTECTED]; Andrew Morton;
dev-etrax
Subject: Re: [Patch 4/8] CRIS: Remove 'TOPDIR' from Makefiles


On Tue, Jan 01, 2008 at 03:29:22PM +0800, WANG Cong wrote:
> 
> TOPDIR is obsolete, use objtree instead.
> This patch removes TOPDIR from all Cris Makefiles.
> 
> Cc: Mikael Starvik <[EMAIL PROTECTED]>
> Cc: Sam Ravnborg <[EMAIL PROTECTED]>
> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
> 
> ---
> 
> diff --git a/arch/cris/arch-v32/boot/compressed/Makefile
b/arch/cris/arch-v32/boot/compressed/Makefile
> index 9f77eda..8586922 100644
> --- a/arch/cris/arch-v32/boot/compressed/Makefile
> +++ b/arch/cris/arch-v32/boot/compressed/Makefile
> @@ -7,7 +7,7 @@
>  target = $(target_compressed_dir)
>  src= $(src_compressed_dir)
>  
> -CC = gcc-cris -mlinux -march=v32 -I $(TOPDIR)/include
> +CC = gcc-cris -mlinux -march=v32 -I $(objtree)/include

As in the mips case the right fix is to use:
> +CC = gcc-cris -mlinux -march=v32 -Iinclude -Iinclude2

In this way we pick up the includes also in the O=..
case.

PS. Mikael - should Jesper be mentioned in MAINTAINERS?

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: regression: sysctl_check changes in 2.6.24 are O(n) resulting in slow creation of 10000 network interfaces

[Eric W. Biederman]

Benjamin LaHaise <[EMAIL PROTECTED]> writes:

> Hello folks,
>
> 2.6.24-rc6 regresses on the 1 network interface creation test relative to 
> 2.6.23.  The cause appears to be the new code in sysctl_check_lookup(), which 
> shows up as the #1 item while profiling.  Is a revert of this new code 
> possible until its scaling issues are fixed?  2.6.23 can do more than 100 new 
> network interfaces per second for the first few thousand devices, but with 
> 2.6.24-rc6 the results drop off rather dramatically to less than 10 interfaces
> per second.  The 1 interface test is unbearable with the new sysctl_check 
> code.

Why do we need 1 interfaces?  Why isn't network device creation a
slow path?

The problem seems to be in the data structures used by sysctl.
You are increasing the length of the linked list each time you
add a network interface.  So sysctl lookups slow down.
At 1 entries that is a long linked list walk.

At 10 things get even longer.  Now the numbers you report still
seem like a lot of time to me.  My guess would be that we are getting
badly into cache miss territory.

If what you describe is a real scenario where users care we need
to fix the sysctl data structures so that they scale.

Because of this bug report and another one I got earlier today
about a real bug in the parallel port code detected by the very
lookup that is slowing you down.  I am quite reluctant to contemplate
pulling this code.  It seems to be doing it's job, if in some cases
uncomfortably so.

So is this a bug report telling me that there are users with
10k or 100k interfaces that care.  So we need to fix sysctl.

Is there a specific kernel test case that is run often that having
slow sysctl performance matters for?  CONFIG_SYSCTL=n should solve
that if it is specialized.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] scsi: Use new __dma_buffer to align sense buffer in scsi_cmnd

[FUJITA Tomonori]

On Sun, 23 Dec 2007 13:09:05 +0200
Boaz Harrosh <[EMAIL PROTECTED]> wrote:

> On Fri, Dec 21 2007 at 4:30 +0200, Benjamin Herrenschmidt <[EMAIL PROTECTED]> 
> wrote:
> > The sense buffer ins scsi_cmnd can nowadays be DMA'ed into directly
> > by some low level drivers (that typically happens with USB mass
> > storage).
> > 
> > This is a problem on non cache coherent architectures such as
> > embedded PowerPCs where the sense buffer can share cache lines with
> > other structure members, which leads to various forms of corruption.
> > 
> > This uses the newly defined __dma_buffer annotation to enforce that
> > on such platforms, the sense_buffer is contained within its own
> > cache line. This has no effect on cache coherent architectures.
> > 
> > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> > ---
> > 
> >  include/scsi/scsi_cmnd.h |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > --- linux-merge.orig/include/scsi/scsi_cmnd.h   2007-12-21 
> > 13:07:14.0 +1100
> > +++ linux-merge/include/scsi/scsi_cmnd.h2007-12-21 13:07:29.0 
> > +1100
> > @@ -88,7 +88,7 @@ struct scsi_cmnd {
> >working on */
> >  
> >  #define SCSI_SENSE_BUFFERSIZE  96
> > -   unsigned char sense_buffer[SCSI_SENSE_BUFFERSIZE];
> > +   unsigned char sense_buffer[SCSI_SENSE_BUFFERSIZE] __dma_buffer;
> > /* obtained by REQUEST SENSE when
> >  * CHECK CONDITION is received on original
> >  * command (auto-sense) */
> 
> This has the potential of leaving a big fat ugly hole in the middle of 
> scsi_cmnd. I would suggest of *just* moving the sense_buffer array to be
> the *first member* of struct scsi_cmnd. The command itself is already cache
> aligned, allocated by the proper flags to it's slab. And put a fat comment
> near it's definition.
> 
> This is until a proper fix is sent. I have in my Q a proposition for a 
> more prominent solution, which I will send next month. Do to short comings
> in the sense handling and optimizations, but should definitely cover this
> problem.
> 
> The code should have time to be discussed and tested, so it is only 2.6.26
> material. For the duration of the 2.6.25 kernel we can live with a reorder
> of scsi_cmnd members, if it solves such a grave bug for some ARCHs.
> 
> Boaz
> 
> [RFD below]
> My proposed solution will be has follows:
> 
>  1. Since the scsi protocol mandates an immediate REQUEST_SENSE after an error
> in effect the Q is frozen until the REQUEST_SENSE command returns.
> 
>  2. The scsi-ml needs the sense buffer for its normal operation, independent 
> from the ULD's request of the sence_buffer or not at request->sense. But
> in effect, 90% of all scsi-requests come with ULD's allocated buffer for
> sense, that is copied to, on command completion.
> 
>  3. 99% of all commands complete successfully, so if an optimization is 
> proposed for the successful case, sacrificing a few cycles for the error
> case than thats a good thing.
> 
>  My suggestion is to have a per Q, driver-overridable, sense buffer that is 
>  DMAed/written to by drivers. At the end of the REQUEST_SENSE command one
>  of 2 things will be done. Either copy the sense to the ULD's supplied buffer,
>  or if not available, allocate one from a dedicated mem_cache pool.
>  
>  So we are completely saving 92 bytes from scsi_cmnd by replacing the buffer
>  with a pointer. We can always read the sense into a per Q buffer. And 10% of
>  %1 of the times we will need to allocate a sense buffer from a dedicated 
> mem_cache
>  I would say thats a nice optimization.
> 
>  The changes to scsi_error/scsi_cmnd and friends, is pretty strait forward. 
> But
>  it depends on a conversion of 4/5 drivers to the new scsi_eh API for 
>  REQUEST_SENSE. I have only converted these drivers that interfered with the 
> accessors
>  effort + 1 other places. But there are a few more places that are not 
> converted.
>  Once done. The implementation can easily change with no affect on drivers.

I think that removing the sense_buffer array from scsi_cmnd effects
lots of LLDs. As I wrote in other mail, many LLDs assume that
scsi_cmnd:sense_buffer is always available. Another big task is to
take care about auto sense.

Have you already had some patches? I've just started to work on this
and I'd like to push that fix into 2.6.25.
--
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: general config preemption Q: preempt-model and Big-Lock Preemption

[Nick Piggin]

On Saturday 05 January 2008 14:25, Linda Walsh wrote:
> A question that comes to mind every time I go through the settings
> for "Preemption Model" and "Preempt The Big Kernel Lock".
>
> Do each of the combinations "make sense", or are some "no-ops"?
> For model, we have 1) no forced (server), 2) Voluntary (Desktop)
> 3) preemptible (low-latency Desktop), and for Big Lock Preemption (BLP),
> we have "yes" or "no".
>
> Questions:
>
> 1) What is the difference between "no forced" and "voluntary"?  Doesn't
>   voluntary normally mean "not forced"?

voluntary adds a few more cond_resched() points.


> 2) If a process is not preemptible, then it seems this would be "doubly
>   so" in the kernel when the big-lock is held.  So does the big-lock
>   preemption question have any effect (when preempt-model="no forced").

With BLP, AFAIK code may not assume preemption is disabled. Debug checks
should have caught any offenders by now.

When there is no kernel preemption, I guess BLP still allows contenders
to sleep and switch rather than spin, so it might improve throughput (or
harm it!).


> 3) If a process is "fully preemptible" but "BLP=false", is that
>   much different than "voluntary preemption" & BLP=false?  I.e. --
>   should 'preemptible kernel' also imply "BLP=true"...i.e.

Yeah, they're all slightly different I think, but it probably is too much
config options at this point in time. I think Ingo plans to make BLP the
default and remove the config option.
--
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.24-rc6 oops in net_tx_action

[linux]

> [EMAIL PROTECTED] <[EMAIL PROTECTED]> :
>> Kernel is 2.6.24-rc6 + linuxpps patches, which are all to the serial
>> port driver.
>> 
>> 2.6.23 was known stable.  I haven't tested earlier 2.6.24 releases.
>> I think it happened once before; I got a black-screen lockup with
>> keyboard LEDs blinking, but that was with X running so I couldn't see a
>> console oops.  But given that I installed 2.6.24-rc6 about 24 hours ago,
>> that's a disturbing pattern.

> It is probably this one:
>
> http://marc.info/?t=11978279403=1=2

Thanks!  I got the patch from
http://marc.info/?l=linux-netdev=119756785219214
(Which didn't make it into -rc7; please fix!)
and am recompiling now.

Actually, I grabbed the hardware mitigation followon patch while I was
at it.  I notice that the comment explaining the format of CSR11 and
what 0x80F1 means got lost; perhaps it would be nice to resurrect it?

0x80F1
  8000 = Cycle size (timer control)
  7800 = TX timer in 16 * Cycle size
  0700 = No. pkts before Int. (0 =  interrupt per packet)
  00F0 = Rx timer in Cycle size
  000E = No. pkts before Int.
  0001 = Continues mode (CM)
  
(Boy, that tulip driver could use a whitespace overhaul.)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] sg_ring: a ring of scatterlist arrays

[Tejun Heo]

Rusty Russell wrote:
> On Monday 07 January 2008 16:01:40 Tejun Heo wrote:
>>> But we hit the same problems:
>>>
>>> 1) sg_chain loses information.  The clever chain packaging makes reading
>>> easy, but manipulation is severely limited.  You can append to your own
>>> chains by padding, but not someone elses.  This works for SCSI, but what
>>> about the rest of us?  And don't even think of joining mapped chains: it
>>> will almost work.
>> You can append by allocating one more element on the chain to be
>> appended and moving the last element of the first chain to it while
>> using the last element for chaining.
> 
> Hi Tejun,
> 
>Nice try!  Even ignoring the ugliness of undoing such an operation if the 
> caller doesn't expect you to mangle their chains, consider a one-element sg 
> array. :(

Heh heh, that can be dealt with by skipping the first chain if the first
chain is empty after chaining.  Please take a look at
ata_sg_setup_extra() in the following.

http://git.kernel.org/?p=linux/kernel/git/tj/libata-dev.git;a=blob;f=drivers/ata/libata-core.c;h=32dde5bbc75ed53e89ac17040da2cd0621a37161;hb=c8847e473a4a2844244784226eb362be10d52ce9

That said, yeah, it's seriously ugly.  Restoring the original sg is ugly
too.  I definitely agree that we need some improvements here.

-- 
tejun
--
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.24-rc6-mm1

[FUJITA Tomonori]

On Sun, 6 Jan 2008 21:03:42 +0100
"Torsten Kaiser" <[EMAIL PROTECTED]> wrote:

> On Jan 6, 2008 2:33 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > On Sun, 6 Jan 2008 12:35:35 +0100
> > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > > On Jan 6, 2008 12:23 PM, FUJITA Tomonori <[EMAIL PROTECTED]> wrote:
> > > > On Sun, 6 Jan 2008 11:41:10 +0100
> > > > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote:
> > > > > I will applie your patch and see if this hunk from
> > > > > find_next_zero_area() makes a difference:
> > > > >
> > > > >end = index + nr;
> > > > > -   if (end > size)
> > > > > +   if (end >= size)
> > > > > return -1;
> 
> -> that might still have made a difference, but ...
> 
> > > > > -   for (i = index + 1; i < end; i++) {
> > > > > +   for (i = index; i < end; i++) {
> 
> ... as you say below, the test for the index position is only needed
> if index is modified after find_next_zero_bit().
> 
> > > > > if (test_bit(i, map)) {
> > > >
> > > > The patch should not make a difference for X86_64.
> > >
> > > Hmm...
> > > arch/x86/kernel/pci-gart_64.c:
> > > alloc_iommu() calls iommu_area_alloc()
> > > lib/iommu-helper.c:
> > > iommu_area_alloc() calls find_next_zero_area()
> > > -> so the above code should be called even on X86_64
> >
> > Oops, I meant that the patch fixes the align allocation (non zero
> > align_mask case). X86_64 doesn't use the align allocation.
> >
> >
> > > And the change in the for loop means that 'index' will now be tested,
> > > but with the old code it was not.
> >
> > With the old code, 'index' is tested by find_next_zero_bit.
> >
> > With the new code and non zero align_mask case, 'index' is not tested
> > by find_next_zero_bit. So test_bit needs to start with 'index'.
> >
> > So If I understand the correctly, this patch should not make a
> > difference for x86_64 though I might miss something.
> 
> You did not miss anything.
> After 18 packages my system crashed again.
> 
> > > And double using something does fit with the errors I'm seeing...
> > >
> > > > Can you try the patch to revert my IOMMU changes?
> > > >
> > > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg12694.html
> > >
> > > Testing for this bug is a little bit slow, as I'm compiling ~100
> > > packages trying to trigger it.
> > > If my current testrun with the patch from
> > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg12702.html
> > > crashes, I will revert the hole IOMMU changes with above patch and try 
> > > again.
> >
> > Thanks for testing,
> 
> OK, I'm still testing this, but after 95 completed packages I'm rather
> certain that reverting the IOMMU changes with this patch fixes my
> problem.
> I didn't have time to look more into this, so I can't offer any
> concrete ideas where the bug is.
> 
> If you send more patches, I'm willing to test them, but it might take
> some more time during the next week.

Can you try 2.6.24-rc7 + the IOMMU changes?

The patches are available at:

http://www.kernel.org/pub/linux/kernel/people/tomo/iommu/

Or if you prefer the git tree:

git://git.kernel.org/pub/scm/linux/kernel/git/tomo/linux-2.6-misc.git 
iommu-sg-fixes



I've looked at the changes to GART but they are straightforward and
don't look wrong...


Thanks,
--
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: "mconf" and help texts

[Ph. Marek]

Hell Roman!

Thank you for your answer.

On Montag, 7. Januar 2008, Roman Zippel wrote:
> On Thursday 3. January 2008, Ph. Marek wrote:
> > So I took a look at "Help", and saw that blob:
...
> > That is a _bit_ unreadable.
>
> What you see here is the internal representation of the select expression.
> To make it more easily readable, you could just cut off everything between
> && and || (it's the dependency of the symbol which does the select, the one
> before &&).
> The readable expression could be generated when needed, but it might be
> easier to just generate at the same time as the full expression (in
> menu_finalize).
>
> > As a side-node - I cannot get xconfig to work (pkg-config);
>
> Why exactly? What's the error message?
  CHECK   qt
*
* Unable to find the QT3 installation. Please make sure that
* the QT3 development package is correctly installed and
* either install pkg-config or set the QTDIR environment
* variable to the correct location.
*
I didn't find a package for debian that has a qt3.pc.

> > is there some
> > way in menuconfig to see why some config option is disallowed? The
> > location tree shows some data ("-> Networking support (NET [=y])"), but
> > not for all dependencies.
>
> I don't quite understand. The dependency for option itself is above the
> location tree and the for dependencies of the dependencies you have to look
> at their individual info.
If there's some option I currently can not choose (because of the 
dependencies), I'd like to see *which* dependency (-ies) prohibit that.

If all I see is
  Depends on: NET && INET && NETFILTER && NF_CONNTRACK
I have to manually hunt down which isn't enabled.

> > [Does xconfig allow enabling them while seeing this option?]
>
> Only if you enable the missing dependency. This is insofar a little easier
> as they are linked if you enable the deubg info, so the prompt may be a
> little easier to find.
So there's no easy way to say "I want that ... aktivate that, that and this 
option as needed", and it recurses through the symbols.


Thank you!


Regards,

Phil
--
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: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop

[Mike Galbraith]

> [ 1687.358730]  [] sys_sync+0xa/0x17

duh.

--
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/

bugreport kernel panic on early stage, with HIGHMEM4G:

[Denys Fedoryshchenko]

Hi

After physical memory upgrade from 3GB to 4GB (also it happens on 5GB) got 
kernel panic.

Because it is happening on early stage and my machine doesn't contain serial 
port, i had to take photo.
Kernel boots fine with 64GB highmem, no highmem, or highmem4G with limited 
memory by mem=3G. All dmesg attached.
Also i attach dmidecode and lspci -vvv output, probably it will be useful.


Photo (2.8MB, sorry, just original size from camera):
http://www.nuclearcat.com/files/panic-07012008/img_1232.jpg

dmesg without highmem
http://www.nuclearcat.com/files/panic-07012008/dmesg-nohighmem.txt

with highmem64G
http://www.nuclearcat.com/files/panic-07012008/dmesg-highmem64G.txt

with highmem4G limited by mem=3G
http://www.nuclearcat.com/files/panic-07012008/dmesg-highmem4G-memlim3G.txt
Kernel config for this specific boot:
http://www.nuclearcat.com/files/panic-07012008/config.txt

dmidecode output
http://www.nuclearcat.com/files/panic-07012008/dmidecode.txt

lspci output
http://www.nuclearcat.com/files/panic-07012008/lspci.txt

--
Denys Fedoryshchenko
Technical Manager
Virtual ISP S.A.L.

--
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 update -mm 16/43] powerpc user_regset compat

[Roland McGrath]

This patch replaces my 2007-12-20 patch by the same title, and has to take
its place in the order of applying that whole series.  

Further testing revealed a bug that resulted in regset-based core dumps of
32-bit processes on 64-bit kernels having r0..r3 cleared to zero.  The fix
(interdiff from original patch) is a trivial pair of lines in two places.


Thanks,
Roland

---

This extends task_user_regset_view CONFIG_PPC64 with support for the 32-bit
view of register state, compatible with what a CONFIG_PPC32 kernel provides.
This will enable generic machine-independent code to access user-mode
threads' registers for debugging and dumping.

Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
 arch/powerpc/kernel/ptrace.c |  162 ++
 1 files changed, 162 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index eb00274..60de9ee 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -501,8 +501,170 @@ static const struct user_regset_view user_ppc_native_view 
= {
.regsets = native_regsets, .n = ARRAY_SIZE(native_regsets)
 };
 
+#ifdef CONFIG_PPC64
+#include 
+
+static int gpr32_get(struct task_struct *target,
+const struct user_regset *regset,
+unsigned int pos, unsigned int count,
+void *kbuf, void __user *ubuf)
+{
+   const unsigned long *regs = >thread.regs->gpr[0];
+   compat_ulong_t *k = kbuf;
+   compat_ulong_t __user *u = ubuf;
+   compat_ulong_t reg;
+
+   if (target->thread.regs == NULL)
+   return -EIO;
+
+   CHECK_FULL_REGS(target->thread.regs);
+
+   pos /= sizeof(reg);
+   count /= sizeof(reg);
+
+   if (kbuf)
+   for (; count > 0 && pos < PT_MSR; --count)
+   *k++ = regs[pos++];
+   else
+   for (; count > 0 && pos < PT_MSR; --count)
+   if (__put_user((compat_ulong_t) regs[pos++], u++))
+   return -EFAULT;
+
+   if (count > 0 && pos == PT_MSR) {
+   reg = get_user_msr(target);
+   if (kbuf)
+   *k++ = reg;
+   else if (__put_user(reg, u++))
+   return -EFAULT;
+   ++pos;
+   --count;
+   }
+
+   if (kbuf)
+   for (; count > 0 && pos < PT_REGS_COUNT; --count)
+   *k++ = regs[pos++];
+   else
+   for (; count > 0 && pos < PT_REGS_COUNT; --count)
+   if (__put_user((compat_ulong_t) regs[pos++], u++))
+   return -EFAULT;
+
+   kbuf = k;
+   ubuf = u;
+   pos *= sizeof(reg);
+   count *= sizeof(reg);
+   return user_regset_copyout_zero(, , , ,
+   PT_REGS_COUNT * sizeof(reg), -1);
+}
+
+static int gpr32_set(struct task_struct *target,
+const struct user_regset *regset,
+unsigned int pos, unsigned int count,
+const void *kbuf, const void __user *ubuf)
+{
+   unsigned long *regs = >thread.regs->gpr[0];
+   const compat_ulong_t *k = kbuf;
+   const compat_ulong_t __user *u = ubuf;
+   compat_ulong_t reg;
+
+   if (target->thread.regs == NULL)
+   return -EIO;
+
+   CHECK_FULL_REGS(target->thread.regs);
+
+   pos /= sizeof(reg);
+   count /= sizeof(reg);
+
+   if (kbuf)
+   for (; count > 0 && pos < PT_MSR; --count)
+   regs[pos++] = *k++;
+   else
+   for (; count > 0 && pos < PT_MSR; --count) {
+   if (__get_user(reg, u++))
+   return -EFAULT;
+   regs[pos++] = reg;
+   }
+
+
+   if (count > 0 && pos == PT_MSR) {
+   if (kbuf)
+   reg = *k++;
+   else if (__get_user(reg, u++))
+   return -EFAULT;
+   set_user_msr(target, reg);
+   ++pos;
+   --count;
+   }
+
+   if (kbuf)
+   for (; count > 0 && pos <= PT_MAX_PUT_REG; --count)
+   regs[pos++] = *k++;
+   else
+   for (; count > 0 && pos <= PT_MAX_PUT_REG; --count) {
+   if (__get_user(reg, u++))
+   return -EFAULT;
+   regs[pos++] = reg;
+   }
+
+   if (count > 0 && pos == PT_TRAP) {
+   if (kbuf)
+   reg = *k++;
+   else if (__get_user(reg, u++))
+   return -EFAULT;
+   set_user_trap(target, reg);
+   ++pos;
+   --count;
+   }
+
+   kbuf = k;
+   ubuf = u;
+   pos *= sizeof(reg);
+   count *= sizeof(reg);
+   return user_regset_copyin_ignore(, , , ,
+

[PATCH] bluetooth : rfcomm tty BUG_ON() code fix

[Dave Young]

1) In tty.c the BUG_ON at line 115 will never be called, because the the before 
list_del_init in this same function.
 115  BUG_ON(!list_empty(>list));
So move the list_del_init to rfcomm_dev_del 

2) The rfcomm_dev_del could be called from diffrent path 
(rfcomm_tty_hangup/rfcomm_dev_state_change/rfcomm_release_dev),
So add another BUG_ON when the rfcomm_dev_del is called more than one time.

Signed-off-by: Dave Young <[EMAIL PROTECTED]> 

---
net/bluetooth/rfcomm/tty.c |   22 +-
1 file changed, 13 insertions(+), 9 deletions(-)

diff -upr linux/net/bluetooth/rfcomm/tty.c linux.new/net/bluetooth/rfcomm/tty.c
--- linux/net/bluetooth/rfcomm/tty.c2008-01-07 13:20:17.0 +0800
+++ linux.new/net/bluetooth/rfcomm/tty.c2008-01-07 13:25:17.0 
+0800
@@ -95,9 +95,10 @@ static void rfcomm_dev_destruct(struct r
 
BT_DBG("dev %p dlc %p", dev, dlc);
 
-   write_lock_bh(_dev_lock);
-   list_del_init(>list);
-   write_unlock_bh(_dev_lock);
+   /* Refcount should only hit zero when called from rfcomm_dev_del()
+  which will have taken us off the list. Everything else are
+  refcounting bugs. */
+   BUG_ON(!list_empty(>list));
 
rfcomm_dlc_lock(dlc);
/* Detach DLC if it's owned by this dev */
@@ -109,11 +110,6 @@ static void rfcomm_dev_destruct(struct r
 
tty_unregister_device(rfcomm_tty_driver, dev->id);
 
-   /* Refcount should only hit zero when called from rfcomm_dev_del()
-  which will have taken us off the list. Everything else are
-  refcounting bugs. */
-   BUG_ON(!list_empty(>list));
-
kfree(dev);
 
/* It's safe to call module_put() here because socket still
@@ -313,7 +309,15 @@ static void rfcomm_dev_del(struct rfcomm
 {
BT_DBG("dev %p", dev);
 
-   set_bit(RFCOMM_TTY_RELEASED, >flags);
+   if (test_bit(RFCOMM_TTY_RELEASED, >flags))
+   BUG_ON(1);
+   else
+   set_bit(RFCOMM_TTY_RELEASED, >flags);
+
+   write_lock_bh(_dev_lock);
+   list_del_init(>list);
+   write_unlock_bh(_dev_lock);
+
rfcomm_dev_put(dev);
 }
 
--
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] msi: set 'En' bit of MSI Mapping Capability

[Peer Chen]

Eric,
Any decision for this patch, if not, currently we prefer to add all our
code to quirks.c.

BRs
Peer Chen

-Original Message-
From: Peer Chen 
Sent: Wednesday, January 02, 2008 5:58 PM
To: 'Eric W. Biederman'
Cc: peerchen; linux-kernel; akpm; Andy Currid
Subject: RE: [PATCH] msi: set 'En' bit of MSI Mapping Capability

I think it's more reasonable to only apply this rule onto AMD platform.

BRs
Peer Chen

-Original Message-
From: Eric W. Biederman [mailto:[EMAIL PROTECTED] 
Sent: Monday, December 24, 2007 7:49 PM
To: Peer Chen
Cc: peerchen; linux-kernel; akpm; Andy Currid
Subject: Re: [PATCH] msi: set 'En' bit of MSI Mapping Capability

"Peer Chen" <[EMAIL PROTECTED]> writes:

> I feel it's dangerous to set the En bit on Intel platform, If the HT
MSI
> En is set, the MSI should be expected to transform to HT INT message
> format. It may cause interrupt lost or hardware internal state machine
> failed depend on the hardware design.

Reasonable.  As long as what the quirk is to avoid errata and
chipset specific issues I don't have a problem with it.

I figure the quirk should be a separate patch though.

My concern is that the general rule that always enabling HT MSI
mapping capabilities is reasonable.  Even if there are some
specific exceptions where we don't want to do that.

I want code that requires the smallest list of chipset
exceptions that we can make. 

Eric
---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
--
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: [vm] writing to UDF DVD+RW (/dev/sr0) while under memory pressure: box ==> doorstop

[Mike Galbraith]

On Sun, 2008-01-06 at 12:29 -0800, Andrew Morton wrote: 
> On Sun, 06 Jan 2008 19:01:10 +0100 Mike Galbraith <[EMAIL PROTECTED]> wrote:
> 
> > 
> > On Sun, 2008-01-06 at 10:42 +0100, Mike Galbraith wrote:
> > > FWIW, here's box having same seizure writing to /dev/pktcdvd/sr0.
> > 
> > Ugh, horrid device IO ==> horrid VM AFIKT.  I'll continue rummaging, but
> > I wonder, am I doing something _so_ stupid as to warrant zero response?
> > 
> 
> Copying linux-mm might have helped.  Bad time of year, too.

Thanks for the reply, I was getting alll paranoid that I was being
really dense, ergo the ping.

> >From the traces it looks like all IO has stopped and everyone is waiting
> (directly or indirectly) for certain IO completions.  Is that really true,
> or is IO still dribbling along?

It's dribbling along.  I drastically improved the situation by bouncing
people off the exclusion wall instead of synchronizing, but the poor sod
who acquires prune_mutex is in purgatory for a very long time.

(undoes butchery)

> >From the kswapd0 trace it would appear that UDF is doing synchronous writes
> (udf_update_inode->sync_dirty_buffer) which perhaps is making things
> mightily slow.

Even synchronous writes shouldn't cause minutes long hangs surely :)
This /dev/sr0 IO seems to be getting jammed up something terrible.  I
formatted the dvd ext2 and tried the same copy.  It didn't jam up the
whole box (well, yet, it's still zooming along at mach 0.01)
doing parallel kbuilds, but when I started a bonnie, the poor thing
instantly got nailed to the floor.  I kill -9'd it about a half an hour
ago, and it has yet to respond.  Every now and again there's a burst of
activity from cp, but bonnie is stuck for the duration it seems.  I'll
find out.



The 515MB cp finished after an hour and change.  When bonnie exits I'll
be able to see what the throughput was.



bonnie finally exited.  uptime is now 1:22. cp started right after
boot... throughput very bad.

I would almost swear I copied to that dvd drive when it was /dev/hdc
(before I upgraded to openSuSE 10.3 and got all modern) and it worked
well enough to not attract my attention.  I guess I need to figure out
how to reacquire /dev/hdc and try again.

[ 1687.358723] SysRq : Show Blocked State
[ 1687.358729]   taskPC stack   pid father
[ 1687.358729] pdflush   D 0140 0   156  2
[ 1687.358729]ee172de4 0046 e0791550 0140 0008  
 00b0 
[ 1687.358729]b0d3bb78 0188 b040d300 b040d300 ef8ab5f0 ef8ab83c 
b180c300 ee172000 
[ 1687.358729] ee2c5550 ef9cb200 ee2c5550 0003  
ef871ee4 0041706e 
[ 1687.358729] Call Trace:
[ 1687.358729]  [] io_schedule+0x4f/0x89
[ 1687.358729]  [] sync_buffer+0x30/0x34
[ 1687.358729]  [] __wait_on_bit+0x42/0x5e
[ 1687.358729]  [] sync_buffer+0x0/0x34
[ 1687.358729]  [] out_of_line_wait_on_bit+0x67/0x6f
[ 1687.358729]  [] sync_buffer+0x0/0x34
[ 1687.358729]  [] wake_bit_function+0x0/0x3c
[ 1687.358729]  [] __wait_on_buffer+0x24/0x29
[ 1687.358729]  [] __bread+0x55/0x8a
[ 1687.358729]  [] ext2_get_inode+0xbe/0x109 [ext2]
[ 1687.358729]  [] ext2_update_inode+0x39/0x331 [ext2]
[ 1687.358729]  [] mpage_bio_submit+0x19/0x1d
[ 1687.358729]  [] ext2_get_block+0x0/0x761 [ext2]
[ 1687.358729]  [] __writeback_single_inode+0x228/0x306
[ 1687.358729]  [] apic_timer_interrupt+0x28/0x30
[ 1687.358729]  [] _atomic_dec_and_lock+0x31/0x5c
[ 1687.358729]  [] sync_sb_inodes+0x1c3/0x294
[ 1687.358729]  [] writeback_inodes+0x7d/0xac
[ 1687.358729]  [] background_writeout+0x98/0xb7
[ 1687.358729]  [] pdflush+0x0/0x1d4
[ 1687.358730]  [] pdflush+0x107/0x1d4
[ 1687.358730]  [] background_writeout+0x0/0xb7
[ 1687.358730]  [] kthread+0x34/0x56
[ 1687.358730]  [] kthread+0x0/0x56
[ 1687.358730]  [] kernel_thread_helper+0x7/0x1c
[ 1687.358730]  ===
[ 1687.358730] hald-addon-st D ee990bc0 0  2330   2284
[ 1687.358730]ee990bd4 0082 0002 ee990bc0 ee990bb8  
 8334c2ad 
[ 1687.358730]0273 b180c300 b040d300 b040d300 ee21c8b0 ee21cafc 
b180c300 ee99 
[ 1687.358730]ee990be8  ee398740 00248b9d ee2c5550 ee2c5550 
 0003 
[ 1687.358730] Call Trace:
[ 1687.358730]  [] schedule_timeout+0x69/0xa1
[ 1687.358730]  [] scsi_request_fn+0x210/0x351 [scsi_mod]
[ 1687.358730]  [] del_timer+0x52/0x5a
[ 1687.358730]  [] cfq_set_request+0xc2/0x2ff
[ 1687.358730]  [] wait_for_common+0x6a/0x101
[ 1687.358730]  [] default_wake_function+0x0/0xc
[ 1687.358730]  [] blk_execute_rq+0x72/0xb3
[ 1687.358730]  [] blk_end_sync_rq+0x0/0x23
[ 1687.358730]  [] default_wake_function+0x0/0xc
[ 1687.358730]  [] get_request_wait+0x1b/0x173
[ 1687.358730]  [] scsi_execute+0xc7/0xdb [scsi_mod]
[ 1687.358730]  [] scsi_execute_req+0x6d/0xd0 [scsi_mod]
[ 1687.358730]  [] scsi_test_unit_ready+0x56/0x95 [scsi_mod]
[ 1687.358730]  [] sr_media_change+0x3a/0x223 [sr_mod]
[ 1687.358730]  [] sr_drive_status+0x53/0x65 [sr_mod]
[ 

Re: [PATCH 0/7] sg_ring: a ring of scatterlist arrays

[Rusty Russell]

On Monday 07 January 2008 16:01:40 Tejun Heo wrote:
> > But we hit the same problems:
> >
> > 1) sg_chain loses information.  The clever chain packaging makes reading
> > easy, but manipulation is severely limited.  You can append to your own
> > chains by padding, but not someone elses.  This works for SCSI, but what
> > about the rest of us?  And don't even think of joining mapped chains: it
> > will almost work.
>
> You can append by allocating one more element on the chain to be
> appended and moving the last element of the first chain to it while
> using the last element for chaining.

Hi Tejun,

   Nice try!  Even ignoring the ugliness of undoing such an operation if the 
caller doesn't expect you to mangle their chains, consider a one-element sg 
array. :(

Cheers,
Rusty.
--
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] Don't blatt first element of prv in sg_chain()

[Tejun Heo]

Rusty Russell wrote:
> I realize that sg chaining is a ploy to make the rest of the kernel
> devs feel the pain of the SCSI subsystem.  But this was a little
> unsubtle.
> 
> Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>

Embarrassingly Acked-by: Tejun Heo <[EMAIL PROTECTED]>

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] sg_ring: a ring of scatterlist arrays

[Tejun Heo]

Hello,

Rusty Russell wrote:
>> The other thing I note is that the problem you're claiming to solve with
>> sg_ring (the ability to add extra scatterlists to the front or the back
>> of an existing one) is already solved with sg_chain, so the only real
>> advantage of sg_ring was that it contains explicit counts, which
>> sg_table (in -mm) also introduces.
> 
> I just converted virtio using latest Linus for fair comparison, and it's 
> still 
> pretty ugly.  sg_ring needs more work to de-scsi it.  sg_table is almost 
> sg_ring except it retains all the chaining warts.

I agree it's ugly.

> But we hit the same problems:
> 
> 1) sg_chain loses information.  The clever chain packaging makes reading 
> easy, 
> but manipulation is severely limited.  You can append to your own chains by 
> padding, but not someone elses.  This works for SCSI, but what about the rest 
> of us?  And don't even think of joining mapped chains: it will almost work.

You can append by allocating one more element on the chain to be
appended and moving the last element of the first chain to it while
using the last element for chaining.  Join can be done by similar
technique using three element extra chain in the middle.  But, yeah,
it's ugly as hell.

-- 
tejun
--
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 02/11] Add fastcall to do_IRQ for i386

[H. Peter Anvin]

Steven Rostedt wrote:


On Thu, 3 Jan 2008, Mathieu Desnoyers wrote:

I would propose to try to see how we can #ifdef two different __mcount
assembly functions that would prepare the stack appropriately for each
REGPARM cases.


I have to confess that I've been testing this mostly on x86_64, which
doesn't have the troubles with REGPARM as i386 does. I'll need to
investigate this a bit deeper on i386 alone.



I thought we had dropped support for the non-REGPARM case, so why don't 
we just make it work for REGPARM and be done with it?


-hpa

--
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] Add bug/warn marker to generic report_bug()

[Arjan van de Ven]

On Sun, 6 Jan 2008 19:22:37 -0600
Olof Johansson <[EMAIL PROTECTED]> wrote:


> This comment in oops_enter threw me off of using it:
> 
> debug_locks_off(); /* can't trust the integrity of the kernel
>   anymore */
> 
> Since we can very well depend on the integrity of the kernel when it's
> just doing a __WARN().

ok fair enough; objection withdrawn

-- 
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: [RFC PATCH 10/11] mcount tracer show task comm and pid

[Mathieu Desnoyers]

* Ingo Molnar ([EMAIL PROTECTED]) wrote:
> 
> * Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> 
> > > @@ -34,6 +34,7 @@ mctracer_add_trace_entry(struct mctracer
> > >  {
> > >   unsigned long idx, idx_next;
> > >   struct mctracer_entry *entry;
> > > + struct task_struct *tsk = current;
> > 
> > Aren't there situations, like in the middle of a context switch, where 
> > current is not valid ? Is also poses a problem for early boot, and NMI 
> > tracing.
> 
> no such problems on x86.
> 
>   Ingo

I based my comments on the following code snippet, but I think I start
to understand what makes it "so special"

arch/x86/mm/fault_32.c :

static inline int vmalloc_fault(unsigned long address)
{
unsigned long pgd_paddr;
pmd_t *pmd_k;
pte_t *pte_k;
/*
 * Synchronize this task's top level page-table
 * with the 'reference' page table.
 *
>* Do _not_ use "current" here. We might be inside
 * an interrupt in the middle of a task switch..
 */
pgd_paddr = read_cr3();
pmd_k = vmalloc_sync_one(__va(pgd_paddr), address);
if (!pmd_k)
return -1;
pte_k = pte_offset_kernel(pmd_k, address);
if (!pte_present(*pte_k))
return -1;
return 0;
}

At context switch on x86, loading the registers is done first, and only
after the is the current pointer set. However, for vmalloc faults, it's
the value in the cr3 register that is important, which may not
correspond to the cr3 value saved in "current".

So, I think using the "pid" and "comm" fields of current, even in NMI
context, is not a problem, just as you said. For early boot, the current
task will be init_task, which has pid = 0 and comm = "swapper", still
ok.

Thanks for pointing it out.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
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] Don't blatt first element of prv in sg_chain()

[Rusty Russell]

I realize that sg chaining is a ploy to make the rest of the kernel
devs feel the pain of the SCSI subsystem.  But this was a little
unsubtle.

Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>

diff -r b3aec596b841 include/linux/scatterlist.h
--- a/include/linux/scatterlist.h   Mon Jan 07 12:43:56 2008 +1100
+++ b/include/linux/scatterlist.h   Mon Jan 07 15:01:51 2008 +1100
@@ -188,8 +188,8 @@ static inline void sg_chain(struct scatt
/*
 * offset and length are unused for chain entry.  Clear them.
 */
-   prv->offset = 0;
-   prv->length = 0;
+   prv[prv_nents - 1].offset = 0;
+   prv[prv_nents - 1].length = 0;
 
/*
 * Set lowest bit to indicate a link pointer, and make sure to clear
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] sg_ring: a ring of scatterlist arrays

[Rusty Russell]

On Sunday 06 January 2008 02:31:12 James Bottomley wrote:
> On Wed, 2007-12-19 at 17:31 +1100, Rusty Russell wrote:
> > This patch series is the start of my attempt to simplify and make
> > explicit the chained scatterlist logic.
> >
> > It's not complete: my SATA box boots and seems happy, but all the other
> > users of SCSI need to be updated and checked.  But I've gotten far enough
> > to believe it's worth persuing.
>
> Sorry for the delay in looking at this, I was busy with Holidays and
> things.

Thankyou for your consideration.

> When I compare sg_ring with the current sg_chain (and later sg_table)
> implementations, I'm actually struck by how similar they are.

I agree, they're solving the same problem.  It is possible that the pain of 
change is no longer worthwhile, but I hate to see us give up on this.  We're 
adding complexity without making it harder to misuse.

> The other thing I note is that the problem you're claiming to solve with
> sg_ring (the ability to add extra scatterlists to the front or the back
> of an existing one) is already solved with sg_chain, so the only real
> advantage of sg_ring was that it contains explicit counts, which
> sg_table (in -mm) also introduces.

I just converted virtio using latest Linus for fair comparison, and it's still 
pretty ugly.  sg_ring needs more work to de-scsi it.  sg_table is almost 
sg_ring except it retains all the chaining warts.

But we hit the same problems:

1) sg_chain loses information.  The clever chain packaging makes reading easy, 
but manipulation is severely limited.  You can append to your own chains by 
padding, but not someone elses.  This works for SCSI, but what about the rest 
of us?  And don't even think of joining mapped chains: it will almost work.

2) sg_chain's end marker is only for reading non-dma elements, not for mapped 
chains, nor for writing into chains.  Plus it's a duplicate of the num arg, 
which is still passed around for efficiency.  (virtio had to implement 
count_sg() because I didn't want those two redundant num args).

3) By overloading struct scatterlist, it's invisible what code has been 
converted to chains, and which hasn't.  Too clever by half!

Look at sg_chain(): it claims to join two scatterlists, but it doesn't.  It 
assumes that prv is an array, not a chain.  Because you've overloaded an 
existing type, this happens everywhere.  Try passing skb_to_sgvec a chained 
skb.

sg_ring would not have required any change to existing drivers, just those 
that want to use long sg lists.  And then it's damn obvious which are which.

4) sg_chain missed a chance to combine all the relevent information (max, num, 
num_dma and the sg array). sg_table comes close, but you still can't join 
them (no max information, and even if there were, what if it's full?).  
Unlike sg_ring, it's unlikely to reduce bugs.

5) (A little moot now) sg_ring didn't require arch changes.

> The other differences are that sg_ring only allows adding at the front
> or back of an existing sg_ring, it doesn't allow splicing at any point
> like sg_chain does, so I'd say it's less functional (not that I actually
> want anyone ever to do this, of course ...)

Well it's just as possible, but you might have to copy more elements (with sg 
chaining you need only copy 1 sg element to make room for the chain elem).  
Agreed that it's a little out there...

> The final point is that sg_ring requires a two level traversal:  ring
> list then scatterlist, whereas sg_chain only requires a single level
> traversal.  I grant that we can abstract out the traversal into
> something that would make users think they're only doing a single level,
> but I don't see what the extra level really buys us.

We hide the real complexity from users and it makes it less safe for 
non-trivial cases.

Hence the introduction of YA datastructure: sg_table.  This is getting close: 
just hang the array off it and you'll have sg_ring and no requirement for 
dynamic alloc all the time.  And once you have a header, no need for chaining 
tricks...

> The only thing missing from sg_chain perhaps is an accessor function
> that does the splicing, which I can easily construct if you want to try
> it out in virtio.

I don't need that (I prepend and append), but it'd be nice if sg_next took a 
const struct scatterlist *.

Cheers,
Rusty.
--
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: Believed resolved: SATA kern-buffRd read slow: based on promise driver bug

[Robert Hancock]

Linda Walsh wrote:

Mikael Pettersson wrote:

Linda Walsh writes:
 > Mikael Pettersson wrote:
 > > Linda Walsh writes:
 > >  > > Linda Walsh wrote:
 > >  >  read rate began falling; (.25 - .3);  > >  > more 
importantly; a chronic error message associated

 > >  > with drive may be causing some or all of the problem(s):
 > >  > ---
 > >  > ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
 > >  > ata1.00: port_status 0x2008
 > >  > ata1.00: cmd c8/00:10:30:06:03/00:00:00:00:00/e0 tag 0 cdb 0x0 
data 8192 in
 > >  >  res 50/00:00:3f:06:03/00:00:00:00:00/e0 Emask 0x2 
(HSM violation)

 > >  > ata1: limiting SATA link speed to 1.5 Gbps
 > >
 > > Looks like the Promise ASIC SG bug. Apply
 > > 
 


 > > and let us know if things improve.
 > > /Mikael
 > ---
 > Yep!  Hope that's making it into a patch soon or, at least 2.6.24.
 > Kernel buffered
Good to hear that it solved this problem.
The patch is in 2.6.24-rc2 and newer kernels, and will be sent
to -stable for the 2.6.23 and 2.6.22 series.
  

---
   Will 'likely' wait till -stable since I use the machine as a 'server'
for just about any/everything that needs "serving" or "proxy" services.
 >  That and I'd like to find out why TCQ/NCQ doesn't work with the 
Seagate drives --


The driver doesn't yet support NCQ.


   Is 'main' diff between NCQ/TCQ that TCQ can re-arrange 'write'
priority under driver control, whereas NCQ is mostly a FIFO queue?


First off one has to distinguish between ATA TCQ and SCSI TCQ. ATA TCQ 
is essentially abandoned, very few drives and fewer still controllers 
and matching drivers ever supported it.


SCSI TCQ has "head of queue", "ordered" and "simple" queueing modes. ATA 
NCQ effectively only has "simple" where the drive always decides what 
order to service the requests in. There is a FUA mode, which tells the 
drive that the command (normally a write) has to access the physical 
media before reporting completion.




   On a Journal'ed file system, isn't "write-order" control required
for integrity?  That would seem to imply TCQ could be used, but
NCQ doesn't seem to offer much benefit, since the higher level
kernel drivers usually have a "larger picture" of sectors that need
to be written.  The only advantage I can see for NCQ drives might


There are cases where writes need to complete in a specific order. This 
can be done either by using FUA bits (though libata doesn't do this by 
default currently) or by issuing cache flushes before and after certain 
commands.



be that the kernel may not know the drive's internal physical
structure nor where the disk is in its current revolution.  That could
allow drive write re-ordering where based on the exact-current state
of the drive that the kernel might not have access to, but it seems
this would be a minor benefit -- and, depending on firmware,
possibly higher overhead in command processing?


That's a big part of it. The kernel doesn't necessarily know what 
sectors will be the fastest to access at any given time whereas the 
drive can.


Also, NCQ has some other improvements that are independent of actually 
queueing commands - for instance, because the drive controls the DMA 
data transfer, it can transfer the data for one request in an 
out-of-order fashion instead of having to transfer to the host strictly 
from beginning to end as in traditional ATA.




Am trying to differentiate NCQ/TCQ and SAS v. SCSI benefits.
It seems both support (SAS & SATA) some type of port-multiplier/
multiplexor/ option to allow more disks/port.

However, (please correct?) SATA uses a hub type architecture while
SAS uses a switch architecture.  My experience with network hubs vs.
switches is that network hubs can be much slower if there is
communication contention.  Is the word 'hub' being used in the
"shared-communication media sense", or is someone using the term
'hub' as a [sic] replacement for a 'switch'?


I believe that they're essentially the same in that regard, though 
someone can correct me if I'm wrong..


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.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/

Replacing drivers/mmc directory in kerenl 2.6.22.1 with drivers/mmc in kernel 2.6.23.1

[raki john]

Hi All,

Please CC me on your responses

I am working on Kernel 2.6.22.1 mmc host  drivers. I recently found that
mmc driver in kernel 2.6.23.1 supports bounce buffers. I wanted to use
bounce buffer feature.

I do not  want to go to Kernel 2.6.23.1. I want to be at 2.6.22.1, but
I need mmc driver in 2.6.23.1.

Can I replace drivers/mmc directory in 2.6.22.1 with drivers/mmc
directory in 2.6.23.1.   Does this cause any issues. Is there any code
in drivers/mmc in 2.6.23.1 which depends on other features in kernel
2.6.23.1.

Thanks in advance for your help

--
Thanks
raki
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm][PATCH] base: Change power/wakeup output from "" to "unsupported" if wakeup feature isn't supported by a device

[David Brownell]

On Sunday 06 January 2008, Yi Yang wrote:
> 
> > How about not changing a userland-visible interface gratuitously?
>
> "empty" can't tell a user the state of wakeup of a device, so it is
> necessary to change it.

Words don't say anything at all in isolation.  For example,
here the current tristate behavior has been documented for
several years now ... and that's the only thing that could
have conveyed any meaning whatever.

I can't agree that it's even slightly "necessary" to make
such a grutuitous and backwards-incompatible change.


--
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: "mconf" and help texts

[Roman Zippel]

Hi,

On Thursday 3. January 2008, Ph. Marek wrote:

> So I took a look at "Help", and saw that blob:
>
>   Selected by: NETFILTER_XT_TARGET_CONNMARK && NET && INET && NETFILTER &&
>  NETFILTER_XTABLES && (IP_NF_MANGLE || IP6_NF_MANGLE) && NF_CONNTRACK
> || NETFILTER_XT_MATCH_CONNMARK && NET && INET && NETFILTER &&
>  NETFILTER_XTABLES && NF_CONNTRACK || IP_NF_TARGET_CLUSTERIP && NET &&
>  INET && NETFILTER && IP_NF_MANGLE && EXPERIMENTAL && NF_CONNTRACK_IPV4
>
> That is a _bit_ unreadable.

What you see here is the internal representation of the select expression. To 
make it more easily readable, you could just cut off everything between && 
and || (it's the dependency of the symbol which does the select, the one 
before &&).
The readable expression could be generated when needed, but it might be easier 
to just generate at the same time as the full expression (in menu_finalize).

> As a side-node - I cannot get xconfig to work (pkg-config);

Why exactly? What's the error message?

> is there some 
> way in menuconfig to see why some config option is disallowed? The location
> tree shows some data ("-> Networking support (NET [=y])"), but not for all
> dependencies.

I don't quite understand. The dependency for option itself is above the 
location tree and the for dependencies of the dependencies you have to look 
at their individual info.

> [Does xconfig allow enabling them while seeing this option?] 

Only if you enable the missing dependency. This is insofar a little easier as 
they are linked if you enable the deubg info, so the prompt may be a little 
easier to find.

bye, Roman
--
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] UPDATED2: hfs: handle more on-disk corruptions without oopsing

[Roman Zippel]

Hi,

On Wednesday 2. January 2008, Eric Sandeen wrote:

> Roman, with this on top does it look better to you?

Looks good, thanks.

> I'll get hfsplus done in a bit.

I'm mainly concerned about brec.c/bfind.c, the patch should be pretty much 
identical.

bye, Roman
--
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/

2.6.24-rc7 -- WARNING: at kernel/lockdep.c:2662 check_flags()

[Miles Lane]

Is this an issue in the Totem code or in the kernel?
Please, let me know if you need my .config file.

[ 5446.835007] WARNING: at kernel/lockdep.c:2662 check_flags()
[ 5446.835022] Pid: 6060, comm: totem-plugin-vi Not tainted 2.6.24-rc7 #1
[ 5446.835027]  [] show_trace_log_lvl+0x1a/0x2f
[ 5446.835041]  [] show_trace+0x12/0x14
[ 5446.835047]  [] dump_stack+0x6c/0x72
[ 5446.835052]  [] check_flags+0xc5/0x194
[ 5446.835061]  [] lock_acquire+0x49/0xac
[ 5446.835066]  [] _spin_lock+0x35/0x42
[ 5446.835074]  [] do_futex+0x339/0x967
[ 5446.835080]  [] sys_futex+0xc0/0xd3
[ 5446.835085]  [] syscall_call+0x7/0xb
[ 5446.835091]  ===
[ 5446.835093] possible reason: unannotated irqs-on.
[ 5446.835097] irq event stamp: 173320
[ 5446.835100] hardirqs last  enabled at (173319): []
sysenter_past_esp+0xb2/0xc1
[ 5446.835106] hardirqs last disabled at (173320): []
ret_from_exception+0x15/0x18
[ 5446.835113] softirqs last  enabled at (173298): []
__do_softirq+0xf7/0xff
[ 5446.835123] softirqs last disabled at (173289): []
do_softirq+0x77/0xf8
--
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/

Size of kernel halts startup

[cksim]

Hi,

Yesterday, I have encountered an issue when the kernel size is more than 1.3MB.

Info on problem encountered as follows:
1) I am using Atmel AT91SAM9261 part. Circuit similar to that of AT91SAM9261EK
evaluation board.

2) I am booting the kernel through NFS. Bootloader
used is UBoot 1.1.5. Kernel used is 2.6.23.1

3) For the past weeks, the kernel size was about 1.3MB and kernel bootup over 
NFS was fine.

4) Yesterday, I have done a menuconfig and turned on some drivers (USB HID and 
I2C).  This resulted in a kernel size of about 1.4MB.

5) Booting up this 1.4MB kernel over NFS causes a register dump to appear and 
the system is halted.

Is this issue related to the size of the kernel or it is due to some conflict 
in memory ?

If it is related to size of kernel, how can the size be increased so as to 
resolve this issue ?

Appreciate any help and advises.

Thanks in advance.

Sim CK
--
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/

Odd behaviour observed on fb0 (TFT LCD screen 800x480)

[cksim]

Hi,

Lately, I have observed an odd behviour in kernel 2.6.23.1 on a 800x480 TFT LCD 
unit.

The odd behviour as follows:
1) I am using Atmel AT91SAM9261 part. Circuit similar to that of AT91SAM9261EK 
evaluation board.

2) I am booting the kernel and mounting root filesystem through NFS. Bootloader 
used is UBoot 1.1.5.

3) During kernel startup, the LCD screen shows the "Penguin" logo with the 
other console output messages.

4) Everything looks fine up to this point. For example, the 0,0 position of 
image on LCD is proper and correct.

5) The root filesystem is then mounted through NFS and followed by a message 
"Freeing init memory: 106K". All this are fine.

6) During the execution of init scripts and the login prompt, the image on the 
screen starts shifting (either left, right, up or down). For example, the 0,0 
position of the LCD image is shifted. However, the image content is still 
correct.

7) After login, this image shift behaviour still exists during normal usage.

In contrast, when using kernel 2.6.21, the image shift behaviour was not 
observed before the login prompt. Image shift after the login does happen 
occasionally but not as frequent as that seen in 2.6.23.1.

Has anyone encountered a similar image shift issue ?

Is this issue related to kernel ? It appears to me that some timing causes the 
image shifting.

Appreciate any help and advises.

Thanks in advance.

Sim CK

--
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/

umount -l , getcwd and /proc//cwd inconsistent

[Ian Kent]

Hi all,

Could someone please help me understand what's happening with, what
looks like inconsistent behavior, between getpwd and procfs readlink.

Basically, from a bash shell, setting working directory to a mounted
directory all is fine with "pwd" and "/proc//cwd". Following a
"umount - l" on the mount "pwd" continues to return the expected string
but "/proc//cwd" returns an empty string.

What I'm really after is why this happens because sys_getcwd and
proc_pid_readlink appear to do essentially the same thing to get the
string.

For example:

[EMAIL PROTECTED] ~]$ mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/mapper/VolGroup00-LogVol03 on /work type ext3 (rw)
/dev/mapper/VolGroup00-LogVol02 on /home type ext3 (rw)
/dev/mapper/VolGroup02-LogVol00 on /vmware type ext3 (rw)
/dev/sda2 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
shark:/export/auto on /mnt/auto type nfs (rw,addr=10.49.97.44)
[EMAIL PROTECTED] ~]$ cd /mnt/auto
[EMAIL PROTECTED] auto]$ pwd
/mnt/auto
[EMAIL PROTECTED] auto]$ ps
  PID TTY  TIME CMD
 5435 pts/200:00:00 bash
 5543 pts/200:00:00 ps
[EMAIL PROTECTED] auto]$ ls -ld /proc/5435/cwd
lrwxrwxrwx 1 raven raven 0 2008-01-07 11:57 /proc/5435/cwd -> /mnt/auto

"umount -l /mnt/auto", done elsewhere at this point.

[EMAIL PROTECTED] auto]$ mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/mapper/VolGroup00-LogVol03 on /work type ext3 (rw)
/dev/mapper/VolGroup00-LogVol02 on /home type ext3 (rw)
/dev/mapper/VolGroup02-LogVol00 on /vmware type ext3 (rw)
/dev/sda2 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
[EMAIL PROTECTED] auto]$ pwd
/mnt/auto
[EMAIL PROTECTED] auto]$ ls -ld /proc/5435/cwd
lrwxrwxrwx 1 raven raven 0 2008-01-07 11:57 /proc/5435/cwd ->
[EMAIL PROTECTED] auto]$


Ian


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] util-linux-ng 2.13.1-rc2

[LaMont Jones]

On Sat, Jan 05, 2008 at 01:31:21AM -0800, Andrew Morton wrote:
> On Wed, 2 Jan 2008 22:10:52 +0100 Karel Zak <[EMAIL PROTECTED]> wrote:
> >  The second util-linux-ng 2.13.1 release candidate is available at
> > ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/
> Interesting.  Thanks.  Which distros are using this, or plan to do so?

Debian's 2.13-13 version is actually 2.13.1-rc2 (looking at
git://git.debian.org/~lamont/util-linux.git) minus the pofile
changes (plus some debian-local stuff), and has been in unstable
since 5 December 2007.  2.13~rc2-3 was the first non-experimental
upload (28 July 2007)

lamont
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] apm_power: Support using VOLTAGE_* properties for apm calculations

[Anton Vorontsov]

On Sun, Jan 06, 2008 at 03:30:16PM +0300, Dmitry Baryshkov wrote:
> Support using VOLTAGE_* properties for apm calculations. It's pretty
> dummy, but useful for batteries for which we can only get voltages.

By the way...

> diff --git a/drivers/power/apm_power.c b/drivers/power/apm_power.c
> index bbf3ee1..526c96e 100644
> --- a/drivers/power/apm_power.c
> +++ b/drivers/power/apm_power.c
[...]
> -static int calculate_time(int status, int using_charge)
> +static int calculate_time(int status, apm_source source)
[...]
> + case SOURCE_VOLTAGE:
> + full_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX;
> + full_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN;
> + empty_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN;
> + empty_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN;
> + cur_avg_prop = POWER_SUPPLY_PROP_VOLTAGE_AVG;
> + cur_now_prop = POWER_SUPPLY_PROP_VOLTAGE_NOW;
> + break;
[...]
>   return -((cur.intval - empty.intval) * 60L) / I.intval;

This formula will return nonsense if you'll feed it with voltage:
Ohms * 60 minutes? ;-)

I'd suppose you can get better accuracy if you'll divide it by
some constant (resistance, we can define new property for it),
but I still doubt it, because this formula doesn't work good
enough even for batteries reporting charge. ;-)

It's interesting what actual values you're getting and how they
accurate.

There is another option though: if you know battery charge
full/empty thresholds (usually you know design values, they
should be written on the battery pack), then you can use this
formula to calculate "charge_now":

((voltage_now - voltage_min) * (charge_full - charge_empty)) /
(voltage_max - voltage_min)

And then you can calculate time as usual, using
charge_{now,full,empty} and current_now. But still, this is
very inaccurate, there isn't direct correlation between
charge and voltage. Oh well, power_supply_class.txt already
states about apm_power.c limitations.


So, with few cosmetic corrections I applied all your patches to
git://git.infradead.org/battery-2.6.git

I also applied few my patches I sent here earlier, hope they
don't break anything (at least they survived my tests).

Good luck,

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
--
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: [Bluez-devel] Oops involving RFCOMM and sysfs

[Tejun Heo]

Hello,

Tejun Heo wrote:
> Al Viro wrote:
>> On Sat, Jan 05, 2008 at 11:30:25PM +0900, Tejun Heo wrote:
 Assuming that this is what we get, everything looks explainable - we
 have sysfs_rename_dir() calling sysfs_get_dentry() while the parent
 gets evicted.  We don't have any exclusion, so while we are playing
 silly buggers with lookups in sysfs_get_dentry() we have parent become
 negative; the rest is obvious...
>>> That part of code is walking down the sysfs tree from the s_root of
>>> sysfs hierarchy and on each step parent is held using dget() while being
>>> referenced, so I don't think they can turn negative there.
>> Turn?  Just what stops you from getting a negative (and unhashed) from
>> lookup_one_noperm() and on the next iteration being buggered on mutex_lock()?
> 
> Right, I haven't thought about that.  When sysfs_get_dentry() is called,
> @sd is always valid so unless there was existing negative dentry, lookup
> is guaranteed to return positive dentry, but by populating dcache with
> negative dentry before a node is created, things can go wrong.  I don't
> think that's what's going on here tho.  If that was the case, the
> while() loop looking up the next sd to lookup (@cur) should have blown
> up as negative dentry will have NULL d_fsdata which doesn't match any sd.
> 
> I guess what's needed here is d_revalidate() as other distributed
> filesystems do.  I'll test whether this can be actually triggered and
> prepare a fix.  Thanks a lot for pointing out the problem.

This can't happen because lookup of non-existent entry doesn't create a
negative dentry.  The new dentry is never hashed and killed after lookup
failure, the above scenario can't happen.

That said, the mechanism is a bit too fragile.  sysfs currently ensures
that dentry/inode point to the associated sysfs_dirent.  This is mainly
remanent of conversion from previous VFS based implementation.  I think
the right thing to do here is to make sysfs behave like other proper
distributed filesystems using d_revalidate.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm][PATCH] base: Change power/wakeup output from "" to "unsupported" if wakeup feature isn't supported by a device

[Yi Yang]

On Mon, 2008-01-07 at 02:57 +0100, Rafael J. Wysocki wrote:
> On Monday, 7 of January 2008, Yi Yang wrote:
> > On Fri, 2008-01-04 at 08:09 -0800, David Brownell wrote:
> > > > > This patch changes empty output to "unsupported" in order that a user 
> > > > > knows
> > > > > wakeup feature isn't supported by this device when he/she
> > > > > 'cat /sys/devices/.../power/wakeup', please consider to apply,
> > > > > thanks.
> > > >
> > > > What about simply removing "wakuep" file if wakeup is not supported?
> > > 
> > > It may not *stay* unsupported, so I think changing it in either
> > > of those permanent ways would be confusing/misleading.
> > > 
> > > For example, USB devices have multiple states ... minimally, an
> > > unconfigured state, and a configured state.  Some have multiple
> > > configurations.  Only configured states can be wakeup-capable.
> > > So a given device might have three states, but support wakeup
> > > except in one of them...
> > If so, we can change "unsupported" to "unconfigurable" or "inoperable"
> > which can cover the states "unconfigured", "unsupported" and other
> > unknown states. :-).
> 
> The main problem with your patch is that is changes a documented behavior
> visible by the user space.  That should be done very cautiously.
Which applications are using this interface? if they assume "\n" means
the unconfigurable or unavailable state, this is very fragile.
> 
> 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: [linux-pm][PATCH] base: Change power/wakeup output from "" to "unsupported" if wakeup feature isn't supported by a device

[Yi Yang]

On Fri, 2008-01-04 at 18:20 +0100, Oliver Neukum wrote:
> Am Freitag, 4. Januar 2008 17:52:14 schrieb Olivier Galibert:
> > On Fri, Jan 04, 2008 at 11:38:29AM -0500, Alan Stern wrote:
> > > How about changing it to say "unavailable"?  That doesn't imply 
> > > permanence.
> > 
> > How about not changing a userland-visible interface gratuitously?
> 
Why not do if we can make it better?
> Very good idea.
> 
>   Regards
>   Oliver

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/7] convert semaphore to mutex in struct class

[Dave Young]

On Sun, Jan 06, 2008 at 07:41:29PM +0100, Stefan Richter wrote:
> Dave Young wrote:
> > Convert semaphore to mutex in struct class.
> > All the patches in this series should be applyed simultaneously
> 
> Therefore you eventually need to repost it as a single patch.  It can't
> go into one of the maintainer trees otherwise, because they only take
> fully bijectable patches.  (Kernel must build and run at any point in
> between any patch series.)
> 
> > toc:
> > ---
> > 1-driver-core-struct-class-convert-semaphore-to-mutex.patch
> > 2-i2c-struct-class-convert-semaphore-to-mutex.patch
> > 3-ieee1394-struct-class-convert-semaphore-to-mutex.patch
> > 4-power-struct-class-convert-semaphore-to-mutex.patch
> > 5-rtc-struct-class-convert-semaphore-to-mutex.patch
> > 6-scsi-struct-class-convert-semaphore-to-mutex.patch
> > 7-spi-struct-class-convert-semaphore-to-mutex.patch
> 
> I was going to test it at runtime on top of 2.6.24-rc6, but the first
> and second patch depend on stuff in -mm.  So, my laziness wins for now,
> as -mm is not my cup of tea.
> 
> About your changelog:
> 
>   "xyz: convert semaphore to mutex in struct class
> 
>   Use mutex instead of semaphore in struct class.
> 
>   Signed-off-by: Dave Young <[EMAIL PROTECTED]>"
> 
> You don't need the second line because it says the same as the first
> line.  Either kill it, or replace it by an explanation _why_ the
> semaphore is to be replaced by mutex.  (I guess you do it because they
> are lighter-weight, both in semantics and in implementation, and because
> there are better facilities to debug mutexes...)

Thanks for your comment, I rewrite it for 2.6.24-rc7 as a all-in-one patch, 
please see following. Drop i2c maintainer and list in cc because there's no 
changes about i2c in this patch:

Convert semaphore to mutex in struct class

Signed-off-by: Dave Young <[EMAIL PROTECTED]> 

---
drivers/base/class.c  |   22 ++--
drivers/base/core.c   |   18 +++--
drivers/ieee1394/nodemgr.c|   40 +++---
drivers/power/apm_power.c |6 ++---
drivers/power/power_supply_core.c |8 +++
drivers/rtc/interface.c   |4 +--
drivers/scsi/hosts.c  |4 +--
drivers/spi/spi.c |4 +--
include/linux/device.h|3 +-
9 files changed, 54 insertions(+), 55 deletions(-)

diff -upr a/linux-2.6.24-rc7/drivers/base/class.c 
linux-2.6.24-rc7/drivers/base/class.c
--- a/linux-2.6.24-rc7/drivers/base/class.c 2008-01-07 08:56:05.0 
+0800
+++ linux-2.6.24-rc7/drivers/base/class.c   2008-01-07 09:12:49.0 
+0800
@@ -144,7 +144,7 @@ int class_register(struct class * cls)
INIT_LIST_HEAD(>devices);
INIT_LIST_HEAD(>interfaces);
kset_init(>class_dirs);
-   init_MUTEX(>sem);
+   mutex_init(>mutex);
error = kobject_set_name(>subsys.kobj, "%s", cls->name);
if (error)
return error;
@@ -617,13 +617,13 @@ int class_device_add(struct class_device
kobject_uevent(_dev->kobj, KOBJ_ADD);
 
/* notify any interfaces this device is now here */
-   down(_class->sem);
+   mutex_lock_nested(_class->mutex, SINGLE_DEPTH_NESTING);
list_add_tail(_dev->node, _class->children);
list_for_each_entry(class_intf, _class->interfaces, node) {
if (class_intf->add)
class_intf->add(class_dev, class_intf);
}
-   up(_class->sem);
+   mutex_unlock(_class->mutex);
 
goto out1;
 
@@ -725,12 +725,12 @@ void class_device_del(struct class_devic
struct class_interface *class_intf;
 
if (parent_class) {
-   down(_class->sem);
+   mutex_lock(_class->mutex);
list_del_init(_dev->node);
list_for_each_entry(class_intf, _class->interfaces, node)
if (class_intf->remove)
class_intf->remove(class_dev, class_intf);
-   up(_class->sem);
+   mutex_unlock(_class->mutex);
}
 
if (class_dev->dev) {
@@ -772,14 +772,14 @@ void class_device_destroy(struct class *
struct class_device *class_dev = NULL;
struct class_device *class_dev_tmp;
 
-   down(>sem);
+   mutex_lock(>mutex);
list_for_each_entry(class_dev_tmp, >children, node) {
if (class_dev_tmp->devt == devt) {
class_dev = class_dev_tmp;
break;
}
}
-   up(>sem);
+   mutex_unlock(>mutex);
 
if (class_dev)
class_device_unregister(class_dev);
@@ -812,7 +812,7 @@ int class_interface_register(struct clas
if (!parent)
return -EINVAL;
 
-   down(>sem);
+   mutex_lock(>mutex);
list_add_tail(_intf->node, >interfaces);
if (class_intf->add) {

Re: [v4l-dvb-maintainer] [PATCH] Re: Regression: VIDIOCGMBUF ioctl hangs on bttv driver (2.6.24-rc6)

[Douglas Landgraf]

Hi Ingo,

> this is about the bttv driver in 2.6.24-rc6/(rc7?) hanging. So whatever
> the devel tree does, this fix (if it's a correct fix) needs to be
> commited upstream ASAP.

You are right, my misunderstood. Sorry guys!

Cheers,
Douglas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm][PATCH] base: Change power/wakeup output from "" to "unsupported" if wakeup feature isn't supported by a device

[Yi Yang]

On Fri, 2008-01-04 at 17:52 +0100, Olivier Galibert wrote:
> On Fri, Jan 04, 2008 at 11:38:29AM -0500, Alan Stern wrote:
> > How about changing it to say "unavailable"?  That doesn't imply 
> > permanence.
> 
> How about not changing a userland-visible interface gratuitously?
"empty" can't tell a user the state of wakeup of a device, so it is
necessary to change it.
> 
>   OG.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm][PATCH] base: Change power/wakeup output from "" to "unsupported" if wakeup feature isn't supported by a device

[Yi Yang]

On Fri, 2008-01-04 at 11:38 -0500, Alan Stern wrote:
> On Fri, 4 Jan 2008, David Brownell wrote:
> 
> > > > This patch changes empty output to "unsupported" in order that a user 
> > > > knows
> > > > wakeup feature isn't supported by this device when he/she
> > > > 'cat /sys/devices/.../power/wakeup', please consider to apply,
> > > > thanks.
> > >
> > > What about simply removing "wakuep" file if wakeup is not supported?
> > 
> > It may not *stay* unsupported, so I think changing it in either
> > of those permanent ways would be confusing/misleading.
> 
> How about changing it to say "unavailable"?  That doesn't imply 
> permanence.
This should be an option.
> 
> 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: [linux-pm][PATCH] base: Change power/wakeup output from "" to "unsupported" if wakeup feature isn't supported by a device

[Yi Yang]

On Fri, 2008-01-04 at 08:31 -0800, David Brownell wrote:
> > This patch changes empty output to "unsupported" in order that a user knows
> > wakeup feature isn't supported by this device when he/she
> > 'cat /sys/devices/.../power/wakeup', please consider to apply, thanks.
> 
> I don't much like this patch.  Not just for the technical reasons
> mentioned in my previous note ... but also because it doesn't update
> the documention at the top, which clearly states that "\n" is
> returned for "temporary or permanent inability to issue wakeup".
> And then it gives the example I gave before ...
> 
> Though I suppose a patch that changes the *entire* userspace interface,
> (which includes its documentation, and all out-of-tree users) would have
> shown more clearly why it wasn't a good idea.  ;)
Really, "\n" should be changed to show that change.
Anyway, "\n" isn't a good indicator for that state. :-)
> 
> 
> > --- a/drivers/base/power/sysfs.c2008-01-04 16:50:54.0 +0800
> > +++ b/drivers/base/power/sysfs.c2008-01-04 17:14:42.0 +0800
> > @@ -49,7 +49,7 @@ wake_show(struct device * dev, struct de
> >  {
> > return sprintf(buf, "%s\n", device_can_wakeup(dev)
> > ? (device_may_wakeup(dev) ? enabled : disabled)
> > -   : "");
> > +   : "unsupported");
> >  }
> >  
> >  static ssize_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/

Re: [linux-pm][PATCH] base: Change power/wakeup output from "" to "unsupported" if wakeup feature isn't supported by a device

[Rafael J. Wysocki]

On Monday, 7 of January 2008, Yi Yang wrote:
> On Fri, 2008-01-04 at 08:09 -0800, David Brownell wrote:
> > > > This patch changes empty output to "unsupported" in order that a user 
> > > > knows
> > > > wakeup feature isn't supported by this device when he/she
> > > > 'cat /sys/devices/.../power/wakeup', please consider to apply,
> > > > thanks.
> > >
> > > What about simply removing "wakuep" file if wakeup is not supported?
> > 
> > It may not *stay* unsupported, so I think changing it in either
> > of those permanent ways would be confusing/misleading.
> > 
> > For example, USB devices have multiple states ... minimally, an
> > unconfigured state, and a configured state.  Some have multiple
> > configurations.  Only configured states can be wakeup-capable.
> > So a given device might have three states, but support wakeup
> > except in one of them...
> If so, we can change "unsupported" to "unconfigurable" or "inoperable"
> which can cover the states "unconfigured", "unsupported" and other
> unknown states. :-).

The main problem with your patch is that is changes a documented behavior
visible by the user space.  That should be done very cautiously.

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/

[RFC][PATCH] PM: Acquire device locks on suspend (rev. 2)

[Rafael J. Wysocki]

Hi,

The patch below is intended as a replacement for
gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch that deadlocked
suspend and hibernation on some systems.  The present patch contains some
safeguards against deadlocks in that cases and a mechanism to print warnings
if a deadlock is probable.

I've tested it a little, but the error paths are generally untested.

Please review.

Thanks,
Rafael

---
From: Alan Stern <[EMAIL PROTECTED]>, Rafael J. Wysocki <[EMAIL PROTECTED]>

This patch reorganizes the way suspend and resume notifications are
sent to drivers.  The major changes are that now the PM core acquires
every device semaphore before calling the methods, and calls to
device_add() during suspends will fail, while calls to device_del()
during suspends will block.

It also provides a way to safely remove a suspended device with the
help of the PM core, by using the destroy_suspended_device() callback
introduced specifically for this purpose, and updates two drivers (msr
and cpuid) that need to use it.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
 arch/x86/kernel/cpuid.c|6 
 arch/x86/kernel/msr.c  |6 
 drivers/base/core.c|   79 ++-
 drivers/base/power/main.c  |  494 -
 drivers/base/power/power.h |   12 +
 include/linux/device.h |8 
 6 files changed, 406 insertions(+), 199 deletions(-)

Index: linux-2.6/drivers/base/core.c
===
--- linux-2.6.orig/drivers/base/core.c
+++ linux-2.6/drivers/base/core.c
@@ -726,11 +726,20 @@ int device_add(struct device *dev)
 {
struct device *parent = NULL;
struct class_interface *class_intf;
-   int error = -EINVAL;
+   int error;
+
+   error = pm_sleep_lock();
+   if (error) {
+   dev_warn(dev, "Illegal %s during suspend\n", __FUNCTION__);
+   dump_stack();
+   return error;
+   }
 
dev = get_device(dev);
-   if (!dev || !strlen(dev->bus_id))
+   if (!dev || !strlen(dev->bus_id)) {
+   error = -EINVAL;
goto Error;
+   }
 
pr_debug("DEV: registering device: ID = '%s'\n", dev->bus_id);
 
@@ -795,6 +804,7 @@ int device_add(struct device *dev)
}
  Done:
put_device(dev);
+   pm_sleep_unlock();
return error;
  BusError:
device_pm_remove(dev);
@@ -905,6 +915,27 @@ void device_del(struct device * dev)
struct device * parent = dev->parent;
struct class_interface *class_intf;
 
+   /*
+* If this function is called during a suspend, it will be blocked by
+* the PM core holding the device's semaphore at that time, which may
+* lead to a deadlock.  In that case we want to print a warning.
+* However, it may also be called by the PM core itself with the
+* device's semaphore released, in which case the warning should not be
+* printed.
+*/
+   if (down_trylock(>sem)) {
+   if (pm_sleep_lock()) {
+   /* Suspend in progress, we may deadlock */
+   dev_warn(dev, "Illegal %s during suspend\n",
+   __FUNCTION__);
+   dump_stack();
+   } else {
+   pm_sleep_unlock();
+   }
+   } else {
+   up(>sem);
+   }
+
if (parent)
klist_del(>knode_parent);
if (MAJOR(dev->devt))
@@ -1156,14 +1187,11 @@ error:
 EXPORT_SYMBOL_GPL(device_create);
 
 /**
- * device_destroy - removes a device that was created with device_create()
+ * find_device - finds a device that was created with device_create()
  * @class: pointer to the struct class that this device was registered with
  * @devt: the dev_t of the device that was previously registered
- *
- * This call unregisters and cleans up a device that was created with a
- * call to device_create().
  */
-void device_destroy(struct class *class, dev_t devt)
+static struct device *find_device(struct class *class, dev_t devt)
 {
struct device *dev = NULL;
struct device *dev_tmp;
@@ -1176,12 +1204,49 @@ void device_destroy(struct class *class,
}
}
up(>sem);
+   return dev;
+}
+
+/**
+ * device_destroy - removes a device that was created with device_create()
+ * @class: pointer to the struct class that this device was registered with
+ * @devt: the dev_t of the device that was previously registered
+ *
+ * This call unregisters and cleans up a device that was created with a
+ * call to device_create().
+ */
+void device_destroy(struct class *class, dev_t devt)
+{
+   struct device *dev;
 
+   dev = find_device(class, devt);
if (dev)
device_unregister(dev);
 }
 EXPORT_SYMBOL_GPL(device_destroy);
 
+#ifdef CONFIG_PM_SLEEP
+/**
+ * destroy_suspended_device - asks the PM core to remove a 

Re: [PATCH] Fix forcedeth reversing the MAC address on suspend

[Björn Steinbrink]

On 2008.01.04 23:26:33 +0100, Björn Steinbrink wrote:
> For cards that initially have the MAC address stored in reverse order,
> the forcedeth driver uses a flag to signal whether the address was
> already corrected, so that it is not reversed again on a subsequent
> probe.
> 
> Unfortunately this flag, which is stored in a register of the card,
> seems to get lost during suspend, resulting in the MAC address being
> reversed again. To fix that, the MAC address needs to be written back in
> reversed order before we suspend and the flag needs to be reset.
> 
> The flag is still required because at least kexec will never write back
> the reversed address and thus needs to know what state the card is in.
> 
> Signed-off-by: Björn Steinbrink <[EMAIL PROTECTED]>
> ---
> On 2008.01.04 15:08:42 +0100, Richard Jonsson wrote:
> > Björn Steinbrink skrev:
> >> Richard, could you give this a spin? And then we'd likely need someone
> >> to test that with kexec...
> >
> > The patch you sent does the trick, works fine now, thanks!
> > I cannot test this with kexec as I barely know what it is, I'll leave that 
> > to someone else.
> 
> Thanks.
> 
> Ayaz, you originally wrote the kexec fix (IIRC), was my analysis of the
> problem correct? If so, I'm quite sure that the patch DTRT. Still it
> should be tested for the rmmod+modprobe and the kexec case. I'll try to
> get my box free for some testing, but that's unlikely in the next few
> days. Plus, I've never used kexec myself either. So I'd be grateful if
> someone else would step up.

Found a few minutes to test, but kexec would just hang for me. So I'm
unable to test that atm. :-(

Björn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm][PATCH] base: Change power/wakeup output from "" to "unsupported" if wakeup feature isn't supported by a device

[Yi Yang]

On Fri, 2008-01-04 at 08:09 -0800, David Brownell wrote:
> > > This patch changes empty output to "unsupported" in order that a user 
> > > knows
> > > wakeup feature isn't supported by this device when he/she
> > > 'cat /sys/devices/.../power/wakeup', please consider to apply,
> > > thanks.
> >
> > What about simply removing "wakuep" file if wakeup is not supported?
> 
> It may not *stay* unsupported, so I think changing it in either
> of those permanent ways would be confusing/misleading.
> 
> For example, USB devices have multiple states ... minimally, an
> unconfigured state, and a configured state.  Some have multiple
> configurations.  Only configured states can be wakeup-capable.
> So a given device might have three states, but support wakeup
> except in one of them...
If so, we can change "unsupported" to "unconfigurable" or "inoperable"
which can cover the states "unconfigured", "unsupported" and other
unknown states. :-).
> 
> - Dave
> 

--
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: forcedeth: MAC-address reversed on resume from suspend

[Björn Steinbrink]

On 2008.01.06 19:49:49 -0200, Adolfo R. Brandes wrote:
>  I have this forcedeth MAC address reversal problem when suspending
> on 2 distinct boxes.  I can confirm Steinbrink's patch fixes the
> problem on only one of them:
> 
> 00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev f3)
> 
>  On the other one the problem persists:
> 
> 00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a1)

Thanks. Leaves me pretty clueless though. Especially since it worked for
Richard, who also has a MCP51. In a private mail, you said that you had
hardcoded the mac address in the source. Any chance that you applied the
patch on your modified sources and didn't get it right?

thanks,
Björn
--
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][intel_agp] fix name for G35 chipset

[Zhenyu Wang]

Change origin chipset name i965G_1 to market name G35.

Signed-off-by: Zhenyu Wang <[EMAIL PROTECTED]>
---
 drivers/char/agp/intel-agp.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index d879619..7f8b06c 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -12,8 +12,8 @@
 
 #define PCI_DEVICE_ID_INTEL_82946GZ_HB  0x2970
 #define PCI_DEVICE_ID_INTEL_82946GZ_IG  0x2972
-#define PCI_DEVICE_ID_INTEL_82965G_1_HB 0x2980
-#define PCI_DEVICE_ID_INTEL_82965G_1_IG 0x2982
+#define PCI_DEVICE_ID_INTEL_82G35_HB0x2980
+#define PCI_DEVICE_ID_INTEL_82G35_IG0x2982
 #define PCI_DEVICE_ID_INTEL_82965Q_HB   0x2990
 #define PCI_DEVICE_ID_INTEL_82965Q_IG   0x2992
 #define PCI_DEVICE_ID_INTEL_82965G_HB   0x29A0
@@ -32,7 +32,7 @@
 #define PCI_DEVICE_ID_INTEL_Q33_IG  0x29D2
 
 #define IS_I965 (agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_82946GZ_HB || \
- agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_82965G_1_HB || 
\
+ agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_82G35_HB || \
  agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_82965Q_HB || \
  agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_82965G_HB || \
  agp_bridge->dev->device == PCI_DEVICE_ID_INTEL_82965GM_HB || \
@@ -1866,7 +1866,7 @@ static const struct intel_driver_description {
NULL, _915_driver },
{ PCI_DEVICE_ID_INTEL_82946GZ_HB, PCI_DEVICE_ID_INTEL_82946GZ_IG, 0, 
"946GZ",
NULL, _i965_driver },
-   { PCI_DEVICE_ID_INTEL_82965G_1_HB, PCI_DEVICE_ID_INTEL_82965G_1_IG, 0, 
"965G",
+   { PCI_DEVICE_ID_INTEL_82G35_HB, PCI_DEVICE_ID_INTEL_82G35_IG, 0, "G35",
NULL, _i965_driver },
{ PCI_DEVICE_ID_INTEL_82965Q_HB, PCI_DEVICE_ID_INTEL_82965Q_IG, 0, 
"965Q",
NULL, _i965_driver },
@@ -2065,7 +2065,7 @@ static struct pci_device_id agp_intel_pci_table[] = {
ID(PCI_DEVICE_ID_INTEL_82945GM_HB),
ID(PCI_DEVICE_ID_INTEL_82945GME_HB),
ID(PCI_DEVICE_ID_INTEL_82946GZ_HB),
-   ID(PCI_DEVICE_ID_INTEL_82965G_1_HB),
+   ID(PCI_DEVICE_ID_INTEL_82G35_HB),
ID(PCI_DEVICE_ID_INTEL_82965Q_HB),
ID(PCI_DEVICE_ID_INTEL_82965G_HB),
ID(PCI_DEVICE_ID_INTEL_82965GM_HB),
-- 
1.5.3.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/

Re: Improve hackbench

[Zhang, Yanmin]

On Fri, 2008-01-04 at 07:44 -0500, Lee Revell wrote:
> On Jan 4, 2008 3:10 AM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >   http://redhat.com/~mingo/cfs-scheduler/tools/hackbench.c
> >
> 
> Why not lose the #ifdef and just use PTHREAD_STACK_MIN?
That's a good idea.

Thanks,
-yanmin

---

--- hackbench.c.orig2008-01-10 08:24:36.0 +0800
+++ hackbench.c 2008-01-10 08:25:12.0 +0800
@@ -151,10 +151,8 @@ pthread_t create_worker(void *ctx, void 
if (pthread_attr_init() != 0)
barf("pthread_attr_init:");
 
-#ifndef __ia64__
-   if (pthread_attr_setstacksize(, (size_t)(16*1024)) != 0)
+   if (pthread_attr_setstacksize(, PTHREAD_STACK_MIN) != 0)
barf("pthread_attr_setstacksize");
-#endif
 
if ((err=pthread_create(, , func, ctx)) != 0) {
fprintf(stderr, "pthread_create failed: %s (%d)\n", 
strerror(err), err);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm][PATCH] base: Change power/wakeup output from "" to "unsupported" if wakeup feature isn't supported by a device

[Yi Yang]

On Fri, 2008-01-04 at 12:48 +0100, Pavel Machek wrote:
> Hi!
> 
> > If a device can't support wakeup, its /sys/devices/.../power/wakeup output 
> > is
> > empty, this is confusing, a user doesn't know if it supports wakeup feature
> > unless he/she read the ralated source code, for this case, it is more
> > reasonable to output "unsupported". Otherwise, no matter what value the user
> > sets to /sys/devices/.../power/wakeup, the result is the same:  Invalid 
> > argument,
> > so the user doesn't know why.
> > 
> > This patch changes empty output to "unsupported" in order that a user knows
> > wakeup feature isn't supported by this device when he/she
> > 'cat /sys/devices/.../power/wakeup', please consider to apply,
> > thanks.
> 
> What about simply removing "wakuep" file if wakeup is not supported?
>   Pavel
At the beginning, i did that as you said, but it can't work, some
power/wakeup will disappear although they can be disabled or enabled, so
it is only one feasible way to make it exist permanently.
> 

--
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/2] show being-loaded/being-unloaded indicator for modules in oopses

[Rusty Russell]

On Monday 07 January 2008 10:18:50 Arjan van de Ven wrote:
> Subject: show being-loaded/being-unloaded indicator for modules in oopses
> From: Arjan van de Ven <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
>
> It's rather common that an oops/WARN_ON/BUG happens during the load or
> unload of a module. Unfortunatly, it's not always easy to see directly
> which module is being loaded/unloaded from the oops itself. Worse,
> it's not even always possible to ask the bug reporter, since there
> are so many components (udev etc) that auto-load modules that there's
> a good chance that even the reporter doesn't know which module this is.

Excellent, applied.

Thanks Arjan!
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2/2] track and print last unloaded module in the oops trace

[Rusty Russell]

On Monday 07 January 2008 10:19:46 Arjan van de Ven wrote:
> Subject: track and print last unloaded module in the oops trace
> From: Arjan van de Ven <[EMAIL PROTECTED]>
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
> CC: [EMAIL PROTECTED]
>
> Based on a suggestion from Andi:
> In various cases, the unload of a module may leave some bad state around
> that causes a kernel crash AFTER a module is unloaded; and it's then hard
> to find which module caused that.
>
> This patch tracks the last unloaded module, and prints this as part of the
> module list in the oops trace.
>
> Right now, only the last 1 module is tracked; I expect that this is enough
> for the vast majority of cases where this information matters; if it turns
> out that tracking more is important, we can always extend it to that.
>
> Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>

Thanks, applied.

Rusty.
--
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.24-rc6-mm1: sparc64: undefined reference to `vmemmap_table'

[David Miller]

From: Andrew Morton <[EMAIL PROTECTED]>
Date: Sun, 6 Jan 2008 02:15:54 -0800

> On Sun, 6 Jan 2008 11:03:02 +0100 Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
> 
> > This is from allnoconfig on sparc64:
> > 
> >   LD  .tmp_vmlinux1
> > arch/sparc64/kernel/head.o: In function `kvmap_vmemmap':
> > (.text+0x34ec): undefined reference to `vmemmap_table'
> > arch/sparc64/kernel/head.o: In function `kvmap_vmemmap':
> > (.text+0x34f4): undefined reference to `vmemmap_table'
> 
> Happens in mainline too.  Maybe arch/sparc64/kernel/ktlb.S needs to be
> taught about CONFIG_SPARSEMEM_VMEMMAP=n.  

It's pointless to support this thing being off.  If possible
I'd like a method to force it always to be enabled and I'll
look into doing that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Add bug/warn marker to generic report_bug()

[Olof Johansson]

On Sun, Jan 06, 2008 at 01:38:17PM -0800, Arjan van de Ven wrote:
> On Sun, 6 Jan 2008 14:22:23 -0600
> Olof Johansson <[EMAIL PROTECTED]> wrote:
> 
> > Powerpc uses the generic report_bug() from lib/bug.c to report
> > warnings, and I'm guessing other arches do as well.
> > 
> > Add the module list as well as the end-of-trace marker to the output.
> > This required making print_oops_end_marker() nonstatic.
> > 
> > 
> 
> this is the wrong approach...
> powerpc and such should just use oops_enter() / oops_exit() to signal the 
> start/end of such 
> a trace, that gives them all the other behavior of oopsing as well (such as 
> the "slow oops scrolling down" etc)

Note that this is for warnings, not oopses.

This comment in oops_enter threw me off of using it:

debug_locks_off(); /* can't trust the integrity of the kernel
anymore */

Since we can very well depend on the integrity of the kernel when it's
just doing a __WARN().

do_warn_slowpath() doesn't use oops_enter() either.


-Olof
--
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: Improve hackbench

[Zhang, Yanmin]

On Fri, 2008-01-04 at 13:51 +0200, T�r�k Edwin wrote:
> Ingo Molnar wrote:
> > * Zhang, Yanmin <[EMAIL PROTECTED]> wrote:
> >
> >   
> >> hackbench is to test Linux scheduler. The original program is at 
> >> http://devresources.linux-foundation.org/craiger/hackbench/src/hackbench.c 
> >> Based on this multi-process version, a nice person created a 
> >> multi-thread version. Pls. see 
> >> http://www.bullopensource.org/posix/pi-futex/hackbench_pth.c
> >> 
> >
> > great. I've uploaded your unified & improved version to:
> >
> >   http://redhat.com/~mingo/cfs-scheduler/tools/hackbench.c
> >
> > (i made some small changes - two warning fixes on gcc 4.2 and a default 
> > of 10 groups when hackbench is called without parameters, plus a 
> > printout.)
> >   
> 
> On x86-64 there's a bug [*], that causes hackbench to segfault when
> compiled with optimizations:
> in reap_worker():
> int status;
> ...
> pthread_join(id, (void **)(void *));
> 
> That is not correct, sizeof(void*) > sizeof(int) on x86-64.
> Something gets overwritten on the stack, I tried with gcc
> -fstack-protector, but it doesn't detect it !?
> After applying the patch, it no longer segfaults.
> 
> This patch fixes it:
Thanks.

> --- hackbench.c 2008-01-04 10:08:26.0 +0200
> +++ ../hackbench.c  2008-01-04 13:45:22.0 +0200
> @@ -241,8 +241,10 @@
> wait();
> if (!WIFEXITED(status))
> exit(1);
> -   } else
> -   pthread_join(id, (void **)(void *));
> +   } else {
> +   void* status;
> +   pthread_join(id, (void **));
We could use NULL to replace 

> +   }
>  }
> 
>  /* One group of senders and receivers */
> 
> 
> 
> 
> I also notice that the thread version is slower, than process version:
I also noticed that. I did an initial check and found the root cause might
be the difference between pthread_join and wait. wait will wait any sub-process
to exit and pthread_join just waits a specific thread to exit. If the first 
thread
exits lastly, it will take the main thread a longer time to reap sub-threads in 
the end.

> 
> $ ./hackbench 5 thread
> Running with 5*40 (== 200) tasks.
> Time: 0.413
> $ ./hackbench 5 thread
> Running with 5*40 (== 200) tasks.
> Time: 0.423
> $ ./hackbench 5 thread 20
> Running with 5*40 (== 200) tasks.
> Time: 0.093
> $ ./hackbench 5 thread 200
> Running with 5*40 (== 200) tasks.
> Time: 0.827
> $ ./hackbench 5 thread 2000
> Running with 5*40 (== 200) tasks.
> Time: 8.409
> $ ./hackbench 5 process 2000
> Running with 5*40 (== 200) tasks.
> Time: 7.669
> $ ./hackbench -pipe 5  process 2000
> Running with 5*40 (== 200) tasks.
> Time: 3.416
> $ ./hackbench -pipe 5  thread 2000
> Running with 5*40 (== 200) tasks.
> Time: 4.320
> 
> [*]
> $ uname -a
> Linux lightspeed2 2.6.24-rc6-ge697789d #3 Wed Jan 2 11:15:05 EET 2008
> x86_64 GNU/Linux
> $ gcc -v
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v
> --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
> --enable-shared --with-system-zlib --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --enable-nls
> --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2
> --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
> --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.2.3 20071123 (prerelease) (Debian 4.2.2-4)
> $ wget http://redhat.com/~mingo/cfs-scheduler/tools/hackbench.c
> --13:40:53--  http://redhat.com/~mingo/cfs-scheduler/tools/hackbench.c
>=> `hackbench.c'
> Resolving redhat.com... 209.132.177.50
> Connecting to redhat.com|209.132.177.50|:80... connected.
> HTTP request sent, awaiting response... 302 Found
> Location: http://www.redhat.com/~mingo/cfs-scheduler/tools/hackbench.c
> [following]
> --13:40:54--  http://www.redhat.com/~mingo/cfs-scheduler/tools/hackbench.c
>=> `hackbench.c'
> Resolving www.redhat.com... 209.132.177.50
> Connecting to www.redhat.com|209.132.177.50|:80... connected.
> HTTP request sent, awaiting response... 301 Moved Permanently
> Location: http://people.redhat.com/mingo/cfs-scheduler/tools/hackbench.c
> [following]
> --13:40:54--  http://people.redhat.com/mingo/cfs-scheduler/tools/hackbench.c
>=> `hackbench.c'
> Resolving people.redhat.com... 66.187.233.237
> Connecting to people.redhat.com|66.187.233.237|:80... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 8,455 (8.3K) [text/plain]
> 
> 100%[>]
> 8,455 --.--K/s
> 
> 13:40:55 (61.93 KB/s) - `hackbench.c' saved [8455/8455]
> 
> $ gcc  -O2 -g -Wall -o hackbench hackbench.c -lpthread
> hackbench.c:32:66: warning: missing terminating ' character
> $ ./hackbench 1 thread
> Running with 

Re: [PATCH 0/16] lguest: introduce vcpu structure

[Rusty Russell]

On Monday 07 January 2008 04:33:53 Glauber de Oliveira Costa wrote:
> On Dec 25, 2007 9:54 PM, Rusty Russell <[EMAIL PROTECTED]> wrote:
> > My only question is whether we should go further and vpu-ify routines
> > like lgread and kill_guest, so that we can avoid more "lg" temporary
> > variables...
>
> Essentially, they don't need it, because they only touch
> globally-visible variables (visible to the guest).
> So it's more of an stylish thing. Using the vcpu in the signature can
> have only one harm:
> It needs the caller to also have a pointer to a vcpu, so we may end up
> using it everywhere, like a domino fall.
>
> Alternatively, in such functions that don't currently receive a vcpu
> (nor they need to), we can convention to always pass
> lg->vcpus[0] to lgread, kill_guest, etc. Which one do you prefer?

I'm happy with a domino effect.  I don't want to see lg->vcpus[0] *anywhere* 
though, because it's non-futureproof.

When I looked through these patches it seems to me that we should accept that 
vcpu is now the basic guest unit, and lg exists to serve it.  Otherwise I 
think you can see the bones of the old UP code poking through, and that's 
ugly.

Thanks!
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-pm] Re: [PATCH] PM: Acquire device locks on suspend

[Rafael J. Wysocki]

On Monday, 7 of January 2008, Rafael J. Wysocki wrote:
> On Monday, 7 of January 2008, Johannes Berg wrote:
> > Rafael J. Wysocki wrote:
> > 
> > >> I don't see anything wrong with it.  All that will happen is that the
> > >> removal will start before the suspend and finish after the resume.
> > >
> > > In that case, we'll attempt to call the device's .suspend() and .resume()
> > > routines, but we shouldn't do that, IMHO.
> > 
> > I don't see anything wrong with that since the driver must be prepared to
> > handle that even in the regular case, it's the only thing you can
> > guarantee: no more method calls after removal finishes. Am I totally
> > misunderstanding things?
> 
> Well, we are towards the end of device removal at this point, having called
> bus_remove_device(dev) for example, but still we've got it on dpm_active ...
> 
> This may not be technically wrong (ie. we should be able to recover from
> that), but it seems conceptually wrong and with pm_sleep_rwsem in place it
> can be avoided.

No, it can't, without major complications.

Well, I think I'll just send a patch that should work most of the time ...

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: Linux 2.6.24-rc7

[Tejun Heo]

Hello,

Linus Torvalds wrote:
> On Sun, 6 Jan 2008, Mark Lord wrote:
>> We're still missing the sata_qstor regression fix from Tejun,
>> and the patch from Venkatesh Pallipadi that reinstates max_cstate
>> in sysfs for !CPU_IDLE.
> 
> I'm not seeing those in my inbox. I don't go out trolling for patches, 
> because I expect that if the author of the patch really wants me to apply 
> it, he'd send it upstream.
> 
> But I know a number of people are on vacation, and I suspect some of these 
> fixes are just queued up, waiting for that.  E.g. I think Jeff is supposed 
> to be back this week, etc..

Yeap, I have two patches pending for #upstream-fixes.

http://article.gmane.org/gmane.linux.ide/26750
http://article.gmane.org/gmane.linux.ide/26822

Jeff, can you ack those?

Thanks.

-- 
tejun
--
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.24-rc6 oops in net_tx_action

[Francois Romieu]

[EMAIL PROTECTED] <[EMAIL PROTECTED]> :
> Kernel is 2.6.24-rc6 + linuxpps patches, which are all to the serial
> port driver.
> 
> 2.6.23 was known stable.  I haven't tested earlier 2.6.24 releases.
> I think it happened once before; I got a black-screen lockup with
> keyboard LEDs blinking, but that was with X running so I couldn't see a
> console oops.  But given that I installed 2.6.24-rc6 about 24 hours ago,
> that's a disturbing pattern.

It is probably this one:

http://marc.info/?t=11978279403=1=2

-- 
Ueimor
--
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 2.6.24-rc7

[Linus Torvalds]

On Sun, 6 Jan 2008, Mark Lord wrote:
> 
> We're still missing the sata_qstor regression fix from Tejun,
> and the patch from Venkatesh Pallipadi that reinstates max_cstate
> in sysfs for !CPU_IDLE.

I'm not seeing those in my inbox. I don't go out trolling for patches, 
because I expect that if the author of the patch really wants me to apply 
it, he'd send it upstream.

But I know a number of people are on vacation, and I suspect some of these 
fixes are just queued up, waiting for that.  E.g. I think Jeff is supposed 
to be back this week, etc..

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: [linux-pm] Re: [PATCH] PM: Acquire device locks on suspend

[Rafael J. Wysocki]

On Monday, 7 of January 2008, Johannes Berg wrote:
> Rafael J. Wysocki wrote:
> 
> >> I don't see anything wrong with it.  All that will happen is that the
> >> removal will start before the suspend and finish after the resume.
> >
> > In that case, we'll attempt to call the device's .suspend() and .resume()
> > routines, but we shouldn't do that, IMHO.
> 
> I don't see anything wrong with that since the driver must be prepared to
> handle that even in the regular case, it's the only thing you can
> guarantee: no more method calls after removal finishes. Am I totally
> misunderstanding things?

Well, we are towards the end of device removal at this point, having called
bus_remove_device(dev) for example, but still we've got it on dpm_active ...

This may not be technically wrong (ie. we should be able to recover from
that), but it seems conceptually wrong and with pm_sleep_rwsem in place it
can be avoided.

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: Linux 2.6.24-rc7

[Mark Lord]

Linus Torvalds wrote:
..
Both git trees and tar-balls/patches pushed out, should be mirroring out 
within minutes. So there are no excuses to not try it out, and see if your 
favorite regression has been fixed.

..

We're still missing the sata_qstor regression fix from Tejun,
and the patch from Venkatesh Pallipadi that reinstates max_cstate
in sysfs for !CPU_IDLE.

Cheers

--
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: pnpacpi: exceeded the max number of IO resources: 24

[Frans Pop]

(Adding the kernel list back. Any reason you did not send the reply there?)

Sorry for the late reply: Christmas, New Year, the flue, etc.

On Friday 28 December 2007, Zhao Yakui wrote:
> On Mon, 2007-12-24 at 06:12 +0100, Frans Pop wrote:
> > During boot with v2.6.24-rc6-125-g5356f66 on my Toshiba Satellite A40
> > laptop, I suddenly get the following message (repeated 22 times!):
> >pnpacpi: exceeded the max number of IO resources: 24
> >
> > Last time I tested 2.6.24 on that box was after the initial merge, but
> > before -rc1. Then those lines were not present.
> >
> > Looks like the messages originate from a7839e96 by Zhao Yakui and that
> > patch just adds the kernel messages so it was probably a hidden issue
> > before, but I cannot determine if I should be worried or not.
>
> Thanks for caring this problem.

And thank you for the reply, although I must admit that I'm still confused.

> In the patch of a7839e96 the predefined PNP constant is changed. For
> example: IO is changed from 8 to 24, Mem is changed from 4 to 12.
> That means that more resources will be obtained from the PNP device
> defined in ACPI table. So the system will print more message.

OK. The change for Mem from 4 to 12 could explain the extra "iomem range" 
messages (although I don't quite understand why resources that "could not 
be reserved" still use a slot).
I do not yet see how the "ioport range" messages increased from 0 to 16 is 
explained, but I'm not too worried about that.

> At the same time another problem maybe happens. If the number of
> resources defined in BIOS still exceeds the predefined PNP constant, it
> will report that pnpacpi: exceeded the max number of IO resources: 24.
> Although it can be fixed by changed the pnp constant bigger, it is
> inappropriate because it will waste a lot of memory in most cases.
>
> Of course the above error message is harmless.

Are the _errors_ really harmless?

Your commit message was:
"It brings that some resources can't be reserved and resource confilicts.  
This will cause PCI resources are assigned wrongly in some systems, and 
cause hang. This is a regression since we deleted ACPI motherboard driver 
and use PNP system driver."

That text seems to indicate that not reserving the remaining resources _can_ 
cause real problems. Do we know what PCI resources are now not being 
correctly reserved on my laptop (and other machines)? The fact that the 
message is repeated 22 times seems to indicate that in my case quite a lot 
of resources are being ignored.

Should the memory allocation maybe be made dynamic instead of static if the 
memory waste is really such a problem? Apparently the number of PCI 
resources can vary wildly from one machine to another.

If the error messages really are harmless, shouldn't they be changed from 
ERR to DEBUG? As it is, the messages are extremely ugly and will probably 
cause a lot of people to file bug reports as it _looks_ like there is an 
error.

Cheers,
Frans Pop
--
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: Oops in evdev_disconnect for kernel 2.6.23.12

[Al Viro]

On Sun, Jan 06, 2008 at 10:15:16PM +0100, Berthold Cogel wrote:
> I did that and got this in 'make modules':
> 
>   CC [M]  drivers/input/joydev.o
>   CC [M]  drivers/input/evdev.o
> drivers/input/evdev.c: In function 'evdev_do_ioctl':
> drivers/input/evdev.c:749: error: 'struct input_dev' has no member named 
> 'event_lock'
> drivers/input/evdev.c:757: error: 'struct input_dev' has no member named 
> 'event_lock'
> make[2]: *** [drivers/input/evdev.o] Fehler 1
> make[1]: *** [drivers/input] Fehler 2
> make: *** [drivers] Fehler 2
> 
> 
> The next piece of the puzzle:
> 
> No oops with 2.6.24-rc6 vanilla and the same kernel patched with 
> TuxOnIce 3.0-rc3 for kernel 2.6.24-rc3. A minor nit was that I had to 
> rebuild the xorg driver for the tablet to get it working.

No puzzle at all - the changeset in question is present in -rc3.  As for
the errors - looks like it does indeed depend on the previous changeset.
After poking a bit in the archived thread, http://lkml.org/lkml/2007/7/24/19
appears to contain the previous one.
--
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] power_supply: add few more values and props

[Dmitry]

Hi,

2008/1/7, Anton Vorontsov <[EMAIL PROTECTED]>:
> On Mon, Jan 07, 2008 at 02:13:07AM +0300, Dmitry wrote:
> > Hi,
> >
> > 2008/1/7, Anton Vorontsov <[EMAIL PROTECTED]>:
> > > On Mon, Jan 07, 2008 at 01:15:32AM +0300, Dmitry wrote:
> > > [...]
> > > > > > + POWER_SUPPLY_ATTR(voltage_max),
> > > > > > + POWER_SUPPLY_ATTR(voltage_min),
> > > > >
> > > > > I'd suggest keep Documentation/power_supply_class.txt in sync
> > > > > wrt new properties, to distinct their meanings and usage.
> > > > >
> > > > > I assume you're using these new properties for non-rechargeable
> > > > > LiMn batteries. So, why new properties, aren't voltage_*_design
> > > > > ones suits that purpose? If battery is non-rechargeable it is
> > > > > having only design values, no?
> > > >
> > > > No, I used it for the battery driver for Sharp Zaurus SL-6000 (tosa).
> > > > It's connected via simple ADC so I can get only voltages. I don't know
> > > > max_design value for the battery, but I have 'FULL' signal which I use
> > > > to detect 'voltage_max' and use it for power estimations.
> > >
> > > Ah, I see. In that case the value is empiric and voltage_max is
> > > appropriate name indeed.
> >
> > :) Documentation patch should be pretty trivial, could you please just
> > make it w/o another resent cycle?
>
> Sure thing, will do.

Thank you very much!

>
> Thanks,
>
> --
> Anton Vorontsov
> email: [EMAIL PROTECTED]
> backup email: [EMAIL PROTECTED]
> irc://irc.freenode.net/bd2
>


-- 
With best wishes
Dmitry
--
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] power_supply: add few more values and props

[Anton Vorontsov]

On Mon, Jan 07, 2008 at 02:13:07AM +0300, Dmitry wrote:
> Hi,
> 
> 2008/1/7, Anton Vorontsov <[EMAIL PROTECTED]>:
> > On Mon, Jan 07, 2008 at 01:15:32AM +0300, Dmitry wrote:
> > [...]
> > > > > + POWER_SUPPLY_ATTR(voltage_max),
> > > > > + POWER_SUPPLY_ATTR(voltage_min),
> > > >
> > > > I'd suggest keep Documentation/power_supply_class.txt in sync
> > > > wrt new properties, to distinct their meanings and usage.
> > > >
> > > > I assume you're using these new properties for non-rechargeable
> > > > LiMn batteries. So, why new properties, aren't voltage_*_design
> > > > ones suits that purpose? If battery is non-rechargeable it is
> > > > having only design values, no?
> > >
> > > No, I used it for the battery driver for Sharp Zaurus SL-6000 (tosa).
> > > It's connected via simple ADC so I can get only voltages. I don't know
> > > max_design value for the battery, but I have 'FULL' signal which I use
> > > to detect 'voltage_max' and use it for power estimations.
> >
> > Ah, I see. In that case the value is empiric and voltage_max is
> > appropriate name indeed.
> 
> :) Documentation patch should be pretty trivial, could you please just
> make it w/o another resent cycle?

Sure thing, will do.

Thanks,

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
--
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: [v4l-dvb-maintainer] [PATCH] Re: Regression: VIDIOCGMBUF ioctl hangs on bttv driver (2.6.24-rc6)

[Ingo Molnar]

* Douglas Landgraf <[EMAIL PROTECTED]> wrote:

> Hi guys,
> 
> Gregor, we have converted bttv driver to use vidioc_ioctl2 some 
> days ago. Could you check and create your patch against v4l 
> development tree? Bttv driver does not have anymore bttv_do_ioctl().

this is about the bttv driver in 2.6.24-rc6/(rc7?) hanging. So whatever 
the devel tree does, this fix (if it's a correct fix) needs to be 
commited upstream ASAP.

Ingo

ps. http://www.zip.com.au/~akpm/linux/patches/stuff/top-posting.txt

--
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] track and print last unloaded module in the oops trace

[Arjan van de Ven]

Subject: track and print last unloaded module in the oops trace
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]

Based on a suggestion from Andi: 
In various cases, the unload of a module may leave some bad state around
that causes a kernel crash AFTER a module is unloaded; and it's then hard
to find which module caused that. 

This patch tracks the last unloaded module, and prints this as part of the
module list in the oops trace.

Right now, only the last 1 module is tracked; I expect that this is enough
for the vast majority of cases where this information matters; if it turns
out that tracking more is important, we can always extend it to that.

Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>

---
 kernel/module.c |6 ++
 1 file changed, 6 insertions(+)

Index: linux-2.6.24-rc6/kernel/module.c
===
--- linux-2.6.24-rc6.orig/kernel/module.c
+++ linux-2.6.24-rc6/kernel/module.c
@@ -655,6 +655,8 @@ static void wait_for_zero_refcount(struc
mutex_lock(_mutex);
 }
 
+static char last_unloaded_module[MODULE_NAME_LEN+1];
+
 asmlinkage long
 sys_delete_module(const char __user *name_user, unsigned int flags)
 {
@@ -721,6 +723,8 @@ sys_delete_module(const char __user *nam
mod->exit();
mutex_lock(_mutex);
}
+   /* Store the name of the last unloaded module for diagnostic purposes */
+   sprintf(last_unloaded_module, mod->name);
free_module(mod);
 
  out:
@@ -2501,6 +2505,8 @@ void print_modules(void)
printk("Modules linked in:");
list_for_each_entry(mod, , list)
printk(" %s%s", mod->name, module_flags(mod, buf));
+   if (last_unloaded_module[0])
+   printk(" [last unloaded: %s]", last_unloaded_module);
printk("\n");
 }
 

-- 
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/

[patch 1/2] show being-loaded/being-unloaded indicator for modules in oopses

[Arjan van de Ven]

Subject: show being-loaded/being-unloaded indicator for modules in oopses
From: Arjan van de Ven <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]

It's rather common that an oops/WARN_ON/BUG happens during the load or
unload of a module. Unfortunatly, it's not always easy to see directly
which module is being loaded/unloaded from the oops itself. Worse,
it's not even always possible to ask the bug reporter, since there
are so many components (udev etc) that auto-load modules that there's
a good chance that even the reporter doesn't know which module this is.

This patch extends the existing "show if it's tainting" print code,
which is used as part of printing the modules in the oops/BUG/WARN_ON
to include a "+" for "being loaded" and a "-" for "being unloaded".

As a result this extension, the "taint_flags()" function gets renamed to
"module_flags()" (and takes a module struct as argument, not a taint
flags int).

Signed-off-by: Arjan van de Ven <[EMAIL PROTECTED]>

---
 kernel/module.c |   21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

Index: linux-2.6.24-rc6/kernel/module.c
===
--- linux-2.6.24-rc6.orig/kernel/module.c
+++ linux-2.6.24-rc6/kernel/module.c
@@ -2355,21 +2355,30 @@ static void m_stop(struct seq_file *m, v
mutex_unlock(_mutex);
 }
 
-static char *taint_flags(unsigned int taints, char *buf)
+static char *module_flags(struct module *mod, char *buf)
 {
int bx = 0;
 
-   if (taints) {
+   if (mod->taints ||
+   mod->state == MODULE_STATE_GOING ||
+   mod->state == MODULE_STATE_COMING) {
buf[bx++] = '(';
-   if (taints & TAINT_PROPRIETARY_MODULE)
+   if (mod->taints & TAINT_PROPRIETARY_MODULE)
buf[bx++] = 'P';
-   if (taints & TAINT_FORCED_MODULE)
+   if (mod->taints & TAINT_FORCED_MODULE)
buf[bx++] = 'F';
/*
 * TAINT_FORCED_RMMOD: could be added.
 * TAINT_UNSAFE_SMP, TAINT_MACHINE_CHECK, TAINT_BAD_PAGE don't
 * apply to modules.
 */
+
+   /* Show a - for module-is-being-unloaded */
+   if (mod->state == MODULE_STATE_GOING)
+   buf[bx++] = '-';
+   /* Show a + for module-is-being-loaded */
+   if (mod->state == MODULE_STATE_COMING)
+   buf[bx++] = '+';
buf[bx++] = ')';
}
buf[bx] = '\0';
@@ -2396,7 +2405,7 @@ static int m_show(struct seq_file *m, vo
 
/* Taints info */
if (mod->taints)
-   seq_printf(m, " %s", taint_flags(mod->taints, buf));
+   seq_printf(m, " %s", module_flags(mod, buf));
 
seq_printf(m, "\n");
return 0;
@@ -2491,7 +2500,7 @@ void print_modules(void)
 
printk("Modules linked in:");
list_for_each_entry(mod, , list)
-   printk(" %s%s", mod->name, taint_flags(mod->taints, buf));
+   printk(" %s%s", mod->name, module_flags(mod, buf));
printk("\n");
 }
 


-- 
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/

2.6.24-rc6 oops in net_tx_action

[linux]

Kernel is 2.6.24-rc6 + linuxpps patches, which are all to the serial
port driver.

2.6.23 was known stable.  I haven't tested earlier 2.6.24 releases.
I think it happened once before; I got a black-screen lockup with
keyboard LEDs blinking, but that was with X running so I couldn't see a
console oops.  But given that I installed 2.6.24-rc6 about 24 hours ago,
that's a disturbing pattern.

(N.B. I was pretty careful, but the following was transcribed by hand.)

BUG: unable to handle kernel paging request at virtual address 00100104
printing eip: b02b3d6a *pde=
Oops: 0002 [#1]

Pid 3162, comm: ntop Not tainted (2.6.24-rc6 #36)
EIP: 0060[] EFLAGS: 00210046 CPU: 0
EIP is at net_tx_action+0x8b/0xec
EAX: 00100100 EBX: efa63924 ECX: 0801fbff EDX: 00200200
ESI: 0010 EDI: 0010 EBP: 012c ESP: b0444fc8
 DS: 007b ES: 007b FS:  GS: 0033 SS: 0068
 Process ntop (pid: 3162, ti=b0444000 task=e9122f90 task.ti=e92ec000)
 Stack:  000a b02b3a84 b044007b 000a7ac5 0001 b0457a44 0009
 b0118016 e92ecf74 e92ec000 00200046 b0103c3c
Call Trace:
 [] net_tx_action+0x5a/0xa8
 [] __do_softirq+0x35/0x75
 [] do_softirq+0x3e/0x8f
 [] do_gettimeofday+0x2c/0xc6
 [] handle_level_irq+0x0/0x8d
 [] irq_exit+0x29/0x58
 [] do_IRQ+0xaf/0xc2
 [] sys_gettimeofday+0x27/0x53
 [] common_interrupt+0x23/0x28
 ===
Code: 24 04 ec 61 3d b0 c7 04 24 87 01 3a b0 e8 ad 10 e6 ff e8 44 fd e4 ff c7 
05 1c b9 46 b0 01 00 00 00 fa 39 fe 75 20 8b 03 8b 53 04 <89> 50 04 89 02 a1 fc 
b8 46 b0 c7 03 f8 b8 46 b0 89 1d fc b8 46
EIP: [] at net_tx_action+0x8b/0xec SS:ESP 0068:b0444fc8
Kernel panic - not syncing: Fatal exception in interrupt


Network config is a little complex; there are 5 physical network
interfaces and a bunch of netfilter rules.  A quad-port 100baseT Tulip
card which provides "outside-facing" interfaces (two uplinks, a DMZ,
and a spare), and a gigabit VIA velocity card for the internal network.

The hardware has ECC memory (1 GB, kernel starts at 2.75G) and mirrored
drives, and has generally been very stable for a long time, modulo some
disk hiccups.

$ lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX Host bridge 
(rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge 
(rev 03)
00:04.0 ISA bridge: Intel Corporation 82371AB/EB/MB PIIX4 ISA (rev 02)
00:04.1 IDE interface: Intel Corporation 82371AB/EB/MB PIIX4 IDE (rev 01)
00:04.2 USB Controller: Intel Corporation 82371AB/EB/MB PIIX4 USB (rev 01)
00:04.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
00:09.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 
Gigabit Ethernet Adapter (rev 11)
00:0a.0 Mass storage controller: Promise Technology, Inc. PDC20268 (Ultra100 
TX2) (rev 01)
00:0b.0 Mass storage controller: Promise Technology, Inc. PDC20268 (Ultra100 
TX2) (rev 01)
00:0c.0 Mass storage controller: Promise Technology, Inc. 20269 (rev 02)
00:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03)
01:00.0 VGA compatible controller: nVidia Corporation NV6 [Vanta/Vanta LT] (rev 
15)
02:04.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 
(rev 41)
02:05.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 
(rev 41)
02:06.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 
(rev 41)
02:07.0 Ethernet controller: Digital Equipment Corporation DECchip 21142/43 
(rev 41)

The tulip drivers have been solid forever.  The VIA velocity driver is more
suspect; I made an effort a while ago to get tagged VLANs working on it,
which was a notable failure.  Still, this oops is in core network code.

As you might guess, it makes people somewhat grumpy when the main
firewall/router takes a dive, but I can experiment after hours.

Here's the kernel config:

$ grep ^CONFIG /usr/src/linux/.config
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_SUPPORTS_OPROFILE=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_IKCONFIG=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_FAIR_USER_SCHED=y
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_HOTPLUG=y

Re: [PATCH 3/3]

[Dmitry]

Hi,

2008/1/7, Anton Vorontsov <[EMAIL PROTECTED]>:
> On Sun, Jan 06, 2008 at 03:30:16PM +0300, Dmitry Baryshkov wrote:
> > Support using VOLTAGE_* properties for apm calculations. It's pretty
> > dummy, but useful for batteries for which we can only get voltages.
>
> Here Signed-off-by: line is missing, please provide one so I could
> apply the patch.

Signed-off-by: Dmitry Baryshkov <[EMAIL PROTECTED]>

:)

>
> Thanks!
>
> > diff --git a/drivers/power/apm_power.c b/drivers/power/apm_power.c
> > index bbf3ee1..526c96e 100644
> > --- a/drivers/power/apm_power.c
> > +++ b/drivers/power/apm_power.c
> > @@ -13,6 +13,12 @@
> >  #include 
> >  #include 
> >
> > +typedef enum {
> > + SOURCE_ENERGY,
> > + SOURCE_CHARGE,
> > + SOURCE_VOLTAGE,
> > +} apm_source;
> > +
> >  #define PSY_PROP(psy, prop, val) psy->get_property(psy, \
> >POWER_SUPPLY_PROP_##prop, val)
> >
> > @@ -87,7 +93,7 @@ static void find_main_battery(void)
> >   }
> >  }
> >
> > -static int calculate_time(int status, int using_charge)
> > +static int calculate_time(int status, apm_source source)
> >  {
> >   union power_supply_propval full;
> >   union power_supply_propval empty;
> > @@ -106,20 +112,34 @@ static int calculate_time(int status, int 
> > using_charge)
> >   return -1;
> >   }
> >
> > - if (using_charge) {
> > + switch (source) {
> > + case SOURCE_CHARGE:
> >   full_prop = POWER_SUPPLY_PROP_CHARGE_FULL;
> >   full_design_prop = POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN;
> >   empty_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
> >   empty_design_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
> >   cur_avg_prop = POWER_SUPPLY_PROP_CHARGE_AVG;
> >   cur_now_prop = POWER_SUPPLY_PROP_CHARGE_NOW;
> > - } else {
> > + break;
> > + case SOURCE_ENERGY:
> >   full_prop = POWER_SUPPLY_PROP_ENERGY_FULL;
> >   full_design_prop = POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN;
> >   empty_prop = POWER_SUPPLY_PROP_ENERGY_EMPTY;
> >   empty_design_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
> >   cur_avg_prop = POWER_SUPPLY_PROP_ENERGY_AVG;
> >   cur_now_prop = POWER_SUPPLY_PROP_ENERGY_NOW;
> > + break;
> > + case SOURCE_VOLTAGE:
> > + full_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX;
> > + full_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN;
> > + empty_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN;
> > + empty_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN;
> > + cur_avg_prop = POWER_SUPPLY_PROP_VOLTAGE_AVG;
> > + cur_now_prop = POWER_SUPPLY_PROP_VOLTAGE_NOW;
> > + break;
> > + default:
> > + printk(KERN_ERR "Unsupported source: %d\n", source);
> > + return -1;
> >   }
> >
> >   if (_MPSY_PROP(full_prop, )) {
> > @@ -146,7 +166,7 @@ static int calculate_time(int status, int using_charge)
> >   return -((cur.intval - empty.intval) * 60L) / I.intval;
> >  }
> >
> > -static int calculate_capacity(int using_charge)
> > +static int calculate_capacity(apm_source source)
> >  {
> >   enum power_supply_property full_prop, empty_prop;
> >   enum power_supply_property full_design_prop, empty_design_prop;
> > @@ -154,20 +174,33 @@ static int calculate_capacity(int using_charge)
> >   union power_supply_propval empty, full, cur;
> >   int ret;
> >
> > - if (using_charge) {
> > + switch (source) {
> > + case SOURCE_CHARGE:
> >   full_prop = POWER_SUPPLY_PROP_CHARGE_FULL;
> >   empty_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
> >   full_design_prop = POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN;
> >   empty_design_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY_DESIGN;
> >   now_prop = POWER_SUPPLY_PROP_CHARGE_NOW;
> >   avg_prop = POWER_SUPPLY_PROP_CHARGE_AVG;
> > - } else {
> > + break;
> > + case SOURCE_ENERGY:
> >   full_prop = POWER_SUPPLY_PROP_ENERGY_FULL;
> >   empty_prop = POWER_SUPPLY_PROP_ENERGY_EMPTY;
> >   full_design_prop = POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN;
> >   empty_design_prop = POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN;
> >   now_prop = POWER_SUPPLY_PROP_ENERGY_NOW;
> >   avg_prop = POWER_SUPPLY_PROP_ENERGY_AVG;
> > + case SOURCE_VOLTAGE:
> > + full_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX;
> > + empty_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN;
> > + full_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN;
> > + empty_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN;
> > + now_prop = POWER_SUPPLY_PROP_VOLTAGE_NOW;
> > + avg_prop = POWER_SUPPLY_PROP_VOLTAGE_AVG;
> > + break;
> > + default:
> > + printk(KERN_ERR "Unsupported source: 

Re: [PATCH 1/3] power_supply: add few more values and props

[Dmitry]

Hi,

2008/1/7, Anton Vorontsov <[EMAIL PROTECTED]>:
> On Mon, Jan 07, 2008 at 01:15:32AM +0300, Dmitry wrote:
> [...]
> > > > + POWER_SUPPLY_ATTR(voltage_max),
> > > > + POWER_SUPPLY_ATTR(voltage_min),
> > >
> > > I'd suggest keep Documentation/power_supply_class.txt in sync
> > > wrt new properties, to distinct their meanings and usage.
> > >
> > > I assume you're using these new properties for non-rechargeable
> > > LiMn batteries. So, why new properties, aren't voltage_*_design
> > > ones suits that purpose? If battery is non-rechargeable it is
> > > having only design values, no?
> >
> > No, I used it for the battery driver for Sharp Zaurus SL-6000 (tosa).
> > It's connected via simple ADC so I can get only voltages. I don't know
> > max_design value for the battery, but I have 'FULL' signal which I use
> > to detect 'voltage_max' and use it for power estimations.
>
> Ah, I see. In that case the value is empiric and voltage_max is
> appropriate name indeed.

:) Documentation patch should be pretty trivial, could you please just
make it w/o another resent cycle?

>
> Thanks,
>
> --
> Anton Vorontsov
> email: [EMAIL PROTECTED]
> backup email: [EMAIL PROTECTED]
> irc://irc.freenode.net/bd2
>


-- 
With best wishes
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3]

[Anton Vorontsov]

On Sun, Jan 06, 2008 at 03:30:16PM +0300, Dmitry Baryshkov wrote:
> Support using VOLTAGE_* properties for apm calculations. It's pretty
> dummy, but useful for batteries for which we can only get voltages.

Here Signed-off-by: line is missing, please provide one so I could
apply the patch.

Thanks!

> diff --git a/drivers/power/apm_power.c b/drivers/power/apm_power.c
> index bbf3ee1..526c96e 100644
> --- a/drivers/power/apm_power.c
> +++ b/drivers/power/apm_power.c
> @@ -13,6 +13,12 @@
>  #include 
>  #include 
>  
> +typedef enum {
> + SOURCE_ENERGY,
> + SOURCE_CHARGE,
> + SOURCE_VOLTAGE,
> +} apm_source;
> +
>  #define PSY_PROP(psy, prop, val) psy->get_property(psy, \
>POWER_SUPPLY_PROP_##prop, val)
>  
> @@ -87,7 +93,7 @@ static void find_main_battery(void)
>   }
>  }
>  
> -static int calculate_time(int status, int using_charge)
> +static int calculate_time(int status, apm_source source)
>  {
>   union power_supply_propval full;
>   union power_supply_propval empty;
> @@ -106,20 +112,34 @@ static int calculate_time(int status, int using_charge)
>   return -1;
>   }
>  
> - if (using_charge) {
> + switch (source) {
> + case SOURCE_CHARGE:
>   full_prop = POWER_SUPPLY_PROP_CHARGE_FULL;
>   full_design_prop = POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN;
>   empty_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
>   empty_design_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
>   cur_avg_prop = POWER_SUPPLY_PROP_CHARGE_AVG;
>   cur_now_prop = POWER_SUPPLY_PROP_CHARGE_NOW;
> - } else {
> + break;
> + case SOURCE_ENERGY:
>   full_prop = POWER_SUPPLY_PROP_ENERGY_FULL;
>   full_design_prop = POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN;
>   empty_prop = POWER_SUPPLY_PROP_ENERGY_EMPTY;
>   empty_design_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
>   cur_avg_prop = POWER_SUPPLY_PROP_ENERGY_AVG;
>   cur_now_prop = POWER_SUPPLY_PROP_ENERGY_NOW;
> + break;
> + case SOURCE_VOLTAGE:
> + full_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX;
> + full_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN;
> + empty_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN;
> + empty_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN;
> + cur_avg_prop = POWER_SUPPLY_PROP_VOLTAGE_AVG;
> + cur_now_prop = POWER_SUPPLY_PROP_VOLTAGE_NOW;
> + break;
> + default:
> + printk(KERN_ERR "Unsupported source: %d\n", source);
> + return -1;
>   }
>  
>   if (_MPSY_PROP(full_prop, )) {
> @@ -146,7 +166,7 @@ static int calculate_time(int status, int using_charge)
>   return -((cur.intval - empty.intval) * 60L) / I.intval;
>  }
>  
> -static int calculate_capacity(int using_charge)
> +static int calculate_capacity(apm_source source)
>  {
>   enum power_supply_property full_prop, empty_prop;
>   enum power_supply_property full_design_prop, empty_design_prop;
> @@ -154,20 +174,33 @@ static int calculate_capacity(int using_charge)
>   union power_supply_propval empty, full, cur;
>   int ret;
>  
> - if (using_charge) {
> + switch (source) {
> + case SOURCE_CHARGE:
>   full_prop = POWER_SUPPLY_PROP_CHARGE_FULL;
>   empty_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY;
>   full_design_prop = POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN;
>   empty_design_prop = POWER_SUPPLY_PROP_CHARGE_EMPTY_DESIGN;
>   now_prop = POWER_SUPPLY_PROP_CHARGE_NOW;
>   avg_prop = POWER_SUPPLY_PROP_CHARGE_AVG;
> - } else {
> + break;
> + case SOURCE_ENERGY:
>   full_prop = POWER_SUPPLY_PROP_ENERGY_FULL;
>   empty_prop = POWER_SUPPLY_PROP_ENERGY_EMPTY;
>   full_design_prop = POWER_SUPPLY_PROP_ENERGY_FULL_DESIGN;
>   empty_design_prop = POWER_SUPPLY_PROP_ENERGY_EMPTY_DESIGN;
>   now_prop = POWER_SUPPLY_PROP_ENERGY_NOW;
>   avg_prop = POWER_SUPPLY_PROP_ENERGY_AVG;
> + case SOURCE_VOLTAGE:
> + full_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX;
> + empty_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN;
> + full_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN;
> + empty_design_prop = POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN;
> + now_prop = POWER_SUPPLY_PROP_VOLTAGE_NOW;
> + avg_prop = POWER_SUPPLY_PROP_VOLTAGE_AVG;
> + break;
> + default:
> + printk(KERN_ERR "Unsupported source: %d\n", source);
> + return -1;
>   }
>  
>   if (_MPSY_PROP(full_prop, )) {
> @@ -234,10 +267,12 @@ static void apm_battery_apm_get_power_status(struct 
> apm_power_info *info)
>   info->battery_life = capacity.intval;
>   } else {
>   /* try calculate using energy */
> -

Re: [v4l-dvb-maintainer] [PATCH] Re: Regression: VIDIOCGMBUF ioctl hangs on bttv driver (2.6.24-rc6)

[Douglas Landgraf]

I mean video_ioctl2 not vidioc_ioctl2, sorry.

Cheers,
Douglas

On Jan 6, 2008 8:53 PM, Douglas Landgraf <[EMAIL PROTECTED]> wrote:
> Hi guys,
>
> Gregor, we have converted bttv driver to use vidioc_ioctl2 some days ago.
> Could you check and create your patch against v4l development tree?
> Bttv driver does not have anymore bttv_do_ioctl().
>
> Cheers,
> Douglas
>
>
> On Jan 6, 2008 12:15 PM, Gregor Jasny <[EMAIL PROTECTED]> wrote:
> > From: Gregor Jasny <[EMAIL PROTECTED]>
> >
> > Fix bttv VIDIOCGMBUF locking like done in commit
> > 820eacd84cff23b76693f4be1e28feb672f4488f.
> >
> > Signed-off-by: Gregor Jasny <[EMAIL PROTECTED]>
> > ---
> > diff --git a/drivers/media/video/bt8xx/bttv-driver.c 
> > b/drivers/media/video/bt8xx/bttv-driver.c
> > index c02d92d..581a3c9 100644
> > --- a/drivers/media/video/bt8xx/bttv-driver.c
> > +++ b/drivers/media/video/bt8xx/bttv-driver.c
> > @@ -3063,11 +3063,10 @@ static int bttv_do_ioctl(struct inode *inode, 
> > struct file *file,
> > struct video_mbuf *mbuf = arg;
> > unsigned int i;
> >
> > -   mutex_lock(>cap.lock);
> > retval = videobuf_mmap_setup(>cap,gbuffers,gbufsize,
> >  V4L2_MEMORY_MMAP);
> > if (retval < 0)
> > -   goto fh_unlock_and_return;
> > +   return retval;
> >
> > gbuffers = retval;
> > memset(mbuf,0,sizeof(*mbuf));
> > @@ -3075,7 +3074,6 @@ static int bttv_do_ioctl(struct inode *inode, struct 
> > file *file,
> > mbuf->size   = gbuffers * gbufsize;
> > for (i = 0; i < gbuffers; i++)
> > mbuf->offsets[i] = i * gbufsize;
> > -   mutex_unlock(>cap.lock);
> > return 0;
> > }
> > case VIDIOCMCAPTURE:
> >
> >
> > ___
> > v4l-dvb-maintainer mailing list
> > [EMAIL PROTECTED]
> > http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
> >
>
--
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: [v4l-dvb-maintainer] [PATCH] Re: Regression: VIDIOCGMBUF ioctl hangs on bttv driver (2.6.24-rc6)

[Douglas Landgraf]

Hi guys,

Gregor, we have converted bttv driver to use vidioc_ioctl2 some days ago.
Could you check and create your patch against v4l development tree?
Bttv driver does not have anymore bttv_do_ioctl().

Cheers,
Douglas

On Jan 6, 2008 12:15 PM, Gregor Jasny <[EMAIL PROTECTED]> wrote:
> From: Gregor Jasny <[EMAIL PROTECTED]>
>
> Fix bttv VIDIOCGMBUF locking like done in commit
> 820eacd84cff23b76693f4be1e28feb672f4488f.
>
> Signed-off-by: Gregor Jasny <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/media/video/bt8xx/bttv-driver.c 
> b/drivers/media/video/bt8xx/bttv-driver.c
> index c02d92d..581a3c9 100644
> --- a/drivers/media/video/bt8xx/bttv-driver.c
> +++ b/drivers/media/video/bt8xx/bttv-driver.c
> @@ -3063,11 +3063,10 @@ static int bttv_do_ioctl(struct inode *inode, struct 
> file *file,
> struct video_mbuf *mbuf = arg;
> unsigned int i;
>
> -   mutex_lock(>cap.lock);
> retval = videobuf_mmap_setup(>cap,gbuffers,gbufsize,
>  V4L2_MEMORY_MMAP);
> if (retval < 0)
> -   goto fh_unlock_and_return;
> +   return retval;
>
> gbuffers = retval;
> memset(mbuf,0,sizeof(*mbuf));
> @@ -3075,7 +3074,6 @@ static int bttv_do_ioctl(struct inode *inode, struct 
> file *file,
> mbuf->size   = gbuffers * gbufsize;
> for (i = 0; i < gbuffers; i++)
> mbuf->offsets[i] = i * gbufsize;
> -   mutex_unlock(>cap.lock);
> return 0;
> }
> case VIDIOCMCAPTURE:
>
>
> ___
> v4l-dvb-maintainer mailing list
> [EMAIL PROTECTED]
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
>
--
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: SATA kernel-buffered read VERY slow (not raid, Promise TX300 card); 2.6.23.1(vanilla)

[Alan Cox]

On Sun, 06 Jan 2008 12:25:10 -0800
Linda Walsh <[EMAIL PROTECTED]> wrote:

> Robert Hancock wrote:
> >
> > If this is a Seagate, I believe that they don't have AAM enabled on 
> > any of their newer drives (something about a lawsuit for patent 
> > infringement on that feature, or something). Quite likely they don't 
> > support that power management command, either.
> --
> Do you have a source for this -- haven't heard of such a conflict -- 

There were patent questions around AAM. There are some discussions on the
t13 archive then it goes silent and nothing is ever said again, which I
imagine is when it got lawyered.

> besides, doesn't
> ATA-7 require some of those functions? 

No.

Alan
--
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] vivi driver works only as first device

[Gregor Jasny]

On Dec 10, 2007 8:08 AM, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> Thanks for the report. Instead of applying your patch, I decided to
> better analyze the issue, fixing it with the proper solution. The issue
> is that vivi_register changes iminor, but this change were not properly
> returned to the driver.

Any chance to push this into 2.6.24?

Gregor
--
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] PM: Acquire device locks on suspend

[Rafael J. Wysocki]

On Sunday, 6 of January 2008, Alan Stern wrote:
> On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> 
> > > No -- the whole idea here is to print an error message in the system
> > > log if a driver's resume method tries to call device_del().  Deadlock 
> > > is unavoidable in this case, but at least we'll know which driver is 
> > > guilty.
> > 
> > Still, if we do that, we won't need to acquire dev->sem in 
> > device_pm_remove()
> > any more.
> 
> There's a window in lock_all_devices() when dpm_list_mtx isn't held.  
> We don't want device_pm_remove() taking an already-locked device off 
> the dpm_locked list at that time.  So we do need to acquire dev->sem in 
> device_pm_remove().

Not if pm_sleep_rwsem is held by device_del(), since in that case we won't
reach lock_all_devices() (device_add() calls device_pm_remove() under
pm_sleep_rwsem already).

> > Apart from this, by acqiring pm_sleep_rwsem for reading in
> > device_del() we can prevent a suspend from starting while the device is 
> > being
> > removed.
> > 
> > Consider, for example, the scenario possible with the $subject patch:
> > - device_del() starts and notices pm_sleep_rwsem unlocked, so the warning is
> >   not printed
> > - it proceeds and everything before device_pm_remove() succeeds
> > - now, device_suspend() is called and locks dev->sem
> > - device_del() calls device_pm_remove() and blocks on that with the device
> >   partialy removed
> > I think we should prevent this from happening.
> 
> I don't see anything wrong with it.  All that will happen is that the 
> removal will start before the suspend and finish after the resume.

In that case, we'll attempt to call the device's .suspend() and .resume()
routines, but we shouldn't do that, IMHO.

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 1/3] power_supply: add few more values and props

[Anton Vorontsov]

On Mon, Jan 07, 2008 at 01:15:32AM +0300, Dmitry wrote:
[...]
> > > + POWER_SUPPLY_ATTR(voltage_max),
> > > + POWER_SUPPLY_ATTR(voltage_min),
> >
> > I'd suggest keep Documentation/power_supply_class.txt in sync
> > wrt new properties, to distinct their meanings and usage.
> >
> > I assume you're using these new properties for non-rechargeable
> > LiMn batteries. So, why new properties, aren't voltage_*_design
> > ones suits that purpose? If battery is non-rechargeable it is
> > having only design values, no?
> 
> No, I used it for the battery driver for Sharp Zaurus SL-6000 (tosa).
> It's connected via simple ADC so I can get only voltages. I don't know
> max_design value for the battery, but I have 'FULL' signal which I use
> to detect 'voltage_max' and use it for power estimations.

Ah, I see. In that case the value is empiric and voltage_max is
appropriate name indeed.

Thanks,

-- 
Anton Vorontsov
email: [EMAIL PROTECTED]
backup email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-usb-devel] [FEATURE REQUEST] Transparent hot plugging of root file system on portable storage devices.

[Pavel Machek]

On Sun 2008-01-06 17:26:17, Alan Stern wrote:
> On Sun, 6 Jan 2008, Oliver Neukum wrote:
> 
> > Am Sonntag 06 Januar 2008 schrieb Alan Stern:
> > > What about people who want to suspend to RAM instead of hibernating and
> > > _do_ want to unplug the USB device containing their root filesystem
> > > while the machine is asleep? 

Ok, I guess I'm lost here. That sounds like a nice way to do
self-leg-shooting. Are there such people?

> > >  In this case we will _know_ that the
> > > power session has been interrupted, but USB Persist won't activate
> > > because the host controller never lost power.
> > 
> > Would it be hard to force the persist feature on for a replugged device?
> 
> Right now the persist feature is enabled by a per-device boolean flag.  
> In theory the flag could accept 3 values: off, on if power was lost,
> or on for any resume transition.  This would not be a hard change.

But do we need it?

Did you progress on "usb-storage-autosuspend"?

Here are my hacks to try to get SATA to survive autosuspend;
unfortunately they do not work :-(.
Pavel



diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 54f38c2..21e6709 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1808,8 +1808,22 @@ static void ahci_thaw(struct ata_port *a
writel(pp->intr_mask, port_mmio + PORT_IRQ_MASK);
 }
 
+struct pci_dev *my_pdev;
+
 static void ahci_error_handler(struct ata_port *ap)
 {
+   struct ata_host *host = ap->host;
+   int rc;
+   extern int slept;
+   
+   if (slept) {
+   printk("ahci_error_handler: Resuming...\n");
+   rc =ahci_pci_device_resume(my_pdev);
+printk("ahci: bad %d\n", rc);
+
+   printk("ahci_error_handler: Device resumed?\n");
+   }
+
if (!(ap->pflags & ATA_PFLAG_FROZEN)) {
/* restart engine */
ahci_stop_engine(ap);
@@ -1945,7 +1959,7 @@ static int ahci_pci_device_resume(struct
if (rc)
return rc;
 
-   if (pdev->dev.power.power_state.event == PM_EVENT_SUSPEND) {
+   if (1) {
rc = ahci_reset_controller(host);
if (rc)
return rc;
@@ -2179,6 +2193,7 @@ static void ahci_p5wdh_workaround(struct
}
 }
 
+
 static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
static int printed_version;
@@ -2190,6 +2205,7 @@ static int ahci_init_one(struct pci_dev 
int i, rc;
 
VPRINTK("ENTER\n");
+   my_pdev = pdev;
 
WARN_ON(ATA_MAX_QUEUE > AHCI_MAX_CMDS);
 
@@ -2283,8 +2299,11 @@ static int ahci_init_one(struct pci_dev 
ahci_print_info(host);
 
pci_set_master(pdev);
-   return ata_host_activate(host, pdev->irq, ahci_interrupt, IRQF_SHARED,
+
+   rc = ata_host_activate(host, pdev->irq, ahci_interrupt, IRQF_SHARED,
 _sht);
+   pci_save_state(pdev);
+   return rc;
 }
 
 static int __init ahci_init(void)

-- 
(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] PM: Acquire device locks on suspend

[Alan Stern]

On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:

> > No -- the whole idea here is to print an error message in the system
> > log if a driver's resume method tries to call device_del().  Deadlock 
> > is unavoidable in this case, but at least we'll know which driver is 
> > guilty.
> 
> Still, if we do that, we won't need to acquire dev->sem in device_pm_remove()
> any more.

There's a window in lock_all_devices() when dpm_list_mtx isn't held.  
We don't want device_pm_remove() taking an already-locked device off 
the dpm_locked list at that time.  So we do need to acquire dev->sem in 
device_pm_remove().

> Apart from this, by acqiring pm_sleep_rwsem for reading in
> device_del() we can prevent a suspend from starting while the device is being
> removed.
> 
> Consider, for example, the scenario possible with the $subject patch:
> - device_del() starts and notices pm_sleep_rwsem unlocked, so the warning is
>   not printed
> - it proceeds and everything before device_pm_remove() succeeds
> - now, device_suspend() is called and locks dev->sem
> - device_del() calls device_pm_remove() and blocks on that with the device
>   partialy removed
> I think we should prevent this from happening.

I don't see anything wrong with it.  All that will happen is that the 
removal will start before the suspend and finish after the resume.

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.24-rc6-git12: Reported regressions from 2.6.23

[Rafael J. Wysocki]

On Sunday, 6 of January 2008, Arjan van de Ven wrote:
> On Sun, 6 Jan 2008 10:55:01 +0100
> Ingo Molnar <[EMAIL PROTECTED]> wrote:
> 
> > 
> > * Mark Lord <[EMAIL PROTECTED]> wrote:
> > 
> > > Rafael J. Wysocki wrote:
> > >> This message contains a list of some regressions from 2.6.23
> > >> reported since 2.6.24-rc1 was released, for which there are no
> > >> fixes in the mainline I know of.  If any of them have been fixed
> > >> already, please let me know.
> > > ..
> > >> Subject  : 2+ wake-ups/second in 2.6.24
> > >> Submitter: Mark Lord <[EMAIL PROTECTED]>
> > >> Date : 2007-12-02 04:23
> > >> References   : http://lkml.org/lkml/2007/12/1/141
> > >>http://bugzilla.kernel.org/show_bug.cgi?id=9489
> > >> Handled-By   : Arjan van de Ven <[EMAIL PROTECTED]>
> > >>
> > >
> > > I wonder if it's just a babbling IRQ on resume, before the driver
> > > has run it's resume code or something ?
> > 
> > i've read the discussions, and i cannot see it analyzed anywhere
> > _what_ causes the wakeups. And how are these wakeups counted? Is this
> > based on powertop output:
> > 
> >  Wakeups-from-idle per second : 20.4 interval: 1.8s
> > 
> > ? Somewhere i saw it mentioned that "the CPU throws out of C mode".
> > What does that mean - does it mean we try to idle again and again,
> > but we immediately return from C mode - while this all looks like
> > "idle" time to the scheduler (so 'top' will show lots of idle time),
> > but the ACPI wakeup counters are going up like mad? What
> > is /proc/interrupts doing when this happens - is any of the irq
> > sources going upwards?
> > 
> 
> what seems to happen (and this is based on seeing this on my own devel 
> laptop, as well
> as several other reports; Mark is by far not the only one) is something 
> hardware
> related, it's been seen on lots of different kernel versions.
> 
> It seems to mostly (but not 100%) happen with TI cardbus bridges, where for 
> some reason,
> once the yenta driver is loaded (unloading it later makes no difference), 
> once in a while
> we get into a mode where the CPU always immediately goes out of the C-state 
> again.
> On a hardware level, there are only a few things that cause a CPU to exit a 
> C-state,
> and one of them is a pending interrupt of some kind, which is the most likely 
> thing going on here;
> some device or apic being stuck with interrupt high, but somehow the CPU 
> isn't actually
> seeing the interrupt itself (or has it blocked!)
> 
> To call this a 2.6.24 regression is a mistake (as I've said before), it's not 
> new to .24
> by any means.

Thanks for the explanation, I'm removing this from the regressions list, then.

Greetings,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM: Acquire device locks on suspend

[Rafael J. Wysocki]

On Sunday, 6 of January 2008, Alan Stern wrote:
> On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> 
> > > Still, shouldn't we fail the removal of the device apart from giving the
> > > warning?
> > 
> > Actually, having thought about it a bit more, I don't see the point in
> > preventing the removal of the device from the list in device_pm_remove() if
> > we allow all of the operations in device_del() preceding it to be performed.
> 
> That's not the issue.  We _don't_ allow all of the operations in 
> device_del() preceding the call to device_pm_remove().  In particular, 
> the call to the device's driver's remove method will deadlock because 
> device_release_driver() always has to acquire dev->sem.
> 
> > Shouldn't we just take pm_sleep_rwsem in device_del() upfront and block on 
> > that
> > if locked?
> 
> No -- the whole idea here is to print an error message in the system
> log if a driver's resume method tries to call device_del().  Deadlock 
> is unavoidable in this case, but at least we'll know which driver is 
> guilty.

Still, if we do that, we won't need to acquire dev->sem in device_pm_remove()
any more.  Apart from this, by acqiring pm_sleep_rwsem for reading in
device_del() we can prevent a suspend from starting while the device is being
removed.

Consider, for example, the scenario possible with the $subject patch:
- device_del() starts and notices pm_sleep_rwsem unlocked, so the warning is
  not printed
- it proceeds and everything before device_pm_remove() succeeds
- now, device_suspend() is called and locks dev->sem
- device_del() calls device_pm_remove() and blocks on that with the device
  partialy removed
I think we should prevent this from happening.

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] PM: Acquire device locks on suspend

[Alan Stern]

On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:

> Still, our present approach doesn't seem to be correct overall.  For example,
> I think we should prevent a suspend from happening while a device is being
> removed.

We could, however I don't think it's dangerous to allow it.  The two
problems to avoid are (1) messing up the PM device list pointers, and
(2) calling a driver's suspend/resume methods while its remove method
is running.  (1) is handled by the pm_list_mutex and (2) is handled by
locking dev->sem.

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: [linux-usb-devel] [FEATURE REQUEST] Transparent hot plugging of root file system on portable storage devices.

[Alan Stern]

On Sun, 6 Jan 2008, Oliver Neukum wrote:

> Am Sonntag 06 Januar 2008 schrieb Alan Stern:
> > What about people who want to suspend to RAM instead of hibernating and
> > _do_ want to unplug the USB device containing their root filesystem
> > while the machine is asleep?  In this case we will _know_ that the
> > power session has been interrupted, but USB Persist won't activate
> > because the host controller never lost power.
> 
> Would it be hard to force the persist feature on for a replugged device?

Right now the persist feature is enabled by a per-device boolean flag.  
In theory the flag could accept 3 values: off, on if power was lost,
or on for any resume transition.  This would not be a hard change.

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] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"

[Adrian Bunk]

On Sun, Jan 06, 2008 at 10:08:13PM +0100, Willy Tarreau wrote:
> On Sun, Jan 06, 2008 at 09:58:02PM +0200, Adrian Bunk wrote:
> > On Sun, Jan 06, 2008 at 08:10:44PM +0100, Willy Tarreau wrote:
> > > I, as an end user of ntpd, have been harrassed to use it to get an
> > > ntp bug reported "because by mail it would get lost". What complicated
> > 
> > Noone knows how many thousand bug reports have never reached lkml 
> > since majordomo silently dropped them.
> 
> Since none of my mails has been dropped yet, I think that the false
> positives are rather rare. Yes, sometimes someone complains about a
> mail getting repeatedly killed. But that's not *that* much frequent
> IMO and people are already used to re-post when mailing their friends,
> coworkers or customers. It's no different here. Still, I agree that
> it is a problem.

If someone works in a company where the default MUA setting is to also 
attach the text as HTML and to add a vCard to all emails people might
try once to submit their bug report, not notice that it didn't arrive
on the list, and then simply give up.

> > This is the price for having lkml relatively spam-free.
> 
> yes and I think it works fairly well.
> 
> > > an interface it is when you don't know it ! I remember I wanted to
> > > attach a patch and it didn't even get through the first time. I did
> > > it wrong. Blame me if you want, but an interface which need training
> > > for proper use is certainly not for casual end users.
> > 
> > What exactly is the problem with attaching files?
> > What is "it didn't even get through the first time" exactly?
> 
> Well, it's quite old in my memories, it may be 2 years ago. IIRC, when
> I wanted to attach files, I got brought to another page for this, and
> once done there was some confusing indication about how to complete the
> filing or get back to terminate the report. Sorry for not being much
> precise on this one, it's too far ago.

Currently the page for attaching a file has a "Submit" button.

> > > Also, it's very annoying to have to create an account somewhere, leaving
> > > there one of the passwords you use on many other sites, just to help a
> > > random developer fix a bug in his code. You quickly wonder if someone
> > > else will report it and have more patience.
> > 
> > If you already lack patience at this point,
> 
> Well, it took me 2 minutes to send my patch to the maintainer by then,
> he very politely told me that the only way was through bugzilla, and
> then it took me half an hour if not more to create a bugzilla account,
> find how to use it, attach the files and put a description in a text-area.

People reporting bugs together with a patch to fix it are not the usual 
case but an exception.

> Also, I remember that the ongoing mail exchanges through bugzilla
> systematically removed the mail history, which made it very hard to
> follow a discussion, because all mails I received were almost single-lined
> looking like "how did that happen ?" or "in what circumstances ?" without
> any history... Maybe this is configurable though.

This depends on how people answer in Bugzilla.

But an advantage of Bugzilla is that each email contains a link to the 
Bugzilla bug containing all discussions in the bug.

> > would you be willing to 
> > bisect which requires more than a dozen kernel recompiles and reboots?
> 
> Certainly not! But I would like kernel people to become less egocentric
> and understand that what they routinely do all the day appears very
> complicated and time-consuming to many users, and that by imposing them
> complex and/or costly methods to report bugs, they filter a lot of
> reports out. Sure, there are still a bunch of them doing everything
> up to and including the git bisects. But what percentage ?

If you report a regression in the kernel and are not willing to bisect 
the probability of the bug being resolved becomes _much_ smaller.

Partially due to this requiring much more developer time, but also 
partially due to the fact that many regressions are undebuggable without 
a bisection.

> People who encounter problems at work will not do that to start with,
> because they cannot delay all their work to spend half a day building
> kernels when their boss or customers are waiting for their work. Others
> will report the problems they encounter at a customer's and will not
> even be able to git-bisect because the customer's mail server is not
> like a notebook they have everywhere with them and can reboot at will.
> Some of them are more free of their time and will probably enjoy the
> experience, but they are a minority IMHO.

People tend to report bugs if and only they have no other choice (like 
some workaround).

So when they report a bug they really need a fix for their problem.

And have you ever worked in a company that pays a seven digit amount of 
Euros each year to Oracle for licences and support for their database?
I have. It's not that spending some man days on debugging or working 
around 

Re: 2.6.24-rc6-git12: Reported regressions from 2.6.23

[Arjan van de Ven]

On Sun, 6 Jan 2008 10:55:01 +0100
Ingo Molnar <[EMAIL PROTECTED]> wrote:

> 
> * Mark Lord <[EMAIL PROTECTED]> wrote:
> 
> > Rafael J. Wysocki wrote:
> >> This message contains a list of some regressions from 2.6.23
> >> reported since 2.6.24-rc1 was released, for which there are no
> >> fixes in the mainline I know of.  If any of them have been fixed
> >> already, please let me know.
> > ..
> >> Subject: 2+ wake-ups/second in 2.6.24
> >> Submitter  : Mark Lord <[EMAIL PROTECTED]>
> >> Date   : 2007-12-02 04:23
> >> References : http://lkml.org/lkml/2007/12/1/141
> >>  http://bugzilla.kernel.org/show_bug.cgi?id=9489
> >> Handled-By : Arjan van de Ven <[EMAIL PROTECTED]>
> >>
> >
> > I wonder if it's just a babbling IRQ on resume, before the driver
> > has run it's resume code or something ?
> 
> i've read the discussions, and i cannot see it analyzed anywhere
> _what_ causes the wakeups. And how are these wakeups counted? Is this
> based on powertop output:
> 
>  Wakeups-from-idle per second : 20.4 interval: 1.8s
> 
> ? Somewhere i saw it mentioned that "the CPU throws out of C mode".
> What does that mean - does it mean we try to idle again and again,
> but we immediately return from C mode - while this all looks like
> "idle" time to the scheduler (so 'top' will show lots of idle time),
> but the ACPI wakeup counters are going up like mad? What
> is /proc/interrupts doing when this happens - is any of the irq
> sources going upwards?
> 

what seems to happen (and this is based on seeing this on my own devel laptop, 
as well
as several other reports; Mark is by far not the only one) is something hardware
related, it's been seen on lots of different kernel versions.

It seems to mostly (but not 100%) happen with TI cardbus bridges, where for 
some reason,
once the yenta driver is loaded (unloading it later makes no difference), once 
in a while
we get into a mode where the CPU always immediately goes out of the C-state 
again.
On a hardware level, there are only a few things that cause a CPU to exit a 
C-state,
and one of them is a pending interrupt of some kind, which is the most likely 
thing going on here;
some device or apic being stuck with interrupt high, but somehow the CPU isn't 
actually
seeing the interrupt itself (or has it blocked!)

To call this a 2.6.24 regression is a mistake (as I've said before), it's not 
new to .24
by any means.

-- 
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: [PATCH] PM: Acquire device locks on suspend

[Rafael J. Wysocki]

On Sunday, 6 of January 2008, Alan Stern wrote:
> On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> 
> > On Sunday, 6 of January 2008, Alan Stern wrote:
> 
> > Still, shouldn't we fail the removal of the device apart from giving the
> > warning?
> 
> We can't.  device_del() can't fail -- it returns void.  Besides, how 
> can a driver hope to deal with an unregistration failure?

Well, right.

Still, our present approach doesn't seem to be correct overall.  For example,
I think we should prevent a suspend from happening while a device is being
removed.

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] PM: Acquire device locks on suspend

[Alan Stern]

On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:

> > Still, shouldn't we fail the removal of the device apart from giving the
> > warning?
> 
> Actually, having thought about it a bit more, I don't see the point in
> preventing the removal of the device from the list in device_pm_remove() if
> we allow all of the operations in device_del() preceding it to be performed.

That's not the issue.  We _don't_ allow all of the operations in 
device_del() preceding the call to device_pm_remove().  In particular, 
the call to the device's driver's remove method will deadlock because 
device_release_driver() always has to acquire dev->sem.

> Shouldn't we just take pm_sleep_rwsem in device_del() upfront and block on 
> that
> if locked?

No -- the whole idea here is to print an error message in the system
log if a driver's resume method tries to call device_del().  Deadlock 
is unavoidable in this case, but at least we'll know which driver is 
guilty.

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/

Linux 2.6.24-rc7

[Linus Torvalds]

It's been two weeks since rc6, but let's face it, with xmas and new years 
(and birthdays) in between, there hasn't actually been a lot of working 
days, and the incremental patch from -rc6 is about half the size of the 
one from rc5->rc6.

And I'll be charitable and claim it's because it's all stabilizing, and 
not because we've all been in a drunken stupor over the holidays.

The shortlog (appended below) is short and fairly informative. It's all 
really just a lot of rather small changes. The diffstat shows a lot of 
one- and two-liners, with just a few drivers (and the Cell platform) 
getting a bit more attention, and the SLUB support of /proc/slabinfo 
showing up as a blip.

Both git trees and tar-balls/patches pushed out, should be mirroring out 
within minutes. So there are no excuses to not try it out, and see if your 
favorite regression has been fixed.

Linus

---
Akos Maroy (1):
  fix: using joysticks in 32 bit applications on 64 bit systems

Al Viro (20):
  [TG3]: Endianness annotations.
  [TG3]: Endianness bugfix.
  typhoon: endianness bug in tx/rx byte counters
  typhoon: missing le32_to_cpu() in get_drvinfo
  typhoon: set_settings broken on big-endian
  typhoon: missed rx overruns on big-endian
  typhoon: memory corruptor on big-endian if TSO is enabled
  typhoon: trivial endianness annotations
  cycx: annotations and fixes (.24 fodder?)
  asix fixes
  yellowfin: annotations and fixes (.24 fodder?)
  dl2k endianness fixes (.24 fodder?)
  r8169 endianness
  rrunner: use offsetof() instead of homegrown insanity
  3c574 and 3c589 endianness fixes (.24?)
  fec_mpc52xx: write in C...
  3c359 endianness annotations and fixes
  uml: user of helper_wait() got missed when it got extra arguments
  restrict reading from /proc//maps to those who share ->mm or can 
ptrace pid
  [CASSINI]: Fix endianness bug.

Bartlomiej Zolnierkiewicz (10):
  ide-cd: fix SAMSUNG CD-ROM SCR-3231 quirk
  ide-cd: fix ACER/AOpen 24X CDROM speed reporting on big-endian machines
  ide-cd: use ide_cd_release() in ide_cd_probe()
  ide-cd: fix error messages in cdrom_{read,write}_check_ireason()
  ide-cd: add missing 'ireason' masking to cdrom_write_intr()
  ide-cd: fix error messages in cdrom_write_intr()
  ide-cd: add error message for DMA error to cdrom_read_intr()
  ide-cd: fix error message in cdrom_pc_intr()
  ide-cd: fix 'ireason' reporting in cdrom_pc_intr()
  cmd64x: fix hwif->chipset setup

Bob Nelson (1):
  [POWERPC] Oprofile: Remove dependency on spufs module

Borislav Petkov (1):
  MAINTAINERS: update ide-cd entry

Christoph Lameter (3):
  SLUB: Improve hackbench speed
  quicklists: do not release off node pages early
  Revert quicklist need->flush fix

Cory T. Tusar (1):
  tty: fix logic change introduced by wait_event_interruptible_timeout()

Cyrill Gorcunov (1):
  NET: mac80211: fix inappropriate memory freeing

Daniel Walker (1):
  ps3: vuart: fix error path locking

Dave Dillow (1):
  [SCSI] SRP transport: only remove our own entries

Dave Young (1):
  [BLUETOOTH]: put_device before device_del fix

David Brownell (1):
  pcmcia: remove pxa2xx_lubbock build warning

David Dillow (1):
  IB/srp: Fix list corruption/oops on module reload

David S. Miller (9):
  [NET]: Correct two mistaken skb_reset_mac_header() conversions.
  [SPARC64]: Fix OOPS in dma_sync_*_for_device()
  [SPARC64]: Implement pci_resource_to_user()
  [SERIAL]: Fix section mismatches in Sun serial console drivers.
  [CASSINI]: Revert 'dont touch page_count'.
  [CASSINI]: Program parent Intel31154 bridge when necessary.
  [CASSINI]: Set skb->truesize properly on receive packets.
  [CASSINI]: Fix two obvious NAPI bugs.
  [CASSINI]: Bump driver version and release date.

Denis V. Lunev (1):
  [IPV4]: OOPS with NETLINK_FIB_LOOKUP netlink socket

Eric Dumazet (1):
  [XFRM]: Do not define km_migrate() if !CONFIG_XFRM_MIGRATE

Eric Sandeen (3):
  ecryptfs: fix string overflow on long cipher names
  ecryptfs: fix unlocking in error paths
  ecryptfs: redo dget,mntget on dentry_open failure

Gavin McCullagh (1):
  [TCP]: use non-delayed ACK for congestion control RTT

Geoff Levand (1):
  [POWERPC] PS3: Fix printing of os-area magic numbers

Greg Kroah-Hartman (1):
  Modules: fix memory leak of module names

Gregory CLEMENT (1):
  MACB: clear transmit buffers properly on transmit underrun

Hans Verkuil (1):
  V4L/DVB (6876): ivtv: mspx4xx needs a longer i2c udelay

Hans-Jürgen Koch (1):
  UIO: Add a MAINTAINERS entry for Userspace I/O

Herbert Xu (2):
  [IPSEC]: Avoid undefined shift operation when testing algorithm ID
  [CRYPTO] padlock: Fix spurious ECB page fault

Ingo Molnar (4):
  sched: fix gcc warnings
  scsi: revert "[SCSI] Get rid of scsi_cmnd->done"
  hda_intel 

Re: [PATCH] PM: Acquire device locks on suspend

[Rafael J. Wysocki]

On Sunday, 6 of January 2008, Rafael J. Wysocki wrote:
> On Sunday, 6 of January 2008, Rafael J. Wysocki wrote:
> > On Sunday, 6 of January 2008, Alan Stern wrote:
> > > On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:
> > > 
> > > > > If you can figure out a way to disable the warning in device_del() 
> > > > > for 
> > > > > just the one device being unregistered by 
> > > > > device_pm_destroy_suspended(),
> > > > 
> > > > Something like this, perhaps:
> > > > 
> > > > @@ -905,6 +915,18 @@ void device_del(struct device * dev)
> > > > struct device * parent = dev->parent;
> > > > struct class_interface *class_intf;
> > > >  
> > > > +   if (down_trylock(>sem)) {
> > > > +   if (pm_sleep_lock()) {
> > > > +   dev_warn(dev, "Illegal %s during suspend\n",
> > > > +   __FUNCTION__);
> > > > +   dump_stack();
> > > > +   } else {
> > > > +   pm_sleep_unlock();
> > > > +   }
> > > > +   } else {
> > > > +   up(>sem);
> > > > +   }
> > > > +
> > > > if (parent)
> > > > klist_del(>knode_parent);
> > > > if (MAJOR(dev->devt))
> > > 
> > > Bizarre, but it should work.
> > 
> > OK
> > 
> > Still, shouldn't we fail the removal of the device apart from giving the
> > warning?
> 
> Actually, having thought about it a bit more, I don't see the point in
> preventing the removal of the device from the list in device_pm_remove() if
> we allow all of the operations in device_del() preceding it to be performed.
> 
> Shouldn't we just take pm_sleep_rwsem in device_del() upfront and block on 
> that
> if locked?

Ugh, the $subject patch looks like a city of races.  I'm struggling to close
them all, but it's getting complicated.

I'll post the result in a new thread.

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 1/3] power_supply: add few more values and props

[Dmitry]

Hi,

2008/1/6, Anton Vorontsov <[EMAIL PROTECTED]>:
> On Sun, Jan 06, 2008 at 03:27:18PM +0300, Dmitry Baryshkov wrote:
> > Add LiMn (one of the most common for small non-rechargable batteries)i
> > battery technology and voltage_min/_max properties support.
> >
> > Signed-off-by: Dmitry Baryshkov <[EMAIL PROTECTED]>
>
> Much thanks, all patches look good to me. Few questions about
> this one though.
>
> > diff --git a/drivers/power/power_supply_sysfs.c 
> > b/drivers/power/power_supply_sysfs.c
> > index 249f61b..45d2f95 100644
> > --- a/drivers/power/power_supply_sysfs.c
> > +++ b/drivers/power/power_supply_sysfs.c
> > @@ -46,7 +46,8 @@ static ssize_t power_supply_show_property(struct device 
> > *dev,
> >   "Unspecified failure"
> >   };
> >   static char *technology_text[] = {
> > - "Unknown", "NiMH", "Li-ion", "Li-poly", "LiFe", "NiCd"
> > + "Unknown", "NiMH", "Li-ion", "Li-poly", "LiFe", "NiCd",
> > + "LiMn"
> >   };
> >   static char *capacity_level_text[] = {
> >   "Unknown", "Critical", "Low", "Normal", "High", "Full"
> > @@ -88,6 +89,8 @@ static struct device_attribute power_supply_attrs[] = {
> >   POWER_SUPPLY_ATTR(present),
> >   POWER_SUPPLY_ATTR(online),
> >   POWER_SUPPLY_ATTR(technology),
> > + POWER_SUPPLY_ATTR(voltage_max),
> > + POWER_SUPPLY_ATTR(voltage_min),
>
> I'd suggest keep Documentation/power_supply_class.txt in sync
> wrt new properties, to distinct their meanings and usage.
>
> I assume you're using these new properties for non-rechargeable
> LiMn batteries. So, why new properties, aren't voltage_*_design
> ones suits that purpose? If battery is non-rechargeable it is
> having only design values, no?

No, I used it for the battery driver for Sharp Zaurus SL-6000 (tosa).
It's connected via simple ADC so I can get only voltages. I don't know
max_design value for the battery, but I have 'FULL' signal which I use
to detect 'voltage_max' and use it for power estimations.

> >   POWER_SUPPLY_ATTR(voltage_max_design),
> >   POWER_SUPPLY_ATTR(voltage_min_design),
> >   POWER_SUPPLY_ATTR(voltage_now),
> > diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
> > index 606c095..cdbc5b8 100644
> > --- a/include/linux/power_supply.h
> > +++ b/include/linux/power_supply.h
> > @@ -54,6 +54,7 @@ enum {
> >   POWER_SUPPLY_TECHNOLOGY_LIPO,
> >   POWER_SUPPLY_TECHNOLOGY_LiFe,
> >   POWER_SUPPLY_TECHNOLOGY_NiCd,
> > + POWER_SUPPLY_TECHNOLOGY_LiMn,
> >  };
> >
> >  enum {
> > @@ -72,6 +73,8 @@ enum power_supply_property {
> >   POWER_SUPPLY_PROP_PRESENT,
> >   POWER_SUPPLY_PROP_ONLINE,
> >   POWER_SUPPLY_PROP_TECHNOLOGY,
> > + POWER_SUPPLY_PROP_VOLTAGE_MAX,
> > + POWER_SUPPLY_PROP_VOLTAGE_MIN,
> >   POWER_SUPPLY_PROP_VOLTAGE_MAX_DESIGN,
> >   POWER_SUPPLY_PROP_VOLTAGE_MIN_DESIGN,
> >   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>
>
> Thanks,
>
> --
> Anton Vorontsov
> email: [EMAIL PROTECTED]
> backup email: [EMAIL PROTECTED]
> irc://irc.freenode.net/bd2
>


-- 
With best wishes
Dmitry
--
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] PM: Acquire device locks on suspend

[Alan Stern]

On Sun, 6 Jan 2008, Rafael J. Wysocki wrote:

> On Sunday, 6 of January 2008, Alan Stern wrote:

> Still, shouldn't we fail the removal of the device apart from giving the
> warning?

We can't.  device_del() can't fail -- it returns void.  Besides, how 
can a driver hope to deal with an unregistration failure?

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: translations (Re: Kbuild update)

[Sam Ravnborg]

> 
> Also, future of the linux codebase with Chinese comments in C or in
> ASM is kind of wired nightmare. Those, who cannot read actual source
> code (i.e. C) will not go too far.
$subject is purely about the kernel configuration - if that was not clear.

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/