Re: 2.6.22: ERROR: "__ucmpdi2" [drivers/net/s2io.ko] undefined!

[Stephen Hemminger]

On Tue, 19 Jun 2007 21:02:53 +0200
Olaf Hering <[EMAIL PROTECTED]> wrote:

> 
> What happend to __ucmpdi2 from David Woodhouse?
> google has a few hits about stuff like this on 32bit powerpc with gcc 4.1.2:
> 
> ERROR: "__ucmpdi2" [drivers/net/s2io.ko] undefined!
> 
> using the drivers/net/s2io* files from 2.6.21 with 2.6.22-rc5 fixes the
> compile.
> 
> 25805dcf9d83098cf5492117ad2669cd14cc9b24 adds two u64 >>= 48 followed by
> a switch statement (line 2889 and 6816).

Probably the "switch(err) {" needs a cast to a smaller type (like u8).
-- 
Stephen Hemminger <[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] diskquota: 32bit quota tools on 64bit architectures

[Mikael Pettersson]

Andrew Morton writes:
 > On Mon, 18 Jun 2007 12:21:47 +0400
 > Vasily Tarasov <[EMAIL PROTECTED]> wrote:
 > 
 > > From: Vasily Tarasov <[EMAIL PROTECTED]>
 > > 
 > > This patch should be applied after Arnd Bergmann's patch,
 > > that intoduces new compat types: 
 > > http://lkml.org/lkml/2007/6/15/98
 > > 
 > > OpenVZ Linux kernel team has discovered the problem 
 > > with 32bit quota tools working on 64bit architectures.
 > > In 2.6.10 kernel sys32_quotactl() function was replaced by sys_quotactl() 
 > > with
 > > the comment "sys_quotactl seems to be 32/64bit clean, enable it for 32bit"
 > > However this isn't right. Look at if_dqblk structure:
 > > 
 > > struct if_dqblk {
 > > __u64 dqb_bhardlimit;
 > > __u64 dqb_bsoftlimit;
 > > __u64 dqb_curspace;
 > > __u64 dqb_ihardlimit;
 > > __u64 dqb_isoftlimit;
 > > __u64 dqb_curinodes;
 > > __u64 dqb_btime;
 > > __u64 dqb_itime;
 > > __u32 dqb_valid;
 > > };
 > > 
 > > For 32 bit quota tools sizeof(if_dqblk) == 0x44.
 > > But for 64 bit kernel its size is 0x48, 'cause of alignment!
 > > Thus we got a problem. Attached patch reintroduce sys32_quotactl() 
 > > function,
 > > that handles this and related situations.
 > > 
 > > Signed-off-by: Vasily Tarasov <[EMAIL PROTECTED]>
 > > 
 > > ---
 > > 
 > > In OpenVZ technology 32 bit Virtual Environments over 
 > > 64 bit OS are common, hence we have customers, that complains on this bad 
 > > quota
 > > behaviour: 
 > > 
 > > # /usr/bin/quota
 > > quota: error while getting quota from /dev/sda1 for 0: Success
 > > 
 > > The reason is caused above.
 > 
 > Only x86_64 and ia64 are fixed.  Would it be correct to assume that the
 > other CONFIG_COMPAT architectures also need to be fixed?

I complained about this very issue when a previous version of
this patch was submitted last week, and Arnd explained that
non-x86 doesn't have a problem here because alignof(u64) is the
same in 32- and 64-bit modes.

However, the fact that the patch description talks about 32-
and 64-bit machines _in_general_, while the patch clearly only
handles x86-32 on x86-64 and ia64, is itself a bug. A more
precise patch description and a better comment in the code
is in order, I think.

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

Re: [patch 10/26] SLUB: Faster more efficient slab determination for __kmalloc.

[Andrew Morton]

On Mon, 18 Jun 2007 02:58:48 -0700
[EMAIL PROTECTED] wrote:

> + BUG_ON(KMALLOC_MIN_SIZE > 256 ||
> + (KMALLOC_MIN_SIZE & (KMALLOC_MIN_SIZE - 1)));

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

Re: Versioning file system

[Jack Stone]

Chris Snook wrote:
> Jack Stone wrote:
>> The idea was that if you did an ls you would get the latest version of
>> the file without the :revision_num. The only visible version would be
>> the latest version, i.e. the current system would not change. The idea
>> was that it would only show earlier versions if they were specifically
>> requested with a :revision_num suffix. In that case the
>> filesystem/kernel would need to recognise the suffix and return the
>> earlier version of the file.
>>
>> The only userspace it would break is files with :num in their name, as I
>> haven't seen any files like that I don't think its too big a problem but
>> the way of specifiying revisions could be changed.
>>
>> Jack
> 
> I have one right now:
> 
> $ ls /tmp/ksocket-csnook/kdeinit*
> /tmp/ksocket-csnook/kdeinit__0  /tmp/ksocket-csnook/kdeinit-:0
> 
> Note, I did not pass any special arguments to ls to make it pull up that
> file. You'd have to modify ls to make it do that.  You'd also need to
> modify everything else out there.  There are decades of programs out
> there that would behave differently with the interface you propose.
> 
> The more fundamental problem with your proposed interface is that it
> treats a filesystem like an opaque server, instead of a transparent data
> structure.  You want files to be completely invisible to applications
> that don't know about it, unless the user requests it.  Unfortunately,
> it doesn't work that way. Applications ask for a directory listing, and
> will open the requested file if and only if the filename in question
> appears in that listing.  If you want to use this opaque server model,
> you'd be better served putting it in some parallel file system (say,
> /backup) that won't interfere with naive applications accessing the
> mundane data.  Personally, I like your idea of putting the older
> versions in the same directory hierarchy, but I think you'd have to use
> .foo hidden directories to do it right.

The whole idea of the file system is that it wouldn't return the file in
the file listing. The user would have to know that the file system was
versioning to access the older versions as they would explicitly have to
request them.

Jack

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

Re: Fix signalfd interaction with thread-private signals

[Oleg Nesterov]

On 06/19, Davide Libenzi wrote:
>
> On Tue, 19 Jun 2007, Oleg Nesterov wrote:
> 
> > On 06/19, Benjamin Herrenschmidt wrote:
> > >
> > > On Tue, 2007-06-19 at 13:14 +0400, Oleg Nesterov wrote:
> > > 
> > > > The commited "Fix signalfd interaction with thread-private signals"
> > > > (commit caec4e8dc85e0644ec24aeb36285e1ba02da58cc) doesn't implement
> > > > this.
> > > 
> > > Indeed, if you want what Davide described, you need to also change
> > > signalfd side. The patch I did merely prevents another thread from
> > > dequeuing somebody else private signals.
> > 
> > Yes I see, but why do we need this change? Yes, we can dequeue SIGSEGV
> > from another thread. Just don't do it if you have a handler for SIGSEGV?
> 
> I believe it can be confusing to have private signals dequeued from 
> another thread. The kernel expect those to be dequeued by the target 
> thread.

Well, I think the kernel doesn't make any assumptions on that. It can't
guarantee the signal will be actually dequeued, to begin with.

(That said, I probably missed something, in that case I'd like to be
 educated. This is the real reason why I am making the noise :)

Oleg.

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

Re: [BUG] ide dma_timer_expiry, then hard lockup

[Sergei Shtylyov]

Bartlomiej Zolnierkiewicz wrote:


There are two distinct issues.
-- libata locks up in partition table read on an hpt366+old maxtor disk
  that has ben working fine for many years with old ide driver. (It
  still works fine when I boot to the alternate ide-based kernel).


-- ide driver locks up on hpt366+new maxtor disk under heavy 
  i/o load. I was able to copy 60GB from old to new disk without a

  problem; however, raid reconstruction locks it up, maybe after 5-15
  seconds.


  This probably is "hardware related"; its something that the new 
  hard drive does. Given that its being sold at a big discount, it

  may even be that the sellers know that this is a crappy disk. :-)



  All I want is some way of resetting the disk, and continuing on.



It would be useful to see hdparm --Istdout output for *both* disks.



I'm stalled in debugging; I'm not sue what I'm looking for.



Sergei, do you think that testing the drive with DMA disabled may
tell us something new?


   Not sure. I'll try to come up with a patch esetting the state machine in 
dma_timeout() method (following Alan's idea) -- HPT366 regs are different 
enough to use the one for HPT370.



Thanks,
Bart


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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Diego Calleja]

El Tue, 19 Jun 2007 20:21:53 +0200, Nicolas Mailhot <[EMAIL PROTECTED]> 
escribió:

> traffic regulations only consider cars? I think not. Yet the same
> argument is the core of most GPL v3 objections we've seen in this
> thread.

No, the core argument of the GPLv3 objections is that you can NOT tell the
hardware manufacturers how to build hardware. You only  can tell software
users what hardware (tivoized) it's forbidden for them. Wether or not the
hardware manufacturers are going to care enought about your anti-tivo
software to remove their tivo protections is a completely different question
unrelated to the software license. Which is why the GPLv3 anti-tivoization
measures are stupid and pointless. 

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

Re: Versioning file system

[Chris Snook]

Jack Stone wrote:

Chris Snook wrote:

But what you're talking about *will* break userspace.  If I do an ls in
a directory, and get pages upon pages of versions of just one file,
that's broken.  If I tar up a directory and get a tarball that's
hundreds of times larger than it should be, that's broken.  If you want
the files to be hidden from userspace applications that don't know about
your backup scheme, (and it sounds like you do) then use the existing
convention for hidden files, the prepended '.'  This is the universal
sign for "don't mess with me unless you know what you're doing".


The idea was that if you did an ls you would get the latest version of
the file without the :revision_num. The only visible version would be
the latest version, i.e. the current system would not change. The idea
was that it would only show earlier versions if they were specifically
requested with a :revision_num suffix. In that case the
filesystem/kernel would need to recognise the suffix and return the
earlier version of the file.

The only userspace it would break is files with :num in their name, as I
haven't seen any files like that I don't think its too big a problem but
the way of specifiying revisions could be changed.

Jack


I have one right now:

$ ls /tmp/ksocket-csnook/kdeinit*
/tmp/ksocket-csnook/kdeinit__0  /tmp/ksocket-csnook/kdeinit-:0

Note, I did not pass any special arguments to ls to make it pull up that file. 
You'd have to modify ls to make it do that.  You'd also need to modify 
everything else out there.  There are decades of programs out there that would 
behave differently with the interface you propose.


The more fundamental problem with your proposed interface is that it treats a 
filesystem like an opaque server, instead of a transparent data structure.  You 
want files to be completely invisible to applications that don't know about it, 
unless the user requests it.  Unfortunately, it doesn't work that way. 
Applications ask for a directory listing, and will open the requested file if 
and only if the filename in question appears in that listing.  If you want to 
use this opaque server model, you'd be better served putting it in some parallel 
file system (say, /backup) that won't interfere with naive applications 
accessing the mundane data.  Personally, I like your idea of putting the older 
versions in the same directory hierarchy, but I think you'd have to use .foo 
hidden directories to do it right.


-- 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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Jan Harkes]

On Tue, Jun 19, 2007 at 02:40:59AM -0300, Alexandre Oliva wrote:
> > The actual software is mailed to you on a credit card sized
> > ROM when you activate service.
...
> The GPLv3 won't remove every way in which people who want/need to stop
> the user from making changes to the software could accomplishing this
> (ROM).  It will just make this a bit more inconvenient, such that
> vendors that have the option respect users' freedoms, and those that
> find it too inconvenient respect the wishes of users who don't want
> their software turned non-free.

I am trying to read that last sentence and it just doesn't seem to make
any sense.

Or are you saying that all that anti-tivoization language that adds
complex requirements which change depending on the market some device
happens to be sold in and which will most likely make GPLv3 software
unusable for various applications ranging from medical equipment to
financial transaction systems (and probably others) is there to just
make it a _bit_ more inconvenient for vendors to implement a tivo-like
scheme?

So what exactly is the point of all this then?

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: Device hang when offlining a CPU due to IRQ misrouting

[Siddha, Suresh B]

On Tue, Jun 19, 2007 at 12:06:37PM -0700, Darrick J. Wong wrote:
> On Tue, Jun 19, 2007 at 11:00:03AM -0700, Siddha, Suresh B wrote:
> > Anyhow, Darrick there is a general bug in this area, can you try this and
> > see if it helps?
> 
> Er... that instantly locked up the system.

hmm.. Please try this instead. This is intended only for debug. Based on your
test results, we can comeup with a more decent fix.

diff --git a/arch/x86_64/kernel/irq.c b/arch/x86_64/kernel/irq.c
index 3eaceac..3997679 100644
--- a/arch/x86_64/kernel/irq.c
+++ b/arch/x86_64/kernel/irq.c
@@ -144,17 +144,37 @@ void fixup_irqs(cpumask_t map)
 
for (irq = 0; irq < NR_IRQS; irq++) {
cpumask_t mask;
+   int break_affinity = 0;
+   int set_affinity = 1;
+
if (irq == 2)
continue;
 
+   /* irq's are disabled at this point */
+   spin_lock(_desc[irq].lock);
+
cpus_and(mask, irq_desc[irq].affinity, map);
if (any_online_cpu(mask) == NR_CPUS) {
-   printk("Breaking affinity for irq %i\n", irq);
+   break_affinity = 1;
mask = map;
}
+
+   if (irq_desc[irq].chip->mask)
+   irq_desc[irq].chip->mask(irq);
+
if (irq_desc[irq].chip->set_affinity)
irq_desc[irq].chip->set_affinity(irq, mask);
else if (irq_desc[irq].action && !(warned++))
+   set_affinity = 0;
+
+   if (irq_desc[irq].chip->unmask)
+   irq_desc[irq].chip->unmask(irq);
+
+   spin_unlock(_desc[irq].lock);
+
+   if (break_affinity && set_affinity)
+   printk("Broke affinity for irq %i\n", irq);
+   else if (!set_affinity)
printk("Cannot set affinity for irq %i\n", irq);
}
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 with global_flush_tlb() on i386 (x86_64? too) in 2.6.22-rc4-mm2

[Mathieu Desnoyers]

Looking more closely into the code to find the cause of the
change_page_addr()/global_flush_tlb() inconsistency, I see where the
problem could be:

In arch/i386/mm/pageattr.c:
__change_page_attr adds the page to the df_list for deferred removal
when it is replaced by a large page (going back to the normal flags).
This list is walked by global_flush_tlb(); it calls flush_map() and
__free_page for each of these pages.

flush_map() is the only call that ends up doing a clflush/wbinvd and
__flush_tlb_all() on every cpu. However, this is only done when there
are pages recombined in a large page. It never happens when we set the
page flags to something unusual in __change_page_attr().

The x86_64 implementation seems to work around this issue by doing a
flush_map() independently of the deferred_pages list. It will therefore
call __flush_tlb_all(), which should flush the TLB, but even there, I
wonder if it should call clflush on the pages that had their flags
modified by __change_page_attr() ?

Some input about the best way to fix this (adding the modified pages to
the deferred list in __change_page_attr() or flushing all the TLBs, and
all caches, independently of the deferred pages list in
global_flush_tlb()) would be appreciated. If we add the pages that
simply had their flags modified to the df_list, would it be ok to issue
a __free_page on them ?

Thanks,

Mathieu

* Mathieu Desnoyers ([EMAIL PROTECTED]) wrote:
> Hi,
> 
> Trying to test my "Text Edit Lock" patches, I ran into a problem related
> to global_flush_tlb() not doing its job at updating the page flags when,
> it seems, the page has been recently accessed. Therefore, it can only be
> reproduced by doing a couple of iterations.
> 
> I run on a Pentium 4 with the following characteristics:
> 
> processor   : 0
> vendor_id   : GenuineIntel
> cpu family  : 15
> model   : 4
> model name  : Intel(R) Pentium(R) 4 CPU 3.00GHz
> stepping: 1
> cpu MHz : 3000.201
> cache size  : 1024 KB
> fdiv_bug: no
> hlt_bug : no
> f00f_bug: no
> coma_bug: no
> fpu : yes
> fpu_exception   : yes
> cpuid level : 5
> wp  : yes
> flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
> mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx
> constant_tsc pebs bts sync_rdtsc pni monitor ds_cpl cid xtpr
> bogomips: 6007.49
> clflush size: 64
> 
> config :
> CONFIG_X86_INVLPG=y (complete .config at the end)
> CONFIG_PARAVIRT=y/n
> 
> 
> (notice that pge and clflush features are present)
> 
> The kernel is configured in UP (I first saw the problem in SMT, but
> switched to UP and it is still there).
> 
> I provide a really crude hackish test module that shows the problematic
> behavior below.
> 
> Whenever I run the module using global_flush_tlb(), I get the following
> OOPS:
> 
> 
> [ 1112.512389] Init Attr RX
> [ 1112.521691] Init Attr RX end
> [ 1113.702965] Loop 0
> [ 1113.709171] Attr RWX 621545
> [ 1113.717662] Attr RX 621545
> [ 1113.725869] Attr RWX 432917
> [ 1113.734295] Attr RX 432917
> [ 1113.742460] Attr RWX 973425
> [ 1113.750885] Attr RX 973425
> [ 1113.759048] Attr RWX 453890
> [ 1113.767490] Attr RX 453890
> [ 1113.775653] Attr RWX 1035918
> [ 1113.784341] Attr RX 1035918
> [ 1113.792764] Attr RWX 1038276
> [ 1113.801449] Attr RX 1038276
> [ 1113.809902] Attr RWX 71394
> [ 1113.818067] Attr RX 71394
> [ 1113.825970] Attr RWX 88253
> [ 1113.834134] Attr RX 88253
> [ 1113.842039] Attr RWX 108029
> [ 1113.850505] Attr RX 108029
> [ 1113.858670] Attr RWX 767772
> [ 1113.867095] Attr RX 767772
> [ 1113.875259] Attr RWX 251394
> [ 1113.883694] Attr RX 251394
> [ 1113.891859] Attr RWX 817582
> [ 1113.900376] Attr RX 817582
> [ 1113.908540] Attr RWX 577819
> [ 1113.916965] Attr RX 577819
> [ 1113.925127] Attr RWX 56979
> [ 1113.933293] Attr RX 56979
> [ 1113.941195] Attr RWX 72953
> [ 1113.949361] Attr RX 72953
> [ 1113.957265] Attr RWX 94222
> [ 1113.965445] BUG: unable to handle kernel paging request at virtual address 
> c3a1700e
> [ 1113.988291]  printing eip:
> [ 1113.996340] f885e0a6
> [ 1114.002835] *pde = 038c6163
> [ 1114.011145] *pte = 03a17163
> [ 1114.019455] Oops: 0003 [#1]
> [ 1114.027766] PREEMPT 
> [ 1114.034268] LTT NESTING LEVEL : 0 
> [ 1114.044402] Modules linked in: test_rodata ltt_statedump ltt_control sky2 
> skge rtc snd_hda_intel
> [ 1114.070679] CPU:0
> [ 1114.070680] EIP:0060:[]Not tainted VLI
> [ 1114.070681] EFLAGS: 00010282   (2.6.22-rc4-mm2-testssmp #129)
> [ 1114.110395] EIP is at my_open+0xa6/0x124 [test_rodata]
> [ 1114.125711] eax: c3a0   ebx: 0001700e   ecx: c39e4000   edx: 
> [ 1114.145953] esi: 36f1700e   edi: f885e000   ebp: c39e5ebc   esp: c39e5ea0
> [ 1114.166195] ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
> [ 1114.183583] Process cat (pid: 4112, ti=c39e4000 task=c38ac1b0 
> task.ti=c39e4000)
> [ 1114.204862] Stack: f885e223 0001700e  f000 

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Anders Larsen]

On 2007-06-19 20:23:00, Alexandre Oliva wrote:
> If you take the Wikipedia definition of Tivoization, you'll see it's
> about copyleft software only, and no law mandates the use of copyleft
> software.  There's no end to bad laws, but a law that mandated the use
> of copyleft (=> free) software and at the same time prohibited
> modifications by the user would be a very contradictory one.

You're absolutely right...

Nobody forces us to use Linux in the credit-card terminals I'm currently
working on; of course we could have selected a proprietary solution (and
we would be forced to, were the Linux kernel and/or certain crucial
libraries or utilities GPLv3 only). 

Only, your statement above seems to run counter to your previous claims
that the "anti-tivoisation" provisions of GPLv3 would bring _more_
developers to copyleft software.

So which one is it?

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

Re: Fix signalfd interaction with thread-private signals

[Oleg Nesterov]

On 06/19, Davide Libenzi wrote:
>
> On Tue, 19 Jun 2007, Oleg Nesterov wrote:
> 
> > The commited "Fix signalfd interaction with thread-private signals"
> > (commit caec4e8dc85e0644ec24aeb36285e1ba02da58cc) doesn't implement
> > this.
> > 
> > We can do something like
> > 
> > int signalfd_dequeue_signal(struct task_struct *tsk, sigset_t *mask, 
> > siginfo_t *info)
> > {
> > if (tsk->tgid == current->tgid)
> > tsk = current;
> > 
> > return dequeue_signal(tsk, mask, info);
> > }
> > 
> > (still I can't understand why should we change signalfd).
> 
> Yes, of course. I was waiting for Ben's patch to go in, before fixing 
> signalfd. I did not know if Linus would have acked that.

OK, this means that signalfd becomes "thread group wide". In that case
I'd suggest to also change sys_signalfd(-1),

-   ctx->tsk = current;
+   ctx->tsk = current->group_leader;

Oleg.

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 19, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

>> On Jun 18, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

>> > Why is the fact that only the root user can load a kernel module not a
>> > further restriction?

>> Because the user (under whose control the computer is, be it person or
>> company) set up the root password herself?

> Well, duh. TiVo, under whose control the software running on my Tivo is, set
> up the signing key themself. *Someone* has to decide what software runs, the
> GPL cannot rationally decide who that is because it's an
> application-specific authorization decision.

Right.  All GPL can say is that you cannot impose further restrictions
on how the user adapts the software, and since the user runs the
software on that computer, that means you must not restrict the user's
ability to upgrade or otherwise replace that software there, when you
gave the user the software along with the computer.


>> > However, "you can't load your modified sofware on *MY* hardware" is
>> > not a further restriction.

>> As long as you didn't hand me the hardware along with the software,
>> for me to become a user of the software on that hardware, I agree.

> This is, again, an argument that is totally alien to the GPL.

No, it's not.  It is intended to ensure that free software remains
free for all its users.  When you receive the software, you become a
user.  That's when you receive the rights, and that's what creates the
obligation on the distributor to not impose restrictions on the
freedoms, no matter by how means such restrictions could be legally or
technically accomplished.

> The idea that you have 'special' rights to the software on some
> hardware but not others is simply insane.

I agree, to some extent.  It's not so much about the rights, but about
the restrictions the vendor can impose on hardware.

It's just that, for this particular hardware, as you say, the
manufacturer has (or had) special rights.  This means it can decide
what software runs, whom it gives the hardware to, etc.

However, by distributing software under the GPL, the vendor accepts
the condition to not use any means whatsoever to impose restrictions
on the recipient's exercise of the rights granted by the license by
means of the distribution of the software.

There's no reason to make the hardware special, or the right of
authorization special, as a possible excuse to impose restrictions on
the user.  It amounts to just that: an attempt to excuse oneself from
the condition of not imposing restrictions on the enjoyment of the
freedoms.

> The GPL is about being able to use the software on *ANY* hardware
> for which you have the right to decide what software runs.

Yes.  And, per the "pass on all rights you have" spirit in the
preamble, that translates into "no further restrictions" in the legal
terms, the user *must* receive this right from the distributor of the
software.


Oh, but what if the distributor doens't have this right in the first
place?  Well, let's see...

Either the distributor received the hardware with the software inside
it, which means it should have received this right along with the
software from whoever gave it the software, so it has this right, or
it installed the software itself, which means it does have this
right.  In both cases.

>> No, because the user is not becoming a user of the software on their
>> own computers.  Only in the computer that was shipped along with the
>> software.

> Yes, they are becoming a user. They might very well be using those
> computers.

This means they already were users there of those computers, just not
necessarily of that software on those computers.

And then, if they choose to copy and run the software on other
computers where they are entitled to install software, they're free to
do so, the vendor of that other piece of hardware must not impose
restrictions on that either.

> You can state what the GPLv3 does as many times as you want, but special
> rights to particular pieces of hardware is *TOTALLY* alien to the spirit of
> the GPL.

I agree.  That's the bug in GPLv2 that the anti-tivoization provision
is trying to fix.

> The GPL was always about equal rights to use the software in any
> hardware.

Exactly.  Thank you.  It finally sank in, it seems.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.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: [PATCH 2/2] UML - Add stack usage monitoring

[Randy Dunlap]

On Tue, 19 Jun 2007 15:50:03 -0400 Jeff Dike wrote:

> Add a machanism to see how much of a kernel stack is used.  This
> allocates zeroed stacks and sees where the lowest non-zero byte is on
> process exit.  It keeps track of the lowest value and logs values as
> they get lower.
> 
> Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
> --
>  arch/um/Kconfig.debug|9 +
>  arch/um/defconfig|1 +
>  arch/um/kernel/process.c |   29 +
>  include/asm-um/thread_info.h |   16 
>  4 files changed, 55 insertions(+)
> 
> Index: linux-2.6.21-mm/arch/um/Kconfig.debug
> ===
> --- linux-2.6.21-mm.orig/arch/um/Kconfig.debug2007-06-19 
> 14:06:36.0 -0400
> +++ linux-2.6.21-mm/arch/um/Kconfig.debug 2007-06-19 14:06:44.0 
> -0400
> @@ -47,4 +47,13 @@ config GCOV
>  If you're involved in UML kernel development and want to use gcov,
>  say Y.  If you're unsure, say N.
>  
> +config DEBUG_STACK_USAGE
> + bool "Stack utilization instrumentation"
> + default N
> + help
> + Track the maximum kernel stack usage - this will look at each
> + kernel stack at process exit and log it if it's the deepest
> + stack seen so far.

Kconfig help text is indented 2 more spaces (by convention or
CodingStyle).

> +
> + This option will slow down process creation and destruction somewhat.
>  endmenu
> Index: linux-2.6.21-mm/arch/um/kernel/process.c
> ===
> --- linux-2.6.21-mm.orig/arch/um/kernel/process.c 2007-06-19 
> 14:06:36.0 -0400
> +++ linux-2.6.21-mm/arch/um/kernel/process.c  2007-06-19 15:48:20.0 
> -0400
> @@ -411,3 +411,32 @@ unsigned long arch_align_stack(unsigned 
>   return sp & ~0xf;
>  }
>  #endif
> +
> +#ifdef CONFIG_DEBUG_STACK_USAGE
> +
> +static DEFINE_SPINLOCK(low_water_lock);
> +static int lowest_to_date = THREAD_SIZE;
> +
> +void check_stack_usage(struct thread_info *s)
> +{
> + unsigned int *stack, *p, *end;
> + int left;
> +
> + stack = (unsigned int *) (s + 1);
> + end = (unsigned int *) ((unsigned long) s + THREAD_SIZE);
> + for (p = stack; p < end; p++) {
> + if(*p != 0)

if (*p != NULL)
or
if (*p)

> + break;
> + }
> +
> + left = (p - stack) * sizeof(*p);
> +
> + spin_lock(_water_lock);
> + if (left < lowest_to_date) {
> + printk("Greatest stack depth - %d bytes left\n", left);

Does UML need/use KERN_* facility levels in printk() calls?

> + lowest_to_date = left;
> + }
> + spin_unlock(_water_lock);
> +}
> +
> +#endif

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

[PATCH 2.6.22-rc5 2/2] sata_promise: SATA hotplug support

[Mikael Pettersson]

This patch enables hotplugging of SATA devices in the
sata_promise driver. It's been tested successfully on
both first- and second-generation Promise SATA chips:
SATA150 TX2plus, SATAII150 TX2plus, SATA300 TX2plus,
and SATA300 TX4.

The only quirk I've seen is that hotplugging (insertion)
on the first-generation SATA150 TX2plus requires a lengthier
EH sequence than on the second-generation chips.
On the second-generation chips a simple soft reset seems
to suffice, but on the first-generation chip there's a
"port is slow to respond" after the initial soft reset,
after which libata issues a hard reset, and then the
device is recognised.

The hotplug checks are high up in the interrupt handling
path, not deep down in error_intr as in ahci/sata_sil24.
That's because the chip doesn't signal hotplug status changes
in the per-port status register: instead a global register
contains hotplug control and status flags for all ports.
I considered following the ahci/sata_sil24 structure, but
that would have required non-trivial changes to the interrupt
handling path, so I chose to keep the hotplug changes simple
and unobtrusive.

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
--
This patch depends on patch 1/2: sata_promise: cleanups.

Changes since the preliminary version:
- cleanups
- added testing on the first-generation SATA150 TX2plus

 drivers/ata/sata_promise.c |   40 +++-
 1 files changed, 35 insertions(+), 5 deletions(-)

--- linux-2.6.22-rc5/drivers/ata/sata_promise.c.~1~ 2007-06-19 
20:40:28.0 +0200
+++ linux-2.6.22-rc5/drivers/ata/sata_promise.c 2007-06-19 20:41:36.0 
+0200
@@ -45,7 +45,7 @@
 #include "sata_promise.h"
 
 #define DRV_NAME   "sata_promise"
-#define DRV_VERSION"2.08"
+#define DRV_VERSION"2.09"
 
 enum {
PDC_MAX_PORTS   = 4,
@@ -716,6 +716,9 @@ static irqreturn_t pdc_interrupt (int ir
unsigned int i, tmp;
unsigned int handled = 0;
void __iomem *mmio_base;
+   unsigned int hotplug_offset, ata_no;
+   u32 hotplug_status;
+   int is_sataii_tx4;
 
VPRINTK("ENTER\n");
 
@@ -726,10 +729,20 @@ static irqreturn_t pdc_interrupt (int ir
 
mmio_base = host->iomap[PDC_MMIO_BAR];
 
+   /* read and clear hotplug flags for all ports */
+   if (host->ports[0]->flags & PDC_FLAG_GEN_II)
+   hotplug_offset = PDC2_SATA_PLUG_CSR;
+   else
+   hotplug_offset = PDC_SATA_PLUG_CSR;
+   hotplug_status = readl(mmio_base + hotplug_offset);
+   if (hotplug_status & 0xff)
+   writel(hotplug_status | 0xff, mmio_base + hotplug_offset);
+   hotplug_status &= 0xff; /* clear uninteresting bits */
+
/* reading should also clear interrupts */
mask = readl(mmio_base + PDC_INT_SEQMASK);
 
-   if (mask == 0x) {
+   if (mask == 0x && hotplug_status == 0) {
VPRINTK("QUICK EXIT 2\n");
return IRQ_NONE;
}
@@ -737,16 +750,33 @@ static irqreturn_t pdc_interrupt (int ir
spin_lock(>lock);
 
mask &= 0x; /* only 16 tags possible */
-   if (!mask) {
+   if (mask == 0 && hotplug_status == 0) {
VPRINTK("QUICK EXIT 3\n");
goto done_irq;
}
 
writel(mask, mmio_base + PDC_INT_SEQMASK);
 
+   is_sataii_tx4 = pdc_is_sataii_tx4(host->ports[0]->flags);
+
for (i = 0; i < host->n_ports; i++) {
VPRINTK("port %u\n", i);
ap = host->ports[i];
+
+   /* check for a plug or unplug event */
+   ata_no = pdc_port_no_to_ata_no(i, is_sataii_tx4);
+   tmp = hotplug_status & (0x11 << ata_no);
+   if (tmp && ap &&
+   !(ap->flags & ATA_FLAG_DISABLED)) {
+   struct ata_eh_info *ehi = >eh_info;
+   ata_ehi_clear_desc(ehi);
+   ata_ehi_hotplugged(ehi);
+   ata_ehi_push_desc(ehi, "hotplug_status %#x", tmp);
+   ata_port_freeze(ap);
+   continue;
+   }
+
+   /* check for a packet interrupt */
tmp = mask & (1 << (i + 1));
if (tmp && ap &&
!(ap->flags & ATA_FLAG_DISABLED)) {
@@ -902,9 +932,9 @@ static void pdc_host_init(struct ata_hos
tmp = readl(mmio + hotplug_offset);
writel(tmp | 0xff, mmio + hotplug_offset);
 
-   /* mask plug/unplug ints */
+   /* unmask plug/unplug ints */
tmp = readl(mmio + hotplug_offset);
-   writel(tmp | 0xff, mmio + hotplug_offset);
+   writel(tmp & ~0xff, mmio + hotplug_offset);
 
/* don't initialise TBG or SLEW on 2nd generation chips */
if (is_gen2)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  

[PATCH 2.6.22-rc5 1/2] sata_promise: cleanups

[Mikael Pettersson]

This patch applies some trivial cleanups to sata_promise:
- repair whitespace damage
- correct comment at board_2057x_pata definition
- pull SATAII TX4 support code out to separate functions
- rename ata_nr to ata_no for consistency with libata's port_no
- remove some init-time debug printks (requested by Jeff)

This patch should cause no behavioural changes, except for
the removed printks.

Signed-off-by: Mikael Pettersson <[EMAIL PROTECTED]>
--
 drivers/ata/sata_promise.c |   56 ++---
 1 files changed, 23 insertions(+), 33 deletions(-)

--- linux-2.6.22-rc5/drivers/ata/sata_promise.c.~1~ 2007-06-19 
20:38:13.0 +0200
+++ linux-2.6.22-rc5/drivers/ata/sata_promise.c 2007-06-19 20:40:28.0 
+0200
@@ -45,8 +45,7 @@
 #include "sata_promise.h"
 
 #define DRV_NAME   "sata_promise"
-#define DRV_VERSION"2.07"
-
+#define DRV_VERSION"2.08"
 
 enum {
PDC_MAX_PORTS   = 4,
@@ -94,7 +93,7 @@ enum {
board_20319 = 2,/* FastTrak S150 TX4 */
board_20619 = 3,/* FastTrak TX4000 */
board_2057x = 4,/* SATAII150 Tx2plus */
-   board_2057x_pata= 5,/* SATAII150 Tx2plus */
+   board_2057x_pata= 5,/* SATAII150 Tx2plus PATA port */
board_40518 = 6,/* SATAII150 Tx4 */
 
PDC_HAS_PATA= (1 << 1), /* PDC20375/20575 has PATA */
@@ -124,7 +123,6 @@ enum {
PDC_FLAG_4_PORTS= (1 << 26), /* 4 ports */
 };
 
-
 struct pdc_port_priv {
u8  *pkt;
dma_addr_t  pkt_dma;
@@ -340,7 +338,6 @@ static const struct pci_device_id pdc_at
{ } /* terminate list */
 };
 
-
 static struct pci_driver pdc_ata_pci_driver = {
.name   = DRV_NAME,
.id_table   = pdc_ata_pci_tbl,
@@ -348,7 +345,6 @@ static struct pci_driver pdc_ata_pci_dri
.remove = ata_pci_remove_one,
 };
 
-
 static int pdc_common_port_start(struct ata_port *ap)
 {
struct device *dev = ap->host->dev;
@@ -438,7 +434,6 @@ static u32 pdc_sata_scr_read (struct ata
return readl(ap->ioaddr.scr_addr + (sc_reg * 4));
 }
 
-
 static void pdc_sata_scr_write (struct ata_port *ap, unsigned int sc_reg,
   u32 val)
 {
@@ -657,8 +652,8 @@ static void pdc_error_intr(struct ata_po
ata_port_abort(ap);
 }
 
-static inline unsigned int pdc_host_intr( struct ata_port *ap,
-  struct ata_queued_cmd *qc)
+static inline unsigned int pdc_host_intr(struct ata_port *ap,
+struct ata_queued_cmd *qc)
 {
unsigned int handled = 0;
void __iomem *port_mmio = ap->ioaddr.cmd_addr;
@@ -685,10 +680,10 @@ static inline unsigned int pdc_host_intr
handled = 1;
break;
 
-default:
+   default:
ap->stats.idle_irq++;
break;
-}
+   }
 
return handled;
 }
@@ -701,6 +696,18 @@ static void pdc_irq_clear(struct ata_por
readl(mmio + PDC_INT_SEQMASK);
 }
 
+static inline int pdc_is_sataii_tx4(unsigned long flags)
+{
+   const unsigned long mask = PDC_FLAG_GEN_II | PDC_FLAG_4_PORTS;
+   return (flags & mask) == mask;
+}
+
+static inline unsigned int pdc_port_no_to_ata_no(unsigned int port_no, int 
is_sataii_tx4)
+{
+   static const unsigned char sataii_tx4_port_remap[4] = { 3, 1, 0, 2};
+   return is_sataii_tx4 ? sataii_tx4_port_remap[port_no] : port_no;
+}
+
 static irqreturn_t pdc_interrupt (int irq, void *dev_instance)
 {
struct ata_host *host = dev_instance;
@@ -807,7 +814,6 @@ static void pdc_tf_load_mmio(struct ata_
ata_tf_load(ap, tf);
 }
 
-
 static void pdc_exec_command_mmio(struct ata_port *ap, const struct 
ata_taskfile *tf)
 {
WARN_ON (tf->protocol == ATA_PROT_DMA ||
@@ -867,7 +873,6 @@ static void pdc_ata_setup_port(struct at
ap->ioaddr.scr_addr = scr_addr;
 }
 
-
 static void pdc_host_init(struct ata_host *host)
 {
void __iomem *mmio = host->iomap[PDC_MMIO_BAR];
@@ -955,10 +960,8 @@ static int pdc_ata_init_one (struct pci_
 
if (pi->flags & PDC_FLAG_SATA_PATA) {
u8 tmp = readb(base + PDC_FLASH_CTL+1);
-   if (!(tmp & 0x80)) {
+   if (!(tmp & 0x80))
ppi[n_ports++] = pi + 1;
-   dev_printk(KERN_INFO, >dev, "PATA port found\n");
-   }
}
 
host = ata_host_alloc_pinfo(>dev, ppi, n_ports);
@@ -968,22 +971,12 @@ static int pdc_ata_init_one (struct pci_
}
host->iomap = pcim_iomap_table(pdev);
 
-   is_sataii_tx4 = 0;
-   if ((pi->flags & (PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS)) == 
(PDC_FLAG_GEN_II|PDC_FLAG_4_PORTS)) {
-   is_sataii_tx4 = 1;
-   dev_printk(KERN_INFO, >dev, "applying SATAII TX4 port 

Re: Fix signalfd interaction with thread-private signals

[Davide Libenzi]

On Tue, 19 Jun 2007, Oleg Nesterov wrote:

> On 06/19, Benjamin Herrenschmidt wrote:
> >
> > On Tue, 2007-06-19 at 13:14 +0400, Oleg Nesterov wrote:
> > 
> > > The commited "Fix signalfd interaction with thread-private signals"
> > > (commit caec4e8dc85e0644ec24aeb36285e1ba02da58cc) doesn't implement
> > > this.
> > 
> > Indeed, if you want what Davide described, you need to also change
> > signalfd side. The patch I did merely prevents another thread from
> > dequeuing somebody else private signals.
> 
> Yes I see, but why do we need this change? Yes, we can dequeue SIGSEGV
> from another thread. Just don't do it if you have a handler for SIGSEGV?

I believe it can be confusing to have private signals dequeued from 
another thread. The kernel expect those to be dequeued by the target 
thread.


- Davide


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

Re: 2.6.21.5-rt15: BUG: scheduling with irqs disabled

[Fernando Lopez-Lezcano]

On Mon, 2007-06-18 at 17:20 -0700, Fernando Lopez-Lezcano wrote:
> Hi Ingo, I'm seeing this on 2.6.21.5-rt14 and 2.6.21.5-rt15, this
> problem did not happen in 2.6.21.3-rt9 (last I checked on this
> hardware). The computer is an athlon x2 and eth0 is "alias eth0 skge",
> the BUGs trigger on network activity (but not a constant stream of
> them)...

Seems to have been fixed in 2.6.21.5-rt17! (briefly booted into one
machine with the new build and so far no BUGs reported). 

Thanks!!!
-- Fernando


> BUG: scheduling with irqs disabled: IRQ-20/0x/1246
> caller is wait_for_completion+0x65/0x9b
>  [] dump_trace+0x64/0x105
>  [] show_trace_log_lvl+0x18/0x2c
>  [] show_trace+0xf/0x11
>  [] dump_stack+0x12/0x14
>  [] schedule+0x86/0xfa
>  [] wait_for_completion+0x65/0x9b
>  [] set_cpus_allowed+0x71/0x8f
>  [] do_softirq_from_hardirq+0xbd/0xda
>  [] do_irqd+0x1ff/0x24d
>  [] kthread+0xb0/0xd8
>  [] kernel_thread_helper+0x7/0x10
>  ===
> [EMAIL PROTECTED] ~]# cat /proc/interrupts
>CPU0   CPU1
>   0:251  1   IO-APIC-edge  timer
>   1:  0  2   IO-APIC-edge  i8042
>   6:  0  6   IO-APIC-edge  floppy
>   7:  1  0   IO-APIC-edge  parport0
>   8:  0  1   IO-APIC-edge  rtc
>   9:  0  0   IO-APIC-fasteoi   acpi
>  12:  0  4   IO-APIC-edge  i8042
>  14:  0   3724   IO-APIC-edge  ide0
>  16:   7591   5688   IO-APIC-fasteoi   ohci_hcd:usb1, libata
>  17:  1238   IO-APIC-fasteoi   ohci_hcd:usb2, NVidia
> CK8S
>  18:  0  3   IO-APIC-fasteoi   ehci_hcd:usb3
>  19:  0  0   IO-APIC-fasteoi   libata
>  20:  0   3028   IO-APIC-fasteoi   eth0
>  21:  0  2   IO-APIC-fasteoi   ohci1394, ICE1712
>  22:  17253   5916   IO-APIC-fasteoi   [EMAIL PROTECTED]::01:00.0
> NMI:  0  0
> LOC:  32953  36858
> ERR:  1
> MIS:  0


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

Re: [PATCH 1/2] rtc: add rtc-m41txx driver

[Mark A. Greer]

On Wed, Jun 20, 2007 at 12:59:26AM +0900, Atsushi Nemoto wrote:
> This is a new-style i2c driver for ST M41TXX RTC chip, derived from
> works by Alexander Bigga <[EMAIL PROTECTED]> who wrote the original
> rtc-m41txx.c based on drivers/i2c/chips/m41t00.c driver.
> 
> This driver supports M41T80, M41T81 and M41ST85.  The old m41t00
> driver supports M41T00, M41T81 and M41T85(M41ST85).  While the M41T00
> chip is now supported by rtc-ds1307 driver, this driver does not
> include support for the chip.
> 
> Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
> Signed-off-by: Alexander Bigga <[EMAIL PROTECTED]>

Other than addressing David's question about alarm support,

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

Re: [PATCH 2/2] UML - Add stack usage monitoring

[Jeff Dike]

On Tue, Jun 19, 2007 at 11:54:22AM -0700, Andrew Morton wrote:
> On Tue, 19 Jun 2007 14:42:45 -0400
> Jeff Dike <[EMAIL PROTECTED]> wrote:
> 
> > Add a machanism to see how much of a kernel stack is used.  This
> > allocates zeroed stacks and sees where the lowest non-zero byte is on
> > process exit.  It keeps track of the lowest value and logs values as
> > they get lower.
> > 
> 
> remind us again why the generic code is unsuitable?

It does something different - it will tell you the greatest stack
usage of any currently running process.  What I want to be able to do
is run a workload and come back a few days later and see how close
anything came to running out of stack.
> 
> > +   for(p = stack; p < end; p++){
> > +   if(*p != 0)
> > +   if(left < lowest_to_date){
> 
> Are there any plans to fix UML coding style?

You know I have been fixing it.  I forgot to eyeball this patch for
style - fixed patch below.

Jeff

-- 
Work email - jdike at linux dot intel dot com


Add a machanism to see how much of a kernel stack is used.  This
allocates zeroed stacks and sees where the lowest non-zero byte is on
process exit.  It keeps track of the lowest value and logs values as
they get lower.

Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
 arch/um/Kconfig.debug|9 +
 arch/um/defconfig|1 +
 arch/um/kernel/process.c |   29 +
 include/asm-um/thread_info.h |   16 
 4 files changed, 55 insertions(+)

Index: linux-2.6.21-mm/arch/um/Kconfig.debug
===
--- linux-2.6.21-mm.orig/arch/um/Kconfig.debug  2007-06-19 14:06:36.0 
-0400
+++ linux-2.6.21-mm/arch/um/Kconfig.debug   2007-06-19 14:06:44.0 
-0400
@@ -47,4 +47,13 @@ config GCOV
 If you're involved in UML kernel development and want to use gcov,
 say Y.  If you're unsure, say N.
 
+config DEBUG_STACK_USAGE
+   bool "Stack utilization instrumentation"
+   default N
+   help
+   Track the maximum kernel stack usage - this will look at each
+   kernel stack at process exit and log it if it's the deepest
+   stack seen so far.
+
+   This option will slow down process creation and destruction somewhat.
 endmenu
Index: linux-2.6.21-mm/arch/um/kernel/process.c
===
--- linux-2.6.21-mm.orig/arch/um/kernel/process.c   2007-06-19 
14:06:36.0 -0400
+++ linux-2.6.21-mm/arch/um/kernel/process.c2007-06-19 15:48:20.0 
-0400
@@ -411,3 +411,32 @@ unsigned long arch_align_stack(unsigned 
return sp & ~0xf;
 }
 #endif
+
+#ifdef CONFIG_DEBUG_STACK_USAGE
+
+static DEFINE_SPINLOCK(low_water_lock);
+static int lowest_to_date = THREAD_SIZE;
+
+void check_stack_usage(struct thread_info *s)
+{
+   unsigned int *stack, *p, *end;
+   int left;
+
+   stack = (unsigned int *) (s + 1);
+   end = (unsigned int *) ((unsigned long) s + THREAD_SIZE);
+   for (p = stack; p < end; p++) {
+   if(*p != 0)
+   break;
+   }
+
+   left = (p - stack) * sizeof(*p);
+
+   spin_lock(_water_lock);
+   if (left < lowest_to_date) {
+   printk("Greatest stack depth - %d bytes left\n", left);
+   lowest_to_date = left;
+   }
+   spin_unlock(_water_lock);
+}
+
+#endif
Index: linux-2.6.21-mm/include/asm-um/thread_info.h
===
--- linux-2.6.21-mm.orig/include/asm-um/thread_info.h   2007-06-19 
14:06:36.0 -0400
+++ linux-2.6.21-mm/include/asm-um/thread_info.h2007-06-19 
14:06:44.0 -0400
@@ -52,6 +52,20 @@ static inline struct thread_info *curren
return ti;
 }
 
+#ifdef CONFIG_DEBUG_STACK_USAGE
+
+extern void check_stack_usage(struct thread_info *stack);
+
+#define alloc_thread_info(tsk) \
+   ((struct thread_info *) __get_free_pages(GFP_KERNEL | __GFP_ZERO, \
+CONFIG_KERNEL_STACK_ORDER))
+
+#define free_thread_info(ti) ({ check_stack_usage(ti) ; \
+   free_pages((unsigned long)(ti), \
+  CONFIG_KERNEL_STACK_ORDER); })
+
+#else
+
 /* thread information allocation */
 #define alloc_thread_info(tsk) \
((struct thread_info *) __get_free_pages(GFP_KERNEL, \
@@ -61,6 +75,8 @@ static inline struct thread_info *curren
 
 #endif
 
+#endif
+
 #define PREEMPT_ACTIVE 0x1000
 
 #define TIF_SYSCALL_TRACE  0   /* syscall trace active */
Index: linux-2.6.21-mm/arch/um/defconfig
===
--- linux-2.6.21-mm.orig/arch/um/defconfig  2007-06-19 14:06:36.0 
-0400
+++ linux-2.6.21-mm/arch/um/defconfig   2007-06-19 14:06:44.0 -0400
@@ -527,3 +527,4 @@ CONFIG_FORCED_INLINING=y
 # 

Re: Fix signalfd interaction with thread-private signals

[Davide Libenzi]

On Tue, 19 Jun 2007, Oleg Nesterov wrote:

> The commited "Fix signalfd interaction with thread-private signals"
> (commit caec4e8dc85e0644ec24aeb36285e1ba02da58cc) doesn't implement
> this.
> 
> We can do something like
> 
>   int signalfd_dequeue_signal(struct task_struct *tsk, sigset_t *mask, 
> siginfo_t *info)
>   {
>   if (tsk->tgid == current->tgid)
>   tsk = current;
> 
>   return dequeue_signal(tsk, mask, info);
>   }
> 
> (still I can't understand why should we change signalfd).

Yes, of course. I was waiting for Ben's patch to go in, before fixing 
signalfd. I did not know if Linus would have acked that.



- Davide


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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[david]

On Tue, 19 Jun 2007, Daniel Hazelton wrote:


Dispute this:

non-tivoized hardware => users can scratch their itches => more
contributions from these users

tivoized hardware => users can't scratch their itches => fewer
contributions from these users


Linus doesn't have to. Statistically the number of people that will even think
of modifying the code running on a "tivoized" device is minute - at most 5%
of the users of such a device. Of those people the ones with the skill to
actually do the work is an even smaller number - figure 2.5 to 3% of them. Of
those  with the skill, probably about 10% of them are actually *good* enough
at it for their changes to be useful. Of that number, figure that only 25%,
at most, will contribute the changes back.

Apply that to a sample case:
"tivoized" device total users: 1,000,000
people that think about modifying: 50,000 (5%)
people with skill: 1500 (3%)
people who are good enough for the changes to be useful: 150 (10%)
those who will contribute them back: 38 (25%)


based on my experiance looking at the software released for tivos, I think 
you are over-estimating these numbers. if there are more then a dozen 
people producing things that are good enough to be useful and releasing 
their results as opensource software I would be surprised.


and for all that the FSF is claiming that tivos can't being modified it's 
really not that hard to change.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 RT] Only check IRQ Thread affinity update if CPU affinity changed.

[Steven Rostedt]

This patch cleans up the softirq in hardirq change. The hard irq threads
pin themselves to one of the CPUs that the IRQ affinity is on.

This patch cleans up this by only updating the cpu affinity, if the cpu
that the thread is pinned on is no longer part of the IRQ affinity.

Signed-off-by: Steven Rostedt <[EMAIL PROTECTED]>

Index: linux-2.6-rt-test/kernel/irq/manage.c
===
--- linux-2.6-rt-test.orig/kernel/irq/manage.c
+++ linux-2.6-rt-test/kernel/irq/manage.c
@@ -762,13 +762,15 @@ static int do_irqd(void * __desc)
 
 #ifdef CONFIG_SMP
cpumask_t cpus_allowed, mask;
+   int pinned_cpu;
 
cpus_allowed = desc->affinity;
/*
 * Restrict it to one cpu so we avoid being migrated inside of
 * do_softirq_from_hardirq()
 */
-   mask = cpumask_of_cpu(first_cpu(desc->affinity));
+   pinned_cpu = first_cpu(desc->affinity);
+   mask = cpumask_of_cpu(pinned_cpu);
set_cpus_allowed(current, mask);
 #endif
current->flags |= PF_NOFREEZE | PF_HARDIRQ;
@@ -793,14 +795,15 @@ static int do_irqd(void * __desc)
/*
 * Did IRQ affinities change?
 */
-   if (!cpus_equal(cpus_allowed, desc->affinity)) {
+   if (!cpu_isset(pinned_cpu, desc->affinity)) {
cpus_allowed = desc->affinity;
/*
 * Restrict it to one cpu so we avoid being
 * migrated inside of
 * do_softirq_from_hardirq()
 */
-   mask = cpumask_of_cpu(first_cpu(desc->affinity));
+   pinned_cpu = first_cpu(desc->affinity);
+   mask = cpumask_of_cpu(pinned_cpu);
set_cpus_allowed(current, mask);
}
 #endif


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

[patch] sched: fix next_interval determination in idle_balance()

[Ingo Molnar]

2.6.22 must-have item - perhaps suitable for -stable too, because it was 
reproduced on 2.6.21.5 too.

-->
From: Christoph Lameter <[EMAIL PROTECTED]>
Subject: [patch] sched: fix next_interval determination in idle_balance()

Fix massive SMP imbalance on NUMA nodes observed on 2.6.21.5 with CFS. 
(and later on reproduced without CFS as well).

The intervals of domains that do not have SD_BALANCE_NEWIDLE must be 
considered for the calculation of the time of the next balance. 
Otherwise we may defer rebalancing forever and nodes might stay idle for 
very long times.

Siddha also spotted that the conversion of the balance interval to 
jiffies is missing. Fix that to.

From: Srivatsa Vaddagiri <[EMAIL PROTECTED]>

also continue the loop if !(sd->flags & SD_LOAD_BALANCE).

Tested-by: Paul E. McKenney <[EMAIL PROTECTED]>

It did in fact trigger under all three of mainline, CFS, and -rt 
including CFS -- see below for a couple of emails from last Friday 
giving results for these three on the AMD box (where it happened) and on 
a single-quad NUMA-Q system (where it did not, at least not with such 
severity).

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
 kernel/sched.c |   22 +-
 1 file changed, 13 insertions(+), 9 deletions(-)

Index: v/kernel/sched.c
===
--- v.orig/kernel/sched.c
+++ v/kernel/sched.c
@@ -2938,17 +2938,21 @@ static void idle_balance(int this_cpu, s
unsigned long next_balance = jiffies + 60 *  HZ;
 
for_each_domain(this_cpu, sd) {
-   if (sd->flags & SD_BALANCE_NEWIDLE) {
+   unsigned long interval;
+
+   if (!(sd->flags & SD_LOAD_BALANCE))
+   continue;
+
+   if (sd->flags & SD_BALANCE_NEWIDLE)
/* If we've pulled tasks over stop searching: */
pulled_task = load_balance_newidle(this_cpu,
-   this_rq, sd);
-   if (time_after(next_balance,
- sd->last_balance + sd->balance_interval))
-   next_balance = sd->last_balance
-   + sd->balance_interval;
-   if (pulled_task)
-   break;
-   }
+   this_rq, sd);
+
+   interval = msecs_to_jiffies(sd->balance_interval);
+   if (time_after(next_balance, sd->last_balance + interval))
+   next_balance = sd->last_balance + interval;
+   if (pulled_task)
+   break;
}
if (!pulled_task)
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: How would I do this? (expert tricks) OT

[Marc Perkel]

--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:

> 
> On Jun 19 2007 10:14, Marc Perkel wrote:
> >> 
> >> tcpdump -lni any port 25
> >> iptables -p tcp --dport 25 -j NFQUEUE
> >> ...
> >> 
> >
> >Thanks Jan, but I'm not sure it answers my
> question.
> 
> There's more than one way to do it.
> 
> One is...
>   tcpdump -lni eth0 tcp [extra operands to match SYN
> packets] |
>   myprogram
> 
> a longer one is to write your own netfilter
> userspace program
> that receives the TCP SYNs (by means of -j NFQUEUE)
> and does
> take action.
> 
> Another one is to use -j LOG and let your program
> parse
> down /var/log/firewall. Like
> 
>   iptables -A INPUT -p tcp --dport 25 --syn -j LOG
> --log-prefix "[evil]"
>   tail -f /var/log/firewall | grep '^\[evil\]' |
> myscript
> 
> myscript:
> #!/usr/bin/perl
> 
> while (defined(my $line = <>)) {
>   my($ip) = ($line =~ /SRC=(\S+)/);
>   # Do something
> }
> 
> >I want to run a script every time a connection
> attempt is made in real time
> 
> The scripts runs constantly, preferably.
> 
> >with the IP address as a parameter to the script.
> How would I do that? Suppose
> >my script is:
> >
> >iplog 
> >
> >
> >
> >
> >   
>
>
> >Take the Internet to Go: Yahoo!Go puts the Internet
> in your pocket: mail, news, photos & more. 
> >http://mobile.yahoo.com/go?refer=1GNXIC
> >

Thanks Jan,

I think what you sent me is workable. I noticed it
goes to the file /var/log/messages. Is there a way to
make it go to a specific file? Thanks a lot for your
help. I've been experimenting with some new and very
interesting ways to catch spam and this could be yet
another breakthrough.






  

Shape Yahoo! in your own image.  Join our Network Research Panel today!   
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 


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

Re: How would I do this? (expert tricks) OT

[Jan Engelhardt]

On Jun 19 2007 12:36, Marc Perkel wrote:
>
>Thanks Jan,
>
>I think what you sent me is workable. I noticed it
>goes to the file /var/log/messages. Is there a way to
>make it go to a specific file?

Configure your syslog daemon accordingly.


> Thanks a lot for your
>help. I've been experimenting with some new and very
>interesting ways to catch spam and this could be yet
>another breakthrough.



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] diskquota: 32bit quota tools on 64bit architectures

[Andrew Morton]

On Mon, 18 Jun 2007 12:21:47 +0400
Vasily Tarasov <[EMAIL PROTECTED]> wrote:

> From: Vasily Tarasov <[EMAIL PROTECTED]>
> 
> This patch should be applied after Arnd Bergmann's patch,
> that intoduces new compat types: 
> http://lkml.org/lkml/2007/6/15/98
> 
> OpenVZ Linux kernel team has discovered the problem 
> with 32bit quota tools working on 64bit architectures.
> In 2.6.10 kernel sys32_quotactl() function was replaced by sys_quotactl() with
> the comment "sys_quotactl seems to be 32/64bit clean, enable it for 32bit"
> However this isn't right. Look at if_dqblk structure:
> 
> struct if_dqblk {
> __u64 dqb_bhardlimit;
> __u64 dqb_bsoftlimit;
> __u64 dqb_curspace;
> __u64 dqb_ihardlimit;
> __u64 dqb_isoftlimit;
> __u64 dqb_curinodes;
> __u64 dqb_btime;
> __u64 dqb_itime;
> __u32 dqb_valid;
> };
> 
> For 32 bit quota tools sizeof(if_dqblk) == 0x44.
> But for 64 bit kernel its size is 0x48, 'cause of alignment!
> Thus we got a problem. Attached patch reintroduce sys32_quotactl() function,
> that handles this and related situations.
> 
> Signed-off-by: Vasily Tarasov <[EMAIL PROTECTED]>
> 
> ---
> 
> In OpenVZ technology 32 bit Virtual Environments over 
> 64 bit OS are common, hence we have customers, that complains on this bad 
> quota
> behaviour: 
> 
> # /usr/bin/quota
> quota: error while getting quota from /dev/sda1 for 0: Success
> 
> The reason is caused above.

Only x86_64 and ia64 are fixed.  Would it be correct to assume that the
other CONFIG_COMPAT architectures also need to be fixed?


> --- linux-2.6.22-rc4-fixed/arch/x86_64/ia32/ia32entry.S.orig  2007-06-14 
> 15:55:24.0 +0400
> +++ linux-2.6.22-rc4-fixed/arch/x86_64/ia32/ia32entry.S   2007-06-14 
> 16:22:52.0 +0400
> @@ -526,7 +526,7 @@ ia32_sys_call_table:
>   .quad sys_init_module
>   .quad sys_delete_module
>   .quad quiet_ni_syscall  /* 130  get_kernel_syms */
> - .quad sys_quotactl
> + .quad sys32_quotactl
>   .quad sys_getpgid
>   .quad sys_fchdir
>   .quad quiet_ni_syscall  /* bdflush */
> --- linux-2.6.22-rc4-fixed/arch/ia64/ia32/ia32_entry.S.orig   2007-06-14 
> 15:55:24.0 +0400
> +++ linux-2.6.22-rc4-fixed/arch/ia64/ia32/ia32_entry.S2007-06-14 
> 16:22:52.0 +0400
> @@ -304,7 +304,7 @@ ia32_syscall_table:
>   data8 sys_ni_syscall/* init_module */
>   data8 sys_ni_syscall/* delete_module */
>   data8 sys_ni_syscall/* get_kernel_syms */  /* 130 */
> - data8 sys_quotactl
> + data8 sys32_quotactl
>   data8 sys_getpgid
>   data8 sys_fchdir
>   data8 sys_ni_syscall/* sys_bdflush */
> --- linux-2.6.22-rc4-fixed/fs/quota.c.orig2007-06-14 15:55:26.0 
> +0400
> +++ linux-2.6.22-rc4-fixed/fs/quota.c 2007-06-18 12:00:56.0 +0400
> @@ -10,12 +10,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  /* Check validity of generic quotactl commands */
>  static int generic_quotactl_valid(struct super_block *sb, int type, int cmd, 
> qid_t id)
> @@ -384,3 +386,119 @@ asmlinkage long sys_quotactl(unsigned in
>  
>   return ret;
>  }
> +
> +#if defined(CONFIG_X86_64) || defined(CONFIG_IA64)
> +/*
> + * This code works only for 32 bit quota tools over 64 bit OS (x86_64, ia64)
> + * and is necessary due to alignment problems.
> + */
> +struct compat_if_dqblk {
> + compat_u64 dqb_bhardlimit;
> + compat_u64 dqb_bsoftlimit;
> + compat_u64 dqb_curspace;
> + compat_u64 dqb_ihardlimit;
> + compat_u64 dqb_isoftlimit;
> + compat_u64 dqb_curinodes;
> + compat_u64 dqb_btime;
> + compat_u64 dqb_itime;
> + compat_uint_t dqb_valid;
> +};
> +
> +/* XFS structures */
> +struct compat_fs_qfilestat {
> + compat_u64 dqb_bhardlimit;
> + compat_u64 qfs_nblks;
> + compat_uint_t qfs_nextents;
> +};
> +
> +struct compat_fs_quota_stat {
> + __s8qs_version;
> + __u16   qs_flags;
> + __s8qs_pad;
> + struct compat_fs_qfilestat  qs_uquota;
> + struct compat_fs_qfilestat  qs_gquota;
> + compat_uint_t   qs_incoredqs;
> + compat_int_tqs_btimelimit;
> + compat_int_tqs_itimelimit;
> + compat_int_tqs_rtbtimelimit;
> + __u16   qs_bwarnlimit;
> + __u16   qs_iwarnlimit;
> +};
> +
> +asmlinkage long sys32_quotactl(unsigned int cmd, const char __user *special,
> + qid_t id, void __user *addr)
> +{
> + unsigned int cmds;
> + struct if_dqblk __user *dqblk;
> + struct compat_if_dqblk __user *compat_dqblk;
> + struct fs_quota_stat __user *fsqstat;
> + struct compat_fs_quota_stat __user *compat_fsqstat;
> + compat_uint_t data;
> + u16 xdata;
> + long ret;
> +
> + cmds = cmd >> SUBCMDSHIFT;
> +
> + switch (cmds) {
> + case 

Re: limits on raid

[david]

On Tue, 19 Jun 2007, Phillip Susi wrote:


[EMAIL PROTECTED] wrote:

 one channel, 2 OS drives plus the 45 drives in the array.


Huh?  You can only have 16 devices on a scsi bus, counting the host adapter. 
And I don't think you can even manage that much reliably with the newer 
higher speed versions, at least not without some very special cables.


6 devices on the bus (2 OS drives, 3 promise drive shelves, controller 
card)



 yes I realize that there will be bottlenecks with this, the large capacity
 is to handle longer history (it's going to be a 30TB circular buffer being
 fed by a pair of OC-12 links)


Building one of those nice packet sniffers for the NSA to install on AT 
network eh? ;)


just for going back in time to track hacker actions at a bank.

I'm hopeing that once I figure out the drives the rest of the software 
will basicly boil down to tcpdump with the right options to write to a 
circular buffer of files.


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

Re: [RFC/PATCH] Documentation of kernel messages

[Arjan van de Ven]

On Tue, 2007-06-19 at 10:51 +0200, holzheu wrote:
> On Mon, 2007-06-18 at 18:36 -0700, Arjan van de Ven wrote:
> > On Mon, 2007-06-18 at 15:53 +0200, holzheu wrote:
> > > On Mon, 2007-06-18 at 06:12 -0700, Arjan van de Ven wrote:
> > > > On Mon, 2007-06-18 at 14:55 +0200, holzheu wrote:
> > > > > Hi Gerrit,
> > > > > 
> > > > > The common thing of your and our approach is, that we need an ID to
> > > > > identify a message either by:
> > > > 
> > > > 
> > > > Maybe I am missing something big, but why is an ID needed?
> > > > The message IS the ID right? That's the only thing that is robust
> > > > against code moving about
> > > 
> > > Yes. As already discussed with Pavel, it is one option to use the format
> > > string of the message as message ID. The disadvantage compared to
> > > message IDs like hashes is, that format strings might be even less
> > > unique than hashes 
> > 
> > if the hash comes from the string in the first place I have a hard time
> > believing that.
> > 
> 
> Just think of all messages containing %s, which can expand to every
> possible string.

of course you hash on the string before you do the format stuff


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.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: [PATCH -mm] add a kmem_cache for nsproxy objects

[Christoph Lameter]

On Tue, 19 Jun 2007, Andrew Morton wrote:

> On Mon, 18 Jun 2007 22:53:13 +0200
> Cedric Le Goater <[EMAIL PROTECTED]> wrote:
> 
> > +static int __init nsproxy_cache_init(void)
> > +{
> > +   nsproxy_cachep = kmem_cache_create("nsproxy", sizeof(struct nsproxy),
> > +  0, SLAB_PANIC, NULL, NULL);
> > +   return 0;
> > +}
> > +
> 
> Christoph added this cheesy KMEM_CACHE macro.  But I don't immediately recall
> the rationale so I'm a bit reluctant to ask people to use-the-cheesy-macro.
> 
> Perhaps he can remind us why it is there?

Because it simplifies the handling of slabs.

The above will could become:

nsproxy_cachep = KMEM_CACHE(nsproxy, SLAB_PANIC);

meaning create a cache for the nsproxy struct, the nsproxy name and the 
nsproxy size. See include/linux/slab.h.
˜

Re: [PATCH -mm] add a kmem_cache for nsproxy objects

[Christoph Lameter]

On Tue, 19 Jun 2007, Christoph Hellwig wrote:

> Hmm, I must have missed the macro going in.  Frankly speaking I plain hate
> it.  It's a rather useless obsfucation.

It makes the code easier to review and reduces errors by establishing a 
standard way of defining a slab with minimal effort. You can 
still do the  old style and create the kmem_cache_create parameter 
monsters that span lots of lines.

KMEM_CACHE can do it just by specifying two parameters.

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

Re: Versioning file system

[Jack Stone]

H. Peter Anvin wrote:
> Jack Stone wrote:
>> But that would cause havoc with shells which use ; to seperate commands.
>> Using ; would defiantly break userspace
>>
> 
> Not really.  It's just a bit awkward to use, but so's the whole concept.

I think we can all agree on that after this thread but I still don't
want people to have the wrong idea about the design.

Jack

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

Re: This is [Re:] How to improve the quality of the kernel[?].

[Stefan Richter]

Oleg Verych wrote:
[I wrote]
>> a) Would it save me more time than it costs me to fit into the system
>>(time that can be invested in actual debugging)?
>>This can only be answered after trying it.
> 
> I'm not a wizard, if i will answer now: "No." [1:]
> 
> [1:] Your User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 
> rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2

Seamonkey isn't interoperable with Debian's BTS?
Lucky me that I frequently use other MUAs too.
-- 
Stefan Richter
-=-=-=== -==- =--==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/7] Introduce a means of compacting memory within a zone

[Christoph Lameter]

On Tue, 19 Jun 2007, Mel Gorman wrote:

> When other mechanisms exist, they would be added here. Right now,
> isolate_lru_page() is the only one I am aware of.

Did you have a look at kmem_cache_vacate in the slab defrag patchset?

> > You do not need to check the result of migration? Page migration is a best 
> > effort that may fail.

> You're right. I used to check it for debugging purposes to make sure migration
> was actually occuring. It is not unusual still for a fair number of pages
> to fail to migrate. migration already uses a retry logic and I shouldn't
> be replicating it.
> 
> More importantly, by leaving the pages on the migratelist, I potentially
> retry the same migrations over and over again wasting time and effort not
> to mention that I keep pages isolated for much longer than necessary and
> that could cause stalling problems. I should be calling putback_lru_pages()
> when migrate_pages() tells me it failed to migrate pages.

No the putback_lru is done for you.
 
> I'll revisit this one. Thanks

You could simply ignore it if you do not care if its migrated or not.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/7] Memory Compaction v2

[Christoph Lameter]

On Tue, 19 Jun 2007, Mel Gorman wrote:

> Agreed. When I put this together first, I felt I would be able to isolate
> pages of different types on migratelist but that is not the case as migration
> would not be able to tell the difference between a LRU page and a pagetable
> page. I'll rename cc->migratelist to cc->migratelist_lru with the view to
> potentially adding cc->migratelist_pagetable or cc->migratelist_slab later.

Right. The particular issue with moving page table pages or slab pages is 
that you do not have a LRU. The page state needs to be established in a 
different way and there needs to be mechanism to ensure that the page is 
not currently being setup or torn down. For the slab pages I have relied 
on page->inuse > 0 to signify a page in use. I am not sure how one would 
realize that for page table pages.

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

[Christoph Lameter]

On Tue, 19 Jun 2007, Thomas Glanzmann wrote:

> it already is. But Debian Etch is stable which means there will no newer
> version of git in Debian Etch. Currently it is 1.4.whatever. When the
> next stable release is released, which takes some time with Debian,
> there will be a newer version of git shipped with it. So for the moment
> you have to a few choices to live with when you use Debian stable:
> 
> - Use the old git version 1.4
> - Build a newer version yourself
> - Use the backports or any other prebuild but up2date packages

The other choice that we developers usually make is to run either testing 
or unstable. "stable" is a synonym for obsolete ;-).

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

Re: v2.6.21.4-rt11

[Christoph Lameter]

On Tue, 19 Jun 2007, Srivatsa Vaddagiri wrote:

> On Tue, Jun 19, 2007 at 11:04:30AM +0200, Ingo Molnar wrote:
> > I'm wondering, why did this trigger under CFS and not on mainline? 
> > Mainline seems to have a similar problem in idle_balance() too, or am i 
> > misreading it?
> 
> The problem is there in mainline very much. I could recreate the problem
> with 2.6.22-rc5 (which doesnt have CFS) on that same hardware, with
> CONFIG_NUMA enabled.
> 
> Let me know if you needed anything else to be clarified.

This is a bugfix that needs to go into 2.6.22.

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

Re: Versioning file system

[H. Peter Anvin]

Jack Stone wrote:
> 
> But that would cause havoc with shells which use ; to seperate commands.
> Using ; would defiantly break userspace
> 

Not really.  It's just a bit awkward to use, but so's the whole concept.

-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: v2.6.21.4-rt11

[Christoph Lameter]

On Tue, 19 Jun 2007, Ingo Molnar wrote:

> I'm wondering, why did this trigger under CFS and not on mainline? 
> Mainline seems to have a similar problem in idle_balance() too, or am i 
> misreading it?

Right. The patch needs to go into mainline as well.

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

Re: Versioning file system

[Jack Stone]

H. Peter Anvin wrote:
> Chris Snook wrote:
>> I pointed out NetApp's .snapshot directories because that's a method
>> that uses legal path character, but doesn't break anything.  With this
>> method, userspace tools will have to be taught that : is suddenly a
>> special character.
> 
> Not to mention that the character historically used for this purpose is
> ; (semicolon.)

But that would cause havoc with shells which use ; to seperate commands.
Using ; would defiantly break userspace

Jack

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

Re: Versioning file system

[H. Peter Anvin]

Chris Snook wrote:
> I pointed out NetApp's .snapshot directories because that's a method
> that uses legal path character, but doesn't break anything.  With this
> method, userspace tools will have to be taught that : is suddenly a
> special character.

Not to mention that the character historically used for this purpose is
; (semicolon.)

-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: Versioning file system

[Jack Stone]

Chris Snook wrote:
> But what you're talking about *will* break userspace.  If I do an ls in
> a directory, and get pages upon pages of versions of just one file,
> that's broken.  If I tar up a directory and get a tarball that's
> hundreds of times larger than it should be, that's broken.  If you want
> the files to be hidden from userspace applications that don't know about
> your backup scheme, (and it sounds like you do) then use the existing
> convention for hidden files, the prepended '.'  This is the universal
> sign for "don't mess with me unless you know what you're doing".

The idea was that if you did an ls you would get the latest version of
the file without the :revision_num. The only visible version would be
the latest version, i.e. the current system would not change. The idea
was that it would only show earlier versions if they were specifically
requested with a :revision_num suffix. In that case the
filesystem/kernel would need to recognise the suffix and return the
earlier version of the file.

The only userspace it would break is files with :num in their name, as I
haven't seen any files like that I don't think its too big a problem but
the way of specifiying revisions could be changed.

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

Re: Change in default vm_dirty_ratio

[Linus Torvalds]

On Tue, 19 Jun 2007, Linus Torvalds wrote:
> 
> Yes. It should depend on:
>  - speed of the device(s) in question

Btw, this one can be quite a big deal. Try connecting an iPod and syncing 
8GB of data to it. Oops.

So yes, it would be nice to have some per-device logic too. Tested patches 
would be very welcome ;)

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: Device hang when offlining a CPU due to IRQ misrouting

[Darrick J. Wong]

On Tue, Jun 19, 2007 at 11:00:03AM -0700, Siddha, Suresh B wrote:
> Anyhow, Darrick there is a general bug in this area, can you try this and
> see if it helps?

Er... that instantly locked up the system.

--D


signature.asc
Description: Digital signature

Re: Change in default vm_dirty_ratio

[Linus Torvalds]

On Tue, 19 Jun 2007, John Stoffel wrote:
> 
> Shouldn't the vm_dirty_ratio be based on the speed of the device, and
> not the size of memory?

Yes. It should depend on:
 - speed of the device(s) in question
 - seekiness of the workload
 - wishes of the user as per the latency of other operations.

However, nobody has ever found the required algorithm.

So "at most 10% of memory dirty" is a simple (and fairly _good_) 
heuristic. Nobody has actually ever ended up complaining about the change 
from 40% -> 10%, and as far as I know this was the first report (and it's 
not so much because the change was bad, but because it showed up on a 
benchmark - and I don't think that actually says anythign about anything 
else then the behaviour of the benchmark itself)

So are there better algorithms in theory? Probably lots of them.

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

Re: [PATCH] remove usage of memmem from scripts/kallsyms.c

[Christoph Hellwig]

On Tue, Jun 19, 2007 at 05:15:56PM +0100, Paulo Marques wrote:
> 
> The only in-kernel user of "memmem" is scripts/kallsyms.c and it only 
> uses it to find tokens that are 2 bytes in size. It is trivial to 
> replace it with a simple function that finds 2-byte tokens.
> 
> This should help users from systems that don't have the memmem GNU 
> extension available.

Please add a comment describing why it's there so that it's not ripped
out again by the first janitor looking over the code.

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

Re: [linux-usb-devel] Error -71 on device descriptor read/all

[Alan Stern]

On Tue, 19 Jun 2007, Paul Walmsley wrote:

> On Tue, 19 Jun 2007, Oliver Neukum wrote:
> 
> > Am Dienstag, 19. Juni 2007 schrieb Chuck Ebbert:
> >
> >> Try disabling CONFIG_USB_SUSPEND
> >>
> >> [usb developers: what are the drawbacks of doing this?]
> >
> > Increased power consumption.
> 
> speaking of CONFIG_USB_SUSPEND, I've encountered at least one device -- a 
> Canon EOS 5D camera -- that, after the bus suspends, must be powercycled 
> in order to return the camera's interrupt endpoints to a functional state. 
> How are these types of problems handled, currently?  Is this something for 
> a blacklist?

There are a few possible approaches.  One is indeed a blacklist, to 
prevent the camera from automatically being suspended.  Another is to 
prevent it by changing a device parameter in sysfs.

Note that neither of these will help if you do a suspend-to-RAM.  That 
suspends everything.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 -mm] add a kmem_cache for nsproxy objects

[Christoph Hellwig]

On Tue, Jun 19, 2007 at 11:35:01AM -0700, Andrew Morton wrote:
> On Mon, 18 Jun 2007 22:53:13 +0200
> Cedric Le Goater <[EMAIL PROTECTED]> wrote:
> 
> > +static int __init nsproxy_cache_init(void)
> > +{
> > +   nsproxy_cachep = kmem_cache_create("nsproxy", sizeof(struct nsproxy),
> > +  0, SLAB_PANIC, NULL, NULL);
> > +   return 0;
> > +}
> > +
> 
> Christoph added this cheesy KMEM_CACHE macro.  But I don't immediately recall
> the rationale so I'm a bit reluctant to ask people to use-the-cheesy-macro.
> 
> Perhaps he can remind us why it is there?

Hmm, I must have missed the macro going in.  Frankly speaking I plain hate
it.  It's a rather useless obsfucation.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.22: ERROR: "__ucmpdi2" [drivers/net/s2io.ko] undefined!

[Olaf Hering]

What happend to __ucmpdi2 from David Woodhouse?
google has a few hits about stuff like this on 32bit powerpc with gcc 4.1.2:

ERROR: "__ucmpdi2" [drivers/net/s2io.ko] undefined!

using the drivers/net/s2io* files from 2.6.21 with 2.6.22-rc5 fixes the
compile.

25805dcf9d83098cf5492117ad2669cd14cc9b24 adds two u64 >>= 48 followed by
a switch statement (line 2889 and 6816).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Change in default vm_dirty_ratio

[Andi Kleen]

Andrew Morton <[EMAIL PROTECTED]> writes:
> 
> It seems too large.  Memory sizes are going up faster than disk throughput
> and it seems wrong to keep vast amounts of dirty data floating about in
> memory like this.  It can cause long stalls while the system writes back
> huge amounts of data and is generally ill-behaved.

A more continuous write out would be better I think. Perhaps the dirty ratio 
needs to be per address space?

> things are trivially tunable and you'd think that after all these years,
> distro initscripts would be establishing the settings, based upon expected
> workload, amount of memory, number and bandwidth of attached devices, etc.

Distro initscripts normally don't have any better clue about any of this
than the kernel.

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

Re: [linux-usb-devel] Error -71 on device descriptor read/all

[Alan Stern]

On Tue, 19 Jun 2007, Jiri Kosina wrote:

> [ OK, it probably seems like a faulty hardware (controller or the device 
>   itself), which is not able to run at high speed, but runs nicely on full 
>   speed. Do you have a chance to try another high speed device in this 
>   machine to check whether it works?
> 
>   Adding linux-usb-devel into CC , just in case, and leaving the full 
>   original message below ]
> 
> On Tue, 19 Jun 2007, Renato S. Yamane wrote:
> 
> > Jiri Kosina wrote:
> > > On Tue, 19 Jun 2007, Renato S. Yamane wrote:
> > > > I see this in dmesg:
> > > > usb 1-1: device descriptor read/all, error -71
> > > 
> > > Is this a USB 2.0 high-speed device?
> > 
> > lspci -v | grep 1d.7
> > 00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 
> > Family)
> > USB2 EHCI Controller (rev 04) (prog-if 20 [EHCI])
> > 
> > My machine is a Laptop Toshiba M45-S355
> > 
> > > Don't you for example have USB extension cable too long to work on-high
> > > speed?
> > 
> > My only USB device is a mouse (Microsoft Notebook Optical Mouse) without
> > extension cable (I use original cable, with less than 3 feets).
> > 
> > > I guess the situation improves when you force USB 1.1 (i.e. rmmod 
> > > ehci_hcd),
> > > right?
> > 
> > #rmmode ehci_hcd
> > #tail /var/log/messages
> > 
> > kernel: ehci_hcd :00:1d.7: remove, state 4
> > kernel: usb usb5: USB disconnect, address 1
> > kernel: ehci_hcd :00:1d.7: USB bus 5 deregistered
> > kernel: ACPI: PCI interrupt for device :00:1d.7 disabled
> > 
> > I don't see any error (-71).
> > 
> > #modprobe ehci_hcd
> > #tail /var/log/messages
> > kernel: ACPI: PCI Interrupt :00:1d.7[A] -> Link [LNKH] -> GSI 10 (level,
> > low) -> IRQ 10
> > kernel: ehci_hcd :00:1d.7: EHCI Host Controller
> > kernel: ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 5
> > kernel: ehci_hcd :00:1d.7: debug port 1
> > kernel: ehci_hcd :00:1d.7: irq 10, io mem 0xf400
> > kernel: ehci_hcd :00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 
> > 2004
> > kernel: usb usb5: configuration #1 chosen from 1 choice
> > kernel: hub 5-0:1.0: USB hub found
> > kernel: hub 5-0:1.0: 8 ports detected
> > kernel: usb 1-1: USB disconnect, address 4
> > kernel: usb 1-1: new low speed USB device using uhci_hcd and address 5
> > kernel: usb 1-1: configuration #1 chosen from 1 choice
> > kernel: input: Microsoft Microsoft 3-Button Mouse with IntelliEye? as 
> > /class/input/input8
> > kernel: input: USB HID v1.00 Mouse [Microsoft Microsoft 3-Button Mouse with
> > IntelliEye?] on usb-:00:1d.0-1
> > 
> > This error is present only in dmesg, see below (line 8):
> > 
> > PCI: Setting latency timer of device :00:1d.7 to 64
> > ehci_hcd :00:1d.7: EHCI Host Controller
> > ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 5
> > ehci_hcd :00:1d.7: debug port 1
> > PCI: cache line size of 32 is not supported by device :00:1d.7
> > ehci_hcd :00:1d.7: irq 10, io mem 0xf400
> > ehci_hcd :00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
> > usb 1-1: device descriptor read/all, error -71
> > usb usb5: configuration #1 chosen from 1 choice
> > hub 5-0:1.0: USB hub found
> > hub 5-0:1.0: 8 ports detected
> > Clocksource tsc unstable (delta = -194969704 ns)
> > ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 6
> > PCI: setting IRQ 6 as level-triggered

Does the mouse work correctly, even with ehci-hcd loaded?

If it does then don't worry about the -71 error.  It appears to be 
transient and it's not necessarily fatal.

Alan Stern

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

Re: Writing a driver for a legacy serial device

[Dmitry Torokhov]

Hi Jean,

On 6/19/07, Jean Delvare <[EMAIL PROTECTED]> wrote:

Hi all,

I want to write a Linux kernel driver for a device which connects to
the legacy serial port. I started writing a driver, however I am
already stuck at the very beginning. The .connect function of my serial
driver is never called, and I just don't get why. I couldn't find any
documentation about writing such a legacy driver in Documentation nor
in LDD3. Is there anyone out there which could lend a helping hand?

I know that the device and my serial port both work. I can talk to the
device using minicom just fine. I have the following drivers loaded:

$ lsmod | grep 8250
8250_pnp   11648  0
8250   23464  1 8250_pnp
serial_core19392  1 8250

Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A

But I need to implement my driver in kernel space. My code looks like
this:

static struct serio_device_id taos_serio_ids[] = {
   {
   .type   = SERIO_RS232,
   .proto  = SERIO_ANY,
   .id = SERIO_ANY,
   .extra  = SERIO_ANY,
   },
   { 0 }
};
MODULE_DEVICE_TABLE(serio, taos_serio_ids);

static struct serio_driver taos_drv = {
   .driver = {
   .name   = "taos-evm",
   },
   .description= "TAOS evaluation module driver",
   .id_table   = taos_serio_ids,
   .connect= taos_connect,
   .disconnect = taos_disconnect,
   .interrupt  = taos_interrupt,
};

static int __init taos_init(void)
{
   return serio_register_driver(_drv);
}

static void __exit taos_exit(void)
{
   serio_unregister_driver(_drv);
}

The problem is that taos_connect is never called. I suppose that I need
different values for .type, .proto or .id, except that I just don't
know what to put there. I tried a few random values without success.
What's the trick?



You need to load serport modue and play with inputattach utility.

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

Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS

[Philipp Matthias Hahn]

Hello!

On Tue, Jun 19, 2007 at 08:04:57AM -0400, Chris Mason wrote:
> On Tue, Jun 19, 2007 at 10:11:13AM +0100, Pádraig Brady wrote:
> > Vladislav Bolkhovitin wrote:
> > > 
> > > I would also suggest one more feature: support for block level
> > > de-duplication. I mean:
...
> > > That would be very usable feature, which in most cases would allow to
> > > shrink occupied disk space on 50-90%.
> > 
> > Have you references for this number?
> > In my experience one gets a lot of benefit from
> > the much simpler process of "de-duplication" of files.
> 
> Yes, I would expect simple hard links to be a better solution for this,
> but the feature request is not that out of line.  I actually had plans
> on implementing auto duplicate block reuse earlier in btrfs.

One problem with hard-links for me is, they also share the meta-data,
especially file permissions and owners.

Take a Subversion checkout for example: For each file "$A" Subversion
saves a backup under ".svm/text-base/$A.svn-base" for file comparison
and diff generation. The user controls the file permissions of "$A",
Subversion protects its backup with 0444. You can't hard-link them,
because than "svn diff" doesn't work anymore if your editor doesn't
break the hard-link, or worse, your permissions can get wrong.

If previous versions Subversion also had an extra file for file
attributes (mime-type, permissions, to-be-ignored, etc.) Since most
files had no special attributes, each had a file only containing "END".
Those you could hard-link by hand to save space.

If somebody want to research this further:

There is this nice little package called "perforate", which contains
"finddup" to find duplicate files. Run it two times, once with "-i" to
ignore permissions while comparing file contents
finddup -i -d /
and once without "-i" for "content and permissions must match"
finddup -d /
This will give you a hint on how many files you could hard-link or how
many files share their content.

BYtE
Philipp
-- 
  / /  (_)__  __   __ Philipp Hahn
 / /__/ / _ \/ // /\ \/ /
//_/_//_/\_,_/ /_/\_\ [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/

3c59x: multiple problems

[Chuck Ebbert]

More and more people are reporting this error message:

Jun 18 19:54:33 loki kernel: NETDEV WATCHDOG: eth0: transmit timed out
Jun 18 19:54:33 loki kernel: eth0: transmit timed out, tx_status 00 status 8601.
Jun 18 19:54:33 loki kernel:   diagnostics: net 0ccc media 8880 dma 003a 
fifo 
Jun 18 19:54:33 loki kernel: eth0: Interrupt posted but not delivered -- IRQ
blocked by another device?
Jun 18 19:54:33 loki kernel:   Flags; bus-master 1, dirty 80643(3) current 
80643(3)
Jun 18 19:54:33 loki kernel:   Transmit list  vs. 81007852d3e0.
Jun 18 19:54:33 loki kernel:   0: @81007852d200  length 804a status 
0c01004a
Jun 18 19:54:33 loki kernel:   1: @81007852d2a0  length 802a status 
8001002a
Jun 18 19:54:33 loki kernel:   2: @81007852d340  length 802a status 
8001002a
Jun 18 19:54:33 loki kernel:   3: @81007852d3e0  length 803e status 
0001003e
Jun 18 19:54:33 loki kernel:   4: @81007852d480  length 803e status 
0001003e
Jun 18 19:54:33 loki kernel:   5: @81007852d520  length 803e status 
0001003e
Jun 18 19:54:33 loki kernel:   6: @81007852d5c0  length 8055 status 
0c010055
Jun 18 19:54:33 loki kernel:   7: @81007852d660  length 8055 status 
0c010055
Jun 18 19:54:33 loki kernel:   8: @81007852d700  length 802a status 
0001002a
Jun 18 19:54:33 loki kernel:   9: @81007852d7a0  length 8055 status 
0c010055
Jun 18 19:54:33 loki kernel:   10: @81007852d840  length 8055 status 
0c010055
Jun 18 19:54:33 loki kernel:   11: @81007852d8e0  length 802a status 
0001002a
Jun 18 19:54:33 loki kernel:   12: @81007852d980  length 8055 status 
0c010055
Jun 18 19:54:33 loki kernel:   13: @81007852da20  length 8055 status 
0c010055
Jun 18 19:54:33 loki kernel:   14: @81007852dac0  length 802a status 
0001002a
Jun 18 19:54:33 loki kernel:   15: @81007852db60  length 804a status 
0c01004a


And now, a new one from the same driver -- apparently it does request_irq() 
before
it's really ready to receive an interrupt:

Jun 17 21:16:22 loki kernel: Unable to handle kernel NULL pointer dereference at
00e0 RIP:
Jun 17 21:16:22 loki kernel:  [] 
:3c59x:boomerang_rx+0x1c0/0x509
Jun 17 21:16:22 loki kernel: PGD 36110067 PUD 3c30e067 PMD 0
Jun 17 21:16:23 loki kernel: Oops:  [1] SMP
Jun 17 21:16:23 loki kernel: last sysfs file: /class/net/eth0/address
Jun 17 21:16:23 loki kernel: CPU 0
Jun 17 21:16:23 loki kernel: Modules linked in: vfat fat usb_storage hfsplus
nf_nat_ftp iptable_nat nf_nat iptable_mangle nf_conntrack_ftp autofs4 it87
hwmon_vid i2c_isa eeprom sunrpc ipv6 nf_conntrack_netbios_ns nf_conntrack_ipv4
xt_state nf_conntrack nfnetlink xt_tcpudp ipt_REJECT iptable_filter ip_tables
x_tables dm_multipath raid1 video sbs i2c_ec button dock battery ac lp loop
snd_hda_intel snd_hda_codec snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm parport_pc snd_timer parport
serio_raw snd pcspkr k8_edac soundcore edac_mc k8temp hwmon snd_page_alloc
i2c_nforce2 3c59x i2c_core mii shpchp forcedeth sr_mod cdrom sg dm_snapshot
dm_zero dm_mirror dm_mod pata_amd ata_generic sata_nv libata sd_mod scsi_mod
raid456 xor ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd
Jun 17 21:16:23 loki kernel: Pid: 4824, comm: ip Not tainted 2.6.21-1.3228.fc7 
#1
Jun 17 21:16:23 loki kernel: RIP: 0010:[] 
[] :3c59x:boomerang_rx+0x1c0/0x509
Jun 17 21:16:23 loki kernel: RSP: 0018:81003dd23c98  EFLAGS: 00010246
Jun 17 21:16:23 loki kernel: RAX:  RBX: 810065e41d80 RCX: 

Jun 17 21:16:23 loki kernel: RDX: 81007f0eb000 RSI:  RDI: 
81007f557870
Jun 17 21:16:23 loki kernel: RBP: 81007f0eb700 R08:  R09: 
810065e41d80
Jun 17 21:16:23 loki kernel: R10: 7fff5a892ea4 R11: 0246 R12: 
000c
Jun 17 21:16:23 loki kernel: R13: 003c R14: 003c R15: 
6000803c
Jun 17 21:16:23 loki kernel: FS:  2aab5810() 
GS:8059d000() knlGS:
Jun 17 21:16:23 loki kernel: CS:  0010 DS:  ES:  CR0: 8005003b
Jun 17 21:16:23 loki kernel: CR2: 00e0 CR3: 3c30d000 CR4: 
06e0
Jun 17 21:16:23 loki kernel: Process ip (pid: 4824, threadinfo 
81003dd22000, task 810016309100)
Jun 17 21:16:23 loki kernel: Stack:  81007f0eb000 07801000 
c2028000 001f7fee5d40
Jun 17 21:16:23 loki kernel:  6ad23812 fff4 
810058115680 8601
Jun 17 21:16:23 loki kernel:  81007f0eb700 81007f0eb000 
0010 88166e57
Jun 17 21:16:23 loki kernel: Call Trace:
Jun 17 21:16:23 loki kernel:  [] 
:3c59x:boomerang_interrupt+0x13b/0x3f1
Jun 17 21:16:23 loki kernel:  [] 
:3c59x:boomerang_interrupt+0x0/0x3f1
Jun 17 21:16:23 loki kernel:  [] request_irq+0xcc/0xfd
Jun 17 21:16:23 loki kernel:  [] :3c59x:vortex_open+0x44/0x20c
Jun 

Re: Device hang when offlining a CPU due to IRQ misrouting

[Eric W. Biederman]

"Siddha, Suresh B" <[EMAIL PROTECTED]> writes:

> On Tue, Jun 19, 2007 at 11:54:45AM -0600, Eric W. Biederman wrote:
>> "Darrick J. Wong" <[EMAIL PROTECTED]> writes:
>> 
>> > On Mon, Jun 18, 2007 at 04:54:34PM -0700, Siddha, Suresh B wrote:
>> >
>> >> > 
>> >> > [  256.298787] irq=4341 affinity=d
>> >> > 
>> >> 
>> >> And just to make sure, at this point, your MSI irq 4341 affinity
>> >> (/proc/irq/4341/smp_affinity) still points to '2'?
>> >
>> > Actually, it's 0xD.  From the kernel's perspective the mask has been
>> > updated (and I even stuck a printk into set_msi_irq_affinity to verify
>> > that the writes are happening) but ... the hardware doesn't seem to
>> > reflect this.  I also tried putting read_msi_msg right afterwards to
>> > compare contents, though it complained about all the MSIs _except_ for
>> > 4341.  (Of course, I could just be way off on the effectiveness of
>> > that.)
>> 
>> The fact that MSI interrupts are having problems is odd.  It is possible
>> that we still have a bug in there somewhere but msi interrupts should
>> be safe to migrate outside of irq context (no known hardware bugs).
>> As we can actually synchronize with the irq source and eliminate all
>> of the migration races.
>> 
>> The non-msi case requires hitting a hardware race that is rare enough
>> you should not normally have problems.
>
> Yep. But Darrick's seems to say, problem happens consistently.
>
> Anyhow, Darrick there is a general bug in this area, can you try this and
> see if it helps?

There are several general bugs in this area.  But yes your patch
should help things, especially for MSI where masking the irq before
migration is required.  Adding locking the proper locking and masking
should make things quite a bit more how set_affinity is expected to be
called.

I just gave up on fixing these things because we can't eliminate
the races, so the real problem is the existence of this code path
with it's unsupportable semantics in the first place.

> diff --git a/arch/x86_64/kernel/irq.c b/arch/x86_64/kernel/irq.c
> index 3eaceac..a0e11c9 100644
> --- a/arch/x86_64/kernel/irq.c
> +++ b/arch/x86_64/kernel/irq.c
> @@ -144,17 +144,35 @@ void fixup_irqs(cpumask_t map)
>  
>   for (irq = 0; irq < NR_IRQS; irq++) {
>   cpumask_t mask;
> + int break_affinity = 0;
> + int set_affinity = 1;
> +
>   if (irq == 2)
>   continue;
>  
> + /* irq's are disabled at this point */
> + spin_lock(_desc[irq].lock);
> +
>   cpus_and(mask, irq_desc[irq].affinity, map);
>   if (any_online_cpu(mask) == NR_CPUS) {
> - printk("Breaking affinity for irq %i\n", irq);
> + break_affinity = 1;
>   mask = map;
>   }

We should really express the "any_online_cpu(mask) == NR_CPUS" test as:
"cpus_empty(mask)" it would be much clearer.

Further we should skip the migration if "cpus_equal(mask,
irq_desc[irq].affinity)" or "!irq_has_action(irq)" because no one has
called request_irq.


> + irq_desc[irq].chip->mask(irq);
> +
>   if (irq_desc[irq].chip->set_affinity)
>   irq_desc[irq].chip->set_affinity(irq, mask);
>   else if (irq_desc[irq].action && !(warned++))
> + set_affinity = 0;
> +
> + irq_desc[irq].chip->unmask(irq);
> +
> + spin_unlock(_desc[irq].lock);
> +
> + if (break_affinity && set_affinity)
> + printk("Broke affinity for irq %i\n", irq);
> + else if (!set_affinity)
>   printk("Cannot set affinity for irq %i\n", irq);
>   }
>  
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-usb-devel] Error -71 on device descriptor read/all

[Oliver Neukum]

Am Dienstag, 19. Juni 2007 schrieb Paul Walmsley:
> On Tue, 19 Jun 2007, Oliver Neukum wrote:
> 
> > Am Dienstag, 19. Juni 2007 schrieb Chuck Ebbert:
> >
> >> Try disabling CONFIG_USB_SUSPEND
> >>
> >> [usb developers: what are the drawbacks of doing this?]
> >
> > Increased power consumption.
> 
> speaking of CONFIG_USB_SUSPEND, I've encountered at least one device -- a 
> Canon EOS 5D camera -- that, after the bus suspends, must be powercycled 
> in order to return the camera's interrupt endpoints to a functional state. 
> How are these types of problems handled, currently?  Is this something for 
> a blacklist?

drivers/usb/core/quirks.c

Please try the reset-resume quirk before you use the no-autosuspend quirk.

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/

Re: [PATCH 2/2] UML - Add stack usage monitoring

[Andrew Morton]

On Tue, 19 Jun 2007 14:42:45 -0400
Jeff Dike <[EMAIL PROTECTED]> wrote:

> Add a machanism to see how much of a kernel stack is used.  This
> allocates zeroed stacks and sees where the lowest non-zero byte is on
> process exit.  It keeps track of the lowest value and logs values as
> they get lower.
> 

remind us again why the generic code is unsuitable?

> + for(p = stack; p < end; p++){
> + if(*p != 0)
> + if(left < lowest_to_date){

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

RE: [PATCH 1/1] cciss: add new controller support for P700m

[Miller, Mike (OS Dev)]

 

> -Original Message-
> From: Jens Axboe [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, June 19, 2007 1:51 PM
> To: Miller, Mike (OS Dev)
> Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org; 
> [EMAIL PROTECTED]
> Subject: Re: [PATCH 1/1] cciss: add new controller support for P700m
> 
> On Tue, Jun 19 2007, Mike Miller (OS Dev) wrote:
> > PATCH 1/1
> > 
> > This patch adds support for the Smart Array P700m SAS 
> controller. This 
> > new controller will ship Fall 2008. Please consider this 
> for inclusion.
> 
> Fall 2007?

Thank you. Yes, 2007. I forgot where I was for a moment. :)

mikem

> 
> Queued for 2.6.23.
> 
> --
> 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/

[PATCH RT] Only allow atomic safe consoles to print in atomic areas.

[Steven Rostedt]

Since PREEMPT_RT makes spin_locks schedule, and some consoles (namely
serial) use spin locks in the write method.  This patch creates a new
console flag called CON_ATOMIC which is set by safe consoles that do not
grab spinlocks.

On PREEMPT_RT only safe consoles will write within non atomic operations
(and not in a oops).

Signed-off-by: Steven Rostedt

Index: linux-2.6-rt-test/arch/x86_64/kernel/early_printk.c
===
--- linux-2.6-rt-test.orig/arch/x86_64/kernel/early_printk.c
+++ linux-2.6-rt-test/arch/x86_64/kernel/early_printk.c
@@ -56,7 +56,7 @@ static void early_vga_write(struct conso
 static struct console early_vga_console = {
.name = "earlyvga",
.write =early_vga_write,
-   .flags =CON_PRINTBUFFER,
+   .flags =CON_PRINTBUFFER | CON_ATOMIC,
.index =-1,
 };
 
@@ -152,7 +152,7 @@ static __init void early_serial_init(cha
 static struct console early_serial_console = {
.name = "earlyser",
.write =early_serial_write,
-   .flags =CON_PRINTBUFFER,
+   .flags =CON_PRINTBUFFER | CON_ATOMIC,
.index =-1,
 };
 
@@ -193,7 +193,7 @@ static void simnow_write(struct console 
 static struct console simnow_console = {
.name = "simnow",
.write =simnow_write,
-   .flags =CON_PRINTBUFFER,
+   .flags =CON_PRINTBUFFER | CON_ATOMIC,
.index =-1,
 };
 
Index: linux-2.6-rt-test/drivers/char/vt.c
===
--- linux-2.6-rt-test.orig/drivers/char/vt.c
+++ linux-2.6-rt-test/drivers/char/vt.c
@@ -2317,7 +2317,7 @@ static struct console vt_console_driver 
.write  = vt_console_print,
.device = vt_console_device,
.unblank= unblank_screen,
-   .flags  = CON_PRINTBUFFER,
+   .flags  = CON_PRINTBUFFER | CON_ATOMIC,
.index  = -1,
 };
 #endif
Index: linux-2.6-rt-test/include/linux/console.h
===
--- linux-2.6-rt-test.orig/include/linux/console.h
+++ linux-2.6-rt-test/include/linux/console.h
@@ -92,6 +92,17 @@ void give_up_console(const struct consw 
 #define CON_ENABLED(4)
 #define CON_BOOT   (8)
 #define CON_ANYTIME(16) /* Safe to call when cpu is offline */
+#define CON_ATOMIC (32) /* Safe to call in PREEMPT_RT atomic */
+
+#ifdef CONFIG_PREEMPT_RT
+# define console_atomic_safe(con)  \
+   (((con)->flags & CON_ATOMIC) || \
+(!in_atomic() && !irqs_disabled()) ||  \
+(system_state != SYSTEM_RUNNING) ||\
+oops_in_progress)
+#else
+# define console_atomic_safe(con) (1)
+#endif
 
 struct console
 {
Index: linux-2.6-rt-test/kernel/printk.c
===
--- linux-2.6-rt-test.orig/kernel/printk.c
+++ linux-2.6-rt-test/kernel/printk.c
@@ -328,6 +328,7 @@ static void __call_console_drivers(unsig
touch_critical_timing();
for (con = console_drivers; con; con = con->next) {
if ((con->flags & CON_ENABLED) && con->write &&
+   console_atomic_safe(con) &&
(cpu_online(raw_smp_processor_id()) ||
(con->flags & CON_ANYTIME))) {
/*


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Documentation/HOWTO: remove stale git URL

[Stefan Richter]

and mention MAINTAINERS as pointer to development trees.

Signed-off-by: Stefan Richter <[EMAIL PROTECTED]>
---
 Documentation/HOWTO |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

Index: linux-2.6.22-rc5/Documentation/HOWTO
===
--- linux-2.6.22-rc5.orig/Documentation/HOWTO
+++ linux-2.6.22-rc5/Documentation/HOWTO
@@ -336,9 +336,6 @@ Here is a list of some of the different 
 - ia64 development tree, Tony Luck <[EMAIL PROTECTED]>
kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
 
-- ieee1394 development tree, Jody McIntyre <[EMAIL PROTECTED]>
-   kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394.git
-
 - infiniband, Roland Dreier <[EMAIL PROTECTED]>
kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
 
@@ -354,14 +351,15 @@ Here is a list of some of the different 
 - SCSI, James Bottomley <[EMAIL PROTECTED]>
kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
 
-  Other git kernel trees can be found listed at http://kernel.org/git
-
   quilt trees:
 - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman <[EMAIL PROTECTED]>
kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
 - x86-64, partly i386, Andi Kleen <[EMAIL PROTECTED]>
 ftp.firstfloor.org:/pub/ak/x86_64/quilt/
 
+  Other kernel trees can be found listed at http://kernel.org/git and in
+  the MAINTAINERS file.
+
 Bug Reporting
 -
 

-- 
Stefan Richter
-=-=-=== -==- =--==
http://arcgraph.de/sr/

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

Re: [PATCH 1/1] cciss: add new controller support for P700m

[Jens Axboe]

On Tue, Jun 19 2007, Mike Miller (OS Dev) wrote:
> PATCH 1/1
> 
> This patch adds support for the Smart Array P700m SAS controller. This new
> controller will ship Fall 2008. Please consider this for inclusion.

Fall 2007?

Queued for 2.6.23.

-- 
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: mount-2.12r-ggk.tar.gz

[Karel Zak]

On Tue, Jun 19, 2007 at 05:28:18PM +0200, Andries Brouwer wrote:
> > > The above mount makes a feeble attempt to record these flags
> > > in /etc/mtab, but will fail in any nontrivial situation.]
> > 
> >  I don't think that mtab is a good place for this shared subtree
> >  stuff. The mtab needs to die.
> 
> Perhaps. Perhaps not.
> 
> On the one hand I think there is a place for arbitrary user-space info
> about mounted filesystems. With information about who mounted, and at what 
> time.
> What the icon is that should represent this filesystem. What resources are
> associated to this mount, and which program must do the cleanup. Etc.
> Today there is not much user-space info, but there is some.

 See also the "[RFC] obsoleting /etc/mtab" thread:
 http://www.mail-archive.com/[EMAIL PROTECTED]/index.html#00208

Karel


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

[PATCH 1/1] cciss: add new controller support for P700m

[Mike Miller (OS Dev)]

PATCH 1/1

This patch adds support for the Smart Array P700m SAS controller. This new
controller will ship Fall 2008. Please consider this for inclusion.

Signed-off-by: Mike Miller <[EMAIL PROTECTED]>


diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c
index 5acc6c4..0fcad43 100644
--- a/drivers/block/cciss.c
+++ b/drivers/block/cciss.c
@@ -87,6 +87,7 @@ static const struct pci_device_id cciss_
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSD, 0x103C, 0x3214},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSD, 0x103C, 0x3215},
{PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSC, 0x103C, 0x3237},
+   {PCI_VENDOR_ID_HP, PCI_DEVICE_ID_HP_CISSC, 0x103C, 0x323D},
{PCI_VENDOR_ID_HP, PCI_ANY_ID,  PCI_ANY_ID, PCI_ANY_ID,
PCI_CLASS_STORAGE_RAID << 8, 0x << 8, 0},
{0,}
@@ -119,6 +120,7 @@ static struct board_type products[] = {
{0x3214103C, "Smart Array E200i", _access, 120},
{0x3215103C, "Smart Array E200i", _access, 120},
{0x3237103C, "Smart Array E500", _access, 512},
+   {0x323D103C, "Smart Array P700m", _access, 512},
{0x103C, "Unknown Smart Array", _access, 120},
 };
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] remove usage of memmem from scripts/kallsyms.c

[Satyam Sharma]

Hi,

On 6/19/07, Paulo Marques <[EMAIL PROTECTED]> wrote:


The only in-kernel user of "memmem" is scripts/kallsyms.c and it only
uses it to find tokens that are 2 bytes in size. It is trivial to
replace it with a simple function that finds 2-byte tokens.

This should help users from systems that don't have the memmem GNU
extension available.


So we could remove the "#define _GNU_SOURCE" at the top
of scripts/kallsyms.c too, presumably? If not (i.e. if there are
more GNUisms left in that file anyway), then I'm not sure if we
really gain by the change.

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

Re: This is [Re:] How to improve the quality of the kernel[?].

[Oleg Verych]

* Date: Tue, 19 Jun 2007 19:50:48 +0200
> 
> [...]
>> Current identification of problems and patch association
>> have completely zero level of tracking or automation, while Bugzilla is
>> believed by somebody to have positive efficiency in bug tracking.
>
> I, as maintainer of a small subsystem, can personally track bug--patch
> relationships with bugzilla just fine, on its near-zero level of
> automation and integration.
>
> Nevertheless, would a more integrated bug/patch tracking system help me
> improve quality of my output? ---
> a) Would it save me more time than it costs me to fit into the system
>(time that can be invested in actual debugging)?
>This can only be answered after trying it.

I'm not a wizard, if i will answer now: "No." [1:]

[1:] Your User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 
rv:1.8.1.4) Gecko/20070509 SeaMonkey/1.1.2

> b) Would it help me to spot mistakes in patches before I submit?
>No.

If you ever tried to report bug with reportbug tool in Debian, you may
understand what i meant. Nothing can substitute intelligence. Something
can reduce impact of laziness (of searching relevant bugreports).

> c) Would I get quicker feedback from testers?
>That depends on whether such a system attracts testers and helps
>testers to work efficiently.  This is also something that can only be
>speculated about without trying it.
>
> The potential testers that I deal with are mostly either very
> non-technical persons, or persons which are experienced in their
> hardware/application area but *not* in kernel internals and kernel
> development procedures.

They also don't bother subscribing to mailing lists and like to write
blogs. I'm not sure about hw databases you talked about, i will talk
about gathering information from testers.

Debian have experimental and unstable branches, people willing to have
new stuff are likely to have this, and not testing or stable. BTS just
collects bugreports . If kernel team uploads new
kernel (release or even rc recently), interested people will use it after
next upgrade. Bug reports get collected, but main answer will be, try
reproduce on most recent kernel.org's one. Here, what i have proposed,
may play role you expect. Mis-configuration/malfunctioning, programmer's
error (Linus noted) in organized manner may easily join reporting person
to kernel.org's testing. On driver or small sub-system level this may
work. Again it's all about information, not intelligence.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/2] UML - Add stack usage monitoring

[Jeff Dike]

Add a machanism to see how much of a kernel stack is used.  This
allocates zeroed stacks and sees where the lowest non-zero byte is on
process exit.  It keeps track of the lowest value and logs values as
they get lower.

Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
 arch/um/Kconfig.debug|9 +
 arch/um/defconfig|1 +
 arch/um/kernel/process.c |   29 +
 include/asm-um/thread_info.h |   16 
 4 files changed, 55 insertions(+)

Index: linux-2.6.21-mm/arch/um/Kconfig.debug
===
--- linux-2.6.21-mm.orig/arch/um/Kconfig.debug  2007-06-19 13:37:16.0 
-0400
+++ linux-2.6.21-mm/arch/um/Kconfig.debug   2007-06-19 14:05:59.0 
-0400
@@ -47,4 +47,13 @@ config GCOV
 If you're involved in UML kernel development and want to use gcov,
 say Y.  If you're unsure, say N.
 
+config DEBUG_STACK_USAGE
+   bool "Stack utilization instrumentation"
+   default N
+   help
+   Track the maximum kernel stack usage - this will look at each
+   kernel stack at process exit and log it if it's the deepest
+   stack seen so far.
+
+   This option will slow down process creation and destruction somewhat.
 endmenu
Index: linux-2.6.21-mm/arch/um/kernel/process.c
===
--- linux-2.6.21-mm.orig/arch/um/kernel/process.c   2007-06-19 
13:37:16.0 -0400
+++ linux-2.6.21-mm/arch/um/kernel/process.c2007-06-19 14:01:55.0 
-0400
@@ -411,3 +411,32 @@ unsigned long arch_align_stack(unsigned 
return sp & ~0xf;
 }
 #endif
+
+#ifdef CONFIG_DEBUG_STACK_USAGE
+
+static DEFINE_SPINLOCK(low_water_lock);
+static int lowest_to_date = THREAD_SIZE;
+
+void check_stack_usage(struct thread_info *s)
+{
+   unsigned int *stack, *p, *end;
+   int left;
+
+   stack = (unsigned int *) (s + 1);
+   end = (unsigned int *) ((unsigned long) s + THREAD_SIZE);
+   for(p = stack; p < end; p++){
+   if(*p != 0)
+   break;
+   }
+
+   left = (p - stack) * sizeof(*p);
+
+   spin_lock(_water_lock);
+   if(left < lowest_to_date){
+   printk("Greatest stack depth - %d bytes left\n", left);
+   lowest_to_date = left;
+   }
+   spin_unlock(_water_lock);
+}
+
+#endif
Index: linux-2.6.21-mm/include/asm-um/thread_info.h
===
--- linux-2.6.21-mm.orig/include/asm-um/thread_info.h   2007-06-19 
13:37:16.0 -0400
+++ linux-2.6.21-mm/include/asm-um/thread_info.h2007-06-19 
13:57:07.0 -0400
@@ -52,6 +52,20 @@ static inline struct thread_info *curren
return ti;
 }
 
+#ifdef CONFIG_DEBUG_STACK_USAGE
+
+extern void check_stack_usage(struct thread_info *stack);
+
+#define alloc_thread_info(tsk) \
+   ((struct thread_info *) __get_free_pages(GFP_KERNEL | __GFP_ZERO, \
+CONFIG_KERNEL_STACK_ORDER))
+
+#define free_thread_info(ti) ({ check_stack_usage(ti) ; \
+   free_pages((unsigned long)(ti), \
+  CONFIG_KERNEL_STACK_ORDER); })
+
+#else
+
 /* thread information allocation */
 #define alloc_thread_info(tsk) \
((struct thread_info *) __get_free_pages(GFP_KERNEL, \
@@ -61,6 +75,8 @@ static inline struct thread_info *curren
 
 #endif
 
+#endif
+
 #define PREEMPT_ACTIVE 0x1000
 
 #define TIF_SYSCALL_TRACE  0   /* syscall trace active */
Index: linux-2.6.21-mm/arch/um/defconfig
===
--- linux-2.6.21-mm.orig/arch/um/defconfig  2007-06-19 13:37:16.0 
-0400
+++ linux-2.6.21-mm/arch/um/defconfig   2007-06-19 13:51:44.0 -0400
@@ -527,3 +527,4 @@ CONFIG_FORCED_INLINING=y
 # CONFIG_RCU_TORTURE_TEST is not set
 # CONFIG_GPROF is not set
 # CONFIG_GCOV is not set
+# CONFIG_DEBUG_STACK_USAGE is not set
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] UML - Use get_free_pages to allocate kernel stacks

[Jeff Dike]

For some reason, I was using kmalloc instead of get_free_pages for
kernel stacks.

Signed-off-by: Jeff Dike <[EMAIL PROTECTED]>
--
 include/asm-um/thread_info.h |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

Index: linux-2.6.21-mm/include/asm-um/thread_info.h
===
--- linux-2.6.21-mm.orig/include/asm-um/thread_info.h   2007-06-19 
12:23:16.0 -0400
+++ linux-2.6.21-mm/include/asm-um/thread_info.h2007-06-19 
14:06:36.0 -0400
@@ -54,8 +54,10 @@ static inline struct thread_info *curren
 
 /* thread information allocation */
 #define alloc_thread_info(tsk) \
-   ((struct thread_info *) kmalloc(THREAD_SIZE, GFP_KERNEL))
-#define free_thread_info(ti) kfree(ti)
+   ((struct thread_info *) __get_free_pages(GFP_KERNEL, \
+CONFIG_KERNEL_STACK_ORDER))
+#define free_thread_info(ti) \
+   free_pages((unsigned long)(ti),CONFIG_KERNEL_STACK_ORDER)
 
 #endif
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] UML stack tweaks

[Jeff Dike]

These can wait till 2.6.23.

They use get_free_page instead of kmalloc to allocate kernel stacks
and add some stack usage monitoring under CONFIG_DEBUG_STACK_USAGE.

Jeff

-- 
Work email - jdike at linux dot intel dot 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: Change in default vm_dirty_ratio

[John Stoffel]

> "Andrew" == Andrew Morton <[EMAIL PROTECTED]> writes:

Andrew> On Mon, 18 Jun 2007 14:14:30 -0700
Andrew> Tim Chen <[EMAIL PROTECTED]> wrote:

>> IOZone write drops by about 60% when test file size is 50 percent of
>> memory.  Rand-write drops by 90%. 

Andrew> heh.

Andrew> (Or is that an inappropriate reaction?)

>> Is there a good reason for turning down the default dirty ratio?

Andrew> It seems too large.  Memory sizes are going up faster than
Andrew> disk throughput and it seems wrong to keep vast amounts of
Andrew> dirty data floating about in memory like this.  It can cause
Andrew> long stalls while the system writes back huge amounts of data
Andrew> and is generally ill-behaved.

Shouldn't the vm_dirty_ratio be based on the speed of the device, and
not the size of memory?  So slower devices can't keep as much in
memory as fast devices?  That would seem to be a better metric.  And
of course those with hundreds of disks will then complain we're taking
too much memory as well, even though they can handle it.  

So per-device vm_dirty_ratio, capped with a vm_dirty_total_ratio seems
to be what we want, right?

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

Re: mea culpa on the meaning of Tivoization

[Alexandre Oliva]

On Jun 19, 2007, Hans-Jürgen Koch <[EMAIL PROTECTED]> wrote:

> Am Dienstag 19 Juni 2007 04:46 schrieb Alexandre Oliva:
>> The distrust for the FSF led to this very short-sighted decision of
>> painting the Linux community into a corner from which it is very
>> unlikely to be able to ever leave, no matter how badly it turns out to
>> be needed.  

> I'm neither in a corner nor do I feel the need for a different license.

Yes.  Some day you may.  And then what will you or anyone else be able
to do about it?

>> Let's just hope it never is, or that some influx of 
>> long-sighted comes in 

> Kernel programmers are short-sighted? What kind of arrogance is that?

It's just stating the obvious.  The upgrade path is a nightmare.

A long-sighted decision should have established *some* means for a
quick fix should it be needed.  It didn't have to be GPLv2+.  In fact,
per the stated goals and general feelings, it probably *shouldn't* be
GPLv2+.  But cutting any reasonable possibility of fixing a legal
problem in the license is short-sighted, yes.  It's putting too much
trust in the perfection of the license *and* the worldwide legal
systems *and* legislators.

>> and introduces mechanisms for the license of 
>> Linux to be patched, should this ever be needed.  

> You know pretty well that Linus clearly said he would change the license
> when _he_ thinks it's needed.

And what makes you think even *he* can change the license?

> The point is that _you_ want him to change the license to support
> _your_ political ideas.

I would like him to, yes.  But this is besides the point.  That I see
reasons for an upgrade, and that I'd like such an upgrade, doesn't
make any difference whatsoever about the plain fact that relicensing
Linux today, to any other license and for whatever reason it was,
would be a nightmare, and that this is a consequence of the
short-sighted decision of not establishing a relicensing procedure.

At this point, the situation is very much like a kernel installed in
ROM.  Who knows that nobody will ever find security bugs in it?  How
would you go about fixing them?

>> I'm not even talking 
>> about GPLv2+, there are many other ways to accomplish this, that I've
>> already mentioned in another posting in another recent huge thread.

> I partly read that "recent huge thread". Linus elaborated his point of 
> view in detail, and I very much share his opinion.

Huh?  It looks like you're talking about something unrelated with
license patching procedures.  I don't think Linus ever responded in
that thread to my suggestions of various means to establish a license
patching procedure.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.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: [PATCH -mm] add a kmem_cache for nsproxy objects

[Andrew Morton]

On Mon, 18 Jun 2007 22:53:13 +0200
Cedric Le Goater <[EMAIL PROTECTED]> wrote:

> +static int __init nsproxy_cache_init(void)
> +{
> + nsproxy_cachep = kmem_cache_create("nsproxy", sizeof(struct nsproxy),
> +0, SLAB_PANIC, NULL, NULL);
> + return 0;
> +}
> +

Christoph added this cheesy KMEM_CACHE macro.  But I don't immediately recall
the rationale so I'm a bit reluctant to ask people to use-the-cheesy-macro.

Perhaps he can remind us why it is there?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 1/6] SM501: suspend support

[Andrew Morton]

On Mon, 18 Jun 2007 21:56:21 +0100
[EMAIL PROTECTED] wrote:

> +/* power management support */
> +
> +static int sm501_plat_suspend(struct platform_device *pdev, pm_message_t 
> state)
> +{
> + struct sm501_devdata *sm = platform_get_drvdata(pdev);
> +
> + sm->in_suspend = 1;
> + sm->pm_misc = readl(sm->regs + SM501_MISC_CONTROL);
> +
> + sm501_dump_regs(sm);
> + return 0;
> +}
> +
> +static int sm501_plat_resume(struct platform_device *pdev)
> +{
> + struct sm501_devdata *sm = platform_get_drvdata(pdev);
> +
> + sm501_dump_regs(sm);
> + sm501_dump_gate(sm);
> + sm501_dump_clk(sm);
> +
> + /* check to see if we are in the same state as when suspended */
> +
> + if (readl(sm->regs + SM501_MISC_CONTROL) != sm->pm_misc) {
> + dev_info(sm->dev, "SM501_MISC_CONTROL changed over sleep\n");
> + writel(sm->pm_misc, sm->regs + SM501_MISC_CONTROL);
> +
> + /* our suspend causes the controller state to change,
> +  * either by something attempting setup, power loss,
> +  * or an external reset event on power change */
> +
> + if (sm->platdata && sm->platdata->init) {
> + sm501_init_regs(sm, sm->platdata->init);
> + }
> + }
> +
> + /* dump our state from resume */
> +
> + sm501_dump_regs(sm);
> + sm501_dump_clk(sm);
> +
> + sm->in_suspend = 0;
> +
> + return 0;
> +}
> +
> +
>  /* Initialisation data for PCI devices */
>  
>  static struct sm501_initdata sm501_pci_initdata = {
> @@ -1126,6 +1207,8 @@ static struct platform_driver sm501_plat
>   },
>   .probe  = sm501_plat_probe,
>   .remove = sm501_plat_remove,
> + .suspend= sm501_plat_suspend,
> + .resume = sm501_plat_resume,
>  };

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

Re: [BUG] ide dma_timer_expiry, then hard lockup

[Bartlomiej Zolnierkiewicz]

Hi,

On Tuesday 19 June 2007, Linas Vepstas wrote:
> On Tue, Jun 19, 2007 at 08:10:25PM +0400, Sergei Shtylyov wrote:
> > 
> > >I'm thinking that trying to debug libata is a better idea, rather than
> > >investing time in ide, right?  Although at the moment, libata works even 
> > >less; see other email.
> > 
> >Which makes me think this really is some *hardware* issue.

Linas, have you checked that there are no firmware updates available
for this drive?

> There are two distinct issues.
> -- libata locks up in partition table read on an hpt366+old maxtor disk
>that has ben working fine for many years with old ide driver. (It
>still works fine when I boot to the alternate ide-based kernel).
> 
> -- ide driver locks up on hpt366+new maxtor disk under heavy 
>i/o load. I was able to copy 60GB from old to new disk without a
>problem; however, raid reconstruction locks it up, maybe after 5-15
>seconds.
> 
>This probably is "hardware related"; its something that the new 
>hard drive does. Given that its being sold at a big discount, it
>may even be that the sellers know that this is a crappy disk. :-)
> 
>All I want is some way of resetting the disk, and continuing on.

It would be useful to see hdparm --Istdout output for *both* disks.

> I'm stalled in debugging; I'm not sue what I'm looking for.

Sergei, do you think that testing the drive with DMA disabled may
tell us something new?

Thanks,
Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Btrfs: a copy on write, snapshotting FS

[david]

On Tue, 19 Jun 2007, Chris Mason wrote:


3. De-de-duplicate blocks on disk, i.e. copy them on write

I suppose that de-duplication itself would be done by some user space
process that would scan files, determine blocks with the same data and
then de-duplicate them by using syscall or IOCTL (2).

That would be very usable feature, which in most cases would allow to
shrink occupied disk space on 50-90%.


Have you references for this number?
In my experience one gets a lot of benefit from
the much simpler process of "de-duplication" of files.


Yes, I would expect simple hard links to be a better solution for this,
but the feature request is not that out of line.  I actually had plans
on implementing auto duplicate block reuse earlier in btrfs.


with COW de-duplication you can merge things that have vastly different 
permissions. hard-links can't be used if different people have write 
permission.


David Lang

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 19, 2007, Anders Larsen <[EMAIL PROTECTED]> wrote:

> On 2007-06-18 21:50:12, Alexandre Oliva wrote:
>> Given the ROM exception in GPLv3, I guess you could seal and
>> anti-tamper it as much as you want, and leave the ROM at such a place
>> in which it's easily replaceable but with signature checking and all
>> such that the user doesn't install ROM that is not authorized by you.

> The manufacturer must be able to _remotely_ update the device
> firmware, so as I see it (IANAL), Tivoisation _is_ a requirement.

If you take the Wikipedia definition of Tivoization, you'll see it's
about copyleft software only, and no law mandates the use of copyleft
software.  There's no end to bad laws, but a law that mandated the use
of copyleft (=> free) software and at the same time prohibited
modifications by the user would be a very contradictory one.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Nicolas Mailhot]

Le mardi 19 juin 2007 à 10:50 -0700, David Schwartz a écrit :
> > > The GPL was never about allowing you to load modified software
> > > onto hardware
> > > where the legitimate creators/owners of that hardware say, "no,
> > > you may not
> > > modify the software running on this hardware".
> 
> > Good try but you had to add creators there so the sentence actually
> > supported your opinion. It's still an obvious alien insert.
> 
> It's simply shorter than saying "owners of the right or ability to decide
> what software runs on that hardware".

Right is not the same thing as ability. You have a technical ability
which has been converted in a "right" which in turn is used as argument
to reject GPLv3.

But did the original conversion happened with the approval of everyone
having rights to the result? I think not.

All the "GPLv2 didn't think of DRM therefore DRM is GPLv2-protected"
arguments make me sick. If tomorrow Ford starts mass+producing flying
saucers will they be exempt from traffic regulations because current
traffic regulations only consider cars? I think not. Yet the same
argument is the core of most GPL v3 objections we've seen in this
thread.

-- 
Nicolas Mailhot


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS

[david]

On Tue, 19 Jun 2007, Vladislav Bolkhovitin wrote:


> 3. De-de-duplicate blocks on disk, i.e. copy them on write
> 
> I suppose that de-duplication itself would be done by some user space

> process that would scan files, determine blocks with the same data and
> then de-duplicate them by using syscall or IOCTL (2).
> 
> That would be very usable feature, which in most cases would allow to

> shrink occupied disk space on 50-90%.

 Have you references for this number?


No, I've seen it somewhere and it well confirms with my own observations.


 In my experience one gets a lot of benefit from
 the much simpler process of "de-duplication" of files.


Yes, sure, de-duplication on files level brings its benefits, but on FS 
blocks level it would bring ever more benefits, because there are many more 
or less big files, which are different as a whole, but with a lot of the same 
blocks. Simple example of such files is UNIX-style mail boxes on a mail 
server.


unix style mail boxes would not be a good example of wins for sector-based 
de-duplication since the duplicate mail is not going to be sector aligned.


David Lang

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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 19, 2007, Johannes Stezenbach <[EMAIL PROTECTED]> wrote:

> (Where "free loaders" is a term introduced by Alexandre, not by me.)

It's actually from game theory.  Or something sufficiently mangled by
translation back and forth between English and Portuguese.  I think
the original is actually free riders.  My bad.

> The GPLv2 is a sufficient tool to defend free software
> against those that don't even grasp tit-for-tat.

It's not.  It doesn't even demand tit-for-tat.  This is a
*consequence* of the player understanding the spirit.  You can't
convince a person who doesn't believe in these ideas by pointing at
the license and saying "see, look, you're going to get contributions
back", because there are no such guarantees in the license.  And
that's how it should be.

> But it has to be their decision, IMHO it's wrong to force them.

Agreed.  Nobody is forcing anyone to use GPLed software.  Nobody is
forcing anyone to accept existing software under the GPLv3.

What every GPL stands to do is to defend the freedoms of users,
respecting the wishes of the authors expressed through the GPL that
the free software mains free.  Of course, authors who use the GPL for
other purposes may differ, but whether or not their claims that the
GPL advances their stances bear any resemblance with reality is
irrelevant.  This doesn't change what the GPL stands to do in any way,
it only changes what they expect the GPL to accomplish.  And whether
they're right or wrong in their expectations is besides the point.

> The GPLv3 tries to be a tool to defend against those that
> don't subscribe to the full Free Software Definition.

Not quite.  There appears to be an occurrence of a very common mistake
in your message.  Please forgive the long digression to try to dispell
it.

Many people think that the GPL is what the Free Software Definition is
all about, that Free Software somehow implies GPL, or some other
misunderstandings (to be read without a condescending tone ;-)

Free Software, and in particular the Free Software Definition, talks
about *respecting* users' freedoms.  There are many Free Software
licenses that accomplish this.

Some are very liberal in this sense.  They let you do whatever you
want with the code.  Even use it to disrespect users' freedoms.

Others are not so liberal.  They go *beyond* the Free Software
Definition, i.e., beyond merely respecting users' freedoms.  They
require agreement from recipients to not disrespect some users'
freedoms with the software, in some specific ways.  In addition to
*respecting* some freedoms, they *defend* some freedoms.

Others take the stance of defending all the four users' freedoms,
requiring agreement to not disrespect any users' freedoms with the
software, and to pass on this requirement, such that that software is
never used to disrespect users' freedoms.  These are called copyleft
licenses.

GPL is just one among all copyleft licenses, that are just some among
all licenses that defend some users' freedoms, that are just some
among all licenses that abide by the Free Software definition.  It
just so happens that it's the most widely-used Free Software license.


Think of it this way (if you understand open source but don't know
much of its history): the Open Source Definition is a rewritten
version of the Free Software Definition, intended to retain the same
meaning, but with a different focus.  That's why, as a general rule,
Free Software licenses are Open Source licenses, and Open Source
licenses are Free Software licenses.  AFAIK there is only one known
exception, and that's the open-source license Reciprocal Public
License, which goes to show that the Open Source definition is not
equivalent to the Free Software definition.

The differences are held to be in the motivations behind each of the
movements.  While Free Software takes the respect for the freedoms as
a moral issue (it's the right thing to do), Open Source takes it as a
pragmatic issue (it's better for everyone).  As luck would have it,
the pragmatic benefits are a consequence of the respect for users'
freedoms.

And more, pragmatists who see value in ensuring that the software
remains open source (which any OSI board member will insist that is
far more than merely keeping the source code open) are perceiving a
consequence of ensuring that the software remains Free, of defending
the freedoms of all users of the software.


Sure, there are other pragmatists that don't even care about the
software remaining open source, but only about the source code
remaining available.  We still have a lot in common with them, and we
can happily work together in projects under a number of licenses in
which our goals overlap.

It's not like everyone needs to move to GPLv3.  It's that there would
be moral and practical benefits for everyone if everyone did.  But if
those who don't want to don't, nothing is really lost.  It's just that
both Free Software and Open Source Software advocates who care not
only about abiding 

Re: [PATCH] - Add IOAPIC NMI support on x86_64

[John Keller]

> 
> >  In our specific case, a loadable driver will register to process
> >  the NMI generated by a timer device on the IOAPIC pin. The driver
> >  will need to unmask/mask the NMI interrupt at init/exit time.
> > 
> >  The timer NMI interrupt will be used to synchronize cluster nodes.
> 
> We normally don't add hooks which are only useful for out of tree
> modules unless there is a very good justification for it.

Sorry, I should have been clearer on all this.
The syncsched driver referred to here, is not anything proprietary,
and will be added to the community tree later this year.

I'm just looking to get some of the completed support code (this patch)
submitted, any issues resolved, and accepted prior to that. 


John


> 
> -Andi
> 

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

[PATCH] bonding: Fix use after free in unregister path

[Jay Vosburgh]

The following patch (based on a patch from Stephen Hemminger
<[EMAIL PROTECTED]>) removes use after free conditions in
the unregister path for the bonding master.  Without this patch, an
operation of the form "echo -bond0 > /sys/class/net/bonding_masters"
would trigger a NULL pointer dereference in sysfs.  I was not able to
induce the failure with the non-sysfs code path, but for consistency I
updated that code as well.

I also did some testing of the bonding /proc file being open
while the bond is being deleted, and didn't see any problems there.

Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>

diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 223517d..6287ffb 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -4345,8 +4345,8 @@ static void bond_free_all(void)
bond_mc_list_destroy(bond);
/* Release the bonded slaves */
bond_release_all(bond_dev);
-   unregister_netdevice(bond_dev);
bond_deinit(bond_dev);
+   unregister_netdevice(bond_dev);
}

 #ifdef CONFIG_PROC_FS
diff --git a/drivers/net/bonding/bond_sysfs.c b/drivers/net/bonding/bond_sysfs.c
index a122baa..60cccf2 100644
--- a/drivers/net/bonding/bond_sysfs.c
+++ b/drivers/net/bonding/bond_sysfs.c
@@ -164,9 +164,9 @@ static ssize_t bonding_store_bonds(struct class *cls, const 
char *buffer, size_t
printk(KERN_INFO DRV_NAME
": %s is being deleted...\n",
bond->dev->name);
-   unregister_netdevice(bond->dev);
bond_deinit(bond->dev);
bond_destroy_sysfs_entry(bond);
+   unregister_netdevice(bond->dev);
rtnl_unlock();
goto out;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Device hang when offlining a CPU due to IRQ misrouting

[Siddha, Suresh B]

On Tue, Jun 19, 2007 at 11:54:45AM -0600, Eric W. Biederman wrote:
> "Darrick J. Wong" <[EMAIL PROTECTED]> writes:
> 
> > On Mon, Jun 18, 2007 at 04:54:34PM -0700, Siddha, Suresh B wrote:
> >
> >> > 
> >> > [  256.298787] irq=4341 affinity=d
> >> > 
> >> 
> >> And just to make sure, at this point, your MSI irq 4341 affinity
> >> (/proc/irq/4341/smp_affinity) still points to '2'?
> >
> > Actually, it's 0xD.  From the kernel's perspective the mask has been
> > updated (and I even stuck a printk into set_msi_irq_affinity to verify
> > that the writes are happening) but ... the hardware doesn't seem to
> > reflect this.  I also tried putting read_msi_msg right afterwards to
> > compare contents, though it complained about all the MSIs _except_ for
> > 4341.  (Of course, I could just be way off on the effectiveness of
> > that.)
> 
> The fact that MSI interrupts are having problems is odd.  It is possible
> that we still have a bug in there somewhere but msi interrupts should
> be safe to migrate outside of irq context (no known hardware bugs).
> As we can actually synchronize with the irq source and eliminate all
> of the migration races.
> 
> The non-msi case requires hitting a hardware race that is rare enough
> you should not normally have problems.

Yep. But Darrick's seems to say, problem happens consistently.

Anyhow, Darrick there is a general bug in this area, can you try this and
see if it helps?

diff --git a/arch/x86_64/kernel/irq.c b/arch/x86_64/kernel/irq.c
index 3eaceac..a0e11c9 100644
--- a/arch/x86_64/kernel/irq.c
+++ b/arch/x86_64/kernel/irq.c
@@ -144,17 +144,35 @@ void fixup_irqs(cpumask_t map)
 
for (irq = 0; irq < NR_IRQS; irq++) {
cpumask_t mask;
+   int break_affinity = 0;
+   int set_affinity = 1;
+
if (irq == 2)
continue;
 
+   /* irq's are disabled at this point */
+   spin_lock(_desc[irq].lock);
+
cpus_and(mask, irq_desc[irq].affinity, map);
if (any_online_cpu(mask) == NR_CPUS) {
-   printk("Breaking affinity for irq %i\n", irq);
+   break_affinity = 1;
mask = map;
}
+
+   irq_desc[irq].chip->mask(irq);
+
if (irq_desc[irq].chip->set_affinity)
irq_desc[irq].chip->set_affinity(irq, mask);
else if (irq_desc[irq].action && !(warned++))
+   set_affinity = 0;
+
+   irq_desc[irq].chip->unmask(irq);
+
+   spin_unlock(_desc[irq].lock);
+
+   if (break_affinity && set_affinity)
+   printk("Broke affinity for irq %i\n", irq);
+   else if (!set_affinity)
printk("Cannot set affinity for irq %i\n", irq);
}
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Versioning file system

[Chris Snook]

Jack Stone wrote:

Chris Snook wrote:

The underlying internal implementation of something like this wouldn't
be all that hard on many filesystems, but it's the interface that's the
problem.  The ':' character is a perfectly legal filename character, so
doing it that way would break things.


But to work without breaking userspace it would need to be a character
that would pass through any path checking routines, ie be a legal path
character.

I think NetApp more or less got the interface right by putting a 
.snapshot directory in each directory, with time-versioned

subdirectories each containing snapshots of that directory's contents
at those points in time.  It keeps the backups under the same
hierarchy as the original files, to avoid permissions headaches,
it's accessible over NFS without modifying the client at all,
and it's hidden just enough to make it hard for users to do something
stupid.


My personal implementation idea was to store lots of files for the form
file:revision_number (I'll keep using that until somebody sugests
something better) on the file system itself, with a hard link form the
latest version to file (this is probably not a major imporvement and
having the hard link coudl make it hard to implement deltas). This could
mean no changes to the file system itself (except maybe a flag to say
its versioned). The kernel would then do the translation to find the
correct file, and would only show the latest version to userapps not
requesting a specific version.


I pointed out NetApp's .snapshot directories because that's a method that uses 
legal path character, but doesn't break anything.  With this method, userspace 
tools will have to be taught that : is suddenly a special character.  Userspace 
already knows that files beginning with . are special and treat them specially. 
 We don't need a new special character for every new feature.  We've got one, 
and it's flexible enough to do what you want, as proven by NetApp's extremely 
successful implementation.  Perhaps you want a slightly different interface from 
what NetApp has implemented, but what you're suggesting will change the default 
behavior of basic tools like tar and ls.  This is not a good thing.



If you want to do something like this (and it's generally not a bad
idea), make sure you do it in a way that's not going to change the
behavior seen by existing applications, and that is accessible to
unmodified remote clients.  Hidden .snapshot directories are one way, a
parallel /backup filesystem could be another, whatever.  If you break
existing apps, I won't touch it with a ten foot pole.


The whole interface would be designed to give existing behavior as
default for two reasons: users are used to opening a file and getting
the latest version and not to break userspace. I personally wouldn't
touch this either if it broke userspace. The only userspace change would
be the addition of tools to manage the revisions etc. Userspace could
later upgrade to take advantage of the new functionality but I cannot
see the worth in breaking it.


But what you're talking about *will* break userspace.  If I do an ls in a 
directory, and get pages upon pages of versions of just one file, that's broken. 
 If I tar up a directory and get a tarball that's hundreds of times larger than 
it should be, that's broken.  If you want the files to be hidden from userspace 
applications that don't know about your backup scheme, (and it sounds like you 
do) then use the existing convention for hidden files, the prepended '.'  This 
is the universal sign for "don't mess with me unless you know what you're doing".


-- 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: Device hang when offlining a CPU due to IRQ misrouting

[Eric W. Biederman]

"Darrick J. Wong" <[EMAIL PROTECTED]> writes:

> On Mon, Jun 18, 2007 at 04:54:34PM -0700, Siddha, Suresh B wrote:
>
>> > 
>> > [  256.298787] irq=4341 affinity=d
>> > 
>> 
>> And just to make sure, at this point, your MSI irq 4341 affinity
>> (/proc/irq/4341/smp_affinity) still points to '2'?
>
> Actually, it's 0xD.  From the kernel's perspective the mask has been
> updated (and I even stuck a printk into set_msi_irq_affinity to verify
> that the writes are happening) but ... the hardware doesn't seem to
> reflect this.  I also tried putting read_msi_msg right afterwards to
> compare contents, though it complained about all the MSIs _except_ for
> 4341.  (Of course, I could just be way off on the effectiveness of
> that.)

The fact that MSI interrupts are having problems is odd.  It is possible
that we still have a bug in there somewhere but msi interrupts should
be safe to migrate outside of irq context (no known hardware bugs).
As we can actually synchronize with the irq source and eliminate all
of the migration races.

The non-msi case requires hitting a hardware race that is rare enough
you should not normally have problems.

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

Re: Why is this patch not in 2.6.22-rc5?

[Jeff Garzik]

Stephen Hemminger wrote:

On Wed, 13 Jun 2007 21:36:30 -0700
Jay Vosburgh <[EMAIL PROTECTED]> wrote:


The following patch (based on a patch from Stephen Hemminger
<[EMAIL PROTECTED]>) removes use after free conditions in
the unregister path for the bonding master.  Without this patch, an
operation of the form "echo -bond0 > /sys/class/net/bonding_masters"
would trigger a NULL pointer dereference in sysfs.  I was not able to
induce the failure with the non-sysfs code path, but for consistency I
updated that code as well.

I also did some testing of the bonding /proc file being open
while the bond is being deleted, and didn't see any problems there.

Signed-off-by: Jay Vosburgh <[EMAIL PROTECTED]>


Hey David, this patch fixes one of the bugs listed in 2.6.22-rc5
list. Jay submitted last week but it hasn't made it upstream.


Get him to forward it to me, like he does for other bonding patches...

Jeff



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

Re: This is [Re:] How to improve the quality of the kernel[?].

[Stefan Richter]

Oleg Verych wrote:
> On Tue, Jun 19, 2007 at 04:27:15PM +0200, Stefan Richter wrote:
>> There are different people involved in
>>   - patch handling,
>>   - bug handling (bugs are reported by end-users),
>> therefore don't forget that PTS and BTS have different requirements.
> 
> Sure. But if tracking was done, possible bugs where killed, user's bug
> report seems to depend on that patch (bisecting), why not to have a
> linkage here?

Of course there are certain links between bugs and patches, and thus
there are certain links between bug tracking and patch tracking.

[...]
> Current identification of problems and patch association
> have completely zero level of tracking or automation, while Bugzilla is
> believed by somebody to have positive efficiency in bug tracking.

I, as maintainer of a small subsystem, can personally track bug--patch
relationships with bugzilla just fine, on its near-zero level of
automation and integration.

Nevertheless, would a more integrated bug/patch tracking system help me
improve quality of my output? ---
a) Would it save me more time than it costs me to fit into the system
   (time that can be invested in actual debugging)?
   This can only be answered after trying it.
b) Would it help me to spot mistakes in patches before I submit?
   No.
c) Would I get quicker feedback from testers?
   That depends on whether such a system attracts testers and helps
   testers to work efficiently.  This is also something that can only be
   speculated about without trying it.

The potential testers that I deal with are mostly either very
non-technical persons, or persons which are experienced in their
hardware/application area but *not* in kernel internals and kernel
development procedures.
-- 
Stefan Richter
-=-=-=== -==- =--==
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[David Schwartz]

> > The GPL was never about allowing you to load modified software
> > onto hardware
> > where the legitimate creators/owners of that hardware say, "no,
> > you may not
> > modify the software running on this hardware".

> Good try but you had to add creators there so the sentence actually
> supported your opinion. It's still an obvious alien insert.

It's simply shorter than saying "owners of the right or ability to decide
what software runs on that hardware".

The right to control the hardware vests originally with its owner/creator.
Tivo does not in fact transfer that right to the purchasers of their
hardware. (You can agree or disagree with this, but I don't think you can
coherently deny that they don't.)

The point is that GPL rights always applied equally to all hardware. Special
rights to run software on particular pieces of hardware are completely alien
to the original spirit of the GPL.

Someone has to decide what software runs on what hardware, and who makes
that decision can differ from the owner of the hardware for any number of
legitimate reasons. (And, IMO, for illegitimate reasons in the case of Tivo,
but that's not the issue here.)

DS


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

RE: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[David Schwartz]

> On Jun 18, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:

> > Why is the fact that only the root user can load a kernel module not a
> > further restriction?

> Because the user (under whose control the computer is, be it person or
> company) set up the root password herself?

Well, duh. TiVo, under whose control the software running on my Tivo is, set
up the signing key themself. *Someone* has to decide what software runs, the
GPL cannot rationally decide who that is because it's an
application-specific authorization decision.

> >> > The GPL was never, until GPLv3, about who gets to make
> >> > authorization decisions.
>
> >> I can agree with that.  As long as the authorization decisions are not
> >> used as means to deprive users' of the freedoms that must not be
> >> restricted, they can be whatever the distributor fancies.

> > Right, which is the freedom to modify the software. The freedom
> > to get the
> > source code. The freedom to use the source code however you want, absent
> > legitimate authorization decisions to the contrary.

> What makes them lawful, given the "no further restrictions"?

That the person who decides what software runs on that hardware can remove
them if they please. *Someone* has to decide what software runs on a
particular piece of hardware, right?

> > However, "you can't load your modified sofware on *MY* hardware" is
> > not a further restriction.

> As long as you didn't hand me the hardware along with the software,
> for me to become a user of the software on that hardware, I agree.

This is, again, an argument that is totally alien to the GPL. The idea that
you have 'special' rights to the software on some hardware but not others is
simply insane. It is totally out of left field with respect to the GPL. The
GPL is about being able to use the software on *ANY* hardware for which you
have the right to decide what software runs.

> However, since they distribute GPLed software along with the hardware,
> such that I'd be a user of the software on that hardware, they should
> not impose further restrictions on my freedoms that the GPL stands to
> defend WRT the GPLed software.  So, they must not use their
> authorization right to deny me, the user of the software, in the
> hardware that they meant me to use the software, the freedom to adapt
> the software for my own needs, and run it for any purpose.

You can argue this, but it's not a GPL argument. It's a reasonable argument,
but it has nothing whatsoever to do with GPL rights. GPL rights are about
being able to use the software on *any* hardware you want, not special
rights to use the software on some one particular piece of hardware. GPL
rights are rights against obstacles to getting the source code and legally
modifying it and distributing it, not rights against authorization obstacles
placed by people who own hardware.

> > That would mean it doesn't permit the distribute to state "BTW,
> > you can't
> > install, modify or run this software on *OUR* computers that run our
> > corporate network".

> No, because the user is not becoming a user of the software on their
> own computers.  Only in the computer that was shipped along with the
> software.

Yes, they are becoming a user. They might very well be using those
computers. It's absolutely absurd to argue that the right to choose what
software runs on a piece of hardware must go to the user of that hardware.
In any event, it's totally alien to the GPL which is not at all about who
gets to decide what software runs on what hardware.

> >> The "no further restrictions" applies equally to all computers.
> >> It's not just because you have some control over some particular
> >> hardware that you deliver along with the software that you're
> >> entitled to use that to limit the user's freedoms.

> > I agree. However, that doesn't mean that people who own or control
> > particular pieces of hardware can't put authorization barriers that
> > prevent you from running whatever software you want on thos pieces
> > of hardware.

> That's correct, as long as they didn't give me that hardware with
> GPLed software in it.  The moment they do, I become recipient and user
> of GPLed software in that computer, and they should relinquish their
> power to impose restrictions on my exercise of the freedoms WRT that
> software.  And there's no reason whatsoever to exclude restrictions
> such as those implemented by means of authorization.

You can state what the GPLv3 does as many times as you want, but special
rights to particular pieces of hardware is *TOTALLY* alien to the spirit of
the GPL. The GPL was always about equal rights to use the software in any
hardware.

DS


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] remove usage of memmem from scripts/kallsyms.c

[Mike Frysinger]

On Tuesday 19 June 2007, Paulo Marques wrote:
> The only in-kernel user of "memmem" is scripts/kallsyms.c and it only
> uses it to find tokens that are 2 bytes in size. It is trivial to
> replace it with a simple function that finds 2-byte tokens.
>
> This should help users from systems that don't have the memmem GNU
> extension available.
>
> Signed-off-by: Paulo Marques <[EMAIL PROTECTED]>

sorry for not getting back to you in the previous thread ... this is a much 
nicer patch than what i proposed and works for me :)

Acked-by: Mike Frysinger <[EMAIL PROTECTED]>
-mike


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

Re: [linux-usb-devel] Error -71 on device descriptor read/all

[Paul Walmsley]

On Tue, 19 Jun 2007, Oliver Neukum wrote:


Am Dienstag, 19. Juni 2007 schrieb Chuck Ebbert:


Try disabling CONFIG_USB_SUSPEND

[usb developers: what are the drawbacks of doing this?]


Increased power consumption.


speaking of CONFIG_USB_SUSPEND, I've encountered at least one device -- a 
Canon EOS 5D camera -- that, after the bus suspends, must be powercycled 
in order to return the camera's interrupt endpoints to a functional state. 
How are these types of problems handled, currently?  Is this something for 
a blacklist?



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

Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 19, 2007, "Pekka Enberg" <[EMAIL PROTECTED]> wrote:

> Hi Alexandre,
> On 6/19/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
>> Dispute this:
>> 
>> non-tivoized hardware => users can scratch their itches => more
>> contributions from these users
>> 
>> tivoized hardware => users can't scratch their itches => fewer
>> contributions from these users

> Maybe, but in what numbers?

We'll get to that.

> Furthermore, Linus has repeatedly explained to you why he (and bunch
> of other _kernel_ hackers -- this is a thread on LKML, remember)
> thinks it's stupid for a software license to restrict hardware
> design choices.

Most of these explanations carried the assumption that this would
lower the amount of contributions he'd get.  And this is precisely the
circular logic in their arguments, and this is why this argument is
intended to show the initial assumption is false.  But hey, maybe I'm
wrong, and it won't show that at all, and I'll be proved wrong, and
then there's going to be one more very vocal defensor of your ideals.


Now, if people want to keep on fooling themselves, I guess they can,
as long as they don't hurt others in the process.  If they try to fool
others, I feel it is my moral duty to intervene.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.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: This is [Re:] How to improve the quality of the kernel[?].

[Oleg Verych]

* Date: Tue, 19 Jun 2007 10:04:58 -0700 (PDT)
> 
> On Tue, 19 Jun 2007, Oleg Verych wrote:
>> 
>> I'm proposing kind of smart tracking, summarized before. I'm not an
>> idealist, doing manual work. Making tools -- is what i've picked up from
>> one of your mails. Thus hope of having more opinions on that.
>
> Don't get me wrong, I wasn't actually responing to you personally, I was 
> actually responding mostly to the tone of this thread.

By reading only known persons[1]? Fine, it is OK.

But i hope, i did useful statements. In fact, noise reduction stuff WRT
bug reports was before in my analysis of Adrian's POV here (reportbug
tool). Also it showed again, when i've wrote about traces, where testers
(bug reporters) can find test cases, before they will cry (again) about
some issues. I see this, example is bugzilla @ mozilla -- known history.

[1] Noise filtering -- that's obvious for me, after all :)

By not flaming further, i'm just going to try to implement something.
Hopefully my next patch will be usefully smart tracked.

Thanks!

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

Re: This is [Re:] How to improve the quality of the kernel[?].

[Natalie Protasevich]

On 6/19/07, Linus Torvalds <[EMAIL PROTECTED]> wrote:



On Tue, 19 Jun 2007, Oleg Verych wrote:
>
> I'm proposing kind of smart tracking, summarized before. I'm not an
> idealist, doing manual work. Making tools -- is what i've picked up from
> one of your mails. Thus hope of having more opinions on that.

Don't get me wrong, I wasn't actually responing to you personally, I was
actually responding mostly to the tone of this thread.

So I was responding to things like the example from Bartlomiej about
missed opportunity for taking developer review into account (and btw, I
think a little public shaming might not be a bad idea - I believe more in
*social* rules than in *technical* rules), and I'm responding to some of
the commentary by Adrian and others about "no regressions *ever*".

These are things we can *wish* for. But the fact that we migth wish for
them doesn't actually mean that they are really good ideas to aim for in
practice.

Let me put it another way: a few weeks ago there was this big news story
in the New York Times about how "forgetting" is a very essential part
about remembering, and people passed this around as if it was a big
revelation. People think that people with good memories have a "good
thing".

And personally, I was like "Duh".

Good memory is not about remembering everything. Good memory is about
forgetting the irrelevant, so that the important stuff stands out and you
*can* remember it. But the big deal is that yes, you have to forget stuff,
and that means that you *will* miss details - but you'll hopefully miss
the stuff you don't care for. The keyword being "hopefully". It works most
of the time, but we all know we've sometimes been able to forget a detail
that turned out to be crucial after all.

So the *stupid* response to that is "we should remember everything". It
misses the point. Yes, we sometimes forget even important details, but
it's *so* important to forget details, that the fact that our brains
occasionally forget things we later ended up needing is still *much*
preferable to trying to remember everything.

The same tends to be true of bug hunting, and regression tracking.

There's a lot of "noise" there. We'll never get perfect, and I'll argue
that if we don't have a system that tries to actively *remove* noise,
we'll just be overwhelmed. But that _inevitably_ means that sometimes
there was actually a signal in the noise that we ended up removing,
because nobody saw it as anything but noise.

So I think people should concentrate on turning "noise" into "clear
signal", but at the same time remember that that inevitably is a "lossy"
transformation, and just accept the fact that it will mean that we
occasionally make "mistakes".


This is the most crucial point so far in my opinion.
Well, not only people who report bugs are smart - they are curious,
enthusiastic, and passionate about their system, and job, hobby -
whatever linux means to them. They often do own investigations, give
lots of detail, and often others jump in with "me too" and give even
more detail (and more noise) But real detail that would help in bug
assessment is not there, and needs to be requested in lengthy
exchanges (time wise, since every request takes  hours, days,
months...)
I think  would help to make some attempt to lead them on to giving out
what's important. Cold and impersonal upfront fields and drop-down
menus are taking a lot of noise and heat off the actual report.
Another observation - things like "me too" should be encouraged to
become separate reports because generally only maintainer and people
who work directly on the module can sort out if this is same problem,
and in fact real problems get lost and not accounted for when getting
in wrong buckets this way.
--Natalie


This is why I've been advocating bugzilla "forget" stuff, for example. I
tend to see bugzilla as a place where noise accumulates, rather than a
place where noise is made into a signal.

Which gets my to the real issue I have: the notion of having a process for
_tracking_ all the information is actually totally counter-productive, if
a big part of the process isn't also about throwing noise away.

We don't want to "save" all the crud. I don't want "smart tracking" to
keep track of everything. I want "smart forgetting", so that we are only
left with the major signal - the stuff that matters.

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: regression tracking (Re: Linux 2.6.21)

[Martin J. Bligh]

Yes, good work, thanks a lot for it!  The new interface is much better and more
useful.

Greetings,
Rafael


PS
BTW, would that be possible to create the "Hibernation/Suspend" subcategory
of "Power Management" that I asked for some time ago, please? :-)
  


Oops. Sorry. Done.

M.

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

Re: How would I do this? (expert tricks) OT

[Jan Engelhardt]

On Jun 19 2007 10:14, Marc Perkel wrote:
>> 
>> tcpdump -lni any port 25
>> iptables -p tcp --dport 25 -j NFQUEUE
>> ...
>> 
>
>Thanks Jan, but I'm not sure it answers my question.

There's more than one way to do it.

One is...
tcpdump -lni eth0 tcp [extra operands to match SYN packets] |
myprogram

a longer one is to write your own netfilter userspace program
that receives the TCP SYNs (by means of -j NFQUEUE) and does
take action.

Another one is to use -j LOG and let your program parse
down /var/log/firewall. Like

iptables -A INPUT -p tcp --dport 25 --syn -j LOG --log-prefix "[evil]"
tail -f /var/log/firewall | grep '^\[evil\]' | myscript

myscript:
#!/usr/bin/perl

while (defined(my $line = <>)) {
my($ip) = ($line =~ /SRC=(\S+)/);
# Do something
}

>I want to run a script every time a connection attempt is made in real time

The scripts runs constantly, preferably.

>with the IP address as a parameter to the script. How would I do that? Suppose
>my script is:
>
>iplog 
>
>
>
>
>   
>
>Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, 
>news, photos & more. 
>http://mobile.yahoo.com/go?refer=1GNXIC
>

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: Dual-Licensing Linux Kernel with GPL V2 and GPL V3

[Alexandre Oliva]

On Jun 19, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:

> On Tuesday 19 June 2007 04:04:52 Alexandre Oliva wrote:
>> So your claim is that a user's possibility to scratch her own itches
>> makes no difference whatsoever as to their amount of contributions she
>> is likely to make?

> Exactly.

Hmm, interesting...  Are you doing this just to make it more
interesting, or did you never take Open Source 101? ;-)  Or economy,
game theory, ecology, politics, for that matter?

Do you realize how many contradictions arise from this claim?

A few examples for you.  Let me know if you don't understand why these
contradict this claim, I'll be happy to explain it to you.

How many newbies have patches accepted that they didn't test?

At which point in becoming a Linux developer does one leave behind
this altruistic attitude and becomes moved by self interest only?

How many people you know got to know Linux in their TiVos, took the
Linux sources that TiVo distributes and built it for their own PC?

>> Yes.  And your estimates are way too low too, FWIW.  Any reason why
>> you changed your mind as to the 10% before?

> That 10% was, IIRC, a reference to the potential number of "Hackers" that 
> would own a TiVO. On thinking about it I realized that the number of hackers 
> owning a TiVO would be vanishingly small because of "tivoization".

Aah, ok.

So, you lowered the estimate for the case of a tivoized device, but
then claimed it was the same for an otherwise-identical non-tivoized
device.

Seriously, try 'modprobe logic', you'll like it ;-)

> Wrong. Nobody here needs a "piece by piece" explanation.

Then why do you keep making claims that are not related with either
the part of the argument I'm posing or the full argument I've already
presented?

> So, in the belief that you were intelligent enough to understand
> that, I was providing proof that refutes your argument entirely.

The only proof you provided was that you didn't understand the
argument.

> With a situation as complex as what exists you can't split the
> argument into two and claim that, since "Argument A" is true in the
> "split" argument that it is true when the argument isn't split. This
> holds true for almost all real-world situations.

Which proves you don't understand how logical proofs work.

Let me explain it to you.

First, you need to establish initial premises.  Whether or not they
resemble any similarity with anything else you're thinking of is
irrelevant.  They might even be known to be false, in proof by
contradiction.

Then, you apply logical inference rules to the initial premises, and
establish consequences of the initial premises.

One of these consequences may be what you are trying to prove.  Or,
you may come to a contradiction, and prove that initial premises are
self-contradictory.  Or you may come to no useful conclusion
whatsoever.

> Now, I am not enjoying the discussion anymore.

Understandable.

> I've asked once before - remove me from the CC list.

I'll try to remember to do that.

-- 
Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member http://www.fsfla.org/
Red Hat Compiler Engineer   [EMAIL PROTECTED], gcc.gnu.org}
Free Software Evangelist  [EMAIL PROTECTED], gnu.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: [rtc-linux] Re: rtc_cmos: error after first write to wakealarm

[Tino Keitel]

On Tue, Jun 19, 2007 at 14:24:04 +0200, Alessandro Zummo wrote:
> On Fri, 15 Jun 2007 09:03:19 +0200
> Tino Keitel <[EMAIL PROTECTED]> wrote:
> 
> > > > I have the following strange behaviour with rtc_cmos:
> > > > 
> > > > $ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm
> > > > bash: echo: write error: Device or resource busy
> > > > $ rmmod rtc_cmos
> > > > $ modprobe rtc_cmos
> > > > $ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm
> > > > $ echo 1181934240 > /sys/class/rtc/rtc0/wakealarm
> > > > bash: echo: write error: Device or resource busy
> > > > $
> > > 
> > > If the alarm has already been enabled, you cannot set the next
> > > alarm.  You should disable first.
> > 
> > Ah, ok.
> >   
> > Where is the documentation that describes that I have to disable it
> > first, and how to do this? A migration document for
> > /proc/acpi/alarm users would be nice, too.
> 
>  Well, I guess there is no documentation. Maybe we could add
>  a dev_warn with an explicit message.

Isn't it somewhat ridiculous to plan the removal of a feature for
several months, and then replace it with something that behaves
differently without any documentation?

I don't know if there is any centralized form sysfs documentation. I
guess not. So at least a short text like the one below somewhere in
Documentation/ would be useful.

I still wonder how 'cat /sys/class/rtc/rtcX/wakealarm' is expected to
behave. With 2.6.22-rc5, I get this:

$ echo 1182351177 > /sys/class/rtc/rtc0/wakealarm 
$ cat /sys/class/rtc/rtc0/wakealarm
2051644873

There seems to be a constant difference of 869984896 seconds. Is this a
bug?


---

How to use /sys/class/rtc/rtcX/wakealarm


This file takes the seconds since epoch to enable a wake event at the
specified time.

If a '0' is written, the alarm is disabled.

If the alarm was already enabled, a new alarm can only be set after the
old alarm is disabled.


Migration from /proc/acpi/alarm
^^^

Users of /proc/acpi/alarm have to change their code to supply the
seconds since epoch instead of a date string.

For shell scripts, this can be done using the date command, e.g. like
this:

date -d tomorrow "+%s"

This returns the seconds since epoch of the current time on the
following day.

Please note that you have to disable the old alarm first, if you want
to set a new alarm. Otherwise, you get an error. Example:

echo 12345 > /sys/class/rtc/rtc0/wakealarm
echo 0 > /sys/class/rtc/rtc0/wakealarm
echo 23456 > /sys/class/rtc/rtc0/wakealarm

---

Regards,
Tino
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] m68k 53c700 SCSI

[Christoph Hellwig]

On Sun, Jun 17, 2007 at 02:47:04PM +0200, Geert Uytterhoeven wrote:
>   Hi James,
> 
> These patches add support for m68k to the 53c700 SCSI core and introduce new
> drivers for various m68k hardware using this 53c700 SCSI core, to replace the
> just removed drivers using the old 53c7xx SCSI core.
> 
>   [1] [PATCH] 53c700 scsi: m68k support for the 53c700 SCSI core
>   [2] [PATCH] 53c700 scsi: m68k BVME6000 NCR53C710 SCSI
>   [3] [PATCH] 53c700 scsi: m68k MVME16x NCR53C710 SCSI
>   [4] [PATCH] 53c700 scsi: Amiga 4000T NCR53c710 SCSI
>   [5] [PATCH] 53c700 scsi: Amiga Zorro NCR53c710 SCSI
> 
> Please apply for 2.6.23. Thx!

The patches all look very nice to me, thanks a lot.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] multiple streams have degraded performance

[Vernon Mauery]

On Tuesday 19 June 2007 8:38:50 am Peter Zijlstra wrote:
> On Tue, 2007-06-19 at 07:25 -0700, Vernon Mauery wrote:
> > On Monday 18 June 2007 11:51:38 pm Peter Zijlstra wrote:
> > > On Mon, 2007-06-18 at 22:12 -0700, Vernon Mauery wrote:
> > > > In looking at the performance characteristics of my network I found
> > > > that 2.6.21.5-rt15 suffers from degraded thoughput with multiple
> > > > threads.  The test that I did this with is simply invoking 1, 2, 4,
> > > > and 8 instances of netperf at a time and measuring the total
> > > > throughput.  I have two 4-way machines connected with 10GbE cards.  I
> > > > tested several kernels (some older and some newer) and found that the
> > > > only thing in common was that with -RT kernels the performance went
> > > > down with concurrent streams.
> > > >
> > > > While the test was showing the numbers for receiving as well as
> > > > sending, the receiving numbers are not reliable because that machine
> > > > was running a -RT kernel for these tests.
> > > >
> > > > I was just wondering if anyone had seen this problem before or would
> > > > have any idea on where to start hunting for the solution.
> > >
> > > could you enable CONFIG_LOCK_STAT
> > >
> > > echo 0 > /proc/lock_stat
> > >
> > > 
> > >
> > > and report the output of (preferably not 80 column wrapped):
> > >
> > > grep : /proc/lock_stat | head
> >
> > /proc/lock_stat stayed empty for the duration of the test.  I am guessing
> > this means there was no lock contention.
>
> Most likely caused by the issue below.
>
> > I do see this on the console:
> > BUG: scheduling with irqs disabled: IRQ-8414/0x/9494
> > caller is wait_for_completion+0x85/0xc4
> >
> > Call Trace:
> >  [] dump_trace+0xaa/0x32a
> >  [] show_trace+0x41/0x64
> >  [] dump_stack+0x15/0x17
> >  [] schedule+0x82/0x102
> >  [] wait_for_completion+0x85/0xc4
> >  [] set_cpus_allowed+0xa1/0xc8
> >  [] do_softirq_from_hardirq+0x105/0x12d
> >  [] do_irqd+0x2a8/0x32f
> >  [] kthread+0xf5/0x128
> >  [] child_rip+0xa/0x12
> >
> > INFO: lockdep is turned off.
> >
> > I haven't seen this until I enabled lock_stat and ran the test.
>
> I think this is what causes the lack of output. It disables all lock
> tracking features...
>
> > > or otherwise if there are any highly contended network locks listed?
> >
> > Any other ideas for debugging this?
>
> fixing the above bug would help :-)
>
> Ingo says that should be fixed in -rt17, so if you could give that a
> spin...

I just tested with -rt17 and the BUG message is gone, but I still don't see 
any entries in.  I don't see any other suspicious message so I think it is 
really strange that is not listing any locks at all.

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

Re: [patch 4/6] ps3: Disk Storage Driver

[Christoph Hellwig]

On Tue, Jun 19, 2007 at 02:51:25PM +0200, Geert Uytterhoeven wrote:
> On Tue, 19 Jun 2007, Christoph Hellwig wrote:
> > On Fri, Jun 15, 2007 at 01:39:23PM +0200, Geert Uytterhoeven wrote:
> > > From: Geert Uytterhoeven <[EMAIL PROTECTED]>
> > > 
> > > Add a Disk Storage Driver for the PS3:
> > >   - Implemented as a block device driver with a dynamic major
> > >   - Disk names (and partitions) are of the format ps3d%c(%u)
> > >   - Uses software scatter-gather with a 64 KiB bounce buffer as the 
> > > hypervisor
> > > doesn't support scatter-gather
> > 
> > Looks good to me.  Only nitpicks are:
> > 
> >  - ps3disk_priv should probably be an inline function instead of a macro
> 
> I used a macro because you can do
> 
> ps3disk_pri(dev) = ...;

I'm not exactly a fan of macros used as lvalues, but if you really
want this it can go in.

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