Re: Status of new kernel.org servers

2005-04-10 Thread H. Peter Anvin
Both the new kernel.org servers are now in full production, including
mirrors.

Enjoy, and as usual, report problems to [EMAIL PROTECTED].

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


[PATCH scsi-misc-2.6] scsi: scsi_send_eh_cmnd() cleanup

2005-04-10 Thread Tejun Heo
 Hello, James.

 This patch makes scsi_send_eh_cmnd() use sdev and shost instead of
referencing them through scmd- everytime.  Following timer cleanup
patchset assumes this patch is applied.


 Signed-off-by: Tejun Heo [EMAIL PROTECTED]


Index: scsi-reqfn-export/drivers/scsi/scsi_error.c
===
--- scsi-reqfn-export.orig/drivers/scsi/scsi_error.c2005-04-10 
15:20:09.0 +0900
+++ scsi-reqfn-export/drivers/scsi/scsi_error.c 2005-04-10 15:25:21.0 
+0900
@@ -485,7 +485,8 @@ static void scsi_eh_done(struct scsi_cmn
  **/
 static int scsi_send_eh_cmnd(struct scsi_cmnd *scmd, int timeout)
 {
-   struct Scsi_Host *host = scmd-device-host;
+   struct scsi_device *sdev = scmd-device;
+   struct Scsi_Host *shost = sdev-host;
DECLARE_MUTEX_LOCKED(sem);
unsigned long flags;
int rtn = SUCCESS;
@@ -496,27 +497,27 @@ static int scsi_send_eh_cmnd(struct scsi
 */
scmd-owner = SCSI_OWNER_LOWLEVEL;
 
-   if (scmd-device-scsi_level = SCSI_2)
+   if (sdev-scsi_level = SCSI_2)
scmd-cmnd[1] = (scmd-cmnd[1]  0x1f) |
-   (scmd-device-lun  5  0xe0);
+   (sdev-lun  5  0xe0);
 
scsi_add_timer(scmd, timeout, scsi_eh_times_out);
 
/*
 * set up the semaphore so we wait for the command to complete.
 */
-   scmd-device-host-eh_action = sem;
+   shost-eh_action = sem;
scmd-request-rq_status = RQ_SCSI_BUSY;
 
-   spin_lock_irqsave(scmd-device-host-host_lock, flags);
+   spin_lock_irqsave(shost-host_lock, flags);
scsi_log_send(scmd);
-   host-hostt-queuecommand(scmd, scsi_eh_done);
-   spin_unlock_irqrestore(scmd-device-host-host_lock, flags);
+   shost-hostt-queuecommand(scmd, scsi_eh_done);
+   spin_unlock_irqrestore(shost-host_lock, flags);
 
down(sem);
scsi_log_completion(scmd, SUCCESS);
 
-   scmd-device-host-eh_action = NULL;
+   shost-eh_action = NULL;
 
/*
 * see if timeout.  if so, tell the host to forget about it.
@@ -536,10 +537,10 @@ static int scsi_send_eh_cmnd(struct scsi
 * abort a timed out command or not.  not sure how
 * we should treat them differently anyways.
 */
-   spin_lock_irqsave(scmd-device-host-host_lock, flags);
-   if (scmd-device-host-hostt-eh_abort_handler)
-   scmd-device-host-hostt-eh_abort_handler(scmd);
-   spin_unlock_irqrestore(scmd-device-host-host_lock, flags);
+   spin_lock_irqsave(shost-host_lock, flags);
+   if (shost-hostt-eh_abort_handler)
+   shost-hostt-eh_abort_handler(scmd);
+   spin_unlock_irqrestore(shost-host_lock, flags);

scmd-request-rq_status = RQ_SCSI_DONE;
scmd-owner = SCSI_OWNER_ERROR_HANDLER;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] sched: unlocked context-switches

2005-04-10 Thread Ingo Molnar

* David S. Miller [EMAIL PROTECTED] wrote:

  Yes, of course.  The deadlock was due to context-switching, not
  switch_mm() per se.  Hopefully someone else beats me to remembering
  the details before Monday.
 
 Sparc64 has a deadlock because we hold mm-page_table_lock during 
 switch_mm().  I bet IA64 did something similar, as I remember it had a 
 very similar locking issue in this area.
 
 So the deadlock was, we held the runqueue locks over switch_mm(), 
 switch_mm() spins on mm-page_table_lock, the cpu which does have 
 mm-page_table_lock tries to do a wakeup on the first cpu's runqueue. 
 Classic AB-BA deadlock.

yeah, i can see that happening - holding the runqueue lock and enabling 
interrupts. (it's basically never safe to enable irqs with the runqueue 
lock held.)

the patch drops both the runqueue lock and enables interrupts, so this 
particular issue should not trigger.

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] sched: unlocked context-switches

2005-04-10 Thread Richard Henderson
On Sat, Apr 09, 2005 at 03:46:12PM -0700, David S. Miller wrote:
 On Sat, 09 Apr 2005 19:22:23 +1000
 Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
 
  ppc64 already has a local_irq_save/restore in switch_to, around the low
  level asm bits, so it should be fine.
 
 Sparc64 essentially does as well.  In fact, it uses an IRQ disable
 which is stronger  than local_irq_save in that it disables reception
 of CPU cross-calls as well.

Alpha does the switch in PALmode, which is never interruptable.


r~


Re: more git updates..

2005-04-10 Thread Junio C Hamano
Listing the file paths and their sigs included in a tree to make
a snapshot of a tree state sounds fine, and diffing two trees by
looking at the sigs between two such files sounds fine as well.

But I am wondering what your plans are to handle renames---or
does git already represent them?

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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.11.x: bootprompt: ALSA: no soundcard detected

2005-04-10 Thread Dennis Heuer
Hello,
I switched from 2.4 to 2.6.11 and found that the hard power-down now definetly 
needs ACPI, which stopped my soundplayer life from playing (stucking display 
and no sound), though. I installed 2.6.11.4, 2.6.11.5, and 2.6.11.7 but all 
three broke the hardware detection on my system. Now, with or without ACPI, the 
soundcard isn't even found.
There is no further error message, linux installs as always.
Regards,
Dennis Heuer
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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]

2005-04-10 Thread Dennis Heuer
unsubscribe linux-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/


Dauphintel Nuovi listini 09/04/2005 New Price list

2005-04-10 Thread valter

DAUPHINTEL
import export cellular accessories  spare parts

Valter Paoli
www.dauphintel.com

Questo messaggio e mail e' confidenziale e indirizzato solo ai destinatari 
specificati, che sono gli unici autorizzati alla lettura delle informazioni 
contenute.
E' proibito distribuire, diffondere e copiare questo messaggio senza la nostra 
preventiva autorizzazione.Nel caso abbiate ricevuto questo messaggio per errore 
ci scusiamo e vi chiediamo di comunicarcelo con una mail , e di cancellare il 
messaggio in questione.
This email message is confidential and addressed only to the mentioned 
recipients.
Only the specified addresses can read and use the informations included.
Any distribution, copy , dissemination of this mail is prohibited.If you have 
received this mail by mistake, please send us a return mail to advice us aní
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 SCM saga..

2005-04-10 Thread David Lang
On Sat, 9 Apr 2005, Linus Torvalds wrote:
The biggest irritation I have with the tree format I chose is actually
not the name (which is trivial), it's the sha1 part. Almost everything
else keeps the sha1 in the ASCII hexadecimal representation, and I
should have done that here too. Why? Not because it's a sha1 - hey, the
binary representation is certainly denser and equivalent - but because an
ASCII representation there would have allowed me to much more easily
change the key format if I ever wanted to. Now it's very SHA1-specific.
Which I guess is fine - I don't really see any reason to change, and if I
do change, I could always just re-generate the whole tree. But I think it
would have been cleaner to have _that_ part in ASCII.
just wanted to point out that recent news shows that sha1 isn't as good as 
it was thought to be (far easier to deliberatly create collisions then it 
should be)

this hasn't reached a point where you HAVE to quit useing it (especially 
since you have the other validity checks in place), but it's a good reason 
to expect that you may want to change to something else in a few years.

it's a lot easier to change things now to make that move easier then once 
this is being used extensively

David Lang
--
There are two ways of constructing a software design. One way is to make it so 
simple that there are obviously no deficiencies. And the other way is to make 
it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: more git updates..

2005-04-10 Thread Christopher Li
On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
 
 But I am wondering what your plans are to handle renames---or
 does git already represent them?


Rename should just work.  It will create a new tree object and you
will notice that in the entry that changed, the hash for the blob
object is the same.

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/


unregister_netdevice(): negative refcnt, suggest patch against 2.6.11

2005-04-10 Thread Felix Palmen
Hi lkml-members,

I recently had a problem with appletalk. After starting atalkd on a TAP
interface and stopping it later, unregister_netdevice() just stated
| unregister_netdevice: waiting for tap0 to become free. Usage count = -1

So I assume there is a problem in the appletalk code, but I didn't try
reproducing that on other systems so far.

I changed my kernel to correct a negative refcnt to 0 and that kind
of fixes the problem. I'm not sure whether this could break anything,
but certainly waiting for a device to become free is no use when there
is a negative number of users, so I think it would be better to allow
the system to shut down cleanly in this case.

Here's m suggestion:

#v+
--- linux-2.6.11-orig/net/core/dev.c 2005-03-02 08:38:09.0 +0100
+++ linux-2.6.11/net/core/dev.c2005-04-09 16:44:42.0 +0200
@@ -2876,7 +2876,7 @@
unsigned long rebroadcast_time, warning_time;

rebroadcast_time = warning_time = jiffies;
-   while (atomic_read(dev-refcnt) != 0) {
+   while (atomic_read(dev-refcnt)  0) {
if (time_after(jiffies, rebroadcast_time + 1 * HZ)) {
rtnl_shlock();

@@ -2910,6 +2910,13 @@
warning_time = jiffies;
}
}
+   if (atomic_read(dev-refcnt) != 0) {
+   printk(KERN_ERR unregister_netdevice: 
+   %s has negative refcnt (%d). 
+   This should never happen! Setting refcnt to 0.\n,
+   dev-name, atomic_read(dev-refcnt));
+   atomic_set(dev-refcnt, 0);
+   }
 }

 /* The sequence is:
#v-

Greets, Felix

PS: Please note I'm not subscribed to lkml and CC me in replies, thanks.

-- 
 | /\   ASCII Ribbon   | Felix M. Palmen (Zirias)http://zirias.ath.cx/ |
 | \ / Campaign Against | [EMAIL PROTECTED]  encrypted mail welcome |
 |  XHTML In Mail   | PGP key: http://zirias.ath.cx/pub.txt |
 | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 |


signature.asc
Description: Digital signature


Re: [2.6 patch] crypto/api.c: make crypto_alg_lookup static

2005-04-10 Thread Herbert Xu
On Sat, Apr 09, 2005 at 09:38:41PM +0200, Adrian Bunk wrote:
 This patch makes a needlessly global function static.

Thanks Adrian, patch applied.
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [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/


Re: Kernel SCM saga..

2005-04-10 Thread Giuseppe Bilotta
On Sat, 9 Apr 2005 12:17:58 -0400, David Roundy wrote:

 I've recently made some improvements
 recently which will reduce the memory use

Does this include check for redundancy? ;)

-- 
Giuseppe Oblomov Bilotta

Hic manebimus optime

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


$B!y!!(BNEW$B!!(BOPEN$B!!!y(B

2005-04-10 Thread info




$B!!!z!y!z!!$D$$$K#O#P#E#N!*!!!z!y!z(B

$B4JC1A`:n$G4JC1EPO?!*(B

$B!!??7u$J=P2q$$$O$3$3$+$i(B

$B!!(B  $B=i$a$F$NJ}$OL5NA%(%s%H%j!$+$i$I$$(B



  $B(Bhttp://www.getluck.net/



$B(GIj$J%$%s%A%-=-$$%5%$%H$O0c$$$^$9!#(B

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


Re: more git updates..

2005-04-10 Thread Junio C Hamano
 CL == Christopher Li [EMAIL PROTECTED] writes:

CL On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
 
 But I am wondering what your plans are to handle renames---or
 does git already represent them?
 

CL Rename should just work.  It will create a new tree object and you
CL will notice that in the entry that changed, the hash for the blob
CL object is the same.

Sorry, I was unclear.  But doesn't that imply that a SCM built
on top of git storage needs to read all the commit and tree
records up to the common ancestor to show tree diffs between two
forked tree?

I suspect that another problem is that noticing the move of the
same SHA1 hash from one pathname to another and recognizing that
as a rename would not always work in the real world, because
sometimes people move files *and* make small changes at the same
time.  If git is meant to be an intermediate format to suck
existing kernel history out of BK so that the history can be
converted for the next SCM chosen for the kernel work, I would
imagine that there needs to be a way to represent such a case.
Maybe convert a file rename as two git trees (one tree for pure
move which immediately followed by another tree for edit) if it
is not a pure move?


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


Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

2005-04-10 Thread Giuseppe Bilotta
On Fri, 08 Apr 2005 20:42:17 +0200, Josselin Mouette wrote:

 Every book in my book shelf is software?
 
 If you digitalize it, yes.

AFAIK software only refers to programs, not to arbitrary sequences of
bytes. An MP3 file isn't software. Although it surely isn't hardware
either.

-- 
Giuseppe Oblomov Bilotta

E la storia dell'umanità, babbo?
Ma niente: prima si fanno delle cazzate,
 poi si studia che cazzate si sono fatte
(Altan)
(And what about the history of the human race, dad?
 Oh, nothing special: first they make some foolish things,
  then you study what foolish things have been made)

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

2005-04-10 Thread Wichert Akkerman
Previously Christopher Li wrote:
 Rename should just work.  It will create a new tree object and you
 will notice that in the entry that changed, the hash for the blob
 object is the same.

What if you rename and change a file within a changeset?

Wichert.

-- 
Wichert Akkerman [EMAIL PROTECTED]It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 SCM saga..

2005-04-10 Thread Junio C Hamano
 DL == David Lang [EMAIL PROTECTED] writes:

DL just wanted to point out that recent news shows that sha1 isn't as
DL good as it was thought to be (far easier to deliberatly create
DL collisions then it should be)

I suspect there is no need to do so...

  Message-ID: [EMAIL PROTECTED]
  From: Linus Torvalds [EMAIL PROTECTED]
  Subject: Re: Kernel SCM saga..
  Date: Sat, 9 Apr 2005 09:16:22 -0700 (PDT)

  ...

  Linus 

  (*) yeah, yeah, I know about the current theoretical case, and I don't
  care. Not only is it theoretical, the way my objects are packed you'd have
  to not just generate the same SHA1 for it, it would have to _also_ still
  be a valid zlib object _and_ get the header to match the type + length  
  of object part. IOW, the object validity checks are actually even stricter
  than just sha1 matches.

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


Re: Re: more git updates..

2005-04-10 Thread Petr Baudis
Dear diary, on Sun, Apr 10, 2005 at 07:53:40AM CEST, I got a letter
where Christopher Li [EMAIL PROTECTED] told me that...
 On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
  
  But I am wondering what your plans are to handle renames---or
  does git already represent them?
 
 
 Rename should just work.  It will create a new tree object and you
 will notice that in the entry that changed, the hash for the blob
 object is the same.

Which is of course wrong when you want to do proper merging, examine
per-file history, etc. One solution which springs to my mind is to have
a UUID accompany each blob and tree; that will take relatively lot of
space though, and I'm not sure it is really worth it.

How many renames were there in the 64k commits so far anyway?

-- 
Petr Pasky Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Re: more git updates..

2005-04-10 Thread Petr Baudis
Dear diary, on Sun, Apr 10, 2005 at 11:28:54AM CEST, I got a letter
where Junio C Hamano [EMAIL PROTECTED] told me that...
  CL == Christopher Li [EMAIL PROTECTED] writes:
 
 CL On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
  
  But I am wondering what your plans are to handle renames---or
  does git already represent them?
  
 
 CL Rename should just work.  It will create a new tree object and you
 CL will notice that in the entry that changed, the hash for the blob
 CL object is the same.
 
 Sorry, I was unclear.  But doesn't that imply that a SCM built
 on top of git storage needs to read all the commit and tree
 records up to the common ancestor to show tree diffs between two
 forked tree?

No. See diff-tree output and
http://pasky.or.cz/~pasky/dev/git/gitdiff-do for how it's done.
Basically, you just take the two trees and compare them linearily (do a
normal diff on them, essentialy). Then the differences you spot this way
are everything what needs to appear in the patch.

 I suspect that another problem is that noticing the move of the
 same SHA1 hash from one pathname to another and recognizing that
 as a rename would not always work in the real world, because
 sometimes people move files *and* make small changes at the same
 time.  If git is meant to be an intermediate format to suck
 existing kernel history out of BK so that the history can be
 converted for the next SCM chosen for the kernel work, I would
 imagine that there needs to be a way to represent such a case.
 Maybe convert a file rename as two git trees (one tree for pure
 move which immediately followed by another tree for edit) if it
 is not a pure move?

Actually, this could be possible too I think. We will have to make
diff-tree two-pass, but it is already so blinding fast that I guess that
doesn't hurt too much. I might try to get my hands on that.

-- 
Petr Pasky Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]

2005-04-10 Thread Herbert Xu
Please add netdev to the CC list since this discussion pertains to
the networking subsystem.

Evgeniy Polyakov [EMAIL PROTECTED] wrote:
 
 User should not know about low-level transport - 
 it is like socket layer -  write only data and do not care about
 how it will be delivered.

The delineation between transport and upper layer is fuzzy.
In one situation the protocol might be transport and in another
it could be above the transport.

So I don't buy this argument.
 
 In the previous versions netlink group was assigned as incremented
 counter, 
 that was not convenient, but now we have 2-way ID, which is better
 from users point of view - idx is supposed to be major id, val - 
 some subsystem of that set.

Actually netlink does let you bind to a specific ID.

Of course you may argue that a single u32 is not enough.  However,
nothing is stopping you from introducing netlink v2 that extends
this.

In fact this is my main gripe with your patch: Why aren't you
extending netlink instead of hacking something on top of the existing
netlink? If the extensions require breaking compatibility: Fine,
you just need to call it netlink v2.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [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/


Re: more git updates..

2005-04-10 Thread Christopher Li
On Sat, Apr 09, 2005 at 04:31:10PM -0700, Linus Torvalds wrote:
 
 Done, and pushed out. The current git.git repository seems to do all of 
 this correctly.
 
 NOTE! This means that each tree file basically tracks just a single
 directory. The old style of every file in one tree file still works, but 
 fsck-cache will warn about it. Happily, the git archive itself doesn't 
 have any subdirectories, so git itself is not impacted by it.

That is really cool stuff. My way to read it, correct me if I am wrong,
git is a user space version file system. tree -- directory and
blob -- file.  commit to describe the version history.

Git always write out a full new version of blob when there is any
update to it. At first I think that waste a lot of space, especially
when there is only tiny change to it. But the more I think about it,
it make more sense. Kernel source is usually small objects and file is
compressed store any way. A very useful thing to gain form it is that,
we can truncate the older history. e.g. We can have option not to sync
the pre 2.4 change set, only grab it if we need to. Most of the time we
only interested in the recent change set.

There is one problem though. How about the SHA1 hash collision?
Even the chance is very remote, you don't want to lose some data do due
to software error. I think it is OK that no handle that
case right now. On the other hand, it will be nice to detect that
and give out a big error message if it really happens.

Some thing like the following patch, may be turn off able.

Chris

Index: git-0.03/read-cache.c
===
--- git-0.03.orig/read-cache.c  2005-04-09 18:42:16.0 -0400
+++ git-0.03/read-cache.c   2005-04-10 02:48:36.0 -0400
@@ -210,8 +210,22 @@
int fd;
 
fd = open(filename, O_WRONLY | O_CREAT | O_EXCL, 0666);
-   if (fd  0)
-   return (errno == EEXIST) ? 0 : -1;
+   if (fd  0) {
+   void *map;
+   static int error(const char * string);
+
+   if (errno != EEXIST)
+   return -1;
+   fd = open(filename, O_RDONLY);
+   if (fd  0)
+   return -1;
+   map = mmap(NULL, size, PROT_READ, MAP_PRIVATE, fd, 0);
+   if (map == MAP_FAILED)
+   return -1;
+   if (memcmp(buf, map, size))
+   return error(Ouch, Strike by lighting!\n);
+   return 0;
+   }
write(fd, buf, size);
close(fd);
return 0;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses

2005-04-10 Thread Moritz Muehlenhoff
Benjamin Herrenschmidt wrote:
 radeonfb_setcolreg: INPLL
 radeonfb_setcolreg: OUTPLL
 radeonfb_setcolreg: OUTPLL
 ... last three lines repeated 63 times

 Hrm... the last (serie of 64 setcolreg) are probably X beeing extremely
 dumb, and calling the ioctl 64 times to set each palette entry instead
 of doing a single call for the whole palette...

 Anyway. Except for maybe the double set-par on switch from X to console,
 there isn't much more we can do here. We might be able to improve X but
 there is a significant lag between a fix done to X.org HEAD appears in
 any distro. The fact is, according to ATI, there is a HW bug on M6 taht
 can cause lockups of the chip, and this 5ms workaround is necessary to
 avoid it... 

But it's not specific to X11; I've applied the patch you posted and the
same symptoms occur for pure tty switching as well, the delay has decreased
a bit (it's hard to measure, but around a second), but it's still rather
annoying to work with.

Is it distinguishable which M6 models are buggy? I'm using my X31 for about
a year now and have probably made some tens of thousands of switches without
lockups, so presumably not all models cause lockups.

Cheers,
Moritz
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 git updates..

2005-04-10 Thread Christopher Li
On Sun, Apr 10, 2005 at 02:28:54AM -0700, Junio C Hamano wrote:
  CL == Christopher Li [EMAIL PROTECTED] writes:
 
 CL On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
  
  But I am wondering what your plans are to handle renames---or
  does git already represent them?
  
 
 CL Rename should just work.  It will create a new tree object and you
 CL will notice that in the entry that changed, the hash for the blob
 CL object is the same.
 
 Sorry, I was unclear.  But doesn't that imply that a SCM built
 on top of git storage needs to read all the commit and tree
 records up to the common ancestor to show tree diffs between two
 forked tree?
 
 I suspect that another problem is that noticing the move of the
 same SHA1 hash from one pathname to another and recognizing that
 as a rename would not always work in the real world, because
 sometimes people move files *and* make small changes at the same
 time.  If git is meant to be an intermediate format to suck
 existing kernel history out of BK so that the history can be
 converted for the next SCM chosen for the kernel work, I would
 imagine that there needs to be a way to represent such a case.
 Maybe convert a file rename as two git trees (one tree for pure
 move which immediately followed by another tree for edit) if it
 is not a pure move?
 

Git is not a SCM yet.  For the rename + change set it should internally
handle by pure rename only plus the extra delta. The current git don't
have per file change history. From git's point of view some file deleted
and the other file appeared with same content.

It is the top level SCM to handle that correctly.
Rename a directory will be even more fun.

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: Re: more git updates..

2005-04-10 Thread Christopher Li
On Sun, Apr 10, 2005 at 11:41:53AM +0200, Petr Baudis wrote:
 Dear diary, on Sun, Apr 10, 2005 at 07:53:40AM CEST, I got a letter
 where Christopher Li [EMAIL PROTECTED] told me that...
  On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
   
   But I am wondering what your plans are to handle renames---or
   does git already represent them?
  
  
  Rename should just work.  It will create a new tree object and you
  will notice that in the entry that changed, the hash for the blob
  object is the same.
 
 Which is of course wrong when you want to do proper merging, examine
 per-file history, etc. One solution which springs to my mind is to have
 a UUID accompany each blob and tree; that will take relatively lot of
 space though, and I'm not sure it is really worth it.

It should just use the rename + change two step then it is tractable
with git now.

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: more git updates..

2005-04-10 Thread Ralph Corderoy

Hi Paul,

 Ralph wrote:
  Watch out for when xargs invokes do_something more than once and the
  `' is parsed by a different one than the `'.
 
 It will take a pretty long list to do that.  It seems that GNU xargs
 on top of a Linux kernel has a 128 KByte ARG_MAX.

I didn't realise it was that long, but one pair of files to diff takes
128 bytes of that.

$ wc -c \E
 100664 aff074c63ac827801a7d02ff92781365957f1430 update-cache.c
 100664 3a672397164d5ff27a19a6888b578af96824ede7 update-cache.c
 E
128

So that's space for 1024 pairs.  (Doesn't envp take some up too?)  That
doesn't seem enough for diffs between revisions, but good enough for
most uses that people will get caught out when it fails.

$ bzip2 -dc patch-2.6.10.bz2 | grep -c '^diff '  
5384

Cheers,


Ralph.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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: scheduling with irqs disabled' when umounting NFS volume

2005-04-10 Thread Ingo Molnar

* Lee Revell [EMAIL PROTECTED] wrote:

 Kernel is 2.6.12-rc1-RT-V0.7.43-05.
 
 BUG: scheduling with irqs disabled: umount/0x/20612
 caller is schedule_timeout+0x63/0xc0
  [c01033d3] dump_stack+0x23/0x30 (20)
  [c02b4f5a] schedule+0xea/0x140 (36)
  [c02b5b23] schedule_timeout+0x63/0xc0 (64)
  [c02b5744] interruptible_sleep_on_timeout+0x74/0xe0 (64)
  [c01cf898] lockd_down+0xb8/0x140 (24)
  [c01c2137] nfs_kill_super+0x77/0x80 (16)
  [c016033c] deactivate_super+0x8c/0xb0 (28)
  [c0178bc1] sys_umount+0x41/0x90 (88)
  [c0178c2e] sys_oldumount+0x1e/0x20 (16)
  [c0102dee] syscall_call+0x7/0xb (-8124)

i've uploaded the -44-04 kernel, which should fix this bug.

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


Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07

2005-04-10 Thread Ingo Molnar

* Steven Rostedt [EMAIL PROTECTED] wrote:

   yeah - i think Andrew said that a global lock at that particular place 
   might not be that much of an issue.
  
  OK, I'll start stripping it out of my kernel today and make a clean
  patch for you.
 
 Ingo, I haven't forgotten about this, I just been heavily bug wacking 
 lately and just haven't had the time to do this.
 
 I've pulled out both the lock_bh_state and lock_bh_journal_head and 
 made them two global locks.  I haven't noticed any slowing down here, 
 but then again I haven't ran any real benchmarks.  There's a BH flag 
 set to know when the lock is pending on a specific buffer head.
 
 I don't know how acceptable this patch is. Take a look and if you have 
 any better ideas then let me know.  I prefer this patch over the 
 wait_on_bit patch I sent you earlier since this patch still accounts 
 for priority inheritance, as the wait_on_bits don't.

looks much cleaner than earlier ones. Would it be possible to make the 
locks per journal? I've applied it to the -44-05 kernel so that it gets 
some testing.

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


Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]

2005-04-10 Thread Evgeniy Polyakov
On Sun, 10 Apr 2005 19:52:54 +1000
Herbert Xu [EMAIL PROTECTED] wrote:

 Please add netdev to the CC list since this discussion pertains to
 the networking subsystem.
 
 Evgeniy Polyakov [EMAIL PROTECTED] wrote:
  
  User should not know about low-level transport - 
  it is like socket layer -  write only data and do not care about
  how it will be delivered.
 
 The delineation between transport and upper layer is fuzzy.
 In one situation the protocol might be transport and in another
 it could be above the transport.
 
 So I don't buy this argument.

Connector allows to hide transport layer completely - 
concider acrypto or superio - that subsystems do not know
about network, author of the temperature driver for superio
should not know how skb is allocated and processed, 
and acrypto is not network related system, so why
they should know about network API?
Why should they know what is skb, how it is allocated, 
why shared skb can not be used in netlink and so on?
Users of the connector are only cared about
destination ID and how to send/receive message.
And what to do if we do not want something like connector
to be used for userspace control - we need to create
each time new netlink socket unit, like kobject's one,
or netlink_ulog, we need to register it in netlink.h, 
where already there too many units.

  In the previous versions netlink group was assigned as incremented
  counter, 
  that was not convenient, but now we have 2-way ID, which is better
  from users point of view - idx is supposed to be major id, val - 
  some subsystem of that set.
 
 Actually netlink does let you bind to a specific ID.
 
 Of course you may argue that a single u32 is not enough.  However,
 nothing is stopping you from introducing netlink v2 that extends
 this.
 
 In fact this is my main gripe with your patch: Why aren't you
 extending netlink instead of hacking something on top of the existing
 netlink? If the extensions require breaking compatibility: Fine,
 you just need to call it netlink v2.

When connector was created in the middle of 2004, it's main aim
was allowing easy userspace control over netlink.
Creating it's own skb receive parser was acceptible for
one project, for two, but it is definitely not the solution
for general use. And also I think it is not so easy to include new
netlink family unit for some completely unrelated to network subsystem.

So I decided to create only one skb parser, and put all skb processing
in one place, so any user has to do only registration with it's 
own receive callback, and sending function.

Thus, transport layer was completely hidden from connector users,
there are no complex netlink macros there, no network API
and all complex related issues, no huge code duplication in each device,
which does not want to mess with 32/64 ioctl issues, but 
want easy userspace control.

Later connector was changed a bit to allow easy notification
ability and new bus was added.
Connector is the solution for d-bus related projects, since
all control is in one place, there are destination ID,
there is no complex API.

Concider the latest xfrm event changes - good that we already
have netlink socket there, but in each sending function 
[there are at least three new]
we have all those skb_alloc, skb_put, NLMSG_* and so on which are
absolutely identical.
According to names and structures itself, they are too close
to what connector is for, and how it is implemented, so we already
have several connectors in the tree, and do we really want 
to proceed with it all over the place?


 Cheers,
 -- 
 Visit Openswan at http://www.openswan.org/
 Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
 Home Page: http://gondor.apana.org.au/~herbert/
 PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] Priority Lists for the RT mutex

2005-04-10 Thread Ingo Molnar

* Daniel Walker [EMAIL PROTECTED] wrote:

 Description:
   This patch adds the priority list data structure from Inaky 
 Perez-Gonzalez to the Preempt Real-Time mutex.

ok, i've added this patch to the -45-00 release. It's looking good on my 
testsystems so far, but it will need some more testing i guess.

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


$B!y(B10000$B1_J,L5NA!y(B

2005-04-10 Thread info
$B###!V(B1$B1_!WJ,L5NA%]%$%s%HB#Dh%-%c%s%Z!%sB;\Cf!*###(B

$B$3$N=U$N=P2q$$$r6/NO$K;Y1g$7$^$9!*(B
$B:#$9$0EPO?$7$FD:$$$?J}$K$O!;O$a$K(B1$B1_J,$N%]%$%s%H$rL5NA$G:9$7e$2$^$9!*(B

$B!(B1$B1_L5NA%]%$%s%H$H?7$7$$=P2q$$(BGET$B!(B 
http://awg.qsv20.com/?springq

$B!zL5NA$GAjEvM7$Y$^$9$N$G@'Hs$*;n$72$5$$$Mv(B
$B!z;HMQ$7$F$_$F!V$3$l$O!*!W$H;W$C$FD:$$$?J}$N$_!VM-NA!W$X$*?J$_2$5$$!#(B

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


Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]

2005-04-10 Thread Kay Sievers
On Sun, 2005-04-10 at 14:32 +0400, Evgeniy Polyakov wrote:
 On Sun, 10 Apr 2005 19:52:54 +1000
 Herbert Xu [EMAIL PROTECTED] wrote:
  Evgeniy Polyakov [EMAIL PROTECTED] wrote:
   
   User should not know about low-level transport - 
   it is like socket layer -  write only data and do not care about
   how it will be delivered.
  
  The delineation between transport and upper layer is fuzzy.
  In one situation the protocol might be transport and in another
  it could be above the transport.
  
  So I don't buy this argument.
 
 Connector allows to hide transport layer completely - 
 concider acrypto or superio - that subsystems do not know
 about network, author of the temperature driver for superio
 should not know how skb is allocated and processed, 
 and acrypto is not network related system, so why
 they should know about network API?
 Why should they know what is skb, how it is allocated, 
 why shared skb can not be used in netlink and so on?
 Users of the connector are only cared about
 destination ID and how to send/receive message.
 And what to do if we do not want something like connector
 to be used for userspace control - we need to create
 each time new netlink socket unit, like kobject's one,
 or netlink_ulog, we need to register it in netlink.h, 
 where already there too many units.
 
   In the previous versions netlink group was assigned as incremented
   counter, 
   that was not convenient, but now we have 2-way ID, which is better
   from users point of view - idx is supposed to be major id, val - 
   some subsystem of that set.
  
  Actually netlink does let you bind to a specific ID.
  
  Of course you may argue that a single u32 is not enough.  However,
  nothing is stopping you from introducing netlink v2 that extends
  this.
  
  In fact this is my main gripe with your patch: Why aren't you
  extending netlink instead of hacking something on top of the existing
  netlink? If the extensions require breaking compatibility: Fine,
  you just need to call it netlink v2.
 
 When connector was created in the middle of 2004, it's main aim
 was allowing easy userspace control over netlink.
 Creating it's own skb receive parser was acceptible for
 one project, for two, but it is definitely not the solution
 for general use. And also I think it is not so easy to include new
 netlink family unit for some completely unrelated to network subsystem.
 
 So I decided to create only one skb parser, and put all skb processing
 in one place, so any user has to do only registration with it's 
 own receive callback, and sending function.

Sure, but that would apply the a generic netlink extension too, right?

 Thus, transport layer was completely hidden from connector users,
 there are no complex netlink macros there, no network API
 and all complex related issues, no huge code duplication in each device,
 which does not want to mess with 32/64 ioctl issues, but 
 want easy userspace control.

I don't see the need for unimplemented abstractions here. You can
replace a generic netlink-use just the same way as you can replace the
connector's own netlink code below the connector API. There is not much
difference.

 Later connector was changed a bit to allow easy notification
 ability and new bus was added.
 Connector is the solution for d-bus related projects, since
 all control is in one place, there are destination ID,
 there is no complex API.

Sorry, what does this have to do with DBUS?

 Concider the latest xfrm event changes - good that we already
 have netlink socket there, but in each sending function 
 [there are at least three new]
 we have all those skb_alloc, skb_put, NLMSG_* and so on which are
 absolutely identical.
 According to names and structures itself, they are too close
 to what connector is for, and how it is implemented, so we already
 have several connectors in the tree, and do we really want 
 to proceed with it all over the place?

That's not the point. Nobody asks to replace the whole connector by raw
netlink. But the message subscription and multicasting could be part of
the generic netlink framework. The connector API would  still be on-top
if it and nothing changes besides that we would have a nice low-level
api to use for other systems too.
The basic idea behind the connector as a nice generic framework for
netlink, as it fills the missing multicast case, while we already can do
singlecast and broadcast with netlink.
It is just the same way the kernel plays with other core functionality
too. If something is not represented in the vfs-layer your are asked to
add it to the generic part and not implement it privately for your
filesystem only.

Thanks,
Kay

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


Re: [PATCH] Priority Lists for the RT mutex

2005-04-10 Thread Ingo Molnar

* Sven-Thorsten Dietrich [EMAIL PROTECTED] wrote:

 On Fri, 2005-04-08 at 08:28 +0200, Ingo Molnar wrote:
  * Daniel Walker [EMAIL PROTECTED] wrote:
  
 This patch adds the priority list data structure from Inaky 
   Perez-Gonzalez to the Preempt Real-Time mutex.
  
  this one looks really clean.
  
  it makes me wonder, what is the current status of fusyn's? Such a light 
  datastructure would be much more mergeable upstream than the former 
  100-queues approach.
 
 Ingo,
 
 Joe Korty has been doing a lot of work on Fusyn recently.
 
 Fusyn is now a generic implementation, similar to the RT mutex. SMP 
 scalability is somewhat better for decoupled locks on PI (last I 
 checked). It has the extra bulk required to support user space.
 
 The major issue that concerns the Fusym and the real-time patch is 
 that merging the kernel portion of Fusyn creates a collision of 
 redundant PI implementations with respect to the RT mutex.

i'd not mind merging the extra bits to PREEMPT_RT to enable fusyn's, if 
they come in small, clean steps. E.g. Daniel's plist.h stuff was nice 
and clean.

 There are a few mistakes on the page, (RT mutex does not do priority 
 ceiling), but for the most part the info is current.

is priority ceiling coming in via some POSIX feature that fusyn's need
to address? What would be needed precisely - a way to set a priority for
a lock (independently of the owner's task priority), and let that
control the PI mechanism?

Unless i'm missing something, this could be implemented by detaching
lock-owner_prio from lock-owner - via e.g. negative values. Thus some
minimal code would check whether we need the owner's priority in the PI
logic, or the semaphore's own priority level.

i.e. this doesnt seem to really affect the core design of RT mutexes.

OTOH, deadlock detection is another issue. It's quite expensive and i'm 
not sure we want to make it a runtime thing. But for fusyn's deadlock 
detection and safe teardown on owner-exit is a must-have i suspect?

 If the RT mutex could be exposed in non PREEMPT_RT configurations, the 
 fulock portion could be superseded by the RT mutex, and the remaining 
 pieces merged in. Or vice versa.

sure, RT mutexes could be exposed in !PREEMPT_RT.

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


Proposal for shell-patch-format [was: Re: more git updates..]

2005-04-10 Thread Rutger Nijlunsing
On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote:
 Listing the file paths and their sigs included in a tree to make
 a snapshot of a tree state sounds fine, and diffing two trees by
 looking at the sigs between two such files sounds fine as well.
 
 But I am wondering what your plans are to handle renames---or
 does git already represent them?

git doesn't represent transitions (or deltas), but only state. So it's
not (much) more then a .tar file from version-management perspective;
the only difference being that a git-tree has a comment field and a
predecessor-reference, which are currently not used in determining the
'patch' between two trees.

Deltas are derived by comparing different versions and determining
the difference by reverse-engineering the differences which got us
from version A to version B.

Deltas are currently described as patch(1)es. Patches don't have the
concept of 'renaming', so even after determining that file X has been
renamed to Y, we have no container for this fact. A patch(1) only
contains local-file-edits: substitute lines by other lines.

Deltas are not needed to follow a tree; deltas are useful for merging
branches of versions, and for reviewing purposes. This is comparable
to using tar for version-management: it is very common to weekly tar
your current version of your project as a poor-mans-version management
for one-person one-project.

So what is needed is a way to represent deltas which can contain more
than only traditional patches. I would propose a simple format: 
the shell-script in a fixed-format.

Shell-patch format in EBNF:
  shellpatch ::= ( comment? command* )*
  comment ::= commentline+
The comments contains the text describing the function of the
patch following it.
  commentline ::= #  text
  command ::=
mv  pathname   pathname \n |
cp  filename   filename \n |
chmod  mode pathname \n |
patch __UNIQUE_STRING__\n patch __UNIQUE_STRING__\n
  (where UNIQUE_STRING must not be contained in patch)
  filename ::= pathname
(but pointing to a file)
  pathname ::= a pathname relative to '.';
escaping special characters the shell-way;
may not contain '..'.

Example:
  # Rename file b to a1, and change a line.
  mv b a1
  patch __END__
  *** a1  Sun Apr 10 11:43:37 2005
  --- a2  Sun Apr 10 11:43:41 2005
  ***
  *** 1,4 
1
2
  ! from
3
  --- 1,4 
1
2
  ! to
3
  __END__

Advantages:
  - ASCII!
  - a shell-patch is executable without extra tooling
  - a shell-patch is readable and therefore reviewable
  - a shell-patch is forward-compatible: a shell-patch acts
like a patch (since patch(1) ignores garbage around patch :),
but not backwards-compatible.
  - extensible
  - the heavy-lifting is done by 'patch'
Disadvantages:
  - no deltas for binary files

Open issues:
  - comment could be made more structured; maybe containing fields
like Sujbect:, Author:, Signed-By:, certificates, ...
(BitKeeper seems to be using #  field : value \n lines)
  - patch(1) doesn't know any directories. Should shell-patch
know directories? This implies commands working on directories to
(like directory renaming, mode changing, ...). Otherwise directories
are implicit (a file in a directories implies the existance of that
directory). Also implies mkdir and rmdir as shell-patch commands.
  - extra commands might be useful to conserve more state(changes):
ln -s  -- for symbolic links;
ln -- for hard links;
chown  -- for permissions;
chattr -- for storing extended attributes
touch  -- for setting timestamps (probably creation time only,
  since mtime is something git relies on)
...and for the really adventurous:
sed 's,fromstring,tostring,' -- for substitutions
  (this is something darcs supports, but which I think is too
   bothersome to use since it is difficult to reverse engineere
   from two random trees)
Why a fixed format at all?
  - This way, the executable shell-patch can be proven to be
harmless to the machine: 'rm -rf /' is a valid shell-script,
but not a valid shell-patch (since 'rm' is not valid command,
random flags like '-rf' are not supported, and '/' is an absolute
pathname.
  - A fixed format enables tooling to support such a patch format;
for example creating the reverse-patch, merging patches (yeah,
'cat' also merges patches...).

...what has this to do with git?  Not much and everything, depending
on how you look onto it. 'git' is 'tar', and 'shell-patch' is 'patch';
both orthogonal concepts but very usable in combination. We'll look at
getting from two git trees to a shell-patch.

Diffing the trees would not only look at the file and per file at the
hashes, but also the other way around: which hash values are used more
than once. For files with the same hash value, compare the contents
(and rest of attributes); this is needed since the mapping from file
contents to sha1 

Re: Kernel SCM saga..

2005-04-10 Thread Ingo Molnar

* David S. Miller [EMAIL PROTECTED] wrote:

 On Fri, 8 Apr 2005 22:45:18 -0700 (PDT)
 Linus Torvalds [EMAIL PROTECTED] wrote:
 
  Also, I don't want people editing repostitory files by hand. Sure, the 
  sha1 catches it, but still... I'd rather force the low-level ops to use 
  the proper helper routines. Which is why it's a raw zlib compressed blob, 
  not a gzipped file.
 
 I understand the arguments for compression, but I hate it for one
 simple reason: recovery is more difficult when you corrupt some
 file in your repository.
 
 It's happened to me more than once and I did lose data.
 
 Without compression, I might be able to recover if something
 causes a block of zeros to be written to the middle of some
 repository file.  With compression, you pretty much just lose.

that depends on how you compress. You are perfectly right that with 
default zlib compression, where you start the compression stream and 
stop it at the end of the file, recovery in case of damage is very hard 
for the portion that comes _after_ the damaged section. You'd have to 
reconstruct the compression state which is akin to breaking a key.

But with zlib you can 'flush' the compression state every couple of 
blocks and basically get the same recovery properties, at some very 
minimal extra space cost (because when you flush out compression state 
you get some extra padding bytes).

Flushing has another advantage as well: a small delta (even if it 
increases/decreases the file size!) in the middle of a larger file will 
still be compressed to the same output both before and after the change 
area (modulo flush block size), which rsync can pick up just fine. (IIRC 
that is one of the reasons why Debian, when compressing .deb's, does 
zlib-flushes every couple of blocks, so that rsync/apt-get can pick up 
partial .deb's as well.)

the zlib option is i think Z_PARTIAL_FLUSH, i'm using it in Tux to do 
chunks of compression. The flushing cost ismax 12 bytes or so, so if 
it's done every 4K we maximize the cost to 0.2%.

so flushing is both rsync-friendly and recovery-friendly.

(recovery isnt as simple as with plaintext, as you have to find the next 
'block' and the block length will be inevitably variable. But it should 
be pretty predictable, and tools might even exist.)

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 git updates..

2005-04-10 Thread tony . luck
handle by pure rename only plus the extra delta. The current git don't
have per file change history. From git's point of view some file deleted
and the other file appeared with same content.

It is the top level SCM to handle that correctly.
Rename a directory will be even more fun.

But from a git perspective it will be very efficient.  Imagine that
Linus decides to rename arch/i386 as arch/x86 ... at the git repository
level this just requires a changeset, a new top level tree, and a new
tree for the arch directory showing that i386 changed to x86.  That's
all ... every files below that didn't change, so the blobs for the files
are all the same.

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


Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]

2005-04-10 Thread Evgeniy Polyakov
On Sun, 10 Apr 2005 13:08:44 +0200
Kay Sievers [EMAIL PROTECTED] wrote:

 On Sun, 2005-04-10 at 14:32 +0400, Evgeniy Polyakov wrote:
  On Sun, 10 Apr 2005 19:52:54 +1000
  Herbert Xu [EMAIL PROTECTED] wrote:
   Evgeniy Polyakov [EMAIL PROTECTED] wrote:

User should not know about low-level transport - 
it is like socket layer -  write only data and do not care about
how it will be delivered.
   
   The delineation between transport and upper layer is fuzzy.
   In one situation the protocol might be transport and in another
   it could be above the transport.
   
   So I don't buy this argument.
  
  Connector allows to hide transport layer completely - 
  concider acrypto or superio - that subsystems do not know
  about network, author of the temperature driver for superio
  should not know how skb is allocated and processed, 
  and acrypto is not network related system, so why
  they should know about network API?
  Why should they know what is skb, how it is allocated, 
  why shared skb can not be used in netlink and so on?
  Users of the connector are only cared about
  destination ID and how to send/receive message.
  And what to do if we do not want something like connector
  to be used for userspace control - we need to create
  each time new netlink socket unit, like kobject's one,
  or netlink_ulog, we need to register it in netlink.h, 
  where already there too many units.
  
In the previous versions netlink group was assigned as incremented
counter, 
that was not convenient, but now we have 2-way ID, which is better
from users point of view - idx is supposed to be major id, val - 
some subsystem of that set.
   
   Actually netlink does let you bind to a specific ID.
   
   Of course you may argue that a single u32 is not enough.  However,
   nothing is stopping you from introducing netlink v2 that extends
   this.
   
   In fact this is my main gripe with your patch: Why aren't you
   extending netlink instead of hacking something on top of the existing
   netlink? If the extensions require breaking compatibility: Fine,
   you just need to call it netlink v2.
  
  When connector was created in the middle of 2004, it's main aim
  was allowing easy userspace control over netlink.
  Creating it's own skb receive parser was acceptible for
  one project, for two, but it is definitely not the solution
  for general use. And also I think it is not so easy to include new
  netlink family unit for some completely unrelated to network subsystem.
  
  So I decided to create only one skb parser, and put all skb processing
  in one place, so any user has to do only registration with it's 
  own receive callback, and sending function.
 
 Sure, but that would apply the a generic netlink extension too, right?

Sending is the only and not the most significant part of the connector.
Of course cn_netlink_send() can be split into prepare_send() and commit_send(),
where commit_send() will live in af_netlink.c and do 
allocation and so on.
But it will not change the fact, that kernel users still need
to allocate a netlink socket, register it's own family unit, and so on...

Direct netlink usage is like using raw socket or even tun/tap device for 
TCP/IP, 
noone use it in that way, although we can, but connector is like
using socket interface.

  Thus, transport layer was completely hidden from connector users,
  there are no complex netlink macros there, no network API
  and all complex related issues, no huge code duplication in each device,
  which does not want to mess with 32/64 ioctl issues, but 
  want easy userspace control.
 
 I don't see the need for unimplemented abstractions here. You can
 replace a generic netlink-use just the same way as you can replace the
 connector's own netlink code below the connector API. There is not much
 difference.

Kernel users do not want to implement it's own transport over netlink.
Socket allocation was changed in 2.5 - we could need to change
each driver that use it instead of changing only one place in connector.c
Abstration over netlink already implemented in connector and is used
in acrypto, superio and even kobject_uevent was changed to do it.

  Later connector was changed a bit to allow easy notification
  ability and new bus was added.
  Connector is the solution for d-bus related projects, since
  all control is in one place, there are destination ID,
  there is no complex API.
 
 Sorry, what does this have to do with DBUS?

Kernel now has only two ways to inform to userspace about it's things - 
kobject [uevent] and hotplug. There is inotify/dnotify too, but it is 
diferent in some way.

The second one is a huge monster that can not be used in embedded
systems, calling userspace process from inside the kernel is 
now very flexible way.
The first one has it's own socket, it's own protocol and infrastructure
based on strings.

What if we want to inform about some new event?
Should we use kobject_uevent mechanism? Not anything can 

Re: more git updates..

2005-04-10 Thread Ralph Corderoy

Hi,

Christopher Li wrote:
 On Sat, Apr 09, 2005 at 04:31:10PM -0700, Linus Torvalds wrote:
  NOTE! This means that each tree file basically tracks just a
  single directory. The old style of every file in one tree file
  still works, but fsck-cache will warn about it. Happily, the git
  archive itself doesn't have any subdirectories, so git itself is not
  impacted by it.
 
 That is really cool stuff. My way to read it, correct me if I am
 wrong, git is a user space version file system. tree -- directory
 and blob -- file.  commit to describe the version history.

See the Venti filesystem in Bell Labs's Plan 9 OS.  It too uses SHA-1.

http://www.cs.bell-labs.com/sys/doc/venti/venti.pdf

Abstract

This paper describes a network storage system, called Venti,
intended for archival data. In this system, a unique hash of a
block's contents acts as the block identifier for read and write
operations. This approach enforces a write-once policy, preventing
accidental or malicious destruction of data. In addition, duplicate
copies of a block can be coalesced, reducing the consumption of
storage and simplifying the implementation of clients. Venti is a
building block for constructing a variety of storage applications
such as logical backup, physical backup, and snapshot file systems.

We have built a prototype of the system and present some preliminary
performance results. The system uses magnetic disks as the storage
technology, resulting in an access time for archival data that is
comparable to non-archival data. The feasibility of the write-once
model for storage is demonstrated using data from over a decade's
use of two Plan 9 file systems. 

Cheers,


Ralph.

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


trigon3 driver memory leak - crash

2005-04-10 Thread Moritz Gartenmeister
hi all
it's my first post in this list, so please point me to another source of 
inspiration if needed.
i'm using a dell poweredge 2650 with four nic (two of them tg3). this server works as transparent 
bridge. (bridge code and netfilter).
currently i am running linux 2.6.11.6.

i observe a steady decrease of free memory and at the same time an increase of active memory 
/proc/meminfo. i stopped almost all services and unloaded most of the iptables-modules. and still 
there was this phenomenon. after a while the server crashes with help of netconsole i was able to 
fetch the latest messages (postet below). there was no unusual traffic or something wired in my 
logfiles. btw, the decrease doesn't not reache the bottom, i.e., there was still some memory free 
befor crash. the server was running perfectly with kernel 2.6.6.

is there an issue with trigon3 network cards?
regards
moritz
here the messages capturated by netcat from netconsole:
NETDEV WATCHDOG: eth2: transmit timed out
tg3: eth2: transmit timed out, resetting
tg3: tg3_stop_block timed out, ofs=2c00 enable_bit=2
tg3: tg3_stop_block timed out, ofs=3400 enable_bit=2
tg3: tg3_stop_block timed out, ofs=2400 enable_bit=2
tg3: tg3_stop_block timed out, ofs=1800 enable_bit=2
tg3: tg3_stop_block timed out, ofs=4800 enable_bit=2
tg3: eth2: Link is down.
br0: port 2(eth2) entering disabled state
tg3: eth2: Link is up at 100 Mbps, half duplex.
tg3: eth2: Flow control is off for TX and off for RX.
br0: port 2(eth2) entering learning state
br0: topology change detected, propagating
br0: port 2(eth2) entering forwarding state
Ebtables v2.0 registered
HTB: quantum of class 10033 is small. Consider r2q change.
oom-killer: gfp_mask=0xd0
DMA per-cpu:
cpu 0 hot: low 2, high 6, batch 1
cpu 0 cold: low 0, high 2, batch 1
cpu 1 hot: low 2, high 6, batch 1
cpu 1 cold: low 0, high 2, batch 1
cpu 2 hot: low 2, high 6, batch 1
cpu 2 cold: low 0, high 2, batch 1
cpu 3 hot: low 2, high 6, batch 1
cpu 3 cold: low 0, high 2, batch 1
Normal per-cpu:
cpu 0 hot: low 32, high 96, batch 16
cpu 0 cold: low 0, high 32, batch 16
cpu 1 hot: low 32, high 96, batch 16
cpu 1 cold: low 0, high 32, batch 16
cpu 2 hot: low 32, high 96, batch 16
cpu 2 cold: low 0, high 32, batch 16
cpu 3 hot: low 32, high 96, batch 16
cpu 3 cold: low 0, high 32, batch 16
HighMem per-cpu:
cpu 0 hot: low 32, high 96, batch 16
cpu 0 cold: low 0, high 32, batch 16
cpu 1 hot: low 32, high 96, batch 16
cpu 1 cold: low 0, high 32, batch 16
cpu 2 hot: low 32, high 96, batch 16
cpu 2 cold: low 0, high 32, batch 16
cpu 3 hot: low 32, high 96, batch 16
cpu 3 cold: low 0, high 32, batch 16
Free pages:  433920kB (420416kB HighMem)
Active:186580 inactive:1496 dirty:38836 writeback:0 unstable:0 free:108480 slab:218645 mapped:4893 
pagetables:131
DMA free:3696kB min:176kB low:220kB high:264kB active:0kB inactive:32kB present:16384kB 
pages_scanned:399 all_unreclaimable? yes
lowmem_reserve[]: 0 880 2031
Normal free:9808kB min:9820kB low:12272kB high:14728kB active:4kB inactive:108kB present:901120kB 
pages_scanned:14744 all_unreclaimable? yes
lowmem_reserve[]: 0 0 9215
HighMem free:420416kB min:512kB low:640kB high:768kB active:746316kB inactive:5844kB 
present:1179520kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 0*4kB 0*8kB 1*16kB 1*32kB 1*64kB 0*128kB 0*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 3696kB
Normal: 0*4kB 0*8kB 1*16kB 0*32kB 1*64kB 0*128kB 0*256kB 1*512kB 1*1024kB 0*2048kB 2*4096kB = 9808kB
HighMem: 0*4kB 18*8kB 63*16kB 6*32kB 4*64kB 2*128kB 1*256kB 1*512kB 2*1024kB 21*2048kB 91*4096kB = 
420416kB
Swap cache: add 0, delete 0, find 0/0, race 0+0
Free swap  = 979924kB
Total swap = 979924kB
Out of Memory: Killed process 13539 (apache).
oom-killer: gfp_mask=0xd0
DMA per-cpu:
cpu 0 hot: low 2, high 6, batch 1
cpu 0 cold: low 0, high 2, batch 1
cpu 1 hot: low 2, high 6, batch 1
cpu 1 cold: low 0, high 2, batch 1
cpu 2 hot: low 2, high 6, batch 1
cpu 2 cold: low 0, high 2, batch 1
cpu 3 hot: low 2, high 6, batch 1
cpu 3 cold: low 0, high 2, batch 1
Normal per-cpu:
cpu 0 hot: low 32, high 96, batch 16
cpu 0 cold: low 0, high 32, batch 16
cpu 1 hot: low 32, high 96, batch 16
cpu 1 cold: low 0, high 32, batch 16
cpu 2 hot: low 32, high 96, batch 16
cpu 2 cold: low 0, high 32, batch 16
cpu 3 hot: low 32, high 96, batch 16
cpu 3 cold: low 0, high 32, batch 16
HighMem per-cpu:
cpu 0 hot: low 32, high 96, batch 16
cpu 0 cold: low 0, high 32, batch 16
cpu 1 hot: low 32, high 96, batch 16
cpu 1 cold: low 0, high 32, batch 16
cpu 2 hot: low 32, high 96, batch 16
cpu 2 cold: low 0, high 32, batch 16
cpu 3 hot: low 32, high 96, batch 16
cpu 3 cold: low 0, high 32, batch 16

Free pages:  433920kB (420480kB HighMem)
Active:186531 inactive:1495 dirty:38835 writeback:0 unstable:0 free:108480 slab:218665 mapped:4837 
pagetables:125
DMA free:3696kB min:176kB low:220kB high:264kB active:0kB inactive:24kB present:16384kB 
pages_scanned:2265 all_unreclaimable? yes
lowmem_reserve[]: 0 880 2031
Normal 

Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]

2005-04-10 Thread Evgeniy Polyakov
On Sun, 10 Apr 2005 15:37:57 +0400
Evgeniy Polyakov [EMAIL PROTECTED] wrote:

 The second one is a huge monster that can not be used in embedded
 systems, calling userspace process from inside the kernel is 
 now very flexible way.

is NOT very flexible way...


Evgeniy Polyakov

Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 git updates..

2005-04-10 Thread tony . luck
In other words, each commit file is very small and cheap, but since 
almost every commit will also imply a totally new tree-file, git is 
going to have an overhead of half a megabyte per commit. Oops.

Damn, that's painful. I suspect I will have to change the format somehow.

Having dodged that bullet with the change to make tree files point at
other tree files ... here's another (potential) issue.

A changeset that touches just one file a few levels down from the top
of the tree (say arch/i386/kernel/setup.c) will make six new files in
the git repository (one for the changeset, four tree files, and a new
blob for the new version of the file). More complex changes make more
files ... but say the average is ten new files per changeset since most
changes touch few files.  With 60,000 changesets in the current tree, we
will start out our git repository with about 600,000 files.  Assuming
the first byte of the SHA1 hash is random, that means an average of 2343
files in each of the objects/xx directories.  Give it a few more years at
the current pace, and we'll have over 10,000 files per directory.  This
sounds like a lot to me ... but perhaps filesystems now handle large
directories enough better than they used to for this to not be a problem?

Or maybe the files should be named objects/xx/yy/?

-Tony
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 SCM saga..

2005-04-10 Thread Ingo Molnar

* Paul Jackson [EMAIL PROTECTED] wrote:

 These 16817 files consume:
 
   224 MBytes uncompressed and
95 MBytes compressed
 
 (using zlib's minigzip, on a 4 KB page reiserfs.)

that's a 42.4% compressed size. Using a (much) more CPU-intense 
compression method (bzip -9), the compressed size is down to 45 MBytes.  
(a ratio of 20.2%)

using default 'gzip' i get 57 MB compressed.

 Since each change will get its own copy of the file, multiplying these
 two sizes (224 and 95) by 12.2 changes per file means the disk cost
 would be:
 
   2.73 GByte uncompressed, or
   1.16 GBytes compressed.

with bzip2 -9 it would be 551 MBytes. It might as well be practical on 
faster CPUs, a full tree (224 MBytes, 45 MBytes compressed) decompresses 
in 24 seconds on a 3.4GHz P4 - single CPU. (and with dual core likely 
becoming the standard, we might as well divide that by two) With default 
gzip it's 3.3 seconds though, and that still compresses it down to 57 
MB.

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


r8169 native module problems on 2.6.11

2005-04-10 Thread TommyDrum
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello, I've got a problem with usrobotics r8169 based gigabit ethernet;
kernel module doesn't properly startup, with modprobe r8169; module gets
correctly loaded, but ifconfig doesn't see it, and startup scripts deny
existence of an eth0 dev; meanwhile the r8169 module taken from the
cdrom compiles installs and functions correctly; here's the modinfo for
both:
kernel native module:
author: Realtek and the Linux r8169 crew netdev@oss.sgi.com
description:RealTek RTL-8169 Gigabit Ethernet driver
parmtype:   media:array of int
parmtype:   rx_copybreak:int
parmtype:   use_dac:int
parm:   use_dac:Enable PCI DAC. Unsafe on 32 bit PCI slot.
license:GPL
version:2.2LK
vermagic:   2.6.11-gentoo-r5 preempt PENTIUMIII gcc-3.3
depends:
alias:  pci:v10ECd8169sv*sd*bc*sc*i*
alias:  pci:v1186d4300sv*sd*bc*sc*i*
srcversion: 017DC70C1E25F3AB2CA0324
USrobotics cdrom module:
author: Realtek
description:U.S. Robotics 10/100/1000 PCI NIC driver
license:GPL
vermagic:   2.6.11-gentoo-r5 preempt PENTIUMIII gcc-3.3
depends:
alias:  pci:v10ECd8169sv*sd*bc*sc*i*
alias:  pci:v16ECd0116sv*sd*bc*sc*i*
and dmesg for both:
kernel native:
ACPI: PCI interrupt :00:09.0[A] - GSI 11 (level, low) - IRQ 11
eth0: Identified chip type is 'RTL8169s/8110s'.
eth0: U.S. Robotics 10/100/1000 PCI NIC driver version 2.0 at
0xe08ee000, 00:c0:49:f2:86:1e, IRQ 11
eth0: Auto-negotiation Enabled.
USR module:
ACPI: PCI interrupt :00:09.0[A] - GSI 11 (level, low) - IRQ 11
eth0: Identified chip type is 'RTL8169s/8110s'.
eth0: U.S. Robotics 10/100/1000 PCI NIC driver version 2.0 at
0xe08e6000, 00:c0:49:f2:86:1e, IRQ 11
eth0: Auto-negotiation Enabled.
I don't understand exactly the difference between the two, thought I
could help by posting this fact. Please if you find it irrelevant don't
flame me, since it's my first post to the kernel mailing list, I'd
welcome any suggestions and I will try to post any other information you
request.
Keep on the good work,
Ciao!
Tommy
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCWRkRgpUvhTIUBAERApE1AJ9aju0Np0VWGD8ItP30fchnXSwSfQCeLbS4
1EimT1GM7TfC2yWrurNFg24=
=j5ge
-END PGP SIGNATURE-
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


PROBLEM: kernel 2.4 pdc202xx and kernel 2.6 pdc202xx_old Broken

2005-04-10 Thread joram.agten
Hello

please put me in CC

I'm using a pdc20262 promise utra66 controller to manage 4 HD's, all 30GB
and I put them in a software /dev/md/0 raid5 configuration

recently I upgraded my kernel to linux-2.6.11-gentoo-r4 and also
linux-2.6.11-gentoo-r5
and the raid array would go offline with dma timeouts when putting load to
it

Apr  9 23:30:15 vennen hde: DMA timeout error
Apr  9 23:30:15 vennen hde: dma timeout error: status=0x58 { DriveReady
SeekComplete DataRequest }
Apr  9 23:30:15 vennen 
Apr  9 23:30:15 vennen ide: failed opcode was: unknown
Apr  9 23:30:15 vennen hdh: dma_timer_expiry: dma status == 0x62
Apr  9 23:30:15 vennen hdh: DMA timeout error
Apr  9 23:30:15 vennen hdh: dma timeout error: status=0x58 { DriveReady
SeekComplete DataRequest }
Apr  9 23:30:15 vennen 
Apr  9 23:30:15 vennen ide: failed opcode was: unknown
Apr  9 23:30:15 vennen hdg: status timeout: status=0xd0 { Busy }
Apr  9 23:30:15 vennen 
Apr  9 23:30:15 vennen ide: failed opcode was: unknown
Apr  9 23:30:15 vennen hdg: DMA disabled
Apr  9 23:30:15 vennen PDC202XX: Secondary channel reset.
Apr  9 23:30:15 vennen PDC202XX: Primary channel reset.

in the beginning it was only with hde, so I suspected the disk, put it on
another controller, run a complete diskcheck on it (maxtor dos tool), no
problems found.
I attach it to the onboard motherboard controller and put it back in the
raid array
but again the raid array would fail, this time another disk.

If I boot again, and reinitialize the array, so that it starts building
again, it would fail quite fast
when not putting any load on the array it would just run fine

since I had installed the whole system from scratch I didn't know the exact
version of the previous kernel, so I went back to linux-2.4.20-gentoo-r33,
an here everything works
I also remember trying some more recent 2.4 kernel, but I do not recall the
exact version, there the same problem would manifest.

after some googling I found this thread: PDC202XX_OLD broken
http://www.ussg.iu.edu/hypermail/linux/kernel/0412.0/1277.html

this is almost the exact same behaviour
but in the thread it does not say if his problem is solved or not
the suggestion of  Bartlomiej Zolnierkiewicz  is present in my 2.6 kernel
images

same info is at http://users.pandora.be/gemma.joram/pdc202xx/pdc202xx.html
I also have sysinfo
http://users.pandora.be/gemma.joram/pdc202xx/pdc202xx_sysinfo.html
and log http://users.pandora.be/gemma.joram/pdc202xx/pdc202xx_log.html

hope this is enough.
I'l happily try more if you need more info.

greetings
joram



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


Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]

2005-04-10 Thread Thomas Graf
* Evgeniy Polyakov [EMAIL PROTECTED] 2005-04-10 15:37
 --- ./net/netlink/af_netlink.c.orig 2005-04-10 15:46:48.0 +0400
 +++ ./net/netlink/af_netlink.c  2005-04-10 15:47:04.0 +0400
 @@ -747,7 +747,7 @@
 if (p-exclude_sk == sk)
 goto out;
  
 -   if (nlk-pid == p-pid || !(nlk-groups  p-group))
 +   if (nlk-pid == p-pid || (nlk-groups != p-group))
 goto out;
  
 if (p-failure) {

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


Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]

2005-04-10 Thread Evgeniy Polyakov
On Sun, 10 Apr 2005 14:10:05 +0200
Thomas Graf [EMAIL PROTECTED] wrote:

 * Evgeniy Polyakov [EMAIL PROTECTED] 2005-04-10 15:37
  --- ./net/netlink/af_netlink.c.orig 2005-04-10 15:46:48.0 +0400
  +++ ./net/netlink/af_netlink.c  2005-04-10 15:47:04.0 +0400
  @@ -747,7 +747,7 @@
  if (p-exclude_sk == sk)
  goto out;
   
  -   if (nlk-pid == p-pid || !(nlk-groups  p-group))
  +   if (nlk-pid == p-pid || (nlk-groups != p-group))
  goto out;
   
  if (p-failure) {
 
 Not valid, would break RTMGRP_*.

Yes, it will break too many existing application, 
it would be new API, like do_one_broadcast_direct().
If I understand Kay right, it is what he needs
for the new multicast.

Evgeniy Polyakov

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


Re: PROBLEM: kernel 2.4 pdc202xx and kernel 2.6 pdc202xx_old Broken

2005-04-10 Thread Bartlomiej Zolnierkiewicz
Hi,

On Apr 10, 2005 2:12 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 Hello
 
 please put me in CC
 
 I'm using a pdc20262 promise utra66 controller to manage 4 HD's, all 30GB
 and I put them in a software /dev/md/0 raid5 configuration
 
 recently I upgraded my kernel to linux-2.6.11-gentoo-r4 and also
 linux-2.6.11-gentoo-r5
 and the raid array would go offline with dma timeouts when putting load to
 it
 
 Apr  9 23:30:15 vennen hde: DMA timeout error
 Apr  9 23:30:15 vennen hde: dma timeout error: status=0x58 { DriveReady
 SeekComplete DataRequest }
 Apr  9 23:30:15 vennen
 Apr  9 23:30:15 vennen ide: failed opcode was: unknown
 Apr  9 23:30:15 vennen hdh: dma_timer_expiry: dma status == 0x62
 Apr  9 23:30:15 vennen hdh: DMA timeout error
 Apr  9 23:30:15 vennen hdh: dma timeout error: status=0x58 { DriveReady
 SeekComplete DataRequest }
 Apr  9 23:30:15 vennen
 Apr  9 23:30:15 vennen ide: failed opcode was: unknown
 Apr  9 23:30:15 vennen hdg: status timeout: status=0xd0 { Busy }
 Apr  9 23:30:15 vennen
 Apr  9 23:30:15 vennen ide: failed opcode was: unknown
 Apr  9 23:30:15 vennen hdg: DMA disabled
 Apr  9 23:30:15 vennen PDC202XX: Secondary channel reset.
 Apr  9 23:30:15 vennen PDC202XX: Primary channel reset.

This is a buggy expiry handler but it gets triggered as a result of
earlier OOPS:

Apr  9 23:30:01 vennen Call Trace:
Apr  9 23:30:01 vennen [] _spin_lock+0x16/0x90
Apr  9 23:30:01 vennen [] _spin_unlock+0xd/0x30
Apr  9 23:30:01 vennen [] do_truncate+0x4a/0x70
Apr  9 23:30:01 vennen [] _spin_unlock_irqrestore+0xf/0x30
Apr  9 23:30:01 vennen [] do_coredump+0x1fd/0x216
Apr  9 23:30:01 vennen [] __dequeue_signal+0xf5/0x1b0
Apr  9 23:30:01 vennen [] dequeue_signal+0x35/0xd0
Apr  9 23:30:01 vennen [] get_signal_to_deliver+0x229/0x320
Apr  9 23:30:01 vennen [] do_signal+0x9b/0x130
Apr  9 23:30:01 vennen [] sys_rt_sigaction+0xaa/0xc0
Apr  9 23:30:01 vennen [] do_page_fault+0x0/0x5d5
Apr  9 23:30:01 vennen [] do_notify_resume+0x37/0x3c
Apr  9 23:30:01 vennen [] work_notifysig+0x13/0x15

which doesn't seem to be related to IDE in any way.

It would be useful if you pinpoint issue further to a specific kernel version.

Bartlomiej
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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.11.x: bootprompt: ALSA: no soundcard detected

2005-04-10 Thread ismail dönmez
That means you didn't load the correct module for your soundcard.


On Sun, 10 Apr 2005 10:16:49 +, Dennis Heuer [EMAIL PROTECTED] wrote:
 This doesn't help. Alsamixer prints:
 
 failure in snd_ctl_open: no such device
 
 Dennis

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


[PATCH] zero disk pages used by swsusp on resume

2005-04-10 Thread Andreas Steinmetz
It may not be desireable to leave swsusp saved pages on disk after
resume as they may contain sensitive data that was never intended to be
stored on disk in an way (e.g. in-kernel dm-crypt keys, mlocked pages).

The attached simple patch against 2.6.11.2 should fix this by zeroing
the swap pages after reading them.

The patch is by no means perfect. Especially it isn't invoked on error
conditions. However it seems to work during regular operation.

Note that it is not possible to do this from userspace in a performant
way, one has to zero the whole swap partition used for swsusp to achive
a similar effect which quite often means clearing 2GB instead of about a
few 100MB. The difference in speed and power consumption is important
especially for laptops when resuming on battery. The userspace method
also allows for a window in which at least some of the data may still be
read.
-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
--- linux-2.6.11.2/kernel/power/swsusp.c.ast2005-04-10 14:08:55.0 
+0200
+++ linux-2.6.11.2/kernel/power/swsusp.c2005-04-10 14:24:10.0 
+0200
@@ -112,6 +112,10 @@
 
 static struct swsusp_info swsusp_info;
 
+static struct swsusp_clear {
+   char zero[PAGE_SIZE];
+} __attribute__((packed, aligned(PAGE_SIZE))) swsusp_clear __initdata;
+
 /*
  * XXX: We try to keep some more pages free so that I/O operations succeed
  * without paging. Might this be more?
@@ -1169,6 +1173,29 @@
 
 }
 
+static int __init data_clear(void)
+{
+   struct pbe * p;
+   int error = 0;
+   int i;
+   int mod = nr_copy_pages / 100;
+
+   if (!mod)
+   mod = 1;
+
+   memset(swsusp_clear, 0, sizeof(swsusp_clear));
+
+   printk( Clearing disk data (%d pages): , nr_copy_pages );
+   for(i = 0, p = pagedir_nosave; i  nr_copy_pages  !error; i++, p++) {
+   if (!(i%mod))
+   printk( \b\b\b\b%3d%%, i / mod );
+   error = bio_write_page(swp_offset(p-swap_address),
+ (void *)swsusp_clear);
+   }
+   printk( %d done.\n,i);
+   return error;
+}
+
 extern dev_t __init name_to_dev_t(const char *line);
 
 static int __init read_pagedir(void)
@@ -1208,6 +1235,8 @@
return error;
if ((error = data_read()))
free_pages((unsigned long)pagedir_nosave, pagedir_order);
+   else
+   data_clear();
return error;
 }
 


Re: crash in entry.S restore_all, 2.6.12-rc2, x86, PAGEALLOC

2005-04-10 Thread Stas Sergeev
Hello.
Linus Torvalds wrote:
2. How can one be sure there are no more
of the like places where the stack is left
empty?
That's a good argument, and may be the strongest reason for _not_ doing 
the speculation. However, I don't think it really can happen anywhere 
else. 
OK, so how do you feel about the attached
patch? I understand that from some point
of view it may look like a hack, but at
the same time it:
1. Allows to preserve the valueable optimization
2. Works for NMIs
3. Doesn't care whether or not there are more
of the like instances where the stack is left
empty.
4. Seems to work for me without the crashes:) 

--- linux/arch/i386/kernel/process.c.old	2005-03-20 14:12:18.0 +0300
+++ linux/arch/i386/kernel/process.c	2005-04-10 16:54:39.0 +0400
@@ -394,7 +394,7 @@
 	childregs-esp = esp;
 
 	p-thread.esp = (unsigned long) childregs;
-	p-thread.esp0 = (unsigned long) (childregs+1);
+	p-thread.esp0 = (unsigned long) (childregs+1) - 8;
 
 	p-thread.eip = (unsigned long) ret_from_fork;
 



PROBLEM: AIPTEK input doesn`t register `device` `driver` section in sysfs (/sys/class/input/event#)

2005-04-10 Thread Viktor A. Danilov

PROBLEM: aiptek input doesn`t register `device`  `driver` section in sysfs 
(/sys/class/input/event#)
REASON: `dev` - field not filled...
SOLUTION: in linux/drivers/usb/input/aiptek.c write
aiptek-inputdev.dev = intf-dev;
before calling 
input_register_device(aiptek-inputdev);

PATCH:

--- linux/drivers/usb/input/aiptek.c.orig   2005-03-09 13:12:31.0 
+0500
+++ linux/drivers/usb/input/aiptek.c2005-04-10 18:39:59.0 +0600
@@ -2139,8 +2140,9 @@
aiptek-inputdev.id.bustype = BUS_USB;
aiptek-inputdev.id.vendor = le16_to_cpu(usbdev-descriptor.idVendor);
aiptek-inputdev.id.product = le16_to_cpu(usbdev-descriptor.idProduct);
aiptek-inputdev.id.version = le16_to_cpu(usbdev-descriptor.bcdDevice);
+  aiptek-inputdev.dev = intf-dev;

aiptek-usbdev = usbdev;
aiptek-ifnum = intf-altsetting[0].desc.bInterfaceNumber;
aiptek-inDelay = 0;



LINUX_VERSION:

[EMAIL PROTECTED]:/usr/src/linux/scripts$ ./ver_linux
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.

Linux viktor 2.6.11.5-C2H5OH #1 Fri Mar 25 15:29:27 YEKT 2005 i686 GNU/Linux

Gnu C  3.3.4
Gnu make   3.80
binutils   2.15
util-linux 2.12h
mount  2.12h
module-init-tools  3.1
e2fsprogs  1.35
reiserfsprogs  line
reiser4progs   line
pcmcia-cs  3.2.5
PPP2.4.2
Linux C Library2.3.2
Dynamic linker (ldd)   2.3.2
Procps 3.2.4
Net-tools  1.60
Console-tools  0.2.3
Sh-utils   5.2.1
udev   056
Modules Loaded i830 drm pcmcia smbfs pcspkr snd_intel8x0m aiptek usbhid 
uhci_hcd intel_agp agpgart 8139too crc32 yenta_socket rsrc_nonstatic 
pcmcia_core ehci_hcd snd_intel8x0 snd_ac97_codec snd_pcm_oss snd_mixer_oss 
snd_pcm snd_timer snd soundcore snd_page_alloc nls_koi8_r vfat fat eeprom evdev 
i2c_sensor i2c_i801 i2c_core ide_cd cdrom usbkbd usbcore psmouse 
speedstep_centrino freq_table



--- linux/drivers/usb/input/aiptek.c.orig	2005-03-09 13:12:31.0 +0500
+++ linux/drivers/usb/input/aiptek.c	2005-04-10 18:39:59.0 +0600
@@ -2139,8 +2140,9 @@
 	aiptek-inputdev.id.bustype = BUS_USB;
 	aiptek-inputdev.id.vendor = le16_to_cpu(usbdev-descriptor.idVendor);
 	aiptek-inputdev.id.product = le16_to_cpu(usbdev-descriptor.idProduct);
 	aiptek-inputdev.id.version = le16_to_cpu(usbdev-descriptor.bcdDevice);
+	aiptek-inputdev.dev = intf-dev;
 
 	aiptek-usbdev = usbdev;
 	aiptek-ifnum = intf-altsetting[0].desc.bInterfaceNumber;
 	aiptek-inDelay = 0;


Re: r8169 native module problems on 2.6.11

2005-04-10 Thread Francois Romieu
TommyDrum [EMAIL PROTECTED] :
[new brand of r8169 adapter coming into town]
 and dmesg for both:
 
 kernel native:
 
 ACPI: PCI interrupt :00:09.0[A] - GSI 11 (level, low) - IRQ 11
 eth0: Identified chip type is 'RTL8169s/8110s'.
 eth0: U.S. Robotics 10/100/1000 PCI NIC driver version 2.0 at
^^^
 0xe08ee000, 00:c0:49:f2:86:1e, IRQ 11
 eth0: Auto-negotiation Enabled.

Can you check that the message above is _really_ the output of your
native kernel ? I have not checked gentoo's sources but the real vanilla
kernel can not issue this string.

 USR module:
 
 ACPI: PCI interrupt :00:09.0[A] - GSI 11 (level, low) - IRQ 11
 eth0: Identified chip type is 'RTL8169s/8110s'.
 eth0: U.S. Robotics 10/100/1000 PCI NIC driver version 2.0 at
 0xe08e6000, 00:c0:49:f2:86:1e, IRQ 11
 eth0: Auto-negotiation Enabled.

 I don't understand exactly the difference between the two, thought I
 could help by posting this fact. Please if you find it irrelevant don't
 flame me, since it's my first post to the kernel mailing list, I'd
 welcome any suggestions and I will try to post any other information you
 request.

You can send for both working/non-working after module insertion (wait
for a few seconds):
- complete dmesg (the beginning of it could be in /var/log/dmesg or such)
- lspci -vx
- lsmod
- ifconfig -a
- ethtool eth0
- cat /proc/interrupts
- source code

Also:
- brand name of the motherboard
- the name given by USR to the adapter (check the box)

I do not mind if the info is mailed, available on some web site or stuffed
at bugzilla.kernel.org. Please Cc: netdev@oss.sgi.com on further messages.

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


Re: [RFC/Patch 2.6.11] Take control of PCI Master Abort Mode

2005-04-10 Thread Andi Kleen
Ross Biro [EMAIL PROTECTED] writes:

 I even have a single motherboard with both a device that cannot handle
 the target abort and an IDE controller that can handle the target
 abort behind the same bridge.  For this motherboard, I have to choose
 the lesser of two evils, network hiccups or potential data corruption.
 For the record, I have seen both occur.  Other people may make wish to
 make a different choice than we did, hence this patch allows the user
 to choose the mode at runtime.

I think it is totally wrong to make this Configs and boot options.
Nobody can do anything with such obscure boot configurations
and it is bad to require kernel recompiles for such things.

The right way to do this would be to have sysfs knobs that allow
to change these bits, and then let a user space tool change
it depending on PCI-ID. If the issue is critical enough
that it happens very often then it should be added to kernel
pci quirks - but again be unconditional.

-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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-mm2

2005-04-10 Thread Alexander Nyberg
 - Largeish x86_64 update

Hi Pavel

I'm playing a bit with suspend on smp, we need something like this:
As the cpu-mask is set to only this cpu _smp_processor_id() is safe.

Index: linux-2.6.11/kernel/power/smp.c
===
--- linux-2.6.11.orig/kernel/power/smp.c2005-04-10 09:43:13.0 
+0200
+++ linux-2.6.11/kernel/power/smp.c 2005-04-10 15:23:36.0 +0200
@@ -46,13 +46,13 @@
 
 void disable_nonboot_cpus(void)
 {
-   printk(Freezing CPUs (at %d), smp_processor_id());
oldmask = current-cpus_allowed;
set_cpus_allowed(current, cpumask_of_cpu(0));
+   printk(Freezing CPUs (at %d), _smp_processor_id());
current-state = TASK_INTERRUPTIBLE;
schedule_timeout(HZ);
printk(...);
-   BUG_ON(smp_processor_id() != 0);
+   BUG_ON(_smp_processor_id() != 0);
 
/* FIXME: for this to work, all the CPUs must be running
 * idle thread (or we deadlock). Is that guaranteed? */


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

2005-04-10 Thread David Roundy
On Sun, Apr 10, 2005 at 11:24:07AM +0200, Giuseppe Bilotta wrote:
 On Sat, 9 Apr 2005 12:17:58 -0400, David Roundy wrote:
 
  I've recently made some improvements recently which will reduce the
  memory use
 
 Does this include check for redundancy? ;)

Yeah, the only catch is that if the redundancy checks fail, we now may
leave the repository in an inconsistent, but repairable, state.  (Only a
cache of the pristine tree is affected.)  The recent improvements mostly
came by increasing the laziness of a few operations, which meant we don't
need to store the entire parsed tree (or parsed patch) in memory for
certain operations.
-- 
David Roundy
http://www.darcs.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: [RFC] Add support for semaphore-like structure with support for asynchronous I/O

2005-04-10 Thread Suparna Bhattacharya


On Fri, Apr 08, 2005 at 07:31:46PM -0400, Trond Myklebust wrote:
 fr den 08.04.2005 Klokka 18:39 (-0400) skreiv Benjamin LaHaise:
 
  On the aio side of things, I introduced the owner field in the mutex (as 
  opposed to the flag in Trond's iosem) for the next patch in the series to 
  enable something like the following api:
  
  int aio_lock_mutex(struct mutex *lock, struct iocb *iocb);
 
 Any chance of a more generic interface too?
 
 iocbs are fairly high level objects, and so I do not see them helping to
 resolve low level filesystem problems such as the NFSv4 state cleanup.

My preferred approach would be to make the wait queue element the
primitive, rather than the iocb, precisely for this reason.

Guess its time for me to repost my aio-wait-bit based patch set - it
doesn't cover the async semaphores bit, but should indicate the general
direction of thinking.

I still need to look at Ben's patches though.

Regards
Suparna

 
 Cheers,
   Trond
 
 -- 
 Trond Myklebust [EMAIL PROTECTED]
 
 --
 To unsubscribe, send a message with 'unsubscribe linux-aio' in
 the body to [EMAIL PROTECTED]  For more info on Linux AIO,
 see: http://www.kvack.org/aio/
 Don't email: a href=mailto:[EMAIL PROTECTED][EMAIL PROTECTED]/a

-- 
Suparna Bhattacharya ([EMAIL PROTECTED])
Linux Technology Center
IBM Software Lab, India

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


Re: unregister_netdevice(): negative refcnt, suggest patch against 2.6.11

2005-04-10 Thread Felix Palmen
* Felix M. Palmen [EMAIL PROTECTED] [20050410 11:16]:
 So I assume there is a problem in the appletalk code, but I didn't try
 reproducing that on other systems so far.

I've now tested this issue on a vanilla 2.6.11.7 kernel. I only applied
my own patch from the previous post so that I am able to shut down the
computer cleanly. So I did the following:

- boot 2.6.11.7
- create a tap device with 'openvpn --mktun --dev tap0'
- create /etc/netatalk/atalkd.conf with a single line 'tap0'
- launch atalkd, wait.
- stop atalkd.
- destroy tap device with 'openvpn --rmtun --dev tap0'

refcnt was -256, very strange.

Would you consider my patch harmful? I intend using it for now, because
otherwise, my system won't shut down cleanly any more...

Greets, Felix

PS: Please CC replies to me.

-- 
 | /\   ASCII Ribbon   | Felix M. Palmen (Zirias)http://zirias.ath.cx/ |
 | \ / Campaign Against | [EMAIL PROTECTED]  encrypted mail welcome |
 |  XHTML In Mail   | PGP key: http://zirias.ath.cx/pub.txt |
 | / \ And News | ED9B 62D0 BE39 32F9 2488 5D0C 8177 9D80 5ECF F683 |


signature.asc
Description: Digital signature


Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]

2005-04-10 Thread jamal
Evgeniy,

Please crosspost on netdev - you should know that by now;-

I actually disagreee with Herbert on this. Theres definetely good
need to have a more usable messaging system that rides on top of
netlink. It is not that netlink cant be extended (I actually think thats
a separate topic) - its just that its usability curve is too high.
Thats what the original motivation for konnector was. To make it easy
for joe dumbass. And i think if konnector sticks to just doing that it
will end up being valuable.

I do think (and ive said this before) that Evgeniy is pushing it
by going beyond this simple agenda/focus. Unfortunately, I actually dont
think he is listening _at all_ on this specific issue. 

Evgeniy, just stick to the original focus and if it is accepted and
understood then lets move on to adding new features. Otherwise the
result of you adding yet one more feature for CBUS or whatever is
clearly to question what the original motivation was. And i dont think
you are able to add any other points to justify the existence of any new
konnector feature other than describe the original goals. At least thats
what i saw reading this thread. 
Otherwise if you really dont know what you want yet lets just pull this
whole thing out IMO.

cheers,
jamal

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


Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]

2005-04-10 Thread James Morris
On 10 Apr 2005, jamal wrote:

 Thats what the original motivation for konnector was. To make it easy
 for joe dumbass.

Who you really want writing kernel code :-)


- James
-- 
James Morris
[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] zero disk pages used by swsusp on resume

2005-04-10 Thread Pavel Machek
Hi! What about doing it right? Encrypt it with symmetric cypher and store key 
in suspend header. That way key is removed automagically while fixing 
signatures. No need to clear anythink. OTOH we may want to dm-crypt whole swap 
partition. You could still store key in header... --p

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


Re: [patch] Real-Time Preemption, -RT-2.6.12-rc1-V0.7.41-07

2005-04-10 Thread Steven Rostedt
On Sun, 2005-04-10 at 12:31 +0200, Ingo Molnar wrote:

 looks much cleaner than earlier ones. Would it be possible to make the 
 locks per journal? [...]

I've already looked into doing this, but it would be much more intrusive
to implement.  The problem lies where these locks are called with only
the buffer head as a reference. The locks are used to attach or detach
the buffer head from a journal or just see if it is already attached.
So having the lock with the journal is difficult since you need to take
the lock sometimes before you know which journal is needed.  I'm sure
this is possible but it will need modifying the code where the locks are
called instead of just replacing the contents of the lock function.
Maybe with the help of Stephen Tweedie, this can be done. But what I
gave you was the cleanest and most reliable solution currently, without
changing anything but the functions to take the locks.

-- Steve


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

2005-04-10 Thread Pavel Machek
Hi! The patch is ok, but this should be rewriten to use cpu hotplug instead. I 
have some patches but they need more testing. --p

-- pavel. Sent from  mobile phone. Sorry for poor formatting.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] zero disk pages used by swsusp on resume

2005-04-10 Thread Andreas Steinmetz
[reformatted]

Pavel Machek wrote:
 Hi! What about doing it right? Encrypt it with symmetric cypher
 and store key in suspend header. That way key is removed automagically
 while fixing signatures. No need to clear anythink.

Good idea. I'll have a look though it will take a while (busy with my job).

 OTOH we may want to dm-crypt whole swap partition.

This would leave the problem that the in-kernel data would be accessible
on the swap device after resume.

 You could still store key in header... --p

Which is the good idea from step one above.

 
 -- pavel. Sent from  mobile phone. Sorry for poor formatting.

The only remark I do have here is that swsusp would then depend on
crypto so the swsusp encryption should be a config option.
-- 
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/


[PATCH] h8300 header update

2005-04-10 Thread Yoshinori Sato
- page.h: fix build error
- unistd.h: _syscall macro cleanup.

plase apply.

-- 
Yoshinori Sato
[EMAIL PROTECTED]

--- 1.3/include/asm-h8300/page.h2005-01-31 15:20:53 +09:00
+++ edited/include/asm-h8300/page.h 2005-04-01 23:41:26 +09:00
@@ -79,7 +79,7 @@
 
 #ifndef __ASSEMBLY__
 
-#define __pa(vaddr)virt_to_phys((void *)vaddr)
+#define __pa(vaddr)virt_to_phys(vaddr)
 #define __va(paddr)phys_to_virt((unsigned long)paddr)
 
 #define virt_to_pfn(kaddr) (__pa(kaddr)  PAGE_SHIFT)
@@ -89,7 +89,7 @@
 #define virt_to_page(addr) (mem_map + (((unsigned long)(addr)-PAGE_OFFSET) 
 PAGE_SHIFT))
 #define virt_to_page(addr) (mem_map + (((unsigned long)(addr)-PAGE_OFFSET) 
 PAGE_SHIFT))
 #define page_to_virt(page) page) - mem_map)  PAGE_SHIFT) + 
PAGE_OFFSET)
-#define VALID_PAGE(page)   ((page - mem_map)  max_mapnr)
+#define pfn_valid(page)(page  max_mapnr)
 
 #define pfn_to_page(pfn)   virt_to_page(pfn_to_virt(pfn))
 #define page_to_pfn(page)  virt_to_pfn(page_to_virt(page))
= include/asm-h8300/unistd.h 1.9 vs edited =
--- 1.9/include/asm-h8300/unistd.h  2005-01-13 01:57:21 +09:00
+++ edited/include/asm-h8300/unistd.h   2005-04-11 00:16:07 +09:00
@@ -310,163 +310,155 @@
return (type) (res); \
 } while (0)
 
-#define _syscall0(type, name)  
\
-type name(void)
\
-{  
\
-  register long __res __asm__(er0);  
\
-  __asm__ __volatile__ (mov.l %1,er0\n\t 
\
-   trapa  #0\n\t 
\
-   : =r (__res)  
\
-   : ir (__NR_##name)
\
-   : cc);
\
-  if ((unsigned long)(__res) = (unsigned long)(-125)) {   
\
-errno = -__res;
\
-__res = -1;
\
-  }
\
-  return (type)__res;  
\
-}
-
-#define _syscall1(type, name, atype, a)
\
-type name(atype a) 
\
-{  
\
-  register long __res __asm__(er0);  
\
-  __asm__ __volatile__ (mov.l %2, er1\n\t
\
-   mov.l  %1, er0\n\t
\
-   trapa  #0\n\t 
\
-   : =r (__res)  
\
-   : ir (__NR_##name),   
\
- g ((long)a) 
\
-   : cc, er1); \
-  if ((unsigned long)(__res) = (unsigned long)(-125)) {   
\
-errno = -__res;
\
-__res = -1;
\
-  }
\
-  return (type)__res;  
\
-}
-
-#define _syscall2(type, name, atype, a, btype, b)  
\
-type name(atype a, btype b)
\
-{  
\
-  register long __res __asm__(er0);  
\
-  __asm__ __volatile__ (mov.l %3, er2\n\t
\
-   mov.l  %2, er1\n\t
\
-   mov.l  %1, er0\n\t
\
-   trapa  #0\n\t 
\
-   : =r (__res)  
\
-   : ir (__NR_##name),   
\
- g ((long)a),
\
- g ((long)b) 
\
-   : cc, er1, er2);  \
-  if ((unsigned long)(__res) = (unsigned long)(-125)) {   
\
-errno = -__res;

Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]

2005-04-10 Thread jamal
On Sun, 2005-04-10 at 10:56, James Morris wrote:
 On 10 Apr 2005, jamal wrote:
 
  Thats what the original motivation for konnector was. To make it easy
  for joe dumbass.
 
 Who you really want writing kernel code :-)

Ok, let me take that back then ;-
The value is in allowing people who are kernel hackers that are trying
to focus on an entirely different problem to not really know much about
the internals of the messaging subsystem (if you wanna call netlink
that). A good example will be the fork patches which were posted
recently.

cheers,
jamal

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] Simple privacy enhancement for /proc/pid

2005-04-10 Thread Rene Scharfe
Hi all,

sorry it took me so long before offering another patch for restricting
/proc permissions.  Real life kept on intervening.

Albert, allowing access based on tty sounds nice, but it _is_ expansive.
More importantly, perhaps, it would virtualize /proc: every user would
see different permissions for certain files in there.  That's too comlex
for my taste.

My previous patchset was complex, too, given its simple purpose: to
restrict regular users from spying on each other.  So let's cut out what
we don't really need.

First, configuring via kernel parameters is sufficient.  It simplifies
implementation a lot because we know the settings cannot change.  And we
don't need the added flexibility of sysctls anyway -- I assume these
parameters are set at installation time and never touched again.

Then I suppose we don't need to be able to fine-tune the permissions for
each file in /proc/pid/.  All that we need is a distinction between
normal users (which are to be restricted) and admins (which need to
see everything).

In a previous mail I asked how to identify tasks every user should be
able to see details of.  Bodo came up with some nice ideas, like
checking if parent is init(1) to catch daemons and identifying kernel
threads by their unique ability to block SIGKILL.  That's simple and
catches most interesting processes; it fails to catch the children of
forking servers like apache and, notably, sshd, however.

I have another idea: let's keep the details of _every_ process owned by
user root readable by anyone.  The superuser doesn't deserve privacy.
No new hole is opened, as root's files don't change their permissions.
Admittedly, admins are people, too, and they can get privacy, too -- but
only if they use their own regular user ID.  They should be doing that
anyway.

This catches the _important_ processes, those used to provide logins
(and then some :-).  Tools like w, who and pstree keep on working just
fine, even for SSH logins.

This patch introduces two kernel parameters: proc.privacy and proc.gid.
The group ID attribute of all files below /proc/pid is set to
proc.gid, but only if you activate the feature by setting proc.privacy
to a non-zero value.  1 means to allow all users to see root's process
details and hide everyone else's (as described above), 2 gives you the
shared nothing semantics where even root's processes are cloaked.

Patch is against 2.6.12-rc2-mm2, please give it a try and tell me how
you like it.

Thanks,
Rene



diff -pur l1/Documentation/kernel-parameters.txt 
l2/Documentation/kernel-parameters.txt
--- l1/Documentation/kernel-parameters.txt  2005-04-07 23:18:36.0 
+0200
+++ l2/Documentation/kernel-parameters.txt  2005-04-10 13:52:56.0 
+0200
@@ -1116,16 +1116,25 @@ running once the system is up.
[ISAPNP] Exclude memory regions for the 
autoconfiguration
Ranges are in pairs (memory base and size).
 
+   processor.max_cstate=   [HW, ACPI]
+   Limit processor to maximum C-state
+   max_cstate=9 overrides any DMI blacklist limit.
+
+   proc.gid=   [KNL] Group ID attribute of the files in /proc/pid,
+   default is 0.  This parameter is ignored if
+   proc.privacy is 0.
+   proc.privacy=   [KNL] Take away permissions for files in /proc/pid
+   from world (think chmod o-rwx) and apply proc.gid
+   setting.  0 = disabled (default), 1 = restrict access
+   to all process details except those having a uid of 0,
+   2 = restrict access to all process details.
+
profile=[KNL] Enable kernel profiling via /proc/profile
{ schedule | number }
(param: schedule - profile schedule points}
(param: profile step/bucket size as a power of 2 for
statistical time based profiling)
 
-   processor.max_cstate=   [HW, ACPI]
-   Limit processor to maximum C-state
-   max_cstate=9 overrides any DMI blacklist limit.
-
prompt_ramdisk= [RAM] List of RAM disks to prompt for floppy disk
before loading.
See Documentation/ramdisk.txt.
diff -pur l1/fs/proc/base.c l2/fs/proc/base.c
--- l1/fs/proc/base.c   2005-04-07 23:18:47.0 +0200
+++ l2/fs/proc/base.c   2005-04-10 14:00:28.0 +0200
@@ -35,8 +35,18 @@
 #include linux/seccomp.h
 #include linux/cpuset.h
 #include linux/audit.h
+#include linux/module.h
+#include linux/moduleparam.h
 #include internal.h
 
+static int proc_privacy;
+module_param_named(privacy, proc_privacy, uint, 0);
+MODULE_PARM_DESC(umask, restrict permissions of files in /proc/pid);
+
+static gid_t proc_gid;
+module_param_named(gid, proc_gid, uint, 0);
+MODULE_PARM_DESC(gid, process admin group);
+
 /*
  * For hysterical 

Re: more git updates..

2005-04-10 Thread Linus Torvalds


On Sun, 10 Apr 2005, Junio C Hamano wrote:
 
 But I am wondering what your plans are to handle renames---or
 does git already represent them?

You can represent renames on top of git - git itself really doesn't care.  
In many ways you can just see git as a filesystem - it's content-
addressable, and it has a notion of versioning, but I really really
designed it coming at the problem from the viewpoint of a _filesystem_
person (hey, kernels is what I do), and I actually have absolutely _zero_
interest in creating a traditional SCM system.

So to take renaming a file as an example - why do you actually want to 
track renames? In traditional SCM's, you do it for two reasons:

 - space efficiency. Most SCM's are based on describing changes to a file, 
   and compress the data by doing revisions on the same file. In order to 
   continue that process past a rename, such an SCM _has_ to track 
   renames, or lose the delta-based approach.

   The most trivial example of this is diff, ie a rename ends up 
   generating a _huge_ diff unless you track the rename explicitly.

   GIT doesn't care. There is _zero_ space efficiency in trying to track 
   renames. In fact, it would add overhead to the system, not lessen it. 
   That's because GIT fundamentally doesn't do the delta-within-a-file  
   model.

 - annotate/blame. This is a valid concern, but the fact is, I never use 
   it. It may be a deficiency of mine, but I simply don't do the per-line 
   thing when I debug or try to find who was responsible. I do blame on 
   a much bigger-picture level, and I personally believe (pretty strongly) 
   that per-line annotations are not actually a good thing - they come not 
   because people _want_ to do things at that low level, but because 
   historically, you didn't _have_ the bigger-picture thing.

   In other words, pretty much every SCM out there is based on SCCS 
   mentally, even if not in any other model. That's why people think 
   per-line blame is important - you have that mental model. 

So consider me deficient, or consider me radical. It boils down to the 
same thing. Renames don't matter. 

That said, if somebody wants to create a _real_ SCM (rather than my notion
of a pure content tracker) on top of GIT, you probably could fairly easily
do so by imposing a few limitations on a higher level. For example, most
SCM's that track renames require that the user _tell_ them about the
renames: you do a bk mv or a svn rename or something.

If you want to do the same on top of GIT, then you should think of GIT as
what it is: GIT just tracks contents. It's a filesystem - although a
fairly strange one. How would you track renames on top of that? Easy: add
your own fields to the GIT revision messages: GIT enforces the header, but
you can add anything you want to the free-form part that follows it. 

Same goes for any other information where you care about what happens 
within a file. GIT simply doesn't track it. You can build things on top 
of GIT if you want to, though. They may not be as efficient as they would 
be if they were built _into_ GIT, but on the other hand GIT does a lot of 
other things a hell of a lot faster thanks to it's design.

So whether you agree with the things that _I_ consider important probably
depends on how you work. The real downside of GIT may be that _my_ way of 
doing things is quite possibly very rare.

But it clearly is the only right way. The fact that everybody else does it 
some other way only means that they are wrong.

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


Re: more git updates..

2005-04-10 Thread Linus Torvalds


On Sat, 9 Apr 2005 [EMAIL PROTECTED] wrote:

 With 60,000 changesets in the current tree, we will start out our git
 repository with about 600,000 files.  Assuming the first byte of the
 SHA1 hash is random, that means an average of 2343 files in each of the
 objects/xx directories.  Give it a few more years at the current pace,
 and we'll have over 10,000 files per directory.  This sounds like a lot
 to me ... but perhaps filesystems now handle large directories enough
 better than they used to for this to not be a problem?

The good news is that git itself doesn't really care. I think it's
literally _one_ function (get_sha1_filename()) that you need to change,
and then you need to write a small script that moves files around, and
you're really much done.

Also, I did actually debate that issue with myself, and decided that even
if we do have tons of files per directory, git doesn't much care. The
reason? Git never _searches_ for them. Assuming you have enough memory to
cache the tree, you just end up doing a lookup, and inside the kernel
that's done using an efficient hash, which doesn't actually care _at_all_
about how many files there are per directory.

So I was for a while debating having a totally flat directory space, but 
since there are _some_ downsides (linear lookup for cold-cache, and just 
that ls -l ends up being O(n**2) and things), I decided that a single 
fan-out is probably a good idea.

 Or maybe the files should be named objects/xx/yy/?

Hey, I may end up being wrong, and yes, maybe I should have done a 
two-level one. The good news is that we can trivially fix it later (even 
dynamically - we can make the sha1 object tree layout be a per-tree 
config option, and there would be no real issue, so you could make small 
projects use a flat version and big projects use a very deep structure 
etc). You'd just have to script some renames to move the files around..

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


[ANNOUNCE] git-pasky-0.1

2005-04-10 Thread Petr Baudis
  Hello,

  so I released git-pasky-0.1, my set of patches and scripts upon
Linus' git, aimed at human usability and to an extent a SCM-like usage.

  You can get it at

http://pasky.or.cz/~pasky/dev/git/git-pasky-base.tar.bz2

and after unpacking and building (make) do

git pull pasky

to get the latest changes from my branch. If you already have some git
from my branch which can do pulling, you can bring yourself up to date
by doing just

gitpull.sh pasky

(but this style of usage is deprecated now). Please see the README for
some details regarding usage etc. You can find the changes from the last
announcement in the ChangeLog (the previous announcement corresponds to
commit id 5125d089ad862f16a306b4942155092e1dce1c2d). The most important
change is probably recursive diff addition, and making git ignore the
nsec of ctime and mtime, since it is totally unreliable and likes to
taint random files as modified.

  My near future plans include especially some merge support; I think it
should be rather easy, actually. I'll also add some simple tagging
mechanism. I've decided to postpone the file moving detection, since
there's no big demand for it now. ;-)

  I will also need to do more testing on the linux kernel tree.
Committing patch-2.6.7 on 2.6.6 kernel and then diffing results in

$ time gitdiff.sh `parent-id` `tree-id` p
real5m37.434s
user1m27.113s
sys 2m41.036s

which is pretty horrible, it seems to me. Any benchmarking help is of
course welcomed, as well as any other feedback.

  BTW, what would be the best (most complete) source for the BK tree
metadata? Should I dig it from the BKCVS gateway, or is there a better
source? Where did you get the sparse git database from, Linus? (BTW, it
would be nice to get sparse.git with the directories as separate.)

  Have fun,

-- 
Petr Pasky Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2005-04-10 Thread Derek Cheung
Enclosed please find the updated patch that incorporates changes for all
the comments I received.

The volatile declaration in the m528xsim.h is needed because the
declaration refers to the ColdFire 5282 register mapping. The volatile
declaration is actually not needed in my I2C driver but someone may
include the m528xsim.h file in his/her applications and we need to force
the compiler not to do any optimization on the register mapping.

Regards
Derek

-Original Message-
From: Randy.Dunlap [mailto:[EMAIL PROTECTED] 
Sent: April 5, 2005 11:44 PM
To: Derek Cheung
Cc: 'Andrew Morton'; [EMAIL PROTECTED]; Linux-kernel@vger.kernel.org
Subject: Re: [PATCH] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU

Derek Cheung wrote:
 
 Below please find the patch file I diff against Linux 2.6.11.6. It
 contains the I2C adaptor for ColdFire 5282 CPU. Since most ColdFire
 CPU
 shares the same I2C register set, the code can be easily adopted for
 other ColdFire CPUs for I2C operations.

 I have tested the code on a ColdFire 5282Lite CPU board
 (http://www.axman.com/Pages/cml-5282LITE.html) running uClinux 2.6.9
 with LM75 and DS1621 temperature sensor chips. As advised by David
 McCullough, the code will be incorporated in the next uClinux
 release.
 
 The patch contains:

 linux/drivers/i2c/busses
  i2c-mcf5282.c (new file)

Limit source code lines to 80 characters (including comment lines).

+static int mcf5282_read_data():

+   if (ackType == NACK)
+   *MCF5282_I2C_I2CR |= MCF5282_I2C_I2CR_TXAK; //
generate NA
+   else
+*MCF5282_I2C_I2CR = ~MCF5282_I2C_I2CR_TXAK;// 
generate ACK

The 2 assignments above should begin in the same column.
Also, kernel comment style is C /* ... */, not C++ (or C99) // style.

+if (timeout = 0)
+printk(%s - I2C IIF never set. Timeout is %d \n, 
__FUNCTION__, timeout);

All printk() calls should have a KERN_WARNING or KERN_ERR or
KERN_DEBUG level used in it...

+   if (timeout = 0 )

No space before the closing ')'.

+static int mcf5282_write_data():

+if (timeout =0)
should be (add a space)
+if (timeout = 0)

+   if (timeout = 0 )
Drop space before ')'

Drop the debugging printk's and DEREK_DEBUG blocks.

+switch (size) {
+case I2C_SMBUS_QUICK:
We usually don't indent the 'case' line to save one indent level.
It helps when using 8-space tabs.

+   // this is not yet ready!!!
Put blocks like this inside
#if 0
or
#if NOT_READY_YET
#endif
blocks.

+static u32 mcf5282_func(struct i2c_adapter *adapter)
+{
+   return(I2C_FUNC_SMBUS_QUICK |
+  I2C_FUNC_SMBUS_BYTE |
+  I2C_FUNC_SMBUS_PROC_CALL |
+  I2C_FUNC_SMBUS_BYTE_DATA |
+  I2C_FUNC_SMBUS_WORD_DATA |
+  I2C_FUNC_SMBUS_BLOCK_DATA);
+};
Don't use parens on return statements.


+static int __init i2c_mcf5282_init():
is not driver registration needed?  I don't know the I2C
subsystem, so maybe not...



Big Question:  does most Coldfire or I2C use volatile so heavily,
or is it just this one driver that does that?  Volatile here
semms very overused.


-- 
~Randy


linux_patch_submit2
Description: Binary data


Re: [ANNOUNCE] git-pasky-0.1

2005-04-10 Thread Linus Torvalds


On Sun, 10 Apr 2005, Petr Baudis wrote:
 
 Where did you get the sparse git database from, Linus? (BTW, it
 would be nice to get sparse.git with the directories as separate.)

When we were trying to figure out how to avert the BK disaster, and one of
Tridges concerns (and, in my opinion, the only really valid one) was that
you couldn't get the BK data in some SCM-independent way.

So I wrote some very preliminary scripts (on top of BK itself) to extract
the data, to show that BK could generate a SCM-neutral file format (a very
stupid one and horribly useless for anything but interoperability, but
still...). I was hoping that that would convince Tridge that trying to
muck around with the internal BK file format was not worth it, and avert
the BK trainwreck.

Larry was ok with the idea to make my export format actually be natively
supported by BK (ie the same way you have bk export -tpatch), but Tridge
wanted to instead get at the native data and be difficult about it. As a
result, I can now not only use BK any more, but we also don't have a nice
export format from BK.

Yeah, I'm a bit bitter about it. 

Anyway, the sparse data came out of my hack. It's very inefficient, and I
estimated that doing the same for the kernel would have taken ten solid
days of conversion, mainly because my hack was really just that: a quick
hack to show that BK could do it. Larry could have done it a lot better.

I'll re-generate the sparse git-database at some point (and I'll probably
do so from the old GIT database itself, rather than re-generating it from
my old BK data).

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


Re: Kernel SCM saga..

2005-04-10 Thread Bill Davidsen
On Sun, 10 Apr 2005, Junio C Hamano wrote:

  DL == David Lang [EMAIL PROTECTED] writes:
 
 DL just wanted to point out that recent news shows that sha1 isn't as
 DL good as it was thought to be (far easier to deliberatly create
 DL collisions then it should be)
 
 I suspect there is no need to do so...

It's possible to generate another object with the same hash, but:
 - you can't just take your desired object and do magic to make it hash
   right
 - it may not have the same length (almost certainly)
 - it's still non-trivial in terms of computation needed

 
   Message-ID: [EMAIL PROTECTED]
   From: Linus Torvalds [EMAIL PROTECTED]
   Subject: Re: Kernel SCM saga..
   Date: Sat, 9 Apr 2005 09:16:22 -0700 (PDT)
 
   ...
 
   Linus 
 
   (*) yeah, yeah, I know about the current theoretical case, and I don't
   care. Not only is it theoretical, the way my objects are packed you'd have
   to not just generate the same SHA1 for it, it would have to _also_ still
   be a valid zlib object _and_ get the header to match the type + length  
   of object part. IOW, the object validity checks are actually even stricter
   than just sha1 matches.
 
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 

-- 
bill davidsen [EMAIL PROTECTED]
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

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

2005-04-10 Thread Rutger Nijlunsing
On Sun, Apr 10, 2005 at 08:44:56AM -0700, Linus Torvalds wrote:
 
 
 On Sun, 10 Apr 2005, Junio C Hamano wrote:
  
  But I am wondering what your plans are to handle renames---or
  does git already represent them?
 
 You can represent renames on top of git - git itself really doesn't care.  
 In many ways you can just see git as a filesystem - it's content-
 addressable, and it has a notion of versioning, but I really really
 designed it coming at the problem from the viewpoint of a _filesystem_
 person (hey, kernels is what I do), and I actually have absolutely _zero_
 interest in creating a traditional SCM system.
 
 So to take renaming a file as an example - why do you actually want to 
 track renames? In traditional SCM's, you do it for two reasons:
 
  - space efficiency. Most SCM's are based on describing changes to a file, 
[snip]
  - annotate/blame. This is a valid concern, but the fact is, I never use 
[snip]

- merging.
  When the parent tree renames a file, it's easier for an out-of-tree
  patch to get up-to-date.

- reviewing.
  A huge patch with 2000 added lines and 1990 removed lines is more
  difficult to review then a rename + 10 lines patch.

 So consider me deficient, or consider me radical. It boils down to the 
 same thing. Renames don't matter. 

When you've got no out-of-tree patches since you've got the
parent-of-all-trees, then they don't matter, that's true :)

 So whether you agree with the things that _I_ consider important probably
 depends on how you work. The real downside of GIT may be that _my_ way of 
 doing things is quite possibly very rare.


-- 
Rutger Nijlunsing -- eludias ed dse.nl
never attribute to a conspiracy which can be explained by incompetence
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] inotify for 2.6.11

2005-04-10 Thread Erik Meitner
Robert Love wrote:
 Below is inotify, diffed against 2.6.11.
 
 I greatly reworked much of the data structures and their interactions,
 to lay the groundwork for sanitizing the locking.  I then, I hope,
 sanitized the locking.  It looks right, I am happy.  Comments welcome.
 I surely could of missed something.  Maybe even something big.
 
 But, regardless, this release is a huge jump from the previous, fixing
 all known issues and greatly improving the locking.
 

Inotify 0.22 severly destabilized my 2.6.11 system when it was in use.
The system would get into a state where it was unable to spawn new
processes, the desktop would hang, and the only way to shut down would
be to do a hard reset. This only happened when inotify was in use after
gamin started up.  I was only able to get the following out of the
logs(not every time though):

c017b901
Modules linked in: radeon deflate zlib_deflate twofish serpent aes_i586
blowfish sha256 sha1 crypto_null af_key parport_pc lp parport 8250_pci
8250 serial_core usbhid ohci_hcd ohci1394 ieee1394 yenta_socket
rsrc_nonstatic
suspend_text
CPU:0
EIP:0060:[inotify_ignore+49/224]Not tainted VLI
EFLAGS: 00010246   (2.6.11.6-nx9005)
EIP is at inotify_ignore+0x31/0xe0
eax:    ebx: e88544e0   ecx:    edx: 
esi:    edi: e88544e0   ebp: e876   esp: e8761f20
ds: 007b   es: 007b   ss: 0068
Process gam_server (pid: 6640, threadinfo=e876 task=ed19e060)
Stack: e88544e8 00f6 e88544e0 fff2 fff7 c017bace e88544e0
00f6
   0004 00f6 0292  08098e54 80045102 fff7
c01685a8
   e5d584c0 80045102 08098e54 c0456118  e5d584c0 c0168785
e5d584c0
Call Trace:
 [inotify_ioctl+286/288] inotify_ioctl+0x11e/0x120
 [do_ioctl+104/128] do_ioctl+0x68/0x80
 [vfs_ioctl+101/464] vfs_ioctl+0x65/0x1d0
 [sys_ioctl+69/144] sys_ioctl+0x45/0x90
 [syscall_call+7/11] syscall_call+0x7/0xb
Code: 10 89 5c 24 08 89 74 24 0c 8b 7c 24 18 ff 4f 28 0f 88 95 03 00 00
8b 44 24 1c 89 44 24 04 8d 47 08 89 04 24 e8 11 89 0b 00 89 c6 ff 40
10 ff 47 28 0f 8e 81 03 00 00 85 f6 b8 ea ff ff ff 74 6e

Thanks.

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


Re: [patch] Real-Time Preemption, -RT-2.6.12-rc2-V0.7.44-00

2005-04-10 Thread K.R. Foley
Ingo,
It would seem that in the latest patch RT-V0.7.45-00 we have reverted 
back to removing the define of jbd_debug which the attached patch 
(against one of the 2.6.11 versions) fixed.

--
   kr
--- linux-2.6.11/include/linux/jbd.h.orig   2005-03-16 09:18:51.0 
-0600
+++ linux-2.6.11/include/linux/jbd.h2005-03-16 09:19:24.0 -0600
@@ -65,6 +65,7 @@ extern int journal_enable_debug;
}   \
} while (0)
 #else
+#define jbd_debug(f, a...)   /**/
 #endif
 
 extern void * __jbd_kmalloc (const char *where, size_t size, int flags, int 
retry);


2.6.11 x86_64 NUMA slightly broken

2005-04-10 Thread Andrew Zabolotny
Hello!

I've upgraded the kernel from 2.6.10 to 2.6.11 (both from Fedora Core 3
RPMs) on one of my servers, based on a Tyan S2882 board with two Opteron
248's and two 1Gb modules inserted into the slots next to *second* CPU
(they just happened to be there). And the kernel didn't booted. I've
also tried to compile the kernel myself -- with same result.

I'll skip the whole detective story and will describe just the net
result. It looks like the bug is somewhere in the NUMA handling code,
because:

a) The kernel boots fine with numa=off

b) The kernel started working even without numa=off after I've moved the
DRAM from the slots bound to CPU#2 to the slots bound to CPU#1.

c) The output with kernel 2.6.10 (which worked fine even with DRAM in
slots #2) was as follows:

Bootdata ok (command line is ro root=/dev/hda1 selinux=0)
Linux version 2.6.10-1.741_FC3smp ([EMAIL PROTECTED])
(gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3)) #1 SMP
Thu Jan 13 16:58:29 EST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e - 0010 (reserved)
 BIOS-e820: 0010 - 7fff (usable)
 BIOS-e820: 7fff - 7000 (ACPI data)
 BIOS-e820: 7000 - 8000 (ACPI NVS)
 BIOS-e820: ff78 - 0001 (reserved)
Scanning NUMA topology in Northbridge 24
Number of nodes 2 (10010)
Skipping disabled node 0
Node 1 MemBase  Limit 7fff
Using node hash shift of 24
Bootmem setup node 1 -7fff
No mptable found.
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:5 APIC version 16
...

---
Kernel 2.6.11 with numa=off:

Linux version 2.6.11-1.7_FC3smp ([EMAIL PROTECTED])
(gcc version 3.4.3 20050227 (Red Hat 3.4.3-22)) #1 SMP
Sat Mar 19 20:16:43 EST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e - 0010 (reserved)
 BIOS-e820: 0010 - 7fff (usable)
 BIOS-e820: 7fff - 7000 (ACPI data)
 BIOS-e820: 7000 - 8000 (ACPI NVS)
 BIOS-e820: ff78 - 0001 (reserved)
NUMA turned off
Faking a node at -7fff
Bootmem setup node 0 -7fff
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:5 APIC version 16
...

---
Kernel 2.6.11 with enabled numa, crashing (transcribed off the
screen with the earlyprintk=vga option):

Linux version 2.6.11-1.7_FC3smp ([EMAIL PROTECTED])
(gcc version 3.4.3 20050227 (Red Hat 3.4.3-22)) #1 SMP
Sat Mar 19 20:16:43 EST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000e - 0010 (reserved)
 BIOS-e820: 0010 - 7fff (usable)
 BIOS-e820: 7fff - 7000 (ACPI data)
 BIOS-e820: 7000 - 8000 (ACPI NVS)
 BIOS-e820: ff78 - 0001 (reserved)
kernel direct mapping tables upto 8101 @ 8000-d000
Scanning NUMA topology in Northbridge 24
Number of nodes 2
Skipping disabled node 0
Node 1 MemBase -7fff
Using node hash shift of 24
Bootmem setup node 1 -7fff
PANIC: early exception rip 8020427b error 0 cr2 0
...

The address 8020427b is:

80204210 T find_next_zero_bit
802042a0 T find_next_bit

Is this information enough for catching the bug? I'll do my best to
gather more info although it's a production server.

-- 
Greetings,
   Andrew

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


Code snippet to reconstruct ancestry graph from bk repo

2005-04-10 Thread Paul P Komkoff Jr
Replying to Roman Zippel:
 the nitty-gritty I was whining about and which is not available via 
 bkcvs or bkweb and it's the most crucial information to make the bk data 
 useful outside of bk. Larry was previously very clear about this that he 
 considers this proprietary bk meta data and anyone attempting to export 
 this information is in violation with the free bk licence, so you indeed 
 just took the important parts and this is/was explicitly verboten for 
 normal bk users.

(borrowed from Tommi Virtanen)

Code snippet to reconstruct ancestry graph from bk repo:
bk changes -end':I: $if(:PARENT:){:PARENT:$if(:MPARENT:){ :MPARENT:}} 
$unless(:PARENT:){-}' |tac

format is:
newrev parent1 [parent2]
parent2 present if merge occurs.

-- 
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key - my pgp key
 This message represents the official view of the voices in my head
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] Real-Time Preemption, -RT-2.6.12-rc2-V0.7.44-00

2005-04-10 Thread Ingo Molnar

* K.R. Foley [EMAIL PROTECTED] wrote:

 Ingo,
 
 It would seem that in the latest patch RT-V0.7.45-00 we have reverted 
 back to removing the define of jbd_debug which the attached patch 
 (against one of the 2.6.11 versions) fixed.

 +#define jbd_debug(f, a...)   /**/

oops, indeed. '/**/' happens to be my private marker for 'debug code', 
which the release scripts automatically strip from the files ...

i've uploaded -45-01 with the fix.

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 git updates..

2005-04-10 Thread Rik van Riel
On Sat, 9 Apr 2005, Linus Torvalds wrote:

 I've rsync'ed the new git repository to kernel.org, it should all be there
 in /pub/linux/kernel/people/torvalds/git.git/ (and it looks like the
 mirror scripts already picked it up on the public side too).

GCC 4 isn't very happy.  Mostly sign changes, but also something
that looks like a real error:

gcc -g -O3 -Wall   -c -o fsck-cache.o fsck-cache.c
fsck-cache.c: In function 'main':
fsck-cache.c:59: warning: control may reach end of non-void function 
'fsck_tree' being inlined
fsck-cache.c:62: warning: control may reach end of non-void function 
'fsck_commit' being inlined

I assume that fsck_tree and fsck_commit should complain loudly
if they ever get to that point - but since I'm not quite sure
there's no patch, sorry.

-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it. - Brian W. Kernighan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [ANNOUNCE] git-pasky-0.1

2005-04-10 Thread Ingo Molnar

* Petr Baudis [EMAIL PROTECTED] wrote:

   I will also need to do more testing on the linux kernel tree.
 Committing patch-2.6.7 on 2.6.6 kernel and then diffing results in
 
   $ time gitdiff.sh `parent-id` `tree-id` p
   real5m37.434s
   user1m27.113s
   sys 2m41.036s
 
 which is pretty horrible, it seems to me. Any benchmarking help is of
 course welcomed, as well as any other feedback.

it seems from the numbers that your system doesnt have enough RAM for 
this and is getting IO-bound?

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 git updates..

2005-04-10 Thread Paul Jackson
Ralph wrote:
 but good enough for
 most uses that people will get caught out when it fails.

Exactly.

If Linus persists in this diff-tree output format, using two lines for
changed files, then I will have to add the following sed script to my
arsenal:

  sed '/^/ { N; s/\n/ / }'

It collapses pairs of lines:

100664 4870bcf91f8666fc788b07578fb7473eda795587 Makefile
100664 5493a649bb33b9264e8ed26cc1f832989a307d3b Makefile

to the single line:

100664 4870bcf91f8666fc788b07578fb7473eda795587 Makefile 100664 
5493a649bb33b9264e8ed26cc1f832989a307d3b Makefile

However, more people will get bit by this git glitch than know sed.

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


Re: more git updates..

2005-04-10 Thread Ingo Molnar

* Rik van Riel [EMAIL PROTECTED] wrote:

 GCC 4 isn't very happy.  Mostly sign changes, but also something that 
 looks like a real error:
 
 gcc -g -O3 -Wall   -c -o fsck-cache.o fsck-cache.c
 fsck-cache.c: In function 'main':
 fsck-cache.c:59: warning: control may reach end of non-void function 
 'fsck_tree' being inlined
 fsck-cache.c:62: warning: control may reach end of non-void function 
 'fsck_commit' being inlined
 
 I assume that fsck_tree and fsck_commit should complain loudly if they 
 ever get to that point - but since I'm not quite sure there's no 
 patch, sorry.

i sent a patch for most of the sign errors, but the above is a case gcc 
not noticing that the function can never ever exit the loop, and thus 
cannot get to the 'return' point.

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


Re: [patch] Real-Time Preemption, -RT-2.6.12-rc2-V0.7.44-00

2005-04-10 Thread Steven Rostedt
On Sun, 2005-04-10 at 19:27 +0200, Ingo Molnar wrote:
 * K.R. Foley [EMAIL PROTECTED] wrote:
 
  Ingo,
  
  It would seem that in the latest patch RT-V0.7.45-00 we have reverted 
  back to removing the define of jbd_debug which the attached patch 
  (against one of the 2.6.11 versions) fixed.
 
  +#define jbd_debug(f, a...)   /**/
 
 oops, indeed. '/**/' happens to be my private marker for 'debug code', 
 which the release scripts automatically strip from the files ...
 
 i've uploaded -45-01 with the fix.
 

Would there be any harm with changing that to 

#define jbd_debug(f, a...) do {} while(0)

The compiler would strip it anyway, and you wouldn't have to worry about
your scripts removing the macro.

-- Steve


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

2005-04-10 Thread Paul Jackson
Ingo wrote:
 With default gzip it's 3.3 seconds though,
 and that still compresses it down to 57 MB.

Interesting.  I'm surprised how much a bunch of separate, modest sized
files can be compressed.

I'm unclear what matters most here.

Space on disk certainly isn't much of an issue.  Even with Andrew Morton
on our side, we still can't grow the kernel as fast as the disk drive
manufacturers can grow disk sizes.

Main memory size of the compressed history matters to Linus and his top
20 lieutenants doing full kernel source patching as a primary mission if
they can't fit the source _history_ in main memory.  But those people
are running 1 GByte or more of RAM - so whether it is 95, 57 or 45
MBytes, it fits fine.  The rest of us are mostly concerned with whether
a kernel build fits in memory.

Looking at an arch i386 kernel build tree I have at hand, I see the
following disk usage:

102 MBytes - BitKeeper/*
287 MBytes - */SCCS/* (outside of already counted BitKeeper/*)
232 MBytes - checked out source files
 94 MBytes - ELF and other build byproducts
---
715 MBytes - Total

Converting from bk to git, I guess this becomes:

 97 MBytes - git (zlib)
232 MBytes - checked out source files
 94 MBytes - ELF and other build byproducts
---
423 MBytes - Total

Size matters when its a two to one difference, but when we are down to a
10% to 15% difference in the Total, its presentation that matters.  The
above numbers tell me that this is not a pure size issue for local disk
or memory usage.

What does matter that I can see:

 1) Linus explicitly stated he wanted a raw zlib compressed blob,
not a gzipped file, to encourage everyone to use the git tools to
access this data.  He did not want people editing repostitory files
by hand.  I'm not sure what he gains here - it did annoy me for a
couple hours before I decided fixing my supper was more important.

 2) The time to compress will be noticed by users as a delay when
checking in changes (I'm guessing zlib compresses relatively faster).

 3) The time to copy compressed data over the internet will be
noticed by users when upgrading kernel versions (gzip can
compress smaller).

 4) Decompress times are smaller so don't matter as much.

 5) Zlib has a nice library, and is patent free.  I don't know about gzip.

 6) As you note, zlib has rsync-friendly, recovery-friendly Z_PARTIAL_FLUSH.
I don't know about gzip.

My guess is that Linus finds (2) and (3) to balance each other, and that
(1) decides the point, in favor of zlib.  Well, that or a simpler
hypothesis, that he found the nice library (5) convenient, and (1)
sealed the deal, with the other tradeoffs passing through his
subconscious faster than he bothered to verbalize them.

You (Ingo) seem in your second message to be encouraging further
consideration of gzip, for its improved compression.

How will that matter to us, day to day?

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


Re: [ANNOUNCE] git-pasky-0.1

2005-04-10 Thread Willy Tarreau
On Sun, Apr 10, 2005 at 07:33:49PM +0200, Ingo Molnar wrote:
 
 * Petr Baudis [EMAIL PROTECTED] wrote:
 
I will also need to do more testing on the linux kernel tree.
  Committing patch-2.6.7 on 2.6.6 kernel and then diffing results in
  
  $ time gitdiff.sh `parent-id` `tree-id` p
  real5m37.434s
  user1m27.113s
  sys 2m41.036s
  
  which is pretty horrible, it seems to me. Any benchmarking help is of
  course welcomed, as well as any other feedback.
 
 it seems from the numbers that your system doesnt have enough RAM for 
 this and is getting IO-bound?

Not the only problem, without I/O, he will go down to 4m8s (u+s) which
is still in the same order of magnitude.

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: Kernel SCM saga..

2005-04-10 Thread Ingo Molnar

* Paul Jackson [EMAIL PROTECTED] wrote:

 Ingo wrote:
  With default gzip it's 3.3 seconds though,
  and that still compresses it down to 57 MB.
 
 Interesting.  I'm surprised how much a bunch of separate, modest sized
 files can be compressed.

sorry, what i measured was in essence the tarball. I.e. not the 
compression of every file separately. I should have been clear about 
that ...

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


Re: [ANNOUNCE] git-pasky-0.1

2005-04-10 Thread Ingo Molnar

* Willy Tarreau [EMAIL PROTECTED] wrote:

 I will also need to do more testing on the linux kernel tree.
   Committing patch-2.6.7 on 2.6.6 kernel and then diffing results in
   
 $ time gitdiff.sh `parent-id` `tree-id` p
 real5m37.434s
 user1m27.113s
 sys 2m41.036s
   
   which is pretty horrible, it seems to me. Any benchmarking help is of
   course welcomed, as well as any other feedback.
  
  it seems from the numbers that your system doesnt have enough RAM for 
  this and is getting IO-bound?
 
 Not the only problem, without I/O, he will go down to 4m8s (u+s) which 
 is still in the same order of magnitude.

probably not the only problem - but if we are lucky then his system was 
just trashing within the kernel repository and then most of the overhead 
is the _unnecessary_ IO that happened due to that (which causes CPU 
overhead just as much). The dominant system time suggests so, to a 
certain degree. Maybe this is wishful thinking.

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


Re: [patch] Real-Time Preemption, -RT-2.6.12-rc2-V0.7.44-00

2005-04-10 Thread Ingo Molnar

* Steven Rostedt [EMAIL PROTECTED] wrote:

 Would there be any harm with changing that to 
 
 #define jbd_debug(f, a...) do {} while(0)
 
 The compiler would strip it anyway, and you wouldn't have to worry 
 about your scripts removing the macro.

yeah, that's what i did in -45-01. Since it's not the first time this 
has happened i might have to change the marker to /*I*/ or something 
like that :-)

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 SCM saga..

2005-04-10 Thread Paul Jackson
 It's possible to generate another object with the same hash, but:

Yeah - the real check is that the modified object has to
compile and do something useful for someone (the cracker
if no one else).

Just getting a random bucket of bits substituted for a
real kernel source file isn't going to get me into the
cracker hall of fame, only into their odd-news of the
day.

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


Re: Kernel SCM saga..

2005-04-10 Thread Matthias Andree
Andrea Arcangeli schrieb am 2005-04-09:

 On Fri, Apr 08, 2005 at 05:12:49PM -0700, Linus Torvalds wrote:
  really designed for something like a offline http grabber, in that you can 
  just grab files purely by filename (and verify that you got them right by 
  running sha1sum on the resulting local copy). So think wget.
 
 I'm not entirely convinced wget is going to be an efficient way to
 synchronize and fetch your tree, its simplicitly is great though. It's a

wget is probably a VERY UNWISE choice:

http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2004-12/0106.html

-- 
Matthias Andree
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 SCM saga..

2005-04-10 Thread Paul Jackson
Ingo wrote:
 not the compression of every file separately.

ok

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


[2.6 patch] drivers/cdrom/cdu31a.c: make some code static

2005-04-10 Thread Adrian Bunk
This patch makes some needlessly global code static.

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

---

 drivers/cdrom/cdu31a.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.12-rc2-mm2-full/drivers/cdrom/cdu31a.c.old2005-04-10 
02:01:50.0 +0200
+++ linux-2.6.12-rc2-mm2-full/drivers/cdrom/cdu31a.c2005-04-10 
02:02:38.0 +0200
@@ -292,7 +292,7 @@
 
 /* The interrupt handler will wake this queue up when it gets an
interrupts. */
-DECLARE_WAIT_QUEUE_HEAD(cdu31a_irq_wait);
+static DECLARE_WAIT_QUEUE_HEAD(cdu31a_irq_wait);
 static int irq_flag = 0;
 
 static int curr_control_reg = 0;   /* Current value of the control 
register */
@@ -2947,7 +2947,7 @@
return cdrom_media_changed(scd_info);
 }
 
-struct block_device_operations scd_bdops =
+static struct block_device_operations scd_bdops =
 {
.owner  = THIS_MODULE,
.open   = scd_block_open,
@@ -3216,7 +3216,7 @@
 }
 
 
-void __exit cdu31a_exit(void)
+static void __exit cdu31a_exit(void)
 {
del_gendisk(scd_gendisk);
put_disk(scd_gendisk);

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] Simple privacy enhancement for /proc/pid

2005-04-10 Thread Bodo Eggert
On Sun, 10 Apr 2005, Rene Scharfe wrote:

 First, configuring via kernel parameters is sufficient.

I don't remember: Would a mount option be equally easy to implement?
(Kernel parameters are OK for me, too.)

 I have another idea: let's keep the details of _every_ process owned by
 user root readable by anyone.

What about SUID processes acting on behalf of users?

 - processor.max_cstate=   [HW, ACPI]
 - Limit processor to maximum C-state
 - max_cstate=9 overrides any DMI blacklist limit.
 -

This seems to belong into another patch



(in pid_revalidate:)
What about moving the things around? (just editing in the MUA)

 + if (IS_PID_DIR(proc_type(inode)) || task_dumpable(task)) {
   inode-i_uid = task-euid;
 + inode-i_gid = proc_gid;
 + if (!proc_privacy || IS_PID_DIR(proc_type(inode)))
   inode-i_gid = task-egid;
   } else {
   inode-i_uid = 0;
   inode-i_gid = 0;
   }
   security_task_to_inode(task, inode);
   return 1;
   }

BTW: You might be able to cache IS_PID_DIR(). It looks like being a gain.

 @@ -1454,6 +1468,11 @@ static struct dentry *proc_pident_lookup

 + if (proc_privacy == 2 || task-euid != 0)
   ^
redundand.
-- 
Funny quotes:
27. If people from Poland are called Poles, why aren't people from Holland
called Holes?
Friß, Spammer: [EMAIL PROTECTED] [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/


swsuspend scheduling while atomic

2005-04-10 Thread Marco Gaddoni
Hello
i am playing a little with swsuspend and getting
scheduling while atomic: bash/0x0001/5244
messages while the system is resuming.
Apparently  the  resume  work  correctly.
Do i have to fear for my data?
Some data about my system:
kernel 2.6.11.5
modules
Module  Size  Used by
it87   26204  0
eeprom  7632  0
i2c_sensor  3520  2 it87,eeprom
i2c_isa 1984  0
i2c_viapro  7888  0
tuner  22500  0
tvaudio23588  0
bttv  155408  0
video_buf  22084  1 bttv
firmware_class 10688  1 bttv
i2c_algo_bit9480  1 bttv
v4l2_common 5824  1 bttv
btcx_risc   4936  1 bttv
tveeprom   13144  1 bttv
i2c_core   23184  10 
it87,eeprom,i2c_sensor,i2c_isa,i2c_viapro,tuner,tvaudio,bttv,i2c_algo_bit,tveeprom
videodev   10112  1 bttv

pci:
:00:00.0 Host bridge: VIA Technologies, Inc. VT8377 [KT400/KT600 
AGP] Host Bridge (rev 80)
:00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI Bridge
:00:09.0 Multimedia audio controller: C-Media Electronics Inc CM8738 
(rev 10)
:00:0b.0 Multimedia video controller: Brooktree Corporation Bt878 
Video Capture (rev 02)
:00:0b.1 Multimedia controller: Brooktree Corporation Bt878 Audio 
Capture (rev 02)
:00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA 
RAID Controller (rev 80)
:00:0f.1 IDE interface: VIA Technologies, Inc. 
VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
:00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 
1.1 Controller (rev 81)
:00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 
1.1 Controller (rev 81)
:00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 
1.1 Controller (rev 81)
:00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 
1.1 Controller (rev 81)
:00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86)
:00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge 
[K8T800 South]:00:11.5 Multimedia audio controller: VIA 
Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 
[Rhine-II] (rev 78)
:01:00.0 VGA compatible controller: nVidia Corporation: Unknown 
device 0326 (rev a1)

and finally the messages:
/visor.c: USB HandSpring Visor / Palm OS driver v2.1
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
Advanced Linux Sound Architecture Driver Version 1.0.8 (Thu Jan 13 
09:39:32 2005 UTC).
ACPI: PCI interrupt :00:09.0[A] - GSI 17 (level, low) - IRQ 17
ALSA device list:
 #0: C-Media PCI CMI8738-MC6 (model 55) at 0x9000, irq 17
oprofile: using NMI interrupt.
NET: Registered protocol family 2
IP: routing cache hash table of 4096 buckets, 32Kbytes
TCP established hash table entries: 32768 (order: 6, 262144 bytes)
TCP bind hash table entries: 32768 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
ip_conntrack version 2.1 (4095 buckets, 32760 max) - 212 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
ipt_recent v0.3.1: Stephen Frost [EMAIL PROTECTED].  
http://snowman.net/projects/ipt_recent/
arp_tables: (C) 2002 David S. Miller
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
ACPI wakeup devices:
SLPB PCI0 USB0 USB1 USB2 USB6 USB7 USB8 USB9 LAN0 MC97 UAR1 UAR2 ECP1
ACPI: (supports S0 S1 S4 S5)
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 196k freed
kjournald starting.  Commit interval 5 seconds
Adding 1082584k swap on /dev/hdd4.  Priority:-1 extents:1
Adding 297160k swap on /dev/hdb1.  Priority:-2 extents:1
EXT3 FS on hdd1, internal journal
Linux video capture interface: v1.00
bttv: driver version 0.9.15 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
bttv: Bt8xx card found (0).
ACPI: PCI interrupt :00:0b.0[A] - GSI 19 (level, low) - IRQ 19
bttv0: Bt878 (rev 2) at :00:0b.0, irq: 19, latency: 32, mmio: 0xea00
bttv0: detected: Terratec TValue (Philips PAL B/G) [card=33], PCI 
subsystem ID is 153b:1117
bttv0: using: Terratec TerraTValue Version Bt878 [card=33,autodetected]
bttv0: gpio: en=, out= in=00ffefff [init]
bttv0: using tuner=5
bttv0: i2c: checking for MSP34xx @ 0x80... not found
bttv0: i2c: checking for TDA9875 @ 0xb0... not found
bttv0: i2c: checking for TDA7432 @ 0x8a... not found
tvaudio: TV audio decoder + audio/video mux driver
tvaudio: known chips: 
tda9840,tda9873h,tda9874h/a,tda9850,tda9855,tea6300,tea6320,tea6420,tda8425,pic16c54 
(PV951),ta8874z
bttv0: i2c: checking for TDA9887 @ 0x86... not found
tuner: chip found at addr 0xc0 i2c-bus bt878 #0 [sw]
tuner: type set to 5 (Philips PAL_BG (FI1216 and 

[2.6 patch] drivers/cdrom/cm206.c: cleanups

2005-04-10 Thread Adrian Bunk
This patch contains the following cleanups:
- make needlessly global functions static
- remove the following unused global function:
  - cm206_delay

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

---

 drivers/cdrom/cm206.c |  115 ++
 1 files changed, 51 insertions(+), 64 deletions(-)

--- linux-2.6.12-rc2-mm2-full/drivers/cdrom/cm206.c.old 2005-04-10 
02:05:27.0 +0200
+++ linux-2.6.12-rc2-mm2-full/drivers/cdrom/cm206.c 2005-04-10 
02:14:47.0 +0200
@@ -307,7 +307,7 @@
 /* First, we define some polling functions. These are actually
only being used in the initialization. */
 
-void send_command_polled(int command)
+static void send_command_polled(int command)
 {
int loop = POLLOOP;
while (!(inw(r_line_status)  ls_transmitter_buffer_empty)
@@ -318,7 +318,7 @@
outw(command, r_uart_transmit);
 }
 
-uch receive_echo_polled(void)
+static uch receive_echo_polled(void)
 {
int loop = POLLOOP;
while (!(inw(r_line_status)  ls_receive_buffer_full)  loop  0) {
@@ -328,13 +328,13 @@
return ((uch) inw(r_uart_receive));
 }
 
-uch send_receive_polled(int command)
+static uch send_receive_polled(int command)
 {
send_command_polled(command);
return receive_echo_polled();
 }
 
-inline void clear_ur(void)
+static inline void clear_ur(void)
 {
if (cd-ur_r != cd-ur_w) {
debug((Deleting bytes from fifo:));
@@ -439,7 +439,7 @@
 }
 
 /* we have put the address of the wait queue in who */
-void cm206_timeout(unsigned long who)
+static void cm206_timeout(unsigned long who)
 {
cd-timed_out = 1;
debug((Timing out\n));
@@ -448,7 +448,7 @@
 
 /* This function returns 1 if a timeout occurred, 0 if an interrupt
happened */
-int sleep_or_timeout(wait_queue_head_t * wait, int timeout)
+static int sleep_or_timeout(wait_queue_head_t * wait, int timeout)
 {
cd-timed_out = 0;
init_timer(cd-timer);
@@ -465,13 +465,7 @@
return 0;
 }
 
-void cm206_delay(int nr_jiffies)
-{
-   DECLARE_WAIT_QUEUE_HEAD(wait);
-   sleep_or_timeout(wait, nr_jiffies);
-}
-
-void send_command(int command)
+static void send_command(int command)
 {
debug((Sending 0x%x\n, command));
if (!(inw(r_line_status)  ls_transmitter_buffer_empty)) {
@@ -490,7 +484,7 @@
outw(command, r_uart_transmit);
 }
 
-uch receive_byte(int timeout)
+static uch receive_byte(int timeout)
 {
uch ret;
cli();
@@ -521,23 +515,23 @@
return ret;
 }
 
-inline uch receive_echo(void)
+static inline uch receive_echo(void)
 {
return receive_byte(UART_TIMEOUT);
 }
 
-inline uch send_receive(int command)
+static inline uch send_receive(int command)
 {
send_command(command);
return receive_echo();
 }
 
-inline uch wait_dsb(void)
+static inline uch wait_dsb(void)
 {
return receive_byte(DSB_TIMEOUT);
 }
 
-int type_0_command(int command, int expect_dsb)
+static int type_0_command(int command, int expect_dsb)
 {
int e;
clear_ur();
@@ -552,7 +546,7 @@
return 0;
 }
 
-int type_1_command(int command, int bytes, uch * status)
+static int type_1_command(int command, int bytes, uch * status)
 {  /* returns info */
int i;
if (type_0_command(command, 0))
@@ -564,7 +558,7 @@
 
 /* This function resets the adapter card. We'd better not do this too
  * often, because it tends to generate `lost interrupts.' */
-void reset_cm260(void)
+static void reset_cm260(void)
 {
outw(dc_normal | dc_initialize | READ_AHEAD, r_data_control);
udelay(10); /* 3.3 mu sec minimum */
@@ -572,7 +566,7 @@
 }
 
 /* fsm: frame-sec-min from linear address; one of many */
-void fsm(int lba, uch * fsm)
+static void fsm(int lba, uch * fsm)
 {
fsm[0] = lba % 75;
lba /= 75;
@@ -581,17 +575,17 @@
fsm[2] = lba / 60;
 }
 
-inline int fsm2lba(uch * fsm)
+static inline int fsm2lba(uch * fsm)
 {
return fsm[0] + 75 * (fsm[1] - 2 + 60 * fsm[2]);
 }
 
-inline int f_s_m2lba(uch f, uch s, uch m)
+static inline int f_s_m2lba(uch f, uch s, uch m)
 {
return f + 75 * (s - 2 + 60 * m);
 }
 
-int start_read(int start)
+static int start_read(int start)
 {
uch read_sector[4] = { c_read_data, };
int i, e;
@@ -613,7 +607,7 @@
return 0;
 }
 
-int stop_read(void)
+static int stop_read(void)
 {
int e;
type_0_command(c_stop, 0);
@@ -630,7 +624,7 @@
routine takes care of this. Set a flag `background' in the cd
struct to indicate the process. */
 
-int read_background(int start, int reading)
+static int read_background(int start, int reading)
 {
if (cd-background)
return -1;  /* can't do twice */
@@ -658,7 +652,7 @@
 
 
 #define MAX_TRIES 100
-int read_sector(int start)
+static int read_sector(int start)
 {
int tries = 0;
if (cd-background) {
@@ -753,7 +747,7 @@
 /* 

[2.6 patch] floppy driver: make fd_routine static

2005-04-10 Thread Adrian Bunk
This patch makes the needlessly global fd_routine static.

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

---

 include/asm-i386/floppy.h   |2 +-
 include/asm-parisc/floppy.h |2 +-
 include/asm-sh/floppy.h |2 +-
 include/asm-x86_64/floppy.h |2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

--- linux-2.6.12-rc2-mm2-full/include/asm-i386/floppy.h.old 2005-04-10 
01:51:37.0 +0200
+++ linux-2.6.12-rc2-mm2-full/include/asm-i386/floppy.h 2005-04-10 
01:51:45.0 +0200
@@ -257,7 +257,7 @@
return 0;
 }
 
-struct fd_routine_l {
+static struct fd_routine_l {
int (*_request_dma)(unsigned int dmanr, const char * device_id);
void (*_free_dma)(unsigned int dmanr);
int (*_get_dma_residue)(unsigned int dummy);
--- linux-2.6.12-rc2-mm2-full/include/asm-x86_64/floppy.h.old   2005-04-10 
01:51:53.0 +0200
+++ linux-2.6.12-rc2-mm2-full/include/asm-x86_64/floppy.h   2005-04-10 
01:51:59.0 +0200
@@ -223,7 +223,7 @@
return 0;
 }
 
-struct fd_routine_l {
+static struct fd_routine_l {
int (*_request_dma)(unsigned int dmanr, const char * device_id);
void (*_free_dma)(unsigned int dmanr);
int (*_get_dma_residue)(unsigned int dummy);
--- linux-2.6.12-rc2-mm2-full/include/asm-parisc/floppy.h.old   2005-04-10 
01:52:07.0 +0200
+++ linux-2.6.12-rc2-mm2-full/include/asm-parisc/floppy.h   2005-04-10 
01:52:13.0 +0200
@@ -235,7 +235,7 @@
return 0;
 }
 
-struct fd_routine_l {
+static struct fd_routine_l {
int (*_request_dma)(unsigned int dmanr, const char * device_id);
void (*_free_dma)(unsigned int dmanr);
int (*_get_dma_residue)(unsigned int dummy);
--- linux-2.6.12-rc2-mm2-full/include/asm-sh/floppy.h.old   2005-04-10 
01:52:25.0 +0200
+++ linux-2.6.12-rc2-mm2-full/include/asm-sh/floppy.h   2005-04-10 
01:52:32.0 +0200
@@ -227,7 +227,7 @@
return 0;
 }
 
-struct fd_routine_l {
+static struct fd_routine_l {
int (*_request_dma)(unsigned int dmanr, const char * device_id);
void (*_free_dma)(unsigned int dmanr);
int (*_get_dma_residue)(unsigned int dummy);

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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/block/rd.c: make a variable static

2005-04-10 Thread Adrian Bunk
This patch makes a needlessly global variable static.

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

--- linux-2.6.12-rc2-mm2-full/drivers/block/rd.c.old2005-04-10 
02:00:08.0 +0200
+++ linux-2.6.12-rc2-mm2-full/drivers/block/rd.c2005-04-10 
02:01:00.0 +0200
@@ -74,7 +74,7 @@
  * architecture-specific setup routine (from the stored boot sector
  * information).
  */
-int rd_size = CONFIG_BLK_DEV_RAM_SIZE; /* Size of the RAM disks */
+static int rd_size = CONFIG_BLK_DEV_RAM_SIZE;  /* Size of the RAM disks */
 /*
  * It would be very desirable to have a soft-blocksize (that in the case
  * of the ramdisk driver is also the hardblocksize ;) of PAGE_SIZE because

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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/block/ll_rw_blk.c: possible cleanups

2005-04-10 Thread Adrian Bunk
This patch contains the following possible cleanups:
- make needlessly global code static
- remove the following unused global functions:
  - blkdev_scsi_issue_flush_fn
  - __blk_attempt_remerge
- remove the following unused EXPORT_SYMBOL's:
  - blk_phys_contig_segment
  - blk_hw_contig_segment
  - blkdev_scsi_issue_flush_fn
  - __blk_attempt_remerge

Please review which of these changes make sense.

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

---

 drivers/block/ll_rw_blk.c |   67 --
 include/linux/blkdev.h|6 ---
 2 files changed, 8 insertions(+), 65 deletions(-)

--- linux-2.6.12-rc2-mm2-full/include/linux/blkdev.h.old2005-04-10 
01:55:03.0 +0200
+++ linux-2.6.12-rc2-mm2-full/include/linux/blkdev.h2005-04-10 
01:57:11.0 +0200
@@ -548,15 +548,12 @@
 extern void blk_put_request(struct request *);
 extern void blk_end_sync_rq(struct request *rq);
 extern void blk_attempt_remerge(request_queue_t *, struct request *);
-extern void __blk_attempt_remerge(request_queue_t *, struct request *);
 extern struct request *blk_get_request(request_queue_t *, int, int);
 extern void blk_insert_request(request_queue_t *, struct request *, int, void 
*, int);
 extern void blk_requeue_request(request_queue_t *, struct request *);
 extern void blk_plug_device(request_queue_t *);
 extern int blk_remove_plug(request_queue_t *);
 extern void blk_recount_segments(request_queue_t *, struct bio *);
-extern int blk_phys_contig_segment(request_queue_t *q, struct bio *, struct 
bio *);
-extern int blk_hw_contig_segment(request_queue_t *q, struct bio *, struct bio 
*);
 extern int scsi_cmd_ioctl(struct file *, struct gendisk *, unsigned int, void 
__user *);
 extern void blk_start_queue(request_queue_t *q);
 extern void blk_stop_queue(request_queue_t *q);
@@ -638,7 +635,6 @@
 extern struct backing_dev_info *blk_get_backing_dev_info(struct block_device 
*bdev);
 extern void blk_queue_ordered(request_queue_t *, int);
 extern void blk_queue_issue_flush_fn(request_queue_t *, issue_flush_fn *);
-extern int blkdev_scsi_issue_flush_fn(request_queue_t *, struct gendisk *, 
sector_t *);
 extern struct request *blk_start_pre_flush(request_queue_t *,struct request *);
 extern int blk_complete_barrier_rq(request_queue_t *, struct request *, int);
 extern int blk_complete_barrier_rq_locked(request_queue_t *, struct request *, 
int);
@@ -681,8 +677,6 @@
 
 #define blkdev_entry_to_request(entry) list_entry((entry), struct request, 
queuelist)
 
-extern void drive_stat_acct(struct request *, int, int);
-
 static inline int queue_hardsect_size(request_queue_t *q)
 {
int retval = 512;
--- linux-2.6.12-rc2-mm2-full/drivers/block/ll_rw_blk.c.old 2005-04-10 
01:55:17.0 +0200
+++ linux-2.6.12-rc2-mm2-full/drivers/block/ll_rw_blk.c 2005-04-10 
01:57:49.0 +0200
@@ -36,6 +36,7 @@
 
 static void blk_unplug_work(void *data);
 static void blk_unplug_timeout(unsigned long data);
+static void drive_stat_acct(struct request *rq, int nr_sectors, int new_io);
 
 /*
  * For the allocated request tables
@@ -1149,7 +1150,7 @@
 }
 
 
-int blk_phys_contig_segment(request_queue_t *q, struct bio *bio,
+static int blk_phys_contig_segment(request_queue_t *q, struct bio *bio,
   struct bio *nxt)
 {
if (!(q-queue_flags  (1  QUEUE_FLAG_CLUSTER)))
@@ -1170,9 +1171,7 @@
return 0;
 }
 
-EXPORT_SYMBOL(blk_phys_contig_segment);
-
-int blk_hw_contig_segment(request_queue_t *q, struct bio *bio,
+static int blk_hw_contig_segment(request_queue_t *q, struct bio *bio,
 struct bio *nxt)
 {
if (unlikely(!bio_flagged(bio, BIO_SEG_VALID)))
@@ -1188,8 +1187,6 @@
return 1;
 }
 
-EXPORT_SYMBOL(blk_hw_contig_segment);
-
 /*
  * map a request to scatterlist, return number of sg entries setup. Caller
  * must make sure sg can hold rq-nr_phys_segments entries
@@ -1810,7 +1807,7 @@
  * is the behaviour we want though - once it gets a wakeup it should be given
  * a nice run.
  */
-void ioc_set_batching(request_queue_t *q, struct io_context *ioc)
+static void ioc_set_batching(request_queue_t *q, struct io_context *ioc)
 {
if (!ioc || ioc_batching(q, ioc))
return;
@@ -2250,45 +2247,7 @@
 
 EXPORT_SYMBOL(blkdev_issue_flush);
 
-/**
- * blkdev_scsi_issue_flush_fn - issue flush for SCSI devices
- * @q: device queue
- * @disk:  gendisk
- * @error_sector:  error offset
- *
- * Description:
- *Devices understanding the SCSI command set, can use this function as
- *a helper for issuing a cache flush. Note: driver is required to store
- *the error offset (in case of error flushing) in -sector of struct
- *request.
- */
-int blkdev_scsi_issue_flush_fn(request_queue_t *q, struct gendisk *disk,
-  sector_t *error_sector)
-{
-   struct request *rq = blk_get_request(q, WRITE, __GFP_WAIT);
-   int ret;
-
-   rq-flags |= 

[2.6 patch] drivers/cdrom/mcdx.c: make code static

2005-04-10 Thread Adrian Bunk
This patch makes needlessly global code static.

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

---

 drivers/cdrom/mcdx.c |   28 +---
 1 files changed, 13 insertions(+), 15 deletions(-)

--- linux-2.6.12-rc2-mm2-full/drivers/cdrom/mcdx.c.old  2005-04-10 
02:16:00.0 +0200
+++ linux-2.6.12-rc2-mm2-full/drivers/cdrom/mcdx.c  2005-04-10 
02:18:28.0 +0200
@@ -107,20 +107,20 @@
The _direct_ size is the number of sectors we're allowed to skip
directly (performing a read instead of requesting the new sector
needed */
-const int REQUEST_SIZE = 800;  /* should be less then 255 * 4 */
-const int DIRECT_SIZE = 400;   /* should be less then REQUEST_SIZE */
+static const int REQUEST_SIZE = 800;   /* should be less then 255 * 4 */
+static const int DIRECT_SIZE = 400;/* should be less then REQUEST_SIZE */
 
 enum drivemodes { TOC, DATA, RAW, COOKED };
 enum datamodes { MODE0, MODE1, MODE2 };
 enum resetmodes { SOFT, HARD };
 
-const int SINGLE = 0x01;   /* single speed drive (FX001S, LU) */
-const int DOUBLE = 0x02;   /* double speed drive (FX001D, ..? */
-const int DOOR = 0x04; /* door locking capability */
-const int MULTI = 0x08;/* multi session capability */
+static const int SINGLE = 0x01;/* single speed drive (FX001S, 
LU) */
+static const int DOUBLE = 0x02;/* double speed drive (FX001D, 
..? */
+static const int DOOR = 0x04;  /* door locking capability */
+static const int MULTI = 0x08; /* multi session capability */
 
-const unsigned char READ1X = 0xc0;
-const unsigned char READ2X = 0xc1;
+static const unsigned char READ1X = 0xc0;
+static const unsigned char READ2X = 0xc1;
 
 
 /* DECLARATIONS /
@@ -210,9 +210,7 @@
repeated here to show what's going on.  And to sense, if they're
changed elsewhere. */
 
-/* declared in blk.h */
-int mcdx_init(void);
-void do_mcdx_request(request_queue_t * q);
+static int mcdx_init(void);
 
 static int mcdx_block_open(struct inode *inode, struct file *file)
 {
@@ -569,7 +567,7 @@
}
 }
 
-void do_mcdx_request(request_queue_t * q)
+static void do_mcdx_request(request_queue_t * q)
 {
struct s_drive_stuff *stuffp;
struct request *req;
@@ -1028,7 +1026,7 @@
return 0;
 }
 
-void __exit mcdx_exit(void)
+static void __exit mcdx_exit(void)
 {
int i;
 
@@ -1075,7 +1073,7 @@
 
 /* Support functions /
 
-int __init mcdx_init_drive(int drive)
+static int __init mcdx_init_drive(int drive)
 {
struct s_version version;
struct gendisk *disk;
@@ -1261,7 +1259,7 @@
return 0;
 }
 
-int __init mcdx_init(void)
+static int __init mcdx_init(void)
 {
int drive;
xwarn(Version 2.14(hs) \n);

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


Re: more git updates..

2005-04-10 Thread Paul Jackson
Tony wrote:
 Or maybe the files should be named objects/xx/yy/?

I tend to size these things with the square root of the number of
leaf nodes.  If I have 2,560,000 leaves (your 10,000 files in each
of 16*16 directories), then I will aim for 1600 directories of
1600 leaves each.

My backup is sized for about this number of leaves, and it uses:

xxx/xxx

(I repeat the xxx in the leaf name - easier to code.)

I don't think there is any need for two levels.  There are 4096
different values of three digit hex numbers.  That's ok in one
directory.

The only question would be 'xx' or 'xxx' - two or three digits.

This one is on the cusp in my view - either works.

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


  1   2   3   >