Re: [PATCH x86_64] Live Patching Function on 2.6.11.7

[Chris Wedgwood]

On Mon, Apr 18, 2005 at 12:35:04AM -0600, Chris Friesen wrote:

> In the telecom space it's quite common to want to modify multiple
> running binaries with as little downtime as possible.

OK

> (Beyond a threshold it becomes FCC-reportable in the US, and
> everyone wants to avoid that...)

That's beside the point.

> Our old proprietary OS had explicit support for replacing running
> binary code on the fly, so customers have gotten used to the
> ability.  Now they want equivalent functionality with our
> linux-based stuff.

*Why* do they need this is what I asked.  A sensible real world
example would be useful.

> For general application support I suspect some kernel support will
> be required.  Whether this is the way to go or whether it can be
> done using existing mechanisms, I'm not knowledgeable enough to
> comment.

I used to work in telco space, we had some such systems and similar
things.  Some from Nortel even.

None of the things I saw did anything that I can image really need a
complicated kernel patch for.


In fact, I'm not convinced *any* of these uses really needed
live-patching at all.


I would just like some examples of real-world needs and an explanation
of why it's needed.  Not handy-waving.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH x86_64] Live Patching Function on 2.6.11.7

[Chris Friesen]

Chris Wedgwood wrote:
On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:

From our experience, sometimes patches became to dozens to hundreds
at one patching, and in this case GDB based approach cause target
process's availability descent.

could you perhaps explain some *real* *world* applications/systems
where this is necessary and why existing APIs won't work with them
perhaps?
In the telecom space it's quite common to want to modify multiple 
running binaries with as little downtime as possible.  (Beyond a 
threshold it becomes FCC-reportable in the US, and everyone wants to 
avoid that...)

Our old proprietary OS had explicit support for replacing running binary 
code on the fly, so customers have gotten used to the ability.  Now they 
want equivalent functionality with our linux-based stuff.

We've done some proprietary stuff (ie. pre-OSDL CGL) in this area, but 
it was apparently a real pain and was quite restrictive on the 
application writers. (I was not involved with that portion of the project.)

For general application support I suspect some kernel support will be 
required.  Whether this is the way to go or whether it can be done using 
existing mechanisms, I'm not knowledgeable enough to comment.

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

Re: Kernel page table and module text

[Chris Wedgwood]

On Mon, Apr 18, 2005 at 02:20:51AM -0400, Allison wrote:

> If somebody can explain how to traverse the kernel page tables, that
> would be very helpful.

It might help if you explained what you are trying to do...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel panic - not syncing: Fatal exception in interupt

[Shaun Reitan]

I actually ran accross that patch this morning on the ebtables lists but i
wasnt sure it would fix the problem i was having.  I will get this patched
into the kernel and see what happens.  Thanks  for the responce, if this
went on much longer this $4,000 machine was going to become a paper weight
:)

Best Regards,

Shaun Reitan


- Original Message -
From: "Herbert Xu" <[EMAIL PROTECTED]>
To: "Shaun Reitan" <[EMAIL PROTECTED]>
Cc: ; <[EMAIL PROTECTED]>
Sent: Sunday, April 17, 2005 11:07 PM
Subject: Re: kernel panic - not syncing: Fatal exception in interupt


> On Sun, Apr 17, 2005 at 08:32:42PM +, Shaun Reitan wrote:
> > OK, finally got a full dump from the serial console!  Here is it!
>
> This was fixed about a month ago.  Here is the patch that did it.
>
> Perhaps it's time to include this in 2.6.11.*?
>
> Cheers,
> --
> Visit Openswan at http://www.openswan.org/
> Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
>

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

Kernel page table and module text

[Allison]

Hi,

Since module is loaded in non-contiguous memory, there has to be an
entry in the kernel page table for all modules that are loaded on the
system. I am trying to find entries corresponding to my module text in
the page tables.

I am not clear about how the kernel page table is organized after the
system switches to protected mode.

I printed out the page starting with swapper_pg_dir . But I do not
find the addresses for all the modules loaded in the system.

Do I still need to read the pg0 and pg1 pages ?

If somebody can explain how to traverse the kernel page tables, that
would be very helpful.

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

Re: increasing scsi_max_sg / max_segments for scsi writes/reads

[sai narasimhamurthy]

Hi , 
I tried working on scsi_malloc to increase burst size
, but to no avail ..all I got was hanged system every
time I started data transfers! 
Has anyone worked on scsi_malloc , I am still trying
to figure out what changes were made in 2.6 to
overcome this problem of limited bursts. 

Any pointers are very greatly welcome...I have never
worked on this part of the code before .


Sai










--- "Randy.Dunlap" <[EMAIL PROTECTED]> wrote:
> On Sat, 9 Apr 2005 19:35:52 -0700 (PDT) sai
> narasimhamurthy wrote:
> 
> | Hi, 
> | I had posted a question on increasing the scsi
> | read/write sectors  per command. I figured out
> some of
> | the things, but many questions still exist. 
> | 
> | I was wondering why the maximum writes I could get
> | from a single scsi write command could never
> exceed
> | 204 
> | 4096B  segments . I traced it to :  
> | 
> | static const int scsi_max_sg = PAGE_SIZE /
> | sizeof(struct scatterlist)
> | 
> | in scsi_merge.c .(which amounts to 204)  
> | 
> | Is this the limit of the maximum blocks we can
> | read/write through a single scsi command, atleast
> for
> | the given kernel (2.4.29) ? How can I increase
> | it??
> | 
> | I am on a P3 Dell poweredgde 2400 . 
> 
> Did you read the comment immediately above that
> calculation?
> 
> /*
>  * scsi_malloc() can only dish out items of
> PAGE_SIZE or less, so we cannot
>  * build a request that requires an sg table
> allocation of more than that.
>  */
> 
> so scsi_malloc() would need some reworking to handle
> more.
> 
> OTOH, it appears that this is all removed in
> 2.6.10++, so moving to
> 2.6.recent is probably your best choice.
> 
> ---
> ~Randy
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> 



__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH x86_64] Live Patching Function on 2.6.11.7

[Chris Wedgwood]

On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:

> From our experience, sometimes patches became to dozens to hundreds
> at one patching, and in this case GDB based approach cause target
> process's availability descent.

i don't really buy that it can't be done or you complex patches are
necessary to be honest --- and there are various alternative APIs that
could help as others have pointed out


could you perhaps explain some *real* *world* applications/systems
where this is necessary and why existing APIs won't work with them
perhaps?

solving a real-world problem is much more interesting to listen to
that filling in a check-box on a (somewhat dubious) specification
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel panic - not syncing: Fatal exception in interupt

[Herbert Xu]

On Sun, Apr 17, 2005 at 08:32:42PM +, Shaun Reitan wrote:
> OK, finally got a full dump from the serial console!  Here is it!

This was fixed about a month ago.  Here is the patch that did it.

Perhaps it's time to include this in 2.6.11.*?

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
# This is a BitKeeper generated diff -Nru style patch.
#
# ChangeSet
#   2005/03/14 21:22:31-08:00 [EMAIL PROTECTED] 
#   [EBTABLES]: Fix smp race.
#   
#   The patch below fixes an smp race that happens on such systems under
#   heavy load.
#   This bug was reported and solved by Steve Herrell
#   <[EMAIL PROTECTED]>
#   
#   Signed-off-by: Bart De Schuymer <[EMAIL PROTECTED]>
#   Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
# 
# net/bridge/netfilter/ebtables.c
#   2005/03/14 21:22:13-08:00 [EMAIL PROTECTED] +2 -1
#   [EBTABLES]: Fix smp race.
#   
#   The patch below fixes an smp race that happens on such systems under
#   heavy load.
#   This bug was reported and solved by Steve Herrell
#   <[EMAIL PROTECTED]>
#   
#   Signed-off-by: Bart De Schuymer <[EMAIL PROTECTED]>
#   Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
# 
diff -Nru a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
--- a/net/bridge/netfilter/ebtables.c   2005-04-18 15:59:25 +10:00
+++ b/net/bridge/netfilter/ebtables.c   2005-04-18 15:59:25 +10:00
@@ -179,9 +179,10 @@
struct ebt_chainstack *cs;
struct ebt_entries *chaininfo;
char *base;
-   struct ebt_table_info *private = table->private;
+   struct ebt_table_info *private;
 
read_lock_bh(&table->lock);
+   private = table->private;
cb_base = COUNTER_BASE(private->counters, private->nentries,
   smp_processor_id());
if (private->chainstack)

Re: [PATCH x86_64] Live Patching Function on 2.6.11.7

[Takashi Ikebe]

Davide Libenzi wrote:
(B
(B>On Mon, 2005-04-18 at 00:42 -0400, Daniel Jacobowitz wrote:
(B>
(B>  
(B>
(B>>On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
(B>>
(B>>
(B>>>GDB based approach seems not fit to our requirements. GDB(ptrace) based 
(B>>>functions are basically need to be done when target process is stopping.
(B>>>In addition to that current PTRACE_PEEK/POKE* allows us to copy only a 
(B>>>*word* size...
(B>>>  
(B>>>
(B>>While true, this is easily fixable. 
(B>>
(B>>
(B>
(B>Indeed, look at the systr_pmem_read() and systr_pmem_write() functions:
(B>
(B>http://www.xmailserver.org/sysctr.html
(B>
(B>  
(B>
(Bsystr_pmem_read() and systr_pmem_write() just calls ptrace PTRACE_PEEKTEXT/DATA 
(Brepeatedly
(BIn this case we need to *stop* target process whenever patch modules is 
(Bloading
(BIt cause target process availability worse.
(B
(B-- 
(BTakashi Ikebe
(BNTT Network Service Systems Laboratories
(B9-11, Midori-Cho 3-Chome Musashino-Shi,
(BTokyo 180-8585 Japan
(BTel : +81 422 59 4246, Fax : +81 422 60 4012
(Be-mail : [EMAIL PROTECTED]
(B
(B
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at  http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at  http://www.tux.org/lkml/

Re: More performance for the TCP stack by using additional hardware chip on NIC

[Avi Kivity]

David S. Miller wrote:
On Sun, 17 Apr 2005 13:29:14 +0300
Avi Kivity <[EMAIL PROTECTED]> wrote:
 

TOEs can remove the data copy on receive. In some applications (notably
storage), where the application does not touch most of the data, this is
a significant advantage that cannot be achieved in a software-only
solution.
   

You don't need to offload the TCP stack to make this case get
zero-copy behavior.
 

yes, Willy Tarreau outlined how buffering on the nic and splitting the 
dma can achieve zero copy.

are there any adapters out there which work this way?
--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: FUSYN and RT

[hui]

On Fri, Apr 15, 2005 at 04:37:05PM -0700, Inaky Perez-Gonzalez wrote:
> By following your method, the pi engine becomes unnecesarily complex;
> you have actually two engines following two different propagation
> chains (one kernel, one user). If your mutexes/locks/whatever are the
> same with a different cover, then you can simplify the whole
> implementation by leaps.

The main comment that I'm making here (so it doesn't get lost) is that,
IMO, you're going to find that there is a mismatch with the requirements
of Posix threading verse kernel uses. To drop the kernel mutex in 1:1 to
back a futex-ish entity is going to be problematic mainly because of how
kernel specific the RT mutex is (or any future kernel mutex) for debugging,
etc... and I think this is going to be clear as it gets progressively
implemented.

I think folks really need to think about this clearly before moving into
any direction prematurely. That's what I'm saying. PI is one of those
issues, but ultimately it's the fundamental differences between userspace
and kernel work.

LynxOS (similar threading system) keep priority calculations of this kind
seperate between user and kernel space. I'll have the ask one of our
engineers here why again that's the case, but I suspect it's for the
reasons I've discussed previously.

bill

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

Re: [PATCH i386] Live Patching Function on 2.6.11.7

[Christoph Hellwig]

On Mon, Apr 18, 2005 at 12:20:31PM +0900, Takashi Ikebe wrote:
> The patch was over 50k, so I separate it to each architecture and in line..
> 
> This patch add function called "Live patching" which is defined on
> OSDL's carrier grade linux requiremnt definition to linux 2.6.11.7 kernel.

Traditionally beeing in OSDL specs was a very good reason not to merge patches.

Can you please come up with real arguments instead of this requirements
bullshit.  Also I hope OSDL would invest their money in more useful things
than CGL, why has this idiocy still not stopped?

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386 & x86_64: Live Patching Funcion on 2.6.11.7

[Takashi Ikebe]

Daniel Jacobowitz wrote:
(B
(B>On Mon, Apr 18, 2005 at 10:41:23AM +0900, Takashi Ikebe wrote:
(B>  
(B>
(B>>Daniel-san,
(B>>GDB based approach seems not fit to our requirements. GDB(ptrace) based 
(B>>functions are basically need to be done when target process is stopping. 
(B>>From our experience, sometimes patches became to dozens to hundreds at 
(B>>one patching, and in this case GDB based approach cause target process's 
(B>>availability descent.
(B>>
(B>>
(B>
(B>That's right, it does require the target process be stopped.  If it
(B>isn't stopped how do you know it isn't executing the same instruction
(B>you're currently patching?
(B>
(B>Even with hundreds of kilobytes of patch, I have trouble imagining this
(B>takes a substantial amount of time.
(B>  
(B>
(BPannus patch does not require target process stop while loading(mapping)
(Bpatch module to target process memory,
(Bbut as you described, target process stopping is needed whenever check
(BEIP not to conflict, and overwrite jump assembly code.(This makes only
(Bfew milliseconds target process stopping. Even on hundreds, it only
(Btakes dozens mill-seconds yet.)
(BTypically telecoms application needs soft real time, and has timeout.
(BThis kind of framework can not stop target process so long(Should be
(Bdozens milliseconds at worst).
(BWe want not to stop target process whenever patch module is loading
(Bwe want not to stop target process as possible as.
(B
(B-- 
(BTakashi Ikebe
(BNTT Network Service Systems Laboratories
(B9-11, Midori-Cho 3-Chome Musashino-Shi,
(BTokyo 180-8585 Japan
(BTel : +81 422 59 4246, Fax : +81 422 60 4012
(Be-mail : [EMAIL PROTECTED]
(B
(B
(B-
(BTo unsubscribe from this list: send the line "unsubscribe linux-kernel" in
(Bthe body of a message to [EMAIL PROTECTED]
(BMore majordomo info at  http://vger.kernel.org/majordomo-info.html
(BPlease read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH x86_64] Live Patching Function on 2.6.11.7

[David S. Miller]

On Mon, 18 Apr 2005 00:42:23 -0400
Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:

> On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
> > GDB based approach seems not fit to our requirements. GDB(ptrace) based 
> > functions are basically need to be done when target process is stopping.
> > In addition to that current PTRACE_PEEK/POKE* allows us to copy only a 
> > *word* size...
> 
> While true, this is easily fixable.  There is even an interface
> precedent on OpenBSD (and possibly other platforms as well).

Some platforms even support the necessary PTRADE_{READ,WRITE}DATA
operations already, sparc is one such platform.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH x86_64] Live Patching Function on 2.6.11.7

[Davide Libenzi]

On Mon, 2005-04-18 at 00:42 -0400, Daniel Jacobowitz wrote:

> On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
> > GDB based approach seems not fit to our requirements. GDB(ptrace) based 
> > functions are basically need to be done when target process is stopping.
> > In addition to that current PTRACE_PEEK/POKE* allows us to copy only a 
> > *word* size...
> 
> While true, this is easily fixable. 

Indeed, look at the systr_pmem_read() and systr_pmem_write() functions:

http://www.xmailserver.org/sysctr.html


- Davide

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

Re: [PATCH x86_64] Live Patching Function on 2.6.11.7

[Nicholas Miell]

On Mon, 2005-04-18 at 00:42 -0400, Daniel Jacobowitz wrote:
> On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
> > GDB based approach seems not fit to our requirements. GDB(ptrace) based 
> > functions are basically need to be done when target process is stopping.
> > In addition to that current PTRACE_PEEK/POKE* allows us to copy only a 
> > *word* size...
> 
> While true, this is easily fixable.  There is even an interface
> precedent on OpenBSD (and possibly other platforms as well).
> 

If we're going to be stealing ideas for debugging interfaces from other
operating systems, could we steal from Solaris instead of anything
ptrace-based?

-- 
Nicholas Miell <[EMAIL PROTECTED]>

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

Re: [PATCH x86_64] Live Patching Function on 2.6.11.7

[Daniel Jacobowitz]

On Mon, Apr 18, 2005 at 01:19:57PM +0900, Takashi Ikebe wrote:
> GDB based approach seems not fit to our requirements. GDB(ptrace) based 
> functions are basically need to be done when target process is stopping.
> In addition to that current PTRACE_PEEK/POKE* allows us to copy only a 
> *word* size...

While true, this is easily fixable.  There is even an interface
precedent on OpenBSD (and possibly other platforms as well).

-- 
Daniel Jacobowitz
CodeSourcery, LLC
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386 & x86_64: Live Patching Funcion on 2.6.11.7

[Daniel Jacobowitz]

On Mon, Apr 18, 2005 at 10:41:23AM +0900, Takashi Ikebe wrote:
> Daniel-san,
> GDB based approach seems not fit to our requirements. GDB(ptrace) based 
> functions are basically need to be done when target process is stopping. 
> From our experience, sometimes patches became to dozens to hundreds at 
> one patching, and in this case GDB based approach cause target process's 
> availability descent.

That's right, it does require the target process be stopped.  If it
isn't stopped how do you know it isn't executing the same instruction
you're currently patching?

Even with hundreds of kilobytes of patch, I have trouble imagining this
takes a substantial amount of time.

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

Re: More performance for the TCP stack by using additional hardware chip on NIC

[Willy Tarreau]

On Mon, Apr 18, 2005 at 12:08:41AM -0400, Kyle Moffett wrote:
(...) 
> What I think would be _much_ more useful is a generic low-power 
> multi-proc MIPS/PPC system on a PCI card with a certain amount of
> RAM, etc that could be programmed at runtime by the master CPU.
> Then you lose none of the flexibility, it can be run in the same
> endian-mode as the host CPU, and it would allow you to program
> it for much more complicated DMA.

it would be really interesting, it would be sort of an I/O coprocessor,
but unfortunately, it would half the PCI bandwidth (which is already a
problem with 10 Gbps) be cause the data would have to go from the NIC
to the copro then from the copro to system RAM.

Or if this copro contains large amounts of RAM, then the applications
can manipulate data directly on the card (and the copro could provide
remote memcpy, memmove, etc...), thus eliminating copies. But in this
case, it would require many modifications on both the kernel and the
application.

> You could do anything from linux software RAID, audio processing,
> encryption, TCP/IP stack acceleration, extra scatter-gather for your
> disk controller, etc.
> If it was low-cost, IE: cheaper than adding extra full-speed CPUs to the
> system, and using a decent bi-endian, vector-capable CPU (Like PPC), you
> might find that people will buy them for the flexibility.  Such a thing
> might also be useful for the prezero folks, it could be used (when not
> otherwise occupied) for zeroing unused pages.
> 
> Personally, I think I'd buy one or two just to tinker with them :-D.

Then you should take a look at some hardware RAID controllers or even
some special intel NICs, both of which often come with an i960 or PPC
onboard. It might become a good start, and if you can show someting
interesting, we already know there's one guy here who can build the
full-speed CPU from the specs :-)

Cheers,
Willy

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

Re: [PATCH x86_64] Live Patching Function on 2.6.11.7

[Takashi Ikebe]

Hello,
Chris Wedgwood wrote:
On Mon, Apr 18, 2005 at 12:19:54PM +0900, Takashi Ikebe wrote:
 
This patch add function called "Live patching" which is defined on
OSDL's carrier grade linux requiremnt definition to linux 2.6.11.7
kernel.
I;m curious as to what people decided this was a necessary
requirement.
The requirements are comes from Network Equipment Providers, Telecom 
Carriers, and Hardware Vendors,
You can see the attendee from below link;
http://groups.osdl.org/world_map/full_roster/

The live patching allows process to patch on-line (without
restarting process) on i386 and x86_64 architectures, by overwriting
jump assembly code on entry point of functions which you want to
fix, to patched functions.
Why can't you use ptrace for all this?
GDB based approach seems not fit to our requirements. GDB(ptrace) based 
functions are basically need to be done when target process is stopping.
In addition to that current PTRACE_PEEK/POKE* allows us to copy only a 
*word* size...
From our experience, sometimes patches became to dozens to hundreds at 
one patching, and in this case GDB based approach cause target process's 
availability descent.

--
Takashi Ikebe
NTT Network Service Systems Laboratories
9-11, Midori-Cho 3-Chome Musashino-Shi,
Tokyo 180-8585 Japan
Tel : +81 422 59 4246, Fax : +81 422 60 4012
e-mail : [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: More performance for the TCP stack by using additional hardware chip on NIC

[Kyle Moffett]

On Apr 17, 2005, at 19:37, Horst von Brand wrote:
Andreas Hartmann <[EMAIL PROTECTED]> said:
Alacritech developed a new chip for NIC's
(http://www.alacritech.com/html/tech_review.html), which makes it 
possible
to take away the TCP stack from the host CPU. Therefore, the host CPU 
has
more performance for the applications according Alacritech.

This sounds interesting.
This idea has been discussed around here a couple of times, and the
consensus is that it is a bad idea: IP (and upper protocol) processing
is not expensive, if done right, so this really doesn't buy much; this
forces a particular interface to networking into the kernel, loosing
flexibility that way is always bad; there is no access to futzing
around in between (for example, for firewalling and such); and if the
"hardware implementation" has bugs, you are screwed.
What I think would be _much_ more useful is a generic low-power 
multi-proc
MIPS/PPC system on a PCI card with a certain amount of RAM, etc that 
could
be programmed at runtime by the master CPU.  Then you lose none of the
flexibility, it can be run in the same endian-mode as the host CPU, and 
it
would allow you to program it for much more complicated DMA.  You could 
do
anything from linux software RAID, audio processing, encryption, TCP/IP
stack acceleration, extra scatter-gather for your disk controller, etc.
If it was low-cost, IE: cheaper than adding extra full-speed CPUs to the
system, and using a decent bi-endian, vector-capable CPU (Like PPC), you
might find that people will buy them for the flexibility.  Such a thing
might also be useful for the prezero folks, it could be used (when not
otherwise occupied) for zeroing unused pages.

Personally, I think I'd buy one or two just to tinker with them :-D.
Cheers,
Kyle Moffett
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCM/CS/IT/U d- s++: a18 C>$ UB/L/X/*(+)>$ P+++()>$
L(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b(++) DI+ D+ G e->$ h!*()>++$ r  
!y?(-)
--END GEEK CODE BLOCK--

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

Re: [PATCH x86_64] Live Patching Function on 2.6.11.7

[Chris Wedgwood]

On Mon, Apr 18, 2005 at 12:19:54PM +0900, Takashi Ikebe wrote:

> This patch add function called "Live patching" which is defined on
> OSDL's carrier grade linux requiremnt definition to linux 2.6.11.7
> kernel.

I;m curious as to what people decided this was a necessary
requirement.

> The live patching allows process to patch on-line (without
> restarting process) on i386 and x86_64 architectures, by overwriting
> jump assembly code on entry point of functions which you want to
> fix, to patched functions.

Why can't you use ptrace for all this?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] DRM: misc cleanup

[Adrian Bunk]

On Tue, Feb 01, 2005 at 09:16:16PM +1100, Dave Airlie wrote:
> 
> I'll nack this patch for now Adrian, but I'm going to bring all these
> changes into the DRM tree as soon as I can.. one of the functions you
> removed pointed out a bug in the i810/i830/i915 drivers (granted
> no-one uses pageflip in those drivers but still should fix it..), I'm
> going to put the through drm CVS first...

I've seen that part of this is already in recent kernels.

Below is as a FYI a version against 2.6.12-rc2-mm3. 

> Thanks,
> Dave.

cu
Adrian


<--  snip   -->


This patch contains the following cleanups:
- make needlessly global functions static
- remove the following unused global functions:
  - drm_fops.c: drm_read
  - i915_dma.c: i915_do_cleanup_pageflip
  - via_ds.c: via_mmDumpMemInfo
  - via_ds.c: via_mmAddRange
  - via_ds.c: via_mmReserveMem
  - via_ds.c: via_mmFreeReserved
  - via_ds.c: via_mmDestroy
- remove the followig unused global variable:
  - via_mm.c: VIA_DEBUG

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

---

 drivers/char/drm/ati_pcigart.c |2 
 drivers/char/drm/drmP.h|   22 --
 drivers/char/drm/drm_auth.c|4 -
 drivers/char/drm/drm_bufs.c|   12 +--
 drivers/char/drm/drm_context.c |6 -
 drivers/char/drm/drm_drv.c |9 +-
 drivers/char/drm/drm_fops.c|   10 ---
 drivers/char/drm/drm_irq.c |2 
 drivers/char/drm/drm_lock.c|   12 ++-
 drivers/char/drm/drm_proc.c|2 
 drivers/char/drm/drm_stub.c|   92 ++--
 drivers/char/drm/drm_vm.c  |   10 +--
 drivers/char/drm/i810_dma.c|   24 +++
 drivers/char/drm/i810_drv.h|1 
 drivers/char/drm/i830_dma.c|   20 +++---
 drivers/char/drm/i830_drv.c|2 
 drivers/char/drm/i830_drv.h|2 
 drivers/char/drm/i830_irq.c|4 -
 drivers/char/drm/i915_dma.c|   60 +++---
 drivers/char/drm/i915_drv.c|2 
 drivers/char/drm/i915_drv.h|   10 ---
 drivers/char/drm/i915_irq.c|4 -
 drivers/char/drm/r128_state.c  |2 
 drivers/char/drm/via_dma.c |4 -
 drivers/char/drm/via_drv.h |2 
 drivers/char/drm/via_ds.c  |  108 -
 drivers/char/drm/via_ds.h  |8 --
 drivers/char/drm/via_map.c |2 
 drivers/char/drm/via_mm.c  |   14 ++--
 drivers/char/drm/via_mm.h  |5 -
 30 files changed, 149 insertions(+), 308 deletions(-)

--- linux-2.6.12-rc2-mm3-full/drivers/char/drm/drmP.h.old   2005-04-18 
03:54:16.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/drm/drmP.h   2005-04-18 
03:54:49.0 +0200
@@ -774,8 +774,6 @@
/* Driver support (drm_drv.h) */
 extern int   drm_init(struct drm_driver *driver);
 extern void  drm_exit(struct drm_driver *driver);
-extern int   drm_version(struct inode *inode, struct file *filp,
- unsigned int cmd, unsigned long arg);
 extern int   drm_ioctl(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
 extern long drm_compat_ioctl(struct file *filp,
@@ -785,21 +783,13 @@
/* Device support (drm_fops.h) */
 extern int   drm_open(struct inode *inode, struct file *filp);
 extern int   drm_stub_open(struct inode *inode, struct file *filp);
-extern int  drm_open_helper(struct inode *inode, struct file *filp,
- drm_device_t *dev);
 extern int  drm_flush(struct file *filp);
 extern int  drm_fasync(int fd, struct file *filp, int on);
 extern int   drm_release(struct inode *inode, struct file *filp);
 
/* Mapping support (drm_vm.h) */
-extern void drm_vm_open(struct vm_area_struct *vma);
-extern void drm_vm_close(struct vm_area_struct *vma);
-extern void drm_vm_shm_close(struct vm_area_struct *vma);
-extern int  drm_mmap_dma(struct file *filp,
-  struct vm_area_struct *vma);
 extern int  drm_mmap(struct file *filp, struct vm_area_struct *vma);
 extern unsigned int  drm_poll(struct file *filp, struct poll_table_struct 
*wait);
-extern ssize_t   drm_read(struct file *filp, char __user *buf, size_t 
count, loff_t *off);
 
/* Memory management support (drm_memory.h) */
 #include "drm_memory.h"
@@ -854,9 +844,6 @@
 extern int  drm_rmctx( struct inode *inode, struct file *filp,
 unsigned int cmd, unsigned long arg );
 
-extern int  drm_context_switch(drm_device_t *dev, int old, int new);
-extern int  drm_context_switch_complete(drm_device_t *dev, int new);
-
 extern int  drm_ctxbitmap_init( drm_device_t *dev );
 extern void drm_ctxbitmap_cleanup( drm_device_t *dev );
 extern void  drm_ctxbitmap_free( drm_device_t *dev, int ctx_handle );
@@ -87

[2.6 patch] drivers/usb/net/zd1201.c: make some code static

[Adrian Bunk]

This patch makes some needlessly global code static.

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

---

 drivers/usb/net/zd1201.c |   20 +++-
 1 files changed, 11 insertions(+), 9 deletions(-)

--- linux-2.6.12-rc2-mm3-full/drivers/usb/net/zd1201.c.old  2005-04-18 
03:16:40.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/usb/net/zd1201.c  2005-04-18 
03:18:49.0 +0200
@@ -45,7 +45,7 @@
 MODULE_DEVICE_TABLE(usb, zd1201_table);
 
 
-int zd1201_fw_upload(struct usb_device *dev, int apfw)
+static int zd1201_fw_upload(struct usb_device *dev, int apfw)
 {
const struct firmware *fw_entry;
char* data;
@@ -112,7 +112,7 @@
return err;
 }
 
-void zd1201_usbfree(struct urb *urb, struct pt_regs *regs)
+static void zd1201_usbfree(struct urb *urb, struct pt_regs *regs)
 {
struct zd1201 *zd = urb->context;
 
@@ -143,7 +143,8 @@
 
total: 4 + 2 + 2 + 2 + 2 + 4 = 16
 */
-int zd1201_docmd(struct zd1201 *zd, int cmd, int parm0, int parm1, int parm2)
+static int zd1201_docmd(struct zd1201 *zd, int cmd, int parm0,
+   int parm1, int parm2)
 {
unsigned char *command;
int ret;
@@ -176,7 +177,7 @@
 }
 
 /* Callback after sending out a packet */
-void zd1201_usbtx(struct urb *urb, struct pt_regs *regs)
+static void zd1201_usbtx(struct urb *urb, struct pt_regs *regs)
 {
struct zd1201 *zd = urb->context;
netif_wake_queue(zd->dev);
@@ -184,7 +185,7 @@
 }
 
 /* Incomming data */
-void zd1201_usbrx(struct urb *urb, struct pt_regs *regs)
+static void zd1201_usbrx(struct urb *urb, struct pt_regs *regs)
 {
struct zd1201 *zd = urb->context;
int free = 0;
@@ -614,7 +615,7 @@
return (zd1201_setconfig(zd, rid, &zdval, sizeof(__le16), 1));
 }
 
-int zd1201_drvr_start(struct zd1201 *zd)
+static int zd1201_drvr_start(struct zd1201 *zd)
 {
int err, i;
short max;
@@ -1740,7 +1741,8 @@
.private_args   = (struct iw_priv_args *) zd1201_private_args,
 };
 
-int zd1201_probe(struct usb_interface *interface, const struct usb_device_id 
*id)
+static int zd1201_probe(struct usb_interface *interface,
+   const struct usb_device_id *id)
 {
struct zd1201 *zd;
struct usb_device *usb;
@@ -1852,7 +1854,7 @@
return err;
 }
 
-void zd1201_disconnect(struct usb_interface *interface)
+static void zd1201_disconnect(struct usb_interface *interface)
 {
struct zd1201 *zd=(struct zd1201 *)usb_get_intfdata(interface);
struct hlist_node *node, *node2;
@@ -1919,7 +1921,7 @@
 
 #endif
 
-struct usb_driver zd1201_usb = {
+static struct usb_driver zd1201_usb = {
.owner = THIS_MODULE,
.name = "zd1201",
.probe = zd1201_probe,

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

[2.6 patch] drivers/usb/media/sn9c102_core.c: make 2 functions static

[Adrian Bunk]

This patch makes two needlessly global functions static.

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

---

 drivers/usb/media/sn9c102_core.c   |4 ++--
 drivers/usb/media/sn9c102_sensor.h |2 --
 2 files changed, 2 insertions(+), 4 deletions(-)

--- linux-2.6.12-rc2-mm3-full/drivers/usb/media/sn9c102_sensor.h.old
2005-04-18 03:14:54.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/usb/media/sn9c102_sensor.h
2005-04-18 03:15:05.0 +0200
@@ -145,8 +145,6 @@
 */
 
 /* The "try" I2C I/O versions are used when probing the sensor */
-extern int sn9c102_i2c_try_write(struct sn9c102_device*,struct sn9c102_sensor*,
- u8 address, u8 value);
 extern int sn9c102_i2c_try_read(struct sn9c102_device*,struct sn9c102_sensor*,
 u8 address);
 
--- linux-2.6.12-rc2-mm3-full/drivers/usb/media/sn9c102_core.c.old  
2005-04-18 03:15:13.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/usb/media/sn9c102_core.c  2005-04-18 
03:15:50.0 +0200
@@ -429,7 +429,7 @@
 }
 
 
-int 
+static int 
 sn9c102_i2c_try_write(struct sn9c102_device* cam,
   struct sn9c102_sensor* sensor, u8 address, u8 value)
 {
@@ -785,7 +785,7 @@
 }
 
 
-int sn9c102_stream_interrupt(struct sn9c102_device* cam)
+static int sn9c102_stream_interrupt(struct sn9c102_device* cam)
 {
int err = 0;
 

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

[2.6 patch] drivers/usb/media/pwc/: make code static

[Adrian Bunk]

This patch makes needlessly global code static.

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

---

 drivers/usb/media/pwc/pwc-ctrl.c |   76 +++
 drivers/usb/media/pwc/pwc-if.c   |2 
 drivers/usb/media/pwc/pwc.h  |6 --
 3 files changed, 40 insertions(+), 44 deletions(-)

--- linux-2.6.12-rc2-mm3-full/drivers/usb/media/pwc/pwc.h.old   2005-04-18 
03:11:14.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/usb/media/pwc/pwc.h   2005-04-18 
03:13:28.0 +0200
@@ -226,9 +226,8 @@
 extern "C" {
 #endif
 
-/* Global variables */
+/* Global variable */
 extern int pwc_trace;
-extern int pwc_preferred_compression;
 
 /** functions in pwc-if.c */
 int pwc_try_video_mode(struct pwc_device *pdev, int width, int height, int 
new_fps, int new_compression, int new_snapshot);
@@ -243,8 +242,6 @@
 /** Functions in pwc-ctrl.c */
 /* Request a certain video mode. Returns < 0 if not possible */
 extern int pwc_set_video_mode(struct pwc_device *pdev, int width, int height, 
int frames, int compression, int snapshot);
-/* Calculate the number of bytes per image (not frame) */
-extern void pwc_set_image_buffer_size(struct pwc_device *pdev);
 
 /* Various controls; should be obvious. Value 0..65535, or < 0 on error */
 extern int pwc_get_brightness(struct pwc_device *pdev);
@@ -256,7 +253,6 @@
 extern int pwc_get_saturation(struct pwc_device *pdev);
 extern int pwc_set_saturation(struct pwc_device *pdev, int value);
 extern int pwc_set_leds(struct pwc_device *pdev, int on_value, int off_value);
-extern int pwc_get_leds(struct pwc_device *pdev, int *on_value, int 
*off_value);
 extern int pwc_get_cmos_sensor(struct pwc_device *pdev, int *sensor);
 
 /* Power down or up the camera; not supported by all models */
--- linux-2.6.12-rc2-mm3-full/drivers/usb/media/pwc/pwc-ctrl.c.old  
2005-04-18 03:11:29.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/usb/media/pwc/pwc-ctrl.c  2005-04-18 
03:24:41.0 +0200
@@ -418,6 +418,44 @@
 
 
 
+static void pwc_set_image_buffer_size(struct pwc_device *pdev)
+{
+   int i, factor = 0, filler = 0;
+
+   /* for PALETTE_YUV420P */
+   switch(pdev->vpalette)
+   {
+   case VIDEO_PALETTE_YUV420P:
+   factor = 6;
+   filler = 128;
+   break;
+   case VIDEO_PALETTE_RAW:
+   factor = 6; /* can be uncompressed YUV420P */
+   filler = 0;
+   break;
+   }
+
+   /* Set sizes in bytes */
+   pdev->image.size = pdev->image.x * pdev->image.y * factor / 4;
+   pdev->view.size  = pdev->view.x  * pdev->view.y  * factor / 4;
+
+   /* Align offset, or you'll get some very weird results in
+  YUV420 mode... x must be multiple of 4 (to get the Y's in
+  place), and y even (or you'll mixup U & V). This is less of a
+  problem for YUV420P.
+*/
+   pdev->offset.x = ((pdev->view.x - pdev->image.x) / 2) & 0xFFFC;
+   pdev->offset.y = ((pdev->view.y - pdev->image.y) / 2) & 0xFFFE;
+
+   /* Fill buffers with gray or black */
+   for (i = 0; i < MAX_IMAGES; i++) {
+   if (pdev->image_ptr[i] != NULL)
+   memset(pdev->image_ptr[i], filler, pdev->view.size);
+   }
+}
+
+
+
 /**
@pdev: device structure
@width: viewport width
@@ -475,44 +513,6 @@
 }
 
 
-void pwc_set_image_buffer_size(struct pwc_device *pdev)
-{
-   int i, factor = 0, filler = 0;
-
-   /* for PALETTE_YUV420P */
-   switch(pdev->vpalette)
-   {
-   case VIDEO_PALETTE_YUV420P:
-   factor = 6;
-   filler = 128;
-   break;
-   case VIDEO_PALETTE_RAW:
-   factor = 6; /* can be uncompressed YUV420P */
-   filler = 0;
-   break;
-   }
-
-   /* Set sizes in bytes */
-   pdev->image.size = pdev->image.x * pdev->image.y * factor / 4;
-   pdev->view.size  = pdev->view.x  * pdev->view.y  * factor / 4;
-
-   /* Align offset, or you'll get some very weird results in
-  YUV420 mode... x must be multiple of 4 (to get the Y's in
-  place), and y even (or you'll mixup U & V). This is less of a
-  problem for YUV420P.
-*/
-   pdev->offset.x = ((pdev->view.x - pdev->image.x) / 2) & 0xFFFC;
-   pdev->offset.y = ((pdev->view.y - pdev->image.y) / 2) & 0xFFFE;
-
-   /* Fill buffers with gray or black */
-   for (i = 0; i < MAX_IMAGES; i++) {
-   if (pdev->image_ptr[i] != NULL)
-   memset(pdev->image_ptr[i], filler, pdev->view.size);
-   }
-}
-
-
-
 /* BRIGHTNESS */
 
 int pwc_get_brightness(struct pwc_device *pdev)
--- linux-2.6.12-rc2-mm3-full/drivers/usb/media/pwc/pwc-if.c.old
2005-04-18 03:13:37.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/usb/media/pwc/pwc-if.c2005-04-18 
03:13:53.0 +0200
@@ -129,7 +129,7 @@
int pwc_trace = TRACE_MODULE | TRACE_FLOW | TRACE_PWCX;
 static int powe

Re: [2.6 patch] remove cifs_kcalloc

[Dave Jones]

On Mon, Apr 18, 2005 at 03:52:02AM +0200, Adrian Bunk wrote:
 > This patch removes cifs_kcalloc and replaces it with calls to
 > kcalloc(1, ...) .
 > 
 > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

As a followup patch you might want to check the return value
of all those calls before blindly deferencing them.

Dave

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

Re: Why Ext2/3 needs immutable attribute?

[Bernd Eckenfels]

On Sun, Apr 17, 2005 at 07:48:50PM -0400, Xin Zhao wrote:
> any kernel level protection, including
> SELinux, could be disabled after the kernel is compromised. Am I
> missing some points here?

No, Immutable bit is an application of capabilities (or securelevel), you
are right.

If the kernel is compromised, the kernel is compromised. However immutable
bit can make it hard to circumvent kernel's protetion, even for root
attackers

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

[2.6 patch] remove cifs_kcalloc

[Adrian Bunk]

This patch removes cifs_kcalloc and replaces it with calls to
kcalloc(1, ...) .

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

---

 fs/cifs/connect.c |   92 --
 1 files changed, 41 insertions(+), 51 deletions(-)

--- linux-2.6.12-rc2-mm3-full/fs/cifs/connect.c.old 2005-04-18 
03:00:31.0 +0200
+++ linux-2.6.12-rc2-mm3-full/fs/cifs/connect.c 2005-04-18 03:02:18.0 
+0200
@@ -471,16 +471,6 @@
return 0;
 }
 
-static void * 
-cifs_kcalloc(size_t size, unsigned int __nocast type)
-{
-   void *addr;
-   addr = kmalloc(size, type);
-   if (addr)
-   memset(addr, 0, size);
-   return addr;
-}
-
 static int
 cifs_parse_mount_options(char *options, const char *devname,struct smb_vol 
*vol)
 {
@@ -598,7 +588,7 @@
/* go from value to value + temp_len condensing 
double commas to singles. Note that this ends up
allocating a few bytes too many, which is ok */
-   vol->password = cifs_kcalloc(temp_len, 
GFP_KERNEL);
+   vol->password = kcalloc(1, temp_len, 
GFP_KERNEL);
for(i=0,j=0;ipassword[j] = value[i];
if(value[i] == separator[0] && 
value[i+1] == separator[0]) {
@@ -608,7 +598,7 @@
}
vol->password[j] = 0;
} else {
-   vol->password = cifs_kcalloc(temp_len + 1, 
GFP_KERNEL);
+   vol->password = kcalloc(1, temp_len + 1, 
GFP_KERNEL);
strcpy(vol->password, value);
}
} else if (strnicmp(data, "ip", 2) == 0) {
@@ -1070,7 +1060,7 @@
sessinit is sent but no second negprot */
struct rfc1002_session_packet * ses_init_buf;
struct smb_hdr * smb_buf;
-   ses_init_buf = cifs_kcalloc(sizeof(struct 
rfc1002_session_packet), GFP_KERNEL);
+   ses_init_buf = kcalloc(1, sizeof(struct 
rfc1002_session_packet), GFP_KERNEL);
if(ses_init_buf) {
ses_init_buf->trailer.session_req.called_len = 32;

rfc1002mangle(ses_init_buf->trailer.session_req.called_name,
@@ -1717,7 +1707,7 @@
 /* We look for obvious messed up bcc or strings in response so we do not go off
the end since (at least) WIN2K and Windows XP have a major bug in not null
terminating last Unicode string in response  */
-   ses->serverOS = cifs_kcalloc(2 * (len + 1), 
GFP_KERNEL);
+   ses->serverOS = kcalloc(1, 2 * (len + 1), 
GFP_KERNEL);
cifs_strfromUCS_le(ses->serverOS,
   (wchar_t *)bcc_ptr, 
len,nls_codepage);
bcc_ptr += 2 * (len + 1);
@@ -1727,7 +1717,7 @@
if (remaining_words > 0) {
len = UniStrnlen((wchar_t *)bcc_ptr,
 remaining_words-1);
-   ses->serverNOS =cifs_kcalloc(2 * (len + 
1),GFP_KERNEL);
+   ses->serverNOS =kcalloc(1, 2 * (len + 
1),GFP_KERNEL);
cifs_strfromUCS_le(ses->serverNOS,
   (wchar_t 
*)bcc_ptr,len,nls_codepage);
bcc_ptr += 2 * (len + 1);
@@ -1743,7 +1733,7 @@
len = UniStrnlen((wchar_t *) 
bcc_ptr, remaining_words); 
   /* last string is not always null terminated (for e.g. for Windows 
XP & 2000) */
ses->serverDomain =
-   
cifs_kcalloc(2*(len+1),GFP_KERNEL);
+   kcalloc(1, 
2*(len+1),GFP_KERNEL);

cifs_strfromUCS_le(ses->serverDomain,
 (wchar_t 
*)bcc_ptr,len,nls_codepage);
bcc_ptr += 2 * (len + 1);
@@ -1752,20 +1742,20 @@
} /* else no more room so create dummy 
domain string */
else
ses->serverDomain =
-   cifs_kcalloc(2,
+   kcalloc(1, 2,
GFP_KERNEL);
} else {/* no room so create dummy 
domain and NOS string */

Relayfs Question: Use of relay_reset(). Potential race?

[Kingsley Cheung]

On Wed, Mar 23, 2005 at 08:02:54PM +1100, [EMAIL PROTECTED] wrote:
> Hi 
> 
> I'm using relayfs to relay data from a kernel module to user space on
> a SuSE 2.6.5 kernel.  I'm not absolutely sure what version of relayfs
> has been back ported to it.

Hi Tom,

Could you please have a look at the following use of relay_reset() in
a kernel module as follows (compiled against pre-redux relayfs):

static int
exec_fileop_notify(int rchan_id, struct file *filp, enum relay_fileop op)
{
if (unlikely(rchan_id != exec_cid)) {
printk(KERN_ERR "%s - bad file number\n", __FUNCTION__);
return -EBADF;
}

switch (op) {
case RELAY_FILE_OPEN:
atomic_inc(&exec_client_cnt);
break;
case RELAY_FILE_CLOSE:
if (atomic_dec_and_test(&exec_client_cnt) == 0)
relay_reset(exec_cid); <---
break;
default:
/* do nothing */
break;
}

return 0;
}

Is that legitimate?  The reason I ask is because I've been seeing
garbled oopses with keventd and I've narrowed it to two things:

1) Inadequate locking on my part in the kernel module, which I have
addressed separately.

2) A race with relay_reset() and keventd, which is probably of
interest to you if you're still maintaining the pre-redux patches.

The race is due to the use of INIT_WORK in _reset_relay():

INIT_WORK(&rchan->wake_readers, NULL, NULL);
INIT_WORK(&rchan->wake_writers, NULL, NULL);

However, at the time relay_reset() is called, it is possible that
these work structures are still being used by keventd when under heavy
loads.  The workaround I've used to fix this is to call
flush_scheduled_work() before calling reset_relay() in the kernel
module.  Perhaps that needs to be called in relay_reset() or
_relay_reset()?

As well I'm not sure about the uses of INIT_WORK in
_relay_realloc_buffer() and relay_release() - perhaps they need
attention too.  I understand, however, that flush_schedule_work()
blocks and thus it probably shouldn't be used in certain areas of the
relayfs code.

My thanks,
-- 
Kingsley
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386 & x86_64: Live Patching Funcion on 2.6.11.7

[Takashi Ikebe]

Daniel-san, David-san,
Pannus project has two targets.
One is user-mode application live patching, and the other one is kernel 
live patching.
What we posted now is user-mode application live patching function.

>If I'm right, I'm not sure why some of the bits of it were done
>separately instead of via the existing ptrace mechanism.  And GDB
>would appreciate a mechanism for mmap/munmap/mprotect in a debugged
>process, also.
Daniel-san,
GDB based approach seems not fit to our requirements. GDB(ptrace) based 
functions are basically need to be done when target process is stopping. 
From our experience, sometimes patches became to dozens to hundreds at 
one patching, and in this case GDB based approach cause target process's 
availability descent.

Patch exceeds 50k, so I cut comments and separate architecture, and post 
as in line.

David S. Miller wrote:
On Sun, 17 Apr 2005 14:51:43 -0400
Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:

Takashi-san's description was not very clear, but it sounds like it's a
patching mechanism for userspace applications - not for kernel space.
So kprobes would not be a good fit.

I saw the presentation of this stuff at the Linux Kernel conference
last year in Tokyo.  I'm pretty sure it's for the kernel. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
--
Takashi Ikebe
NTT Network Service Systems Laboratories
9-11, Midori-Cho 3-Chome Musashino-Shi,
Tokyo 180-8585 Japan
Tel : +81 422 59 4246, Fax : +81 422 60 4012
e-mail : [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

question : is the init process of kernel running in kernel space or user space?

[Tomko]

Hi all,
In the linux system , kernel is often starting up like this :
bootloader -> start_32() -> start_kernel() -> init()
i would like to ask what is the piority level in this starting procedure 
? 0 or 3 ? that means, this start up process are running in kernel space 
or user space ?  or the level is keep changing ?
If it is in kernel space from the very beginning , at which point the 
system is switched into user space ? is it at the time when kernel open 
the shell ?

I am new to linux, hope someone can help me here.
Regards,
TOM
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: More performance for the TCP stack by using additional hardware chip on NIC

[Horst von Brand]

Andreas Hartmann <[EMAIL PROTECTED]> said:
> Alacritech developed a new chip for NIC's
> (http://www.alacritech.com/html/tech_review.html), which makes it possible
> to take away the TCP stack from the host CPU. Therefore, the host CPU has
> more performance for the applications according Alacritech.
> 
> This sounds interesting.

This idea has been discussed around here a couple of times, and the
consensus is that it is a bad idea: IP (and upper protocol) processing
is not expensive, if done right, so this really doesn't buy much; this
forces a particular interface to networking into the kernel, loosing
flexibility that way is always bad; there is no access to futzing
around in between (for example, for firewalling and such); and if the
"hardware implementation" has bugs, you are screwed.
-- 
Dr. Horst H. von Brand   User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Kernelpanic - not syncing: VFS: Unable to mount root fs on unknown-block

[S S]

I compiled linux kernel 2.6.11.7 on RHEL and while
rebooting I get this
error message -

Cannot open root device /SCSIGroup00/SCSIVol000
Please append a correct "root=" boot option
Kernelpanic - not syncing: VFS: Unable to mount root
fs on
unknown-block 0,0

This root entry in grub .conf is identical to kernel
image entry 2.6.9 which boots fine. However 2.6.11.7
compiled kernel does not find
/dev//SCSIGroup00/SCSIVol000

Could anyone please suggest what could be going wrong.

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.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/

Fedora Core 2 installation cannot recognize raid disks?

[Xin Zhao]

Sorry for this dumb question.

I am trying to install Fedora Core 2 on a dell PowerEdge  2850 with
three 73GB SCSI disks on a RAID 4e/DI controller. I set it up as Raid
5. but when I tried to install FC2, it always complaint that no disk
drive can be found.

Can anybody give me some advice on how to address thsi problem? Many
thanks in advance.

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

Re: [RFC] FUSE permission modell (Was: fuse review bits)

[Bodo Eggert <[EMAIL PROTECTED]>]

Eric Van Hensbergen <[EMAIL PROTECTED]> wrote:
> On 4/11/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote:

>> 
>>   1) Only allow mount over a directory for which the user has write
>>  access (and is not sticky)
>> 
>>   2) Use nosuid,nodev mount options
[...]

> Do these solve all the security concerns with unprivileged mounts, or
> are there other barriers/concerns?  Should there be ulimit (or rlimit)
> style restrictions on how many mounts/binds a user is allowed to have
> to prevent users from abusing mount privs?

Definitively. Mountpoints use kernel space, the users could DoS the machine.
The per-Machine-limit isn't fine-grained enough, since the users may DoS
each other.

You'll have to avoid users capturing system daemons in D state or in
slowed-down artificial directory-forests, too. I think namespaces will
do most the trick.

> I was thinking about this a while back and thought having a user-mount
> permissions file might be the right way to address lots of these
> issues.  Essentially it would contain information about what
> users/groups were allowed to mount what sources to what destinations
> and with what mandatory options.

Users being able to mount random fs containing suid or device nodes
are root whenever they want to. If you want to mount with dev or suid,
use sudo and restrict the mount to a limited set of images/devices/whatever.
-- 
Anger, fear, aggression. The Dark Side of the Force are they.
Once you start down the Dark Path, forever will it dominate your destiny.
-- Jedi Master Yoda

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

Re: Why Ext2/3 needs immutable attribute?

[Xin Zhao]

We can certainly harden the system, but sometime the vulnerability in
kernel is hard to detect and protect. For example, the brk()
vulnerablitiy found in Linux kernel. All the security mechanisms you
mentioned have to rely on a healthy kernel. Unfortunately, the kernel
itself could be compromised too. Although it could be very difficult,
thereotically speaking,  any kernel level protection, including
SELinux, could be disabled after the kernel is compromised. Am I
missing some points here?


On 4/17/05, Bernd Eckenfels <[EMAIL PROTECTED]> wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > Yes. I know,  with immutable,  even root cannot modify sensitive
> > files. What I am curious is if an intruder has root access, he may
> > have many ways to turn off the immutable protection and modify files.
> 
> If you secure your system correctly (i.e make /dev/*mem imutable, disalow
> module loading, restrict io... (and I admit it is quite complicated to find
> all holes and secure it correctly without additional ptches like SELinux))
> then even root cant gt arround immutable or append only (without rebooting).
> 
> Greetings
> Bernd
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] drivers/net/wan/: possible cleanups

[Adrian Bunk]

On Fri, Apr 15, 2005 at 06:49:56PM +0100, Alan Cox wrote:
> On Gwe, 2005-04-15 at 00:20, Adrian Bunk wrote:
> > On Sun, Mar 27, 2005 at 05:38:38PM +0100, Alan Cox wrote:
> > > On Sul, 2005-03-27 at 15:34, Adrian Bunk wrote:
> > > >   - syncppp.c: sppp_input
> > > >   - syncppp.c: sppp_change_mtu
> > > >   - z85230.c: z8530_dma_sync
> > > >   - z85230.c: z8530_txdma_sync
> > > 
> > > Please leave the z85230 ones at least. They are an intentional part of
> > > the external API for writing other 85230 card drivers.
> > 
> > If they are part of an API, why aren't the prototypes for them in any 
> > header file?
> 
> They were once. I guess that got "tided" at some point, possibly long
> ago even before submission.
>...

Are there any external drivers using these exports, and if there are, 
why aren't they in the kernel?

If there aren't and someone will at some time in the future need them, 
re-adding the exports will be trivial.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: [PATCH] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU

[Greg KH]

On Wed, Apr 13, 2005 at 09:12:53PM -0400, Derek Cheung wrote:
> OK, hope this patch can satisfy everyone :-)
> 
> The following is the diffstat of the enclosed patch file:
> 
>  drivers/i2c/busses/Kconfig   |   10 
>  drivers/i2c/busses/Makefile  |1 
>  drivers/i2c/busses/i2c-mcf5282.c |  414
> +++
>  drivers/i2c/busses/i2c-mcf5282.h |   46 
>  include/asm-m68knommu/m528xsim.h |   42 +++
>  5 files changed, 513 insertions(+)
> 
> I did:
> 
> a) remove all trailing spaces in the files
> b) re-align the switch statement
> c) change a return statement
> d) change some white space intents to TABs
> e) insert a break for the I2C_SMBUS_PROC_CALL, thanks for spotting it
> f) fix the mcf5282lite wording in Kconfig
> 
> I did not:
> 
> g) use the ioremap. This is because Coldfire is a CPU without MMU and
> there is no difference between virtual and physical memory. In fact, the
> ioremap routine in the m68knommu is simply a stub routine that returns
> the input address argument for compatibility reason. Also, all other
> Coldfire CPU include files such as the m5307sim.h uses the volatile
> declaration method. 
> So, I hope this is acceptable to the Linux kernel maintainers

No, do not do this.  Even the i386 platform can get away with doing this
kind of io memory addressing, but drivers do not do that, as they are
not portable.  The first time someone wants to use this kind of i2c
adapter on a non-coldfire chip, they will have to rewrite the driver,
not acceptable.

Also, you did not include a good Changelog entry, nor a Signed-off-by:
line, and you attached the file in a mime attachment.

Please fix these issues up.

thanks,

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

Re: [PATCH] tpm: Stop taking over the non-unique lpc bus PCI ID, Also timer, stack and enum fixes

[Greg KH]

On Sun, Apr 17, 2005 at 10:05:27AM +1000, Dave Airlie wrote:
> > NO!  DO NOT use pci_find_device().  It is broken for systems with pci
> > hotplug (which means any pci system).  Please use the way the driver
> > currently works, that is correct.
> 
> But its not an LPC driver, it only uses a small piece of the LPC, we
> really do need some sort of bridge driver layer or something for
> these, then other drivers can sit on top of that,

Then the TPM driver can provide that layer.

> The DRM still uses pci_find_device for the exact same reason, the fb
> drivers take the PCI device and we have been told we can't use the
> proper interface, hence one of the needs to merge fb and DRM..

Exactly.

thanks,

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

Re: 2.6.12-rc2-mm3

[Mikael Pettersson]

On Mon, 18 Apr 2005 00:27:02 +0200, Alexander Nyberg wrote:
>This patch fixes the NMI checking problems in -mm x64 for me. It 

What problems?

>changes the perfctr selection to use RETIRED_UOPS instead 
>(makes both processors tick even on my box).

This patch mixes what appears to be cleanups with what appears
to be bug fixes. Please separate them, and describe the problem
in enough detail that we can judge the validity of the bug-fix parts.

>Index: x64_mm/arch/x86_64/kernel/nmi.c
>===
>--- x64_mm.orig/arch/x86_64/kernel/nmi.c   2005-04-17 14:34:09.0 
>+0200
>+++ x64_mm/arch/x86_64/kernel/nmi.c2005-04-18 02:11:37.0 +0200
>@@ -58,7 +58,7 @@
> int panic_on_timeout;
> 
> unsigned int nmi_watchdog = NMI_DEFAULT;
>-static unsigned int nmi_hz = HZ;
>+static unsigned long nmi_hz = HZ;

Why? Surely the value won't exceed 2^32-1?

> unsigned int nmi_perfctr_msr; /* the MSR to reset in NMI handler */
> 
> /* Note that these events don't tick when the CPU idles. This means
>@@ -70,6 +70,7 @@
> #define K7_EVNTSEL_USR(1 << 16)
> #define K7_EVENT_CYCLES_PROCESSOR_IS_RUNNING  0x76
> #define K7_NMI_EVENT  K7_EVENT_CYCLES_PROCESSOR_IS_RUNNING
>+#define K7_RETIRED_UOPS   0xC1 /* always running */
> 
> #define P6_EVNTSEL0_ENABLE(1 << 22)
> #define P6_EVNTSEL_INT(1 << 20)
>@@ -78,6 +79,11 @@
> #define P6_EVENT_CPU_CLOCKS_NOT_HALTED0x79
> #define P6_NMI_EVENT  P6_EVENT_CPU_CLOCKS_NOT_HALTED
> 
>+static inline unsigned long nmi_interval(void)
>+{
>+  return (((unsigned long)cpu_khz * 1000UL) / nmi_hz);

Extraneous parentheses. Also I'd prefer to divide before the multiply.

>+}
>+
> /* Run after command line and cpu_init init, but before all other checks */
> void __init nmi_watchdog_default(void)
> {
>@@ -129,8 +135,8 @@
> 
>   for (cpu = 0; cpu < NR_CPUS; cpu++)
>   counts[cpu] = cpu_pda[cpu].__nmi_count; 
>-  local_irq_enable();

Why?

>-  mdelay((10*1000)/nmi_hz); // wait 10 ticks
>+
>+  mdelay((10*1000) / nmi_hz); /* wait 10 NMI ticks */

Not a bug fix.

> 
>   for (cpu = 0; cpu < NR_CPUS; cpu++) {
>   if (cpu_pda[cpu].__nmi_count - counts[cpu] <= 5) {
>@@ -305,9 +311,6 @@
>   int i;
>   unsigned int evntsel;
> 
>-  /* No check, so can start with slow frequency */
>-  nmi_hz = 1; 
>-

What's this for?

>   /* XXX should check these in EFER */
> 
>   nmi_perfctr_msr = MSR_K7_PERFCTR0;
>@@ -322,10 +325,10 @@
>   evntsel = K7_EVNTSEL_INT
>   | K7_EVNTSEL_OS
>   | K7_EVNTSEL_USR
>-  | K7_NMI_EVENT;
>+  | K7_RETIRED_UOPS;

Bogus. Redefine K7_NMI_EVENT instead.

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

[2.6 patch] drivers/w1/: possible cleanups

[Adrian Bunk]

This patch contains the following possible cleanups:
- make needlessly global code static
- #if 0 unused functions
- remove unused EXPORT_SYMBOL's

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

---

 drivers/w1/dscore.c|   35 ++-
 drivers/w1/dscore.h|4 
 drivers/w1/w1.c|   10 +-
 drivers/w1/w1.h|1 -
 drivers/w1/w1_family.c |   17 -
 drivers/w1/w1_family.h |2 --
 drivers/w1/w1_int.c|7 ---
 drivers/w1/w1_int.h|2 --
 drivers/w1/w1_io.c |   15 ++-
 drivers/w1/w1_io.h |3 ---
 10 files changed, 45 insertions(+), 51 deletions(-)

--- linux-2.6.12-rc2-mm3-full/drivers/w1/dscore.h.old   2005-04-18 
00:17:43.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/w1/dscore.h   2005-04-18 
00:23:28.0 +0200
@@ -156,11 +156,7 @@
 int ds_read_bit(struct ds_device *, u8 *);
 int ds_write_byte(struct ds_device *, u8);
 int ds_write_bit(struct ds_device *, u8);
-int ds_start_pulse(struct ds_device *, int);
-int ds_set_speed(struct ds_device *, int);
 int ds_reset(struct ds_device *, struct ds_status *);
-int ds_detect(struct ds_device *, struct ds_status *);
-int ds_stop_pulse(struct ds_device *, int);
 struct ds_device * ds_get_device(void);
 void ds_put_device(struct ds_device *);
 int ds_write_block(struct ds_device *, u8 *, int);
--- linux-2.6.12-rc2-mm3-full/drivers/w1/dscore.c.old   2005-04-18 
00:18:43.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/w1/dscore.c   2005-04-18 
00:56:47.0 +0200
@@ -32,19 +32,16 @@
 };
 MODULE_DEVICE_TABLE(usb, ds_id_table);
 
-int ds_probe(struct usb_interface *, const struct usb_device_id *);
-void ds_disconnect(struct usb_interface *);
+static int ds_probe(struct usb_interface *, const struct usb_device_id *);
+static void ds_disconnect(struct usb_interface *);
 
 int ds_touch_bit(struct ds_device *, u8, u8 *);
 int ds_read_byte(struct ds_device *, u8 *);
 int ds_read_bit(struct ds_device *, u8 *);
 int ds_write_byte(struct ds_device *, u8);
 int ds_write_bit(struct ds_device *, u8);
-int ds_start_pulse(struct ds_device *, int);
-int ds_set_speed(struct ds_device *, int);
+static int ds_start_pulse(struct ds_device *, int);
 int ds_reset(struct ds_device *, struct ds_status *);
-int ds_detect(struct ds_device *, struct ds_status *);
-int ds_stop_pulse(struct ds_device *, int);
 struct ds_device * ds_get_device(void);
 void ds_put_device(struct ds_device *);
 
@@ -126,7 +123,8 @@
printk("%45s: %8x\n", str, buf[off]);
 }
 
-int ds_recv_status_nodump(struct ds_device *dev, struct ds_status *st, 
unsigned char *buf, int size)
+static int ds_recv_status_nodump(struct ds_device *dev, struct ds_status *st,
+unsigned char *buf, int size)
 {
int count, err;

@@ -245,6 +243,8 @@
return err;
 }
 
+#if 0
+
 int ds_stop_pulse(struct ds_device *dev, int limit)
 {
struct ds_status st;
@@ -297,7 +297,9 @@
return err;
 }
 
-int ds_wait_status(struct ds_device *dev, struct ds_status *st)
+#endif  /*  0  */
+
+static int ds_wait_status(struct ds_device *dev, struct ds_status *st)
 {
u8 buf[0x20];
int err, count = 0;
@@ -345,6 +347,7 @@
return 0;
 }
 
+#if 0
 int ds_set_speed(struct ds_device *dev, int speed)
 {
int err;
@@ -363,8 +366,9 @@
 
return err;
 }
+#endif  /*  0  */
 
-int ds_start_pulse(struct ds_device *dev, int delay)
+static int ds_start_pulse(struct ds_device *dev, int delay)
 {
int err;
u8 del = 1 + (u8)(delay >> 4);
@@ -552,6 +556,8 @@
return !(err == len);
 }
 
+#if 0
+
 int ds_search(struct ds_device *dev, u64 init, u64 *buf, u8 id_number, int 
conditional_search)
 {
int err;
@@ -625,7 +631,10 @@
return 0;
 }
 
-int ds_probe(struct usb_interface *intf, const struct usb_device_id *udev_id)
+#endif  /*  0  */
+
+static int ds_probe(struct usb_interface *intf,
+   const struct usb_device_id *udev_id)
 {
struct usb_device *udev = interface_to_usbdev(intf);
struct usb_endpoint_descriptor *endpoint;
@@ -720,7 +729,7 @@
return 0;
 }
 
-void ds_disconnect(struct usb_interface *intf)
+static void ds_disconnect(struct usb_interface *intf)
 {
struct ds_device *dev;

@@ -740,7 +749,7 @@
ds_dev = NULL;
 }
 
-int ds_init(void)
+static int ds_init(void)
 {
int err;
 
@@ -753,7 +762,7 @@
return 0;
 }
 
-void ds_fini(void)
+static void ds_fini(void)
 {
usb_deregister(&ds_driver);
 }
--- linux-2.6.12-rc2-mm3-full/drivers/w1/w1.h.old   2005-04-18 
00:24:29.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/w1/w1.h   2005-04-18 00:24:34.0 
+0200
@@ -137,7 +137,6 @@
 };
 
 int w1_create_master_attributes(struct w1_master *);
-void w1_destroy_master_attributes(struct w1_master *);
 void w1_search(struct w1_master *dev);
 
 #endif /* __KERNEL__ */
--- linux-2.6.12-rc2-mm3-fu

[2.6 patch] drivers/video/sis/: make some functions static

[Adrian Bunk]

This patch makes some needlessly global functions static.

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

---

 drivers/video/sis/init.c |4 ++--
 drivers/video/sis/init.h |3 ---
 drivers/video/sis/init301.c  |9 +
 drivers/video/sis/init301.h  |4 
 drivers/video/sis/sis_main.c |5 +++--
 5 files changed, 10 insertions(+), 15 deletions(-)

--- linux-2.6.12-rc2-mm3-full/drivers/video/sis/init.h.old  2005-04-18 
00:41:31.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/video/sis/init.h  2005-04-18 
00:43:25.0 +0200
@@ -2394,11 +2394,9 @@
 void   SiS_DisplayOn(SiS_Private *SiS_Pr);
 void   SiS_DisplayOff(SiS_Private *SiS_Pr);
 void   SiSRegInit(SiS_Private *SiS_Pr, SISIOADDRESS BaseAddr);
-void   SiSSetLVDSetc(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo);
 BOOLEAN SiSDetermineROMLayout661(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo);
 void   SiS_SetEnableDstn(SiS_Private *SiS_Pr, int enable);
 void   SiS_SetEnableFstn(SiS_Private *SiS_Pr, int enable);
-void   SiS_GetVBType(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo);
 BOOLEANSiS_SearchModeID(SiS_Private *SiS_Pr, USHORT *ModeNo, USHORT 
*ModeIdIndex);
 UCHAR  SiS_GetModePtr(SiS_Private *SiS_Pr, USHORT ModeNo, USHORT ModeIdIndex);
 USHORT SiS_GetColorDepth(SiS_Private *SiS_Pr, USHORT ModeNo, USHORT 
ModeIdIndex);
@@ -2444,7 +2442,6 @@
 extern void SiS_SetYPbPr(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo);
 extern voidSiS_SetTVMode(SiS_Private *SiS_Pr, USHORT ModeNo, USHORT 
ModeIdIndex, PSIS_HW_INFO HwInfo);
 extern void SiS_UnLockCRT2(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo);
-extern void SiS_LockCRT2(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo);
 extern void SiS_DisableBridge(SiS_Private *, PSIS_HW_INFO);
 extern BOOLEAN  SiS_SetCRT2Group(SiS_Private *, PSIS_HW_INFO, USHORT);
 extern USHORT   SiS_GetRatePtr(SiS_Private *SiS_Pr, USHORT ModeNo, USHORT 
ModeIdIndex,
--- linux-2.6.12-rc2-mm3-full/drivers/video/sis/init.c.old  2005-04-18 
00:41:47.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/video/sis/init.c  2005-04-18 
00:42:03.0 +0200
@@ -1384,7 +1384,7 @@
 /* HELPER: SetLVDSetc*/
 /*/
 
-void
+static void
 SiSSetLVDSetc(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo)
 {
USHORT temp;
@@ -1625,7 +1625,7 @@
 /* HELPER: GetVBType */
 /*/
 
-void
+static void
 SiS_GetVBType(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo)
 {
   USHORT flag=0, rev=0, nolcd=0, p4_0f, p4_25, p4_27;
--- linux-2.6.12-rc2-mm3-full/drivers/video/sis/init301.h.old   2005-04-18 
00:42:27.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/video/sis/init301.h   2005-04-18 
00:43:59.0 +0200
@@ -293,7 +293,6 @@
 #endif
 
 void   SiS_UnLockCRT2(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo);
-void   SiS_LockCRT2(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo);
 void   SiS_EnableCRT2(SiS_Private *SiS_Pr);
 USHORT SiS_GetRatePtr(SiS_Private *SiS_Pr, USHORT ModeNo, USHORT ModeIdIndex, 
PSIS_HW_INFO HwInfo);
 void   SiS_WaitRetrace1(SiS_Private *SiS_Pr);
@@ -310,7 +309,6 @@
 USHORT RefreshRateTableIndex, PSIS_HW_INFO HwInfo);
 USHORT SiS_GetResInfo(SiS_Private *SiS_Pr,USHORT ModeNo,USHORT ModeIdIndex);
 void   SiS_DisableBridge(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo);
-void   SiS_EnableBridge(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo);
 BOOLEANSiS_SetCRT2Group(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo, 
USHORT ModeNo);
 void   SiS_SiS30xBLOn(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo);
 void   SiS_SiS30xBLOff(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo);
@@ -319,8 +317,6 @@
 USHORT SiS_GetCH700x(SiS_Private *SiS_Pr, USHORT tempax);
 void   SiS_SetCH701x(SiS_Private *SiS_Pr, USHORT tempax);
 USHORT SiS_GetCH701x(SiS_Private *SiS_Pr, USHORT tempax);
-void   SiS_SetCH70xx(SiS_Private *SiS_Pr, USHORT tempax);
-USHORT SiS_GetCH70xx(SiS_Private *SiS_Pr, USHORT tempax);
 void   SiS_SetCH70xxANDOR(SiS_Private *SiS_Pr, USHORT tempax,USHORT 
tempbh);
 #ifdef SIS315H
 static voidSiS_Chrontel701xOn(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo);
--- linux-2.6.12-rc2-mm3-full/drivers/video/sis/init301.c.old   2005-04-18 
00:42:42.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/video/sis/init301.c   2005-04-18 
00:52:32.0 +0200
@@ -86,6 +86,7 @@
 #define SiS_I2CDELAYSHORT  150
 
 static USHORT SiS_GetBIOSLCDResInfo(SiS_Private *SiS_Pr);
+static void SiS_SetCH70xx(SiS_Private *SiS_Pr, USHORT tempbx);
 
 /*/
 /* HELPER: Lock/Unlock CRT2  */
@@ -100,7 +101,7 @@
   SiS_SetRegOR(SiS_Pr->SiS_Part1Port,0x24,0x01);
 }
 
-void
+static void
 SiS_LockCRT2(SiS_Private *SiS_Pr, PSIS_HW_INFO HwInfo)
 {
if(HwInfo->jChipType >= SIS_315H)
@@ -4236,7 +4237,7 @@
  * from outside the context of a mode switch!
  * MUST call getVBType before calling this
  */
-void
+s

[2.6 patch] drivers/video/fbsysfs.c: make a struct static

[Adrian Bunk]

This patch makes a needlessly global struct static.

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

--- linux-2.6.12-rc2-mm3-full/drivers/video/fbsysfs.c.old   2005-04-18 
00:40:01.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/video/fbsysfs.c   2005-04-18 
00:40:09.0 +0200
@@ -354,7 +354,7 @@
fb_info->var.xoffset);
 }
 
-struct class_device_attribute class_device_attrs[] = {
+static struct class_device_attribute class_device_attrs[] = {
__ATTR(bits_per_pixel, S_IRUGO|S_IWUSR, show_bpp, store_bpp),
__ATTR(blank, S_IRUGO|S_IWUSR, show_blank, store_blank),
__ATTR(color_map, S_IRUGO|S_IWUSR, show_cmap, store_cmap),

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

[2.6 patch] drivers/video/fbmem.c: make a function static

[Adrian Bunk]

This patch makes a needlessly global function static.

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

--- linux-2.6.12-rc2-mm3-full/drivers/video/fbmem.c.old 2005-04-18 
00:39:21.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/video/fbmem.c 2005-04-18 
00:39:34.0 +0200
@@ -1312,7 +1312,7 @@
  * Returns zero.
  *
  */
-int __init video_setup(char *options)
+static int __init video_setup(char *options)
 {
int i, global = 0;
 

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

SkyMinder (CLPS711x derivative) - decided to try 2.6.11.7

[Luke Kenneth Casson Leighton]

... aaand it flopped.  i'm not even getting data out of the
serial console - not a squeak.  HELP!

the patch is quite large - and contains [working in 2.4.27] a
lot of untested stuff - naturally, if i don't get a squeak out
of the serial console.  features include support for CPU_FREQ
which is a bitch on the CLPS711x because the bloody serial
uarts are tied to the PLLW, which changes of course depending
on clock speed (!!!).

anyway.

patch INCLUDING config file can be viewed at:

http://lkcl.net/skyminder

the physical setup (memory etc.) is pretty much identical to
an EDB7312.

oh - i also added a #define for FIQ_START, which makes it
possible to enable the FIQ code (CONFIG_FIQ).

boot is performed using a drastically modified version of
armboot [which works perfectly for the 2.4.27 kernel].

kernel is loaded into memory at 0xc080.
${CROSS_COMPILE}-objcopy is used to prepare a linux.bin.
mkimage is used to prepare that into an appropriate format...

${CROSS_COMPILE} is set to arm-unknown-linux-gnu-

arm-unknown-linux-gnu-gcc --version gives 3.3.3


the only thing _not_ working on the 2.4.27 kernel was the
keyboard driver: as soon as that was loaded (as either an input
device _or_ a keyboard device - yes i tried both variations,
basing the code on both pc_keyb.c _and_ usbkbd.c) then the
console _instantly_ crashed.

i got sufficiently pissed off with 2.4.27 that i decided to
go to 2.6, and i'm stuck before i can even begin.

2.4.27 compiles with arm-linux-gcc, version 2.95.1


help, help, gloop, gloop, there's a lot riding on getting this
working: where do i start when you can't even see anything
coming out of the serial console?

any help much appreciated.

l.

-- 
--
http://lkcl.net";>http://lkcl.net
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.12-rc2-mm3

[Alexander Nyberg]

mån 2005-04-11 klockan 01:25 -0700 skrev Andrew Morton:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> 

I tried to kexec on my x64 and it hangs up in calibrate_delay() because
the PIT never fires any interrupts so jiffies is never updated. Has
kexec been tested on x64 and should be working? I want to know if I
should start looking at weirdness with my hardware or if it is like this
on all x64 boxes.

Also, patch at bottom is needed to compile kexec on x64 without ia32
emulation support (the includes are not used at the moment).

  CC  arch/x86_64/kernel/crash.o
In file included from arch/x86_64/kernel/crash.c:18:
include/linux/elfcore.h: I funktion `elf_core_copy_regs':
include/linux/elfcore.h:92: error: dereferencing pointer to incomplete type
include/linux/elfcore.h:92: error: dereferencing pointer to incomplete type


Index: x64_mm/arch/x86_64/kernel/crash.c
===
--- x64_mm.orig/arch/x86_64/kernel/crash.c  2005-04-16 19:23:58.0 
+0200
+++ x64_mm/arch/x86_64/kernel/crash.c   2005-04-16 19:47:56.0 +0200
@@ -14,8 +14,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 
 #include 
 #include 


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.12-rc2-mm3

[Alexander Nyberg]

> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
> 
> 

[Mikael Pettersson on CC, would like your advice]

This patch fixes the NMI checking problems in -mm x64 for me. It 
changes the perfctr selection to use RETIRED_UOPS instead 
(makes both processors tick even on my box).

This makes the NMI tick once per second while running which is quite much, 
I'd like to get it down to every fourth second and herein lies the problem.
Multiplying nmi_interval() in patch below with 4 does not help, still ticks 
at about the same pace. I'm puzzled...


Index: x64_mm/arch/x86_64/kernel/nmi.c
===
--- x64_mm.orig/arch/x86_64/kernel/nmi.c2005-04-17 14:34:09.0 
+0200
+++ x64_mm/arch/x86_64/kernel/nmi.c 2005-04-18 02:11:37.0 +0200
@@ -58,7 +58,7 @@
 int panic_on_timeout;
 
 unsigned int nmi_watchdog = NMI_DEFAULT;
-static unsigned int nmi_hz = HZ;
+static unsigned long nmi_hz = HZ;
 unsigned int nmi_perfctr_msr;  /* the MSR to reset in NMI handler */
 
 /* Note that these events don't tick when the CPU idles. This means
@@ -70,6 +70,7 @@
 #define K7_EVNTSEL_USR (1 << 16)
 #define K7_EVENT_CYCLES_PROCESSOR_IS_RUNNING   0x76
 #define K7_NMI_EVENT   K7_EVENT_CYCLES_PROCESSOR_IS_RUNNING
+#define K7_RETIRED_UOPS0xC1 /* always running */
 
 #define P6_EVNTSEL0_ENABLE (1 << 22)
 #define P6_EVNTSEL_INT (1 << 20)
@@ -78,6 +79,11 @@
 #define P6_EVENT_CPU_CLOCKS_NOT_HALTED 0x79
 #define P6_NMI_EVENT   P6_EVENT_CPU_CLOCKS_NOT_HALTED
 
+static inline unsigned long nmi_interval(void)
+{
+   return (((unsigned long)cpu_khz * 1000UL) / nmi_hz);
+}
+
 /* Run after command line and cpu_init init, but before all other checks */
 void __init nmi_watchdog_default(void)
 {
@@ -129,8 +135,8 @@
 
for (cpu = 0; cpu < NR_CPUS; cpu++)
counts[cpu] = cpu_pda[cpu].__nmi_count; 
-   local_irq_enable();
-   mdelay((10*1000)/nmi_hz); // wait 10 ticks
+
+   mdelay((10*1000) / nmi_hz); /* wait 10 NMI ticks */
 
for (cpu = 0; cpu < NR_CPUS; cpu++) {
if (cpu_pda[cpu].__nmi_count - counts[cpu] <= 5) {
@@ -305,9 +311,6 @@
int i;
unsigned int evntsel;
 
-   /* No check, so can start with slow frequency */
-   nmi_hz = 1; 
-
/* XXX should check these in EFER */
 
nmi_perfctr_msr = MSR_K7_PERFCTR0;
@@ -322,10 +325,10 @@
evntsel = K7_EVNTSEL_INT
| K7_EVNTSEL_OS
| K7_EVNTSEL_USR
-   | K7_NMI_EVENT;
+   | K7_RETIRED_UOPS;
 
wrmsr(MSR_K7_EVNTSEL0, evntsel, 0);
-   wrmsrl(MSR_K7_PERFCTR0, -((u64)cpu_khz*1000) / nmi_hz);
+   wrmsrl(MSR_K7_PERFCTR0, -nmi_interval());
apic_write(APIC_LVTPC, APIC_DM_NMI);
evntsel |= K7_EVNTSEL_ENABLE;
wrmsr(MSR_K7_EVNTSEL0, evntsel, 0);
@@ -409,7 +412,7 @@
alert_counter[cpu] = 0;
}
if (nmi_perfctr_msr)
-   wrmsr(nmi_perfctr_msr, -(cpu_khz/nmi_hz*1000), -1);
+   wrmsr(nmi_perfctr_msr, -nmi_interval(), -1);
 }
 
 static int dummy_nmi_callback(struct pt_regs * regs, int cpu)


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] rename rw_verify_area() to rw_access_ok()

[Jesper Juhl]

verify_area() will soon be dead and gone, replaced by access_ok(), thus 
the function named rw_verify_area() is badly named and should be renamed. 
This patch renames rw_verify_area to rw_access_ok which seems more 
appropriate (it also updates all callers of the functions as well as 
references to it in comments).

Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 arch/mips/kernel/linux32.c |4 ++--
 fs/compat.c|2 +-
 fs/locks.c |2 +-
 fs/read_write.c|   12 ++--
 include/linux/fs.h |2 +-
 5 files changed, 11 insertions(+), 11 deletions(-)

--- linux-2.6.12-rc2-mm3-orig/fs/read_write.c   2005-04-11 21:20:51.0 
+0200
+++ linux-2.6.12-rc2-mm3/fs/read_write.c2005-04-17 23:39:14.0 
+0200
@@ -183,7 +183,7 @@ bad:
 #endif
 
 
-int rw_verify_area(int read_write, struct file *file, loff_t *ppos, size_t 
count)
+int rw_access_ok(int read_write, struct file *file, loff_t *ppos, size_t count)
 {
struct inode *inode;
loff_t pos;
@@ -230,7 +230,7 @@ ssize_t vfs_read(struct file *file, char
if (unlikely(!access_ok(VERIFY_WRITE, buf, count)))
return -EFAULT;
 
-   ret = rw_verify_area(READ, file, pos, count);
+   ret = rw_access_ok(READ, file, pos, count);
if (!ret) {
ret = security_file_permission (file, MAY_READ);
if (!ret) {
@@ -278,7 +278,7 @@ ssize_t vfs_write(struct file *file, con
if (unlikely(!access_ok(VERIFY_READ, buf, count)))
return -EFAULT;
 
-   ret = rw_verify_area(WRITE, file, pos, count);
+   ret = rw_access_ok(WRITE, file, pos, count);
if (!ret) {
ret = security_file_permission (file, MAY_WRITE);
if (!ret) {
@@ -480,7 +480,7 @@ static ssize_t do_readv_writev(int type,
goto out;
}
 
-   ret = rw_verify_area(type, file, pos, tot_len);
+   ret = rw_access_ok(type, file, pos, tot_len);
if (ret)
goto out;
 
@@ -633,7 +633,7 @@ static ssize_t do_sendfile(int out_fd, i
else
if (!(in_file->f_mode & FMODE_PREAD))
goto fput_in;
-   retval = rw_verify_area(READ, in_file, ppos, count);
+   retval = rw_access_ok(READ, in_file, ppos, count);
if (retval)
goto fput_in;
 
@@ -654,7 +654,7 @@ static ssize_t do_sendfile(int out_fd, i
if (!out_file->f_op || !out_file->f_op->sendpage)
goto fput_out;
out_inode = out_file->f_dentry->d_inode;
-   retval = rw_verify_area(WRITE, out_file, &out_file->f_pos, count);
+   retval = rw_access_ok(WRITE, out_file, &out_file->f_pos, count);
if (retval)
goto fput_out;
 
--- linux-2.6.12-rc2-mm3-orig/fs/compat.c   2005-04-11 21:20:50.0 
+0200
+++ linux-2.6.12-rc2-mm3/fs/compat.c2005-04-17 23:41:32.0 +0200
@@ -1190,7 +1190,7 @@ static ssize_t compat_do_readv_writev(in
goto out;
}
 
-   ret = rw_verify_area(type, file, pos, tot_len);
+   ret = rw_access_ok(type, file, pos, tot_len);
if (ret)
goto out;
 
--- linux-2.6.12-rc2-mm3-orig/fs/locks.c2005-04-05 21:21:43.0 
+0200
+++ linux-2.6.12-rc2-mm3/fs/locks.c 2005-04-17 23:41:47.0 +0200
@@ -1018,7 +1018,7 @@ int locks_mandatory_locked(struct inode 
  * @count:  length of area to check
  *
  * Searches the inode's list of locks to find any POSIX locks which conflict.
- * This function is called from rw_verify_area() and
+ * This function is called from rw_access_ok() and
  * locks_verify_truncate().
  */
 int locks_mandatory_area(int read_write, struct inode *inode,
--- linux-2.6.12-rc2-mm3-orig/arch/mips/kernel/linux32.c2005-04-05 
21:21:08.0 +0200
+++ linux-2.6.12-rc2-mm3/arch/mips/kernel/linux32.c 2005-04-17 
23:42:03.0 +0200
@@ -468,7 +468,7 @@ asmlinkage ssize_t sys32_pread(unsigned 
if (!(file->f_mode & FMODE_READ))
goto out;
pos = merge_64(a4, a5);
-   ret = rw_verify_area(READ, file, &pos, count);
+   ret = rw_access_ok(READ, file, &pos, count);
if (ret)
goto out;
ret = -EINVAL;
@@ -503,7 +503,7 @@ asmlinkage ssize_t sys32_pwrite(unsigned
if (!(file->f_mode & FMODE_WRITE))
goto out;
pos = merge_64(a4, a5);
-   ret = rw_verify_area(WRITE, file, &pos, count);
+   ret = rw_access_ok(WRITE, file, &pos, count);
if (ret)
goto out;
ret = -EINVAL;
--- linux-2.6.12-rc2-mm3-orig/include/linux/fs.h2005-04-11 
21:20:56.0 +0200
+++ linux-2.6.12-rc2-mm3/include/linux/fs.h 2005-04-17 23:42:13.0 
+0200
@@ -1260,7 +1260,7 @@ static inline int locks_verify_locked(st
return 0;
 }
 
-extern int rw_verify_area(int, struct file *, loff_t *, size_t);
+extern int rw_access_ok(int, struct file *

[PATCH 2.6.11.7] sbpcd init cleanup and fix

[Ross Kendall Axe]

- Remove ugly '#ifdef MODULE's
- Use the __exit attribute on sbpcd_exit()
- Don't rename sbpcd_init() to __sbpcd_init() in modules
- Make sbpcd_init() and sbpcd_exit() static
- Ensure sbpcd_init() is actually called when the driver is compiled in
to the kernel

Signed-off-by: Ross Kendall Axe <[EMAIL PROTECTED]>
--- linux-2.6.11.7/drivers/cdrom/sbpcd.c.orig	2005-04-13 17:12:29.0 +0100
+++ linux-2.6.11.7/drivers/cdrom/sbpcd.c	2005-04-13 17:46:29.0 +0100
@@ -5639,11 +5639,7 @@ static int __init config_spea(void)
  */
 
 /* FIXME: cleanups after failed allocations are too ugly for words */
-#ifdef MODULE
-int __init __sbpcd_init(void)
-#else
-int __init sbpcd_init(void)
-#endif
+static int __init sbpcd_init(void)
 {
 	int i=0, j=0;
 	int addr[2]={1, CDROM_PORT};
@@ -5894,8 +5890,7 @@ int __init sbpcd_init(void)
 	return 0;
 }
 /*==*/
-#ifdef MODULE
-void sbpcd_exit(void)
+static void __exit sbpcd_exit(void)
 {
 	int j;
 	
@@ -5926,11 +5921,10 @@ void sbpcd_exit(void)
 }
 
 
-module_init(__sbpcd_init) /*HACK!*/;
+module_init(sbpcd_init);
 module_exit(sbpcd_exit);
 
 
-#endif /* MODULE */
 static int sbpcd_media_changed(struct cdrom_device_info *cdi, int disc_nr)
 {
 	struct sbpcd_drive *p = cdi->handle;


signature.asc
Description: OpenPGP digital signature

Re: ACPI/HT or Packet Scheduler BUG?

[Herbert Xu]

On Sun, Apr 17, 2005 at 07:46:16PM +0200, Patrick McHardy wrote:
> 
> HTB also needs to be fixed. Destruction is usually defered by the
> refcnt until ->put(), htb_put() doesn't lock the tree. Same for
> HFSC and CBQ.

Yes you're absolutely right.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[-mm patch] fix "make mandocs"

[Adrian Bunk]

On Mon, Apr 11, 2005 at 01:25:32AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.12-rc2-mm2:
>...
>  gregkh-driver.patch
>...

Due to the removal of class_simple.c, "make mandocs" no longer works.

This patch fixes this issue.

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

--- linux-2.6.12-rc2-mm3-full/Documentation/DocBook/kernel-api.tmpl.old 
2005-04-17 23:26:10.0 +0200
+++ linux-2.6.12-rc2-mm3-full/Documentation/DocBook/kernel-api.tmpl 
2005-04-17 23:26:17.0 +0200
@@ -338,7 +338,6 @@
 X!Iinclude/linux/device.h
 -->
 !Edrivers/base/driver.c
-!Edrivers/base/class_simple.c
 !Edrivers/base/core.c
 !Edrivers/base/firmware_class.c
 !Edrivers/base/transport_class.c

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] rename TEST_VERIFY_AREA to TEST_ACCESS_OK

[Jesper Juhl]

Since verify_area is deprecated and going away completely very soon now 
TEST_VERIFY_AREA is a bad name to use and should be renamed. The patch 
below renames it to TEST_ACCESS_OK which I believe is more appropriate.

Btw: I didn't find anything that actually ever defines TEST_VERIFY_AREA. 
Is this intended as a debug thing to be set by hand if needed or is it 
just some old debug stuff that no longer serves a real purpose?  I guess 
my real question is "should these actually just be removed along with the 
code they wrap instead of just being renamed?"


Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---

 arch/frv/mm/fault.c|2 +-
 arch/i386/mm/fault.c   |2 +-
 arch/m68k/mm/sun3mmu.c |2 +-
 include/asm-frv/pgtable.h  |2 +-
 include/asm-i386/pgtable.h |2 +-
 include/asm-um/pgtable.h   |2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

--- linux-2.6.12-rc2-mm3-orig/arch/frv/mm/fault.c   2005-03-02 
08:38:17.0 +0100
+++ linux-2.6.12-rc2-mm3/arch/frv/mm/fault.c2005-04-17 23:11:16.0 
+0200
@@ -134,7 +134,7 @@
default:
/* handle write to write protected page */
case ESR0_ATXC_WP_EXCEP:
-#ifdef TEST_VERIFY_AREA
+#ifdef TEST_ACCESS_OK
if (!(user_mode(__frame)))
printk("WP fault at %08lx\n", __frame->pc);
 #endif
--- linux-2.6.12-rc2-mm3-orig/arch/i386/mm/fault.c  2005-04-11 
21:20:38.0 +0200
+++ linux-2.6.12-rc2-mm3/arch/i386/mm/fault.c   2005-04-17 23:11:44.0 
+0200
@@ -317,7 +317,7 @@
write = 0;
switch (error_code & 3) {
default:/* 3: write, present */
-#ifdef TEST_VERIFY_AREA
+#ifdef TEST_ACCESS_OK
if (regs->cs == KERNEL_CS)
printk("WP fault at %08lx\n", regs->eip);
 #endif
--- linux-2.6.12-rc2-mm3-orig/arch/m68k/mm/sun3mmu.c2005-03-02 
08:37:51.0 +0100
+++ linux-2.6.12-rc2-mm3/arch/m68k/mm/sun3mmu.c 2005-04-17 23:11:56.0 
+0200
@@ -50,7 +50,7 @@
unsigned long size;
 
 
-#ifdef TEST_VERIFY_AREA
+#ifdef TEST_ACCESS_OK
wp_works_ok = 0;
 #endif
empty_zero_page = alloc_bootmem_pages(PAGE_SIZE);
--- linux-2.6.12-rc2-mm3-orig/include/asm-um/pgtable.h  2005-04-11 
21:20:56.0 +0200
+++ linux-2.6.12-rc2-mm3/include/asm-um/pgtable.h   2005-04-17 
23:12:17.0 +0200
@@ -108,7 +108,7 @@
  * it will (on an i486) warn about kernel memory accesses that are
  * done without a 'access_ok(VERIFY_WRITE,..)'
  */
-#undef TEST_VERIFY_AREA
+#undef TEST_ACCESS_OK
 
 /* page table for 0-4MB for everybody */
 extern unsigned long pg0[1024];
--- linux-2.6.12-rc2-mm3-orig/include/asm-i386/pgtable.h2005-04-11 
21:20:56.0 +0200
+++ linux-2.6.12-rc2-mm3/include/asm-i386/pgtable.h 2005-04-17 
23:12:29.0 +0200
@@ -195,7 +195,7 @@
  * it will (on an i486) warn about kernel memory accesses that are
  * done without a 'verify_area(VERIFY_WRITE,..)'
  */
-#undef TEST_VERIFY_AREA
+#undef TEST_ACCESS_OK
 
 /* The boot page tables (all created as a single array) */
 extern unsigned long pg0[];
--- linux-2.6.12-rc2-mm3-orig/include/asm-frv/pgtable.h 2005-04-11 
21:20:56.0 +0200
+++ linux-2.6.12-rc2-mm3/include/asm-frv/pgtable.h  2005-04-17 
23:12:42.0 +0200
@@ -351,7 +351,7 @@
  * Define this to warn about kernel memory accesses that are
  * done without a 'verify_area(VERIFY_WRITE,..)'
  */
-#undef TEST_VERIFY_AREA
+#undef TEST_ACCESS_OK
 
 #define pte_present(x) (pte_val(x) & _PAGE_PRESENT)
 #define pte_clear(mm,addr,xp)  do { set_pte_at(mm, addr, xp, __pte(0)); } 
while (0)


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

Re: [PATCH] fs/fcntl.c : don't test unsigned value for less than zero

[Jesper Juhl]

On Fri, 15 Apr 2005, Matthew Wilcox wrote:

> On Fri, Apr 15, 2005 at 10:03:05PM +1000, Herbert Xu wrote:
> > I suppose it could be smart and stay quiet about
> > 
> > val < 0 || val > BOUND
> > 
> > However, gcc is slow enough as it is without adding unnecessary
> > smarts like this.
> 
> It only warns with -W on, not with -Wall, so I see no compelling
> reason to fix this.

Fixing the -W warning was not the main point. The main point was simply 
that the check makes no sense at all.

>  I think the real problem here is that 'arg'
> is declared 2 pages earlier in the function prototype (aka the
> function-growth-hormone-imbalance syndrome).
> 
> There's two good ways of fixing this, adding a f_setsig() function:
> 
[...]
> or add a function that checks a variable to see if it's a valid signal number:
[...]
> 
> Looks like futex.c, ptrace.c, signal.c, sys.c and almost every
> architecture's ptrace code could easily make use of the latter, but not
> the former.  It also looks like we have a few off-by-one errors.  For
[...]
> so I'd recommend the second solution.

Thank you for your feedback, that makes a lot of sense. That should get 
rid of the pointless tests, get rid of the -W warning and get rid of the 
off-by-one errors - sounds good to me.
I'll create patches and send them along shortly.


>  But be careful not to "fix up"
> cases like:
> 
> ./kernel/exit.c:if (sig < 1 || sig > _NSIG)
> 
> where we really don't want to allow zero.
> 
I'll watch out for those.  
I can either leave them alone or re-write as one of
if (valid_signal(sig) && sig != 0)
if (valid_signal(sig) && sig > 0)
any preference?
Personally I would probably go with the 
'rewrite as  if (valid_signal(sig) && sig > 0)' one to encourage use of 
the new valid_signal() function and make usage consistent.


-- 
Jesper Juhl


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

[2.6 patch] drivers/char/keyboard.c: make a function static

[Adrian Bunk]

This patch makes a needlessly globbal function static.

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

--- linux-2.6.12-rc2-mm3-full/drivers/char/keyboard.c.old   2005-04-17 
18:10:34.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/keyboard.c   2005-04-17 
18:10:55.0 +0200
@@ -1026,7 +1026,8 @@
put_queue(vc, data);
 }
 
-void kbd_keycode(unsigned int keycode, int down, int hw_raw, struct pt_regs 
*regs)
+static void kbd_keycode(unsigned int keycode, int down,
+   int hw_raw, struct pt_regs *regs)
 {
struct vc_data *vc = vc_cons[fg_console].d;
unsigned short keysym, *key_map;



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

Re: More performance for the TCP stack by using additional hardware chip on NIC

[David S. Miller]

On Sun, 17 Apr 2005 13:29:14 +0300
Avi Kivity <[EMAIL PROTECTED]> wrote:

> TOEs can remove the data copy on receive. In some applications (notably
> storage), where the application does not touch most of the data, this is
> a significant advantage that cannot be achieved in a software-only
> solution.

You don't need to offload the TCP stack to make this case get
zero-copy behavior.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] drivers/char/rocket.c: cleanups

[Adrian Bunk]

This patch contains the following cleanups:
- make needlessly global code static
- remove the TRUE/FALSE macros

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

---

 drivers/char/rocket.c |  226 --
 drivers/char/rocket_int.h |   40 --
 2 files changed, 119 insertions(+), 147 deletions(-)

--- linux-2.6.12-rc2-mm3-full/drivers/char/rocket_int.h.old 2005-04-17 
18:21:04.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/rocket_int.h 2005-04-17 
18:26:53.0 +0200
@@ -1130,46 +1130,6 @@
 */
 #define sWriteTxByte(IO,DATA) sOutB(IO,DATA)
 
-int sInitController(CONTROLLER_T * CtlP,
-   int CtlNum,
-   ByteIO_t MudbacIO,
-   ByteIO_t * AiopIOList,
-   int AiopIOListSize,
-   int IRQNum, Byte_t Frequency, int PeriodicOnly);
-
-int sPCIInitController(CONTROLLER_T * CtlP,
-  int CtlNum,
-  ByteIO_t * AiopIOList,
-  int AiopIOListSize,
-  WordIO_t ConfigIO,
-  int IRQNum,
-  Byte_t Frequency,
-  int PeriodicOnly,
-  int altChanRingIndicator, int UPCIRingInd);
-
-int sReadAiopID(ByteIO_t io);
-int sReadAiopNumChan(WordIO_t io);
-int sInitChan(CONTROLLER_T * CtlP,
- CHANNEL_T * ChP, int AiopNum, int ChanNum);
-Byte_t sGetRxErrStatus(CHANNEL_T * ChP);
-void sStopRxProcessor(CHANNEL_T * ChP);
-void sStopSWInFlowCtl(CHANNEL_T * ChP);
-void sFlushRxFIFO(CHANNEL_T * ChP);
-void sFlushTxFIFO(CHANNEL_T * ChP);
-int sWriteTxPrioByte(CHANNEL_T * ChP, Byte_t Data);
-void sEnInterrupts(CHANNEL_T * ChP, Word_t Flags);
-void sDisInterrupts(CHANNEL_T * ChP, Word_t Flags);
-void sModemReset(CONTROLLER_T * CtlP, int chan, int on);
-void sPCIModemReset(CONTROLLER_T * CtlP, int chan, int on);
-void sSetInterfaceMode(CHANNEL_T * ChP, Byte_t mode);
-
-extern Byte_t R[RDATASIZE];
-extern CONTROLLER_T sController[CTL_SIZE];
-extern Byte_t sIRQMap[16];
-extern Byte_t sBitMapClrTbl[8];
-extern Byte_t sBitMapSetTbl[8];
-extern int sClockPrescale;
-
 /*
  * Begin Linux specific definitions for the Rocketport driver
  *
--- linux-2.6.12-rc2-mm3-full/drivers/char/rocket.c.old 2005-04-17 
18:20:10.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/rocket.c 2005-04-17 
18:45:51.0 +0200
@@ -161,6 +161,64 @@
UPCI_AIOP_INTR_BIT_3
 };
 
+static Byte_t RData[RDATASIZE] = {
+   0x00, 0x09, 0xf6, 0x82,
+   0x02, 0x09, 0x86, 0xfb,
+   0x04, 0x09, 0x00, 0x0a,
+   0x06, 0x09, 0x01, 0x0a,
+   0x08, 0x09, 0x8a, 0x13,
+   0x0a, 0x09, 0xc5, 0x11,
+   0x0c, 0x09, 0x86, 0x85,
+   0x0e, 0x09, 0x20, 0x0a,
+   0x10, 0x09, 0x21, 0x0a,
+   0x12, 0x09, 0x41, 0xff,
+   0x14, 0x09, 0x82, 0x00,
+   0x16, 0x09, 0x82, 0x7b,
+   0x18, 0x09, 0x8a, 0x7d,
+   0x1a, 0x09, 0x88, 0x81,
+   0x1c, 0x09, 0x86, 0x7a,
+   0x1e, 0x09, 0x84, 0x81,
+   0x20, 0x09, 0x82, 0x7c,
+   0x22, 0x09, 0x0a, 0x0a
+};
+
+static Byte_t RRegData[RREGDATASIZE] = {
+   0x00, 0x09, 0xf6, 0x82, /* 00: Stop Rx processor */
+   0x08, 0x09, 0x8a, 0x13, /* 04: Tx software flow control */
+   0x0a, 0x09, 0xc5, 0x11, /* 08: XON char */
+   0x0c, 0x09, 0x86, 0x85, /* 0c: XANY */
+   0x12, 0x09, 0x41, 0xff, /* 10: Rx mask char */
+   0x14, 0x09, 0x82, 0x00, /* 14: Compare/Ignore #0 */
+   0x16, 0x09, 0x82, 0x7b, /* 18: Compare #1 */
+   0x18, 0x09, 0x8a, 0x7d, /* 1c: Compare #2 */
+   0x1a, 0x09, 0x88, 0x81, /* 20: Interrupt #1 */
+   0x1c, 0x09, 0x86, 0x7a, /* 24: Ignore/Replace #1 */
+   0x1e, 0x09, 0x84, 0x81, /* 28: Interrupt #2 */
+   0x20, 0x09, 0x82, 0x7c, /* 2c: Ignore/Replace #2 */
+   0x22, 0x09, 0x0a, 0x0a  /* 30: Rx FIFO Enable */
+};
+
+static CONTROLLER_T sController[CTL_SIZE] = {
+   {-1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, {0, 0, 0, 0},
+{0, 0, 0, 0}, {-1, -1, -1, -1}, {0, 0, 0, 0}},
+   {-1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, {0, 0, 0, 0},
+{0, 0, 0, 0}, {-1, -1, -1, -1}, {0, 0, 0, 0}},
+   {-1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, {0, 0, 0, 0},
+{0, 0, 0, 0}, {-1, -1, -1, -1}, {0, 0, 0, 0}},
+   {-1, -1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, {0, 0, 0, 0},
+{0, 0, 0, 0}, {-1, -1, -1, -1}, {0, 0, 0, 0}}
+};
+
+static Byte_t sBitMapClrTbl[8] = {
+   0xfe, 0xfd, 0xfb, 0xf7, 0xef, 0xdf, 0xbf, 0x7f
+};
+
+static Byte_t sBitMapSetTbl[8] = {
+   0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80
+};
+
+static int sClockPrescale = 0x14;
+
 /*
  *  Line number is the ttySIx number (x), the Minor number.  We 
  *  assign them sequentially, starting at zero.  The following 
@@ -177,6 +235,26 @@
 static unsigned char GetLineNumber(int ctrl, int aiop, int ch);
 static unsigned char SetLineNumber(int ctrl, int aiop, int ch);
 static void rp_start(struct tty_struct *tty)

Re: [RFC: 2.6 patch] drivers/char/random.c: #if 0 randomize_range

[Matt Mackall]

On Sun, Apr 17, 2005 at 10:15:37PM +0200, Adrian Bunk wrote:
> This patch #if 0's the unused global function randomize_range.
>

This is presumably for future work in process randomization. Arjan,
what's the status of this bit?

> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
> ---
> 
>  drivers/char/random.c  |2 ++
>  include/linux/random.h |1 -
>  2 files changed, 2 insertions(+), 1 deletion(-)
> 
> --- linux-2.6.12-rc2-mm3-full/include/linux/random.h.old  2005-04-17 
> 18:17:17.0 +0200
> +++ linux-2.6.12-rc2-mm3-full/include/linux/random.h  2005-04-17 
> 18:17:23.0 +0200
> @@ -65,7 +65,6 @@
>  #endif
>  
>  unsigned int get_random_int(void);
> -unsigned long randomize_range(unsigned long start, unsigned long end, 
> unsigned long len);
>  
>  #endif /* __KERNEL___ */
>  
> --- linux-2.6.12-rc2-mm3-full/drivers/char/random.c.old   2005-04-17 
> 18:17:30.0 +0200
> +++ linux-2.6.12-rc2-mm3-full/drivers/char/random.c   2005-04-17 
> 18:18:12.0 +0200
> @@ -1618,6 +1618,7 @@
>   * a  with size "len" starting at the return value is inside in the
>   * area defined by [start, end], but is otherwise randomized.
>   */
> +#if 0
>  unsigned long
>  randomize_range(unsigned long start, unsigned long end, unsigned long len)
>  {
> @@ -1627,3 +1628,4 @@
>   return 0;
>   return PAGE_ALIGN(get_random_int() % range + start);
>  }
> +#endif  /*  0  */

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386 & x86_64: Live Patching Funcion on 2.6.11.7

[David S. Miller]

On Sun, 17 Apr 2005 14:51:43 -0400
Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:

> Takashi-san's description was not very clear, but it sounds like it's a
> patching mechanism for userspace applications - not for kernel space.
> So kprobes would not be a good fit.

I saw the presentation of this stuff at the Linux Kernel conference
last year in Tokyo.  I'm pretty sure it's for the kernel. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[no subject]

[enqhyzbm]

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

Re: kernel panic - not syncing: Fatal exception in interupt

[Shaun Reitan]

OK, finally got a full dump from the serial console!  Here is it!


---
Unable to handle kernel paging request at virtual address f8b6f02c
 printing eip:
f88b0078
*pde = 031f6067
Oops:  [#1]
SMP
Modules linked in: loop tun ebt_ip ebt_arp ebtable_filter ebtables autofs4
ipv6

bridge e1000 ohci1394 ieee1394 floppy sg parport_pc parport ext3 jbd 3w_9xxx
sd_

mod scsi_mod
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010286   (2.6.11.5-hr1)
EIP is at ebt_do_table+0x78/0x6e0 [ebtables]
eax: f8b6f000   ebx: f88b7000   ecx: f88b7080   edx: f88b7080
esi: c03e8d20   edi: c0438f08   ebp: 8000   esp: c03e8c7c
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c03e8000 task=c0333b60)
Stack: c0438dd8 8000 c0294362 f7728580 c02a9010 0003 0003
c85c6012
   f8816610 f8b6f000 f8b6f000 f8b39000  f88b7080 f88b7080
000a
   000a f6646800 c03e8d1c 0001 f8816620 c03e8d20 c0438f08
8000
Call Trace:
 [] nf_iterate+0x72/0xb0
 [] dst_output+0x0/0x20
 [] nf_iterate+0x72/0xb0
 [] br_pass_frame_up_finish+0x0/0x10 [bridge]
 [] nf_hook_slow+0x68/0xf0
 [] br_pass_frame_up_finish+0x0/0x10 [bridge]
 [] br_pass_frame_up+0x5a/0x60 [bridge]
 [] br_pass_frame_up_finish+0x0/0x10 [bridge]
 [] br_handle_frame_finish+0x79/0x110 [bridge]
 [] br_handle_frame_finish+0x0/0x110 [bridge]
 [] nf_hook_slow+0xb2/0xf0
 [] br_handle_frame_finish+0x0/0x110 [bridge]
 [] br_nf_pre_routing_finish+0xfc/0x290 [bridge]
 [] br_handle_frame_finish+0x0/0x110 [bridge]
 [] try_to_wake_up+0x220/0x250
 [] autoremove_wake_function+0x1b/0x50
 [] __wake_up_common+0x37/0x60
 [] __mod_timer+0xd6/0x120
 [] nf_iterate+0x72/0xb0
 [] br_nf_pre_routing_finish+0x0/0x290 [bridge]
 [] br_nf_pre_routing_finish+0x0/0x290 [bridge]
 [] nf_hook_slow+0xb2/0xf0
 [] br_nf_pre_routing_finish+0x0/0x290 [bridge]
 [] br_nf_pre_routing+0x257/0x410 [bridge]
 [] br_nf_pre_routing_finish+0x0/0x290 [bridge]
 [] nf_iterate+0x72/0xb0
 [] br_handle_frame_finish+0x0/0x110 [bridge]
 [] br_handle_frame_finish+0x0/0x110 [bridge]
 [] nf_hook_slow+0x68/0xf0
 [] br_handle_frame_finish+0x0/0x110 [bridge]
 [] br_handle_frame+0xfa/0x1e0 [bridge]
 [] br_handle_frame_finish+0x0/0x110 [bridge]
 [] netif_receive_skb+0x13d/0x2c0
 [] e1000_clean_rx_irq+0x15e/0x4a0 [e1000]
 [] __kfree_skb+0xa9/0x150
 [] e1000_clean+0xba/0xf0 [e1000]
 [] net_rx_action+0x6f/0x100
 [] __do_softirq+0xb9/0xd0
 [] do_softirq+0x4a/0x60
 ===
 [] do_IRQ+0x63/0xb0
 [] smp_apic_timer_interrupt+0xd0/0xe0
 [] common_interrupt+0x1a/0x20
 [] mwait_idle+0x52/0x80
 [] default_idle+0x0/0x30
 [] cpu_idle+0x5b/0x70
 [] start_kernel+0x161/0x1a0
 [] unknown_bootoption+0x0/0x1e0
Code: 00 89 54 24 34 8b 43 20 c7 44 24 2c 00 00 00 00 85 c0 74 07 8b 0c 88
89 4c

 24 2c 8b 44 24 4c 8b 4c 24 34 8b 44 83 08 89 44 24 28 <8b> 50 2c 89 c5 83
c5 30

 89 54 24 3c 8b 40 24 c1 e0 04 01 c8 89
 <0>Kernel panic - not syncing: Fatal exception in interrupt

-

--

Best Regards,

Shaun Reitan

"Zwane Mwaikambo" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Tue, 12 Apr 2005, [EMAIL PROTECTED] wrote:
>
> > The machine crashed again twice today.  I have vga=791 so i caugh a bit
more
> > of the crash.  i enabled serial redirection in the bios so i'm hoping to
> > catch the full dump next time.
>
> Cool, can you also try Cc'ing [EMAIL PROTECTED]
>
> Thanks,
> Zwane
>



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

[RFC: 2.6 patch] drivers/char/random.c: #if 0 randomize_range

[Adrian Bunk]

This patch #if 0's the unused global function randomize_range.

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

---

 drivers/char/random.c  |2 ++
 include/linux/random.h |1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

--- linux-2.6.12-rc2-mm3-full/include/linux/random.h.old2005-04-17 
18:17:17.0 +0200
+++ linux-2.6.12-rc2-mm3-full/include/linux/random.h2005-04-17 
18:17:23.0 +0200
@@ -65,7 +65,6 @@
 #endif
 
 unsigned int get_random_int(void);
-unsigned long randomize_range(unsigned long start, unsigned long end, unsigned 
long len);
 
 #endif /* __KERNEL___ */
 
--- linux-2.6.12-rc2-mm3-full/drivers/char/random.c.old 2005-04-17 
18:17:30.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/random.c 2005-04-17 
18:18:12.0 +0200
@@ -1618,6 +1618,7 @@
  * a  with size "len" starting at the return value is inside in the
  * area defined by [start, end], but is otherwise randomized.
  */
+#if 0
 unsigned long
 randomize_range(unsigned long start, unsigned long end, unsigned long len)
 {
@@ -1627,3 +1628,4 @@
return 0;
return PAGE_ALIGN(get_random_int() % range + start);
 }
+#endif  /*  0  */

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

[2.6 patch] drivers/char/rio/rio_linux.c: make a variable static

[Adrian Bunk]

This patch makes a needlessly global variable static.

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

--- linux-2.6.12-rc2-mm3-full/drivers/char/rio/rio_linux.c.old  2005-04-17 
18:18:39.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/rio/rio_linux.c  2005-04-17 
18:18:47.0 +0200
@@ -221,7 +221,7 @@
 /* Set the mask to all-ones. This alas, only supports 32 interrupts. 
Some architectures may need more. -- Changed to LONG to
support up to 64 bits on 64bit architectures. -- REW 20/06/99 */
-long rio_irqmask = -1;
+static long rio_irqmask = -1;
 
 MODULE_AUTHOR("Rogier Wolff <[EMAIL PROTECTED]>, Patrick van de Lageweg 
<[EMAIL PROTECTED]>");
 MODULE_DESCRIPTION("RIO driver");

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

Re: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2)

[Daniel Ritz]

On Friday 15 April 2005 08:43, Peter Baumann wrote:
> On Thu, Apr 14, 2005 at 07:40:52PM +0200, Daniel Ritz wrote:
> > 
> > could you apply this debuggin patch instead and send me the dmsg output
> > plus output from lspci, lspci -vvvn. also please send me a hexdump from
> > /proc/bus/pci/00/0b.0
> > 
> > i think i'm having some 3coms around so maybe i can reprocude :)
> > 
> > rgds
> > -daniel
> > 
> > --- 1.81/drivers/pci/pci.c  2005-03-03 08:17:57 +01:00
> > +++ edited/drivers/pci/pci.c2005-04-05 00:37:13 +02:00
> > @@ -268,7 +268,7 @@
> > return -EIO; 
> >  
> > pci_read_config_word(dev,pm + PCI_PM_PMC,&pmc);
> > -   if ((pmc & PCI_PM_CAP_VER_MASK) > 2) {
> > +   if ((pmc & PCI_PM_CAP_VER_MASK) > 3) {
> > printk(KERN_DEBUG
> >"PCI: %s has unsupported PM cap regs version (%u)\n",
> >pci_name(dev), pmc & PCI_PM_CAP_VER_MASK);
> > @@ -287,15 +287,19 @@
> >  * This doesn't affect PME_Status, disables PME_En, and
> >  * sets PowerState to 0.
> >  */
> > -   if (dev->current_state >= PCI_D3hot)
> > +   printk("PCI: %s pmc: %04x, current_state, pmcsr: %08x", pci_name(dev), 
> > pmc, dev->current_state);

for the record: i messed up that printk, but anyway...

> > +   if (dev->current_state >= PCI_D3hot) {
> > pmcsr = 0;
> > -   else {
> > +   printk("0");
> > +   } else {
> > pci_read_config_word(dev, pm + PCI_PM_CTRL, &pmcsr);
> > +   printk("%04x", pmcsr);
> > pmcsr &= ~PCI_PM_CTRL_STATE_MASK;
> > pmcsr |= state;
> > }
> >  
> > /* enter specified state */
> > +   printk(", new: %04x\n", pmcsr);
> > pci_write_config_word(dev, pm + PCI_PM_CTRL, pmcsr);
> >  
> > /* Mandatory power management transition delays */
> > 
> 
> I applied this one (just for the record, the offsets weren't correct for 
> 2.6.12-rc2-mm3, but it applied cleanly)

(it was against mainline, not -mm)

> 
> Attached is the info you asked for.
> 
> ...1.txt  = first boot (working)
> ...2.txt  = second boot (not working)
> 
> -Peter
> 

from your dmesg:
PCI: :00:0b.0 pmc: 7601, current_state, pmcsr: 00040, new: 
ACPI: PCI Interrupt :00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0xac00. Vers LK1.1.19
PCI: :00:0b.0 pmc: 7601, current_state, pmcsr: , new: 0003

so the device is sent to D3 right after it is up. nice.

and second boot:
PCI: :00:0b.0 pmc: 7601, current_state, pmcsr: 00040, new: 
PCI: Enabling device :00:0b.0 ( -> 0003)
ACPI: PCI Interrupt :00:0b.0[A] -> GSI 19 (level, low) -> IRQ 19
3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
:00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19
PCI: Setting latency timer of device :00:0b.0 to 64
*** EEPROM MAC address is invalid.
3c59x: vortex_probe1 fails.  Returns -22
3c59x: probe of :00:0b.0 failed with error -22

to me it looks like during the second boot the device is in D3 and has
troubles coming out of it. unfortunatley that is not made visible by the
debugging patch. a hexdump of the device in a second boot without
loading the 3c59x driver would tell us...

the diff in the hexdumps of the config space proves that the device
is programmed wrong:
--- hexdump-2.6.12-rc2-mm3-withdebugpatch_1.txt 2005-04-17 21:27:28.0 
+0200
+++ hexdump-2.6.12-rc2-mm3-withdebugpatch_2.txt 2005-04-17 21:27:32.0 
+0200
@@ -1,7 +1,7 @@
-000 10b7 9055 0007 0210 0024 0200 2008 
-010 ac01  2000 e800    
+000 10b7 9055 0003 0210 0024 0200 4000 
+010 0001       

so the I/O ports and the iomem are not set!

 020       10b7 9055
-030   00dc    010a 0a0a
+030   00dc    0100 0a0a
 040        
 050   0040     
 060        

but to make it short: i think it's a driver bug. the device doesn't seem to be
correctly reprogrammed when it is in D3 initially. and then it shouldn't be
put into D3 during the first boot. so please try with the attached patch.

rgds
-daniel

PS: does somebody have a datasheet of a 3com chip around? i could need one.

-

[PATCH] 3c59x: only put the device into D3 when we're actually using WOL

Signed-off-by: Daniel Ritz <[EMAIL PROTECTED]>

--- 1.77/drivers/net/3c59x.c2005-03-03 06:00:42 +01:00
+++ edited/drivers/net/3c59x.c  2005-04-17 22:17:19 +02:00
@@ -1581,7 +1581,8 @@
 
if (VORTEX_PCI(vp)) {
pci_set_power_state(VORTEX_PCI(vp), PCI_D0);/* Go active */
-   pci_restore_state(VORTEX_PCI(vp));
+   if (vp->pm_state_valid)
+   pci_restore_state(VORTEX_PCI(vp));

[2.6 patch] drivers/char/stallion.c: make a function static

[Adrian Bunk]

This patch makes a needlessly global function static.

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

--- linux-2.6.12-rc2-mm3-full/drivers/char/stallion.c.old   2005-04-17 
18:27:46.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/stallion.c   2005-04-17 
18:28:03.0 +0200
@@ -466,7 +466,7 @@
 
 static unsigned long stl_atol(char *str);
 
-intstl_init(void);
+static int stl_init(void);
 static int stl_open(struct tty_struct *tty, struct file *filp);
 static voidstl_close(struct tty_struct *tty, struct file *filp);
 static int stl_write(struct tty_struct *tty, const unsigned char *buf, int 
count);
@@ -3063,7 +3063,7 @@
 
 /*/
 
-int __init stl_init(void)
+static int __init stl_init(void)
 {
int i;
printk(KERN_INFO "%s: version %s\n", stl_drvtitle, stl_drvversion);

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

Re: [RFC][PATCH 4/4] AES assembler implementation for x86_64

[Andreas Steinmetz]

Adrian Bunk wrote:
> That is not specifically against this patch, but before we add another 
> AES implementation, I'd like to find a better solution for the general 
> AES selection.

That would be nice as I didn't like having to duplicate a whole Kconfig
entry which in fact means that it is triplicated now.
I'm fine with any solution here but I do believe whatever solution is
for the crypto maintainers to decide.

[snip]

>>+ depends on CRYPTO && (X86 && !X86_64)
>>+ depends on CRYPTO && X86 && !X86_64
>>...
> 
> 
> This doesn't make any difference.
> 
> I think the former version was better readable, but that's no strong 
> opinion.

This was only personal preference during development and actually you're
right, the former version is better readable.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[2.6 patch] drivers/char/tty_io.c: make a function static

[Adrian Bunk]

This patch makes a needlessly global function static.

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

---

 drivers/char/tty_io.c |5 +++--
 include/linux/tty.h   |2 --
 2 files changed, 3 insertions(+), 4 deletions(-)

--- linux-2.6.12-rc2-mm3-full/include/linux/tty.h.old   2005-04-17 
18:30:17.0 +0200
+++ linux-2.6.12-rc2-mm3-full/include/linux/tty.h   2005-04-17 
18:30:24.0 +0200
@@ -337,8 +337,6 @@
 extern void console_init(void);
 extern int vcs_init(void);
 
-extern int tty_paranoia_check(struct tty_struct *tty, struct inode *inode,
- const char *routine);
 extern char *tty_name(struct tty_struct *tty, char *buf);
 extern void tty_wait_until_sent(struct tty_struct * tty, long timeout);
 extern int tty_check_change(struct tty_struct * tty);
--- linux-2.6.12-rc2-mm3-full/drivers/char/tty_io.c.old 2005-04-17 
18:30:32.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/tty_io.c 2005-04-17 
18:30:51.0 +0200
@@ -186,8 +186,9 @@
 
 EXPORT_SYMBOL(tty_name);
 
-inline int tty_paranoia_check(struct tty_struct *tty, struct inode *inode,
- const char *routine)
+static inline int tty_paranoia_check(struct tty_struct *tty,
+struct inode *inode,
+const char *routine)
 {
 #ifdef TTY_PARANOIA_CHECK
if (!tty) {

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

[RFC: 2.6 patch] drivers/ieee1394/pcilynx.c: remove dead options

[Adrian Bunk]

The options CONFIG_IEEE1394_PCILYNX_LOCALRAM and 
CONFIG_IEEE1394_PCILYNX_PORTS are not available for some time.

Is this patch for removing them and the code behind them correct, or is 
a future usage planned?

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

---

 drivers/ieee1394/Kconfig   |5 
 drivers/ieee1394/pcilynx.c |  391 -
 drivers/ieee1394/pcilynx.h |   49 
 3 files changed, 2 insertions(+), 443 deletions(-)

--- linux-2.6.12-rc2-mm3-full/drivers/ieee1394/Kconfig.old  2005-04-17 
21:01:11.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/ieee1394/Kconfig  2005-04-17 
21:01:23.0 +0200
@@ -84,11 +84,6 @@
  To compile this driver as a module, say M here: the
  module will be called pcilynx.
 
-# Non-maintained pcilynx options
-# if [ "$CONFIG_IEEE1394_PCILYNX" != "n" ]; then
-# bool 'Use PCILynx local RAM' CONFIG_IEEE1394_PCILYNX_LOCALRAM
-# bool 'Support for non-IEEE1394 local ports' 
CONFIG_IEEE1394_PCILYNX_PORTS
-# fi
 config IEEE1394_OHCI1394
tristate "OHCI-1394 support"
depends on PCI && IEEE1394
--- linux-2.6.12-rc2-mm3-full/drivers/ieee1394/pcilynx.h.old2005-04-17 
21:01:31.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/ieee1394/pcilynx.h2005-04-17 
21:02:21.0 +0200
@@ -55,16 +55,6 @@
 void __iomem *aux_port;
quadlet_t bus_info_block[5];
 
-#ifdef CONFIG_IEEE1394_PCILYNX_PORTS
-atomic_t aux_intr_seen;
-wait_queue_head_t aux_intr_wait;
-
-void *mem_dma_buffer;
-dma_addr_t mem_dma_buffer_dma;
-struct semaphore mem_dma_mutex;
-wait_queue_head_t mem_dma_intr_wait;
-#endif
-
 /*
  * use local RAM of LOCALRAM_SIZE bytes for PCLs, which allows for
  * LOCALRAM_SIZE * 8 PCLs (each sized 128 bytes);
@@ -72,11 +62,9 @@
  */
 u8 pcl_bmap[LOCALRAM_SIZE / 1024];
 
-#ifndef CONFIG_IEEE1394_PCILYNX_LOCALRAM
/* point to PCLs memory area if needed */
void *pcl_mem;
 dma_addr_t pcl_mem_dma;
-#endif
 
 /* PCLs for local mem / aux transfers */
 pcl_t dmem_pcl;
@@ -378,39 +366,6 @@
 #define pcloffs(MEMBER) (offsetof(struct ti_pcl, MEMBER))
 
 
-#ifdef CONFIG_IEEE1394_PCILYNX_LOCALRAM
-
-static inline void put_pcl(const struct ti_lynx *lynx, pcl_t pclid,
-   const struct ti_pcl *pcl)
-{
-int i;
-u32 *in = (u32 *)pcl;
-u32 *out = (u32 *)(lynx->local_ram + pclid * sizeof(struct ti_pcl));
-
-for (i = 0; i < 32; i++, out++, in++) {
-writel(*in, out);
-}
-}
-
-static inline void get_pcl(const struct ti_lynx *lynx, pcl_t pclid,
-   struct ti_pcl *pcl)
-{
-int i;
-u32 *out = (u32 *)pcl;
-u32 *in = (u32 *)(lynx->local_ram + pclid * sizeof(struct ti_pcl));
-
-for (i = 0; i < 32; i++, out++, in++) {
-*out = readl(in);
-}
-}
-
-static inline u32 pcl_bus(const struct ti_lynx *lynx, pcl_t pclid)
-{
-return pci_resource_start(lynx->dev, 1) + pclid * sizeof(struct 
ti_pcl);
-}
-
-#else /* CONFIG_IEEE1394_PCILYNX_LOCALRAM */
-
 static inline void put_pcl(const struct ti_lynx *lynx, pcl_t pclid,
const struct ti_pcl *pcl)
 {
@@ -431,10 +386,8 @@
 return lynx->pcl_mem_dma + pclid * sizeof(struct ti_pcl);
 }
 
-#endif /* CONFIG_IEEE1394_PCILYNX_LOCALRAM */
-
 
-#if defined (CONFIG_IEEE1394_PCILYNX_LOCALRAM) || defined (__BIG_ENDIAN)
+#if defined (__BIG_ENDIAN)
 typedef struct ti_pcl pcltmp_t;
 
 static inline struct ti_pcl *edit_pcl(const struct ti_lynx *lynx, pcl_t pclid,
--- linux-2.6.12-rc2-mm3-full/drivers/ieee1394/pcilynx.c.old2005-04-17 
21:02:29.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/ieee1394/pcilynx.c2005-04-17 
21:05:02.0 +0200
@@ -834,327 +834,6 @@
  * IEEE-1394 functionality section END *
  ***/
 
-#ifdef CONFIG_IEEE1394_PCILYNX_PORTS
-/* VFS functions for local bus / aux device access.  Access to those
- * is implemented as a character device instead of block devices
- * because buffers are not wanted for this.  Therefore llseek (from
- * VFS) can be used for these char devices with obvious effects.
- */
-static int mem_open(struct inode*, struct file*);
-static int mem_release(struct inode*, struct file*);
-static unsigned int aux_poll(struct file*, struct poll_table_struct*);
-static loff_t mem_llseek(struct file*, loff_t, int);
-static ssize_t mem_read (struct file*, char*, size_t, loff_t*);
-static ssize_t mem_write(struct file*, const char*, size_t, loff_t*);
-
-
-static struct file_operations aux_ops = {
-   .owner =THIS_MODULE,
-.read = mem_read,
-.write =mem_write,
-.poll = aux_poll,
-.llseek =   mem_llseek,
-.open = mem_open,
-.release =  mem_release,
-};
-
-
-static void

[no subject]

[tayqdgqgq]

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

Re: [2.6 patch] drivers/i2c/chips/ds1337.c: #if 0 an unused function

[Jean Delvare]

Hi Adrian,

> This patch #if 0's an unused global function.

No. James and Ladislav are working on this driver.

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

[2.6 patch] drivers/char/nvram.c: possible cleanups

[Adrian Bunk]

This patch contains the following possible cleanups:
- make the needlessly global function __nvram_set_checksum static
- #if 0 the unused global function nvram_set_checksum
- remove the EXPORT_SYMBOL's for both functions

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

---

 drivers/char/nvram.c  |6 +++---
 include/linux/nvram.h |2 --
 2 files changed, 3 insertions(+), 5 deletions(-)

--- linux-2.6.12-rc2-mm3-full/include/linux/nvram.h.old 2005-04-17 
18:15:57.0 +0200
+++ linux-2.6.12-rc2-mm3-full/include/linux/nvram.h 2005-04-17 
18:16:04.0 +0200
@@ -20,8 +20,6 @@
 extern void nvram_write_byte(unsigned char c, int i);
 extern int __nvram_check_checksum(void);
 extern int nvram_check_checksum(void);
-extern void __nvram_set_checksum(void);
-extern void nvram_set_checksum(void);
 #endif
 
 #endif  /* _LINUX_NVRAM_H */
--- linux-2.6.12-rc2-mm3-full/drivers/char/nvram.c.old  2005-04-17 
18:16:10.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/nvram.c  2005-04-17 
18:16:36.0 +0200
@@ -211,12 +211,13 @@
return rv;
 }
 
-void
+static void
 __nvram_set_checksum(void)
 {
mach_set_checksum();
 }
 
+#if 0
 void
 nvram_set_checksum(void)
 {
@@ -226,6 +227,7 @@
__nvram_set_checksum();
spin_unlock_irqrestore(&rtc_lock, flags);
 }
+#endif  /*  0  */
 
 /*
  * The are the file operation function for user access to /dev/nvram
@@ -921,6 +923,4 @@
 EXPORT_SYMBOL(nvram_write_byte);
 EXPORT_SYMBOL(__nvram_check_checksum);
 EXPORT_SYMBOL(nvram_check_checksum);
-EXPORT_SYMBOL(__nvram_set_checksum);
-EXPORT_SYMBOL(nvram_set_checksum);
 MODULE_ALIAS_MISCDEV(NVRAM_MINOR);

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

[2.6 patch] drivers/char/mwave/3780i.c: cleanups

[Adrian Bunk]

This patch contains the following cleanups:
- make a needlessly global function static
- #if 0 the unused global function dsp3780I_ReadGenCfg

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

---

 drivers/char/mwave/3780i.c |6 --
 drivers/char/mwave/3780i.h |4 
 2 files changed, 4 insertions(+), 6 deletions(-)

--- linux-2.6.12-rc2-mm3-full/drivers/char/mwave/3780i.h.old2005-04-17 
18:12:29.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/mwave/3780i.h2005-04-17 
18:13:16.0 +0200
@@ -338,10 +338,6 @@
unsigned long ulMsaAddr);
 void dsp3780I_WriteMsaCfg(unsigned short usDspBaseIO,
   unsigned long ulMsaAddr, unsigned short usValue);
-void dsp3780I_WriteGenCfg(unsigned short usDspBaseIO, unsigned uIndex,
-  unsigned char ucValue);
-unsigned char dsp3780I_ReadGenCfg(unsigned short usDspBaseIO,
-  unsigned uIndex);
 int dsp3780I_GetIPCSource(unsigned short usDspBaseIO,
   unsigned short *pusIPCSource);
 
--- linux-2.6.12-rc2-mm3-full/drivers/char/mwave/3780i.c.old2005-04-17 
18:12:49.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/mwave/3780i.c2005-04-17 
18:13:33.0 +0200
@@ -107,8 +107,8 @@
spin_unlock_irqrestore(&dsp_lock, flags);
 }
 
-void dsp3780I_WriteGenCfg(unsigned short usDspBaseIO, unsigned uIndex,
-  unsigned char ucValue)
+static void dsp3780I_WriteGenCfg(unsigned short usDspBaseIO, unsigned uIndex,
+unsigned char ucValue)
 {
DSP_ISA_SLAVE_CONTROL rSlaveControl;
DSP_ISA_SLAVE_CONTROL rSlaveControl_Save;
@@ -141,6 +141,7 @@
 
 }
 
+#if 0
 unsigned char dsp3780I_ReadGenCfg(unsigned short usDspBaseIO,
   unsigned uIndex)
 {
@@ -167,6 +168,7 @@
 
return ucValue;
 }
+#endif  /*  0  */
 
 int dsp3780I_EnableDSP(DSP_3780I_CONFIG_SETTINGS * pSettings,
unsigned short *pIrqMap,

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

[2.6 patch] drivers/char/istallion.c: remove an unneeded variable

[Adrian Bunk]

This patch removes an unneeded global variable.

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

---

 drivers/char/istallion.c |3 +--
 1 files changed, 1 insertion(+), 2 deletions(-)

--- linux-2.6.12-rc2-mm3-full/drivers/char/istallion.c.old  2005-04-17 
18:05:53.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/istallion.c  2005-04-17 
18:07:32.0 +0200
@@ -407,7 +407,6 @@
 };
 
 static int stli_eisamempsize = sizeof(stli_eisamemprobeaddrs) / 
sizeof(unsigned long);
-intstli_eisaprobe = STLI_EISAPROBE;
 
 /*
  * Define the Stallion PCI vendor and device IDs.
@@ -4685,7 +4684,7 @@
 #ifdef MODULE
stli_argbrds();
 #endif
-   if (stli_eisaprobe)
+   if (STLI_EISAPROBE)
stli_findeisabrds();
 #ifdef CONFIG_PCI
stli_findpcibrds();

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

[2.6 patch] drivers/char/ip2*: cleanups

[Adrian Bunk]

This patch contains the following cleanups:
- i2cmd.c: #if 0 the unused function i2cmdUnixFlags
- i2cmd.c: make the needlessly global funciton i2cmdBaudDef static
- ip2main.c: remove dead code that wasn't reachable due to an #ifdef

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

---

 drivers/char/ip2/i2cmd.c |4 +++-
 drivers/char/ip2/i2cmd.h |   12 ++--
 drivers/char/ip2main.c   |   10 --
 3 files changed, 5 insertions(+), 21 deletions(-)

--- linux-2.6.12-rc2-mm3-full/drivers/char/ip2/i2cmd.h.old  2005-04-17 
18:04:22.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/ip2/i2cmd.h  2005-04-17 
19:08:54.0 +0200
@@ -64,16 +64,6 @@
// directly from user-level
 #define VAR 0x10// This command is of variable length!
 
-//---
-// External declarations for i2cmd.c
-//---
-// Routine to set up parameters for the "define hot-key sequence" command. 
Since
-// there is more than one parameter to assign, we must use a function rather
-// than a macro (used usually).
-//
-extern cmdSyntaxPtr i2cmdUnixFlags(USHORT iflag,USHORT cflag,USHORT lflag);
-extern cmdSyntaxPtr i2cmdBaudDef(int which, USHORT rate);
-
 // Declarations for the global arrays used to bear the commands and their
 // arguments.
 //
@@ -433,6 +423,7 @@
 #define CMD_HOT_ENAB (cmdSyntaxPtr)(ct45) // Enable Hot-key checking
 #define CMD_HOT_DSAB (cmdSyntaxPtr)(ct46) // Disable Hot-key checking
 
+#if 0
 // COMMAND 47: Send Protocol info via Unix flags:
 // iflag = Unix tty t_iflag
 // cflag = Unix tty t_cflag
@@ -441,6 +432,7 @@
 // within these flags
 //
 #define CMD_UNIX_FLAGS(iflag,cflag,lflag) i2cmdUnixFlags(iflag,cflag,lflag)
+#endif  /*  0  */
 
 #define CMD_DSRFL_ENAB  (cmdSyntaxPtr)(ct48) // Enable  DSR receiver ctrl
 #define CMD_DSRFL_DSAB  (cmdSyntaxPtr)(ct49) // Disable DSR receiver ctrl
--- linux-2.6.12-rc2-mm3-full/drivers/char/ip2/i2cmd.c.old  2005-04-17 
18:04:42.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/ip2/i2cmd.c  2005-04-17 
19:09:27.0 +0200
@@ -162,6 +162,7 @@
 // This routine sets the parameters of command 47 and returns a pointer to the
 // appropriate structure.
 
//**
+#if 0
 cmdSyntaxPtr
 i2cmdUnixFlags(unsigned short iflag,unsigned short cflag,unsigned short lflag)
 {
@@ -175,6 +176,7 @@
pCM->cmd[6] = (unsigned char) (lflag >> 8);
return pCM;
 }
+#endif  /*  0  */
 
 
//**
 // Function:   i2cmdBaudDef(which, rate)
@@ -187,7 +189,7 @@
 // This routine sets the parameters of commands 54 or 55 (according to the
 // argument which), and returns a pointer to the appropriate structure.
 
//**
-cmdSyntaxPtr
+static cmdSyntaxPtr
 i2cmdBaudDef(int which, unsigned short rate)
 {
cmdSyntaxPtr pCM;
--- linux-2.6.12-rc2-mm3-full/drivers/char/ip2main.c.old2005-04-17 
19:09:40.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/ip2main.c2005-04-17 
19:09:53.0 +0200
@@ -2691,16 +2691,6 @@
pCh->flags  |= ASYNC_CHECK_CD;
}
 
-#ifdef XXX
-do_flags_thing:// This is a test, we don't do the flags thing
-   
-   if ( (cflag & CRTSCTS) ) {
-   cflag |= 0140;
-   }
-   i2QueueCommands(PTYPE_BYPASS, pCh, 100, 1, 
-   CMD_UNIX_FLAGS(iflag,cflag,lflag));
-#endif
-   
 service_it:
i2DrainOutput( pCh, 100 );  
 }

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

[2.6 patch] drivers/ide/: possible cleanups

[Adrian Bunk]

This patch contains the following possible cleanups:
- pci/cy82c693.c: make a needlessly global function statix
- remove the following unneeded EXPORT_SYMBOL's:
  - ide-taskfile.c: do_rw_taskfile
  - ide-iops.c: default_hwif_iops
  - ide-iops.c: default_hwif_transport
  - ide-iops.c: wait_for_ready

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

---

 drivers/ide/ide-iops.c |6 --
 drivers/ide/ide-taskfile.c |2 --
 drivers/ide/pci/cy82c693.c |2 +-
 3 files changed, 1 insertion(+), 9 deletions(-)

--- linux-2.6.11-rc3-mm1-full/drivers/ide/ide-taskfile.c.old2005-02-05 
02:57:03.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/ide/ide-taskfile.c2005-02-05 
02:57:12.0 +0100
@@ -161,8 +161,6 @@
return ide_stopped;
 }
 
-EXPORT_SYMBOL(do_rw_taskfile);
-
 /*
  * set_multmode_intr() is invoked on completion of a WIN_SETMULT cmd.
  */

--- linux-2.6.12-rc2-mm3-full/drivers/ide/pci/cy82c693.c.old2005-04-17 
21:11:22.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/ide/pci/cy82c693.c2005-04-17 
21:11:30.0 +0200
@@ -469,7 +469,7 @@
 
 static __initdata ide_hwif_t *primary;
 
-void __init init_iops_cy82c693(ide_hwif_t *hwif)
+static void __init init_iops_cy82c693(ide_hwif_t *hwif)
 {
if (PCI_FUNC(hwif->pci_dev->devfn) == 1)
primary = hwif;
--- linux-2.6.12-rc2-mm3-full/drivers/ide/ide-iops.c.old2005-04-17 
21:12:44.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/ide/ide-iops.c2005-04-17 
21:12:54.0 +0200
@@ -104,8 +104,6 @@
hwif->INSL  = ide_insl;
 }
 
-EXPORT_SYMBOL(default_hwif_iops);
-
 /*
  * MMIO operations, typically used for SATA controllers
  */
@@ -329,8 +327,6 @@
hwif->atapi_output_bytes= atapi_output_bytes;
 }
 
-EXPORT_SYMBOL(default_hwif_transport);
-
 /*
  * Beginning of Taskfile OPCODE Library and feature sets.
  */
@@ -525,8 +525,6 @@
return 0;
 }
 
-EXPORT_SYMBOL(wait_for_ready);
-
 /*
  * This routine busy-waits for the drive status to be not "busy".
  * It then checks the status for all of the "good" bits and none

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

[2.6 patch] drivers/i2c/chips/ds1337.c: #if 0 an unused function

[Adrian Bunk]

This patch #if 0's an unused global function.

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

--- linux-2.6.12-rc2-mm3-full/drivers/i2c/chips/ds1337.c.old2005-04-17 
18:32:54.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/i2c/chips/ds1337.c2005-04-17 
18:33:16.0 +0200
@@ -228,6 +228,7 @@
  * Public API for access to specific device. Useful for low-level
  * RTC access from kernel code.
  */
+#if 0
 int ds1337_do_command(int id, int cmd, void *arg)
 {
struct list_head *walk;
@@ -242,6 +243,7 @@
 
return -ENODEV;
 }
+#endif  /*  0  */
 
 static int ds1337_attach_adapter(struct i2c_adapter *adapter)
 {

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

[2.6 patch] drivers/cpufreq/cpufreq_ondemand.c: make cpufreq_gov_dbs static

[Adrian Bunk]

This patch makes a needlessly global and EXPORT_SYMBOL'ed struct static.

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

--- linux-2.6.12-rc2-mm3-full/drivers/cpufreq/cpufreq_ondemand.c.old
2005-04-17 18:32:10.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/cpufreq/cpufreq_ondemand.c
2005-04-17 18:32:19.0 +0200
@@ -459,12 +459,11 @@
return 0;
 }
 
-struct cpufreq_governor cpufreq_gov_dbs = {
+static struct cpufreq_governor cpufreq_gov_dbs = {
.name   = "ondemand",
.governor   = cpufreq_governor_dbs,
.owner  = THIS_MODULE,
 };
-EXPORT_SYMBOL(cpufreq_gov_dbs);
 
 static int __init cpufreq_gov_dbs_init(void)
 {

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

[2.6 patch] drivers/char/agp/: make code static

[Adrian Bunk]

This patch makes some needlessly global code static.

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

---

 drivers/char/agp/ali-agp.c  |4 ++--
 drivers/char/agp/amd-k7-agp.c   |2 +-
 drivers/char/agp/amd64-agp.c|2 +-
 drivers/char/agp/ati-agp.c  |2 +-
 drivers/char/agp/backend.c  |4 ++--
 drivers/char/agp/efficeon-agp.c |2 +-
 drivers/char/agp/frontend.c |6 +++---
 drivers/char/agp/nvidia-agp.c   |2 +-
 drivers/char/agp/sis-agp.c  |2 +-
 drivers/char/agp/sworks-agp.c   |2 +-
 drivers/char/agp/via-agp.c  |4 ++--
 11 files changed, 16 insertions(+), 16 deletions(-)

--- linux-2.6.12-rc2-mm3-full/drivers/char/agp/ali-agp.c.old2005-04-17 
17:53:35.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/agp/ali-agp.c2005-04-17 
17:53:49.0 +0200
@@ -192,7 +192,7 @@
{4, 1024, 0, 3}
 };
 
-struct agp_bridge_driver ali_generic_bridge = {
+static struct agp_bridge_driver ali_generic_bridge = {
.owner  = THIS_MODULE,
.aperture_sizes = ali_generic_sizes,
.size_type  = U32_APER_SIZE,
@@ -215,7 +215,7 @@
.agp_destroy_page   = ali_destroy_page,
 };
 
-struct agp_bridge_driver ali_m1541_bridge = {
+static struct agp_bridge_driver ali_m1541_bridge = {
.owner  = THIS_MODULE,
.aperture_sizes = ali_generic_sizes,
.size_type  = U32_APER_SIZE,
--- linux-2.6.12-rc2-mm3-full/drivers/char/agp/amd-k7-agp.c.old 2005-04-17 
17:53:58.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/agp/amd-k7-agp.c 2005-04-17 
17:54:08.0 +0200
@@ -358,7 +358,7 @@
{.mask = 1, .type = 0}
 };
 
-struct agp_bridge_driver amd_irongate_driver = {
+static struct agp_bridge_driver amd_irongate_driver = {
.owner  = THIS_MODULE,
.aperture_sizes = amd_irongate_sizes,
.size_type  = LVL2_APER_SIZE,
--- linux-2.6.12-rc2-mm3-full/drivers/char/agp/amd64-agp.c.old  2005-04-17 
17:54:26.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/agp/amd64-agp.c  2005-04-17 
17:54:35.0 +0200
@@ -243,7 +243,7 @@
 }
 
 
-struct agp_bridge_driver amd_8151_driver = {
+static struct agp_bridge_driver amd_8151_driver = {
.owner  = THIS_MODULE,
.aperture_sizes = amd_8151_sizes,
.size_type  = U32_APER_SIZE,
--- linux-2.6.12-rc2-mm3-full/drivers/char/agp/ati-agp.c.old2005-04-17 
17:54:43.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/agp/ati-agp.c2005-04-17 
17:54:51.0 +0200
@@ -393,7 +393,7 @@
return 0;
 }
 
-struct agp_bridge_driver ati_generic_bridge = {
+static struct agp_bridge_driver ati_generic_bridge = {
.owner  = THIS_MODULE,
.aperture_sizes = ati_generic_sizes,
.size_type  = LVL2_APER_SIZE,
--- linux-2.6.12-rc2-mm3-full/drivers/char/agp/backend.c.old2005-04-17 
17:55:00.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/agp/backend.c2005-04-17 
17:55:24.0 +0200
@@ -97,7 +97,7 @@
 EXPORT_SYMBOL(agp_backend_release);
 
 
-struct { int mem, agp; } maxes_table[] = {
+static struct { int mem, agp; } maxes_table[] = {
{0, 0},
{32, 4},
{64, 28},
@@ -322,7 +322,7 @@
return 0;
 }
 
-void __exit agp_exit(void)
+static void __exit agp_exit(void)
 {
 }
 
--- linux-2.6.12-rc2-mm3-full/drivers/char/agp/efficeon-agp.c.old   
2005-04-17 17:55:31.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/agp/efficeon-agp.c   2005-04-17 
17:55:47.0 +0200
@@ -303,7 +303,7 @@
 }
 
 
-struct agp_bridge_driver efficeon_driver = {
+static struct agp_bridge_driver efficeon_driver = {
.owner  = THIS_MODULE,
.aperture_sizes = efficeon_generic_sizes,
.size_type  = LVL2_APER_SIZE,
--- linux-2.6.12-rc2-mm3-full/drivers/char/agp/frontend.c.old   2005-04-17 
17:55:56.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/char/agp/frontend.c   2005-04-17 
17:56:18.0 +0200
@@ -235,7 +235,7 @@
 
 /* File private list routines */
 
-struct agp_file_private *agp_find_private(pid_t pid)
+static struct agp_file_private *agp_find_private(pid_t pid)
 {
struct agp_file_private *curr;
 
@@ -250,7 +250,7 @@
return NULL;
 }
 
-void agp_insert_file_private(struct agp_file_private * priv)
+static void agp_insert_file_private(struct agp_file_private * priv)
 {
struct agp_file_private *prev;
 
@@ -262,7 +262,7 @@
agp_fe.file_priv_list = priv;
 }
 
-void agp_remove_file_private(struct agp_file_private * priv)
+static void agp_remove_file_private(struct agp_file_private * priv)
 {
struct agp_file_private *next;
struct agp_file_private *prev;
--- linux-2.6.12-rc2-mm3-full/drivers/char/agp/nvidia-agp.c.old 2005-04-17 
17:56:36.0 +0200
++

Re: [RFC] FUSE permission modell (Was: fuse review bits)

[Eric Van Hensbergen]

On 4/17/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> > >
> > >   1) Only allow mount over a directory for which the user has write
> > >  access (and is not sticky)
> > >
> > >   2) Use nosuid,nodev mount options
> > >
> > > [ parts deleted ]
> >
> > Do these solve all the security concerns with unprivileged mounts, or
> > are there other barriers/concerns?  Should there be ulimit (or rlimit)
> > style restrictions on how many mounts/binds a user is allowed to have
> > to prevent users from abusing mount privs?
> 
> Currently there is a (configurable) global limit for all non-root FUSE
> mounts.  An additional per-user limit would be nice, but from the
> security standpoint it doesn't matter.
> 
> > I was thinking about this a while back and thought having a user-mount
> > permissions file might be the right way to address lots of these
> > issues.  Essentially it would contain information about what
> > users/groups were allowed to mount what sources to what destinations
> > and with what mandatory options.
> 
> I haven't yet seen the need for such a great flexibility.  Debian
> installs fusermount (the FUSE mount utility) "-rwsr-x--- root fuse",

These are both well and good, but I was looking for a more global
system (for things other than FUSE).

> 
> > Is this unnecessary?  Is this not enough?
> 
> Maybe it is necessary, but why bother until somebody actually wants
> it?  I'm a great believer of the "lazy" development philosophy ;)
> 

Yeah, I guess I'm motivated in that I want to use normal mount to
handle v9fs user file systems, local private mounts, and local private
resource shares.  I'd also like normal users to be able to take better
advantage of -o bind.  I think its kinda silly that we have special
purpose mounts for cifs, samba, fuse, v9fs, etc -- but I suppose
that's more of a user-space util-linux dilemma than a kernel dilemma.

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

[2.6 patch] drivers/ieee1394/: remove unneeded EXPORT_SYMBOL's

[Adrian Bunk]

This patch removes unneeded EXPORT_SYMBOL's.

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

---

 drivers/ieee1394/ieee1394_core.c |   16 
 1 files changed, 16 deletions(-)

--- linux-2.6.12-rc2-mm3-full/drivers/ieee1394/ieee1394_core.c.old  
2005-04-17 20:49:31.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/ieee1394/ieee1394_core.c  2005-04-17 
20:57:34.0 +0200
@@ -1225,9 +1225,7 @@
 EXPORT_SYMBOL(hpsb_set_packet_complete_task);
 EXPORT_SYMBOL(hpsb_alloc_packet);
 EXPORT_SYMBOL(hpsb_free_packet);
-EXPORT_SYMBOL(hpsb_send_phy_config);
 EXPORT_SYMBOL(hpsb_send_packet);
-EXPORT_SYMBOL(hpsb_send_packet_and_wait);
 EXPORT_SYMBOL(hpsb_reset_bus);
 EXPORT_SYMBOL(hpsb_bus_reset);
 EXPORT_SYMBOL(hpsb_selfid_received);
@@ -1246,9 +1244,6 @@
 EXPORT_SYMBOL(hpsb_make_lock64packet);
 EXPORT_SYMBOL(hpsb_make_phypacket);
 EXPORT_SYMBOL(hpsb_make_isopacket);
-EXPORT_SYMBOL(hpsb_read);
-EXPORT_SYMBOL(hpsb_write);
-EXPORT_SYMBOL(hpsb_lock);
 EXPORT_SYMBOL(hpsb_packet_success);
 
 /** highlevel.c **/
@@ -1265,8 +1260,6 @@
 EXPORT_SYMBOL(hpsb_set_hostinfo_key);
 EXPORT_SYMBOL(hpsb_get_hostinfo_bykey);
 EXPORT_SYMBOL(hpsb_set_hostinfo);
-EXPORT_SYMBOL(highlevel_add_host);
-EXPORT_SYMBOL(highlevel_remove_host);
 EXPORT_SYMBOL(highlevel_host_reset);
 
 /** nodemgr.c **/
@@ -1275,7 +1268,6 @@
 EXPORT_SYMBOL(hpsb_register_protocol);
 EXPORT_SYMBOL(hpsb_unregister_protocol);
 EXPORT_SYMBOL(ieee1394_bus_type);
-EXPORT_SYMBOL(nodemgr_for_each_host);
 
 /** csr.c **/
 EXPORT_SYMBOL(hpsb_update_config_rom);
@@ -1312,19 +1304,11 @@
 EXPORT_SYMBOL(hpsb_iso_recv_flush);
 
 /** csr1212.c **/
-EXPORT_SYMBOL(csr1212_create_csr);
-EXPORT_SYMBOL(csr1212_init_local_csr);
-EXPORT_SYMBOL(csr1212_new_immediate);
 EXPORT_SYMBOL(csr1212_new_directory);
-EXPORT_SYMBOL(csr1212_associate_keyval);
 EXPORT_SYMBOL(csr1212_attach_keyval_to_directory);
-EXPORT_SYMBOL(csr1212_new_string_descriptor_leaf);
 EXPORT_SYMBOL(csr1212_detach_keyval_from_directory);
 EXPORT_SYMBOL(csr1212_release_keyval);
-EXPORT_SYMBOL(csr1212_destroy_csr);
 EXPORT_SYMBOL(csr1212_read);
-EXPORT_SYMBOL(csr1212_generate_csr_image);
 EXPORT_SYMBOL(csr1212_parse_keyval);
-EXPORT_SYMBOL(csr1212_parse_csr);
 EXPORT_SYMBOL(_csr1212_read_keyval);
 EXPORT_SYMBOL(_csr1212_destroy_keyval);

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

Re: [RFC][PATCH 4/4] AES assembler implementation for x86_64

[Adrian Bunk]

On Sun, Apr 17, 2005 at 09:20:21PM +0200, Andreas Steinmetz wrote:

> The attached patch contains the required changes for the crypto Kconfig
> to enable the usage of the x86_64 AES assembler implementation.


That is not specifically against this patch, but before we add another 
AES implementation, I'd like to find a better solution for the general 
AES selection.

My original thoughts on this issue are in [1], but this didn't attack 
the problem of CRYPTO_DEV_PADLOCK_AES where it might not be known at 
compile time whether the hardware will be present.


> Andreas Steinmetz

> diff -rNu linux-2.6.11.2.orig/crypto/Kconfig linux-2.6.11.2/crypto/Kconfig
> --- linux-2.6.11.2.orig/crypto/Kconfig2005-03-09 09:12:53.0 
> +0100
> +++ linux-2.6.11.2/crypto/Kconfig 2005-04-17 13:10:51.0 +0200
>...
>  config CRYPTO_AES_586
>   tristate "AES cipher algorithms (i586)"
> - depends on CRYPTO && (X86 && !X86_64)
> + depends on CRYPTO && X86 && !X86_64
>...

This doesn't make any difference.

I think the former version was better readable, but that's no strong 
opinion.

cu
Adrian

[1] http://www.ussg.iu.edu/hypermail/linux/kernel/0502.3/0518.html

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

Re: "swap_free: Unused swap offset entry 00000100" but no crash?

[Marcin Owsiany]

On Tue, Jul 27, 2004 at 03:58:59PM -0300, Marcelo Tosatti wrote:
> On Tue, Jul 27, 2004 at 07:53:04AM -0500, Robin Holt wrote:
> > Marcin, you have a process with a Page Table Entry which indicates it is
> > pointing to a page which has been swapped out to block 0 of swap device
> > 256.  This is probably caused by a problem in the kernel.  You can certainly
> > run memtest et al.  If you don't find anything, I would assume the problem
> > is in the kernel.
> 
> Marcin, please run the memtest86 and report back.

Finally I was able to take the machine down and test its memory. Indeed
one of the modules was faulty (the very first run of memtest revealed
it).

thanks,

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

Re: Why Ext2/3 needs immutable attribute?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Yes. I know,  with immutable,  even root cannot modify sensitive
> files. What I am curious is if an intruder has root access, he may
> have many ways to turn off the immutable protection and modify files. 

If you secure your system correctly (i.e make /dev/*mem imutable, disalow
module loading, restrict io... (and I admit it is quite complicated to find
all holes and secure it correctly without additional ptches like SELinux))
then even root cant gt arround immutable or append only (without rebooting).

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

Re: Why Ext2/3 needs immutable attribute?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> Why not simply unset the write bit for all three groups of users? 
> That seems to be enough to prevent file modification.

# touch test
# chmod a-w test
# echo test > test
# cat test
test

Because this does not protect against writes from root and it does not
protect against root setting the flags again.

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

Re: More performance for the TCP stack by using additional hardware chip on NIC

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> maybe one day you would be able to offload your firewall and policy
> router too :)

There are quite a few filtering NICs out there.

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

Reading kmem

[Catalin Patulea]

Hello,
I'm having trouble reading from /dev/kmem in Linux 2.4.22 and 2.4.25. I 
have written some code available at 
http://vv.carleton.ca/~cat/misc/readidt.c. The behavior on both kernel 
versions is the following:

# ./readidt
idt: 0xe000 + 0x07ff
pointer at 0xe400
read: 0
As read returns 0, it seems as if it's reading past the end of file. 
However, the IDT must be present in the kernel's virtual memory. Also, 
looking at 2.4.20's read_kmem() (drivers/char/mem.c:215), I don't see how 
the function could return 0 unless count was 0.

It would be great if follow-ups could be CC'ed to my e-mail address.
Thank you very much for your time,
Catalin
-
Catalin Patulea   VV Volunteer 2002,3
http://vv.carleton.ca/~cat/VV HI 2004
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH 3/4] AES assembler implementation for x86_64

[Andreas Steinmetz]

The attached patch contains the x86_64 arch specific Makefile stuff.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
diff -rNu linux-2.6.11.2.orig/arch/x86_64/Makefile 
linux-2.6.11.2/arch/x86_64/Makefile
--- linux-2.6.11.2.orig/arch/x86_64/Makefile2005-03-09 09:12:47.0 
+0100
+++ linux-2.6.11.2/arch/x86_64/Makefile 2005-04-17 13:05:04.0 +0200
@@ -65,7 +65,8 @@
 head-y := arch/x86_64/kernel/head.o arch/x86_64/kernel/head64.o 
arch/x86_64/kernel/init_task.o
 
 libs-y += arch/x86_64/lib/
-core-y += arch/x86_64/kernel/ arch/x86_64/mm/
+core-y += arch/x86_64/kernel/ arch/x86_64/mm/ \
+  arch/x86_64/crypto/
 core-$(CONFIG_IA32_EMULATION)  += arch/x86_64/ia32/
 drivers-$(CONFIG_PCI)  += arch/x86_64/pci/
 drivers-$(CONFIG_OPROFILE) += arch/x86_64/oprofile/
diff -rNu linux-2.6.11.2.orig/arch/x86_64/crypto/Makefile 
linux-2.6.11.2/arch/x86_64/crypto/Makefile
--- linux-2.6.11.2.orig/arch/x86_64/crypto/Makefile 1970-01-01 
01:00:00.0 +0100
+++ linux-2.6.11.2/arch/x86_64/crypto/Makefile  2005-04-17 13:02:00.0 
+0200
@@ -0,0 +1,9 @@
+# 
+# x86_64/crypto/Makefile 
+# 
+# Arch-specific CryptoAPI modules.
+# 
+
+obj-$(CONFIG_CRYPTO_AES_X86_64) += aes-x86_64.o
+
+aes-x86_64-y := aes-x86_64-asm.o aes.o

[RFC][PATCH 4/4] AES assembler implementation for x86_64

[Andreas Steinmetz]

The attached patch contains the required changes for the crypto Kconfig
to enable the usage of the x86_64 AES assembler implementation.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
diff -rNu linux-2.6.11.2.orig/crypto/Kconfig linux-2.6.11.2/crypto/Kconfig
--- linux-2.6.11.2.orig/crypto/Kconfig  2005-03-09 09:12:53.0 +0100
+++ linux-2.6.11.2/crypto/Kconfig   2005-04-17 13:10:51.0 +0200
@@ -133,7 +133,7 @@
 
 config CRYPTO_AES
tristate "AES cipher algorithms"
-   depends on CRYPTO && !(X86 && !X86_64)
+   depends on CRYPTO && !X86 && !X86_64
help
  AES cipher algorithms (FIPS-197). AES uses the Rijndael 
  algorithm.
@@ -153,7 +153,27 @@
 
 config CRYPTO_AES_586
tristate "AES cipher algorithms (i586)"
-   depends on CRYPTO && (X86 && !X86_64)
+   depends on CRYPTO && X86 && !X86_64
+   help
+ AES cipher algorithms (FIPS-197). AES uses the Rijndael 
+ algorithm.
+
+ Rijndael appears to be consistently a very good performer in
+ both hardware and software across a wide range of computing 
+ environments regardless of its use in feedback or non-feedback 
+ modes. Its key setup time is excellent, and its key agility is 
+ good. Rijndael's very low memory requirements make it very well 
+ suited for restricted-space environments, in which it also 
+ demonstrates excellent performance. Rijndael's operations are 
+ among the easiest to defend against power and timing attacks. 
+
+ The AES specifies three key sizes: 128, 192 and 256 bits
+
+ See  for more information.
+
+config CRYPTO_AES_X86_64
+   tristate "AES cipher algorithms (x86_64)"
+   depends on CRYPTO && X86 && X86_64
help
  AES cipher algorithms (FIPS-197). AES uses the Rijndael 
  algorithm.

[RFC][PATCH 2/4] AES assembler implementation for x86_64

[Andreas Steinmetz]

The attached patch contains Gladman's in-kernel code for key schedule
and table generation modified to fit to my assembler implementation,
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
diff -rNu linux-2.6.11.2.orig/arch/x86_64/crypto/aes.c 
linux-2.6.11.2/arch/x86_64/crypto/aes.c
--- linux-2.6.11.2.orig/arch/x86_64/crypto/aes.c1970-01-01 
01:00:00.0 +0100
+++ linux-2.6.11.2/arch/x86_64/crypto/aes.c 2005-04-17 13:34:17.0 
+0200
@@ -0,0 +1,332 @@
+/* 
+ * Cryptographic API.
+ *
+ * AES Cipher Algorithm.
+ *
+ * Based on Brian Gladman's code.
+ *
+ * Linux developers:
+ *  Alexander Kjeldaas <[EMAIL PROTECTED]>
+ *  Herbert Valerio Riedel <[EMAIL PROTECTED]>
+ *  Kyle McMartin <[EMAIL PROTECTED]>
+ *  Adam J. Richter <[EMAIL PROTECTED]> (conversion to 2.5 API).
+ *  Andreas Steinmetz <[EMAIL PROTECTED]> (adapted to x86_64 assembler)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * ---
+ * Copyright (c) 2002, Dr Brian Gladman <[EMAIL PROTECTED]>, Worcester, UK.
+ * All rights reserved.
+ *
+ * LICENSE TERMS
+ *
+ * The free distribution and use of this software in both source and binary
+ * form is allowed (with or without changes) provided that:
+ *
+ *   1. distributions of this source code include the above copyright
+ *  notice, this list of conditions and the following disclaimer;
+ *
+ *   2. distributions in binary form include the above copyright
+ *  notice, this list of conditions and the following disclaimer
+ *  in the documentation and/or other associated materials;
+ *
+ *   3. the copyright holder's name is not used to endorse products
+ *  built using this software without specific written permission.
+ *
+ * ALTERNATIVELY, provided that this notice is retained in full, this product
+ * may be distributed under the terms of the GNU General Public License (GPL),
+ * in which case the provisions of the GPL apply INSTEAD OF those given above.
+ *
+ * DISCLAIMER
+ *
+ * This software is provided 'as is' with no explicit or implied warranties
+ * in respect of its properties, including, but not limited to, correctness
+ * and/or fitness for purpose.
+ * ---
+ */
+
+/* Some changes from the Gladman version:
+s/RIJNDAEL(e_key)/E_KEY/g
+s/RIJNDAEL(d_key)/D_KEY/g
+*/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define AES_MIN_KEY_SIZE   16
+#define AES_MAX_KEY_SIZE   32
+
+#define AES_BLOCK_SIZE 16
+
+/*
+ * #define byte(x, nr) ((unsigned char)((x) >> (nr*8))) 
+ */
+inline static u8
+byte(const u32 x, const unsigned n)
+{
+   return x >> (n << 3);
+}
+
+#define u32_in(x) le32_to_cpu(*(const u32 *)(x))
+
+struct aes_ctx {
+   u32 key_length;
+   u32 E[60];
+   u32 D[60];
+};
+
+#define E_KEY ctx->E
+#define D_KEY ctx->D
+
+static u8 pow_tab[256] __initdata;
+static u8 log_tab[256] __initdata;
+static u8 sbx_tab[256] __initdata;
+static u8 isb_tab[256] __initdata;
+static u32 rco_tab[10];
+u32 aes_ft_tab[4][256];
+u32 aes_it_tab[4][256];
+
+u32 aes_fl_tab[4][256];
+u32 aes_il_tab[4][256];
+
+static inline u32 __init rol32(u32 word, unsigned int shift)
+{
+   return (word << shift) | (word >> (32 - shift));
+}
+
+static inline u32 ror32(u32 word, unsigned int shift)
+{
+   return (word >> shift) | (word << (32 - shift));
+}
+
+static inline u8 __init
+f_mult (u8 a, u8 b)
+{
+   u8 aa = log_tab[a], cc = aa + log_tab[b];
+
+   return pow_tab[cc + (cc < aa ? 1 : 0)];
+}
+
+#define ff_mult(a,b)(a && b ? f_mult(a, b) : 0)
+
+#define ls_box(x)  \
+( aes_fl_tab[0][byte(x, 0)] ^  \
+  aes_fl_tab[1][byte(x, 1)] ^  \
+  aes_fl_tab[2][byte(x, 2)] ^  \
+  aes_fl_tab[3][byte(x, 3)] )
+
+void __init
+gen_tabs (void)
+{
+   u32 i, t;
+   u8 p, q;
+
+   /* log and power tables for GF(2**8) finite field with
+  0x011b as modular polynomial - the simplest primitive
+  root is 0x03, used here to generate the tables */
+
+   for (i = 0, p = 1; i < 256; ++i) {
+   pow_tab[i] = (u8) p;
+   log_tab[p] = (u8) i;
+
+   p ^= (p << 1) ^ (p & 0x80 ? 0x01b : 0);
+   }
+
+   log_tab[1] = 0;
+
+   for (i = 0, p = 1; i < 10; ++i) {
+   rco_tab[i] = p;
+
+   p = (p << 1) ^ (p & 0x80 ? 0x01b : 0);
+   }
+
+   for (i = 0; i < 256; ++i) {
+   p = (i ? pow_tab[255 - log_tab[i]] : 0);
+   q = ((p >> 7) | (p << 1)) ^ ((p >> 6) | (p << 2));
+   p ^= 0x63 ^ q ^ ((q >> 6) | (q << 2));
+   sbx_tab[i

[RFC][PATCH 1/4] AES assembler implementation for x86_64

[Andreas Steinmetz]

The attached patch contains my AES assembler implementation for x86_64.
This includes only encrypt/decrypt as Gladman's in-kernel code is used
for key schedule and table generation.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
diff -rNu linux-2.6.11.2.orig/arch/x86_64/crypto/aes-x86_64-asm.S 
linux-2.6.11.2/arch/x86_64/crypto/aes-x86_64-asm.S
--- linux-2.6.11.2.orig/arch/x86_64/crypto/aes-x86_64-asm.S 1970-01-01 
01:00:00.0 +0100
+++ linux-2.6.11.2/arch/x86_64/crypto/aes-x86_64-asm.S  2005-04-17 
12:56:05.0 +0200
@@ -0,0 +1,186 @@
+/* AES (Rijndael) implementation (FIPS PUB 197) for x86_64
+ *
+ * Copyright (C) 2005 Andreas Steinmetz, <[EMAIL PROTECTED]>
+ *
+ * License:
+ * This code can be distributed under the terms of the GNU General Public
+ * License (GPL) Version 2 provided that the above header down to and
+ * including this sentence is retained in full.
+ */
+
+.extern aes_ft_tab
+.extern aes_it_tab
+.extern aes_fl_tab
+.extern aes_il_tab
+
+.text
+
+#define R1 %rax
+#define R1E%eax
+#define R1X%ax
+#define R1H%ah
+#define R1L%al
+#define R2 %rbx
+#define R2E%ebx
+#define R2X%bx
+#define R2H%bh
+#define R2L%bl
+#define R3 %rcx
+#define R3E%ecx
+#define R3X%cx
+#define R3H%ch
+#define R3L%cl
+#define R4 %rdx
+#define R4E%edx
+#define R4X%dx
+#define R4H%dh
+#define R4L%dl
+#define R5 %rsi
+#define R5E%esi
+#define R6 %rdi
+#define R6E%edi
+#define R7 %rbp
+#define R7E%ebp
+#define R8 %r8
+#define R9 %r9
+#define R10%r10
+#define R11%r11
+
+#define prologue(FUNC,BASE,B128,B192,r1,r2,r3,r4,r5,r6,r7,r8,r9,r10,r11) \
+   .global FUNC;   \
+   .type   FUNC,@function; \
+   .align  8;  \
+FUNC:  movqr1,r2;  \
+   movqr3,r4;  \
+   leaqBASE+52(r8),r9; \
+   movqr10,r11;\
+   movl(r7),r5 ## E;   \
+   movl4(r7),r1 ## E;  \
+   movl8(r7),r6 ## E;  \
+   movl12(r7),r7 ## E; \
+   movl(r8),r10 ## E;  \
+   xorl-48(r9),r5 ## E;\
+   xorl-44(r9),r1 ## E;\
+   xorl-40(r9),r6 ## E;\
+   xorl-36(r9),r7 ## E;\
+   cmpl$24,r10 ## E;   \
+   jb  B128;   \
+   leaq32(r9),r9;  \
+   je  B192;   \
+   leaq32(r9),r9;
+
+#define epilogue(r1,r2,r3,r4,r5,r6,r7,r8,r9) \
+   movqr1,r2;  \
+   movqr3,r4;  \
+   movlr5 ## E,(r9);   \
+   movlr6 ## E,4(r9);  \
+   movlr7 ## E,8(r9);  \
+   movlr8 ## E,12(r9); \
+   ret;
+
+#define round(TAB,OFFSET,r1,r2,r3,r4,r5,r6,r7,r8,ra,rb,rc,rd) \
+   movzbl  r2 ## H,r5 ## E;\
+   movzbl  r2 ## L,r6 ## E;\
+   movlTAB+1024(,r5,4),r5 ## E;\
+   movwr4 ## X,r2 ## X;\
+   movlTAB(,r6,4),r6 ## E; \
+   roll$16,r2 ## E;\
+   shrl$16,r4 ## E;\
+   movzbl  r4 ## H,r7 ## E;\
+   movzbl  r4 ## L,r4 ## E;\
+   xorlOFFSET(r8),ra ## E; \
+   xorlOFFSET+4(r8),rb ## E;   \
+   xorlTAB+3072(,r7,4),r5 ## E;\
+   xorlTAB+2048(,r4,4),r6 ## E;\
+   movzbl  r1 ## L,r7 ## E;\
+   movzbl  r1 ## H,r4 ## E;\
+   movlTAB+1024(,r4,4),r4 ## E;\
+   movwr3 ## X,r1 ## X;\
+   roll$16,r1 ## E;\
+   shrl$16,r3 ## E;\
+   xorlTAB(,r7,4),r5 ## E; \
+   movzbl  r3 ## H,r7 ## E;\
+   movzbl  r3 ## L,r3 ## E;\
+   xorlTAB+3072(,r7,4),r4 ## E;\
+   xorlTAB+2048(,r3,4),r5 ## E;\
+   movzbl  r1 ## H,r7 ## E;\
+   movzbl  r1 ## L,r3 ## E;\
+   shrl$16,r1 ## E;\
+   xorlTAB+3072(,r7,4),r6 ## E;\
+   movlTAB+2048(,r3,4),r3 ## E;\
+   movzbl  r1 ## H,r7 ## E;\
+   movzbl  r1 ## L,r1 ## E;\
+   xorlTAB+1024(,r7,4),r6 ## E;\
+   xorlTAB(,r1,4),r3 ## E; \
+   movzbl  r2 ## H,r1 ## E;\
+   movzbl  r2 ## L,r7 ## E;\
+   shrl$16,r2 ## E;\
+   xorlTAB+3072(,r1,4),r3 ## E;\
+   xorlTAB+2048(,r7,4),r4 ## E;\
+   movzbl  r2 ## H,r1 ## E;\
+   movzbl  r2 ## L,r2 ## E;\
+   xorlOFFSET+8(r8),rc ## E;   \
+   xorlOFFSET+12(r8),rd ## E;  \
+   xorlTAB+1024(,r1,4),r3 ## E;\
+   xorlTAB(,r2,4),r4 ## E;
+
+#define move_regs(r1,r2,r3,r4) \
+   movlr3 ## E,r1 ## E;\
+   movlr4 ## E,r2 ## E;
+
+#define entry(FUNC,BASE,B128,B192) \
+   prologue(FUNC,BASE,B128,B192,R2,

[RFC][PATCH 0/4] AES assembler implementation for x86_64

[Andreas Steinmetz]

Implementation:
===
The encrypt/decrypt code is based on an x86 implementation I did a while
ago which I never published. This unpublished implementation does
include an assembler based key schedule and precomputed tables. For
simplicity and best acceptance, however, I took Gladman's in-kernel code
for table generation and key schedule for the kernel port of my
assembler code and modified this code to produce the key schedule as
required by my assembler implementation. File locations and Kconfig are
kept similar to the i586 AES assembler implementation.
It may seem a little bit strange to use 32 bit I/O and registers in the
assembler implementation but this gives the best code size. My
implementation takes one instruction more per round compared to
Gladman's x86 assembler but it doesn't require any stack for local
variables or saved registers and it is less serialized than Gladman's
x86 code.
Note that all comparisons to Gladman's code were done after my code was
implemented. I did only use FIPS PUB 197 for the implementation so my
implementation is independent work.
If anybody has a better assembler solution for x86_64 I'll be pleased to
have my code replaced with the better solution.

Testing:

The implementation passes the in-kernel crypto testing module and I'm
running it without any problems on my laptop where it is mainly used for
dm-crypt.

Microbenchmark:
===
The microbenchmark was done in userspace with similar compile flags as
used during kernel compile.
Encrypt/decrypt is about 35% faster than the generic C implementation.
As the generic C as well as my assembler implementation are both table
driven I don't really expect that there is much room for further
improvements though I'll be glad to be corrected here.
The key schedule is about 5% slower than the generic C implementation.
This is due to the fact that some more work has to be done in the key
schedule routine to fit the schedule to the assembler implementation.

Code Size:
==
Encrypt and decrypt are together about 2.1 Kbytes smaller than the
generic C implementation which is important with regard to L1 cache
usage. The key schedule routine is about 100 bytes larger than the
generic C implementation.

Data Size:
==
There's no difference in data size requirements between the assembler
implementation and the generic C implementation.

License:

Gladmans's code is dual BSD/GPL whereas my assembler code is GPLv2 only
(I'm  not going to change the license for my code). So I had to change
the module license for the x86_64 aes module from 'Dual BSD/GPL' to
'GPL' to reflect the most restrictive license within the module.

PS: It can happen that it may take a while until I can reply as I'm
regularly offline due to my current daytime job requirements.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]

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

Re: More performance for the TCP stack by using additional hardware chip on NIC

[Andreas Hartmann]

Willy Tarreau schrieb:
> Hello !
> 
> On Sun, Apr 17, 2005 at 01:29:14PM +0300, Avi Kivity wrote:
>> On Sun, 2005-04-17 at 12:07, Arjan van de Ven wrote:
>> > On Sun, 2005-04-17 at 10:17 +0200, Andreas Hartmann wrote:
>> > > Hello!
>> > > 
>> > > Alacritech developed a new chip for NIC's
>> > > (http://www.alacritech.com/html/tech_review.html), which makes it 
>> > > possible
>> > > to take away the TCP stack from the host CPU. Therefore, the host CPU has
>> > > more performance for the applications according Alacritech.
>> > 
>> > there are very many good reasons why this for linux is not the right
>> > solution, including the fact that the linux tcp/ip stack already is
>> > quite fast so the "gains" achieved aren't that stellar as the gains you
>> > get when comparing to windows.
>> > 
>> 
>> TOEs can remove the data copy on receive. In some applications (notably
>> storage), where the application does not touch most of the data, this is
>> a significant advantage that cannot be achieved in a software-only
>> solution.
> 
> Well, if the application does not touch most of the data, either it
> is playing as a relay, and the data will at least have to be copied,
> or it will play as a client or server which reads from/writes to disk,
> and in this case, I wonder how the NIC will send its writes directly
> to the disk controller without some help.
> 
> What worries me with those NICs is that you have no control on the
> TCP stack. You often have to disable the acceleration when you
> want to insert even 1 firewall rule, use policy routing or even
> do a simple anti-spoofing check. It is exactly like the routers
> which do many things in hardware at wire speed, but jump to snail
> speed when you enable any advanced feature.
> 
>> > Also these types of solution always add quite a bit of overhead to
>> > connection setup/teardown making it actually a *loss* for the "many
>> > short connections" types of workloads. Now guess which things certain
>> > benchmarks use, and guess what real world servers do :)
>> > 
>> 
>> again, this depends on the application.
> 
> The speed itself depends on the application. An application which
> goal is to achieve 10 Gbps needs to be written with this goal in
> mind from start, and needs fine usage of the kernel internals, and
> even sometimes good knowledge of the hardware itself.

Alacritech says, the hardware solution would make it very easy for the
application, because _every_ application would gain, without considering
the hardware it runs on itself. These are things which CEO's like to hear
- because they think, they could save time and money during development of
the application.


I don't think that it must be a problem, that on the hardware TCP stack
doesn't run any filter or other additional functions, because machines
(often clusters) with high workloads usually run on dedicated servers with
other dedicated firewall machines in front of.


I think it would be good to support this hardware, because the user can
decide afterwards (after testing), which is the best choice for his
specific application and workload.



Kind regards,
Andreas Hartmann
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] i386 & x86_64: Live Patching Funcion on 2.6.11.7

[Daniel Jacobowitz]

On Sat, Apr 16, 2005 at 11:44:39PM -0700, David S. Miller wrote:
> 
> Takashi-san, have you ever investigated using kprobes to
> implement this feature?  It seems a perfect fit, and would
> allow support on several architectures other than just x86
> and x86_64.
> 
> If kprobes does not meet your needs completely, it could
> be trivially extended to do so.
> 
> I think implementing something like this from scratch is
> not a good idea when we have much of the needed logic and
> infrastructure already.

Takashi-san's description was not very clear, but it sounds like it's a
patching mechanism for userspace applications - not for kernel space.
So kprobes would not be a good fit.

If I'm right, I'm not sure why some of the bits of it were done
separately instead of via the existing ptrace mechanism.  And GDB
would appreciate a mechanism for mmap/munmap/mprotect in a debugged
process, also.

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

Re: [RFC] FUSE permission modell (Was: fuse review bits)

[Miklos Szeredi]

> > 
> >   1) Only allow mount over a directory for which the user has write
> >  access (and is not sticky)
> > 
> >   2) Use nosuid,nodev mount options
> > 
> > [ parts deleted ]
> 
> Do these solve all the security concerns with unprivileged mounts, or
> are there other barriers/concerns?  Should there be ulimit (or rlimit)
> style restrictions on how many mounts/binds a user is allowed to have
> to prevent users from abusing mount privs?

Currently there is a (configurable) global limit for all non-root FUSE
mounts.  An additional per-user limit would be nice, but from the
security standpoint it doesn't matter.

> I was thinking about this a while back and thought having a user-mount
> permissions file might be the right way to address lots of these
> issues.  Essentially it would contain information about what
> users/groups were allowed to mount what sources to what destinations
> and with what mandatory options.

I haven't yet seen the need for such a great flexibility.  Debian
installs fusermount (the FUSE mount utility) "-rwsr-x--- root fuse",
so only users in the "fuse" group are allowed to use it.  This is sane
for a new technology, but I expect these limitations to be removed
once it establishes itsef as a secure solution.

> You can get the start of this with the user/users/etc. stuff in
> /etc/fstab, but I was envisioning something a bit more dynamic with
> regular expression based rules for sources and destinations.   So,
> something like:

[snip]

> Is this unnecessary?  Is this not enough?

Maybe it is necessary, but why bother until somebody actually wants
it?  I'm a great believer of the "lazy" development philosophy ;)

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

[2.6 patch] drivers/scsi/dpt*: remove version.h dependencies

[Adrian Bunk]

On Fri, Apr 15, 2005 at 08:56:25AM -0400, Salyzyn, Mark wrote:
> 
> You can not remove the entries in sys_info.h (osMajorVersion & friends),
> this communicates information to the application via the ioctls and the
> structure shape is important. Change the code to zero the values, leave
> osType set to OS_LINUX.

Sorry, my fault.

Corrected patch below.

> Sincerely -- Mark Salyzyn

cu
Adrian


<--  snip  -->


This patch removes version.h dependencies.

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

 drivers/scsi/dpt/sys_info.h |4 
 drivers/scsi/dpt_i2o.c  |5 -
 drivers/scsi/dpti.h |   12 
 3 files changed, 21 deletions(-)

--- linux-2.6.12-rc2-mm3-full/drivers/scsi/dpti.h.old   2005-04-15 
01:21:04.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/scsi/dpti.h   2005-04-15 
01:21:26.0 +0200
@@ -20,15 +20,7 @@
 #ifndef _DPT_H
 #define _DPT_H
 
-#ifndef LINUX_VERSION_CODE
-#include 
-#endif
-
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,00)
-#define MAX_TO_IOP_MESSAGES   (210)
-#else
 #define MAX_TO_IOP_MESSAGES   (255)
-#endif
 #define MAX_FROM_IOP_MESSAGES (255)
 
 
@@ -321,10 +313,6 @@
 static void adpt_delay(int millisec);
 #endif
 
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,4,0)
-static struct pci_dev* adpt_pci_find_device(uint vendor, struct pci_dev* from);
-#endif
-
 #if defined __ia64__ 
 static void adpt_ia64_info(sysInfo_S* si);
 #endif
--- linux-2.6.12-rc2-mm3-full/drivers/scsi/dpt_i2o.c.old2005-04-15 
01:21:48.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/scsi/dpt_i2o.c2005-04-15 
01:25:20.0 +0200
@@ -34,7 +34,6 @@
 
 #define ADDR32 (0)
 
-#include 
 #include 
 
 MODULE_AUTHOR("Deanna Bonds, with _lots_ of help from Mark Salyzyn");
@@ -1824,10 +1823,10 @@
 
memset(&si, 0, sizeof(si));
 
si.osType = OS_LINUX;
-   si.osMajorVersion = (u8) (LINUX_VERSION_CODE >> 16);
-   si.osMinorVersion = (u8) (LINUX_VERSION_CODE >> 8 & 0x0ff);
-   si.osRevision = (u8) (LINUX_VERSION_CODE & 0x0ff);
+   si.osMajorVersion = 0;
+   si.osMinorVersion = 0;
+   si.osRevision = 0;
si.busType = SI_PCI_BUS;
si.processorFamily = DPTI_sig.dsProcessorFamily;
 



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

[2.6 patch] ACPI: add two missing config.h #include's

[Adrian Bunk]

On Sat, Apr 16, 2005 at 08:59:23AM +0100, Russell King wrote:
> On Sat, Apr 16, 2005 at 04:38:52AM +0200, Adrian Bunk wrote:
> > In the Linux kernel, it's more common to put such header dependencies 
> > for header files into the C files, but if the ACPI people agree a patch 
> > to add the #include  to acpi_bus.h is the other possble 
> > correct solution for this issue.
> 
> With the exception of linux/config.h.
> 
> Do a 'make configcheck' and it'll tell you where linux/config.h is missing
> and where it shouldn't be.

OK, then the patch below is the correct solution.

cu
Adrian


<--  snip  -->


This patch fixes the following warning by adding two missing config.h 
#include's:

<--  snip  -->

...
  CC  drivers/serial/8250_acpi.o
drivers/serial/8250_acpi.c: In function `acpi_serial_ext_irq':
drivers/serial/8250_acpi.c:51: warning: implicit declaration of function 
`acpi_register_gsi'
...

<--  snip  -->

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

--- linux-2.6.12-rc2-mm3-full/include/acpi/acpi_bus.h.old   2005-04-17 
19:05:23.0 +0200
+++ linux-2.6.12-rc2-mm3-full/include/acpi/acpi_bus.h   2005-04-17 
19:05:37.0 +0200
@@ -26,6 +26,7 @@
 #ifndef __ACPI_BUS_H__
 #define __ACPI_BUS_H__
 
+#include 
 #include 
 
 #include 
--- linux-2.6.12-rc2-mm3-full/include/linux/acpi.h.old  2005-04-17 
19:25:51.0 +0200
+++ linux-2.6.12-rc2-mm3-full/include/linux/acpi.h  2005-04-17 
19:24:54.0 +0200
@@ -25,6 +25,8 @@
 #ifndef _LINUX_ACPI_H
 #define _LINUX_ACPI_H
 
+#include 
+
 #ifdef CONFIG_ACPI
 
 #ifndef _LINUX
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] FUSE permission modell (Was: fuse review bits)

[Jamie Lokier]

Eric Van Hensbergen wrote:
> I'd like to second that I think private-namespaces are the right way
> to solve this sort of problem.  It also helps not cluttering the
> global namespace with user-local mounts
> 
> >
> > Shared subtrees and more support in userspace tools is needed before
> > private namespaces can become really useful.
> > 
> 
> I'd like to talk about this a bit more and start driving to a solution
> here.  I've been looking at the namespace code quite a bit and was
> just about to dive in and start checking into adding/fixing certain
> aspects such as stackable namespaces, optional inheritence (changes in
> a parent namespace are reflected in the child but not vice-versa),
> etc.
> 
> One aspect I was thinking about here was a mount flag that would give
> you a new private namespace (if you didn't already have one) for the
> mount (and I guess that would impact any subsequent mounts from the
> user in that shell).  Another option would be a 'newns' style
> system-call, but I'm generally against adding new system calls.
> 
> Shared subtrees are a tricky one.  I know how we would handle it in
> V9FS, but not sure how well that would translate to others
> (essentially we'd re-export the subtree so other user's could mount it
> individually -- but that's a very Plan 9 solution and may not be what
> more UNIX-minded folks would want -- we also need to improve our own
> server infrastructure to more efficiently support such a re-export).
> 
> So, to sum up I think private namespaces is the right solution, and
> I'd rather put effort into making it more useful than work-around the
> fact that its not practical right now.

Have a chat with Al Viro, who has already done some work on shared
mounts and subtrees I think.

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

Re: [RFC] FUSE permission modell (Was: fuse review bits)

[Eric Van Hensbergen]

On 4/11/05, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
> 
>   1) Only allow mount over a directory for which the user has write
>  access (and is not sticky)
> 
>   2) Use nosuid,nodev mount options
> 
> [ parts deleted ]

Do these solve all the security concerns with unprivileged mounts, or
are there other barriers/concerns?  Should there be ulimit (or rlimit)
style restrictions on how many mounts/binds a user is allowed to have
to prevent users from abusing mount privs?

I was thinking about this a while back and thought having a user-mount
permissions file might be the right way to address lots of these
issues.  Essentially it would contain information about what
users/groups were allowed to mount what sources to what destinations
and with what mandatory options.

You can get the start of this with the user/users/etc. stuff in
/etc/fstab, but I was envisioning something a bit more dynamic with
regular expression based rules for sources and destinations.   So,
something like:

# /etc/usermounts: user mount permissions

#  

# allow users to mount any file system under their home directory
*   $HOME   * 
   nosuid, nosgid
# allow users to bind over /usr/bin as long as its only in their
private namespace
*   /usr/bin  
bindnewns
# allow users to loopback mount distributed file systems to /mnt
127.0.0.1  /mnt   *   
 nosuid, nosgid
# allow users to mount files over any directory they have right access to
*   (perm=0222) * 
   nosuid, nosgid

Is this unnecessary?  Is this not enough?

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

Re: via82xx driver: reporting dxs_support experience

[Sergey Vlasov]

On Sun, 17 Apr 2005 12:53:24 -0400 TJ wrote:

> I was using the 2.6.7 kernel without APIC or ACPI support, and the via82xx
> driver worked perfectly, compiled as a module, without any options. I built a
> new 2.6.7 kernel on the same hardware with APIC and ACPI support in the
> kernel, as the board supports it, and the driver did not work correctly.

2.6.7 is pretty old; there were many bugfixes in both ACPI and sound
drivers since that time.

> When sound was played, a short, 1 second long bit of the sound to be
> played was looped. Possibly this is the clicking noise described by
> some people?

Does not look like it.  The most common cause of looping sound are
interrupt problems, and unfortunately ACPI (especially when coupled
with APIC support) often triggers them (sometimes because of bugs in
the kernel ACPI support, sometimes because a buggy BIOS supplies
broken data).

If interrupts are not working, usually this happens:

- The driver sets up a circular buffer which contains the first
  portion of sound samples to be played, and starts the playback
  hardware.

- The sound card reads the samples from the buffer; when it reaches
  some point in the buffer, it sends the interrupt signal, notifying
  the driver about it.

- Normally, when the driver handles the interrupt, it will place more
  sound data in the circular buffer (or, in the mmap mode, it will
  notify the application, which will write to the buffer directly).
  However, if interrupts are not working, the driver will never get
  such notification, and the same portion of sound samples will stay
  in the buffer forever.  The sound card does not know that the buffer
  was not updated and will play that piece of sound forever.

Another symptom of not working interrupts is that aplay just hangs
forever (aplay -vv should draw a histogram of played data).

> The driver works fine with this new kernel after adding the option
> "dxs_support=1".

This is very strange - the dxs_support option should not cause such
changes.  Usually the problem caused by a wrong dxs_support value is
that sound is basically there, but distorted.

Also, seems that dxs_support=1 should not work at all (at least in
theory).  dxs_support=4 seems to be more correct; latest code in ALSA
CVS supports dxs_support=5, which uses more capabilities of the
hardware (apparently the VIA VT8233/5/7 chips are able to perform
sample rate conversion from arbitrary rates to 48000 Hz with 4
independent channels).

> I hope this interaction with ACPI and APIC sheds some light on some
> of the troubles with this driver.

Most likely you have some trouble with ACPI (either with the buggy
implementation in 2.6.7, or with the buggy BIOS, or maybe both).

> I can provide more information if
> anyone wants it. Please CC me, I'm not on the list.
> 
> TJ
> 
> Motherboard: MSI K7T266 Pro2
> 
> 00:11.5 Class 0401: 1106:3059 (rev 10)

Hmm, seems to be some old chip revision:

#define VIA_REV_PRE_82330x10/* not in market */

> Subsystem: 4005:4710

Not in the known devices list of snd-via82xx (this list contains
working values of the dxs_support option for known boards).  But you
should report it to ALSA developers (e.g., in their bug tracking
system, https://bugtrack.alsa-project.org/alsa-bug/ ) - your message
to LKML will likely be lost.

> Flags: medium devsel, IRQ 28
> I/O ports at bc00 [size=256]
> Capabilities: [c0] Power Management version 2


pgpCEtZpQwkB4.pgp
Description: PGP signature

Re: ACPI/HT or Packet Scheduler BUG?

[Patrick McHardy]

Herbert Xu wrote:
On Sat, Apr 16, 2005 at 01:06:39PM +0200, Thomas Graf wrote:
qdisc_destroy can still be invoked without qdisc_tree_lock via the
deletion of a class when it calls qdisc_destroy to destroy its
leaf qdisc.
Indeed.  Fortuantely HTB seems to be safe as it calls sch_tree_lock
which is another name for qdisc_tree_lock.  CBQ on the other hand
needs to have a little tweak.
HTB also needs to be fixed. Destruction is usually defered by the
refcnt until ->put(), htb_put() doesn't lock the tree. Same for
HFSC and CBQ.
Regards
Patrick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/