Re: [PATCH] CodingStyle: Add information about trailing whitespace.

[Josh Triplett]

Jan Engelhardt wrote:
> On Jun 28 2007 06:29, dave young wrote:
>> IMHO, another  cause of trailing whitespace is human error, for
>> example long lines breaking will easy to cause the first line with one
>> traling whitespace (original space between the last two words).
> 
> Most common errors (to me) are:
> 
>  - hit return+tab too quickly that it interchanges, hence producing
>the unwanted \t\n
>  - hit return+return to start a new paragraph of code;
>the intermediate line remains indented if autoindent is on.

Interestingly, emacs gets that case right: when you hit enter it places the
cursor at the properly indented insertion point, but if you leave the line
without typing anything it does not leave the indentation.  I thought I
remembered vim doing the same thing, but I just tested and it appears not.  It
seems to avoid leaving subsequent lines indented, but not the first one.

- Josh Triplett

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

Re: how about mutual compatibility between Linux's GPLv2 and GPLv3?

[Alexandre Oliva]

On Jun 28, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote:

>> As for making modifications, I'd like to take this opportunity to
>> withdraw, for purposes of interpretation, my earlier agreement that
>> TiVo permits modification, even though it doesn't permit modification
>> in place.  I don't see any distinction in US copyright law between
>> modification in place and modification by creating a separate work.

> In section 2 where it talks about modifications it at first doesn't seem
> to distinguish between source and binary, but it doesn't grant the right
> that the resulting modified program will actually work. And yes, you can
> still modify the kernel binary on the Tivo harddrive, it just won't boot
> with the standard bootloader.

> But there is an explicit no warranty clause in the GPLv2. Which I
> believe is a good thing. If the license tried to enforce usability,

Yup.  But will courts see this as a valid excuse for effectively
denying users the ability to modify the copies of the GPLed programs
they run on tivoized devices, even though the means to accomplish this
are based on blocking the ability to run the modified executable,
which happens to not require permission from the copyright holder in
the US?

Even more so when the modified binary provably works just fine on
similar computers, and fails to work on the tivoizing device just
because mechanisms were introduced to stop the user from modifying the
behavior of the software that runs in the device?  I.e., it fails
because you changed it, rather than because you broke it.

Couldn't this be understood by a court as an attempt to exploit a
loophole in the letter of the license, rather than as an intentional
permission to restrict the ability to run covered programs, an act
that the license phrases as "not restricted" and "outside its scope"
just because US copyright law doesn't demand permission from the
copyright holder to run programs, which results in permission to run
being outside the scope of a copyright license?


Anyhow, I didn't mean to restart this debate, I just wanted (as stated
above) to withdraw my earlier tentative agreement that "modification
in place" was something that could be forbidden without infringing
GPL.

>> When you modify a sculpture, you're modifying it in place, and this
>> requires as much copyright permission as creating a modified copy of
>> it.  Both count as modification.

> And when you scribble in the margin of a book you are also modifying it,
> so what.

Maybe it's fair use, especially for a printed book, of which many
copies presumably exist.

> I don't think you even need copyright permission, although you
> will probably get into trouble if the book was borrowed from a library.
> I don't see the relevance in the context of this discussion.

Relevance was only to counter the argument that the right to "modify
in place", as some put it, was not covered by the GPL, "because that's
not how copyright law defines modification."  I bought that argument
at first, but then I referred back to US copyright law and not only
failed to find supporting evidence for this argument, but actually
found opposing evidence.  So I brought it up to make sure my tentative
agreement wouldn't be used in a court as an indication that the
argument holds water.

>> Here are variations of another scenario I proposed back then:
>> 
>> - Tivoizing device ships with tivoized software, regardless of whether
>> the corresponding sources are accessible to the end user or hidden
>> inside the box, in a fully-encrypted disk that only that machine can
>> read.

> I'm assuming no written offer for access to the software is included.

Yup, that's the idea.

> Source are inaccessible, restricted the recipients rights to copy,
> distribute and modify the source code, GPLv2 violation.

So, the same standards would apply to the binaries: if they were
inaccessible, copyright holder could claim infringement under the same
grounds, right?

> If it doesn't download the sources then the binary is not accompanied by
> the corresponding source code and since we assumed no written offer this
> is a violation of section 3.

Except, perhaps, for this bit:

  If distribution of executable or object code is made by offering
  access to copy from a designated place, then offering equivalent
  access to copy the source code from the same place counts as
  distribution of the source code, even though third parties are not
  compelled to copy the source along with the object code.

So, let's narrow the scenario to: tivoized machine downloads binary
from protected site, refrains from downloading sources that it could
download, user can still access and copy the binaries, but can't
obtain the sources because the machine opted not to get them.

Now, the user can't distribute the binaries, because doing so without
being able to get the sources to pass them on would be copyright
infringement.  Would a court see this as a restriction on distribution
imposed by the distribut

RE: [PATCH] CodingStyle: Add information about trailing whitespace.

[Li Yang-r58472]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Josh Triplett
> Sent: Thursday, June 28, 2007 2:59 PM
> To: Jan Engelhardt
> Cc: dave young; Chris Shoemaker; Josh Triplett;
linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]
> Subject: Re: [PATCH] CodingStyle: Add information about trailing
whitespace.
> 
> Jan Engelhardt wrote:
> > On Jun 28 2007 06:29, dave young wrote:
> >> IMHO, another  cause of trailing whitespace is human error, for
> >> example long lines breaking will easy to cause the first line with
one
> >> traling whitespace (original space between the last two words).
> >
> > Most common errors (to me) are:
> >
> >  - hit return+tab too quickly that it interchanges, hence producing
> >the unwanted \t\n
> >  - hit return+return to start a new paragraph of code;
> >the intermediate line remains indented if autoindent is on.
> 
> Interestingly, emacs gets that case right: when you hit enter it
places the
> cursor at the properly indented insertion point, but if you leave the
line
> without typing anything it does not leave the indentation.  I thought
I
> remembered vim doing the same thing, but I just tested and it appears
not.  It
> seems to avoid leaving subsequent lines indented, but not the first
one.

No, vim works just fine here without leaving any indentation.  Maybe the
version of vim or the options matter.

- Leo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] CodingStyle: Add information about trailing whitespace.

[Dave Young]

On 6/28/07, Li Yang-r58472 <[EMAIL PROTECTED]> wrote:
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Josh Triplett
> Sent: Thursday, June 28, 2007 2:59 PM
> To: Jan Engelhardt
> Cc: dave young; Chris Shoemaker; Josh Triplett;
linux-kernel@vger.kernel.org;
> [EMAIL PROTECTED]
> Subject: Re: [PATCH] CodingStyle: Add information about trailing
whitespace.
>
> Jan Engelhardt wrote:
> > On Jun 28 2007 06:29, dave young wrote:
> >> IMHO, another  cause of trailing whitespace is human error, for
> >> example long lines breaking will easy to cause the first line with
one
> >> traling whitespace (original space between the last two words).
> >
> > Most common errors (to me) are:
> >
> >  - hit return+tab too quickly that it interchanges, hence producing
> >the unwanted \t\n
> >  - hit return+return to start a new paragraph of code;
> >the intermediate line remains indented if autoindent is on.
>
> Interestingly, emacs gets that case right: when you hit enter it
places the
> cursor at the properly indented insertion point, but if you leave the
line
> without typing anything it does not leave the indentation.  I thought
I
> remembered vim doing the same thing, but I just tested and it appears
not.  It
> seems to avoid leaving subsequent lines indented, but not the first
one.

No, vim works just fine here without leaving any indentation.  Maybe the
version of vim or the options matter.


Yes, vim autoindent doesn't leave tabs in blank line for me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/7] ICH Force HPET: Make generic time capable of switching broadcast timer

[Andrew Morton]

On Fri, 22 Jun 2007 13:38:22 -0700 Venki Pallipadi <[EMAIL PROTECTED]> wrote:

> Auto-detect the presence of HPET on ICH5 or newer platforms and enable
> HPET for broadcast timer.

Hey.  This works.  The Vaio-of-doom is running tickless for the first time.

I can't start the X server any more, but that's probably unrelated ;)


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

linux.conf.au 2008 - call for proposals

[Peter Lieverdink]

I hope this is of some interest to some of you. :-)

We can't run LCA without your participation and we hope you'll help us
make it a great conference again.


== linux.conf.au 2008 Call For Presentations ==

linux.conf.au isn't just a Linux conference. It is a technical 
conference about Free Software, held annually in Australasia.
We invite submissions on any Free Software related subject; from 
Linux and the BSDs to OpenOffice.org, from networking to 
audio-visual magic, from deep hacks to free content.

== Important dates ==

 * Submissions open: Friday, June 1 2007
 * Submission deadline: Friday, July 20, 2007
 * Email notifications from review committee: early September
 * Conference begins: Monday, January 28 2008

== Presentations being accepted ==

You can submit a 50 minute talk proposal, or a 2 or 4 hour tutorial
proposal: tutorials are interactive and involve more audience
participation.  All presentations must be related to Free and Open
Source Software.

== How to submit ==

Please see http://linux.conf.au/presentations for more information on
the types of presentations we're looking for and full details of how to
submit a proposal. You can even submit a video pitch!

== About linux.conf.au ==

linux.conf.au (http://linux.conf.au/) is Australia's annual technical
conference about Free Software. Fun, informal and seriously technical,
linux.conf.au draws together Free and Open Source Software developers 
from across the world. It will be held from January 28th to February 
2nd, 2008 at The University of Melbourne.

== About Linux Australia ==

Linux Australia (http://www.linux.org.au/) is the peak body for 
Linux User Groups (LUGs) around Australia, and as such represents
approximately 5000 Australian Linux users and developers. Linux
Australia facilitates the organisation of this international 
Free Software conference in a different Australasian city each year.

Cheers,
- Peter.
-- 
peter lieverdink
secretary   MEL8OURNE2008 
linux.conf.au   must.be.there
9662 1CB5 8E54 450D 2E12 9D7E 580E 2519 969F 3F57

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] CodingStyle: Add information about trailing whitespace.

[Dave Young]

On 6/28/07, Dave Young <[EMAIL PROTECTED]> wrote:
>On 6/28/07, Li Yang-r58472 <[EMAIL PROTECTED]> wrote:
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Josh Triplett
> > Sent: Thursday, June 28, 2007 2:59 PM
> > To: Jan Engelhardt
> > Cc: dave young; Chris Shoemaker; Josh Triplett;
> linux-kernel@vger.kernel.org;
> > [EMAIL PROTECTED]
> > Subject: Re: [PATCH] CodingStyle: Add information about trailing
> whitespace.
> >
> > Jan Engelhardt wrote:
> > > On Jun 28 2007 06:29, dave young wrote:
> > >> IMHO, another  cause of trailing whitespace is human error, for
> > >> example long lines breaking will easy to cause the first line with
> one
> > >> traling whitespace (original space between the last two words).
> > >
> > > Most common errors (to me) are:
> > >
> > >  - hit return+tab too quickly that it interchanges, hence producing
> > >the unwanted \t\n
> > >  - hit return+return to start a new paragraph of code;
> > >the intermediate line remains indented if autoindent is on.
> >
> > Interestingly, emacs gets that case right: when you hit enter it
> places the
> > cursor at the properly indented insertion point, but if you leave the
> line
> > without typing anything it does not leave the indentation.  I thought
> I
> > remembered vim doing the same thing, but I just tested and it appears
> not.  It
> > seems to avoid leaving subsequent lines indented, but not the first
> one.
>
> No, vim works just fine here without leaving any indentation.  Maybe the
> version of vim or the options matter.
>
Yes, vim autoindent doesn't leave tabs in blank line for me.


And for vim trailing space, there's a tip in vim.org:
http://www.vim.org/tips/tip.php?tip_id=878
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] mtd: add module license to mtdbdi

[David Howells]

Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:

>   This seems to be a known issue [1] about Photron PNC-2000 module called
> pnc2000. To reproduce this just 'modprobe pnc2000'. The patch attached at 
> least
> makes the kernel to be not tainted when mtdbdi gets loaded.

This is the wrong solution.  This file should not be its own module, but
should rather be linked with mtdcore.

There was a patch for this, but I don't know what happened to it.

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

[PATCH 1/1] Fix elf_core_dump() when writing arch specific notes (spu coredumps)

[Michael Ellerman]

elf_core_dump() supports dumping arch specific ELF notes, via the #define
ELF_CORE_WRITE_EXTRA_NOTES. Currently the only user of this is the powerpc
spu coredump code.

There is a bug in the handling of foffset WRT the arch notes, which causes
us to erroneously increment foffset by the size of the arch notes, leaving
a block of zeroes in the file, and causing all subsequent data in the file
to be at  + . eg:

  LOAD  0x05 0x0010 0x 0x2 0x2 R E 0x1

Tells us we should have a chunk of data at 0x5. The truth is the data is
at 0x90dbc = 0x5 + 0x40dbc (the size of the arch notes).

This bug prevents gdb from reading the core file correctly.

The simplest fix is to simply remember the size of the arch notes, and add
it to foffset after we've written the arch notes. The only drawback is that
if the arch code doesn't write as many bytes as it said it would, we end up
with a broken core dump again. For now I think that's a reasonable
requirement.

Tested on a Cell blade, gdb no longer complains about the core file being
bogus.

While I'm here I should point out that the spu coredump code does not work
if we're dumping to a pipe - we'll have to wait for 23 to fix that.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 fs/binfmt_elf.c |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index fa8ea33..08e4414 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1499,6 +1499,9 @@ static int elf_core_dump(long signr, struct pt_regs 
*regs, struct file *file)
 #endif
int thread_status_size = 0;
elf_addr_t *auxv;
+#ifdef ELF_CORE_WRITE_EXTRA_NOTES
+   int extra_notes_size;
+#endif
 
/*
 * We no longer stop all VM operations.
@@ -1628,7 +1631,8 @@ static int elf_core_dump(long signr, struct pt_regs 
*regs, struct file *file)
sz += thread_status_size;
 
 #ifdef ELF_CORE_WRITE_EXTRA_NOTES
-   sz += ELF_CORE_EXTRA_NOTES_SIZE;
+   extra_notes_size = ELF_CORE_EXTRA_NOTES_SIZE;
+   sz += extra_notes_size;
 #endif
 
fill_elf_note_phdr(&phdr, sz, offset);
@@ -1674,6 +1678,7 @@ static int elf_core_dump(long signr, struct pt_regs 
*regs, struct file *file)
 
 #ifdef ELF_CORE_WRITE_EXTRA_NOTES
ELF_CORE_WRITE_EXTRA_NOTES;
+   foffset += extra_notes_size;
 #endif
 
/* write out the thread status notes section */
-- 
1.5.1.3.g7a33b

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

Re: Oops on rmmod asus_acpi

[Dmitry Monakhov]

On 21:16 Срд 27 Июн , Jan Engelhardt wrote:
> Hi,
> 
> 
> 
>   modprobe asus_acpi
>   rmmod asus_acpi
> 
> is all that is needed to trigger an Oops in 2.6.22-rc6 (x86).
> If you need more info, please let me know, thanks.
> 
> Note that the machine is not ASUS at all (vmware).
> (But suse_factory loads asus_acpi anyway -wtf?!)
Fixed in -mm tree by asus_acpi-fix-oops-on-non-asus-machines.patch
> 
> 
> Jun 27 21:11:33 su1 kernel: WARNING: at /ws/linux-2.6.22/lib/kref.c:33 
> kref_get()
> Jun 27 21:11:33 su1 kernel:  [] kref_get+0x34/0x3f
> Jun 27 21:11:33 su1 kernel:  [] kobject_get+0xf/0x13
> Jun 27 21:11:33 su1 kernel:  [] get_driver+0xe/0x14
> Jun 27 21:11:33 su1 kernel:  [] driver_remove_file+0xb/0x25
> Jun 27 21:11:33 su1 kernel:  [] bus_remove_driver+0x17/0x75
> Jun 27 21:11:33 su1 kernel:  [] asus_acpi_exit+0x18/0x28 [asus_acpi]
> Jun 27 21:11:33 su1 kernel:  [] sys_delete_module+0x1a0/0x1c8
> Jun 27 21:11:33 su1 kernel:  [] audit_syscall_entry+0x10d/0x137
> Jun 27 21:11:33 su1 kernel:  [] do_syscall_trace+0x13d/0x181
> Jun 27 21:11:33 su1 kernel:  [] syscall_call+0x7/0xb
> Jun 27 21:11:33 su1 kernel:  ===
> Jun 27 21:11:33 su1 kernel: WARNING: at /ws/linux-2.6.22/lib/kref.c:33 
> kref_get()
> Jun 27 21:11:33 su1 kernel:  [] kref_get+0x34/0x3f
> Jun 27 21:11:33 su1 kernel:  [] kobject_get+0xf/0x13
> Jun 27 21:11:33 su1 kernel:  [] get_driver+0xe/0x14
> Jun 27 21:11:33 su1 kernel:  [] driver_remove_file+0xb/0x25
> Jun 27 21:11:33 su1 kernel:  [] bus_remove_driver+0x23/0x75
> Jun 27 21:11:33 su1 kernel:  [] asus_acpi_exit+0x18/0x28 [asus_acpi]
> Jun 27 21:11:33 su1 kernel:  [] sys_delete_module+0x1a0/0x1c8
> Jun 27 21:11:33 su1 kernel:  [] audit_syscall_entry+0x10d/0x137
> Jun 27 21:11:33 su1 kernel:  [] do_syscall_trace+0x13d/0x181
> Jun 27 21:11:33 su1 kernel:  [] syscall_call+0x7/0xb
> Jun 27 21:11:33 su1 kernel:  ===
> Jun 27 21:11:33 su1 kernel: BUG: unable to handle kernel NULL pointer 
> dereference at virtual address 0010
> Jun 27 21:11:33 su1 kernel:  printing eip:
> Jun 27 21:11:33 su1 kernel: c02ab74b
> Jun 27 21:11:33 su1 kernel: *pde = 
> Jun 27 21:11:33 su1 kernel: Oops:  [#1]
> Jun 27 21:11:33 su1 kernel: SMP 
> Jun 27 21:11:33 su1 kernel: Modules linked in: asus_acpi ipv6 nfs lockd 
> nfs_acl sunrpc dock button battery ac dm_crypt loop dm_mod xt_hashlimit 
> ip6_tables xt_u32 xt_conntrack xt_connlimit nf_conntrack nfnetlink x_tables 
> rtc_cmos rtc_core rtc_lib pcnet32 mii i2c_piix4 i2c_core mptctl generic piix 
> ide_core shpchp pci_hotplug intel_agp agpgart sg parport_pc lp parport sd_mod 
> edd xfs fan mptspi mptscsih mptbase scsi_transport_spi ata_piix libata 
> scsi_mod thermal processor
> Jun 27 21:11:33 su1 kernel: CPU:0
> Jun 27 21:11:33 su1 kernel: EIP:0060:[]Not tainted VLI
> Jun 27 21:11:33 su1 kernel: EFLAGS: 00010246   (2.6.22-rc6+ccj #11)
> Jun 27 21:11:33 su1 kernel: EIP is at klist_del+0x9/0x31
> Jun 27 21:11:33 su1 kernel: eax:    ebx:    ecx: c02fdc20   
> edx: 0001
> Jun 27 21:11:33 su1 kernel: esi:    edi: c6aa262c   ebp: c139c000   
> esp: c139df30
> Jun 27 21:11:33 su1 kernel: ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
> Jun 27 21:11:33 su1 kernel: Process rmmod (pid: 3004, ti=c139c000 
> task=c5da0030 task.ti=c139c000)
> Jun 27 21:11:33 su1 kernel: Stack: c6aa262c  c0341100 c02ab7c3 
> c6aa25d0 c0227f36 c6aa2d80  
> Jun 27 21:11:33 su1 kernel:0880 c6a9f018 c013cebc 73757361 
> 7063615f c2cf0069  c01494bd 
> Jun 27 21:11:33 su1 kernel:bfb59010 0081 4003 c5da0030 
> bfb5b858 0880  c139dfb8 
> Jun 27 21:11:33 su1 kernel: Call Trace:
> Jun 27 21:11:33 su1 kernel:  [] klist_remove+0x8/0x13
> Jun 27 21:11:33 su1 kernel:  [] bus_remove_driver+0x50/0x75
> Jun 27 21:11:33 su1 kernel:  [] asus_acpi_exit+0x18/0x28 [asus_acpi]
> Jun 27 21:11:33 su1 kernel:  [] sys_delete_module+0x1a0/0x1c8
> Jun 27 21:11:33 su1 kernel:  [] audit_syscall_entry+0x10d/0x137
> Jun 27 21:11:33 su1 kernel:  [] do_syscall_trace+0x13d/0x181
> Jun 27 21:11:33 su1 kernel:  [] syscall_call+0x7/0xb
> Jun 27 21:11:33 su1 kernel:  ===
> Jun 27 21:11:33 su1 kernel: Code: ff 8b 04 24 8b 16 89 46 08 b0 01 86 02 85 
> ed 74 08 85 ff 74 04 89 f8 ff d5 8b 04 24 5a 5b 5e 5f 5d c3 57 89 c7 56 53 8b 
> 18 89 d8 <8b> 73 10 e8 d3 22 00 00 89 f8 e8 6f ff ff ff 83 f8 01 19 c0 f7 
> Jun 27 21:11:33 su1 kernel: EIP: [] klist_del+0x9/0x31 SS:ESP 
> 0068:c139df30
> 
> 
>   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/

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

Re: [PATCH] hw_random: add quality categories

[Henrique de Moraes Holschuh]

On Wed, 27 Jun 2007, Michael Buesch wrote:
> On Wednesday 27 June 2007 18:40:41 Henrique de Moraes Holschuh wrote:
> > There *is* a much better way to deal with it, though.  Add the fail always
> > RNG device, and always select it by default.  Let the user specifically set
> > which RNG he wants, and it now rates as "trusted", which is the only
> > fail-proof way to go about it IMHO.
> 
> Well, but it changes ABI, which is forbidden.
> After a kernel update your system will partially not work anymore.

.  At least it will not be doing anything dangerous, and it is a ABI
*fix*, so you are not just changing it for the kicks of it.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: NAK (bashizm in the /bin/sh script): [PATCH v3] doc/oops-tracing: add Code: decode info

[Arne Georg Gleditsch]

Randy Dunlap <[EMAIL PROTECTED]> writes:
> On Tue, 26 Jun 2007 19:25:00 +0200 Julio M. Merino Vidal wrote:
>> The correct expression could be $((${a} + 2)).  Tested under NetBSD's  
>> sh, which is very POSIX-compliant.
>
> Thanks.  Does anyone see other changes that are needed?

[..]

> and the complete script is:

Both busybox sh and dash are happy with this.  (Or rather, busybox
would be if its mktemp hadn't been broken.)

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

Re: [Possible BUG] Logitech USB keyboard inconsistent led state

[Antonino Ingargiola]

2007/6/27, Jiri Kosina <[EMAIL PROTECTED]>:

On Wed, 27 Jun 2007, Antonino Ingargiola wrote:

> I'm using a logitech USB keyboard, I think it's one of the most cheap
> and diffuse logitech keyboard models.
> I have an inconsistent led state. During boot the NumLock led blinks
> several times and is on as boot finishes. However the numeric keypad
> works as it was off (no numbers, keypad '.' works as Canc, '0' as Ins
> and so on).

Could you please send me vendor and product ids of the keyboard? I will
send you a patch to test.


Sure, here it is:

$ cat /sys/bus/usb/devices/1-1.2/idVendor
046d
$ cat /sys/bus/usb/devices/1-1.2/idProduct
c311


Best regards,

   ~ Antonio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 RFC #2] hwrng: Add type categories

[Henrique de Moraes Holschuh]

On Wed, 27 Jun 2007, Michael Buesch wrote:
> Ok, all very good ideas. Patches are welcome ;)

Not from me, sorry. I really don't have the time, or the drive, to do it
right now.  thinkpad-acpi is taking all my "kernel code" time, which is not
much.

> > I don't much like sysfs over IOCTLs for this, as you will probably need to
> > be able to set and get things in an atomic way.  A sysfs binary attribute
> > would also work.  A sysfs one-value-per-attribute bunch of them is
> > completely useless from a security point of view.
> 
> hm? Why?

Because you cannot risk anyone changing one of them behind your back while
you are trying to set them all before you lock them.  And I am not even
considering an attack scenario, I am considering two apps trying to set it
up concurrently.

You need some sort of locking for this sort of device, and exclusive open +
ioctl solves the problem completely.  Sysfs is not made for this kind of
thing.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] LinuxPPS (with new syscalls API)

[David Woodhouse]

On Thu, 2007-06-28 at 00:46 +0200, Rodolfo Giometti wrote:
> Just last question: I still don't well understand where I should
> declare the new compat_sys_time_pps_fetch() syscall... it's
> automagically defined by the system when CONFIG_COMPAT is enabled? :-o

It isn't used on i386. On a 64-bit architecture, you need to put
compat_sys_time_pps_fetch() into the syscall table for 32-bit
processes. 

On PowerPC you do this by using COMPAT_SYS_SPU(time_pps_fetch) instead
of SYSCALL_SPU(..) in include/asm-powerpc/systbl.h. On x86_64 you'd put
it into the ia32_sys_call_table in arch/x86_64/ia32/ia32entry.S

-- 
dwmw2

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

Re: [PATCH] LinuxPPS (with new syscalls API)

[Rodolfo Giometti]

On Thu, Jun 28, 2007 at 09:08:53AM +0100, David Woodhouse wrote:
> On Thu, 2007-06-28 at 00:46 +0200, Rodolfo Giometti wrote:
> > Just last question: I still don't well understand where I should
> > declare the new compat_sys_time_pps_fetch() syscall... it's
> > automagically defined by the system when CONFIG_COMPAT is enabled? :-o
> 
> It isn't used on i386. On a 64-bit architecture, you need to put
> compat_sys_time_pps_fetch() into the syscall table for 32-bit
> processes. 
> 
> On PowerPC you do this by using COMPAT_SYS_SPU(time_pps_fetch) instead
> of SYSCALL_SPU(..) in include/asm-powerpc/systbl.h. On x86_64 you'd put
> it into the ia32_sys_call_table in arch/x86_64/ia32/ia32entry.S

I see.

Do you think I should add these functions into my patch, even if I
cannot test it, or it's enought providing just the
compat_sys_time_pps_fetch() function?

Thanks,

Rodolfo

-- 

GNU/Linux Solutions  e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded Systems[EMAIL PROTECTED]
UNIX programming phone: +39 349 2432127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] ICH Force HPET: Make generic time capable of switching broadcast timer

[Andrew Morton]

On Thu, 28 Jun 2007 00:12:21 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:

> I can't start the X server any more, but that's probably unrelated ;)
> 
>  me hopelessly outnumbered>

And the winner of the u-o-akpm-1-hour-of-his-life-back award (and the bonus
u-delayed-next-mm-by-a-day award!) is   git-selinux.patch!

(II) Loading /usr/lib/xorg/modules/libvgahw.so
(II) Module vgahw: vendor="X.Org Foundation"
compiled for 7.0.0, module version = 0.1.0
ABI class: X.Org Video Driver, version 0.8
(**) I810(0): Depth 24, (--) framebuffer bpp 32
(==) I810(0): RGB weight 888
(==) I810(0): Default visual is TrueColor
(II) Loading sub module "int10"
(II) LoadModule: "int10"
(II) Reloading /usr/lib/xorg/modules/libint10.so
(II) I810(0): initializing int10
(EE) I810(0): Cannot shmat() low memory
(EE) I810(0): shmat(low_mem) error: Invalid argument
(EE) I810(0): VBE initialization failed.

Due to

commit fe276418917d00e6f7ecab2efa8331dd86db2f3f
Author: Eric Paris <[EMAIL PROTECTED]>
Date:   Wed Jun 6 02:30:33 2007 -0400

security: Protection for exploiting null dereference using mmap

Add a new security check on mmap operations to see if the user is attempting
to mmap to low area of the address space.  The amount of space protected is
indicated by the new proc tunable /proc/sys/kernel/mmap_min_addr and
defaults to 0, preserving existing behavior.

This patch uses a new SELinux security class "memprotect."  Policy already
contains a number of allow rules like a_t self:process * (unconfined_t being
one of them) which mean that putting this check in the process class (its
best current fit) would make it useless as all user processes, which we also
want to protect against, would be allowed. By taking the memprotect name of
the new class it will also make it possible for us to move some of the other
memory protect permissions out of 'process' and into the new class next time
we bump the policy version number (which I also think is a good future idea)

Acked-by: Stephen Smalley <[EMAIL PROTECTED]>
Signed-off-by: Eric Paris <[EMAIL PROTECTED]>
Signed-off-by: James Morris <[EMAIL PROTECTED]>

and yes, setting /proc/sys/kernel/mmap_min_addr to zero does fix it. 
(Shouldn't this be in /proc/sys/vm?)

My fix:

--- a/security/selinux/hooks.c~git-selinux-disable-mmap_min_addr-by-default
+++ a/security/selinux/hooks.c
@@ -4917,15 +4917,6 @@ static __init int selinux_init(void)
sizeof(struct 
inode_security_struct),
0, SLAB_PANIC, NULL, NULL);
 
-   /*
-* Tasks cannot mmap below this without the mmap_zero permission.
-* If not enabled already, do so by setting it to 64KB.
-*/
-   if (mmap_min_addr == 0) {
-   enabled_mmap_min_addr = 1;
-   mmap_min_addr = 65536;
-   }
-
avc_init();
 
original_ops = secondary_ops = security_ops;
_

although perhaps we should permit suitably-privileged apps (ie: X) to
override this instead.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] LinuxPPS (with new syscalls API)

[David Woodhouse]

On Thu, 2007-06-28 at 10:15 +0200, Rodolfo Giometti wrote:
> Do you think I should add these functions into my patch, even if I
> cannot test it, or it's enought providing just the
> compat_sys_time_pps_fetch() function? 

Probably best to put them in. That way, you make it easier for people to
test. Ideally, you should also provide a simple program that other
people can use to test it, preferably without needing hardware (or at
least just a nullmodem cable and another test program at the other end
of it).

-- 
dwmw2

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

Re: [PATCH] LinuxPPS (with new syscalls API)

[Rodolfo Giometti]

On Thu, Jun 28, 2007 at 09:31:14AM +0100, David Woodhouse wrote:
> On Thu, 2007-06-28 at 10:15 +0200, Rodolfo Giometti wrote:
> > Do you think I should add these functions into my patch, even if I
> > cannot test it, or it's enought providing just the
> > compat_sys_time_pps_fetch() function? 
> 
> Probably best to put them in. That way, you make it easier for people to

Mmm... so I should provide new syscalls for _all_
architectures... gulp! :)

It could be acceptable, just for the first release, to provide the
support for x86 only?

In this manner we can have a first release of LinuxPPS in the main
line just for x86 and then me, or other people, may add support for
the several supported architectures.

> test. Ideally, you should also provide a simple program that other
> people can use to test it, preferably without needing hardware (or at
> least just a nullmodem cable and another test program at the other end
> of it).

I already have a basic testing program... I can add it into
Documentation/pps directory, can't I?

Ciao,

Rodolfo

-- 

GNU/Linux Solutions  e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded Systems[EMAIL PROTECTED]
UNIX programming phone: +39 349 2432127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] x86_64: arch_pick_mmap_layout() fixlet

[Alexey Dobriyan]

sparse now warns about
arch/x86_64/mm/mmap.c:15:3: warning: returning void-valued expression

Generated code looks correct: there is jump to the end of
arch_pick_mmap_layout() after ia32_pick_mmap_layout(), but this should be fixed
regardless.

Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---

 arch/x86_64/mm/mmap.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/arch/x86_64/mm/mmap.c
+++ b/arch/x86_64/mm/mmap.c
@@ -11,8 +11,10 @@
 void arch_pick_mmap_layout(struct mm_struct *mm)
 {
 #ifdef CONFIG_IA32_EMULATION
-   if (current_thread_info()->flags & _TIF_IA32)
-   return ia32_pick_mmap_layout(mm);
+   if (current_thread_info()->flags & _TIF_IA32) {
+   ia32_pick_mmap_layout(mm);
+   return;
+   }
 #endif
mm->mmap_base = TASK_UNMAPPED_BASE;
if (current->flags & PF_RANDOMIZE) {

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Documentation/firmware_class/firmware_sample_driver.c

[Anders Blomdell]

Marcel Holtmann wrote:
> Hi Anders,
> 
>> Signed-off-by: Anders Blomdell <[EMAIL PROTECTED]>
>>
>> Minor modifications to make the example load and unload without Oops
>>
>> This is what unpatched version generates with 2.6.21.3
>>
>> kernel: Oops:  [#2]
>> ...
>> kernel: Call Trace:
>> kernel:  [] sysfs_create_dir+0x49/0x63
>> kernel:  [] kobject_shadow_add+0xd5/0x17d
>> kernel:  [] kobject_set_name+0x2b/0x92
>> kernel:  [] device_add+0x9a/0x58e
>> kernel:  [] klist_init+0x23/0x2e
>> kernel:  [] _request_firmware+0x116/0x29f
>> kernel:  [] wait_for_completion+0x8b/0x93
>> kernel:  [] request_firmware+0xf/0x11
>> kernel:  [] sample_init+0x59/0xc0 [firmware_sample_driver]
>> kernel:  [] sys_init_module+0x16b7/0x17ee
>> kernel:  [] printk+0x0/0x1f
>> kernel:  [] mntput_no_expire+0x11/0x6e
>> kernel:  [] syscall_call+0x7/0xb
>>
>>
>>
>> diff -u Documentation/firmware_class/firmware_sample_driver.c
>> /tmp/fw/firmware_sample_driver.c
>> --- Documentation/firmware_class/firmware_sample_driver.c   2007-05-24
>> 23:22:47.0 +0200
>> +++ /tmp/fw/firmware_sample_driver.c2007-06-27 16:51:16.0 +0200
>> @@ -15,11 +15,16 @@
>>
>>  #include "linux/firmware.h"
>>
>> +static void ghost_release(struct device *dev)
>> +{
>> +   printk(KERN_DEBUG "firmware_sample_driver: ghost_release\n");
>> +}
>> +
> 
> I know it is a sample driver, but you can't do that. You have to
> allocate the device and then free it here.
Are you sure about this? The code in the example looks very similar to the code
in "Linux Device Drivers" 3rd edition, p 382.

Regards

Anders Blomdell

-- 
Anders Blomdell  Email: [EMAIL PROTECTED]
Department of Automatic Control
Lund University  Phone:+46 46 222 4625
P.O. Box 118 Fax:  +46 46 138118
SE-221 00 Lund, Sweden
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: libata-bug in 2.6.21.5 on amd64 with ali chipset

[Hemmann, Volker Armin]

On Mittwoch, 27. Juni 2007, you wrote:

> It has worked in the past. I will try different kernels in the next
> 24hours.

I tried this kernels:
2.6.20
2.6.20.1
2.6.21
2.6.21.1
2.6.21.3
2.6.21.5

2.6.21.5 with and without cfs. Every other kernel without cfs. Patched with 
reiser4, nvidia not loaded nor used. All of them locked up. I tried two 
different cdrtools 2.01.01_alpha27 and alpha25. No change.

The strange thing: 2.6.21.1 has worked in the past. At the 21.May I tried 
(successfully) to burn a dvd. The only real change I could find since then: I 
recompiled the whole system to remove 'ricer' cflags. 

Glück Auf
Volker
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 16/16] fix handling of integer constant expressions

[Segher Boessenkool]

Here are three independently invalid non-ICEs that sparse doesn't
diagnose.

extern int f(void);
enum { cast_to_ptr = (int) (void *) 0 };
enum { cast_to_float = (int) (double) 1 };


Those two *really* shouldn't fail. I don't care if the C standard says 
so,

that is *fine*.


GCC doesn't guarantee you this, either.


In particular, "offsetof()" should be portably able to basically be the
standard #define, which involves an integer cast from a constant 
pointer.

That had *better* be a valid constant integer expression, because it's
very useful.


Yes it's useful.  That's why GCC gives you __builtin_offsetof()
for this purpose.


And I think standards can go screw themselves, and you can make it an
error with some "--standard-pedantic" switch or similar.

Standards are just random pieces of paper, for crying out loud! They 
have

zero relevance in the end.


Sure, as long as you don't care about compatibility across
compilers, what matters is what the compilers you _do_ use
actually implement.  And note that GCC doesn't guarantee
you much over what the C standard does.  Almost everything
it allows extra is just an implementation side effect.


Segher

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.

[Segher Boessenkool]

+- #address-cells : Address representation for "rapidio" devices.
+  This field represents the number of cells needed to represent
+  the RapidIO address of the registers.  For supporting more than
+  32-bits RapidIO address, this field should be <2>.
+  See 1) above for more details on defining #address-cells.


What does the RapidIO standard say about number of address
bits?  You want to follow that, so all RapidIO devices can
use the same #address-cells, not just the FSL ones.  Also,
are there different kinds of address spaces on the bus, or
is it just one big memory-like space?


Segher

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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/5 v2] Add the explanation and a sample of RapidIO DTS sector to the document of booting-without-of.txt file.

[Segher Boessenkool]

+   k) RapidIO
+
+   Required properties:


Should probably recommend a name for the node here, as well.  "srio" I
guess, from the example below.


I would prefer "rapidio", being more generic and more
readable.  What would parallel RapidIO be, "prio"?  No
thanks :-)


Segher

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 0/6] Convert all tasklets to workqueues

[Ingo Molnar]

* Jeff Garzik <[EMAIL PROTECTED]> wrote:

> Tasklets fill a niche not filled by either workqueues (slower, 
> requiring context switches, and possibly much latency is all wq's 
> processes are active) [...]

... workqueues are also possibly much more scalable (percpu workqueues 
are easy without changing anything in your code but the call where you 
create the workqueue).

the context-switch argument i'll believe if i see numbers. You'll 
probably need in excess of tens of thousands of irqs/sec to even be able 
to measure its overhead. (workqueues are driven by nice kernel threads 
so there's no TLB overhead, etc.)

the only remaining argument is latency: but workqueues are already 
pretty high-prio (with a default priority of nice -5) - and you can 
increase it even further. You can make it SCHED_FIFO prio 98 if latency 
is so important. Tasklets on the other hand are _unconditionally_ 
high-priority. So this argument is more of an arms-race argument: "i 
want _my_ processing to be done immediately!". The fact that workqueues 
can be preempted and that their priorities can be adjusted flexibly is 
an optional _bonus_, not a disadvantage. If low-prio workqueues hurts 
your workflow, make them high-prio.

> And moving code -back- into hardirq is just the wrong thing to do, 
> usually.

agreed - except if the in-tasklet processing is really thin and there's 
already a softirq layer in the workflow. (which the case was for the 
example that was cited.) In such a case moving either to the hardirq or 
to the softirq looks like the right thing - instead of the tasklet 
intermediary.

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

[RFC/PATCH] debug workqueue deadlocks with lockdep

[Johannes Berg]

This patch adds a fake lock to each workqueue in order to debug things
where you have something like

  my_function() -> lock(); ...; flush_workqueue(); ...
vs
  run_workqueue() -> my_work() -> ...; lock(); ...

which can obviously deadlock if my_work is scheduled when my_function()
is invoked (but hasn't locked yet.)

Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
---
I'm not sure if this is correct on SMP because then might it complain
that the fake lock is locked at the same time from multiple CPUs? I
haven't (on my quad G5), however, had it print out anything but the
trace below which is legitimate.

This is sort of a regression test for an actual deadlock in mac80211 I
found by experiencing it, apparently it's really hard to trigger. Then I
wanted to see if I could add lockdep support to debug cases like it.
Here's the output with my patch:

[  171.522236] ===
[  171.522248] [ INFO: possible circular locking dependency detected ]
[  171.522257] 2.6.22-rc6 #163
[  171.522266] ---
[  171.522275] khubd/1922 is trying to acquire lock:
[  171.522283]  (khelper){--..}, at: [] 
.flush_workqueue+0x48/0xf4
[  171.522318] 
[  171.522320] but task is already holding lock:
[  171.522330]  (rtnl_mutex){--..}, at: [] 
.mutex_lock+0x3c/0x58
[  171.522366] 
[  171.522368] which lock already depends on the new lock.
[  171.522371] 
[  171.522383] 
[  171.522386] the existing dependency chain (in reverse order) is:
[  171.522396] 
[  171.522398] -> #1 (rtnl_mutex){--..}:
[  171.522424][] .__lock_acquire+0xb8c/0xd68
[  171.522476][] .lock_acquire+0xa0/0xe8
[  171.522527][] .__mutex_lock_slowpath+0x138/0x3d0
[  171.522579][] .mutex_lock+0x3c/0x58
[  171.522629][] .rtnl_lock+0x24/0x40
[  171.522677][] .linkwatch_event+0x20/0x70
[  171.522725][] .run_workqueue+0x114/0x22c
[  171.522774][] .worker_thread+0x11c/0x140
[  171.522822][] .kthread+0x84/0xd4
[  171.522872][] .kernel_thread+0x4c/0x68
[  171.522922] 
[  171.522924] -> #0 (khelper){--..}:
[  171.522947][] .__lock_acquire+0xa7c/0xd68
[  171.523000][] .lock_acquire+0xa0/0xe8
[  171.523051][] .flush_workqueue+0x78/0xf4
[  171.523102][] .ieee80211_stop+0x1fc/0x3a4 
[mac80211]
[  171.523176][] .dev_close+0xb8/0xfc
[  171.523222][] .unregister_netdevice+0xc0/0x254
[  171.523275][] .__ieee80211_if_del+0x34/0x50 
[mac80211]
[  171.523352][] .ieee80211_unregister_hw+0xf8/0x2d8 
[mac80211]
[  171.523421][] .disconnect+0x3c/0x98 
[zd1211rw_mac80211]
[  171.523483][] .usb_unbind_interface+0x6c/0xcc 
[usbcore]
[  171.523555][] .__device_release_driver+0xcc/0x110
[  171.523605][] .device_release_driver+0x70/0xbc
[  171.523655][] .bus_remove_device+0xa0/0xcc
[  171.523708][] .device_del+0x2f4/0x3d4
[  171.523758][] .usb_disable_device+0xa0/0x150 
[usbcore]
[  171.523833][] .usb_disconnect+0xfc/0x1a4 [usbcore]
[  171.523907][] .hub_thread+0x3d8/0xc70 [usbcore]
[  171.523984][] .kthread+0x84/0xd4
[  171.524039][] .kernel_thread+0x4c/0x68
[  171.524093] 
[  171.524096] other info that might help us debug this:
[  171.524099] 
[  171.524109] 1 lock held by khubd/1922:
[  171.524117]  #0:  (rtnl_mutex){--..}, at: [] 
.mutex_lock+0x3c/0x58
[  171.524155] 
[  171.524157] stack backtrace:
[  171.524165] Call Trace:
[  171.524174] [c86af130] [c000f624] .show_stack+0x70/0x1bc 
(unreliable)
[  171.524203] [c86af1e0] [c000f790] .dump_stack+0x20/0x34
[  171.524228] [c86af260] [c0070310] 
.print_circular_bug_tail+0x84/0xa8
[  171.524256] [c86af330] [c0072324] .__lock_acquire+0xa7c/0xd68
[  171.524281] [c86af420] [c00726b0] .lock_acquire+0xa0/0xe8
[  171.524307] [c86af4e0] [c0060cbc] .flush_workqueue+0x78/0xf4
[  171.524332] [c86af580] [d0498374] 
.ieee80211_stop+0x1fc/0x3a4 [mac80211]
[  171.524376] [c86af640] [c031b8bc] .dev_close+0xb8/0xfc
[  171.524401] [c86af6d0] [c031b9c0] 
.unregister_netdevice+0xc0/0x254
[  171.524425] [c86af760] [d04a828c] 
.__ieee80211_if_del+0x34/0x50 [mac80211]
[  171.524475] [c86af7f0] [d0497654] 
.ieee80211_unregister_hw+0xf8/0x2d8 [mac80211]
[  171.524522] [c86af8c0] [d045cfa8] .disconnect+0x3c/0x98 
[zd1211rw_mac80211]
[  171.524558] [c86af960] [d00ff650] 
.usb_unbind_interface+0x6c/0xcc [usbcore]
[  171.524611] [c86afa00] [c027bcdc] 
.__device_release_driver+0xcc/0x110
[  171.524635] [c86afa90] [c027c430] 
.device_release_driver+0x70/0xbc
[  171.524662] [c86afb20] [c027b270] 
.bus_remove_device+0xa0/0xcc
[  171.524687] [c86afbb0] [c02782f0] .device_del+0x2f4/0x3d4

Re: [patch-mm 00/28] High resolution timer updates and x86_64 support - V3

[Andrew Morton]

On Sat, 23 Jun 2007 13:32:25 - Thomas Gleixner <[EMAIL PROTECTED]> wrote:

> The following patch series contains:
> 
> - dyntick bugfixes for -mm (caused by the cpuidle changes in ACPI)
> 
> - updates and improvements to high resolution timer / dynticks 
> 
> - high resolution timer / dynticks support for x86_64

Blam.  http://userweb.kernel.org/~akpm/hpet-crash.jpg

time_init() is called before slab is set up.  We cannot do memory
allocations inside time_init().

> The patch set has been tested in the -hrt and -rt trees for quite a while
> and the initial problems have been sorted out. Thanks to the folks from the
> PowerTop project for testing and feedback.

hrm.  Looks like none of your testers have HPET_ID_LEGSUP hardware.  This:

--- a/arch/i386/kernel/hpet.c~a
+++ a/arch/i386/kernel/hpet.c
@@ -376,7 +376,7 @@ int __init hpet_enable(void)
 
clocksource_register(&clocksource_hpet);
 
-   if (id & HPET_ID_LEGSUP) {
+   if (0 && (id & HPET_ID_LEGSUP)) {
hpet_enable_int();
hpet_reserve_platform_timers(id);
/*
_

gets it working.  It basically nobbles the hpet and the kernel chose the
TSC clocksource instead.


btw, if you want to know why I go on and on about crappy commenting, try to
work out from the kernel source code what HPET_ID_LEGSUP is, and why it
gets special treatment.  It is not possible.  This is not maintainable
code.

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

Re: [patch-mm 00/28] High resolution timer updates and x86_64 support - V3

[Andi Kleen]

On Thursday 28 June 2007 11:42:33 Andrew Morton wrote:

> > The patch set has been tested in the -hrt and -rt trees for quite a while
> > and the initial problems have been sorted out. Thanks to the folks from the
> > PowerTop project for testing and feedback.
> 
> hrm.  Looks like none of your testers have HPET_ID_LEGSUP hardware.  

AFAIK it's only on IBM Summit. You have such a box?

> btw, if you want to know why I go on and on about crappy commenting, try to
> work out from the kernel source code what HPET_ID_LEGSUP is, and why it
> gets special treatment.  It is not possible.  This is not maintainable
> code.

We have a reference somewhere to the HPET spec.

-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 0/6][TAKE5] fallocate system call

[Andrew Morton]

On Mon, 25 Jun 2007 18:58:10 +0530 "Amit K. Arora" <[EMAIL PROTECTED]> wrote:

> N O T E: 
> ---
> 1) Only Patches 4/7 and 7/7 are NEW. Rest of them are _already_ part
>of ext4 patch queue git tree hosted by Ted.

Why the heck are replacements for these things being sent out again when
they're already in -mm and they're already in Ted's queue (from which I
need to diligently drop them each time I remerge)?

Are we all supposed to re-review the entire patchset (or at least #4 and
#7) again?

The core kernel changes are not appropriate to the ext4 tree.

For a start, the syscall numbers in Ted's queue are wrong (other new
syscalls are pending).

Patches which add syscalls are an utter PITA to carry due to all the patch
conflicts and to the relatively frequent syscall renumbering (they don't
get numbered in time-of-arrival order due to differing rates at which patches
mature).

Please drop the non-ext4 patches from the ext4 tree and send incremental
patches against the (non-ext4) fallocate patches in -mm.

And try to get the code finished?  Time is pressing.

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

Re: [AppArmor 00/44] AppArmor security module overview

[Alan Cox]

> > Anyone can apply the apparmour patch to their tree, they get the
> > choice that way.  Nobody is currently prevented from using apparmour
> > if they want to, any such suggestion is pure rubbish.
> 
> The exact same argument was made prior to SELinux going upstream.

Its made for every thing before it goes upstream. It shouldn't be going
uptream until it works, is reliable and does something useful. Then if it
ever makes that grade it can go and sit in -mm for a bit to shake down .

> > Frankly I think AppArmour is a joke,
> 
> "SELinux, AppArmor, and Hilary Clinton walk into a bar ..."


SELinux orders a beer object
AppArmor order a /beer
Hilary says "You are both under 21 you can't"
SELinux orders a shandy object
AppArmor orders a /shandy

SELinux is refused because the shandy mixer opened a beer object and
shandy inherited beer typing
AppArmor gets drunk because /shandy and /beer are clearly different


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

[Joerg Schilling]

David Woodhouse <[EMAIL PROTECTED]> wrote:

> On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote:
> > Warning: *** linux/ext2_fs.h is not usable at all ***
> > Warning: *** This makes it impossible to support Linux file flags ***
> > You may try to compile using 'make COPTX=-DTRY_EXT2_FS'
>
> Again, can you be _specific_? Amusing though your consistent 'Lunix is
> broken' chants are, the only reason I'm bothering to participate in this
> thread is on the off-chance that something _productive_ will come of it.

I have been forced to add this test as too many people reported that they
have no been able to compile star on their Linux distribution. 


> By the way, your mailer seems to be sometimes omitting In-Reply-To: and
> References: headers, which RFC2822 says you SHOULD include in replies. 

Sending such accusation without knowing the reason is not polite.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Userspace compiler support of "long long"

[Harald Arnesen]

Adrian Bunk <[EMAIL PROTECTED]> writes:

> Is there any userspace Linux compiler that does not support "long long"?
> If yes, is there any other way to tell that something is a
> 64bit int on 32bit architectures?

TenDRA C:

"test.c", line 6: Error:
  [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'.

-- 
Hilsen Harald.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Documentation/firmware_class/firmware_sample_driver.c

[Satyam Sharma]

Hi,

[ It's good that you're trying to fix this, code in documentation should
be setting standards, clearly. ]

On 6/27/07, Anders Blomdell <[EMAIL PROTECTED]> wrote:

[...]
Minor modifications to make the example load and unload without Oops
[...]
 static int sample_init(void)
 {
-   device_initialize(&ghost_device);
+   device_register(&ghost_device);
/* since there is no real hardware insertion I just call the
 * sample probe functions here */
-   sample_probe_specific();
+   /* sample_probe_specific(); */
sample_probe_default();
-   sample_probe_async();
+   /*sample_probe_async();*/
return 0;
 }


But IMO the above functions should be *fixed* to work properly instead
of simply commenting them out. If they are un-fixable, why even keep
the broken code in that file (only to mislead readers in future?). You
might as well remove those calls (and the function definitions) completely.
Best would be to fix them, of course.

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

Re: Linux Kernel include files

[David Woodhouse]

On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
> David Woodhouse <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote:
> > > Warning: *** linux/ext2_fs.h is not usable at all ***
> > > Warning: *** This makes it impossible to support Linux file flags ***
> > > You may try to compile using 'make COPTX=-DTRY_EXT2_FS'
> >
> > Again, can you be _specific_? Amusing though your consistent 'Lunix is
> > broken' chants are, the only reason I'm bothering to participate in this
> > thread is on the off-chance that something _productive_ will come of it.
> 
> I have been forced to add this test as too many people reported that they
> have no been able to compile star on their Linux distribution. 

But do you not know _why_? What exactly are you testing _for_?

Bug reports which merely say 'is broken' are not helpful.

> > By the way, your mailer seems to be sometimes omitting In-Reply-To: and
> > References: headers, which RFC2822 says you SHOULD include in replies. 
> 
> Sending such accusation without knowing the reason is not polite.

It's not an accusation -- it's merely an observation. You may not have
noticed that your mailer was misbehaving; now you _do_ know, and if you
care about RFC compliance you might want to fix it. You're not _obliged_
to fix it, of course. I just thought you'd like to know.

-- 
dwmw2

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

Re: [patch-mm 00/28] High resolution timer updates and x86_64 support - V3

[Andrew Morton]

On Thu, 28 Jun 2007 11:47:04 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:

> On Thursday 28 June 2007 11:42:33 Andrew Morton wrote:
> 
> > > The patch set has been tested in the -hrt and -rt trees for quite a while
> > > and the initial problems have been sorted out. Thanks to the folks from 
> > > the
> > > PowerTop project for testing and feedback.
> > 
> > hrm.  Looks like none of your testers have HPET_ID_LEGSUP hardware.  
> 
> AFAIK it's only on IBM Summit. You have such a box?

Intel Nocona SDV thing.  Old.

> > btw, if you want to know why I go on and on about crappy commenting, try to
> > work out from the kernel source code what HPET_ID_LEGSUP is, and why it
> > gets special treatment.  It is not possible.  This is not maintainable
> > code.
> 
> We have a reference somewhere to the HPET spec.

The HPET spec won't tell me why HPET_ID_LEGSUP hpets get a kmalloc in Linux
but the !HPET_ID_LEGSUP ones don't.

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

[Joerg Schilling]

David Woodhouse <[EMAIL PROTECTED]> wrote:

> On Thu, 2007-06-28 at 12:27 +0200, Joerg Schilling wrote:
> > David Woodhouse <[EMAIL PROTECTED]> wrote:
> > 
> > > On Wed, 2007-06-27 at 16:00 +0200, Joerg Schilling wrote:
> > > > Warning: *** linux/ext2_fs.h is not usable at all ***
> > > > Warning: *** This makes it impossible to support Linux file flags ***
> > > > You may try to compile using 'make COPTX=-DTRY_EXT2_FS'
> > >
> > > Again, can you be _specific_? Amusing though your consistent 'Lunix is
> > > broken' chants are, the only reason I'm bothering to participate in this
> > > thread is on the off-chance that something _productive_ will come of it.
> > 
> > I have been forced to add this test as too many people reported that they
> > have no been able to compile star on their Linux distribution. 
>
> But do you not know _why_? What exactly are you testing _for_?
>
> Bug reports which merely say 'is broken' are not helpful.

If you like to know what I test, I encourage you to check the autoconf
scripts. I am testing whether the named include file may be used from a 
user space program.

As I did mention already, I was forced to add the test in order to be able to
compile at all.


> > > By the way, your mailer seems to be sometimes omitting In-Reply-To: and
> > > References: headers, which RFC2822 says you SHOULD include in replies. 
> > 
> > Sending such accusation without knowing the reason is not polite.
>
> It's not an accusation -- it's merely an observation. You may not have
> noticed that your mailer was misbehaving; now you _do_ know, and if you
> care about RFC compliance you might want to fix it. You're not _obliged_
> to fix it, of course. I just thought you'd like to know.

Well there you are: my mailer is definitely NOT missbehaving.
Please do not repeat similar accusations when not knowing the reason.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2.6.22-rc6-mm1

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/

- NOTE (an uppercase one, indeed): there are a lot of menuconfig changes in
  here which break `make oldconfig' badly.  If you grab an old .config and run
  `make oldconfig', your kernel probably won't work.  I lost useful things
  like CONFIG_BLK_DEV and the whole SCSI system, because they were added after
  I generated my .config.

  So save yourself some hassle and check your .config carefully before
  building this kernel.  Make sure that everything you need is still enabled.

  I found that manually adding "CONFIG_BLK_DEV=y" to the .config before
  running oldconfig saved a large number of config items from getting lost.

  Those menuconfig changes have been a huge pain.

- Added the kgdb tree, as git-kgdb.patch (Jason Wessel
  <[EMAIL PROTECTED]>)

  This is a large patch which unifies all the various kgdb stubs lying
  around various architectures and extends kgdb support to other
  architectures.  Supported architectures are at present arm, i386, ia64,
  mips, ppc32, ppc64, sh, and x86_64.

  Subject to review, we're aiming this at 2.6.24.

- Jean's hwmon git tree was dropped and was replaced by the new
  git-hwmon.patch (Mark M.  Hoffman <[EMAIL PROTECTED]>)

- Added new git-ixgbe.patch: "10GbE driver for Intel 82598 based PCI Express
  adapters" (Ayyappan Veeraiyan <[EMAIL PROTECTED]>)

- I cannot persuade git to generate a sane diff out of git-wireless, so it
  is dropped.  Which is bad, because it contains a tremendous amount of stuff.

- Added x86_64 dynticks support

- Merged the dynamic commandline length patches - these remove Linux's
  hard-coded limit.



Boilerplate:

- See the `hot-fixes' directory for any important updates to this patchset.

- To fetch an -mm tree using git, use (for example)

  git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git 
tag v2.6.16-rc2-mm1
  git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1

- -mm kernel commit activity can be reviewed by subscribing to the
  mm-commits mailing list.

echo "subscribe mm-commits" | mail [EMAIL PROTECTED]

- If you hit a bug in -mm and it is not obvious which patch caused it, it is
  most valuable if you can perform a bisection search to identify which patch
  introduced the bug.  Instructions for this process are at

http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt

  But beware that this process takes some time (around ten rebuilds and
  reboots), so consider reporting the bug first and if we cannot immediately
  identify the faulty patch, then perform the bisection search.

- When reporting bugs, please try to Cc: the relevant maintainer and mailing
  list on any email.

- When reporting bugs in this kernel via email, please also rewrite the
  email Subject: in some manner to reflect the nature of the bug.  Some
  developers filter by Subject: when looking for messages to read.

- Occasional snapshots of the -mm lineup are uploaded to
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
  the mm-commits list.




Changes since 2.6.22-rc4-mm2:


 origin.patch
 git-acpi.patch
 git-alsa.patch
 git-arm.patch
 git-avr32.patch
 git-cifs.patch
 git-cpufreq.patch
 git-powerpc.patch
 git-drm.patch
 git-dvb.patch
 git-hwmon.patch
 git-gfs2-nmw.patch
 git-hid.patch
 git-ia64.patch
 git-ieee1394.patch
 git-infiniband.patch
 git-input.patch
 git-jfs.patch
 git-kbuild.patch
 git-kvm.patch
 git-leds.patch
 git-libata-all.patch
 git-md-accel.patch
 git-mips.patch
 git-mmc.patch
 git-ubi.patch
 git-netdev-all.patch
 git-ixgbe.patch
 git-net.patch
 git-backlight.patch
 git-battery.patch
 git-ioat.patch
 git-nfs.patch
 git-ocfs2.patch
 git-selinux.patch
 git-s390.patch
 git-scsi-misc.patch
 git-scsi-target.patch
 git-unionfs.patch
 git-watchdog.patch
 git-ipwireless_cs.patch
 git-newsetup.patch
 git-newsetup-fixup.patch
 git-xfs.patch
 git-cryptodev.patch
 git-kgdb.patch
 git-gccbug.patch

 git trees

-update-checkpatchpl-to-version-003.patch
-m68knommu-fix-coldfire-timer-off-by-1.patch
-nommu-report-correct-errno-in-message.patch
-loop-preallocate-eight-loop-devices.patch
-document-acked-by.patch
-pi-futex-fixes.patch
-update-feature-removal-scheduletxt-to-include-deprecated-functions.patch
-mount-t-tmpfs-o-mpol=-check-nodes-online.patch
-slab-fix-alien-cache-handling.patch
-potential-parse-error-in-ifdef-part-3.patch
-slub-return-zero_size_ptr-for-kmalloc0.patch
-ramfs-nommu-missed-posix-uid-gid-inode-attribute-checking.patch
-uml-fix-kernel-stack-size-on-x86_64.patch
-documentation-atomic_opstxt.patch
-move-three-functions-that-are-only-needed-for.patch
-char-stallion-dont-fail-with-less-than-max-panels.patch
-char-stallion-alloc-tty-before-pci-devices-init.patch
-char-stallion-proper-fail-return-values.patch
-frv-build-fix.patch
-uml-get-declaration-of-simple_strtoul.patch
-isdn-diva-fix-section-mismatch.patch
-checkpatch-produce-fewer-lines-of-output.patch
-

Re: Userspace compiler support of "long long"

[Joerg Schilling]

Harald Arnesen <[EMAIL PROTECTED]> wrote:

> Adrian Bunk <[EMAIL PROTECTED]> writes:
>
> > Is there any userspace Linux compiler that does not support "long long"?
> > If yes, is there any other way to tell that something is a
> > 64bit int on 32bit architectures?
>
> TenDRA C:
>
> "test.c", line 6: Error:
>   [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'.

You cannot use this compiler for any program that uses an interface that
needs long long.

BTW: C99 requires long long but the Large File summit from 1995 did to the
same since 1995. An 32 bit OS that supports large files cannot have a compiler
that does not support long long.

If TenDRA C does support 64 bit integral type in a different way. TenDRA C
would need to deliver include files that take care about this fact.

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 Kernel include files

[Joerg Schilling]

Sam Ravnborg <[EMAIL PROTECTED]> wrote:

> > gcc -c t.c
> > In file included from /usr/include/linux/ext2_fs.h:20,
> >  from t.c:2:
> > /usr/include/linux/ext2_fs_sb.h:40: error: syntax error before âuid_tâ
> > /usr/include/linux/ext2_fs_sb.h:49: error: syntax error before 
> > âs_next_generationâ
> > /usr/include/linux/ext2_fs_sb.h:51: error: syntax error before â*â token
> > /usr/include/linux/ext2_fs_sb.h:56: error: syntax error before â}â token
>
> Hi Jörg.
>
> For my test I used latest -git of the Linux kernel.
> In this version the include of ext2_fs_bh.h is guarded
> by __KERNEL__ like this:
>
> #ifdef __KERNEL__
> #include 
> static inline struct ext2_sb_info *EXT2_SB(struct super_block *sb)
> {
> return sb->s_fs_info;
> }
>

Thank you!

Jörg

-- 
 EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
   [EMAIL PROTECTED](uni)  
   [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Some NCQ numbers...

[Michael Tokarev]

[Offtopic notice: For the first time I demonstrated some
speed testing results on linux-ide mailinglist, as a
demonstration how [NT]CQ can help.  But later, someone
becomes curious and posted that email to lkml, asking
for more details.  Since that, I become more curious
as well, and decided to look at it more closely.
Here it goes...]

A test drive is Seagate Barracuda ST3250620AS "desktop" drive,
250Gb, cache size is 16Mb, 7200RPM.

The same results shows Seagate Barracuda ES drive, ST3250620NS.

I guess pretty similar results will be fore larger Barracudas from
Seagate.  The only difference between 250Gb ones and larger ones is
the amount of disk platters and heads.

Test machine was using MPTSAS driver for the following card:
  SCSI storage controller: LSI Logic / Symbios Logic SAS1064E PCI-Express 
Fusion-MPT SAS (rev 02)

Pretty similar results were obtained on an AHCI controller:
  SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) Serial ATA 
Storage Controller AHCI (rev 01)
on another machines.


The following tables shows data read/write speed in Megabytes/sec,
with different parameters.

All I/O performed directly on the whole drive, i.e.
open("/dev/sda", O_RDWR|O_DIRECT).

There are 5 kinds of tests were performed: linear read (linRd),
random read (rndRd), linear write (linWr), random write (rndWr),
and a combination of random read and write (rndR/W).

Each test has been tried with 1 (2 in case of r/w), 4 and 32 threads
doing I/O in parallel (Trd column).  Linear read and writes were
performed only for single thread.

Two modes for each test -- with command queuing enabled (qena) and
disabled (qdis), using /sys/block/sda/device/queue_depth, by setting
queue depth to 31 (default) and 1 respectively.

And finally, each set of tests were performed for different block sizes --
4, 8, 16, 32, 128 and 1024 kb (1 kb = 1024 bytes).


First, tests with write cache enabled (factory default settings for the
drives in question):

BlkSz Trd   linRd   rndRd linWr   rndWr   rndR/W
   qena qdis  qena qdis  qena qdis  qena qdis qena  qdis
   4k   1  12.8 12.8   0.3  0.3  35.4 37.0   0.5  0.5   0.2/ 0.2  0.2/ 0.2
4  0.3  0.3  0.5  0.5   0.2/ 0.2  0.2/ 0.1
   32  0.3  0.4  0.5  0.5   0.2/ 0.2  0.2/ 0.1
   8k   1  23.4 23.4   0.6  0.6  51.5 51.2   1.0  1.0   0.4/ 0.4  0.4/ 0.4
4  0.6  0.6  1.0  1.0   0.4/ 0.4  0.4/ 0.2
   32  0.6  0.8  1.0  1.0   0.4/ 0.4  0.4/ 0.2
  16k   1  41.1 40.3   1.2  1.2  67.4 67.8   2.0  2.0   0.7/ 0.7  0.7/ 0.7
4  1.2  1.1  2.0  2.0   0.7/ 0.7  0.8/ 0.4
   32  1.2  1.6  2.0  2.0   0.7/ 0.7  0.9/ 0.4
  32k   1  58.6 57.6   2.2  2.2  79.1 70.9   3.8  3.7   1.4/ 1.4  1.4/ 1.4
4  2.3  2.2  3.8  3.7   1.4/ 1.4  1.6/ 0.8
   32  2.3  3.0  3.7  3.8   1.4/ 1.4  1.7/ 0.9
  128k  1  80.4 80.4   8.1  8.0  78.7 77.3  11.6 11.6   4.5/ 4.5  4.5/ 4.5
4  8.1  8.0 11.4 11.3   4.6/ 4.6  5.5/ 2.8
   32  8.1  9.2 11.3 11.4   4.7/ 4.6  5.7/ 3.0
 1024k  1  80.4 80.4  33.9 34.0  78.2 78.3  33.6 33.6  15.9/15.9 15.9/15.9
4 34.5 34.8 33.5 33.3  16.4/16.3 17.2/11.8
   32 34.5 34.5 33.5 35.8  20.6/11.3 21.4/11.6


And second, the same drive with write caching disabled (WCE=0, hdparm -W0):

BlkSz Trd   linRd   rndRd linWr   rndWr   rndR/W
   qena qdis  qena qdis  qena qdis  qena qdis qena  qdis
   4k   1  12.8 12.8   0.3  0.3   0.4  0.5   0.3  0.3   0.2/ 0.2  0.2/ 0.2
4  0.3  0.3  0.3  0.3   0.2/ 0.2  0.2/ 0.1
   32  0.3  0.4  0.3  0.4   0.2/ 0.1  0.2/ 0.1
   8k   1  24.6 24.6   0.6  0.6   0.9  0.9   0.6  0.6   0.3/ 0.3  0.3/ 0.3
4  0.6  0.6  0.6  0.5   0.3/ 0.3  0.4/ 0.2
   32  0.6  0.8  0.6  0.8   0.3/ 0.3  0.4/ 0.2
  16k   1  41.8 41.7   1.2  1.1   1.8  1.8   1.1  1.1   0.6/ 0.6  0.6/ 0.6
4  1.2  1.1  1.1  1.0   0.6/ 0.6  0.8/ 0.4
   32  1.2  1.5  1.1  1.6   0.6/ 0.6  0.8/ 0.4
  32k   1  60.1 59.2   2.3  2.3   3.6  3.5   2.1  2.1   1.1/ 1.1  1.1/ 1.1
4  2.3  2.2  2.1  2.0   1.1/ 1.1  1.5/ 0.7
   32  2.3  2.9  2.1  3.0   1.1/ 1.1  1.5/ 0.8
 128k   1  79.4 79.4   8.1  8.1  12.4 12.6   7.2  7.1   3.8/ 3.8  3.8/ 3.8
4  8.1  7.9  7.2  7.1   3.8/ 3.8  5.2/ 2.6
   32  8.1  9.0  7.2  7.8   3.9/ 3.8  5.2/ 2.7
1024k   1  79.0 79.4  33.8 33.8  34.2 34.1  24.6 24.6  14.3/14.2 14.3/14.2
4 33.9 34.3 24.7 24.8  14.4/14.2 15.9/11.1
   32 34.0 34.3

Re: 2.6.22-rc6 on Dreamcast (SH4)

[Mike Frysinger]

On Monday 25 June 2007, Adrian McMenamin wrote:
> Still getting this:
>
>  MODPOST vmlinux
> WARNING: arch/sh/boards/dreamcast/built-in.o(.data+0x0): Section
> mismatch: reference to .init.text: (between 'mv_dreamcast' and
> 'systemasic_int')
> WARNING: drivers/built-in.o(.text+0x168e0): Section mismatch: reference
> to .init.data: (between 'pvr2fb_check_var' and 'pvr2fb_interrupt')
> WARNING: drivers/built-in.o(.text+0x1701c): Section mismatch: reference
> to .init.data: (between 'pvr2fb_pci_probe' and 'read_mem')
> WARNING: drivers/built-in.o(.text+0x17024): Section mismatch: reference
> to .init.text: (between 'pvr2fb_pci_probe' and 'read_mem')
> WARNING: drivers/built-in.o(.data+0x738): Section mismatch: reference
> to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')
> WARNING: drivers/built-in.o(.data+0x750): Section mismatch: reference
> to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')

it means there is code that is not marked as init making references 
function/data that is marked as init ... this is normally not noticed at boot 
as the init sections arent cleared/clobbered until well after boot and 
usually these are problems just for initialization routines ...

i'd review the symbols that are being warned about here to see if they're 
missing the proper section markers (aka functions that should be labeled as 
__init but arent)
-mike


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

Re: Linux Kernel include files

[Jan-Benedict Glaw]

On Thu, 2007-06-28 12:39:57 +0200, Joerg Schilling <[EMAIL PROTECTED]> wrote:
> > > > By the way, your mailer seems to be sometimes omitting In-Reply-To: and
> > > > References: headers, which RFC2822 says you SHOULD include in replies. 
> > > 
> > > Sending such accusation without knowing the reason is not polite.
> >
> > It's not an accusation -- it's merely an observation. You may not have
> > noticed that your mailer was misbehaving; now you _do_ know, and if you
> > care about RFC compliance you might want to fix it. You're not _obliged_
> > to fix it, of course. I just thought you'd like to know.
> 
> Well there you are: my mailer is definitely NOT missbehaving.
> Please do not repeat similar accusations when not knowing the reason.

Just out of interest: In which cases do you want to break threading?

MfG, JBG

-- 
  Jan-Benedict Glaw  [EMAIL PROTECTED]  +49-172-7608481
Signature of:  What we do for ourselves dies with us. What we do for
the second  : others and the world remains and is immortal. (Albert 
Pine)


signature.asc
Description: Digital signature

Re: Some NCQ numbers...

[Michael Tokarev]

Michael Tokarev wrote:
[]
> I'm planning to test several models of SCSI drives.  On SCSI front
> (or maybe with different drives - I don't know) things are WAY more
> interesting wrt TCQ.  Difference in results between 1 and 32 threads
> goes up to 4 times sometimes!.  But I'm a bit stuck with SCSI tests
> since I don't know how to turn off TCQ without rebooting a machine.

A quick followup, to demonstrate the "interesting" part.

Seagate SCSI ST3146854LC drive, 140Gb, 15KRPM, write cache disabled,
queue depth = 32:

BlkSz Trd linRd rndRd linWr rndWr  rndR/W
   4k   1  37.9   0.6   0.9   0.6   0.4/ 0.3
4 0.9 0.7   0.6/ 0.4
   32 1.5 1.1   0.9/ 0.4
   8k   1  75.2   1.2   1.9   1.1   0.8/ 0.6
4 1.7 1.5   1.1/ 0.7
   32 2.9 2.2   1.7/ 0.9
  16k   1  82.3   2.4   3.6   2.3   1.5/ 1.2
4 3.3 2.9   2.2/ 1.4
   32 5.5 4.3   3.3/ 1.7
  32k   1  86.3   4.7   6.9   4.4   2.9/ 2.3
4 6.4 5.6   4.2/ 2.7
   3210.2 8.0   6.2/ 3.1
 128k   1  86.5  15.8  26.6  14.9   9.5/ 7.7
420.618.2  13.5/ 8.5
   3229.224.8  18.3/ 9.1
1024k   1  88.6  46.7  63.1  48.2  25.3/25.3
451.751.3  33.5/21.8
   3255.957.3  37.6/19.0


Fujitsu SCSI MAX3147NC drive, same parameters:

BlkSz Trd linRd rndRd linWr rndWr  rndR/W
   4k   1  37.4   0.7   1.0   0.6   0.4/ 0.3
4 0.9 0.8   0.6/ 0.4
   32 1.5 1.2   0.9/ 0.4
   8k   1  32.9   1.3   1.9   1.2   0.7/ 0.7
4 1.8 1.5   1.2/ 0.7
   32 2.8 2.3   1.7/ 0.9
  16k   1  89.6   2.6   3.7   2.4   1.4/ 1.3
4 3.5 3.0   2.4/ 1.4
   32 5.4 4.4   3.3/ 1.7
  32k   1  87.9   4.8   7.0   4.4   2.6/ 2.6
4 6.8 5.6   4.6/ 2.7
   32 9.9 8.3   6.2/ 3.1
 128k   1  90.7  16.2  22.5  15.3   8.6/ 8.6
421.818.6  15.0/ 8.1
   3228.625.0  18.2/ 9.1
1024k   1  90.6  48.9  60.0  47.4  25.3/25.9
455.651.7  34.4/22.5
   3259.856.2  38.6/19.7

/mjt

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] PXA27x UDC driver.

[Li Yang-r58472]

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Rodolfo
Giometti
> Sent: Thursday, June 28, 2007 6:36 PM
> To: [EMAIL PROTECTED]
> Cc: linux-kernel@vger.kernel.org; Andrew Morton
> Subject: [PATCH] PXA27x UDC driver.
> 
> Hello,
> 
> attached you can find new version of my patch for PXA27x UDC driver
> support against kernel 2.6.22-rc3 (but it applies also ro rc6).
> 
> I'd like to know what I have to do in order to prepare this patch for
> kernel inclusion. It's time PXA27x has its UDC driver into linux! :)
> 
> Thanks for your suggestions,

You should probably also cc: [EMAIL PROTECTED] and
David Brownell for UDC matters.

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

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Rene Herman]

On 06/28/2007 04:28 AM, Rene Herman wrote:


On 06/28/2007 03:58 AM, Rene Herman wrote:


to figure it out. If you need to specify an ALSA device somewhere, make
sure it's not the old "hw:0" but "default" (or "default:0" for the
first card, "default:1" for the second, ...). The "hw:N" devices don't
do mixing.


Slight correction/expansion -- don't do _software_ mixing. Some cards 
can do hardware mixing and in that case, "hw:N" or, specifically 
"hw:N,0", "hw:N,1" and so on devices are available as hardware mixed 
devices.


Correcting the correction (sorry, it was late) -- "hw:N" is card N, "hw:N,M" 
is PCM interface M of card N and "hw:N,M,K" is (hardware mixed) subdevice K 
on PCM interface M of card N. Normal cards have only one PCM interface 
meaning that M is 0 in the above.


That is, I meant that "hw:N,0,0", "hw:N,0,1" and so on are the hardware 
mixed devices.


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

Re: Add INPUT support to toshiba_acpi

[Rolf Eike Beer]

Richard Hughes wrote:
> On Tue, 2007-06-26 at 07:03 +0200, Rolf Eike Beer wrote:
>> Richard Hughes wrote:
>>> On Sat, 2007-06-23 at 16:56 +0200, Rolf Eike Beer wrote:
 None of the above keys generated a key event. Neither does
 "Brightness down", but it still works. "Brightness up" generates an event
 and works.
>>
 Kpowersave tells me it can't do brightness switching in software
 (which works in WinXtraPain).
>>
>> Yes, I need a special process running for this. Would it be of some
>> use if I take a look with IRPtracker on it or is that all you need to
>> know?
>
> Yes, although this is out of my area or expertise, sorry.

I've looked a bit but can't find any driver interaction of those programs. Any 
further ideas welcome.

Eike


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

Re: [AppArmor 00/44] AppArmor security module overview

[Tilman Schmidt]

David Miller schrieb:
> What you get by the code going into the upstream kernel tree is that
> it a) adds some pseudo legitimacy to AppArmour (which I don't
> personally think is warranted) and b) gets the work of keeping
> apparmour working with upstream largely off of your back and in the
> hands of the upstream community.
> 
> Neither of those are reasons why something should go into the tree.

I beg to differ. b) is *the* reason cited again and again on LKML
for submitting code for inclusion in the tree. Whenever anyone
posts anything which is remotely related to out-of-tree code,
whether it's a question on the usage of some standard in-tree
function, a request for help with a coding or debugging problem,
or out-of-tree repercussions of an in-tree change, he or she
invariably has to put up with an answer along the lines of: "put
your code into the tree and all your problems will be solved" -
or its sarcastic variant: "I can't find your code anywhere in
the current kernel sources".

You can't have it both ways. Either you go around bashing
people for maintaining their code out-of-tree or you go around
bashing people for trying to get their code into the tree.

-- 
Tilman SchmidtE-Mail: [EMAIL PROTECTED]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)



signature.asc
Description: OpenPGP digital signature

Re: Please release a stable kernel Linux 3.0

[Helge Hafting]

Bill Waddington wrote:

(And taking my drivers main-line isn't an option.  It would be fine
with me, but there is *zero* chance that my funky code would be
welcomed into the tree.)
  

If the only merge-stopper is code quality, why not
post your driver and get some feedback?  Cleaning up code
will take some effort of course;
but once it is done, you're protected from module API changes. . .

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

Re: Userspace compiler support of "long long"

[Geert Uytterhoeven]

On Thu, 28 Jun 2007, Jan Engelhardt wrote:
> On Jun 28 2007 04:12, Geert Uytterhoeven wrote:
> >On Wed, 27 Jun 2007, Randy Dunlap wrote:
> >> On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote:
> >> > LDD3 ch. 11 says that long on Sparc64 is 32 bits.
> >> > Same for "ppc" (don't know which power* arch. they mean by that).
> >> 
> >> Hm, I suppose that table only applies to userspace, not kernel...
> >
> >32-bit userspace?
> >
> >On 64-bit, `long' is 64-bit on all platforms supported by Linux.
> 
> All types are as wide as the compiler makes them.
> 
> Compiler  short  int long llong
> Turbo C  16   16   32 -
> GCC -m32 16   32   3264
> GCC -m64 16   32   6464

We do not support building Linux with Turbo C (or MS Visual C for Win64
P64).

Gr{oetje,eeting}s,

Geert

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

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

Re: Userspace compiler support of "long long"

[David Woodhouse]

On Thu, 2007-06-28 at 13:34 +0200, Geert Uytterhoeven wrote:
> We do not support building Linux with Turbo C (or MS Visual C for
> Win64 P64). 

We're talking about types which are exposed to userspace.

-- 
dwmw2

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

Re: Userspace compiler support of "long long"

[Kyle Moffett]

On Jun 27, 2007, at 20:30:42, Andi Kleen wrote:

On Thursday 28 June 2007 00:30:52 Kyle Moffett wrote:
The only trick is if you care about building 32-bit compat code  
using 64-bit linux kernel headers.  In that case we should  
probably just make all archs use "long long" for their 64-bit  
integers, unless there's some platform I'm not remembering where  
"long long" is 128-bits or bigger.  The other benefit is that  
people could then just use the printf format "%llu" for 64-bit  
integers instead of having to conditionalize it all over the place.


I'm working on a patch now.


Changing this will give you a zillion warnings for printk formats.


Why?  If this were a problem then we'd be getting a zillion warnings  
*now* from all the 32-bit archs (which already use "long long" for 64- 
bit.  This would actually make it _easier_ to get the printk formats  
right, as you could always use %ull for 64-bit types without having  
to cast for 64-bit platforms.


This is another way to get around the "build 32-bit-compat userspace  
on 64-bit kernel headers" problem:  It tells GCC to use the  
"smallest" available type of the given size, which ends up being  
exactly the types we use now.  On the other hand, it only works for  
GCC which sort of ruins most of the reason for changing the types in  
the first place.


typedef   signed __s8  __attribute__((__mode__(__QI__)));
typedef unsigned __u8  __attribute__((__mode__(__QI__)));
typedef   signed __s16 __attribute__((__mode__(__HI__)));
typedef unsigned __u16 __attribute__((__mode__(__HI__)));
typedef   signed __s32 __attribute__((__mode__(__SI__)));
typedef unsigned __u32 __attribute__((__mode__(__SI__)));
typedef   signed __s64 __attribute__((__mode__(__DI__)));
typedef unsigned __u64 __attribute__((__mode__(__DI__)));

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: [PATCH] LinuxPPS (with new syscalls API)

[David Woodhouse]

On Thu, 2007-06-28 at 10:40 +0200, Rodolfo Giometti wrote:
> On Thu, Jun 28, 2007 at 09:31:14AM +0100, David Woodhouse wrote:
> > On Thu, 2007-06-28 at 10:15 +0200, Rodolfo Giometti wrote:
> > > Do you think I should add these functions into my patch, even if I
> > > cannot test it, or it's enought providing just the
> > > compat_sys_time_pps_fetch() function? 
> > 
> > Probably best to put them in. That way, you make it easier for people to
> 
> Mmm... so I should provide new syscalls for _all_
> architectures... gulp! :)

It's nice if you can do so, but I wouldn't suggest that you _have_ to.
I have to admit that I rarely bother actually wiring new system calls up
on anything but PowerPC to start with.

The important thing is that you've _considered_ the other architectures,
and the 32/64 compatibility implications. As long as the API of your new
system call is sensible and takes that kind of thing into account, it
should be fine.

Had you considered changing the API so that you don't need the
compatibility wrapper at all? Could you take an integer number of µS or
ms instead of a struct timespec?

-- 
dwmw2

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

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Tomasz Kłoczko]

On Wed, 27 Jun 2007, Patrick Draper wrote:


Rene Herman wrote:
So -- the fact that mixing actually works for you when using libaoss means 
software mixing is working correctly for your ALSA setup. The only thing 
you should do is _use_ ALSA (natively) and not its OSS emulation so you can 
drop the library preload.


Cool. How do I go about figuring out what every app uses? For example, you 
mentioned that the flash 9 plugin, which I also use, is an ALSA aware 
application. How do you know? I need the check out everything that I use 
which needs sound (vmware, skype, kmplayer, etc.) I don't have source code 
for at least two of those.


If can I join .. (again)
After upgrade to skype 1.4.x all sound output in skype I have only in left 
channel. Serching for skype+left+channel on google shows many people 
have this kind problem :>
ALSA does not privide application mixer settings on application level. 
Some messages on skype forums suggests some workarouds in ~/.asoudrc 
but where is documentation for this part ?

Anywhere are described ALSA diagnostics procedures/technics ?

kloczek
--
---
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
---
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Tomasz Kłoczko]

On Wed, 27 Jun 2007, Lee Revell wrote:


On 6/26/07, Andreas Hartmetz <[EMAIL PROTECTED]> wrote:
Why not put the whole sound system in userland? It has been done before. 
Sound

is just not performance critical at all and it's almost never mission
critical.


There are dozens of companies selling Linux powered professional audio
gear, multiple pro audio centric distros, and hundreds of serious free
software audio apps.  I suspect these developers and their users would
disagree.


OK .. hundreds.
Can you list ten ?
Can you point to oppinions of this people about ALSA ?

kloczek
--
---
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
---
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]

[PATCH] CONFIG_SCSI_FD_8xx no longer exists

[Geert Uytterhoeven]

CONFIG_SCSI_FD_8xx no longer exists.

Apparently it was renamed to CONFIG_SCSI_SEAGATE, but the Makefile was
not correctly updated.

Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>

diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
index b1b6327..eb92b31 100644
--- a/drivers/scsi/Makefile
+++ b/drivers/scsi/Makefile
@@ -89,7 +89,6 @@ obj-$(CONFIG_SCSI_QLA_ISCSI)  += qla4xxx/
 obj-$(CONFIG_SCSI_LPFC)+= lpfc/
 obj-$(CONFIG_SCSI_PAS16)   += pas16.o
 obj-$(CONFIG_SCSI_SEAGATE) += seagate.o
-obj-$(CONFIG_SCSI_FD_8xx)  += seagate.o
 obj-$(CONFIG_SCSI_T128)+= t128.o
 obj-$(CONFIG_SCSI_DMX3191D)+= dmx3191d.o
 obj-$(CONFIG_SCSI_DTC3280) += dtc.o

Gr{oetje,eeting}s,

Geert

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

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

Re: Userspace compiler support of "long long"

[Kyle Moffett]

On Jun 27, 2007, at 23:57:54, Matthew Wilcox wrote:

On Wed, Jun 27, 2007 at 06:30:52PM -0400, Kyle Moffett wrote:

Then all 64-bit archs have:
typedef   signed long  __s64;
typedef unsigned long  __u64;

While all 32-bit archs have:
typedef   signed long long __s64;
typedef unsigned long long __u64;


include/asm-parisc/types.h:typedef unsigned long long __u64;

For both 32 and 64-bit.

include/asm-sh64/types.h:typedef unsigned long long __u64;
include/asm-x86_64/types.h:typedef unsigned long long  __u64;

So that's three architectures that violate your first assertion.


Oh, ok, that makes it even easier to say this with certainty:   
Changing the other 64-bit archs to use "long long" for their 64-bit  
numbers will not cause additional warnings.  I'm also almost certain  
there are no architectures which use "long long" for 128-bit  
integers. (Moreover, I can't find hardly anything which does 128-bit  
integers at all).


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/

sh section mismatches [was Re: 2.6.22-rc6 on Dreamcast (SH4)]

[Satyam Sharma]

Hi,


On Monday 25 June 2007, Adrian McMenamin wrote:
> Still getting this:
>
>  MODPOST vmlinux
> WARNING: arch/sh/boards/dreamcast/built-in.o(.data+0x0): Section
> mismatch: reference to .init.text: (between 'mv_dreamcast' and
> 'systemasic_int')


I had sent a patch for this earlier ... Adrian, did you try (build + boot +
testrun) with it? Does this one go away (and system executes fine)?

[ http://lkml.org/lkml/diff/2007/6/23/116/1 ]

[ This has to do with __init functions calling __initmv functions in a
zillion files in arch/sh/boards/.../setup.c which is problematic when
__initmv is not __init itself (!SH_GENERIC && !SH_UNKNOWN) ]


> WARNING: drivers/built-in.o(.text+0x168e0): Section mismatch: reference
> to .init.data: (between 'pvr2fb_check_var' and 'pvr2fb_interrupt')
> WARNING: drivers/built-in.o(.text+0x1701c): Section mismatch: reference
> to .init.data: (between 'pvr2fb_pci_probe' and 'read_mem')
> WARNING: drivers/built-in.o(.text+0x17024): Section mismatch: reference
> to .init.text: (between 'pvr2fb_pci_probe' and 'read_mem')
> WARNING: drivers/built-in.o(.data+0x738): Section mismatch: reference
> to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')
> WARNING: drivers/built-in.o(.data+0x750): Section mismatch: reference
> to .init.text: (between 'board_list' and 'pvr2fb_pci_driver')


drivers/video/pvr2fb.c is a mess with __init, __initdata, __devinit and
__devinitdata (__exit and __devexit variants for good measure) all being
used and referencing each other freely ... I have no idea what function
should actually be what. Sam normally knows about such things,
adding him to Cc: list.

On 6/28/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:

it means there is code that is not marked as init making references
function/data that is marked as init ...


These warnings are most likely bogus (still good to get rid of them,
of course).

BTW, in include/asm-sh/machvec_init.h, __initmv is:

__attribute__((__section__(".machvec.init"))) /* .machvec.init */

But from arch/sh/kernel/vmlinux.ld.S the name of the section is:

__machvec_start = .;
.init.machvec : { *(.init.machvec) }/* .init.machvec */
__machvec_end = .;

Am I obtuse, or is there something weird about this?

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

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Gabriel C]

Tomasz Kłoczko wrote:

On Wed, 27 Jun 2007, Patrick Draper wrote:

  

Rene Herman wrote:

So -- the fact that mixing actually works for you when using libaoss means 
software mixing is working correctly for your ALSA setup. The only thing 
you should do is _use_ ALSA (natively) and not its OSS emulation so you can 
drop the library preload.
  
Cool. How do I go about figuring out what every app uses? For example, you 
mentioned that the flash 9 plugin, which I also use, is an ALSA aware 
application. How do you know? I need the check out everything that I use 
which needs sound (vmware, skype, kmplayer, etc.) I don't have source code 
for at least two of those.



If can I join .. (again)
  

Heh =)

ALSA does not privide application mixer settings on application level. 
Some messages on skype forums suggests some workarouds in ~/.asoudrc 
but where is documentation for this part ?
  

You may want to read this one:

http://www.alsa-project.org/alsa-doc/doc-php/asoundrc.php


Anywhere are described ALSA diagnostics procedures/technics ?

kloczek
  


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

Re: 2.6.22-rc6-mm1

[Gabriel C]

Andrew Morton wrote:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc6/2.6.22-rc6-mm1/

  


Compile error here.

...

Kernel: arch/i386/boot/bzImage is ready (#1)
ERROR: "check_signature" [drivers/input/misc/wistron_btns.ko] undefined!
ERROR: "check_signature" [drivers/block/xd.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2


...

http://frugalware.org/~crazy/other/kernel/config


Regards,

Gabriel C

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

Re: Userspace compiler support of "long long"

[Jakub Jelinek]

On Thu, Jun 28, 2007 at 07:53:51AM -0400, Kyle Moffett wrote:
> On Jun 27, 2007, at 23:57:54, Matthew Wilcox wrote:
> >On Wed, Jun 27, 2007 at 06:30:52PM -0400, Kyle Moffett wrote:
> >>Then all 64-bit archs have:
> >>typedef   signed long  __s64;
> >>typedef unsigned long  __u64;
> >>
> >>While all 32-bit archs have:
> >>typedef   signed long long __s64;
> >>typedef unsigned long long __u64;
> >
> >include/asm-parisc/types.h:typedef unsigned long long __u64;
> >
> >For both 32 and 64-bit.
> >
> >include/asm-sh64/types.h:typedef unsigned long long __u64;
> >include/asm-x86_64/types.h:typedef unsigned long long  __u64;
> >
> >So that's three architectures that violate your first assertion.
> 
> Oh, ok, that makes it even easier to say this with certainty:   
> Changing the other 64-bit archs to use "long long" for their 64-bit  
> numbers will not cause additional warnings.  I'm also almost certain  
> there are no architectures which use "long long" for 128-bit  
> integers. (Moreover, I can't find hardly anything which does 128-bit  
> integers at all).

unsigned long and unsigned long long have the same size, precision
and alignment on all LP64 arches, that's true.  But they have
different ranks and more importantly they mangle differently in C++.
So, whether some user exposed type uses unsigned long or unsigned long long
is part of the ABI, whether that's size_t, uintptr_t, uint64_t, u_int64_t
or any other type, you can't change it without breaking the ABI.

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

Re: Userspace compiler support of "long long"

[Kyle Moffett]

On Jun 28, 2007, at 06:26:06, Harald Arnesen wrote:

Adrian Bunk <[EMAIL PROTECTED]> writes:
Is there any userspace Linux compiler that does not support "long  
long"?  If yes, is there any other way to tell that something is a  
64bit int on 32bit architectures?


TenDRA C:

"test.c", line 6: Error:
  [ISO 6.5.2]: Illegal type specifier, 'long long', assuming 'long'.


I can't even find the docs for their "tcc".  Their "tchk" appears to  
have a "#pragma longlong type allow" or something, so I'd imagine the  
same exists for tcc and would be required to build stuff using kernel  
headers.  On the other hand, their compiler looks so immature that it  
does not appear to be worth spending much time worrying about now.   
When somebody shows up with a solution for that compiler then we can  
look at it at that time.


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: [PATCH 1/7] ICH Force HPET: Make generic time capable of switching broadcast timer

[James Morris]

On Thu, 28 Jun 2007, Andrew Morton wrote:

Sorry, we should have discovered this before you.


> (Shouldn't this be in /proc/sys/vm?)

Probably.

> My fix:

This should work.

(We have some code to allow things like this to be added without needing 
new policy, but it's too late for this case).




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

Re: Userspace compiler support of "long long"

[Kyle Moffett]

On Jun 28, 2007, at 08:08:03, Jakub Jelinek wrote:

On Thu, Jun 28, 2007 at 07:53:51AM -0400, Kyle Moffett wrote:
Oh, ok, that makes it even easier to say this with certainty:  
Changing the other 64-bit archs to use "long long" for their 64- 
bit numbers will not cause additional warnings.  I'm also almost  
certain there are no architectures which use "long long" for 128- 
bit integers. (Moreover, I can't find hardly anything which does  
128-bit integers at all).


unsigned long and unsigned long long have the same size, precision  
and alignment on all LP64 arches, that's true.  But they have  
different ranks and more importantly they mangle differently in C+ 
+.  So, whether some user exposed type uses unsigned long or  
unsigned long long is part of the ABI, whether that's size_t,  
uintptr_t, uint64_t, u_int64_t or any other type, you can't change  
it without breaking the ABI.


That sounds *extraordinarily* broken.  Hopefully this would *not*  
affect the type of a function which is passed a C "struct" containing  
the "long long", right?


Hmm, I guess the question is:  Do we support people directly passing  
__u64 to C++ functions in userspace?  I could understand, perhaps,  
passing around structures defined in the kernel headers, but  
certainly not the kernel-internal types.  The only reason we even  
export those is so we can have a private set of bit-size-defined  
types with which to define kernel ABI structures.


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: Userspace compiler support of "long long"

[Kyle Moffett]

On Jun 28, 2007, at 07:36:14, David Woodhouse wrote:

On Thu, 2007-06-28 at 13:34 +0200, Geert Uytterhoeven wrote:
We do not support building Linux with Turbo C (or MS Visual C for  
Win64 P64).


We're talking about types which are exposed to userspace.


Yes, and all 64-bit software built using kernel headers must be built  
in LP64 mode, anything else is pure insanity.  On LP64 (IE: how the  
kernel itself is compiled on EVERY 64-bit arch):


char == 8 bits
short == 16 bits
int == 32 bits
long == 64 bits
pointer == 64 bits
long long == 64 bits

On LP32 (IE: how the kernel itself is compiled on EVERY 32-bit arch):

char == 8 bits
short == 16 bits
int == 32 bits
long == 32 bits
pointer == 32 bits
long long == 64 bits

Ergo we can simply require that if you want to use kernel headers you  
must be using the same mode as the kernel is compiled in (LP32 or LP64).


The simplest guaranteed-not-to-break way to do this on _every_  
supported platform is:

typedef   signed char  __s8;
typedef unsigned char  __s8;
typedef   signed short __s16;
typedef unsigned short __s16;
typedef   signed int   __s32;
typedef unsigned int   __s32;
# if __STDC_VERSION__ >= 19901L
typedef   signed long long __s64;
typedef unsigned long long __s64;
# elif defined(__GNUC__)
__extension__ typedef   signed long long __s64;
__extension__ typedef unsigned long long __s64;
# endif

If you have some other compiler that works under linux *AND* supports  
a 64-bit type in non-C99-mode (whether "long long" or something  
else), then they are welcome to submit patches to fix it.


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: [RFC] fsblock

[Chris Mason]

On Thu, Jun 28, 2007 at 04:44:43AM +0200, Nick Piggin wrote:
> On Thu, Jun 28, 2007 at 08:35:48AM +1000, David Chinner wrote:
> > On Wed, Jun 27, 2007 at 07:50:56AM -0400, Chris Mason wrote:
> > > Lets look at a typical example of how IO actually gets done today,
> > > starting with sys_write():
> > > 
> > > sys_write(file, buffer, 1MB)
> > > for each page:
> > > prepare_write()
> > >   allocate contiguous chunks of disk
> > > attach buffers
> > > copy_from_user()
> > > commit_write()
> > > dirty buffers
> > > 
> > > pdflush:
> > > writepages()
> > > find pages with contiguous chunks of disk
> > >   build and submit large bios
> > > 
> > > So, we replace prepare_write and commit_write with an extent based api,
> > > but we keep the dirty each buffer part.  writepages has to turn that
> > > back into extents (bio sized), and the result is completely full of dark
> > > dark corner cases.
> 
> That's true but I don't think an extent data structure means we can
> become too far divorced from the pagecache or the native block size
> -- what will end up happening is that often we'll need "stuff" to map
> between all those as well, even if it is only at IO-time.

I think the fundamental difference is that fsblock still does:
mapping_info = page->something, where something is attached on a per
page basis.  What we really want is mapping_info = lookup_mapping(page),
where that function goes and finds something stored on a per extent
basis, with extra bits for tracking dirty and locked state.

Ideally, in at least some of the cases the dirty and locked state could
be at an extent granularity (streaming IO) instead of the block
granularity (random IO).

In my little brain, even block based filesystems should be able to take
advantage of this...but such things are always easier to believe in
before the coding starts.

> 
> But the point is taken, and I do believe that at least for APIs, extent
> based seems like the best way to go. And that should allow fsblock to
> be replaced or augmented in future without _too_ much pain.
> 
>  
> > Yup - I've been on the painful end of those dark corner cases several
> > times in the last few months.
> > 
> > It's also worth pointing out that mpage_readpages() already works on
> > an extent basis - it overloads bufferheads to provide a "map_bh" that
> > can point to a range of blocks in the same state. The code then iterates
> > the map_bh range a page at a time building bios (i.e. not even using
> > buffer heads) from that map..
> 
> One issue I have with the current nobh and mpage stuff is that it
> requires multiple calls into get_block (first to prepare write, then
> to writepage), it doesn't allow filesystems to attach resources
> required for writeout at prepare_write time, and it doesn't play nicely
> with buffers in general. (not to mention that nobh error handling is
> buggy).
> 
> I haven't done any mpage-like code for fsblocks yet, but I think they
> wouldn't be too much trouble, and wouldn't have any of the above
> problems...

Could be, but the fundamental issue of sometimes pages have mappings
attached and sometimes they don't is still there.  The window is
smaller, but non-zero.

-chris

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

Re: Add INPUT support to toshiba_acpi

[Renato S. Yamane]

Rolf Eike Beer wrote:

Richard Hughes wrote:

Yes, although this is out of my area or expertise, sorry.


I've looked a bit but can't find any driver interaction of those programs. Any 
further ideas welcome.


Do you try omnibook driver?
svn export https://svn.sourceforge.net/svnroot/omnibook/omnibook/trunk

toshiba_acpi don't work on my Toshiba M45-S355 (Toshiba BIOS) and I try 
this module above and now I can change brightness writing in 
/proc/omnibook/lcd and kpowersave can change brightness too.


But, is impossible use multimedia keys (play, pause, browser, etc) and 
couple keys (fn-fx), because Fn key and Multimedia keys don't is recognized.


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

speedstep-centrino (no such device)

[Renato S. Yamane]

Hi,

Is impossible use speedstep in my Laptop with Pentium M 1,86Ghz:

#modprobe speedstep-centrino
FATAL: Error inserting speedstep_centrino 
(/lib/modules/2.6.18-3-686/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko): 
No such device


To do that (speedstep), I need install powersaved, but 
speedstep-centrino is not used.


More information can see in:


Regards,
Renato
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 0/6] Convert all tasklets to workqueues

[Steven Rostedt]

Hi Dan,

On Mon, 25 Jun 2007, Dan Williams wrote:

> Yes you are right, ARM does not flush L1 when prev==next in switch_mm.
>
> > Perhaps something else is at fault here.
> >
> I'll try and dig a bit deeper...

BTW:

 static int __init iop_adma_init (void)
 {
+   iop_adma_workqueue = create_workqueue("iop-adma");
+   if (!iop_adma_workqueue)
+   return -ENODEV;
+

Could you also try upping the prio of all the "iop-adma" threads?

You should see thread names such as (on SMP) "iop-adma/0", "iop-adma/1"
... "iop-adma/N" where N = # of CPUs - 1.

do a "chrt -p -f 98 "  once for each of the thread's PIDs.  The
chrt can be found in the package "util-linux" on Red Hat / Fedora, and in
schedutils on Debian.

It just dawned on me that workqueues don't run at a high priority by
default.  So it's funny that I'm running all my current tasklets as a low
priority work queues :-)

But that can certainly be a cause of high latency.  I need to update my
patches to make the workqueue thread a higher priority. All benchmarks on
this patch have been using a low priority work queue.

I also don't see any nice API to have the priority set for a workqueue
thread from within the kernel. Looks like one needs to be added,
otherwise, I need to have the wrapper dig into the workqueue structs to
find the thread that handles the workqueue.

Thanks,

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

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Rene Herman]

On 06/28/2007 05:04 AM, Patrick Draper wrote:


Rene Herman wrote:


So -- the fact that mixing actually works for you when using libaoss 
means software mixing is working correctly for your ALSA setup. The 
only thing you should do is _use_ ALSA (natively) and not its OSS 
emulation so you can drop the library preload.


Cool. How do I go about figuring out what every app uses? For example, 
you mentioned that the flash 9 plugin, which I also use, is an ALSA 
aware application. How do you know?


Various methods. If all's well, the application has a config menu where you 
can look at and change the settings.


Or, running ldd on the binary to see if it's linked to libasound, "grep 
/proc//maps libasound" (also catches dlopen), "strace" or usually 
easiest and what I tended to do -- "lsmod" to see if starting the app 
triggered the automatic loading of snd-pcm-oss and snd-mixer-oss which I 
don't normally have loaded.


This is the "[things are still not great] partly _due_ to people maintaining 
OSS is somehow a valid choice on Linux" that I stated early in this thread. 
I actually believe the kernel space OSS emulation has been fairly counter 
productive -- it's allowed applications to stay with an obsolete interface 
since the users didn't even have to _know_ due to it all just working. At 
least with the userspace emulation, people know they are using an OSS 
emulation if they are starting the application with an library preload.


The kernel space emulation is a bit more bullet-proof in the sense that the 
userspace emulation would not for example help with applications that use 
direct syscalls to open device nodes and I guess that was important.


When OSS/Free was replaced with ALSA inside the Linux kernel this was a big 
change in an area most users use and any such change inevitably opens up big 
cans of change resistant wankers who understand the old interface and have 
no need for the new one and will tell you that you did it all wrong, it was 
all for nothing and you suck period. They'll keep it up for years and years 
generally. The kernel-space OSS emulation _does_ mostly just work, which is 
the kind of thing that you need in this environment to be allowed to tell 
these people to go sexually entertain themselves.


Perhaps it's now finally coming to the time where the kernel space emulation 
can be deprecated and eventually removed. Or not...



I need the check out everything that I use which needs sound (vmware,
skype, kmplayer, etc.) I don't have source code for at least two of
those.


I don't know if vmware by now supports native ALSA but it didn't use to. The 
current version of skype (1.4, still called a beta it seems) does.


kmplayer seems to be a frontend for various mediaplayer solutions. Don't you 
just love that mess? Its backends include MPlayer and Xine, and both these 
can talk native ALSA fine at least. For mplayer, use a "ao=alsa" line in the 
.mplayer/config file (or just start it with -ao alsa) and for xine, look in 
its setup menu (audio tab, having set the interface level to beter than 
"beginner").


Rene.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 00/44] AppArmor security module overview

[Adrian Bunk]

On Thu, Jun 28, 2007 at 01:27:12PM +0200, Tilman Schmidt wrote:
> David Miller schrieb:
> > What you get by the code going into the upstream kernel tree is that
> > it a) adds some pseudo legitimacy to AppArmour (which I don't
> > personally think is warranted) and b) gets the work of keeping
> > apparmour working with upstream largely off of your back and in the
> > hands of the upstream community.
> > 
> > Neither of those are reasons why something should go into the tree.
> 
> I beg to differ. b) is *the* reason cited again and again on LKML
> for submitting code for inclusion in the tree. Whenever anyone
> posts anything which is remotely related to out-of-tree code,
> whether it's a question on the usage of some standard in-tree
> function, a request for help with a coding or debugging problem,
> or out-of-tree repercussions of an in-tree change, he or she
> invariably has to put up with an answer along the lines of: "put
> your code into the tree and all your problems will be solved" -
> or its sarcastic variant: "I can't find your code anywhere in
> the current kernel sources".
> 
> You can't have it both ways. Either you go around bashing
> people for maintaining their code out-of-tree or you go around
> bashing people for trying to get their code into the tree.

You have a point.

But:
Code in the kernel must fulfill some (not completely fixed) quality 
criteria. It wouldn't be good to blindly include every bit of GPL'ed 
kernel code available anywhere in the Internet.

As an example, it's highly unlikely that some external device driver 
will be accepted without the author/maintainer doing some changes for 
getting it included.

If [1] AppArmor is considered to be generally insecure or in all 
respects inferior to SELinux it doesn't belong into the kernel.

Being blessed with some of the holy penguin pee by being included in the 
kernel is considered by many users as a quality criteria.

Sure, this contradicts a bit the "get your code upstream" mantra, but 
these are two conflicting goals and there's therefore no ideal solution.

If [1] AppArmor is offering required functionality not available through 
SELinux and it's considered a correct and secure solution for these 
purposes it should go into the kernel. Otherwise, it should not go into 
the kernel.

cu
Adrian

[1] note the "if"

-- 

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

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

Re: [PATCH 1/7] ICH Force HPET: Make generic time capable of switching broadcast timer

[Eric Paris]

On Thu, 2007-06-28 at 01:27 -0700, Andrew Morton wrote:
> On Thu, 28 Jun 2007 00:12:21 -0700 Andrew Morton <[EMAIL PROTECTED]> wrote:
> 
> > I can't start the X server any more, but that's probably unrelated ;)
> > 
> >  > me hopelessly outnumbered>
> 
> And the winner of the u-o-akpm-1-hour-of-his-life-back award (and the bonus
> u-delayed-next-mm-by-a-day award!) is   git-selinux.patch!
> 
> (II) Loading /usr/lib/xorg/modules/libvgahw.so
> (II) Module vgahw: vendor="X.Org Foundation"
> compiled for 7.0.0, module version = 0.1.0
> ABI class: X.Org Video Driver, version 0.8
> (**) I810(0): Depth 24, (--) framebuffer bpp 32
> (==) I810(0): RGB weight 888
> (==) I810(0): Default visual is TrueColor
> (II) Loading sub module "int10"
> (II) LoadModule: "int10"
> (II) Reloading /usr/lib/xorg/modules/libint10.so
> (II) I810(0): initializing int10
> (EE) I810(0): Cannot shmat() low memory
> (EE) I810(0): shmat(low_mem) error: Invalid argument
> (EE) I810(0): VBE initialization failed.

It has been found and the policy people already know about it.  I'm not
sure what the upstream status of the fixed policy is should appear soon.
(I also talked with the X people and apparently this is unfixable on
i686.  ajax posted about this on the original thread)

There is another bug however which I have a patch but haven't tested
much, I'll try to get it out today.  If you use a hint > 0 but <
mmap_min_addr without map fixed you will likely be denied.  Simple fix,
change hints up to mmap_min_addr if they are too low.

-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: Is it time for remove (crap) ALSA from kernel tree ?

[Rene Herman]

On 06/28/2007 01:50 PM, Tomasz Kłoczko wrote:


If can I join .. (again)


Welcome...

After upgrade to skype 1.4.x all sound output in skype I have only in 
left channel. Serching for skype+left+channel on google shows many 
people have this kind problem :>


This would seem to be a (fairly, it's no doubt just outputting mono) skype 
specific problem and given that skype is a proprietary closed source 
application, you now get to go suck on a Skype support engineer! Hurrah!


Or this might be helpful:

http://forum.skype.com/lofiversion/index.php/t85880.html

No, no idea why skype would require you to do this yourself. Maybe you 
should ask them. This is now _really_ no longer a kernel issue though.


Rene.

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

Is it time for remove (crap) ALSA from kernel tree ?

[Anton Petrusevich]

>>I don't like random applications blocking my sound card. 
>So don't use random applications.
 
I have ICE1724, a very good sound card to my taste, works like a charm. But 
with ALSA I had a really hard time to configure it properly, wanna see 
my .asoundrc? And I am not sure I have done it right (== the best possible 
way). I have read everything on http://www.alsa-project.org/documentation.php 
about .asoundrc. When I am using Skype I have to rename .asoundrc to 
something else in order to get it working. When I am doing some changes 
to .asoundrc I have to restart the app. Is there a tool which can be used to 
configure .asoundrc? I want to be able to hear sound from flashplayer on my 
reciever or in my headphones -- how? It's not quite clear to me how to get 
full duplex working with my .asoundrc.
-- 
Anton Petrusevich
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: speedstep-centrino (no such device)

[jimmy bahuleyan]

Renato S. Yamane wrote:
> Hi,
> 
> Is impossible use speedstep in my Laptop with Pentium M 1,86Ghz:
> 
> #modprobe speedstep-centrino
> FATAL: Error inserting speedstep_centrino
> (/lib/modules/2.6.18-3-686/kernel/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.ko):
> No such device
> 
> To do that (speedstep), I need install powersaved, but
> speedstep-centrino is not used.
> 
> More information can see in:
> 
> 
> Regards,
> Renato

did you try with the latest kernel (it works on my PentiumM and kubuntu)
or is this a ubuntu specific bug?


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

Re: Is it time for remove (crap) ALSA from kernel tree ?

[Meelis Roos]

Our developers chose ALSA over OSS as the sound API for a VOIP-like
fullduplex application and one of the reasons was API - OSS mixer API
was not flexible enough (something to do with separating muting and
volume control IIRC).

-- 
Meelis Roos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] SELinux: make mmap hint addresses greater than mmap_min_addr

[Eric Paris]

The new protection to keep users from writing to the first couple of
pages of virtual memory also is stopping mmap operations which are only
giving a hint address greater than 0 but less than mmap_min_addr.  This
patch should take the address given to mmap and move it up to
mmap_min_addr thus eliminating the security denial.

--

Testing on this patch resulted in expected results.  With my
mmap_min_addr set to 40960

About to MAP_FIXED addr:40960
Works.
About to MAP_FIXED addr:32768
mmap: Permission denied

So MAP_FXIED operations were getting denied.

About to mmap with hint addr:40960
Works.
About to mmap with hint addr:32768
Requested addr:32768 but got addr:40960

So given a low hint address we just got 40960

About to mmap with hint addr:4096
Requested addr:4096 but got addr:40960
About to mmap with hint addr:8192
Requested addr:8192 but got addr:3086798848

Here I didn't munmap between each mmap call.  In this case 4096 hint got
bumped to 40960 (mmap_min_addr) and worked fine.  A new hint, 8192 also
got bumped to 40960 but the kernel found it couldn't use that and
instead found a whole new open memory area.  Appears to be working as
expected.

 mm/mmap.c  |7 +++
 mm/nommu.c |7 +++
 2 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/mm/mmap.c b/mm/mmap.c
index bce4995..ecd1dcc 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -916,6 +916,13 @@ unsigned long do_mmap_pgoff(struct file * file, unsigned 
long addr,
if (!len)
return -EINVAL;
 
+   /*
+* If a hint addr is less than mmap_min_addr change addr to be as
+* low as possible but still greater than mmap_min_addr
+*/
+   if (!(flags & MAP_FIXED) && (addr != NULL) && (addr < mmap_min_addr))
+   addr = (mmap_min_addr + ~PAGE_MASK) & PAGE_MASK;
+
error = arch_mmap_check(addr, len, flags);
if (error)
return error;
diff --git a/mm/nommu.c b/mm/nommu.c
index 989e2e9..6c13728 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -805,6 +805,13 @@ unsigned long do_mmap_pgoff(struct file *file,
void *result;
int ret;
 
+   /*
+   * If a hint addr is less than mmap_min_addr change addr to be as
+   * low as possible, but still greater than mmap_min_addr
+   */
+   if (!(flags & MAP_FIXED) && (addr != NULL) && (addr < mmap_min_addr))
+   addr = (mmap_min_addr + ~PAGE_MASK) & PAGE_MASK;
+
/* decide whether we should attempt the mapping, and if so what sort of
 * mapping */
ret = validate_mmap_request(file, addr, len, prot, flags, pgoff,


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

[Rusty Russell]

On Wed, 2007-06-27 at 19:14 -0500, Matt Mackall wrote:
> lguest: unhandled trap 14 at 0xc01362f7 (0x0)
> Dump of assembler code for function __lock_acquire:

Thanks for the bug report Matt!  I wonder if other
paravirt_disable_iospace users have the same issue...
===

Fix "lguest: unhandled trap 14 at 0xc013630f (0x0)" with CONFIG_LOCKDEP=y

paravirt_disable_iospace -> request_resource -> write_lock -> __lock_acquire()

lockdep_init() is already idempotent: simply call it before
paravirt_disable_iospace().

Signed-off-by: Rusty Russell <[EMAIL PROTECTED]>

diff -r bea2b8147985 drivers/lguest/lguest.c
--- a/drivers/lguest/lguest.c   Thu Jun 07 22:50:36 2007 +1000
+++ b/drivers/lguest/lguest.c   Thu Jun 28 23:21:26 2007 +1000
@@ -593,6 +593,8 @@ __init void lguest_init(void *boot)
 
reserve_top_address(lguest_data.reserve_mem);
 
+   lockdep_init();
+
paravirt_disable_iospace();
 
cpu_detect(&new_cpu_data);


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

Re: implement-file-posix-capabilities.patch

[Serge E. Hallyn]

Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Serge E. Hallyn wrote:
> >> Does that explain it?
> > 
> > Yes, thanks, but then it still could come in handy to have fE be a full
> > bitset, so the application gets some eff caps automatically, while
> > others it has to manually set...
> 
> [We touched on this a number of emails back.]
> 
> If an application is capability aware, it can manipulate its own
> capabilities and should have fE=0.
> 
> If an application is not capability aware, it needs to have *all* of its
> capabilities enabled at exec() time. Otherwise, it won't work.
> 
> The only reason for having an fE bitmap is to allow a capability-aware
> program (you really trust to do its privileged operations carefully) to
> be lazy and get some of its capabilities raised for free. Perhaps you
> can clarify why this is a desirable thing? :-)

Sure - because it doesn't hurt anything, someone just *might* find it
useful one day, and mostly the three bitmaps just look a lot cleaner to
me than hiding a bit inside the version field.  There are a *few* people
using this, and so a complete switch in format for no actual net gain
seems wrong.  If we want to fake fE to the user as being one bit we can
do that through the setfcaps/getfcaps programs.

There also are prior examples of doing it this way (i.e. Olaf Dietsche's
implementation)

OTOH I don't deny implementing it fully as you describe seems to make
the intent of the code clearer to readers and maintainers.

I guess maybe I'll give it a go and see what turns out.

thanks,
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 -mm] Make check_signature() depend on CONFIG_HAS_IOMEM

[Heiko Carstens]

From: Heiko Carstens <[EMAIL PROTECTED]>

check_signature() uses readb() and therefore should only be build on
CONFIG_HAS_IOMEM.

Otherwise breaks s390:
lib/check_signature.c: In function `check_signature':
lib/check_signature.c:19: error: implicit declaration of function `readb'

Cc: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
---
 lib/Makefile |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

Index: linux-2.6.22-rc6-mm1/lib/Makefile
===
--- linux-2.6.22-rc6-mm1.orig/lib/Makefile
+++ linux-2.6.22-rc6-mm1/lib/Makefile
@@ -5,8 +5,7 @@
 lib-y := ctype.o string.o vsprintf.o cmdline.o \
 rbtree.o radix-tree.o dump_stack.o \
 idr.o int_sqrt.o bitmap.o extable.o prio_tree.o \
-sha1.o irq_regs.o reciprocal_div.o argv_split.o \
-check_signature.o
+sha1.o irq_regs.o reciprocal_div.o argv_split.o
 
 lib-$(CONFIG_MMU) += ioremap.o pagewalk.o
 lib-$(CONFIG_SMP) += cpumask.o
@@ -22,7 +21,7 @@ CFLAGS_kobject_uevent.o += -DDEBUG
 endif
 
 obj-$(CONFIG_GENERIC_IOMAP) += iomap.o
-obj-$(CONFIG_HAS_IOMEM) += iomap_copy.o devres.o
+obj-$(CONFIG_HAS_IOMEM) += iomap_copy.o devres.o check_signature.o
 obj-$(CONFIG_DEBUG_LOCKING_API_SELFTESTS) += locking-selftest.o
 obj-$(CONFIG_DEBUG_SPINLOCK) += spinlock_debug.o
 lib-$(CONFIG_RWSEM_GENERIC_SPINLOCK) += rwsem-spinlock.o
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 -mm] s390: struct bin_attribute changes

[Heiko Carstens]

From: Heiko Carstens <[EMAIL PROTECTED]>

git-acpi contains a patch that adds 'struct bin_attribute *' to
the read method of struct bin_attribute. This breaks s390:

  CC  arch/s390/kernel/ipl.o
arch/s390/kernel/ipl.c:317:
 warning: initialization from incompatible pointer type
arch/s390/kernel/ipl.c:340:
  warning: initialization from incompatible pointer type

Cc: Zhang Rui <[EMAIL PROTECTED]>
Cc: Greg KH <[EMAIL PROTECTED]>
Cc: Len Brown <[EMAIL PROTECTED]>
Cc: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
---
 arch/s390/kernel/ipl.c |   10 ++
 1 files changed, 6 insertions(+), 4 deletions(-)

Index: linux-2.6.22-rc6-mm1/arch/s390/kernel/ipl.c
===
--- linux-2.6.22-rc6-mm1.orig/arch/s390/kernel/ipl.c
+++ linux-2.6.22-rc6-mm1/arch/s390/kernel/ipl.c
@@ -295,8 +295,9 @@ static ssize_t sys_ipl_device_show(struc
 static struct subsys_attribute sys_ipl_device_attr =
__ATTR(device, S_IRUGO, sys_ipl_device_show, NULL);
 
-static ssize_t ipl_parameter_read(struct kobject *kobj, char *buf, loff_t off,
- size_t count)
+static ssize_t ipl_parameter_read(struct kobject *kobj,
+ struct bin_attribute *attr,
+ char *buf, loff_t off, size_t count)
 {
unsigned int size = IPL_PARMBLOCK_SIZE;
 
@@ -317,8 +318,9 @@ static struct bin_attribute ipl_paramete
.read = &ipl_parameter_read,
 };
 
-static ssize_t ipl_scp_data_read(struct kobject *kobj, char *buf, loff_t off,
-   size_t count)
+static ssize_t ipl_scp_data_read(struct kobject *kobj,
+struct bin_attribute *attr,
+char *buf, loff_t off, size_t count)
 {
unsigned int size = IPL_PARMBLOCK_START->ipl_info.fcp.scp_data_len;
void *scp_data = &IPL_PARMBLOCK_START->ipl_info.fcp.scp_data;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 -mm] s390: rename CPU_IDLE to S390_CPU_IDLE

[Heiko Carstens]

From: Heiko Carstens <[EMAIL PROTECTED]>

sched-cfs-v2.6.22-git-v18.patch introduces CPU_IDLE in sched.h.
This conflict with the already existing define in
include/asm-s390/processor.h
Just rename the s390 defines, since they will go away as soon as
we support CONFIG_NO_HZ instead of our own CONFIG_NO_IDLE_HZ.

Cc: Ingo Molnar <[EMAIL PROTECTED]>
Cc: Martin Schwidefsky <[EMAIL PROTECTED]>
Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]>
---
 arch/s390/kernel/process.c   |6 +++---
 arch/s390/kernel/time.c  |4 ++--
 arch/s390/kernel/vtime.c |4 ++--
 include/asm-s390/processor.h |4 ++--
 4 files changed, 9 insertions(+), 9 deletions(-)

Index: linux-2.6.22-rc6-mm1/arch/s390/kernel/process.c
===
--- linux-2.6.22-rc6-mm1.orig/arch/s390/kernel/process.c
+++ linux-2.6.22-rc6-mm1/arch/s390/kernel/process.c
@@ -93,8 +93,8 @@ void do_monitor_call(struct pt_regs *reg
/* disable monitor call class 0 */
__ctl_clear_bit(8, 15);
 
-   atomic_notifier_call_chain(&idle_chain, CPU_NOT_IDLE,
-   (void *)(long) smp_processor_id());
+   atomic_notifier_call_chain(&idle_chain, S390_CPU_NOT_IDLE,
+  (void *)(long) smp_processor_id());
 }
 
 extern void s390_handle_mcck(void);
@@ -115,7 +115,7 @@ static void default_idle(void)
}
 
rc = atomic_notifier_call_chain(&idle_chain,
-   CPU_IDLE, (void *)(long) cpu);
+   S390_CPU_IDLE, (void *)(long) cpu);
if (rc != NOTIFY_OK && rc != NOTIFY_DONE)
BUG();
if (rc != NOTIFY_OK) {
Index: linux-2.6.22-rc6-mm1/arch/s390/kernel/time.c
===
--- linux-2.6.22-rc6-mm1.orig/arch/s390/kernel/time.c
+++ linux-2.6.22-rc6-mm1/arch/s390/kernel/time.c
@@ -226,10 +226,10 @@ static int nohz_idle_notify(struct notif
unsigned long action, void *hcpu)
 {
switch (action) {
-   case CPU_IDLE:
+   case S390_CPU_IDLE:
stop_hz_timer();
break;
-   case CPU_NOT_IDLE:
+   case S390_CPU_NOT_IDLE:
start_hz_timer();
break;
}
Index: linux-2.6.22-rc6-mm1/arch/s390/kernel/vtime.c
===
--- linux-2.6.22-rc6-mm1.orig/arch/s390/kernel/vtime.c
+++ linux-2.6.22-rc6-mm1/arch/s390/kernel/vtime.c
@@ -545,10 +545,10 @@ static int vtimer_idle_notify(struct not
  unsigned long action, void *hcpu)
 {
switch (action) {
-   case CPU_IDLE:
+   case S390_CPU_IDLE:
stop_cpu_timer();
break;
-   case CPU_NOT_IDLE:
+   case S390_CPU_NOT_IDLE:
start_cpu_timer();
break;
}
Index: linux-2.6.22-rc6-mm1/include/asm-s390/processor.h
===
--- linux-2.6.22-rc6-mm1.orig/include/asm-s390/processor.h
+++ linux-2.6.22-rc6-mm1/include/asm-s390/processor.h
@@ -357,8 +357,8 @@ extern void (*s390_base_ext_handler_fn)(
 /*
  * CPU idle notifier chain.
  */
-#define CPU_IDLE   0
-#define CPU_NOT_IDLE   1
+#define S390_CPU_IDLE  0
+#define S390_CPU_NOT_IDLE  1
 
 struct notifier_block;
 int register_idle_notifier(struct notifier_block *nb);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] file capabilities: get_file_caps cleanups

[Serge E. Hallyn]

Quoting Andrew Morgan ([EMAIL PROTECTED]):
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> This contains a typo:
> 
> Serge E. Hallyn wrote:
> >>From 588755d9498c87c4e963527ba0f49c11107de354 Mon Sep 17 00:00:00 2001
> > From: Serge E. Hallyn <[EMAIL PROTECTED]>
> > Date: Wed, 27 Jun 2007 19:55:27 -0400
> > Subject: [PATCH 1/1] file capabilities: get_file_caps cleanups
> > 
> > Two cleanups relating to set_file caps.
> [...]
> > @@ -187,12 +186,21 @@ out:
> > dput(dentry);
> > if ((void *)dcaps != (void *)&v1caps)
> > kfree(dcaps);
> Move this two lines down (rc defaults to 0 in goto above):
> from here-->
> > +clear_caps:
> > +   if (rc) {
> to here-->

Hmm?  But if we succeeded we still want to free dcaps if we
kmalloc()'d it.

If we didn't kmalloc it, dcaps==v1caps and it won't be freed.

thanks,
-serge

> > +   cap_clear (bprm->cap_inheritable);
> > +   cap_clear (bprm->cap_permitted);
> > +   cap_clear (bprm->cap_effective);
> > +   }
> > return rc;
> 
> Cheers
> 
> Andrew
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.6 (GNU/Linux)
> 
> iD8DBQFGg1DNQheEq9QabfIRApNqAJ99rNMF4VU/FPOolDLHlXbbQ2MRMwCeO3Fy
> 8ze7XhlBuBKdHElbZmWFJ5Y=
> =gAEK
> -END PGP SIGNATURE-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [AppArmor 00/44] AppArmor security module overview

[Bill O'Donnell]

On Wed, Jun 27, 2007 at 05:27:17PM -0700, Casey Schaufler wrote:
| 
| --- David Miller <[EMAIL PROTECTED]> wrote:
| 
| > From: Crispin Cowan <[EMAIL PROTECTED]>
| > Date: Wed, 27 Jun 2007 15:46:57 -0700
| > 
| > > But we do not want to prevent other people from using SELinux if it
| > > suits them. Linux is about choice, and that is especially vital in
| > > security. As Linus himself observed when LSM was started, there are a
| > > lot of security models, they have various strengths and weaknesses, and
| > > often are not compatible with each other. That is why it is important
| > > that LSM persist, that SELinux not be the only in-tree user of LSM, and
| > > why we think AppArmor should be included upstream, so that non-SUSE
| > > users can also use AppArmor if it suits them.
| > 
| > Anyone can apply the apparmour patch to their tree, they get the
| > choice that way.  Nobody is currently prevented from using apparmour
| > if they want to, any such suggestion is pure rubbish.
| 
| The exact same argument was made prior to SELinux going upstream.
| Look, if you can't be right, try at least to be original.
| 
| > It is even more incredulious to imply that just by having apparmour
| > in the upstream kernel all the userland bits will magically appear
| > on every user's distribution.
| 
| Just like all the SELinux userland magically appeared in everyone's
| distribution? Nope, didn't happen.
| 
| > Give me a break.
| 
| No. You are out of line and spewing ignorance.

Please.
I really wish this thread would stick to the technical matter and 
dispense with the infernile sniping on one hand and stroking of
egos on the other.  Sheesh - some of us are actually trying to glean
something useful from all of this.

| 
| > What you get by the code going into the upstream kernel tree is that
| > it a) adds some pseudo legitimacy to AppArmour (which I don't
| > personally think is warranted) and b) gets the work of keeping
| > apparmour working with upstream largely off of your back and in the
| > hands of the upstream community.
| 
| Duh. Those are pretty much the reasons anyone goes through the
| trouble of getting anything upstream.
| 
| > Neither of those are reasons why something should go into the tree.
| 
| They reflect the corporate reality of the open source community.
| If you're going to go down the "open source isn't for money"
| rathole please take it elsewhere. I've heard the arguments so many
| times I can sing them to the tune of "Lady Madonna".
| 
| > Frankly I think AppArmour is a joke,
| 
| "SELinux, AppArmor, and Hilary Clinton walk into a bar ..."

Yawn.  Not funny. See above comment.

| > and all of this integration with
| > LSM business is just a face saving effort, nothing more.  And saving
| > face is not, and has never been, a reason for something to be put into
| > the upstream tree.
| 
| Believe what you will. Crispin has been working with LSM from the
| inception those many years ago. He's been working on getting this
| module in for over a year. If you don't like his module go write
| your own and put him out of business.

Now this is getting really boring.  See above comment.
Can't we just stay on point?

-- 
Bill O'Donnell
SGI
[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: Linux Kernel include files

[Jan Engelhardt]

On Jun 27 2007 19:18, Sam Ravnborg wrote:
>
>For my test I used latest -git of the Linux kernel.
>In this version the include of ext2_fs_bh.h is guarded
>by __KERNEL__ like this:
>
>#ifdef __KERNEL__
>#include 
>static inline struct ext2_sb_info *EXT2_SB(struct super_block *sb)
>{
>return sb->s_fs_info;
>}
[...]

I'll have to chime in here.
Test program:
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include  /* get IP_FREEBIND */

Creates a lot of error messages.
(Lots of redefinitions.)

$ rpm -q linux-kernel-headers glibc
linux-kernel-headers-2.6.21-7
glibc-2.6-5
(suse 10.3 factory)

So looks like there's still something to do.



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: man-pages-2.59 and man-pages-2.60 are released

[Alexander E. Patrakov]

Michael Kerrisk wrote:


I just released man-pages-2.59 and man-pages-2.60.

These releases are now available for download at:

http://www.kernel.org/pub/linux/docs/manpages


There is one little problem with this: there is no stable URL for a given 
version. This hurts, e.g., automated Linux From Scratch rebuilds (the 
official script grabs the URL from the book, but it becomes invalid too soon).


Could you please, in order to avoid this, do what SAMBA team does: place 
into http://www.kernel.org/pub/linux/docs/manpages/Old not only old 
versions, but also the current version? This way, LFS will be sure that the 
2.60 version is always available as 
http://www.kernel.org/pub/linux/docs/manpages/Old/man-pages-2.60.tar.bz2 
(even if it is in fact the latest version).


Thanks in advance.

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

[RFC] get rid of CONFIG_DISABLE_CONSOLE_SUSPEND

[Pavel Machek]

Hi!

What about this? (Only compile tested, but looks pretty obvious to
me). Something like this should get us rid of ugly option, and still
solve debugging problems... Hmmm?
Pavel

Kill CONFIG_DISABLE_CONSOLE_SUSPEND; it should not be configurable at
all, instead, we should automatically keep console alive when
possible.

Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>

diff --git a/drivers/char/lp.c b/drivers/char/lp.c
index 62051f8..8267ff8 100644
--- a/drivers/char/lp.c
+++ b/drivers/char/lp.c
@@ -144,7 +144,7 @@ static unsigned int lp_count = 0;
 static struct class *lp_class;
 
 #ifdef CONFIG_LP_CONSOLE
-static struct parport *console_registered; // initially NULL
+static struct parport *console_registered;
 #endif /* CONFIG_LP_CONSOLE */
 
 #undef LP_DEBUG
@@ -749,8 +749,8 @@ #endif /* console on line printer */
 /* --- initialisation code - */
 
 static int parport_nr[LP_NO] = { [0 ... LP_NO-1] = LP_PARPORT_UNSPEC };
-static char *parport[LP_NO] = { NULL,  };
-static int reset = 0;
+static char *parport[LP_NO];
+static int reset;
 
 module_param_array(parport, charp, NULL, 0);
 module_param(reset, bool, 0);
@@ -758,10 +758,10 @@ module_param(reset, bool, 0);
 #ifndef MODULE
 static int __init lp_setup (char *str)
 {
-   static int parport_ptr; // initially zero
+   static int parport_ptr;
int x;
 
-   if (get_option (&str, &x)) {
+   if (get_option(&str, &x)) {
if (x == 0) {
/* disable driver on "lp=" or "lp=0" */
parport_nr[0] = LP_PARPORT_OFF;
@@ -808,7 +808,7 @@ static int lp_register(int nr, struct pa
 #ifdef CONFIG_LP_CONSOLE
if (!nr) {
if (port->modes & PARPORT_MODE_SAFEININT) {
-   register_console (&lpcons);
+   register_console(&lpcons);
console_registered = port;
printk (KERN_INFO "lp%d: console ready\n", CONSOLE_LP);
} else
@@ -824,8 +824,7 @@ static void lp_attach (struct parport *p
 {
unsigned int i;
 
-   switch (parport_nr[0])
-   {
+   switch (parport_nr[0]) {
case LP_PARPORT_UNSPEC:
case LP_PARPORT_AUTO:
if (parport_nr[0] == LP_PARPORT_AUTO &&
@@ -856,7 +855,7 @@ static void lp_detach (struct parport *p
/* Write this some day. */
 #ifdef CONFIG_LP_CONSOLE
if (console_registered == port) {
-   unregister_console (&lpcons);
+   unregister_console(&lpcons);
console_registered = NULL;
}
 #endif /* CONFIG_LP_CONSOLE */
diff --git a/drivers/net/netconsole.c b/drivers/net/netconsole.c
index 69233f6..7f7c2ce 100644
--- a/drivers/net/netconsole.c
+++ b/drivers/net/netconsole.c
@@ -75,7 +75,7 @@ static void write_msg(struct console *co
 
local_irq_save(flags);
 
-   for(left = len; left; ) {
+   for (left = len; left; ) {
frag = min(left, MAX_PRINT_CHUNK);
netpoll_send_udp(&np, msg, frag);
msg += frag;
@@ -103,10 +103,10 @@ static int init_netconsole(void)
 {
int err;
 
-   if(strlen(config))
+   if (strlen(config))
option_setup(config);
 
-   if(!configured) {
+   if (!configured) {
printk("netconsole: not configured, aborting\n");
return 0;
}
@@ -115,6 +115,7 @@ static int init_netconsole(void)
if (err)
return err;
 
+   disable_console_on_suspend++;
register_console(&netconsole);
printk(KERN_INFO "netconsole: network logging started\n");
return 0;
@@ -123,6 +124,7 @@ static int init_netconsole(void)
 static void cleanup_netconsole(void)
 {
unregister_console(&netconsole);
+   disable_console_on_suspend--;
netpoll_cleanup(&np);
 }
 
diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c
index 326020f..b2331a5 100644
--- a/drivers/serial/serial_core.c
+++ b/drivers/serial/serial_core.c
@@ -1934,12 +1934,10 @@ int uart_suspend_port(struct uart_driver
 
mutex_lock(&state->mutex);
 
-#ifdef CONFIG_DISABLE_CONSOLE_SUSPEND
if (uart_console(port)) {
mutex_unlock(&state->mutex);
return 0;
}
-#endif
 
if (state->info && state->info->flags & UIF_INITIALIZED) {
const struct uart_ops *ops = port->ops;
@@ -1982,12 +1980,10 @@ int uart_resume_port(struct uart_driver 
 
mutex_lock(&state->mutex);
 
-#ifdef CONFIG_DISABLE_CONSOLE_SUSPEND
if (uart_console(port)) {
mutex_unlock(&state->mutex);
return 0;
}
-#endif
 
uart_change_pm(state, 0);
 
diff --git a/include/linux/console.h b/include/linux/console.h
index 62ef6e1..3cb477e 100644
--- a/include/linux/console.h
+++ b/include/linux/console.h
@@ -120,14 +120,11 @

Re: New format Intel microcode...

[Bill Davidsen]

Andi Kleen wrote:

"Daniel J Blueman" <[EMAIL PROTECTED]> writes:


On 23/03/07, Shaohua Li <[EMAIL PROTECTED]> wrote:

On Thu, 2007-03-22 at 23:45 +, Daniel J Blueman wrote:

Hi Shao-hua,

Is the tool you mentioned last June [1] available for splitting up the
old firmware files to the new format (eg
/lib/firmware/intel-ucode/06-0d-06), or are updates available from
Intel (or otherwise) in this new format?

Yes, we are preparing the new format data files and maybe put it into a
new website. We will announce it when it's ready.

It's been a while; is there any sign of the ucode updates being
available, especially in light of the C2D/Q incorrect TLB invalidation
+ recent ucode to fix this?


That microcode update is not needed on any recent Linux kernel; it flushes
the TLBs in a way that is fine.

Slashdot carried an article this morning saying that an error in Intel 
microcode was being fixed. However, it listed only Windows related sites 
for the "fix" download. Is this the same TLB issue? And are these really 
fixes for Windows to flush the TLB properly the way Linux does?


--
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: [PATCH] Fix lguest w/ lockdep

[Jeremy Fitzhardinge]

Rusty Russell wrote:

On Wed, 2007-06-27 at 19:14 -0500, Matt Mackall wrote:
  

lguest: unhandled trap 14 at 0xc01362f7 (0x0)
Dump of assembler code for function __lock_acquire:



Thanks for the bug report Matt!  I wonder if other
paravirt_disable_iospace users have the same issue...
  


I call it a little later (from arch_setup), and I think lockdep_init 
will have already been called at that point.  Hm, yes, it gets called at 
the top of start_kernel.


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

2.6.22-rc6 spurious hangs

[Thomas Sattler]

Hi there ...

I'm observing seldom hangs with linux 2.6. I can't tell when exactly it
happened the first time, I think somewhere around 2.6.16 or 2.6.17. I
see it about once or twice a month. With absolutely nothing in the logs.
So far I asked for help:

 - in the -ck list

Mon Sep 4 10:22:06 EST 2006, [ck] ck-patches seem to break DVB-T drivers
(see http://bhhdoa.org.au/pipermail/ck/2006-September/thread.html#6385)

 - in the linux-dvb list

Wed Sep 6 19:02:29 CEST 2006, [linux-dvb] driver problems when using
ck-patchset
(http://www.linuxtv.org/pipermail/linux-dvb/2006-September/thread.html#12649)

 - in the DaLUG (german, currently no archive) 14.09.2006


But nobody could help me so far.

Here is what I do:

I was running different kernels with different patchsets. It happened in
the past on -ck kernels (staircase), vanilla scheduler and cfs. As far
as I can remember the following patches were allways applied: squashfs
and vesa-tng.

Currently I'm running 2.6.22rc6 with cfs-v18, vesa-tng and an
XFS-lockdep patch:

http://people.redhat.com/mingo/cfs-scheduler/sched-cfs-v2.6.22-rc6-v18.patch
http://dev.gentoo.org/~spock/projects/vesafb-tng/archive/vesafb-tng-1.0-rc2-2.6.20-rc2.patch
see http://marc.info/?l=linux-kernel&m=118286232709378&w=2

I also installed these kernel modules via gentoo portage:

ati-drivers-8.37.6-r1
fuse-2.6.4-r1
kqemu-1.3.0_pre11
truecrypt-4.3

kqemu and truecrypt weren't loaded, but ati-drivers and fuse were.

The box I talk about is an IBM T41p with 1.7GHz Pentium M and 512MB RAM.
The distribution in use is gentoo, quite up to date. Attached to the box
is an USB2.0 DVB-T receiver (Cinergy T², Terratec).

In rare cases the keyboard stops working when the T² stops streaming DVB
to the box. It happens when I record the stream to disk as well as when
I stream it to mplayer.

If end of streaming is caused by a keypress, 'q' or 'enter' on mplayer,
that key gets stuck. It's repeated until I reboot the box.

If the recording was scheduled and stops by itself no more keys are
recognized. The keyboard is dead. The laptop's own and the attached
USB-Keyboard. Magic-Sys-Keys are still working.

I can still use the mouse to move windows around, start new xterms via
icewm's panel or copy and past single characters from an xterm to other
xterms.

I can also close most of the open windows, for example firefox and most
xterms. I cannot close an xterm which is started as 'xterm -e top' by
icewm or a vncviewer. Both windows stay open but lose their content.

If a root shell is open I can enter 'reboot' or 'halt' but most of the
time this doesn't reboot or halt. I get the message for an upcoming
shotdown in all xterms but the box doesn't come down.

The systemload continously increases but there is nothing to see in top why.

Ingo Molnar told me to enable CONFIG_PROVE_LOCKING but xfs triggers it
long before the box hangs. I tested the patch mentioned above but it was
triggered by xfs again, see [1] and I didn't reboot between this and the
last hung. [1] http://marc.info/?l=linux-kernel&m=118295294529681&w=2

As Ingo told me I run 'echo t > /proc/sysrq-trigger' this time. The
corresponding part of my syslogs is attached, as well as my kernel config.


Another thing I observed with the T² is that it doesn't work if it's
already connected when the laptop boots up. I need to power off,
disconnect and boot. If I connect the T² after bootup it works. I can
also rmmod it's driver when it's not in use.

If I boot the box with the T² connected I cannot use it, the blue led in
the T² is always off and I cannot rmmod the driver. (I don't know
whether I ever tired to rmmod the driver before I tried to use the T².)


Please CC me as I'm not subscribed to the list.

Thomas

-- 
keep mailinglists in english, feel free to send PM in german


messages.gz
Description: application/gzip


config.gz
Description: application/gzip

[PATCH] frv: fix fallout from "remove sched.h from mm.h" patch

[Alexey Dobriyan]

Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---

 include/asm-frv/pgtable.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/asm-frv/pgtable.h
+++ b/include/asm-frv/pgtable.h
@@ -25,7 +25,7 @@
 #include 
 #include 
 #include 
-struct mm_struct;
+#include 
 struct vm_area_struct;
 #endif
 

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

Re: [RFC] get rid of CONFIG_DISABLE_CONSOLE_SUSPEND

[Tejun Heo]

Pavel Machek wrote:
> Hi!
> 
> What about this? (Only compile tested, but looks pretty obvious to
> me). Something like this should get us rid of ugly option, and still
> solve debugging problems... Hmmm?

Violent agreement from me.  Not taking down serial console would help a
lot too.  Storing dmesg from the image-loading kernel during resume from
hibernation would be another nice addition.

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] RFC: have tcp_recvmsg() check kthread_should_stop() and treat it as if it were signalled

[Oleg Nesterov]

(trimmed the cc: list)

On 06/28, Satyam Sharma wrote:
>
> On 6/27/07, Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> >
> >Contrary, I believe we should avoid signals when it
> >comes to kernel threads.
>
> And I agree, but there's quite a subtle difference between signals being
> used like they normally are, and this case here. Fact is, there is simply
> no other way to break out of certain functions (if there was, I would've
> preferred that myself).
>
> In fact, what I'm proposing is that kthreads should *not* be tinkering
> with (flushing, handling, dequeueing, whatever) signals at all, because
> like you mentioned, if they do that, it's possible that the TIF_SIGPENDING
> could get lost.

But we do have kthreads which call dequeue_signal(). And perhaps some
kthread treats SIGKILL as "urgent exit with a lot of printks" while
kthread_should_stop() means "exit gracefully".

> >I am talking about the case
> >when wait_event_interruptible() should not fail (unless something bad
> >happens) inside the "while (!kthread_should_stop())" loop.
> >Note also that kthread could use TASK_INTERRUPTIBLE sleep
> >[...] and because it knows that all signals are ignored.
>
> Ok, I think you're saying that if a kthread used wait_event_interruptible
> (and was not expecting signals, because it ignores them), then bad
> things (say exit in inconsistent state, etc) will happen if we break that
> wait_event_interruptible unexpectedly.

No. Of course, kthread should check the error and doesn't exit in
inconsistent state.

The question is: why should we break (say) tcp_recvmsg() inside
"while (!kthread_should_stop())" loop if it is supposed to succeed
unless something bad happens? (I mean, we may have a kthread which
doesn't expect the failure unless something bad happens).

OK, let me give a silly example. The correctly written kthread should check
the result of kmalloc(), yes? kthread(k) means that k should exit anyway, yes?
So let's change kthread_stop(k) to also set TIF_MEMDIE, this means that
__alloc_pages() will fail quickly when get_page_from_freelist() doesn't
succeed, but won't start pageout() which may take a while. Please don't
explain me why this suggestion is bad :), I am just trying to illustrate
my point.

I believe kthread_stop() should not send the signal. Just because it could
be actually dequeued by kthread, and it may have some special meaning for
this kthread.

Perhaps it makes sense to do signal_wake_up() (sets TIF_SIGPENDING and wakes
up), recalc_sigpending() could be changed to take kthread_should_stop() into
account (so TIF_SIGPENDING can't be cleared). Once again, I _personally_ do
not like this too much, but yes, I see your point, and I can't say such a
change is "wrong".

Hmm... actually, such a change breaks the

while (signal_pending(current))
dequeue_signal_and_so_something();

loop, see jffs2_garbage_collect_thread() for example.

In short, I think that kthread_stop() + TIF_SIGPENDING should be a special
case, the signal should be sent explicitly before kthread_stop(), like
cifs does. After all, the caller of kthread_stop(k) should know what and
why k does.

In any case, that kind of the changes can break things, just because
this means API change.

> And thirdly, what I'm proposing is putting the check for checking the
> SIGKILL in kthread_should_stop itself, in /addition/ to the
> kthread_stop_info.k == current check.

This is what I can't understand completely. Why should we check SIGKILL
or signal_pending() in addition to kthread_stop_info.k, what is the point?

Oleg.

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

Re: [PATCH] LinuxPPS (with new syscalls API)

[Rodolfo Giometti]

On Thu, Jun 28, 2007 at 12:44:20PM +0100, David Woodhouse wrote:
> 
> It's nice if you can do so, but I wouldn't suggest that you _have_ to.
> I have to admit that I rarely bother actually wiring new system calls up
> on anything but PowerPC to start with.
> 
> The important thing is that you've _considered_ the other architectures,
> and the 32/64 compatibility implications. As long as the API of your new
> system call is sensible and takes that kind of thing into account, it
> should be fine.

Ok. :)

> Had you considered changing the API so that you don't need the
> compatibility wrapper at all? Could you take an integer number of µS or
> ms instead of a struct timespec?

Not before now, but I followed the API specified into RFC 2783 who
specifies struct timespec...

Thanks for your suggestions! I'll send a new patch ASAP!

Rodolfo

-- 

GNU/Linux Solutions  e-mail:[EMAIL PROTECTED]
Linux Device Driver [EMAIL PROTECTED]
Embedded Systems[EMAIL PROTECTED]
UNIX programming phone: +39 349 2432127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: New format Intel microcode...

[Arjan van de Ven]

(while I work for Intel this is not an official Intel statement, but
there is so much FUD going around now that I feel I need to at least
point out a few things others "forget")
> > 
> Slashdot carried an article this morning saying that an error in Intel 
> microcode was being fixed.

don't just always believe everything you read on slashdot please

>  However, it listed only Windows related sites 
> for the "fix" download. Is this the same TLB issue? And are these really 
> fixes for Windows to flush the TLB properly the way Linux does?

First of all, Linux has microcode updates as well. Some of the more
hypish news-bulletins just conveniently "forgot" about this. Basically
all distributions ship them, so users who use the distro update tools
get these automatically. And the update mentioned has been shipping for
a while (in version 1.17).

Second, Intel really recommends always running the latest microcode.
(which is easy on Linux at least, and on Windows you can now see how
they do it). While reading the errata list may sound really scary, most
of the issues found and fixed are "lab finds" and are things operating
systems don't do. Some are more visible though; and since it's easy to
get the latest microcode (yum upgrade / apt-get upgrade / etc) you
probably are already running a recent one.

As for the TLB behavior; the Linux kernel is behaving correctly for
quite a while now as far as I know.. I wouldn't worry about it too much.
SMP tlb shootdown always has been tricky in the light of multiple cpus
having tlbs "hot" and active while tearing down mappings. 
(just think about it: cpu0 is accessing the memory while cpu1 is
removing it; until you flush the tlb on cpu0 it won't see the new
pagetable state since the tlb is a cache...)

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

[PATCH 1/2] serial_txx9: Fix modem control line handling

[Atsushi Nemoto]

This chip does not have modem control lines.  Return TIOCM_CAR and
TIOCM_DSR always on get_mctrl() and ajust some bits in termios cflag.

Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
diff --git a/drivers/serial/serial_txx9.c b/drivers/serial/serial_txx9.c
index 1deb576..407fca0 100644
--- a/drivers/serial/serial_txx9.c
+++ b/drivers/serial/serial_txx9.c
@@ -37,7 +37,7 @@
 
 #include 
 
-static char *serial_version = "1.09";
+static char *serial_version = "1.10";
 static char *serial_name = "TX39/49 Serial driver";
 
 #define PASS_LIMIT 256
@@ -436,8 +436,10 @@ static unsigned int serial_txx9_get_mctrl(struct uart_port 
*port)
struct uart_txx9_port *up = (struct uart_txx9_port *)port;
unsigned int ret;
 
-   ret =  ((sio_in(up, TXX9_SIFLCR) & TXX9_SIFLCR_RTSSC) ? 0 : TIOCM_RTS)
-   | ((sio_in(up, TXX9_SICISR) & TXX9_SICISR_CTSS) ? 0 : 
TIOCM_CTS);
+   /* no modem control lines */
+   ret = TIOCM_CAR | TIOCM_DSR;
+   ret |= (sio_in(up, TXX9_SIFLCR) & TXX9_SIFLCR_RTSSC) ? 0 : TIOCM_RTS;
+   ret |= (sio_in(up, TXX9_SICISR) & TXX9_SICISR_CTSS) ? 0 : TIOCM_CTS;
 
return ret;
 }
@@ -557,6 +559,12 @@ serial_txx9_set_termios(struct uart_port *port, struct 
ktermios *termios,
unsigned long flags;
unsigned int baud, quot;
 
+   /*
+* We don't support modem control lines.
+*/
+   termios->c_cflag &= ~(HUPCL | CMSPAR);
+   termios->c_cflag |= CLOCAL;
+
cval = sio_in(up, TXX9_SILCR);
/* byte size and parity */
cval &= ~TXX9_SILCR_UMODE_MASK;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] serial_txx9: Cleanup includes

[Atsushi Nemoto]

Do not include some header files already indluded by serial_core.h.

Signed-off-by: Atsushi Nemoto <[EMAIL PROTECTED]>
---
diff --git a/drivers/serial/serial_txx9.c b/drivers/serial/serial_txx9.c
index 407fca0..7480dc8 100644
--- a/drivers/serial/serial_txx9.c
+++ b/drivers/serial/serial_txx9.c
@@ -25,15 +25,11 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
-#include 
 
 #include 
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] MAP_NOZERO - implement a new VM_NOZERO/MAP_NOZERO page retirement policy

[Rik van Riel]

Andy Isaacson wrote:


That said, I think I like the idea of MAP_NOZERO.  Could it be
generalized to some kind of "free pool" rather than keyed off of uid?


Good idea.  At exec() time the new mm can inherit the "free pool"
pointer that the parent process points to, when nothing changes.

Certain events can cause a process to need another "free pool",
for example changing the UID, changing security context or
changing CPU/NUMA node binding.

--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is.  Each group
calls the other unpatriotic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git patches] libata fixes

[Mikael Pettersson]

On Wed, 27 Jun 2007 03:35:26 -0400, Jeff Garzik wrote:
>Tejun Heo (9):
>  libata: kill the infamous abnormal status message
>  libata: kill non-sense warning message
>  libata: be less verbose about hpa
>  libata: remove unused variable from ata_eh_reset()
>  libata: fix ata_dev_disable()
>  libata: fix infinite EH waiting bug
>  libata: call ata_check_atapi_dma() with qc better prepared
>  libata: use PIO for non-16 byte aligned ATAPI commands
>  libata: kill ATA_HORKAGE_DMA_RW_ONLY

These changes fixed the CDROM IDENTIFY failures one of
my older test machines used to get with libata. I now
get much nicer results on that machine:

ata_piix :00:1f.1: version 2.11
PCI: Setting latency timer of device :00:1f.1 to 64
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max UDMA/100 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f000 irq 14
ata2: PATA max UDMA/100 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f008 irq 15
ata1.00: ATA-5: IC35L080AVVA07-0, VA4OA52A, max UDMA/100
ata1.00: 160836480 sectors, multi 16: LBA 
ata1.00: configured for UDMA/100
ata2.00: ATAPI: CRD-8320B, 1.12, max MWDMA2
ata2.01: ATAPI: Hewlett-Packard CD-Writer Plus 9100, 1.0c, max UDMA/33
ata2.00: configured for MWDMA2
ata2.01: configured for UDMA/33
scsi 0:0:0:0: Direct-Access ATA  IC35L080AVVA07-0 VA4O PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 160836480 512-byte hardware sectors (82348 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
sd 0:0:0:0: [sda] 160836480 512-byte hardware sectors (82348 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA
 sda: sda1 sda2 sda3 sda4 < sda5 sda6 >
sd 0:0:0:0: [sda] Attached SCSI disk
scsi 1:0:0:0: CD-ROMGoldStar CD-ROM CRD-8320B 1.12 PQ: 0 ANSI: 5
scsi 1:0:1:0: CD-ROMHP   CD-Writer+ 9100  1.0c PQ: 0 ANSI: 5

It's the CRD-8320B that used to time out and fail IDENTIFY.

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

Re: [PATCH 0/6][TAKE5] fallocate system call

[Mingming Cao]

On Thu, 2007-06-28 at 02:55 -0700, Andrew Morton wrote:

> Please drop the non-ext4 patches from the ext4 tree and send incremental
> patches against the (non-ext4) fallocate patches in -mm.
> 
The ext4 fallocate() patches are dependent on the core fallocate()
patches, so ext4 patch-queue and git tree won't compile (it's not based
on mm tree) without the core changes.

We can send ext4 fallocate patches (incremental patches against mm tree)
and drop the full fallocate patches(ext4 and non ext4 part) from ext4
patch queue if you prefer this way.

> And try to get the code finished?  Time is pressing.
> 
I looked at the mm tree, there are other ext4 features/changes that are
currently in ext4-patch-queue(not ext4 git tree) that not in part of
ext4 series yet. Ted, can you merge those patches to your git tree?
Thanks!


Thanks for your patience.

Mingming.

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