Re: [RFC] LZO de/compression support - take 6

2007-05-28 Thread Nitin Gupta

On 5/29/07, Bret Towe <[EMAIL PROTECTED]> wrote:


tested this on ppc and its still good



is there any reason to bother with a test on amd64?
if there is I might be able to get to it tonight


Yes, this test is desired on 'take 6'
(In future I will append version to patch bz2)

Thanks,
Nitin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 1/3] introduce SYS_CLONE_MASK

2007-05-28 Thread Roland McGrath
> Having the kernel not reparent user processes to init is an interesting
> idea, especially when those processes have not existed.  I'm not
> certain that is POSIX complaint and otherwise backwards compatible.

It's hard to see how it would work.  There has to be some parent PID.  The
reason using 1 makes sense is that it is always there.  Anything >0 and not
the PID of some live process could be reused for a new process at some point.


Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] LZO de/compression support - take 6

2007-05-28 Thread Nitin Gupta

On 5/28/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:

On Mon, May 28, 2007 at 09:33:32PM +0530, Nitin Gupta wrote:
> On 5/28/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:






I have not seen any explanations:
- Why did the upstream author write the code that way?
- Why are your changes correct?
- Why do your changes allow the compiler to produce faster code?

The upstream author of the code is available - and he might be able to
help you getting answers. No matter whether your changes are incorrect
or correct optimizations that should go upstream, in both cases
discussing these issues with upstream is the best solution.


The changelog I posted along with patch mentions all the changes I
made. I thought we will find all problems with this changelog in hand
and considering that its  just ~500 LOC.   But still, ok, asking
author himself will be good if he replies. I will mail him detailed
changelog and seek his feedback on this. This should answer all of
your questions.



And testing is nice, but if you broke some case that's outside of your
tests you'll never notice.



Yes. We cannot come up with exhaustive set of test cases to cover all
cases. But assuming that _original_ version is right and taking the
chagelog we should be able to verify if the porting is correct.


- Nitin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] LZO de/compression support - take 6

2007-05-28 Thread Nitin Gupta

On 5/29/07, Bret Towe <[EMAIL PROTECTED]> wrote:

On 5/28/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Attached is tester code used for testing.
> (developed by Daniel Hazelton -- modified slightly to now use 'take 6'
> version for 'TinyLZO')
>
> Cheers,
> Nitin
>
> On 5/28/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> > (Using tester program from Daniel)
> >
> > Following compares this kernel port ('take 6') vs original miniLZO code:
> >
> > 'TinyLZO' refers to this kernel port.
> >
> > 1 run averages:
> > 'Tiny LZO':
> >Combined: 61.2223 usec
> >Compression: 41.8412 usec
> >Decompression: 19.3811 usec
> > 'miniLZO':
> >Combined: 66.0444 usec
> >Compression: 46.6323 usec
> >Decompression: 19.4121 usec
> >
> > Result:
> > Overall: TinyLZO is 7.3% faster
> > Compressor: TinyLZO is 10.2% faster
> > Decompressor: TinyLZO is 0.15% faster
> >
>
>

1 run averages:
'Tiny LZO':
Combined: 112.6642 usec
Compression: 56.3321 usec
Decompression: 56.3321 usec
'miniLZO':
Combined: 77.6642 usec
Compression: 56.3416 usec
Decompression: 21.3226 usec

now the interesting bit I thought was the following
[EMAIL PROTECTED]:/usr/src/lzo1x-test-4# ./fulltest
[test_lzo.c::compress (93)] run took 42 microseconds
[test_lzo.c::decompress (127)] run took 20 microseconds
[EMAIL PROTECTED]:/usr/src/lzo1x-test-4# ./tinytest
[test.c::compress (91)] run took 44 microseconds
[test.c::decompress (117)] BUG: lzo1x_decompress has failed ( t == -6 )
[test.c::main (149)] BUG: Decompression routine failure




Did you use x86 for above test? Maybe some problem with testing
script? What data did you use for this test?


- Nitin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/3] Preserve the dirty bit in init_page_buffers

2007-05-28 Thread Eric W. Biederman
Nick Piggin <[EMAIL PROTECTED]> writes:

> Eric W. Biederman wrote:
>> Nick Piggin <[EMAIL PROTECTED]> writes:
>
>>> However we
>>>could still set_page_dirty of a block device page without buffers
>>>via an mmap.
>>
>>
>> After the page is made dirty via mmap we have:
>> sys_write -> ... -> block_prepare_write -> ... -> create_empty_buffers.
>
> Yep, that's what I mean.
>
>
>> I suspect that is a pretty rare case but it does indeed seem to exist
>> as a problem.
>
> I think so too. But either we have some misunderstanding of the
> codepaths involved, or the author of the comments there didn't
> consider this case, so...

Which is likely.

Which is why I brought up the try_to_free_buffers case.

There has been some significant dancing around trying to
sort things out and make them race free in this code.

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: [PATCH 1/1] V4L: stk11xx, add a new webcam driver

2007-05-28 Thread Thierry Merle



Thierry Merle a écrit :

Mauro Carvalho Chehab a écrit :
As Luca pointed, if we add conversion for one driver, we should add 
for

the rest.

Instead, it would be better if Jiri sends the decoding and the 
rescaling

stuff as a patch to v4l2-apps/lib, starting the API decoding library.
Once we have a library, we can ask the userspace developers to use it
for the formats not recognized by their userspace apps.

  

I think it would be better to evaluate existing solutions (eg. libpw).



Agreed. Volunteers?

  

Hi Mauro and Markus,
Just to summ up what I understood we need:

What do we need in userspace, only for v4l (dvb is not concerned):
- colorspace translations
- filters that be done in hardware if the selected hardware can, 
otherwise software plugin
- decompression algorithm like stk11xx or usbvision (the decompression 
algorithm is in kernelspace since it is of linear complexity but shall 
be moved to userspace)


Using pwlib will not mean that application developers will use pwlib 
to decode v4l driver outputs.
C bindings are much more popular than C++ bindings and do not prevent 
object oriented design.

Application developers implement their own codecs.
As an example, every application do deinterlacing internally or not...
Application developers will probably not use pwlib v4l extensions 
because they will prefer to write adapted codecs for their framework.


Much more important for me is to see the actual specification of the 
needed v4l extensions points, with advice/participation of 
application/codec developers.
As an example, we could empacket frames with a header containing 
audio/video format as it is done for MPEG streams.

Is it possible without breaking the current ABI?
Do application developers would cope with that?


Thierry



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


Re: [stable] pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

2007-05-28 Thread Greg KH
On Mon, May 28, 2007 at 09:53:50AM -0700, Linus Torvalds wrote:
> 
> Before we suspend a device, we call the subsystem that that device has 
> been registered with. Ie, we have code like this:
> 
>   if (dev->class && dev->class->suspend)
>   error = dev->class->suspend(dev, state);
> 
> which was very much designed so that individual devices wouldn't have to 
> always know - if the upper layer devices for that class can handle these 
> things, they should.
> 
> Do people actually _do_ this, right now? No. But we do actually have the 
> infrastructure, and I think we have one or two classes that actually do 
> use it (at least the "rfkill_class" has a suspend member, dunno how well 
> this model actually works).
> 
> I think Greg had some patches to make network drivers use this, for 
> example. Network drivers right now all end up doing stuff that really 
> doesn't belong in the driver at all when they suspend, and the 
> infrastructure _should_ just do it for them (ie do all the _network_ 
> related stuff, as opposed to the actual hardware-related stuff).

Yes, I started to work on it, as it is the correct thing to do, but got
sidetracked, sorry :(

> (Examples of things that we probably _should_ do for network devices on a 
> class level:
> 
>   suspend:
>   netif_poll_disable()
>   if (netif_running(dev))
>   dev->stop(dev);
> 
>   resume:
>   if (netif_running(dev))
>   dev->start(dev);
>   netif_poll_enable(dev);
> 
> or something similar).

I'll try to hack something together later this week along this line and
see how it works...

thanks,

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


Re: Network broken in kernel level.

2007-05-28 Thread Robert Hancock

Wang Penghui wrote:

Hello, list,

Recently, i have messed up with the follow problem, i have two server
both with two ethernet cards. Here are them:

[EMAIL PROTECTED] ~]# lspci | grep -i eth
05:00.0 Ethernet controller: Marvell Technology Group Ltd. Gigabit
Ethernet Controller (rev 18)
07:04.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet
Controller (rev 05)

And they are running MySQL server on both of them. The OS is RHEL 4 with
the default kernel 2.6.9-5.ELsmp. These days there are lots of error
message comming out in /var/log/message and dmesg.


That kernel is very old, you should get the latest RHEL errata update 
kernel and see if that helps. There have been hundreds of bugfixes in 
RHEL kernels since that version.


--
Robert Hancock  Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.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: [PATCH 1/3] Preserve the dirty bit in init_page_buffers

2007-05-28 Thread Nick Piggin

Eric W. Biederman wrote:

Nick Piggin <[EMAIL PROTECTED]> writes:



However we
could still set_page_dirty of a block device page without buffers
via an mmap.



After the page is made dirty via mmap we have:
sys_write -> ... -> block_prepare_write -> ... -> create_empty_buffers.


Yep, that's what I mean.



I suspect that is a pretty rare case but it does indeed seem to exist
as a problem.


I think so too. But either we have some misunderstanding of the
codepaths involved, or the author of the comments there didn't
consider this case, so...

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


Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP

2007-05-28 Thread Nick Piggin

Carsten Otte wrote:

The current xip stack relies on having struct page behind the memory 
segment. This causes few impact on memory management, but occupies some 
more memory. The cramfs patch chose to modify copy on write in order to 
deal with vmas that don't have struct page behind.
So far, Hugh and Linus have shown strong opposition against copy on 
write with no struct page behind. If this implementation is acceptable 
to the them, it seems preferable to me over wasting memory. The xip 
stack should be modified to use this vma flag in that case.


I would rather not :P

We can copy on write without a struct page behind the source today, no?
What is insufficient for the XIP code with the current COW?

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


Re: [PATCH 1/2] UDF: coding style conversion - lindent

2007-05-28 Thread Cyrill Gorcunov

This changes were made by Lindent script and the second patch fixup it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC, PATCH 1/3] introduce SYS_CLONE_MASK

2007-05-28 Thread Eric W. Biederman
"Albert Cahalan" <[EMAIL PROTECTED]> writes:

> This has long been rotten. Mind fixing it for us? :-)
>
> We have N types of thread on M CPUs. Pick something, N or M,
> to be at the top level in /proc. The other goes below, in the
> per-process task directories.
>
> You then have either N or M things showing up in ps, not N*M.
>
> Note that both ps and top can print the CPU number just fine.
> Abusing the task name for this is just retarded. This suggests
> that the top level should be the type of task, with the lower
> level in /proc/*/task being per-CPU and not needing distinct
> naming at all.

In a lot of ways that is reasonable.  However kernel threads don't
share signal handling and getting to the point where they could share
signal handling would be difficult so we cannot use the generic
CLONE_THREAD handling they really are more like individual processes.
So at that level the cpu number in the name is just to help tell them
apart. 

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: [RFC, PATCH 1/3] introduce SYS_CLONE_MASK

2007-05-28 Thread Eric W. Biederman
"Albert Cahalan" <[EMAIL PROTECTED]> writes:

> Jan Engelhardt writes:
>> On Apr 10 2007 17:47, Jan Engelhardt wrote:
>>> On Apr 8 2007 20:57, Oleg Nesterov wrote:
>
 Anyway, re-parenting to swapper breaks pstree, it doesn't
 show kernel threads. And if ->parent == /sbin/init, we can't
 remove us from ->children (unless we forbid sub-thread-of-init
 exec). So the only safe change is set ->exit_state = -1.
>>>
>>> Then we have to fix pstree and all that. (In fact, I'm
>>> trying to patch `ps f` to DTRT ;p)
>>
>> Done that and the result is that `ps afwx` now looks like:
>>
>>   PID TTY  STAT   TIME COMMAND
>>  2722 ?S  0:00 [lockd]
> ...
>> 3 ?S< 0:00 [events/0]
>> 2 ?SN 0:00 [ksoftirqd/0]
>> 1 ?Ss 0:02 init [3]
>>   537 ?S>  1600 ?Ss 0:00  \_ /usr/bin/dbus-daemon --system
>>  1692 ?Ss 0:00  \_ /sbin/acpid
>>  1923 ?Ss 0:00  \_ /sbin/resmgrd
> ...
>> -if(self_pid==1 && ADOPTED(processes[i]) && forest_type!='u')
>> +if(ADOPTED(processes[i]) && forest_type!='u')
>
> That's not compatible because init's children are now in the
> logical place. Since the days of procps-1.x.x or earlier,
> such processes have been listed at top level.
>
> BTW, what does "ps -ejH" do for you, with and without the patch?

ps -ejH displays everything.  For 2.6.22 we will only have kthreadd
as a sibling of init with ppid == 0.  Depending on what happens
in the evolution of how we start kernel thread we may be able
to remove kthreadd and have all kthreads with a ppid of 0, but only
time will tell.

> I'd be a lot happier about breaking compatibility in this area
> if I could get a functional adoption flag. That is, I really
> would like to show a process as child of init if it naturally
> was created as a child of init. It's less informative to have
> fake children showing up the same as real ones. The original
> parent PID would do. (BTW, the original parent name and/or
> grandparent PID would be great to have) As a bonus, the kernel
> could reap these processes more quickly than init can... and
> then maybe we can stop caring if init is alive.

Having the kernel not reparent user processes to init is an interesting
idea, especially when those processes have not existed.  I'm not
certain that is POSIX complaint and otherwise backwards compatible.

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/


warning while building module.

2007-05-28 Thread Tej Parkash

hi all

while building module i was getting following warning and it terminate
module building stage

MODPOST 1889 modules
WARNING: vmlinux - Section mismatch: reference to
.init.text:start_kernel from .text between 'is386' (at offset
0xc0101171) and 'check_x87'
WARNING: vmlinux - Section mismatch: reference to .init.text: from
.text between 'rest_init' (at offset 0xc0101458) and 'try_name'
WARNING: vmlinux - Section mismatch: reference to
.init.text:__alloc_bootmem from .text between 'init_gdt' (at offset
0xc010adfb) and 'cpu_init'
WARNING: vmlinux - Section mismatch: reference to
.init.text:__alloc_bootmem from .text between 'init_gdt' (at offset
0xc010ae11) and 'cpu_init'
WARNING: vmlinux - Section mismatch: reference to
.init.text:sysenter_setup from .text between 'identify_cpu' (at offset
0xc010b46b) and 'display_cacheinfo'
WARNING: vmlinux - Section mismatch: reference to
.init.text:mtrr_bp_init from .text between 'identify_cpu' (at offset
0xc010b475) and 'display_cacheinfo'
WARNING: vmlinux - Section mismatch: reference to
.init.text:trap_init_f00f_bug from .text between 'init_intel' (at
offset 0xc010d576) and 'cpuid4_cache_lookup'
WARNING: vmlinux - Section mismatch: reference to .init.text: from
.text between 'iret_exc' (at offset 0xc02f2c2e) and '_etext'
WARNING: vmlinux - Section mismatch: reference to
.init.data:initkmem_list3 from .text between 'set_up_list3s' (at
offset 0xc0173aff) and 's_start'
WARNING: vmlinux - Section mismatch: reference to
.init.text:eisa_root_register from .text between
'virtual_eisa_root_init' (at offset 0xc026fecf) and
'cpufreq_unregister_driver'
WARNING: vmlinux - Section mismatch: reference to .init.text: from
.text between 'iret_exc' (at offset 0xc02f32c8) and '_etext'

i was trying to fix with online available patches but does not help out.
please cc to me

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


Re: [NFS] [PATCH] NFSD: fix uninitialized variable

2007-05-28 Thread young dave

Hi,


Given what you said above, I don't see gcc, on its best day, will ever
know enough to validate that that variable is indeed always initialized.
  So I would vote for silencing it on those grounds.


I agree too. How about this one:

diff -dur linux/fs/nfsd/nfs4acl.c linux.new/fs/nfsd/nfs4acl.c
--- linux/fs/nfsd/nfs4acl.c 2007-05-29 12:28:29.0 +
+++ linux.new/fs/nfsd/nfs4acl.c 2007-05-29 12:30:45.0 +
@@ -183,8 +183,6 @@
summarize_posix_acl(struct posix_acl *acl, struct posix_acl_summary *pas)
{
   struct posix_acl_entry *pa, *pe;
-   pas->users = 0;
-   pas->groups = 0;
   pas->mask = 07;

   pe = acl->a_entries + acl->a_count;
@@ -229,6 +227,7 @@
   int eflag = ((flags & NFS4_ACL_TYPE_DEFAULT) ?
   NFS4_INHERITANCE_FLAGS | NFS4_ACE_INHERIT_ONLY_ACE : 0);

+   memset(pas, 0, sizeof(struct posix_acl_summary);
   BUG_ON(pacl->a_count < 3);
   summarize_posix_acl(pacl, );

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


Re: Block devices and barriers

2007-05-28 Thread Neil Brown
On Monday May 21, [EMAIL PROTECTED] wrote:
>   Hi,
> 
> I'm adding cache flush support to the PS3 disk driver and have a few questions
> related to barriers.
> 
> In my driver, I do:
> 
> blk_queue_issue_flush_fn(queue, ps3disk_issue_flush);
> blk_queue_ordered(queue, QUEUE_ORDERED_DRAIN_FLUSH, 
> ps3disk_prepare_flush);
> 
> but I can't find a way to actually trigger the calling of 
> ps3disk_issue_flush()
> and ps3disk_prepare_flush().
> 
>  1. My prepare_flush_fn() routine should be called from queue_flush(), which 
> is
> in turn called by start_ordered().
> start_ordered() is called by blk_do_ordered(), but only if there's no
> barrier (REQ_HARDBARRIER is not set).
> Apart from drivers/block/pktcdvd.c and init_request_from_bio()
> (BIO_RW_BARRIER is set by drivers/md/md.c only?), the only other way
> REQ_HARDBARRIER can be set is in queue_flush(), which is not possible.

BIO_RW_BARRIER is set by various filesystems when mounted with
  -o barrier 
or
  -o barrier=1 (ext3)

See calls to set_buffer_ordered in fs/jbd/commit.c

> 
>   2. My issue_flush_fn() should be called from blkdev_issue_flush() (ignoring
>  drivers/md). But blkdev_issue_flush() is called by ReiserFS and XFS only.

Yeh, it isn't widely used at the moment.

> 
> I read the Block Device chapter in Linux Device Drivers 3rd edition, which 
> says
> to check blk_barrier_rq(), but the barrier part seems to be obsolete, as we 
> now
> have the prepare_flush_fn parameter of blk_queue_ordered().
> 
> Am I missing something? Should I care about barriers?

Yes, you should care about barriers, though it is true that there is
some confusion around them and it might be difficult.


> 
> Thanks!
> 
> BTW, Documentation/block/barrier.txt seems to be out-of-date. Patch to update
> it is below.

You might like to post this directly to
  Tejun Heo <[EMAIL PROTECTED]>

NeilBrown

> 
> ---
> 
> Documentation/block/barrier.txt is not in sync with the actual code:
>   - blk_queue_ordered() no longer has a gfp_mask parameter
>   - blk_queue_ordered_locked() no longer exists
>   - sd_prepare_flush() looks slightly different
> 
> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
> 
> --- a/Documentation/block/barrier.txt
> +++ b/Documentation/block/barrier.txt
> @@ -82,23 +82,12 @@ including draining and flushing.
>  typedef void (prepare_flush_fn)(request_queue_t *q, struct request *rq);
>  
>  int blk_queue_ordered(request_queue_t *q, unsigned ordered,
> -   prepare_flush_fn *prepare_flush_fn,
> -   unsigned gfp_mask);
> -
> -int blk_queue_ordered_locked(request_queue_t *q, unsigned ordered,
> -  prepare_flush_fn *prepare_flush_fn,
> -  unsigned gfp_mask);
> -
> -The only difference between the two functions is whether or not the
> -caller is holding q->queue_lock on entry.  The latter expects the
> -caller is holding the lock.
> +   prepare_flush_fn *prepare_flush_fn);
>  
>  @q   : the queue in question
>  @ordered : the ordered mode the driver/device supports
>  @prepare_flush_fn: this function should prepare @rq such that it
> flushes cache to physical medium when executed
> [EMAIL PROTECTED] : gfp_mask used when allocating data structures
> -   for ordered processing
>  
>  For example, SCSI disk driver's prepare_flush_fn looks like the
>  following.
> @@ -106,9 +95,10 @@ following.
>  static void sd_prepare_flush(request_queue_t *q, struct request *rq)
>  {
>   memset(rq->cmd, 0, sizeof(rq->cmd));
> - rq->flags |= REQ_BLOCK_PC;
> + rq->cmd_type = REQ_TYPE_BLOCK_PC;
>   rq->timeout = SD_TIMEOUT;
>   rq->cmd[0] = SYNCHRONIZE_CACHE;
> + rq->cmd_len = 10;
>  }
>  
>  The following seven ordered modes are supported.  The following table
> 
> Gr{oetje,eeting}s,
> 
>   Geert
> 
> --
> Geert Uytterhoeven -- Sony Network and Software Technology Center Europe 
> (NSCE)
> [EMAIL PROTECTED] --- The Corporate Village, Da Vincilaan 7-D1
> Voice +32-2-7008453 Fax +32-2-7008622  B-1935 Zaventem, 
> Belgium
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

2007-05-28 Thread Kyle Moffett

On May 28, 2007, at 16:38:38, Pavel Machek wrote:

Kyle Moffett wrote:
I am of the opinion that adding a  "name" parameter to the file/ 
directory create actions would be useful.  For example, with such  
support you could actually specify a  type-transition rule  
conditional on a specific name or substring:


named_type_transition sshd_t tmp_t:sock_file prefix "ssh-"  
ssh_sock_t;


Useful options for matching would be "prefix", "suffix", "substr  
(start,len)".  "regex" would be nice but is sorta computationally  
intensive and would be likely to cause more problems than it solves.


Could someone implement this? AFAICT that prevents SELinux from  
being superset of AppArmor... Doing this should be significantly  
simpler than whole AA, and hopefully it will end up less ugly, too.


Really it would need to extend all action-match items with new  
"named_" equivalents, and most callbacks would need to be extended to  
pass in an object name, if available.  On the other hand, with such  
support implemented then the AppArmor policy compilation tools could  
be transformed into a simple SELinux policy generator.  I estimate  
that the number of new lines of kernel code for such a modified  
SELinux would be 100x less than the kernel code in AppArmor.


Cheers,
Kyle Moffett

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


Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

2007-05-28 Thread Kyle Moffett

On May 28, 2007, at 06:41:11, Toshiharu Harada wrote:

2007/5/27, Kyle Moffett <[EMAIL PROTECTED]>:
If you can't properly manage your labels, then how do you expect  
any security at all?
Please read my message again. I didn't say, "This can never be  
achieved".  I said, "This can not be easily achieved".


So you said "(data labels) can not be easily achieved".  My  
question for you is: How do you manage secure UNIX systems without  
standard UNIX permission bits?  Also:  If you have problems with  
data labels then what makes pathname based labels "easier"?  If  
there is something that could be done to improve SELinux and make  
it more readily configurable then it should probably be done.


Permission bits can be checked easily with "ls" command but  
assuring the correctness of labels are not that easy. I'll try to  
explain.


The correctness of the permission bit for a given file can be  
judged solely by the result of "ls" command.  The correctness of  
the label, on the other hand, can't be judged without understanding  
of whole policy including domain transitions. (see the attached  
figure) I can imagine that once one get the complete SELinux  
policy, then it is able to modify and maintain it.


That's why there are a number of efforts to make modular SELinux  
policies.  A good SELinux policy provides a few core system types and  
labels which a policy developer needs to understand, as well as some  
good macros to simplify the human-editable policy files.  For  
instance, in my customized policy a daemon run by an initscript which  
reads a single config file in /etc needs this policy (Note that I use  
"_d" as a suffix for process domains instead of the usual "_t"):


initrc_daemon(foo_exec_t, foo_d)
daemon_config(foo_d, foo_conf_t)

Add maybe 2 lines for network port access, another 2 for database  
files in /var, plus maybe an "iptables" rule or two in your firewall  
file.


I don't say making a complete SELinux policy is impossible, and  
actually you said you did it.  But to be frank, I don't think you  
are the average level user at all. ;-)


Average users are not supposed to be writing security policy.  To be  
honest, even average-level system administrators should not be  
writing security policy.  It's OK for such sysadmins to tweak  
existing policy to give access to additional web-docs or such, but  
only expert sysadmin/developers or security professionals should be  
writing security policy.  It's just too damn easy to get completely  
wrong.


I'm very interested in how you can know that you have the correct  
object labeling (this is my point). Could you tell?


I know that I have the correct object labeling because:


Do you mind if I add this?

0) I understood the default policy and perfectly understand the  
every behavior of my system.


this is where the difficulties exist.


You don't have to understand the entire default policy; that's the  
point of modular policy.  You only have to understand how to _use_  
the interfaces of the system policy (which are documented) and how  
the particular daemon policy is supposed to work.  The people  
developing the core system policy need to understand the inner  
workings of said policy, but they don't need to understand how the  
rest of the system works.  The core functionality behind this  
separation is macro interfaces and attributes.  By grouping types  
with attributes it is possible for arbitrary daemon types to  
categorize themselves under access rules defined by the base policy,  
and with interfaces the daemons don't really even need to know what  
those attributes are called.


I don't deny DAC at all.  If we deny DAC, we can't live with  
Linux it's the base.  MAC can be used to cover the shortages of  
DAC and Linux's simple user model, that's it.


From security point of view, simplicity is always the virtue and  
the way to go.  Inode combined label is guaranteed to be a single  
at any point time.  This is the most noticeable advantage of  
label-based security.


I would argue that pathname-based security breaks the "simplicity  
is the best virtue (of a security system)" paradigm, because it  
attributes multiple potentially-conflicting labels to the same piece


I have a question for you.  With current implementation of SELinux,  
only one label can be assigned.  But there are cases
that one object can be used in different context, so I think it  
might help if SELinux would allow objects to have multiple labels.  
(I'm not talking about conflicts here)  What do you think?


This is the whole advantage of SELinux type attributes: you can  
define a type "var_foo_t" which has a specific list of attributes;  
rules which accept type specifiers can also accept attribute  
specifiers as well.  If what you want is a label which may be  
accessed in two different ways, then you declare attributes for each  
access method and declare a type which has the attributes "filetype",  
"access1", and "access2" 

Network broken in kernel level.

2007-05-28 Thread Wang Penghui
Hello, list,

Recently, i have messed up with the follow problem, i have two server
both with two ethernet cards. Here are them:

[EMAIL PROTECTED] ~]# lspci | grep -i eth
05:00.0 Ethernet controller: Marvell Technology Group Ltd. Gigabit
Ethernet Controller (rev 18)
07:04.0 Ethernet controller: Intel Corp. 82541GI/PI Gigabit Ethernet
Controller (rev 05)

And they are running MySQL server on both of them. The OS is RHEL 4 with
the default kernel 2.6.9-5.ELsmp. These days there are lots of error
message comming out in /var/log/message and dmesg.

KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK |
MSG_TRUNC))) failed at net/ipv4/tcp.c (1348)
KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK |
MSG_TRUNC))) failed at net/ipv4/tcp.c (1348)
KERNEL: assertion (tp->copied_seq == tp->rcv_nxt || (flags & (MSG_PEEK |
MSG_TRUNC))) failed at net/ipv4/tcp.c (1348)
KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1284)
KERNEL: assertion (flags & MSG_PEEK) failed at net/ipv4/tcp.c (1284)

When it appeared, the network of Marvell card has been broken. It
connected but accessable.
We have installed the driver of the Marvell card manully with the driver
"Driver version: 8.30.2.3 (Dec-14-2005)".

I have digged in google for a long time. But unluckly, i haven't got the
sulotion.

Did i need a kernel upgrade or driver upgrade or anything else?

Every response is apperciated.

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


Re: [ckrm-tech] [RFC] [PATCH 0/3] Add group fairness to CFS

2007-05-28 Thread Peter Williams

Peter Williams wrote:

Srivatsa Vaddagiri wrote:

On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
I don't think that ignoring cpu affinity is an option.  Setting the 
cpu affinity of tasks is a deliberate policy action on the part of 
the system administrator and has to be honoured.  


mmm ..but users can set cpu affinity w/o administrator priveleges ..



OK. So you have to assume the users know what they're doing. :-)

In reality though, the policy of allowing ordinary users to set affinity 
on their tasks should be rethought.


After more contemplation, I now think I may have gone overboard here.  I 
am now of the opinion that any degradation of overall system performance 
due to the use of cpu affinity would be confined to the tasks with cpu 
affinity set.  So there's no need to prevent ordinary users from setting 
cpu affinity on their own processes as any degradation will only affect 
them.


So it goes back to the situation where you have to assume that they know 
what they're doing and obey their policy.




In any case, there's no point having cpu affinity if it's going to be 
ignored.  Maybe you could have two levels of affinity: 1. if set by a 
root it must be obeyed; and 2. if set by an ordinary user it can be 
overridden if the best interests of the system dictate.  BUT I think 
that would be a bad idea.


This idea is now not just bad but unnecessary.

Peter
--
Peter Williams   [EMAIL PROTECTED]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 1/3] introduce SYS_CLONE_MASK

2007-05-28 Thread Albert Cahalan

Jan Engelhardt writes:

On Apr 10 2007 17:47, Jan Engelhardt wrote:

On Apr 8 2007 20:57, Oleg Nesterov wrote:



Anyway, re-parenting to swapper breaks pstree, it doesn't
show kernel threads. And if ->parent == /sbin/init, we can't
remove us from ->children (unless we forbid sub-thread-of-init
exec). So the only safe change is set ->exit_state = -1.


Then we have to fix pstree and all that. (In fact, I'm
trying to patch `ps f` to DTRT ;p)


Done that and the result is that `ps afwx` now looks like:

  PID TTY  STAT   TIME COMMAND
 2722 ?S  0:00 [lockd]

...

3 ?S< 0:00 [events/0]
2 ?SN 0:00 [ksoftirqd/0]
1 ?Ss 0:02 init [3]
  537 ?S
...

-if(self_pid==1 && ADOPTED(processes[i]) && forest_type!='u')
+if(ADOPTED(processes[i]) && forest_type!='u')


That's not compatible because init's children are now in the
logical place. Since the days of procps-1.x.x or earlier,
such processes have been listed at top level.

BTW, what does "ps -ejH" do for you, with and without the patch?

I'd be a lot happier about breaking compatibility in this area
if I could get a functional adoption flag. That is, I really
would like to show a process as child of init if it naturally
was created as a child of init. It's less informative to have
fake children showing up the same as real ones. The original
parent PID would do. (BTW, the original parent name and/or
grandparent PID would be great to have) As a bonus, the kernel
could reap these processes more quickly than init can... and
then maybe we can stop caring if init is alive.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [NFS] [PATCH] NFSD: fix uninitialized variable

2007-05-28 Thread Jeff Garzik

J. Bruce Fields wrote:

On Sun, May 27, 2007 at 06:34:42AM -0400, Jeff Garzik wrote:

Unlike many of the bogus warnings spewed by gcc, this one actually
complains about a real bug:


No, the calls to posix_acl_valid() in nfs4_acl_posix_to_nfsv4() ensure
that the passed-in acl has ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER
entries, and hence that these fields will always be initialized.


OK



But I don't want anyone else wasting their time on this.  Should we cave
in and add the initialization here just to shut up gcc?  Or would a
comment here help?


Given what you said above, I don't see gcc, on its best day, will ever 
know enough to validate that that variable is indeed always initialized. 
 So I would vote for silencing it on those grounds.


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: fs periodic check (was Re: 2.6.22-rc1 killed my ext3 filesystem cleanly unmounted)

2007-05-28 Thread Neil Brown
On Monday May 28, [EMAIL PROTECTED] wrote:
> On Thu, May 24, 2007 at 05:39:11PM +, Pavel Machek wrote:
> > Right. Could we get more helpful message here? 'Filesystem check on
> > next boot on AC power'? 
> 
> So "(check deferred; on battery)" wasn't explicit enough?  I guess I
> assumed that users would understand that the opposite of "on battery"
> was "on AC power".  I guess I could say "(check defferred 'til on AC
> power)" if people think it would be clearer.
> 

So when I use my travelling power adapter which I plug into the 12V-DC
power in my car, and it delivers DC power to my notebook.
My note book tells me that I am using AC power

I really think "AC" as the opposite of "battery" is wrong and should
be stamped out everywhere, certainly not introduced here.

"external power" maybe?

  Check deferred until system is externally powered.

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


Re: [NFS] [PATCH] NFSD: fix uninitialized variable

2007-05-28 Thread J. Bruce Fields
On Sun, May 27, 2007 at 06:34:42AM -0400, Jeff Garzik wrote:
> 
> Unlike many of the bogus warnings spewed by gcc, this one actually
> complains about a real bug:

No, the calls to posix_acl_valid() in nfs4_acl_posix_to_nfsv4() ensure
that the passed-in acl has ACL_USER_OBJ, ACL_GROUP_OBJ, and ACL_OTHER
entries, and hence that these fields will always be initialized.

But I don't want anyone else wasting their time on this.  Should we cave
in and add the initialization here just to shut up gcc?  Or would a
comment here help?

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


Re: [RFC, PATCH 1/3] introduce SYS_CLONE_MASK

2007-05-28 Thread Albert Cahalan

Robin Holt writes:

On Mon, Apr 09, 2007 at 08:36:21AM -0600, Eric W. Biederman wrote:

Robin Holt <[EMAIL PROTECTED]> writes:



I would say this is more a benefit than a problem.  With a couple
of these systems we are testing, the number of kernel threads is
far greater than the number of user processes and having pstree
not normally show them, but maybe have an option we add later to
show them again would be beneficial.


Sure.

Robin how many kernel thread per cpu are you seeing?


10.


This has long been rotten. Mind fixing it for us? :-)

We have N types of thread on M CPUs. Pick something, N or M,
to be at the top level in /proc. The other goes below, in the
per-process task directories.

You then have either N or M things showing up in ps, not N*M.

Note that both ps and top can print the CPU number just fine.
Abusing the task name for this is just retarded. This suggests
that the top level should be the type of task, with the lower
level in /proc/*/task being per-CPU and not needing distinct
naming at all.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: fs periodic check (was Re: 2.6.22-rc1 killed my ext3 filesystem cleanly unmounted)

2007-05-28 Thread Theodore Tso
On Thu, May 24, 2007 at 05:39:11PM +, Pavel Machek wrote:
> Right. Could we get more helpful message here? 'Filesystem check on
> next boot on AC power'? 

So "(check deferred; on battery)" wasn't explicit enough?  I guess I
assumed that users would understand that the opposite of "on battery"
was "on AC power".  I guess I could say "(check defferred 'til on AC
power)" if people think it would be clearer.

> Or maybe keep counting, and when we reach 2x mount-count-limit,
> force a fsck, battery power or not?

We do that already.  It's just tough to make that all fit on an 80
status message.  :-)

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


RE: [patch] Add the device IDs f or AMD/ATI SB700

2007-05-28 Thread Henry Su
Hi all,
Since I am a junior linux developing engineer, I really appreciate that you 
tell me these informations,
Thanks for your help!

Brs,
Henry

-Original Message-
From: Bartlomiej Zolnierkiewicz [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, May 29, 2007 4:17 AM
To: Jeff Garzik
Cc: Henry Su; [EMAIL PROTECTED]; [EMAIL PROTECTED]; 
linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [patch] Add the device IDs for AMD/ATI SB700


Hi,

Sorry for the late reply and thanks to Jeff for stepping in. :)

Since Jeff covered both status of your patches and administrative issues
I would only like to add one small hint for people adding support for
multi-function PCI chipsets (with multiple PCI device IDs):

It makes sense to put addition of _all_ new PCI IDs into the first patch
of the series and send it to PCI Maintainer (Hi Greg).  This should make
all other patches from the series independent of each other (in the usual
case I'm not talking about all crazy scenarios here).  After the patch
with PCI IDs gets applied upstream you may now send all other patches to
the respective maintainers without worrying about inter-patch dependencies
and without maintainers worrying about your patches not applying cleanly.

IIRC Intely guys are using this process when adding support for their new
chipsets and it works smoothly.

[ Yep, this process is the exception from the general "patch shouldn't add
  unused code" rule but the amount of _temporarily_ unused stuff is _minimal_
  and doing it this way saves a lot of time for all parties involved. ]

PS Greg/Jeff If I'm totally wrong on this please correct me...

Thanks,
Bart

On Friday 25 May 2007, Jeff Garzik wrote:
> Henry Su wrote:
> > I check the latest kernel source code with git, and find out that the
> > SMBus patch has not been applied yet,  
> 
> Correct.  When you don't see a patch in the upstream git tree 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 
> then the next step is consult the MAINTAINERS file, and determine to 
> whom you should send a follow-up patch, or simply contact about the 
> status of a patch you just sent.  In this case, SMBus is in drivers/i2c 
> sub-directory, which leads us to find in MAINTAINERS,
> 
> I2C SUBSYSTEM
> P:  Jean Delvare
> M:  [EMAIL PROTECTED]
> L:  [EMAIL PROTECTED]
> T:  quilt http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/
> S:  Maintained
> 
> That tells us the maintainer of the subsystem, and also ("T:") an 
> external reference (a tree) to where the maintainer posts accepted 
> patches, prior to sending them upstream.
> 
> So for SMBus, you should make sure your SMBus changes appear in Jean 
> Delvare's quilt tree.  If they do not, create a new patch and send it to 
> Jean and CC [EMAIL PROTECTED] and [EMAIL PROTECTED]
> 
> 
> > and the patch for IDE  has not been  applied completely.one more device
> > id should be added to pata_atiixp.c, 
> > l list the patch as following, or you can fetch it from the attached file,
> > could you please apply this for me?  
> 
> Actually it has been applied -- the part that I maintain (drivers/ata/*) 
> is currently stored in a secondary tree, as described above.  Your patch 
> has been stored on the 'upstream' branch of 
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> 
> Currently, the upstream Linux kernel is only accepting bug fixes.  I 
> merge ATA bug fixes (and sometimes simple PCI ID additions) into 
> libata-dev.git#upstream-fixes during this phase of development.  These 
> changes are sent upstream in 24-48 hours, to ensure that they will be 
> included in the next release (kernel 2.6.22).
> 
> All other ATA changes are merged into libata-dev.git#upstream.  When 
> Linus releases kernel 2.6.22, the "merge window" opens, allowing 
> non-bug-fix changes to be submitted upstream.  When the merge window 
> opens, I submit everything in libata-dev.git#upstream to Linus and 
> Andrew Morton for inclusion in the official upstream kernel tree.
> 
> That is our development process in a nutshell.
> 
> The kernel development process is conducted entirely via email, so you 
> see why it is so important to learn how to email patches in the proper 
> format.
> 
>   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: [ckrm-tech] [RFC] [PATCH 0/3] Add group fairness to CFS

2007-05-28 Thread Paul Menage

On 5/28/07, Peter Williams <[EMAIL PROTECTED]> wrote:


In any case, there's no point having cpu affinity if it's going to be
ignored.  Maybe you could have two levels of affinity: 1. if set by a
root it must be obeyed; and 2. if set by an ordinary user it can be
overridden if the best interests of the system dictate.  BUT I think
that would be a bad idea.


Something like that already exists (at least for controlling the
bounding set of allowed cpus) via cpusets.

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: [PATCH] add a trivial patch style checker

2007-05-28 Thread Qi Yong

On 28/05/07, Andy Whitcroft <[EMAIL PROTECTED]> wrote:

...


diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index a417b25..23637e8 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -118,7 +118,21 @@ then only post say 15 or so at a time and wait for review 
and integration.



...


-8) Name your kernel version.
+9) Name your kernel version.

 It is important to note, either in the subject line or in the patch
 description, the kernel version to which this patch applies.


If omitted, we could assume it default to the latest linus git tree.


-10) Include PATCH in the subject
+11) Include PATCH in the subject

 Due to high e-mail traffic to Linus, and to linux-kernel, it is common
 convention to prefix your subject line with [PATCH].  This lets Linus


or use "patch", to be easier to read.

--
Qi Yong
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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]Multi-threaded Initcall with dependence support

2007-05-28 Thread Yang Sheng
On Tuesday 29 May 2007 06:52, Randy Dunlap wrote:
> On Mon, 28 May 2007 15:03:10 +0800 Yang Sheng wrote:
> > Why we need this:
> >
> > It can speed up the calling of initcalls, especially useful for some
> > embed device.
>
> Can you give concrete example(s) of why we need this?
> Any real configs/hardware where it helps and how much it helps.
>

We didn't got the precise data at hand now, because we should build a complete  
stable initcall dependence relationship for it, but we can't do it now. 

But we have done a relative stable test in a common x86_64 machine, with 2 
threads and one dependence relation(pnpacpi_init depends on pnp_init and 
acpi_init). The result is the time spending on initcall calling reducing from 
about _5s_ to _2s_ (make the kernel with the defconfig). We analyzed the 
dmesg and found the most of time was save by run ide_generic_init and 
piix_init in parallel. 

Of course the dependence in the test case is not sufficient, but the effect is 
shown. 

We think this patch would be very useful in some embed deviced which requires 
fast boot speed. Some server may benefit too because of it's long time for 
device initiation. 

>
> General:
> 1/ Patch has 12 lines with trailing whitespace.  Please chop those
> off (always).
> 2/ Try to keep sources lines < 80 characters.
> 3/ Read & use Documentation/CodingStyle, Documentation/SubmittingPatches,
> and Documentation/SubmitChecklist.
>

Thanks for advise! Next time I will be more careful on coding style and check 
the patch following the document above. 

The patch below is a prototype now. Some problem can't be solve in current 
stage, like the map function's algorithm complexity is O(n^2). I have another 
method for this but require some duplicate name initcall's rename. 

Thanks!

> > Idea:
> >
> > 1. The initcall can indicate a executing sequence by using the a
> > macro(initcall_depend()) in case of causing dependence problem in
> > multi-threaded running. Multi dependences is also allowed.
> > 2. Ensure the calling of initcalls in the same layer would be completed
> > before the next layers' calling.
> >
> > Usage:
> > You can indicate that initcall A must be run after initcall B by calling
> > the macro in A's file:
> >
> > initcall_depend(A, B);
> >
> > Means initcall A must run after initcall B finish executing(A depends on
> > B).
> >
> > Take notice of that if you declare A depends on B and C, you must put
> > these together as (the sequences is not important):
> >
> > initcall_depend(A, B);
> > initcall_depend(A, C);
> >
> > The detail of method:
> >
> > A new section called .initcall.depend was added to
> > arch/xxx/kernel/vmlinux.lds.S to indicate the dependence relationship. A
> > struct called initcall_depend_t stored the relationship between A and B,
> > and was stored in section .initcall.depend.
> >
> > Because all the dependence of A are put together, and the sequences of
> > initcall_depend_t was decided in linker order as initcall itself did.
> > When A is going to run, we can check if A would depend on others by
> > checking the point indicate the current item in dependence table. If the
> > field "call" of initcall_depend_t point to A, we know that A is depend on
> > something and get the prev_addr of the struct to find what it depends on.
> > The field "prev_addr" point to somewhere in .initcall.init section to
> > indicate the address(also the order) of depended initcall, so it can be
> > used to find out whether other threads complete executing of the depended
> > initcall. If the current point of the thread executing is smaller than
> > prev_addr(it means some thread not completed executing, not only this
> > thread), we'll wait, otherwise we can continue to check next thread. If
> > all the thread is ok, we will run the initcall and go to the next one.
> >
> > This method is not very precision(for we may have to wait even when the
> > initcall was completed but not all the other pass it), but easy to
> > implement.
> >
> > I provide two method to get the dependence relationship, the following
> > code contains the one which is more flexibly but less efficiency.
> >
> > The downside of this patch is every driver must explictly indicate its
> > dependence, please tell if this is acceptable. Any suggestions and
> > comments are welcome.
> >
> > Thanks.
> >
> > 
> >
> >  arch/x86_64/kernel/vmlinux.lds.S |6 +
> >  include/linux/init.h |   16 +++
> >  init/main.c  |  257
> > +++-- 3 files changed, 237 insertions(+),
> > 42 deletions(-)
> >
> > diff --git a/arch/x86_64/kernel/vmlinux.lds.S
> > b/arch/x86_64/kernel/vmlinux.lds.S
> > index dbccfda..355c8b6 100644
> > --- a/arch/x86_64/kernel/vmlinux.lds.S
> > +++ b/arch/x86_64/kernel/vmlinux.lds.S
> > @@ -167,6 +167,12 @@ SECTIONS
> > INITCALLS
> >}
> >__initcall_end = .;
> > +  . = ALIGN(16);
> > +  __initcall_depend_start = .;
> > +  .initcall.depend : AT(ADDR(.initcall.depend) - 

Re: [PATCH 1/2] UDF: coding style conversion - lindent

2007-05-28 Thread WANG Cong
On Mon, May 28, 2007 at 06:30:38PM +0400, Cyrill Gorcunov wrote:
>This patch converts UDF coding style to kernel
>coding style using Lindent.
>
>Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
>---
>
> fs/udf/balloc.c|  709 ---
> fs/udf/crc.c   |   19 +-
> fs/udf/dir.c   |  132 ++---
> fs/udf/directory.c |  207 
> fs/udf/ecma_167.h  |  875 +---
> fs/udf/file.c  |  114 ++--
> fs/udf/fsync.c |4 +-
> fs/udf/ialloc.c|   69 ++--
> fs/udf/inode.c | 1494 ---
> fs/udf/lowlevel.c  |   25 +-
> fs/udf/misc.c  |  172 +++---
> fs/udf/namei.c |  720 +++
> fs/udf/osta_udf.h  |  239 
> fs/udf/partition.c |  273 ++
> fs/udf/super.c | 1630 
> fs/udf/symlink.c   |   56 +-
> fs/udf/truncate.c  |  230 +
> fs/udf/udf_i.h |2 +-
> fs/udf/udf_sb.h|6 +-
> fs/udf/udfdecl.h   |  106 +++--
> fs/udf/udfend.h|2 +-
> fs/udf/udftime.c   |   93 ++--
> fs/udf/unicode.c   |  299 +--
> 23 files changed, 3812 insertions(+), 3664 deletions(-)
>
>diff --git a/fs/udf/balloc.c b/fs/udf/balloc.c
>index 4cec910..ef48d09 100644
>--- a/fs/udf/balloc.c
>+++ b/fs/udf/balloc.c
>@@ -41,18 +41,17 @@
> #define uint(x) xuint(x)
> #define xuint(x) __le ## x
> 
>-static inline int find_next_one_bit (void * addr, int size, int offset)
>+static inline int find_next_one_bit(void *addr, int size, int offset)
> {
>-  uintBPL_t * p = ((uintBPL_t *) addr) + (offset / BITS_PER_LONG);
>-  int result = offset & ~(BITS_PER_LONG-1);
>+  uintBPL_t *p = ((uintBPL_t *) addr) + (offset / BITS_PER_LONG);
>+  int result = offset & ~(BITS_PER_LONG - 1);
>   unsigned long tmp;
> 
>   if (offset >= size)
>   return size;
>   size -= result;
>-  offset &= (BITS_PER_LONG-1);
>-  if (offset)
>-  {
>+  offset &= (BITS_PER_LONG - 1);
>+  if (offset) {
>   tmp = leBPL_to_cpup(p++);
>   tmp &= ~0UL << offset;
>   if (size < BITS_PER_LONG)
>@@ -62,8 +61,7 @@ static inline int find_next_one_bit (void * addr, int size, 
>int offset)
>   size -= BITS_PER_LONG;
>   result += BITS_PER_LONG;
>   }
>-  while (size & ~(BITS_PER_LONG-1))
>-  {
>+  while (size & ~(BITS_PER_LONG - 1)) {
>   if ((tmp = leBPL_to_cpup(p++)))
>   goto found_middle;
>   result += BITS_PER_LONG;
>@@ -72,17 +70,18 @@ static inline int find_next_one_bit (void * addr, int 
>size, int offset)
>   if (!size)
>   return result;
>   tmp = leBPL_to_cpup(p);
>-found_first:
>-  tmp &= ~0UL >> (BITS_PER_LONG-size);
>-found_middle:
>+  found_first:
>+  tmp &= ~0UL >> (BITS_PER_LONG - size);
>+  found_middle:


I doubt about this change. First, it seems that you replace a tab with 
whitespaces. Second, IMO, the labels should not be aligned with the statements.


>   return result + ffz(~tmp);
> }
> 
> #define find_first_one_bit(addr, size)\
>   find_next_one_bit((addr), (size), 0)
> 
>-static int read_block_bitmap(struct super_block * sb,
>-  struct udf_bitmap *bitmap, unsigned int block, unsigned long bitmap_nr)
>+static int read_block_bitmap(struct super_block *sb,
>+   struct udf_bitmap *bitmap, unsigned int block,
>+   unsigned long bitmap_nr)
> {
>   struct buffer_head *bh = NULL;
>   int retval = 0;
>@@ -92,38 +91,39 @@ static int read_block_bitmap(struct super_block * sb,
>   loc.partitionReferenceNum = UDF_SB_PARTITION(sb);
> 
>   bh = udf_tread(sb, udf_get_lb_pblock(sb, loc, block));
>-  if (!bh)
>-  {
>+  if (!bh) {
>   retval = -EIO;
>   }
>   bitmap->s_block_bitmap[bitmap_nr] = bh;
>   return retval;
> }
> 
>-static int __load_block_bitmap(struct super_block * sb,
>-  struct udf_bitmap *bitmap, unsigned int block_group)
>+static int __load_block_bitmap(struct super_block *sb,
>+ struct udf_bitmap *bitmap,
>+ unsigned int block_group)
> {
>   int retval = 0;
>   int nr_groups = bitmap->s_nr_groups;
> 
>-  if (block_group >= nr_groups)
>-  {
>-  udf_debug("block_group (%d) > nr_groups (%d)\n", block_group, 
>nr_groups);
>+  if (block_group >= nr_groups) {
>+  udf_debug("block_group (%d) > nr_groups (%d)\n", block_group,
>+nr_groups);
>   }
> 
>   if (bitmap->s_block_bitmap[block_group])
>   return block_group;
>-  else
>-  {
>-  retval = read_block_bitmap(sb, bitmap, block_group, 
>block_group);
>+  else {
>+  retval =
>+  read_block_bitmap(sb, bitmap, block_group, block_group);
>   if (retval < 0)
>   return 

Re: [PATCH] libata: implement ata_wait_after_reset()

2007-05-28 Thread Jeff Garzik

Tejun Heo wrote:

-   msleep(150);
+   /* wait a while before checking status */
+   ata_wait_after_reset(ap, deadline);

[...]

-   msleep(150);
+   /* wait a while before checking status */
+   ata_wait_after_reset(ap, deadline);
 
 	/* Before we perform post reset processing we want to see if

 * the bus shows 0xFF because the odd clown forgets the D7
@@ -3543,8 +3583,8 @@ int sata_std_hardreset(struct ata_port *
return 0;
}
 
-	/* wait a while before checking status, see SRST for more info */

-   msleep(150);
+   /* wait a while before checking status */
+   ata_wait_after_reset(ap, deadline);
 
 	rc = ata_wait_ready(ap, deadline);

[...]

-   msleep(150);
+   /* wait a while before checking status */
+   ata_wait_after_reset(ap, deadline);
 
 	/* Before we perform post reset processing we want to see if

 * the bus shows 0xFF because the odd clown forgets the D7
Index: work/drivers/ata/sata_inic162x.c
===
--- work.orig/drivers/ata/sata_inic162x.c
+++ work/drivers/ata/sata_inic162x.c
@@ -446,7 +446,7 @@ static int inic_hardreset(struct ata_por
struct ata_taskfile tf;
 
 		/* wait a while before checking status */

-   msleep(150);
+   ata_wait_after_reset(ap, deadline);
 
 		rc = ata_wait_ready(ap, deadline);

[...]

The main thing that bothers me is not the increase in delay, but the 
fact that this create converts a delay/Status-poll sequence into a 
delay/Status-poll/Status-poll sequence.


ata_wait_after_reset() immediately before ata_wait_ready() seems highly 
redundant.  Why not just poll Status once?


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: [PATCH] add a trivial patch style checker

2007-05-28 Thread Andi Kleen
Andy Whitcroft <[EMAIL PROTECTED]> writes:
> +
> +# no BUG() or BUG_ON()
> + if ($line =~ /\b(BUG|BUG_ON)\b/) {
> + print "Try to use WARN_ON & Recovery code rather than 
> BUG() or BUG_ON()\n";

Just outlawing BUG_ON doesn't seem like a good idea to me. We'll just end
up with lots of untested and likely buggy recovery code or no asserts. Both
would be bad.

> +#need space before brace following if, while, etc
> + if($line=~/\(.*\){/) {
> + print ("need a space before the brace\n");
> + print "$herecurr";
> + $clean = 0; 
> + }
> +
> +#gotos aren't indented

You mean goto labels? Surely goto statements are to be indented.
Confusing message

> + if($line=~/^\s*[A-Za-z\d_]+:/ and !($line=~/^\s*default:/)){
> + print "Gotos should not be indented\n";
> + print "$herecurr";
> + $clean = 0;
> + }

emacs generates one space label in front of a goto label. I wouldn't
outlaw this.

> +# don't include 

It would be probably better to define some syntax that makes it possible
to auto extract those from feature-removal-schedule.txt. Otherwise
long term this will become messy.

Possible further checks that might make sense:
- panic() anywhere in drivers/* 
- externs in .c files without asmlinkage
- general checking that everything in a fully visible {} block is the right 
indentation

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


Re: [patch] CFS scheduler, -v14

2007-05-28 Thread Li Yu

Li Yu wrote:


But as I observe by cat /proc/sched_debug (2.6.21.1, UP, RHEL4), I 
found the all waiting fields often are more than zero, or less than zero.


IMHO, the sum of task_struct->wait_runtime just is the denominator of 
all runnable time in some ways, is it right? if so, increasing the sum 
of wait_runtime just make scheduling decision more precise. so what's 
meaning for keeping the wait_runtime is zero-sum?



Forget it pls, here I am wrong, sorry for pestering.

Good luck

- Li Yu

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


Re: software suspend doesn't work with 2.6.22-rc3

2007-05-28 Thread Herbert Xu
On Mon, May 28, 2007 at 08:21:29PM +0200, Rafael J. Wysocki wrote:
>
> Well, it looks like we have to fix this one separately.
> 
> Can you please tell me what to do to make cryptd run?

If you build it as a module then just loading it should be sufficient.
If you have it built-in then it should always be there.

Let me know when you guys have a final patch.

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


Re: [ckrm-tech] [RFC] [PATCH 0/3] Add group fairness to CFS

2007-05-28 Thread Peter Williams

Srivatsa Vaddagiri wrote:

On Sat, May 26, 2007 at 10:17:42AM +1000, Peter Williams wrote:
I don't think that ignoring cpu affinity is an option.  Setting the cpu 
affinity of tasks is a deliberate policy action on the part of the 
system administrator and has to be honoured.  


mmm ..but users can set cpu affinity w/o administrator priveleges ..



OK. So you have to assume the users know what they're doing. :-)

In reality though, the policy of allowing ordinary users to set affinity 
on their tasks should be rethought.


In any case, there's no point having cpu affinity if it's going to be 
ignored.  Maybe you could have two levels of affinity: 1. if set by a 
root it must be obeyed; and 2. if set by an ordinary user it can be 
overridden if the best interests of the system dictate.  BUT I think 
that would be a bad idea.


Peter
--
Peter Williams   [EMAIL PROTECTED]

"Learning, n. The kind of ignorance distinguishing the studious."
 -- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: stuff ready to be deleted?

2007-05-28 Thread Daniel Hazelton
On Monday 28 May 2007 16:52:07 Robert P. J. Day wrote:
> On Mon, 28 May 2007, Oliver Pinter wrote:
> > + open sound system
>
> yeah, that one's so obvious, i don't even list it anymore. :-)  i'm
> assuming adrian's going to deal with that when the time comes.
>
> rday

And I thought OSS was being kept around until all the hardware it drives 
properly is also supported by ALSA. Last time this one came up there were 
still more than 5 items on the list of OSS supported hardware that wasn't 
covered under ALSA - and the list was likely longer.

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


Re: [PATCH] Fix potential memory leak in tipc_named_node_up()

2007-05-28 Thread Björn Steinbrink
On 2007.05.28 22:58:08 +0200, Jesper Juhl wrote:
> There seems to be a memory leak in net/tipc/name_distr.c::tipc_named_node_up()
> 
> The function, with comments, is this :
> 
> void tipc_named_node_up(unsigned long node)
> {
> struct publication *publ;
> struct distr_item *item = NULL;
> struct sk_buff *buf = NULL;
> u32 left = 0;
> u32 rest;
> u32 max_item_buf;
> 
> read_lock_bh(_nametbl_lock);
> max_item_buf = TIPC_MAX_USER_MSG_SIZE / ITEM_SIZE;
> max_item_buf *= ITEM_SIZE;
> rest = publ_cnt * ITEM_SIZE;
> 
> list_for_each_entry(publ, _root, local_list) {
> -> If we stop processing here after doing 1, 2 & 3 below we end up at (4) 
> (below).
> if (!buf) {
> left = (rest <= max_item_buf) ? rest : max_item_buf;
> rest -= left;
> buf = named_prepare_buf(PUBLICATION, left, node);
> -> (1) here we allocate memory and store a pointer to it in 'buf'.
> 
> if (!buf) {
> -> (2) This test needs to fail, meaning we did allocate some memory.
> warn("Bulk publication distribution 
> failure\n");
> goto exit;
> }
> item = (struct distr_item *)msg_data(buf_msg(buf));
> }
> publ_to_item(item, publ);
> item++;
> left -= ITEM_SIZE;
> if (!left) {
> -> (3) If this test fails we loop and do nothing to 'buf'.
> msg_set_link_selector(buf_msg(buf), node);
> dbg("tipc_named_node_up: sending publish msg to "
> "<%u.%u.%u>\n", tipc_zone(node),
> tipc_cluster(node), tipc_node(node));
> tipc_link_send(buf, node, node);
> buf = NULL;
> }
> }
> exit:
> read_unlock_bh(_nametbl_lock);
> -> (4) here we return without freeing 'buf' - memory leak.
> }
> 
> Luckily this is easy to fix, since we can only leave the function with 'buf'
> either set to NULL or (in the leak case) set to a valid address, and since 
> kfree() handles being passed NULL gracefully we can simply kfree(buf) just 
> before we leave the function.

Actually, I don't think that there's a leak.

publ_cnt: Number of items in the list

rest = publ_cnt * ITEM_SIZE
max_item_buf = n * ITEM_SIZE (Buffer can hold n elements at most)

1)
If publ_cnt <= n, "rest" becomes 0 and "left" becomes publ_cnt * ITEM_SIZE,
so for the last iteration "left" becomes 0 and "buf" is freed.

2)
And if publ_cnt > n, "left" becomes 0 in the nth iteration. As "rest"
already got decrement by n * ITEM_SIZE, you now got:
rest = (publ_cnt - n) * ITEM_SIZE
Then after 2*n iterations:
rest = (publ_cnt - 2*n) * ITEM_SIZE
and so on, until publ_cnt - m*n < n

At that point, "left" becomes (publ_cnt - m*n) * ITEM_SIZE, and there are
also (publ_cnt - m*n) iterations left, so "left" again becomes 0 in the
last iteration and "buf" is freed.


Besides that, is it valid to call kfree() on a buffer allocated by
alloc_skb()?

Thanks,
Björn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 3/3] ide_in_drive_list(): "ALL" is not a wildcard anymore.

2007-05-28 Thread Junio C Hamano
This removes the support to treat "ALL" as a wildcard for
firmware revision.  This is made a separate patch, as it will
break out-of-tree ide drivers that feed its own table that uses
"ALL" as the wildcard to ide_in_drive_list().

Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---

 * This is a respin of earlier "3/3 Make ide dma blacklist handling a bit 
saner."

 drivers/ide/ide-dma.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/drivers/ide/ide-dma.c b/drivers/ide/ide-dma.c
index 230ea12..3107b5e 100644
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -148,7 +148,6 @@ int ide_in_drive_list(struct hd_driveid *id, const struct 
drive_list_entry *driv
for ( ; drive_table->id_model ; drive_table++)
if ((!strcmp(drive_table->id_model, id->model)) &&
(!drive_table->id_firmware ||
-!strcmp(drive_table->id_firmware, "ALL") || /* to be 
removed later */
 strstr(id->fw_rev, drive_table->id_firmware)))
return 1;
return 0;
-- 
1.5.2.86.g99b5-dirty


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/3] mips au1xxx_ide.h: use NULL as firmware-revision wildcard.

2007-05-28 Thread Junio C Hamano
This updates the DMA whitelist in MIPS specific au1xxx ide
driver to use NULL instead of "ALL" as the wildcard.

Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---

 * This is a respin of earlier "3/3 Make ide dma blacklist handling a bit 
saner."

 include/asm-mips/mach-au1x00/au1xxx_ide.h |   28 ++--
 1 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/include/asm-mips/mach-au1x00/au1xxx_ide.h 
b/include/asm-mips/mach-au1x00/au1xxx_ide.h
index 8fcae21..4663e8b 100644
--- a/include/asm-mips/mach-au1x00/au1xxx_ide.h
+++ b/include/asm-mips/mach-au1x00/au1xxx_ide.h
@@ -88,26 +88,26 @@ static const struct drive_list_entry dma_white_list [] = {
 /*
  * Hitachi
  */
-{ "HITACHI_DK14FA-20",   "ALL"   },
-{ "HTS726060M9AT00"  ,   "ALL"   },
+{ "HITACHI_DK14FA-20",   NULL},
+{ "HTS726060M9AT00"  ,   NULL},
 /*
  * Maxtor
  */
-{ "Maxtor 6E040L0"  ,   "ALL"   },
-{ "Maxtor 6Y080P0"  ,   "ALL"   },
-{ "Maxtor 6Y160P0"  ,   "ALL"   },
+{ "Maxtor 6E040L0"  ,   NULL},
+{ "Maxtor 6Y080P0"  ,   NULL},
+{ "Maxtor 6Y160P0"  ,   NULL},
 /*
  * Seagate
  */
-{ "ST3120026A"  ,   "ALL"   },
-{ "ST320014A"   ,   "ALL"   },
-{ "ST94011A",   "ALL"   },
-{ "ST340016A"   ,   "ALL"   },
+{ "ST3120026A"  ,   NULL},
+{ "ST320014A"   ,   NULL},
+{ "ST94011A",   NULL},
+{ "ST340016A"   ,   NULL},
 /*
  * Western Digital
  */
-{ "WDC WD400UE-00HCT0"  ,   "ALL"   },
-{ "WDC WD400JB-00JJC0"  ,   "ALL"   },
+{ "WDC WD400UE-00HCT0"  ,   NULL},
+{ "WDC WD400JB-00JJC0"  ,   NULL},
 { NULL  ,   NULL}
 };
 
@@ -116,9 +116,9 @@ static const struct drive_list_entry dma_black_list [] = {
 /*
  * Western Digital
  */
-{ "WDC WD100EB-00CGH0"  ,   "ALL"   },
-{ "WDC WD200BB-00AUA1"  ,   "ALL"   },
-{ "WDC AC24300L",   "ALL"   },
+{ "WDC WD100EB-00CGH0"  ,   NULL},
+{ "WDC WD200BB-00AUA1"  ,   NULL},
+{ "WDC AC24300L",   NULL},
 { NULL  ,   NULL}
 };
 #endif
-- 
1.5.2.86.g99b5-dirty


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/3] ide_in_drive_list(): accept NULL as the wildcard for firmware revision.

2007-05-28 Thread Junio C Hamano
Earlier, the matching of (model,rev) in ide-dma black/white list
handling was to consider "ALL" in the table to match any
revision.  This makes NULL to be also an accepted wildcard, and
changes the entries of tables in ide-dma.c to use NULL.

The code still accepts "ALL" as the wildcard, in order to keep
any out-of-tree ide driver that feeds its own table that uses
"ALL" as the wildcard to ide_in_drive_list() function from
breaking.

Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
 * This is a respin of earlier "3/3 Make ide dma blacklist handling a bit 
saner."

 drivers/ide/ide-dma.c |   67 +
 1 files changed, 34 insertions(+), 33 deletions(-)

diff --git a/drivers/ide/ide-dma.c b/drivers/ide/ide-dma.c
index ead141e..230ea12 100644
--- a/drivers/ide/ide-dma.c
+++ b/drivers/ide/ide-dma.c
@@ -91,45 +91,45 @@
 
 static const struct drive_list_entry drive_whitelist [] = {
 
-   { "Micropolis 2112A",   "ALL"   },
-   { "CONNER CTMA 4000",   "ALL"   },
-   { "CONNER CTT8000-A",   "ALL"   },
-   { "ST34342A",   "ALL"   },
+   { "Micropolis 2112A",   NULL},
+   { "CONNER CTMA 4000",   NULL},
+   { "CONNER CTT8000-A",   NULL},
+   { "ST34342A",   NULL},
{ NULL  ,   NULL}
 };
 
 static const struct drive_list_entry drive_blacklist [] = {
 
-   { "WDC AC11000H",   "ALL"   },
-   { "WDC AC22100H",   "ALL"   },
-   { "WDC AC32500H",   "ALL"   },
-   { "WDC AC33100H",   "ALL"   },
-   { "WDC AC31600H",   "ALL"   },
+   { "WDC AC11000H",   NULL},
+   { "WDC AC22100H",   NULL},
+   { "WDC AC32500H",   NULL},
+   { "WDC AC33100H",   NULL},
+   { "WDC AC31600H",   NULL},
{ "WDC AC32100H",   "24.09P07"  },
{ "WDC AC23200L",   "21.10N21"  },
-   { "Compaq CRD-8241B",   "ALL"   },
-   { "CRD-8400B"   ,   "ALL"   },
-   { "CRD-8480B",  "ALL"   },
-   { "CRD-8482B",  "ALL"   },
-   { "CRD-84"  ,   "ALL"   },
-   { "SanDisk SDP3B"   ,   "ALL"   },
-   { "SanDisk SDP3B-64",   "ALL"   },
-   { "SANYO CD-ROM CRD",   "ALL"   },
-   { "HITACHI CDR-8"   ,   "ALL"   },
-   { "HITACHI CDR-8335",   "ALL"   },
-   { "HITACHI CDR-8435",   "ALL"   },
-   { "Toshiba CD-ROM XM-6202B" ,   "ALL"   },
-   { "TOSHIBA CD-ROM XM-1702BC",   "ALL"   },
-   { "CD-532E-A"   ,   "ALL"   },
-   { "E-IDE CD-ROM CR-840","ALL"   },
-   { "CD-ROM Drive/F5A",   "ALL"   },
-   { "WPI CDD-820","ALL"   },
-   { "SAMSUNG CD-ROM SC-148C", "ALL"   },
-   { "SAMSUNG CD-ROM SC",  "ALL"   },
-   { "ATAPI CD-ROM DRIVE 40X MAXIMUM", "ALL"   },
-   { "_NEC DV5800A",   "ALL"   },  
+   { "Compaq CRD-8241B",   NULL},
+   { "CRD-8400B"   ,   NULL},
+   { "CRD-8480B",  NULL},
+   { "CRD-8482B",  NULL},
+   { "CRD-84"  ,   NULL},
+   { "SanDisk SDP3B"   ,   NULL},
+   { "SanDisk SDP3B-64",   NULL},
+   { "SANYO CD-ROM CRD",   NULL},
+   { "HITACHI CDR-8"   ,   NULL},
+   { "HITACHI CDR-8335",   NULL},
+   { "HITACHI CDR-8435",   NULL},
+   { "Toshiba CD-ROM XM-6202B" ,   NULL},
+   { "TOSHIBA CD-ROM XM-1702BC",   NULL},
+   { "CD-532E-A"   ,   NULL},
+   { "E-IDE CD-ROM CR-840",NULL},
+   { "CD-ROM Drive/F5A",   NULL},
+   { "WPI CDD-820",NULL},
+   { "SAMSUNG CD-ROM SC-148C", NULL},
+   { "SAMSUNG CD-ROM SC",  NULL},
+   { "ATAPI CD-ROM DRIVE 40X MAXIMUM", NULL},
+   { "_NEC DV5800A",   NULL},
{ "SAMSUNG CD-ROM SN-124",  "N001" },
-   { "Seagate STT2A",  "ALL" },
+   { "Seagate STT2A",  NULL  },
{ NULL  ,   NULL}
 
 };
@@ -147,8 +147,9 @@ int ide_in_drive_list(struct hd_driveid 

Re: [PATCH 3/3] Make ide dma blacklist handling a bit saner.

2007-05-28 Thread Junio C Hamano
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> writes:

> The change itself looks good but IMO it is worth doing it before patch #2/3
> (it would also make it possible for me to merge this patch immediately).

Yes, I should have considered that the earlier #2/3 needs
coordination between you and Jeff.

> When it comes to patch #2 - Alan's comment may be a bit harsh but he seems
> to be right - there should be a common library-like file (ata-blacklist.c
> or ata-quirks.c or whatever name you like) containing ata_device_blacklist[].
>
> This would require slight modification of ide_in_drive_list() to teach
> it about ATA_HORKAGE_DMA ... Please also note that  is used by 
> both
> IDE and libata so it should be a good place to put struct ata_blacklist_entry
> and ATA_HORKAGE_* macros.

Thanks for the hint.  Alan is correct to point out that I
cheated. ;-)  If I understand correctly, the change would
involve:

 - create a new file that has ata_device_blacklist[] whose type
   is "struct ata_blacklist_entry" (i.e. matches libata-core),
   by separating the table out of ata/libata-core.c.

   Q1. should that file go to drivers/ata/ or drivers/ide/?

 - make that file depended on when either libata and/or IDE is
   selected.

   Q2. Kconfig dependency rule is needed for this, perhaps.  How
   should that look like?

 - some out-of-tree drivers might be using ide_in_drive_list()
   and relying on it to take "struct drive_list_entry"; create a
   new function, ide_in_device_list(), that takes "struct
   ata_blacklist_entry" as its parameter.

   Q3. Is the 'out-of-tree drivers' a real issue, and if so, is
   the above a reasonable avenue to take?

 - convert in-tree callers to use ide_in_device_list() instead,
   feeding it ata_device_blacklist[], and remove drive_blacklist[]
   from drivers/ide/ide-dma.c.

   Q4. What would you like to do for drive_whitelist[]?

> Care to respin both patches?

Before the questions are answered I cannot respin the earlier
#2/3, but I can certainly respin #3/3.




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


Portable syscall inspection

2007-05-28 Thread Trent Waddington

Someone finally noticed that my program that uses ptrace only works on i386..
and, by the looks of it, there is no portable way to refer to the
registers of a
user_regs_struct when inspecting a system call.

I will probably end up making a header file for each architecture that
defines where
in the user_regs_struct things like the syscall number, the return
value and the first 3 parameters are..

has anyone done this already?  or can otherwise save me a lot of time?

Thanks,

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


Re: b44: regression in 2.6.22 (resend)

2007-05-28 Thread Uwe Bugla
On Mon, 2007-05-28 at 22:55 +0200, Maximilian Engelhardt wrote:
> > > I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution
> > > Timer, but the high ping problem is still there.
> >
> > Hmm, that's mysterious. Wild guess is that highres exposes the hidden
> > "feature" in a different way than rc2-mm1 does.
>
> I think the bug in 2.6.21/22-rc3 is a different one that the one in
> 2.6.22-rc2-mm1, but that's also only a wild guess :)
>
> I'll explain this a bit:
> In 2.6.21/22-rc3 is the same b44 driver that has been in the stock kernels for
> some time. With this driver and High Resolution Timer turned on I get
> problems using iperf. The problems are that the systems becomes really slow
> and unresponsive. Michael Buesch thought this could be an IRQ storm which
> sounds logical to me. This bug did never happen to me before I startet the
> iperf test.

Can you please apply

http://www.tglx.de/projects/hrtimers/2.6.22-rc3/patch-2.6.22-rc3-hrt1.patch

on top of rc3 and check, whether it has any effect on your problem.

> The other issue happens only with 2.6.22-rc2-mm1 which includes the b44 ssb
> spilt. It's independed wether High Resolution Timer is turned on or off I
> always get very varying and high ping times. The iperf-test doesn't show the
> problems from 2.6.21/22-rc3.

Neither with nor without highres ?

tglx

Neither with nor without Gleixner ?

Neither with nor without Buesch ?

Neither with nor without Miller ?

Neither with nor without Kyle ?

Neither with nor without  ?

Neither with nor without would-like-to-spare time hackers ?

Neither with nor without profile neurotic would-like-to-copyright owners ?

___
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] LZO de/compression support - take 6

2007-05-28 Thread Bret Towe

On 5/28/07, Bret Towe <[EMAIL PROTECTED]> wrote:

On 5/28/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This is kernel port of LZO1X-1 compressor and LZO1X decompressor (safe
> version only).
>
> * Changes since 'take 5' (Full Changelog after this):
> - Added compressor and decomrpesssor as separate and hidden config
> options (default: n)
> - Cleanups: removed LZO_CHECK_MPOS_NON_DET macro
> - removed PTR* macros.
>
> * Benchmarks: (system: P4 3GHz, 1G RAM)
> (Using tester program from Daniel)
>
> Following compares this kernel port ('take 6') vs original miniLZO code:
>
> 'TinyLZO' refers to this kernel port.
>
> 1 run averages:
> 'Tiny LZO':
>Combined: 61.2223 usec
>Compression: 41.8412 usec
>Decompression: 19.3811 usec
> 'miniLZO':
>Combined: 66.0444 usec
>Compression: 46.6323 usec
>Decompression: 19.4121 usec
>
> Result:
> Overall: TinyLZO is 7.3% faster
> Compressor: TinyLZO is 10.2% faster
> Decompressor: TinyLZO is 0.15% faster
>
> TODO: test 'take 6' port on archs other than x86(_32)
>
> * Changelog vs. original LZO:
> 1) Used standard/kernel defined data types: (this eliminated _huge_
> #ifdef chunks)
>   lzo_bytep -> unsigned char *
>   lzo_uint -> size_t
>   lzo_xint -> size_t
>   lzo_uint32p -> u32 *
>   lzo_uintptr_t  -> unsigned long
> 2) Removed everything #ifdef'ed under COPY_DICT (this is not set for
> LZO1X, so removed corres. parts).
> 3) Removed code #ifdef'ed for LZO1Y, LZO1Z, other variants.
> 4) Reformatted the code to match general kernel style.
> 5) The only code change: (as suggested by Andrey)
> -#if defined(__LITTLE_ENDIAN)
> - m_pos = op - 1;
> - m_pos -= (*(const unsigned short *)ip) >> 2;
> -#else
> - m_pos = op - 1;
> - m_pos -= (ip[0] >> 2) + (ip[1] << 6);
> -#endif
>
> + m_pos = op - 1 - (cpu_to_le16(*(const u16 *)ip) >> 2);
>
> (Andrey suggested le16_to_cpu for above but I think it should be cpu_to_le16).
> *** Need testing on big endian machine ***
>
> Similarly:
> -#if defined(__LITTLE_ENDIAN)
> - m_pos -= (*(const unsigned short *)ip) >> 2;
> -#else
> - m_pos -= (ip[0] >> 2) + (ip[1] << 6);
> -#endif
>
> + m_pos -= cpu_to_le16(*(const u16 *)ip) >> 2;
>
> 6) Get rid of LZO_CHECK_MPOS_NON_DET macro and PTR* macros.
>
>
> I think it's now ready for mainline inclusion.
>
>
>  include/linux/lzo1x.h|   66 +++
>  lib/Kconfig  |6 +
>  lib/Makefile |2 +
>  lib/lzo1x/Makefile   |2 +
>  lib/lzo1x/lzo1x_compress.c   |  259

tested this on ppc and its still good
is there any reason to bother with a test on amd64?
if there is I might be able to get to it tonight



forgot to mention that it would make life easier if you would put the
version of the patch
in the .bz2 files you attach since you poping out new takes so quick
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] LZO de/compression support - take 6

2007-05-28 Thread Bret Towe

On 5/28/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:

Hi,

Attached is tester code used for testing.
(developed by Daniel Hazelton -- modified slightly to now use 'take 6'
version for 'TinyLZO')

Cheers,
Nitin

On 5/28/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:
> (Using tester program from Daniel)
>
> Following compares this kernel port ('take 6') vs original miniLZO code:
>
> 'TinyLZO' refers to this kernel port.
>
> 1 run averages:
> 'Tiny LZO':
>Combined: 61.2223 usec
>Compression: 41.8412 usec
>Decompression: 19.3811 usec
> 'miniLZO':
>Combined: 66.0444 usec
>Compression: 46.6323 usec
>Decompression: 19.4121 usec
>
> Result:
> Overall: TinyLZO is 7.3% faster
> Compressor: TinyLZO is 10.2% faster
> Decompressor: TinyLZO is 0.15% faster
>




1 run averages:
'Tiny LZO':
   Combined: 112.6642 usec
   Compression: 56.3321 usec
   Decompression: 56.3321 usec
'miniLZO':
   Combined: 77.6642 usec
   Compression: 56.3416 usec
   Decompression: 21.3226 usec

now the interesting bit I thought was the following
[EMAIL PROTECTED]:/usr/src/lzo1x-test-4# ./fulltest
[test_lzo.c::compress (93)] run took 42 microseconds
[test_lzo.c::decompress (127)] run took 20 microseconds
[EMAIL PROTECTED]:/usr/src/lzo1x-test-4# ./tinytest
[test.c::compress (91)] run took 44 microseconds
[test.c::decompress (117)] BUG: lzo1x_decompress has failed ( t == -6 )
[test.c::main (149)] BUG: Decompression routine failure
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] LZO de/compression support - take 6

2007-05-28 Thread Bret Towe

On 5/28/07, Nitin Gupta <[EMAIL PROTECTED]> wrote:

Hi,

This is kernel port of LZO1X-1 compressor and LZO1X decompressor (safe
version only).

* Changes since 'take 5' (Full Changelog after this):
- Added compressor and decomrpesssor as separate and hidden config
options (default: n)
- Cleanups: removed LZO_CHECK_MPOS_NON_DET macro
- removed PTR* macros.

* Benchmarks: (system: P4 3GHz, 1G RAM)
(Using tester program from Daniel)

Following compares this kernel port ('take 6') vs original miniLZO code:

'TinyLZO' refers to this kernel port.

1 run averages:
'Tiny LZO':
   Combined: 61.2223 usec
   Compression: 41.8412 usec
   Decompression: 19.3811 usec
'miniLZO':
   Combined: 66.0444 usec
   Compression: 46.6323 usec
   Decompression: 19.4121 usec

Result:
Overall: TinyLZO is 7.3% faster
Compressor: TinyLZO is 10.2% faster
Decompressor: TinyLZO is 0.15% faster

TODO: test 'take 6' port on archs other than x86(_32)

* Changelog vs. original LZO:
1) Used standard/kernel defined data types: (this eliminated _huge_
#ifdef chunks)
  lzo_bytep -> unsigned char *
  lzo_uint -> size_t
  lzo_xint -> size_t
  lzo_uint32p -> u32 *
  lzo_uintptr_t  -> unsigned long
2) Removed everything #ifdef'ed under COPY_DICT (this is not set for
LZO1X, so removed corres. parts).
3) Removed code #ifdef'ed for LZO1Y, LZO1Z, other variants.
4) Reformatted the code to match general kernel style.
5) The only code change: (as suggested by Andrey)
-#if defined(__LITTLE_ENDIAN)
- m_pos = op - 1;
- m_pos -= (*(const unsigned short *)ip) >> 2;
-#else
- m_pos = op - 1;
- m_pos -= (ip[0] >> 2) + (ip[1] << 6);
-#endif

+ m_pos = op - 1 - (cpu_to_le16(*(const u16 *)ip) >> 2);

(Andrey suggested le16_to_cpu for above but I think it should be cpu_to_le16).
*** Need testing on big endian machine ***

Similarly:
-#if defined(__LITTLE_ENDIAN)
- m_pos -= (*(const unsigned short *)ip) >> 2;
-#else
- m_pos -= (ip[0] >> 2) + (ip[1] << 6);
-#endif

+ m_pos -= cpu_to_le16(*(const u16 *)ip) >> 2;

6) Get rid of LZO_CHECK_MPOS_NON_DET macro and PTR* macros.


I think it's now ready for mainline inclusion.


 include/linux/lzo1x.h|   66 +++
 lib/Kconfig  |6 +
 lib/Makefile |2 +
 lib/lzo1x/Makefile   |2 +
 lib/lzo1x/lzo1x_compress.c   |  259


tested this on ppc and its still good
is there any reason to bother with a test on amd64?
if there is I might be able to get to it tonight
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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][EXPERIMENTAL] Make kernel threads nonfreezable by default

2007-05-28 Thread Nigel Cunningham
Hi.

On Tue, 2007-05-29 at 00:51 +0200, Rafael J. Wysocki wrote:
> > The copy_flags routine changes another process's flags - that's why
> I
> > was suggesting this.
> 
> Yes, it does, but I'm dropping the clearing of PF_NOFREEZE from there,
> not adding anything new. :-)

Doh! Sorry :)

Nigel


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


Re: pcmcia resume 60 second hang. Re: [patch 00/69] -stable review

2007-05-28 Thread Nigel Cunningham
Hi.

On Mon, 2007-05-28 at 14:03 +0100, Matthew Garrett wrote:
> On Mon, May 28, 2007 at 02:55:07PM +0200, Pavel Machek wrote:
> 
> > Well, PPC people are aware of this, and they think they can fix the
> > drivers. We probably want to drop the freezer for suspend long-term,
> > so. PPC machines use small subset of all the drivers, so it apparently
> > is not big problem for them.
> 
> I'm fairly certain that PPC uses USB. In any case, it's not limited to 
> PPC - APM has the same issue. Any driver that assumes processes will be 
> frozen during suspend to RAM is broken now, not the future.

The converse is also true, though. Any process that assumes processes
aren't frozen during suspend to RAM is also broken now, and will be
while we allow the possibility of suspending to ram after writing a
hibernation image.

In short, drivers should be designed to work whether processes are
frozen or not.

Regards,

Nigel


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


Re: [2.6.21.1] resume doesn't run suspended kernel?

2007-05-28 Thread Nigel Cunningham
Hi.

On Mon, 2007-05-28 at 19:57 +0200, Rafael J. Wysocki wrote:
> On Monday, 28 May 2007 15:26, Pavel Machek wrote:
> > Hi!
> > 
> > > >That's clear, I'll have to use xen or kvm or similar which restores 
> > > >the system as suspended. Thanks for the clarification of the limitations.
> > > >
> > > Sorry, I wrote that late at night and quickly. I should have said 
> > > "design decision" rather than "limitation," For systems which don't do 
> > > multiple kernels it's not an issue.
> > > 
> > > I certainly would not have made the same decision, but I didn't write 
> > > the code. It seems more robust to save everything than to try to 
> > > identify what has and hasn't changed in a modular kernel.
> > 
> > We rely on atomic copy routine not moving inside the kernel. Yes, it
> > would be possible to copy it to "known good" address and gain ability
> > to resume different kernels. Actually it should not be _that_ hard.
> 
> Yup.  Don't we do something like this for the (ACPI-based) suspend to RAM
> already?

Yeah, I was thinking about this overnight too. It should be doable. In
addition to what we already do, I think you'd want:

- to copy the assembly to do the copying to a safe page;
- to put the location of the cpu state that was saved in the image
header so that it can be used after the data is copied back;
- to copy the nosave data to a 'safe' page.

What else?

Regards,

Nigel


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


Re: [RFC PATCH]Multi-threaded Initcall with dependence support

2007-05-28 Thread Randy Dunlap
On Mon, 28 May 2007 15:03:10 +0800 Yang Sheng wrote:

> Why we need this:
> 
> It can speed up the calling of initcalls, especially useful for some embed 
> device. 

Can you give concrete example(s) of why we need this?
Any real configs/hardware where it helps and how much it helps.


General:
1/ Patch has 12 lines with trailing whitespace.  Please chop those
off (always).
2/ Try to keep sources lines < 80 characters.
3/ Read & use Documentation/CodingStyle, Documentation/SubmittingPatches,
and Documentation/SubmitChecklist.


> Idea:
> 
> 1. The initcall can indicate a executing sequence by using the a 
> macro(initcall_depend()) in case of causing dependence problem in 
> multi-threaded running. Multi dependences is also allowed.
> 2. Ensure the calling of initcalls in the same layer would be completed 
> before 
> the next layers' calling.
> 
> Usage:
> You can indicate that initcall A must be run after initcall B by calling the 
> macro in A's file:
> 
> initcall_depend(A, B);
> 
> Means initcall A must run after initcall B finish executing(A depends on B).
> 
> Take notice of that if you declare A depends on B and C, you must put these 
> together as (the sequences is not important):
> 
> initcall_depend(A, B);
> initcall_depend(A, C);
> 
> The detail of method:
> 
> A new section called .initcall.depend was added to 
> arch/xxx/kernel/vmlinux.lds.S to indicate the dependence relationship. A 
> struct called initcall_depend_t stored the relationship between A and B, and 
> was stored in section .initcall.depend.
> 
> Because all the dependence of A are put together, and the sequences of 
> initcall_depend_t was decided in linker order as initcall itself did. When A 
> is going to run, we can check if A would depend on others by checking the 
> point indicate the current item in dependence table. If the field "call" of 
> initcall_depend_t point to A, we know that A is depend on something and get 
> the prev_addr of the struct to find what it depends on. The field "prev_addr" 
>  
> point to somewhere in .initcall.init section to indicate the address(also the 
> order) of depended initcall, so it can be used to find out whether other 
> threads complete executing of the depended initcall. If the current point of 
> the thread executing is smaller than prev_addr(it means some thread not 
> completed executing, not only this thread), we'll wait, otherwise we can 
> continue to check next thread. If all the thread is ok, we will run the 
> initcall and go to the next one.
> 
> This method is not very precision(for we may have to wait even when the 
> initcall was completed but not all the other pass it), but easy to implement. 
> 
> I provide two method to get the dependence relationship, the following code 
> contains the one which is more flexibly but less efficiency.
> 
> The downside of this patch is every driver must explictly indicate its 
> dependence, please tell if this is acceptable. Any suggestions and comments 
> are welcome.
> 
> Thanks.
> 
> 
> 
>  arch/x86_64/kernel/vmlinux.lds.S |6 +
>  include/linux/init.h |   16 +++
>  init/main.c  |  257 +++--
>  3 files changed, 237 insertions(+), 42 deletions(-)
> 
> diff --git a/arch/x86_64/kernel/vmlinux.lds.S 
> b/arch/x86_64/kernel/vmlinux.lds.S
> index dbccfda..355c8b6 100644
> --- a/arch/x86_64/kernel/vmlinux.lds.S
> +++ b/arch/x86_64/kernel/vmlinux.lds.S
> @@ -167,6 +167,12 @@ SECTIONS
>   INITCALLS
>}
>__initcall_end = .;
> +  . = ALIGN(16);
> +  __initcall_depend_start = .;
> +  .initcall.depend : AT(ADDR(.initcall.depend) - LOAD_OFFSET) {
> + *(.initcall.depend)
> +  }
> +  __initcall_depend_end = .;
>__con_initcall_start = .;
>.con_initcall.init : AT(ADDR(.con_initcall.init) - LOAD_OFFSET) {
>   *(.con_initcall.init)
> diff --git a/include/linux/init.h b/include/linux/init.h
> index 56ec4c6..68134d7 100644
> --- a/include/linux/init.h
> +++ b/include/linux/init.h
> @@ -73,7 +73,17 @@
>  /*
>   * Used for initialization calls..
>   */
> +
>  typedef int (*initcall_t)(void);
> +
> +typedef struct {
> + initcall_t call;
> + union {
> + initcall_t func;
> + initcall_t* addr;
> + } prev;
> +} initcall_depend_t;

Don't add typedefs as shortcuts for struct names.

> +
>  typedef void (*exitcall_t)(void);
>  
>  extern initcall_t __con_initcall_start[], __con_initcall_end[];
> @@ -108,6 +118,12 @@ void prepare_namespace(void);
>   static initcall_t __initcall_##fn##id __attribute_used__ \
>   __attribute__((__section__(".initcall" level ".init"))) = fn
>  
> +#define initcall_depend(fn, req) \
> + static initcall_depend_t __dependency_##fn_after_##req \
> + __attribute_used__ __attribute__((__section__(".initcall.depend"))) = { 
> \
> + .call = fn, \
> + .prev.func = req }
> +
>  /*
>   * A "pure" initcall has no dependencies on anything else, and purely
>   * initializes 

Re: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

2007-05-28 Thread Rafael J. Wysocki
On Monday, 28 May 2007 23:26, Nigel Cunningham wrote:
> Hi.
> 
> On Mon, 2007-05-28 at 20:17 +0200, Rafael J. Wysocki wrote:
> > On Monday, 28 May 2007 11:46, Nigel Cunningham wrote:
> > > Hello!
> > > 
> > > In reply to your more recent message, I had looked but not tried, so
> > > didn't feel in a position to reply yet.
> > > 
> > > On Sun, 2007-05-27 at 00:12 +0200, Rafael J. Wysocki wrote:
> > > >  63 files changed, 78 insertions(+), 138 deletions(-)
> > > 
> > > Well, that looks good, for a start :)
> > > 
> > > > Index: linux-2.6.22-rc3/kernel/exit.c
> > > > ===
> > > > --- linux-2.6.22-rc3.orig/kernel/exit.c
> > > > +++ linux-2.6.22-rc3/kernel/exit.c
> > > > @@ -389,6 +389,11 @@ void daemonize(const char *name, ...)
> > > >  * they would be locked into memory.
> > > >  */
> > > > exit_mm(current);
> > > > +   /*
> > > > +* We don't want to have TIF_FREEZE set if the system-wide 
> > > > hibernation
> > > > +* or suspend transision begins right now.
> > > > +*/
> > > > +   current->flags |= PF_NOFREEZE;
> > > 
> > > s/transision/transition
> > 
> > Thanks, will fix.
> > 
> > > > set_special_pids(1, 1);
> > > > proc_clear_tty(current);
> > > > Index: linux-2.6.22-rc3/include/linux/freezer.h
> > > > ===
> > > > --- linux-2.6.22-rc3.orig/include/linux/freezer.h
> > > > +++ linux-2.6.22-rc3/include/linux/freezer.h
> > > > @@ -118,6 +118,14 @@ static inline int freezer_should_skip(st
> > > > return !!(p->flags & PF_FREEZER_SKIP);
> > > >  }
> > > >  
> > > > +/*
> > > > + * Tell the freezer that the current task should be frozen by it
> > > > + */
> > > > +static inline void set_freezable(void)
> > > > +{
> > > > +   current->flags &= ~PF_NOFREEZE;
> > > > +}
> > > > +
> > > 
> > > Given the clearing of the flag above, should we just have a
> > > set_unfreezeable here that's used above (and potentially elsewhere)...
> > > (reads more)... or more generic set_[un]freezeable(task_struct *p)
> > > routines that could also be used in copy_flags below?
> > 
> > Yes, I can introduce set_unfreezeable(), although that would be used in
> > a couple of places only.
> > 
> > I don't think it's a good idea to have set_[un]freezeable(task_struct *p),
> > since only current is allowed to set/unset its flags.
> 
> The copy_flags routine changes another process's flags - that's why I
> was suggesting this.

Yes, it does, but I'm dropping the clearing of PF_NOFREEZE from there,
not adding anything new. :-)

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


Re: stuff ready to be deleted?

2007-05-28 Thread Robert P. J. Day
On Mon, 28 May 2007, Robert P. J. Day wrote:

> On Mon, 28 May 2007, Jan Engelhardt wrote:
>
> >
> > On May 28 2007 16:15, Robert P. J. Day wrote:
> > >removing dead content from the tree:
> > >
> > >http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List
> > >
> > >currently, the list contains the items:
> > >
> > >* 4 Traffic policing
> >
> > CONFIG_NET_SCHED? CONFIG_NET_ACT_POLICE? Neither seems
> > marked as deprecated/obsoleted in Kconfig.
>
> the "traffic policing" entry in that list refers specifically to the
> config option "CLS_NET_POLICE" in net/sched/Kconfig:
>
> config NET_CLS_POLICE
> bool "Traffic Policing (obsolete)"
> depends on NET_CLS_ACT!=y
> select NET_ESTIMATOR
> ---help---
>   Say Y here if you want to do traffic policing, i.e. strict
>   bandwidth limiting. This option is obsoleted by the traffic
>   policer implemented as action, it stays here for compatibility
>   reasons.
>
> so ... does "obsolete" really mean "obsolete"?

whoops, the URL i gave above is only for the main page, not for the
specific "stuff to be removed" list here:

http://fsdev.net/wiki/index.php?title=Stuff_to_be_removed

rday
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/7 RESEND] cxgb3 - Update FW to 4.1

2007-05-28 Thread Jeff Garzik

[EMAIL PROTECTED] wrote:

From: Divy Le Ray <[EMAIL PROTECTED]>

Bump FW version to 4.1.
Modify chip tuning in consequence.

Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---

 drivers/net/cxgb3/regs.h|4 
 drivers/net/cxgb3/t3_hw.c   |   40 ++--
 drivers/net/cxgb3/version.h |2 +-
 3 files changed, 27 insertions(+), 19 deletions(-)


You think requiring a FIRMWARE UPGRADE is something that should be done 
in the middle of a kernel bugfix series?  What Q/A planet are you from?


This is a completely ridiculous burden you are placing on the individual 
user.  A good driver knows that firmware NOT SHIPPED WITH THE KERNEL 
does not necessarily move in lock-step with the kernel driver.  You are 
welcome to GPL your firmware and ship it of course


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: [PATCH 3/7] cxgb3 - Fix direct XAUI support

2007-05-28 Thread Jeff Garzik

[EMAIL PROTECTED] wrote:

From: Divy Le Ray <[EMAIL PROTECTED]>

Check all lanes for link status on direct XAUI cards.
Don't assume that direct XAUI always uses XGMAC 1.

Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---

 drivers/net/cxgb3/ael1002.c |   10 --
 drivers/net/cxgb3/regs.h|2 ++
 2 files changed, 10 insertions(+), 2 deletions(-)


ACK


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

2007-05-28 Thread Jeff Garzik

[EMAIL PROTECTED] wrote:

From: Divy Le Ray <[EMAIL PROTECTED]>

Fix netpoll handler to work with line interrupt, msi and msi-x.

Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---

 drivers/net/cxgb3/cxgb3_main.c |   12 +---
 drivers/net/cxgb3/sge.c|1 -
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index 67b4b21..e0ef724 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -2076,10 +2076,16 @@ static void vlan_rx_kill_vid(struct net_
 static void cxgb_netpoll(struct net_device *dev)
 {
struct adapter *adapter = dev->priv;
-   struct sge_qset *qs = dev2qset(dev);
+   struct port_info *pi = netdev_priv(dev);
+   int qidx;
 
-	t3_intr_handler(adapter, qs->rspq.polling) (adapter->pdev->irq,

-   adapter);
+   for (qidx = pi->first_qset; qidx < pi->first_qset + pi->nqsets; qidx++) 
{
+   struct sge_qset *qs = >sge.qs[qidx];
+   
+		t3_intr_handler(adapter, qs->rspq.polling) (0, 
+	(adapter->flags & USING_MSIX) ?

+   (void *)qs : (void *)adapter);


Remove needless casts to void*


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


Re: [PATCH 1/7] cxgb3 - Fix SGE page management

2007-05-28 Thread Jeff Garzik

[EMAIL PROTECTED] wrote:

From: Divy Le Ray <[EMAIL PROTECTED]>

Streamline page management on RX.
Fix dma mappings.

Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>


NAK #1:  "streamline" is not a bug-fixes-only change, which is the only 
type of change appropriate for 2.6.22-rc.


NAK #2:  You should use the page_address(page) accessor rather than 
creating a struct member in the same struct as your page, solely to 
contain the virtual address.



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


Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

2007-05-28 Thread Crispin Cowan
Cliffe wrote:
> The following would be used in conjunction with a pathname based
> confinement to try to provide some assurances about what a path refers
> to.
>
> "/etc/shadow" is a name to a sensitive resource. There is no guarantee
> that there are not other ways to access this resource. For example a
> link "/etc/shadowlink" or a rename to "/etc/shadownewname"
>
> Pathname based security has various advantages (such as the ability to
> have more readable and centralised policies by describing resources in
> terms of their pathnames) but the above is clearly a problem (if
> confidentiality or integrity of a specific resource is important).
>
> Could we find a way to make paths a more reliable mechanism by
> labeling the file data with a simple description of names it is
> allowed to be accessed with?
>
> If we want "/etc/shadow" to be the only way to access the shadow file
> we could label the data with "/etc/shadow". Any attempts to access
> this data using a renamed file or link would be denied (attempts to
> link or rename could also be denied).
Eloquently put.

AppArmor actually does something similar to this, by mediating all of
the ways that you can make an alias to a file. These are:

* Symbolic links: these actually don't work for making aliases with
  respect to LSM-based security systems such as AppArmor, SELinux,
  and TOMOYO Linux, because the symbolic link is resolved before the
  access request is presented to the LSM hooks. So if you create the
  symbolic link /tmp/harmless -> /etc/shadow and then the confined
  victim tries to access /tmp/harmless, what the LSM sees is an
  attempt to access /etc/shadow.
* Hard links: AppArmor explicitly mediates permission to make a hard
  link to a file. To be able to make a hard link /tmp/harmless ->
  /etc/shadow you have to have explicit permission to do so, or the
  attempt to make the link is blocked. This mediation is kept
  relatively simple by the fact that you can only hard link to
  files, and not to directories.
* Multiple mounts: Linux lets you mount the same file system
  multiple times at multiple mount points, so the same file could
  appear at two different places. AppArmor has very coarse mediation
  here, and simply prohibits all calls to mount() without special
  permission. So only highly privileged processes can create such an
  alias.
* Name spaces: Linux name spaces present a similar issue, and
  AppArmor's coarse blocking of mount() serves the same function;
  only highly privileged processes are permitted to create name spaces.


> We could label a document with "/home/me/documents/*". Then the
> document could be linked or renamed within that specified directory.
We are thinking about something kind of like this for finer-grained
mediation of mount(). Currently it is all-or-nothing; we either totally
block the ability to create aliases with multiple mount points or name
spaces, or we totally trust the process with permission to do what it
likes with multiple mount point and name space aliases.

What we want is a more nuanced mediation of mount point and name space
manipulation, so that you can write a spec that says "/tmp/* can be
aliased any way you like, but /etc/shadow cannot be aliased at all" or
something like that.

However, not much work has been done on this, because at the moment the
AppArmor team is concentrating on making the code for current
functionality acceptable for upstreaming.

> Obvious problems with this solution:
> * it seems hard to determine what the label should be set to (setting
> it to "*" would be tempting and completely negate the whole thing,
> while setting it to the current filename would often be too restrictive).
This is equivalent to the question of what kind of access to grant to
the data. I don't see it as really difficult. What is harder is that the
specification has to specify what you can alias, and where it can
appear, and dealing with the two factors tends to make one's head hurt.

I am reminded of the pithy quote "Noalias must go. This is not
negotiable" -- Dennis Ritchie, referring to a proposed 'noalias' type
qualifier in ANSI C http://www.lysator.liu.se/c/dmr-on-noalias.html

Mediating permission to make aliases is complicated :(

> * when files are created these labels need to be created, and they may
> need to be changed.
.. if you use the approach of labeling the files :) In fact this
problem is general: label-based security has a hard time dealing with
new files in general, not just with respect to permission to create
aliases. The security policy for a newly created file is determined by
the label on the file, and so labeling new files is critical. SELinux
uses a variety of smart heuristics to decide the label of a new file:

* the label of the parent directory
* the label of the creating process
* the domain for the creating process can do conditional things
  based on the 

Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend

2007-05-28 Thread Alan Stern
On Mon, 28 May 2007, Pavel Machek wrote:

> > The theoretical answer is that it behaves the way we want.  The kernel 
> > thread does selective resumes in response to device requests.  If such 
> > a request comes in while the system is asleep it will awaken the 
> > system; so it's only logical that a request coming in while the system 
> > is in the process of going to sleep should abort the suspend.
> 
> I'd say that it shows ppc being broken. User wanted to suspend the
> system, and now unrelated task did lsusb... and system will not sleep.
> 
> AFAICT it is DoS issue -- if one of your users keeps doing lsusb, root
> will not be able to suspend the system.

This is a matter of one's philosophy.  In suspend-to-RAM, should tasks
be frozen or should I/O queues be frozen?

With the USB subsystem I have followed the approach taken by the PM
core, which is that tasks are frozen.  But one can -- and Linus has on
at least one occasion -- make a good case that tasks should be left
running while only I/O is frozen.  This would require the subsystem to
distinguish between a selective device suspend and a system-wide
suspend-to-RAM, so that selective resume could be enabled on demand in
one case but not the other.

It's quite doable in principle -- it's just not the technique I used.

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: stuff ready to be deleted?

2007-05-28 Thread Jeff Garzik

Bill Davidsen wrote:
OSS [is] maintained by an 
independent commercial company (4Front) so maintenance isn't an issue, 


False.  OSS drivers have been largely maintainerless for years.

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: stuff ready to be deleted?

2007-05-28 Thread Robert P. J. Day
On Mon, 28 May 2007, Jan Engelhardt wrote:

>
> On May 28 2007 16:15, Robert P. J. Day wrote:
> >removing dead content from the tree:
> >
> >http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List
> >
> >currently, the list contains the items:
> >
> >* 4 Traffic policing
>
> CONFIG_NET_SCHED? CONFIG_NET_ACT_POLICE? Neither seems
> marked as deprecated/obsoleted in Kconfig.

the "traffic policing" entry in that list refers specifically to the
config option "CLS_NET_POLICE" in net/sched/Kconfig:

config NET_CLS_POLICE
bool "Traffic Policing (obsolete)"
depends on NET_CLS_ACT!=y
select NET_ESTIMATOR
---help---
  Say Y here if you want to do traffic policing, i.e. strict
  bandwidth limiting. This option is obsoleted by the traffic
  policer implemented as action, it stays here for compatibility
  reasons.

so ... does "obsolete" really mean "obsolete"?

rday
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page

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


Re: stuff ready to be deleted?

2007-05-28 Thread Bill Davidsen

Oliver Pinter wrote:

+ open sound system


Why?

OSS supports some hardware ALSA doesn't, it's maintained by an 
independent commercial company (4Front) so maintenance isn't an issue, 
and it's portable to many other operating systems.


Functionality and low TCO, what could be better?

New Linux code, including x86_64 3D drivers, was released in April, so 
there's no lack of new features and activity.


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


PROBLEM: V4L2 - Leadtek Winfast PVR 2000 XP makes partial kernel freeze

2007-05-28 Thread [EMAIL PROTECTED]
Kernel very often freezes when I watch TV on my card TV Leadtek Winfast 
PVR 2000 XP.
When I watch TV in KdeTV, I got message like "problem with v4l2" and 
then no picture, only sound. (Some tv applications dont run at all). 
After that I can normally work witch computer but I can't run ps aux, 
which freezes and turn off computer.


Kernel version: 2.6.20.x (kernel in ubuntu 2.6.20-15 is ok, but 
2.6.20-16 is not), 2.6.21.1(my compilation), 2.6.21.2(my compilation)


This reports are from 2.6.20-15-generic:

cat /proc/cpuinfo:

processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 15
model   : 75
model name  : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
stepping: 2
cpu MHz : 1000.000
cache size  : 512 KB
physical id : 0
siblings: 2
core id : 0
cpu cores   : 2
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp 
lm 3dno

wext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy
bogomips: 2011.54
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc

processor   : 1
vendor_id   : AuthenticAMD
cpu family  : 15
model   : 75
model name  : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
stepping: 2
cpu MHz : 1000.000
cache size  : 512 KB
physical id : 0
siblings: 2
core id : 1
cpu cores   : 2
fpu : yes
fpu_exception   : yes
cpuid level : 1
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca 
cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp 
lm 
3dno   
wext 3dnow pni cx16 lahf_lm cmp_legacy svm cr8_legacy

bogomips: 2011.54
TLB size: 1024 4K pages
clflush size: 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: ts fid vid ttp tm stc



cat /proc/modules:

snd_rtctimer 5216 1 - Live 0x88c06000
rfcomm 45352 0 - Live 0x88bf9000
l2cap 28160 5 rfcomm, Live 0x88bf1000
bluetooth 62340 4 rfcomm,l2cap, Live 0x88be
ppdev 11272 0 - Live 0x88bdc000
capifs 7824 1 - Live 0x88bd9000
powernow_k8 16480 1 - Live 0x88bd3000
cpufreq_userspace 6176 0 - Live 0x88bd
cpufreq_stats 8416 0 - Live 0x88bcc000
cpufreq_powersave 3072 0 - Live 0x8807e000
cpufreq_ondemand 10640 1 - Live 0x88bc8000
freq_table 6336 3 powernow_k8,cpufreq_stats,cpufreq_ondemand, Live 
0x88bc5000

cpufreq_conservative 9736 0 - Live 0x88bc1000
tc1100_wmi 9224 0 - Live 0x88bbd000
sony_acpi 7064 0 - Live 0x88bba000
pcc_acpi 15616 0 - Live 0x88bb5000
dev_acpi 17028 0 - Live 0x88baf000
video 19080 0 - Live 0x88ba9000
sbs 17856 0 - Live 0x88ba3000
i2c_ec 6784 1 sbs, Live 0x88ba
dock 11992 0 - Live 0x88b9c000
container 6144 0 - Live 0x88b99000
button 10016 0 - Live 0x88b95000
battery 12040 0 - Live 0x88b91000
asus_acpi 19756 0 - Live 0x88b8b000
backlight 8448 1 asus_acpi, Live 0x88b87000
ac 6920 0 - Live 0x88b84000
nls_utf8 3456 1 - Live 0x88079000
ntfs 101960 1 - Live 0x88b6a000
reiserfs 248576 1 - Live 0x88b2c000
ext2 72464 1 - Live 0x88b19000
mbcache 11400 1 ext2, Live 0x88b15000
it87 24336 0 - Live 0x88b0e000
hwmon_vid 4864 1 it87, Live 0x88b0b000
i2c_isa 7680 1 it87, Live 0x88b08000
eeprom 9744 0 - Live 0x88b04000
lp 15048 0 - Live 0x88aff000
fuse 51888 0 - Live 0x88af1000
snd_intel8x0 38952 1 - Live 0x88ae6000
snd_ac97_codec 117720 1 snd_intel8x0, Live 0x88ac8000
ac97_bus 3968 1 snd_ac97_codec, Live 0x88071000
snd_pcm_oss 49536 0 - Live 0x88aba000
snd_mixer_oss 19840 1 snd_pcm_oss, Live 0x88ab4000
snd_pcm 92808 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss, Live 
0x88a9c000

tuner 67368 0 - Live 0x88a8a000
snd_seq_dummy 5380 0 - Live 0x88a87000
snd_seq_oss 36608 0 - Live 0x88a7d000
snd_seq_midi 11008 0 - Live 0x88a79000
snd_rawmidi 29696 1 snd_seq_midi, Live 0x88a7
snd_seq_midi_event 9856 2 snd_seq_oss,snd_seq_midi, Live 0x88a6c000
snd_seq 61856 7 
snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event, Live 
0x88a5b000

snd_timer 26632 3 snd_rtctimer,snd_pcm,snd_seq, Live 0x88a53000
snd_seq_device 10260 5 

Re: NOHZ: local_softirq_pending 08

2007-05-28 Thread Anant Nitya
On Tuesday 29 May 2007 02:34:22 Rafał Bilski wrote:
> Hi!
>
> A lot of "NOHZ: local_softirq_pending 08" messages (about 100) and
> then suddenly stoped to show. I have 2.6.21.1. I checked .2 and .3
> changelogs but I don't see anything about this message.
> What does it mean?
>
> Is "08" IRQ number?
>   8:  2XT-PIC-XTrtc
>
> Please CC me.
Does this patch [ http://lkml.org/lkml/2007/5/22/35 ] helps you fix it ?

Regards 
Ananitya


-- 
Out of many thousands, one may endeavor for perfection, and of
those who have achieved perfection, hardly one knows Me in truth.
-- Gita Sutra Of Mysticism
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] V4L: stk11xx, add a new webcam driver

2007-05-28 Thread Thierry Merle

Mauro Carvalho Chehab a écrit :

As Luca pointed, if we add conversion for one driver, we should add for
the rest.

Instead, it would be better if Jiri sends the decoding and the rescaling
stuff as a patch to v4l2-apps/lib, starting the API decoding library.
Once we have a library, we can ask the userspace developers to use it
for the formats not recognized by their userspace apps.

  

I think it would be better to evaluate existing solutions (eg. libpw).



Agreed. Volunteers?

  

Hi Mauro and Markus,
Just to summ up what I understood we need:

What do we need in userspace, only for v4l (dvb is not concerned):
- colorspace translations
- filters that be done in hardware if the selected hardware can, 
otherwise software plugin
- decompression algorithm like stk11xx or usbvision (the decompression 
algorithm is in kernelspace since it is of linear complexity but shall 
be moved to userspace)


Using pwlib will not mean that application developers will use pwlib to 
decode v4l driver outputs.
C bindings are much more popular than C++ bindings and do not prevent 
object oriented design.

Application developers implement their own codecs.
As an example, every application do deinterlacing internally or not...
Application developers will probably not use pwlib v4l extensions 
because they will prefer to write adapted codecs for their framework.


Much more important for me is to see the actual specification of the 
needed v4l extensions points, with advice/participation of 
application/codec developers.


Thierry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] pata_sis: FIFO whack

2007-05-28 Thread Jeff Garzik

Alan Cox wrote:

If you are using a SiS controller and the BIOS didn't set it up then the
FIFO may be left active when we try and set up the CD. Not convinced this
matters but I'd prefer to be safe

Signed-off-by: Alan Cox <[EMAIL PROTECTED]>

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.22-rc2-mm1/drivers/ata/pata_sis.c 
linux-2.6.22-rc2-mm1/drivers/ata/pata_sis.c
--- linux.vanilla-2.6.22-rc2-mm1/drivers/ata/pata_sis.c 2007-05-25 
17:39:06.0 +0100
+++ linux-2.6.22-rc2-mm1/drivers/ata/pata_sis.c 2007-05-25 18:22:21.0 
+0100
@@ -149,6 +149,9 @@
if (!pci_test_config_bits(pdev, _enable_bits[ap->port_no]))
return -ENOENT;
 
+	/* Clear the FIFO settings. We can't enable the FIFO until

+  we know we are poking at a disk */
+   pci_write_config_byte(pdev, 0x4B, 0);
return ata_std_prereset(ap, deadline);



Should I queue this into #upstream (2.6.23) or #upstream-fixes 
(2.6.22-rc) branch?


I lean towards #upstream since it is so late in the 2.6.22-rc cycle, 
because of your comment "Not convinced this matters".


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: [PATCH] ARM/ARM26: Enable arbitary speed tty ioctls and split input/output speed

2007-05-28 Thread Russell King
On Mon, May 28, 2007 at 02:56:32PM -0700, Andrew Morton wrote:
> On Mon, 28 May 2007 20:36:58 +0100 Russell King <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, May 23, 2007 at 05:27:39PM +0100, Alan Cox wrote:
> > > Add the ioctls and values needed for this to the ARM26/ARM32 ports. The
> > > actual code has been in the base kernel for a while and automatically
> > > turns on when a port sets the required defines.
> > 
> > Did you forget to provide a termios2 structure for ARM?  Hope you
> > remembered for the other arches:
> > 
> > drivers/char/tty_ioctl.c: In function `set_termios':
> > drivers/char/tty_ioctl.c:429: error: invalid application of `sizeof' to 
> > incomplete type `termios2'
> > drivers/char/tty_ioctl.c: In function `n_tty_ioctl':
> > drivers/char/tty_ioctl.c:732: error: invalid application of `sizeof' to 
> > incomplete type `termios2'
> > 
> > Will copy the i386 version into ARM's termbits.h
> > 
> 
> I think Alan's per-arch patch was dependent upon an earlier patch.  He
> fooled everyone by sending them out in random order, without sequence
> nnumbers and without telling anyone the dependencies.  And the add-termios2
> patch was a single megapatch whereas the enablement patches were a per-arch
> sprinkle.
> 
> 
> Here's tha arm bit of
> lots-of-architectures-enable-arbitary-speed-tty-support.patch: 

I hope that isn't because it's wrong.  It's "termios2" not "termios_2".

> Or you can just drop this patch and I'll resend it once
> lots-of-architectures-enable-arbitary-speed-tty-support.patch is merged up.

I think I'd prefer to commit my own version copied from x86, which at
least passes a build test.  Doing that now.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] ARM/ARM26: Enable arbitary speed tty ioctls and split input/output speed

2007-05-28 Thread Andrew Morton
On Mon, 28 May 2007 20:36:58 +0100 Russell King <[EMAIL PROTECTED]> wrote:

> On Wed, May 23, 2007 at 05:27:39PM +0100, Alan Cox wrote:
> > Add the ioctls and values needed for this to the ARM26/ARM32 ports. The
> > actual code has been in the base kernel for a while and automatically
> > turns on when a port sets the required defines.
> 
> Did you forget to provide a termios2 structure for ARM?  Hope you
> remembered for the other arches:
> 
> drivers/char/tty_ioctl.c: In function `set_termios':
> drivers/char/tty_ioctl.c:429: error: invalid application of `sizeof' to 
> incomplete type `termios2'
> drivers/char/tty_ioctl.c: In function `n_tty_ioctl':
> drivers/char/tty_ioctl.c:732: error: invalid application of `sizeof' to 
> incomplete type `termios2'
> 
> Will copy the i386 version into ARM's termbits.h
> 

I think Alan's per-arch patch was dependent upon an earlier patch.  He
fooled everyone by sending them out in random order, without sequence
nnumbers and without telling anyone the dependencies.  And the add-termios2
patch was a single megapatch whereas the enablement patches were a per-arch
sprinkle.


Here's tha arm bit of
lots-of-architectures-enable-arbitary-speed-tty-support.patch: 

diff -puN 
include/asm-arm/termbits.h~lots-of-architectures-enable-arbitary-speed-tty-support
 include/asm-arm/termbits.h
--- 
a/include/asm-arm/termbits.h~lots-of-architectures-enable-arbitary-speed-tty-support
+++ a/include/asm-arm/termbits.h
@@ -15,6 +15,17 @@ struct termios {
cc_t c_cc[NCCS];/* control characters */
 };
 
+struct termios_2 {
+   tcflag_t c_iflag;   /* input mode flags */
+   tcflag_t c_oflag;   /* output mode flags */
+   tcflag_t c_cflag;   /* control mode flags */
+   tcflag_t c_lflag;   /* local mode flags */
+   cc_t c_line;/* line discipline */
+   cc_t c_cc[NCCS];/* control characters */
+   speed_t c_ispeed;   /* input speed */
+   speed_t c_ospeed;   /* output speed */
+};
+
 struct ktermios {
tcflag_t c_iflag;   /* input mode flags */
tcflag_t c_oflag;   /* output mode flags */

Or you can just drop this patch and I'll resend it once
lots-of-architectures-enable-arbitary-speed-tty-support.patch is merged up.

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


Re: Linux v2.6.22-rc3

2007-05-28 Thread Bill Davidsen

Jeff Garzik wrote:


Several people have reported LITE-ON LTR-48246S detection failed
because SETXFER fails.  It seems the device raises IRQ too early after
SETXFER.  This is controller independent.  The same problem has been
reported for different controllers.

So, now we have pata_via where the controller raises IRQ before it's
ready after SETXFER and a device which does similar thing.  This patch
makes libata always execute SETXFER via polling.  As this only happens
during EH, performance impact is nil.  Setting ATA_TFLAG_POLLING is
also moved from issue hot path to ata_dev_set_xfermode() - the only
place where SETXFER can be issued.

Note that ATA_TFLAG_POLLING applies only to drivers which implement
SFF TF interface and use libata HSM.  More advanced controllers ignore
the flag.  This doesn't matter for this fix as SFF TF controllers are
the problematic ones.

Not only kills two birds with a single store, but will avoid having to 
re-solve the problem at sometime in the future. That's good software!


--
Bill Davidsen <[EMAIL PROTECTED]>
  "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: What causes iowait other than waiting for i/o?

2007-05-28 Thread Jesper Juhl

On 28/05/07, Bill Davidsen <[EMAIL PROTECTED]> wrote:

I recently noted that my system was spending a lot of time in i/o wait
when doing some tasks which I thought didn't involve i/o, as noted by
the lack of disk light activity most of the time. I thought of network,
certainly the NIC had no activity for this job. So I set up a little
loop to capture all disk i/o and network activity (including loopback).
That was no obvious help, and the program doesn't use pipes.

At this point I'm really curious, does someone have a good clue?

Note: I don't think this is a bug or performance issue, unless the
kernel is doing something and charging time to iowait instead of system
I don't see anything to fix, but I would like to understand.



Nothing /should/ cause time to be attributed to i/o wait other than
waiting for i/o. But the accounting isn't completely accurate. When
the kernel records what the has happen (governed by when the timer
interrupt triggers as far as I remember), many different processes may
have run and done may different things, but only what the last one did
is recorded. So if you are unlucky you may have the system doing all
sorts of activities, but only recording i/o wait if the last process
to run before the kernel looked was doing i/o wait...  The numbers are
not exactely accurate...


--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: b44: regression in 2.6.22 (resend)

2007-05-28 Thread Thomas Gleixner
On Mon, 2007-05-28 at 22:55 +0200, Maximilian Engelhardt wrote:
> > > I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution
> > > Timer, but the high ping problem is still there.
> >
> > Hmm, that's mysterious. Wild guess is that highres exposes the hidden
> > "feature" in a different way than rc2-mm1 does.
> 
> I think the bug in 2.6.21/22-rc3 is a different one that the one in 
> 2.6.22-rc2-mm1, but that's also only a wild guess :)
> 
> I'll explain this a bit:
> In 2.6.21/22-rc3 is the same b44 driver that has been in the stock kernels 
> for 
> some time. With this driver and High Resolution Timer turned on I get 
> problems using iperf. The problems are that the systems becomes really slow 
> and unresponsive.  Michael Buesch thought this could be an IRQ storm which 
> sounds logical to me. This bug did never happen to me before I startet the 
> iperf test.

Can you please apply

http://www.tglx.de/projects/hrtimers/2.6.22-rc3/patch-2.6.22-rc3-hrt1.patch

on top of rc3 and check, whether it has any effect on your problem.

> The other issue happens only with 2.6.22-rc2-mm1 which includes the b44 ssb 
> spilt. It's independed wether High Resolution Timer is turned on or off I 
> always get very varying and high ping times. The iperf-test doesn't show the 
> problems from 2.6.21/22-rc3.

Neither with nor without highres ?

tglx


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


What causes iowait other than waiting for i/o?

2007-05-28 Thread Bill Davidsen
I recently noted that my system was spending a lot of time in i/o wait 
when doing some tasks which I thought didn't involve i/o, as noted by 
the lack of disk light activity most of the time. I thought of network, 
certainly the NIC had no activity for this job. So I set up a little 
loop to capture all disk i/o and network activity (including loopback). 
That was no obvious help, and the program doesn't use pipes.


At this point I'm really curious, does someone have a good clue?

Note: I don't think this is a bug or performance issue, unless the 
kernel is doing something and charging time to iowait instead of system 
I don't see anything to fix, but I would like to understand.


--
bill davidsen <[EMAIL PROTECTED]>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

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


Re: stuff ready to be deleted?

2007-05-28 Thread Jan Engelhardt

On May 28 2007 16:15, Robert P. J. Day wrote:
>removing dead content from the tree:
>
>http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List
>
>currently, the list contains the items:
>
>* 4 Traffic policing

CONFIG_NET_SCHED? CONFIG_NET_ACT_POLICE? Neither seems
marked as deprecated/obsoleted in Kconfig.



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: [RFC][PATCH][EXPERIMENTAL] Make kernel threads nonfreezable by default

2007-05-28 Thread Nigel Cunningham
Hi.

On Mon, 2007-05-28 at 20:17 +0200, Rafael J. Wysocki wrote:
> On Monday, 28 May 2007 11:46, Nigel Cunningham wrote:
> > Hello!
> > 
> > In reply to your more recent message, I had looked but not tried, so
> > didn't feel in a position to reply yet.
> > 
> > On Sun, 2007-05-27 at 00:12 +0200, Rafael J. Wysocki wrote:
> > >  63 files changed, 78 insertions(+), 138 deletions(-)
> > 
> > Well, that looks good, for a start :)
> > 
> > > Index: linux-2.6.22-rc3/kernel/exit.c
> > > ===
> > > --- linux-2.6.22-rc3.orig/kernel/exit.c
> > > +++ linux-2.6.22-rc3/kernel/exit.c
> > > @@ -389,6 +389,11 @@ void daemonize(const char *name, ...)
> > >* they would be locked into memory.
> > >*/
> > >   exit_mm(current);
> > > + /*
> > > +  * We don't want to have TIF_FREEZE set if the system-wide hibernation
> > > +  * or suspend transision begins right now.
> > > +  */
> > > + current->flags |= PF_NOFREEZE;
> > 
> > s/transision/transition
> 
> Thanks, will fix.
> 
> > >   set_special_pids(1, 1);
> > >   proc_clear_tty(current);
> > > Index: linux-2.6.22-rc3/include/linux/freezer.h
> > > ===
> > > --- linux-2.6.22-rc3.orig/include/linux/freezer.h
> > > +++ linux-2.6.22-rc3/include/linux/freezer.h
> > > @@ -118,6 +118,14 @@ static inline int freezer_should_skip(st
> > >   return !!(p->flags & PF_FREEZER_SKIP);
> > >  }
> > >  
> > > +/*
> > > + * Tell the freezer that the current task should be frozen by it
> > > + */
> > > +static inline void set_freezable(void)
> > > +{
> > > + current->flags &= ~PF_NOFREEZE;
> > > +}
> > > +
> > 
> > Given the clearing of the flag above, should we just have a
> > set_unfreezeable here that's used above (and potentially elsewhere)...
> > (reads more)... or more generic set_[un]freezeable(task_struct *p)
> > routines that could also be used in copy_flags below?
> 
> Yes, I can introduce set_unfreezeable(), although that would be used in
> a couple of places only.
> 
> I don't think it's a good idea to have set_[un]freezeable(task_struct *p),
> since only current is allowed to set/unset its flags.

The copy_flags routine changes another process's flags - that's why I
was suggesting this.

> > >  #else
> > >  static inline int frozen(struct task_struct *p) { return 0; }
> > >  static inline int freezing(struct task_struct *p) { return 0; }
> > > @@ -134,6 +142,7 @@ static inline int try_to_freeze(void) { 
> > >  static inline void freezer_do_not_count(void) {}
> > >  static inline void freezer_count(void) {}
> > >  static inline int freezer_should_skip(struct task_struct *p) { return 0; 
> > > }
> > > +static inline void set_freezable_current(void) {}
> 
> Ah, this is a mistake (wrong name).
> 
> > >  #endif
> > >  
> > >  #endif /* LINUX_FREEZER_H */
> > > Index: linux-2.6.22-rc3/kernel/fork.c
> > > ===
> > > --- linux-2.6.22-rc3.orig/kernel/fork.c
> > > +++ linux-2.6.22-rc3/kernel/fork.c
> > > @@ -920,7 +920,7 @@ static inline void copy_flags(unsigned l
> > >  {
> > >   unsigned long new_flags = p->flags;
> > >  
> > > - new_flags &= ~(PF_SUPERPRIV | PF_NOFREEZE);
> > > + new_flags &= ~PF_SUPERPRIV;
> > >   new_flags |= PF_FORKNOEXEC;
> > >   if (!(clone_flags & CLONE_PTRACE))
> > >   p->ptrace = 0;
> > > Index: linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
> > > ===
> > > --- linux-2.6.22-rc3.orig/arch/i386/kernel/io_apic.c
> > > +++ linux-2.6.22-rc3/arch/i386/kernel/io_apic.c
> > > @@ -669,7 +669,6 @@ static int balanced_irq(void *unused)
> > >  
> > >   for ( ; ; ) {
> > >   time_remaining = schedule_timeout_interruptible(time_remaining);
> > > - try_to_freeze();
> > >   if (time_after(jiffies,
> > >   prev_balance_time+balanced_irq_interval)) {
> > >   preempt_disable();
> > 
> > I'm the one who is confused, aren't I? If I'm reading this right,
> > io_apic used to be frozen. After this patch, it will not be frozen. If
> > that's the intended behaviour, shouldn't this be two patches - one to
> > make kernel threads unfreezeable by default, and one to make threads
> > that were formerly freezeable unfreezeable?
> 
> Yes, I think you're right.  I tend to try to make too many changes in one
> shot. :-)
> 
> > 
> > [...]
> > 
> > > Index: linux-2.6.22-rc3/Documentation/power/swsusp.txt
> > > ===
> > > --- linux-2.6.22-rc3.orig/Documentation/power/swsusp.txt
> > > +++ linux-2.6.22-rc3/Documentation/power/swsusp.txt
> > > @@ -140,22 +140,6 @@ should be sent to the mailing list avail
> > >  website, and not to the Linux Kernel Mailing List. We are working
> > >  toward merging suspend2 into the mainline kernel.
> > >  
> > > -Q: A kernel thread must voluntarily freeze itself (call 'refrigerator').

Re: stuff ready to be deleted?

2007-05-28 Thread Jesper Juhl

On 28/05/07, John Anthony Kazos Jr. <[EMAIL PROTECTED]> wrote:

> >   i'm trying to keep track of kernel janitor projects that involve
> > removing dead content from the tree:
> >
> > http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List
> >
> > currently, the list contains the items:
> >
> > * 1 Legacy power management
> > * 2 PCMCIA IOCTL support
> > * 3 Traffic shaper
> > * 4 Traffic policing
> > * 5 Userspace queueing via NETLINK
> > * 6 ebt: ulog support
> > * 7 MOXA SmartIO support
> > * 8 Old I2O ioctls
> > * 9 Stallion drivers
> > * 10 SDL RISCom/8 support
> > * 11 Macintosh M68K support
> > * 12 Commodore A2232 serial support
> > * 13 CONFIG_FORCED_INLINING
> > * 14 kernel_thread()
> >
> > which of the above are legitimate candidates for removal?  which are
> > already underway in someone's local tree?  anything else that can
> > be added?  etc, etc.
> >
>
> Take a look at Documentation/feature-removal-schedule.txt
> Some of that stuff is already listed there along with who is in charge
> of removing it and when.

Let's not get in that catfight again. That file has been demonstrated to
be half too premature and half completely obsolete. He's asking for which
things should he start generating and sending patches and expect them to
not be ignored or angrily shot down. feature-removal-schedule.txt does not
provide this information, again as has been demonstrated.

Of course, it would be great if it were accurate and -did- provide that
information.



Well, at least that file does give him a clue as to who to talk to
about removal of some of the items on the list.  It may not be as
up-to-date as it ought to be, but it's still a source of
information/contact info.

--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: stuff ready to be deleted?

2007-05-28 Thread Jiri Slaby
Robert P. J. Day napsal(a):
>   i'm trying to keep track of kernel janitor projects that involve
> removing dead content from the tree:
> 
> http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List
> 
> currently, the list contains the items:
[...]
> * 7 MOXA SmartIO support

already scheduled with the MXSER name.

thanks,
-- 
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
 B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: stuff ready to be deleted?

2007-05-28 Thread John Anthony Kazos Jr.
> >   i'm trying to keep track of kernel janitor projects that involve
> > removing dead content from the tree:
> > 
> > http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List
> > 
> > currently, the list contains the items:
> > 
> > * 1 Legacy power management
> > * 2 PCMCIA IOCTL support
> > * 3 Traffic shaper
> > * 4 Traffic policing
> > * 5 Userspace queueing via NETLINK
> > * 6 ebt: ulog support
> > * 7 MOXA SmartIO support
> > * 8 Old I2O ioctls
> > * 9 Stallion drivers
> > * 10 SDL RISCom/8 support
> > * 11 Macintosh M68K support
> > * 12 Commodore A2232 serial support
> > * 13 CONFIG_FORCED_INLINING
> > * 14 kernel_thread()
> > 
> > which of the above are legitimate candidates for removal?  which are
> > already underway in someone's local tree?  anything else that can
> > be added?  etc, etc.
> > 
> 
> Take a look at Documentation/feature-removal-schedule.txt
> Some of that stuff is already listed there along with who is in charge
> of removing it and when.

Let's not get in that catfight again. That file has been demonstrated to 
be half too premature and half completely obsolete. He's asking for which 
things should he start generating and sending patches and expect them to 
not be ignored or angrily shot down. feature-removal-schedule.txt does not 
provide this information, again as has been demonstrated.

Of course, it would be great if it were accurate and -did- provide that 
information.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


"[IPV6]: Fix routing round-robin locking." breaks manual default route (bug 8349)

2007-05-28 Thread Simon Arlott

Initial state - address, no routes:
# ip -6 a
2: eth0:  mtu 1500 qlen 1000
   inet6 2001:4b10:1005:0:202:44ff:fe50:91af/64 scope global
  valid_lft forever preferred_lft forever
   inet6 fe80::202:44ff:fe50:91af/64 scope link
  valid_lft forever preferred_lft forever
# ip -6 r
fe80::/64 dev eth0  metric 256  expires 21332290sec mtu 1500 advmss 1440
ff00::/8 dev eth0  metric 256  expires 21332290sec mtu 1500 advmss 1440
unreachable default dev lo  proto none  metric -1  error -101
# ping6 -c 1 2001:4b10:1005:0:205:b4ff:fe12:530
connect: Network is unreachable

Adding a 2000::/3 route works:
# ip -6 r a 2000::/3 via fe80::230:18ff:feb0:25c2 dev eth0
# ping6 -c 1 2001:4b10:1005:0:205:b4ff:fe12:530
64 bytes from 2001:4b10:1005:0:205:b4ff:fe12:530: icmp_seq=1 ttl=64 time=0.921 
ms
# ip -6 r d 2000::/3 via fe80::230:18ff:feb0:25c2 dev eth0

Adding a ::/0 route doesn't work:
# ip -6 r a ::/0 via fe80::230:18ff:feb0:25c2 dev eth0
# ping6 -c 1 2001:4b10:1005:0:205:b4ff:fe12:530
connect: Network is unreachable

A route assigned by addrconf works.


Reverting this patch from 2.6.22-rc3 fixes it:
commit f11e6659ce9058928d73ff440f9b40a818d628ab
Author: David S. Miller <[EMAIL PROTECTED]>
Date:   Sat Mar 24 20:36:25 2007 -0700
[IPV6]: Fix routing round-robin locking.

This patch is was added to 2.6.20.5, breaking -stable too.


With RT6_DEBUG 3 in route.c (plus some additional debug statements):

Manual default route:
[  535.981000] fib6_add_rt2node
[  535.981000] fib6_add_rt2node fn->fn_flags = 0007 (RTN_TL_ROOT=0001)
[  535.981000] fib6_add_rt2node fn->leaf = b0697be0 (ip6_null_entry = b0697be0)
[  535.981000] fib6_add_rt2node rt->rt6i_flags = 0003 (RTF_DEFAULT = 
0001, RTF_ADDRCONF = 0004)
[  535.981000] fib6_add_rt2node goto out...
[  535.981000] fib6_add_rt2node out:

Ping6:
[  570.903000] rt6_select(fn->leaf=b1b63140, oif=0)
[  570.903000] find_match rt->rt6i_gateway =    
[  570.903000] find_match m = 10, *mpri = -1
[  570.904000] rt6_select() => b0697be0
[  570.904000] rt6_select(fn->leaf=b1b63140, oif=0)
[  570.904000] find_match rt->rt6i_gateway =    
[  570.904000] find_match m = 10, *mpri = -1
[  570.904000] rt6_select() => b0697be0


Addrconf default route:
[  624.846000] rt6_select(fn->leaf=b1b63300, oif=2)
[  624.846000] find_match rt->rt6i_gateway = 02ff   0100
[  624.846000] find_match m = 10, *mpri = -1
[  624.846000] rt6_select() => b1b63300
[  624.846000] rt6_select(fn->leaf=b1b63300, oif=2)
[  624.846000] find_match rt->rt6i_gateway = 02ff   0100
[  624.846000] find_match m = 10, *mpri = -1
[  624.846000] rt6_select() => b1b63300
[  624.846000] fib6_add_rt2node
[  624.846000] fib6_add_rt2node fn->fn_flags = 0007 (RTN_TL_ROOT=0001)
[  624.846000] fib6_add_rt2node fn->leaf = b0697be0 (ip6_null_entry = b0697be0)
[  624.846000] fib6_add_rt2node rt->rt6i_flags = 00450003 (RTF_DEFAULT = 
0001, RTF_ADDRCONF = 0004)
[  624.846000] fib6_add_rt2node out:

Ping6:
[  689.245000] rt6_select(fn->leaf=b1b63140, oif=0)
[  689.245000] find_match rt->rt6i_gateway = 104b0120 0510 ffb40502 300512fe
[  689.245000] find_match m = 10, *mpri = -1
[  689.245000] rt6_select() => b1b63140
[  689.245000] rt6_select(fn->leaf=b1b63140, oif=0)
[  689.245000] find_match rt->rt6i_gateway = 104b0120 0510 ffb40502 300512fe
[  689.245000] find_match m = 10, *mpri = -1
[  689.245000] rt6_select() => b1b63140
[  689.248000] rt6_select(fn->leaf=b1b63140, oif=0)
[  689.248000] find_match rt->rt6i_gateway = 104b0120 0510 ffb40502 300512fe
[  689.248000] find_match m = 10, *mpri = -1
[  689.248000] rt6_select() => b1b63140
[  689.248000] rt6_select(fn->leaf=b1b63140, oif=0)
[  689.248000] find_match rt->rt6i_gateway = 104b0120 0510 ffb40502 300512fe
[  689.248000] find_match m = 10, *mpri = -1
[  689.248000] rt6_select() => b1b63140
[  689.248000] rt6_select(fn->leaf=b1b63ae0, oif=2)
[  689.248000] find_match rt->rt6i_gateway =    
[  689.248000] find_match m = 9, *mpri = -1
[  689.248000] rt6_select() => b1b63ae0
[  689.702000] rt6_select(fn->leaf=b1b63ae0, oif=2)
[  689.702000] find_match rt->rt6i_gateway =    
[  689.702000] find_match m = 9, *mpri = -1
[  689.702000] rt6_select() => b1b63ae0


Manual 2000::/3 route:
[  765.424000] fib6_add_rt2node
[  765.424000] fib6_add_rt2node fn->fn_flags =  (RTN_TL_ROOT=0001)
[  765.424000] fib6_add_rt2node fn->leaf =  (ip6_null_entry = b0697be0)
[  765.424000] fib6_add_rt2node rt->rt6i_flags = 0003 (RTF_DEFAULT = 
0001, RTF_ADDRCONF = 0004)
[  765.424000] fib6_add_rt2node out:
[  765.424000] fib6_add_rt2node fn->fn_flags |= RTN_RTINFO;

Ping6:
[  779.705000] rt6_select(fn->leaf=b1b63060, oif=0)
[  779.705000] find_match rt->rt6i_gateway = 80fe  ff183002 c225b0fe
[  779.705000] 

Re: [patch 2.6.20-rc3 1/3] rtc-cmos driver

2007-05-28 Thread David Brownell
On Monday 28 May 2007, Matthew Garrett wrote:
> On Fri, Jan 05, 2007 at 10:01:57AM -0800, David Brownell wrote:
> > This is an "RTC framework" driver for the "CMOS" RTCs which are standard
> > on PCs and some other platforms.  That's MC146818 compatible silicon.
> > ...
> > +static int cmos_read_alarm(struct device *dev, struct rtc_wkalrm *t)
> 
> This is awkward. At the very least, year will be set to -1. This then 
> gets passed through to rtc_tm_to_time, which results in reading 
> wakealarm providing very odd feedback. I guess the "right" fix is for 
> rtc_tm_to_time to use the current values for anything that's -1?

Well ... legacy APIs allow "-1" there; /proc/driver/rtc certainly
interprets wildcards consistently too.  That is, historically it's
not been legit to call rtc_tm_to_time(>time).

A counter-argument could be made that rtc_read_alarm() should get
rid of wildcards.  It's got the right RTC in hand; rtc_tm_to_time()
doesn't.  Other RTCs can have this same type of "wildcard" issue.

Me, I'd prefer to make the API treat alarms as purely oneshot.
That whole "wildcard" model is, as you noted, awkward ... even
though it's got hardware support in cases like MC146818 and clones,
it's not very portable.  But I don't want to push that issue either
way just now.



> > +   rtc_control = CMOS_READ(RTC_CONTROL);
> > +   rtc_control &= ~(RTC_PIE | RTC_AIE | RTC_UIE);
> 
> Do you really want to clobber RTC_AIE on probe? If an alarm has been set 
> by the BIOS, it seems a little unfair to disable it on boot.

I was wondering about that in the context of a different RTC, which
happens to run on BIOS-less hardware.  Which, curiously, may be the
opposite of BIOS-impaired hardware ... :)

In general, I suspect the alarm should stay active ... unless its
time has already passed.  That was the original intent of that
tweak, but of course PCs don't actually *have* oneshot alarms, so
there's no way to tell if a given alarm is in the past.  Leading to
the conclusion that AIE should probably stay enabled.

- Dave

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


Re: [PATCH] RTC: Use fallback IRQ if PNP tables don't provide one

2007-05-28 Thread David Brownell
On Monday 28 May 2007, Matthew Garrett wrote:
> From: Matthew Garrett <[EMAIL PROTECTED]>
> 
> Intel Macs (and possibly other machines) provide a PNP entry for the 
> RTC, but provide no IRQ. As a result the rtc-cmos driver doesn't allow 
> wakeup alarms. If the RTC is located at the legacy ioport range, assume 
> that it's on IRQ 8 unless the tables say otherwise.
> 
> Signed-off-by: Matthew Garrett <[EMAIL PROTECTED]>

Signed-off-by: David Brownell <[EMAIL PROTECTED]>

> 
> ---
> 
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index 6085261..e24ea82 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -641,9 +641,16 @@ cmos_pnp_probe(struct pnp_dev *pnp, const struct 
> pnp_device_id *id)
>* drivers can't provide shutdown() methods to disable IRQs.
>* Or better yet, fix PNP to allow those methods...
>*/
> - return cmos_do_probe(>dev,
> - >res.port_resource[0],
> - pnp->res.irq_resource[0].start);
> + if (pnp_port_start(pnp,0) == 0x70 && !pnp_irq_valid(pnp,0))
> + /* Some machines contain a PNP entry for the RTC, but
> +  * don't define the IRQ. It should always be safe to
> +  * hardcode it in these cases
> +  */
> + return cmos_do_probe(>dev, >res.port_resource[0], 8);
> + else
> + return cmos_do_probe(>dev,
> +  >res.port_resource[0],
> +  pnp->res.irq_resource[0].start);
>  }
>  
>  static void __exit cmos_pnp_remove(struct pnp_dev *pnp)
> 
> -- 
> Matthew Garrett | [EMAIL PROTECTED]
> 


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


Re: RTC_DRV_CMOS can break userspace interface

2007-05-28 Thread David Brownell
On Monday 28 May 2007, frank paulsen wrote:
> David Brownell <[EMAIL PROTECTED]> writes:
> 
> > On Sunday 27 May 2007, Matthew Garrett wrote:
> >> f5f72b46c349fefcfd4421b2213c6ffb324c5e56 appears to break the userspace 
> >> interface to the CMOS alarm. This could previously be accessed via 
> >> /proc/acpi/alarm ...
> >
> > I was a bit surprised the ACPI team didn't have more comments on
> > that issue, myself.  Thing is, all of /proc/acpi/* is deprecated
> > (scheduled for removal in barely over one month!) and nobody had
> > found any actual users of that "alarm" file when they searched for
> > them a while ago.  I suppose the conclusion then was that there
> > are no applications using it.
> 
> sorry for breaking the CC:, but i am currently not subscribed to lkml.

I restored both lkml and linux-acpi to the CC list.  :)


> please have a look at at http://www.mythtv.org/wiki/index.php/ACPI_Wakeup
> 
> i think there is quite a number of users, but most of them won't ever
> look into LKML :)

That seems to be true.  And those particular users should learn the
portable /sys/class/rtc/rtc0/wakealarm syntax ... e.g. using numeric
seconds-since-epoch ("date '+%s'") instead of strings the kernel needs
to parse.  That way, they can start converting usage sooner.

Someone with edit privs on that wiki should update those docs, and
tell folk to switch to that interface since the other one is going...


I'm suspecting that there should be a CONFIG_ACPI_SLEEP_PROC_ALARM
not the current internal (acpi/sleep/proc.c) HAVE_ACPI_LEGACY_ALARM,
and some way should be found that the two interfaces can coexist for
a while.  But I can't quite make sense of the strategy for getting
rid of the /proc/acpi/* files ... for example, I see one entry
saying the ACPI procfs as a whole vanishes July 2007, and the next
one says that /proc/acpi/button stays until August 2007.

- Dave
 


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


Re: [patch] Add the device IDs for AMD/ATI SB700

2007-05-28 Thread Bartlomiej Zolnierkiewicz

Hi,

Sorry for the late reply and thanks to Jeff for stepping in. :)

Since Jeff covered both status of your patches and administrative issues
I would only like to add one small hint for people adding support for
multi-function PCI chipsets (with multiple PCI device IDs):

It makes sense to put addition of _all_ new PCI IDs into the first patch
of the series and send it to PCI Maintainer (Hi Greg).  This should make
all other patches from the series independent of each other (in the usual
case I'm not talking about all crazy scenarios here).  After the patch
with PCI IDs gets applied upstream you may now send all other patches to
the respective maintainers without worrying about inter-patch dependencies
and without maintainers worrying about your patches not applying cleanly.

IIRC Intely guys are using this process when adding support for their new
chipsets and it works smoothly.

[ Yep, this process is the exception from the general "patch shouldn't add
  unused code" rule but the amount of _temporarily_ unused stuff is _minimal_
  and doing it this way saves a lot of time for all parties involved. ]

PS Greg/Jeff If I'm totally wrong on this please correct me...

Thanks,
Bart

On Friday 25 May 2007, Jeff Garzik wrote:
> Henry Su wrote:
> > I check the latest kernel source code with git, and find out that the
> > SMBus patch has not been applied yet,  
> 
> Correct.  When you don't see a patch in the upstream git tree 
> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 
> then the next step is consult the MAINTAINERS file, and determine to 
> whom you should send a follow-up patch, or simply contact about the 
> status of a patch you just sent.  In this case, SMBus is in drivers/i2c 
> sub-directory, which leads us to find in MAINTAINERS,
> 
> I2C SUBSYSTEM
> P:  Jean Delvare
> M:  [EMAIL PROTECTED]
> L:  [EMAIL PROTECTED]
> T:  quilt http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/
> S:  Maintained
> 
> That tells us the maintainer of the subsystem, and also ("T:") an 
> external reference (a tree) to where the maintainer posts accepted 
> patches, prior to sending them upstream.
> 
> So for SMBus, you should make sure your SMBus changes appear in Jean 
> Delvare's quilt tree.  If they do not, create a new patch and send it to 
> Jean and CC [EMAIL PROTECTED] and [EMAIL PROTECTED]
> 
> 
> > and the patch for IDE  has not been  applied completely.one more device
> > id should be added to pata_atiixp.c, 
> > l list the patch as following, or you can fetch it from the attached file,
> > could you please apply this for me?  
> 
> Actually it has been applied -- the part that I maintain (drivers/ata/*) 
> is currently stored in a secondary tree, as described above.  Your patch 
> has been stored on the 'upstream' branch of 
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
> 
> Currently, the upstream Linux kernel is only accepting bug fixes.  I 
> merge ATA bug fixes (and sometimes simple PCI ID additions) into 
> libata-dev.git#upstream-fixes during this phase of development.  These 
> changes are sent upstream in 24-48 hours, to ensure that they will be 
> included in the next release (kernel 2.6.22).
> 
> All other ATA changes are merged into libata-dev.git#upstream.  When 
> Linus releases kernel 2.6.22, the "merge window" opens, allowing 
> non-bug-fix changes to be submitted upstream.  When the merge window 
> opens, I submit everything in libata-dev.git#upstream to Linus and 
> Andrew Morton for inclusion in the official upstream kernel tree.
> 
> That is our development process in a nutshell.
> 
> The kernel development process is conducted entirely via email, so you 
> see why it is so important to learn how to email patches in the proper 
> format.
> 
>   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: [PATCH 3/3] Make ide dma blacklist handling a bit saner.

2007-05-28 Thread Bartlomiej Zolnierkiewicz

Hi,

On Tuesday 22 May 2007, Junio C Hamano wrote:
> Earlier, the matching of (model,rev) in ide-dma black/white list
> handling was to consider "ALL" in the table to match any
> revision.  This changes the wildcard to NULL.  This way, the
> DMA_BLACK_LIST macro used in the previous patch does not have to
> use a slightly funky compile time constant expression to convert
> NULL to "ALL".
> 
> Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>

The change itself looks good but IMO it is worth doing it before patch #2/3
(it would also make it possible for me to merge this patch immediately).

When it comes to patch #2 - Alan's comment may be a bit harsh but he seems
to be right - there should be a common library-like file (ata-blacklist.c
or ata-quirks.c or whatever name you like) containing ata_device_blacklist[].

This would require slight modification of ide_in_drive_list() to teach
it about ATA_HORKAGE_DMA but as I see from this patch this shouldn't be
a problem for you. ;)  Please also note that  is used by both
IDE and libata so it should be a good place to put struct ata_blacklist_entry
and ATA_HORKAGE_* macros.

Care to respin both patches?

>  * I do not really know what I am doing in the mips area, but
>that architecture specific table seems to be used by the same
>ide_in_drive_list() function, so the entries are matched to
>the updated code.

Yep, thanks for not breaking AMD Alchemy IDE suppport.

It looks like au1xxx_ide.h should really be in drivers/ide/mips because
it is only included from drivers/ide/mips/au1xxx_ide.c - could somebody
verify this and send me a patch?

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/


NOHZ: local_softirq_pending 08

2007-05-28 Thread Rafał Bilski
Hi!

A lot of "NOHZ: local_softirq_pending 08" messages (about 100) and 
then suddenly stoped to show. I have 2.6.21.1. I checked .2 and .3 
changelogs but I don't see anything about this message.
What does it mean?

Is "08" IRQ number?
  8:  2XT-PIC-XTrtc

Please CC me.

Thank You
Rafał



--
Ile masz w domu niepotrzebnych rzeczy?
Wymien sie z sasiadami >> http://link.interia.pl/f1a93


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


Re: software suspend doesn't work with 2.6.22-rc3

2007-05-28 Thread Maximilian Engelhardt
On Monday 28 May 2007, Rafael J. Wysocki wrote:
> On Monday, 28 May 2007 09:59, Rafael J. Wysocki wrote:
> > On Monday, 28 May 2007 02:21, Maximilian Engelhardt wrote:
> > > On Sunday 27 May 2007, Rafael J. Wysocki wrote:
> > > > On Sunday, 27 May 2007 22:41, Maximilian Engelhardt wrote:
> > > > > On Sunday 27 May 2007, Rafael J. Wysocki wrote:
> > > > > > On Sunday, 27 May 2007 18:01, Maximilian Engelhardt wrote:
> > > > > > > On Saturday 26 May 2007, Nigel Cunningham wrote:
> > > > > > > > Hi.
> > > > > > > >
> > > > > > > > On Sat, 2007-05-26 at 14:49 +0200, Maximilian Engelhardt 
wrote:
> > > > > > > > > On Saturday 26 May 2007, Nigel Cunningham wrote:
> > > > > > > > > > Hi.
> > > > > > > > > >
> > > > > > > > > > On Sat, 2007-05-26 at 11:28 +0200, Maximilian Engelhardt 
wrote:
> > > > > > > > > > > Hello,
> > > > > > > > > > >
> > > > > > > > > > > When I try software suspend on my laptop it always
> > > > > > > > > > > returns to my running system after some time.
> > > > > > > > > > > This is what's logged by the kernel:
> > > > > > > > > > >
> > > > > > > > > > > swsusp: Basic memory bitmaps created
> > > > > > > > > > > Stopping tasks ...
> > > > > > > > > > > Stopping kernel threads timed out after 20 seconds (1
> > > > > > > > > > > tasks refusing to freeze):
> > > > > > > > > > >  cryptd
> > > > > > > > > > > Restarting tasks ... done.
> > > > > > > > > > > swsusp: Basic memory bitmaps freed
> > > > > > > > > > >
> > > > > > > > > > > I have no idea what's the problem, but if you tell me
> > > > > > > > > > > what I should do I can create debugging information
> > > > > > > > > > > and/or test patches.
> > > > > > > > > >
> > > > > > > > > > Could you try this patch, please? It should help.
> > > > > > > > > >
> > > > > > > > > > Herbert, is this right? If cryptd is going to be used for
> > > > > > > > > > block devs, the task should probably be PF_NOFREEZE (or
> > > > > > > > > > whatever it is today) instead.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > Nigel
> > > > > > > > > >
> > > > > > > > > >  crypto/cryptd.c |1 +
> > > > > > > > > >  include/linux/freezer.h |3 +++
> > > > > > > > > >  kernel/power/process.c  |2 +-
> > > > > > > > > >  3 files changed, 5 insertions(+), 1 deletion(-)
> > > > > > > > > > diff -ruNp 991-fix-cryptd.patch-old/crypto/cryptd.c
> > > > > > > > > > 991-fix-cryptd.patch-new/crypto/cryptd.c ---
> > > > > > > > > > 991-fix-cryptd.patch-old/crypto/cryptd.c2007-05-19
> > > > > > > > > > 18:16:47.0 +1000 +++
> > > > > > > > > > 991-fix-cryptd.patch-new/crypto/cryptd.c2007-05-26
> > > > > > > > > > 19:45:42.0 +1000 @@ -341,6 +341,7 @@ static int
> > > > > > > > > > cryptd_thread(void *data)
> > > > > > > > > >
> > > > > > > > > > mutex_unlock(>mutex);
> > > > > > > > > >
> > > > > > > > > > +   try_to_freeze();
> > > > > > > > > > schedule();
> > > > > > > > > > } while (!stop);
> > > > > > > > >
> > > > > > > > > I tried your patch, but when I apply it my kernel doesn't
> > > > > > > > > compile any more. I get these warnings/errors:
> > > > > > > > >
> > > > > > > > > [...]
> > > > > > > > >   CC  crypto/cryptd.o
> > > > > > > > > crypto/cryptd.c: In function ‘cryptd_thread’:
> > > > > > > > > crypto/cryptd.c:344: warning: implicit declaration of
> > > > > > > > > function ‘try_to_freeze’ [...]
> > > > > > > > >   LD  init/built-in.o
> > > > > > > > >   LD  .tmp_vmlinux1
> > > > > > > > > crypto/built-in.o: In function `cryptd_thread':
> > > > > > > > > cryptd.c:(.text+0xd7f5): undefined reference to
> > > > > > > > > `try_to_freeze' make: *** [.tmp_vmlinux1] Error 1
> > > > > > > >
> > > > > > > > Ah. You'll need to add #include  near that
> > > > > > > > start of crypto/cryptd.c. Sorry for forgetting that.
> > > > > > > >
> > > > > > > > Nigel
> > > > > > >
> > > > > > > I added the include line and now I could compile the kernel,
> > > > > > > but suspending still doesn't work.
> > > > > > >
> > > > > > > swsusp: Basic memory bitmaps created
> > > > > > > Stopping tasks ...
> > > > > > > Stopping kernel threads timed out after 20 seconds (1 tasks
> > > > > > > refusing to freeze):
> > > > > > > cryptd
> > > > > > > Restarting tasks ... done.
> > > > > > > swsusp: Basic memory bitmaps freed
> > > > > >
> > > > > > OK, this means that cryptd doesn't execute the try_to_freeze()
> > > > > > for some reason.
> > > > > >
> > > > > > Please apply the appended patch on top of 2.6.22-rc3 and see if
> > > > > > that helps.
> > > > > >
> > > > > > Greetings,
> > > > > > Rafael
> > > > > >
> > > > > > ---
> > > > > >  crypto/cryptd.c |1 +
> > > > > >  1 file changed, 1 insertion(+)
> > > > > >
> > > > > > Index: linux-2.6.22-rc3/crypto/cryptd.c
> > > > > > =
> > > > > >== --- linux-2.6.22-rc3.orig/crypto/cryptd.c
> > > > > > +++ linux-2.6.22-rc3/crypto/cryptd.c
> > > > > > 

Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend

2007-05-28 Thread Pavel Machek
Hi!

> >In fact, I'd like drivers to use notifiers to actually 
> >load the firmware into
> >memory before hibernation/suspend.  Namely, if there's 
> >PM_PRE_FREEZE, the
> >driver calls request_firmware() from within the 
> >notifier and saves the firmware
> >in memory for future use, if need be.  Later, when 
> >PM_POST_THAW comes, the
> >memory holding the firmware is released.
> >
> >Unfortunately there are drivers that call 
> >request_firmware() directly from
> >.resume() which blocks until timeout expires and fails 
> >anyway.  I just wanted
> >this to fail immediately, without waiting.
> 
> Stupid question time. Wouldn't it just be easier to have
> request_firmware() keep a copy of the firmware once it's 
> been loaded?
> We're not talking about a lot of memory that would be 
> wasted, and that
> way no drivers have to be changed.

Actually, I like this idea. Firmware problems magically disappear.

...unless someone uses x86 emulator in userland to POST graphics card.
You can't 'cache' that. But that's separate problem.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] reiser4: remove lzo compression security hole

2007-05-28 Thread Edward Shishkin

Richard Purdie wrote:


Switch reiser4 to use lzo1x_decompress_safe instead of lzo1x_decompress
as otherwise it presents a security hole (lzo1x_decompress doesn't
perform bounds checking on the decompressed data).

Signed-off-by: Richard Purdie <[EMAIL PROTECTED]>

---
fs/reiser4/plugin/compress/compress.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.21/fs/reiser4/plugin/compress/compress.c
===
--- linux-2.6.21.orig/fs/reiser4/plugin/compress/compress.c 2007-05-16 
20:47:45.0 +0100
+++ linux-2.6.21/fs/reiser4/plugin/compress/compress.c  2007-05-24 
23:43:28.0 +0100
@@ -319,7 +319,7 @@ lzo1_decompress(coa_t coa, __u8 * src_fi
assert("edward-851", coa == NULL);
assert("edward-852", src_len != 0);

-   result = lzo1x_decompress(src_first, src_len, dst_first, , NULL);
+   result = lzo1x_decompress_safe(src_first, src_len, dst_first, , 
NULL);
if (result != LZO_E_OK)
warning("edward-853", "lzo1x_1_decompress failed\n");
*dst_len = dstlen;

 



Signed-off-by: Edward Shishkin <[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: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend

2007-05-28 Thread Pavel Machek
Hi!

> > > I can't speak for the second example, but there's a good reason the
> > > first example works this way.  It's not a matter of races; the problem
> > > is that the kernel thread's job is to selectively suspend and resume
> > > devices.  We don't want it doing this while a system sleep is in 
> > > progress; it would (and in fact has, before the thread was made 
> > > freezable) cause the sleep transition to abort.
> > 
> > How does this work on PPC or APM systems?
> 
> For hibernation it behaves the same as on other types of systems.
> 
> For STR it generally works okay.  There was one report of suspends
> aborting, and it looked like this was caused by selective resumes
> originating from userspace.  This seemed to be unrelated to the kernel
> threads; apparently some program was running while the STR was in
> progress, and causing the problem.  For example, the lsusb program will
> do a selective resume on every USB device as it scans through them all.
> However that's just a guess, we haven't fully resolved that bug report.
> 
> The theoretical answer is that it behaves the way we want.  The kernel 
> thread does selective resumes in response to device requests.  If such 
> a request comes in while the system is asleep it will awaken the 
> system; so it's only logical that a request coming in while the system 
> is in the process of going to sleep should abort the suspend.

I'd say that it shows ppc being broken. User wanted to suspend the
system, and now unrelated task did lsusb... and system will not sleep.

AFAICT it is DoS issue -- if one of your users keeps doing lsusb, root
will not be able to suspend the system.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Fix potential memory leak in tipc_named_node_up()

2007-05-28 Thread Jesper Juhl
There seems to be a memory leak in net/tipc/name_distr.c::tipc_named_node_up()

The function, with comments, is this :

void tipc_named_node_up(unsigned long node)
{
struct publication *publ;
struct distr_item *item = NULL;
struct sk_buff *buf = NULL;
u32 left = 0;
u32 rest;
u32 max_item_buf;

read_lock_bh(_nametbl_lock);
max_item_buf = TIPC_MAX_USER_MSG_SIZE / ITEM_SIZE;
max_item_buf *= ITEM_SIZE;
rest = publ_cnt * ITEM_SIZE;

list_for_each_entry(publ, _root, local_list) {
-> If we stop processing here after doing 1, 2 & 3 below we end up at (4) 
(below).
if (!buf) {
left = (rest <= max_item_buf) ? rest : max_item_buf;
rest -= left;
buf = named_prepare_buf(PUBLICATION, left, node);
-> (1) here we allocate memory and store a pointer to it in 'buf'.

if (!buf) {
-> (2) This test needs to fail, meaning we did allocate some memory.
warn("Bulk publication distribution failure\n");
goto exit;
}
item = (struct distr_item *)msg_data(buf_msg(buf));
}
publ_to_item(item, publ);
item++;
left -= ITEM_SIZE;
if (!left) {
-> (3) If this test fails we loop and do nothing to 'buf'.
msg_set_link_selector(buf_msg(buf), node);
dbg("tipc_named_node_up: sending publish msg to "
"<%u.%u.%u>\n", tipc_zone(node),
tipc_cluster(node), tipc_node(node));
tipc_link_send(buf, node, node);
buf = NULL;
}
}
exit:
read_unlock_bh(_nametbl_lock);
-> (4) here we return without freeing 'buf' - memory leak.
}

Luckily this is easy to fix, since we can only leave the function with 'buf'
either set to NULL or (in the leak case) set to a valid address, and since 
kfree() handles being passed NULL gracefully we can simply kfree(buf) just 
before we leave the function.

The patch below frees 'buf' before leaving the function, thus avoiding the 
potential leak.



Fix a potential memory leak in tipc_named_node_up()

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

 net/tipc/name_distr.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/net/tipc/name_distr.c b/net/tipc/name_distr.c
index 39fd161..228ccfe 100644
--- a/net/tipc/name_distr.c
+++ b/net/tipc/name_distr.c
@@ -204,6 +204,7 @@ void tipc_named_node_up(unsigned long node)
}
 exit:
read_unlock_bh(_nametbl_lock);
+   kfree(buf);
 }
 
 /**



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] enhancing the kernel's graphics subsystem

2007-05-28 Thread Jon Smirl

On 5/28/07, Pavel Machek <[EMAIL PROTECTED]> wrote:

Hi!

> >> These are not isolated problems. Linux needs a
> >properly designed
> >> graphics subsystem. One way to achieve that is to
> >design it all on
> >> paper first so that we can try and locate the
> >interactions between
> >> modules. For example the current mode setting design
> >is definitely
> >> broken for multi-seat support, that's because you
> >didn't take that
> >> feature into account when writing the code.
> >
> >No it isn't the code Jesse posted can handle multi-seat
> >fine in the
> >areas that it makes sense as we've pointed out to you
> >you cannot just
>
> The code doesn't create one device per CRTC. Missing
> that feature
> means that we need a persistent root priv app around
> that owns the
> single device and then listens for messages from each
> seat asking it
> to do things. That root priv app is not necessary, it is
> a security
> risk and it should be eliminated.

Fine, submit a patch. But don't block other people patches just
because they do not address your favourite problem.


I have already implemented this once and submitted a patch.

Search in the paper for this paragraph:
http://jonsmirl.googlepages.com/graphics.html
DRM also implements the concept of a master user with more
capabilities than normal users. These extra capabilities allow the
graphics device to be initialized and the consumption of GPU resources
to be controlled. The current X server, which runs as root, functions
as the DRM master. There is actually no real requirement that the DRM
master be run as root, and there is a preliminary patch that removes
this requirement.

That paragraphs contains a link to the code that used to be hosted at
freedesktop.org. Maybe they can still find it.

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


Re: b44: regression in 2.6.22 (resend)

2007-05-28 Thread Maximilian Engelhardt
On Monday 28 May 2007, Thomas Gleixner wrote:
> On Mon, 2007-05-28 at 19:44 +0200, Maximilian Engelhardt wrote:
> > > Can you please keep CONFIG_HIGH_RES_TIMERS and CONFIG_NOHZ and try the
> > > following combinations on the kernel command line:
> > >
> > > 1) highres=off nohz=off (should be the same as your working config)
> > > 2) highres=off
> > > 3) nohz=off
> >
> > I tested this with my 2.6.22-rc3 kernel, here are the results:
> >
> > without any special boot parameters: problem does appear
> > highres=off nohz=off: problem does not appear
> > highres=off: problem does not appear
> > nohz=off: problem does appear
>
> Is there any other strange behavior of the high res enabled kernel than
> the b44 problem ?

I didn't notice anything.

>
> > I additionally built my 2.6.22-rc2-mm1 kernel without High Resolution
> > Timer, but the high ping problem is still there.
>
> Hmm, that's mysterious. Wild guess is that highres exposes the hidden
> "feature" in a different way than rc2-mm1 does.

I think the bug in 2.6.21/22-rc3 is a different one that the one in 
2.6.22-rc2-mm1, but that's also only a wild guess :)

I'll explain this a bit:
In 2.6.21/22-rc3 is the same b44 driver that has been in the stock kernels for 
some time. With this driver and High Resolution Timer turned on I get 
problems using iperf. The problems are that the systems becomes really slow 
and unresponsive.  Michael Buesch thought this could be an IRQ storm which 
sounds logical to me. This bug did never happen to me before I startet the 
iperf test.

The other issue happens only with 2.6.22-rc2-mm1 which includes the b44 ssb 
spilt. It's independed wether High Resolution Timer is turned on or off I 
always get very varying and high ping times. The iperf-test doesn't show the 
problems from 2.6.21/22-rc3.

Maxi


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


Re: stuff ready to be deleted?

2007-05-28 Thread Robert P. J. Day
On Mon, 28 May 2007, Oliver Pinter wrote:

> + open sound system

yeah, that one's so obvious, i don't even list it anymore. :-)  i'm
assuming adrian's going to deal with that when the time comes.

rday
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] LZO de/compression support - take 6

2007-05-28 Thread Daniel Hazelton
On Monday 28 May 2007 16:18:40 Daniel Hazelton wrote:
> On Monday 28 May 2007 13:11:15 Adrian Bunk wrote:
> > On Mon, May 28, 2007 at 09:33:32PM +0530, Nitin Gupta wrote:
> > > On 5/28/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > >...
> > >
> > >> - then ensure that it works correctly on all architectures and
> > >
> > > Already tested on x86, amd64, ppc (by Bret). I do not have machines
> > > from other archs available. Bret tested 'take 3' version but no
> > > changes were introduced in further revisions that could affect
> > > correctness - but still it will be good to have this version tested
> > > too. Only with inclusion in -mm and testing by much wider user base
> > > can make it to mainline (I suppose nobody uses -mm for production use
> > > anyway).
> > >
> > >>   document why your version is that much faster than the original
> > >>   version and why you know your optimizations have no side effects
>
> With likely(), unlikely() and noinline *not* defined as NOP's performance
> drops:
>
> 1 run averages:
> 'Tiny LZO':
> Combined: 84.9292 usec
> Compression: 42.4646 usec
> Decompression: 42.4646 usec
> 'miniLZO':
> Combined: 61.3548 usec
> Compression: 43.5648 usec
> Decompression: 17.79 usec
>
> However, I'm worried that my testbed code - likely the Perl script that
> actually loops the test code and collects its output - is somehow faulting,
> as the way that the Compression and Decompression code have the exact same
> value.
>
> I'm going to toss some debugging output in the script and see if I can spot
> the problem.
>

Okay, checked my code and it was all a problem with cpu_to_le16 getting 
defined fully instead of just being a NOP. With that problem corrected the 
performance returns:

1 run averages:
'Tiny LZO':
Combined: 60.1028 usec
Compression: 42.0652 usec
Decompression: 18.0376 usec
'miniLZO':
Combined: 61.0932 usec
Compression: 43.4382 usec
Decompression: 17.655 usec

Combined average shows 'Tiny' to be 1.6% faster
Compression in 'Tiny' is 3.2% faster
Decompression in 'Tiny' is 2.2% slower

All in all, the trade-off in this code, with the overall performance of 
the 'Tiny' code being faster than the stock miniLZO code I'd like to say that 
I'm certain that the decompressor could probably be sped up more, although I 
don't know of a place in the kernel where less than half a microsecond would 
make a massive impact. (Only place I can think of where this might have a 
negative is in SLAB/SLOB/SLUB,  and I don't think that a low-level memory 
manager like those is a place for a compression algorithm anyway)

Later today or tommorrow  I'll start putting together another part to 
this "test-bed" for stress-testing the algorithm. Currently I only have a few 
ideas for tests:
(for benchmarking)
1) Random input to compressor
2) large input data
3) real-world data (mmap()'d chunk of /dev/mem as input)

(for stability checking)
4) deliberate corruption of compressed data
5) early finish (realloc() compressed data buffer to less than the full size 
   of the data)
6) late start (change pointer to start of compressed data so the decompressor
 doesn't start at the beginning)

When I have a better idea of how the LZO algorithm works I might try creating 
an input data-set for the decompressor that would deliberately overflow the 
output buffer. This is supposed to be caught by bounds-checking in 
the '_safe' version of the decompressor (the version  used in 'Tiny' and  
used in the benchmarking of miniLZO), however it might be possible to trick 
the decompressor. (If I do manage this and it crashes both 'Tiny' 
and 'miniLZO' I *will* report it to Herr Oberhumer as well as see if I can 
come up with a quick patch for the problem).

As I said before, any suggestions for how to improve the benchmark code are 
welcome, as are suggestions for tests I can add to it for stressing the 
new 'TinyLZO' implementation. Latest version of the test-bed attached. 
Significant changes include:
likely(), unlikely() and noinline are no longer NOP's
when the marked line in helpers.h is commented out, cpu_to_le16 functions as 
expected and is no longer a NOP. (Yes, that means this code is now fully 
capable of working correctly on a BE system).

DRH


lzo1x-test-bed-5.tar.bz2
Description: application/tbz


Re: [RFC][PATCH -mm 3/3] PM: Disable _request_firmware before hibernation/suspend

2007-05-28 Thread Ray Lee

On 5/28/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:

On Monday, 28 May 2007 17:55, Alan Stern wrote:
> You're using the PM_PRE_FREEZE and PM_POST_THAW notifiers for both this
> and the userspace helper change.  Is it your intention that drivers
> should continue to request these services but encounter an error if the
> request occurs at the wrong time?  Or do you expect drivers to use the
> notifier chains to know when they shouldn't make any requests?

In fact, I'd like drivers to use notifiers to actually load the firmware into
memory before hibernation/suspend.  Namely, if there's PM_PRE_FREEZE, the
driver calls request_firmware() from within the notifier and saves the firmware
in memory for future use, if need be.  Later, when PM_POST_THAW comes, the
memory holding the firmware is released.

Unfortunately there are drivers that call request_firmware() directly from
.resume() which blocks until timeout expires and fails anyway.  I just wanted
this to fail immediately, without waiting.


Stupid question time. Wouldn't it just be easier to have
request_firmware() keep a copy of the firmware once it's been loaded?
We're not talking about a lot of memory that would be wasted, and that
way no drivers have to be changed.

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


Re: stuff ready to be deleted?

2007-05-28 Thread Oliver Pinter

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


Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

2007-05-28 Thread Pavel Machek
Hi!

> >>That's a circular argument, and a fairly trivial one 
> >>at that.  If you
> >>can't properly manage your labels, then how do you 
> >>expect any
> >>security at all?
> >
> >Unfortunately, it's not at all as simple as all that. 
> >Toshiharu is  quite correct that it isn't always easy 
> >to actually implement.   Consider how many ad-croc 
> >usages of 'restorecon' are needed to get  a Fedora 
> >SELinux box through rc.sysinit:
> 
> While I don't think restorecon is really necessary to 
> properly boot  SELinux-enabled (I've got a Debian box 
> with some heavily customized  policy which does so just 
> fine), I am of the opinion that adding a  "name" 
> parameter to the file/directory create actions would be  
> useful.  For example, with such support you could 
> actually specify a  type-transition rule conditional on 
> a specific name or substring:
> 
> named_type_transition sshd_t tmp_t:sock_file prefix 
> "ssh-" ssh_sock_t;
> 
> Useful options for matching would be "prefix", "suffix", 
> "substr (start,len)".  "regex" would be nice but is 
> sorta computationally  intensive and would be likely to 
> cause more problems than it solves.

Could someone implement this? AFAICT that prevents SELinux from being
superset of AppArmor... Doing this should be significantly simpler
than whole AA, and hopefully it will end up less ugly, too.
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: ARM: Section mismatch warnings

2007-05-28 Thread Russell King
On Mon, May 28, 2007 at 09:58:47PM +0200, Sam Ravnborg wrote:
> Declaring neponset_probe __init cured it.
> Sorry for posting the wrong patch in the first place.

Arguably, making neponset_probe __devinit and neponset_port_fns
__devinitdata is arguably more correct since any device driver can
be bound and unbound at any time (grumble).

I don't think David's platform_driver_probe() is a proper answer
since it's still possible to unbind the driver, leaving no way to
re-bind.  IOW, it only solves half the problem.  Really, the
allowance of bind/unbind should be a per-driver and per-bus thing
imho.  That's for a separate discussion though.

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


Re: stuff ready to be deleted?

2007-05-28 Thread Jesper Juhl

On 28/05/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:


  i'm trying to keep track of kernel janitor projects that involve
removing dead content from the tree:

http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List

currently, the list contains the items:

* 1 Legacy power management
* 2 PCMCIA IOCTL support
* 3 Traffic shaper
* 4 Traffic policing
* 5 Userspace queueing via NETLINK
* 6 ebt: ulog support
* 7 MOXA SmartIO support
* 8 Old I2O ioctls
* 9 Stallion drivers
* 10 SDL RISCom/8 support
* 11 Macintosh M68K support
* 12 Commodore A2232 serial support
* 13 CONFIG_FORCED_INLINING
* 14 kernel_thread()

which of the above are legitimate candidates for removal?  which are
already underway in someone's local tree?  anything else that can
be added?  etc, etc.



Take a look at Documentation/feature-removal-schedule.txt
Some of that stuff is already listed there along with who is in charge
of removing it and when.

--
Jesper Juhl <[EMAIL PROTECTED]>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] LZO de/compression support - take 6

2007-05-28 Thread Daniel Hazelton
On Monday 28 May 2007 13:11:15 Adrian Bunk wrote:
> On Mon, May 28, 2007 at 09:33:32PM +0530, Nitin Gupta wrote:
> > On 5/28/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> >...
> >
> >> - then ensure that it works correctly on all architectures and
> >
> > Already tested on x86, amd64, ppc (by Bret). I do not have machines
> > from other archs available. Bret tested 'take 3' version but no
> > changes were introduced in further revisions that could affect
> > correctness - but still it will be good to have this version tested
> > too. Only with inclusion in -mm and testing by much wider user base
> > can make it to mainline (I suppose nobody uses -mm for production use
> > anyway).
> >
> >>   document why your version is that much faster than the original
> >>   version and why you know your optimizations have no side effects

With likely(), unlikely() and noinline *not* defined as NOP's performance 
drops:

1 run averages:
'Tiny LZO':
Combined: 84.9292 usec
Compression: 42.4646 usec
Decompression: 42.4646 usec
'miniLZO':
Combined: 61.3548 usec
Compression: 43.5648 usec
Decompression: 17.79 usec

However, I'm worried that my testbed code - likely the Perl script that 
actually loops the test code and collects its output - is somehow faulting, 
as the way that the Compression and Decompression code have the exact same 
value.

I'm going to toss some debugging output in the script and see if I can spot 
the problem.

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


stuff ready to be deleted?

2007-05-28 Thread Robert P. J. Day

  i'm trying to keep track of kernel janitor projects that involve
removing dead content from the tree:

http://fsdev.net/wiki/index.php?title=Kernel_Janitor%27s_Todo_List

currently, the list contains the items:

* 1 Legacy power management
* 2 PCMCIA IOCTL support
* 3 Traffic shaper
* 4 Traffic policing
* 5 Userspace queueing via NETLINK
* 6 ebt: ulog support
* 7 MOXA SmartIO support
* 8 Old I2O ioctls
* 9 Stallion drivers
* 10 SDL RISCom/8 support
* 11 Macintosh M68K support
* 12 Commodore A2232 serial support
* 13 CONFIG_FORCED_INLINING
* 14 kernel_thread()

which of the above are legitimate candidates for removal?  which are
already underway in someone's local tree?  anything else that can
be added?  etc, etc.

rday

-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page

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


  1   2   3   4   5   6   7   8   >