Location of character device of Matrox agpcard driver

2005-04-11 Thread karthik
Hi,

          Can anybody tell me where the device corresponding to the graphics 
driver 
is created ie whether its in /dev or /sys/class etc in 2.6 kernel.

        Also can i uses ioctls after opening the device to see its working.

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


Re: New SCM and commit list

2005-04-11 Thread Linus Torvalds


On Mon, 11 Apr 2005, Jeff Garzik wrote:
 
  But I hope that I can get non-conflicting merges done fairly soon, and 
  maybe I can con James or Jeff or somebody to try out GIT then...
 
 I don't mind being a guinea pig as long as someone else does the hard 
 work of finding a new way to merge :)

So I can tell you what merges are going to be like, just to prepare you.

First, the good news: I think we can make the workflow look like bk, ie
pretty much like git pull and git push.  And for well-behaved stuff
(ie minimal changes to the same files on both sides) it will even be fast.  
I think.

Then the bad news: the merge algorithm is going to suck. It's going to be
just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
understanding of renames etc. I'll try to find the best parent to base the
merge off of, although early testers may have to tell the piece of crud
what the most recent common parent was.

So anything that got modified in just one tree obviously merges to that 
version. Any file that got modified in two trees will end up just being 
passed to the merge program. See man merge and man diff3. The merger 
gets to fix up any conflicts by hand.

Quite frankly, that means that we really want to avoid any exciting 
merges with GIT. Maybe somebody can come up with something smarter. 
Eventually. Don't count on it, at least not in the near future.

The good news is that it's not like a three-way file merge is any worse
than many people are used to. The bad news is that BK is just a hell of a
lot better. So anybody who has been depending heavily on BK merges (and
hey, the beauty of them is that you often don't even _know_ that you are
depending on them) will be a bit bummed by the Welcome back to the
1980's message from a three-way merge.

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: [2.6 patch] drivers/block/ll_rw_blk.c: possible cleanups

2005-04-11 Thread Jens Axboe
On Sun, Apr 10 2005, Adrian Bunk wrote:
 This patch contains the following possible cleanups:
 - make needlessly global code static
 - remove the following unused global functions:
   - blkdev_scsi_issue_flush_fn

Kill the function completely, it is not used anymore.

   - __blk_attempt_remerge

Normally I would say leave that since it's part of the API, but lets
just kill it. I don't envision any further users of the remerging
attempts.

 - remove the following unused EXPORT_SYMBOL's:
   - blk_phys_contig_segment
   - blk_hw_contig_segment
   - blkdev_scsi_issue_flush_fn
   - __blk_attempt_remerge
 
 Please review which of these changes make sense.

Looks fine to me, thanks. Can you send a new patch that kills
blkdev_scsi_issue_flush_fn()?

-- 
Jens Axboe

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


Re: [discuss] [21/31] x86_64: Always use CPUID 80000008 to figure out MTRR address space size

2005-04-11 Thread Siddha, Suresh B
We need to use the size_and_mask in set_mtrr_var_ranges(which is called 
while programming MTRR's for AP's

Signed-off-by: Suresh Siddha [EMAIL PROTECTED]

--- linux/arch/i386/kernel/cpu/mtrr/generic.c~  2005-04-10 14:07:11.82144 
-0700
+++ linux/arch/i386/kernel/cpu/mtrr/generic.c   2005-04-10 14:12:21.913325536 
-0700
@@ -192,7 +192,8 @@ static int set_mtrr_var_ranges(unsigned 
 
rdmsr(MTRRphysBase_MSR(index), lo, hi);
if ((vr-base_lo  0xf0ffUL) != (lo  0xf0ffUL)
-   || (vr-base_hi  0xfUL) != (hi  0xfUL)) {
+   || (vr-base_hi  (size_and_mask  (32 - PAGE_SHIFT))) != 
+   (hi  (size_and_mask  (32 - PAGE_SHIFT {
mtrr_wrmsr(MTRRphysBase_MSR(index), vr-base_lo, vr-base_hi);
changed = TRUE;
}
@@ -200,7 +201,8 @@ static int set_mtrr_var_ranges(unsigned 
rdmsr(MTRRphysMask_MSR(index), lo, hi);
 
if ((vr-mask_lo  0xf800UL) != (lo  0xf800UL)
-   || (vr-mask_hi  0xfUL) != (hi  0xfUL)) {
+   || (vr-mask_hi  (size_and_mask  (32 - PAGE_SHIFT))) != 
+   (hi  (size_and_mask  (32 - PAGE_SHIFT {
mtrr_wrmsr(MTRRphysMask_MSR(index), vr-mask_lo, vr-mask_hi);
changed = TRUE;
}

On Thu, Apr 07, 2005 at 05:42:36PM +0200, Andi Kleen wrote:
 Always use CPUID 8008 to figure out MTRR address space size
 
 It doesn't make sense to only do this only for AMD K8.
 
 This would support future CPUs with extended address spaces properly.
 
 For i386 and x86-64
 
 Cc: [EMAIL PROTECTED]
 
 
 Index: linux/arch/i386/kernel/cpu/mtrr/main.c
 ===
 --- linux.orig/arch/i386/kernel/cpu/mtrr/main.c
 +++ linux/arch/i386/kernel/cpu/mtrr/main.c
 @@ -614,40 +614,21 @@ static int __init mtrr_init(void)
   mtrr_if = generic_mtrr_ops;
   size_or_mask = 0xff00;  /* 36 bits */
   size_and_mask = 0x00f0;
 - 
 - switch (boot_cpu_data.x86_vendor) {
 - case X86_VENDOR_AMD:
 - /* The original Athlon docs said that
 -total addressable memory is 44 bits wide.
 -It was not really clear whether its MTRRs
 -follow this or not. (Read: 44 or 36 bits).
 -However, x86-64_overview.pdf explicitly
 -states that previous implementations support
 -36 bit MTRRs and also provides a way to
 -query the width (in bits) of the physical
 -addressable memory on the Hammer family.
 -  */
 - if (boot_cpu_data.x86 == 15
 -  (cpuid_eax(0x8000) = 0x8008)) {
 - u32 phys_addr;
 - phys_addr = cpuid_eax(0x8008)  0xff;
 - size_or_mask =
 - ~((1  (phys_addr - PAGE_SHIFT)) - 1);
 - size_and_mask = ~size_or_mask  0xfff0;
 - }
 - /* Athlon MTRRs use an Intel-compatible interface for 
 -  * getting and setting */
 - break;
 - case X86_VENDOR_CENTAUR:
 - if (boot_cpu_data.x86 == 6) {
 - /* VIA Cyrix family have Intel style MTRRs, but 
 don't support PAE */
 - size_or_mask = 0xfff0;  /* 32 bits */
 - size_and_mask = 0;
 - }
 - break;
 - 
 - default:
 - break;
 + 
 + /* This is an AMD specific MSR, but we assume(hope?) that
 +Intel will implement it to when they extend the address
 +bus of the Xeon. */  
 + if (cpuid_eax(0x8000) = 0x8008) {
 + u32 phys_addr;
 + phys_addr = cpuid_eax(0x8008)  0xff;
 + size_or_mask = ~((1  (phys_addr - PAGE_SHIFT)) - 1);
 + size_and_mask = ~size_or_mask  0xfff0;
 + } else if (boot_cpu_data.x86_vendor == X86_VENDOR_CENTAUR 
 +boot_cpu_data.x86 == 6) {
 + /* VIA C* family have Intel style MTRRs, but
 +don't support PAE */
 + size_or_mask = 0xfff0;  /* 32 bits */
 + size_and_mask = 0;
   }
   } else {
   switch (boot_cpu_data.x86_vendor) {
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Kernel SCM saga..

2005-04-11 Thread Jan Hudec
On Mon, Apr 11, 2005 at 04:56:06 +0200, Marcin Dalecki wrote:
 
 On 2005-04-11, at 04:26, Miles Bader wrote:
 
 Marcin Dalecki [EMAIL PROTECTED] writes:
 Better don't waste your time with looking at Arch. Stick with patches
 you maintain by hand combined with some scripts containing a list of
 apply commands and you should be still more productive then when using
 Arch.
 
 Arch has its problems, but please lay off the uninformed flamebait (the
 issues you complain about are so utterly minor as to be laughable).
 
 I wish you a lot of laughter after replying to an already 3 days old 
 message,
 which was my final on Arch.

Marcin Dalecki [EMAIL PROTECTED] complained:
 Arch isn't a sound example of software design. Quite contrary to the 
 random notes posted by it's author the following issues did strike me 
 the time I did evaluate it:
 [...]

I didn't comment on this first time, but I see I should have. *NONE* of
the issues you complained about were issues of *DESIGN*. They were all
issues of *ENGINEERING*. *ENGINEERING* issues can be fixed. One of the
issues does not even exist any longer (the diff/patch one -- it now
checks they are the right ones -- and in all other respects it is
*exactly* the same as depending on a library)

But what really matters here is the concept. Arch has a simple concept,
that works well. Others have different concepts, that work well or
almost well too (Darcs, Monotone).

---
 Jan 'Bulb' Hudec [EMAIL 
PROTECTED]


signature.asc
Description: Digital signature


Re: Processes stuck on D state on Dual Opteron

2005-04-11 Thread Nick Piggin
Claudio Martins wrote:
On Sunday 10 April 2005 03:47, Andrew Morton wrote:
Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from
cutting in during long sysrq traces.
Also, capture the `sysrq-m' output so we can see if the thing is out of
memory.

  Hi Andrew,
  Thanks for the tip. I booted with nmi_watchdog=0 and was able to get a full 
sysrq-t as well as a sysrq-m. Since it might be a little too big for the 
list, I've put it on a text file at:

 http://193.136.132.235/dl145/dump1-2.6.12-rc2.txt
 I also made a run with the mempool-can-fail patch from Nick Piggin. With this 
I got some nice memory allocation errors from the md threads when the trouble 
started. The dump (with sysrq-t and sysrq-m included) is at:

 http://193.136.132.235/dl145/dump2-2.6.12-rc2-nick1.txt
 Let me know if you find it more convenient to send the dumps by mail or 
something. Hope this helps.

Itried to get these just now, but couldn't.
Would you gzip them and send them to me privately?
Thanks,
Nick
--
SUSE Labs, Novell 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: New SCM and commit list

2005-04-11 Thread Ryan Anderson
On Sun, Apr 10, 2005 at 11:15:20PM -0700, Linus Torvalds wrote:
 On Mon, 11 Apr 2005, Jeff Garzik wrote:
   But I hope that I can get non-conflicting merges done fairly soon, and 
   maybe I can con James or Jeff or somebody to try out GIT then...
  
  I don't mind being a guinea pig as long as someone else does the hard 
  work of finding a new way to merge :)
 
 So I can tell you what merges are going to be like, just to prepare you.
 
 First, the good news: I think we can make the workflow look like bk, ie
 pretty much like git pull and git push.  And for well-behaved stuff
 (ie minimal changes to the same files on both sides) it will even be fast.  
 I think.

If you can stick something meaningful in a simple text file, overwritten
after each merge completes, similar to the BitKeeper/csets-in file, it
should be trivial to write a wrapper for the basic merge tool that calls
a trigger after each merge and uses csets-in to generate diffs and email
them out.

-- 

Ryan Anderson
  sometimes Pug Majere
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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.12-rc1-mm4] fork_connector: add a fork connector

2005-04-11 Thread Evgeniy Polyakov
On Sun, Apr 10, 2005 at 10:43:24PM -0700, Jay Lan ([EMAIL PROTECTED]) wrote:
 I based my listen program on the fclisten.c posted by Kaigai Kohei
 with my own modification. Unfortunately i lost my test machine in the
 lab. I will recreate the listen program Monday. The original listener
 did not validate sequence number. It also prints length of data and
 sequence number of every message it receives. My listener prints
 only out-of-sequence error messages.
 
 The fork generator fork-test.c was yours? I called it fork-test
 and let it run continuously in while-loop:
 
 # while 1
 # ./fork-test 1000
 # sleep 1
 # end
 
 I let it do 10,000,000 times of fork continuously while the system
 is running AIM7 and/or ubench.
 
 The original fclisten.c and fork-test.c are attached for your reference.

It is pretty normal to see duplicated numbers in a fork test - 
I observed it too, since counter is incremented without locks
we can catch situation when it is incremented simultaneously 
on both processors, the latest version of the fork connector
from Guillaume contains processor id in the message and per cpu counters, 
so one can destinguish messages which sequence numbers will flow
in a very similar way now.

 - jay
 

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


Re: New SCM and commit list

2005-04-11 Thread Geert Uytterhoeven
On Sun, 10 Apr 2005, Linus Torvalds wrote:
 Then the bad news: the merge algorithm is going to suck. It's going to be
 just plain 3-way merge, the same RCS/CVS thing you've seen before. With no

Actually 3-way merge is not that bad. It's definitely better than ClearCase's
merge (I always fall back to RCS merge if ClearCase cannot resolve a merge
automatically).

 understanding of renames etc. I'll try to find the best parent to base the
 merge off of, although early testers may have to tell the piece of crud
 what the most recent common parent was.

Yep, finding the best parent is the important part :-)

I guess 3-way merge got a bad name because CVS always uses the branch point as
the parent, which fails miserably for any but the first merge after the branch.

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/


question about execve()

2005-04-11 Thread Tomko
Hi,
I would like to ask when a userprogram called in user space called 
execve(/bin/abc   will  this system call finally copy the code of 
/bin/abc into kernel space before kernel runs it or just leave the code 
in the userspace and run directly ?  If the system really copy the 
program into kernel space , why ?
Hope some one can tell me

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


Re: more git updates..

2005-04-11 Thread bert hubert
On Sun, Apr 10, 2005 at 03:38:39PM -0700, Linus Torvalds wrote:

 compressed with zlib, they are all named by the sha1 file, and they all 

Now I know this is a concious decision, but recent zlib allows you to write
out gzip content, at a cost of 14 bytes I think per file, by adding 32 to
the window size. This in turn would allow users to zcat your objects at
ease.

You get confirmation of completeness of the file for free, as gzip encodes
the length of the file at the end.

Perhaps something to consider.

-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://netherlabs.nl  Open and Closed source 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: Oops in swsusp

2005-04-11 Thread Rafael J. Wysocki
Hi,

On Monday, 11 of April 2005 01:17, Andreas Steinmetz wrote:
 Pavel,
 during testing of the encrypted swsusp_image on x86_64 I did get an Oops
 from time to time at memcpy+11 called from swsusp_save+1090 which turns
 out to be the memcpy in copy_data_pages() of swsusp.c.
 The Oops is caused by a NULL pointer (I don't remember if it was source
 or destination).

It's quite important, however.  If it's the destination, it's probably a bug in
swsusp.  Otherwise, the problem is more serious.  Could you, please,
add BUG_ON(!pbe-address) right before the memcpy() and retest?

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll Alice's Adventures in Wonderland
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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.12-rc1-mm4] fork_connector: add a fork connector

2005-04-11 Thread Andrew Morton
Evgeniy Polyakov [EMAIL PROTECTED] wrote:

 On Sun, Apr 10, 2005 at 10:43:24PM -0700, Jay Lan ([EMAIL PROTECTED]) wrote:
  I based my listen program on the fclisten.c posted by Kaigai Kohei
  with my own modification. Unfortunately i lost my test machine in the
  lab. I will recreate the listen program Monday. The original listener
  did not validate sequence number. It also prints length of data and
  sequence number of every message it receives. My listener prints
  only out-of-sequence error messages.
  
  The fork generator fork-test.c was yours? I called it fork-test
  and let it run continuously in while-loop:
  
  # while 1
  # ./fork-test 1000
  # sleep 1
  # end
  
  I let it do 10,000,000 times of fork continuously while the system
  is running AIM7 and/or ubench.
  
  The original fclisten.c and fork-test.c are attached for your reference.
 
 It is pretty normal to see duplicated numbers in a fork test - 
 I observed it too, since counter is incremented without locks
 we can catch situation when it is incremented simultaneously 
 on both processors, the latest version of the fork connector
 from Guillaume contains processor id in the message and per cpu counters, 
 so one can destinguish messages which sequence numbers will flow
 in a very similar way now.

Oh come on, that's just daft.  Evgeniy, put a lock in there and fix it up.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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.7 1/1] x86 reboot: Add reboot fixup for gx1/cs5530a

2005-04-11 Thread jayalk
Hi Riley, Dave, Peter, i386 boot/workaround maintainers,

I'm resending this patch (from March 28). 

This patch incorporates the suggestions from the previous thread and also
switches to using pci_get_device since pci_find_device is deprecated, and
made some of the variables static.

Please let me know if it's okay.

Thanks,
Jaya Kumar

--- 

I ran into a problem getting reboot working with 2.6.11 on an embedded
board. The board has a Geode GX1 with a CS5530A companion. What I observe on
reboot is the Restarting system printk, and then a cpu stall/hang. I think
the problem arises because the keyboard controller is disabled by the BIOS,
so the traditional mach_reboot()'s output to port 0x64 is ignored. Then the
386 triple fault issued after mach_reboot() results in a shutdown (because
the hardware doesn't have to detect the triple fault and issue a reset).
That then gives the end result of a stalled cpu/hang. 

I found that the CS5530A in question has a issue system wide reset bit.
The reboot works cleanly if I write that bit rather than do mach_reboot().
So the following patch is my attempt to incorporate that change into 2.6.11
by adding a X86_REBOOTFIXUPS option. In order to keep reboot.c free of hw
specific fixups, I put it in another file, reboot_fixups.c. I tried to make
it a bit generic so that if there are other reboot related fixups for other
chipsets/boards, there'd be a clean place to put it. Please let me know what
you think.

Thanks,
Jaya Kumar

---

Signed-off-by:  Jaya Kumar  [EMAIL PROTECTED]

diff -uprN -X dontdiff linux-2.6.11.7-vanilla/arch/i386/Kconfig 
linux-2.6.11.7/arch/i386/Kconfig
--- linux-2.6.11.7-vanilla/arch/i386/Kconfig2005-04-08 02:57:18.0 
+0800
+++ linux-2.6.11.7/arch/i386/Kconfig2005-04-11 14:21:05.0 +0800
@@ -645,6 +645,24 @@ config I8K
  Say Y if you intend to run this kernel on a Dell Inspiron 8000.
  Say N otherwise.
 
+config X86_REBOOTFIXUPS
+   bool Enable X86 board specific fixups for reboot
+   depends on X86 
+   default n
+   ---help---
+ This enables chipset and/or board specific fixups to be done
+ in order to get reboot to work correctly. This is only needed on
+ some combinations of hardware and BIOS. The symptom, for which 
+ this config is intended, is when reboot ends with a stalled/hung 
+ system. 
+
+ Currently, the only fixup is for the Geode GX1/CS5530A/TROM2.1. 
+ combination.
+
+ Say Y if you want to enable the fixup. Currently, it's safe to
+ enable this option even if you don't need it.
+ Say N otherwise.
+
 config MICROCODE
tristate /dev/cpu/microcode - Intel IA32 CPU microcode support
---help---
diff -uprN -X dontdiff linux-2.6.11.7-vanilla/arch/i386/kernel/Makefile 
linux-2.6.11.7/arch/i386/kernel/Makefile
--- linux-2.6.11.7-vanilla/arch/i386/kernel/Makefile2005-04-08 
02:57:22.0 +0800
+++ linux-2.6.11.7/arch/i386/kernel/Makefile2005-04-11 13:10:31.0 
+0800
@@ -23,6 +23,7 @@ obj-$(CONFIG_X86_TRAMPOLINE)  += trampoli
 obj-$(CONFIG_X86_MPPARSE)  += mpparse.o
 obj-$(CONFIG_X86_LOCAL_APIC)   += apic.o nmi.o
 obj-$(CONFIG_X86_IO_APIC)  += io_apic.o
+obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups.o
 obj-$(CONFIG_X86_NUMAQ)+= numaq.o
 obj-$(CONFIG_X86_SUMMIT_NUMA)  += summit.o
 obj-$(CONFIG_KPROBES)  += kprobes.o
diff -uprN -X dontdiff linux-2.6.11.7-vanilla/arch/i386/kernel/reboot.c 
linux-2.6.11.7/arch/i386/kernel/reboot.c
--- linux-2.6.11.7-vanilla/arch/i386/kernel/reboot.c2005-04-08 
02:57:27.0 +0800
+++ linux-2.6.11.7/arch/i386/kernel/reboot.c2005-04-11 13:10:31.0 
+0800
@@ -13,6 +13,7 @@
 #include asm/uaccess.h
 #include asm/apic.h
 #include mach_reboot.h
+#include linux/reboot_fixups.h
 
 /*
  * Power off function, if any
@@ -348,6 +349,7 @@ void machine_restart(char * __unused)
/* rebooting needs to touch the page at absolute addr 0 */
*((unsigned short *)__va(0x472)) = reboot_mode;
for (;;) {
+   mach_reboot_fixups(); /* for board specific fixups */
mach_reboot();
/* That didn't work - force a triple fault.. */
__asm__ __volatile__(lidt %0: :m (no_idt));
diff -uprN -X dontdiff linux-2.6.11.7-vanilla/arch/i386/kernel/reboot_fixups.c 
linux-2.6.11.7/arch/i386/kernel/reboot_fixups.c
--- linux-2.6.11.7-vanilla/arch/i386/kernel/reboot_fixups.c 1970-01-01 
07:30:00.0 +0730
+++ linux-2.6.11.7/arch/i386/kernel/reboot_fixups.c 2005-04-11 
14:09:02.0 +0800
@@ -0,0 +1,56 @@
+/*
+ * linux/arch/i386/kernel/reboot_fixups.c
+ * 
+ * This is a good place to put board specific reboot fixups.
+ *
+ * List of supported fixups:
+ * geode-gx1/cs5530a - Jaya Kumar [EMAIL PROTECTED]
+ *
+ */
+
+#include asm/delay.h
+#include linux/pci.h
+
+static void 

Re: New SCM and commit list

2005-04-11 Thread David Woodhouse
On Mon, 2005-04-11 at 09:10 +1000, Benjamin Herrenschmidt wrote:
 Do you intend to continue posting commited patches to a mailing list
 like bk scripts did to [EMAIL PROTECTED] ? As I said a while ago, I
 find this very useful, especially with the actual patch included in the
 commit message (which isn't the case with most other projects CVS commit
 lists, and I find that annoying).
 
 If yes, then I would appreciate if you could either keep the same list,
 or if you want to change the list name, keep the subscriber list so
 those of us who actually archive it don't miss anything ;)

The commits lists currently only accept posts from [EMAIL PROTECTED], I
believe. That can relatively easily be changed if the mail is going to
come from somewhere else.

I did ask Linus to let me know as soon as possible when he starts to
commit patches, so we can come up with a way to keep the list fed. Since
he thinks I'm James, however, I suspect that part of the message didn't
get through. Perhaps he was just distracted by the Britishness?

-- 
dwmw2


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 Alpha port: kernel panik under moderate DISK IO conditions

2005-04-11 Thread Rao Davide
I'm not using the qlogic controller as boot controller. I'm mooting from 
the internal disk connected to LSI controller.
In any case I'll try out the suggested 1280  right now.

Can I build a modular kernel with the 2.6 kernel series ?
I would find it handy to have som parts colpiled as modules.
--
Regards
Davide Rao
  Client/server Unix
  Atos Origin
  Via C.Viola - Pont St. Martin (AO) Italy
  Cell :  +39 3357599151
  Tel  :  +39 125810433
  Email:  [EMAIL PROTECTED]
Richard Henderson wrote:
On Fri, Apr 08, 2005 at 04:57:11PM +0200, Rao Davide wrote:
My name is David Rao and I have an old alpha DS10 ds10 (ev6 
Tsunami-webbrick cpu) with internal HDU on a LSI controller and external 
HSZ80 storage attached to a Qlogic.

Well, the CONFIG_SCSI_QLOGIC_ISP driver isn't supported, and you
may have noticed prints big warning messages when you boot with it.
Fortunately, the CONFIG_SCSI_QLOGIC_1280 driver has been extended
to handle the 1020 and 1040 devices.  I've been using that for a
while now on my ds10.
r~
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: more git updates..

2005-04-11 Thread Christer Weinigel
bert hubert [EMAIL PROTECTED] writes:

 On Sun, Apr 10, 2005 at 03:38:39PM -0700, Linus Torvalds wrote:
 
  compressed with zlib, they are all named by the sha1 file, and they all 
 
 Now I know this is a concious decision, but recent zlib allows you to write
 out gzip content, at a cost of 14 bytes I think per file, by adding 32 to
 the window size. This in turn would allow users to zcat your objects at
 ease.
 
 You get confirmation of completeness of the file for free, as gzip encodes
 the length of the file at the end.

I would very much like it if git used normal gzip files with a .gz
extension.  Doing it this way means that the compression methods can
be extended in the future.  I.e:

ab/1234567890.gzgzip compressed
ab/1234567890.xdxdelta compressed

I find the xdelta encoding very attractive since it can probably
reduce the size of the repository drastically.  A compression script
could for run nightly and xdelta compress everything that's older than
a few months (to figure out what files to create the delta from, just
look at the commit files and compare the parent tree to the current
tree).

Of course, this means that a dumb wget won't work all that well to
synchronize two trees, but it might be worthwile anyways.

  /Christer

-- 
Just how much can I get away with and still go to heaven?

Freelance consultant specializing in device driver programming for Linux 
Christer Weinigel [EMAIL PROTECTED]  http://www.weinigel.se
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] reparent_to_init-cleanup

2005-04-11 Thread Coywolf Qi Hunt
Hello,

Split out from my oom-killer patch, this patch hides reparent_to_init(). 
reparent_to_init()
should only be called by daemonize(). This applies to 2.6.12-rc2-mm2 too.

Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED]
---

 arch/i386/mach-voyager/voyager_thread.c |1 -
 include/linux/sched.h   |1 -
 kernel/exit.c   |2 +-
 3 files changed, 1 insertion(+), 3 deletions(-)

diff -pruN 2.6.12-rc2-mm1/arch/i386/mach-voyager/voyager_thread.c 
2.6.12-rc2-mm1-cy/arch/i386/mach-voyager/voyager_thread.c
--- 2.6.12-rc2-mm1/arch/i386/mach-voyager/voyager_thread.c  2004-08-20 
14:39:58.0 +0800
+++ 2.6.12-rc2-mm1-cy/arch/i386/mach-voyager/voyager_thread.c   2005-04-08 
18:53:06.0 +0800
@@ -126,7 +126,6 @@ thread(void *unused)
 
kvoyagerd_running = 1;
 
-   reparent_to_init();
daemonize(THREAD_NAME);
 
set_timeout = 0;
diff -pruN 2.6.12-rc2-mm1/include/linux/sched.h 
2.6.12-rc2-mm1-cy/include/linux/sched.h
--- 2.6.12-rc2-mm1/include/linux/sched.h2005-04-06 10:18:18.0 
+0800
+++ 2.6.12-rc2-mm1-cy/include/linux/sched.h 2005-04-08 18:53:06.0 
+0800
@@ -1068,7 +1068,6 @@ extern void exit_itimers(struct signal_s
 
 extern NORET_TYPE void do_group_exit(int);
 
-extern void reparent_to_init(void);
 extern void daemonize(const char *, ...);
 extern int allow_signal(int);
 extern int disallow_signal(int);
diff -pruN 2.6.12-rc2-mm1/kernel/exit.c 2.6.12-rc2-mm1-cy/kernel/exit.c
--- 2.6.12-rc2-mm1/kernel/exit.c2005-04-06 10:18:20.0 +0800
+++ 2.6.12-rc2-mm1-cy/kernel/exit.c 2005-04-08 18:53:06.0 +0800
@@ -224,7 +224,7 @@ static inline int has_stopped_jobs(int p
  *
  * NOTE that reparent_to_init() gives the caller full capabilities.
  */
-void reparent_to_init(void)
+static inline void reparent_to_init(void)
 {
write_lock_irq(tasklist_lock);
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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.12-rc1-mm4] fork_connector: add a fork connector

2005-04-11 Thread Evgeniy Polyakov
On Sun, Apr 10, 2005 at 11:51:24PM -0700, Andrew Morton ([EMAIL PROTECTED]) 
wrote:
 Evgeniy Polyakov [EMAIL PROTECTED] wrote:
 
  On Sun, Apr 10, 2005 at 10:43:24PM -0700, Jay Lan ([EMAIL PROTECTED]) wrote:
   I based my listen program on the fclisten.c posted by Kaigai Kohei
   with my own modification. Unfortunately i lost my test machine in the
   lab. I will recreate the listen program Monday. The original listener
   did not validate sequence number. It also prints length of data and
   sequence number of every message it receives. My listener prints
   only out-of-sequence error messages.
   
   The fork generator fork-test.c was yours? I called it fork-test
   and let it run continuously in while-loop:
   
   # while 1
   # ./fork-test 1000
   # sleep 1
   # end
   
   I let it do 10,000,000 times of fork continuously while the system
   is running AIM7 and/or ubench.
   
   The original fclisten.c and fork-test.c are attached for your reference.
  
  It is pretty normal to see duplicated numbers in a fork test - 
  I observed it too, since counter is incremented without locks
  we can catch situation when it is incremented simultaneously 
  on both processors, the latest version of the fork connector
  from Guillaume contains processor id in the message and per cpu counters, 
  so one can destinguish messages which sequence numbers will flow
  in a very similar way now.
 
 Oh come on, that's just daft.  Evgeniy, put a lock in there and fix it up.

#ifndef FAST_AND_SUSPICIOUS
spin_lock(fork_lock);
#endif
seq++;
#ifndef FAST_AND_SUSPICIOUS
spin_unlock(fork_lock);
#endif

:)

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


Re: New SCM and commit list

2005-04-11 Thread Ingo Molnar

* Linus Torvalds [EMAIL PROTECTED] wrote:

 Then the bad news: the merge algorithm is going to suck. It's going to 
 be just plain 3-way merge, the same RCS/CVS thing you've seen before.  
 With no understanding of renames etc. I'll try to find the best parent 
 to base the merge off of, although early testers may have to tell the 
 piece of crud what the most recent common parent was.
 
 So anything that got modified in just one tree obviously merges to 
 that version. Any file that got modified in two trees will end up just 
 being passed to the merge program. See man merge and man diff3.  
 The merger gets to fix up any conflicts by hand.

at that point Chris Mason's rej tool is pretty nifty:

  ftp://ftp.suse.com/pub/people/mason/rej/rej-0.13.tar.gz

it gets the trivial rejects right, and is pretty powerful to quickly 
cycle through the nontrivial ones too. It shows the old and new code 
side by side too, etc.

(There is no fully automatic mode in where it would not bother the user 
with the really trivial rejects - but it has an automatic mode where you 
basically have to do nothing - maybe a fully automatic one could be 
added that would resolve low-risk rejects?)

it's really easy to use (but then again i'm a vim user, so i'm biased), 
just try it on a random .rej file you have (rej -a kernel/sched.c.rej 
or whatever).

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: 2.6.12-rc2-mm1

2005-04-11 Thread Stefan Seyfried
Barry K. Nathan wrote:
 On Sun, Apr 10, 2005 at 11:27:47PM +0200, Pavel Machek wrote:
 Can you try without XFS?
 
 No, XFS is my root filesystem. :( (Now that I think about it, would
 modularizing XFS and using an initrd be OK?)

Yes, although it is not totally trivial.

 I'll see if I can reproduce this on one of my test boxes. I'll *try* to
 get to it later today, but it's possible that I won't be able to get to
 it until next Friday or Saturday.
 
 I do not why it interferes, but I've seen that before on suse
 kernels...
 
 Have you seen it without the resume-from-initrd patch too, or only with
 that patch?

We have seen it in 9.3-beta, exact scenario was:
- root fs is XFS, ide driver is modular
  = xfs module and ide-controller module is in initramfs
  = first all modules were loaded (device driver + fs)
  = resume was triggered, resume was _really_ slow.

we worked around it in the initramfs by first loading device drivers,
triggering resume, then loading the fs modules and continuing boot.
In the resume case, we'd never reach the load fs modules part and
generally it seems a good idea (if the drivers are modular) to keep the
setup before resume as minimalistic as possible.

We never tried with XFS compiled in. It seems we can no longer hide from
fixing XFS ;-)

Best regards,

 Stefan

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


Re: [PATCH] zero disk pages used by swsusp on resume

2005-04-11 Thread Stefan Seyfried
Pavel Machek wrote:

 Encrypting swsusp image is of course even better, because you don't
 have to write large ammounts of zeros to your disks during resume ;-).

and while we are at it: compressing before encryption will also reduce
the amount of data you have to write during suspend... ;-)

   Pavel

Stefan

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


Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

2005-04-11 Thread Ingo Molnar

* Linus Torvalds [EMAIL PROTECTED] wrote:

 Btw, does anybody have strong opinions on the license? I didn't put in 
 a COPYING file exactly because I was torn between GPLv2 and OSL2.1.
 
 I'm inclined to go with GPLv2 just because it's the most common one, 
 but I was wondering if anybody really had strong opinions. For 
 example, I'd really make it v2 by default like the kernel, since I'm 
 sure v3 will be fine, but regardless of how sure I am, I'm _not_ a 
 gambling man.

is there any fundamental problem with going with v2 right now, and then 
once v3 is out and assuming it looks ok, all newly copyrightable bits 
(new files, rewrites, substantial contributions, etc.) get a v3 
copyright? (and the collection itself would be v3 too) That method 
wouldnt make it fully v3 automatically once v3 is out, but with time 
there would be enough v3 bits in it to make it essentially v3. This way 
we wouldnt have to blanket trust v3 before having seen it, and wouldnt 
be stuck at v2 either.

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: bdflush/rpciod high CPU utilization, profile does not make sense

2005-04-11 Thread Jakob Oestergaard
On Sat, Apr 09, 2005 at 05:52:32PM -0400, Trond Myklebust wrote:
 lau den 09.04.2005 Klokka 23:35 (+0200) skreiv Jakob Oestergaard:
 
  2.6.11.6: (dual PIII 1GHz, 2G RAM, Intel e1000)
  
   File   Block  Num  Seq ReadRand Read   Seq Write  Rand Write
DirSize   Size   Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
  --- -- --- --- --- --- --- ---
 . 2000   40961  38.34 18.8% 19.61 6.77% 22.53 23.4% 6.947 15.6%
 . 2000   40962  52.82 29.0% 24.42 9.37% 24.20 27.0% 7.755 16.7%
 . 2000   40964  62.48 34.8% 33.65 17.0% 24.73 27.6% 8.027 15.4%
  
  
  44MiB/sec for 2.4 versus 22MiB/sec for 2.6 - any suggestions as to how
  this could be improved?
 
 What happened to the retransmission rates when you changed to TCP?

tcp with timeo=600 causes retransmits (as seen with nfsstat) to drop to
zero.

 
 Note that on TCP (besides bumping the value for timeo) I would also
 recommend using a full 32k r/wsize instead of 4k (if the network is of
 decent quality, I'd recommend 32k for UDP too).

32k seems to be default for both UDP and TCP.

The network should be of decent quality - e1000 on client, tg3 on
server, both with short cables into a gigabit switch with plenty of
backplane headroom.

 The other tweak you can apply for TCP is to bump the value
 for /proc/sys/sunrpc/tcp_slot_table_entries. That will allow you to have
 several more RPC requests in flight (although that will also tie up more
 threads on the server).

Changing only to TCP gives me:

 File   Block  Num  Seq ReadRand Read   Seq Write  Rand Write
  DirSize   Size   Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
--- -- --- --- --- --- --- ---
   . 2000   40961  47.04 65.2% 50.57 26.2% 24.24 29.7% 6.896 28.7%
   . 2000   40962  55.77 66.1% 61.72 31.9% 24.13 33.0% 7.646 26.6%
   . 2000   40964  61.94 68.9% 70.52 42.5% 25.65 35.6% 8.042 26.7%

Pretty much the same as before - with writes being suspiciously slow
(compared to good ole' 2.4.25)

With tcp_slot_table_entries bumped to 64 on the client (128 knfsd
threads on the server, same as in all tests), I see:

 File   Block  Num  Seq ReadRand Read   Seq Write  Rand Write
  DirSize   Size   Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
--- -- --- --- --- --- --- ---
   . 2000   40961  60.50 67.6% 30.12 14.4% 22.54 30.1% 7.075 27.8%
   . 2000   40962  59.87 69.0% 34.34 19.0% 24.09 35.2% 7.805 30.0%
   . 2000   40964  62.27 69.8% 44.87 29.9% 23.07 34.3% 8.239 30.9%

So, reads start off better, it seems, but writes are still half speed of
2.4.25.

I should say that it is common to see a single rpciod thread hogging
100% CPU for 20-30 seconds - that looks suspicious to me, other than
that, I can't really point my finger at anything in this setup.

Any suggestions Trond?   I'd be happy to run some tests for you if you
have any idea how we can speed up those writes (or reads for that
matter, although I am fairly happy with those).


-- 

 / jakob

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 encrypted swsusp 0/3] encrypted swsusp image

2005-04-11 Thread folkert
 The following patches allow for encryption of the on-disk swsusp image
 to prevent data gathering of e.g. in-kernel keys or mlocked data after
 resume.
 For this purpose the aes cipher must be compiled into the kernel as
 module load is not possible at resume time.
 A random key is generated at suspend time, stored in the suspend header
 on disk and deleted from the header at resume time. If you don't resume
 a mkswap on the suspend partition will also delete the temporary key.
 Only the data pages are encrypted as only these may contain sensitive data.
 This works on my x86_64 laptop (64bit mode) and probably needs testing
 on other platforms.

What about an option for an user-defined key? One that can be set when
suspending?


Folkert van Heusden

Auto te koop! Zie: http://www.vanheusden.com/daihatsu.php
Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden!
+--+
|UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/)|
|a try, it brings monitoring logfiles to a different level! See|
|http://vanheusden.com/multitail/features.html for a feature list. |
+--= www.unixsoftware.nl =-+
Phone: +31-6-41278122, PGP-key: 1F28D8AE
Get your PGP/GPG key signed at www.biglumber.com!


pgpNAtjpp9ckB.pgp
Description: PGP signature


Unable to boot 2.6.12-rc2-mm1 with command line maxcpus=1

2005-04-11 Thread Vivek Goyal
Hi,

I am having problems while booting 2.6.12-rc2-mm1 on i386 with command line 
maxcpus=1.  Without this commandline, system boots fine otherwise it hangs. 
Serial output is pasted below.

If maxcpus=1 is given along with acpi=off then system boots fine. I am not sure 
where the problem is.

2.6.12-rc1-mm4 does not have this problem.

Any idea what is going on? config file is attached with the mail.

Thanks
Vivek


LILO boot: 
linux   linux-upt   base
2.6.5-sy2.6.12-rc1-mm1  hzless  Rachita-crash
vivek   sharyathi   
boot: vivek
Loading vivek.
Linux version 2.6.12-rc2-mm1-1M ([EMAIL PROTECTED]) (gcc version 3.2.3 20030502 
(Red Hat Linux 3.2.3-31)) #1 SMP PREEMPT Mon Apr 11 11:40:30 IST 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009e000 (usable)
 BIOS-e820: 0009e000 - 000a (reserved)
 BIOS-e820: 000e - 0010 (reserved)
 BIOS-e820: 0010 - efff6500 (usable)
 BIOS-e820: efff6500 - f000 (ACPI data)
 BIOS-e820: fffb - 0001 (reserved)
 BIOS-e820: 0001 - 0002 (usable)
user-defined physical RAM map:
 user:  - 0009e000 (usable)
 user: 0009e000 - 000a (reserved)
 user: 000e - 0010 (reserved)
 user: 0010 - 8000 (usable)
1152MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 0009e140
DMI 2.1 present.
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x07] enabled)
Processor #7 6:10 APIC version 17
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 6:10 APIC version 17
WARNING: maxcpus limit of 1 reached. Processor ignored.
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 6:10 APIC version 17
WARNING: maxcpus limit of 1 reached. Processor ignored.
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled)
Processor #2 6:10 APIC version 17
WARNING: maxcpus limit of 1 reached. Processor ignored.
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled)
Processor #3 6:10 APIC version 17
WARNING: maxcpus limit of 1 reached. Processor ignored.
ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled)
Processor #4 6:10 APIC version 17
WARNING: maxcpus limit of 1 reached. Processor ignored.
ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled)
Processor #5 6:10 APIC version 17
WARNING: maxcpus limit of 1 reached. Processor ignored.
ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] enabled)
Processor #6 6:10 APIC version 17
WARNING: maxcpus limit of 1 reached. Processor ignored.
ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x04] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x05] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x06] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x07] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x0e] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 14, version 19, address 0xfec0, GSI 0-63
ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 8 low edge)
ACPI: NMI_SRC (dfl dfl global_irq 58)
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 8000 (gap: 8000:8000)
Built 1 zonelists
Initializing CPU#0
Kernel command line: BOOT_IMAGE=vivek ro 
BOOT_FILE=/boot/bzImage-2.6.12-rc2-mm1-1M root=/dev/sda3 consle=tty0 
console=ttyS0,38400 maxcpus=1 [EMAIL PROTECTED] mem=2G
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 900.198 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2024916k/2097152k available (3086k kernel code, 71432k reserved, 1142k 
data, 232k init, 1179648k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Mount-cache hash table entries: 512
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 2048K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
CPU0: Intel Pentium III (Cascades) stepping 04
Total of 1 processors activated (1769.47 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 pin1=0 pin2=-1
Brought up 1 CPUs
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfd26c, last bus=15
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050309
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] segment is 0
ACPI: Assume root 

[PATCH] ppc64: very basic desktop g5 sound support

2005-04-11 Thread Benjamin Herrenschmidt
Hi !

This patch hacks the current PowerMac Alsa driver to add some basic
support of analog sound output to some desktop G5s. It has severe
limitations though:

 - Only 44100Khz 16 bits
 - Only work on G5 models using a TAS3004 analog code, that is early
   single CPU desktops and all dual CPU desktops at this date, but none
   of the more recent ones like iMac G5.
 - It does analog only, no digital/SPDIF support at all, no native
   AC3 support

Better support would require a complete rewrite of the driver (which I
am working on,  but don't hold your breath), to properly support the
diversity of apple sound HW setup, including dual codecs, several i2s
busses,  all the new codecs used in the new machines, proper clock
switching with digital, etc etc etc...

This patch applies on top of the other PowerMac sound patches I posted
in the past couple of days (new powerbook support and sleep fixes). 

Note: This is a FAQ entry for PowerMac sound support with TI codecs:
They have a feature called DRC which is automatically enabled for the
internal speaker (at least when auto mute control is enabled) which will
cause your sound to fade out to nothing after half a second of playback
if you don't set a proper DRC Range in the mixer. So if you have a
problem like that, check alsamixer and raise your DRC Range to something
reasonable.

Note2: This patch will also add auto-mute of the speaker when line-out
jack is used on some earlier desktop G4s (and on the G5) in addition to
the headphone jack. If that behaviour isn't what you want, just disable
auto-muting and use the manual mute controls in alsamixer.

Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]

Index: linux-work/sound/ppc/pmac.c
===
--- linux-work.orig/sound/ppc/pmac.c2005-04-11 10:50:18.0 +1000
+++ linux-work/sound/ppc/pmac.c 2005-04-11 17:48:06.0 +1000
@@ -27,14 +27,13 @@
 #include linux/delay.h
 #include linux/slab.h
 #include linux/interrupt.h
+#include linux/pci.h
+#include linux/dma-mapping.h
 #include sound/core.h
 #include pmac.h
 #include sound/pcm_params.h
-#ifdef CONFIG_PPC_HAS_FEATURE_CALLS
 #include asm/pmac_feature.h
-#else
-#include asm/feature.h
-#endif
+#include asm/pci-bridge.h
 
 
 #if defined(CONFIG_PM)  defined(CONFIG_PMAC_PBOOK)
@@ -57,22 +56,29 @@
 /*
  * allocate DBDMA command arrays
  */
-static int snd_pmac_dbdma_alloc(pmac_dbdma_t *rec, int size)
+static int snd_pmac_dbdma_alloc(pmac_t *chip, pmac_dbdma_t *rec, int size)
 {
-   rec-space = kmalloc(sizeof(struct dbdma_cmd) * (size + 1), GFP_KERNEL);
+   unsigned int rsize = sizeof(struct dbdma_cmd) * (size + 1);
+
+   rec-space = dma_alloc_coherent(chip-pdev-dev, rsize,
+   rec-dma_base, GFP_KERNEL);
if (rec-space == NULL)
return -ENOMEM;
rec-size = size;
-   memset(rec-space, 0, sizeof(struct dbdma_cmd) * (size + 1));
+   memset(rec-space, 0, rsize);
rec-cmds = (void __iomem *)DBDMA_ALIGN(rec-space);
-   rec-addr = virt_to_bus(rec-cmds);
+   rec-addr = rec-dma_base + (unsigned long)((char *)rec-cmds - (char 
*)rec-space);
+
return 0;
 }
 
-static void snd_pmac_dbdma_free(pmac_dbdma_t *rec)
+static void snd_pmac_dbdma_free(pmac_t *chip, pmac_dbdma_t *rec)
 {
-   if (rec)
-   kfree(rec-space);
+   if (rec) {
+   unsigned int rsize = sizeof(struct dbdma_cmd) * (rec-size + 1);
+
+   dma_free_coherent(chip-pdev-dev, rsize, rec-space, 
rec-dma_base);
+   }
 }
 
 
@@ -237,7 +243,7 @@
/* continuous DMA memory type doesn't provide the physical address,
 * so we need to resolve the address here...
 */
-   offset = virt_to_bus(runtime-dma_area);
+   offset = runtime-dma_addr;
for (i = 0, cp = rec-cmd.cmds; i  rec-nperiods; i++, cp++) {
st_le32(cp-phy_addr, offset);
st_le16(cp-req_count, rec-period_size);
@@ -664,8 +670,8 @@
chip-capture.cur_freqs = chip-freqs_ok;
 
/* preallocate 64k buffer */
-   snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_CONTINUOUS, 
- 
snd_dma_continuous_data(GFP_KERNEL),
+   snd_pcm_lib_preallocate_pages_for_all(pcm, SNDRV_DMA_TYPE_DEV, 
+ chip-pdev-dev,
  64 * 1024, 64 * 1024);
 
return 0;
@@ -757,28 +763,10 @@
 /*
  * a wrapper to feature call for compatibility
  */
-#if defined(CONFIG_PM)  defined(CONFIG_PMAC_PBOOK)
 static void snd_pmac_sound_feature(pmac_t *chip, int enable)
 {
-#ifdef CONFIG_PPC_HAS_FEATURE_CALLS
ppc_md.feature_call(PMAC_FTR_SOUND_CHIP_ENABLE, chip-node, 0, enable);
-#else
-   if (chip-is_pbook_G3) {
-   pmu_suspend();
-   feature_clear(chip-node, FEATURE_Sound_power);
-   feature_clear(chip-node, 

Re: [PATCH] bootmem.c clean up bad pfn convertions

2005-04-11 Thread Franck Bui-Huu
Dave Hansen wrote:
The only arch with phys_to_pfn() defined is UML, so the patch simply
won't compile anything but UML on current kernels (unless I'm missing
something).
 

oops, I forgot to send the part of the patch that defines these macros, 
sorry.

Could you try to give us a more complete description of your problem?  I
know your memory doesn't start at 0x0, but what problems does that
cause?  Does the mem_map[] allocation blow up, etc...  
 

yes, it actually intends to solve that.
If it's just mem_map[], That calculation could be fixed pretty easily.
Something like
+#ifdef CONFIG_CRAZY_MIPS_FOO_MEM_MAP_START... 
+extern unsigned long mem_map_start_pfn
+#else
+#define mem_map_start_pfn 0UL
+#endif
-#define pfn_to_page(pfn)(mem_map + (pfn))
+#define pfn_to_page(pfn)(mem_map + (pfn) - mem_map_start_pfn)

 

This is another solution indeed...But you will have to define another 
constant which
will be used for virtual to physical address convertion. In my case I have

#define phys_to_pfn(x)(((x) - PHYS_START)  PAGE_SHIFT)
#define pa(x)   ((x) - PAGE_OFFSET + PHYS_START)
and pfn_to_page stays untouch.
But I expect your solution easier to implement since as you said 
previously no arch
defines phys_to_pfn.

Thanks
 Franck.
---
Come to visit Innova Card at CTST (Las Vegas, April 11-14, 2005) on booth 559 
and Cards Asia (Singapore, April 27-29, 2005) on booth 4A04 !

links:
- www.ctst.com
- www.worldofcards.biz/2005/cardsa_SG/
---
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and delete
this e-mail from your system.
Innova Card will not therefore be liable for the message if modified.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


RE: [PATCH] Priority Lists for the RT mutex

2005-04-11 Thread Perez-Gonzalez, Inaky
From: Ingo Molnar [mailto:[EMAIL PROTECTED]


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

I am finishing breaking it up in small bits so you can take a look
at it. Should be finished tomorrow noon (PST).

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

Yep. It is kind of easy to do (at least in fusyns)--it is just a
matter of setting the priority of the lock, that sets the priority
of its list node.

Because the promotion code only cares about the priority of the
list node, it blends automatically in the whole scheme. The PI
code will modify the list node's priority while promoting all the
tasks affected in the ownership chain, only when the fulocks/mutexes
are PI. The PP code will modify the priority of the fulock/mutex's
list node with an special call. 

[you can check for my 2004 OLS paper for a deeper explanation, or
I can extend this one, if you want]. 

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

Nope it doesn't. As I said, it is done in such a way that no 
modifications are needed.

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

Not really. Deadlock check is needed on PI, so it can be done at the
same time (you have to walk the chain anyway). In any other case, it
is an option you can request (or not).

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


Re: question about execve()

2005-04-11 Thread Tommy Reynolds
Uttered Tomko [EMAIL PROTECTED], spake thus:

 I would like to ask when a userprogram called in user space called 
 execve(/bin/abc   will  this system call finally copy the code of 
 /bin/abc into kernel space before kernel runs it or just leave the code 
 in the userspace and run directly ? 

None of these.  All execve really does is to discard the current VM
setup, tell the VM system to attach this process to the new
executable image, and then transfer control to the starting
instruction of the program.  Since nothing is really in memory, aside
from maybe some caching/readahead, page faults do all the work of
loading application code, page by page, on demand.

HTH


pgpmkcDEN8WDp.pgp
Description: PGP signature


Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

2005-04-11 Thread Florian Weimer
* Ingo Molnar:

 is there any fundamental problem with going with v2 right now, and then 
 once v3 is out and assuming it looks ok, all newly copyrightable bits 
 (new files, rewrites, substantial contributions, etc.) get a v3 
 copyright? (and the collection itself would be v3 too) That method 
 wouldnt make it fully v3 automatically once v3 is out, but with time 
 there would be enough v3 bits in it to make it essentially v3.

Almost certainly, v3 will be incompatible with v2 because it adds
further restrictions.  This means that your proposal would result in
software which is not redistributable by third parties.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Priority Lists for the RT mutex

2005-04-11 Thread Ingo Molnar

* Perez-Gonzalez, Inaky [EMAIL PROTECTED] wrote:

 OTOH, deadlock detection is another issue. It's quite expensive and i'm
 not sure we want to make it a runtime thing. But for fusyn's deadlock
 detection and safe teardown on owner-exit is a must-have i suspect?
 
 Not really. Deadlock check is needed on PI, so it can be done at the 
 same time (you have to walk the chain anyway). In any other case, it 
 is an option you can request (or not).

well, i was talking about the mutex code in PREEMPT_RT. There deadlock 
detection is an optional debug feature. You dont _have_ to do deadlock 
detection for the kernel's locks, and there's a difference in 
performance.

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


Re: [ANNOUNCE] git-pasky-0.2

2005-04-11 Thread Ingo Molnar

* Petr Baudis [EMAIL PROTECTED] wrote:

   Hello,
 
   here goes git-pasky-0.2, my set of patches and scripts upon Linus' 
 git, aimed at human usability and to an extent a SCM-like usage.

works fine on FC4, i only minor issues: 'git' in the tarball didnt have 
the x permission. Also, your scripts assume they are in $PATH. When 
trying out a tarball one doesnt usually do a 'make install' but tries 
stuff locally. Also, 'make install' doesnt seem to install the git 
script itself, is that intentional?

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


RE: [PATCH] Priority Lists for the RT mutex

2005-04-11 Thread Perez-Gonzalez, Inaky
From: Ingo Molnar [mailto:[EMAIL PROTECTED]

* Perez-Gonzalez, Inaky [EMAIL PROTECTED] wrote:

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

 Not really. Deadlock check is needed on PI, so it can be done at the
 same time (you have to walk the chain anyway). In any other case, it
 is an option you can request (or not).

well, i was talking about the mutex code in PREEMPT_RT. There deadlock
detection is an optional debug feature. You dont _have_ to do deadlock
detection for the kernel's locks, and there's a difference in
performance.

Big mouth'o mine :-| 

Let me re-phrase then: it is a must have only on PI, to make sure 
you don't have a loop when doing it. Maybe is a consequence of the
algorithm I chose. -However- it should be possible to disable it
in cases where you are reasonably sure it won't happen (such as
kernel code). In any case, AFAIR, I still did not implement it.

Was this more useful?

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


Re: 2.6.12-rc2-mm3

2005-04-11 Thread J.A. Magallon

On 04.11, Andrew Morton wrote:
 
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
 
 

Is this not needed anymore ?

--- 25/arch/i386/kernel/entry.S~nmi_stack_correct-fix   2005-04-05 
00:02:48.0 -0700
+++ 25-akpm/arch/i386/kernel/entry.S2005-04-05 00:02:48.0 -0700
@@ -178,9 +178,9 @@ ENTRY(resume_kernel)
 need_resched:
movl TI_flags(%ebp), %ecx   # need_resched set ?
testb $_TIF_NEED_RESCHED, %cl
-   jz restore_all
+   jz restore_nocheck
testl $IF_MASK,EFLAGS(%esp) # interrupts off (exception path) ?
-   jz restore_all
+   jz restore_nocheck
call preempt_schedule_irq
jmp need_resched
 #endif
@@ -587,7 +587,7 @@ nmi_stack_correct:
xorl %edx,%edx  # zero error code
movl %esp,%eax  # pt_regs pointer
call do_nmi
-   jmp restore_all
+   jmp restore_nocheck
 
 nmi_stack_fixup:
FIX_STACK(12,nmi_stack_correct, 1)

--
J.A. Magallon jamagallon()able!es \   Software is like sex:
werewolf!able!es \ It's better when it's free
Mandrakelinux release 10.2 (Limited Edition 2005) for i586
Linux 2.6.11-jam12 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)) #1


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


Re: [PATCH] Priority Lists for the RT mutex

2005-04-11 Thread Ingo Molnar

* Perez-Gonzalez, Inaky [EMAIL PROTECTED] wrote:

 Let me re-phrase then: it is a must have only on PI, to make sure you 
 don't have a loop when doing it. Maybe is a consequence of the 
 algorithm I chose. -However- it should be possible to disable it in 
 cases where you are reasonably sure it won't happen (such as kernel 
 code). In any case, AFAIR, I still did not implement it.

are there cases where userspace wants to disable deadlock-detection for 
its own locks?

the deadlock detector in PREEMPT_RT is pretty much specialized for 
debugging (it does all sorts of weird locking tricks to get the first 
deadlock out, and to really report it on the console), but it ought to 
be possible to make it usable for userspace-controlled locks as well.

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


RE: [PATCH] Priority Lists for the RT mutex

2005-04-11 Thread Perez-Gonzalez, Inaky
From: Ingo Molnar [mailto:[EMAIL PROTECTED]

* Perez-Gonzalez, Inaky [EMAIL PROTECTED] wrote:

 Let me re-phrase then: it is a must have only on PI, to make sure you
 don't have a loop when doing it. Maybe is a consequence of the
 algorithm I chose. -However- it should be possible to disable it in
 cases where you are reasonably sure it won't happen (such as kernel
 code). In any case, AFAIR, I still did not implement it.

are there cases where userspace wants to disable deadlock-detection for
its own locks?

I would guess--if I know I have coded my application properly
(cough) or I am using locks that by design are completely orthogonal,
I would say deadlock checking is getting in the way.

the deadlock detector in PREEMPT_RT is pretty much specialized for
debugging (it does all sorts of weird locking tricks to get the first
deadlock out, and to really report it on the console), but it ought to
be possible to make it usable for userspace-controlled locks as well.

fusyn's is as simple as it can get: when you are about to lock(), it
checks that you don't own the lock already, but it generalizes it
(it checks that the owner of the lock is not waiting for a lock 
whose owner is waiting for a lock whose owner...is waiting for a lock
that you own).

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


Re: Light Scribe Technology

2005-04-11 Thread Mark Watts
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


 Can you tell me if there is currently support in the
 kernel for HP's new LightScribe technology?
 (http://h30015.www3.hp.com/hp_dec/lightscribe/index_FL.asp).
 If there is not, are there plans for it?

 Supposdly, you can burn DVD's or CD's, then flip the
 media over and burn a label directly onto the CD or
 DVD (no ink or toner...the laser burns it directly
 onto the CD)


Didn't Yamaha have something like this with their [EMAIL PROTECTED] (tatoo) 
drives?
IIRC it was supported in cdrecord without needing kernel support...

Mark.

- -- 
Mark Watts
Senior Systems Engineer
QinetiQ Trusted Information Management
Trusted Solutions and Services Group
GPG Public Key ID: 455420ED

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCWj2hBn4EFUVUIO0RAtN2AKCh5nheB/T8mECxtg9gPMUYiiHvqgCguHyO
RtyisdPmV3SZPishnarux+Y=
=9v9V
-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/


smbfs: lseek returns EINVAL when using large files.

2005-04-11 Thread Mathieu Fluhr
Hello

It seems that the smbfs driver does not handle correctly large files
(2GB). The thing is that statting them is correct (for example, the
st_size field is correctly set), but as soon as you try to make a lseek
with an offset larget than INT_MAX, you get a EINVAL error.

Note: This is not coming out of the remote samba server (Tested with
under windows, and it is working fine).

I'm using a 2.6.10 kernel without external patches. I parsed the 2.6.11
changelog to see if this problem has been fixed, but I didn't found
anything related. If this has already been discussed, just let me
know ;-)

You can reproduce this bug with this little program:

-8--

/* Enable large file support for x86 */
#define _FILE_OFFSET_BITS 64

#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
#include limits.h
#include stdio.h

int main(int argc, char **argv)
{
  int fd = open(argv[1], O_RDONLY);
  if(fd == -1)
perror(open);

  struct stat st;
  fstat(fd, st);

  printf(filesize: %llu\n, st.st_size);

  /* Go at end... */
  if(lseek(fd, 0, SEEK_END) == (off_t)(-1))
perror(lseek);

  close(fd);
  return 0;
}

-8--

Best Regards,
Mathieu Fluhr


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


Re: smbfs: lseek returns EINVAL when using large files.

2005-04-11 Thread Arjan van de Ven
On Mon, 2005-04-11 at 11:07 +0200, Mathieu Fluhr wrote:
 Hello
 
 It seems that the smbfs driver does not handle correctly large files
 (2GB). The thing is that statting them is correct (for example, the
 st_size field is correctly set), but as soon as you try to make a lseek
 with an offset larget than INT_MAX, you get a EINVAL error.


have you tried the cifs client, which is new in 2.6 and is the more
actively maintained way to access windows shares and samba ?


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


Re: more git updates..

2005-04-11 Thread Anton Altaparmakov
On Mon, 2005-04-11 at 01:04 +0200, Bernd Eckenfels wrote:
 In article [EMAIL PROTECTED] you wrote:
  (I repeat the xxx in the leaf name - easier to code.)
 
 It is a bit OT, but just a note: there are file systems (hash functions) out
 there who dont like a lot of files named the same way. For example NTFS with
 the 8.3 short names.

Since you mention NTFS, there is no need to worry about that for Linux.
Certainly the Linux kernel NTFS driver is never going to create 8.3
short names.  (It doesn't create names at all at the moment but my grand
plan is that it will only ever create file names in the Win32 and/or
POSIX name spaces.  The DOS name space is a thing of the past IMO.)

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: 2.6.12-rc2-mm3

2005-04-11 Thread Andrew Morton

(Please do reply-to-all)

J.A. Magallon [EMAIL PROTECTED] wrote:

 On 04.11, Andrew Morton wrote:
   
   
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/
   
   
 
  Is this not needed anymore ?
 
  --- 25/arch/i386/kernel/entry.S~nmi_stack_correct-fix2005-04-05 
 00:02:48.0 -0700
  +++ 25-akpm/arch/i386/kernel/entry.S 2005-04-05 00:02:48.0 -0700

Hopefully not. fix-crash-in-entrys-restore_all.patch works around the problem.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] I2C rtc8564.c remove duplicate include (whitespace fixed)

2005-04-11 Thread Clemens Koller
[PATCH] I2C rtc8564.c remove duplicate include
Trivial fix: removes duplicate include line.
Patch applies to: 2.6.11.x
(This is my very first patch to the linux-kernel, so let me
start with small things first...)
Signed-off-by: Clemens Koller [EMAIL PROTECTED]
---
diff -Nur --exclude-from=dontdiff-osdl linux-2.6.11.6-clean/drivers/i2c/chips/rtc8564.c linux-2.6.11.6/drivers/i2c/chips/rtc8564.c
--- linux-2.6.11.6-clean/drivers/i2c/chips/rtc8564.c	2005-03-26 04:28:14.0 +0100
+++ linux-2.6.11.6/drivers/i2c/chips/rtc8564.c	2005-04-04 12:37:05.0 +0200
@@ -19,7 +19,6 @@
 #include linux/string.h
 #include linux/rtc.h		/* get the user-level API */
 #include linux/init.h
-#include linux/init.h
 
 #include rtc8564.h
 


Re: Processes stuck on D state on Dual Opteron

2005-04-11 Thread Nick Piggin
Claudio Martins wrote:
On Sunday 10 April 2005 03:47, Andrew Morton wrote:
Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from
cutting in during long sysrq traces.
Also, capture the `sysrq-m' output so we can see if the thing is out of
memory.

  Hi Andrew,
  Thanks for the tip. I booted with nmi_watchdog=0 and was able to get a full 
sysrq-t as well as a sysrq-m. Since it might be a little too big for the 
list, I've put it on a text file at:

 http://193.136.132.235/dl145/dump1-2.6.12-rc2.txt
OK, you _may_ be out of memory here (depending on what the lower zone
protection for DMA ends up as), however you are well above all the
emergency watermarks in ZONE_NORMAL. Also:
 I also made a run with the mempool-can-fail patch from Nick Piggin. With this 
I got some nice memory allocation errors from the md threads when the trouble 
started. The dump (with sysrq-t and sysrq-m included) is at:

 http://193.136.132.235/dl145/dump2-2.6.12-rc2-nick1.txt
This one shows plenty of memory. The allocation failure messages are
actually a good thing, and show that my patch is sort of working. I
have reworked it a bit so they won't show up though.
So probably not your common or garden memory deadlock.
The common theme seems to be: try_to_free_pages, swap_writepage,
mempool_alloc, down/down_failed in .text.lock.md. Next I would suspect
md/raid1 - maybe some deadlock in an uncommon memory allocation
failure path?
I'll see if I can reproduce it here.
--
SUSE Labs, Novell 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: [PATCH encrypted swsusp 0/3] encrypted swsusp image

2005-04-11 Thread Pavel Machek
Hi!

  The following patches allow for encryption of the on-disk swsusp image
  to prevent data gathering of e.g. in-kernel keys or mlocked data after
  resume.
  For this purpose the aes cipher must be compiled into the kernel as
  module load is not possible at resume time.
  A random key is generated at suspend time, stored in the suspend header
  on disk and deleted from the header at resume time. If you don't resume
  a mkswap on the suspend partition will also delete the temporary key.
  Only the data pages are encrypted as only these may contain sensitive data.
  This works on my x86_64 laptop (64bit mode) and probably needs testing
  on other platforms.
 
 What about an option for an user-defined key? One that can be set when
 suspending?

That's logical next step, but lets try to solve one problem at a time.

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


Re: [PATCH] zero disk pages used by swsusp on resume

2005-04-11 Thread Pavel Machek
Hi!

  Encrypting swsusp image is of course even better, because you don't
  have to write large ammounts of zeros to your disks during resume ;-).
 
 How does zeroing help if they steal the laptop?  The data is there, they
 can just pull the hard disk out and mirror it before they boot.
 
 The only way to improve security here is to encrypt it.  Zeroing will
 help some if they compromise root later, but I doubt that's really worth
 it considering you're screwed after a root compromise anyway.

Yes, it helps. It also helps if they steal your laptop later. And we
are switching to encryption, anyway, because it should be faster.
Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH 0/5] autoparam

2005-04-11 Thread Magnus Damm
On 4/9/05, Domen Puncer [EMAIL PROTECTED] wrote:
 On 21/03/05 00:06 +0100, Magnus Damm wrote:
  Here are a set of patches that makes it possible to autogenerate kernel 
  command
  line documentation from the source code. The approach is rather 
  straightforward
  - the parameter name, the type and the description are stored in a section
  called __param_strings. After vmlinux is built this section is extracted 
  using
  objcopy and a script is used to generate a primitive - but up to date -
  document.
 
 I think it's a great idea. A needed feature with simple implementation.
 I like it.

Thanks! And together with the disable built-in patch we have a much
more user-friendly system...

  Right now the section is left in the kernel binary. The document is 
  currently
  not generated from the Makefile, so the curious user should perform:
 
 Any plans to make this a complete patch?

Yes, if there is enough interest. I think autogenerating documents
from source code is the right way to do it, but I am not sure about
the disadvantages. Maybe someone could enlighten me? The latest patch
does not support obsolete MODULE_PARM() parameters - so I need to add
that to next release but that is no biggie.

  $ objcopy -j __param_strings vmlinux -O binary foo
  $ chmod a+x scripts/section2text.rb
  $ cat foo | ./scripts/section2text.rb
 
  And yeah, you need to install ruby to run the script.
 
 Attached a perl script, that has almost the same output. (I think
 perl is more usual on linux machines)

Great, thanks! I prefer to do prototype hacking in ruby, but I realize
that the magic duct tape language is more suitable.. =)

Also, I am thinking of using a prefix with the parameter type to
determine the origin of the parameter, ie:

prefix s: means from __setup()
prefix e: means from early_param()
prefix m: means from module_param()
prefix o: means from obsolete MODULE_PARM()

Then I would like to let the script convert the types to a common set of types.
I thought about treating descriptions without parameters as errors,
and generate warnings about parameters without description. And to
reduce the amount of warnings I think it is a good idea to add a
SETUP_DESC() as suggested by Matt Domsch.

  The ruby script section2text.rb does some checks to see if 
  MODULE_PARM_DESC()
  is used without module_param(). You will find interesting typos.
 
  Future work that extends this idea could include replacing __setup(name) 
  with
  __setup(name, descr). And storing the documentation somewhere to make it 
  easy
  for the end user to look up the generated parameter list from the boot 
  loader.
 
 And kernel-parameters.txt will never again have obsoleted options :-)

Exactly! =)

/magnus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] Kprobes: Multiple probes feature at given address

2005-04-11 Thread Prasanna S Panchamukhi
Thanks Maneesh for your comments. Please find
the patch below.

 [..]
  Assumption : If a user has already inserted a probe using old 
  register_kprobe()
  routine, and later wants to insert another probe at the same address using
  register_multiprobe() routine, then register_multiprobe() will return 
  EEXIST.
  This can be avoided by renaming the interface routines.
  
 I am not sure if systemTap can tolerate this resitriction.
 

Basically lets understand that there are two sets of users
1. One set wants to use the older register_kprobe() interface
and dont want multiprobe complexities.

2. Second set of users want multiprobes (such as systemtap).

By adding two new interface to insert multiprobe should help both
the types of users. And now the new interface in this patch
also accepts the same datatype ie struct kprobe *. Just by
writting the wrappers around these interfaces will help the 
systemtap. I have modified this patch as per your comments.


 I think it should not exit here without un-registering any thing if temp
 is an active_probe. Instead, it should parse the ap-head to look
 for the desired multiprobe to unregsiter.
 

Let the user take care about this.


 -EEXIST doesnot seem to be a proper error code here. When temp is NULL that 
 means, there is no such kprobe.

modified in the new patch.

Please let me know if you have any issues.

Thanks
Prasanna




Here is an attempt to provide multiple handlers feature as an addon patch over
the existing kprobes infrastructure without even changing existing kprobes
infrastructure. The design goal is to provide a simple, compact multiprobe
feature without even changing a single line of existing kprobes. This patch 
introduces two new interface:

register_multiprobe(struct kprobe *p); and
unregister_multiprobe(struct kprobe *p);

register_multiprobe(struct kprobe *p):
User has to allocate kprobe (defined in kprobes.h) and pass the pointer to 
register_multiprobe();
This routine does some housekeeping by storing reference to individual handlers
and registering kprobes with common handler if the user requests for the first 
time at a given address. On subsequenct calls to insert probes on the same 
address, this routines just adds the individual handlers to the hhlist 
(struct kprobe) without registering the kprobes.
unregister_multiprobe(struct kprobe *p):
User has to pass the kprobe pointer to unregister. This routine just checks
if he is the only active user and calls unregister kprobes. If there are more 
active users, it just removes the individual handlers inserted by this user 
from the hhlist.

Advantages :
1. Layered architecture, need not worry about underlying stuff.
2. Its simple and compact.
3. Wrapper routines can be written over new and existing interface
to handle interface naming issue.
4. It works without even changing a single line of existing
kprobes code.

Assumption : If a user has already inserted a probe using old
register_kprobe()
routine, and later wants to insert another probe at the same address using
register_multiprobe() routine, then register_multiprobe() will return EEXIST.
This can be avoided by renaming the interface routines.

Signed-off-by: Prasanna S Panchamukhi [EMAIL PROTECTED]


---

 linux-2.6.12-rc2-prasanna/include/linux/kprobes.h |   26 +++
 linux-2.6.12-rc2-prasanna/kernel/kprobes.c|  152 ++
 2 files changed, 178 insertions(+)

diff -puN kernel/kprobes.c~kprobes-layered-multiple-handlers kernel/kprobes.c
--- linux-2.6.12-rc2/kernel/kprobes.c~kprobes-layered-multiple-handlers 
2005-04-11 13:52:52.0 +0530
+++ linux-2.6.12-rc2-prasanna/kernel/kprobes.c  2005-04-11 13:57:55.0 
+0530
@@ -27,6 +27,9 @@
  * interface to access function arguments.
  * 2004-SepPrasanna S Panchamukhi [EMAIL PROTECTED] Changed Kprobes
  * exceptions notifier to be first on the priority list.
+ * 2005-April  Prasanna S Panchamukhi [EMAIL PROTECTED] Added multiple
+ * handlers feature as an addon interface over existing kprobes
+ * interface.
  */
 #include linux/kprobes.h
 #include linux/spinlock.h
@@ -116,6 +119,153 @@ void unregister_kprobe(struct kprobe *p)
spin_unlock_irqrestore(kprobe_lock, flags);
 }
 
+
+/* common kprobes pre handler that gets control when the registered probe
+ * gets fired. This routines is wrapper over the inserted multiple handlers
+ * at a given address and calls individual handlers.
+ */
+int comm_pre_handler(struct kprobe *p, struct pt_regs *regs)
+{
+   struct active_probe *ap;
+   struct hlist_node *node;
+   struct hlist_head *head;
+
+   ap = container_of(p, struct active_probe, comm_probe);
+   head = ap-head;
+   hlist_for_each(node, head) {
+   struct kprobe *kp = hlist_entry(node, struct kprobe , hhlist);
+   if (kp-pre_handler)
+   kp-pre_handler(kp, regs);
+   }
+   

Re: Re: [ANNOUNCE] git-pasky-0.2

2005-04-11 Thread Petr Baudis
Dear diary, on Mon, Apr 11, 2005 at 04:46:42AM CEST, I got a letter
where Daniel Barkalow [EMAIL PROTECTED] told me that...
 On Mon, 11 Apr 2005, Petr Baudis wrote:
 
Hello,
  
here goes git-pasky-0.2, my set of patches and scripts upon
  Linus' git, aimed at human usability and to an extent a SCM-like usage.
 
 Incidentally, the git-pasky-base tarball you have up has its checked-out
 tree partway between 0.1 and 0.2, and doesn't compile. (The included HEAD
 version in .dircache is fine, if the user has some way to bootstrap)

Oops, I'm sorry. It appears some diffs just slipped out from the tracked
tree, perhaps I was pulling once when git diff was broken and I didn't
notice it. Now there is a newer tarball there, it is not a pure 0.2
anymore though - if you use the COMMITTER_* env variables, they are now
AUTHOR_*.

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


Re: Re: [ANNOUNCE] git-pasky-0.2

2005-04-11 Thread Petr Baudis
Dear diary, on Mon, Apr 11, 2005 at 10:50:51AM CEST, I got a letter
where Ingo Molnar [EMAIL PROTECTED] told me that...
 
 * Petr Baudis [EMAIL PROTECTED] wrote:
 
Hello,
  
here goes git-pasky-0.2, my set of patches and scripts upon Linus' 
  git, aimed at human usability and to an extent a SCM-like usage.
 
 works fine on FC4, i only minor issues: 'git' in the tarball didnt have 
 the x permission.

Sorry, fixed in the tarball. It is in the diffs but I have no git patch
yet to apply the mode changes.

 Also, your scripts assume they are in $PATH.  When 
 trying out a tarball one doesnt usually do a 'make install' but tries
 stuff locally.

Hmm, I think I will need to make something like

exedir=$(dirname $0)

on the top of each script and then do all the git calls with ${exedit}
prepended. That should fix the issue, right?

 Also, 'make install' doesnt seem to install the git script itself, is
 that intentional?

Oops, I actually didn't even notice that there _is_ any install target
in the Makefile already. ;-) I will add the relevant stuff to it.

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


Re: [PATCH encrypted swsusp 1/3] core functionality

2005-04-11 Thread Pavel Machek
Hi!

 The following patch adds the core functionality for the encrypted
 suspend image.

[Please inline patches, it makes it easier to comment on them.]

You seem to reuse same key/iv for all the blocks. I'm no crypto
expert, but I think that is seriously wrong... You probably should use
block number as a IV or something like that.

Does it slow down swsusp in measurable way, or is it just lost in the
noise?
Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.12-rc2-mm3

2005-04-11 Thread Jan Dittmer
Andrew Morton wrote:
bk-cifs.patch
This breaks the build on mips, ppc64, sparc, sparc64 with the
following error (defconfig, compared to mm2):
  CC [M]  fs/cifs/misc.o
fs/cifs/misc.c: In function `cifs_convertUCSpath':
fs/cifs/misc.c:546: error: case label does not reduce to an integer constant
fs/cifs/misc.c:549: error: case label does not reduce to an integer constant
fs/cifs/misc.c:552: error: case label does not reduce to an integer constant
fs/cifs/misc.c:561: error: case label does not reduce to an integer constant
fs/cifs/misc.c:564: error: case label does not reduce to an integer constant
fs/cifs/misc.c:567: error: case label does not reduce to an integer constant
make[2]: *** [fs/cifs/misc.o] Error 1
make[1]: *** [fs/cifs] Error 2
make: *** [fs] Error 2
See http://l4x.org/k for details.
Jan
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 encrypted swsusp 1/3] core functionality

2005-04-11 Thread folkert
  The following patch adds the core functionality for the encrypted
  suspend image.
 [Please inline patches, it makes it easier to comment on them.]
 You seem to reuse same key/iv for all the blocks. I'm no crypto
 expert, but I think that is seriously wrong... You probably should use
 block number as a IV or something like that.

Or use a feedback loop: xor your data with the outcome of the previous
round. And for the initial block use 0x00...00 for 'previous block'-
value.


Folkert van Heusden

Auto te koop, zie: http://www.vanheusden.com/daihatsu.php
Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden.

 UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) 
 a try, it brings monitoring logfiles to a different level! See 
 http://vanheusden.com/multitail/features.html for a feature-list.  

Phone: +31-6-41278122, PGP-key: 1F28D8AE
Get your PGP/GPG key signed at www.biglumber.com!


signature.asc
Description: Digital signature


Re: [PATCH] zero disk pages used by swsusp on resume

2005-04-11 Thread Oliver Neukum
Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:
 Hi!
 
   Oliver Neukum wrote:
What is the point in doing so after they've rested on the disk for ages?
   
   The point is not physical access to the disk but data gathering after
   resume or reboot.
  
  After resume or reboot normal access control mechanisms will work
  again. Those who can read a swap partition under normal circumstances
  can also read /dev/kmem. It seems to me like you are putting an extra
  lock on a window on the third floor while leaving the front door open.
 
 Andreas is right, his patches are needed.
 
 Currently, if your laptop is stolen after resume, they can still data
 in swsusp image.
 
 Zeroing the swsusp pages helps a lot here, because at least they are
 not getting swsusp image data without heavy tools. [Or think root
 compromise month after you used swsusp.]
 
 Encrypting swsusp image is of course even better, because you don't
 have to write large ammounts of zeros to your disks during resume ;-).

Not only is it better, it completely supercedes wiping the image.
Your laptop being stolen after resume is very much a corner case.
You suspend your laptop while you are not around, don't you?

Additionally it helps only if you cannot trigger another swsusp, eg by
running dry the batteries.

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


BUG in RT 45-01 when RT program dumps core

2005-04-11 Thread kus Kusche Klaus
When a process running with RT priority dumps core,
I get the following BUG:

Apr 11 13:44:23 OF455 kern.err kernel: BUG: rtc2:833 RT task
yield()-ing!
Apr 11 13:44:23 OF455 kern.warn kernel:  [c026dad1] yield+0x61/0x70
(8)
Apr 11 13:44:23 OF455 kern.warn kernel:  [c0151e49]
coredump_wait+0x79/0xc0 (20)
Apr 11 13:44:23 OF455 kern.warn kernel:  [c0151f83]
do_coredump+0xf3/0x200 (92)
Apr 11 13:44:23 OF455 kern.warn kernel:  [c0136789]
kmem_cache_free+0x49/0x120 (32)
Apr 11 13:44:23 OF455 kern.warn kernel:  [c012abdb]
atomic_dec_and_spin_lock+0x3b/0x50 (24)
Apr 11 13:44:23 OF455 kern.warn kernel:  [c011c9a5]
__dequeue_signal+0x105/0x160 (20)
Apr 11 13:44:23 OF455 kern.warn kernel:  [c011e734]
get_signal_to_deliver+0x334/0x350 (48)
Apr 11 13:44:23 OF455 kern.warn kernel:  [c01027f8]
do_signal+0x98/0x180 (44)
Apr 11 13:44:23 OF455 kern.warn kernel:  [c0106b56]
timer_interrupt+0x46/0x70 (108)
Apr 11 13:44:23 OF455 kern.warn kernel:  [c012c9eb]
handle_IRQ_event+0x5b/0xe0 (8)
Apr 11 13:44:23 OF455 kern.warn kernel:  [c012cba1]
__do_IRQ+0x111/0x190 (48)
Apr 11 13:44:23 OF455 kern.warn kernel:  [c010d590]
do_page_fault+0x0/0x530 (16)
Apr 11 13:44:23 OF455 kern.warn kernel:  [c0102917]
do_notify_resume+0x37/0x3c (8)
Apr 11 13:44:23 OF455 kern.warn kernel:  [c0102ae6]
work_notifysig+0x13/0x15 (8)



Klaus Kusche
 Entwicklung Software - Steuerung
 Software Development - Control
 
 KEBA AG
 A-4041 Linz
 Gewerbepark Urfahr
 Tel +43 / 732 / 7090-3120
 Fax +43 / 732 / 7090-6301
 E-Mail: [EMAIL PROTECTED]
 www.keba.com
 
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2005-04-11 Thread Thomas Graf
* Evgeniy Polyakov [EMAIL PROTECTED] 2005-04-11 09:22
 On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED]) 
 wrote:
  +   size = NLMSG_SPACE(sizeof(*msg) + msg-len);
  +
  +   skb = alloc_skb(size, GFP_ATOMIC);
  +   if (!skb) {
  +   printk(KERN_ERR Failed to allocate new skb with 
  size=%u.\n, size);
  +   return;
  +   }
  +
  +   nlh = NLMSG_PUT(skb, 0, msg-seq, NLMSG_DONE, size - sizeof(*nlh));
  
  This is not correct, what happens is:
  size = NLMSG_SPACE(sizeof(*msg) + msg-len);
   -- align(hdr)+align(data)
  size - sizeof(*nlh)
   -- (align(hdr)-hdr)+align(data)
  NLMSG_PUT pads again to get to the end of the data block (NLMSG_LENGTH)
   -- align(hdr)+(align(hdr)-hdr)+align(data)
  
  At the moment align(hdr) == hdr since nlmsghdr is already aligned
  but this might change and your code will break.
 
 As far as I remember, header is always supposed to be aligned properly
 by design, so it even could be nonaligned here.

No, have a look at the macros:

#define NLMSG_LENGTH(len) ((len)+NLMSG_ALIGN(sizeof(struct nlmsghdr)))
#define NLMSG_SPACE(len) NLMSG_ALIGN(NLMSG_LENGTH(len))

NLMSG_LENGTH points to the end of the payload in the message, NLMSG_SPACE
represents the total size aligned properly for a possible next multipart
message.

It is unlikely that nlmsghdr will ever be unaligned but there can be no
reason to introduce code that can break with perfectly legal changes just
because of that.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

2005-04-11 Thread Petr Baudis
Dear diary, on Mon, Apr 11, 2005 at 10:40:00AM CEST, I got a letter
where Florian Weimer [EMAIL PROTECTED] told me that...
 * Ingo Molnar:
 
  is there any fundamental problem with going with v2 right now, and then 
  once v3 is out and assuming it looks ok, all newly copyrightable bits 
  (new files, rewrites, substantial contributions, etc.) get a v3 
  copyright? (and the collection itself would be v3 too) That method 
  wouldnt make it fully v3 automatically once v3 is out, but with time 
  there would be enough v3 bits in it to make it essentially v3.
 
 Almost certainly, v3 will be incompatible with v2 because it adds
 further restrictions.  This means that your proposal would result in
 software which is not redistributable by third parties.

Hmm, what would be actually the point in introducing further
restrictions? Anyone who then wants to get around them will just
distribute the software with the any later version provision under
GPLv2, and GPLv3 will have no impact expect for new software with v3 or
any later version provision. What am I missing?

I've been doing a lot of LKML catching up, and I remember someone
suggesting using GPLv2 (for kernel, but should apply to git too), with a
provision to let someone trusted (Linus) decide when GPLv3 is out
whether you can use GPLv3 for the kernel too. Does it make sense? And is
it even legally doable without sending signed written documents to
Linus' tropical hacienda?

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


Re: Oops in swsusp

2005-04-11 Thread Pavel Machek
Hi!

 during testing of the encrypted swsusp_image on x86_64 I did get an Oops
 from time to time at memcpy+11 called from swsusp_save+1090 which turns
 out to be the memcpy in copy_data_pages() of swsusp.c.
 The Oops is caused by a NULL pointer (I don't remember if it was source
 or destination).
 This Oops seems to be unrelated to the encrypted image addition as I
 didn't touch any code in that area.

Could you still try to reproduce without any patches? Alocating memory
at wrong moment may cause something like that, and crypto routines
might do that.
Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 encrypted swsusp 1/3] core functionality

2005-04-11 Thread Pavel Machek
Hi!

   The following patch adds the core functionality for the encrypted
   suspend image.
  [Please inline patches, it makes it easier to comment on them.]
  You seem to reuse same key/iv for all the blocks. I'm no crypto
  expert, but I think that is seriously wrong... You probably should use
  block number as a IV or something like that.
 
 Or use a feedback loop: xor your data with the outcome of the previous
 round. And for the initial block use 0x00...00 for 'previous block'-
 value.

I'd like to retain ability to read suspend image in any order (so that
code can be reused for swap encryption, etc).
Pavel
-- 
Boycott Kodak -- for their patent abuse against Java.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 encrypted swsusp 1/3] core functionality

2005-04-11 Thread Pavel Machek
Hi!

 The following patch adds the core functionality for the encrypted
 suspend image.

+#ifdef CONFIG_SWSUSP_ENCRYPT
+static struct crypto_tfm *crypto_init(int mode)
+{
+   struct crypto_tfm *tfm;
+   int len;
+
+   tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+   if(!tfm) {
  ~ please put space between if and (

+   printk(KERN_ERR swsusp: no tfm, suspend not
possible\n);
+   return NULL;
+   }
+
+   if(sizeof(key)  crypto_tfm_alg_min_keysize(tfm)) {

same here.

Was it really neccessary to include union u? I don't like its name,
and perhaps few casts are better than this. If not, it probably should
go in separate patch, and ASAP.

Splitting it to code/kconfig/doc probably does not make much sense, it
is small enough, already.

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


Re: Problem in log_do_checkpoint()?

2005-04-11 Thread Jan Kara
 I get OOPs  in log_do_checkpoint() while using ext3 quotas.
 Is this anyway related to what you are working on ?
  Nope, it does not seem to be the same problem. In theory it could be a
bug Stephen fixed some time ago - could you try to reproduce the problem
with 2.6.12-rc2 (it contains the fix)? If you're still able to get the
oops, could you please find out where exactly in log_do_checkpoint() it
occured?

 
 Unable to handle kernel NULL pointer dereference at virtual address
 
  printing eip:
 801aeee1
 *pde = 52b31001
 Oops: 0002 [#1]
 PREEMPT SMP 
 Modules linked in:
 CPU:3
 EIP:0060:[801aeee1]Not tainted VLI
 EFLAGS: 00010213   (2.6.11-22) 
 EIP is at log_do_checkpoint+0x91/0x220
 eax: 0002   ebx: b7d09e0c   ecx: 0001   edx: e24a2000
 esi:    edi: c4bac47c   ebp: cceb726c   esp: e24a2d18
 ds: 007b   es: 007b   ss: 0068
 Process rm (pid: 8694, threadinfo=e24a2000 task=f7b79040)
 Stack: f7dc70e4 a1d60b3c e24a2d44 e24a2d3c e24a2d40 e24a2000 4df4
 a6062200 
f7dc70e4   95447db0 95447e4c ec6c1d7c b52210e4
 ec032b40 
ec032b0c 936a5800 e5a262b8 95447cac eb4c4354 936a57cc 936a5798
 ac0e93bc 
 Call Trace:
  [801ae94f] __log_wait_for_space+0x9f/0xc0
  [801a9b42] start_this_handle+0x132/0x3f0
  [8012f720] autoremove_wake_function+0x0/0x60
  [8012f720] autoremove_wake_function+0x0/0x60
  [801a9efd] journal_start+0xad/0xe0
  [801a68b1] ext3_dquot_initialize+0x51/0x70
  [801a2d0d] ext3_rmdir+0x4d/0x1c0
  [8031df76] _spin_lock+0x16/0x90
  [80168aa9] vfs_rmdir+0x189/0x230
  [80168be9] sys_rmdir+0x99/0xf0
  [8010272f] syscall_call+0x7/0xb
 Code: 8b 54 24 1c 89 5c 24 28 8b 40 04 89 44 24 18 8b 5a 28 8b 6b 2c 89
 df 8d 76 00 89 fb b8 01 00 00 00 8b 7f 28 8b 33 e8 cf 76 f6 ff f0 0f
 ba 2e 13 19 c0 85 c0 0f 85 3f 01 00 00 89 5c 24 04 8d 44 

Thanks for report
Honza

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


swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]

2005-04-11 Thread Pavel Machek
Hi!

   No, XFS is my root filesystem. :( (Now that I think about it, would
   modularizing XFS and using an initrd be OK?)
  
  Yes, loading xfs from initrd should help. [At least it did during
  suse9.3 testing.]
 
 Once I modularized xfs and switched to using an initrd, the problem
 disappeared.

I reproduced it locally. Problem is that xfsbufd goes refrigerated,
but someone still tries to wake it up *very* often. Probably something
else in xfs needs refrigerating, too, but I'm not a XFS wizard...

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


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

2005-04-11 Thread Evgeniy Polyakov
On Mon, 2005-04-11 at 12:45 +0200, Thomas Graf wrote:
 * Evgeniy Polyakov [EMAIL PROTECTED] 2005-04-11 09:22
  On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED]) 
  wrote:
   +   size = NLMSG_SPACE(sizeof(*msg) + msg-len);
   +
   +   skb = alloc_skb(size, GFP_ATOMIC);
   +   if (!skb) {
   +   printk(KERN_ERR Failed to allocate new skb with 
   size=%u.\n, size);
   +   return;
   +   }
   +
   +   nlh = NLMSG_PUT(skb, 0, msg-seq, NLMSG_DONE, size - 
   sizeof(*nlh));
   
   This is not correct, what happens is:
   size = NLMSG_SPACE(sizeof(*msg) + msg-len);
-- align(hdr)+align(data)
   size - sizeof(*nlh)
-- (align(hdr)-hdr)+align(data)
   NLMSG_PUT pads again to get to the end of the data block (NLMSG_LENGTH)
-- align(hdr)+(align(hdr)-hdr)+align(data)
   
   At the moment align(hdr) == hdr since nlmsghdr is already aligned
   but this might change and your code will break.
  
  As far as I remember, header is always supposed to be aligned properly
  by design, so it even could be nonaligned here.
 
 No, have a look at the macros:
 
 #define NLMSG_LENGTH(len) ((len)+NLMSG_ALIGN(sizeof(struct nlmsghdr)))
 #define NLMSG_SPACE(len) NLMSG_ALIGN(NLMSG_LENGTH(len))
 
 NLMSG_LENGTH points to the end of the payload in the message, NLMSG_SPACE
 represents the total size aligned properly for a possible next multipart
 message.
 
 It is unlikely that nlmsghdr will ever be unaligned but there can be no
 reason to introduce code that can break with perfectly legal changes just
 because of that.

But NLMSG_ALIGN(sizeof(hdr)) is always equal to sizeof(hdr), that size
was select not accidentally.

I will change it, no problem, it is good from aesthetic point of view.

-- 
Evgeniy Polyakov

Crash is better than data corruption -- Arthur Grabowski


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


Re: Problem in log_do_checkpoint()?

2005-04-11 Thread Jan Kara
  Hello,

 On Mon, 2005-04-04 at 10:04, Jan Kara wrote:
 
In log_do_checkpoint() we go through the t_checkpoint_list of a
  transaction and call __flush_buffer() on each buffer. Suppose there is
  just one buffer on the list and it is dirty. __flush_buffer() sees it and
  puts it to an array of buffers for flushing. Then the loop finishes,
  retry=0, drop_count=0, batch_count=1. So __flush_batch() is called - we
  drop all locks and sleep. While we are sleeping somebody else comes and
  makes the buffer dirty again (OK, that is not probable, but I think it
  could be possible). 
 
 Yes, there's no reason why not at that point.
 
  Now we wake up and call __cleanup_transaction().
  It's not able to do anything and returns 0.
 
 I think the _right_ answer here is to have two separate checkpoint
 lists: the current one, plus one for which the checkpoint write has
 already been submitted.  That way, we can wait for IO completion on
 submitted writes without (a) getting conned into doing multiple rewrites
 if there's somebody else dirtying the buffer; or (b) getting confused
 about how much progress we're making.  Buffers on the pre-write list get
 written; buffers on the post-write list get waited for; and both count
 as progress (eliminating the false assert-failure when we failed to
 detect progress).
  Yes, this seems to be a better long-term solution. A hotfix (retrying
after __flush_batch()) is attached if somebody is interested - it should
be safe and is lightly tested.

 The prevention of multiple writes in this case should also improve
 performance a little.
 
 That ought to be pretty straightforward, I think.  The existing cases
 where we remove buffers from a checkpoint shouldn't have to care about
 which list_head we're removing from; those cases already handle buffers
 in both states.  It's only when doing the flush/wait that we have to
 distinguish the two.
  Yes, AFAICS the changes should remain local to the checkpointing code
(plus __unlink_buffer()). Should I write the patch or will you?

Honza
-- 
Jan Kara [EMAIL PROTECTED]
SuSE CR Labs
Fix possible false assertion failure in JBD checkpointing code.

Signed-off-by: Jan Kara [EMAIL PROTECTED]

diff -rupX /home/jack/.kerndiffexclude linux-2.6.12-rc2/fs/jbd/checkpoint.c 
linux-2.6.12-rc2-checkpoint/fs/jbd/checkpoint.c
--- linux-2.6.12-rc2/fs/jbd/checkpoint.c2005-03-03 18:58:29.0 
+0100
+++ linux-2.6.12-rc2-checkpoint/fs/jbd/checkpoint.c 2005-04-05 
13:26:42.0 +0200
@@ -339,8 +339,10 @@ int log_do_checkpoint(journal_t *journal
}
} while (jh != last_jh  !retry);
 
-   if (batch_count)
+   if (batch_count) {
__flush_batch(journal, bhs, batch_count);
+   retry = 1;
+   }
 
/*
 * If someone cleaned up this transaction while we slept, we're


[rfc] git: combo-blobs

2005-04-11 Thread Ingo Molnar

i think all of the 'repository size' and 'bandwidth' concerns could be 
solved via a new (and pretty much simple and transparent) object type: 
the 'combo-blob'.

Summary:


This is a space/bandwidth-efficient blob that 'includes' arbitrary 
portions of (one, two, or more) simple blobs by reference [1], with byte 
granularity, plus an optional followup portion that includes the full 
constructed state, uncompressed. [2] It can also conserve more RAM 
compared to the current repository format.

Representation:
---

A combo-blob would have the 'simplest possible' and thus most obvious 
representation: a list (the 'include-table') of include X bytes at 
offset Y from parent Z operations:

  parent-blob-ID offset size
  [optional full constructed state]

e.g.:

  6d11b2dd7f169c29664ac0553090865b7b020973 0 6
  6d374c972c04a0b1894cc6898dffa8ab0b273fcb 0 100
  6d11b2dd7f169c29664ac0553090865b7b020973 64545 163656

'punches' 100 bytes out of blob 6d1* at offset 6, and replaces it 
with blob 6d3*'s 100 bytes. [offset/size would be stored in a binary 
form to have constant record sizes.]

in OS terms it's similar to an iovec representation. [3]

The hash of a combo-blob is calculated off the include-table alone: i.e.  
it's _not_ equivalent to the hash of the included contents. I.e. you 
cannot 'collapse' a combo-blob after the fact, it's an immutable part of
the history of the repository, similar to other stored objects. You can
freely cache/uncache (blow-up/collapse) it on the other hand.

[ NOTE: further below you can find a 'Notes' section as well, which
  might address some of the issues/ideas you might have at this point. ]

Cons:
-

there are a number of disadvantages:

- performance hit. Linus is perfectly right, in terms of performance, 
  nothing beats having full objects.

  Hence i kept the option to include the full constructed blob [4]
  (uncompressed) as well in the combo-blob. When all combo-blobs are
  'blown up' then they can be better in terms of performance than the 
  current repository format. [they still carry the small slice  dice
  information as well]

  the performance hit can be reduced in a finegrained way by introducing 
  occasional full objects in the history. E.g. after every 8 steps one
  would include a full blob, to limit the number of blobs necessary to
  construct a previously unconstructed combo-blob. This would still cut
  the overhead of the current format substantially.

  clearly, the most important cache is the current directory cache, 
  which this abstraction does not hurt.

- complexity. It's all pretty straightforward, but checking the
  consistency of a combo object is not as simple as checking the 
  consistency of a simple object, as it would have to recursively check 
  all parent IDs as well. I think it's worth the price though.

- repository has optional components: the 'blown up' (cached) portion of 
  a combo-blob can be freely destructed. This means that two 
  repositories can now not only differ in their directory-cache, but 
  also in their objects/ hierarchy. I dont think this is a big issue, 
  BYMMV.

Pros:
-

- the main advantage is space/bandwith: it's pretty much as efficient as 
  it gets: it can be used to represent compressed binary deltas. A fully 
  trimmed (uncached) repository is very efficient.

- the optional 'fully constructed' portion is not compressed, so once a
  repository is 'cached', it is faster to process (in areas outside the
  current directory cache) than the current repository format. (In fact,
  when a previously unused portion of a repository is accessed _first_, 
  it is IO-bound by nature - so we can very well spend the extra CPU
  cycles on uncompressing things.)

- a 'combo' blob will be more memory-efficient as well. So with given 
  amount of RAM one could access more history, with a small CPU cost - 
  as long as the level of 'history recursion' is kept in check (e.g. via 
  the previously mentioned 'at most 8-deep combinations').  
  Straightforward iovecs could be passed to Linux system-calls, when 
  constructing a 'view' of a file, without having to cache every step of 
  the file's history.

- a combo-blob directly represents the way humans code: combining 
  pre-existing pieces of information and adding relatively low amount of 
  new stuff. Having a natural representation for the type of activity 
  that a tool supports cannot hurt.

( - combo-blobs enable a per-chunk (or per-line) edit history. It's not
an important feature though.  )

Notes:
--

[1] the combo-blob is not a 'delta' thing. It combines pre-existing 
parents. One of the parents may of course be a 'delta' that acts upon 
the other parent - but the combo-blob does not know and does not care.  
(A combo-blob might as well represent an act of someone consolidating 
multiple small files into a big file, or splitting up a big file into 
smaller files. Or a combo-blob might represent the trimming of a 

Re: Problem in log_do_checkpoint()?

2005-04-11 Thread Stephen C. Tweedie
Hi,

On Fri, 2005-04-08 at 18:14, Badari Pulavarty wrote:
 I get OOPs  in log_do_checkpoint() while using ext3 quotas.
 Is this anyway related to what you are working on ?
 
 Unable to handle kernel NULL pointer dereference at virtual address
 

Doesn't look like it, no.  If we understand it right, Jan's problem
would only ever manifest itself as an assert failure, not as an oops.

--Stephen

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 encrypted swsusp 1/3] core functionality

2005-04-11 Thread folkert
The following patch adds the core functionality for the encrypted
suspend image.
   [Please inline patches, it makes it easier to comment on them.]
   You seem to reuse same key/iv for all the blocks. I'm no crypto
   expert, but I think that is seriously wrong... You probably should use
   block number as a IV or something like that.
  Or use a feedback loop: xor your data with the outcome of the previous
  round. And for the initial block use 0x00...00 for 'previous block'-
  value.
 I'd like to retain ability to read suspend image in any order (so that
 code can be reused for swap encryption, etc).

In that case: encrypt the blocknumber with the key, and then use the
outcome as IV for the encryption of the data. Or calculate a hash over the
blocknumber and use the outcome of that as IV. Don't use the blocknumer
directly.


Folkert van Heusden

Auto te koop, zie: http://www.vanheusden.com/daihatsu.php
Op zoek naar een IT of Finance baan? Mail me voor de mogelijkheden.

 UNIX admin? Then give MultiTail (http://vanheusden.com/multitail/) 
 a try, it brings monitoring logfiles to a different level! See 
 http://vanheusden.com/multitail/features.html for a feature-list.  

Phone: +31-6-41278122, PGP-key: 1F28D8AE
Get your PGP/GPG key signed at www.biglumber.com!


signature.asc
Description: Digital signature


RT 45-01: CF Card read: High latency?

2005-04-11 Thread kus Kusche Klaus
From the three sources of multi-millisecond latency in my experiments
(console messages to dead serial console, USB I/O, CF Card bulk read), 
I've analyzed one:

The latency of around 70 milliseconds in low-priority RT processes
when running a dd if=/dev/hda of=/dev/null in parallel (where hda
is a CF card) is due to readahead.

Two indications for that:
* Per default, maximum readahead is 128 KB. 70 ms is exactly the time
needed to transfer 128 KB 
(our CF cards have a sustained transfer rate of 1800 KB/sec).
* If the readahead constants in the kernel are changed,
the observed latencies scale almost linearly.

So obviously:
* The PIO mode IDE transfers keep the CPU 100 % busy.
* No other processes get scheduled between the data transfer of
individual sectors, i.e. there are no holes between the IDE 
interrupts.

However, there is no need to change the readahead mechanism,
because even the transfer of a single sector would exceed our
latency requirements. So we either need to switch to DMA (which we
can't in the short term), or run the time-critical tasks above IDE 
priority. 

So the question is, what exactly is the IDE priority?
Is the PIO transfer done in the IRQ handler or in a bh?

-- 
Klaus Kusche (Software Development - Control Systems)
KEBA AG Gewerbepark Urfahr, A-4041 Linz, Austria (Europe)
Tel: +43 / 732 / 7090-3120 Fax: +43 / 732 / 7090-6301
E-Mail: [EMAIL PROTECTED]WWW: www.keba.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: ext3 allocate-with-reservation latencies

2005-04-11 Thread Stephen C. Tweedie
Hi,

On Fri, 2005-04-08 at 19:10, Mingming Cao wrote:

  It still needs to be done under locking to prevent us from expanding
  over the next window, though.  And having to take and drop a spinlock a
  dozen times or more just to find out that there are no usable free
  blocks in the current block group is still expensive, even if we're not
  actually fully unlinking the window each time.

 Isn't this a rare case? The whole group is relatively full and the free
 bits are all reserved by other files.

Well, that's not much different from the case where there _are_ usable
bits but they are all near the end of the bitmap.  And that's common
enough as you fill up a block group with small files, for example.  Once
the bg becomes nearly full, new file opens-for-write will still try to
allocate in that bg (because that's where the inode was allocated), but
as it's a new fd we have no prior knowledge of _where_ in the bh to
allocate, and we'll have to walk it to the end to find any free space. 
This is the access pattern I'd expect of (for example) tar xvjf
linux-2.6.12.tar.bz2, not exactly a rare case.

   Probably we should avoid trying
 to make reservation in this block group at the first place

Not in this case, because it's the home of the file in question, and
skipping to another bg would just leave useful space empty --- and that
leads to fragmentation.

 You are proposing that we hold the read lock first, do the window search
 and bitmap scan, then once we confirm there is free bit in the candidate
 window, we grab the write lock and update the tree?  

No, I'm suggesting that if we need the write lock for tree updates, we
may still be able to get away with just a read lock when updating an
individual window.  If all we're doing is winding the window forwards a
bit, that's not actually changing the structure of the tree.

 However I am still worried that the rw lock will allow concurrent files
 trying to lock the same window at the same time. 

Adding a new window will need the write lock, always.  But with the read
lock, we can still check the neighbouring windows (the structure is
pinned so those remain valid), so advancing a window with just that lock
can still be done without risking overlapping the next window.

--Stephen

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


Re: RT 45-01: CF Card read: High latency?

2005-04-11 Thread Bartlomiej Zolnierkiewicz
On Apr 11, 2005 1:38 PM, kus Kusche Klaus [EMAIL PROTECTED] wrote:

 So the question is, what exactly is the IDE priority?
 Is the PIO transfer done in the IRQ handler or in a bh?

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


Re: [PATCH 2.6.11.7 1/1] x86 reboot: Add reboot fixup for gx1/cs5530a

2005-04-11 Thread H. Peter Anvin
[EMAIL PROTECTED] wrote:
Hi Riley, Dave, Peter, i386 boot/workaround maintainers,
I'm resending this patch (from March 28). 

This patch incorporates the suggestions from the previous thread and also
switches to using pci_get_device since pci_find_device is deprecated, and
made some of the variables static.
Please let me know if it's okay.

+#define mach_reboot_fixups(x) do {} while (0)
As I stated last time, this should be:
#define mach_reboot_fixup(x)((void)(x))
... to preserve side effects, and be expression-like.
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2005-04-11 Thread Anthony DeRobertis
Glenn Maynard wrote:
I've heard the claim, several times, that that creating a derivative
work requires creative input, that linking stuff together with ld is
completely uncreative, therefore no derivative work is created.  (I'm
not sure if you're making (here or elsewhere) that claim, but it seems
like it.)  What's the basis for this claim?  (If you're not making it,
anybody that does believe this is free to respond.)

It's based on Title 17 USC, Sec. 101, where derivative work is defined:
A derivative work is a work based upon one or more preexisting works,
such as a translation, musical arrangement, dramatization,
fictionalization, motion picture version, sound recording, art
reproduction, abridgment, condensation, or any other form in which a
work may be recast, transformed, or adapted. A work consisting of
editorial revisions, annotations, elaborations, or other modifications
which, as a whole, represent an ORIGINAL WORK OF AUTHORSHIP, is a
derivative work. (emphasis added)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

2005-04-11 Thread Humberto Massa
David Schwartz wrote:
 On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote:
 The way you stop someone from distributing part of your work is
 by arguing that the work they are distributing is a derivative
 work of your work and they had no right to *make* it in the first
  place. See, for example, Mulcahy v. Cheetah Learning.
 Er, that's one way, but not *the* way.  I could grant you
 permission to create derivatives of my work, but not to
 redistribute them.  To stop you from distributing them, I'd argue
 that you had no right to distribute them--you *did* have the right
 to make it in the first place.
 You could do that be means of a contract, but I don't think you could
 it do by means of a copyright license. The problem is that there is
 no right to control the distribution of derivative works for you to
 withhold from me.
Wrong, sorry. Copyright is a *monopoly* on some activities (copy, 
distribution of copies, making *and* distribution of derivative works).

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


Re: bdflush/rpciod high CPU utilization, profile does not make sense

2005-04-11 Thread Trond Myklebust
m den 11.04.2005 Klokka 09:48 (+0200) skreiv Jakob Oestergaard:

 tcp with timeo=600 causes retransmits (as seen with nfsstat) to drop to
 zero.

Good.

  File   Block  Num  Seq ReadRand Read   Seq Write  Rand Write
   DirSize   Size   Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
 --- -- --- --- --- --- --- ---
. 2000   40961  60.50 67.6% 30.12 14.4% 22.54 30.1% 7.075 27.8%
. 2000   40962  59.87 69.0% 34.34 19.0% 24.09 35.2% 7.805 30.0%
. 2000   40964  62.27 69.8% 44.87 29.9% 23.07 34.3% 8.239 30.9%
 
 So, reads start off better, it seems, but writes are still half speed of
 2.4.25.

 I should say that it is common to see a single rpciod thread hogging
 100% CPU for 20-30 seconds - that looks suspicious to me, other than
 that, I can't really point my finger at anything in this setup.

That certainly shouldn't be the case (and isn't on any of my setups). Is
the behaviour identical same on both the PIII and the Opteron systems?

As for the WRITE rates, could you send me a short tcpdump from the
sequential write section of the above test? Just use tcpdump -s 9
-w binary.dmp  just for a couple of seconds. I'd like to check the
latencies, and just check that you are indeed sending unstable writes
with not too many commit or getattr calls.

Cheers
  Trond
-- 
Trond Myklebust [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.6.11.7 1/1] x86 reboot: Add reboot fixup for gx1/cs5530a

2005-04-11 Thread Richard B. Johnson
On Mon, 11 Apr 2005, H. Peter Anvin wrote:
[EMAIL PROTECTED] wrote:
Hi Riley, Dave, Peter, i386 boot/workaround maintainers,
I'm resending this patch (from March 28).
This patch incorporates the suggestions from the previous thread and also
switches to using pci_get_device since pci_find_device is deprecated, and
made some of the variables static.
Please let me know if it's okay.

+#define mach_reboot_fixups(x) do {} while (0)
As I stated last time, this should be:
#define mach_reboot_fixup(x)((void)(x))
... to preserve side effects, and be expression-like.
	-hpa
Shouldn't it just be:
#define mach_reboot_fixup(x)
  |___ Nothing here.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 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/


Re: Processes stuck on D state on Dual Opteron

2005-04-11 Thread Nick Piggin
Nick Piggin wrote:
The common theme seems to be: try_to_free_pages, swap_writepage,
mempool_alloc, down/down_failed in .text.lock.md. Next I would suspect
md/raid1 - maybe some deadlock in an uncommon memory allocation
failure path?
I'll see if I can reproduce it here.
No luck yet (on SMP i386). How many disks are you using in each
raid1 array? You are using one array for swap, and one mounted as
ext3 for the working area of the `stress` program, right?
Neil, have you had a look at the traces? Do they mean much to you?
Claudio - I have attached another patch you could try. It has a more
complete set of mempool and related memory allocation fixes, as well
as some other recent patches I had which reduces atomic memory usage
by the block layer. Could you try if you get time? Thanks.
Nick
--
SUSE Labs, Novell Inc.
Index: linux-2.6/drivers/block/ll_rw_blk.c
===
--- linux-2.6.orig/drivers/block/ll_rw_blk.c2005-04-11 22:18:49.0 
+1000
+++ linux-2.6/drivers/block/ll_rw_blk.c 2005-04-11 22:38:10.0 +1000
@@ -1450,7 +1450,7 @@ EXPORT_SYMBOL(blk_remove_plug);
  */
 void __generic_unplug_device(request_queue_t *q)
 {
-   if (test_bit(QUEUE_FLAG_STOPPED, q-queue_flags))
+   if (unlikely(test_bit(QUEUE_FLAG_STOPPED, q-queue_flags)))
return;
 
if (!blk_remove_plug(q))
@@ -1828,7 +1828,6 @@ static void __freed_request(request_queu
clear_queue_congested(q, rw);
 
if (rl-count[rw] + 1 = q-nr_requests) {
-   smp_mb();
if (waitqueue_active(rl-wait[rw]))
wake_up(rl-wait[rw]);
 
@@ -1860,18 +1859,20 @@ static void freed_request(request_queue_
 
 #define blkdev_free_rq(list) list_entry((list)-next, struct request, 
queuelist)
 /*
- * Get a free request, queue_lock must not be held
+ * Get a free request, queue_lock must be held.
+ * Returns NULL on failure, with queue_lock held.
+ * Returns !NULL on success, with queue_lock *not held*.
  */
 static struct request *get_request(request_queue_t *q, int rw, int gfp_mask)
 {
+   int batching;
struct request *rq = NULL;
struct request_list *rl = q-rq;
-   struct io_context *ioc = get_io_context(gfp_mask);
+   struct io_context *ioc = get_io_context(GFP_ATOMIC);
 
if (unlikely(test_bit(QUEUE_FLAG_DRAIN, q-queue_flags)))
goto out;
 
-   spin_lock_irq(q-queue_lock);
if (rl-count[rw]+1 = q-nr_requests) {
/*
 * The queue will fill after this allocation, so set it as
@@ -1884,6 +1885,8 @@ static struct request *get_request(reque
blk_set_queue_full(q, rw);
}
}
+   
+   batching = ioc_batching(q, ioc);
 
switch (elv_may_queue(q, rw)) {
case ELV_MQUEUE_NO:
@@ -1894,12 +1897,11 @@ static struct request *get_request(reque
goto get_rq;
}
 
-   if (blk_queue_full(q, rw)  !ioc_batching(q, ioc)) {
+   if (blk_queue_full(q, rw)  !batching) {
/*
 * The queue is full and the allocating process is not a
 * batcher, and not exempted by the IO scheduler
 */
-   spin_unlock_irq(q-queue_lock);
goto out;
}
 
@@ -1933,11 +1935,10 @@ rq_starved:
if (unlikely(rl-count[rw] == 0))
rl-starved[rw] = 1;
 
-   spin_unlock_irq(q-queue_lock);
goto out;
}
 
-   if (ioc_batching(q, ioc))
+   if (batching)
ioc-nr_batch_requests--;

rq_init(q, rq);
@@ -1950,13 +1951,14 @@ out:
 /*
  * No available requests for this queue, unplug the device and wait for some
  * requests to become available.
+ *
+ * Called with q-queue_lock held, and returns with it unlocked.
  */
 static struct request *get_request_wait(request_queue_t *q, int rw)
 {
DEFINE_WAIT(wait);
struct request *rq;
 
-   generic_unplug_device(q);
do {
struct request_list *rl = q-rq;
 
@@ -1968,6 +1970,8 @@ static struct request *get_request_wait(
if (!rq) {
struct io_context *ioc;
 
+   __generic_unplug_device(q);
+   spin_unlock_irq(q-queue_lock);
io_schedule();
 
/*
@@ -1979,6 +1983,8 @@ static struct request *get_request_wait(
ioc = get_io_context(GFP_NOIO);
ioc_set_batching(q, ioc);
put_io_context(ioc);
+
+   spin_lock_irq(q-queue_lock);
}
finish_wait(rl-wait[rw], wait);
} while (!rq);
@@ -1992,10 +1998,15 @@ struct request *blk_get_request(request_
 
BUG_ON(rw != READ  rw != WRITE);
 
+   spin_lock_irq(q-queue_lock);
if (gfp_mask  

Re: [PATCH scsi-misc-2.6 03/04] scsi: make scsi_requeue_request() use blk_requeue_request()

2005-04-11 Thread Christoph Hellwig
 + cmd-request-flags |= REQ_SOFTBARRIER;
 +
 + spin_lock_irqsave(q-queue_lock, flags);
 + blk_requeue_request(q, cmd-request);
 + spin_unlock_irqrestore(q-queue_lock, flags);
  
   scsi_run_queue(q);

This exact code sequence is duplicated in the previous patch, maybe time
for a

void scsi_requeue_request(struct request *rq)
{
struct request_queue *q = rq-q;
unsigned long flags;

rq-flags |= REQ_SOFTBARRIER;

spin_lock_irqsave(q-queue_lock, flags);
blk_requeue_request(q, rq);
spin_unlock_irqrestore(q-queue_lock, flags);
  
scsi_run_queue(q);
}

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


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

2005-04-11 Thread Humberto Massa
Adrian Bunk wrote:
Even RedHat with a stronger financial background than Debian considered 
the MP3 patents being serious enough to remove MP3 support.
 

Actually, they did it to spite the patent holders.
[]s
Massa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


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

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

Every book in my book shelf is software?
 

If you digitalize it, yes.
   

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

AFAIK software is just the complementary concept of hardware. 
Hardware is hard, ie, the parts of anything you can touch. Software is 
the *information* part of anything. In the case of a table, hardware are 
the wood, nails, nuts and bolts that make the table and software is the 
design of the table, the recipy of the resin used to coat it, etc. In 
the case of a computer, hardware is the boards, case, monitor and 
software is all the information used to make the thing work, including 
all programs and all data contained in it.

[]
Massa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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/1] connector/CBUS: new messaging subsystem. Revision number next.

2005-04-11 Thread Evgeniy Polyakov
/*/
Kernel Connector.
/*/

Kernel connector - new netlink based userspace - kernel space easy to use 
communication module.

Connector driver adds possibility to connect various agents using
netlink based network.
One must register callback and identifier. When driver receives
special netlink message with appropriate identifier, appropriate
callback will be called.

From the userspace point of view it's quite straightforward:
socket();
bind();
send();
recv();

But if kernelspace want to use full power of such connections, driver
writer must create special sockets, must know about struct sk_buff
handling...
Connector allows any kernelspace agents to use netlink based
networking for inter-process communication in a significantly easier
way:

int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *));
void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask);

struct cb_id
{
__u32   idx;
__u32   val;
};

idx and val are unique identifiers which must be registered in connector.h
for in-kernel usage.
void (*callback) (void *) - is a callback function which will be called
when message with above idx.val will be received by connector core.
Argument for that function must be dereferenced to struct cn_msg *.

struct cn_msg
{
struct cb_idid;

__u32   seq;
__u32   ack;

__u32   len;/* Length of the following data 
*/
__u8data[0];
};

/*/
Connector interfaces.
/*/

int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *));
Registers new callback with connector core.

struct cb_id *id- unique connector's user identifier.
  It must be registered in connector.h for 
legal in-kernel users.
char *name  - connector's callback symbolic name.
void (*callback) (void *)   - connector's callback.
  Argument must be dereferenced to struct 
cn_msg *.

void cn_del_callback(struct cb_id *id);
Unregisters new callback with connector core.

struct cb_id *id- unique connector's user identifier.

void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask);
Sends message to the specified groups.
It can be safely called from any context, but may silently
fail under strong memory pressure.

struct cn_msg * - message header(with attached data).
u32 __groups- destination groups.
  If __groups is zero, then appropriate group 
will
  be searched through all registered connector 
users,
  and message will be delivered to the group 
which was
  created for user with the same ID as in msg.
  If __groups is not zero, then message will be 
delivered
  to the specified group.
int gfp_mask- GFP mask.

Note: When registering new callback user, connector core assigns netlink group
to the user which is equal to it's id.idx.

/*/
Protocol description.
/*/

Current offers transport layer with fixed header.
Recommended protocol which uses such header is following:

msg-seq and msg-ack are used to determine message genealogy.
When someone sends message it puts there locally unique sequence
and random acknowledge numbers.
Sequence number may be copied into nlmsghdr-nlmsg_seq too.

Sequence number is incremented with each message to be sent.

If we expect reply to our message, then sequence number in received
message MUST be the same as in original message, and acknowledge
number MUST be the same + 1.

If we receive message and it's sequence number is not equal to one
we are expecting, then it is new message.
If we receive message and it's sequence number is the same as one we
are expecting, but it's acknowledge is not equal acknowledge number
in original message + 1, then it is new message.

Obviously, protocol header contains above id.

connector allows event notification in the following form:
kernel driver or userspace process can ask connector to notify it
when selected id's will be turned on or off(registered or unregistered
it's callback). It is done by sending special command to connector
driver(it also registers itself with id={-1, -1}).

As example of usage Documentation/connector now contains cn_test.c - 
testing module which uses connector to request notification
and to send messages.


/*/
CBUS.
/*/

This message bus allows message 

Re: Linux 2.4.30-rc3 md/ext3 problems (ext3 gurus : please check)

2005-04-11 Thread Stephen C. Tweedie
Hi,

On Thu, 2005-04-07 at 16:51, Stephen C. Tweedie wrote:

 I'm currently running with the buffer-trace debug patch, on 2.4, with a
 custom patch to put every buffer jbd ever sees onto a per-superblock
 list, and remove it only when the bh is destroyed in
 put_unused_buffer_head().  At unmount time, we can walk that list to
 find stale buffers attached to data pages (invalidate_buffers() already
 does such a walk for metadata.)

After a 50-process dbench run, unmount is showing ~300 buffers
unclaimed; that seems to be OK, it's a large stress test doing _lots_ of
create/unlink and we expect to see a few buffers around at the end where
they were truncated during commit and couldn't be instantly reclaimed.

The main thing now is to test these buffers to make 100% sure that they
are in a state where the VM can reclaim them.  That looks fine: the
buffers I see are unjournaled, have no jh, and are clean and on the
BUF_CLEAN lru.

Andrew, what was the exact illegal state of the pages you were seeing
when fixing that recent leak?  It looks like it's nothing more complex
than dirty buffers on an anon page.  I think that simply calling
try_to_release_page() for all the remaining buffers at umount time will
be enough to catch these; if that function fails, it tells us that the
VM can't reclaim these pages.  The only thing that would be required on
top of that would be a check that the page is also on the VM LRU lists.

--Stephen

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


Re: RT 45-01: CF Card read: High latency?

2005-04-11 Thread P
I handled this issue by precaching all my files (15MB),
from my readonly root filesystem.
find / -type f |
grep -v ^/boot | #kernel is  1MB and never read so don't put in cache
while read file; do
dd bs=32k if=$file of=/dev/null 2/dev/null
done
Pádraig.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: New SCM and commit list

2005-04-11 Thread Chris Mason
On Monday 11 April 2005 03:38, Ingo Molnar wrote:
 * Linus Torvalds [EMAIL PROTECTED] wrote:
  So anything that got modified in just one tree obviously merges to
  that version. Any file that got modified in two trees will end up just
  being passed to the merge program. See man merge and man diff3.
  The merger gets to fix up any conflicts by hand.

 at that point Chris Mason's rej tool is pretty nifty:

   ftp://ftp.suse.com/pub/people/mason/rej/rej-0.13.tar.gz

 (There is no fully automatic mode in where it would not bother the user
 with the really trivial rejects - but it has an automatic mode where you
 basically have to do nothing - maybe a fully automatic one could be
 added that would resolve low-risk rejects?)


rej -M skips the merge program, so rej -a -M will give you something like 
this:

coffee:/local/linux.p # rej -a -M drivers/ide/ide.c.rej
drivers/ide/ide.c: 1 matched, 0 conflicts remain

But I would want to go over the bit that calculates the conflicts remaining 
more carefully if people plan on trusting this ;)  It'll run on unified diffs 
too, although it will be slower then patch since the assumption is the quick 
and easy placement patch does has already failed.  (that's easy enough to fix 
though).

 it's really easy to use (but then again i'm a vim user, so i'm biased),
 just try it on a random .rej file you have (rej -a kernel/sched.c.rej
 or whatever).

you can rej -m kdiff3|meld|tkdiff or any program that does a side by side 
comparison of two files. (export REJMERGE=foo sets the diff prog as well)

I use rej frequently to merge patches in here, but that is mostly because 
there is no easy way to get the common ancestor and parent revision of the 
patches I'm merging.

With that info in hand, kdiff3 is pretty nice.  You would have to spoon feed 
it the renames, but it should have most of the other features you're looking 
for, including the 'no gui if all conflicts are auto-solvable'

-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: [PATCH encrypted swsusp 1/3] core functionality

2005-04-11 Thread Andreas Steinmetz
[EMAIL PROTECTED] wrote:
The following patch adds the core functionality for the encrypted
suspend image.

[Please inline patches, it makes it easier to comment on them.]

Aiyeeh - good ole Mozilla tends to reformat things when inlining...

You seem to reuse same key/iv for all the blocks. I'm no crypto
expert, but I think that is seriously wrong... You probably should use
block number as a IV or something like that.
 
 
 Or use a feedback loop: xor your data with the outcome of the previous
 round. And for the initial block use 0x00...00 for 'previous block'-
 value.

I'm already using cipher block chaining, look for CRYPTO_TFM_MODE_CBC in
swsusp.c. You may want to have a look at cbc_process in crypto/cipher.c.
Thus using the same key is ok. The only known drawback is a watermarking
attack but this can only used to look for the existence of specially
crafted files which are not stored on disk during software suspend.

I should, however, use crypto_cipher_en/decrypt instead of
crypto_cipher_en/decrypt_iv as I actually wanted to use the iv in the
tfm I did set up with crypto_cipher_set_iv instead of the local copy.

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


Re: Oops in swsusp

2005-04-11 Thread Andreas Steinmetz
Rafael J. Wysocki wrote:
 Hi,
 
 On Monday, 11 of April 2005 01:17, Andreas Steinmetz wrote:
 
Pavel,
during testing of the encrypted swsusp_image on x86_64 I did get an Oops
from time to time at memcpy+11 called from swsusp_save+1090 which turns
out to be the memcpy in copy_data_pages() of swsusp.c.
The Oops is caused by a NULL pointer (I don't remember if it was source
or destination).
 
 
 It's quite important, however.  If it's the destination, it's probably a bug 
 in
 swsusp.  Otherwise, the problem is more serious.  Could you, please,
 add BUG_ON(!pbe-address) right before the memcpy() and retest?

I'll try.

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


Re: [Alsa-devel] [2.6 patch] sound/pci/ymfpci/ymfpci_main.c: remove dead code

2005-04-11 Thread Takashi Iwai
At Sun, 10 Apr 2005 01:12:11 +0200,
Adrian Bunk wrote:
 
 This patch removes some dead code found by the Coverity checker.
 
 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

Applied to ALSA tree.  Thanks!


Takashi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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 encrypted swsusp 1/3] core functionality

2005-04-11 Thread Andreas Steinmetz
Pavel Machek wrote:
 Hi!
 
 
The following patch adds the core functionality for the encrypted
suspend image.
 
 
 +#ifdef CONFIG_SWSUSP_ENCRYPT
 +static struct crypto_tfm *crypto_init(int mode)
 +{
 +   struct crypto_tfm *tfm;
 +   int len;
 +
 +   tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
 +   if(!tfm) {
   ~ please put space between if and (
 
 +   printk(KERN_ERR swsusp: no tfm, suspend not
 possible\n);
 +   return NULL;
 +   }
 +
 +   if(sizeof(key)  crypto_tfm_alg_min_keysize(tfm)) {
 
 same here.
 
 Was it really neccessary to include union u? I don't like its name,
 and perhaps few casts are better than this. If not, it probably should
 go in separate patch, and ASAP.

I'll revert this and use few casts.

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


Re: [PATCH 2.6.11.7 1/1] x86 reboot: Add reboot fixup for gx1/cs5530a

2005-04-11 Thread H. Peter Anvin
Richard B. Johnson wrote:
Shouldn't it just be:
#define mach_reboot_fixup(x)
  |___ Nothing here.
Dear Wrongbot,
No.
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [1/1] connector/CBUS: new messaging subsystem. Revision number next.

2005-04-11 Thread Thomas Graf
* Evgeniy Polyakov [EMAIL PROTECTED] 2005-04-11 16:59
 + size = NLMSG_SPACE(sizeof(*msg) + msg-len);
 +
 + skb = alloc_skb(size, gfp_mask);
 + if (!skb) {
 + printk(KERN_ERR Failed to allocate new skb with size=%u.\n, 
 size);
 + return -ENOMEM;
 + }
 +
 + nlh = NLMSG_PUT(skb, 0, msg-seq, NLMSG_DONE, size - sizeof(*nlh));

Needs same fix.

 + size0 = sizeof(*msg) + sizeof(*ctl) + 3*sizeof(*req);
 + 
 + size = NLMSG_SPACE(size0);
 +
 + skb = alloc_skb(size, GFP_ATOMIC);
 + if (!skb) {
 + printk(KERN_ERR Failed to allocate new skb with size=%u.\n, 
 size);
 +
 + return -ENOMEM;
 + }
 +
 + nlh = NLMSG_PUT(skb, 0, 0x123, NLMSG_DONE, size - 
 NLMSG_ALIGN(sizeof(*nlh)));

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


Re: bdflush/rpciod high CPU utilization, profile does not make sense

2005-04-11 Thread Jakob Oestergaard
On Mon, Apr 11, 2005 at 08:35:39AM -0400, Trond Myklebust wrote:
...
 That certainly shouldn't be the case (and isn't on any of my setups). Is
 the behaviour identical same on both the PIII and the Opteron systems?

The dual opteron is the nfs server

The dual athlon is the 2.4 nfs client

The dual PIII is the 2.6 nfs client

 As for the WRITE rates, could you send me a short tcpdump from the
 sequential write section of the above test? Just use tcpdump -s 9
 -w binary.dmp  just for a couple of seconds. I'd like to check the
 latencies, and just check that you are indeed sending unstable writes
 with not too many commit or getattr calls.

Certainly;

http://unthought.net/binary.dmp.bz2

I got an 'invalid snaplen' with the 9 you suggested, the above dump
is done with 9000 - if you need another snaplen please just let me know.

A little explanation for the IPs you see;
 sparrow/10.0.1.20 - nfs server
 raven/10.0.1.7 - 2.6 nfs client
 osprey/10.0.1.13 - NIS/DNS server

Thanks,

-- 

 / jakob

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


[ANNOUNCE] git-pasky-0.3

2005-04-11 Thread Petr Baudis
  Hello,

  here goes git-pasky-0.3, my set of patches and scripts upon
Linus' git, aimed at human usability and to an extent a SCM-like usage.

  If you already have a previous git-pasky version, just git pull pasky
to get it (but see below!!!). Otherwise, you can get it from:

http://pasky.or.cz/~pasky/dev/git/

  Please see the README there and/or the parent post for detailed
instructions. You can find the changes from the last announcement
in the ChangeLog (releases have separate commits so you can find them
easily; they are also tagged for purpose of diffing etc).

  This release is mainly focused on bugfixes. Especially, it fixes git
diff, which was totally broken in the previous release and would only
diff every other file (forgot to remove one shift from the times when
changes were reported two-line from diff-tree). Very sorry about that.

  This implies that git pull was broken too, though - if you pulled
tracked branch, git diff wouldn't produce the complete diff for patch to
apply. If you didn't do any local changes, it is fortunately easy to
repair:

git diff | patch -p0 -R

  (The unapplied changes appear as reverted in your local tree when
compared with the cache.) You will need to edit the diff if you did
some local changes.

  Other change breaking some compatibility is regarding commit
environment variables - s/COMMITTER_*/AUTHOR_*/. Otherwise it is usual
bunch of merges with Linus and some really minor stuff. Oh, and make
install works.

  One annoying thing is rsync error when pulling from Linus - it tries
to sync the tags/ directory and I don't know how to safely silence it
except throwing away all stderr. I will probably make it fetch the list
of .dircache and rsync only things which are really there.

  Any feedback/opinions/suggestions/patches (especially patches) are
welcome. You can also stop by at #git either on FreeNode or on OTFC (I
will be around only from 20:00 CET on, though).

  Have fun,

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


Re: more git updates..

2005-04-11 Thread H. Peter Anvin
Followup to:  [EMAIL PROTECTED]
By author:Christopher Li [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
 
 There is one problem though. How about the SHA1 hash collision?
 Even the chance is very remote, you don't want to lose some data do due
 to software error. I think it is OK that no handle that
 case right now. On the other hand, it will be nice to detect that
 and give out a big error message if it really happens.
 

If you're actually worried about it, it'd be better to just use a
different hash, like one of the SHA-2's (probably a better choice
anyway), instead of SHA-1.

-hpa

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


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

2005-04-11 Thread Michael Poole
Humberto Massa writes:

 David Schwartz wrote:

  On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote:


  The way you stop someone from distributing part of your work is
  by arguing that the work they are distributing is a derivative
  work of your work and they had no right to *make* it in the first
   place. See, for example, Mulcahy v. Cheetah Learning.


  Er, that's one way, but not *the* way.  I could grant you
  permission to create derivatives of my work, but not to
  redistribute them.  To stop you from distributing them, I'd argue
  that you had no right to distribute them--you *did* have the right
  to make it in the first place.


  You could do that be means of a contract, but I don't think you could
  it do by means of a copyright license. The problem is that there is
  no right to control the distribution of derivative works for you to
  withhold from me.
 Wrong, sorry. Copyright is a *monopoly* on some activities (copy,
 distribution of copies, making *and* distribution of derivative works).

Copyright law only _explicitly_ grants a monopoly on preparation of
derivative works.  However, it is trivial, and overwhelmingly common,
for a copyright owner to grant a license to create a derivative work
that is conditional on how the licensee agrees to distribute (or not
distribute) the derivative work.

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


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

2005-04-11 Thread Humberto Massa
Michael Poole wrote:
Copyright law only _explicitly_ grants a monopoly on preparation of
derivative works.  However, it is trivial, and overwhelmingly common,
for a copyright owner to grant a license to create a derivative work
that is conditional on how the licensee agrees to distribute (or not
distribute) the derivative work.
Michael Poole
 

Conceded. Altough .br's computer programs law explicitly says that you 
can reserve, in a license to create derivative works, all the rights 
over the derivative works.

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


Re: [PATCH] zero disk pages used by swsusp on resume

2005-04-11 Thread Jan Niehusmann
 Andreas is right, his patches are needed.
 
 Currently, if your laptop is stolen after resume, they can still data
 in swsusp image.

Which shows that swsusp is a security risk if you have sensitive data in
RAM. A thief stealing a running computer can get access to memory
contents much more easy if he can just suspend the system and then
recover all the memory contents from disk. Encrypted swsusp wouldn't
help here if the key is stored on the disk as well.

(This is probably not a real risk in most applications, but one should
keep it in mind and disable swsusp if necessary)

Jan

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] MAINTAINERS: remove obsolete ACP/MWAVE MODEM entry

2005-04-11 Thread Marcelo Tosatti
Adrian,

./drivers/char/mwave/Makefile also references Paul's email 
address, at least in v2.4.

Applied, thanks.

On Sun, Apr 10, 2005 at 01:15:45AM +0200, Adrian Bunk wrote:
 Both maintainer email addresses are bouncing and the web address is no 
 longer valid.
 
 Seems to be a good time to remove the entry.
 
 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
 
 --- linux-2.6.12-rc2-mm2-full/MAINTAINERS.old 2005-04-10 01:12:58.0 
 +0200
 +++ linux-2.6.12-rc2-mm2-full/MAINTAINERS 2005-04-10 01:13:14.0 
 +0200
 @@ -172,14 +172,6 @@
  W:   http://www.stud.uni-karlsruhe.de/~uh1b/
  S:   Maintained
  
 -ACP/MWAVE MODEM
 -P:   Paul B Schroeder
 -M:   [EMAIL PROTECTED]
 -P:   Mike Sullivan
 -M:   [EMAIL PROTECTED]
 -W:   http://www.ibm.com/linux/ltc/
 -S:   Supported
 -
  AACRAID SCSI RAID DRIVER
  P:   Adaptec OEM Raid Solutions
  L:   linux-scsi@vger.kernel.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: bdflush/rpciod high CPU utilization, profile does not make sense

2005-04-11 Thread Trond Myklebust
m den 11.04.2005 Klokka 15:47 (+0200) skreiv Jakob Oestergaard:

 Certainly;
 
 http://unthought.net/binary.dmp.bz2
 
 I got an 'invalid snaplen' with the 9 you suggested, the above dump
 is done with 9000 - if you need another snaplen please just let me know.

So, the RPC itself looks good, but it also looks as if after a while you
are running into some heavy retransmission problems with TCP too (at the
TCP level now, instead of at the RPC level). When you get into that
mode, it looks as if every 2nd or 3rd TCP segment being sent from the
client is being lost...

That can mean either that the server is dropping fragments, or that the
client is dropping the replies. Can you generate a similar tcpdump on
the server?

Cheers,
  Trond
-- 
Trond Myklebust [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: bdflush/rpciod high CPU utilization, profile does not make sense

2005-04-11 Thread Jakob Oestergaard
On Mon, Apr 11, 2005 at 10:35:25AM -0400, Trond Myklebust wrote:
 må den 11.04.2005 Klokka 15:47 (+0200) skreiv Jakob Oestergaard:
 
  Certainly;
  
  http://unthought.net/binary.dmp.bz2
  
  I got an 'invalid snaplen' with the 9 you suggested, the above dump
  is done with 9000 - if you need another snaplen please just let me know.
 
 So, the RPC itself looks good, but it also looks as if after a while you
 are running into some heavy retransmission problems with TCP too (at the
 TCP level now, instead of at the RPC level). When you get into that
 mode, it looks as if every 2nd or 3rd TCP segment being sent from the
 client is being lost...

Odd...

I'm really sorry for using your time if this ends up being just a
networking problem.

 That can mean either that the server is dropping fragments, or that the
 client is dropping the replies. Can you generate a similar tcpdump on
 the server?

Certainly;  http://unthought.net/sparrow.dmp.bz2


-- 

 / jakob

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

2005-04-11 Thread Paul Jackson
Hmmm ... I have this strong sense that I am about 2 hours away from
smacking my forehead and groaning Duh - so that's what Ingo meant!

However, one must play out one's destiny.

Could you provide an example scenario, which results in the creation of
a combo-blob?

The best I can come up with is the following.

Let's say Nick changes one line in the middle of kernel/sched.c
(yeah - I know - unlikely scenario - he usually changes more
than that - nevermind that detail.)

In the days Before Combo Blobs (BCB), git would have been told that
kernel/sched.c was to be picked up, and would have wrapped it up in a
zlib'd blob, sha1summed it, seen it was a new sum, and added that blob
to its objects (or something like this -- I'm still a little fuzzy on
these git details.)

But Nick just downloaded the latest git 1.5.11.1 which has added support
for combo blobs, so now, guessing here, instead of wrapping up the new
sched.c, git instead unwraps the old one, diff's with the new, notices a
couple of long sequences that are unchanged, wraps up both of those
sequences as a couple of relatively large blobs, and wraps up the new
lines that Nick just coded in the middle as a small blob, and puts all
three in the object store, along with another small combo-blob, tying
them all together.

So far, not too bad.  Haven't gained anything, and required the
unpacking of a zlib blog we didn't require before, and the running and
analyzing of a diff we didn't require before, but the end result is only
moderately worse - four object blobs instead of one, but of total size
not much larger (well, total size typically 3 disk blocks worse, due to
a slight increase in fragmentation from using 4 blocks to store what
used to be in one.)

But now I get stuck.  Unless I throw in something like the interleaved
delta compression that's at the heart of Marc Rochind's old SCCS code
(and Larry's rewrite thereof), I don't see how we ever come to the
practical realization that any of these four new blobs can ever be
reused.

So explain to me again how we ever gain anything with these combo blobs,
while I take a prophylactic aspirin, so the forehead whack won't hurt as
much.

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


[PATCH] Kprobes: Oops! in unregister_kprobe()

2005-04-11 Thread Prasanna S Panchamukhi
Hi,

Please find the patch below to fix Oops! in unregister_kprobe().
Please let me know if you any issues.

Thanks
Prasanna


kernel oops! when unregister_kprobe() is called on a non-registered
kprobe. This patch fixes the above problem by checking if the probe exists
before unregistering.

Signed-off-by: Prasanna S Panchamukhi [EMAIL PROTECTED]


---

 linux-2.6.12-rc2-prasanna/kernel/kprobes.c |6 +-
 1 files changed, 5 insertions(+), 1 deletion(-)

diff -puN kernel/kprobes.c~kprobes-unregister-oops-fix kernel/kprobes.c
--- linux-2.6.12-rc2/kernel/kprobes.c~kprobes-unregister-oops-fix   
2005-04-11 17:23:34.0 +0530
+++ linux-2.6.12-rc2-prasanna/kernel/kprobes.c  2005-04-11 17:32:50.0 
+0530
@@ -110,13 +110,17 @@ rm_kprobe:
 void unregister_kprobe(struct kprobe *p)
 {
unsigned long flags;
-   arch_remove_kprobe(p);
spin_lock_irqsave(kprobe_lock, flags);
+   if (!get_kprobe(p-addr)) {
+   spin_unlock_irqrestore(kprobe_lock, flags);
+   return;
+   }
*p-addr = p-opcode;
hlist_del(p-hlist);
flush_icache_range((unsigned long) p-addr,
   (unsigned long) p-addr + sizeof(kprobe_opcode_t));
spin_unlock_irqrestore(kprobe_lock, flags);
+   arch_remove_kprobe(p);
 }
 
 

_
-- 

Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Ph: 91-80-25044636
[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/


  1   2   3   4   >