Re: [PATCH]: x86_64: Remove unnecessary cast in prefetch()

[Serge Belyshev]

Andi Kleen <[EMAIL PROTECTED]> writes:

>> This can be fixed better by using gcc's __builtin_prefetch().
>
> I changed it to just use that. Thanks.
>
> It seems like gcc 3.1/3.2 already supported it and that's the earliest gcc
> still supported so it can be used unconditionally.
>

Hi!

Will you submit this patch for inclusion into 2.6.23?  It is important
to make kernel work with GCC 4.3 and above.  (Also note that gcc 4.2 already
smart enough to break that code, but kernel is just lucky currently).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 update] SCSI: update Kconfig help text to indicate SCSI core's widespread usage

[Stefan Richter]

FUJITA Tomonori wrote:
> On Fri, 14 Sep 2007 23:14:21 +0200 (CEST)
> Stefan Richter <[EMAIL PROTECTED]> wrote:
...
>> And one more update:
>> There is SAS too,
...
>> +  You need it
>> +  - for classic parallel SCSI hardware,
>> +  - for newer SCSI transports such as Fibre Channel, FireWire storage,
>> +SAS, or iSCSI,
> 
> There is SRP too.

I think I'll rewrite it as "for newer SCSI transports such as FireWire
storage."  ;-)

If SRP was in, can 'such as' be omitted?  "for newer SCSI transports
(Fibre Channel, FireWire storage, iSCSI, SAS, SRP),"  Or would be "for
newer SCSI transports such as Fibre Channel, FireWire storage, iSCSI,
SAS, and more," be OK?
-- 
Stefan Richter
-=-=-=== =--= -
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Nakajima, Jun]

Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > The hypervisor detection machanism is generic, and the signature
> > returned is implentation specific. Having a list of all hypervisor
> > signatures sounds fine to me as we are detecting vendor-specific
> > processor(s) in the native. And I don't expect the list is large.
> > 
> > 
> 
> I'm confused about what you're proposing.  I was thinking that a
kernel
> looking for the generic hypervisor interface would check for a
specific
> signature at some cpuid leaf, and then go about using it from there.
If
> not, how does is it supposed to detect the generic hypervisor
interface?
> 
> J

I'm suggesting that we use CPUID.0x400Y (Y: TBD, e.g. 6) for Linux
paravirtualization.  The ebx, ecx and edx return the Linux
paravirtualization features available on that hypervisor. Those features
are defined architecturally (not VMM specific).

Like CPUID.0, CPUID.0x4000 is used to detect the hypervisor with the
vendor identification string returned in ebx, edx, and ecx (as we are
doing in Xen). The eax returns the max leaf (which is 0x4002 on Xen
today). And like CPUID.1, CPUID.0x4001 returns the version number in
eax, and each VMM should be able to define a number of VMM-specific
features available in ebx, ecx, and edx returned (which are reserved,
i.e. not used in Xen today). 

Suppose we knew (i.e. tested) Xen and KVM supported Linux
paravirtualization, the Linux code does:
1. detect Xen or KVM  using CPUID.0x4000 
2. Check the version if necessary using CPUID.0x4001
3. Check the Linux paravirtualization features available using
CPUID.0x400Y.

Jun
---
Intel Open Source Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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]PCI:disable resource decode in PCI BAR detection

[Yinghai Lu]

On 9/14/07, Robert Hancock <[EMAIL PROTECTED]> wrote:
> It's not impossible at all. In fact I'm quite sure (Jesse can confirm)
> that in the case of the board he was using, it was an add-in graphics
> card where he saw this problem.
>
> The fact is that in the case of MMCONFIG overlap with PCI BARs, which
> one takes priority is completely undefined. In the case of this Intel
> chipset, clearly the PCI Express device connected to the northbridge had
> higher decode priority than the MMCONFIG aperture.

can you relocate the MMCONFIG above RAM range? for example 512G...

YH
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: On thread scheduling

[Matthias Kaehlcke]

El Sat, Sep 15, 2007 at 01:40:00AM +0300 Heikki Orsila ha dit:

> Consider a simple embedded system:
> 
> void interrupt_handler(void)
> {
>   ...
> }
> 
> int main(void)
> {
>   ...
> }
> 
> I would like to "emulate" this system with a workstation to make 
> development faster. I would create two threads, one executing the 
> main() function, and the other occasionally calling interrupt_handler(). 
> Before interrupt_handler() is called, the main() thread should be 
> stopped asynchronously.
> 
> I looked into pthreads documentation and found only pthread_kill(thread, 
> SIGTSTP) to do asynchronous stop, but then I also have to play terminal 
> tricks to avoid problems..
> 
> Is there are function to just disable scheduling of a single thread 
> without having other side-effects (such as terminal stuff)? Functions 
> like pthread_disable_scheduling(thread) and 
> pthread_enable_scheduling(thread) would be good for this..

i wonder if assigning a real time priority with
pthread_setschedparam() to the caller of your interrupt_handler()
function would solve your problem. this way the main() thread is never
scheduled when the interrupt_handler() thread is
runnable. interrupt_handler() should be as short as possible,
otherwise you risk starving of the rest of your systems processes.

-- 
Matthias Kaehlcke
Linux Application Developer
Barcelona

Representation of the world, like the world itself, is
the work of men; they describe it from their own point
 of view, which they  confuse with the absolute truth
  (Simone de Beauvoir)
 .''`.
using free software / Debian GNU/Linux | http://debian.org  : :'  :
`. `'`
gpg --keyserver pgp.mit.edu --recv-keys 47D8E5D4  `-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: crashme fault

[Randy Dunlap]

On Fri, 14 Sep 2007 22:05:17 -0700 Randy Dunlap wrote:

> On Fri, 14 Sep 2007 21:28:12 -0700 (PDT) Linus Torvalds wrote:
> 
> > On Wed, 12 Sep 2007, Randy Dunlap wrote:
> > >
> > > I run almost-daily kernel testing.  I haven't seen 'crashme' cause a
> > > kernel fault until today, and now I've seen it twice on 2.6.23-rc6-git2,
> > > x86_64.  After the first fault, I ran 'crashme' about 10 more times
> > > to get the second fault (usually for 10 minutes, one time for 30
> > > minutes).
> > 
> > Interesting. If this is reproducible for you, can you try to narrow down 
> > (with bit-bisect) roughly when it started.
> 
> It doesn't happen quite on demand.  Only 2 times in several hours
> of testing of the last few days.
> 
> > > There is very little helpful info.  RIP is strange, e.g.: 0051b446
> > > The call stack is not printed.  No kernel symbols are printed,
> > > even though I have CONFIG_KALLSYMS{_ALL}=y.
> > 
> > It looks like it's a page fault as a result of a *user*space* access, and 
> > most likely your machine would continue happily, except you have 
> > "panic_on_oops" set, so when the oops happens, it shuts the system down.
> 
> I see.
> 
> > Now, the reason I say it looks like a user space access is that you have
> > 
> > RIP: 0033:[<00510eea>]
> > RSP: 002b:7fffc9a8ec10
> > 
> > which are all user space segments. So the register contents clearly say 
> > "page fault in user space".
> > 
> > However, what makes the kernel oops (rather than just send a SIGSEGV) is 
> > that the page fault "error code" is zero (that's the number that is 
> > printed out just after the "Oops" string). For a normal user space access, 
> > you should have bit #2 set in the error code.
> > 
> > So the kernel thinks it's a kernel page fault, because the page fault 
> > error code says so. But everything else seems to indicate that it's really 
> > user mode.. It would be very interesting to hear when this started 
> > happening.
> > 
> > Even if you cannot bisect it down all the way, since you say that you do 
> > almost daily kernel testing, is this really new to 2.6.23-rc6-git2, and 
> > 2.6.23-rc6-git1 was fine? 
> 
> I'll check back thru my test logs.

I looked thru several hundred test logs and didn't find any other
occurrences of it.  Doesn't prove much.
I'll continue to run the test most of this weekend.


> > Andi, anything comes to mind?
> > 
> > Linus
> > 
> > ---
> > > [ 7487.208128] Unable to handle kernel paging request at ff019b53 
> > > RIP:
> > > [ 7487.212752]  [<00510eea>]
> > > [ 7487.218537] PGD 10c1a2067 PUD 0
> > > [ 7487.221811] Oops:  [1] SMP
> > > [ 7487.224989] CPU 2
> > > [ 7487.227024] Modules linked in: loop
> > > [ 7487.230550] Pid: 19139, comm: crashme Not tainted 2.6.23-rc6-git2 #1
> > > [ 7487.236896] RIP: 0033:[<00510eea>]  [<00510eea>]
> > > [ 7487.242925] RSP: 002b:7fffc9a8ec10  EFLAGS: 00010e83
> > > [ 7487.248234] RAX: 8c4a RBX: 004014f1 RCX: 
> > > 2b20e11c8b37
> > > [ 7487.255361] RDX: 00510ee0 RSI:  RDI: 
> > > 000a
> > > [ 7487.262489] RBP: 7fffc9a8ec10 R08: 7fffc9a8eb60 R09: 
> > > 
> > > [ 7487.269616] R10: 0008 R11: 0612 R12: 
> > > 
> > > [ 7487.276743] R13: 7fffc9a8ee00 R14:  R15: 
> > > 
> > > [ 7487.283871] FS:  2b20e13676d0() GS:81011fc75840() 
> > > knlGS:
> > > [ 7487.291952] CS:  0010 DS:  ES:  CR0: 8005003b
> > > [ 7487.297693] CR2: ff019b53 CR3: 5be6b000 CR4: 
> > > 06e0
> > > [ 7487.304821] DR0:  DR1:  DR2: 
> > > 
> > > [ 7487.311949] DR3:  DR6: 0ff0 DR7: 
> > > 0400
> > > [ 7487.319076] Process crashme (pid: 19139, threadinfo 81010683, 
> > > task 810102cf5040)
> > > [ 7487.327511]
> > > [ 7487.329009] RIP  [<00510eea>]
> > > [ 7487.332690]  RSP <7fffc9a8ec10>
> > > [ 7487.336180] CR2: ff019b53
> > > [ 7487.339810] Kernel panic - not syncing: Fatal exception
> > -
> 
> ---
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] Trace code and documentation

[Sam Ravnborg]

On Fri, Sep 14, 2007 at 09:49:31PM -0700, David Wilder wrote:
> Sam Ravnborg wrote:
> >Hi David.
> >
> >A random comment to the code.
> >Several of the struct file_operations are not declared static as
> >they should be.
> >
> >Btw. it looks good from a coding style point-of-view.
> >
> >About the name what about ktrace??
> >
> > Sam
> >
> >  
> Thanks for the comment. I sure don't want to change the name a forth 
> time, can we live with "trace"?

I do not care much about the name so no big deal for me.
I was just soo generic..

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

Re: crashme fault

[Randy Dunlap]

On Fri, 14 Sep 2007 21:28:12 -0700 (PDT) Linus Torvalds wrote:

> On Wed, 12 Sep 2007, Randy Dunlap wrote:
> >
> > I run almost-daily kernel testing.  I haven't seen 'crashme' cause a
> > kernel fault until today, and now I've seen it twice on 2.6.23-rc6-git2,
> > x86_64.  After the first fault, I ran 'crashme' about 10 more times
> > to get the second fault (usually for 10 minutes, one time for 30
> > minutes).
> 
> Interesting. If this is reproducible for you, can you try to narrow down 
> (with bit-bisect) roughly when it started.

It doesn't happen quite on demand.  Only 2 times in several hours
of testing of the last few days.

> > There is very little helpful info.  RIP is strange, e.g.: 0051b446
> > The call stack is not printed.  No kernel symbols are printed,
> > even though I have CONFIG_KALLSYMS{_ALL}=y.
> 
> It looks like it's a page fault as a result of a *user*space* access, and 
> most likely your machine would continue happily, except you have 
> "panic_on_oops" set, so when the oops happens, it shuts the system down.

I see.

> Now, the reason I say it looks like a user space access is that you have
> 
>   RIP: 0033:[<00510eea>]
>   RSP: 002b:7fffc9a8ec10
> 
> which are all user space segments. So the register contents clearly say 
> "page fault in user space".
> 
> However, what makes the kernel oops (rather than just send a SIGSEGV) is 
> that the page fault "error code" is zero (that's the number that is 
> printed out just after the "Oops" string). For a normal user space access, 
> you should have bit #2 set in the error code.
> 
> So the kernel thinks it's a kernel page fault, because the page fault 
> error code says so. But everything else seems to indicate that it's really 
> user mode.. It would be very interesting to hear when this started 
> happening.
> 
> Even if you cannot bisect it down all the way, since you say that you do 
> almost daily kernel testing, is this really new to 2.6.23-rc6-git2, and 
> 2.6.23-rc6-git1 was fine? 

I'll check back thru my test logs.

> Andi, anything comes to mind?
> 
>   Linus
> 
> ---
> > [ 7487.208128] Unable to handle kernel paging request at ff019b53 
> > RIP:
> > [ 7487.212752]  [<00510eea>]
> > [ 7487.218537] PGD 10c1a2067 PUD 0
> > [ 7487.221811] Oops:  [1] SMP
> > [ 7487.224989] CPU 2
> > [ 7487.227024] Modules linked in: loop
> > [ 7487.230550] Pid: 19139, comm: crashme Not tainted 2.6.23-rc6-git2 #1
> > [ 7487.236896] RIP: 0033:[<00510eea>]  [<00510eea>]
> > [ 7487.242925] RSP: 002b:7fffc9a8ec10  EFLAGS: 00010e83
> > [ 7487.248234] RAX: 8c4a RBX: 004014f1 RCX: 
> > 2b20e11c8b37
> > [ 7487.255361] RDX: 00510ee0 RSI:  RDI: 
> > 000a
> > [ 7487.262489] RBP: 7fffc9a8ec10 R08: 7fffc9a8eb60 R09: 
> > 
> > [ 7487.269616] R10: 0008 R11: 0612 R12: 
> > 
> > [ 7487.276743] R13: 7fffc9a8ee00 R14:  R15: 
> > 
> > [ 7487.283871] FS:  2b20e13676d0() GS:81011fc75840() 
> > knlGS:
> > [ 7487.291952] CS:  0010 DS:  ES:  CR0: 8005003b
> > [ 7487.297693] CR2: ff019b53 CR3: 5be6b000 CR4: 
> > 06e0
> > [ 7487.304821] DR0:  DR1:  DR2: 
> > 
> > [ 7487.311949] DR3:  DR6: 0ff0 DR7: 
> > 0400
> > [ 7487.319076] Process crashme (pid: 19139, threadinfo 81010683, 
> > task 810102cf5040)
> > [ 7487.327511]
> > [ 7487.329009] RIP  [<00510eea>]
> > [ 7487.332690]  RSP <7fffc9a8ec10>
> > [ 7487.336180] CR2: ff019b53
> > [ 7487.339810] Kernel panic - not syncing: Fatal exception
> -

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Jeremy Fitzhardinge]

Nakajima, Jun wrote:
> The hypervisor detection machanism is generic, and the signature
> returned is implentation specific. Having a list of all hypervisor
> signatures sounds fine to me as we are detecting vendor-specific
> processor(s) in the native. And I don't expect the list is large. 
>
>   

I'm confused about what you're proposing.  I was thinking that a kernel
looking for the generic hypervisor interface would check for a specific
signature at some cpuid leaf, and then go about using it from there.  If
not, how does is it supposed to detect the generic hypervisor interface?

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

Re: [PATCH 1/2] Trace code and documentation

[David Wilder]

Sam Ravnborg wrote:

Hi David.

A random comment to the code.
Several of the struct file_operations are not declared static as
they should be.

Btw. it looks good from a coding style point-of-view.

About the name what about ktrace??

Sam

  
Thanks for the comment. I sure don't want to change the name a forth 
time, can we live with "trace"?

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

Re: [PATCH 1/2] Trace code and documentation

[David Wilder]

Andrew Morton wrote:


+/*
+ * Based on blktrace code, Copyright (C) 2006 Jens Axboe <[EMAIL PROTECTED]>



So can we migrate blktrace to using this?
  

Yes, a blktrace patch is comming.


+   int ret;
+
+   if (trace->flags & TRACE_DISABLE_STATE)
+   return -EINVAL;
+   
+   if (count > sizeof(buf) - 1)
+   return -EINVAL;
+
+   if (copy_from_user(buf, buffer, count))
+   return -EFAULT;
+
+   buf[count] = '\0';
+   
+   if (strncmp(buf, "start", strlen("start")) == 0 ) {
+   ret = trace_start(trace);
+   if (ret)
+   return ret;
+   } else if (strncmp(buffer, "stop", strlen("stop")) == 0)
+   trace_stop(trace);
+   else
+   return -EINVAL;



What's the above code doing?  Trying to cope with trailing chars after
"start" or "stop"?  Is that actually needed?   It's the \n, I assume?
  


Yes, the typical usage is "echo start > state" and echo adds a \n.


Thanks for the comments, I will make the changes and resubmit.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Distributed storage. Move away from char device ioctls.

[J. Bruce Fields]

On Sat, Sep 15, 2007 at 12:08:42AM -0400, Jeff Garzik wrote:
> J. Bruce Fields wrote:
>> No, servers are required to support ordinary nfs operations to the
>> metadata server.
>> At least, that's the way it was last I heard, which was a while ago.  I
>> agree that it'd stink (for any number of reasons) if you ever *had* to
>> get a layout to access some file.
>> Was that your main concern?
>
> I just sorta assumed you could fall back to the NFSv4.0 mode of operation, 
> going through the metadata server for all data accesses.

Right.  So any two pNFS implementations *will* be able to talk to each
other; they just may not be able to use the (possibly higher-bandwidth)
read/write path that pNFS gives them.

> But look at that choice in practice:  you can either ditch pNFS completely, 
> or use a proprietary solution.  The market incentives are CLEARLY tilted in 
> favor of makers of proprietary solutions.

I doubt somebody would go to all the trouble to implement pNFS and then
present their customers with that kind of choice.  But maybe I'm missing
something.  What market incentives do you see that would make that more
attractive than either 1) using a standard fully-specified layout type,
or 2) just implementing your own proprietary protocol instead of pNFS?

> Overall, my main concern is that NFSv4.1 is no longer an open architecture 
> solution.  The "no-pNFS or proprietary platform" choice merely illustrate 
> one of many negative aspects of this architecture.

It's always been possible to extend NFS in various ways if you want.
You could use sideband protocols with v2 and v3, for example.  People
have done that.  Some of them have been standardized and widely
implemented, some haven't.  You could probably add your own compound ops
to v4 if you wanted, I guess.

And there's advantages to experimenting with extensions first and then
standardizing when you figure out what works.  I wish it happened that
way more often.

> Now, for the first time in NFS's history (AFAIK), the protocol is no longer 
> completely specified, completely known.  No longer a "closed loop."  
> Private layout types mean that it is _highly_ unlikely that any OS or 
> appliance or implementation will be able to claim "full NFS compatibility."

Do you know of any such "private layout types"?

This is kind of a boring argument, isn't it?  I'd rather hear whatever
ideas you have for a new distributed filesystem protocol.

--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: crashme fault

[Linus Torvalds]

On Wed, 12 Sep 2007, Randy Dunlap wrote:
>
> I run almost-daily kernel testing.  I haven't seen 'crashme' cause a
> kernel fault until today, and now I've seen it twice on 2.6.23-rc6-git2,
> x86_64.  After the first fault, I ran 'crashme' about 10 more times
> to get the second fault (usually for 10 minutes, one time for 30
> minutes).

Interesting. If this is reproducible for you, can you try to narrow down 
(with bit-bisect) roughly when it started.

> There is very little helpful info.  RIP is strange, e.g.: 0051b446
> The call stack is not printed.  No kernel symbols are printed,
> even though I have CONFIG_KALLSYMS{_ALL}=y.

It looks like it's a page fault as a result of a *user*space* access, and 
most likely your machine would continue happily, except you have 
"panic_on_oops" set, so when the oops happens, it shuts the system down.

Now, the reason I say it looks like a user space access is that you have

RIP: 0033:[<00510eea>]
RSP: 002b:7fffc9a8ec10

which are all user space segments. So the register contents clearly say 
"page fault in user space".

However, what makes the kernel oops (rather than just send a SIGSEGV) is 
that the page fault "error code" is zero (that's the number that is 
printed out just after the "Oops" string). For a normal user space access, 
you should have bit #2 set in the error code.

So the kernel thinks it's a kernel page fault, because the page fault 
error code says so. But everything else seems to indicate that it's really 
user mode.. It would be very interesting to hear when this started 
happening.

Even if you cannot bisect it down all the way, since you say that you do 
almost daily kernel testing, is this really new to 2.6.23-rc6-git2, and 
2.6.23-rc6-git1 was fine? 

Andi, anything comes to mind?

Linus

---
> [ 7487.208128] Unable to handle kernel paging request at ff019b53 RIP:
> [ 7487.212752]  [<00510eea>]
> [ 7487.218537] PGD 10c1a2067 PUD 0
> [ 7487.221811] Oops:  [1] SMP
> [ 7487.224989] CPU 2
> [ 7487.227024] Modules linked in: loop
> [ 7487.230550] Pid: 19139, comm: crashme Not tainted 2.6.23-rc6-git2 #1
> [ 7487.236896] RIP: 0033:[<00510eea>]  [<00510eea>]
> [ 7487.242925] RSP: 002b:7fffc9a8ec10  EFLAGS: 00010e83
> [ 7487.248234] RAX: 8c4a RBX: 004014f1 RCX: 
> 2b20e11c8b37
> [ 7487.255361] RDX: 00510ee0 RSI:  RDI: 
> 000a
> [ 7487.262489] RBP: 7fffc9a8ec10 R08: 7fffc9a8eb60 R09: 
> 
> [ 7487.269616] R10: 0008 R11: 0612 R12: 
> 
> [ 7487.276743] R13: 7fffc9a8ee00 R14:  R15: 
> 
> [ 7487.283871] FS:  2b20e13676d0() GS:81011fc75840() 
> knlGS:
> [ 7487.291952] CS:  0010 DS:  ES:  CR0: 8005003b
> [ 7487.297693] CR2: ff019b53 CR3: 5be6b000 CR4: 
> 06e0
> [ 7487.304821] DR0:  DR1:  DR2: 
> 
> [ 7487.311949] DR3:  DR6: 0ff0 DR7: 
> 0400
> [ 7487.319076] Process crashme (pid: 19139, threadinfo 81010683, task 
> 810102cf5040)
> [ 7487.327511]
> [ 7487.329009] RIP  [<00510eea>]
> [ 7487.332690]  RSP <7fffc9a8ec10>
> [ 7487.336180] CR2: ff019b53
> [ 7487.339810] Kernel panic - not syncing: Fatal exception
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.23-rc4-mm1

[Paul Jackson]

FUJITA Tomonori wrote:
> Can you try this patch (against 2.6.23-rc4-mm1)?
> 
> >From 592bd2049cb3e6e1f1dde7cf631879f26ddffeaa Mon Sep 17 00:00:00 2001
> From: FUJITA Tomonori <[EMAIL PROTECTED]>
> Date: Mon, 10 Sep 2007 04:17:13 +0100
> Subject: [PATCH] qla1280: sg chaining fixes
> 
> Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
> ---
>  drivers/scsi/qla1280.c |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)

This patch works for me.

I was getting the scsi errors reported earlier in
this thread, running 2.6.23-rc4-mm1 on one of our
big SGI Altix systems.

Applying this patch fixed it, so far as I can tell,
which is to say my system boots cleanly once again.

Thanks.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Distributed storage. Move away from char device ioctls.

[Jeff Garzik]

J. Bruce Fields wrote:

On Fri, Sep 14, 2007 at 06:32:11PM -0400, Jeff Garzik wrote:

J. Bruce Fields wrote:

On Fri, Sep 14, 2007 at 05:14:53PM -0400, Jeff Garzik wrote:
NFSv4.1 adds to the fun, by throwing interoperability completely out the 
window.



What parts are you worried about in particular?



I'm not worried; I'm stating facts as they exist today (draft 13):

NFS v4.1 does something completely without precedent in the history of NFS: 
 the specification is defined such that interoperability is -impossible- to 
guarantee.


pNFS permits private and unspecified layout types.  This means it is 
impossible to guarantee that one NFSv4.1 implementation will be able to 
talk another NFSv4.1 implementation.



No, servers are required to support ordinary nfs operations to the
metadata server.

At least, that's the way it was last I heard, which was a while ago.  I
agree that it'd stink (for any number of reasons) if you ever *had* to
get a layout to access some file.

Was that your main concern?


I just sorta assumed you could fall back to the NFSv4.0 mode of 
operation, going through the metadata server for all data accesses.


But look at that choice in practice:  you can either ditch pNFS 
completely, or use a proprietary solution.  The market incentives are 
CLEARLY tilted in favor of makers of proprietary solutions.  But it's a 
poor choice (really little choice at all).


Overall, my main concern is that NFSv4.1 is no longer an open 
architecture solution.  The "no-pNFS or proprietary platform" choice 
merely illustrate one of many negative aspects of this architecture.


One of NFS's biggest value propositions is its interoperability.  To 
quote some Wall Street guys, "NFS is like crack.  It Just Works.  We 
love it."


Now, for the first time in NFS's history (AFAIK), the protocol is no 
longer completely specified, completely known.  No longer a "closed 
loop."  Private layout types mean that it is _highly_ unlikely that any 
OS or appliance or implementation will be able to claim "full NFS 
compatibility."


And when the proprietary portion of the spec involves something as basic 
as accessing one's own data, I consider that a fundamental flaw.  NFS is 
no longer completely open.


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: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Zachary Amsden]

On Fri, 2007-09-14 at 16:44 -0500, Anthony Liguori wrote:

> So then each module creates a hypercall page using this magic MSR and 
> the hypervisor has to keep track of it so that it can appropriately 
> change the page on migration.  The page can only contain a single 
> instruction or else it cannot be easily changed (or you have to be able 
> to prevent the guest from being migrated while in the hypercall page).
> 
> We're really talking about identical models.  Instead of an MSR, the #GP 
> is what tells the hypervisor to update the instruction.  The nice thing 
> about this is that you don't have to keep track of all the current 
> hypercall page locations in the hypervisor.

I agree, multiple hypercall pages is insane.  I was thinking more of a
single hypercall page, fixed in place by the hypervisor, not the kernel.

Then each module can read an MSR saying what VA the hypercall page is
at, and the hypervisor can simply flip one page to switch architectures.

Zach

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-dvb] [PATCH] Userspace tuner

[Mauro Carvalho Chehab]

> The main discussion in this thread was about drivers in userspace
> are bad because the API will allow binary drivers. 

No. The focus is that userspace API is not needed at all, and the
community believe that this is a regression from all efforts that are
being done by the community to have good quality OSS software.

> The guy
> who works for Hauppauge (again I also have good contacts
> at Hauppauge Europe) writes it's bad - for no technical reason.

Please stop with personal attacks.

> I (again) don't intend to
> release binary drivers. (also keep in mind that ubuntu takes
> everything which makes things work - this matters to the enduser)

Markus, you are thinking that all the community are fool? You used to
state on your website that your intention were to release binary-only
xc5000 drivers. So, please stop with childish and assume what you've
said.

> Mauro is copying the logic of my code and writes I told him I'm ok with
> taking my code without just adding a single line of how his driver
> got developed. (I still wonder why he skipped some significant parts
> of the driver .. because he used the existing one as logic template)
> 
> http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c

The basis for tuner-xc2028 driver is tea5767. The xc2028/xc3028 drivers
is very simple:

a) load the proper firmware;
b) send one 32 bits command to select frequency + the frequency divider.

All the rest is the common logic of a tuner driver.

If you take a look at my driver, you will see that the implementation is
different, providing also those functionalities:

- provides a sync during frequency setting, needed by tm6000;
- has the logic to retrieve signal status;
- part of the firmware need to be reload every time you change a freq
(tm6000 driver needs it);
- supports just the firmwares I've identified as being used by tm6000
driver;

The only thing I used is your usbreplay.pl, as properly stated at
README.first (properly pointing to your site).

Again, please stop with personal attacks. This leads to nowhere.

---

>From my side, I've nacked your userspace tuner.

However, I keep open to accept your kernelspace em28xx/xc3028 drivers,
providing that they fits at the current V4L/DVB core.

Changes at common APIs, and especially at Kernel to userspace API should
be discussed with the community. If you accept this fact, you may also
propose improvements at the APIs.

If, after all that were discussed, you're willing to do a serious work,
please send us the patches for em28xx/xc3028 kernelspace drivers.
Otherwise, I'll kindly ask you to take your own way and stop with those
flamewars.
 
Cheers,
Mauro


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

Re: [PATCH 2/3] Consolidate host virtualization support under Virtualization menu

[Rusty Russell]

On Fri, 2007-09-14 at 09:19 -0700, Randy Dunlap wrote:
> On Fri, 14 Sep 2007 15:18:44 +1000 Rusty Russell wrote:
> 
> > We turn "Virtualization" into a menu, not a config option, since it's
> > actually only used as a menu.  Then we move lguest under that menu.
> 
> so you want to revert the 2007-july-16 merge that changes
> menu -> menuconfig and makes most of the menus consistent in
> presentation.  I'd rather not, but I don't own it.

Ok, I missed that one.  To me it seems gratuitous to create a config
option simply to control a menu.  However if that is considered the
Right Way, here is the "Just move lguest" variant.

> And Yes, lguest does need to be moved into a better location.

Indeed,
Rusty.
===
Move lguest under the virtualization menu.

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

diff -r c2893801de2a drivers/Kconfig
--- a/drivers/Kconfig   Fri Sep 14 13:24:46 2007 +1000
+++ b/drivers/Kconfig   Fri Sep 14 13:24:49 2007 +1000
@@ -87,6 +87,4 @@ source "drivers/kvm/Kconfig"
 source "drivers/kvm/Kconfig"
 
 source "drivers/uio/Kconfig"
-
-source "drivers/lguest/Kconfig"
 endmenu
diff -r c2893801de2a drivers/kvm/Kconfig
--- a/drivers/kvm/Kconfig   Fri Sep 14 13:24:46 2007 +1000
+++ b/drivers/kvm/Kconfig   Fri Sep 14 13:32:22 2007 +1000
@@ -45,4 +36,8 @@ config KVM_AMD
  Provides support for KVM on AMD processors equipped with the AMD-V
  (SVM) extensions.
 
-endif # VIRTUALIZATION
+# OK, it's a little counter-intuitive to do this, but it puts it neatly under
+# the virtualization menu.
+source drivers/lguest/Kconfig
+
+endif # VIRTUALIZATION



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Refactor hypercall infrastructure

[Rusty Russell]

On Fri, 2007-09-14 at 13:53 -0700, Jeremy Fitzhardinge wrote:
> Anthony Liguori wrote:
> > This patch refactors the current hypercall infrastructure to better support 
> > live
> > migration and SMP.  It eliminates the hypercall page by trapping the UD
> > exception that would occur if you used the wrong hypercall instruction for 
> > the
> > underlying architecture and replacing it with the right one lazily.
> >   
> 
> I guess it would be pretty rude/unlikely for these opcodes to get reused
> in other implementations...  But couldn't you make the page trap
> instead, rather than relying on an instruction fault?

That's a pain for inline hypercalls tho.  I was planning on moving
lguest to this model (which is interesting, because AFAICT this insn
will cause a #UD or #GP depending on whether VT is supported on this box
so I have to look for both).

Cheers,
Rusty.

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

Re: Distributed storage. Move away from char device ioctls.

[Mike Snitzer]

On 9/14/07, Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Evgeniy Polyakov wrote:
> > Hi.
> >
> > I'm pleased to announce fourth release of the distributed storage
> > subsystem, which allows to form a storage on top of remote and local
> > nodes, which in turn can be exported to another storage as a node to
> > form tree-like storages.
> >
> > This release includes new configuration interface (kernel connector over
> > netlink socket) and number of fixes of various bugs found during move
> > to it (in error path).
> >
> > Further TODO list includes:
> > * implement optional saving of mirroring/linear information on the remote
> >   nodes (simple)
> > * new redundancy algorithm (complex)
> > * some thoughts about distributed filesystem tightly connected to DST
> >   (far-far planes so far)
> >
> > Homepage:
> > http://tservice.net.ru/~s0mbre/old/?section=projects&item=dst
> >
> > Signed-off-by: Evgeniy Polyakov <[EMAIL PROTECTED]>
>
> My thoughts.  But first a disclaimer:   Perhaps you will recall me as
> one of the people who really reads all your patches, and examines your
> code and proposals closely.  So, with that in mind...
>
> I question the value of distributed block services (DBS), whether its
> your version or the others out there.  DBS are not very useful, because
> it still relies on a useful filesystem sitting on top of the DBS.  It
> devolves into one of two cases:  (1) multi-path much like today's SCSI,
> with distributed filesystem arbitrarion to ensure coherency, or (2) the
> filesystem running on top of the DBS is on a single host, and thus, a
> single point of failure (SPOF).

This distributed storage is very much needed; even if it were to act
as a more capable/performant replacement for NBD (or MD+NBD) in the
near term.  Many high availability applications don't _need_ all the
additional complexity of a full distributed filesystem.  So given
that, its discouraging to see you trying to gently push Evgeniy away
from all the promising work he has published.

Evgeniy, please continue your current work.

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

Re: [PATCH 2/2] Fix user namespace exiting OOPs

[Andrew Morton]

On Fri, 14 Sep 2007 13:23:55 -0500 "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:

> > run on kernel with CONFIG_USER_NS turned on will oops the
> > kernel immediately.
> > 
> > This was spotted during OpenVZ kernel testing.
> > 
> > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
> > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
> 
> Good spot.  Interesting solution :)
> 

Do we want to fix this in 2.6.23?

If so then at present I'll need to merge 

kernel-userc-use-list_for_each_entry-instead-of-list_for_each.patch
convert-uid-hash-to-hlist.patch
fix-user-namespace-exiting-oops.patch

which is rather a lot of merging at this stage - surely more than
is really needed?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.23-rc6: known regressions with patches v2

[Michal Piotrowski]

Hi all,

Here is a list of some known regressions in 2.6.23-rc6
with patches available.

Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions

List of Aces

NameRegressions fixed since 21-Jun-2007
Adrian Bunk10
Andi Kleen 7
Linus Torvalds 6
Alan Stern 5
Hugh Dickins   5
Trond Myklebust5
Andrew Morton  4
David S. Miller4
Al Viro3
Alexey Starikovskiy3
Cornelia Huck  3
Jens Axboe 3
Stephen Hemminger  3
Tejun Heo  3



Unclassified

Subject : Oops while modprobing phy fixed module
References  : http://lkml.org/lkml/2007/7/14/63
Last known good : ?
Submitter   : Gabriel C <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Satyam Sharma <[EMAIL PROTECTED]>
  Vitaly Bordug <[EMAIL PROTECTED]>
Patch1  : http://lkml.org/lkml/2007/7/18/506
Status  : patch available



ACPI

Subject : 2.6.23-rc5 hangs on boot, apparently when initializing the EC
References  : http://lkml.org/lkml/2007/9/11/369
Last known good : ?
Submitter   : Chuck Ebbert <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Alexey Starikovskiy <[EMAIL PROTECTED]>
Patch   : http://bugzilla.kernel.org/attachment.cgi?id=12673
Status  : patch was suggested



Drivercore

Subject : sysfs change of input/event devices in 2.6.23rc breaks udev
References  : http://lkml.org/lkml/2007/9/8/86
Last known good : ?
Submitter   : Anssi Hannula <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Dmitry Torokhov <[EMAIL PROTECTED]>
Patch   : http://lkml.org/lkml/2007/9/10/3
Status  : patch available



Networking

Subject : 2.6.23-rc5: possible irq lock inversion dependency detected
References  : http://lkml.org/lkml/2007/9/2/97
Last known good : ?
Submitter   : Christian Kujau <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : jamal <[EMAIL PROTECTED]>
Patch   : http://lkml.org/lkml/2007/9/11/159
Status  : patch available



Farewell!
Michal

--
LOGOUT
http://www.stardust.webpages.pl/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: rtc-ds1742.c should use resource_size_t for base address

[David Gibson]

On Fri, Sep 14, 2007 at 12:20:37PM -0500, Josh Boyer wrote:
> On Fri, 14 Sep 2007 15:54:27 +1000
> David Gibson <[EMAIL PROTECTED]> wrote:
> 
> > Currently the rtc driver, rtc-ds1742.c uses an unsigned long to store
> > the base mmio address of the NVRAM/RTC.  This breaks on systems like
> > PowerPC 440, which is a 32-bit core with 36-bit physical addresses: IO
> > on the system, including the RTC, is typically above the 4GB point,
> > and cannot fit into an unsigned long.
> > 
> > This patch fixes the problem by replacing the unsigned long with a
> > resource_size_t.  Tested on Ebony (PPC440) (with additional patches to
> > instantiate the ds1742 platform device appropriately).
> 
> Where would those additional patches be? :)

Coming, they still need polish...

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/3] 2.6.23-rc6: known regressions v2

[Michal Piotrowski]

Hi all,

Here is a list of some known regressions in 2.6.23-rc6.

Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions

List of Aces

NameRegressions fixed since 21-Jun-2007
Adrian Bunk10
Andi Kleen 7
Linus Torvalds 6
Alan Stern 5
Hugh Dickins   5
Trond Myklebust5
Andrew Morton  4
David S. Miller4
Al Viro3
Alexey Starikovskiy3
Cornelia Huck  3
Jens Axboe 3
Stephen Hemminger  3
Tejun Heo  3



FS

Subject : hanging ext3 dbench tests
References  : http://lkml.org/lkml/2007/9/11/176
Last known good : ?
Submitter   : Andy Whitcroft <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : under test -- unreproducible at present

Subject : umount triggers a warning in jfs and takes almost a minute
References  : http://lkml.org/lkml/2007/9/4/73
Last known good : ?
Submitter   : Oliver Neukum <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : unknown



Networking

Subject : build #301 failed for 2.6.23-rc6-g0d4cbb5 in 
linux/drivers/net/wireless/libertas/
References  : http://lkml.org/lkml/2007/9/11/150
Last known good : ?
Submitter   : Toralf Förster <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : unknown

Subject : zd1211rw regression, device does not enumerate
References  : http://marc.info/?l=linux-usb-devel&m=118854967709322&w=2
  http://bugzilla.kernel.org/show_bug.cgi?id=8972
Last known good : ?
Submitter   : Oliver Neukum <[EMAIL PROTECTED]>
Caused-By   : Daniel Drake <[EMAIL PROTECTED]>
  commit 74553aedd46b3a2cae986f909cf2a3f99369decc
Handled-By  : ?
Status  : unknown

Subject : NETDEV WATCHDOG: eth0: transmit timed out
References  : http://lkml.org/lkml/2007/8/13/737
Last known good : ?
Submitter   : Karl Meyer <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Francois Romieu <[EMAIL PROTECTED]>
Status  : problem is being debugged

Subject : Weird network problems with 2.6.23-rc2
References  : http://lkml.org/lkml/2007/8/11/40
Last known good : ?
Submitter   : Shish <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : unknown



Farewell!
Michal

--
LOGOUT
http://www.stardust.webpages.pl/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [3/3] 2.6.23-rc6: known regressions v2

[Michal Piotrowski]

Hi all,

Here is a list of some known regressions in 2.6.23-rc6.

Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions

List of Aces

NameRegressions fixed since 21-Jun-2007
Adrian Bunk10
Andi Kleen 7
Linus Torvalds 6
Alan Stern 5
Hugh Dickins   5
Trond Myklebust5
Andrew Morton  4
David S. Miller4
Al Viro3
Alexey Starikovskiy3
Cornelia Huck  3
Jens Axboe 3
Stephen Hemminger  3
Tejun Heo  3



Power management

Subject : powersaving degradation, (time spend in C0 goes up after a 
while)
References  : http://lkml.org/lkml/2007/9/2/142
Last known good : ?
Submitter   : Christian Leber <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : unknown

Subject : something broke resume from s2ram on mbp c1d (??? :))
References  : http://lkml.org/lkml/2007/8/28/67
Last known good : 2.6.23-rc3
Submitter   : Soeren Sonnenburg <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Rafael J. Wysocki <[EMAIL PROTECTED]>
Status  : unknown

Subject : 2.6.23-rc2 swsusp, suddenly increased uptime
References  : http://lkml.org/lkml/2007/8/12/249
Last known good : ?
Submitter   : Thomas Voegtle <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Rafael J. Wysocki <[EMAIL PROTECTED]>
Status  : problem is being debugged

Subject : resume from ram much slower
References  : http://lkml.org/lkml/2007/8/10/275
Last known good : 2.6.23-rc1 ?
Submitter   : Arkadiusz Miskiewicz <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Rafael J. Wysocki <[EMAIL PROTECTED]>
Status  : problem is being debugged



USB

Subject : usb 1-1: device not accepting address 2, error -62
References  : http://lkml.org/lkml/2007/9/14/302
Last known good : ?
Submitter   : Christian Volkmann <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : unknown



Farewell!
Michal

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

[1/3] 2.6.23-rc6: known regressions v2

[Michal Piotrowski]

Hi all,

Here is a list of some known regressions in 2.6.23-rc6.

Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions

List of Aces

NameRegressions fixed since 21-Jun-2007
Adrian Bunk10
Andi Kleen 7
Linus Torvalds 6
Alan Stern 5
Hugh Dickins   5
Trond Myklebust5
Andrew Morton  4
David S. Miller4
Al Viro3
Alexey Starikovskiy3
Cornelia Huck  3
Jens Axboe 3
Stephen Hemminger  3
Tejun Heo  3



Unclassified

Subject : crashme fault
References  : http://lkml.org/lkml/2007/9/13/19
Last known good : ?
Submitter   : Randy Dunlap <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : unknown

Subject : cpu hotplug support broken in 2.6.23-rc3/highres timers break 
cpu hotplug in 2.6.23-rc5
References  : http://lkml.org/lkml/2007/8/27/58
  http://lkml.org/lkml/2007/9/3/65
Last known good : ?
Submitter   : Pavel Machek <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : Thomas Gleixner <[EMAIL PROTECTED]>
Status  : problem is being debugged

Subject : console is messed up after resume from s2ram or switching to 
console from X
References  : http://lkml.org/lkml/2007/8/4/6
  http://lkml.org/lkml/2007/9/13/227
Last known good : ?
Submitter   : Jeff Chua <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : H. Peter Anvin <[EMAIL PROTECTED]>
  Antonino A. Daplas <[EMAIL PROTECTED]>
Workaround  : "s2ram --force --acpi_sleep 1 --vbe_mode"
Status  : problem is being debugged



CPUFREQ

Subject : ide problems: 2.6.22-git17 working, 2.6.23-rc1* is not
References  : http://lkml.org/lkml/2007/7/27/298
  http://lkml.org/lkml/2007/7/29/371
Last known good : ?
Submitter   : dth <[EMAIL PROTECTED]>
Caused-By   : Len Brown <[EMAIL PROTECTED]>
  commit f79e3185dd0f8650022518d7624c876d8929061b
Handled-By  : Len Brown <[EMAIL PROTECTED]>
Status  : problem is being debugged



FireWire

Subject : empty suspend stopped working around 2.6.23-rc4
References  : http://lkml.org/lkml/2007/9/11/326
Last known good : ?
Submitter   : Pavel Machek <[EMAIL PROTECTED]>
Caused-By   : ?
Handled-By  : ?
Status  : unknown



Farewell!
Michal

--
LOGOUT
http://www.stardust.webpages.pl/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Introduce "used_vectors" bitmap which can be used to reserve vectors.

[Rusty Russell]

On Fri, 2007-09-14 at 09:44 +0200, Andi Kleen wrote:
> On Fri, Sep 14, 2007 at 03:14:09PM +1000, Rusty Russell wrote:
> > This simplifies the io_apic.c __assign_irq_vector() logic and removes
> > the explicit SYSCALL_VECTOR check, and also allows for vectors to be
> > reserved by other mechanisms (ie. lguest).
> 
> Seems reasonable even as a cleanup.
> 
> >  
> >  int panic_on_unrecovered_nmi;
> > +
> > +DECLARE_BITMAP(used_vectors, NR_VECTORS);
> > +EXPORT_SYMBOL_GPL(used_vectors);
> 
> But what is the export good for? Since it's only used at boot
> a module cannot do anything useful with it.

Hmm, maybe I misunderstood.  I assumed that create_irq() was also called
later to get irqs for any devices which appeared later.  Although I can
at least check it's not in use.

The current lguest patch uses it like so (syscall_vector is a module
parameter):

int init_interrupts(void)
{
/* If they want some strange system call vector, reserve it now */
if (syscall_vector != SYSCALL_VECTOR
&& test_and_set_bit(syscall_vector, used_vectors)) {
printk("lg: couldn't reserve syscall %u\n", syscall_vector);
return -EBUSY;
}
return 0;
}

Thanks,
Rusty.


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

Re: [PATCH 4/4] [-mm patch] Add a prefix "VMCOREINFO_" to the vmcoreinfo macros.

[Andrew Morton]

On Fri, 14 Sep 2007 12:00:18 +0900 "Ken'ichi Ohmichi" <[EMAIL PROTECTED]> wrote:

> [4/4] Add a prefix "VMCOREINFO_" to the vmcoreinfo macros.
>Old vmcoreinfo macros were defined as generic names SYMBOL/SIZE/OFFSET
>/LENGTH/CONFIG, and it is impossible to grep for them. So these names
>should be changed. This discussion is the following:
>http://www.ussg.iu.edu/hypermail/linux/kernel/0709.1/0415.html

I already had these patches, except for #4.

Your email client is space-stuffing the patches, so I have to do s/^ / /g
to apply them.  Please see
http://mbligh.org/linuxdocs/Email/Clients/Thunderbird and/or the
soon-to-be-merged Documentation/email-clients.txt

I plan on folding all of

add-vmcoreinfo.patch
add-vmcore-cleanup-the-coding-style-according-to-andrews-comments.patch
add-vmcore-add-nodemask_ts-size-and-nr_free_pagess-value-to-vmcoreinfo_data.patch
add-vmcore-use-the-existing-ia64_tpa-instead-of-asm-code.patch
add-vmcore-add-a-prefix-vmcoreinfo_-to-the-vmcoreinfo-macros.patch

into a single patch for upstream.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-dvb] [PATCH] Userspace tuner

[Markus Rechberger]

On 9/14/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 14, 2007, Markus Rechberger wrote:
> >
> > people do contribute to the em28xx project.
> ...
> > there's also an active and even problem solving oriented ML available:
> > http://mcentral.de/pipermail/em28xx/
> >
> > Also if you look at the mercurial code you'll see several people
> > contributing to that project.
>
> Of course, people who own such a device and want to use
> it with Linux have no choice but to work with you.
> And you do a good job for your users, you support them
> well and in return they contribute info and patches
> to support new devices.
>
> But the thing is that at mcentral.de you're the man at the top,

why is it mcentral.de at the moment? I started several discussions about
the whole topic. The thing which is in v4l-dvb on linuxtv does not satisfy
any requirements, also further additions will be hard to achieve with it.

> and your users will hardly disagree with you on core
> technical questions. (Well, admittedly I'm speculating
> here as I don't read your em28xx list.)
>

they can disagree, I even pointed out to design flaws lately when
some users posted bugreports.

> On for drivers/media/ OTOH you are just one developer among others,
> and some of them choose to disagree with you. Even worse,
> IIRC there wasn't even _a single_ other developer willing
> to ACK your offending patch.
>

the current patch isn't offending anymore, see it as a chance I'm
giving you the chance to acknowlidge what has been done now from
my side.
The main discussion in this thread was about drivers in userspace
are bad because the API will allow binary drivers. The guy
who works for Hauppauge (again I also have good contacts
at Hauppauge Europe) writes it's bad - for no technical reason.

If someone points out that it is bad (after reading the whole thread)
why don't we put X.org, bash, well everything into the kernel?
GPL is the saviour seems to be the saviour for some people in this
world, but in the end it's still if people want to go that way.
Much work has been done by other people before, my work
is also just an additional contribution and I (again) don't intend to
release binary drivers. (also keep in mind that ubuntu takes
everything which makes things work - this matters to the enduser)

Hey I can also write I can help you to get things right with some other
people, and I can financially support people by giving away
hardware and even specs for free in some cases. Who is able
to do that from the old crufted v4l/dvb guys?

Manu throws his drivers over the wall to the OSS community, although
I don't mind.
Mauro is copying the logic of my code and writes I told him I'm ok with
taking my code without just adding a single line of how his driver
got developed. (I still wonder why he skipped some significant parts
of the driver .. because he used the existing one as logic template)

http://linuxtv.org/hg/~mchehab/tm6000-new/log/14352ab89146/linux/drivers/media/video/tuner-xc2028.c
(not looking at the specific changeset but he copied the firmware
loading instructions without taking care about the copyright?)

> Now, doesn't _that_ get you thinking?
>

oh yes.

Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-dvb] [PATCH] Userspace tuner

[Mauro Carvalho Chehab]

> Beside that I'm just curious how much did you contribute
> during the last 2 years to the lkml/linux kernel, and how much
> do you want to contribute in future? (also from my side
> talk is cheap (even for me) but getting something done costs
> quite some time and feedback from other people)

Contributing doesn't necessarily means submitting patches. There are
several good guys at the community offering very valuable contributions,
like patchset reviews, good comments, userspace experiences, etc.

Johannes does a very impressive work of maintaining, almost alone,
LinuxTV website, upgrading the system, monitoring disk spaces, taking
backups, etc. Also, he is always available to discuss the most important
changes at APIs and to defend the Open Source community, providing his
very clear point of view.

Thank you, Johannes for all your good work!

-- 
Cheers,
Mauro

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

Re: [PATCH 1/2] Trace code and documentation

[Randy Dunlap]

On Fri, 14 Sep 2007 18:08:40 -0700 Andrew Morton wrote:

> > Trace - Provides tracing primitives
> > 
> > ...
> >
> > +config TRACE
> > +   bool "Trace setup and control"
> > +   select RELAY
> > +   select DEBUG_FS
> > +   help
> > + This option provides support for the setup, teardown and control
> > + of tracing channels from kernel code.  It also provides trace
> > + information and control to userspace via a set of debugfs control
> > + files.  If unsure, say N.
> > +
> 
> select is evil - you really want to avoid using it.

I checked when I reviewed(?) this patch.  There are a few other
places that select also (IIRC, the blktrace code does), but most of
them use depends on.

> The problem is where you select a symbol whose dependencies aren't met. 
> Kconfig resolves this incompatibility by just not selecting the thing you
> wanted, iirc.  So your CONFIG_SYSFS=n, CONFIG_TRACE=y kernel won't build.
> 
> > +/*
> > + * Based on blktrace code, Copyright (C) 2006 Jens Axboe <[EMAIL 
> > PROTECTED]>
> 
> So can we migrate blktrace to using this?

> > +static ssize_t sub_size_read(struct file *filp, char __user *buffer,
> > +size_t count, loff_t *ppos)
> > +{
> > +   struct trace_info *trace = filp->private_data;
> > +   char buf[32];
> > +
> > +   snprintf(buf, sizeof(buf), "%u\n",
> > +(unsigned int)trace->rchan->subbuf_size);
> 
> Use %tu to print a size_t, rather than the typecast.

Eh?
Use %zu to print a size_t.  Use %tu to print a ptrdiff_t.


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Add ELF note with Linux version

[Roland McGrath]

> Yes, binutils can be pretty fragile with notes about.  In this case it
> seems to be a specific problem with build-id; I'm not really sure what
> build-id actually does.

The thing about the build ID section that brings up issues with linking is
that it is a SHF_ALLOC, SHT_NOTE section.  As you mentioned, this is a
general, straightforward, and well-defined thing in ELF.  But in practice,
there were not previously SHF_ALLOC note sections used with custom linker
scripts like the kernel's.  (They are used every day in normal executables
and DSOs, but those don't use custom linker scripts.)


Thanks,
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: [linux-dvb] [PATCH] Userspace tuner

[Markus Rechberger]

On 9/14/07, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:
> On Fri, Sep 14, 2007, Markus Rechberger wrote:
> >
> > people do contribute to the em28xx project.
> ...
> > there's also an active and even problem solving oriented ML available:
> > http://mcentral.de/pipermail/em28xx/
> >
> > Also if you look at the mercurial code you'll see several people
> > contributing to that project.
>
> Of course, people who own such a device and want to use
> it with Linux have no choice but to work with you.
> And you do a good job for your users, you support them
> well and in return they contribute info and patches
> to support new devices.
>
> But the thing is that at mcentral.de you're the man at the top,
> and your users will hardly disagree with you on core
> technical questions. (Well, admittedly I'm speculating
> here as I don't read your em28xx list.)
>

they can. Put technical issues infront of everything also see the
whole picture that userspace tv applications have to support
all the codecs which are available.

> On for drivers/media/ OTOH you are just one developer among others,
> and some of them choose to disagree with you. Even worse,
> IIRC there wasn't even _a single_ other developer willing
> to ACK your offending patch.
>

there was not a single developer of the old crufted developers who
didn't bring the project forward during the last 2 years.
yes you're right.

> Now, doesn't _that_ get you thinking?
>

it gets me thinking. Some core developers who I met during
the last few weeks (kernel summit, suse conference in czech)
told me to go on with it actually because the final plan isn't that
bad.. I don't expect anyone of the old crufted v4l/dvb (well many
of them already left the party) will join the game...
(I'll leave that open here) spend some time read the whole history
of this thread and it will show up what this all is targeting at.
I'll answer your questions with technical reasons why I'm doing
all that stuff that way if you'll just ask.
Someone told me during the last 2 weeks
 "but v4l2 was about to solve all those problems" it didn't. (point)
and I think I explained good enough why all that crap still goes
on as it is.

Beside that I'm just curious how much did you contribute
during the last 2 years to the lkml/linux kernel, and how much
do you want to contribute in future? (also from my side
talk is cheap (even for me) but getting something done costs
quite some time and feedback from other people)

Markus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Uclinux-dist-devel] Re: [PATCH] Blackfin arch: add some missing syscall

[Mike Frysinger]

On 9/14/07, Bryan Wu <[EMAIL PROTECTED]> wrote:
> On Fri, 2007-09-14 at 02:44 -0400, Mike Frysinger wrote:
> > On 9/14/07, Bryan Wu <[EMAIL PROTECTED]> wrote:
> > > On Thu, 2007-09-13 at 13:03 +0200, Bernd Schmidt wrote:
> > > > Bryan Wu wrote:
> > > > >>> but mremap doesn't -- there's even an implementation in mm/nommu.c.
> > > > >>> Could you check the rest of these over to see if they truly don't 
> > > > >>> need
> > > > >>> to be implemented for no-mmu?
> > > > >> you're right we want mremap, my fault
> > > > >>
> > > > >
> > > > > Yes, I do think so, both sys_mremap and sys_munmap are implemented in
> > > > > mm/nommu.c. How do think of this, Bernd?
> > > >
> > > > There's a mremap in nommu.c, but it doesn't do a lot that is useful.
> > > > With some further mm changes in our tree, it's little more than a fancy
> > > > way of saying munmap, and uClibc does not use it, so there's no
> > > > compelling need to have it in userspace.
> > >
> > > Make sense. So currently Blackfin uClinux use the mremap/munmap in
> > > uClibc?
> >
> > most functions like this dont have any real libc component ... uClibc
> > will define userspace symbols that merely make a syscall iff the __NR_
> > exists in the headers
> >
> > if we have __NR_mremap in our unistd.h, we'll automagically get the
> > mremap() symbol in uClibc which simply passes along the args to the
> > kernel
>
> Yes, I know this. But currently, __NR_mremap does not exit in Blackfin
> unistd.h:
> /* 163 __NR_mremap */.
>
> So the implementation of this kind syscalls should be in uClibc, right?

no ... if the kernel supports it, uClibc supports ... if the kernel
doesnt support, uClibc doesnt support it

adding a ghetto userspace implementation to workaround this is weak
... that'll just mean random bugs may crop up on us that dont exist
for any other architecture simply because we opted not to hook up the
common kernel version

either we support it and have the kernel pull in the common one or we
dont support ... no middle ground here
-mike
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] MAINTAINERS : mpt fusion mailing list change

[Eric Moore]

Mailing list changed. The former list at [EMAIL PROTECTED] is no
longer in service. Please use the new email provided listed in this patch.

Signed-off-by: Eric Moore <[EMAIL PROTECTED]>

diff -uarpN b/MAINTAINERS a/MAINTAINERS
--- b/MAINTAINERS   2007-08-15 16:33:58.0 -0600
+++ a/MAINTAINERS   2007-09-14 19:20:34.0 -0600
@@ -2375,7 +2375,7 @@ LSILOGIC MPT FUSION DRIVERS (FC/SAS/SPI)
 P: Eric Moore
 M: [EMAIL PROTECTED]
 M: [EMAIL PROTECTED]
-L: [EMAIL PROTECTED]
+L: [EMAIL PROTECTED]
 L: [EMAIL PROTECTED]
 W: http://www.lsilogic.com/support
 S: Supported
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] Trace code and documentation

[Andrew Morton]

> Trace - Provides tracing primitives
> 
> ...
>
> +config TRACE
> + bool "Trace setup and control"
> + select RELAY
> + select DEBUG_FS
> + help
> +   This option provides support for the setup, teardown and control
> +   of tracing channels from kernel code.  It also provides trace
> +   information and control to userspace via a set of debugfs control
> +   files.  If unsure, say N.
> +

select is evil - you really want to avoid using it.

The problem is where you select a symbol whose dependencies aren't met. 
Kconfig resolves this incompatibility by just not selecting the thing you
wanted, iirc.  So your CONFIG_SYSFS=n, CONFIG_TRACE=y kernel won't build.

> +/*
> + * Based on blktrace code, Copyright (C) 2006 Jens Axboe <[EMAIL PROTECTED]>

So can we migrate blktrace to using this?

> +static ssize_t state_write(struct file *filp, const char __user *buffer,
> +size_t count, loff_t *ppos)
> +{
> + struct trace_info *trace = filp->private_data;
> + char buf[16] = { '\0' };

this initialisation isn't needed and will waste cycles.

> + int ret;
> +
> + if (trace->flags & TRACE_DISABLE_STATE)
> + return -EINVAL;
> + 
> + if (count > sizeof(buf) - 1)
> + return -EINVAL;
> +
> + if (copy_from_user(buf, buffer, count))
> + return -EFAULT;
> +
> + buf[count] = '\0';
> + 
> + if (strncmp(buf, "start", strlen("start")) == 0 ) {
> + ret = trace_start(trace);
> + if (ret)
> + return ret;
> + } else if (strncmp(buffer, "stop", strlen("stop")) == 0)
> + trace_stop(trace);
> + else
> + return -EINVAL;

What's the above code doing?  Trying to cope with trailing chars after
"start" or "stop"?  Is that actually needed?   It's the \n, I assume?

> + return count;
> +}
> +
> +
> +static struct file_operations state_fops = {
> + .owner  = THIS_MODULE,
> + .open   = state_open,
> + .read   = state_read,
> + .write  = state_write,
> +};
> +
> +
> +static void remove_root(struct trace_info *trace)
> +{
> + if (trace->root->root && simple_empty(trace->root->root)) {
> + debugfs_remove(trace->root->root);
> + list_del(&trace->root->list);
> + kfree(trace->root);
> + trace->root = NULL;
> + }
> +}
> +
> +
> +static void remove_tree(struct trace_info *trace)
> +{
> + mutex_lock(&trace_mutex);
> +
> + debugfs_remove(trace->dir);
> +
> + if (--trace->root->users == 0)
> + remove_root(trace);
> +
> + mutex_unlock(&trace_mutex);
> +}

We usually only put a single blank line between functions.  Two is just a
waste of screen space.

> +
> +
> +/*
> + * Creates the trace_root if it's not found.
> + */
>
> ...
>
> +static ssize_t sub_size_read(struct file *filp, char __user *buffer,
> +  size_t count, loff_t *ppos)
> +{
> + struct trace_info *trace = filp->private_data;
> + char buf[32];
> +
> + snprintf(buf, sizeof(buf), "%u\n",
> +  (unsigned int)trace->rchan->subbuf_size);

Use %tu to print a size_t, rather than the typecast.

> + return simple_read_from_buffer(buffer, count, ppos, buf, strlen(buf));
> +}
> +
>
> ...
>
> +static ssize_t nr_sub_read(struct file *filp, char __user *buffer,
> +size_t count, loff_t *ppos)
> +{
> + struct trace_info *trace = filp->private_data;
> + char buf[32];
> +
> + snprintf(buf, sizeof(buf), "%u\n",
> +  (unsigned int)trace->rchan->n_subbufs);

Ditto.  (It's unobvious why n_subbufs is a size_t)

> + return simple_read_from_buffer(buffer, count, ppos, buf, strlen(buf));
> +}
> +
>
> ...
>
> +static void remove_controls(struct trace_info *trace)
> +{
> + if (trace->state_file)
> + debugfs_remove(trace->state_file);
> + if (trace->dropped_file)
> + debugfs_remove(trace->dropped_file);
> + if (trace->reset_consumed_file)
> + debugfs_remove(trace->reset_consumed_file);
> + if (trace->nr_sub_file)
> + debugfs_remove(trace->nr_sub_file);
> + if (trace->sub_size_file)
> + debugfs_remove(trace->sub_size_file);

debugfs_remove(NULL) is legal: all the above tests can be removed.

> + if (trace->dir)
> + remove_tree(trace);
> +}
> +
>
> ...
>
> + *   trace_setup: create a new trace trace handle
> + *
> + *   @root: The root directory name in the root of the debugfs
> + *  to place trace directories. Created as needed.
> + *   @name: Trace directory name, created in @root
> + *   @buf_size: size of the relay sub-buffers
> + *   @buf_nr: number of relay sub-buffers
> + *   @flags: Option selection (see GTSC channel flags definitions)
> + *   default values when flags=0 are: use per-CPU buffering,
> + *   use non-overwrite mode. See Documentation/trace.txt for details.
> + *
> + *   returns

RE: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Nakajima, Jun]

Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > Today, 3 CPUID leaves starting from 0x4000_ are defined in a
generic
> > fashion (hypervisor detection, version, and hypercall page), and
those
> > are the ones used by Xen today. We should extend those leaves (e.g.
> > starting from 0x4000_0003) for the vmm-independent features as well.
> > 
> > If Xen needs additional Xen-specific features, we need to allocate
some
> > leaves for those (e.g. 0x4000_1000)
> 
> But the signature is "XenVMMXenVMM", which isn't very generic.  If
we're
> presenting a generic interface, it needs to have a generic signature,
> otherwise guests will need to have a list of all hypervisor signatures
> supporting their interface.  Since 0x4000 has already been
> established as the base leaf of the hypervisor-specific interfaces,
the
> generic interface will have to be elsewhere.

The hypervisor detection machanism is generic, and the signature
returned is implentation specific. Having a list of all hypervisor
signatures sounds fine to me as we are detecting vendor-specific
processor(s) in the native. And I don't expect the list is large. 

> 
> J

Jun
---
Intel Open Source Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 - Ketchup] update for new RT patch location

[Steven Rostedt]

With the move of the RT patch to kernel.org, here's a patch to ketchup
to accommodate the change (/me puts on his snake suit).

I also updated it to try a non zipped patch if the zipped versions are
not there. This is because the main patches are zipped, but the archived
"older" versions are not zipped, but will probably be in the future.

Signed-off-by: Steven Rostedt

Index: x/ketchup
===
--- x.orig/ketchup  2007-09-14 20:01:06.0 -0400
+++ x/ketchup   2007-09-14 20:37:18.0 -0400
@@ -231,6 +231,12 @@ def latest_ck(url, pat):
 l.sort(compare_ver)
 return l[-1]
 
+def latest_rt(url, pat):
+url = kernel_url + '/projects/rt/'
+url += last(url)
+part = last(url)
+return part[:-1]
+
 def latest_dir(url, pat):
 """Find the latest link matching pat at url after sorting"""
 p = []
@@ -361,6 +367,11 @@ def trydownload(urls, f, sign):
 if download(url2, f2):
 if not sign or verify(url2, f2, sign):
 return f2
+   f2 = f[:-4]
+   url2 = url[:-4]
+   if download(url2, f2):
+if not sign or verify(url2, f2, sign):
+return f2
 return None
 
 def get_patch(ver):
@@ -592,11 +603,11 @@ version_info = {
  kernel_url + "/people/mbligh/%(prebase)s/patch-%(full)s.bz2",
  r'patch-(2.6.*?).bz2',
  1, "Martin Bligh's random collection 'o crap"),
-'2.6-rt': (latest_dir,
-   ["http://people.redhat.com/mingo/"; +
-"realtime-preempt/patch-%(full)s",
-"http://people.redhat.com/mingo/"; +
-"realtime-preempt/older/patch-%(full)s"],
+'2.6-rt': (latest_rt,
+   [kernel_url + "/projects/rt/" +
+   "patch-%(full)s.bz2",
+   kernel_url + "/projects/rt/older/" +
+   "patch-%(full)s.bz2"],
r'patch-(2.6.*?)',
0, "Ingo Molnar's realtime-preempt kernel"),
 '2.6-ck': (latest_ck,


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

Re: [PATCH 0/2] A kernel tracing interface

[Andrew Morton]

On Thu, 13 Sep 2007 16:43:09 -0700
David Wilder <[EMAIL PROTECTED]> wrote:

> These patches provide a kernel tracing interface called "trace".
> 
> The motivation for "trace" is to:
> - Provide a simple set of tracing primitives that will utilize the high-
>   performance and low-overhead of relayfs for passing traces data from
>   kernel to user space.
> - Provide a common user interface for managing kernel traces.
> - Allow for binary as well as ascii trace data.
> - Incorporate features from the systemtap runtime that are
>   useful to others.
> 
> History- Versions of this code have been submitted for review under
> a couple of different names.  The original submission was called UTT,
> it was later re-submitted as GTSC.   Christoph Hellwig commented "The
> code looks fine ...but the name is just dumb".  Following Christoph's
> advice, I changed the name to simply "Trace".
> 
> This patch addresses review comments made by Christoph Hellwig and Mathieu
> Desnoyers.  Changes include the addition of a mutex and synchronization
> protecting trace state changes (using RCU) and the reduction of the
> number of exports.
> 
> Patches are against 2.6.23-rc4-mm1
> 
> Required patches:
> 1/2 Trace code and documentation
> 2/2 Relay reset consumed  (required for trace's "rewind" feature")
> 
> Signed-off-by: David Wilder <[EMAIL PROTECTED]>

Well the code looks neat and easy enough to merge.

What exactly is the relationship between this and systemtap and kprobes and
all the other tracing things which people are doing?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: In search of 10gbps cards/shootout in Linux?

[David Miller]

From: Bill Fink <[EMAIL PROTECTED]>
Date: Mon, 10 Sep 2007 00:02:50 -0400

> I haven't done any comparisons with other vendor offerings, but I can
> highly recommend the Myricom PCI-Express (8x) 10-GigE NICs.  They only
> cost about $900 and can do full unidirectional 10-GigE line rate.  And
> as a 10-GigE router, they can do full bidirectional 10-GigE line rate
> IP forwarding.  Note the choice of system/motherboard/CPU is as
> important as the choice of NIC in achieving maximum performance.

The only thing I don't like about the myri10ge cards is that
they lack VLAN offloading in hardware.

Strangely this appears to be common amongst 10gb parts :-/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [00/41] Large Blocksize Support V7 (adds memmap support)

[Goswin von Brederlow]

Christoph Lameter <[EMAIL PROTECTED]> writes:

> On Fri, 14 Sep 2007, Christoph Lameter wrote:
>
>> an -ENOMEM. Given the quantities of pages on todays machine--a 1 G machine 
>
> s/1G/1T/ Sigh.
>
>> has 256 milllion 4k pages--and the unmovable ratios we see today it 
>
> 256k for 1G.

256k == 64 pages for 1GB ram or 256k pages == 1Mb?

MfG
Goswin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [00/41] Large Blocksize Support V7 (adds memmap support)

[Goswin von Brederlow]

Mel Gorman <[EMAIL PROTECTED]> writes:

> On Fri, 2007-09-14 at 18:10 +0200, Goswin von Brederlow wrote:
>> Nick Piggin <[EMAIL PROTECTED]> writes:
>> 
>> > In my attack, I cause the kernel to allocate lots of unmovable allocations
>> > and deplete movable groups. I theoretically then only need to keep a
>> > small number (1/2^N) of these allocations around in order to DoS a
>> > page allocation of order N.
>> 
>> I'm assuming that when an unmovable allocation hijacks a movable group
>> any further unmovable alloc will evict movable objects out of that
>> group before hijacking another one. right?
>> 
>
> No eviction takes place. If an unmovable allocation gets placed in a
> movable group, then steps are taken to ensure that future unmovable
> allocations will take place in the same range (these decisions take
> place in __rmqueue_fallback()). When choosing a movable block to
> pollute, it will also choose the lowest possible block in PFN terms to
> steal so that fragmentation pollution will be as confined as possible.
> Evicting the unmovable pages would be one of those expensive steps that
> have been avoided to date.

But then you can have all blocks filled with movable data, free 4K in
one group, allocate 4K unmovable to take over the group, free 4k in
the next group, take that group and so on. You can end with 4k
unmovable in every 64k easily by accident.

There should be a lot of preassure for movable objects to vacate a
mixed group or you do get fragmentation catastrophs. Looking at my
little test program evicting movable objects from a mixed group should
not be that expensive as it doesn't happen often. The cost of it
should be freeing some pages (or finding free ones in a movable group)
and then memcpy. With my simplified simulation it never happens so I
expect it to only happen when the work set changes.

>> > And it doesn't even have to be a DoS. The natural fragmentation
>> > that occurs today in a kernel today has the possibility to slowly push out
>> > the movable groups and give you the same situation.
>> 
>> How would you cause that? Say you do want to purposefully place one
>> unmovable 4k page into every 64k compund page. So you allocate
>> 4K. First 64k page locked. But now, to get 4K into the second 64K page
>> you have to first use up all the rest of the first 64k page. Meaning
>> one 4k chunk, one 8k chunk, one 16k cunk, one 32k chunk. Only then
>> will a new 64k chunk be broken and become locked.
>
> It would be easier early in the boot to mmap a large area and fault it
> in in virtual address order then mlock every a page every 64K. Early in
> the systems lifetime, there will be a rough correlation between physical
> and virtual memory.
>
> Without mlock(), the most successful attack will like mmap() a 60K
> region and fault it in as an attempt to get pagetable pages placed in
> every 64K region. This strategy would not work with grouping pages by
> mobility though as it would group the pagetable pages together.

But even with mlock the virtual pages should still be movable. So if
you evict movable objects from mixed group when needed all the
pagetable pages would end up in the same mixed group slowly taking it
over completly. No fragmentation at all. See how essential that
feature is. :)

> Targetted attacks on grouping pages by mobility are not very easy and
> not that interesting either. As Nick suggests, the natural fragmentation
> over long periods of time is what is interesting.
>
>> So to get the last 64k chunk used all previous 32k chunks need to be
>> blocked and you need to allocate 32k (or less if more is blocked). For
>> all previous 32k chunks to be blocked every second 16k needs to be
>> blocked. To block the last of those 16k chunks all previous 8k chunks
>> need to be blocked and you need to allocate 8k. For all previous 8k
>> chunks to be blocked every second 4k page needs to be used. To alloc
>> the last of those 4k pages all previous 4k pages need to be used.
>> 
>> So to construct a situation where no continious 64k chunk is free you
>> have to allocate  - 64k - 32k - 16k - 8k - 4k (or there
>> about) of memory first. Only then could you free memory again while
>> still keeping every 64k page blocked. Does that occur naturally given
>> enough ram to start with?
>> 
>
> I believe it's very difficult to craft an attack that will work in a
> short period of time. An attack that worked on 2.6.22 as well may have
> no success on 2.6.23-rc4-mm1 for example as grouping pages by mobility
> does it make it exceedingly hard to craft an attack unless the attacker
> can mlock large amounts of memory.
>
>> 
>> Too see how bad fragmentation could be I wrote a little progamm to
>> simulate allocations with the following simplified alogrithm:
>> 
>> Memory management:
>> - Free pages are kept in buckets, one per order, and sorted by address.
>> - alloc() the front page (smallest address) out of the bucket of the
>>   right order or recursively splits the next higher bucket.
>> -

Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Jeremy Fitzhardinge]

Nakajima, Jun wrote:
> Today, 3 CPUID leaves starting from 0x4000_ are defined in a generic
> fashion (hypervisor detection, version, and hypercall page), and those
> are the ones used by Xen today. We should extend those leaves (e.g.
> starting from 0x4000_0003) for the vmm-independent features as well.
>
> If Xen needs additional Xen-specific features, we need to allocate some
> leaves for those (e.g. 0x4000_1000)

But the signature is "XenVMMXenVMM", which isn't very generic.  If we're
presenting a generic interface, it needs to have a generic signature,
otherwise guests will need to have a list of all hypervisor signatures
supporting their interface.  Since 0x4000 has already been
established as the base leaf of the hypervisor-specific interfaces, the
generic interface will have to be elsewhere.

J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] State limits to safety of _safe iterators

[Andrew Morton]

On Thu, 13 Sep 2007 08:21:07 -0700
"Paul E. McKenney" <[EMAIL PROTECTED]> wrote:

> On Thu, Sep 13, 2007 at 02:22:45AM -0700, Matthew Helsley wrote:
> > On Wed, 2007-09-12 at 18:01 -0700, Paul E. McKenney wrote:
> > > The _safe list iterators make a blanket statement about how they are
> > > safe against removal.  This patch, inspired by private conversations
> > > with people who unwisely but perhaps understandably took this blanket
> > > statement at its word, adds comments stating limits to this safety.
> > > 
> > > Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
> > > ---
> > > 
> > >  list.h |   42 ++
> > >  1 file changed, 42 insertions(+)
> > > 
> > > diff -urpNa -X dontdiff linux-2.6.22/include/linux/list.h 
> > > linux-2.6.22-safedoc/include/linux/list.h
> > > --- linux-2.6.22/include/linux/list.h 2007-07-08 16:32:17.0 
> > > -0700
> > > +++ linux-2.6.22-safedoc/include/linux/list.h 2007-09-12 
> > > 17:45:38.0 -0700
> > > @@ -472,6 +472,12 @@ static inline void list_splice_init_rcu(
> > >   * @pos: the &struct list_head to use as a loop cursor.
> > >   * @n:   another &struct list_head to use as temporary storage
> > >   * @head:the head for your list.
> > > + *
> > > + * Please note that this is safe only against removal by the code in
> > 
> > I'm not trying to be snarky but how far should we go before expecting
> > folks to read the macros? Depending on the answer you may also want to
> > mention that without additional additional code it's safe only against
> > removal of the list element at pos.
> 
> Good question.  In fact, I would have agreed with you before coming
> across people who in my experience are generally reasonably well clued
> in who were confused about this.
> 

hmm, yes, I must say, one would need to be fairly thick to expect a little
helper macro to protect you from activity on other CPUs.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Resend][PATCH -mm] Hibernation: Enter platform hibernation state in a consistent way (rev. 4)

[Rafael J. Wysocki]

On Saturday, 15 September 2007 01:37, Andrew Morton wrote:
> On Wed, 12 Sep 2007 13:14:08 +0200
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> 
> > +   if (!hibernation_ops)
> > +   return -ENOSYS;
> > +
> > +   /*
> > +* We have cancelled the power transition by running
> > +* hibernation_ops->finish() before saving the image, so we should let
> > +* the firmware know that we're going to enter the sleep state after all
> > +*/
> > +   error = hibernation_ops->start();
> > +   if (error)
> > +   return error;
> > +
> > +   suspend_console();
> > +   error = device_suspend(PMSG_SUSPEND);
> > +   if (error)
> > +   return error;
> > +
> > +   error = hibernation_ops->prepare();
> > +   if (error)
> > +   goto Resume_devices;
> > +
> > +   error = disable_nonboot_cpus();
> > +   if (error)
> > +   goto Finish;
> > +
> > +   local_irq_disable();
> > +   error = device_power_down(PMSG_SUSPEND);
> > +   if (!error) {
> > +   hibernation_ops->enter();
> > +   /* We should never get here */
> > +   while (1);
> > }
> > +   local_irq_enable();
> > +
> 
> Confused.  afacit there's no way for the caller of this function to know
> whether or not suspend_console() was called, so the error recovery doesn't
> know whether or not to run resume_console().  How does all that work?

Well, if this fails, we try to power off and if that fails, we halt.

Resuming devices in case of an error is needed so that kernel_power_off()
can work, but the consoles need not be resumed for that.

Still, now that I think of it, the resuming of consoles in case of an error
will probably be useful in diagnostics.  I'll post a fix on top of this patch.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/6] cpuset write dirty map

[Satyam Sharma]

On 9/15/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Sat, 15 Sep 2007 05:17:48 +0530
> "Satyam Sharma" <[EMAIL PROTECTED]> wrote:
>
> > > It's unobvious why the break point is at MAX_NUMNODES = BITS_PER_LONG and
> > > we might want to tweak that in the future.  Yet another argument for
> > > centralising this comparison.
> >
> > Looks like just an optimization to me ... Ethan wants to economize and not 
> > bloat
> > struct address_space too much.
> >
> > So, if sizeof(nodemask_t) == sizeof(long), i.e. when:
> > MAX_NUMNODES <= BITS_PER_LONG, then we'll be adding only sizeof(long)
> > extra bytes to the struct (by plonking the object itself into it).
> >
> > But even when MAX_NUMNODES > BITS_PER_LONG, because we're storing
> > a pointer, and because sizeof(void *) == sizeof(long), so again the maximum
> > bloat addition to struct address_space would only be sizeof(long) bytes.
>
> yup.
>
> Note that "It's unobvious" != "It's unobvious to me".  I review code for
> understandability-by-others, not for understandability-by-me.
>
> > I didn't see the original mail, but if the #ifdeffery for this
> > conditional is too much
> > as a result of this optimization, Ethan should probably just do away
> > with all of it
> > entirely, and simply put a full nodemask_t object (irrespective of 
> > MAX_NUMNODES)
> > into the struct. After all, struct task_struct does the same 
> > unconditionally ...
> > but admittedly, there are several times more address_space struct's 
> > resident in
> > memory at any given time than there are task_struct's, so this optimization 
> > does
> > make sense too ...
>
> I think the optimisation is (probably) desirable, but it would be best to
> describe the tradeoff in the changelog and to add some suitable
> code-commentary for those who read the code in a year's time and to avoid
> sprinkling the logic all over the tree.

True, the other option could be to put the /pointer/ in there unconditionally,
but that would slow down the MAX_NUMNODES <= BITS_PER_LONG case,
which (after grepping through defconfigs) appears to be the common case on
all archs other than ia64. So I think your idea of making that conditional
centralized in the code with an accompanying comment is the way to go here ...


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

Re: [git patches] net driver fixes

[Kok, Auke]

Dan Williams wrote:

On Thu, 2007-09-13 at 01:30 -0400, Jeff Garzik wrote:

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

to receive the following updates:

 drivers/net/atl1/atl1_main.c |   19 +++
 drivers/net/ehea/ehea.h  |5 -
 drivers/net/ehea/ehea_main.c |   16 ++--
 drivers/net/phy/phy.c|4 ++--
 drivers/net/phy/phy_device.c |4 ++--
 drivers/net/sky2.c   |9 -
 drivers/net/spider_net.c |   12 
 7 files changed, 41 insertions(+), 28 deletions(-)

Hans-Jürgen Koch (1):
  Fix a lock problem in generic phy code

Ishizaki Kou (1):
  spidernet: fix interrupt reason recognition

Jan-Bernd Themann (2):
  ehea: propagate physical port state
  ehea: fix last_rx update



maybe a little bit late with this comment:


ehea_error("Failed setting port speed");
}
}
-   netif_carrier_on(port->netdev);
+   if (!prop_carrier_state || (port->phy_link == EHEA_PHY_LINK_UP))
+   netif_carrier_on(port->netdev);
+
kfree(cb4);
 out:
return ret;
@@ -869,13 +875,19 @@ static void ehea_parse_eqe(struct ehea_adapter *adapter, 
u64 eqe)
}
 
 		if (EHEA_BMASK_GET(NEQE_EXTSWITCH_PORT_UP, eqe)) {

+   port->phy_link = EHEA_PHY_LINK_UP;
if (netif_msg_link(port))
ehea_info("%s: Physical port up",
  port->netdev->name);
+   if (prop_carrier_state)
+   netif_carrier_on(port->netdev);
} else {
+   port->phy_link = EHEA_PHY_LINK_DOWN;
if (netif_msg_link(port))
ehea_info("%s: Physical port down",
  port->netdev->name);
+   if (prop_carrier_state)
+   netif_carrier_off(port->netdev);


maybe it was better to code this as 'ehea_carrier_off/on()' which then tests 
(prop_carrier_state) - this now begs for regressions where this isn't properly 
done in future commits, and on top of that there are all these extra conditions now.


Cheers,

Auke

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

RE: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Nakajima, Jun]

Jeremy Fitzhardinge wrote:
> Nakajima, Jun wrote:
> > > > one.  Start the kvm leaves at 0x40001000 or something?
> > > > 
> > > > 
> > > Yeah, that works with me.
> > > 
> > 
> > To me this is the beginning of fragmentation. Why do we need
different
> > and VMM-specific Linux paravirtualization for hardware-assisted
> > virtualization? That would not be good for Linux.
> > 
> 
> On the contrary.  Xen already has a hypercall interface, and we need
to
> keep supporting it.  If we were to also support a vmm-independent
> interface (aka "kvm interface"), then we need to be able to do that in
> parallel.  If we have a cpuid leaf clash, then its impossible to do
so;
> if we define the new interface to be disjoint from other current users
> of cpuid, then we can support them concurrently.
> 
> J

Today, 3 CPUID leaves starting from 0x4000_ are defined in a generic
fashion (hypervisor detection, version, and hypercall page), and those
are the ones used by Xen today. We should extend those leaves (e.g.
starting from 0x4000_0003) for the vmm-independent features as well.

If Xen needs additional Xen-specific features, we need to allocate some
leaves for those (e.g. 0x4000_1000)

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

Re: [PATCH 1/6] cpuset write dirty map

[Andrew Morton]

On Sat, 15 Sep 2007 05:17:48 +0530
"Satyam Sharma" <[EMAIL PROTECTED]> wrote:

> > It's unobvious why the break point is at MAX_NUMNODES = BITS_PER_LONG and
> > we might want to tweak that in the future.  Yet another argument for
> > centralising this comparison.
> 
> Looks like just an optimization to me ... Ethan wants to economize and not 
> bloat
> struct address_space too much.
> 
> So, if sizeof(nodemask_t) == sizeof(long), i.e. when:
> MAX_NUMNODES <= BITS_PER_LONG, then we'll be adding only sizeof(long)
> extra bytes to the struct (by plonking the object itself into it).
> 
> But even when MAX_NUMNODES > BITS_PER_LONG, because we're storing
> a pointer, and because sizeof(void *) == sizeof(long), so again the maximum
> bloat addition to struct address_space would only be sizeof(long) bytes.

yup.

Note that "It's unobvious" != "It's unobvious to me".  I review code for
understandability-by-others, not for understandability-by-me.

> I didn't see the original mail, but if the #ifdeffery for this
> conditional is too much
> as a result of this optimization, Ethan should probably just do away
> with all of it
> entirely, and simply put a full nodemask_t object (irrespective of 
> MAX_NUMNODES)
> into the struct. After all, struct task_struct does the same unconditionally 
> ...
> but admittedly, there are several times more address_space struct's resident 
> in
> memory at any given time than there are task_struct's, so this optimization 
> does
> make sense too ...

I think the optimisation is (probably) desirable, but it would be best to
describe the tradeoff in the changelog and to add some suitable
code-commentary for those who read the code in a year's time and to avoid
sprinkling the logic all over the 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: [PATCH] KEYS: Make request_key() and co fundamentally asynchronous

[Andrew Morton]

On Wed, 12 Sep 2007 15:25:08 +0100
David Howells <[EMAIL PROTECTED]> wrote:

> Make request_key() and co fundamentally asynchronous to make it easier for NFS
> to make use of them.  There are now accessor functions that do asynchronous
> constructions, a wait function to wait for construction to complete, and a
> completion function for the key type to indicate completion of construction.
> 
> Note that the construction queue is now gone.  Instead, keys under 
> construction
> are linked in to the appropriate keyring in advance, and that anyone
> encountering one must wait for it to be complete before they can use it.  This
> is done automatically for userspace.
> 
> The following auxiliary changes are also made:
> 
>  (1) Key type implementation stuff is split from linux/key.h into
>  linux/key-type.h.
> 
>  (2) AF_RXRPC provides a way to allocate null rxrpc-type keys so that AFS does
>  not need to call key_instantiate_and_link() directly.
> 
>  (3) Documentation.
> 
> Signed-off-by: David Howells <[EMAIL PROTECTED]>
> ---
> 
>  Documentation/keys-request-key.txt |   25 +-
>  Documentation/keys.txt |   91 +-
>  Documentation/networking/rxrpc.txt |7 
>  fs/afs/cell.c  |   17 -
>  include/keys/rxrpc-type.h  |2 
>  include/linux/key-type.h   |  112 +++
>  include/linux/key.h|   99 +-
>  net/rxrpc/af_rxrpc.c   |1 
>  net/rxrpc/ar-key.c |   31 ++
>  security/keys/internal.h   |   29 +-
>  security/keys/key.c|   27 +-
>  security/keys/process_keys.c   |   16 +
>  security/keys/request_key.c|  556 
> ++--
>  security/keys/request_key_auth.c   |9 +
>  14 files changed, 595 insertions(+), 427 deletions(-)

So who's going to review this?  Nobody?  Well gee, maybe it was my turn
anyway.

checkpatch generates a pile of warnings, all of which afacit are legit.

> +#ifdef __KDEBUG
> +#define kenter(FMT, ...) printk("==> %s("FMT")\n",__FUNCTION__ 
> ,##__VA_ARGS__)
> +#define kleave(FMT, ...) printk("<== %s()"FMT"\n",__FUNCTION__ 
> ,##__VA_ARGS__)
> +#define kdebug(FMT, ...) printk(FMT"\n" ,##__VA_ARGS__)
>  #else
> -#define kenter(FMT, a...)do {} while(0)
> -#define kleave(FMT, a...)do {} while(0)
> -#define kdebug(FMT, a...)do {} while(0)
> +#define kenter(FMT, ...) no_printk("==> %s("FMT")\n",__FUNCTION__ 
> ,##__VA_ARGS__)
> +#define kleave(FMT, ...) no_printk("<== %s()"FMT"\n",__FUNCTION__ 
> ,##__VA_ARGS__)
> +#define kdebug(FMT, ...) no_printk(FMT"\n" ,##__VA_ARGS__)
>  #endif

How many different&private versions of this sort of thing do we have?  Sigh.

The debug infrastructure changes don't appear to be related to the intent
of this patch and aren't changelogged.  Not that this matters a lot.

> @@ -901,10 +901,9 @@ void key_revoke(struct key *key)
>  
>   /* make sure no one's trying to change or use the key when we mark
>* it */
> - down_write(&key->sem);
> - set_bit(KEY_FLAG_REVOKED, &key->flags);
> -
> - if (key->type->revoke)
> + down_write_nested(&key->sem, 1);

It'd be nice to add a comment explaining to the long-suffering reader why
down_write_nested() is used here.

> @@ -151,6 +152,12 @@ struct key *request_key_auth_new(struct key *target, 
> const char *callout_info)
>   kleave(" = -ENOMEM");
>   return ERR_PTR(-ENOMEM);
>   }
> + rka->callout_info = kmalloc(strlen(callout_info) + 1, GFP_KERNEL);
> + if (!rka->callout_info) {
> + kleave(" = -ENOMEM");
> + kfree(rka);
> + return ERR_PTR(-ENOMEM);
> + }

You could actually use kstrdup() here, I think.

rka->callout_info gets leaked later on (goto auth_key_revoked)

>   /* see if the calling process is already servicing the key request of
>* another process */
> @@ -179,7 +186,7 @@ struct key *request_key_auth_new(struct key *target, 
> const char *callout_info)
>   }
>  
>   rka->target_key = key_get(target);
> - rka->callout_info = callout_info;
> + strcpy(rka->callout_info, callout_info);
>  
>   /* allocate the auth key */
>   sprintf(desc, "%x", target->serial);

Apart from that the changes look reasonable to me, but I am not a suitable
reviewer for keys, NFS or rxrpc stuff.  Who is??

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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]PCI:disable resource decode in PCI BAR detection

[Robert Hancock]

Ivan Kokshaysky wrote:

On Fri, Sep 14, 2007 at 08:30:59AM -0600, Robert Hancock wrote:

Do you have an example of specific hardware that exhibits this problem?


Well, first two results of google search for "disable bar when sizing":
 http://lkml.org/lkml/2002/12/21/95
 http://lkml.org/lkml/2002/12/20/110


In the first one, Linus talks about a USB controller whose SMM code 
chokes on the BAR being disabled. That explanation seems odd to me. If 
it chokes on the BAR disabled, how doesn't it choke on the BAR being 
moved to a different location, which is unavoidable during probing?


Also, I think we do USB handoff from the BIOS much earlier than we used 
to, which likely prevents these issues.


In the second one, he mentions that "So the secondary rule to "don't 
turnoff MEM or IO accesses" is "never allocate real PCI BAR resources at 
the top of memory". Well, unfortunately, the second one isn't possible 
to meet given that we have boards with the MMCONFIG up there, so 
disabling the decode is the only thing we can do. That whole discussion 
was also based on the fact that it wasn't necessary to solve problems. 
This is no longer a theoretical problem. We now have real problems that 
we need this in order to solve.




So far after a similar patch has been in -mm for months there have been 
no reports of any such problems.


You cannot compare user base of -mm and release kernels. Also, note
that we're talking about maybe 0.01% of systems running Linux.
And similar patch appeared in various trees several times over the last
decade and every time it had to be reverted.

This isn't guaranteed to help. I don't think it is only integrated 
graphics that could cause this problem, I think that an add-on PCI 
Express card can do this as well. Depending on the chipset memory decode 
rules, any PCI or PCI Express device with a BAR large enough could cause 
issues.


No, it's impossible for several reasons. Most obvious one is that a PCI-E
bridge does isolate stuff quite nicely.


It's not impossible at all. In fact I'm quite sure (Jesse can confirm) 
that in the case of the board he was using, it was an add-in graphics 
card where he saw this problem.


The fact is that in the case of MMCONFIG overlap with PCI BARs, which 
one takes priority is completely undefined. In the case of this Intel 
chipset, clearly the PCI Express device connected to the northbridge had 
higher decode priority than the MMCONFIG aperture.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/

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

Re: [PATCH 1/6] cpuset write dirty map

[Satyam Sharma]

On 9/15/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 11 Sep 2007 18:36:34 -0700
> Ethan Solomita <[EMAIL PROTECTED]> wrote:

> > The dirty map may be stored either directly in the mapping (for NUMA
> > systems with less then BITS_PER_LONG nodes) or separately allocated
> > for systems with a large number of nodes (f.e. IA64 with 1024 nodes).

> > --- 0/include/linux/fs.h  2007-09-11 14:35:58.0 -0700
> > +++ 1/include/linux/fs.h  2007-09-11 14:36:24.0 -0700
> > @@ -516,6 +516,13 @@ struct address_space {
> >   spinlock_t  private_lock;   /* for use by the 
> > address_space */
> >   struct list_headprivate_list;   /* ditto */
> >   struct address_space*assoc_mapping; /* ditto */
> > +#ifdef CONFIG_CPUSETS
> > +#if MAX_NUMNODES <= BITS_PER_LONG
> > + nodemask_t  dirty_nodes;/* nodes with dirty pages */
> > +#else
> > + nodemask_t  *dirty_nodes;   /* pointer to map if dirty */
> > +#endif
> > +#endif
>
> afacit there is no code comment and no changelog text which explains the
> above design decision?  There should be, please.

> > +/*
> > + * Special functions for NUMA systems with a large number of nodes.
> > + * The nodemask is pointed to from the address space structures.
> > + * The attachment of the dirty_node mask is protected by the
> > + * tree_lock. The nodemask is freed only when the inode is cleared
> > + * (and therefore unused, thus no locking necessary).
> > + */
>
> hmm, OK, there's a hint as to wghat's going on.
>
> It's unobvious why the break point is at MAX_NUMNODES = BITS_PER_LONG and
> we might want to tweak that in the future.  Yet another argument for
> centralising this comparison.

Looks like just an optimization to me ... Ethan wants to economize and not bloat
struct address_space too much.

So, if sizeof(nodemask_t) == sizeof(long), i.e. when:
MAX_NUMNODES <= BITS_PER_LONG, then we'll be adding only sizeof(long)
extra bytes to the struct (by plonking the object itself into it).

But even when MAX_NUMNODES > BITS_PER_LONG, because we're storing
a pointer, and because sizeof(void *) == sizeof(long), so again the maximum
bloat addition to struct address_space would only be sizeof(long) bytes.

I didn't see the original mail, but if the #ifdeffery for this
conditional is too much
as a result of this optimization, Ethan should probably just do away
with all of it
entirely, and simply put a full nodemask_t object (irrespective of MAX_NUMNODES)
into the struct. After all, struct task_struct does the same unconditionally ...
but admittedly, there are several times more address_space struct's resident in
memory at any given time than there are task_struct's, so this optimization does
make sense too ...


> > + if (!nodes)
> > + return;
> > +
> > + *nodes = NODE_MASK_NONE;
> > + mapping->dirty_nodes = nodes;
> > + }
> > +
> > + if (!node_isset(node, *nodes))
> > + node_set(node, *nodes);
> > +}
> > +
> > +void cpuset_clear_dirty_nodes(struct address_space *mapping)
> > +{
> > + nodemask_t *nodes = mapping->dirty_nodes;
> > +
> > + if (nodes) {
> > + mapping->dirty_nodes = NULL;
> > + kfree(nodes);
> > + }
> > +}
>
> Can this race with cpuset_update_dirty_nodes()?  And with itself?  If not,
> a comment which describes the locking requirements would be good.
>
> > +/*
> > + * Called without the tree_lock. The nodemask is only freed when the inode
> > + * is cleared and therefore this is safe.
> > + */
> > +int cpuset_intersects_dirty_nodes(struct address_space *mapping,
> > + nodemask_t *mask)
> > +{
> > + nodemask_t *dirty_nodes = mapping->dirty_nodes;
> > +
> > + if (!mask)
> > + return 1;
> > +
> > + if (!dirty_nodes)
> > + return 0;
> > +
> > + return nodes_intersects(*dirty_nodes, *mask);
> > +}
> > +#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: [PATCH 1/5] Use existing macros for distinguishing mandatory locks

[Andrew Morton]

On Wed, 12 Sep 2007 15:17:58 +0400
Pavel Emelyanov <[EMAIL PROTECTED]> wrote:

> The combination of S_ISGID bit set and S_IXGRP bit unset is 
> used to mark the inode as "mandatory lockable" and there's a 
> macro for this check called MANDATORY_LOCK(inode). However, 
> fs/locks.c and some filesystems still perform the explicit 
> i_mode checking. 
> 
> Switch the fs/locks.c to macro making the code shorter and 
> more readable.
> 
> The __MANDATORY_LOCK() macro is to be used in places where
> the IS_MANDLOCK() for superblock is already known to be true.
> 

If we're going to churn this code then it would be better to switch from
ugly-upper-case-macro to nice-lower-case-C-function while we're doing it,
please.

> 
> diff --git a/include/linux/fs.h b/include/linux/fs.h
> index 291d40b..035ffda 100644
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -1488,8 +1488,8 @@ extern int locks_mandatory_area(int, str
>   * Candidates for mandatory locking have the setgid bit set
>   * but no group execute bit -  an otherwise meaningless combination.
>   */
> -#define MANDATORY_LOCK(inode) \
> - (IS_MANDLOCK(inode) && ((inode)->i_mode & (S_ISGID | S_IXGRP)) == 
> S_ISGID)
> +#define __MANDATORY_LOCK(ino) (((ino)->i_mode & (S_ISGID | S_IXGRP)) == 
> S_ISGID)
> +#define MANDATORY_LOCK(inode) (IS_MANDLOCK(inode) && __MANDATORY_LOCK(inode))

Especially as the macro is a buggy one which references its argument more
than once.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Resend][PATCH -mm] Hibernation: Enter platform hibernation state in a consistent way (rev. 4)

[Andrew Morton]

On Wed, 12 Sep 2007 13:14:08 +0200
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:

> + if (!hibernation_ops)
> + return -ENOSYS;
> +
> + /*
> +  * We have cancelled the power transition by running
> +  * hibernation_ops->finish() before saving the image, so we should let
> +  * the firmware know that we're going to enter the sleep state after all
> +  */
> + error = hibernation_ops->start();
> + if (error)
> + return error;
> +
> + suspend_console();
> + error = device_suspend(PMSG_SUSPEND);
> + if (error)
> + return error;
> +
> + error = hibernation_ops->prepare();
> + if (error)
> + goto Resume_devices;
> +
> + error = disable_nonboot_cpus();
> + if (error)
> + goto Finish;
> +
> + local_irq_disable();
> + error = device_power_down(PMSG_SUSPEND);
> + if (!error) {
> + hibernation_ops->enter();
> + /* We should never get here */
> + while (1);
>   }
> + local_irq_enable();
> +

Confused.  afacit there's no way for the caller of this function to know
whether or not suspend_console() was called, so the error recovery doesn't
know whether or not to run resume_console().  How does all that work?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 00/10] x86: Reduce Memory Usage and Inter-Node message traffic (v3)

[Andrew Morton]

On Tue, 11 Sep 2007 18:56:44 -0700
[EMAIL PROTECTED] wrote:

> Changes for version v3:
> 
> cpu_sibling_map has been converted to a per_cpu data array to fix
> build errors on ia64, ppc64 and sparc64 to accomodate references in
> block/blktrace.c and kernel/sched.c when CONFIG_SCHED_SMT is defined.
> 
> Warning: ppc64 and sparc64 have not yet been built nor tested.

These patches all seem to be unaltered from what I had.

The first patch (x86: remove x86_cpu_to_log_apicid array) is in Andi's
tree as x86_64-mm-remove-x86_cpu_to_log_apicid.patch so I don't apply that.

The sparc64/ppc64/ia64 convert-cpu_sibling_map-to-a-per_cpu-data-array
patches need to be folded into the base patch so that we don't break the build
at any stage.

So what I ended up with was

x86-fix-cpu_to_node-references.patch
x86-convert-cpu_core_map-to-be-a-per-cpu-variable.patch
convert-cpu_sibling_map-to-be-a-per-cpu-variable.patch
convert-cpu_sibling_map-to-a-per_cpu-data-array-ia64.patch
convert-cpu_sibling_map-to-a-per_cpu-data-array-ppc64.patch
convert-cpu_sibling_map-to-a-per_cpu-data-array-sparc64.patch
x86-convert-x86_cpu_to_apicid-to-be-a-per-cpu-variable.patch
x86-convert-cpu_llc_id-to-be-a-per-cpu-variable.patch

where the four convert-cpu_sibling_map-to-* will be clumped into a
single diff.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Per option CFLAGS?

[Rene Herman]

On 09/15/2007 01:13 AM, H. Peter Anvin wrote:


Rene Herman wrote:



I have a single file foo.c that I want to generate two (ALSA) modules
from, snd-foo2000.ko and snd-foo2001.ko, by compiling with either
FOO2000 or FOO2001 defined.

I can do this, and ALSA does this a few times, by providing dummy
foo2000.c and foo2001.c files, like:

=== foo2000.c
#define FOO2000
#include "foo.c"
===

and a regular Makefile

===
foo2000-objs := foo2000.o
foo2001-objs := foo2001.o

obj-$(CONFIG_SND_FOO2000) += snd-foo2000.o
obj-$(CONFIG_SND_F002001) += snd-foo2001.o
===

That #include is a little lame though. Is there a nicer way? I noticed
the per-file CFLAGS, but given that it's one source file for both, that
doesn't fit.



The stub source file is usually considered a good way to do this.


Mmm. If I'll have to live with it, I can, but thought I'd ask if there was 
some nice build trickery available instead.


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: [PATCH] Configurable reclaim batch size

[Peter Zijlstra]

On Fri, 2007-09-14 at 15:23 -0700, Christoph Lameter wrote:
> This patch allows a configuration of the basic reclaim unit for reclaim in 
> vmscan.c. As memory sizes increase so will the frequency of running 
> reclaim. Configuring the reclaim unit higher will reduce the number of 
> times reclaim has to be entered and reduce the number of times that the 
> zone locks have to be taken.

It increases the lock hold times though. Otoh it might work out with the
lock placement.

Do you have any numbers that show this is worthwhile?



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 6/6] cpuset dirty limits

[Andrew Morton]

On Tue, 11 Sep 2007 18:42:16 -0700
Ethan Solomita <[EMAIL PROTECTED]> wrote:

> Per cpuset dirty ratios
> 
> This implements dirty ratios per cpuset. Two new files are added
> to the cpuset directories:
> 
> background_dirty_ratioPercentage at which background writeback starts
> 
> throttle_dirty_ratio  Percentage at which the application is throttled
>   and we start synchrononous writeout.
> 
> Both variables are set to -1 by default which means that the global
> limits (/proc/sys/vm/vm_dirty_ratio and /proc/sys/vm/dirty_background_ratio)
> are used for a cpuset.
> 
> Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
> Acked-by: Ethan Solomita <[EMAIL PROTECTED]>
> 
> ---
> 
> Patch against 2.6.23-rc4-mm1
> 
> diff -uprN -X 0/Documentation/dontdiff 5/include/linux/cpuset.h 
> 7/include/linux/cpuset.h
> --- 5/include/linux/cpuset.h  2007-09-11 14:50:48.0 -0700
> +++ 7/include/linux/cpuset.h  2007-09-11 14:51:12.0 -0700
> @@ -77,6 +77,7 @@ extern void cpuset_track_online_nodes(vo
>  
>  extern int current_cpuset_is_being_rebound(void);
>  
> +extern void cpuset_get_current_ratios(int *background, int *ratio);
>  /*
>   * We need macros since struct address_space is not defined yet
>   */
> diff -uprN -X 0/Documentation/dontdiff 5/kernel/cpuset.c 7/kernel/cpuset.c
> --- 5/kernel/cpuset.c 2007-09-11 14:50:49.0 -0700
> +++ 7/kernel/cpuset.c 2007-09-11 14:56:18.0 -0700
> @@ -51,6 +51,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -92,6 +93,9 @@ struct cpuset {
>   int mems_generation;
>  
>   struct fmeter fmeter;   /* memory_pressure filter */
> +
> + int background_dirty_ratio;
> + int throttle_dirty_ratio;
>  };
>  
>  /* Retrieve the cpuset for a container */
> @@ -169,6 +173,8 @@ static struct cpuset top_cpuset = {
>   .flags = ((1 << CS_CPU_EXCLUSIVE) | (1 << CS_MEM_EXCLUSIVE)),
>   .cpus_allowed = CPU_MASK_ALL,
>   .mems_allowed = NODE_MASK_ALL,
> + .background_dirty_ratio = -1,
> + .throttle_dirty_ratio = -1,
>  };
>  
>  /*
> @@ -785,6 +791,21 @@ static int update_flag(cpuset_flagbits_t
>   return 0;
>  }
>  
> +static int update_int(int *cs_int, char *buf, int min, int max)
> +{
> + char *endp;
> + int val;
> +
> + val = simple_strtol(buf, &endp, 10);
> + if (val < min || val > max)
> + return -EINVAL;
> +
> + mutex_lock(&callback_mutex);
> + *cs_int = val;
> + mutex_unlock(&callback_mutex);

I don't think this locking does anything?

> + return 0;
> +}
> +
>  /*
>   * Frequency meter - How fast is some event occurring?
>   *
> ...
> +void cpuset_get_current_ratios(int *background_ratio, int *throttle_ratio)
> +{
> + int background = -1;
> + int throttle = -1;
> + struct task_struct *tsk = current;
> +
> + task_lock(tsk);
> + background = task_cs(tsk)->background_dirty_ratio;
> + throttle = task_cs(tsk)->throttle_dirty_ratio;
> + task_unlock(tsk);

ditto?


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

Re: [PATCH 1/6] cpuset write dirty map

[Andrew Morton]

On Tue, 11 Sep 2007 18:36:34 -0700
Ethan Solomita <[EMAIL PROTECTED]> wrote:

> Add a dirty map to struct address_space

I get a tremendous number of rejects trying to wedge this stuff on top of
Peter's mm-dirty-balancing-for-tasks changes.  More rejects than I am
prepared to partially-fix so that I can usefully look at these changes in
tkdiff, so this is all based on a quick peek at the diff itself..

> In a NUMA system it is helpful to know where the dirty pages of a mapping
> are located. That way we will be able to implement writeout for applications
> that are constrained to a portion of the memory of the system as required by
> cpusets.
> 
> This patch implements the management of dirty node maps for an address
> space through the following functions:
> 
> cpuset_clear_dirty_nodes(mapping) Clear the map of dirty nodes
> 
> cpuset_update_nodes(mapping, page)Record a node in the dirty nodes map
> 
> cpuset_init_dirty_nodes(mapping)  First time init of the map
> 
> 
> The dirty map may be stored either directly in the mapping (for NUMA
> systems with less then BITS_PER_LONG nodes) or separately allocated
> for systems with a large number of nodes (f.e. IA64 with 1024 nodes).
> 
> Updating the dirty map may involve allocating it first for large
> configurations. Therefore we protect the allocation and setting
> of a node in the map through the tree_lock. The tree_lock is
> already taken when a page is dirtied so there is no additional
> locking overhead if we insert the updating of the nodemask there.
> 
> The dirty map is only cleared (or freed) when the inode is cleared.
> At that point no pages are attached to the inode anymore and therefore it can
> be done without any locking. The dirty map therefore records all nodes that
> have been used for dirty pages by that inode until the inode is no longer
> used.
>

It'd be nice to see some discussion regarding the memory consumption of
this patch and the associated tradeoffs.


> ...
>
> +#if MAX_NUMNODES <= BITS_PER_LONG

The patch is sprinkled full of this conditional.

  I don't understand why this is being done.  afaict it isn't described
  in a code comment (it should be) nor even in the changelogs?

  Given its overall complexity and its likelihood to change in the
  future, I'd suggest that this conditional be centralised in a single
  place.  Something like

  /*
   * nice comment goes here
   */
  #if MAX_NUMNODES <= BITS_PER_LONG
  #define CPUSET_DIRTY_LIMITS 1
  #else
  #define CPUSET_DIRTY_LIMITS 0
  #endif

  Then use #if CPUSET_DIRTY_LIMITS everywhere else.

  (This is better than #ifdef CPUSET_DIRTY_LIMITS because we'll et a
  warning if someone typos '#if CPUSET_DITRY_LIMITS')

  Even better would be to calculate CPUSET_DIRTY_LIMITS within Kconfig,
  but I suspect you'll need to jump through unfeasible hoops to do that
  sort of calculation within Kconfig.


> --- 0/include/linux/fs.h  2007-09-11 14:35:58.0 -0700
> +++ 1/include/linux/fs.h  2007-09-11 14:36:24.0 -0700
> @@ -516,6 +516,13 @@ struct address_space {
>   spinlock_t  private_lock;   /* for use by the address_space 
> */
>   struct list_headprivate_list;   /* ditto */
>   struct address_space*assoc_mapping; /* ditto */
> +#ifdef CONFIG_CPUSETS
> +#if MAX_NUMNODES <= BITS_PER_LONG
> + nodemask_t  dirty_nodes;/* nodes with dirty pages */
> +#else
> + nodemask_t  *dirty_nodes;   /* pointer to map if dirty */
> +#endif
> +#endif

afacit there is no code comment and no changelog text which explains the
above design decision?  There should be, please.

There is talk of making cpusets available with CONFIG_SMP=n.  Will this new
feature be available in that case?  (it should be).

>  } __attribute__((aligned(sizeof(long;
>   /*
>* On most architectures that alignment is already the case; but
> diff -uprN -X 0/Documentation/dontdiff 0/include/linux/writeback.h 
> 1/include/linux/writeback.h
> --- 0/include/linux/writeback.h   2007-09-11 14:35:58.0 -0700
> +++ 1/include/linux/writeback.h   2007-09-11 14:37:46.0 -0700
> @@ -62,6 +62,7 @@ struct writeback_control {
>   unsigned for_writepages:1;  /* This is a writepages() call */
>   unsigned range_cyclic:1;/* range_start is cyclic */
>   void *fs_private;   /* For use by ->writepages() */
> + nodemask_t *nodes;  /* Set of nodes of interest */
>  };

That comment is a bit terse.  It's always good to be lavish when commenting
data structures, for understanding those is key to understanding a design.

>  /*
> diff -uprN -X 0/Documentation/dontdiff 0/kernel/cpuset.c 1/kernel/cpuset.c
> --- 0/kernel/cpuset.c 2007-09-11 14:35:58.0 -0700
> +++ 1/kernel/cpuset.c 2007-09-11 14:36:24.0 -0700
> @@ -4,7 +4,7 @@
>   *  Processor and Memory placement constraints for sets of tasks.
>   *
>   *  Copyright (C) 2003 BULL SA.
> - *  Copyright (C) 

Re: Per option CFLAGS?

[H. Peter Anvin]

Rene Herman wrote:
> Hi Kai, Sam.
> 
> I have a single file foo.c that I want to generate two (ALSA) modules
> from, snd-foo2000.ko and snd-foo2001.ko, by compiling with either
> FOO2000 or FOO2001 defined.
> 
> I can do this, and ALSA does this a few times, by providing dummy
> foo2000.c and foo2001.c files, like:
> 
> === foo2000.c
> #define FOO2000
> #include "foo.c"
> ===
> 
> and a regular Makefile
> 
> ===
> foo2000-objs := foo2000.o
> foo2001-objs := foo2001.o
> 
> obj-$(CONFIG_SND_FOO2000) += snd-foo2000.o
> obj-$(CONFIG_SND_F002001) += snd-foo2001.o
> ===
> 
> That #include is a little lame though. Is there a nicer way? I noticed
> the per-file CFLAGS, but given that it's one source file for both, that
> doesn't fit.
> 

The stub source file is usually considered a good way to do this.

-hpa


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

Per option CFLAGS?

[Rene Herman]

Hi Kai, Sam.

I have a single file foo.c that I want to generate two (ALSA) modules from, 
snd-foo2000.ko and snd-foo2001.ko, by compiling with either FOO2000 or 
FOO2001 defined.


I can do this, and ALSA does this a few times, by providing dummy foo2000.c 
and foo2001.c files, like:


=== foo2000.c
#define FOO2000
#include "foo.c"
===

and a regular Makefile

===
foo2000-objs := foo2000.o
foo2001-objs := foo2001.o

obj-$(CONFIG_SND_FOO2000) += snd-foo2000.o
obj-$(CONFIG_SND_F002001) += snd-foo2001.o
===

That #include is a little lame though. Is there a nicer way? I noticed the 
per-file CFLAGS, but given that it's one source file for both, that doesn't fit.


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: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Jeremy Fitzhardinge]

Nakajima, Jun wrote:
>>> one.  Start the kvm leaves at 0x40001000 or something?
>>>
>>>   
>> Yeah, that works with me.
>> 
>
> To me this is the beginning of fragmentation. Why do we need different
> and VMM-specific Linux paravirtualization for hardware-assisted
> virtualization? That would not be good for Linux.
>   

On the contrary.  Xen already has a hypercall interface, and we need to
keep supporting it.  If we were to also support a vmm-independent
interface (aka "kvm interface"), then we need to be able to do that in
parallel.  If we have a cpuid leaf clash, then its impossible to do so;
if we define the new interface to be disjoint from other current users
of cpuid, then we can support them concurrently.

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

On thread scheduling

[Heikki Orsila]

Consider a simple embedded system:

void interrupt_handler(void)
{
...
}

int main(void)
{
...
}

I would like to "emulate" this system with a workstation to make 
development faster. I would create two threads, one executing the 
main() function, and the other occasionally calling interrupt_handler(). 
Before interrupt_handler() is called, the main() thread should be 
stopped asynchronously.

I looked into pthreads documentation and found only pthread_kill(thread, 
SIGTSTP) to do asynchronous stop, but then I also have to play terminal 
tricks to avoid problems..

Is there are function to just disable scheduling of a single thread 
without having other side-effects (such as terminal stuff)? Functions 
like pthread_disable_scheduling(thread) and 
pthread_enable_scheduling(thread) would be good for this..

-- 
Heikki Orsila   Barbie's law:
[EMAIL PROTECTED]   "Math is hard, let's go shopping!"
http://www.iki.fi/shd
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Distributed storage. Move away from char device ioctls.

[J. Bruce Fields]

On Fri, Sep 14, 2007 at 06:32:11PM -0400, Jeff Garzik wrote:
> J. Bruce Fields wrote:
>> On Fri, Sep 14, 2007 at 05:14:53PM -0400, Jeff Garzik wrote:
>>> J. Bruce Fields wrote:
 On Fri, Sep 14, 2007 at 03:07:46PM -0400, Jeff Garzik wrote:
> I've been waiting for years for a smart person to come along and write 
> a POSIX-only distributed filesystem.
 What exactly do you mean by "POSIX-only"?
>>> Don't bother supporting attributes, file modes, and other details not 
>>> supported by POSIX.  The prime example being NFSv4, which is larded down 
>>> with Windows features.
>> I am sympathetic  Cutting those out may still leave you with
>> something pretty complicated, though.
>
> Far less complicated than NFSv4.1 though (which is easy :))

One would hope so.

>>> NFSv4.1 adds to the fun, by throwing interoperability completely out the 
>>> window.
>> What parts are you worried about in particular?
>
> I'm not worried; I'm stating facts as they exist today (draft 13):
>
> NFS v4.1 does something completely without precedent in the history of NFS: 
>  the specification is defined such that interoperability is -impossible- to 
> guarantee.
>
> pNFS permits private and unspecified layout types.  This means it is 
> impossible to guarantee that one NFSv4.1 implementation will be able to 
> talk another NFSv4.1 implementation.

No, servers are required to support ordinary nfs operations to the
metadata server.

At least, that's the way it was last I heard, which was a while ago.  I
agree that it'd stink (for any number of reasons) if you ever *had* to
get a layout to access some file.

Was that your main concern?

--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Nakajima, Jun]

Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
> > Anthony Liguori wrote:
> > 
> > > Yeah, see, the initial goal was to make it possible to use the KVM
> > > paravirtualizations on other hypervisors.  However, I don't think
this
> > > is really going to be possible in general so maybe it's better to
just
> > > use leaf 0.  I'll let others chime in before sending a new patch.
> > > 
> > 
> > Hm.  Obviously you can just define a signature for "kvm-compatible
> > hypercall interface" and make it common that way, but it gets tricky
if
> > the hypervisor supports multiple hypercall interfaces, including the
kvm
> > one.  Start the kvm leaves at 0x40001000 or something?
> > 
> 
> Yeah, that works with me.

To me this is the beginning of fragmentation. Why do we need different
and VMM-specific Linux paravirtualization for hardware-assisted
virtualization? That would not be good for Linux.

> 
> Regards,
> 
> Anthony Liguori
> 
> > J

Jun
---
Intel Open Source Technology Center
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Distributed storage. Move away from char device ioctls.

[Jeff Garzik]

J. Bruce Fields wrote:

On Fri, Sep 14, 2007 at 05:14:53PM -0400, Jeff Garzik wrote:

J. Bruce Fields wrote:

On Fri, Sep 14, 2007 at 03:07:46PM -0400, Jeff Garzik wrote:
I've been waiting for years for a smart person to come along and write a 
POSIX-only distributed filesystem.

What exactly do you mean by "POSIX-only"?
Don't bother supporting attributes, file modes, and other details not 
supported by POSIX.  The prime example being NFSv4, which is larded down 
with Windows features.


I am sympathetic  Cutting those out may still leave you with
something pretty complicated, though.


Far less complicated than NFSv4.1 though (which is easy :))


NFSv4.1 adds to the fun, by throwing interoperability completely out the 
window.


What parts are you worried about in particular?


I'm not worried; I'm stating facts as they exist today (draft 13):

NFS v4.1 does something completely without precedent in the history of 
NFS:  the specification is defined such that interoperability is 
-impossible- to guarantee.


pNFS permits private and unspecified layout types.  This means it is 
impossible to guarantee that one NFSv4.1 implementation will be able to 
talk another NFSv4.1 implementation.


Even if Linux supports the entire NFSv4.1 RFC (as it stands in draft 13 
anyway), there is no guarantee at all that Linux will be able to store 
and retrieve data, since it's entirely possible that a proprietary 
protocol is required to access your data.


NFSv4.1 is no longer a completely open architecture.

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: Define termios_1 functions for powerpc, s390, avr32 and frv

[David Miller]

From: Andrew Morton <[EMAIL PROTECTED]>
Date: Fri, 14 Sep 2007 15:12:53 -0700

> That fixes sparc, but I think other architectures are still broken.  And if
> we use Tony's ifdef patch to fix the other architectures, that makes the
> above sparc-fix patch unneeded.
> 
> argh.

I don't care if we use Tony's fix or mine, both are fine.

What I do care about is that I spent 24 hours on trains and
planes, only to find more than a day later that Sparc still
didn't build.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Configurable reclaim batch size

[Christoph Lameter]

This patch allows a configuration of the basic reclaim unit for reclaim in 
vmscan.c. As memory sizes increase so will the frequency of running 
reclaim. Configuring the reclaim unit higher will reduce the number of 
times reclaim has to be entered and reduce the number of times that the 
zone locks have to be taken.

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>

---
 include/linux/mmzone.h |1 +
 kernel/sysctl.c|8 
 mm/vmscan.c|   41 +
 3 files changed, 30 insertions(+), 20 deletions(-)

Index: linux-2.6/mm/vmscan.c
===
--- linux-2.6.orig/mm/vmscan.c  2007-09-12 18:21:28.0 -0700
+++ linux-2.6/mm/vmscan.c   2007-09-12 18:31:13.0 -0700
@@ -57,11 +57,11 @@ struct scan_control {
/* Can pages be swapped as part of reclaim? */
int may_swap;
 
-   /* This context's SWAP_CLUSTER_MAX. If freeing memory for
-* suspend, we effectively ignore SWAP_CLUSTER_MAX.
+   /* This context's  reclaim batch size. If freeing memory for
+* suspend, we effectively ignore reclaim_batch.
 * In this context, it doesn't matter that we scan the
 * whole list at once. */
-   int swap_cluster_max;
+   int reclaim_batch;
 
int swappiness;
 
@@ -105,6 +105,7 @@ struct scan_control {
  */
 int vm_swappiness = 60;
 long vm_total_pages;   /* The total number of pages which the VM controls */
+int sysctl_reclaim_batch = SWAP_CLUSTER_MAX;
 
 static LIST_HEAD(shrinker_list);
 static DECLARE_RWSEM(shrinker_rwsem);
@@ -159,7 +160,7 @@ unsigned long shrink_slab(unsigned long 
unsigned long ret = 0;
 
if (scanned == 0)
-   scanned = SWAP_CLUSTER_MAX;
+   scanned = sysctl_reclaim_batch;
 
if (!down_read_trylock(&shrinker_rwsem))
return 1;   /* Assume we'll be able to shrink next time */
@@ -338,7 +339,7 @@ static pageout_t pageout(struct page *pa
int res;
struct writeback_control wbc = {
.sync_mode = WB_SYNC_NONE,
-   .nr_to_write = SWAP_CLUSTER_MAX,
+   .nr_to_write = sysctl_reclaim_batch,
.range_start = 0,
.range_end = LLONG_MAX,
.nonblocking = 1,
@@ -801,7 +802,7 @@ static unsigned long shrink_inactive_lis
unsigned long nr_freed;
unsigned long nr_active;
 
-   nr_taken = isolate_lru_pages(sc->swap_cluster_max,
+   nr_taken = isolate_lru_pages(sc->reclaim_batch,
 &zone->inactive_list,
 &page_list, &nr_scan, sc->order,
 (sc->order > PAGE_ALLOC_COSTLY_ORDER)?
@@ -1076,7 +1077,7 @@ static unsigned long shrink_zone(int pri
zone->nr_scan_active +=
(zone_page_state(zone, NR_ACTIVE) >> priority) + 1;
nr_active = zone->nr_scan_active;
-   if (nr_active >= sc->swap_cluster_max)
+   if (nr_active >= sc->reclaim_batch)
zone->nr_scan_active = 0;
else
nr_active = 0;
@@ -1084,7 +1085,7 @@ static unsigned long shrink_zone(int pri
zone->nr_scan_inactive +=
(zone_page_state(zone, NR_INACTIVE) >> priority) + 1;
nr_inactive = zone->nr_scan_inactive;
-   if (nr_inactive >= sc->swap_cluster_max)
+   if (nr_inactive >= sc->reclaim_batch)
zone->nr_scan_inactive = 0;
else
nr_inactive = 0;
@@ -1092,14 +1093,14 @@ static unsigned long shrink_zone(int pri
while (nr_active || nr_inactive) {
if (nr_active) {
nr_to_scan = min(nr_active,
-   (unsigned long)sc->swap_cluster_max);
+   (unsigned long)sc->reclaim_batch);
nr_active -= nr_to_scan;
shrink_active_list(nr_to_scan, zone, sc, priority);
}
 
if (nr_inactive) {
nr_to_scan = min(nr_inactive,
-   (unsigned long)sc->swap_cluster_max);
+   (unsigned long)sc->reclaim_batch);
nr_inactive -= nr_to_scan;
nr_reclaimed += shrink_inactive_list(nr_to_scan, zone,
sc);
@@ -1181,7 +1182,7 @@ unsigned long try_to_free_pages(struct z
struct scan_control sc = {
.gfp_mask = gfp_mask,
.may_writepage = !laptop_mode,
-   .swap_cluster_max = SWAP_CLUSTER_MAX,
+   .reclaim_batch = sysctl_reclaim_batch,
.may_swap = 1,
.swappiness = vm_swappiness,
.order = order,
@@ -1210,7 +1211,

[RFC] SLUB: Make NUMA support optional on NUMA machines

[Christoph Lameter]

NUMA support in the slab allocators may create unnecessary overhead for
small NUMA configurations (especially those that realize multiple nodes
on a motherboard like Opterons).

If NUMA support is disabled on a NUMA machines then the NUMA locality
controls will not work for slab allocations anymore. However, the resulting
memory imbalances and non optimal placements may not matter much if the
system is small.

Is this worth doing?

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>

Index: linux-2.6/include/linux/slab.h
===
--- linux-2.6.orig/include/linux/slab.h 2007-09-14 13:54:51.0 -0700
+++ linux-2.6/include/linux/slab.h  2007-09-14 13:54:56.0 -0700
@@ -178,7 +178,7 @@ static inline void *kcalloc(size_t n, si
return __kmalloc(n * size, flags | __GFP_ZERO);
 }
 
-#if !defined(CONFIG_NUMA) && !defined(CONFIG_SLOB)
+#if !defined(CONFIG_SLAB_NUMA) && !defined(CONFIG_SLOB)
 /**
  * kmalloc_node - allocate memory from a specific node
  * @size: how many bytes of memory are required.
@@ -206,7 +206,7 @@ static inline void *kmem_cache_alloc_nod
 {
return kmem_cache_alloc(cachep, flags);
 }
-#endif /* !CONFIG_NUMA && !CONFIG_SLOB */
+#endif /* !CONFIG_SLAB_NUMA && !CONFIG_SLOB */
 
 /*
  * kmalloc_track_caller is a special version of kmalloc that records the
@@ -225,7 +225,7 @@ extern void *__kmalloc_track_caller(size
__kmalloc(size, flags)
 #endif /* DEBUG_SLAB */
 
-#ifdef CONFIG_NUMA
+#ifdef CONFIG_SLAB_NUMA
 /*
  * kmalloc_node_track_caller is a special version of kmalloc_node that
  * records the calling function of the routine calling it for slab leak
@@ -244,7 +244,7 @@ extern void *__kmalloc_node_track_caller
__kmalloc_node(size, flags, node)
 #endif
 
-#else /* CONFIG_NUMA */
+#else /* CONFIG_SLAB_NUMA */
 
 #define kmalloc_node_track_caller(size, flags, node) \
kmalloc_track_caller(size, flags)
Index: linux-2.6/include/linux/slub_def.h
===
--- linux-2.6.orig/include/linux/slub_def.h 2007-09-14 13:54:51.0 
-0700
+++ linux-2.6/include/linux/slub_def.h  2007-09-14 13:54:56.0 -0700
@@ -58,7 +58,7 @@ struct kmem_cache {
struct kobject kobj;/* For sysfs */
 #endif
 
-#ifdef CONFIG_NUMA
+#ifdef CONFIG_SLAB_NUMA
int defrag_ratio;
struct kmem_cache_node *node[MAX_NUMNODES];
 #endif
@@ -181,7 +181,7 @@ static __always_inline void *kmalloc(siz
return __kmalloc(size, flags);
 }
 
-#ifdef CONFIG_NUMA
+#ifdef CONFIG_SLAB_NUMA
 void *__kmalloc_node(size_t size, gfp_t flags, int node);
 void *kmem_cache_alloc_node(struct kmem_cache *, gfp_t flags, int node);
 
Index: linux-2.6/mm/slub.c
===
--- linux-2.6.orig/mm/slub.c2007-09-14 13:54:51.0 -0700
+++ linux-2.6/mm/slub.c 2007-09-14 13:58:50.0 -0700
@@ -137,6 +137,12 @@ static inline void ClearSlabDebug(struct
page->flags &= ~SLABDEBUG;
 }
 
+#ifdef CONFIG_SLAB_NUMA
+#define node(x) page_to_nid(x)
+#else
+#define node(x) 0
+#endif
+
 /*
  * Issues still to be resolved:
  *
@@ -260,7 +266,7 @@ int slab_is_available(void)
 
 static inline struct kmem_cache_node *get_node(struct kmem_cache *s, int node)
 {
-#ifdef CONFIG_NUMA
+#ifdef CONFIG_SLAB_NUMA
return s->node[node];
 #else
return &s->local_node;
@@ -813,7 +819,7 @@ static void remove_full(struct kmem_cach
if (!(s->flags & SLAB_STORE_USER))
return;
 
-   n = get_node(s, page_to_nid(page));
+   n = get_node(s, node(page));
 
spin_lock(&n->list_lock);
list_del(&page->lru);
@@ -1067,7 +1073,7 @@ static struct page *new_slab(struct kmem
if (!page)
goto out;
 
-   n = get_node(s, page_to_nid(page));
+   n = get_node(s, node(page));
if (n)
atomic_long_inc(&n->nr_slabs);
page->slab = s;
@@ -1141,7 +1147,7 @@ static void free_slab(struct kmem_cache 
 
 static void discard_slab(struct kmem_cache *s, struct page *page)
 {
-   struct kmem_cache_node *n = get_node(s, page_to_nid(page));
+   struct kmem_cache_node *n = get_node(s, node(page));
 
atomic_long_dec(&n->nr_slabs);
reset_page_mapcount(page);
@@ -1192,7 +1198,7 @@ static void add_partial(struct kmem_cach
 static void remove_partial(struct kmem_cache *s,
struct page *page)
 {
-   struct kmem_cache_node *n = get_node(s, page_to_nid(page));
+   struct kmem_cache_node *n = get_node(s, node(page));
 
spin_lock(&n->list_lock);
list_del(&page->lru);
@@ -1247,7 +1253,7 @@ out:
  */
 static struct page *get_any_partial(struct kmem_cache *s, gfp_t flags)
 {
-#ifdef CONFIG_NUMA
+#ifdef CONFIG_SLAB_NUMA
struct zonelist *zonelist;
struct zone **z;
struct page *page;
@@ -1315,7 +1321,7 @@ static struct page *g

Re: Define termios_1 functions for powerpc, s390, avr32 and frv

[Andrew Morton]

On Fri, 14 Sep 2007 11:33:24 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:

> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Thu, 13 Sep 2007 03:55:06 -0700
> 
> > I think we need to go with Tony's patch.  sparc32 and sparc64 are
> > presently broken too, and the patch which converts sparc to use the
> > new interfaces introduces a few build errors.
> 
> The problem with the asm-generic/termios.h thing is it only works
> if your copying functions are just a copy_{to,from}_user() and you
> can define that __ARCH_* macro.
> 
> In retrospect what that header should do is, outside of the
> ARCH_* block, define the foo_1 interfaces plainly to foo.
> 
> Alternatively, here is a patch that gets sparc compiling and
> working again in the current tree.
> 
> This whole termios thing hasn't been handled very well, and it's maybe
> not what we should be doing so late in the -rc cycle.  And yes,
> this is coming from the guy who added the TCP oops'er two weeks ago
> :-P

tell me about it.

> [SPARC]: Fix build due to termios changes.
> 
> Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
> 
> diff --git a/include/asm-sparc/termios.h b/include/asm-sparc/termios.h
> index d767f20..25e9cbb 100644
> --- a/include/asm-sparc/termios.h
> +++ b/include/asm-sparc/termios.h
> @@ -142,6 +142,11 @@ struct winsize {
>   0; \
>  })
>  
> +#define user_termios_to_kernel_termios_1(k, u) \
> + user_termios_to_kernel_termios(k, u)
> +#define kernel_termios_to_user_termios_1(u, k) \
> + kernel_termios_to_user_termios(u, k)
> +
>  #endif   /* __KERNEL__ */
>  
>  #endif /* _SPARC_TERMIOS_H */
> diff --git a/include/asm-sparc64/termios.h b/include/asm-sparc64/termios.h
> index f05d390..6fc71e6 100644
> --- a/include/asm-sparc64/termios.h
> +++ b/include/asm-sparc64/termios.h
> @@ -145,6 +145,11 @@ struct winsize {
>   err; \
>  })
>  
> +#define user_termios_to_kernel_termios_1(k, u) \
> + user_termios_to_kernel_termios(k, u)
> +#define kernel_termios_to_user_termios_1(u, k) \
> + kernel_termios_to_user_termios(u, k)
> +
>  #endif   /* __KERNEL__ */
>  
>  #endif /* _SPARC64_TERMIOS_H */

That fixes sparc, but I think other architectures are still broken.  And if
we use Tony's ifdef patch to fix the other architectures, that makes the
above sparc-fix patch unneeded.

argh.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 consts where appropriate in sound/pci/hda/*

[Denys Vlasenko]

On Friday 14 September 2007 18:48, Denys Vlasenko wrote:
> There is a lot of data structures in that code,
> and most of them seems to be read-only.
> 
> I added const modifiers to most of such places:
> 
>textdata bss dec hex filename
>  106315  179564  36  285915   45cdb snd-hda-intel.o
>  2830512624  36  285711   45c0f snd-hda-intel_patched.o
> 
> Patch is attached.
> 
> It moves "static struct hda_codec_preset *hda_preset_tables[]"
> from hda_patch.h to hda_codec.c, and then adds
> #include "hda_patch.h"
> in a few .c files so that definitions of e.g.
> const struct hda_codec_preset snd_hda_preset_analog[]
> are checked to match declarations in hda_patch.h
> 
> The rest of the patch (bulk of it) adds "const"
> in many places.
> 
> Patch is compile tested. Please apply.

After additional testing I found a place where
I forgot to add 'const', and build throws warnings
at me.

Updated patch is attached.

Signed-off-by: Denys Vlasenko <[EMAIL PROTECTED]>
--
vda


constify_hda_codec_v2.diff.bz2
Description: BZip2 compressed data

Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Anthony Liguori]

Jeremy Fitzhardinge wrote:

Anthony Liguori wrote:
  

Yeah, see, the initial goal was to make it possible to use the KVM
paravirtualizations on other hypervisors.  However, I don't think this
is really going to be possible in general so maybe it's better to just
use leaf 0.  I'll let others chime in before sending a new patch.



Hm.  Obviously you can just define a signature for "kvm-compatible
hypercall interface" and make it common that way, but it gets tricky if
the hypervisor supports multiple hypercall interfaces, including the kvm
one.  Start the kvm leaves at 0x40001000 or something?
  


Yeah, that works with me.

Regards,

Anthony Liguori


J

  


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 update] SCSI: update Kconfig help text to indicate SCSI core's widespread usage

[FUJITA Tomonori]

On Fri, 14 Sep 2007 23:14:21 +0200 (CEST)
Stefan Richter <[EMAIL PROTECTED]> wrote:

> Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
> ---
> 
> And one more update:
> There is SAS too, and I forgot 'is' in "on a disk which __ accessed via".
> 
>  drivers/scsi/Kconfig |   67 ++-
>  1 file changed, 35 insertions(+), 32 deletions(-)
> 
> Index: linux-2.6.23-rc6/drivers/scsi/Kconfig
> ===
> --- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig
> +++ linux-2.6.23-rc6/drivers/scsi/Kconfig
> @@ -12,23 +12,31 @@ config SCSI
>   depends on BLOCK
>   select SCSI_DMA if HAS_DMA
>   ---help---
> -   If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or
> -   any other SCSI device under Linux, say Y and make sure that you know
> -   the name of your SCSI host adapter (the card inside your computer
> -   that "speaks" the SCSI protocol, also called SCSI controller),
> -   because you will be asked for it.
> -
> -   You also need to say Y here if you have a device which speaks
> -   the SCSI protocol.  Examples of this include the parallel port
> -   version of the IOMEGA ZIP drive, USB storage devices, Fibre
> -   Channel, FireWire storage and the IDE-SCSI emulation driver.
> +   This option enables core support for SCSI protocols.
> +   You need it
> +   - for classic parallel SCSI hardware,
> +   - for newer SCSI transports such as Fibre Channel, FireWire storage,
> + SAS, or iSCSI,

There is SRP 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: [linux-dvb] [PATCH] Userspace tuner

[Manu Abraham]

Aidan Thornton wrote:

> 
> I think this will require a rethink of either how the em2880-dvb
> driver works or how frontend drivers work. The current API expects
> users to initialise their frontend and then bind a tuner to it.
> em2880-dvb is a sort of subdriver that attaches to the main driver,
> and doesn't have any control over when or how it initialises its
> tuner, so it can't delay tuner initialisation until the frontend has
> been initialised. (I don't think it's the only hybrid driver that
> works this way either). Of course, I could be missing something.

The em28xx/xc3028 is in fact not too complex. Just for sake of
demonstration, some time back i had posted a dummy driver how it can be
done in a nice and clean way as an example.

The patch assumes some additional standards, you can ignore them. But
you get the general idea from in there.
http://marc.info/?l=linux-video&m=117613833119350&w=2


> 
>> There is no reason why the Xceive driver cannot be merged into the
>> current development tree using the hybrid tuner framework as it stands
>> today.
> 
> I'm not convinced this is entirely true. In order to avoid unnecessary
> reinitialisation of the device, the driver needs to know whether the
> device is in analog or digital mode, and I can't see a way of doing it
> with the current API. (I think existing drivers, such as the xc2028
> driver in one branch, use the older analog API and make the digital
> driver a wrapper around it.) Again, I may be missing something.

You can read this post also for some additional information.
http://marc.info/?l=linux-video&m=117922735929375&w=2

Use the ideas as you deem fit. ;-)

Manu
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] list.h: add list_for_each_entry_continue_rcu

[Paul E. McKenney]

On Fri, Sep 14, 2007 at 11:14:58PM +0200, Johannes Berg wrote:
> On Mon, 2007-09-10 at 10:39 -0700, Paul E. McKenney wrote:
> > On Mon, Sep 10, 2007 at 02:05:47PM +0200, Johannes Berg wrote:
> > > To implement the multicast list callback in mac80211 we need to
> > > do partial list iteration. Since I want to convert the interface
> > > list to an RCU list, I need a new list walking primitive:
> > > list_for_each_entry_continue_rcu().
> 
> Hah. Turns out if I do the right thing with dev_mc_sync() I no longer
> need this. Paul, do you want to push it to akpm or such? My bugfix no
> longer relies on it.

OK, will push it when I convert list_for_each_continue_rcu().

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

Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Jeremy Fitzhardinge]

Anthony Liguori wrote:
> Yeah, see, the initial goal was to make it possible to use the KVM
> paravirtualizations on other hypervisors.  However, I don't think this
> is really going to be possible in general so maybe it's better to just
> use leaf 0.  I'll let others chime in before sending a new patch.

Hm.  Obviously you can just define a signature for "kvm-compatible
hypercall interface" and make it common that way, but it gets tricky if
the hypervisor supports multiple hypercall interfaces, including the kvm
one.  Start the kvm leaves at 0x40001000 or something?

J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Anthony Liguori]

Jeremy Fitzhardinge wrote:

Anthony Liguori wrote:
  

The whole point of using the instruction is to allow hypercalls to be
used in many locations.  This has the nice side effect of not
requiring a central hypercall initialization routine in the guest to
fetch the hypercall page.  A PV driver can be completely independent
of any other code provided that it restricts itself to it's hypercall
namespace.



I see.  So you take the fault, disassemble the instruction, see that its
another CPU's vmcall instruction, and then replace it with the current
CPU's vmcall?
  


Yup.

Xen is currently using 0/1/2.  I had thought it was only using 0/1. 
The intention was not to squash Xen's current CPUID usage so that it

would still be possible for Xen to make use of the guest code.  Can we
agree that Xen won't squash leaves 3/4 or is it not worth trying to be
compatible at this point?



No, the point is that you're supposed to work out which hypervisor it is
from the signature in leaf 0, and then the hypervisor can put anything
it wants in the other leaves.
  


Yeah, see, the initial goal was to make it possible to use the KVM 
paravirtualizations on other hypervisors.  However, I don't think this 
is really going to be possible in general so maybe it's better to just 
use leaf 0.  I'll let others chime in before sending a new patch.


Regards,

Anthony Liguori


J

  


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Anthony Liguori]

Zachary Amsden wrote:

On Fri, 2007-09-14 at 16:02 -0500, Anthony Liguori wrote:
  

Jeremy Fitzhardinge wrote:


Anthony Liguori wrote:
  
  

This patch refactors the current hypercall infrastructure to better support live
migration and SMP.  It eliminates the hypercall page by trapping the UD
exception that would occur if you used the wrong hypercall instruction for the
underlying architecture and replacing it with the right one lazily.
  



I guess it would be pretty rude/unlikely for these opcodes to get reused
in other implementations...  But couldn't you make the page trap
instead, rather than relying on an instruction fault?
  
  
The whole point of using the instruction is to allow hypercalls to be 
used in many locations.  This has the nice side effect of not requiring 
a central hypercall initialization routine in the guest to fetch the 
hypercall page.  A PV driver can be completely independent of any other 
code provided that it restricts itself to it's hypercall namespace.



But if the instruction is architecture dependent, and you run on the
wrong architecture, now you have to patch many locations at fault time,
introducing some nasty runtime code / data cache overlap performance
problems.  Granted, they go away eventually.
  


We're addressing that by blowing away the shadow cache and holding the 
big kvm lock to ensure SMP safety.  Not a great thing to do from a 
performance perspective but the whole point of patching is that the cost 
is amortized.



I prefer the idea of a hypercall page, but not a central initialization.
Rather, a decentralized approach where PV drivers can detect using CPUID
which hypervisor is present, and a common MSR shared by all hypervisors
that provides the location of the hypercall page.
  


So then each module creates a hypercall page using this magic MSR and 
the hypervisor has to keep track of it so that it can appropriately 
change the page on migration.  The page can only contain a single 
instruction or else it cannot be easily changed (or you have to be able 
to prevent the guest from being migrated while in the hypercall page).


We're really talking about identical models.  Instead of an MSR, the #GP 
is what tells the hypervisor to update the instruction.  The nice thing 
about this is that you don't have to keep track of all the current 
hypercall page locations in the hypervisor.


Regards,

Anthony Liguori


Zach


  


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Fix BIOS-e820 end address

[Keshavamurthy, Anil S]

On Fri, Sep 14, 2007 at 02:31:59PM -0700, Siddha, Suresh B wrote:
> On Fri, Sep 14, 2007 at 02:00:02PM -0700, Jeremy Fitzhardinge wrote:
> > Keshavamurthy, Anil S wrote:
> > > Subject: [patch] Fix BIOS-e820 end address
> > >
> > > --snip of boot message--
> > > BIOS-provided physical RAM map:
> > >  BIOS-e820:  - 000a (usable)
> > >  BIOS-e820: 000f - 0010 (reserved)
> > >  BIOS-e820: 0010 - 7fe8cc00 (usable)
> > > end snip---
> > >
> > > As you see from above the address 0010 is both
> > > shown as reserved and usable which is confusing.
> > >   
> > 
> > I think this is consistent with many other kernel interfaces (such as
> > /proc/X/maps) where the end address is taken to be exclusive: [0xf,
> > 0x10).
> 
> Andrew, Please disregard this patch. As Jermy, Jan pointed out, this
> will cause more confusions. Thanks. 
I agree, we can discard my patch.

-Anil
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Fix BIOS-e820 end address

[Siddha, Suresh B]

On Fri, Sep 14, 2007 at 02:00:02PM -0700, Jeremy Fitzhardinge wrote:
> Keshavamurthy, Anil S wrote:
> > Subject: [patch] Fix BIOS-e820 end address
> >
> > --snip of boot message--
> > BIOS-provided physical RAM map:
> >  BIOS-e820:  - 000a (usable)
> >  BIOS-e820: 000f - 0010 (reserved)
> >  BIOS-e820: 0010 - 7fe8cc00 (usable)
> > end snip---
> >
> > As you see from above the address 0010 is both
> > shown as reserved and usable which is confusing.
> >   
> 
> I think this is consistent with many other kernel interfaces (such as
> /proc/X/maps) where the end address is taken to be exclusive: [0xf,
> 0x10).

Andrew, Please disregard this patch. As Jermy, Jan pointed out, this
will cause more confusions. 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: [PATCH] Add ELF note with Linux version

[Jeremy Fitzhardinge]

Sam Ravnborg wrote:
>>> This seems outright silly.
>>> Either we should revert the notes changes or someone caring about it 
>>> should sweep all archs and make sure it does not hurt there.
>>>   
>> Hm, sounds like yet another binutils bug; unfortunately common when ELF
>> notes are about.  Was there any further effort to isolate what was
>> causing the problem?
>> 
>
> Lennart posted this:
> An ARM vmlinux kernel image built with pre-build-id binutils has:
>
> Program Header:
> LOAD off0x8000 vaddr 0xc0008000 paddr 0xc0008000 align 
> 2**15
>  filesz 0x002e503c memsz 0x003032c0 flags rwx
> private flags = 402: [Version4 EABI] [has entry point]
>
>
> Whereas a build-id binutils-built vmlinux kernel image ends up with:
>
> Program Header:
> LOAD off0x8000 vaddr 0x paddr 0x align 
> 2**15
>  filesz 0x0024 memsz 0x0024 flags r--
> LOAD off0x0001 vaddr 0xc0008000 paddr 0xc0008000 align 
> 2**15
>  filesz 0x002e503c memsz 0x003032c0 flags rwx
> NOTE off0x8000 vaddr 0x paddr 0x align 
> 2**2
>  filesz 0x0024 memsz 0x0024 flags r--
> private flags = 402: [Version4 EABI] [has entry point]
>
>
> The .note.gnu.build-id section causes objcopy to produce a 3G+
> Image file, breaking the build.
>   

Hm, these phdrs seem OK though; I don't see any ~3Gish numbers here, so
it looks like objcopy is just going off into the weeds. 

I don't know how ARM images are built, but I would guess that something
is trying to make the file large enough to accomodate a 3Gish kernel
virtual address address which hasn't being appropriately phys-ized.  It
may be more a linker script bug than an inherent problem with either
notes or build-id themselves.

> Samuel Ortiz posted following patch:
>   
>> With build-id binutils (e.g. the latest bintuils 2.18), objcopy produces
>> a 3.1 Gbytes Image file. Adding a note section fixes the problem.
>>
>> Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
>> Cc: Lennert Buytenhek <[EMAIL PROTECTED]>
>> Cc: Sam Ravnborg <[EMAIL PROTECTED]>
>>
>> ---
>>  arch/arm/kernel/vmlinux.lds.S |1 +
>>  1 file changed, 1 insertion(+)
>>
>> Index: linux-2.6.22/arch/arm/kernel/vmlinux.lds.S
>> ===
>> --- linux-2.6.22.orig/arch/arm/kernel/vmlinux.lds.S   2007-09-11 
>> 18:32:29.0 +0200
>> +++ linux-2.6.22/arch/arm/kernel/vmlinux.lds.S2007-09-11 
>> 18:33:42.0 +0200
>> @@ -94,6 +94,7 @@
>>   TEXT_TEXT
>>   SCHED_TEXT
>>   LOCK_TEXT
>> + *(.note.*)
>>  #ifdef CONFIG_MMU
>>   *(.fixup)
>>  #endif
>> 
>
>
> I cannot see why this should fix it since the patch does
> not discard the section. Maybe the inclusion of the section in
> some oter section does some good.
>   

Yes, binutils can be pretty fragile with notes about.  In this case it
seems to be a specific problem with build-id; I'm not really sure what
build-id actually does.

Though if my theory above is true, it may end up properly assigning a
value to a symbol
by putting it into the right section.  Or something.
> Anyway the original submitter of the build-id should have identified such
> issues and fixed all archs.
>
> And I still do not get exactly what problem the note section solves when
> included in vmlinux

The Note section is supposed to be a general extensible way of adding
metadata to an object file, either for a linker or a loader.  There's no
inherent connection between notes and build-id (other than build-id is
one of the users of notes, I suppose).

J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.23-rc6: usb 1-1: device not accepting address 2, error -62

[Christian Volkmann]

Hi everybody,

I have an error message with 2.6.23-rc6.
This did not happen with 2.6.22.

The kernel reports message like this:
 <3>usb 1-1: device not accepting address 2, error -62
 <3>hub 2-2.1:1.0: hub_port_status failed (err = -71)

Does this message harm or is something broken in 2.6.23-rc6 ?
I get this kind of messages also with 2.6.23-rc3

Best regards,

Christian


Please see below for:

grep -e hub -e usb boot.msg for a 2.6.23-rc6 boot. (that boot was without (err 
= -71)
grep -e hub -e usb boot.msg for a 2.6.22 boot.
lspci -vnn (2.6.22)
lsusb -v (2.6.22)


2.6.23-rc6 boot.msg extract ( hub/usb )

<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>usb usb1: configuration #1 chosen from 1 choice
<6>hub 1-0:1.0: USB hub found
<6>hub 1-0:1.0: 2 ports detected
<6>usb usb2: configuration #1 chosen from 1 choice
<6>hub 2-0:1.0: USB hub found
<6>hub 2-0:1.0: 2 ports detected
<6>usb 1-1: new low speed USB device using ohci_hcd and address 2
<6>usb usb3: configuration #1 chosen from 1 choice
<6>hub 3-0:1.0: USB hub found
<6>hub 3-0:1.0: 2 ports detected
<6>usb usb4: configuration #1 chosen from 1 choice
<6>hub 4-0:1.0: USB hub found
<6>hub 4-0:1.0: 6 ports detected
<6>usb usb5: configuration #1 chosen from 1 choice
<6>hub 5-0:1.0: USB hub found
<6>hub 5-0:1.0: 2 ports detected
<3>usb 1-1: device not accepting address 2, error -62
<6>usb 5-2: new full speed USB device using uhci_hcd and address 2
<6>usb usb6: configuration #1 chosen from 1 choice
<6>hub 6-0:1.0: USB hub found
<6>hub 6-0:1.0: 4 ports detected
<6>usb usb7: configuration #1 chosen from 1 choice
<6>hub 7-0:1.0: USB hub found
<6>hub 7-0:1.0: 2 ports detected
<6>usb 1-1: new low speed USB device using ohci_hcd and address 4
<6>usb 1-1: configuration #1 chosen from 1 choice
<6>usb 2-1: new full speed USB device using ohci_hcd and address 2
<6>usb 2-1: configuration #1 chosen from 1 choice
<6>usb 6-2: new high speed USB device using ehci_hcd and address 2
<6>usb 6-2: configuration #1 chosen from 1 choice
<6>hub 6-2:1.0: USB hub found
<6>hub 6-2:1.0: 2 ports detected
<6>usbcore: registered new interface driver hiddev
<6>input: USB HID v1.11 Mouse [USB Optical Mouse] on usb-:00:03.0-1
<6>usbcore: registered new interface driver usbhid
<6>drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
<7>usb-storage: device found at 2
<7>usb-storage: waiting for device to settle before scanning
<6>usb 6-2.1: new high speed USB device using ehci_hcd and address 3
<6>usb 6-2.1: configuration #1 chosen from 1 choice
<6>hub 6-2.1:1.0: USB hub found
<6>hub 6-2.1:1.0: 4 ports detected
<6>usb 6-2.1.1: new high speed USB device using ehci_hcd and address 4
<6>usb 6-2.1.1: configuration #1 chosen from 1 choice
<7>usb-storage: device found at 4
<7>usb-storage: waiting for device to settle before scanning
<6>usbcore: registered new interface driver usb-storage
<7>usb-storage: device scan complete
<7>usb-storage: device scan complete

2.6.22 boot.msg extract ( hub/usb )

<6>usbcore: registered new interface driver usbfs
<6>usbcore: registered new interface driver hub
<6>usbcore: registered new device driver usb
<6>usb usb1: configuration #1 chosen from 1 choice
<6>hub 1-0:1.0: USB hub found
<6>hub 1-0:1.0: 2 ports detected
<6>usb usb2: configuration #1 chosen from 1 choice
<6>hub 2-0:1.0: USB hub found
<6>hub 2-0:1.0: 2 ports detected
<6>usb 1-1: new low speed USB device using ohci_hcd and address 2
<6>usb usb3: configuration #1 chosen from 1 choice
<6>hub 3-0:1.0: USB hub found
<6>hub 3-0:1.0: 2 ports detected
<6>usb 1-1: configuration #1 chosen from 1 choice
<6>usb usb4: configuration #1 chosen from 1 choice
<6>hub 4-0:1.0: USB hub found
<6>hub 4-0:1.0: 6 ports detected
<6>usb 1-1: USB disconnect, address 2
<6>usb usb5: configuration #1 chosen from 1 choice
<6>hub 5-0:1.0: USB hub found
<6>hub 5-0:1.0: 4 ports detected
<6>usb usb6: configuration #1 chosen from 1 choice
<6>hub 6-0:1.0: USB hub found
<6>hub 6-0:1.0: 2 ports detected
<6>usb usb7: configuration #1 chosen from 1 choice
<6>hub 7-0:1.0: USB hub found
<6>hub 7-0:1.0: 2 ports detected
<6>usb 5-2: new high speed USB device using ehci_hcd and address 2
<6>usb 5-2: configuration #1 chosen from 1 choice
<6>hub 5-2:1.0: USB hub found
<6>hub 5-2:1.0: 2 ports detected
<6>usb 1-1: new low speed USB device using ohci_hcd and address 3
<6>usb 1-1: configuration #1 chosen from 1 choice
<6>usbcore: registered new interface driver hiddev
<6>usb 2-1: new full speed USB device using ohci_hcd and address 2
<6>usb 2-1: configuration #1 chosen from 1 choice
<6>usb 5-2.1: new high speed USB device using ehci_hcd and address 3
<6>usb 5-2.1: configuration #1 chosen from 1 choice
<6>hub 5-2.1:1.0: USB hub found
<6>hub 5-2.1:1.0: 4 ports detected
<6>input: USB HID v1.11 Mouse [USB Optical Mouse] on usb-:00:03.0-1
<7>usb-storage: device found at 2
<7>usb-storage: waiting for device to settle before scanning
<6>usb 5-2.1.1: new high 

Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Jeremy Fitzhardinge]

Anthony Liguori wrote:
> The whole point of using the instruction is to allow hypercalls to be
> used in many locations.  This has the nice side effect of not
> requiring a central hypercall initialization routine in the guest to
> fetch the hypercall page.  A PV driver can be completely independent
> of any other code provided that it restricts itself to it's hypercall
> namespace.

I see.  So you take the fault, disassemble the instruction, see that its
another CPU's vmcall instruction, and then replace it with the current
CPU's vmcall?

> Xen is currently using 0/1/2.  I had thought it was only using 0/1. 
> The intention was not to squash Xen's current CPUID usage so that it
> would still be possible for Xen to make use of the guest code.  Can we
> agree that Xen won't squash leaves 3/4 or is it not worth trying to be
> compatible at this point?

No, the point is that you're supposed to work out which hypervisor it is
from the signature in leaf 0, and then the hypervisor can put anything
it wants in the other leaves.

J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Zachary Amsden]

On Fri, 2007-09-14 at 16:02 -0500, Anthony Liguori wrote:
> Jeremy Fitzhardinge wrote:
> > Anthony Liguori wrote:
> >   
> >> This patch refactors the current hypercall infrastructure to better 
> >> support live
> >> migration and SMP.  It eliminates the hypercall page by trapping the UD
> >> exception that would occur if you used the wrong hypercall instruction for 
> >> the
> >> underlying architecture and replacing it with the right one lazily.
> >>   
> >> 
> >
> > I guess it would be pretty rude/unlikely for these opcodes to get reused
> > in other implementations...  But couldn't you make the page trap
> > instead, rather than relying on an instruction fault?
> >   
> 
> The whole point of using the instruction is to allow hypercalls to be 
> used in many locations.  This has the nice side effect of not requiring 
> a central hypercall initialization routine in the guest to fetch the 
> hypercall page.  A PV driver can be completely independent of any other 
> code provided that it restricts itself to it's hypercall namespace.

But if the instruction is architecture dependent, and you run on the
wrong architecture, now you have to patch many locations at fault time,
introducing some nasty runtime code / data cache overlap performance
problems.  Granted, they go away eventually.

I prefer the idea of a hypercall page, but not a central initialization.
Rather, a decentralized approach where PV drivers can detect using CPUID
which hypervisor is present, and a common MSR shared by all hypervisors
that provides the location of the hypercall page.

Zach

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

SCO files for bankruptcy

[Jon Masters]

Hey,

I wouldn't normally post news stories...but in case anyone is living
under a rock, not reading Slashdot, LWN, or one of a bazillion other
news sites that are *bound* to cover this at some point about now...

http://www.groklaw.net/article.php?story=20070914152904577

Have an awesome weekend, everyone! :-)

Jon.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Distributed storage. Move away from char device ioctls.

[J. Bruce Fields]

On Fri, Sep 14, 2007 at 05:14:53PM -0400, Jeff Garzik wrote:
> J. Bruce Fields wrote:
>> On Fri, Sep 14, 2007 at 03:07:46PM -0400, Jeff Garzik wrote:
>>> I've been waiting for years for a smart person to come along and write a 
>>> POSIX-only distributed filesystem.
>
>> What exactly do you mean by "POSIX-only"?
>
> Don't bother supporting attributes, file modes, and other details not 
> supported by POSIX.  The prime example being NFSv4, which is larded down 
> with Windows features.

I am sympathetic  Cutting those out may still leave you with
something pretty complicated, though.

> NFSv4.1 adds to the fun, by throwing interoperability completely out the 
> window.

What parts are you worried about in particular?

--b.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-dvb] [PATCH] Userspace tuner

[Mauro Carvalho Chehab]

> > There is no reason why the Xceive driver cannot be merged into the
> > current development tree using the hybrid tuner framework as it stands
> > today.
> 
> I'm not convinced this is entirely true. In order to avoid unnecessary
> reinitialisation of the device, the driver needs to know whether the
> device is in analog or digital mode, and I can't see a way of doing it
> with the current API. (I think existing drivers, such as the xc2028
> driver in one branch, use the older analog API and make the digital
> driver a wrapper around it.) Again, I may be missing something.

For sure there are some ways. One dirty way would be to add an static
lock at xc3028 driver. You can rise the lock when firmware is being
uploaded, removing it at the end. This would prevent the troubles you've
mentioned.

A cleaner way would be to create a tasklet for firmware upload. This
will also prevent the driver for a long load time, due to firmware
initialization (a similar change were recently added at ivtv driver).

For sure there are other ways of doing this.
 
Cheers,
Mauro

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 ELF note with Linux version

[Roland McGrath]

The right fix for the linker script is to use the NOTES macro after RODATA.
I'm pretty sure this has been posted before.  Each arch's vmlinux.lds.S
needs that change, but the details vary if it uses an explicit PHDRS.


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

[PATCH update] SCSI: update Kconfig help text to indicate SCSI core's widespread usage

[Stefan Richter]

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---

And one more update:
There is SAS too, and I forgot 'is' in "on a disk which __ accessed via".

 drivers/scsi/Kconfig |   67 ++-
 1 file changed, 35 insertions(+), 32 deletions(-)

Index: linux-2.6.23-rc6/drivers/scsi/Kconfig
===
--- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig
+++ linux-2.6.23-rc6/drivers/scsi/Kconfig
@@ -12,23 +12,31 @@ config SCSI
depends on BLOCK
select SCSI_DMA if HAS_DMA
---help---
- If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or
- any other SCSI device under Linux, say Y and make sure that you know
- the name of your SCSI host adapter (the card inside your computer
- that "speaks" the SCSI protocol, also called SCSI controller),
- because you will be asked for it.
-
- You also need to say Y here if you have a device which speaks
- the SCSI protocol.  Examples of this include the parallel port
- version of the IOMEGA ZIP drive, USB storage devices, Fibre
- Channel, FireWire storage and the IDE-SCSI emulation driver.
+ This option enables core support for SCSI protocols.
+ You need it
+ - for classic parallel SCSI hardware,
+ - for newer SCSI transports such as Fibre Channel, FireWire storage,
+   SAS, or iSCSI,
+ - for non-SCSI hardware which speaks SCSI protocols, such as USB
+   storage devices or the parallel port version of Iomega Zip drive,
+ - for non-SCSI hardware whose drivers translate from and to SCSI
+   protocols, most notably all Serial ATA drivers, and Parallel ATA
+   via the ATA configuration option.
 
  To compile this driver as a module, choose M here and read
  .
  The module will be called scsi_mod.
 
  However, do not compile this as a module if your root file system
- (the one containing the directory /) is located on a SCSI device.
+ (the one containing the directory /) is located on a SCSI device
+ or on a device whose driver represents it as SCSI device, as
+ indicated above.  Choose Y in this case, or set up an initrd.
+
+ Subsequent options in this menu enable specific SCSI command set
+ support for harddisks, CD/DVD-ROM/R/W, tapes etc..  This menu also
+ presents options for specific SCSI controllers, while options for
+ some other SCSI transports and all non-SCSI controllers are located
+ in other menus (SATA, USB, FireWire etc.).
 
 config SCSI_DMA
bool
@@ -57,32 +65,27 @@ config SCSI_PROC_FS
 
  If unsure say Y.
 
-comment "SCSI support type (disk, tape, CD-ROM)"
+comment "SCSI command set drivers (disk, tape, CD-ROM)"
depends on SCSI
 
 config BLK_DEV_SD
-   tristate "SCSI disk support"
+   tristate "Harddisks and other Direct access devices"
depends on SCSI
---help---
- If you want to use SCSI hard disks, Fibre Channel disks,
- Serial ATA (SATA) or Parallel ATA (PATA) hard disks,
- USB storage or the SCSI or parallel port version of
- the IOMEGA ZIP drive, say Y and read the SCSI-HOWTO,
- the Disk-HOWTO and the Multi-Disk-HOWTO, available from
- . This is NOT for SCSI
- CD-ROMs.
+ Say Y if you want to use harddisks and similar block-oriented devices
+ via SCSI or via drivers which use SCSI command sets (e.g. the Serial
+ and Parallel ATA kernel subsystem, USB, and more).
 
  To compile this driver as a module, choose M here and read
  .
  The module will be called sd_mod.
 
- Do not compile this driver as a module if your root file system
- (the one containing the directory /) is located on a SCSI disk.
- In this case, do not compile the driver for your SCSI host adapter
- (below) as a module either.
+ If your root file system (the one containing the directory /) is
+ located on a disk which is accessed via this driver, choose Y rather
+ than M or set up a suitable initrd.
 
 config CHR_DEV_ST
-   tristate "SCSI tape support"
+   tristate "Tape drives"
depends on SCSI
---help---
  If you want to use a SCSI tape drive under Linux, say Y and read the
@@ -95,7 +98,7 @@ config CHR_DEV_ST
  . The module will be called st.
 
 config CHR_DEV_OSST
-   tristate "SCSI OnStream SC-x0 tape support"
+   tristate "SCSI OnStream SC-x0 tape drives"
depends on SCSI
---help---
  The OnStream SC-x0 SCSI tape drives cannot be driven by the
@@ -117,13 +120,13 @@ config CHR_DEV_OSST
  . The module will be called osst.
 
 config BLK_DEV_SR
-   tristate "SCSI CDROM support"
+   tristate "CD-ROMs, D

Re: Distributed storage. Move away from char device ioctls.

[Jeff Garzik]

J. Bruce Fields wrote:

On Fri, Sep 14, 2007 at 03:07:46PM -0400, Jeff Garzik wrote:
I've been waiting for years for a smart person to come along and write a 
POSIX-only distributed filesystem.



What exactly do you mean by "POSIX-only"?


Don't bother supporting attributes, file modes, and other details not 
supported by POSIX.  The prime example being NFSv4, which is larded down 
with Windows features.


NFSv4.1 adds to the fun, by throwing interoperability completely out the 
window.


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] list.h: add list_for_each_entry_continue_rcu

[Johannes Berg]

On Mon, 2007-09-10 at 10:39 -0700, Paul E. McKenney wrote:
> On Mon, Sep 10, 2007 at 02:05:47PM +0200, Johannes Berg wrote:
> > To implement the multicast list callback in mac80211 we need to
> > do partial list iteration. Since I want to convert the interface
> > list to an RCU list, I need a new list walking primitive:
> > list_for_each_entry_continue_rcu().

Hah. Turns out if I do the right thing with dev_mc_sync() I no longer
need this. Paul, do you want to push it to akpm or such? My bugfix no
longer relies on it.

johannes


signature.asc
Description: This is a digitally signed message part

Re: Distributed storage. Move away from char device ioctls.

[J. Bruce Fields]

On Fri, Sep 14, 2007 at 03:07:46PM -0400, Jeff Garzik wrote:
> My thoughts.  But first a disclaimer:   Perhaps you will recall me as one 
> of the people who really reads all your patches, and examines your code and 
> proposals closely.  So, with that in mind...
>
> I question the value of distributed block services (DBS), whether its your 
> version or the others out there.  DBS are not very useful, because it still 
> relies on a useful filesystem sitting on top of the DBS.  It devolves into 
> one of two cases:  (1) multi-path much like today's SCSI, with distributed 
> filesystem arbitrarion to ensure coherency, or (2) the filesystem running 
> on top of the DBS is on a single host, and thus, a single point of failure 
> (SPOF).
>
> It is quite logical to extend the concepts of RAID across the network, but 
> ultimately you are still bound by the inflexibility and simplicity of the 
> block device.
>
> In contrast, a distributed filesystem offers far more scalability, 
> eliminates single points of failure, and offers more room for optimization 
> and redundancy across the cluster.
>
> A distributed filesystem is also much more complex, which is why 
> distributed block devices are so appealing :)
>
> With a redundant, distributed filesystem, you simply do not need any 
> complexity at all at the block device level.  You don't even need RAID.
>
> It is my hope that you will put your skills towards a distributed 
> filesystem :)  Of the current solutions, GFS (currently in kernel) scales 
> poorly, and NFS v4.1 is amazingly bloated and overly complex.
>
> I've been waiting for years for a smart person to come along and write a 
> POSIX-only distributed filesystem.

What exactly do you mean by "POSIX-only"?

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

Re: [PATCH] SCSI: update Kconfig help text to indicate SCSI core's widespread usage

[Lennart Sorensen]

On Fri, Sep 14, 2007 at 11:06:44PM +0200, Stefan Richter wrote:
> On 14 Sep, Lennart Sorensen wrote:
> > On Fri, Sep 14, 2007 at 10:14:16PM +0200, Stefan Richter wrote:
> >> -If you want to use a SCSI or FireWire CD-ROM under Linux,
> >> +If you want to use a SCSI, SATA, USB or FireWire CD-ROM or DVD-ROM,
> >>  say Y and read the SCSI-HOWTO and the CDROM-HOWTO at
> >>  . Also make sure to say
> >>  Y or M to "ISO 9660 CD-ROM file system support" later.
> > 
> > How about that one for libata driven PATA CDROM drives?  Could replace
> > SATA with libata, or something similar.
> 
> 
> From: Stefan Richter <[EMAIL PROTECTED]>
> Subject: SCSI: update Kconfig help text to indicate SCSI core's widespread 
> usage
> 
> Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
> ---
>  drivers/scsi/Kconfig |   67 ++-
>  1 file changed, 35 insertions(+), 32 deletions(-)
> 
> Index: linux-2.6.23-rc6/drivers/scsi/Kconfig
> ===
> --- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig
> +++ linux-2.6.23-rc6/drivers/scsi/Kconfig
> @@ -12,23 +12,31 @@ config SCSI
>   depends on BLOCK
>   select SCSI_DMA if HAS_DMA
>   ---help---
> -   If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or
> -   any other SCSI device under Linux, say Y and make sure that you know
> -   the name of your SCSI host adapter (the card inside your computer
> -   that "speaks" the SCSI protocol, also called SCSI controller),
> -   because you will be asked for it.
> -
> -   You also need to say Y here if you have a device which speaks
> -   the SCSI protocol.  Examples of this include the parallel port
> -   version of the IOMEGA ZIP drive, USB storage devices, Fibre
> -   Channel, FireWire storage and the IDE-SCSI emulation driver.
> +   This option enables core support for SCSI protocols.
> +   You need it
> +   - for classic parallel SCSI hardware,
> +   - for newer SCSI transports such as Fibre Channel, FireWire storage,
> + or iSCSI,
> +   - for non-SCSI hardware which speaks SCSI protocols, such as USB
> + storage devices or the parallel port version of Iomega Zip drive,
> +   - for non-SCSI hardware whose drivers translate from and to SCSI
> + protocols, most notably all Serial ATA drivers, and Parallel ATA
> + via the ATA configuration option.
>  
> To compile this driver as a module, choose M here and read
> .
> The module will be called scsi_mod.
>  
> However, do not compile this as a module if your root file system
> -   (the one containing the directory /) is located on a SCSI device.
> +   (the one containing the directory /) is located on a SCSI device
> +   or on a device whose driver represents it as SCSI device, as
> +   indicated above.  Choose Y in this case, or set up an initrd.
> +
> +   Subsequent options in this menu enable specific SCSI command set
> +   support for harddisks, CD/DVD-ROM/R/W, tapes etc..  This menu also
> +   presents options for specific SCSI controllers, while options for
> +   some other SCSI transports and all non-SCSI controllers are located
> +   in other menus (SATA, USB, FireWire etc.).
>  
>  config SCSI_DMA
>   bool
> @@ -57,32 +65,27 @@ config SCSI_PROC_FS
>  
> If unsure say Y.
>  
> -comment "SCSI support type (disk, tape, CD-ROM)"
> +comment "SCSI command set drivers (disk, tape, CD-ROM)"
>   depends on SCSI
>  
>  config BLK_DEV_SD
> - tristate "SCSI disk support"
> + tristate "Harddisks and other Direct access devices"
>   depends on SCSI
>   ---help---
> -   If you want to use SCSI hard disks, Fibre Channel disks,
> -   Serial ATA (SATA) or Parallel ATA (PATA) hard disks,
> -   USB storage or the SCSI or parallel port version of
> -   the IOMEGA ZIP drive, say Y and read the SCSI-HOWTO,
> -   the Disk-HOWTO and the Multi-Disk-HOWTO, available from
> -   . This is NOT for SCSI
> -   CD-ROMs.
> +   Say Y if you want to use harddisks and similar block-oriented devices
> +   via SCSI or via drivers which use SCSI command sets (e.g. the Serial
> +   and Parallel ATA kernel subsystem, USB, and more).
>  
> To compile this driver as a module, choose M here and read
> .
> The module will be called sd_mod.
>  
> -   Do not compile this driver as a module if your root file system
> -   (the one containing the directory /) is located on a SCSI disk.
> -   In this case, do not compile the driver for your SCSI host adapter
> -   (below) as a module either.
> +   If your root file system (the one containing the directory /) is
> +   located on a disk which accessed via this driver, choose Y instead of
> +   M or set up 

Re: [PATCH 2.6.23-rc4] qconf ("make xconfig") Search Dialog Enhancement (rev8)

[Sam Ravnborg]

Hi Shlomi Fish.

> [ I'm not subscribed to this list so please CC me on your replies. ]
We always do so at lkml..

> This patch adds an option to use either substring match, regular expression 
> match, or keywords search in the "make xconfig" Edit->Find dialog.
> 
> It also allows searching on the "help" field of the menus as well as 
> the "name" of the symbol.
> 
> This change involved adding the sym_generic_search function to the LKC, and 
> implementing sym_re_search using it.
> 
Thanks for being persistent on this.
Unless I hear otherwise from Roman I plan to apply your patch during the 
weekend.

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

Re: [PATCH] SCSI: update Kconfig help text to indicate SCSI core's widespread usage

[Stefan Richter]

On 14 Sep, Lennart Sorensen wrote:
> On Fri, Sep 14, 2007 at 10:14:16PM +0200, Stefan Richter wrote:
>> -  If you want to use a SCSI or FireWire CD-ROM under Linux,
>> +  If you want to use a SCSI, SATA, USB or FireWire CD-ROM or DVD-ROM,
>>say Y and read the SCSI-HOWTO and the CDROM-HOWTO at
>>. Also make sure to say
>>Y or M to "ISO 9660 CD-ROM file system support" later.
> 
> How about that one for libata driven PATA CDROM drives?  Could replace
> SATA with libata, or something similar.


From: Stefan Richter <[EMAIL PROTECTED]>
Subject: SCSI: update Kconfig help text to indicate SCSI core's widespread usage

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
 drivers/scsi/Kconfig |   67 ++-
 1 file changed, 35 insertions(+), 32 deletions(-)

Index: linux-2.6.23-rc6/drivers/scsi/Kconfig
===
--- linux-2.6.23-rc6.orig/drivers/scsi/Kconfig
+++ linux-2.6.23-rc6/drivers/scsi/Kconfig
@@ -12,23 +12,31 @@ config SCSI
depends on BLOCK
select SCSI_DMA if HAS_DMA
---help---
- If you want to use a SCSI hard disk, SCSI tape drive, SCSI CD-ROM or
- any other SCSI device under Linux, say Y and make sure that you know
- the name of your SCSI host adapter (the card inside your computer
- that "speaks" the SCSI protocol, also called SCSI controller),
- because you will be asked for it.
-
- You also need to say Y here if you have a device which speaks
- the SCSI protocol.  Examples of this include the parallel port
- version of the IOMEGA ZIP drive, USB storage devices, Fibre
- Channel, FireWire storage and the IDE-SCSI emulation driver.
+ This option enables core support for SCSI protocols.
+ You need it
+ - for classic parallel SCSI hardware,
+ - for newer SCSI transports such as Fibre Channel, FireWire storage,
+   or iSCSI,
+ - for non-SCSI hardware which speaks SCSI protocols, such as USB
+   storage devices or the parallel port version of Iomega Zip drive,
+ - for non-SCSI hardware whose drivers translate from and to SCSI
+   protocols, most notably all Serial ATA drivers, and Parallel ATA
+   via the ATA configuration option.
 
  To compile this driver as a module, choose M here and read
  .
  The module will be called scsi_mod.
 
  However, do not compile this as a module if your root file system
- (the one containing the directory /) is located on a SCSI device.
+ (the one containing the directory /) is located on a SCSI device
+ or on a device whose driver represents it as SCSI device, as
+ indicated above.  Choose Y in this case, or set up an initrd.
+
+ Subsequent options in this menu enable specific SCSI command set
+ support for harddisks, CD/DVD-ROM/R/W, tapes etc..  This menu also
+ presents options for specific SCSI controllers, while options for
+ some other SCSI transports and all non-SCSI controllers are located
+ in other menus (SATA, USB, FireWire etc.).
 
 config SCSI_DMA
bool
@@ -57,32 +65,27 @@ config SCSI_PROC_FS
 
  If unsure say Y.
 
-comment "SCSI support type (disk, tape, CD-ROM)"
+comment "SCSI command set drivers (disk, tape, CD-ROM)"
depends on SCSI
 
 config BLK_DEV_SD
-   tristate "SCSI disk support"
+   tristate "Harddisks and other Direct access devices"
depends on SCSI
---help---
- If you want to use SCSI hard disks, Fibre Channel disks,
- Serial ATA (SATA) or Parallel ATA (PATA) hard disks,
- USB storage or the SCSI or parallel port version of
- the IOMEGA ZIP drive, say Y and read the SCSI-HOWTO,
- the Disk-HOWTO and the Multi-Disk-HOWTO, available from
- . This is NOT for SCSI
- CD-ROMs.
+ Say Y if you want to use harddisks and similar block-oriented devices
+ via SCSI or via drivers which use SCSI command sets (e.g. the Serial
+ and Parallel ATA kernel subsystem, USB, and more).
 
  To compile this driver as a module, choose M here and read
  .
  The module will be called sd_mod.
 
- Do not compile this driver as a module if your root file system
- (the one containing the directory /) is located on a SCSI disk.
- In this case, do not compile the driver for your SCSI host adapter
- (below) as a module either.
+ If your root file system (the one containing the directory /) is
+ located on a disk which accessed via this driver, choose Y instead of
+ M or set up a suitable initrd.
 
 config CHR_DEV_ST
-   tristate "SCSI tape support"
+   tristate "Tape drives"
depends on SCSI
 

Re: [linux-dvb] [PATCH] Userspace tuner

[Aidan Thornton]

Hi,

On 9/14/07, Michael Krufky <[EMAIL PROTECTED]> wrote:
> On 9/14/07, Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote:
> > > > - The hybrid tuner support, that where your requirement, when all those
> > > > discussions started, were already added to the subsystem. So now, an
> > > > hybrid tuner can be accessed by both DVB and V4L devices;
> > > >
> > >
> > > It's far more complex as the thing which is implemented there.
> > > The only thing that has been implemented is that one moduleformat
> > > can be loaded by the v4l and by the dvb framework nothing else at the
> > > moment. I told you at the kernel summit about that and I think you
> > > knew about that before.
> > >
> > > Just to quote some text:
> > > "Right now, a separate instance of the driver is used for analog /
> > > digital tuning.  In order to use a single instance, we will have to
> > > store a pointer to the dvb_frontend structure on the bridge level, but
> > > there are various other prerequisites that must be dealt with before we
> > > get to that point.
> > >
> > > We _will_ get there though, eventually."
> >
> > Maybe it is still not perfect. Feel free to improve it. Several people
> > from the community, including me, already offered you help to add your
> > driver, reworking on the 5% of the stuff that aren't compatible with the
> > V4L/DVB core API design.
>
> For clarification, Markus is quoting me, above.
>
> The idea is to eventually store a pointer to the dvb_frontend
> structure on the bridge level to be used as a single entry point
> between the analog and digital subsystems.  However, we are not yet
> ready for this, as the refactoring process has a lot more to be done
> beforehand.

I think this will require a rethink of either how the em2880-dvb
driver works or how frontend drivers work. The current API expects
users to initialise their frontend and then bind a tuner to it.
em2880-dvb is a sort of subdriver that attaches to the main driver,
and doesn't have any control over when or how it initialises its
tuner, so it can't delay tuner initialisation until the frontend has
been initialised. (I don't think it's the only hybrid driver that
works this way either). Of course, I could be missing something.

> There is no reason why the Xceive driver cannot be merged into the
> current development tree using the hybrid tuner framework as it stands
> today.

I'm not convinced this is entirely true. In order to avoid unnecessary
reinitialisation of the device, the driver needs to know whether the
device is in analog or digital mode, and I can't see a way of doing it
with the current API. (I think existing drivers, such as the xc2028
driver in one branch, use the older analog API and make the digital
driver a wrapper around it.) Again, I may be missing something.

Aidan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 ELF note with Linux version

[Sam Ravnborg]

> > This seems outright silly.
> > Either we should revert the notes changes or someone caring about it 
> > should sweep all archs and make sure it does not hurt there.
> 
> Hm, sounds like yet another binutils bug; unfortunately common when ELF
> notes are about.  Was there any further effort to isolate what was
> causing the problem?

Lennart posted this:
An ARM vmlinux kernel image built with pre-build-id binutils has:

Program Header:
LOAD off0x8000 vaddr 0xc0008000 paddr 0xc0008000 align 2**15
 filesz 0x002e503c memsz 0x003032c0 flags rwx
private flags = 402: [Version4 EABI] [has entry point]


Whereas a build-id binutils-built vmlinux kernel image ends up with:

Program Header:
LOAD off0x8000 vaddr 0x paddr 0x align 2**15
 filesz 0x0024 memsz 0x0024 flags r--
LOAD off0x0001 vaddr 0xc0008000 paddr 0xc0008000 align 2**15
 filesz 0x002e503c memsz 0x003032c0 flags rwx
NOTE off0x8000 vaddr 0x paddr 0x align 2**2
 filesz 0x0024 memsz 0x0024 flags r--
private flags = 402: [Version4 EABI] [has entry point]


The .note.gnu.build-id section causes objcopy to produce a 3G+
Image file, breaking the build.


Samuel Ortiz posted following patch:
> With build-id binutils (e.g. the latest bintuils 2.18), objcopy produces
> a 3.1 Gbytes Image file. Adding a note section fixes the problem.
> 
> Signed-off-by: Samuel Ortiz <[EMAIL PROTECTED]>
> Cc: Lennert Buytenhek <[EMAIL PROTECTED]>
> Cc: Sam Ravnborg <[EMAIL PROTECTED]>
> 
> ---
>  arch/arm/kernel/vmlinux.lds.S |1 +
>  1 file changed, 1 insertion(+)
> 
> Index: linux-2.6.22/arch/arm/kernel/vmlinux.lds.S
> ===
> --- linux-2.6.22.orig/arch/arm/kernel/vmlinux.lds.S   2007-09-11 
> 18:32:29.0 +0200
> +++ linux-2.6.22/arch/arm/kernel/vmlinux.lds.S2007-09-11 
> 18:33:42.0 +0200
> @@ -94,6 +94,7 @@
>   TEXT_TEXT
>   SCHED_TEXT
>   LOCK_TEXT
> + *(.note.*)
>  #ifdef CONFIG_MMU
>   *(.fixup)
>  #endif


I cannot see why this should fix it since the patch does
not discard the section. Maybe the inclusion of the section in
some oter section does some good.

Anyway the original submitter of the build-id should have identified such
issues and fixed all archs.

And I still do not get exactly what problem the note section solves when
included in vmlinux

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

Re: [kvm-devel] [PATCH] Refactor hypercall infrastructure

[Anthony Liguori]

Jeremy Fitzhardinge wrote:

Anthony Liguori wrote:
  

This patch refactors the current hypercall infrastructure to better support live
migration and SMP.  It eliminates the hypercall page by trapping the UD
exception that would occur if you used the wrong hypercall instruction for the
underlying architecture and replacing it with the right one lazily.
  



I guess it would be pretty rude/unlikely for these opcodes to get reused
in other implementations...  But couldn't you make the page trap
instead, rather than relying on an instruction fault?
  


The whole point of using the instruction is to allow hypercalls to be 
used in many locations.  This has the nice side effect of not requiring 
a central hypercall initialization routine in the guest to fetch the 
hypercall page.  A PV driver can be completely independent of any other 
code provided that it restricts itself to it's hypercall namespace.



It also introduces the infrastructure to probe for hypercall available via
CPUID leaves 0x4002.  CPUID leaf 0x4003 should be filled out by
userspace.
  



Is this compatible with Xen's (and other's) use of cpuid?  That is,
0x4000 returns a hypervisor-specific signature in e[bcd]x, and eax
has the max hypervisor leaf.
  


Xen is currently using 0/1/2.  I had thought it was only using 0/1.  The 
intention was not to squash Xen's current CPUID usage so that it would 
still be possible for Xen to make use of the guest code.  Can we agree 
that Xen won't squash leaves 3/4 or is it not worth trying to be 
compatible at this point?


Regards,

Anthony Liguori


J

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

  


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Fix BIOS-e820 end address

[Jeremy Fitzhardinge]

Keshavamurthy, Anil S wrote:
> Subject: [patch] Fix BIOS-e820 end address
>
> --snip of boot message--
> BIOS-provided physical RAM map:
>  BIOS-e820:  - 000a (usable)
>  BIOS-e820: 000f - 0010 (reserved)
>  BIOS-e820: 0010 - 7fe8cc00 (usable)
> end snip---
>
> As you see from above the address 0010 is both
> shown as reserved and usable which is confusing.
>   

I think this is consistent with many other kernel interfaces (such as
/proc/X/maps) where the end address is taken to be exclusive: [0xf,
0x10).

J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Refactor hypercall infrastructure

[Jeremy Fitzhardinge]

Anthony Liguori wrote:
> This patch refactors the current hypercall infrastructure to better support 
> live
> migration and SMP.  It eliminates the hypercall page by trapping the UD
> exception that would occur if you used the wrong hypercall instruction for the
> underlying architecture and replacing it with the right one lazily.
>   

I guess it would be pretty rude/unlikely for these opcodes to get reused
in other implementations...  But couldn't you make the page trap
instead, rather than relying on an instruction fault?

> It also introduces the infrastructure to probe for hypercall available via
> CPUID leaves 0x4002.  CPUID leaf 0x4003 should be filled out by
> userspace.
>   

Is this compatible with Xen's (and other's) use of cpuid?  That is,
0x4000 returns a hypervisor-specific signature in e[bcd]x, and eax
has the max hypervisor leaf.

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