Re: [BK] upgrade will be needed

[Anton Altaparmakov]

On Fri, 18 Feb 2005, Dmitry Torokhov wrote:
> On Fri, 18 Feb 2005 23:18:19 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> > On Fri, Feb 18, 2005 at 09:34:47PM +, Anton Altaparmakov wrote:
> > > On Fri, 18 Feb 2005, David S. Miller wrote:
> > > > On Fri, 18 Feb 2005 21:45:55 +0100
> > > > "d.c" <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > 2) And more important, *nobody* works against "linus' bk head".
> > > >
> > > > I do, %100 exclusively, for all the networking and sparc
> > > > development.
> > > >
> > > > I never work against the -mm tree.
> > >
> > > Dito.  All my kernel development happens against Linus' bk head and I
> > > almost never work against -mm tree.
> > 
> > Same here, I work on Linus's bk head and all the changes go to -mm for
> > testing first, then to Linus for inclusion.
> 
> I guess there is a perception that developers/maintainers are working
> against -mm because all maintainers trees are automatically pulled by
> Andrew. And when someone doing stuff on somewhat regular basis he/she
> tends to do it against maintainer's tree thus making patches suitable
> for -mm as well.

Ah yes, that is possible.  However at least for me I work against Linus' 
BK head, but my developmental NTFS tree is pulled by Andrew for -mm.  When 
I consider a release ready I request inclusion into Linus' tree.  For 
non-ntfs stuff I generally send to Andrew for -mm (like the loop driver 
fallback to file write patch I sent him a few days ago) and he can merge 
it into mainline later.

I imagine it is simillar for most maintainers trees.

Best regards,

Anton
-- 
Anton Altaparmakov  (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Should kirqd work on HT?

[Jeff Garzik]

Nigel Cunningham wrote:
Hi all.
I've noticed this problem for a while, but only now decided to ask.
Interrupt balancing doesn't do anything on my system.
   CPU0   CPU1
  0:   31931808  0IO-APIC-edge  timer
  1:  76595  0IO-APIC-edge  i8042
  8:  1  0IO-APIC-edge  rtc
  9:  1  0   IO-APIC-level  acpi
 14:122  1IO-APIC-edge  ide0
 16:4074456  0   IO-APIC-level  uhci_hcd, uhci_hcd, [EMAIL 
PROTECTED]:1:0:0
 17:4295132  0   IO-APIC-level  Intel ICH5
 18:2070933  0   IO-APIC-level  libata, uhci_hcd, eth0
 19: 887311  0   IO-APIC-level  uhci_hcd
 22: 572530  0   IO-APIC-level  ath0
NMI:   31931749   31931636 (I've since disabled the nmi_watchdog)
LOC:   31931252   31931251
ERR:  0
MIS:  0
I enabled the debugging and found that it doesn't think it's worth the
effort. Is that correct? Not a complaint, just curious!
What are the results of running irqbalanced?
Jeff

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

Re: 2.6: drivers/input/power.c is never built

[Dmitry Torokhov]

Hi Nigel,

On Saturday 19 February 2005 01:28, Nigel Cunningham wrote:
> Hi.
> 
> On Sat, 2005-02-19 at 13:58, Dmitry Torokhov wrote: 
> > On Friday 18 February 2005 18:31, Pavel Machek wrote:
> > > I believe power and suspend keys should definitely go through
> > > input. I'm not that sure about battery... Lid is somewhere in
> > > between...
> > I think we need a generic way of delivering system status changes to
> > userspace. Something like acpid but bigger than that, something not
> > so heavily oriented on ACPI. I wonder if that kernel connector patch
> > should be looked at.
> 
> Absolutely. I've been thinking about this too, but haven't yet found the
> time to put it down on paper/email yet.
> 
> I think we need a very generic system by which changes in anything 
> remotely impacting on power management (kernelspace or userspace,
> including ACPI, UPS drivers, keyboard handlers, devices etc) can notify
> events to a userspace daemon. This daemon can act in accordance with
> user specified policies (changeable on the fly) to implement system
> level state changes (suspend to ram/disk, shutdown etc), run time power
> management

Yep.

> (shutdown a USB hub that just signalled the removal of its 
> last client), logging and so on.

This last example - I don't think the daemon should micro-manage, I think
USB bus should shutdown the hub automatically without involving userspace.

> In some cases, it might set policy but 
> not be actively informed of the details of the application of that
> policy (we don't feedback loops with a process leaving C3 to notify that
> it's entering C3!).
> 
> This implies, of course, not just a generic way of notifying changes,
> but a generic way of implementing policy.
> 
> Sound too ambitious, or am I thinking your thoughts after you?
> 

Well, at this moment I only care about delivering the data to userspace,
the rest (daemon, policies) is although interesting is out of scope for
me.

-- 
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] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

[Lee Revell]

On Sat, 2005-02-19 at 00:08 -0500, Lee Revell wrote:
> On Fri, 2005-02-04 at 11:03 +0100, Ingo Molnar wrote:
> >   http://redhat.com/~mingo/realtime-preempt/
> > 
> 
> Testing on an all SCSI 1.3Ghz Athlon XP system, I am seeing very long
> latencies in the journalling code with 2.6.11-rc4-RT-V0.7.39-02.

If I mount all filesystems with 'data=writeback', it works perfectly.  I
can run 'dbench 64', JACK with Hydrogen at 32 frames and have been
unable to produce a single xrun.  The maximum wakeup latency I have seen
is 139us.  With 'data=ordered', just launching a web browser can produce
an xrun.

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Should kirqd work on HT?

[Kwijibo]

My guess is that irqbalance is not running.
Nigel Cunningham wrote:
Hi all.
I've noticed this problem for a while, but only now decided to ask.
Interrupt balancing doesn't do anything on my system.
  CPU0   CPU1
 0:   31931808  0IO-APIC-edge  timer
 1:  76595  0IO-APIC-edge  i8042
 8:  1  0IO-APIC-edge  rtc
 9:  1  0   IO-APIC-level  acpi
14:122  1IO-APIC-edge  ide0
16:4074456  0   IO-APIC-level  uhci_hcd, uhci_hcd, [EMAIL 
PROTECTED]:1:0:0
17:4295132  0   IO-APIC-level  Intel ICH5
18:2070933  0   IO-APIC-level  libata, uhci_hcd, eth0
19: 887311  0   IO-APIC-level  uhci_hcd
22: 572530  0   IO-APIC-level  ath0
NMI:   31931749   31931636 (I've since disabled the nmi_watchdog)
LOC:   31931252   31931251
ERR:  0
MIS:  0
I enabled the debugging and found that it doesn't think it's worth the
effort. Is that correct? Not a complaint, just curious!
Regards,
Nigel
 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ohci1394: dma_pool_destroy while in_atomic() && irqs_disabled()

[Jody McIntyre]

On Fri, Feb 18, 2005 at 10:42:46AM -0500, Parag Warudkar wrote:
> On Friday 18 February 2005 10:32 am, Dan Dennedy wrote:
> > I have tested the patches (including for allocation), and it is working
> > great, but should I only commit for now the deallocation patch? Hmm..
> > which is worse the debug or the 200K waste?
> Thanks for following it up.
> 
> IMHO, we should commit both patches for now since we don't have an 
> alternative 
> solution yet. 

I disagree because the impact of this bug is small.  How often do you start
an ISO receive?  If you think it needs to be fixed urgently, please
explain why - maybe I'm just missing somethnig.

> Jody - Is the 200K waste for sure or do you want me to verify it by some 
> means? ( Reason I am asking is firstly, Dave Brownell was quite sure it 
> wasn't that costly and secondly, I am hoping it isn't.. ;)

I'm not sure, but I looked through the code and it seems to allocate:
 - 16 buffers of 2x PAGE_SIZE (= 131072 on i386)
 - 16 buffers of PAGE_SIZE (= 65536 on i386)
 - various other smaller structures.

I'm not sure how to actually _measure_ how much memory this is using.
slabinfo isn't useful, at least on my system, because the 1394
allocations get lost in the noise of other activity.

If you really need this fixed quickly, I'll find some time this weekend
to examine the locks.  In particular, I'm not sure what host_info_lock
protects or why it needs to be held in so many places with irqs disabled.

Jody

> 
> Parag

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

Should kirqd work on HT?

[Nigel Cunningham]

Hi all.

I've noticed this problem for a while, but only now decided to ask.
Interrupt balancing doesn't do anything on my system.

   CPU0   CPU1
  0:   31931808  0IO-APIC-edge  timer
  1:  76595  0IO-APIC-edge  i8042
  8:  1  0IO-APIC-edge  rtc
  9:  1  0   IO-APIC-level  acpi
 14:122  1IO-APIC-edge  ide0
 16:4074456  0   IO-APIC-level  uhci_hcd, uhci_hcd, [EMAIL 
PROTECTED]:1:0:0
 17:4295132  0   IO-APIC-level  Intel ICH5
 18:2070933  0   IO-APIC-level  libata, uhci_hcd, eth0
 19: 887311  0   IO-APIC-level  uhci_hcd
 22: 572530  0   IO-APIC-level  ath0
NMI:   31931749   31931636 (I've since disabled the nmi_watchdog)
LOC:   31931252   31931251
ERR:  0
MIS:  0

I enabled the debugging and found that it doesn't think it's worth the
effort. Is that correct? Not a complaint, just curious!

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028  Mob: +61 (417) 100 574

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: drivers/input/power.c is never built

[Nigel Cunningham]

Hi.

On Sat, 2005-02-19 at 13:58, Dmitry Torokhov wrote: 
> On Friday 18 February 2005 18:31, Pavel Machek wrote:
> > I believe power and suspend keys should definitely go through
> > input. I'm not that sure about battery... Lid is somewhere in
> > between...
> I think we need a generic way of delivering system status changes to
> userspace. Something like acpid but bigger than that, something not
> so heavily oriented on ACPI. I wonder if that kernel connector patch
> should be looked at.

Absolutely. I've been thinking about this too, but haven't yet found the
time to put it down on paper/email yet.

I think we need a very generic system by which changes in anything 
remotely impacting on power management (kernelspace or userspace,
including ACPI, UPS drivers, keyboard handlers, devices etc) can notify
events to a userspace daemon. This daemon can act in accordance with
user specified policies (changeable on the fly) to implement system
level state changes (suspend to ram/disk, shutdown etc), run time power
management (shutdown a USB hub that just signalled the removal of its
last client), logging and so on. In some cases, it might set policy but
not be actively informed of the details of the application of that
policy (we don't feedback loops with a process leaving C3 to notify that
it's entering C3!).

This implies, of course, not just a generic way of notifying changes,
but a generic way of implementing policy.

Sound too ambitious, or am I thinking your thoughts after you?

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028  Mob: +61 (417) 100 574

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Dynamically allocated pageflags.

[Nigel Cunningham]

Hi.

On Sat, 2005-02-19 at 16:51, Dave Hansen wrote:
> On Sat, 2005-02-19 at 14:35 +1100, Nigel Cunningham wrote:
> > On Sat, 2005-02-19 at 14:02, Dave Hansen wrote:
> > > One issue is that it doesn't work with DISCONTIGMEM (or the upcoming
> > > sparsemem).  max_mapnr doesn't exist on those systems, and on the really
> > > discontiguous ones, you might be allocating very large areas with very
> > > sparse maps.
> > 
> > :> Am I right in thinking that just requires something similar, done
> > per-zone? If that's the case, I'll happily modify the code to suit. I
> > should support discontig anyway in suspend.
> 
> The mem_maps are per-pgdat or per-node with discontig, but I have a
> patch in the pipeline to take them out of there and make one for every
> 128MB or 256MB, etc... area of memory (for memory hotplug).  So, hanging
> them off the pgdat or zone won't even work in that case, because even
> the struct zone can have pretty sparse memory inside of it.  I *think*
> the table is the only way to go.  But, that can wait until Monday. :)

Okay. I'll just wait :>

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028  Mob: +61 (417) 100 574

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Jim Crilly]

Helge Hafting wrote:

Well, this will depend on your email server (pop? imap? other?)
being up.  Is it local on your machine, or external?  Either way,
being able to launch an email client (or some "new mail" notification
app) shouldn't be a problem.  It will simply not notice new mail until
the mail service comes up - but it won't fail.  It'll be as if the
mail arrived a little later.
Sure it can fail, when you start it up it'll most likely fail to login to 
the mail server, whether it's local or not, if certain services aren't 
already started. If you're using local direct access via maildir or mbox, 
that'll work fine but most people access remote server for their mail.

Helge Hafting
Jim.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Dynamically allocated pageflags.

[Dave Hansen]

On Sat, 2005-02-19 at 14:35 +1100, Nigel Cunningham wrote:
> On Sat, 2005-02-19 at 14:02, Dave Hansen wrote:
> > One issue is that it doesn't work with DISCONTIGMEM (or the upcoming
> > sparsemem).  max_mapnr doesn't exist on those systems, and on the really
> > discontiguous ones, you might be allocating very large areas with very
> > sparse maps.
> 
> :> Am I right in thinking that just requires something similar, done
> per-zone? If that's the case, I'll happily modify the code to suit. I
> should support discontig anyway in suspend.

The mem_maps are per-pgdat or per-node with discontig, but I have a
patch in the pipeline to take them out of there and make one for every
128MB or 256MB, etc... area of memory (for memory hotplug).  So, hanging
them off the pgdat or zone won't even work in that case, because even
the struct zone can have pretty sparse memory inside of it.  I *think*
the table is the only way to go.  But, that can wait until Monday. :)

-- 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: [OT] speeding boot process (was Re: [ANNOUNCE] hotplug-ng 001 release)

[Jim Crilly]

Wouldn't it be sufficient to have an applet in your UI (or dialog,
depending on your preference), which communicates with init and displays
the final initialization steps?  Don't check your email until it says it has
started the services for email.
So now instead of watching the boot messages or bootsplash you want to watch 
an icon on the task bar? In both cases you're just sitting and waiting on 
things to start, so why is waiting in one place better than another?

--
Chris Larson - kergoth at handhelds dot org
Linux Software Systems Engineer - clarson at ti dot com
Core Developer/Architect - BitBake, OpenEmbedded, OpenZaurus
Jim.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: workqueue - process context

[Vicente Feito]

On Saturday 19 February 2005 04:57 am, you wrote:
> Vicente> I've been playing with workqueues, and I've found that
> Vicente> once I unload the module, if I don't call
> Vicente> destroy_workqueue(); then the workqueue I've created
> Vicente> stays in the process list, [my_wq], I don't know if
> Vicente> that's meant to be, or is it a bug, cause I believe there
> Vicente> can be two options in here:
>
> Vicente> 1) It's meant to be so you can unload your module and let
> Vicente> the works run some time after you're already gone, that
> Vicente> allows you to probe other modules or do whatever necesary
> Vicente> without the need to wait for the workqueue to be emtpy.
>
> Vicente> 2) It's a bug, cause the module allows to be unloaded,
> Vicente> destroying the structs but not removing the workqueue
> Vicente> from the process context.
>
> Not destroying its workqueue is a bug in the module just like any
> other resource leak.  It's analogous to a module allocating some
> memory with kmalloc() and not calling kfree() when it's unloaded.  If
> a module creates a workqueue, then it should call destroy_workqueue()
> when it's unloaded.
What if I need the module to be unloaded cause It's mutually exclusive with 
another module to be loaded, and I still need to run the works in a workqueue 
time before that happens? That's completely out of the picture?cause that 
might be useful.
>
> By the way, the module (or any code calling destroy_workqueue()) must
> make sure that it has race conditions that might result in work being
> submitted to the queue while it is being destroyed.
yes, I think flushing is enough, is it?

>
>  -R .
Vicente.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AHCI oops

[Jeff Garzik]

Justin Cormack wrote:
Have a new AHCI board to test and it oopses pretty quickly just with a few
reads simultaneously.
This should be fixed now, with
[EMAIL PROTECTED], 2005-01-28 22:29:02-05:00, [EMAIL PROTECTED]
  [PATCH] fix an oops in ata_to_sense_error
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.6.9 Use skb_padto() in drivers/net/8390.c

[Jeff Garzik]

Alan Cox wrote:
On Llu, 2005-01-10 at 02:41, Paul Gortmaker wrote:
Using rdtscl over the  area affected by the patch on the two variants for a
sample  of 234 small packets, I see an average of 4141 for using the
existing stack scratch area, and 4162 for using skb_padto.   That is a
difference of about 0.5%, which is significantly less than the typical
spread in the samples themselves.  To help give a relevant scale,  feeding
it a larger 1400 byte packet comes in at around 60,000 cycles on this
particular box.   Am I being optimistic to see this as good news -- meaning
that there is no longer a need for driver specific padto implementations,
whereas it looks like there was back when you did your tests? 

It means that padto has improved a lot (or the underlying allocators).
It also still means the patch makes the code slower and introduces
changes that have no benefit into the kernel, so while its good to see
its not relevant its still a pointless change.
So the verdict is to revert?
Jeff

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

Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01

[Lee Revell]

On Fri, 2005-02-04 at 11:03 +0100, Ingo Molnar wrote:
>   http://redhat.com/~mingo/realtime-preempt/
> 

Testing on an all SCSI 1.3Ghz Athlon XP system, I am seeing very long
latencies in the journalling code with 2.6.11-rc4-RT-V0.7.39-02.

preemption latency trace v1.1.4 on 2.6.11-rc4-RT-V0.7.39-02

 latency: 713 µs, #3455/3455, CPU#0 | (M:preempt VP:0, KP:1, SP:1 HP:1 #P:1)
-
| task: ksoftirqd/0-2 (uid:0 nice:-10 policy:0 rt_prio:0)
-

 _--=> CPU#
/ _-=> irqs-off
   | / _=> need-resched
   || / _---=> hardirq/softirq 
   ||| / _--=> preempt-depth   
    /
   | delay
   cmd pid | time  |   caller  
  \   /|   \   |   /
kjournal-2478  0dn.40µs!: <756f6a6b> (<6c616e72>)
kjournal-2478  0dn.40µs : __trace_start_sched_wakeup (try_to_wake_up)
kjournal-2478  0dn.30µs : preempt_schedule (try_to_wake_up)
kjournal-2478  0dn.30µs : try_to_wake_up <<...>-2> (69 73): 
kjournal-2478  0dn.20µs : preempt_schedule (try_to_wake_up)
kjournal-2478  0dn.20µs : wake_up_process (do_softirq)
kjournal-2478  0dn.11µs < (1)

The repeating pattern is 8 of these:

kjournal-2478  0.n.11µs : inverted_lock (journal_commit_transaction)
kjournal-2478  0.n.11µs : __journal_unfile_buffer 
(journal_commit_transaction)
kjournal-2478  0.n.11µs : journal_remove_journal_head 
(journal_commit_transaction)
kjournal-2478  0.n.11µs : __journal_remove_journal_head 
(journal_remove_journal_head)
kjournal-2478  0.n.11µs : __brelse (__journal_remove_journal_head)
kjournal-2478  0.n.11µs : journal_free_journal_head 
(journal_remove_journal_head)
kjournal-2478  0.n.12µs : kmem_cache_free (journal_free_journal_head)

and one of these:

kjournal-2478  0dn.19µs : cache_flusharray (kmem_cache_free)
kjournal-2478  0dn.29µs : free_block (cache_flusharray)
kjournal-2478  0dn.1   11µs : preempt_schedule (cache_flusharray)
kjournal-2478  0dn.1   11µs : memmove (cache_flusharray)
kjournal-2478  0dn.1   11µs : memcpy (memmove)

etc.  Finally:

kjournal-2478  0dn.1  704µs : cache_flusharray (kmem_cache_free)
kjournal-2478  0dn.2  704µs+: free_block (cache_flusharray)
kjournal-2478  0dn.1  707µs : preempt_schedule (cache_flusharray)
kjournal-2478  0dn.1  707µs : memmove (cache_flusharray)
kjournal-2478  0dn.1  707µs : memcpy (memmove)
kjournal-2478  0.n.1  708µs : inverted_lock (journal_commit_transaction)
kjournal-2478  0.n.1  708µs : __journal_unfile_buffer 
(journal_commit_transaction)
kjournal-2478  0.n.1  709µs : journal_remove_journal_head 
(journal_commit_transaction)
kjournal-2478  0.n.1  709µs : __journal_remove_journal_head 
(journal_remove_journal_head)
kjournal-2478  0.n.1  709µs : __brelse (__journal_remove_journal_head)
kjournal-2478  0.n.1  709µs : journal_free_journal_head 
(journal_remove_journal_head)
kjournal-2478  0.n.1  709µs : kmem_cache_free (journal_free_journal_head)
kjournal-2478  0.n..  710µs : preempt_schedule (journal_commit_transaction)
kjournal-2478  0dn..  710µs : __schedule (preempt_schedule)
kjournal-2478  0dn..  710µs : profile_hit (__schedule)
kjournal-2478  0dn.1  710µs : sched_clock (__schedule)
kjournal-2478  0dn.2  711µs : dequeue_task (__schedule)
kjournal-2478  0dn.2  711µs : recalc_task_prio (__schedule)
kjournal-2478  0dn.2  711µs : effective_prio (recalc_task_prio)
kjournal-2478  0dn.2  711µs : enqueue_task (__schedule)
   <...>-2 0d..2  712µs : __switch_to (__schedule)
   <...>-2 0d..2  712µs : __schedule  (73 69):
   <...>-2 0d..2  712µs : finish_task_switch (__schedule)
   <...>-2 0d..1  712µs : trace_stop_sched_switched (finish_task_switch)
   <...>-2 0d..1  712µs : trace_stop_sched_switched <<...>-2> (69 0):
   <...>-2 0d..1  713µs : trace_stop_sched_switched (finish_task_switch)

Lee

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: workqueue - process context

[Roland Dreier]

Vicente> What if I need the module to be unloaded cause It's
Vicente> mutually exclusive with another module to be loaded, and
Vicente> I still need to run the works in a workqueue time before
Vicente> that happens? That's completely out of the picture?cause
Vicente> that might be useful.

That doesn't sound like a good idea.  For one thing, how does the
second module get the workqueue pointer from the first module?  The
simplest solution would be for each module to create and destroy its
own workqueue.  However, if you really need a shared workqueue for
some reason, then have a simple third module that can remain loaded
and have it manage the workqueue for both of your other modules.

Roland> By the way, the module (or any code calling
Roland> destroy_workqueue()) must make sure that it has race
Roland> conditions that might result in work being submitted to
Roland> the queue while it is being destroyed.

Vicente> yes, I think flushing is enough, is it?

Usually, but you have to be extra-careful if you have any work
functions that might resubmit themselves.

 - Roland

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: workqueue - process context

[Vicente Feito]

On Saturday 19 February 2005 04:57 am, you wrote:
> Vicente> I've been playing with workqueues, and I've found that
> Vicente> once I unload the module, if I don't call
> Vicente> destroy_workqueue(); then the workqueue I've created
> Vicente> stays in the process list, [my_wq], I don't know if
> Vicente> that's meant to be, or is it a bug, cause I believe there
> Vicente> can be two options in here:
>
> Vicente> 1) It's meant to be so you can unload your module and let
> Vicente> the works run some time after you're already gone, that
> Vicente> allows you to probe other modules or do whatever necesary
> Vicente> without the need to wait for the workqueue to be emtpy.
>
> Vicente> 2) It's a bug, cause the module allows to be unloaded,
> Vicente> destroying the structs but not removing the workqueue
> Vicente> from the process context.
>
> Not destroying its workqueue is a bug in the module just like any
> other resource leak.  It's analogous to a module allocating some
> memory with kmalloc() and not calling kfree() when it's unloaded.  If
> a module creates a workqueue, then it should call destroy_workqueue()
> when it's unloaded.
What if I need the module to be unloaded cause It's mutually exclusive with 
another module to be loaded, and I still need to run the works in a workqueue 
time before that happens? That's completely out of the picture?cause that 
might be useful.
>
> By the way, the module (or any code calling destroy_workqueue()) must
> make sure that it has race conditions that might result in work being
> submitted to the queue while it is being destroyed.
yes, I think flushing is enough, is it?

>
>  -R .
Vicente.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: workqueue - process context

[Roland Dreier]

Vicente> I've been playing with workqueues, and I've found that
Vicente> once I unload the module, if I don't call
Vicente> destroy_workqueue(); then the workqueue I've created
Vicente> stays in the process list, [my_wq], I don't know if
Vicente> that's meant to be, or is it a bug, cause I believe there
Vicente> can be two options in here:

Vicente> 1) It's meant to be so you can unload your module and let
Vicente> the works run some time after you're already gone, that
Vicente> allows you to probe other modules or do whatever necesary
Vicente> without the need to wait for the workqueue to be emtpy.

Vicente> 2) It's a bug, cause the module allows to be unloaded,
Vicente> destroying the structs but not removing the workqueue
Vicente> from the process context.

Not destroying its workqueue is a bug in the module just like any
other resource leak.  It's analogous to a module allocating some
memory with kmalloc() and not calling kfree() when it's unloaded.  If
a module creates a workqueue, then it should call destroy_workqueue()
when it's unloaded.

By the way, the module (or any code calling destroy_workqueue()) must
make sure that it has race conditions that might result in work being
submitted to the queue while it is being destroyed.

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

workqueue - process context

[Vicente Feito]

I've been playing with workqueues, and I've found that once I unload the 
module, if I don't call destroy_workqueue(); then the workqueue I've created 
stays in the process list, [my_wq], I don't know if that's meant to be, or is 
it a bug, cause I believe there can be two options in here:

1) It's meant to be so you can unload your module and let the works run some 
time after you're already gone, that allows you to probe other modules or do 
whatever necesary without the need to wait for the workqueue to be emtpy.

2) It's a bug, cause the module allows to be unloaded, destroying the structs 
but not removing the workqueue from the process context.

Which one is it?I hope I'm being clear with my question.
I was about to try to find a solution to remove the queue but maybe it's meant 
to be, although not likely.

Vicente.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Sis760 chipset support

[Dave Jones]

On Fri, Feb 18, 2005 at 07:07:16PM +0100, Marc Cramdal wrote:
 > Hello,
 > 
 > I can't make agpgart working (even when trying the agp_try_unsupported) 
 > option. I have an AMD64 3000+ with a Sis760 chipset and agp doesn't seem to 
 > be supported : I only get this with dmesg : "Linux agpgart interface v0.100 
 > (c) Dave Jones". That's all...
 > 
 > So, is Sis760 chipset supported for agpgart under linux kernel ? if not, is 
 > there plan to be, tweaks to do (I even tried the Sis Chipset driver 
 > for !x86_64 by removing this entry in KConfig ... ) ?
 > 

amd64 should be using the amd64-agp driver, as your agpgart is on-cpu
on that platform.

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: [RFC][PATCH] Dynamically allocated pageflags.

[Nigel Cunningham]

Hi.

On Sat, 2005-02-19 at 14:02, Dave Hansen wrote:
> On Sat, 2005-02-19 at 13:43 +1100, Nigel Cunningham wrote:
> > For some time now, we've been running out of bits for pageflags.
> > 
> > In Suspend2, I need the functional equivalent of pageflags, but don't
> > need them when Suspend isn't running. One of the outcomes of the last
> > submission of Suspend2 for review was that I changed the format in which
> > that data is stored, creating something I call dynamically allocated
> > pageflags.
> > 
> > It's a simple idea: we tie together a bunch of order zero allocated
> > pages using a kmalloc'd list of poiinters to those pages, and store the
> > location of that kmalloc'd list in what's really an unsigned long **
> > (typedef'd). We also provide macros so that calls for setting and
> > clearing flags can look just like ordinary pageflag set/clear/test
> > invocations.
> > 
> > Helpers are also provided for allocating and freeing the maps.
> 
> I'm kicking myself because I thought about this 2 minutes after we
> talked on IRC.  

> One issue is that it doesn't work with DISCONTIGMEM (or the upcoming
> sparsemem).  max_mapnr doesn't exist on those systems, and on the really
> discontiguous ones, you might be allocating very large areas with very
> sparse maps.

:> Am I right in thinking that just requires something similar, done
per-zone? If that's the case, I'll happily modify the code to suit. I
should support discontig anyway in suspend.

> One thing that I've been thinking about for these things is something
> tree-based.  A 1 or 2-level tree, like pagetables should be fast enough,
> and handle the sparse and discontiguous layouts a little better than a
> flat one.  We could even do a flat bitmap for normal systems, and #ifdef
> in the table only when it's needed.  I can take a look at doing this
> next week.

Mmm. I've got enough on my plate at the mo, so I'll just wait to see
what you come up with.

Regards,

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028  Mob: +61 (417) 100 574

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Dynamically allocated pageflags.

[Dave Hansen]

On Sat, 2005-02-19 at 13:43 +1100, Nigel Cunningham wrote:
> For some time now, we've been running out of bits for pageflags.
> 
> In Suspend2, I need the functional equivalent of pageflags, but don't
> need them when Suspend isn't running. One of the outcomes of the last
> submission of Suspend2 for review was that I changed the format in which
> that data is stored, creating something I call dynamically allocated
> pageflags.
> 
> It's a simple idea: we tie together a bunch of order zero allocated
> pages using a kmalloc'd list of poiinters to those pages, and store the
> location of that kmalloc'd list in what's really an unsigned long **
> (typedef'd). We also provide macros so that calls for setting and
> clearing flags can look just like ordinary pageflag set/clear/test
> invocations.
> 
> Helpers are also provided for allocating and freeing the maps.

I'm kicking myself because I thought about this 2 minutes after we
talked on IRC.  

One issue is that it doesn't work with DISCONTIGMEM (or the upcoming
sparsemem).  max_mapnr doesn't exist on those systems, and on the really
discontiguous ones, you might be allocating very large areas with very
sparse maps.

One thing that I've been thinking about for these things is something
tree-based.  A 1 or 2-level tree, like pagetables should be fast enough,
and handle the sparse and discontiguous layouts a little better than a
flat one.  We could even do a flat bitmap for normal systems, and #ifdef
in the table only when it's needed.  I can take a look at doing this
next week.

-- 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: 2.6: drivers/input/power.c is never built

[Dmitry Torokhov]

On Friday 18 February 2005 18:31, Pavel Machek wrote:
> Hi!
> 
> > > What is the benefit of splitting the flow of information so?
> > 
> > It's split already. You get some from input (power and sleep keys on
> > keyboards, sound volume keys and display brightness on some notebooks),
> > some from ACPI events (power keys on notebooks and desktop cases, sound
> > volume, display brightness on other notebooks), some from /proc/acpi/*
> > (battery status, fan status), some from APM, from platform specific
> > devices, from hotplug, from userspace daemons (UPS status).
> > 
> > The question is how to unify it.
> > 
> > Using power.c to simply pass power/sleep keys to the ACPI event pipe
> > could get the input subsystem out of the loop at least. Maybe we could
> > even pass sound keys to it. 
> 
> I do not think passing sound keys through acpi is good idea. acpid
> does not know how to handle them, and X already know how to get them
> from input subsystem.

What X? I am not saying that sound events should go through acpid, but
why bringing X here? One may not even run X...

> 
> I believe power and suspend keys should definitely go through
> input. I'm not that sure about battery... Lid is somewhere in
> between...
>

I think we need a generic way of delivering system status changes to
userspace. Something like acpid but bigger than that, something not
so heavily oriented on ACPI. I wonder if that kernel connector patch
should be looked at.

-- 
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: I wrote a kernel tool for monitoring / web page

[Lee Revell]

On Sat, 2005-02-19 at 02:33 +0100, sylvanino b wrote:
> Sorry, it's meant to run on linux.
> Actually, patch provided is for linux 2.6.9 + kdb 4.4
> 

Cool program.  It has an annoying bug where every time you go to "Open
Log File", it starts you in your home directory again.  Otherwise it's a
nice utility.

I actually have a problem that this might help with.  The issue is that
the scheduler seems to treat Evolution as a CPU bound rather than an
event driven, I/O bound process.  The most obvious symptom is that a
real CPU bound activity like a kernel compile will cause navigating the
message list in Evolution to slow to a crawl.  Evolution is perfectly
usable when no other CPU hogs are running, or when the CPU hogs are
niced, so it's definitely a scheduler issue.

My understanding of Unix schedulers is that the basic idea is to
penalize CPU bound and reward I/O bound processes by giving the former
lower dynamic priority with longer timeslice and the latter high
priority with shorter timeslice.  I suspect the scheduler does not
handle interactive, event driven apps that also consume a lot of CPU due
to bloat very well.  These would seem to need high priority and long
timeslices, which would require the scheduler to distinguish a process
like a kernel compile that will continually exhaust its timeslice no
matter how long, and a process like evolution that if given a long
enough timeslice will finish rendering the message and go back to sleep.

Anyway, that's my hypothesis, I'll let you know what I find out.

Lee


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [BK] upgrade will be needed

[Horst von Brand]

"Sean" <[EMAIL PROTECTED]> said:

[...]

> Yeah,  I didn't mean to suggest that it be opened up to the public :o) 
> Just that the flow of information wouldn't all have to originate in bk to
> make it into head (ie. bk could pull changes from head too).

No problem. bk can happily import patches, which you can certainly get out
of any other SCM.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Dynamically allocated pageflags.

[Nigel Cunningham]

Hi all.

For some time now, we've been running out of bits for pageflags.

In Suspend2, I need the functional equivalent of pageflags, but don't
need them when Suspend isn't running. One of the outcomes of the last
submission of Suspend2 for review was that I changed the format in which
that data is stored, creating something I call dynamically allocated
pageflags.

It's a simple idea: we tie together a bunch of order zero allocated
pages using a kmalloc'd list of poiinters to those pages, and store the
location of that kmalloc'd list in what's really an unsigned long **
(typedef'd). We also provide macros so that calls for setting and
clearing flags can look just like ordinary pageflag set/clear/test
invocations.

Helpers are also provided for allocating and freeing the maps.

Speaking with Dave Hansen this morning on IRC prompted me to send this
ahead of the rest of Suspend2 (I hope to do another submission soon), so
that he (and perhaps others) can utilise it in the mean time. A couple
of obvious candidates for using these flags are the Nosave and
NoSaveFree flags.

I make no claim that the calculations are done in the most efficient
way; just that it works and is well tested.

For sample usage, see the example in dyn_pageflags.h.

Regards,

Nigel

diff -ruNp 992-dynamic-pageflags-old/include/linux/dyn_pageflags.h 
992-dynamic-pageflags-new/include/linux/dyn_pageflags.h
--- 992-dynamic-pageflags-old/include/linux/dyn_pageflags.h 1970-01-01 
10:00:00.0 +1000
+++ 992-dynamic-pageflags-new/include/linux/dyn_pageflags.h 2005-02-19 
13:11:31.0 +1100
@@ -0,0 +1,47 @@
+/*
+ * include/linux/dyn_pageflags.h
+ *
+ * Copyright (C) 2004-2005 Nigel Cunningham <[EMAIL PROTECTED]>
+ *
+ * This file is released under the GPLv2.
+ *
+ * It implements support for dynamically allocated bitmaps that are
+ * used for temporary or infrequently used pageflags, in lieu of
+ * bits in the struct page flags entry.
+ */
+
+#include 
+
+typedef unsigned long ** dyn_pageflags_t;
+
+#define BITNUMBER(page) (page_to_pfn(page))
+
+#define PAGEBIT(page) ((int) ((page_to_pfn(page))%(8 * sizeof(unsigned long
+
+#define BITS_PER_PAGE (PAGE_SIZE * 8)
+#define PAGES_PER_BITMAP ((max_mapnr + BITS_PER_PAGE - 1) / BITS_PER_PAGE)
+#define PAGENUMBER(page) (BITNUMBER(page) / BITS_PER_PAGE)
+
+#define PAGEINDEX(page) ((BITNUMBER(page) - (BITS_PER_PAGE * 
PAGENUMBER(page)))/(8*sizeof(unsigned long)))
+
+#define PAGE_UL_PTR(bitmap, pagenum) 
((bitmap[PAGENUMBER(pagenum)])+PAGEINDEX(pagenum))
+
+/* With the above macros defined, you can do...
+
+#define PageInUse(page)\
+   test_bit(PAGEBIT(page), PAGE_UL_PTR(in_use_map, page))
+#define SetPageInUse(page) \
+   set_bit(PAGEBIT(page), PAGE_UL_PTR(in_use_map, page))
+#define ClearPageInUse(page) \
+   clear_bit(PAGEBIT(page), PAGE_UL_PTR(in_use_map, page))
+*/
+
+extern void clear_dyn_pageflags(dyn_pageflags_t pagemap);
+extern int allocate_dyn_pageflags(dyn_pageflags_t *pagemap);
+extern int free_dyn_pageflags(dyn_pageflags_t *pagemap);
+
+/* Used by Suspend2 */
+extern void save_dyn_pageflags(dyn_pageflags_t pagemap);
+extern void load_dyn_pageflags(dyn_pageflags_t pagemap);
+void relocate_dyn_pageflags(dyn_pageflags_t *pagemap);
+int compare_dyn_pageflags(dyn_pageflags_t map1, dyn_pageflags_t map2);
diff -ruNp 992-dynamic-pageflags-old/lib/dyn_pageflags.c 
992-dynamic-pageflags-new/lib/dyn_pageflags.c
--- 992-dynamic-pageflags-old/lib/dyn_pageflags.c   1970-01-01 
10:00:00.0 +1000
+++ 992-dynamic-pageflags-new/lib/dyn_pageflags.c   2005-02-19 
13:11:31.0 +1100
@@ -0,0 +1,82 @@
+/*
+ * lib/dyn_pageflags.c
+ *
+ * Copyright (C) 2004-2005 Nigel Cunningham <[EMAIL PROTECTED]>
+ * 
+ * This file is released under the GPLv2.
+ *
+ * Routines for dynamically allocating and releasing bitmaps
+ * used as pseudo-pageflags.
+ *
+ * Arrays are not contiguous. The first sizeof(void *) bytes are
+ * the pointer to the next page in the bitmap. This allows us to
+ * work under low memory conditions where order 0 might be all
+ * that's available. In their original use (suspend2), it also
+ * lets us save the pages at suspend time, reload and relocate them
+ * as necessary at resume time without much effort.
+ */
+
+#include 
+#include 
+
+/* clear_map
+ *
+ * Description:Clear an array used to store local page flags.
+ * Arguments:  dyn_pageflags_t:The pagemap to be cleared.
+ */
+
+void clear_dyn_pageflags(dyn_pageflags_t pagemap)
+{
+   int i = 0;
+   
+   for (i = 0; i < PAGES_PER_BITMAP; i++)
+   memset((pagemap[i]), 0, PAGE_SIZE);
+}
+
+/* allocate_local_pageflags
+ *
+ * Description:Allocate a bitmap for local page flags.
+ * Arguments:  dyn_pageflags_t *:  Pointer to the bitmap.
+ */
+int allocate_dyn_pageflags(dyn_pageflags_t *pagemap)
+{
+   int i;
+
+   BUG_ON(*pagemap);
+
+   *pagemap = kmalloc(sizeof(void *) * PAGES_PER_BITMAP, GFP_ATOMIC);
+
+   for (i = 0; i < 

Re: [ANNOUNCE] iproute2 050209

[Eric Sandall]

On Wed, 9 Feb 2005, Stephen Hemminger wrote:
Small update to iproute2 which adds:
* infiniband address decode
* reorganize source for netem distribution files into separate directory
http://developer.osdl.org/dev/iproute2/download/iproute2-2.6.10-050209.tar.gz
This uncompresses to iproute2-2.6.9-050209 instead of
iproute2-2.6.10-050209.
-sandalle
--
Eric Sandall |  Source Mage GNU/Linux Developer
[EMAIL PROTECTED]  |  http://www.sourcemage.org/
http://eric.sandall.us/  |  SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC][PATCH] Memory Hotplug

[Rik van Riel]

On Fri, 18 Feb 2005, Dave Hansen wrote:
Memory hot-remove isn't really needed with Xen, the balloon
driver takes care of that.
You can free up individual pages back to the hypervisor, but you might
also want the opportunity to free up some unused mem_map if you shrink
the partition by a large amount.
Agreed, though I rather like the fact that the code can
be introduced bit by bit, so the memory hot-remove code
(probably the most complex part) doesn't need to be
maintained out-of-tree for Xen, but can wait until it
is upstream.
I can post individual patches if anyone would like to comment on them.
I'm interested.  I want to get this stuff working with Xen ;)
You can either pull them from here:
	http://www.sr71.net/patches/2.6.11/2.6.11-rc3-mhp1/broken-out/
Thanks, I'll take a stab at porting this functionality to Xen.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: I wrote a kernel tool for monitoring / web page

[sylvanino b]

Hi,

Sorry, it's meant to run on linux.
Actually, patch provided is for linux 2.6.9 + kdb 4.4


I have uploaded a new tarball and updated the webpage.
should be ok,

Sylvain
 

On Fri, 18 Feb 2005 20:01:55 -0500, Lee Revell <[EMAIL PROTECTED]> wrote:
> On Sat, 2005-02-19 at 01:41 +0100, sylvanino b wrote:
> > I did a webpage for it, you can check it out at:
> > http://membres.lycos.fr/kernelanalyzer/
> >
> > If you have any comment/critics, don't hesitate to share it
> 
> Is this meant to run on a Windows system or something?  The screenshots
> look like Windows, and the archive is a .rar file.
> 
> I was not able to extract the .rar file.  File roller does not work at
> all because it tries to pass the nonexistent "-c" switch to unrar.  And
> it won't unrar manually:
> 
> [EMAIL PROTECTED]:~/cvs$ unrar kernelanalyzer.rar 2>&1 | head -20
> 
> unrar 0.0.1   Copyright (c) 2004 Ben Asselstine
> 
> Extracting from /smb/rlrevell/cvs/kernelanalyzer.rar
> 
> Extracting  download/image/ex1.JPGFailed
> Extracting  download/image/ex2.JPGFailed
> Extracting  download/image/schema.PNG Failed
> 
> Please use standard Linux file formats like .tar.gz instead of oddballs like 
> .rar.
> 
> Lee
> 
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: drivers/input/power.c is never built

[Xavier Bestel]

Le samedi 19 février 2005 à 00:51 +0100, Oliver Neukum a écrit :

> > Well, we can say that userspace definitely is interested in "power"
> > key ;-).
> 
> I wouldn't call that selfevident. The system might be eg. a ticket
> vending system and we care only about wake ups from touchscreen,
> trackball and modem and about volume control keys. I don't think
> you can make up any rules about what user space is interested or not.

If noone can tell in advance who will be interested and what to do with
it, that looks like a very good reason to go through userspace ..

Xav


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Bootsplash for 2.6.11-rc4

[Michal Januszewski]

On Fri, Feb 18, 2005 at 05:52:54PM +0100, Pavel Machek wrote:

Hi,

> Just in case someone is interested, this is bootsplash for 2.6.11-rc4,
> taken from suse kernel. I'll probably try to modify it to work with
> radeonfb.
> 
> Any ideas why bootsplash needs to hack into vesafb? It only uses
> vesafb_ops to test against them before some kind of free...

It doesn't really need vesafb for anything. Back in the days of 2.6.7 
I used to release a version of bootsplash that had the dep. on vesafb 
removed. It worked fine with at least some other fb drivers.

You might also want to save yourself some work and try out an
alternative solution called fbsplash [1], which I designed after I got 
tired of fixing bootsplash and which I actively maintain. Fbsplash 
provides virtually the same functionality, and it has as much code as 
possible moved into userspace (no more JPEG decoders in the kernel).

[1] http://dev.gentoo.org/~spock/projects/gensplash/current/
 
Live long and prosper.
-- 
Michal 'Spock' JanuszewskiGentoo Linux Developer
cell: +48504917690 http://dev.gentoo.org/~spock/
JID: [EMAIL PROTECTED]   freenode: #gentoo-dev, #gentoo-pl



pgpeEsQ5qfv4d.pgp
Description: PGP signature

Re: A common layer for Accounting packages

[Andrew Morton]

Jay Lan <[EMAIL PROTECTED]> wrote:
>
> Since the need of Linux system accounting has gone beyond what BSD
> accounting provides, i think it is a good idea to create a thin layer
> of common code for various accounting packages, such as BSD accounting,
> CSA, ELSA, etc. The hook to do_exit() at exit.c was changed to invoke
> a routine in the common code which would then invoke those accounting
> packages that register to the acct_common to handle do_exit situation.

This all seems to be heading in the wrong direction.  Do we really want to
have lots of different system accounting packages all hooking into a
generic we-cant-decide-what-to-do-so-we-added-some-pointless-overhead
framework?

Can't we get _one_ accounting system in there, get it right, avoid the
framework?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

[Ray Bryant]

Andi Kleen wrote:
[Enjoy your vacation]
[I am thanks -- or I was -- I go home tomorrow]
I assume they would allow marking arbitary segments with specific
policies, so it should be possible.
An alternative way to handle shared libraries BTW would be to add the ELF
headers Steve did in his patch. And then handle them in user space
in ld.so and let it apply the necessary policy. 

This won't work for non ELF files though.
Would I then have to sign-off from the ld.so maintainer to get that patch
in?  :-(
This sounds more general than the xattr attribute thing I was thinking
of (i. e. marking a file non-migratable or library)
Well, we can work the exact details of this part later.

(2)  Something along the lines of:
page_migrate(pid, old_node, new_node);
or perhaps
page_migrate(pid, old_node_mask, new_node_mask);

+ node mask length. 

I don't like old_node* very much because it's imho unreliable
(because you can usually never fully know on which nodes the old
process was and there can be good reasons to just migrate everything)
In our case, it turns out we do because the job is running inside of
a cpuset.  So it can't allocate memory outside of that cpuset.  In
more general scenarios, you are right, you don't know.  But this
can be handled with a MIGRATE_NODE_ANY (more below).
I assume the second way would be more flexible, although I found
having node masks for this has the problem that you tend to allocate
most memory on the lowest numbered node because it's not easy to
round-robin over all set nodes (that's an issue in PREFERED policy
in NUMA API currently). So maybe the simple  new_node argument
is preferable.
page_migrate(pid, new_node)
(or putting it into a writable /proc file if you prefer that)   

or
(3)  mbind() with a pid argument?

That would bring it to 7 arguments, really too much for a system
call (and a function in general). Also it would mean needing
to know about other process private addresses again.
Maybe set_mempolicy, but a new call is probably better.
OK, lets assume we have a new call of some kind then.

But I think I now understand why you want this complicated
user space control. You want to preserve relative ordering
on a set of nodes, right? 

e.g. job runs threads on nodes 0,1,2,3  and you want it to move
to nodes 4,5,6,7 with all memory staying staying in the same
distance from the new CPUs as it were from the old CPUs, right? 
Yes, thats it:  we want the relative distances between the pages
on the new set of nodes to match the distances on the old set of
nodes as much as is possible, or we at least want a sufficiently
powerful system call to let us do this if the correct set of new
nodes is available.  This is to have the application have the same
level of performance before and after the migration call.
In actuality, what we intend to do is to use this API to migrate
jobs from one cpuset to another; we will require the administrator
to set up the cpusets so they are topologically equivalent for cpusets
of the same size.  If the don't do that, then performance can
change when a job is migrated.
It explains why you want old_node, you would do 
(assuming node mask arguments) 

page_migrate(pid, 0, 4)
page_migrate(pid, 1, 5)
...
page_migrate(pid, 3, 7) 

keeping the memory in the same relative order. Problem is what happens
when some memory is in some other node due to memory pressure fallbacks.
Your scheme would not migrate this memory at all. While you may
get away with this in your application I think it would make 
page migration much less useful in the general case than it could
be.  e.g. for a single threaded process it is very useful to just
force all its pages that have been allocated on multiple nodes
to a specific node. I would like to have this option at least, 
but with old node it would be rather inefficient. Ok, I guess you could
add a wildcard value for it; I guess that would work.

The patch that I sent out already defines MIGRATE_NODE_ANY to request
any other available node; this is needed for those cases where memory
hotplug just wants to move the page off of >>this<< node.  I don't
see why we we couldn't allow this as a value for old node, and it
would mean "migrate all pages".  (i. e. MIGRATE_NODE_ANY matches
pages on all nodes.)
Problem is still that you would need to iterate through all nodes for your 
migration scenario (or how would you find out where the job  allocated
its old pages?), which is not very nice.
Agreed.  Which is why  we really prefer an old_node_list, new_node_list,
then we iterate acrcoss pages and make the indicated decision for each
page.
Perhaps node masks would be better and teaching the kernel to handle
relative distances inside the masks transparently while migrating?
Not sure how complicated this would be to implement though.
Supporting interleaving on the new nodes may be also useful, that would
need a policy argument at least too and masks.
The worry I have about using node masks is that it is not as general 

Re: I wrote a kernel tool for monitoring / web page

[Lee Revell]

On Sat, 2005-02-19 at 01:41 +0100, sylvanino b wrote:
> I did a webpage for it, you can check it out at:
> http://membres.lycos.fr/kernelanalyzer/
> 
> If you have any comment/critics, don't hesitate to share it

Is this meant to run on a Windows system or something?  The screenshots
look like Windows, and the archive is a .rar file.

I was not able to extract the .rar file.  File roller does not work at
all because it tries to pass the nonexistent "-c" switch to unrar.  And
it won't unrar manually:

[EMAIL PROTECTED]:~/cvs$ unrar kernelanalyzer.rar 2>&1 | head -20

unrar 0.0.1   Copyright (c) 2004 Ben Asselstine


Extracting from /smb/rlrevell/cvs/kernelanalyzer.rar

Extracting  download/image/ex1.JPGFailed
Extracting  download/image/ex2.JPGFailed
Extracting  download/image/schema.PNG Failed

Please use standard Linux file formats like .tar.gz instead of oddballs like 
.rar.

Lee

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

A common layer for Accounting packages

[Jay Lan]

It started with the need of CSA to handle end-of-process (eop) at
do_exit() at exit.c. The hook at exit.c was BSD Accounting specific.
Since the need of Linux system accounting has gone beyond what BSD
accounting provides, i think it is a good idea to create a thin layer
of common code for various accounting packages, such as BSD accounting,
CSA, ELSA, etc. The hook to do_exit() at exit.c was changed to invoke
a routine in the common code which would then invoke those accounting
packages that register to the acct_common to handle do_exit situation.
Here is the description of this acct_common patch:
1) two new files at include/linux/acct_common.h and kernel/acct_common.c
2) A new config flag CONFIG_ACCT_COMMON is created and
   CONFIG_BSD_PROCESS_ACCT and a future CSA config flag depend on it.
   I think it is a good idea to always have acct_common in the kernel;
   in that case, the new config flag may not be really necessary. I can
   go either way.
3) Accounting packages can register themselves to acct_common for
   callbacks. Only do_exit handling is defined now. BSD acct.c has been
   modified to register/unergister to acct_common.
4) The 'enhanced acct data collection' routines have been moved from
   acct.c to acct_common.c. Files used to #include  were
   modified to #include .
This patch was generated against 2.6.11-rc3-mm2.
Signed-off-by: Jay Lan <[EMAIL PROTECTED]>
Index: linux/kernel/fork.c
===
--- linux.orig/kernel/fork.c2005-02-17 19:24:54.388927143 -0800
+++ linux/kernel/fork.c 2005-02-18 09:59:14.179816325 -0800
@@ -40,7 +40,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
Index: linux/fs/exec.c
===
--- linux.orig/fs/exec.c2005-02-18 05:45:19.868493728 -0800
+++ linux/fs/exec.c 2005-02-18 09:59:14.196418021 -0800
@@ -47,7 +47,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 #include 
Index: linux/kernel/exit.c
===
--- linux.orig/kernel/exit.c2005-02-17 19:24:54.380138011 -0800
+++ linux/kernel/exit.c 2005-02-18 10:05:43.506174767 -0800
@@ -17,7 +17,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -814,7 +814,7 @@ fastcall NORET_TYPE void do_exit(long co
group_dead = atomic_dec_and_test(>signal->live);
if (group_dead) {
del_timer_sync(>signal->real_timer);
-   acct_process(code);
+   acct_do_exit(code, tsk);
}
exit_mm(tsk);
 
Index: linux/include/linux/acct_common.h
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ linux/include/linux/acct_common.h   2005-02-18 12:41:28.232626074 -0800
@@ -0,0 +1,83 @@
+/*
+ *  Copyright (c) 2005 Silicon Graphics, Inc.
+ *  All rights reserved.
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ *
+ * Jay Lan <[EMAIL PROTECTED]>
+ */
+
+/*
+ *  include/linux/acct_common.h
+ *  
+ *  Common Accounting for Linux - Definitions
+ *
+ *  02/17/05 Jay Lan <[EMAIL PROTECTED]>. Initial creation of the header file.
+ *  This header file contains the definitions needed to support
+ *  registration/unregistration of various accounting agents to
+ *  the kernel. It also contains prototypes of common routines.
+ *
+ */
+
+#ifndef _LINUX_ACCT_COMMON_H
+#define _LINUX_ACCT_COMMON_H
+
+#include 
+#include 
+#include 
+
+
+/*
+ * Various accounting modules ID's
+ */
+#define ACCT_BSD   0
+#define ACCT_CSA   1
+#define ACCT_ELSA  2
+#define LAST_ACCT_ID   ACCT_ELSA
+#define ACCT_PKG_COUNT (LAST_ACCT_ID+1)
+
+/* 
+ * Used by accounting packages to define the callback functions into the
+ * packages.
+ *
+ * STRUCT MEMBERS:
+ *   pkg_id:   Accounting package ID. This should be set the package
+ * when register.
+ *   do_exit:  Function pointer to function used when do_exit()
+ * hook is needed.
+ * This is optional and may be set to NULL if it is
+ * not needed by the accounting package.
+ */
+struct 

I wrote a kernel tool for monitoring / web page

[sylvanino b]

Hi,

I wrote a kernel tool for my personnal usage which goal is to keep a
record of recent task preemptions and interruptions that appears under
linux. Although the record is short (a few minutes only), It can help
to analyse scheduling algorithm efficiency and also driver timing
issues. The user can access data from user-space, through proc
filesystem and analyze it with a graphics tool.  Then, since it's also
availlable within KDB, it can give clues and help for debugging.

So far, the tool is not a big deal, but not trivial either. When It is
running, the tool doesn't overload the system. And when it is not
running, it's just transparent.

I did a webpage for it, you can check it out at:
http://membres.lycos.fr/kernelanalyzer/

If you have any comment/critics, don't hesitate to share it
Thanks,

Sylvain
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 umask parameter to procfs

[Rene Scharfe]

On Fri, Feb 18, 2005 at 04:56:01AM +0100, Herbert Poetzl wrote:
> hmm, so what about debugger and similar not able to find the
> parent process or something like that?

You can walk the parentage chain up until you reach your login shell.
So you can look up info about the parent of every one of your processes
except for your login shell and any zombies.

> I'd say this needs some more investigation what tools and
> applications will break once it is enabled ...

Sure, that can't be bad.  I didn't really do anything so far that
warrants being called testing (compiles, runs, doesn't crash on boot --
send patch! ;).

But I also didn't invent this feature: it has been in OpenWall and
grsecurity for a long time now, so a form of restricted /proc has
received at least *some* testing.

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

Re: [RFC: 2.6 patch] drivers/pci/: possible cleanups

[Jon Smirl]

On Sat, 19 Feb 2005 00:54:19 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> This patch contains the following possible cleanups:
> - pci-acpi.c: make OSC_UUID static
> - remove the following unused functions:
>   - pci-acpi.c: acpi_query_osc
>   - pci-acpi.c: pci_osc_support_set
>   - pci.c: pci_find_ext_capability
>   - rom.c: pci_map_rom_copy
>   - rom.c: pci_remove_rom
> - remove the following unneeded EXPORT_SYMBOL's:
>   - pci-acpi.c: pci_osc_support_set
>   - rom.c: pci_map_rom_copy
>   - rom.c: pci_remove_rom

pci_map_rom_copy and pci_remove_rom are there to support boards that
can't access their hardware and their ROM at the same time. These
boards are known to exist but nobody has updated a driver yet to use
the new routines. These should be left in place as the PCI spec
explicitly allows the non-simultaneous access case.

pci_remove_rom should probably be renamed to pci_remove_rom_copy.

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

Re: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device

[Valdis . Kletnieks]

On Fri, 18 Feb 2005 15:23:44 EST, Bill Davidsen said:

> I'll try to build a truth table for this, I'm now working with some 
> non-iso data sets, so I'm a bit more interested. I would expect read() 
> to only try to read one sector, so I'll just do a quick and dirty to get 
> the size from the command line, seek and read.
> 
> I haven't had a problem using dd to date, as long as I know how long the 
> data set was, but I'll try to have results tonight.

The problem is that often you don't know exactly how long the data set is
(think "backup burned to CD/RW") - there's a *lot* of code that does stuff
like

while (actual=read(fd,buffer,65536) > 0) {
...
}

with the realistic expectation that the last read might return less than 64k,
in which case 'actual' will tell us how much was read.  Instead, we just get
an error on the read.

Note that 'dd' does this - that's why you get messages like '12343+1 blocks 
read'.
We *really* want to get to a point where 'dd' will work *without* having to
tell it a 'bs=' and 'count=' to get the size right


pgptZ019Ji54H.pgp
Description: PGP signature

Re: [2.6 patch] drivers/net/shaper.c: cleanups

[Jeff Garzik]

Adrian Bunk wrote:
This patch contains the following cleanups:
- remove an unused #define SHAPER_BANNER
- remove the sh_debug flag
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
you are removing presumably-useful debug code; NAK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] drivers/net/skfp/: cleanups

[Adrian Bunk]

This patch contains the following cleanups:
- make needlessly global code static
- remove the completely unused smtparse.c
- remove the following unused global functions:
  - drvfbi.c: init_dma
  - drvfbi.c: dis_dma
  - drvfbi.c: get_rom_byte
  - drvfbi.c: mac_drv_vpd_read
  - drvfbi.c: mac_drv_pci_fix
  - fplustm.c: mac_set_func_addr
  - fplustm.c: mac_del_multicast
  - hwmtm.c: mac_drv_rx_frag
  - pcmplc.c: pcm_set_lct_short
  - smt.c: smt_please_reconnect
  - smt.c: smt_change_t_neg
  - smtdef.c: smt_set_defaults

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/net/skfp/Makefile   |2 
 drivers/net/skfp/drvfbi.c   |  222 -
 drivers/net/skfp/ess.c  |4 
 drivers/net/skfp/fplustm.c  |   70 -
 drivers/net/skfp/h/cmtdef.h |7 
 drivers/net/skfp/h/hwmtm.h  |   25 -
 drivers/net/skfp/hwmtm.c|   34 --
 drivers/net/skfp/pcmplc.c   |7 
 drivers/net/skfp/pmf.c  |   11 
 drivers/net/skfp/skfddi.c   |1 
 drivers/net/skfp/smt.c  |   46 ---
 drivers/net/skfp/smtdef.c   |5 
 drivers/net/skfp/smtparse.c |  467 
 13 files changed, 19 insertions(+), 882 deletions(-)

--- linux-2.6.11-rc3-mm2-full/drivers/net/skfp/smtparse.c   2005-02-17 
02:17:05.0 +0100
+++ /dev/null   2004-11-25 03:16:25.0 +0100
@@ -1,467 +0,0 @@
-/**
- *
- * (C)Copyright 1998,1999 SysKonnect,
- * a business unit of Schneider & Koch & Co. Datensysteme GmbH.
- *
- * See the file "skfddi.c" for further information.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * The information in this file is provided "AS IS" without warranty.
- *
- 
**/
-
-
-/*
-   parser for SMT parameters
-*/
-
-#include "h/types.h"
-#include "h/fddi.h"
-#include "h/smc.h"
-#include "h/smt_p.h"
-
-#define KERNEL
-#include "h/smtstate.h"
-
-#ifndeflint
-static const char ID_sccs[] = "@(#)smtparse.c  1.12 98/10/06 (C) SK " ;
-#endif
-
-#ifdef sun
-#define _far
-#endif
-
-/*
- * convert to BCLK units
- */
-#define MS2BCLK(x)  ((x)*12500L)
-#define US2BCLK(x)  ((x/10)*125L)
-
-/*
- * parameter table
- */
-static struct s_ptab {
-   char*pt_name ;
-   u_short pt_num ;
-   u_short pt_type ;
-   u_long  pt_min ;
-   u_long  pt_max ;
-} ptab[] = {
-   { "PMFPASSWD",0,0 } ,
-   { "USERDATA",1, 0 } ,
-   { "LERCUTOFFA",2,   1,  4,  15  } ,
-   { "LERCUTOFFB",3,   1,  4,  15  } ,
-   { "LERALARMA",4,1,  4,  15  } ,
-   { "LERALARMB",5,1,  4,  15  } ,
-   { "TMAX",6, 1,  5,  165 } ,
-   { "TMIN",7, 1,  5,  165 } ,
-   { "TREQ",8, 1,  5,  165 } ,
-   { "TVX",9,  1,  2500,   1   } ,
-#ifdef ESS
-   { "SBAPAYLOAD",10,  1,  0,  1562} ,
-   { "SBAOVERHEAD",11, 1,  50, 5000} ,
-   { "MAXTNEG",12, 1,  5,  165 } ,
-   { "MINSEGMENTSIZE",13,  1,  0,  4478} ,
-   { "SBACATEGORY",14, 1,  0,  0x  } ,
-   { "SYNCHTXMODE",15, 0 } ,
-#endif
-#ifdef SBA
-   { "SBACOMMAND",16,  0 } ,
-   { "SBAAVAILABLE",17,1,  0,  100 } ,
-#endif
-   { NULL }
-} ;
-
-/* Define maximum string size for values and keybuffer */
-#define MAX_VAL40
-
-/*
- * local function declarations
- */
-static u_long parse_num(int type, char _far *value, char *v, u_long mn,
-   u_long mx, int scale);
-static int parse_word(char *buf, char _far *text);
-
-#ifdef SIM
-#define DB_MAIN(a,b,c) printf(a,b,c)
-#else
-#define DB_MAIN(a,b,c)
-#endif
-
-/*
- * BEGIN_MANUAL_ENTRY()
- *
- * int smt_parse_arg(struct s_smc *,char _far *keyword,int type,
-   char _far *value)
- *
- * parse SMT parameter
- * *keyword
- * pointer to keyword, must be \0, \n or \r terminated
- * *value  pointer to value, either char * or u_long *
- * if char *
- * pointer to value, must be \0, \n or \r terminated
- * if u_long *
- * contains binary value
- *
- * type0: integer
- * 1: string
- * return
- * 0   parameter parsed ok
- * != 0error
- * NOTE:
- * function can be called with DS != SS
- *
- *
- * END_MANUAL_ENTRY()
- */
-int smt_parse_arg(struct s_smc *smc, char _far *keyword, int type,
- char _far *value)
-{
-   char

[2.6 patch] drivers/net/slhc.c: remove 2 functions

[Adrian Bunk]

This patch removes two unused global functions.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/net/slhc.c|   27 ---
 include/net/slhc_vj.h |3 ---
 2 files changed, 30 deletions(-)

--- linux-2.6.11-rc3-mm2-full/include/net/slhc_vj.h.old 2005-02-16 
18:43:00.0 +0100
+++ linux-2.6.11-rc3-mm2-full/include/net/slhc_vj.h 2005-02-16 
18:43:49.0 +0100
@@ -185,7 +185,4 @@
  int isize));
 int slhc_toss __ARGS((struct slcompress *comp));
 
-void slhc_i_status __ARGS((struct slcompress *comp));
-void slhc_o_status __ARGS((struct slcompress *comp));
-
 #endif /* _SLHC_H */
--- linux-2.6.11-rc3-mm2-full/drivers/net/slhc.c.old2005-02-16 
18:43:15.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/slhc.c2005-02-16 
18:43:40.0 +0100
@@ -693,33 +693,6 @@
 }
 
 
-void slhc_i_status(struct slcompress *comp)
-{
-   if (comp != NULLSLCOMPR) {
-   printk("\t%d Cmp, %d Uncmp, %d Bad, %d Tossed\n",
-   comp->sls_i_compressed,
-   comp->sls_i_uncompressed,
-   comp->sls_i_error,
-   comp->sls_i_tossed);
-   }
-}
-
-
-void slhc_o_status(struct slcompress *comp)
-{
-   if (comp != NULLSLCOMPR) {
-   printk("\t%d Cmp, %d Uncmp, %d AsIs, %d NotTCP\n",
-   comp->sls_o_compressed,
-   comp->sls_o_uncompressed,
-   comp->sls_o_tcp,
-   comp->sls_o_nontcp);
-   printk("\t%10d Searches, %10d Misses\n",
-   comp->sls_o_searches,
-   comp->sls_o_misses);
-   }
-}
-
-/* Should this be surrounded with "#ifdef CONFIG_MODULES" ? */
 /* VJ header compression */
 EXPORT_SYMBOL(slhc_init);
 EXPORT_SYMBOL(slhc_free);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] drivers/net/shaper.c: cleanups

[Adrian Bunk]

This patch contains the following cleanups:
- remove an unused #define SHAPER_BANNER
- remove the sh_debug flag

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/net/shaper.c |   30 +-
 1 files changed, 5 insertions(+), 25 deletions(-)

--- linux-2.6.11-rc3-mm2-full/drivers/net/shaper.c.old  2005-02-16 
18:20:33.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/shaper.c  2005-02-16 
18:22:48.0 +0100
@@ -96,10 +96,6 @@
 }; 
 #define SHAPERCB(skb) ((struct shaper_cb *) ((skb)->cb))
 
-int sh_debug;  /* Debug flag */
-
-#define SHAPER_BANNER  "CymruNet Traffic Shaper BETA 0.04 for Linux 2.1\n"
-
 /*
  * Locking
  */
@@ -252,8 +248,6 @@
skb_queue_tail(>sendq, skb);
}
 #endif 
-   if(sh_debug)
-   printk("Frame queued.\n");
if(skb_queue_len(>sendq)>SHAPER_QLEN)
{
ptr=skb_dequeue(>sendq);
@@ -271,22 +265,16 @@
 static void shaper_queue_xmit(struct shaper *shaper, struct sk_buff *skb)
 {
struct sk_buff *newskb=skb_clone(skb, GFP_ATOMIC);
-   if(sh_debug)
-   printk("Kick frame on %p\n",newskb);
if(newskb)
{
newskb->dev=shaper->dev;
newskb->priority=2;
-   if(sh_debug)
-   printk("Kick new frame to %s, %d\n",
-   shaper->dev->name,newskb->priority);
+
dev_queue_xmit(newskb);
 
 shaper->stats.tx_bytes += skb->len;
shaper->stats.tx_packets++;
 
-if(sh_debug)
-   printk("Kicked new frame out.\n");
dev_kfree_skb(skb);
}
 }
@@ -316,8 +304,6 @@
 
if (test_and_set_bit(0, >locked))
{
-   if(sh_debug)
-   printk("Shaper locked.\n");
mod_timer(>timer, jiffies);
return;
}
@@ -334,8 +320,6 @@
 *  of SHAPER_BURST) gets kicked onto the link 
 */
 
-   if(sh_debug)
-   printk("Clock = %ld, jiffies = %ld\n", 
SHAPERCB(skb)->shapeclock, jiffies);
if(time_before_eq(SHAPERCB(skb)->shapeclock, jiffies + 
SHAPER_BURST))
{
/*
@@ -444,8 +428,7 @@
 {
struct shaper *sh=dev->priv;
int v;
-   if(sh_debug)
-   printk("Shaper header\n");
+
skb->dev=sh->dev;
v=sh->hard_header(skb,sh->dev,type,daddr,saddr,len);
skb->dev=dev;
@@ -457,8 +440,7 @@
struct shaper *sh=skb->dev->priv;
struct net_device *dev=skb->dev;
int v;
-   if(sh_debug)
-   printk("Shaper rebuild header\n");
+
skb->dev=sh->dev;
v=sh->rebuild_header(skb);
skb->dev=dev;
@@ -471,8 +453,7 @@
struct shaper *sh=neigh->dev->priv;
struct net_device *tmp;
int ret;
-   if(sh_debug)
-   printk("Shaper header cache bind\n");
+
tmp=neigh->dev;
neigh->dev=sh->dev;
ret=sh->hard_header_cache(neigh,hh);
@@ -484,8 +465,7 @@
unsigned char *haddr)
 {
struct shaper *sh=dev->priv;
-   if(sh_debug)
-   printk("Shaper cache update\n");
+
sh->header_cache_update(hh, sh->dev, haddr);
 }
 #endif

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: drivers/input/power.c is never built

[Pavel Machek]

Hi!

> > If usb keyboard has power button... I do not think we really want to
> > route that through acpi. And what if acpi is not available? (APM knows
> > about suspend key in weird way, but not about power key).
> 
> I'd suggest to primarily care about acpi. The other important power
> management subsystems will follow suit.

But... power key is not really a powermanagment and we do not want to
have 1000 different ways "deliver info about power key into
userspace".

And acpi way of delivery things is not really suitable it mixes
power key (and similar) with battery alarms etc. ACPI interface is
*not* nice, lets not emulate that one.

> > > > trip points), and I do not see how you can do interrupts for fan
> > > > status. Either fans are under Linux control (and kernel could tell you
> > > > when it turns fan on/off, but...), or they do not exist from Linux's
> > > > point of few.
> > > 
> > > They still can have a readable rate, even if not under os control.
> > > Nevertheless I don't think you can reasonably define what might
> > > interest user space or not and in which detail.
> > 
> > Well, we can say that userspace definitely is interested in "power"
> > key ;-).
> 
> I wouldn't call that selfevident. The system might be eg. a ticket
> vending system and we care only about wake ups from touchscreen,
> trackball and modem and about volume control keys. I don't think
> you can make up any rules about what user space is interested or not.

Yes, maybe userspace is not interested in "space" key. In such case
userland simply ignores "space" event. I do not know why "power" key
should be handled in any other way.

Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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][RFC] PlugSched-3.0 meets CKRM-E17

[Peter Williams]

Peter Williams wrote:
A patch of PlugSched-3.0 against a 2.6.10 kernel with 
ckrm-e17.2610.patch and cpu.ckrm-e17.v10.patch already applied is 
available for download from:

 

and a patchset and series file are available in at gzipped tarball at:
 

The model adopted in merging PlugSched with CKRM was to apply the CKRM 
mechanisms as an optional adjunct to each of the schedulers (ingosched, 
staircase, spa_no_frills and zaphod) which can be selected at boot time 
by adding "cpusched=" to the boot command line.  If the 
CKRM scheduler is included in the build then it can be 
selected/deselected in the usual ways.

PlugSched's version number has been bumped to 3.0 as its interface has 
been modified to increase the ability to share code between schedulers 
as well as integrate with CKRM.

A stand alone version of PlugSched-3.0 will be available in a few days.
Now available at:

--
Peter Williams   [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] drivers/net/seeq8005.c: cleanups

[Adrian Bunk]

This patch contains the following cleanups:
- make the needlessly global function seeq8005_init static
- kill an ancient version variable
- remove some outdated Emacs settings

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/net/seeq8005.c |   25 +++--
 1 files changed, 3 insertions(+), 22 deletions(-)

--- linux-2.6.11-rc3-mm2-full/drivers/net/seeq8005.c.old2005-02-16 
18:18:56.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/seeq8005.c2005-02-16 
18:19:53.0 +0100
@@ -12,12 +12,6 @@
This file is a network device driver for the SEEQ 8005 chipset and
the Linux operating system.
 
-*/
-
-static const char version[] =
-   "seeq8005.c:v1.00 8/07/95 Hamish Coleman ([EMAIL PROTECTED])\n";
-
-/*
   Sources:
SEEQ 8005 databook

@@ -91,10 +85,10 @@
 /* Example routines you must write ;->. */
 #define tx_done(dev)   (inw(SEEQ_STATUS) & SEEQSTAT_TX_ON)
 static void hardware_send_packet(struct net_device *dev, char *buf, int 
length);
-extern void seeq8005_init(struct net_device *dev, int startp);
+static  void seeq8005_init(struct net_device *dev, int startp);
 static inline void wait_for_buffer(struct net_device *dev);
 
-
+
 /* Check for a network adaptor of this type, and return '0' iff one exists.
If dev->base_addr == 0, probe all likely locations.
If dev->base_addr == 1, always return failure.
@@ -150,7 +144,6 @@
 
 static int __init seeq8005_probe1(struct net_device *dev, int ioaddr)
 {
-   static unsigned version_printed;
int i,j;
unsigned char SA_prom[32];
int old_cfg1;
@@ -291,9 +284,6 @@
}
 #endif
 
-   if (net_debug  &&  version_printed++ == 0)
-   printk(version);
-
printk("%s: %s found at %#3x, ", dev->name, "seeq8005", ioaddr);
 
/* Fill in the 'dev' fields. */
@@ -637,7 +627,7 @@
 #endif
 }
 
-void seeq8005_init(struct net_device *dev, int startp)
+static void seeq8005_init(struct net_device *dev, int startp)
 {
struct net_local *lp = netdev_priv(dev);
int ioaddr = dev->base_addr;
@@ -758,12 +748,3 @@
 }
 
 #endif /* MODULE */
-
-/*
- * Local variables:
- *  compile-command: "gcc -D__KERNEL__ -I/usr/src/linux/net/inet -Wall 
-Wstrict-prototypes -O6 -m486 -c skeleton.c"
- *  version-control: t
- *  kept-new-versions: 5
- *  tab-width: 4
- * End:
- */

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] drivers/net/sb1000.c: make some variables static

[Adrian Bunk]

This patch makes some needlessly global variables static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/net/sb1000.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

--- linux-2.6.11-rc3-mm2-full/drivers/net/sb1000.c.old  2005-02-16 
18:17:09.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/sb1000.c  2005-02-16 
18:18:02.0 +0100
@@ -57,9 +57,9 @@
 #include 
 
 #ifdef SB1000_DEBUG
-int sb1000_debug = SB1000_DEBUG;
+static int sb1000_debug = SB1000_DEBUG;
 #else
-int sb1000_debug = 1;
+static int sb1000_debug = 1;
 #endif
 
 static const int SB1000_IO_EXTENT = 8;
@@ -247,12 +247,12 @@
.remove = sb1000_remove_one,
 };
 
-
+
 /*
  * SB1000 hardware routines to be used during open/configuration phases
  */
 
-const int TimeOutJiffies = (875 * HZ) / 100;
+static const int TimeOutJiffies = (875 * HZ) / 100;
 
 static inline void nicedelay(unsigned long usecs)
 {
@@ -359,11 +359,11 @@
return 0;
 }
 
-
+
 /*
  * SB1000 hardware routines to be used during frame rx interrupt
  */
-const int Sb1000TimeOutJiffies = 7 * HZ;
+static const int Sb1000TimeOutJiffies = 7 * HZ;
 
 /* Card Wait For Ready (to be used during frame rx) */
 static inline int

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] drivers/net/s2io.c: cleanups

[Adrian Bunk]

This patch contains the following cleanups:
- make needlessly global code static
- remove the unused blobal function get_xena_rev_id

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/net/s2io.c |   75 ++---
 drivers/net/s2io.h |8 ++--
 2 files changed, 35 insertions(+), 48 deletions(-)

--- linux-2.6.11-rc3-mm2-full/drivers/net/s2io.h.old2005-02-16 
18:09:41.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/s2io.h2005-02-16 
18:15:42.0 +0100
@@ -848,7 +848,7 @@
 static void alarm_intr_handler(struct s2io_nic *sp);
 
 static int s2io_starter(void);
-void s2io_closer(void);
+static void s2io_closer(void);
 static void s2io_tx_watchdog(struct net_device *dev);
 static void s2io_tasklet(unsigned long dev_addr);
 static void s2io_set_multicast(struct net_device *dev);
@@ -858,13 +858,13 @@
 static int rx_osm_handler(nic_t * sp, RxD_t * rxdp, int ring_no,
  buffAdd_t * ba);
 #endif
-void s2io_link(nic_t * sp, int link);
-void s2io_reset(nic_t * sp);
+static void s2io_link(nic_t * sp, int link);
+static void s2io_reset(nic_t * sp);
 #ifdef CONFIG_S2IO_NAPI
 static int s2io_poll(struct net_device *dev, int *budget);
 #endif
 static void s2io_init_pci(nic_t * sp);
-int s2io_set_mac_addr(struct net_device *dev, u8 * addr);
+static int s2io_set_mac_addr(struct net_device *dev, u8 * addr);
 static irqreturn_t s2io_isr(int irq, void *dev_id, struct pt_regs *regs);
 static int verify_xena_quiescence(u64 val64, int flag);
 static struct ethtool_ops netdev_ethtool_ops;
--- linux-2.6.11-rc3-mm2-full/drivers/net/s2io.c.old2005-02-16 
18:07:48.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/s2io.c2005-02-16 
19:05:11.0 +0100
@@ -1350,7 +1350,7 @@
  *
  */
 
-void fix_mac_address(nic_t * sp)
+static void fix_mac_address(nic_t * sp)
 {
XENA_dev_config_t __iomem *bar0 = sp->bar0;
u64 val64;
@@ -1506,7 +1506,7 @@
  *  Return Value: void 
 */
 
-void free_tx_buffers(struct s2io_nic *nic)
+static void free_tx_buffers(struct s2io_nic *nic)
 {
struct net_device *dev = nic->dev;
struct sk_buff *skb;
@@ -1597,7 +1597,7 @@
  *  SUCCESS on success or an appropriate -ve value on failure.
  */
 
-int fill_rx_buffers(struct s2io_nic *nic, int ring_no)
+static int fill_rx_buffers(struct s2io_nic *nic, int ring_no)
 {
struct net_device *dev = nic->dev;
struct sk_buff *skb;
@@ -2422,7 +2422,7 @@
  *   SUCCESS on success and FAILURE on failure.
  */
 
-int wait_for_cmd_complete(nic_t * sp)
+static int wait_for_cmd_complete(nic_t * sp)
 {
XENA_dev_config_t __iomem *bar0 = sp->bar0;
int ret = FAILURE, cnt = 0;
@@ -2452,7 +2452,7 @@
  *  void.
  */
 
-void s2io_reset(nic_t * sp)
+static void s2io_reset(nic_t * sp)
 {
XENA_dev_config_t __iomem *bar0 = sp->bar0;
u64 val64;
@@ -2504,7 +2504,7 @@
  *  SUCCESS on success and FAILURE on failure.
  */
 
-int s2io_set_swapper(nic_t * sp)
+static int s2io_set_swapper(nic_t * sp)
 {
struct net_device *dev = sp->dev;
XENA_dev_config_t __iomem *bar0 = sp->bar0;
@@ -2598,7 +2598,7 @@
  *   file on failure.
  */
 
-int s2io_open(struct net_device *dev)
+static int s2io_open(struct net_device *dev)
 {
nic_t *sp = dev->priv;
int err = 0;
@@ -2650,7 +2650,7 @@
  *  file on failure.
  */
 
-int s2io_close(struct net_device *dev)
+static int s2io_close(struct net_device *dev)
 {
nic_t *sp = dev->priv;
 
@@ -2677,7 +2677,7 @@
  *  0 on success & 1 on failure.
  */
 
-int s2io_xmit(struct sk_buff *skb, struct net_device *dev)
+static int s2io_xmit(struct sk_buff *skb, struct net_device *dev)
 {
nic_t *sp = dev->priv;
u16 frg_cnt, frg_len, i, queue, queue_len, put_off, get_off;
@@ -2897,7 +2897,7 @@
  *  pointer to the updated net_device_stats structure.
  */
 
-struct net_device_stats *s2io_get_stats(struct net_device *dev)
+static struct net_device_stats *s2io_get_stats(struct net_device *dev)
 {
nic_t *sp = dev->priv;
mac_info_t *mac_control;
@@ -3145,7 +3145,7 @@
  * return 0 on success.
  */
 
-int s2io_ethtool_gset(struct net_device *dev, struct ethtool_cmd *info)
+static int s2io_ethtool_gset(struct net_device *dev, struct ethtool_cmd *info)
 {
nic_t *sp = dev->priv;
info->supported = (SUPPORTED_1baseT_Full | SUPPORTED_FIBRE);
@@ -3342,8 +3342,8 @@
  * int, returns 0 on Success
  */
 
-int s2io_ethtool_setpause_data(struct net_device *dev,
-  struct ethtool_pauseparam *ep)
+static int s2io_ethtool_setpause_data(struct net_device *dev,
+ struct ethtool_pauseparam *ep)
 {
u64 val64;
nic_t *sp = dev->priv;
@@ -3458,8 +3458,8 @@
  *  int  0 on success
  */
 
-int s2io_ethtool_geeprom(struct net_device *dev,
-struct ethtool_eeprom *eeprom, u8 * data_buf)
+static int s2io_ethtool_geeprom(struct net_device 

[2.6 patch] drivers/net/pppoe.c: make a struct static

[Adrian Bunk]

This patch makes a needlessly global struct static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

--- linux-2.6.11-rc3-mm2-full/drivers/net/pppoe.c.old   2005-02-16 
18:07:09.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/pppoe.c   2005-02-16 
18:07:23.0 +0100
@@ -1059,7 +1059,7 @@
read_unlock_bh(_hash_lock);
 }
 
-struct seq_operations pppoe_seq_ops = {
+static struct seq_operations pppoe_seq_ops = {
.start  = pppoe_seq_start,
.next   = pppoe_seq_next,
.stop   = pppoe_seq_stop,

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] drivers/net/ppp_deflate.c: make 2 structs static

[Adrian Bunk]

This patch makes two needlessly global structs static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/net/ppp_deflate.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.11-rc3-mm2-full/drivers/net/ppp_deflate.c.old 2005-02-16 
18:06:29.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/ppp_deflate.c 2005-02-16 
18:06:45.0 +0100
@@ -600,7 +600,7 @@
 /*
  * Procedures exported to if_ppp.c.
  */
-struct compressor ppp_deflate = {
+static struct compressor ppp_deflate = {
.compress_proto =   CI_DEFLATE,
.comp_alloc =   z_comp_alloc,
.comp_free =z_comp_free,
@@ -618,7 +618,7 @@
.owner =THIS_MODULE
 };
 
-struct compressor ppp_deflate_draft = {
+static struct compressor ppp_deflate_draft = {
.compress_proto =   CI_DEFLATE_DRAFT,
.comp_alloc =   z_comp_alloc,
.comp_free =z_comp_free,

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

[PATCH] Remove unused get_resource_list() declaration

[Bjorn Helgaas]

Remove unused get_resource_list() declaration.

Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>

= include/linux/ioport.h 1.15 vs edited =
--- 1.15/include/linux/ioport.h 2004-10-07 20:11:55 -06:00
+++ edited/include/linux/ioport.h   2005-02-15 15:27:49 -07:00
@@ -91,8 +91,6 @@
 extern struct resource ioport_resource;
 extern struct resource iomem_resource;
 
-extern int get_resource_list(struct resource *, char *buf, int size);
-
 extern int request_resource(struct resource *root, struct resource *new);
 extern struct resource * request_resource(struct resource *root, struct 
resource *new);
 extern int release_resource(struct resource *new);


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: 2.6 patch] drivers/pci/: possible cleanups

[Adrian Bunk]

This patch contains the following possible cleanups:
- pci-acpi.c: make OSC_UUID static
- remove the following unused functions:
  - pci-acpi.c: acpi_query_osc
  - pci-acpi.c: pci_osc_support_set
  - pci.c: pci_find_ext_capability
  - rom.c: pci_map_rom_copy
  - rom.c: pci_remove_rom
- remove the following unneeded EXPORT_SYMBOL's:
  - pci-acpi.c: pci_osc_support_set
  - rom.c: pci_map_rom_copy
  - rom.c: pci_remove_rom

Which of these changes are correct and which conflict with pending 
patches?

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/pci/pci-acpi.c   |   97 ---
 drivers/pci/pci.c|   48 ---
 drivers/pci/rom.c|   54 -
 include/linux/pci-acpi.h |2 
 include/linux/pci.h  |4 -
 5 files changed, 1 insertion(+), 204 deletions(-)

--- linux-2.6.11-rc3-mm2-full/include/linux/pci-acpi.h.old  2005-02-17 
23:18:44.0 +0100
+++ linux-2.6.11-rc3-mm2-full/include/linux/pci-acpi.h  2005-02-17 
23:18:54.0 +0100
@@ -48,14 +48,12 @@
 
 #ifdef CONFIG_ACPI
 extern acpi_status pci_osc_control_set(u32 flags);
-extern acpi_status pci_osc_support_set(u32 flags);
 #else
 #if !defined(acpi_status)
 typedef u32acpi_status;
 #define AE_ERROR   (acpi_status) (0x0001)
 #endif
 static inline acpi_status pci_osc_control_set(u32 flags) {return AE_ERROR;}
-static inline acpi_status pci_osc_support_set(u32 flags) {return AE_ERROR;} 
 #endif
 
 #endif /* _PCI_ACPI_H_ */
--- linux-2.6.11-rc3-mm2-full/drivers/pci/pci-acpi.c.old2005-02-17 
23:17:28.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/pci/pci-acpi.c2005-02-17 
23:48:50.0 +0100
@@ -19,72 +19,7 @@
 
 static u32 ctrlset_buf[3] = {0, 0, 0};
 static u32 global_ctrlsets = 0;
-u8 OSC_UUID[16] = {0x5B, 0x4D, 0xDB, 0x33, 0xF7, 0x1F, 0x1C, 0x40, 0x96, 0x57, 
0x74, 0x41, 0xC0, 0x3D, 0xD7, 0x66};
-
-static acpi_status  
-acpi_query_osc (
-   acpi_handle handle,
-   u32 level,
-   void*context,
-   void**retval )
-{
-   acpi_status status;
-   struct acpi_object_list input;
-   union acpi_object   in_params[4];
-   struct acpi_buffer  output;
-   union acpi_object   out_obj;
-   u32 osc_dw0;
-
-   /* Setting up output buffer */
-   output.length = sizeof(out_obj) + 3*sizeof(u32);  
-   output.pointer = _obj;
-   
-   /* Setting up input parameters */
-   input.count = 4;
-   input.pointer = in_params;
-   in_params[0].type   = ACPI_TYPE_BUFFER;
-   in_params[0].buffer.length  = 16;
-   in_params[0].buffer.pointer = OSC_UUID;
-   in_params[1].type   = ACPI_TYPE_INTEGER;
-   in_params[1].integer.value  = 1;
-   in_params[2].type   = ACPI_TYPE_INTEGER;
-   in_params[2].integer.value  = 3;
-   in_params[3].type   = ACPI_TYPE_BUFFER;
-   in_params[3].buffer.length  = 12;
-   in_params[3].buffer.pointer = (u8 *)context;
-
-   status = acpi_evaluate_object(handle, "_OSC", , );
-   if (ACPI_FAILURE (status)) {
-   printk(KERN_DEBUG  
-   "Evaluate _OSC Set fails. Status = 0x%04x\n", status);
-   return status;
-   }
-   if (out_obj.type != ACPI_TYPE_BUFFER) {
-   printk(KERN_DEBUG  
-   "Evaluate _OSC returns wrong type\n");
-   return AE_TYPE;
-   }
-   osc_dw0 = *((u32 *) out_obj.buffer.pointer);
-   if (osc_dw0) {
-   if (osc_dw0 & OSC_REQUEST_ERROR)
-   printk(KERN_DEBUG "_OSC request fails\n"); 
-   if (osc_dw0 & OSC_INVALID_UUID_ERROR)
-   printk(KERN_DEBUG "_OSC invalid UUID\n"); 
-   if (osc_dw0 & OSC_INVALID_REVISION_ERROR)
-   printk(KERN_DEBUG "_OSC invalid revision\n"); 
-   if (osc_dw0 & OSC_CAPABILITIES_MASK_ERROR) {
-   /* Update Global Control Set */
-   global_ctrlsets = *((u32 *)(out_obj.buffer.pointer+8));
-   return AE_OK;
-   }
-   return AE_ERROR;
-   }
-
-   /* Update Global Control Set */
-   global_ctrlsets = *((u32 *)(out_obj.buffer.pointer + 8));
-   return AE_OK;
-}
-
+static u8 OSC_UUID[16] = {0x5B, 0x4D, 0xDB, 0x33, 0xF7, 0x1F, 0x1C, 0x40, 
0x96, 0x57, 0x74, 0x41, 0xC0, 0x3D, 0xD7, 0x66};
 
 static acpi_status  
 acpi_run_osc (
@@ -147,36 +82,6 @@
 }
 
 /**
- * pci_osc_support_set - register OS support to Firmware
- * @flags: OS support bits
- *
- * Update OS support fields and doing a _OSC Query to obtain an update
- * from Firmware on supported control bits.
- **/
-acpi_status pci_osc_support_set(u32 flags)
-{
-   u32 temp;
-
-   if (!(flags & OSC_SUPPORT_MASKS)) {
-   return 

Re: 2.6: drivers/input/power.c is never built

[Oliver Neukum]

Am Samstag, 19. Februar 2005 00:34 schrieb Pavel Machek:
> Hi!
> 
> > > Well, if you have power button on usb keyboard -- why should it be
> > > handled differently from built-in button?
> > 
> > I see no reason. But that tells you that one subsystem should handle
> > that, not which subsystem.
> 
> If usb keyboard has power button... I do not think we really want to
> route that through acpi. And what if acpi is not available? (APM knows
> about suspend key in weird way, but not about power key).

I'd suggest to primarily care about acpi. The other important power
management subsystems will follow suit.

> > > trip points), and I do not see how you can do interrupts for fan
> > > status. Either fans are under Linux control (and kernel could tell you
> > > when it turns fan on/off, but...), or they do not exist from Linux's
> > > point of few.
> > 
> > They still can have a readable rate, even if not under os control.
> > Nevertheless I don't think you can reasonably define what might
> > interest user space or not and in which detail.
> 
> Well, we can say that userspace definitely is interested in "power"
> key ;-).

I wouldn't call that selfevident. The system might be eg. a ticket
vending system and we care only about wake ups from touchscreen,
trackball and modem and about volume control keys. I don't think
you can make up any rules about what user space is interested or not.

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/

[2.6 patch] oprofile: make some code static

[Adrian Bunk]

This patch makes some needlessly global code static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/oprofile/buffer_sync.c  |6 +++---
 drivers/oprofile/cpu_buffer.c   |2 +-
 drivers/oprofile/event_buffer.c |7 ---
 3 files changed, 8 insertions(+), 7 deletions(-)

--- linux-2.6.11-rc3-mm2-full/drivers/oprofile/buffer_sync.c.old
2005-02-17 22:18:31.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/oprofile/buffer_sync.c2005-02-17 
22:19:25.0 +0100
@@ -34,9 +34,9 @@
  
 static LIST_HEAD(dying_tasks);
 static LIST_HEAD(dead_tasks);
-cpumask_t marked_cpus = CPU_MASK_NONE;
+static cpumask_t marked_cpus = CPU_MASK_NONE;
 static DEFINE_SPINLOCK(task_mortuary);
-void process_task_mortuary(void);
+static void process_task_mortuary(void);
 
 
 /* Take ownership of the task struct and place it on the
@@ -422,7 +422,7 @@
  * and to have reached the list, it must have gone through
  * one full sync already.
  */
-void process_task_mortuary(void)
+static void process_task_mortuary(void)
 {
struct list_head * pos;
struct list_head * pos2;
--- linux-2.6.11-rc3-mm2-full/drivers/oprofile/cpu_buffer.c.old 2005-02-17 
22:20:01.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/oprofile/cpu_buffer.c 2005-02-17 
22:20:10.0 +0100
@@ -32,7 +32,7 @@
 static void wq_sync_buffer(void *);
 
 #define DEFAULT_TIMER_EXPIRE (HZ / 10)
-int work_enabled;
+static int work_enabled;
 
 void free_cpu_buffers(void)
 {
--- linux-2.6.11-rc3-mm2-full/drivers/oprofile/event_buffer.c.old   
2005-02-17 22:20:45.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/oprofile/event_buffer.c   2005-02-17 
22:21:38.0 +0100
@@ -94,7 +94,7 @@
 }
 
  
-int event_buffer_open(struct inode * inode, struct file * file)
+static int event_buffer_open(struct inode * inode, struct file * file)
 {
int err = -EPERM;
 
@@ -130,7 +130,7 @@
 }
 
 
-int event_buffer_release(struct inode * inode, struct file * file)
+static int event_buffer_release(struct inode * inode, struct file * file)
 {
oprofile_stop();
oprofile_shutdown();
@@ -142,7 +142,8 @@
 }
 
 
-ssize_t event_buffer_read(struct file * file, char __user * buf, size_t count, 
loff_t * offset)
+static ssize_t event_buffer_read(struct file * file, char __user * buf,
+size_t count, loff_t * offset)
 {
int retval = -EINVAL;
size_t const max = buffer_size * sizeof(unsigned long);

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] drivers/net/ne3210.c: cleanups

[Adrian Bunk]

This patch contains the following cleanups:
- make two needlessly global functions static
- kill an ancient version variable

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 drivers/net/ne3210.c |   10 ++
 1 files changed, 2 insertions(+), 8 deletions(-)

--- linux-2.6.11-rc3-mm2-full/drivers/net/ne3210.c.old  2005-02-16 
16:09:39.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/ne3210.c  2005-02-17 
21:55:37.0 +0100
@@ -26,9 +26,6 @@
Updated to EISA probing API 5/2003 by Marc Zyngier.
 */
 
-static const char *version =
-   "ne3210.c: Driver revision v0.03, 30/09/98\n";
-
 #include 
 #include 
 #include 
@@ -196,9 +193,6 @@
ei_status.word16 = 1;
ei_status.priv = phys_mem;
 
-   if (ei_debug > 0)
-   printk(version);
-
ei_status.reset_8390 = _reset_8390;
ei_status.block_input = _block_input;
ei_status.block_output = _block_output;
@@ -359,12 +353,12 @@
 MODULE_DESCRIPTION("NE3210 EISA Ethernet driver");
 MODULE_LICENSE("GPL");
 
-int ne3210_init(void)
+static int ne3210_init(void)
 {
return eisa_driver_register (_eisa_driver);
 }
 
-void ne3210_cleanup(void)
+static void ne3210_cleanup(void)
 {
eisa_driver_unregister (_eisa_driver);
 }

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 umask parameter to procfs

[Debian User]

On Thu, Feb 17, 2005 at 03:41:19PM -0800, Andrew Morton wrote:
> The feature seems fairly obscure, although very simple.  Is anyone actually
> likely to use this?

Yes, it's an obscure obscurity feature. :)  There certainly seems to be
some interest in it: both GrSecurity and OpenWall contain something
similar.  They set the mask at compile time, though.  But being able to
change it at boot time makes it much easier for mainstream distros to
include it in their kernels.

Personally I felt the need for the feature when I was a student sharing
a server with hundreds others.  Sure, it's not very useful on machines
offering no shell access at all.

> > +static umode_t umask = 0;
> 
> a) I think the above should be called proc_umask.
> 
> b) You shouldn't initialise it.
> 
> c) When adding a kernel parameter you should update
>Documentation/kernel-parameters.txt

Like below?

Hrm, maybe the option should be named pidumask instead of simply umask?


diff -urp linux-2.6.11-rc4/Documentation/kernel-parameters.txt 
linux-2.6.11-rc4+/Documentation/kernel-parameters.txt
--- linux-2.6.11-rc4/Documentation/kernel-parameters.txt2005-02-11 
21:16:00.0 +0100
+++ linux-2.6.11-rc4+/Documentation/kernel-parameters.txt   2005-02-12 
01:37:42.0 +0100
@@ -1037,16 +1037,19 @@ running once the system is up.
[ISAPNP] Exclude memory regions for the 
autoconfiguration
Ranges are in pairs (memory base and size).
 
+   processor.max_cstate=   [HW, ACPI]
+   Limit processor to maximum C-state
+   max_cstate=9 overrides any DMI blacklist limit.
+
+   proc.umask= [KNL] Restrict permissions of process specific
+   entries in /proc (i.e. the numerical directories).
+
profile=[KNL] Enable kernel profiling via /proc/profile
{ schedule |  }
(param: schedule - profile schedule points}
(param: profile step/bucket size as a power of 2 for
statistical time based profiling)
 
-   processor.max_cstate=   [HW, ACPI]
-   Limit processor to maximum C-state
-   max_cstate=9 overrides any DMI blacklist limit.
-
prompt_ramdisk= [RAM] List of RAM disks to prompt for floppy disk
before loading.
See Documentation/ramdisk.txt.
diff -urp linux-2.6.11-rc4/fs/proc/base.c linux-2.6.11-rc4+/fs/proc/base.c
--- linux-2.6.11-rc4/fs/proc/base.c 2005-02-11 21:16:13.0 +0100
+++ linux-2.6.11-rc4+/fs/proc/base.c2005-02-12 01:33:14.0 +0100
@@ -32,8 +32,14 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include "internal.h"
 
+static umode_t proc_umask;
+module_param_named(umask, proc_umask, ushort, 0);
+MODULE_PARM_DESC(umask, "umask for the numerical directories in /proc");
+
 /*
  * For hysterical raisins we keep the same inumbers as in the old procfs.
  * Feel free to change the macro below - just keep the range distinct from
@@ -1369,7 +1375,7 @@ static struct dentry *proc_pident_lookup
goto out;
 
ei = PROC_I(inode);
-   inode->i_mode = p->mode;
+   inode->i_mode = p->mode & ~(proc_umask & S_IALLUGO);
/*
 * Yes, it does not scale. And it should not. Don't add
 * new entries into /proc// without very good reasons.
@@ -1699,7 +1705,7 @@ struct dentry *proc_pid_lookup(struct in
put_task_struct(task);
goto out;
}
-   inode->i_mode = S_IFDIR|S_IRUGO|S_IXUGO;
+   inode->i_mode = S_IFDIR | ((S_IRUGO|S_IXUGO) & ~proc_umask);
inode->i_op = _tgid_base_inode_operations;
inode->i_fop = _tgid_base_operations;
inode->i_nlink = 3;
@@ -1754,7 +1760,7 @@ static struct dentry *proc_task_lookup(s
 
if (!inode)
goto out_drop_task;
-   inode->i_mode = S_IFDIR|S_IRUGO|S_IXUGO;
+   inode->i_mode = S_IFDIR | ((S_IRUGO|S_IXUGO) & ~proc_umask);
inode->i_op = _tid_base_inode_operations;
inode->i_fop = _tid_base_operations;
inode->i_nlink = 3;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Linux-fbdev-devel] Re: Hotplug blacklist and video devices

[Jon Smirl]

On Fri, 18 Feb 2005 17:58:51 -0500, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > For example I'm looking at making changes to DRM such that DRM will
> > require the corresponding framebuffer driver to be loaded.
> 
> Ignoring my suspicion that people won't like stuff getting forced down
> their throats like this (why would a DRM _require_ a framebuffer
> device?), does the hotplug blacklisting of the framebuffer devices
> matter at all if the DRM depends on them, i.e. won't they be loaded
> regardless when the DRM is loaded?

There is no mechanism for getting a hotplug remove event into a driver
like DRM that doesn't attach to the PCI device.

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

Re: 2.6: drivers/input/power.c is never built

[Pavel Machek]

Hi!

> > Well, if you have power button on usb keyboard -- why should it be
> > handled differently from built-in button?
> 
> I see no reason. But that tells you that one subsystem should handle
> that, not which subsystem.

If usb keyboard has power button... I do not think we really want to
route that through acpi. And what if acpi is not available? (APM knows
about suspend key in weird way, but not about power key).

> > trip points), and I do not see how you can do interrupts for fan
> > status. Either fans are under Linux control (and kernel could tell you
> > when it turns fan on/off, but...), or they do not exist from Linux's
> > point of few.
> 
> They still can have a readable rate, even if not under os control.
> Nevertheless I don't think you can reasonably define what might
> interest user space or not and in which detail.

Well, we can say that userspace definitely is interested in "power"
key ;-).
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] rwsem removal from kobj_map

[Jonathan Corbet]

[Since this is something I once looked at too...]

>  struct kobj_map *kobj_map_init(kobj_probe_t *base_probe,
> - struct subsystem *s)
> + struct subsystem *s, struct semaphore *sem)

The only reason kobj_map_init() needed the subsystem argument was for
the semaphore.  Since you're passing that separately now, I would think
that the subsystem argument could simply go away altogether.

Once that's done, you should be able to delete cdev_subsys as well; when
I cleaned that stuff up, I only left it there for kobj_map().

jon

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

Re: 2.6: drivers/input/power.c is never built

[Pavel Machek]

Hi!

> > What is the benefit of splitting the flow of information so?
> 
> It's split already. You get some from input (power and sleep keys on
> keyboards, sound volume keys and display brightness on some notebooks),
> some from ACPI events (power keys on notebooks and desktop cases, sound
> volume, display brightness on other notebooks), some from /proc/acpi/*
> (battery status, fan status), some from APM, from platform specific
> devices, from hotplug, from userspace daemons (UPS status).
> 
> The question is how to unify it.
> 
> Using power.c to simply pass power/sleep keys to the ACPI event pipe
> could get the input subsystem out of the loop at least. Maybe we could
> even pass sound keys to it. 

I do not think passing sound keys through acpi is good idea. acpid
does not know how to handle them, and X already know how to get them
from input subsystem.

I believe power and suspend keys should definitely go through
input. I'm not that sure about battery... Lid is somewhere in
between...

> It's probably still the best option, though I argued for doing it the
> other way around - I want to know the pros and cons for all the possible
> approaches.

Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [resend] VFS locking errors on max offset edge cases

[Bruce Allan]

Resending patch which also applies to 2.6.11-rc4.

On Thu, 2004-12-23 at 19:26, Matthew Wilcox wrote: 
> On Thu, Dec 23, 2004 at 03:01:20PM -0800, Bruce Allan wrote:
> > A number of Connectathon (http://www.connectathon.org/nfstests.html)
> > POSIX/fcntl() locking tests fail (even on local filesystems) at various
> > edge cases (i.e. around maximum allowable offsets) on 64-bit
> > architectures.
> 
> OK, that's bad and needs to be fixed.
> 
> > The overflow tests in fs/compat.c were superfluous where they were
> > located because if there was a conflicting lock, l_start and l_len would
> > have been overwritten with the values owned by the conflicting lock; if
> > no conflicting lock, sys_fcntl() would have returned any applicable
> > error.  The tests are moved above the call to sys_fcntl() to capture
> > overflow errors which would not have been caught by sys_fcntl(), eg.
> > obvious overflow when _FILE_OFFSET_BITS == 32.
> 
> I don't buy this explanation though.  With your patch, we're testing
> the lock the user passed in to see if it'd overflow.  Clearly, that
> can never happen.  The checks are supposed to be testing whether the
> conflicting lock is outside the limits that a program using a 32-bit
> off_t can cope with.

Hi Matthew,

I now agree with you not buying my initial explanation, but have some
follow-up comments/questions.  How is it clear that a user can never
pass in a lock request that would overflow?  AFAICT, there is no reason
a 32-bit application could not pass down a request for a lock (eg.
l_whence=SEEK_SET, l_start=0x7fff, l_len=2) which should overflow.

For 64-bit applications on a 64-bit architecture (and 32-bit apps/32-bit
archs) any overflow error in a lock request would be caught in
flock_to_posix_lock() whether or not there is a conflicting lock.

For 32-bit applications with 32-bit userland off_t on a 64-bit
architecture, flock_to_posix_lock() does not capture overflow errors on
requested locks because that function is checking for overflow assuming
it is a 64-bit value.  If there is no conflicting lock these values are
passed back to compat_sys_fcntl64() and the overflow check in that
function should catch it (provided l_whence==SEEK_SET, otherwise that
check may not catch it), but if there is a conflicting lock the overflow
check in compat_sys_fcntl64() is checking the values on the conflicting
lock instead of the requested lock.

I do see your point now about compat_sys_fcntl64() "checks are supposed
to be testing whether the conflicting lock is outside the limits that a
program using a 32-bit off_t can cope with", but it seems to me there
still needs to be an overflow check of the requested lock in
compat_sys_fcntl64() for the case of F_GETLK/F_SETLK/F_SETLKW; something
akin to the check in flock_to_posix_lock().  It's duplicate code, I
know, but at the moment I'm at a loss for a better alternative (I
suppose it could be setup instead to pass the maximum filesize all the
way to flock_to_posix_lock()).  This check would be unnecessary for
F_GETLK64/F_SETLK64/F_SETLKW64 as it would be properly handled in
flock_to_posix_lock().

Comments?

> > These tests also had a couple 'off by one' errors when comparing with
> > the maximum allowable offset.
> 
> Perhaps just fix that, and don't move the tests around?
[snip] 
> I hate assignments inside if statements.  Make this:
> 
>   start += l->l_start;
>   if (start < 0)
>   return -EINVAL;
Done.

Signed-off-by: Bruce Allan <[EMAIL PROTECTED]>

diff -Nurp -Xdontdiff linux-2.6.10-rc3-vanilla/fs/compat.c 
linux-2.6.10-rc3/fs/compat.c
--- linux-2.6.10-rc3-vanilla/fs/compat.c2004-12-23 11:52:50.0 
-0800
+++ linux-2.6.10-rc3/fs/compat.c2004-12-30 13:33:52.525317789 -0800
@@ -523,6 +523,40 @@ static int put_compat_flock64(struct flo
 }
 #endif
 
+static int check_compat_flock(unsigned int fd, struct flock *l)
+{
+   compat_off_t start, end;
+   struct file *filp = fget(fd);
+
+   switch (l->l_whence) {
+   case 0: /*SEEK_SET*/
+   start = 0;
+   break;
+   case 1: /*SEEK_CUR*/
+   start = filp->f_pos;
+   break;
+   case 2: /*SEEK_END*/
+   start = i_size_read(filp->f_dentry->d_inode);
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   /* POSIX-1996 leaves the case l->l_len < 0 undefined;
+  POSIX-2001 defines it. */
+   start += l->l_start;
+   end = start + l->l_len - 1;
+   if (l->l_len < 0) {
+   end = start - 1;
+   start += l->l_len;
+   }
+   if (start < 0)
+   return -EINVAL;
+   if (l->l_len > 0 && end < 0)
+   return -EOVERFLOW;
+   return 0;
+}
+
 asmlinkage long compat_sys_fcntl64(unsigned int fd, unsigned int cmd,
unsigned long arg)
 {
@@ -537,13 +571,18 @@ asmlinkage long compat_sys_fcntl64(unsig
ret = get_compat_flock(, compat_ptr(arg));

[PATCH] Add nobh_writepage() support

[Badari Pulavarty]

Hi Andrew,

Here is the patch to add nobh_wripage() support for the filesystems
which uses nobh_prepare_write/nobh_commit_write().

Idea here is to reduce unnecessary bufferhead creation/attachment
to the page through block_write_full_page(). nobh_wripage() tries 
to operate by directly creating bios, but it falls back to 
__block_write_full_page() if it can't make progress.

Note that this is not really generic routine and can't be used
for filesystems which uses page->Private for anything other
than buffer heads.

BTW, my next set of patches are to add ext3_writepages() support
for writeback mode and to add "nobh" support for ext3 writeback 
mode - which are based on some of this work (These are already 
discussed on ext2-devel).

And also, this needs some airtime in -mm tree before hitting mainline.

Thanks,
Badari




Signed-off-by: Badari Pulavarty <[EMAIL PROTECTED]>
diff -Narup -X dontdiff linux-2.6.10/fs/buffer.c linux-2.6.10.nobh/fs/buffer.c
--- linux-2.6.10/fs/buffer.c2004-12-24 13:34:58.0 -0800
+++ linux-2.6.10.nobh/fs/buffer.c   2005-02-18 14:52:20.707345056 -0800
@@ -39,6 +39,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int fsync_buffers_list(spinlock_t *lock, struct list_head *list);
 static void invalidate_bh_lrus(void);
@@ -2492,6 +2493,62 @@ int nobh_commit_write(struct file *file,
 EXPORT_SYMBOL(nobh_commit_write);
 
 /*
+ * nobh_writepage() - based on block_full_write_page() except
+ * that it tries to operate without attaching bufferheads to
+ * the page.
+ */
+int nobh_writepage(struct page *page, get_block_t *get_block,
+   struct writeback_control *wbc)
+{
+   struct inode * const inode = page->mapping->host;
+   loff_t i_size = i_size_read(inode);
+   const pgoff_t end_index = i_size >> PAGE_CACHE_SHIFT;
+   unsigned offset;
+   void *kaddr;
+   int ret;
+
+   /* Is the page fully inside i_size? */
+   if (page->index < end_index) {
+   goto out;
+   }
+
+   /* Is the page fully outside i_size? (truncate in progress) */
+   offset = i_size & (PAGE_CACHE_SIZE-1);
+   if (page->index >= end_index+1 || !offset) {
+   /*
+* The page may have dirty, unmapped buffers.  For example,
+* they may have been added in ext3_writepage().  Make them
+* freeable here, so the page does not leak.
+*/
+#if 0
+   /* Not really sure about this  - do we need this ? */
+   if (page->mapping->a_ops->invalidatepage)
+   page->mapping->a_ops->invalidatepage(page, offset);
+#endif
+   unlock_page(page);
+   return 0; /* don't care */
+   }
+
+   /*
+* The page straddles i_size.  It must be zeroed out on each and every
+* writepage invocation because it may be mmapped.  "A file is mapped
+* in multiples of the page size.  For a file that is not a multiple of
+* the  page size, the remaining memory is zeroed when mapped, and
+* writes to that region are not written out to the file."
+*/
+   kaddr = kmap_atomic(page, KM_USER0);
+   memset(kaddr + offset, 0, PAGE_CACHE_SIZE - offset);
+   flush_dcache_page(page);
+   kunmap_atomic(kaddr, KM_USER0);
+out:
+   ret = mpage_writepage(page, get_block, wbc);
+   if (ret == -EAGAIN)
+   ret = __block_write_full_page(inode, page, get_block, wbc);
+   return ret;
+}
+EXPORT_SYMBOL(nobh_writepage);
+
+/*
  * This function assumes that ->prepare_write() uses nobh_prepare_write().
  */
 int nobh_truncate_page(struct address_space *mapping, loff_t from)
diff -Narup -X dontdiff linux-2.6.10/fs/ext2/inode.c 
linux-2.6.10.nobh/fs/ext2/inode.c
--- linux-2.6.10/fs/ext2/inode.c2004-12-24 13:33:51.0 -0800
+++ linux-2.6.10.nobh/fs/ext2/inode.c   2005-02-16 16:27:32.0 -0800
@@ -626,6 +626,12 @@ ext2_nobh_prepare_write(struct file *fil
return nobh_prepare_write(page,from,to,ext2_get_block);
 }
 
+static int ext2_nobh_writepage(struct page *page, 
+   struct writeback_control *wbc)
+{
+   return nobh_writepage(page, ext2_get_block, wbc);
+}
+
 static sector_t ext2_bmap(struct address_space *mapping, sector_t block)
 {
return generic_block_bmap(mapping,block,ext2_get_block);
@@ -675,7 +681,7 @@ struct address_space_operations ext2_aop
 struct address_space_operations ext2_nobh_aops = {
.readpage   = ext2_readpage,
.readpages  = ext2_readpages,
-   .writepage  = ext2_writepage,
+   .writepage  = ext2_nobh_writepage,
.sync_page  = block_sync_page,
.prepare_write  = ext2_nobh_prepare_write,
.commit_write   = nobh_commit_write,
diff -Narup -X dontdiff linux-2.6.10/fs/jfs/inode.c 
linux-2.6.10.nobh/fs/jfs/inode.c
--- linux-2.6.10/fs/jfs/inode.c 2004-12-24 

Re: Question on CONFIG_IRQBALANCE / 2.6.x

[Jeff Garzik]

Joerg Sommrey wrote:
On Fri, Feb 18, 2005 at 02:39:49PM -0800, Martin J. Bligh wrote:
there's something I don't understand:  With IRQBALANCE *enabled* almost
all interrupts are processed on CPU0.  This changed in an unexpected way
after disabling IRQBALANCE: now all interrupts are distributed uniformly
to both CPUs.  Maybe it's intentional, but it's not what I expect when a
config option named IRQBALANCE is *disabled*.
Can anybody comment on this?
If you have a Pentium 3 based system, by default they'll round robin.
If you turn on IRQbalance, they won't move until the traffic gets high
enough load to matter. That's presumably what you're seeing.

It's an Athlon box that propably has the same behaviour.  Just another
question on this topic:  with IRQBALANCE enabled, almost all interupts
are routet to CPU0.  Lately irq 0 runs on CPU1 and never returns to CPU0
- is there any obvious reason for that?
Note that it is a popular recommendation to -disable- CONFIG_IRQBALANCE, 
and then run the userspace 'irqbalanced'.

Jeff

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

Re: [Linux-fbdev-devel] Re: Hotplug blacklist and video devices

[Michel Dänzer]

On Fri, 2005-02-18 at 16:14 -0500, Jon Smirl wrote:
> On Fri, 18 Feb 2005 16:08:22 -0500, Bill Nottingham <[EMAIL PROTECTED]> wrote:
> > Under Fedora (and RHEL), they're there because we generally
> > don't want to load them unless the user asked for them.
> 
> Is there a specific reason why they are blocked? 

One reaseon might be that the framebuffer devices can cause problems,
e.g. with proprietary X drivers.

> For example I'm looking at making changes to DRM such that DRM will
> require the corresponding framebuffer driver to be loaded.

Ignoring my suspicion that people won't like stuff getting forced down
their throats like this (why would a DRM _require_ a framebuffer
device?), does the hotplug blacklisting of the framebuffer devices
matter at all if the DRM depends on them, i.e. won't they be loaded
regardless when the DRM is loaded?


-- 
Earthling Michel DÃnzer  | Debian (powerpc), X and DRI developer
Libre software enthusiast|   http://svcs.affero.net/rm.php?r=daenzer

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

Re: Question on CONFIG_IRQBALANCE / 2.6.x

[Joerg Sommrey]

On Fri, Feb 18, 2005 at 02:39:49PM -0800, Martin J. Bligh wrote:
> > 
> > there's something I don't understand:  With IRQBALANCE *enabled* almost
> > all interrupts are processed on CPU0.  This changed in an unexpected way
> > after disabling IRQBALANCE: now all interrupts are distributed uniformly
> > to both CPUs.  Maybe it's intentional, but it's not what I expect when a
> > config option named IRQBALANCE is *disabled*.
> > 
> > Can anybody comment on this?
> 
> If you have a Pentium 3 based system, by default they'll round robin.
> If you turn on IRQbalance, they won't move until the traffic gets high
> enough load to matter. That's presumably what you're seeing.

It's an Athlon box that propably has the same behaviour.  Just another
question on this topic:  with IRQBALANCE enabled, almost all interupts
are routet to CPU0.  Lately irq 0 runs on CPU1 and never returns to CPU0
- is there any obvious reason for that?

-jo

-- 
-rw-r--r--  1 jo users 63 2005-02-18 23:29 /home/jo/.signature
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: cciss CSMI via sysfs for 2.6

[James Bottomley]

On Fri, 2005-02-18 at 12:05 -0800, Greg KH wrote:
> For a device?  It seems a huge overkill to add this attribute for
> _every_ device in the system, when only a small minority can actually
> use it.  Just put it as a default scsi or transport class attribute
> instead.

Actually, we might be able to do this as a simple attribute container
rather than a transport class, but I agree, it's not a generic property
of every device.

James


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

Re: Question on CONFIG_IRQBALANCE / 2.6.x

[Martin J. Bligh]

> 
> there's something I don't understand:  With IRQBALANCE *enabled* almost
> all interrupts are processed on CPU0.  This changed in an unexpected way
> after disabling IRQBALANCE: now all interrupts are distributed uniformly
> to both CPUs.  Maybe it's intentional, but it's not what I expect when a
> config option named IRQBALANCE is *disabled*.
> 
> Can anybody comment on this?

If you have a Pentium 3 based system, by default they'll round robin.
If you turn on IRQbalance, they won't move until the traffic gets high
enough load to matter. That's presumably what you're seeing.

m.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [BK] upgrade will be needed

[Dmitry Torokhov]

On Fri, 18 Feb 2005 23:18:19 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 18, 2005 at 09:34:47PM +, Anton Altaparmakov wrote:
> > On Fri, 18 Feb 2005, David S. Miller wrote:
> > > On Fri, 18 Feb 2005 21:45:55 +0100
> > > "d.c" <[EMAIL PROTECTED]> wrote:
> > >
> > > > 2) And more important, *nobody* works against "linus' bk head".
> > >
> > > I do, %100 exclusively, for all the networking and sparc
> > > development.
> > >
> > > I never work against the -mm tree.
> >
> > Dito.  All my kernel development happens against Linus' bk head and I
> > almost never work against -mm tree.
> 
> Same here, I work on Linus's bk head and all the changes go to -mm for
> testing first, then to Linus for inclusion.
> 

I guess there is a perception that developers/maintainers are working
against -mm because all maintainers trees are automatically pulled by
Andrew. And when someone doing stuff on somewhat regular basis he/she
tends to do it against maintainer's tree thus making patches suitable
for -mm as well.
 
-- 
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: [Problem] slow write to dvd-ram since 2.6.7-bk8

[Droebbel]

On Fr, 2005-02-18 at 00:10 +0100, Tino Keitel wrote:
>On Wed, Feb 16, 2005 at 23:29:24 +0100, Droebbel wrote:
>> On Mi, 2005-02-16 at 22:55 +0100, Droebbel wrote:
>> 
>> >The vmscan-dont-reclaim-too-many-pages.patch led to the said reduction
>> >of writing speed. I reverse-applied it to 2.6.8.1, where it seems to
>> >solve the problem.
>> 
>> Sorry, have to correct that: it seemed to help at my tests with dd
>> (write 1G of zeroes to a file). Copying a file with mc still shows
>> around 1.4MB/s. Could be worse, but is definitely not ok. It *is* better
>> with 2.6.7.
>
>Here are some numbers with my setup. I always wrote 1 GB of data to the
>same DVD-RAM disc (EMTEC), to the device directly and to a fresh ext2
>on
>the disc.
>
>kernel 2.6.10:
>
>$ time { sudo dd if=/dev/zero of=bigfile bs=64k count=16000 ; sync ; }
>
>real32m5.025s
>
>$ time {sudo dd if=/dev/zero of=/dev/cdrom bs=64k count=16000 ; sync ;}
>
>real29m41.980s
>
>kernel 2.6.7:
>
>$ time { sudo dd if=/dev/zero of=bigfile bs=64k count=16000 ; sync ; }
>
>real13m23.688s
>
>$ time {sudo dd if=/dev/zero of=/dev/cdrom bs=64k count=16000 ; sync ;}
>
>real13m14.609s

This is what I get:
 2.6.8 to 2.6.10: about 30 min. I think that's clear now. I did not run
any mre test with that.

2.6.7 gives less than 10 minutes.

Reverse-Patched 2.6.8.1 and 2.6.10 about 9-11 min.

But what I think is interesting: Other than with 2.6.7, with my 2.6.10
the result seems to be highly dependent on other io activities. I came
to test that when I saw that writing to dvd-ram slowed down when reading
from a cdrom at the same time. System disk, cdrom and dvd-ram are
connected by buses as independent as possible: hda, hdd and scd0 via
on-chip ide2. hdc is inactive and spun down at the times of testing.

Some results (same command as yours, but writing to file only):

2.6.8.1 with vmscan-dont-reclaim-too-many-pages.patch
and vmscan-scan-sanity.patch reversed:

real9m17.389s
real10m11.271s
(run twice)

2.6.10, both patches reversed:

real10m26.374s

same kernel, some io and high (but niced) system load by reading from
hda and gzipping into /dev/null

real21m46.795s

same kernel, some io and low load by reading from cdrom (raw read with
dd as well) into /dev/null

real22m11.639s

2.6.7 vanilla, some io and low load by reading from cdrom (raw read with
dd as well) into /dev/null

real5m58.092

That's too fast - impossible on 3x media with verification. I'll check
that again. But it *really* seemed to be fast.

I also hat the impression that my tests with 2.6.10 and 2.6.8.1 were
much more promising when run from a rather basic testing system without
X, a bit closer to the 2.6.7 results. Haven't got time to check that
till monday. All the above results except the 2.6.7 are from Ubuntu
(Hoary) Systems with X and Gnome running. 

Regards
David



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

Re: [RFC][PATCH] Memory Hotplug

[Dave Hansen]

On Fri, 2005-02-18 at 16:52 -0500, Rik van Riel wrote:
> On Thu, 17 Feb 2005, Dave Hansen wrote:
> > The attached patch is a prototype implementation of memory hot-add.  It
> > allows you to boot your system, and add memory to it later.  Why would
> > you want to do this?
> 
> I want it so I can grow Xen guests after they have been booted
> up.  Being able to hot-add memory is essential for dynamically
> resizing the memory of various guest OSes, to readjust them for
> the workload.

That's the same thing we like about it on ppc64 partitions.

> Memory hot-remove isn't really needed with Xen, the balloon
> driver takes care of that.

You can free up individual pages back to the hypervisor, but you might
also want the opportunity to free up some unused mem_map if you shrink
the partition by a large amount.

> > I can post individual patches if anyone would like to comment on them.
> 
> I'm interested.  I want to get this stuff working with Xen ;)

You can either pull them from here:

http://www.sr71.net/patches/2.6.11/2.6.11-rc3-mhp1/broken-out/

or grab the whole tarball:

http://www.sr71.net/patches/2.6.11/2.6.11-rc3-mhp1/broken-out-2.6.11-rc3-mhp1.tar.gz

Or, I could always post the whole bunch to lhms.  Nobody there should
mind too much. :)

The largest part of porting hot-add to a new architecture is usually the
sparsemem portion.  You'll pretty much have to #ifdef pfn_to_page() and
friends, declare a few macros, and then do a bit of debugging.  Here's
ppc64 as an example:

http://www.sr71.net/patches/2.6.11/2.6.11-rc3-mhp1/broken-out/B-sparse-170-sparsemem-ppc64.patch

-- 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: [BK] upgrade will be needed

[Vojtech Pavlik]

On Fri, Feb 18, 2005 at 09:34:47PM +, Anton Altaparmakov wrote:
> On Fri, 18 Feb 2005, David S. Miller wrote:
> > On Fri, 18 Feb 2005 21:45:55 +0100
> > "d.c" <[EMAIL PROTECTED]> wrote:
> > 
> > > 2) And more important, *nobody* works against "linus' bk head".
> > 
> > I do, %100 exclusively, for all the networking and sparc
> > development.
> > 
> > I never work against the -mm tree.
> 
> Dito.  All my kernel development happens against Linus' bk head and I 
> almost never work against -mm tree.

Same here, I work on Linus's bk head and all the changes go to -mm for
testing first, then to Linus for inclusion.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: drivers/input/power.c is never built

[Oliver Neukum]

Am Freitag, 18. Februar 2005 22:34 schrieb Pavel Machek:

> Well, if you have power button on usb keyboard -- why should it be
> handled differently from built-in button?

I see no reason. But that tells you that one subsystem should handle
that, not which subsystem.
 
> > > I think that's all you need to trigger actions. You don't need the exact
> > > percentage of the battery, and you don't need the exact AC voltage at
> > > input. 
> > 
> > That is very debateable. I might want a quiet mode and would be
> > interested in notifications about thermal data and fan status. 
> 
> Hmm, yes, some thermal notifications are needed. OTOH I'm not sure if
> all the hardware does sent interrupts for temperature changes (you
> definitely do not get interrupts for "small" changes that do not cross

I suspect that this is really done in SMI.

> trip points), and I do not see how you can do interrupts for fan
> status. Either fans are under Linux control (and kernel could tell you
> when it turns fan on/off, but...), or they do not exist from Linux's
> point of few.

They still can have a readable rate, even if not under os control.
Nevertheless I don't think you can reasonably define what might
interest user space or not and in which detail.

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: [RFC][PATCH] Memory Hotplug

[Rik van Riel]

On Thu, 17 Feb 2005, Dave Hansen wrote:
The attached patch is a prototype implementation of memory hot-add.  It
allows you to boot your system, and add memory to it later.  Why would
you want to do this?
I want it so I can grow Xen guests after they have been booted
up.  Being able to hot-add memory is essential for dynamically
resizing the memory of various guest OSes, to readjust them for
the workload.
Memory hot-remove isn't really needed with Xen, the balloon
driver takes care of that.
I can post individual patches if anyone would like to comment on them.
I'm interested.  I want to get this stuff working with Xen ;)
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [BK] upgrade will be needed

[Anton Altaparmakov]

On Fri, 18 Feb 2005, David S. Miller wrote:
> On Fri, 18 Feb 2005 21:45:55 +0100
> "d.c" <[EMAIL PROTECTED]> wrote:
> 
> > 2) And more important, *nobody* works against "linus' bk head".
> 
> I do, %100 exclusively, for all the networking and sparc
> development.
> 
> I never work against the -mm tree.

Dito.  All my kernel development happens against Linus' bk head and I 
almost never work against -mm tree.

Best regards,

Anton
-- 
Anton Altaparmakov  (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: drivers/input/power.c is never built

[Pavel Machek]

Hi!

> > I wouldn't want to pass all the battery info (UPSes can be even more
> > complex, able to switch on/off individual sockets, etc) through input,
> > just the basic events:
> > 
> > AC power on/off
> > battery full/normal/low/critical/(fail)
> > 
> > Then the other power-related events
> > 
> > Lid open/closed
> > Power button
> > Sleep button
> 
> What is the benefit of splitting the flow of information so?

Well, if you have power button on usb keyboard -- why should it be
handled differently from built-in button?

> > I think that's all you need to trigger actions. You don't need the exact
> > percentage of the battery, and you don't need the exact AC voltage at
> > input. 
> 
> That is very debateable. I might want a quiet mode and would be
> interested in notifications about thermal data and fan status. 

Hmm, yes, some thermal notifications are needed. OTOH I'm not sure if
all the hardware does sent interrupts for temperature changes (you
definitely do not get interrupts for "small" changes that do not cross
trip points), and I do not see how you can do interrupts for fan
status. Either fans are under Linux control (and kernel could tell you
when it turns fan on/off, but...), or they do not exist from Linux's
point of few.
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: drivers/input/power.c is never built

[Vojtech Pavlik]

On Fri, Feb 18, 2005 at 10:23:19PM +0100, Oliver Neukum wrote:

> What is the benefit of splitting the flow of information so?

It's split already. You get some from input (power and sleep keys on
keyboards, sound volume keys and display brightness on some notebooks),
some from ACPI events (power keys on notebooks and desktop cases, sound
volume, display brightness on other notebooks), some from /proc/acpi/*
(battery status, fan status), some from APM, from platform specific
devices, from hotplug, from userspace daemons (UPS status).

The question is how to unify it.

Using power.c to simply pass power/sleep keys to the ACPI event pipe
could get the input subsystem out of the loop at least. Maybe we could
even pass sound keys to it. 

It's probably still the best option, though I argued for doing it the
other way around - I want to know the pros and cons for all the possible
approaches.

> > I think that's all you need to trigger actions. You don't need the exact
> > percentage of the battery, and you don't need the exact AC voltage at
> > input. 
> 
> That is very debateable. I might want a quiet mode and would be
> interested in notifications about thermal data and fan status. 
> 
>   Regards
>   Oliver
> 

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: drivers/input/power.c is never built

[James Simmons]

> All you'd need is input.c. One file, approx 750 lines at the moment, a
> big chunk of that can be confugured out if you don't need procfs or
> hotplug.
> 
> > Think about embedded stuff I wonder whether this is viable.
> 
> On most embedded platforms you have some buttons or controls, so it's
> likely you'll use input anyway.

I have always used the input api on embedded devices.

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

Question on CONFIG_IRQBALANCE / 2.6.x

[Joerg Sommrey]

Hi all,

there's something I don't understand:  With IRQBALANCE *enabled* almost
all interrupts are processed on CPU0.  This changed in an unexpected way
after disabling IRQBALANCE: now all interrupts are distributed uniformly
to both CPUs.  Maybe it's intentional, but it's not what I expect when a
config option named IRQBALANCE is *disabled*.

Can anybody comment on this?

Thanks,
-jo

-- 
-rw-r--r--  1 jo users 63 2005-02-18 21:21 /home/jo/.signature
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: cciss CSMI via sysfs for 2.6

[Greg KH]

On Fri, Feb 18, 2005 at 07:46:28PM +, Christoph Hellwig wrote:
> >  /*
> > + * sysfs stuff
> > + * this should be moved to it's own file, maybe cciss_sysfs.h
> > + */
> > +
> > +static ssize_t cciss_firmver_show(struct device *dev, char *buf)
> > +{
> > +   ctlr_info_t *h = dev->driver_data;
> > +return sprintf(buf,"%c%c%c%c\n", h->firm_ver[0], h->firm_ver[1],
> > +h->firm_ver[2], h->firm_ver[3]);
> > +}
> 
> I really wish we had a common firmver release attribut in the driver
> core, as mentioned in the fc transport class thread.  Greg?

For a device?  It seems a huge overkill to add this attribute for
_every_ device in the system, when only a small minority can actually
use it.  Just put it as a default scsi or transport class attribute
instead.

thanks,

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

[RFC] rwsem removal from kobj_map

[Greg KH]

So, in my continuing quest to remove the big rwsem from struct semaphore
(or at least reduce the usage of it), here's a patch against 2.6.11-rc4
that takes it out of the kobj_map code.

This might fix up any odd issues that people might have had with the
genhd code lately in allocating major numbers, as I didn't realize that
it was also using the lock through the kobj_map code.  This resolves
that issue.

It should show up in the next -mm releases through the bk-driver tree,
but if anyone has any comments on it, please let me know.

thanks,

greg k-h



 Subject: kmap: remove usage of rwsem from kobj_map.

This forces the caller to provide the lock, but as they all already had one, 
it's not a big change.

Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>

diff -Nru a/drivers/base/map.c b/drivers/base/map.c
--- a/drivers/base/map.c2005-02-18 13:25:04 -08:00
+++ b/drivers/base/map.c2005-02-18 13:25:04 -08:00
@@ -25,7 +25,7 @@
int (*lock)(dev_t, void *);
void *data;
} *probes[255];
-   struct rw_semaphore *sem;
+   struct semaphore *sem;
 };
 
 int kobj_map(struct kobj_map *domain, dev_t dev, unsigned long range,
@@ -53,7 +53,7 @@
p->range = range;
p->data = data;
}
-   down_write(domain->sem);
+   down(domain->sem);
for (i = 0, p -= n; i < n; i++, p++, index++) {
struct probe **s = >probes[index % 255];
while (*s && (*s)->range < range)
@@ -61,7 +61,7 @@
p->next = *s;
*s = p;
}
-   up_write(domain->sem);
+   up(domain->sem);
return 0;
 }
 
@@ -75,7 +75,7 @@
if (n > 255)
n = 255;
 
-   down_write(domain->sem);
+   down(domain->sem);
for (i = 0; i < n; i++, index++) {
struct probe **s;
for (s = >probes[index % 255]; *s; s = &(*s)->next) {
@@ -88,7 +88,7 @@
}
}
}
-   up_write(domain->sem);
+   up(domain->sem);
kfree(found);
 }
 
@@ -99,7 +99,7 @@
unsigned long best = ~0UL;
 
 retry:
-   down_read(domain->sem);
+   down(domain->sem);
for (p = domain->probes[MAJOR(dev) % 255]; p; p = p->next) {
struct kobject *(*probe)(dev_t, int *, void *);
struct module *owner;
@@ -120,7 +120,7 @@
module_put(owner);
continue;
}
-   up_read(domain->sem);
+   up(domain->sem);
kobj = probe(dev, index, data);
/* Currently ->owner protects _only_ ->probe() itself. */
module_put(owner);
@@ -128,12 +128,12 @@
return kobj;
goto retry;
}
-   up_read(domain->sem);
+   up(domain->sem);
return NULL;
 }
 
 struct kobj_map *kobj_map_init(kobj_probe_t *base_probe,
-   struct subsystem *s)
+   struct subsystem *s, struct semaphore *sem)
 {
struct kobj_map *p = kmalloc(sizeof(struct kobj_map), GFP_KERNEL);
struct probe *base = kmalloc(sizeof(struct probe), GFP_KERNEL);
@@ -151,6 +151,6 @@
base->get = base_probe;
for (i = 0; i < 255; i++)
p->probes[i] = base;
-   p->sem = >rwsem;
+   p->sem = sem;
return p;
 }
diff -Nru a/drivers/block/genhd.c b/drivers/block/genhd.c
--- a/drivers/block/genhd.c 2005-02-18 13:25:04 -08:00
+++ b/drivers/block/genhd.c 2005-02-18 13:25:04 -08:00
@@ -302,7 +302,7 @@
 
 static int __init genhd_device_init(void)
 {
-   bdev_map = kobj_map_init(base_probe, _subsys);
+   bdev_map = kobj_map_init(base_probe, _subsys, _subsys_sem);
blk_dev_init();
subsystem_register(_subsys);
return 0;
diff -Nru a/fs/char_dev.c b/fs/char_dev.c
--- a/fs/char_dev.c 2005-02-18 13:25:04 -08:00
+++ b/fs/char_dev.c 2005-02-18 13:25:04 -08:00
@@ -28,7 +28,7 @@
 
 #define MAX_PROBE_HASH 255 /* random */
 
-static DEFINE_RWLOCK(chrdevs_lock);
+static DECLARE_MUTEX(chrdevs_lock);
 
 static struct char_device_struct {
struct char_device_struct *next;
@@ -54,13 +54,13 @@
 
len = sprintf(page, "Character devices:\n");
 
-   read_lock(_lock);
+   down(_lock);
for (i = 0; i < ARRAY_SIZE(chrdevs) ; i++) {
for (cd = chrdevs[i]; cd; cd = cd->next)
len += sprintf(page+len, "%3d %s\n",
   cd->major, cd->name);
}
-   read_unlock(_lock);
+   up(_lock);
 
return len;
 }
@@ -90,7 +90,7 @@
 
memset(cd, 0, sizeof(struct char_device_struct));
 
-   write_lock_irq(_lock);
+   down(_lock);
 
/* temporary */
if (major == 0) {
@@ -125,10 +125,10 @@
}
cd->next = *cp;
*cp = cd;
-   write_unlock_irq(_lock);
+   up(_lock);
return cd;
 

Re: [linux-usb-devel] cdrecord stuck in D state with USB DVD burner

[David Brownell]

On Friday 18 February 2005 1:23 pm, Chuck Berg wrote:
> On Fri, Feb 18, 2005 at 08:36:57AM -0800, David Brownell wrote:
> > > > I have a system with two USB DVD burners. If I burn a disc on both at 
> > > > the
> > > > same time, one of the dvdrecord processes hangs (unkillably stuck in the
> > > 
> > > http://marc.theaimsgroup.com/?l=linux-usb-devel=110859441830485=2
> > 
> > Chuck, that's the one I mentioned to you yesterday:  already in rc4-bk.
> 
> With 2.6.11-rc4-bk6, it works reliably, thanks.
> 


Thanks for confirming that.  LKML cc'd, in case anyone else has this issue.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: drivers/input/power.c is never built

[Oliver Neukum]

Am Freitag, 18. Februar 2005 21:40 schrieb Vojtech Pavlik:

> I wouldn't want to pass all the battery info (UPSes can be even more
> complex, able to switch on/off individual sockets, etc) through input,
> just the basic events:
> 
>   AC power on/off
>   battery full/normal/low/critical/(fail)
> 
> Then the other power-related events
> 
>   Lid open/closed
>   Power button
>   Sleep button

What is the benefit of splitting the flow of information so?

> I think that's all you need to trigger actions. You don't need the exact
> percentage of the battery, and you don't need the exact AC voltage at
> input. 

That is very debateable. I might want a quiet mode and would be
interested in notifications about thermal data and fan status. 

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: [BK] upgrade will be needed

[David S. Miller]

On Fri, 18 Feb 2005 21:45:55 +0100
"d.c" <[EMAIL PROTECTED]> wrote:

> 2) And more important, *nobody* works against "linus' bk head".

I do, %100 exclusively, for all the networking and sparc
development.

I never work against the -mm tree.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Hotplug blacklist and video devices

[Jon Smirl]

On Fri, 18 Feb 2005 16:08:22 -0500, Bill Nottingham <[EMAIL PROTECTED]> wrote:
> Under Fedora (and RHEL), they're there because we generally
> don't want to load them unless the user asked for them.

Is there a specific reason why they are blocked? 

For example I'm looking at making changes to DRM such that DRM will
require the corresponding framebuffer driver to be loaded. If you back
up further this is part of fixing X so that it won't mess with the
hardware from user space. Mode setting would come from the framebuffer
driver instead of the X 2D XAA driver.

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

Re: Hotplug blacklist and video devices

[Bill Nottingham]

Jon Smirl ([EMAIL PROTECTED]) said: 
> Why are all of the framebuffer drivers on the hotplug blacklist?

Well, that probably depends on your distribution. :)

Under Fedora (and RHEL), they're there because we generally
don't want to load them unless the user asked for them.

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

Re: [BK] upgrade will be needed

[d.c]

El Fri, 18 Feb 2005 13:34:23 -0500 (EST),
"Sean" <[EMAIL PROTECTED]> escribió:


> BK already feeds patches out at the head, surely if it's as powerful as
> you think, it could feed a free SCM too for your non-bk friends in the
> community.

Who cares, really?

1) Linux was never supposed to have a "head", but -pre/-rc diff patches

2) And more important, *nobody* works against "linus' bk head". Everyone who
is implementing something so intrusive that needs to keep track of the
"development head" developes again the _true_ "head" of the linux
kernel - akpm's tree.


In fact is surprising that so many people are bitching about BK and nobody
has complained that the -mm tree is not available through a SCM system (be it 
free
or not), which should be a issue _much_ bigger than any problem you've with
BK. I just don't get it, in my opinion people who whines about BK is people
who just don't like BK and can't accept the fact that BK is really helping
to linux development. When RMS started GNU he had to use non-free tools
and systems to work on it because everythin else sucked or it would have been
more difficult, I don't think BK is much different in this regard.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: drivers/input/power.c is never built

[Pavel Machek]

Hi!

> > Well, I'm not sure if input layer is suitable for batteries... Modern
> > battery has quite a lot of parameters. It can tell you current
> > voltage, current capacity (either mAh or mWh), design capacity, last
> > capacity at full charge, current current, battery's estimate of run
> > time (which may be better than system's estimate), ... But some
> > batteries only know percentage of energy left, and some batteries only
> > know current voltage (you can estimate %left from that). I'm not sure
> > if input system can handle all that complexity...
> 
> I wouldn't want to pass all the battery info (UPSes can be even more
> complex, able to switch on/off individual sockets, etc) through input,
> just the basic events:
> 
>   AC power on/off
>   battery full/normal/low/critical/(fail)
> 
> Then the other power-related events
> 
>   Lid open/closed
>   Power button
>   Sleep button
> 
> I think that's all you need to trigger actions. You don't need the exact
> percentage of the battery, and you don't need the exact AC voltage at
> input. 
> 
> Nice graphics battery monitors in X can gather their information from
> the platform specific sources, since they'll need it all in the greatest
> detail.

Makes sense. Other possibility is to have simple "battery status
changed" event, but that would not be enough for simple UPSes... I
guess battery full/normal/low/critical makes sense, perhaps I'd say
that battery might repeat event if something "interesting" changed.

Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdXas device

[David Lang]

I regularly burn tarballs to a CD without useing a filesystem and as long 
as I use the -pad option when burning I've had no problems reading them 
(the -pad was nessasary even when I was useing ide-scsi)

David Lang
 On Fri, 18 Feb 
2005, Bill Davidsen wrote:

Date: Fri, 18 Feb 2005 15:23:44 -0500
From: Bill Davidsen <[EMAIL PROTECTED]>
To: linux-kernel@vger.kernel.org
Newsgroups: mail.linux-kernel
Subject: Re: ide-scsi is deprecated for cd burning! Use ide-cd and give
dev=/dev/hdXas device
Kiniger, Karl (GE Healthcare) wrote:
On Thu, Feb 17, 2005 at 05:58:05PM -0500, Bill Davidsen wrote:
[EMAIL PROTECTED] wrote:
On Wed, 16 Feb 2005 10:42:21 +0100, "Kiniger, Karl (GE Healthcare)" 
said:


Have you tested the ISO on some *OTHER* hardware?  The impression 
I got
was that the cd was *burned* right by ide-cd, but when *read 
back*, it
bollixed things up at the end of the CD.
Using ide-scsi is enough to get all the data till the real end of 
the CD.

OK, so the problem is that ide-cd is able to *burn* the CD just fine, 
but it
suffers lossage when ide-cd tries to read it back...

Alan - are the sense-byte patches for ide-cd in a shape to push either 
upstream
or to -mm?
The last time I looked at this, the issue was that the user software did 
a large read and the ide-cd didn't properly return a small data block 
with no error, but rather returned an error with no data. If you get the 
size of the ISO image, you can read that with any program which doesn't 
try to read MORE than that.

Not entirely true (at least for me). I actually tried to read the last 
iso9660 data sector with a small C program (reading 2 kb) and
it failed to read the sector. Using ide-scsi I was able to read it.

sdd (from Joerg Schilling) should not try to read more than ivsize
bytes (InputVolumeSize) if that argument is given - I did not
verify with strace though.
I'll try to build a truth table for this, I'm now working with some non-iso 
data sets, so I'm a bit more interested. I would expect read() to only try to 
read one sector, so I'll just do a quick and dirty to get the size from the 
command line, seek and read.

I haven't had a problem using dd to date, as long as I know how long the data 
set was, but I'll try to have results tonight.

Thanks for your additional info on this.
--
  -bill davidsen ([EMAIL PROTECTED])
"The secret to procrastination is to put things off until the
last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
--
There are two ways of constructing a software design. One way is to make it so 
simple that there are obviously no deficiencies. And the other way is to make 
it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Hotplug blacklist and video devices

[Jon Smirl]

Why are all of the framebuffer drivers on the hotplug blacklist?

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

Re: [ACPI] Re: Call for help: list of machines with working S3

[Alistair John Strachan]

On Wednesday 16 Feb 2005 14:25, Kjartan Maraas wrote:
> tir, 15,.02.2005 kl. 17.42 +, skrev Alistair John Strachan:
> > On Tuesday 15 Feb 2005 16:16, Lorenzo Colitti wrote:
> > [snip]
> >
> > > Ok, here is the output from dmidecode (Debian package) and from lspci.
> > > I don't have acpidmp and I don't know where to get it, but if you think
> > > it's necessary I can download it if you tell me where to find it.
> >
> > Find below a diff of my dmidecode output versus Lorenzo's. Nothing much
> > to call home about.
>
> I've attached a diff against Lorenzo's too. Only difference is that my
> laptop is a nc4010, and looking here it's clear that this model doesn't
> support APM at least. I also have non-working S3. It behaves just like
> the entry in the ubuntu wiki for the nc6000 in all three cases with a
> full system running at least. I'll try init=/bin/sh later to see if that
> helps and if it does experiment with removing modules one by one...

Got it. Sorry for the radio silence, I've been busy for a few days.

I discovered that either the i2c_core.ko or i2c_i801.ko modules cause the hang 
on resume! If you stop the entire i2c subsystem from being loaded by hotplug 
(note this is the BUS driver, not the sensors driver!), then resume works 
perfectly! Presumably there's a bug in the resuming of this module.

In other news, USB devices only work after I remove uhci_hcd and ehci_hcd and 
reload them.

The s3_bios workaround allows video to kind of work, but I can't use anything 
other than vga=normal (vesafb results in corruption), and the screen is no 
longer artificially resized to fill the LCD, it's native res and centered 
(which sure is annoying).

Kjartan, I hope you isolate the driver causing you problems, as it seems these 
machines can be made, even if it is a bit of a headache.

Lorenzo, thanks for your kernel config. It made it a lot easier to debug this 
problem.

-- 
Cheers,
Alistair.

personal:   alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student:CS/CSim Undergraduate
contact:1F2 55 South Clerk Street,
Edinburgh. EH8 9PP.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 libata-dev-2.6 1/5] libata: fix command queue leak when xlat_func fails

[Jeff Garzik]

applied all five, 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: 2.6: drivers/input/power.c is never built

[Vojtech Pavlik]

On Fri, Feb 18, 2005 at 09:24:43PM +0100, Pavel Machek wrote:
> Hi!
> 
> > > > > But input layer shoudl not be used as a generic transport. I mean
> > > > > battery low, docking requests, etc has nothing to do with input.
> > > > 
> > > > Well, plugging in a power cord is a physical user action much like
> > > > closing the lid is, much like pressing the power button is, much like
> > > > pressing a key is.
> > > 
> > > What about power dying and my UPS switing on? I think it is out of
> > > input layer,
> > 
> > Yes, I was thinking about this, too. An UPS is pretty much the same
> > thing to a desktop as a battery is to a notebook. And I also got to the
> > conclusion that this is a bad idea.
> 
> Well, I'm not sure if input layer is suitable for batteries... Modern
> battery has quite a lot of parameters. It can tell you current
> voltage, current capacity (either mAh or mWh), design capacity, last
> capacity at full charge, current current, battery's estimate of run
> time (which may be better than system's estimate), ... But some
> batteries only know percentage of energy left, and some batteries only
> know current voltage (you can estimate %left from that). I'm not sure
> if input system can handle all that complexity...

I wouldn't want to pass all the battery info (UPSes can be even more
complex, able to switch on/off individual sockets, etc) through input,
just the basic events:

AC power on/off
battery full/normal/low/critical/(fail)

Then the other power-related events

Lid open/closed
Power button
Sleep button

I think that's all you need to trigger actions. You don't need the exact
percentage of the battery, and you don't need the exact AC voltage at
input. 

Nice graphics battery monitors in X can gather their information from
the platform specific sources, since they'll need it all in the greatest
detail.

PS.

full = not charging
normal = OK state, charging if AC
low = better shutdown if you don't want to stress the battery
  (namely LiIon batteries prefer not to be discharged too much)
critical = last chance to shutdown cleanly
fail = battery present, but doesn't work.

A server, while booting should wait for battery going at least to 'low'
before mounting system read/write, otherwise subsequent power failures
might cause damage.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 I/O error uevent for block devices

[Andrew Morton]

Kay Sievers <[EMAIL PROTECTED]> wrote:
>
> On Fri, Feb 18, 2005 at 11:02:32AM -0800, Andrew Morton wrote:
> > Kay Sievers <[EMAIL PROTECTED]> wrote:
> > >
> > >  > - there are numerous other places where an I/O error can be detected:
> > >  >   grep the tree for b_end_io and bio_end_io.
> > > 
> > >  You mean the mmap and direct-io stuff?
> > 
> > direct-io, certainly.  Also reiserfs, xfs, ntfs, ext3, jfs and possibly md
> > have their own I/O completion handlers.
> 
> Hmm, ok. Any idea how to propagate errors like this in a saner way? Some of
> these places don't even log errors and spreading uevents all over the place
> doesn't sounds like the best idea.
> 

I guess you should add some new generic function
handle_block_io_error(bdev, rw, sector) in ll_rw_blk.c and do whatever you
need to do inside that.  Move the ratelimited printk there, too.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: drivers/input/power.c is never built

[Oliver Neukum]

Am Freitag, 18. Februar 2005 21:14 schrieb Pavel Machek:
> Hi!
> 
> > > > Yes, there are. They can probably stay... Or we can get "battery low"
> > > > key.
> > >  
> > > We even have an event class for that, EV_PWR in the input subsystem.
> > 
> > Over that route we'd arrive at a situation where power management
> > without the input layer is impossible. Think about embedded stuff I wonder
> > whether this is viable.
> 
> I'd say it is: you need some support to get it into userspace. And I'd
> certianly prefer input infrastructure over ACPI infrastructure...

If it could replace ACPI (or some abstraction thereof), maybe.
But power management needs communication in both ways
(like setting warn levels and transfers complex things, like
queries for battery power which cannot easily be abstracted as events)

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: 2.6: drivers/input/power.c is never built

[Pavel Machek]

Hi!

> > > > But input layer shoudl not be used as a generic transport. I mean
> > > > battery low, docking requests, etc has nothing to do with input.
> > > 
> > > Well, plugging in a power cord is a physical user action much like
> > > closing the lid is, much like pressing the power button is, much like
> > > pressing a key is.
> > 
> > What about power dying and my UPS switing on? I think it is out of
> > input layer,
> 
> Yes, I was thinking about this, too. An UPS is pretty much the same
> thing to a desktop as a battery is to a notebook. And I also got to the
> conclusion that this is a bad idea.

Well, I'm not sure if input layer is suitable for batteries... Modern
battery has quite a lot of parameters. It can tell you current
voltage, current capacity (either mAh or mWh), design capacity, last
capacity at full charge, current current, battery's estimate of run
time (which may be better than system's estimate), ... But some
batteries only know percentage of energy left, and some batteries only
know current voltage (you can estimate %left from that). I'm not sure
if input system can handle all that complexity...

Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device

[Bill Davidsen]

Kiniger, Karl (GE Healthcare) wrote:
On Thu, Feb 17, 2005 at 05:58:05PM -0500, Bill Davidsen wrote:
[EMAIL PROTECTED] wrote:
On Wed, 16 Feb 2005 10:42:21 +0100, "Kiniger, Karl (GE Healthcare)" said:

Have you tested the ISO on some *OTHER* hardware?  The impression I got
was that the cd was *burned* right by ide-cd, but when *read back*, it
bollixed things up at the end of the CD.
Using ide-scsi is enough to get all the data till the real end of the CD.

OK, so the problem is that ide-cd is able to *burn* the CD just fine, but 
it
suffers lossage when ide-cd tries to read it back...

Alan - are the sense-byte patches for ide-cd in a shape to push either 
upstream
or to -mm?
The last time I looked at this, the issue was that the user software did 
a large read and the ide-cd didn't properly return a small data block 
with no error, but rather returned an error with no data. If you get the 
size of the ISO image, you can read that with any program which doesn't 
try to read MORE than that.

Not entirely true (at least for me). I actually tried to read the 
last iso9660 data sector with a small C program (reading 2 kb) and
it failed to read the sector. Using ide-scsi I was able to read it.

sdd (from Joerg Schilling) should not try to read more than ivsize
bytes (InputVolumeSize) if that argument is given - I did not
verify with strace though.
I'll try to build a truth table for this, I'm now working with some 
non-iso data sets, so I'm a bit more interested. I would expect read() 
to only try to read one sector, so I'll just do a quick and dirty to get 
the size from the command line, seek and read.

I haven't had a problem using dd to date, as long as I know how long the 
data set was, but I'll try to have results tonight.

Thanks for your additional info on this.
--
   -bill davidsen ([EMAIL PROTECTED])
"The secret to procrastination is to put things off until the
 last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 I/O error uevent for block devices

[Kay Sievers]

On Fri, Feb 18, 2005 at 11:02:32AM -0800, Andrew Morton wrote:
> Kay Sievers <[EMAIL PROTECTED]> wrote:
> >
> >  > - there are numerous other places where an I/O error can be detected:
> >  >   grep the tree for b_end_io and bio_end_io.
> > 
> >  You mean the mmap and direct-io stuff?
> 
> direct-io, certainly.  Also reiserfs, xfs, ntfs, ext3, jfs and possibly md
> have their own I/O completion handlers.

Hmm, ok. Any idea how to propagate errors like this in a saner way? Some of
these places don't even log errors and spreading uevents all over the place
doesn't sounds like the best idea.

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

[patch libata-dev-2.6 5/5] libata: update ATA pass thru opcodes

[John W. Linville]

Update ATA pass thru opcodes to match what is specified in the current
ATA pass thru spec (T10/04-262r7).

Signed-off-by: John W. Linville <[EMAIL PROTECTED]>
---
This part was controversial before, because these opcodes seemed to
overlap with some existing opcodes.  So I contacted the author of
the spec, Curtis Stevens: (quoted without permision)

"The command values in 04-262r7 are correct.  There was an erroneous value
published in the minutes that subsequently got published in SPC.  This has
been corrected.

Command sets are supposed to be qualified by the Inquiry Peripheral Device
Type.  I am a little concerned that some portions of linux depend on opcodes
being the same for all PDTs.  Using reusing opcodes will continue to happen
more frequently as new applications emerge and new devices are created.  The
SCSI opcoded are already overloaded to the point that Service Actions have
become necessary to extend the protocol."

Honestly, I don't know if that clears things up or not.  But, Curtis
seems pretty adamant that the values in the patch below (which match
rev 7 of the spec) are correct.  IMHO, at worst these values are no
more wrong than the ones already there.

So, apply this now, or apply it later... :-)

 include/scsi/scsi.h |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

--- sata-smart-2.6/include/scsi/scsi.h.orig 2005-02-01 16:22:12.390234346 
-0500
+++ sata-smart-2.6/include/scsi/scsi.h  2005-02-01 16:23:02.828491161 -0500
@@ -113,9 +113,9 @@ extern const char *const scsi_device_typ
 /* values for service action in */
 #defineSAI_READ_CAPACITY_16  0x10
 
-/* Temporary values for T10/04-262 until official values are allocated */
-#defineATA_160x85  /* 16-byte pass-thru [0x85 == 
unused]*/
-#defineATA_120xb3  /* 12-byte pass-thru [0xb3 == 
obsolete set limits command] */
+/* Values for T10/04-262r7 */
+#defineATA_160x85  /* 16-byte pass-thru */
+#defineATA_120xa1  /* 12-byte pass-thru */
 
 /*
  *  SCSI Architecture Model (SAM) Status codes. Taken from SAM-3 draft
-- 
John W. Linville
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.10-ac12 + kernbench == oom-killer: (OSDL)

[Alan Cox]

On Gwe, 2005-02-18 at 16:55, Cliff White wrote:
> Okay, with just vm.overcommit=2, things are still bad:
> http://khack.osdl.org/stp/300854/logs/TestRunFailed.console.log.txt
> 
> Suggestion for vm.overcommit_ratio ?
> Or should i repeat with later -ac ?

Thats showing up problems in the core code still. The OOM in this case
is because the kernel is deciding it is out of memory when it's merely
constipated with dirty pages for disk write by the look of it.

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/