Re: [PATCH] Realtime preempt support for PPC

2005-02-17 Thread Ingo Molnar

* Frank Rowand [EMAIL PROTECTED] wrote:

 I have attached a patch to add realtime support for PowerPC (32 bit
 only). [...]

two comments:

- why is us_to_tb needed? It just seems to add alot of unnecessary
  clutter to the patch, while it's not used anywhere.

- could you submit the drivers/net/ibm_emac/ibm_emac_core.c patch
  upstream as well?

otherwise it looks pretty clean and straightforward.

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: Swsusp, resume and kernel versions

2005-02-17 Thread Nigel Cunningham
Hi.

On Thu, 2005-02-17 at 16:38, Dmitry Torokhov wrote:
 On Thursday 17 February 2005 00:15, Nigel Cunningham wrote:
  On Thu, 2005-02-17 at 15:46, Dmitry Torokhov wrote:
   But I think there is one pretty severe issue present - even if swsusp
   is not enabled kernel should check if there is an image in swap and
   erase it. Today I has somewhat unpleasant experience - after suspending
   I accidentially loaded a vendor kernel. I was in hurry and decided that
   resume just failed for some reason so I did couple of things and left
   the box running. In the evening I realized that I am running vendor kernel
   and decided to reboot into my devel. version. What I did not expect is for
   the kernel to find a valid suspend image and restore it. As you might
   imagine messed up my disk somewhat.
   
   Any chance this can be done?
  
  One of my suspend2 users had the same thing yesterday. Unfortunately
  there's no easy way for us to detect that another kernel has been
  booted.
 
 What do you mean? I thought it already compares signatures of the booting
 kernel and suspend image. Just wipe it out if it does not match, or, even
 better, just stop if signature does not match unless one boots with
 nosuspend. This way even if I start booting wrong image I have a chance
 to select right one and avoid fsck.

That would work if the alternate kernel is suspend-enabled. Suspend2
handles that case nicely and I'm sure swsusp will handle it as well
(although exactly what it does, I'm not sure. It used to panic IIRC).

If the mistakenly booted kernel isn't suspend enabled, however, you need
a more generic method of removing the image, such as mkswapping the
storage device. This is what I was speaking of.

Regards,

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

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

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


Re: [BK] upgrade will be needed

2005-02-17 Thread Clemens Schwaighofer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/17/2005 04:55 PM, Roland Kuhn wrote:

 That said, it would of course be possible to improve the internal
 workflow of our emperor penguin if he used subversion, but the
 collaboration with others could not benefit the way it does with a
 changeset-based approach.

Question is then, what about keeping a main trunk with the vanialle
release, and each dev has its own branch. now at a certain point you
have to merge them. Now where is the difference between a central rep
and a de-central one.
At day X, patches from Andrew's tree have to go to Linus tree and from
his tree into the new vanialla kernel. right?
Somehow I can't see the difference here.

 Linux kernel development is hard _and_ sexy :-)

at least something :D

- --
[ Clemens Schwaighofer  -=:~ ]
[ TBWA\  TEQUILA\ Japan IT Group   ]
[6-17-2 Ginza Chuo-ku, Tokyo 104-0061, JAPAN ]
[ Tel: +81-(0)3-3545-7703Fax: +81-(0)3-3545-7343 ]
[ http://www.tequila.co.jphttp://www.tbwajapan.co.jp ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCFFEojBz/yQjBxz8RAs5rAKC1i4RuDxyi3hjnRDfcjCYyRTGbNQCgsRgc
ErnefDIDGimPjjXa8cALBQc=
=lWQ8
-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/


Baker Grassmann Michaels

2005-02-17 Thread Fornalczyk Robert
Enlarge staying power  fortitude
http://Mielnick.jrz874383w.com/cs/?theman

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


Vega Sobolev Lee

2005-02-17 Thread Rivera Fernando
Intensify sexual life ride
http://Mahiques.jrz874383w.com/cs/?theman

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


Re: [PATCH] Fix buf in zeromap_pud_range() losing virtual address

2005-02-17 Thread Andi Kleen
Benjamin Herrenschmidt [EMAIL PROTECTED] writes:

 zeromap_pud_range() is one of these page tables walking functions that
 split the address into a base and an offset. It forgets to add back the
 base when calling the lower level zeromap_pmd_range(), thus passing a
 bogus virtual address. Most archs won't care, unless they do the above,
 since the lower level can allocate a PTE page.

Hmm, there might be even more cases of this. I remember pondering
it when I did the original 4 level work (sometimes we discard higher level 
virtual address bits during walking)

 (Note: We are in _urgent_ need to consolidate all those page table
 walking functions, they all do things in a subtely different way, with
 different checks (sometimes redudant) and inconsitent with each other,
 even within a given set of them. Hopefully, Nick has some work in
 progress there).

I have. But it will just make them more similar, not completely consolidate
them into an iterator, because that's too hard/ugly to do efficiently.

-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: [PATCH] Fix possible race with 4level-fixup.h

2005-02-17 Thread Nick Piggin
Benjamin Herrenschmidt wrote:
Hi !
When using 4level-fixup.h, a PMD page may end up beeing freed before the
matching PGD entry is cleared due to the way the compatibility macros
work. This can cause nasty races on some architectures.
This patch fixes it by defining pud_clear() to be pgd_clear(). That
means we'll actually write 0 twice, a small price to pay here,
especially seeing how easy it is to convert to the new headers anyway
(hint hint, ppc  ppc64 patches as soon as 2.6.11 is out).
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Index: linux-work/include/asm-generic/4level-fixup.h
===
--- linux-work.orig/include/asm-generic/4level-fixup.h	2005-01-24 17:09:49.0 +1100
+++ linux-work/include/asm-generic/4level-fixup.h	2005-02-17 18:10:38.0 +1100
@@ -24,7 +24,7 @@
 #define pud_bad(pud)			0
 #define pud_present(pud)		1
 #define pud_ERROR(pud)			do { } while (0)
-#define pud_clear(pud)			do { } while (0)
+#define pud_clear(pud)			pgd_clear((pgd_t *)(pud))
 
Just a small nit - no cast needed here.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Fix buf in zeromap_pud_range() losing virtual address

2005-02-17 Thread Benjamin Herrenschmidt
On Thu, 2005-02-17 at 09:33 +0100, Andi Kleen wrote:
 Benjamin Herrenschmidt [EMAIL PROTECTED] writes:
 
  zeromap_pud_range() is one of these page tables walking functions that
  split the address into a base and an offset. It forgets to add back the
  base when calling the lower level zeromap_pmd_range(), thus passing a
  bogus virtual address. Most archs won't care, unless they do the above,
  since the lower level can allocate a PTE page.
 
 Hmm, there might be even more cases of this. I remember pondering
 it when I did the original 4 level work (sometimes we discard higher level 
 virtual address bits during walking)

I think I went through all of them, but I'll do again just in case ...

  (Note: We are in _urgent_ need to consolidate all those page table
  walking functions, they all do things in a subtely different way, with
  different checks (sometimes redudant) and inconsitent with each other,
  even within a given set of them. Hopefully, Nick has some work in
  progress there).
 
 I have. But it will just make them more similar, not completely consolidate
 them into an iterator, because that's too hard/ugly to do efficiently.

Hrm... I'm pretty sure half of the ones we have now are not fully
efficient, and they all do the exact same thing until they get all the
way down. The only real variation is wether to allocate on the way. Oh
well, nick has some bits too, I'll have a look at what he has already
done.

Ben.


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


Re: [PATCH] Fix possible race with 4level-fixup.h

2005-02-17 Thread Benjamin Herrenschmidt
On Thu, 2005-02-17 at 19:33 +1100, Nick Piggin wrote:
 Benjamin Herrenschmidt wrote:
  Hi !
  
  When using 4level-fixup.h, a PMD page may end up beeing freed before the
  matching PGD entry is cleared due to the way the compatibility macros
  work. This can cause nasty races on some architectures.
  
  This patch fixes it by defining pud_clear() to be pgd_clear(). That
  means we'll actually write 0 twice, a small price to pay here,
  especially seeing how easy it is to convert to the new headers anyway
  (hint hint, ppc  ppc64 patches as soon as 2.6.11 is out).
  
  Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
  
  Index: linux-work/include/asm-generic/4level-fixup.h
  ===
  --- linux-work.orig/include/asm-generic/4level-fixup.h  2005-01-24 
  17:09:49.0 +1100
  +++ linux-work/include/asm-generic/4level-fixup.h   2005-02-17 
  18:10:38.0 +1100
  @@ -24,7 +24,7 @@
   #define pud_bad(pud)   0
   #define pud_present(pud)   1
   #define pud_ERROR(pud) do { } while (0)
  -#define pud_clear(pud) do { } while (0)
  +#define pud_clear(pud) pgd_clear((pgd_t *)(pud))
   
 
 Just a small nit - no cast needed here.

Well, do you know ? pud is a pud_t* and the arch is free to implement
pgd_clear as an inline with strong typing no ? 

Ben.


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


Re: [PATCH] Fix possible race with 4level-fixup.h

2005-02-17 Thread Nick Piggin
Benjamin Herrenschmidt wrote:
Index: linux-work/include/asm-generic/4level-fixup.h
===
--- linux-work.orig/include/asm-generic/4level-fixup.h  2005-01-24 
17:09:49.0 +1100
+++ linux-work/include/asm-generic/4level-fixup.h   2005-02-17 
18:10:38.0 +1100
@@ -24,7 +24,7 @@
#define pud_bad(pud)0
#define pud_present(pud)1
#define pud_ERROR(pud)  do { } while (0)
-#define pud_clear(pud) do { } while (0)
+#define pud_clear(pud) pgd_clear((pgd_t *)(pud))
Just a small nit - no cast needed here.

Well, do you know ? pud is a pud_t* and the arch is free to implement
pgd_clear as an inline with strong typing no ? 

Yeah but if you're using the 4level-fixup.h header, then you get
#define pud_tpgd_t
Not that I really mind, but in this header we've just avoided
doing casts for that reason.
Nick
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


bt8xxx would not reset properly

2005-02-17 Thread Eyal Lebedinsky
I have a bt848 based TV tuner (see bootlog below) which sometimes
goes on the blink (see failure log below). It will not reset, and a
reboot does not fix it. I need to cycle the power to get it back
online.
I know that 2.6.10 and 2.6.11-rc4 did not restore operation when
booted, and I recall this even on earlier kernels.
I wonder if the reset process is not as extensive as it should be.
Naturally, it is possible that the card, when it fails, is in
a state where a reset is just not possible. It will be nice if this
can be improved though.
Boot log

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 :03:01.0[A] - GSI 21 (level, low) - IRQ 21
bttv0: Bt848 (rev 18) at :03:01.0, irq: 21, latency: 32, mmio: 0xde00
bttv0: using: STB, Gateway P/N 6000699 (bt848) [card=3,insmod option]
bttv0: gpio config override: mask=0x7, mux=0x1,0x0,0x2,0x3,0x4
bttv0: gpio: en=, out= in=00f0c0fc [init]
tuner: chip found at addr 0xc0 i2c-bus bt848 #0 [sw]
tuner: type set to 5 (Philips PAL_BG (FI1216 and compatibles)) by insmod option
tuner: The type=n insmod option will go away soon.
tuner: Please use the tuner=n option provided by
tuner: tv aard core driver (bttv, saa7134, ...) instead.
bttv0: using tuner=2
tuner: type already set to 5, ignoring request for 2
bttv0: registered device video0
bttv0: registered device vbi0
bttv0: registered device radio0
bttv0: PLL can sleep, using XTAL (35468950).
bttv: Bt8xx card found (1).
Typical failure
===
Feb 17 09:09:33 eyal kernel: bttv0: OCERR @ 37efb000,bits: HSYNC OFLOW OCERR*
Feb 17 09:09:34 eyal last message repeated 14 times
Feb 17 09:09:34 eyal kernel: bttv0: OCERR @ 37efb000,bits: HSYNC OFLOW FDSR 
OCERR*
Feb 17 09:09:37 eyal last message repeated 66 times
Feb 17 09:09:37 eyal kernel: bttv0: timeout: drop=39 irq=318/321, 
risc=37efb01c, bits: HSYNC OFLOW
Feb 17 09:09:37 eyal kernel: bttv0: reset, reinitialize
Feb 17 09:09:37 eyal kernel: bttv0: PLL can sleep, using XTAL (35468950).
Feb 17 09:09:37 eyal kernel: bttv0: OCERR @ 37efb000,bits: VSYNC HSYNC OFLOW 
FDSR OCERR*
Feb 17 09:09:45 eyal last message repeated 200 times
Feb 17 09:09:45 eyal kernel: bttv0: timeout: drop=241 irq=726/729, risc=37efb01c, 
bits: VSYNC HSYNC OFLOW6bttv0: OCERR @ 37efb000,bits: HSYNC OFLOW FBUS FDSR 
OCERR*
Feb 17 09:09:45 eyal kernel:
Feb 17 09:09:45 eyal kernel: bttv0: reset, reinitialize
Feb 17 09:09:45 eyal kernel: bttv0: PLL can sleep, using XTAL (35468950).
Feb 17 09:09:45 eyal kernel: bttv0: OCERR @ 37efb000,bits: VSYNC HSYNC OFLOW 
OCERR*
Feb 17 09:09:45 eyal last message repeated 11 times
Feb 17 09:09:45 eyal kernel: bttv0: timeout: drop=242 irq=743/746, risc=37efb01c, 
6bttv0: OCERR @ 37efb000,bits: VSYNC HSYNC OFLOW FBUS OCERR*
Feb 17 09:09:45 eyal kernel: bits: VSYNC HSYNC OFLOW6bttv0: OCERR @ 
37efb000,bits: VSYNC HSYNC OFLOW OCERR*
--
Eyal Lebedinsky ([EMAIL PROTECTED]) http://samba.org/eyal/
attach .zip as .dat
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [BK] upgrade will be needed

2005-02-17 Thread Roland Kuhn
Hi Clemens!
On Feb 17, 2005, at 9:09 AM, Clemens Schwaighofer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/17/2005 04:55 PM, Roland Kuhn wrote:
That said, it would of course be possible to improve the internal
workflow of our emperor penguin if he used subversion, but the
collaboration with others could not benefit the way it does with a
changeset-based approach.
Question is then, what about keeping a main trunk with the vanialle
release, and each dev has its own branch. now at a certain point you
have to merge them. Now where is the difference between a central rep
and a de-central one.
At day X, patches from Andrew's tree have to go to Linus tree and from
his tree into the new vanialla kernel. right?
Somehow I can't see the difference here.
The difference comes after the merge. Suppose Andrew didn't push 
everything to Linus. Then new patches come in, both trees change. In 
this situation it is very time consuming with subversion to work out 
the changes which still have to go from Andrew's tree to Linus' tree.

Ciao,
Roland
--
TU Muenchen, Physik-Department E18, James-Franck-Str. 85747 Garching
Telefon 089/289-12592; Telefax 089/289-12570
--
A mouse is a device used to point at
the xterm you want to type in.
Kim Alm on a.s.r.


PGP.sig
Description: This is a digitally signed message part


Re: possible leak in kernel 2.6.10-ac12

2005-02-17 Thread Maciej Soltysiak
Hello Pedro,

Thursday, February 17, 2005, 12:28:15 AM, you wrote:

 boot. It came to a point that it started swapping and the swap usage too
 started to grow linearly.
I had the same with swap being eaten especially by perl apps like qmail-scanner

I think this helps:
--- a/mm/vmscan.c   2004-12-24 13:36:18 -08:00
+++ b/mm/vmscan.c   2004-12-24 13:36:18 -08:00
@@ -675,6 +674,7 @@
 }
 pgscanned++;
 }
+zone-pages_scanned += pgscanned;
 zone-nr_active -= pgmoved;
 spin_unlock_irq(zone-lru_lock);

This patchlet is at:
http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.6%2Fpatch-2.6.10.bz2;z=4918
This changeset contains other patches, you need only one.

2.6.11 will have it fixed.

Regards,
Maciej Soltysiak


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] passcred cleanup in struct socket

2005-02-17 Thread Herbert Poetzl

struct socket uses a 'bool' (unsigned char) to
'flag' the pass-credential option for sockets
(which can be easily replaced by a flag)

best,
Herbert


diff -NurpP --minimal linux-2.6.11-rc4/include/linux/net.h 
linux-2.6.11-rc4-sock/include/linux/net.h
--- linux-2.6.11-rc4/include/linux/net.h2005-02-13 17:17:06 +0100
+++ linux-2.6.11-rc4-sock/include/linux/net.h   2005-02-17 09:47:44 +0100
@@ -61,6 +61,7 @@ typedef enum {
 #define SOCK_ASYNC_NOSPACE 0
 #define SOCK_ASYNC_WAITDATA1
 #define SOCK_NOSPACE   2
+#define SOCK_PASSCRED  3
 
 #ifndef ARCH_HAS_SOCKET_TYPES
 /** sock_type - Socket types
@@ -111,7 +112,6 @@ struct socket {
struct sock *sk;
wait_queue_head_t   wait;
short   type;
-   unsigned char   passcred;
 };
 
 struct vm_area_struct;
diff -NurpP --minimal linux-2.6.11-rc4/include/net/scm.h 
linux-2.6.11-rc4-sock/include/net/scm.h
--- linux-2.6.11-rc4/include/net/scm.h  2004-08-14 12:55:32 +0200
+++ linux-2.6.11-rc4-sock/include/net/scm.h 2005-02-17 09:49:42 +0100
@@ -51,13 +51,13 @@ static __inline__ void scm_recv(struct s
 {
if (!msg-msg_control)
{
-   if (sock-passcred || scm-fp)
+   if (test_bit(SOCK_PASSCRED, sock-flags) || scm-fp)
msg-msg_flags |= MSG_CTRUNC;
scm_destroy(scm);
return;
}
 
-   if (sock-passcred)
+   if (test_bit(SOCK_PASSCRED, sock-flags))
put_cmsg(msg, SOL_SOCKET, SCM_CREDENTIALS, sizeof(scm-creds), 
scm-creds);
 
if (!scm-fp)
diff -NurpP --minimal linux-2.6.11-rc4/net/core/sock.c 
linux-2.6.11-rc4-sock/net/core/sock.c
--- linux-2.6.11-rc4/net/core/sock.c2005-02-13 17:17:18 +0100
+++ linux-2.6.11-rc4-sock/net/core/sock.c   2005-02-17 09:49:42 +0100
@@ -333,7 +333,10 @@ int sock_setsockopt(struct socket *sock,
break;
 
case SO_PASSCRED:
-   sock-passcred = valbool;
+   if (valbool)
+   set_bit(SOCK_PASSCRED, sock-flags);
+   else
+   clear_bit(SOCK_PASSCRED, sock-flags);
break;
 
case SO_TIMESTAMP:
@@ -557,7 +560,7 @@ int sock_getsockopt(struct socket *sock,
break; 
 
case SO_PASSCRED:
-   v.val = sock-passcred;
+   v.val = test_bit(SOCK_PASSCRED, sock-flags) ? 1 : 0;
break;
 
case SO_PEERCRED:
diff -NurpP --minimal linux-2.6.11-rc4/net/socket.c 
linux-2.6.11-rc4-sock/net/socket.c
--- linux-2.6.11-rc4/net/socket.c   2005-02-13 17:17:19 +0100
+++ linux-2.6.11-rc4-sock/net/socket.c  2005-02-17 09:34:41 +0100
@@ -287,7 +287,7 @@ static struct inode *sock_alloc_inode(st
ei-socket.ops = NULL;
ei-socket.sk = NULL;
ei-socket.file = NULL;
-   ei-socket.passcred = 0;
+   ei-socket.flags = 0;
 
return ei-vfs_inode;
 }
diff -NurpP --minimal linux-2.6.11-rc4/net/unix/af_unix.c 
linux-2.6.11-rc4-sock/net/unix/af_unix.c
--- linux-2.6.11-rc4/net/unix/af_unix.c 2005-02-13 17:17:19 +0100
+++ linux-2.6.11-rc4-sock/net/unix/af_unix.c2005-02-17 09:49:42 +0100
@@ -861,8 +861,8 @@ static int unix_dgram_connect(struct soc
goto out;
alen = err;
 
-   if (sock-passcred  !unix_sk(sk)-addr 
-   (err = unix_autobind(sock)) != 0)
+   if (test_bit(SOCK_PASSCRED, sock-flags) 
+   !unix_sk(sk)-addr  (err = unix_autobind(sock)) != 0)
goto out;
 
other=unix_find_other(sunaddr, alen, sock-type, hash, err);
@@ -952,7 +952,8 @@ static int unix_stream_connect(struct so
goto out;
addr_len = err;
 
-   if (sock-passcred  !u-addr  (err = unix_autobind(sock)) != 0)
+   if (test_bit(SOCK_PASSCRED, sock-flags)
+!u-addr  (err = unix_autobind(sock)) != 0)
goto out;
 
timeo = sock_sndtimeo(sk, flags  O_NONBLOCK);
@@ -1286,7 +1287,8 @@ static int unix_dgram_sendmsg(struct kio
goto out;
}
 
-   if (sock-passcred  !u-addr  (err = unix_autobind(sock)) != 0)
+   if (test_bit(SOCK_PASSCRED, sock-flags)
+!u-addr  (err = unix_autobind(sock)) != 0)
goto out;
 
err = -EMSGSIZE;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [BK] upgrade will be needed

2005-02-17 Thread Geert Uytterhoeven
On Thu, 17 Feb 2005, Pavel Machek wrote:
   if they really need the more powerful features.  Or we could donate
   some on a case by case basis.
   
   If the hackers who are using BK can reach agreement that it would be
   better if the BK they had didn't move forward unless they got commercial
   seats then we could start moving towards a license on the free product
   that was less restrictive.  What that would mean is that the BK you have
  
   I want to pay the fee for Linus and Alan.
  
  I'd like to pay the fee to have Linus' license to use BK revoked.  But
  I probably can't afford it, oh well :-)
 
 Easy, start working for OSDL, then start hacking arch or
 whatever. Puff, you are his coworker, you are competing with Larry,
 Linus license goes away.

I don't know whether the kernel hackers that work for IBM use the `free'
version of BK or not, but if they do, s/OSDL/IBM/ and s/arch/ClearCase/ and
there's a problem...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [Fastboot] Re: [PATCH] /proc/cpumem

2005-02-17 Thread Eric W. Biederman
Itsuro Oda [EMAIL PROTECTED] writes:

 Hi Eric,
 
  The lack of a type field looses a fair amount of functionality compared
  to /proc/iomem.  In particular you can't see where the ACPI data is.
 
 Hmm, restricting System RAM only may be too pessimistic.
 (One of motivations of this work is for using /dev/mem safely.
  dd if=/dev/mem of=xxx causes panic on my amd64(8GB mem) machine
  since reading from address around 0xfe00 causes a machine
  check. hmm, this area is marked as reserved. not ACPI area.
  ACPI area can be read.)
 
 Ok, I will add a type field.

To be very clear.  I do not believe is necessary for x86.  The
is already sufficient information elsewhere to handle this.

  The other direction something like this can go is to dump 
  the data structures in linux/mmzone.h 
 
 Do you mean defining a data structure in linux/mmzone.h ?
 
 I used to think a particular struct is not necessary for this work,
 but now I think it is better to define a struct for this.
 Let me consider. 

To be clear there are two pieces of information that are needed.
1) The list of physical memory areas and what they are.
   /proc/iomem does a good job of this.
2) The list of which memory areas the kernel is using.
   It is the pgdat_t and related structures that define this.
   For the purposes of a core dump we want to capture this
   information before the kernel crashes and use it afterward.

  I have written a first pass at a user space core dump generator,
  using /dev/mem.  /sbin/kexec still needs some work to prepare
  the ELF headers before a crash.
 
 I am looking forward this :-)
 
 And, you mentioned a couple of weeks ago:
  Anyway one thing I want to do is actually drop the apic shutdown
  code altogether in this code path.  I threw it in there to
  ease the transition from the old code base to the new, but
  if that code is causing issues  So this is probably a good time
  to start testing that.
 
 How about this ?

My role in this is that of maintainer and architect.  On a practical
level I gain nothing from a working crash-dump/kexec-on-panic
implementation except it stops being a gating factor for the rest
of the kexec code.  So while many times I can see what needs to be
done it is hard for me to justify doing it.  So a lot of times
where I will weigh in with code is when I see a particular blind spot
on the part of the implementors.

The parties I see actively working on the crash dump implementation
are currently a group from IBM and you guys from valinux.co.jp.
One of the primaries at IBM has been on vacation which is likely
why we have not seen anything out of them for the last couple of
weeks.

But also this is open source software it will be done when it
is done.

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


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

2005-02-17 Thread Vojtech Pavlik
On Thu, Feb 17, 2005 at 01:16:45AM -0500, Len Brown wrote:

 Pavel,
 I think that it is the BIOS' job on S3-suspend
 to save the video mode.  On S3-resume the BIOS should
 re-POST and restore the video mode.

Should.

But this definitely is not the case on about 80+% of notebooks.

You can save the video state through VESA VBE, and restore it on resume,
but if the BIOS didn't re-POST the video, this will often fail.

 While Linux's X drivers may be able to handle the case
 where X is running -- that doesn't help us with the
 cases where X is not running (a case that Windows
 presumably does not have).
 
 Besides updated X drivers, which may have complicated
 restore routines for complicated modes, all the other
 techniques for restoring video from Linux are
 hit/miss workarounds for broken platforms.
 
 To completely solve the Linux S3 video restore issue,
 we need to push the platform and BIOS vendors.

That's correct.

 What am I missing?
 
I'm not sure if you can push the whole industry at once.

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


Re: Bug in SLES8 kernel 2.4.x freezing HP DL740/760

2005-02-17 Thread Bernd Petrovitsch
On Wed, 2005-02-16 at 22:03 +0100, Oliver Antwerpen wrote:
 Matthias-Christian Ott schrieb:
  Oliver Antwerpen wrote:
  SuSE has patched UNICON into the kernel which will cause these servers 
  to hang when booted with vga=normal. The system will run fine in 
  fb-mode, but not in plain text.
 
  Well if you don't need unicon, then remove the patch from the .spec file 
  and rebuild the kernel (from the source rpm). Or report it their bug 
  tracking system.
 
 My problem ist, that when I change .config, then I lose my support. So
 SuSE or HP have to tell me to do so.

And they listen here to you?

Bernd
-- 
Firmix Software GmbH   http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
  Embedded Linux Development and Services

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


Re: [BK] upgrade will be needed

2005-02-17 Thread Sean
On Thu, February 17, 2005 4:27 am, Roland Kuhn said:

 The difference comes after the merge. Suppose Andrew didn't push
 everything to Linus. Then new patches come in, both trees change. In
 this situation it is very time consuming with subversion to work out
 the changes which still have to go from Andrew's tree to Linus' tree.

Since Andrew does this all by hand now, subversion / arch / whatever could
only improve the situation.  And the kicker is that using a free system
would mean the result could be dumped into BK for those that want to use
it.   The reverse unfortunately isn't true; not because of technical
reasons, but because of license restrictions.

Sean


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


Re: Oops in 2.6.10-ac12 in kjournald (journal_commit_transaction)

2005-02-17 Thread Ralf Hildebrandt
* Andrew Morton [EMAIL PROTECTED]:

 There have been a handful of reports - there's surely a race in there.
 
 Unfortunately I've yet to see a report from which we can identify the
 offending line in the very large journal_commit_transaction() function.

:(

 
 The best way to do that is to ensure that the kernel was built with
 CONFIG_DEBUG_INFO, note the offending EIP value, then do
 
 # gdb vmlinux
 (gdb) l *0xc0whatever

I'm rebuilding the ac12 kernel which crashed on me after just one day
and will reboot it today.

-- 
Ralf Hildebrandt (i.A. des IT-Zentrum)  [EMAIL PROTECTED]
Charite - Universitätsmedizin BerlinTel.  +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-BerlinFax.  +49 (0)30-450 570-962
IT-Zentrum Standort CBF send no mail to [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2005-02-17 Thread Matthew Garrett
On Thu, 2005-02-17 at 01:16 -0500, Len Brown wrote:
 Pavel,
 I think that it is the BIOS' job on S3-suspend
 to save the video mode.  On S3-resume the BIOS should
 re-POST and restore the video mode.

I agree, but in the absence of spec requirement and some form of
certification process, I don't see it happening in the near future.
Given that vendors are still shipping invalid DSDTs, if Windows is able
to reinitialise the graphics hardware, few are going to care about
making life easier for Linux.

-- 
Matthew Garrett | [EMAIL PROTECTED]

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


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

2005-02-17 Thread Pavel Machek
Hi!

 I think that it is the BIOS' job on S3-suspend
 to save the video mode.  On S3-resume the BIOS should
 re-POST and restore the video mode.

Can you find it written down somewhere? It would be certainly easier
for me if every BIOS did re-post, but it is not the case on any new
BIOS

 To completely solve the Linux S3 video restore issue,
 we need to push the platform and BIOS vendors.
 
 What am I missing?

I think we are missing few lines in docs somewhere saying video must
be re-POSTed during S3 wakeup. And then we miss someone going around
vendors with baseball bat, telling them to fix their BIOSes.

Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2005-02-17 Thread Norbert Preining
On Die, 15 Feb 2005, Stefan Dösinger wrote:
  After deactivating DRI in the X config file and saving the states with
  your script (thanks) and turning off various stuff I get X running
  again.
 
  Questions:
  - DRI must be disabled I guess?! Even with newer X server (x.org)?

 Do you use the fglrx driver? This doesn't work with any type of suspend so 

No

 far. If you use the radeon driver try a driver update.

From deb http://www.nixnuts.net/files/ ./ ??

Or direct from dri.freedesktop.org, and updating X to X.org on sid?

Best wishes

Norbert

---
Norbert Preining preining AT logic DOT at Università di Siena
sip:[EMAIL PROTECTED] +43 (0) 59966-690018
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
SWANIBOST (adj.)
Complete shagged out after a hard day having income tax explained to
you.
--- Douglas Adams, The Meaning of Liff
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Swsusp, resume and kernel versions

2005-02-17 Thread Pavel Machek
Hi!

 First of all I must say that swsusp has progressed alot and now works
 very reliably, at least for my configuration, and I use it a lot. Great
 job!
 
 But I think there is one pretty severe issue present - even if swsusp
 is not enabled kernel should check if there is an image in swap and
 erase it. Today I has somewhat unpleasant experience - after suspending
 I accidentially loaded a vendor kernel. I was in hurry and decided that
 resume just failed for some reason so I did couple of things and left
 the box running. In the evening I realized that I am running vendor kernel
 and decided to reboot into my devel. version. What I did not expect is for
 the kernel to find a valid suspend image and restore it. As you might
 imagine messed up my disk somewhat.

When all the vendor's kernels have swsusp, it will magically kill the
signature. Or stick mkswap /dev/XXX in your init scripts.
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: NTFS - Kernel memory leak in driver for kernel 2.4.28?

2005-02-17 Thread Anton Altaparmakov
On Wed, 2005-02-16 at 09:16 -0800, Martin Bogomolni wrote:
 I should say that the malloc() succeeds, but the 16mb I need for the
 buffer are not available.  Since there is no swap/page file in the
 embedded environment, there isn't enough memory left afterwards for
 the buffer.
 
 After taking another look at the problem, the kernel has a lot of
 memory tied up in the inode and dentry cache.   I've tuned
 /proc/sys/vm/vm_cache_scan_ratio, vm_mapped_ratio, vm_vfs_scan_ratio
 with no real success in shrinking the amount of memory used by these
 caches.
 
 Is there a way to tune and shring the overall amount of memory the
 kernel attempts to use for the dentry/inode cache, or make it much,
 much more aggressive at clearing it?

Are you using the old (1.x) or new (2.x) ntfs driver?

If you are using the old one you could try using the new driver.  That
should be a lot better than the old one in terms of how much memory it
uses.  You can get an outdated patch (but should still work) for the new
driver here:

http://sourceforge.net/project/showfiles.php?group_id=13956package_id=21892

Best regards,

Anton
-- 
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/  http://www-stu.christs.cam.ac.uk/~aia21/

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


Re: [Linux-fbdev-devel] Re: i810 BUG summary. Was Re: [SoftwareSuspend-devel] [Announce] 2.1.7 for 2.6.11-rc4

2005-02-17 Thread Antonino A. Daplas
On Thursday 17 February 2005 12:39, Nigel Cunningham wrote:
 Hi Michael.

 Perhaps this belongs with the framebuffer devel guys? I'll copy them
 now. Antonio et al, have I called it right?

Is he using a framebuffer console or vgacon?

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: [Linux-fbdev-devel] Re: i810 BUG summary. Was Re: [SoftwareSuspend-devel] [Announce] 2.1.7 for 2.6.11-rc4

2005-02-17 Thread mhf
On Thursday 17 February 2005 13:09, Antonino A. Daplas 
wrote:
 On Thursday 17 February 2005 12:39, Nigel Cunningham 
wrote:
  Hi Michael.
 
  Perhaps this belongs with the framebuffer devel guys?
  I'll copy them now. Antonio et al, have I called it
  right?

 Is he using a framebuffer console or vgacon?

 Tony

Sorry, using vgacon and I shall be more specific next time.

Good point, I will test it also with fbcon and report back.

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


x86_64: AGP support for SiS760?

2005-02-17 Thread Thomas Winischhofer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The SiS760 is an AMD64 chipset and AGP support works nicely in 32bit
mode. So why is AGP_SIS only configurable if !X86_64?
Thomas
- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net
twini AT xfree86 DOT org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCFI6qzydIRAktyUcRAkIwAJsFzCUaBm2G0Q+hUsvx4yJQqC/GjACgg+yG
kYo5c2wl6/s0ZPioAVbvPUY=
=Mn0b
-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/


Re: [BK] upgrade will be needed

2005-02-17 Thread Pavel Machek
Hi!

  Easy, start working for OSDL, then start hacking arch or
  whatever. Puff, you are his coworker, you are competing with Larry,
  Linus license goes away.
 
 I don't know whether the kernel hackers that work for IBM use the `free'
 version of BK or not, but if they do, s/OSDL/IBM/ and s/arch/ClearCase/ and
 there's a problem...

Actually someone should show the license agreement to IBM (and Novell,
for that matter) lawyers. I guess next thing would be company-wide
search-and-destroy aimed at bitkeeper ;-).
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


2.6.11-rc4: touch pad misidentified (ALPS instead of ImPS/2)

2005-02-17 Thread Michael Brade
Hi,

the new 2.6.11-rc series has another problem for me, my touchpad (Toshiba 
Laptop) stopped working. I guess this has to do with [PATCH] ALPS touchpad 
detection fix that was posted about 4 weeks ago. The kernel says while 
booting:

newton kernel: mice: PS/2 mouse device common for all mice
newton kernel: input: AT Translated Set 2 keyboard on isa0060/serio0
newton kernel: ALPS Touchpad (Glidepoint) detected
newton kernel:   Disabling hardware tapping
newton kernel: input: AlpsPS/2 ALPS TouchPad on isa0060/serio1

and when I try to use it, the following is spit out:

last message repeated 2 times
kernel: psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
last message repeated 2 times
kernel: psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1

This goes on until I stop touching the touchpad. With up to 2.6.10 there were 
no problems and the kernel said:

newton kernel: mice: PS/2 mouse device common for all mice
newton kernel: input: AT Translated Set 2 keyboard on isa0060/serio0
newton kernel: input: ImPS/2 Generic Wheel Mouse on isa0060/serio1

I haven't compiled in any ISA support, but I don't think this can be the 
reason since I haven't changed the kernel config between 2.6.10 and 2.6.11.

Thanks for any help,
  Michael

PS: I'm not subscribed.
-- 
Michael Brade; KDE Developer, Student of Computer Science
  |-mail: echo brade !#|tr -d c oh|s\e\d 's/e/\@/2;s/$/.org/;s/bra/k/2'
  °--web: http://www.kde.org/people/michaelb.html

KDE 3: The Next Generation in Desktop Experience


pgp98gmOYgnOz.pgp
Description: PGP signature


rmmod while module is in use

2005-02-17 Thread Davide Rossetti
maybe RTFM...
a module:
- char device driver for..
- a PCI device
any clue as to how to protect from module unloading while there is still 
some process opening it??? have I to sleep in the remove_one() pci 
driver function till last process closes its file descriptor???

static void __devexit apedev_remove_one(struct pci_dev *pdev)
{
   ApeDev* apedev = pci_get_drvdata(pdev);
   if(test_bit(APEDEV_FLAG_OPEN, apedev-flags)) {
   PERROR(still open flag on!!! (flags=0x%08x)\n, apedev-flags);
   // sleep here till it gets closed...
   }
   ...
}
static struct pci_driver apedev_driver = {
   .name =  DEVNAME,
   .id_table =  apedev_pci_tbl,
   .probe=  apedev_init_one,
   .remove   =  __devexit_p(apedev_remove_one),
};
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [OOPS] 2.6.10, ReiserFS errors, preempt

2005-02-17 Thread Sami Farin
On Thu, Feb 17, 2005 at 01:59:47AM +0100, Guennadi Liakhovetski wrote:
 Hi
 
 The machine was running updatedb, while I was trying to burn on an ATAPI 
 CDR (hdc) and read a SCSI DVD-ROM not very intensively, ran a couple of 
 random applications, when my /home partition (hda7) became unaccessible, 

some apps using bttv?

 then came a few Oopses. I sysrq-dumped traces and rebooted. After the 
 reboot /home mounted without any errors, nothing seems to be lost 
 (phew...). In logs found a few ReiserFS errors before the Oops. Attached 
 is a log, perhaps too verbous - sorry.
 
 In kernel configured ACPI (no suspends), USB-UHCI, Bluetooth, bttv, no 
 ide-scsi, CONFIG_BLK_DEV_VIA82CXXX, LAPIC, boot parameter nmi_watchdog=2 
 (doesn't seem to work anyway), hda is a pretty new. Just looked at 
 smartctl -a /dev/hda - didn't see anything bad (not 100% sure though).
 
 A comment fixed in latest 2.6.11-rcX would be gladly accepted:-)

I don't know, but if I keep on whacking 'v' in xawtv (Video (Capture) on/off),
I get this kind of crap sooner or later (and Oops a bit later).

Dec 25 16:27:37 safari kernel: bttv0: timeout: drop=18 irq=3151491/3151491, 
risc=0d85301c, bits: VSYNC HSYNC OFLOW
Dec 25 16:27:38 safari kernel: bttv0: reset, reinitialize
Dec 25 16:27:38 safari kernel: bttv0: PLL: 28636363 = 35468950 . ok
Dec 25 16:29:56 safari kernel: ReiserFS: warning: is_tree_node: node level 8 
does not match to the expected one 1
Dec 25 16:29:56 safari kernel: ReiserFS: hda6: warning: vs-5150: search_by_key: 
invalid format found in block 1774456. Fsck?

so, can you reproduce the Oops without using bttv?
I believe there's unresolved memory corruption bug in bttv...

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


Re: -rc3 leaking NOT BIO [Was: Memory leak in 2.6.11-rc1?]

2005-02-17 Thread Parag Warudkar
On Wednesday 16 February 2005 06:52 pm, Andrew Morton wrote:
 So it's probably an ndiswrapper bug?
Andrew, 
It looks like it is a kernel bug triggered by NdisWrapper. Without 
NdisWrapper, and with just 8139too plus some light network activity the 
size-64 grew from ~ 1100 to 4500 overnight. Is this normal? I will keep it 
running to see where it goes.

A question - is it safe to assume it is  a kmalloc based leak? (I am thinking 
of tracking it down by using kprobes to insert a probe into __kmalloc and 
record the stack to see what is causing so many allocations.)

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


Re: [PATCH] Realtime preempt support for PPC

2005-02-17 Thread Frank Rowand
Ingo Molnar wrote:
* Frank Rowand [EMAIL PROTECTED] wrote:

I have attached a patch to add realtime support for PowerPC (32 bit
only). [...]

two comments:
- why is us_to_tb needed? It just seems to add alot of unnecessary
  clutter to the patch, while it's not used anywhere.
Sorry, the usage of us_to_tb got dropped from the patch when I moved
it from one of my development trees to another.  It gets used in
usecs_to_cycles().  The patch to add that is attached below.
Even with the usage of us_to_tb by usecs_to_cycles(), there is a lot
of added clutter for what is accomplished.  I considered a nasty hack
to try to derive the proper value from other sources, but adding
us_to_tb seemed a lot easier to understand.
This patch also adds the dreaded #ifdefs, so I suspect it will not be
the correct implementation long term.  I'm not sure if Manish's patch
included the ARM implementation of usecs_to_cycles() - it is a third
case in the #ifdef.
Performance instrumentation is also going to need mcount() and
_mcount(), which is currently a work in progress.
- could you submit the drivers/net/ibm_emac/ibm_emac_core.c patch
  upstream as well?
Yes, I will do that.

otherwise it looks pretty clean and straightforward.
	Ingo

Source: MontaVista Software, Inc.
Signed-off-by: Frank Rowand [EMAIL PROTECTED]
Index: linux-2.6.10/kernel/latency.c
===
--- linux-2.6.10.orig/kernel/latency.c
+++ linux-2.6.10/kernel/latency.c
@@ -192,7 +192,11 @@ static unsigned long notrace cycles_to_u
 static cycles_t notrace usecs_to_cycles(unsigned long delta)
 {
+#if defined CONFIG_X86
return (cycles_t) delta * (cycles_t) (cpu_khz/1000+1);
+#elif defined(CONFIG_PPC)
+   return delta * us_to_tb;
+#endif
 }
 #ifdef CONFIG_LATENCY_TRACE

Thanks,
-Frank (off to vacation for a couple days)
--
Frank Rowand [EMAIL PROTECTED]
MontaVista Software, Inc
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: rmmod while module is in use

2005-02-17 Thread linux-os
On Thu, 17 Feb 2005, Davide Rossetti wrote:
maybe RTFM...
a module:
- char device driver for..
- a PCI device
any clue as to how to protect from module unloading while there is still some 
process opening it??? have I to sleep in the remove_one() pci driver function 
till last process closes its file descriptor???

The kernel code is supposed to prevent module removal when it
is still in use. Have you discovered a bug where the kernel
will allow unloading when it's still being used???
There used to be MOD_INC_USE_COUNT and MOD_DEC_USE_COUNT
macros to be using in open() and close(). However their
use has been depreciated in favor of some internal kernel
magic. So, unless you have discovered a bug, your code
doesn't have to worry anymore.
static void __devexit apedev_remove_one(struct pci_dev *pdev)
{
  ApeDev* apedev = pci_get_drvdata(pdev);
  if(test_bit(APEDEV_FLAG_OPEN, apedev-flags)) {
  PERROR(still open flag on!!! (flags=0x%08x)\n, apedev-flags);
  // sleep here till it gets closed...
  }
  ...
}
static struct pci_driver apedev_driver = {
  .name =  DEVNAME,
  .id_table =  apedev_pci_tbl,
  .probe=  apedev_init_one,
  .remove   =  __devexit_p(apedev_remove_one),
};
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


AMD 64 and Kernel AGPart support

2005-02-17 Thread Marc Cramdal
Hello,

I have an AMD 64 (gentoo compiled for amd64) and I would like to succeed in my 
video driver installation (ATI Radeon 9250 :-/). I would need the agpgart 
support for the Sis Chipset, but all the entry for agpgart are grayed, I 
can't change anything (Kernel 2.6.9, 2.6.10 ...)

So is it normal or a bug ?? , or am I making a mistake.

NB: one of my friends made the test, without AMD64 and exactly the same kernel 
he can check these options within agpgart...

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


Re: rmmod while module is in use

2005-02-17 Thread Sean Neakums
Davide Rossetti [EMAIL PROTECTED] writes:

 maybe RTFM...
 a module:
 - char device driver for..
 - a PCI device

Setting the 'owner' field of your char device's file_operations
structure to THIS_MODULE should be sufficient to enable the kernel to
manage the reference count for you.  This is the magic referred to
in linux-os's reply.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: AMD 64 and Kernel AGPart support

2005-02-17 Thread Thomas Winischhofer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I wondered about this a couple of minutes ago, too. I have a SiS760 and
can't enable AGP support either.
What host bridge does your system have? If it's anything but a 760, the
agpgart code for sis needs to be patched by adding the proper PCI ID.
(All this apart from the !X86_64 in the Kconfig file.)
I am running 32bit only at the moment (waiting for a new harddisk to
install, the 32bit system is only for some initial testing), but does
AGP compile and initialize correctly if you remove the !X86_64 in
drivers/char/agp/Kconfig at the AGP_SIS entry?
Thomas
- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net *** http://www.winischhofer.net
twini AT xfree86 DOT org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCFJodzydIRAktyUcRAoIlAJ9jHr0rvTzx4Ea5eLWZsmhj3h9iBgCgvt6r
aSKGQteRZWegCJq3i3Lmf+c=
=y/95
-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/


Re: Oops in 2.6.10-ac12 in kjournald (journal_commit_transaction)

2005-02-17 Thread Ralf Hildebrandt
* Ralf Hildebrandt [EMAIL PROTECTED]:

  The best way to do that is to ensure that the kernel was built with
  CONFIG_DEBUG_INFO, note the offending EIP value, then do
  
  # gdb vmlinux
  (gdb) l *0xc0whatever
 
 I'm rebuilding the ac12 kernel which crashed on me after just one day
 and will reboot it today.

Is it normal that the kernel with debugging enabled is not larger than
the normal 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/


Re: -rc3 leaking NOT BIO [Was: Memory leak in 2.6.11-rc1?]

2005-02-17 Thread Parag Warudkar
On Wednesday 16 February 2005 10:48 pm, Horst von Brand wrote:
 Does x86_64 use up a (freeable) register for the frame pointer or not?
 I.e., does -fomit-frame-pointer have any effect on the generated code?

{Took Linus out of the loop as he probably isn't interested}

The generated code is different for both cases but for some reason gcc has 
trouble with __builtin_return_address on x86-64.

For e.g. specifying gcc -fo-f-p, a method produces following assembly.

method_1:
.LFB2:
subq$8, %rsp
.LCFI0:
movl$__FUNCTION__.0, %esi
movl$.LC0, %edi
movl$0, %eax
callprintf
movl$0, %eax
addq$8, %rsp
ret

And with -fno-o-f-p,  the same method yields 

method_1:
.LFB2:
pushq   %rbp
.LCFI0:
movq%rsp, %rbp
.LCFI1:
movl$__FUNCTION__.0, %esi
movl$.LC0, %edi
movl$0, %eax
callprintf
movl$0, %eax
leave
ret
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [OOPS] 2.6.10, ReiserFS errors, preempt

2005-02-17 Thread castet . matthieu
Hi,

 I believe there's unresolved memory corruption bug in bttv...
yes I think so, other have also similar problem :
http://marc.theaimsgroup.com/?l=linux-kernelm=110820804010204w=2
http://marc.theaimsgroup.com/?t=11053154392r=1w=2
http://www.ussg.iu.edu/hypermail/linux/kernel/0412.3/0881.html

Matthieu
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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-rc4: touch pad misidentified (ALPS instead of ImPS/2)

2005-02-17 Thread Dmitry Torokhov
On Thu, 17 Feb 2005 13:37:55 +0100, Michael Brade
[EMAIL PROTECTED] wrote:
 Hi,
 
 the new 2.6.11-rc series has another problem for me, my touchpad (Toshiba
 Laptop) stopped working. I guess this has to do with [PATCH] ALPS touchpad
 detection fix that was posted about 4 weeks ago. The kernel says while
 booting:
 
 newton kernel: mice: PS/2 mouse device common for all mice
 newton kernel: input: AT Translated Set 2 keyboard on isa0060/serio0
 newton kernel: ALPS Touchpad (Glidepoint) detected
 newton kernel:   Disabling hardware tapping
 newton kernel: input: AlpsPS/2 ALPS TouchPad on isa0060/serio1
 
 and when I try to use it, the following is spit out:
 
 last message repeated 2 times
 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1
 last message repeated 2 times
 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 - driver resynched.
 kernel: psmouse.c: TouchPad at isa0060/serio1/input0 lost sync at byte 1


Hi,

Could you please boot with i8042.debug log_buf_len=131072 boot
option, work touchpad a bit and send me your full dmesg (or
/var/log/messages), please?

I the meantime to get your touchpad working (after you send me the
dmesg) add psmouse.proto=exps to your boot options (or add options
psmouse proto=exps if psmouse is compiled as a module).

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


[PATCH 1/2] optimise copy page range

2005-02-17 Thread Nick Piggin
Some of you have seen this before. Just resending because
I based my next patch on top of this one.


Suggested by Linus: optimise a condition in the clear_p?d_range functions.
Results in one less conditional branch on i386 with gcc-3.4.4

Signed-off-by: Nick Piggin [EMAIL PROTECTED]


---

 linux-2.6-npiggin/mm/memory.c |9 ++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff -puN mm/memory.c~mm-opt-cpr mm/memory.c
--- linux-2.6/mm/memory.c~mm-opt-cpr2005-02-16 13:45:11.0 +1100
+++ linux-2.6-npiggin/mm/memory.c   2005-02-16 13:45:11.0 +1100
@@ -98,7 +98,8 @@ static inline void clear_pmd_range(struc
pmd_clear(pmd);
return;
}
-   if (!(start  ~PMD_MASK)  !(end  ~PMD_MASK)) {
+   if (!((start | end)  ~PMD_MASK)) {
+   /* Only clear full, aligned ranges */
page = pmd_page(*pmd);
pmd_clear(pmd);
dec_page_state(nr_page_table_pages);
@@ -131,7 +132,8 @@ static inline void clear_pud_range(struc
addr = next;
} while (addr  (addr  end));
 
-   if (!(start  ~PUD_MASK)  !(end  ~PUD_MASK)) {
+   if (!((start | end)  ~PUD_MASK)) {
+   /* Only clear full, aligned ranges */
pud_clear(pud);
pmd_free_tlb(tlb, __pmd);
}
@@ -162,7 +164,8 @@ static inline void clear_pgd_range(struc
addr = next;
} while (addr  (addr  end));
 
-   if (!(start  ~PGDIR_MASK)  !(end  ~PGDIR_MASK)) {
+   if (!((start | end)  ~PGDIR_MASK)) {
+   /* Only clear full, aligned ranges */
pgd_clear(pgd);
pud_free_tlb(tlb, __pud);
}

_


[PATCH 2/2] page table iterators

2005-02-17 Thread Nick Piggin
I am pretty surprised myself that I was able to consolidate
all page table range functions into a single type of iterator
(well, there are a couple of variations, but it's not too bad).
I thought at least the functions which allocate new page tables
would have to be seperate from those which don't it turns
out that if you slightly change the implementation of the
allocating functions, they start walking, quacking, etc. like
the other type.
This may also opens the way for things like:
#define for_each_pud(pgd, start, end, pud, pud_start, pud_end) \
if (pud = (pud_t *)pgd, pud_start = start, pud_end = end, 1)
for 2 and 3 level page tables (don't laugh if I've messed up the
above completely - you get the idea).
Then the last bit of the performance puzzle I think will just come
from inlining things. Now Andi doesn't want to do that (probably
rightly so)... what about compiling mm/ with -funit-at-a-time? It
doesn't do much harm to the stack, and it shaves off quite a few
KB...
Anyway, this iterator patch shaves off a bit itself. I haven't
looked at generated code, but I hope it is alright.
[EMAIL PROTECTED]:~/usr/src/linux-2.6$ size mm/memory.o.before
   textdata bss dec hex filename
  11349   4 120   114732cd1 mm/memory.o
[EMAIL PROTECTED]:~/usr/src/linux-2.6$ size mm/memory.o.after
   textdata bss dec hex filename
  11221   4 120   113452c51 mm/memory.o
Suggestions, help, etc. welcome.
Nick



---

 drivers/char/mem.c  |0 
 linux-2.6-npiggin/arch/i386/mm/ioremap.c|   78 +--
 linux-2.6-npiggin/include/asm-generic/pgtable.h |  128 +
 linux-2.6-npiggin/mm/memory.c   |  591 ++--
 linux-2.6-npiggin/mm/mprotect.c |  118 +---
 linux-2.6-npiggin/mm/msync.c|  159 ++
 linux-2.6-npiggin/mm/vmalloc.c  |  222 +++--
 7 files changed, 600 insertions(+), 696 deletions(-)

diff -puN include/asm-generic/pgtable.h~vm-pgt-walkers 
include/asm-generic/pgtable.h
--- linux-2.6/include/asm-generic/pgtable.h~vm-pgt-walkers  2005-02-17 
23:59:16.0 +1100
+++ linux-2.6-npiggin/include/asm-generic/pgtable.h 2005-02-18 
00:50:19.0 +1100
@@ -134,4 +134,132 @@ static inline void ptep_mkdirty(pte_t *p
 #define pgd_offset_gate(mm, addr)  pgd_offset(mm, addr)
 #endif
 
+/*
+ * for_each_pgd - iterates through pgd entries in a given mm structa
+ *
+ * @mm: the mm to use
+ * @start: the first address, inclusive
+ * @end: the last address, exclusive
+ * @pgd: the pgd iterator
+ * @pgd_start: the first address within the current 'pgd'
+ * @pgd_end: the last address within the current 'pgd'
+ *
+ * mm, start, end are all unchanged
+ * pgd, pgd_start, pgd_end may all be changed
+ */
+#define for_each_pgd(mm, start, end, pgd, pgd_start, pgd_end)  \
+   for (   pgd = pgd_offset(mm, start),\
+ pgd_start = start;\
+   pgd_end = (pgd_start + PGDIR_SIZE)  PGDIR_MASK,\
+ pgd_end = ((pgd_end  pgd_end = end) ? pgd_end : end), \
+ pgd = pgd_offset(mm, end-1); \
+   pgd_start = pgd_end,\
+ pgd++ )
+
+/*
+ * for_each_pgd_k - iterates through pgd entries in the kernel mapping
+ *
+ * see for_each_pgd
+ */
+#define for_each_pgd_k(start, end, pgd, pgd_start, pgd_end)\
+   for (   pgd = pgd_offset_k(start),  \
+ pgd_start = start;\
+   pgd_end = (pgd_start + PGDIR_SIZE)  PGDIR_MASK,\
+ pgd_end = ((pgd_end  pgd_end = end) ? pgd_end : end), \
+ pgd = pgd_offset_k(end-1);   \
+   pgd_start = pgd_end,\
+ pgd++ )
+
+/*
+ * for_each_pud - iterate through pud entries in a given pgd
+ *
+ * see for_each_pgd
+ */
+#define for_each_pud(pgd, start, end, pud, pud_start, pud_end) \
+   for (   pud = pud_offset(pgd, start),   \
+ pud_start = start;\
+   pud_end = (pud_start + PUD_SIZE)  PUD_MASK,\
+ pud_end = ((pud_end  pud_end = end) ? pud_end : end), \
+ pud = pud_offset(pgd, end-1);\
+   pud_start = pud_end,\
+ pud++ )
+
+/*
+ * for_each_pmd - iterate through pmd entries in a given pud
+ *
+ * see for_each_pgd
+ */
+#define for_each_pmd(pud, start, end, pmd, pmd_start, pmd_end) \
+   for (   pmd = pmd_offset(pud, start),   \
+ pmd_start = start;\
+   pmd_end = 

Re: [BK] upgrade will be needed

2005-02-17 Thread Citizen Number 24655
On Thu, Feb 17, 2005 at 01:36:03PM +0100, Citizen Number 52642 wrote:
   Easy, start working for OSDL, then start hacking arch or
   whatever. Puff, you are his coworker, you are competing with Larry,
   Linus license goes away.
  
  I don't know whether the kernel hackers that work for IBM use the `free'
  version of BK or not, but if they do, s/OSDL/IBM/ and s/arch/ClearCase/ and
  there's a problem...
 
 Actually someone should show the license agreement to IBM (and Novell,
 for that matter) lawyers. I guess next thing would be company-wide
 search-and-destroy aimed at bitkeeper ;-).

I think this attitude is completely rediculous.

What you are suggesting is taking away peoples right to choose to use
BitKeeper if they decide that it fits what they want to use it for,
and that they can live with the license terms (and/or have a special
agreement with BitMover for that purpose.)

Sure, that sounds exactly like a free world, Citizen Number 52642.

-- 
Citizen Number 24655
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 PCMCIA  - http://pcmcia.arm.linux.org.uk/
 2.6 Serial core
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] PHYSDEVDRIVER=NULL

2005-02-17 Thread Olaf Hering

For some reasons, PHYSDEVDRIVER can be NULL for block events.
So just check for that.

 base/class.c  |4 ++--
 base/core.c   |4 ++--
 block/genhd.c |4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

Signed-off-by: Olaf Hering [EMAIL PROTECTED]

diff -purNx tags ../linux-2.6.11-rc4.orig/drivers/base/class.c 
./drivers/base/class.c
--- ../linux-2.6.11-rc4.orig/drivers/base/class.c   2005-02-13 
04:08:06.0 +0100
+++ ./drivers/base/class.c  2005-02-17 14:42:56.0 +0100
@@ -314,13 +314,13 @@ static int class_hotplug(struct kset *ks
kfree(path);
 
/* add bus name of physical device */
-   if (dev-bus)
+   if (dev-bus  dev-bus-name)
add_hotplug_env_var(envp, num_envp, i,
buffer, buffer_size, length,
PHYSDEVBUS=%s, dev-bus-name);
 
/* add driver name of physical device */
-   if (dev-driver)
+   if (dev-driver  dev-driver-name)
add_hotplug_env_var(envp, num_envp, i,
buffer, buffer_size, length,
PHYSDEVDRIVER=%s, 
dev-driver-name);
diff -purNx tags ../linux-2.6.11-rc4.orig/drivers/base/core.c 
./drivers/base/core.c
--- ../linux-2.6.11-rc4.orig/drivers/base/core.c2005-02-13 
04:05:10.0 +0100
+++ ./drivers/base/core.c   2005-02-17 14:42:08.0 +0100
@@ -121,13 +121,13 @@ static int dev_hotplug(struct kset *kset
int retval = 0;
 
/* add bus name of physical device */
-   if (dev-bus)
+   if (dev-bus  dev-bus-name)
add_hotplug_env_var(envp, num_envp, i,
buffer, buffer_size, length,
PHYSDEVBUS=%s, dev-bus-name);
 
/* add driver name of physical device */
-   if (dev-driver)
+   if (dev-driver  dev-driver-name)
add_hotplug_env_var(envp, num_envp, i,
buffer, buffer_size, length,
PHYSDEVDRIVER=%s, dev-driver-name);
diff -purNx tags ../linux-2.6.11-rc4.orig/drivers/block/genhd.c 
./drivers/block/genhd.c
--- ../linux-2.6.11-rc4.orig/drivers/block/genhd.c  2005-02-13 
04:06:23.0 +0100
+++ ./drivers/block/genhd.c 2005-02-17 14:43:26.0 +0100
@@ -453,13 +453,13 @@ static int block_hotplug(struct kset *ks
kfree(path);
 
/* add bus name of physical device */
-   if (dev-bus)
+   if (dev-bus  dev-bus-name)
add_hotplug_env_var(envp, num_envp, i,
buffer, buffer_size, length,
PHYSDEVBUS=%s, dev-bus-name);
 
/* add driver name of physical device */
-   if (dev-driver)
+   if (dev-driver  dev-driver-name)
add_hotplug_env_var(envp, num_envp, i,
buffer, buffer_size, length,
PHYSDEVDRIVER=%s, 
dev-driver-name);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 7/13] Encode and decode arbitrary XDR arrays

2005-02-17 Thread Adrian Bunk
On Tue, Feb 15, 2005 at 02:17:18PM -0500, Trond Myklebust wrote:
 
 net/sunrpc/xdr.c:1024:3: warning: mixing declarations and code
...
 Please don't use these gcc extensions in the kernel.

Just for the record:
This is not a gcc extension - this is C99 but not supported by
gcc 2.95 (which is a supported compiler for kernel 2.6).

 Cheers,
   Trond

cu
Adrian

-- 

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

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


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-17 Thread Kenan Esau
Am Mittwoch, den 16.02.2005, 22:35 +0100 schrieb Vojtech Pavlik:
 On Wed, Feb 16, 2005 at 07:34:52PM +0100, Kenan Esau wrote:
 
+
+/* 
+   Enable absolute output -- ps2_command fails always but if
+   you leave this call out the touchsreen will never send
+   absolute coordinates
+*/ 
+param = 0x07;
+ps2_command(ps2dev, param, PSMOUSE_CMD_SETRES);
   
   Have you checked whether really the touchscreen sends a 0xfe error back,
   or some other value, or timeout? i8042.debug=1 is your friend here.
  
  Yes the answer is 0xfe. 
 
 Would you be so kind to post the 'dmesg' log?

Shure -- here you are...

...
input: LBPS/2 Fujitsu Lifebook TouchScreen on isa0060/serio1
drivers/input/serio/i8042.c: d4 - i8042 (command) [78488524]
drivers/input/serio/i8042.c: f5 - i8042 (parameter) [78488524]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, aux, 12) [78488532]
drivers/input/serio/i8042.c: d4 - i8042 (command) [78488753]
drivers/input/serio/i8042.c: ff - i8042 (parameter) [78488753]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, aux, 12) [78488759]
drivers/input/serio/i8042.c: aa - i8042 (interrupt, aux, 12) [78488822]
drivers/input/serio/i8042.c: 00 - i8042 (interrupt, aux, 12) [78488823]
drivers/input/serio/i8042.c: d4 - i8042 (command) [78489004]
drivers/input/serio/i8042.c: e8 - i8042 (parameter) [78489004]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, aux, 12) [78489009]
drivers/input/serio/i8042.c: d4 - i8042 (command) [78489009]
drivers/input/serio/i8042.c: 07 - i8042 (parameter) [78489009]
drivers/input/serio/i8042.c: fe - i8042 (interrupt, aux, 12) [78489014]
drivers/input/serio/i8042.c: d4 - i8042 (command) [78489014]
drivers/input/serio/i8042.c: f3 - i8042 (parameter) [78489014]
drivers/input/serio/i8042.c: fc - i8042 (interrupt, aux, 12) [78489018]
drivers/input/serio/i8042.c: d4 - i8042 (command) [78489216]
drivers/input/serio/i8042.c: e8 - i8042 (parameter) [78489216]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, aux, 12) [78489218]
drivers/input/serio/i8042.c: d4 - i8042 (command) [78489219]
drivers/input/serio/i8042.c: 03 - i8042 (parameter) [78489219]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, aux, 12) [78489223]
drivers/input/serio/i8042.c: d4 - i8042 (command) [78489223]
drivers/input/serio/i8042.c: f4 - i8042 (parameter) [78489223]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, aux, 12) [78489228]
drivers/input/serio/i8042.c: d4 - i8042 (command) [78489229]
drivers/input/serio/i8042.c: f4 - i8042 (parameter) [78489229]
drivers/input/serio/i8042.c: fa - i8042 (interrupt, aux, 12) [78489233]
drivers/input/serio/i8042.c: 20 - i8042 (interrupt, kbd, 1) [78494505]
drivers/input/serio/i8042.c: a0 - i8042 (interrupt, kbd, 1) [78494603]
drivers/input/serio/i8042.c: 32 - i8042 (interrupt, kbd, 1) [78494680]
...


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] Realtime preempt support for PPC

2005-02-17 Thread Matt Porter
On Thu, Feb 17, 2005 at 05:01:39AM -0800, Frank Rowand wrote:
 Ingo Molnar wrote:
  * Frank Rowand [EMAIL PROTECTED] wrote:
  - could you submit the drivers/net/ibm_emac/ibm_emac_core.c patch
upstream as well?
 
 Yes, I will do that.

This one is already mainline, was posted a week or so ago.

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


E-cards for You

2005-02-17 Thread e-cards
Greetings!

 has sent you an E-Card -- a virtual postcard from
TheArtHaven.com. You can pickup your card at the TheArtHaven.com website.

- If your e-mail is hot-link enabled, click here:
   http://thearthaven.com/cards/[EMAIL PROTECTED]


Your E-Card will be available for 15 days from the sending date.
To keep your E-Card accessible indefinitely, you may want to join
My E-Cards -- an option to do so is provided in your E-Card!




  ^Save trees. Learn about wildlife nature and the environment.
 ^^^  Generate an advertising sponsored donation.
^  Every E-Card sent helps support wildlife and the environment!
  %




Re: 2.6.10: irq 12 nobody cared!

2005-02-17 Thread Zwane Mwaikambo
On Wed, 16 Feb 2005, Joshua Kwan wrote:

CPU0
   0:1073809  XT-PIC  timer
   1:   1291  XT-PIC  i8042
   2:  0  XT-PIC  cascade
   4:  7  XT-PIC  serial
   5:   4366  XT-PIC  eth0
   7: 12  XT-PIC  parport0
   8:  1  XT-PIC  rtc
  10:   7698  XT-PIC  uhci_hcd, uhci_hcd, eth1
  11:  58320  XT-PIC  ide2, ide3
  12: 306731  XT-PIC  wifi0
  14:  24446  XT-PIC  ide0
  15: 13  XT-PIC  ide1
 NMI:  0
 ERR:  0
 
 that IRQ 12 is a wireless device:
 
 :00:09.0 Network controller: Intersil Corporation Prism 2.5 Wavelan
 chipset (rev 01)
 
 that gets handled by HostAP. The device is operating correctly.
 
 What's to blame here?

Check that the hostap interrupt handler is 2.6 aware (IRQ_HANDLED etc)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: rmmod while module is in use

2005-02-17 Thread Zwane Mwaikambo
On Thu, 17 Feb 2005, Davide Rossetti wrote:

 maybe RTFM...
 a module:
 - char device driver for..
 - a PCI device
 
 any clue as to how to protect from module unloading while there is still some
 process opening it??? have I to sleep in the remove_one() pci driver function
 till last process closes its file descriptor???
 
 static void __devexit apedev_remove_one(struct pci_dev *pdev)
 {
ApeDev* apedev = pci_get_drvdata(pdev);
 
if(test_bit(APEDEV_FLAG_OPEN, apedev-flags)) {
PERROR(still open flag on!!! (flags=0x%08x)\n, apedev-flags);
 
// sleep here till it gets closed...
 
}
...
 }
 
 static struct pci_driver apedev_driver = {
.name =  DEVNAME,
.id_table =  apedev_pci_tbl,
.probe=  apedev_init_one,
.remove   =  __devexit_p(apedev_remove_one),
 };

Add .module = THIS_MODULE to your file_operations.

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


Re: AMD 64 and Kernel AGPart support

2005-02-17 Thread Paolo Ornati
On Thu, 17 Feb 2005 15:08:32 +0100
Marc Cramdal [EMAIL PROTECTED] wrote:

 I have an AMD 64 (gentoo compiled for amd64) and I would like to
 succeed in my video driver installation (ATI Radeon 9250 :-/). I would
 need the agpgart support for the Sis Chipset, but all the entry for
 agpgart are grayed, I can't change anything (Kernel 2.6.9, 2.6.10 ...)
 
 So is it normal or a bug ?? , or am I making a mistake.


I have an AMD Athlon64 with Radeon 9200SE on VIA K8T800 Chipset... and
AGP works fine with only CONFIG_AGP_AMD64 enabled.

The fact is that these AMD processors have an on-CPU northbridge for
AGP, and the support for the various external AGP bridges (VIA, SiS,
Nvidia) is provided directly in drivers/char/agp/amd64-agp.c driver
(selected by CONFIG_AGP_AMD64).

Reading drivers/char/agp/amd64-agp.c I can see that SIS 755 chipset
is supported.

If you have a chipset that isn't supported you can always try with the
agp_try_unsupported=1 option (as stated in the HELP of
CONFIG_AGP_AMD64).

 
 NB: one of my friends made the test, without AMD64 and exactly the
 same kernel he can check these options within agpgart...

You don't have to be on a i386 to see the options avaiable for i386...
just do a make menuconfig ARCH=i386 and you are done!

But if you are on x86_64, why do you want to enable drivers for other
architectures?

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


Netfilter: TARPIT Target

2005-02-17 Thread Fao, Sean
I wanted to use the TARPIT target provided by Netfilter, but I am unable 
to find the module in the kernel.  Has it been removed or am I looking 
in the wrong place?

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


[2.6 patch] drivers/net/3c509.c: make 2 structs static

2005-02-17 Thread Adrian Bunk
This patch makes two needlessly global structs static.

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

---

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

--- linux-2.6.11-rc3-mm2-full/drivers/net/3c509.c.old   2005-02-16 
15:12:23.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/3c509.c   2005-02-16 
15:12:44.0 +0100
@@ -214,7 +214,7 @@
 #endif
 
 #ifdef CONFIG_EISA
-struct eisa_device_id el3_eisa_ids[] = {
+static struct eisa_device_id el3_eisa_ids[] = {
{ TCM5092 },
{ TCM5093 },
{  }
@@ -222,7 +222,7 @@
 
 static int el3_eisa_probe (struct device *device);
 
-struct eisa_driver el3_eisa_driver = {
+static struct eisa_driver el3_eisa_driver = {
.id_table = el3_eisa_ids,
.driver   = {
.name= 3c509,

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


Re: Netfilter: TARPIT Target

2005-02-17 Thread Max Kellermann
On 2005/02/17 15:41, Fao, Sean [EMAIL PROTECTED] wrote:
 I wanted to use the TARPIT target provided by Netfilter, but I am unable 
 to find the module in the kernel.  Has it been removed or am I looking 
 in the wrong place?

It is not in the mainstream kernel yet. You can find it in
netfilter patch-o-matic:

 http://ftp.netfilter.org/pub/patch-o-matic-ng/snapshot/

Max

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


Re: rmmod while module is in use

2005-02-17 Thread Zwane Mwaikambo
On Thu, 17 Feb 2005, Zwane Mwaikambo wrote:

 On Thu, 17 Feb 2005, Davide Rossetti wrote:
 
  maybe RTFM...
  a module:
  - char device driver for..
  - a PCI device
  
  any clue as to how to protect from module unloading while there is still 
  some
  process opening it??? have I to sleep in the remove_one() pci driver 
  function
  till last process closes its file descriptor???
  
  static void __devexit apedev_remove_one(struct pci_dev *pdev)
  {
 ApeDev* apedev = pci_get_drvdata(pdev);
  
 if(test_bit(APEDEV_FLAG_OPEN, apedev-flags)) {
 PERROR(still open flag on!!! (flags=0x%08x)\n, apedev-flags);
  
 // sleep here till it gets closed...
  
 }
 ...
  }
  
  static struct pci_driver apedev_driver = {
 .name =  DEVNAME,
 .id_table =  apedev_pci_tbl,
 .probe=  apedev_init_one,
 .remove   =  __devexit_p(apedev_remove_one),
  };
 
 Add .module = THIS_MODULE to your file_operations.
  ^^^

That should be .owner

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


RE: Netfilter: TARPIT Target

2005-02-17 Thread Massimo Cetra
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Fao, Sean
 Sent: Thursday, February 17, 2005 3:42 PM
 To: linux-kernel@vger.kernel.org
 Subject: Netfilter: TARPIT Target
 
 I wanted to use the TARPIT target provided by Netfilter, but 
 I am unable to find the module in the kernel.  Has it been 
 removed or am I looking in the wrong place?

http://www.netfilter.org/patch-o-matic/pom-extra.html#pom-extra-TARPIT

TARPIT is in the extra repository.
Use patch-o-matic to patch both kernel and iptables source.

Regards,
 Max

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


Re: Netfilter: TARPIT Target

2005-02-17 Thread Fao, Sean
Massimo Cetra wrote:
-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Fao, Sean
Sent: Thursday, February 17, 2005 3:42 PM
To: linux-kernel@vger.kernel.org
Subject: Netfilter: TARPIT Target

I wanted to use the TARPIT target provided by Netfilter, but 
I am unable to find the module in the kernel.  Has it been 
removed or am I looking in the wrong place?
   

http://www.netfilter.org/patch-o-matic/pom-extra.html#pom-extra-TARPIT
TARPIT is in the extra repository.
Use patch-o-matic to patch both kernel and iptables source.
 

That would explain it.  Than you much!
--
Sean
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] kill include/linux/eeprom.h

2005-02-17 Thread Adrian Bunk
This patch kills include/linux/eeprom.h .

Rationale:
- it's only used by one single driver
- most of this file are non-inline and non-static functions (sic)

This patch moves all required contents of this file into ns83820.c and 
removes include/linux/eeprom.h (and makes setup_ee_mem_bitbanger 
static).

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

---

 drivers/net/ns83820.c  |   49 +-
 include/linux/eeprom.h |  136 -
 2 files changed, 44 insertions(+), 141 deletions(-)

--- linux-2.6.11-rc3-mm2-full/include/linux/eeprom.h2004-12-24 
22:33:49.0 +0100
+++ /dev/null   2004-11-25 03:16:25.0 +0100
@@ -1,136 +0,0 @@
-/* credit winbond-840.c
- */
-#include asm/io.h
-struct eeprom_ops {
-   void(*set_cs)(void *ee);
-   void(*clear_cs)(void *ee);
-};
-
-#define EEPOL_EEDI 0x01
-#define EEPOL_EEDO 0x02
-#define EEPOL_EECLK0x04
-#define EEPOL_EESEL0x08
-
-struct eeprom {
-   void *dev;
-   struct eeprom_ops *ops;
-
-   void __iomem *  addr;
-
-   unsignedee_addr_bits;
-
-   unsignedeesel;
-   unsignedeeclk;
-   unsignedeedo;
-   unsignedeedi;
-   unsignedpolarity;
-   unsignedee_state;
-
-   spinlock_t  *lock;
-   u32 *cache;
-};
-
-
-u8   eeprom_readb(struct eeprom *ee, unsigned address);
-void eeprom_read(struct eeprom *ee, unsigned address, u8 *bytes,
-   unsigned count);
-void eeprom_writeb(struct eeprom *ee, unsigned address, u8 data);
-void eeprom_write(struct eeprom *ee, unsigned address, u8 *bytes,
-   unsigned count);
-
-/* The EEPROM commands include the alway-set leading bit. */
-enum EEPROM_Cmds {
-EE_WriteCmd=(5  6), EE_ReadCmd=(6  6), EE_EraseCmd=(7  6),
-};
-
-void setup_ee_mem_bitbanger(struct eeprom *ee, void __iomem *memaddr, int 
eesel_bit, int eeclk_bit, int eedo_bit, int eedi_bit, unsigned polarity)
-{
-   ee-addr = memaddr;
-   ee-eesel = 1  eesel_bit;
-   ee-eeclk = 1  eeclk_bit;
-   ee-eedo = 1  eedo_bit;
-   ee-eedi = 1  eedi_bit;
-
-   ee-polarity = polarity;
-
-   *ee-cache = readl(ee-addr);
-}
-
-/* foo. put this in a .c file */
-static inline void eeprom_update(struct eeprom *ee, u32 mask, int pol)
-{
-   unsigned long flags;
-   u32 data;
-
-   spin_lock_irqsave(ee-lock, flags);
-   data = *ee-cache;
-
-   data = ~mask;
-   if (pol)
-   data |= mask;
-
-   *ee-cache = data;
-//printk(update: %08x\n, data);
-   writel(data, ee-addr);
-   spin_unlock_irqrestore(ee-lock, flags);
-}
-
-void eeprom_clk_lo(struct eeprom *ee)
-{
-   int pol = !!(ee-polarity  EEPOL_EECLK);
-
-   eeprom_update(ee, ee-eeclk, pol);
-   udelay(2);
-}
-
-void eeprom_clk_hi(struct eeprom *ee)
-{
-   int pol = !!(ee-polarity  EEPOL_EECLK);
-
-   eeprom_update(ee, ee-eeclk, !pol);
-   udelay(2);
-}
-
-void eeprom_send_addr(struct eeprom *ee, unsigned address)
-{
-   int pol = !!(ee-polarity  EEPOL_EEDI);
-   unsigned i;
-   address |= 6  6;
-
-/* Shift the read command bits out. */
-for (i=0; i11; i++) {
-   eeprom_update(ee, ee-eedi, ((address  10)  1) ^ pol);
-   address = 1;
-   eeprom_clk_hi(ee);
-   eeprom_clk_lo(ee);
-}
-   eeprom_update(ee, ee-eedi, pol);
-}
-
-u16   eeprom_readw(struct eeprom *ee, unsigned address)
-{
-   unsigned i;
-   u16 res = 0;
-
-   eeprom_clk_lo(ee);
-   eeprom_update(ee, ee-eesel, 1 ^ !!(ee-polarity  EEPOL_EESEL));
-   eeprom_send_addr(ee, address);
-
-   for (i=0; i16; i++) {
-   u32 data;
-   eeprom_clk_hi(ee);
-   res = 1;
-   data = readl(ee-addr);
-//printk(eeprom_readw: %08x\n, data);
-   res |= !!(data  ee-eedo) ^ !!(ee-polarity  EEPOL_EEDO);
-   eeprom_clk_lo(ee);
-   }
-   eeprom_update(ee, ee-eesel, 0 ^ !!(ee-polarity  EEPOL_EESEL));
-
-   return res;
-}
-
-
-void eeprom_writeb(struct eeprom *ee, unsigned address, u8 data)
-{
-}
--- linux-2.6.11-rc3-mm2-full/drivers/net/ns83820.c.old 2005-02-16 
17:52:43.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/ns83820.c 2005-02-16 
18:05:26.0 +0100
@@ -107,7 +107,6 @@
 #include linux/init.h
 #include linux/ip.h  /* for iph */
 #include linux/in.h  /* for IPPROTO_... */
-#include linux/eeprom.h
 #include linux/compiler.h
 #include linux/prefetch.h
 #include linux/ethtool.h
@@ -422,6 +421,35 @@
 
 #define DESC_SIZE  8   /* Should be cache line sized */
 
+struct eeprom_ops {
+   void(*set_cs)(void *ee);
+   void(*clear_cs)(void *ee);
+};
+
+#define EEPOL_EEDI 0x01
+#define EEPOL_EEDO 0x02
+#define EEPOL_EECLK0x04
+#define EEPOL_EESEL0x08
+
+struct eeprom {
+   void *dev;
+   struct eeprom_ops *ops;
+
+   

Re: queue_work from interrupt Real time preemption2.6.11-rc2-RT-V0.7.37-03

2005-02-17 Thread Steven Rostedt

On Thu, 17 Feb 2005, Ingo Molnar wrote:
 as long as it stays on a single CPU, could we allow softirq contexts to
 preempt each other? I.e. we'd keep the per-CPU assumption (that is fair
 and needed for performance anyway), but we'd allow NET_TX to preempt
 NET_RX and vice versa. Would this corrupt the rx/tx queues? (i suspect
 it would.)

 (anyway, by adding an explicit no-preempt section around the 'take
 current rx queue private, then process it' on PREEMPT_RT it could be
 made safe. I'm wondering whether there are any other deeper assumptions
 about atomic separation of softirq contexts.)


Ingo,

Wouldn't this cause a longer latency in these sections. I understand
that turning preemption off doesn't stop interrupts that are not
threaded, but especially on a UP, this would cause higher latencies for
high priority processes when a lower priority process is heavy on network
traffic.

As I mentioned earlier, what would it take to be able to group
softirq threads that should not preempt each other, but still keep
preemption available for other threads?

Actually, I guess I need to ask, what do you intend on doing to prioritize
the softirq?  Are you going to make a separate thread for each tasklet?
Once I see what you're doing, I'll make something up to help handle this
problem.

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


[PATCH 2.6.11-rc3-mm2] connector: Add a fork connector

2005-02-17 Thread Guillaume Thouvenin
Hello,

It's a new patch that implements a fork connector in the
kernel/fork.c:do_fork() routine. The connector sends information about
parent PID and child PID over a netlink interface. It allows to several
user space applications to be alerted when a fork occurs in the kernel.
The main drawback is that even if nobody listens, a message is send. I
don't know how to avoid that. I added an option (FORK_CONNECTOR) to
enable the fork connector (or disable) when compiling the kernel. To
work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
has been tested on a 2.6.11-rc3-mm2 kernel with two user space
applications connected. 

It is used by ELSA to manage group of processes in user space. In
conjunction with a per-process accounting information, like BSD or CSA,
ELSA provides a per-group of processes accounting.


Every comments are welcome,

Guillaume

Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
--- 

 drivers/connector/Kconfig |   10 ++
 include/linux/connector.h |2 ++
 kernel/fork.c |   41 +
 3 files changed, 53 insertions(+)

diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/drivers/connector/Kconfig 
linux-2.6.11-rc3-mm2-cnfork/drivers/connector/Kconfig
--- linux-2.6.11-rc3-mm2/drivers/connector/Kconfig  2005-02-11 
11:00:16.0 +0100
+++ linux-2.6.11-rc3-mm2-cnfork/drivers/connector/Kconfig   2005-02-17 
15:48:41.0 +0100
@@ -10,4 +10,14 @@ config CONNECTOR
  Connector support can also be built as a module.  If so, the module
  will be called cn.ko.
 
+config FORK_CONNECTOR
+   bool Enable fork connector
+   depends on CONNECTOR
+   ---help---
+ It adds a connector in kernel/fork.c:do_fork() function. When a fork
+ occurs, netlink is used to transfer information about the parent and 
+ its child. This information can be used by a user space application. 
+ 
+ Note: it only works if connector is built in the kernel.
+ 
 endmenu
diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/include/linux/connector.h 
linux-2.6.11-rc3-mm2-cnfork/include/linux/connector.h
--- linux-2.6.11-rc3-mm2/include/linux/connector.h  2005-02-11 
11:00:18.0 +0100
+++ linux-2.6.11-rc3-mm2-cnfork/include/linux/connector.h   2005-02-16 
15:07:46.0 +0100
@@ -28,6 +28,8 @@
 #define CN_VAL_KOBJECT_UEVENT  0x
 #define CN_IDX_SUPERIO 0xaabb  /* SuperIO subsystem */
 #define CN_VAL_SUPERIO 0xccdd
+#define CN_IDX_FORK0xfeed  /* fork events */
+#define CN_VAL_FORK0xbeef
 
 
 #define CONNECTOR_MAX_MSG_SIZE 1024
diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/kernel/fork.c 
linux-2.6.11-rc3-mm2-cnfork/kernel/fork.c
--- linux-2.6.11-rc3-mm2/kernel/fork.c  2005-02-11 11:00:18.0 +0100
+++ linux-2.6.11-rc3-mm2-cnfork/kernel/fork.c   2005-02-17 13:43:48.0 
+0100
@@ -41,6 +41,7 @@
 #include linux/profile.h
 #include linux/rmap.h
 #include linux/acct.h
+#include linux/connector.h
 
 #include asm/pgtable.h
 #include asm/pgalloc.h
@@ -63,6 +64,44 @@ DEFINE_PER_CPU(unsigned long, process_co
 
 EXPORT_SYMBOL(tasklist_lock);
 
+#if defined(CONFIG_CONNECTOR)  defined(CONFIG_FORK_CONNECTOR)
+#define FORK_CN_INFO_SIZE  64 
+static inline void fork_connector(pid_t parent, pid_t child)
+{
+   struct cb_id fork_id = {CN_IDX_FORK, CN_VAL_FORK};
+   static __u32 seq; /* used to test if we lost message */
+   
+   if (cn_already_initialized) {
+   struct cn_msg *msg;
+   size_t size;
+
+   size = sizeof(*msg) + FORK_CN_INFO_SIZE;
+   msg = kmalloc(size, GFP_KERNEL);
+   if (msg) {
+   memset(msg, '\0', size);
+   memcpy(msg-id, fork_id, sizeof(msg-id));
+   msg-seq = seq++;
+   msg-ack = 0; /* not used */
+   /* 
+* size of data is the number of characters 
+* printed plus one for the trailing '\0'
+*/
+   msg-len = snprintf(msg-data, FORK_CN_INFO_SIZE-1, 
+   %i %i, parent, child) + 1;
+
+   cn_netlink_send(msg, 1);
+
+   kfree(msg);
+   }
+   }
+}
+#else
+static inline void fork_connector(pid_t parent, pid_t child) 
+{
+   return; 
+}
+#endif
+
 int nr_processes(void)
 {
int cpu;
@@ -1238,6 +1277,8 @@ long do_fork(unsigned long clone_flags,
if (unlikely (current-ptrace  PT_TRACE_VFORK_DONE))
ptrace_notify ((PTRACE_EVENT_VFORK_DONE  8) | 
SIGTRAP);
}
+
+   fork_connector(current-pid, p-pid);
} else {
free_pidmap(pid);
pid = PTR_ERR(p);


-
To unsubscribe from 

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

2005-02-17 Thread Adrian Bunk
This patch makes a needlessly global struct static.

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

--- linux-2.6.11-rc3-mm2-full/drivers/net/3c527.c.old   2005-02-16 
15:13:19.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/3c527.c   2005-02-16 
15:13:29.0 +0100
@@ -197,7 +197,7 @@
char*name;
 };
 
-const struct mca_adapters_t mc32_adapters[] = {
+static const struct mca_adapters_t mc32_adapters[] = {
{ 0x0041, 3COM EtherLink MC/32 },
{ 0x8EF5, IBM High Performance Lan Adapter },
{ 0x, NULL }

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


[2.6 patch] drivers/net/amd8111e.c: make 2 functions static

2005-02-17 Thread Adrian Bunk
This patch makes two needlessly global functions static.

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

---

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

--- linux-2.6.11-rc3-mm2-full/drivers/net/amd8111e.c.old2005-02-16 
15:14:01.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/amd8111e.c2005-02-16 
15:14:29.0 +0100
@@ -1487,7 +1487,7 @@
 amd8111e crc generator implementation is different from the kernel
 ether_crc() function.
 */
-int amd8111e_ether_crc(int len, char* mac_addr)
+static int amd8111e_ether_crc(int len, char* mac_addr)
 {
int i,byte;
unsigned char octet;
@@ -1715,7 +1715,7 @@
 /* 
 This function changes the mtu of the device. It restarts the device  to 
initialize the descriptor with new receive buffers.
 */  
-int amd8111e_change_mtu(struct net_device *dev, int new_mtu)
+static int amd8111e_change_mtu(struct net_device *dev, int new_mtu)
 {
struct amd8111e_priv *lp = netdev_priv(dev);
int err;

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


Re: [rfc/rft] Fujitsu B-Series Lifebook PS/2 TouchScreen driver

2005-02-17 Thread Vojtech Pavlik
On Thu, Feb 17, 2005 at 03:19:53PM +0100, Kenan Esau wrote:

  Would you be so kind to post the 'dmesg' log?
 
 Shure -- here you are...
 
 ...
 input: LBPS/2 Fujitsu Lifebook TouchScreen on isa0060/serio1
 drivers/input/serio/i8042.c: d4 - i8042 (command) [78488524]
 drivers/input/serio/i8042.c: f5 - i8042 (parameter) [78488524]
 drivers/input/serio/i8042.c: fa - i8042 (interrupt, aux, 12) [78488532]
 drivers/input/serio/i8042.c: d4 - i8042 (command) [78488753]
 drivers/input/serio/i8042.c: ff - i8042 (parameter) [78488753]
 drivers/input/serio/i8042.c: fa - i8042 (interrupt, aux, 12) [78488759]
 drivers/input/serio/i8042.c: aa - i8042 (interrupt, aux, 12) [78488822]
 drivers/input/serio/i8042.c: 00 - i8042 (interrupt, aux, 12) [78488823]
 drivers/input/serio/i8042.c: d4 - i8042 (command) [78489004]
 drivers/input/serio/i8042.c: e8 - i8042 (parameter) [78489004]
 drivers/input/serio/i8042.c: fa - i8042 (interrupt, aux, 12) [78489009]
 drivers/input/serio/i8042.c: d4 - i8042 (command) [78489009]
 drivers/input/serio/i8042.c: 07 - i8042 (parameter) [78489009]
 drivers/input/serio/i8042.c: fe - i8042 (interrupt, aux, 12) [78489014]

Ok, this is a regular 'I don't know what you mean' response from the
pad.

 drivers/input/serio/i8042.c: d4 - i8042 (command) [78489014]
 drivers/input/serio/i8042.c: f3 - i8042 (parameter) [78489014]
 drivers/input/serio/i8042.c: fc - i8042 (interrupt, aux, 12) [78489018]

But this return code is _very_ unusual. 0xfc means 'basic assurance test
failure' and should be reported only as a response to the 0xff command.

 drivers/input/serio/i8042.c: d4 - i8042 (command) [78489216]
 drivers/input/serio/i8042.c: e8 - i8042 (parameter) [78489216]
 drivers/input/serio/i8042.c: fa - i8042 (interrupt, aux, 12) [78489218]
 drivers/input/serio/i8042.c: d4 - i8042 (command) [78489219]
 drivers/input/serio/i8042.c: 03 - i8042 (parameter) [78489219]
 drivers/input/serio/i8042.c: fa - i8042 (interrupt, aux, 12) [78489223]
 drivers/input/serio/i8042.c: d4 - i8042 (command) [78489223]
 drivers/input/serio/i8042.c: f4 - i8042 (parameter) [78489223]
 drivers/input/serio/i8042.c: fa - i8042 (interrupt, aux, 12) [78489228]
 drivers/input/serio/i8042.c: d4 - i8042 (command) [78489229]
 drivers/input/serio/i8042.c: f4 - i8042 (parameter) [78489229]
 drivers/input/serio/i8042.c: fa - i8042 (interrupt, aux, 12) [78489233]

Nothing else important here.

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


Re: Customized 2.6.10 kernel on a Compact Flash

2005-02-17 Thread Paulo Marques
govind raj wrote:
Thanks for all the pointers.
We had taken the /sbin/init from the existing Linux installation from 
where we had created the customized image. 
Usually distro binaries are dynamically linked (as they should be) so 
you also need to provide the libraries they request.

As a first cut, use bash as your init (so that you have a prompt to test 
stuff). Do a ldd bash to check the libraries necessary for this to 
work and create a /lib dir on your target system with those. Then copy 
the bash binary to /sbin/init.

I hope this helps,
--
Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [BK] upgrade will be needed

2005-02-17 Thread Theodore Ts'o
On Thu, Feb 17, 2005 at 10:46:41AM +0100, Geert Uytterhoeven wrote:
 I don't know whether the kernel hackers that work for IBM use the `free'
 version of BK or not, but if they do, s/OSDL/IBM/ and s/arch/ClearCase/ and
 there's a problem...

No, there's not a problem.

- Ted
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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: AMD 64 and Kernel AGPart support

2005-02-17 Thread Paolo Ornati
On Thu, 17 Feb 2005 15:42:50 +0100
[EMAIL PROTECTED] wrote:

 ÄúºÃ£º
 ÎÒÒÑ_­ÊÕµ_ÄúµÄÀ_ÐÅ

and... what does this means?

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


Re: queue_work from interrupt Real time preemption2.6.11-rc2-RT-V0.7.37-03

2005-02-17 Thread Steven Rostedt

Damn! I'm doing this from out of town and my pine setup had a reply to to
another email account, and I didn't read this before I sent my previous
response (so Please ignore it!)

On Thu, 17 Feb 2005, Ingo Molnar wrote:
 * Steven Rostedt [EMAIL PROTECTED] wrote:

   See net/core/dev.c:softnet_data
 
  How about a design to put softirq's into domains. [...]

 just to make sure that the context of this discussion is not lost to
 David and other readers of lkml. We are not redesigning softirqs in any
 way, shape or form for the normal kernel - there they remain what they
 are.

 This discussion is about seemless (automatic) extensions/modifications
 to the softirq concept on PREEMPT_RT, for latency reduction purposes.
 PREEMPT_SOFTIRQS is already such an extension.


I'm only working on your PREEMPT_RT extension, so I wasn't thinking about
the mainline kernel.

But I'll ask again from this context. What is the plan for softirqs on the
PREEMPT_RT kernel? Are you going to thread them? Otherwise, what other way
can you preempt different softirqs?

I understand that the design of softirqs will not change for the mainline
kernel, but what changes are going to be made wrt PREEMPT_RT? If they are
going to be threaded, then grouping them would not be too much of a
problem with simple #ifdefs around the code and keep the mainline
untouched.

I may be just confused, so please enlighten me :-)

Thanks,

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


[2.6 patch] drivers/net/appletalk/: make firmware static

2005-02-17 Thread Adrian Bunk
This patch makes some needlessly global firmware static.

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

---

 drivers/net/appletalk/cops_ffdrv.h |2 +-
 drivers/net/appletalk/cops_ltdrv.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- linux-2.6.11-rc3-mm2-full/drivers/net/appletalk/cops_ffdrv.h.old
2005-02-16 15:15:32.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/appletalk/cops_ffdrv.h
2005-02-16 15:15:41.0 +0100
@@ -28,7 +28,7 @@
 
 #ifdef CONFIG_COPS_DAYNA
 
-unsigned char ffdrv_code[] = {
+static unsigned char ffdrv_code[] = {
58,3,0,50,228,149,33,255,255,34,226,149,
249,17,40,152,33,202,154,183,237,82,77,68,
11,107,98,19,54,0,237,176,175,50,80,0,
--- linux-2.6.11-rc3-mm2-full/drivers/net/appletalk/cops_ltdrv.h.old
2005-02-16 15:15:50.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/appletalk/cops_ltdrv.h
2005-02-16 15:15:58.0 +0100
@@ -27,7 +27,7 @@
 
 #ifdef CONFIG_COPS_TANGENT
 
-unsigned char ltdrv_code[] = {
+static unsigned char ltdrv_code[] = {
58,3,0,50,148,10,33,143,15,62,85,119,
190,32,9,62,170,119,190,32,3,35,24,241,
34,146,10,249,17,150,10,33,143,15,183,237,

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


[2.6 patch] drivers/net/arcnet/: possible cleanups

2005-02-17 Thread Adrian Bunk
This patch contains the following possible cleanups:
- make needlessly global code static
- arcnet.c: kill the outdated VERSION
- arcnet.c: remove the unneeded EXPORT_SYMBOL(arc_proto_null)
- arcnet.c: remove the unneeded EXPORT_SYMBOL(arcnet_dump_packet)

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

---

 drivers/net/arcnet/arc-rawmode.c |2 +-
 drivers/net/arcnet/arcnet.c  |   19 +--
 drivers/net/arcnet/rfc1051.c |2 +-
 drivers/net/arcnet/rfc1201.c |2 +-
 include/linux/arcdevice.h|9 -
 5 files changed, 12 insertions(+), 22 deletions(-)

--- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arc-rawmode.c.old  
2005-02-16 15:16:38.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arc-rawmode.c  2005-02-16 
15:16:51.0 +0100
@@ -42,7 +42,7 @@
 static int prepare_tx(struct net_device *dev, struct archdr *pkt, int length,
  int bufnum);
 
-struct ArcProto rawmode_proto =
+static struct ArcProto rawmode_proto =
 {
.suffix = 'r',
.mtu= XMTU,
--- linux-2.6.11-rc3-mm2-full/include/linux/arcdevice.h.old 2005-02-16 
15:17:26.0 +0100
+++ linux-2.6.11-rc3-mm2-full/include/linux/arcdevice.h 2005-02-16 
15:20:57.0 +0100
@@ -206,7 +206,6 @@
 
 extern struct ArcProto *arc_proto_map[256], *arc_proto_default,
*arc_bcast_proto, *arc_raw_proto;
-extern struct ArcProto arc_proto_null;
 
 
 /*
@@ -334,17 +333,9 @@
 #define arcnet_dump_skb(dev,skb,desc) ;
 #endif
 
-#if (ARCNET_DEBUG_MAX  D_RX) || (ARCNET_DEBUG_MAX  D_TX)
-void arcnet_dump_packet(struct net_device *dev, int bufnum, char *desc,
-   int take_arcnet_lock);
-#else
-#define arcnet_dump_packet(dev, bufnum, desc,take_arcnet_lock) ;
-#endif
-
 void arcnet_unregister_proto(struct ArcProto *proto);
 irqreturn_t arcnet_interrupt(int irq, void *dev_id, struct pt_regs *regs);
 struct net_device *alloc_arcdev(char *name);
-void arcnet_rx(struct net_device *dev, int bufnum);
 
 #endif /* __KERNEL__ */
 #endif /* _LINUX_ARCDEVICE_H */
--- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arcnet.c.old   2005-02-16 
15:17:47.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/arcnet.c   2005-02-16 
15:21:20.0 +0100
@@ -41,8 +41,6 @@
  * [EMAIL PROTECTED]
  */
 
-#define VERSION arcnet: v3.93 BETA 2000/04/29 - by Avery Pennarun et al.\n
-
 #include linux/module.h
 #include linux/config.h
 #include linux/types.h
@@ -61,6 +59,7 @@
 static int null_prepare_tx(struct net_device *dev, struct archdr *pkt,
   int length, int bufnum);
 
+static void arcnet_rx(struct net_device *dev, int bufnum);
 
 /*
  * one ArcProto per possible proto ID.  None of the elements of
@@ -71,7 +70,7 @@
  struct ArcProto *arc_proto_map[256], *arc_proto_default,
*arc_bcast_proto, *arc_raw_proto;
 
-struct ArcProto arc_proto_null =
+static struct ArcProto arc_proto_null =
 {
.suffix = '?',
.mtu= XMTU,
@@ -90,7 +89,6 @@
 EXPORT_SYMBOL(arc_proto_default);
 EXPORT_SYMBOL(arc_bcast_proto);
 EXPORT_SYMBOL(arc_raw_proto);
-EXPORT_SYMBOL(arc_proto_null);
 EXPORT_SYMBOL(arcnet_unregister_proto);
 EXPORT_SYMBOL(arcnet_debug);
 EXPORT_SYMBOL(alloc_arcdev);
@@ -118,8 +116,6 @@
 
arcnet_debug = debug;
 
-   printk(VERSION);
-
 #ifdef ALPHA_WARNING
BUGLVL(D_EXTRA) {
printk(arcnet: ***\n
@@ -178,8 +174,8 @@
  * Dump the contents of an ARCnet buffer
  */
 #if (ARCNET_DEBUG_MAX  (D_RX | D_TX))
-void arcnet_dump_packet(struct net_device *dev, int bufnum, char *desc,
-   int take_arcnet_lock)
+static void arcnet_dump_packet(struct net_device *dev, int bufnum,
+  char *desc, int take_arcnet_lock)
 {
struct arcnet_local *lp = dev-priv;
int i, length;
@@ -208,7 +204,10 @@
 
 }
 
-EXPORT_SYMBOL(arcnet_dump_packet);
+#else
+
+#define arcnet_dump_packet(dev, bufnum, desc,take_arcnet_lock) do { } while (0)
+
 #endif
 
 
@@ -987,7 +986,7 @@
  * This is a generic packet receiver that calls arcnet??_rx depending on the
  * protocol ID found.
  */
-void arcnet_rx(struct net_device *dev, int bufnum)
+static void arcnet_rx(struct net_device *dev, int bufnum)
 {
struct arcnet_local *lp = dev-priv;
struct archdr pkt;
--- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1051.c.old  2005-02-16 
15:22:16.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1051.c  2005-02-16 
15:22:23.0 +0100
@@ -43,7 +43,7 @@
  int bufnum);
 
 
-struct ArcProto rfc1051_proto =
+static struct ArcProto rfc1051_proto =
 {
.suffix = 's',
.mtu= XMTU - RFC1051_HDR_SIZE,
--- linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1201.c.old  2005-02-16 
15:22:35.0 +0100
+++ linux-2.6.11-rc3-mm2-full/drivers/net/arcnet/rfc1201.c  2005-02-16 

Re: [rfc] keytables - the new keycode-keysym mapping

2005-02-17 Thread Jirka Bohac
On Wed, Feb 16, 2005 at 10:49:58PM +0100, Andries Brouwer wrote:
 On Wed, Feb 16, 2005 at 07:20:35PM +0100, Jirka Bohac wrote:

 For the time being I look only at the diacr for unicode part.
 The fragment below looks like a strange kludge.
 
  -   if (diacr)
  -   value = handle_diacr(vc, value);
  +   if (diacr) {
  +   v = handle_diacr(vc, value);
  +
  +   if (kbd-kbdmode == VC_UNICODE) {
  +   to_utf8(vc, v  0x);
  +   return;
  +   }
  +
  +   /* 
  +* this makes at least latin-1 compose chars work 
  +* even when using unicode keymap in non-unicode mode
  +*/
  +   value = v  0xFF; 
  +   }
   
  if (dead_key_next) {
  dead_key_next = 0;
  @@ -637,7 +652,7 @@
   {
  if (up_flag)
  return;
  -   diacr = (diacr ? handle_diacr(vc, value) : value);
  +   diacr = (diacr ? handle_diacr(vc, value)  0xff : value);

I can't see your point ... you mean there is a problem that when 
kbd-kbdmode == VC_UNICODE, then control will not reach the 
if (dead_key_next)?

I don't think this is a problem. You have type a really strange sequence
of keypresses -- sth like: a dead keyCompose a letter in Unicode
mode ... then the behaviour would slightly differ from today's one. 
If you think this is worth fixing, I can do it.

 I see twice  0xff but why?

Ok, it's not needed, because it would have been done automatically, as 
diacr and value are both unsigned chars. But at least we can clearly see
what's happening.

 The original code was good, so the only change should be to transport
 more than 8 bits.

You only want to transport more bits when handling a dead key. If the
put_queue at the end of the function was simply replaced by to_utf8, you
would modify the behaviour of normal KT_LATIN keys with value  127;
Somebody may be rely on the current meaning.

regards,

-- 
Jirka Bohac [EMAIL PROTECTED]
SUSE Labs, SUSE CR

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


Re: ________________: Re: AMD 64 and Kernel AGPart support

2005-02-17 Thread Parag Warudkar
On Thursday 17 February 2005 10:10 am, Paolo Ornati wrote:
  ÄúºÃ£º
      ÎÒÒÑ_­ÊÕµ_ÄúµÄÀ_ÐÅ

 and... what does this means?
SPAM. This looks to me like a new way of spamming though, replying to valid 
mailing list messages. (I too received couple of these in reply to my 
messages.)

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


Re: Netfilter: TARPIT Target

2005-02-17 Thread Fao, Sean
Where are those nonsense (base64) messages from [EMAIL PROTECTED] coming 
from after I post?

--
Sean E. Fao
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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: AMD 64 and Kernel AGPart support

2005-02-17 Thread Paolo Ornati
On Thu, 17 Feb 2005 10:26:55 -0500
Parag Warudkar [EMAIL PROTECTED] wrote:

 SPAM. This looks to me like a new way of spamming though, replying to
 valid mailing list messages. (I too received couple of these in reply
 to my messages.)

agrrr.. and I've done a mistake replying!

-- 
Paolo Ornati
Gentoo Linux (kernel 2.6.10-gentoo-r7)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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.9 IO-APIC + timer doesn't work! with VMWare 4

2005-02-17 Thread Zwane Mwaikambo
On Tue, 15 Feb 2005, Joseph Cosby wrote:

 Hi,
  Using VMWare 4 with a 2.6.9 kernel I get IO-APIC + timer doesn't work! As
 suggested, the noapic option fixes the problem. This resulted after adding
 APIC support to my kernel. My problem is, I need APIC support to boot on a
 separate, non-VMWare machine, and I need to keep the kernel and boot params
 the same on both machines.
  Aside from disabling APIC support, and running with the noapic parameter, can
 anybody suggest how to get this running on the VMware machine?

It works here with 2.6.11-rc3-mm2 and 4.5.2 build 8848

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


[PATCH 1/2] folded page table walkers

2005-02-17 Thread Nick Piggin
(Note these are all obviously just RFCs, until after 2.6.11,
at which time I'll send them off to Andrew if they've proven
OK).
Anyway, here is the patch to fold the page table walkers
nicely for 2 and 3 level implementations... now we are getting
some good reasons why people should convert to the -nop?d.h
headers :)
We cut 35% off lmbench fork time with 2 level UP i386. This
patch gets most of the improvement.
   plain  +ptwalk +folded +funit-at-a-time for mm/
mm/memory.o text size  10935  1067997999519
lmb fork 335327 223 218
lmb exec1417   144512281198
lmb shell   5483   550751955087



---

 linux-2.6-npiggin/include/asm-generic/pgtable-nopmd.h |9 +
 linux-2.6-npiggin/include/asm-generic/pgtable-nopud.h |8 
 linux-2.6-npiggin/include/asm-generic/pgtable.h   |4 
 3 files changed, 21 insertions(+)

diff -puN include/asm-generic/pgtable.h~vm-folded-walkers 
include/asm-generic/pgtable.h
--- linux-2.6/include/asm-generic/pgtable.h~vm-folded-walkers   2005-02-18 
01:54:50.0 +1100
+++ linux-2.6-npiggin/include/asm-generic/pgtable.h 2005-02-18 
01:54:50.0 +1100
@@ -175,6 +175,7 @@ static inline void ptep_mkdirty(pte_t *p
  *
  * see for_each_pgd
  */
+#ifndef for_each_pud
 #define for_each_pud(pgd, start, end, pud, pud_start, pud_end) \
for (   pud = pud_offset(pgd, start),   \
  pud_start = start;\
@@ -183,12 +184,14 @@ static inline void ptep_mkdirty(pte_t *p
  pud = pud_offset(pgd, end-1);\
pud_start = pud_end,\
  pud++ )
+#endif
 
 /*
  * for_each_pmd - iterate through pmd entries in a given pud
  *
  * see for_each_pgd
  */
+#ifndef for_each_pmd
 #define for_each_pmd(pud, start, end, pmd, pmd_start, pmd_end) \
for (   pmd = pmd_offset(pud, start),   \
  pmd_start = start;\
@@ -197,6 +200,7 @@ static inline void ptep_mkdirty(pte_t *p
  pmd = pmd_offset(pud, end-1);\
pmd_start = pmd_end,\
  pmd++ )
+#endif
 
 /*
  * for_each_pte_map - iterate through pte entries in a given pmd
diff -puN include/asm-generic/pgtable-nopud.h~vm-folded-walkers 
include/asm-generic/pgtable-nopud.h
--- linux-2.6/include/asm-generic/pgtable-nopud.h~vm-folded-walkers 
2005-02-18 01:54:50.0 +1100
+++ linux-2.6-npiggin/include/asm-generic/pgtable-nopud.h   2005-02-18 
02:22:43.0 +1100
@@ -52,5 +52,13 @@ static inline pud_t * pud_offset(pgd_t *
 #define pud_free(x)do { } while (0)
 #define __pud_free_tlb(tlb, x) do { } while (0)
 
+#undef for_each_pud
+#define for_each_pud(pgd, start, end, pud, pud_start, pud_end) \
+   for (   pud = (pud_t *)pgd, \
+ pud_start = start,\
+ pud_end = end;\
+   pud_start == start; \
+   pud_start++ )
+
 #endif /* __ASSEMBLY__ */
 #endif /* _PGTABLE_NOPUD_H */
diff -puN include/asm-generic/pgtable-nopmd.h~vm-folded-walkers 
include/asm-generic/pgtable-nopmd.h
--- linux-2.6/include/asm-generic/pgtable-nopmd.h~vm-folded-walkers 
2005-02-18 01:54:50.0 +1100
+++ linux-2.6-npiggin/include/asm-generic/pgtable-nopmd.h   2005-02-18 
02:22:43.0 +1100
@@ -55,6 +55,15 @@ static inline pmd_t * pmd_offset(pud_t *
 #define pmd_free(x)do { } while (0)
 #define __pmd_free_tlb(tlb, x) do { } while (0)
 
+#undef for_each_pmd
+#define for_each_pmd(pud, start, end, pmd, pmd_start, pmd_end) \
+   for (   pmd = (pmd_t *)pud, \
+ pmd_start = start,\
+ pmd_end = end;\
+   pmd_start == start; \
+   pmd_start++ )
+
+
 #endif /* __ASSEMBLY__ */
 
 #endif /* _PGTABLE_NOPMD_H */

_


[PATCH 2/2] trim unused functions

2005-02-17 Thread Nick Piggin
And lastly, redo this vital optimisation that David
had to remove earlier. Saves a few bytes.



---

 linux-2.6-npiggin/include/asm-generic/pgtable-nopmd.h |2 ++
 linux-2.6-npiggin/include/asm-generic/pgtable-nopud.h |2 ++
 linux-2.6-npiggin/mm/memory.c |8 +++-
 3 files changed, 11 insertions(+), 1 deletion(-)

diff -puN include/asm-generic/pgtable-nopud.h~vm-trim-unused 
include/asm-generic/pgtable-nopud.h
--- linux-2.6/include/asm-generic/pgtable-nopud.h~vm-trim-unused
2005-02-18 02:14:30.0 +1100
+++ linux-2.6-npiggin/include/asm-generic/pgtable-nopud.h   2005-02-18 
02:15:41.0 +1100
@@ -3,6 +3,8 @@
 
 #ifndef __ASSEMBLY__
 
+#define __PAGETABLE_PUD_FOLDED
+
 /*
  * Having the pud type consist of a pgd gets the size right, and allows
  * us to conceptually access the pgd entry that this pud is folded into
diff -puN include/asm-generic/pgtable-nopmd.h~vm-trim-unused 
include/asm-generic/pgtable-nopmd.h
--- linux-2.6/include/asm-generic/pgtable-nopmd.h~vm-trim-unused
2005-02-18 02:14:32.0 +1100
+++ linux-2.6-npiggin/include/asm-generic/pgtable-nopmd.h   2005-02-18 
02:15:31.0 +1100
@@ -5,6 +5,8 @@
 
 #include asm-generic/pgtable-nopud.h
 
+#define __PAGETABLE_PMD_FOLDED
+
 /*
  * Having the pmd type consist of a pud gets the size right, and allows
  * us to conceptually access the pud entry that this pmd is folded into
diff -puN mm/memory.c~vm-trim-unused mm/memory.c
--- linux-2.6/mm/memory.c~vm-trim-unused2005-02-18 02:14:44.0 
+1100
+++ linux-2.6-npiggin/mm/memory.c   2005-02-18 02:17:34.0 +1100
@@ -2006,6 +2006,8 @@ int handle_mm_fault(struct mm_struct *mm
 }
 
 #ifndef __ARCH_HAS_4LEVEL_HACK
+
+#ifndef __PAGETABLE_PUD_FOLDED
 /*
  * Allocate page upper directory.
  *
@@ -2037,7 +2039,9 @@ pud_t fastcall *__pud_alloc(struct mm_st
  out:
return pud_offset(pgd, address);
 }
+#endif /* __PAGETABLE_PUD_FOLDED */
 
+#ifndef __PAGETABLE_PMD_FOLDED
 /*
  * Allocate page middle directory.
  *
@@ -2069,7 +2073,9 @@ pmd_t fastcall *__pmd_alloc(struct mm_st
  out:
return pmd_offset(pud, address);
 }
-#else
+#endif /* __PAGETABLE_PMD_FOLDED */
+
+#else /* __ARCH_HAS_4LEVEL_HACK */
 pmd_t fastcall *__pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long 
address)
 {
pmd_t *new;

_


Re: Pty is losing bytes

2005-02-17 Thread Linus Torvalds


On Wed, 16 Feb 2005, Theodore Ts'o wrote:
 
 Yes, but then when the buffer is full, and we return the we'll take
 anything return value, the code that was getting confused with the
 incorrect receive_room value will still be getting confused

But that's fine - at that point we're literally _supposed_ to drop 
characters: we have to, in order to see the EOLN.

But we're only supposed to drop characters IFF:
 - the buffer is full
 - we are in canon mode
 - we _still_ haven't seen a single EOLN in the whole buffer

If any of these three isn't true, we're not supposed to drop anything.

That's my argument.

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: [PATCH 2.6.11-rc3-mm2] connector: Add a fork connector

2005-02-17 Thread Evgeniy Polyakov
On Thu, 2005-02-17 at 15:55 +0100, Guillaume Thouvenin wrote:
 Hello,

Hello, I have small note about connector's usage in your module
in particular and others in general.

 It's a new patch that implements a fork connector in the
 kernel/fork.c:do_fork() routine. The connector sends information about
 parent PID and child PID over a netlink interface. It allows to several
 user space applications to be alerted when a fork occurs in the kernel.
 The main drawback is that even if nobody listens, a message is send. I
 don't know how to avoid that. I added an option (FORK_CONNECTOR) to
 enable the fork connector (or disable) when compiling the kernel. To
 work, connector must be compiled as built-in (CONFIG_CONNECTOR=y). It
 has been tested on a 2.6.11-rc3-mm2 kernel with two user space
 applications connected. 
 
 It is used by ELSA to manage group of processes in user space. In
 conjunction with a per-process accounting information, like BSD or CSA,
 ELSA provides a per-group of processes accounting.

I think people will complain here...
From rom one point of view it is step to the chaotic microkernel message
flows, 
from the other side why only fork is monitored in this way?
I still think that lsm with all calls logging is the best way to
achieve 
this goal.

 Every comments are welcome,
 
 Guillaume
 
 Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
 --- 
 
  drivers/connector/Kconfig |   10 ++
  include/linux/connector.h |2 ++
  kernel/fork.c |   41 +
  3 files changed, 53 insertions(+)
 
 diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/drivers/connector/Kconfig 
 linux-2.6.11-rc3-mm2-cnfork/drivers/connector/Kconfig
 --- linux-2.6.11-rc3-mm2/drivers/connector/Kconfig2005-02-11 
 11:00:16.0 +0100
 +++ linux-2.6.11-rc3-mm2-cnfork/drivers/connector/Kconfig 2005-02-17 
 15:48:41.0 +0100
 @@ -10,4 +10,14 @@ config CONNECTOR
 Connector support can also be built as a module.  If so, the module
 will be called cn.ko.
  
 +config FORK_CONNECTOR
 + bool Enable fork connector
 + depends on CONNECTOR
 + ---help---
 +   It adds a connector in kernel/fork.c:do_fork() function. When a fork
 +   occurs, netlink is used to transfer information about the parent and 
 +   its child. This information can be used by a user space application. 
 +   
 +   Note: it only works if connector is built in the kernel.
 +   
  endmenu
 diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/include/linux/connector.h 
 linux-2.6.11-rc3-mm2-cnfork/include/linux/connector.h
 --- linux-2.6.11-rc3-mm2/include/linux/connector.h2005-02-11 
 11:00:18.0 +0100
 +++ linux-2.6.11-rc3-mm2-cnfork/include/linux/connector.h 2005-02-16 
 15:07:46.0 +0100
 @@ -28,6 +28,8 @@
  #define CN_VAL_KOBJECT_UEVENT0x
  #define CN_IDX_SUPERIO   0xaabb  /* SuperIO subsystem */
  #define CN_VAL_SUPERIO   0xccdd
 +#define CN_IDX_FORK  0xfeed  /* fork events */
 +#define CN_VAL_FORK  0xbeef
  
 
  #define CONNECTOR_MAX_MSG_SIZE   1024
 diff -uprN -X dontdiff linux-2.6.11-rc3-mm2/kernel/fork.c 
 linux-2.6.11-rc3-mm2-cnfork/kernel/fork.c
 --- linux-2.6.11-rc3-mm2/kernel/fork.c2005-02-11 11:00:18.0 
 +0100
 +++ linux-2.6.11-rc3-mm2-cnfork/kernel/fork.c 2005-02-17 13:43:48.0 
 +0100
 @@ -41,6 +41,7 @@
  #include linux/profile.h
  #include linux/rmap.h
  #include linux/acct.h
 +#include linux/connector.h
  
  #include asm/pgtable.h
  #include asm/pgalloc.h
 @@ -63,6 +64,44 @@ DEFINE_PER_CPU(unsigned long, process_co
  
  EXPORT_SYMBOL(tasklist_lock);
  
 +#if defined(CONFIG_CONNECTOR)  defined(CONFIG_FORK_CONNECTOR)

I suspect CONFIG_FORK_CONNECTOR is enough.

 +#define FORK_CN_INFO_SIZE64 
 +static inline void fork_connector(pid_t parent, pid_t child)
 +{
 + struct cb_id fork_id = {CN_IDX_FORK, CN_VAL_FORK};
 + static __u32 seq; /* used to test if we lost message */
 + 
 + if (cn_already_initialized) {
 + struct cn_msg *msg;
 + size_t size;
 +
 + size = sizeof(*msg) + FORK_CN_INFO_SIZE;
 + msg = kmalloc(size, GFP_KERNEL);
 + if (msg) {
 + memset(msg, '\0', size);
 + memcpy(msg-id, fork_id, sizeof(msg-id));
 + msg-seq = seq++;
 + msg-ack = 0; /* not used */
 + /* 
 +  * size of data is the number of characters 
 +  * printed plus one for the trailing '\0'
 +  */
 + msg-len = snprintf(msg-data, FORK_CN_INFO_SIZE-1, 
 + %i %i, parent, child) + 1;
 +
 + cn_netlink_send(msg, 1);

1 here means that this message will be delivered to any group
which has it's first bit set(1, 3, and 

Re: Oops in 2.6.10-ac12 in kjournald (journal_commit_transaction)

2005-02-17 Thread Randy.Dunlap
Ralf Hildebrandt wrote:
* Ralf Hildebrandt [EMAIL PROTECTED]:

The best way to do that is to ensure that the kernel was built with
CONFIG_DEBUG_INFO, note the offending EIP value, then do
# gdb vmlinux
(gdb) l *0xc0whatever
I'm rebuilding the ac12 kernel which crashed on me after just one day
and will reboot it today.

Is it normal that the kernel with debugging enabled is not larger than
the normal kernel?
-
No, it should be much larger.  Recheck the .config file
for CONFIG_DEBUG_INFO=y.  Maybe you need to do 'make clean'
first.
--
~Randy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 2/2] page table iterators

2005-02-17 Thread Linus Torvalds


On Fri, 18 Feb 2005, Nick Piggin wrote:

 I am pretty surprised myself that I was able to consolidate
 all page table range functions into a single type of iterator
 (well, there are a couple of variations, but it's not too bad).

Ok, this is post-2.6.11 material, so please remind me.

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: Oops in 2.6.10-ac12 in kjournald (journal_commit_transaction)

2005-02-17 Thread Ralf Hildebrandt
* Randy.Dunlap [EMAIL PROTECTED]:

 Is it normal that the kernel with debugging enabled is not larger than
 the normal kernel?
 -
 
 No, it should be much larger.  Recheck the .config file
 for CONFIG_DEBUG_INFO=y.  Maybe you need to do 'make clean'
 first.

CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_INFO=y
# CONFIG_FRAME_POINTER is not set
CONFIG_EARLY_PRINTK=y

I built that using make-kpkg

make-kpkg clean
CONCURRENCY_LEVEL=4 MAKEFLAGS=CC=gcc-3.4 make-kpkg --revision=20050217 
kernel_image

-- 
Ralf Hildebrandt (i.A. des IT-Zentrum)  [EMAIL PROTECTED]
Charite - Universitätsmedizin BerlinTel.  +49 (0)30-450 570-155
Gemeinsame Einrichtung von FU- und HU-BerlinFax.  +49 (0)30-450 570-962
IT-Zentrum Standort CBF send no mail to [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 2/2] page table iterators

2005-02-17 Thread Nick Piggin
Linus Torvalds wrote:
On Fri, 18 Feb 2005, Nick Piggin wrote:
I am pretty surprised myself that I was able to consolidate
all page table range functions into a single type of iterator
(well, there are a couple of variations, but it's not too bad).

Ok, this is post-2.6.11 material, so please remind me.
Sure... it will probably be best to go through -mm, but either
way I'll package the patches up nicely and rediff them against
2.6.11 when it comes out.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2005-02-17 Thread Carl-Daniel Hailfinger
Matthew Garrett schrieb:
 On Thu, 2005-02-17 at 01:16 -0500, Len Brown wrote:
 
I think that it is the BIOS' job on S3-suspend
to save the video mode.  On S3-resume the BIOS should
re-POST and restore the video mode.
 
 I agree, but in the absence of spec requirement and some form of
 certification process, I don't see it happening in the near future.
 Given that vendors are still shipping invalid DSDTs, if Windows is able
 to reinitialise the graphics hardware, few are going to care about
 making life easier for Linux.

1. A first step towards better DSDTs would be to make the ASL compiler
complain about the same things which are complained about by the
in-kernel ACPI interpreter. An example would be the following:

acpi_processor-0496 [10] acpi_processor_get_inf: Invalid PBLK length [7]

The ASL compiler will not complain about it, yet the kernel will
refuse to do any processor throttling with a PBLK length of 7.

2. Urge/force vendors to use the latest ASL compiler available.
In most cases, this will result in a size reduction of the compiled
code, which should be in the interest of the vendors.

3. Get some shiny certification/label going that can be put on
fully conforming products as a sticker. Something like the old
EPA pollution preventer logo, but with a more appealing design.
Perhaps a InstantOn/PowerSave sticker, you get the idea.

4. Include a mandantory description of video bringup after resume
into the ACPI spec along the lines of Conforming products SHOULD
make information about handling of the primary video device on
resume available to the ACPI interpreter during runtime. If video
state will be preserved over a suspend/resume cycle, the _WAK
method for said video device MUST be empty. If the video device
requires any actions by the operating system after resume to restore
the state it had before suspend, the _WAK method for said video
device MUST contain ALL the code needed to restore the state before
suspend. The _WAK method MAY call OS-supplied ACPI helper functions
like ACPI_EXECUTE_CODE_FROM_ROM to keep the _WAK method short.
If no _WAK method for a given video device is available, the OS
MUST be able to rely on the fact that video state is preserved
over suspend/resume.


Something like item 4 would be a major step forward and as a bonus,
it wouldn't require any hardware changes, only perhaps 3 or 4
additional lines of code in the DSDT. If the _WAK function for
my laptop graphics card existed and had the hypothetical commands
ACPI_EXECUTE_CODE_FROM_ROM_X86(VGA.ROM)
ACPI_RESTORE_VESA_STATE(VGA)
we wouldn't have this discussion in the first place.


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


Re: queue_work from interrupt Real time preemption2.6.11-rc2-RT-V0.7.37-03

2005-02-17 Thread Mark Gross
On Thursday 17 February 2005 06:57, Steven Rostedt wrote:
 On Thu, 17 Feb 2005, Ingo Molnar wrote:
  as long as it stays on a single CPU, could we allow softirq contexts to
  preempt each other? I.e. we'd keep the per-CPU assumption (that is fair
  and needed for performance anyway), but we'd allow NET_TX to preempt
  NET_RX and vice versa. Would this corrupt the rx/tx queues? (i suspect
  it would.)
 
  (anyway, by adding an explicit no-preempt section around the 'take
  current rx queue private, then process it' on PREEMPT_RT it could be
  made safe. I'm wondering whether there are any other deeper assumptions
  about atomic separation of softirq contexts.)

 Ingo,

 Wouldn't this cause a longer latency in these sections. I understand
 that turning preemption off doesn't stop interrupts that are not
 threaded, but especially on a UP, this would cause higher latencies for
 high priority processes when a lower priority process is heavy on network
 traffic.

 As I mentioned earlier, what would it take to be able to group
 softirq threads that should not preempt each other, but still keep
 preemption available for other threads?

It would only take the creationt of multiple softIRQd threads per CPU.  Just 
keep net_rx and net_tx in the same work queue.



 Actually, I guess I need to ask, what do you intend on doing to prioritize
 the softirq?  Are you going to make a separate thread for each tasklet?
 Once I see what you're doing, I'll make something up to help handle this
 problem.

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

2005-02-17 Thread Florian Weimer
* Geert Uytterhoeven:

 Easy, start working for OSDL, then start hacking arch or
 whatever. Puff, you are his coworker, you are competing with Larry,
 Linus license goes away.

 I don't know whether the kernel hackers that work for IBM use the
 `free' version of BK or not, but if they do, s/OSDL/IBM/ and
 s/arch/ClearCase/ and there's a problem...

No, there isn't.  Bitmover can choose freely against whom they try to
enforce their copyright licenses.  Copyright law is not like trademark
law.  You can selectively enforce your rights without risking
dilution.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Swsusp, resume and kernel versions

2005-02-17 Thread John M Flinchbaugh
On Thu, Feb 17, 2005 at 12:07:31PM +0100, Pavel Machek wrote:
 When all the vendor's kernels have swsusp, it will magically kill the
 signature. Or stick mkswap /dev/XXX in your init scripts.

This is what I've done in some instances.  There should be no harm in
sticking that mkswap into your init scripts right before the swapon -a,
and then you have a nice userspace solution.

It's safe to reinitialize swap on any clean boot.  A resume will not get
into the init scripts.

Just remember you're doing the mkswap if you decide to rearrange your
partitions at all, or code a script smart enough to grep your swap
partitions out of your fstab.

-- 
John M Flinchbaugh
[EMAIL PROTECTED]


signature.asc
Description: Digital signature


Re: pci_map_rom bug?

2005-02-17 Thread Jon Smirl
On Wed, 16 Feb 2005 16:00:47 -0800, Jesse Barnes [EMAIL PROTECTED] wrote:
 It looks like it's trying to verify all the ROMs on a given PCI device rather
 than just the one we just ioremap'd above.  Should this check just be inline
 and the loop deleted?  In that case, all of the breaks would turn into return
 NULLs (though the code should probably be refactored to make that a little
 clearer) along with an iounmap?

The ROM experts on linux-pci supplied that code. It is legal to have
multiple images in a ROM for different formats, x86, OpenFirmware,
proprietary. The loop is adding all of the images together. Above we
IO remapped the entire PCI window which may be 64K and it contained
two images each at 20K. The extra loop returns the smaller size. This
lets the copy_rom case allocate 40K of memory instead of 64K.

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


Re: /proc/*/statm, exactly what does shared mean?

2005-02-17 Thread Richard F. Rebel
Hello Hugh,

On Wed, 2005-02-16 at 16:10 +, Hugh Dickins wrote:
 On Wed, 16 Feb 2005, Richard F. Rebel wrote:
  
  I have heard that this particular information, while very important to
  userland developers like me, is probably too expensive to keep track of
  for most users.
  
  Perhaps a way to enable it for developers, whom are willing to spend the
  cpu cycles, and disable it for regular use would be a solution.
  
  Would it be possible develop a solution allowing us to enable/disable
  this tracking via a sysctl call?
 
 Possible, but I don't think a sysctl would make much sense here.
 
 The most important thing is that any heavyweight information gathering
 should not be happening by default, as a side-effect of something
 frequently run.

Okay and agreed.

 So a lot of people would oppose putting back any such heavyweight
 work into any of the /proc/pid/statm fields.  But if it goes into
 a separate /proc/pid/whatever, not read by current tools, then
 it's much less of a problem.
 
 I'm still resistant, because I think if the information you're
 interested in (how many private pages shared across forks) really
 were of interest to many people, then someone would soon write a
 top-like tool which kept sampling these values, and we'd be back to
 the original situation.  Or if it's not of interest to many people,
 then isn't it better off as an out-of-tree patch?

Well, let's put it this way.  In general, would you agree that the bulk
of Linux servers on the internet run apache?  It's also not hard to
assume that many of these also run apache+php or apache+mod_perl.

Apache has lots of modules and code that can easily be shared between
processes.  Especially when you use mod_perl or php.  This sharing
significantly effects the memory footprint and saves us all from having
gigabytes of memory that we don't really need.  My apache2 processes
have a VSS of around 120MB!

The capacity of a web serving machine is some combination of CPU,
Memory, and IO bandwidth.  Being able to measure the copy-on-write pages
for processes is a key variable to determining a machine capacity.  This
figure changes over the life of the process as well, and can be used to
tell children to exit once they reach a certain point.

Now, about keeping it in the vanilla kernel:  AFAIK, the only way to
acquire this information is from the kernel.  It's useful to developers,
and available on most other platforms.  Copy on write pages make sense,
why waste tons of RAM when there is no real need?  It makes sense to be
able to observe this behavior, and the information can guide developers
to make their applications more efficient.

In many organizations developers do not have the ability/skill to make
custom kernels.  They are given development platforms, told to write
their applications, and so on and so on.  Patching the kernel for
keeping track of cow's and subsequently maintaining that patch really
doesn't help them much.  I could go on but this is getting a bit off
topic.

Best,

Richard Rebel

 But I don't have a dogmatic position on it,
 and trust others' judgement better than my own.
 
 Hugh
 -
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
-- 
Richard F. Rebel

cat /dev/null  `tty`


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


Re: [PATCH] quiet non-x86 option ROM warnings

2005-02-17 Thread Jon Smirl
On Thu, 17 Feb 2005 11:48:14 +1100, Benjamin Herrenschmidt
[EMAIL PROTECTED] wrote:
 On Wed, 2005-02-16 at 15:54 -0800, Jesse Barnes wrote:
  On Tuesday, February 15, 2005 5:03 pm, Benjamin Herrenschmidt wrote:
   What about printing No PCI ROM detected ? I like having that info when
   getting user reports, but I agree that a less worrying message would
   be good.
 
  Ok, how about this then?  It changes the printks in both drivers to 
  KERN_INFO
  and describes the situation a bit more accurately.
 
  Signed-off-by: Jesse Barnes [EMAIL PROTECTED]
 
  Thanks,
  Jesse
 
  P.S. Jon, I think the pci_map_rom code is buggy--if the option ROM signature
  is missing or indicates that there's no ROM, the routine still returns a
  valid pointer making the caller thing it succeeded.  If we fix that up we 
  can
  fix up the callers.
 
 No, pci_map_rom shouldn't test the signature IMHO. While PCI ROMs should
 have the signature to be recognized as containing valid firmware images
 on x86 BIOSes an OF, it's just a convention on these platforms, and I
 would rather let people put whatever they want in those ROMs and still
 let them map it...
 

pci_map_rom will return a pointer to any ROM it finds. It the
signature is invalid the size returned will be zero. Is this ok or do
we want it to do something different?

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


Re: [BK] upgrade will be needed

2005-02-17 Thread Lee Revell
On Thu, 2005-02-17 at 01:49 -0500, Sean wrote:
 The affects of many top level folks using a non free system is felt all
 the way down the food-chain.  If the top tier would agree to use a free
 SCM system then we could build bridges and offer the data in the preferred
 format to _everyone_  (arch, subversion, patch, BK, etc).  But because BK
 is used at the top, many useful options are cut off.   It's a rather large
 hidden cost of BK adoption as the primary tool at the top.

If you don't like it you are free to write a better SCM that is free
software.  I am sure if you brought Linus a free software SCM that's as
good as BK he would use it.  Bitching about it on LKML will not get you
any closer to having said SCM.

Lee

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


Re: Netfilter: TARPIT Target

2005-02-17 Thread Lee Revell
On Thu, 2005-02-17 at 10:27 -0500, Fao, Sean wrote:
 Where are those nonsense (base64) messages from [EMAIL PROTECTED] coming 
 from after I post?
 

Looks like a new spammer tactic.  They have progressed from spoofing
emails from real LKML posters to sending spam replies to actual threads.

Lee

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


Re: [BK] upgrade will be needed

2005-02-17 Thread Sean
On Thu, February 17, 2005 11:34 am, Lee Revell said:

 If you don't like it you are free to write a better SCM that is free
 software.  I am sure if you brought Linus a free software SCM that's as
 good as BK he would use it.  Bitching about it on LKML will not get you
 any closer to having said SCM.

Lee,

Your cookie cutter response, proves you didn't really absorb the content
of my message.   Please reread; there was no bitching at all.

Cheers,
Sean



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


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

2005-02-17 Thread Vernon Mauery
Carl-Daniel Hailfinger wrote:
 1. A first step towards better DSDTs would be to make the ASL compiler
 complain about the same things which are complained about by the
 in-kernel ACPI interpreter. An example would be the following:
 
 acpi_processor-0496 [10] acpi_processor_get_inf: Invalid PBLK length [7]
 
 The ASL compiler will not complain about it, yet the kernel will
 refuse to do any processor throttling with a PBLK length of 7.

This is like getting gcc to complain about run-time bugs in a program.  The 
compiler of a language (ASL in this case) compiles the language, regardless of 
run-time bugs because it can only detect syntax errors.  And iasl does that 
pretty well.  

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


Re: [BK] upgrade will be needed

2005-02-17 Thread Chris Friesen
Sean wrote:
Your cookie cutter response, proves you didn't really absorb the content
of my message.   Please reread; there was no bitching at all.
If you look at the archives, there have been a *lot* of people saying 
very much the same thing as you.  I suspect people are getting tired of 
giving the same responses all the time.

Here is what Linus had to say about it a while back:
   If people in the open-source SCM community wake up and notice that
   the current open-source SCM systems aren't cutting it, that's _good_.
   But it's absolutely NOT an excuse to use them today.  Sorry.  I use
   CVS at work, and I could never use it for Linux.  I took a look at
   subversion, and it doesn't even come close to what I wanted.
   And I personally refuse to use inferior tools because of ideology. In
   fact, I will go as far as saying that making excuses for bad tools
   due to ideology is _stupid_, and people who do that think with their
   gonads, not their brains.
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: [BK] upgrade will be needed

2005-02-17 Thread Sean
On Thu, February 17, 2005 11:55 am, Chris Friesen said:

 If you look at the archives, there have been a *lot* of people saying
 very much the same thing as you.  I suspect people are getting tired of
 giving the same responses all the time.

 Here is what Linus had to say about it a while back:

 If people in the open-source SCM community wake up and notice that
 the current open-source SCM systems aren't cutting it, that's _good_.
 But it's absolutely NOT an excuse to use them today.  Sorry.  I use
 CVS at work, and I could never use it for Linux.  I took a look at
 subversion, and it doesn't even come close to what I wanted.

 And I personally refuse to use inferior tools because of ideology. In
 fact, I will go as far as saying that making excuses for bad tools
 due to ideology is _stupid_, and people who do that think with their
 gonads, not their brains.

Chris,

Yes, I do remember that post.  But i'm not arguing from an ideological
basis; i'm arguing on practical grounds that the price of using BK is too
high for its supposed benefits.  I've not seen anyone else make that
argument here on the list and it is something that Linus may not have
given full consideration to.   At least the comment that you quote gives
no consideration to it at all.

Cheers,
Sean


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


spam mails with the same Message-ID

2005-02-17 Thread Adrian Bunk
On Thu, Feb 17, 2005 at 10:26:55AM -0500, Parag Warudkar wrote:
 On Thursday 17 February 2005 10:10 am, Paolo Ornati wrote:
   ÄúºÃ£º
       ÎÒÒÑ_­ÊÕµ_ÄúµÄÀ_ÐÅ
 
  and... what does this means?
 SPAM. This looks to me like a new way of spamming though, replying to valid 
 mailing list messages. (I too received couple of these in reply to my 
 messages.)

The most interesting fact seems to be that these spam messages have the 
same message ID as the original Mails.

If you run a program that automatically discards duplicate mails and the 
spam message reaches you faster than the original email through 
linux-kernel (which seems to often happen with these mails), the 
original email will be discarded. 

I don't know whether these are known attacks, but the automatic 
discarding of duplicated emails offers attackers nice opportunities if 
they know a message ID (as with these emails) or can guess the
message ID (since many MUAs have predictable message IDs, an attacker C
could use this to suppress a message from person A to person B by 
sending an email with the message ID to person B bevor person B gets 
the email from person A).

 Parag

cu
Adrian

-- 

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

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


[no subject]

2005-02-17 Thread Deepti Patel
Hi 
I am getting an error while inserting an hello world program. 

[EMAIL PROTECTED] deepti]$ /sbin/insmod hello-2.ko
insmod: error inserting 'hello-2.ko': -1 Operation not permitted

I haven't logged in as root. For inserting a module do I need to logged in as 
root?
I will really appretiate any suggestions.

Thanks in advance



-- 
___
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

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


Re: pci_map_rom bug?

2005-02-17 Thread Jesse Barnes
On Thursday, February 17, 2005 8:29 am, Jon Smirl wrote:
 On Wed, 16 Feb 2005 16:00:47 -0800, Jesse Barnes [EMAIL PROTECTED] wrote:
  It looks like it's trying to verify all the ROMs on a given PCI device
  rather than just the one we just ioremap'd above.  Should this check just
  be inline and the loop deleted?  In that case, all of the breaks would
  turn into return NULLs (though the code should probably be refactored to
  make that a little clearer) along with an iounmap?

 The ROM experts on linux-pci supplied that code. It is legal to have
 multiple images in a ROM for different formats, x86, OpenFirmware,
 proprietary. The loop is adding all of the images together. Above we
 IO remapped the entire PCI window which may be 64K and it contained
 two images each at 20K. The extra loop returns the smaller size. This
 lets the copy_rom case allocate 40K of memory instead of 64K.

Ah, ok, but we still have the situation that cause me to post the cleanup 
patch in the first place--pci_map_rom succeeds, but the first two bytes 
aren't 0x55aa but 0x0303...  Any ideas?

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