Linus Torvalds wrote:
So do cleanups _separately_ from movement.
Definitely. Anything else makes review more difficult, by obscuring
changes with movement.
Quite frankly, I personally am considering removing "checkpatch.pl". That
thing is just a nazi dream. That hard-coded 80-character li
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
On Tue, Jun 26, 2007 at 09:32:44PM -0700, Davide Libenzi wrote:
> > Because an SUID program can change its UID back.
> >
> > At least, one that was SUID root. OTOH, any
> > program running as root can change UID, so we
> > should probably not allow root to get nonzeroed
> > pages.
>
> Well, root
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 tha
Hi, Arnd,
>
> On Wednesday 27 June 2007, Zhang Wei wrote:
> > +static struct of_device_id mpc86xx_of_ids[] = {
> > + { .type = "soc", },
> > + { .compatible = "fsl,rapidio-delta", },
> > + {},
> > +};
> > +
> > +static __init int mpc86xx_of_device_init(void)
> > +{
> > +
So I'm running the generic version of this on i386 with 8k stacks (below),
with a quick LTP run.
Holy cow, either we use a _lot_ of stack or these numbers are off:
vmm:/home/akpm> dmesg -s 100|grep 'bytes left'
khelper used greatest stack depth: 7176 bytes left
khelper used greatest stack d
2007/6/28, Josh Triplett <[EMAIL PROTECTED]>:
dave young wrote:
> 2007/6/27, Jan Engelhardt <[EMAIL PROTECTED]>:
>> On Jun 27 2007 14:05, Chris Shoemaker wrote:
>>> What I'd really like to see is, _why_ is trailing whitespace
>>> considered harmful?
>> Consumes bytes you'll never see :)
>>
>>> Som
-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
> Let's hope courts see it this way.
> But then, why is it that I can't use hardware to stop someone from
> copying or modifying the source code, but I can use hardware to stop
> someone from copying or modifying the binary? Or is that not so?
You can use the hardware to stop someone from copyi
2007/6/28, Dmitry Torokhov <[EMAIL PROTECTED]>:
On Wednesday 27 June 2007 01:02, dave young wrote:
> 2007/6/27, Dmitry Torokhov <[EMAIL PROTECTED]>:
> > On Wednesday 27 June 2007 00:28, Greg KH wrote:
> > > On Wed, Jun 27, 2007 at 12:34:09AM -0400, Dmitry Torokhov wrote:
> > > > Hi Dave,
> > > >
>
-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_fil
On Mon, 18 Jun 2007 02:58:44 -0700 [EMAIL PROTECTED] wrote:
> kmalloc_node() and kmem_cache_alloc_node() were not available in
> a zeroing variant in the past. But with __GFP_ZERO it is possible
> now to do zeroing while allocating.
>
> Use __GFP_ZERO to remove the explicit clearing of memory via
dave young wrote:
> 2007/6/27, Jan Engelhardt <[EMAIL PROTECTED]>:
>> On Jun 27 2007 14:05, Chris Shoemaker wrote:
>>> What I'd really like to see is, _why_ is trailing whitespace
>>> considered harmful?
>> Consumes bytes you'll never see :)
>>
>>> Something about MUAs not preserving it or somethin
2007/6/27, Jan Engelhardt <[EMAIL PROTECTED]>:
On Jun 27 2007 14:05, Chris Shoemaker wrote:
>
>What I'd really like to see is, _why_ is trailing whitespace
>considered harmful?
Consumes bytes you'll never see :)
>Something about MUAs not preserving it or something?
Well, there is format=flowe
Ingo Molnar wrote:
so how about the following, different approach: anyone who has a tasklet
in any performance-sensitive codepath, please yell now. We'll also do a
proactive search for such places. We can convert those places to
softirqs, or move them back into hardirq context. Once this is don
Any chance you can remove linux-fsdevel from the CC list? I don't think this
has anything to do with filesystems.
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On Wednesday 27 June 2007 01:02, dave young wrote:
> 2007/6/27, Dmitry Torokhov <[EMAIL PROTECTED]>:
> > On Wednesday 27 June 2007 00:28, Greg KH wrote:
> > > On Wed, Jun 27, 2007 at 12:34:09AM -0400, Dmitry Torokhov wrote:
> > > > Hi Dave,
> > > >
> > > > On Wednesday 27 June 2007 06:59, Dave Youn
On Wed, 2007-06-27 at 22:04 -0500, 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 emul
On Wed, Jun 27, 2007 at 08:08:08PM -0300, Alexandre Oliva wrote:
> On Jun 26, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote:
>
> > GPLv2 section 3.
> > The source code for a work means the preferred form of the work for
> > making modifications to it.
>
> > I believe this states that the sou
On Jun 28, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
> Until someplace you can't actually access the software is customarily used
> for software interchange, ...
As in TiVo boxes? :-) :-)
> This is a defect in the GPL. At least as I understood it, the intent
> was to force distributors t
On Thursday 28 June 2007 00:45:18 Alexandre Oliva wrote:
> On Jun 27, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> > Section 3 doesn't apply to this situation. However, other sections
> > do. They are distributing in line with the distribution requirement,
> > but not the "modification and co
On Jun 27, 2007, Daniel Hazelton <[EMAIL PROTECTED]> wrote:
> Section 3 doesn't apply to this situation. However, other sections
> do. They are distributing in line with the distribution requirement,
> but not the "modification and copying" requirements. These are
> granted early in the license an
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
Kyle Moffett wrote:
Gah, this particular topic and a few other similar header-compatibility
ones show up once a month on LKML; I should probably just make a patch
to fix all the types.h files and be done with it. The proper solution
is this:
# if __STDC_VERSION__ >= 19901L
typedef signed
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:t
Andrey,
Can you try the following patch? It applies on top of the previous
two patches, and it is enough to make the driver find the device on
my Portege 4000. Unfortunately, I can't tell whether it really works
because I don't have a clue about how to make two IR devices talk
to each other.
Bj
On Tue, Jun 19, 2007 at 03:25:52PM +0200, [EMAIL PROTECTED] wrote:
> * 32bit struct xfs_fsop_bulkreq has different size and layout of
> members, no matter the alignment. Move the code out of the #else
> branch (why was it there in the first place?). Define _32 variants of
> the ioctl constant
> Alexandre Oliva writes:
>
> >> Yes, but in the scenario I proposed, the source code *is* in the
> >> preferred form for making modifications, it just so happens to be
> >> behind a barrier you cannot trespass. This is not different from
> >> shipping binaries and sources in a CD inside a locked
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, mul
In 2.6.18, replace times with clockevents. arch/i386/kernel/timers/ was removed.
`pit_latch_buggy' was referred in timers/timer_tsc.c, and currently removed.
Therefore nobody refer it. It has no effect already.
Signed-off-by: TAKADA Yoshihito <[EMAIL PROTECTED]>
diff -Narup a/arch/i386/kernel/cp
On 6/27/07, Patrick Draper <[EMAIL PROTECTED]> 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
Hi Ingo, this is happening in a brand new laptop, a Lenovo t61 with a
7700 processor and the Santa Rosa chipset.
Lukewarm IQ detected in hotplug locking
BUG: at kernel/cpu.c:44 lock_cpu_hotplug()
[] dump_trace+0x64/0x105
[] show_trace_log_lvl+0x18/0x2c
[] show_trace+0xf/0x11
[] dump_stack+0x1
On Wed, Jun 27, 2007 at 04:16:48PM -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...
>
Doing 64-bit Linux non-LP64 would be a
On Wed, 27 Jun 2007 22:57:39 -0400 "J. Bruce Fields" <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 27, 2007 at 07:36:13PM -0700, Andrew Morton wrote:
> > How's this?
>
> Makes sense to me, thanks. I guess fs/nsfd/nfssvc:nfsd_create_serv()
> should be similarly modified? It calculates the size of per
On Tue, Jun 19, 2007 at 03:25:51PM +0200, [EMAIL PROTECTED] wrote:
> 32bit struct xfs_fsop_handlereq has different size and offsets (due to
> pointers). TODO: case XFS_IOC_{FSSETDM,ATTRLIST,ATTRMULTI}_BY_HANDLE
> still not handled.
Looks good. Added to my qa tree...
Cheers,
Dave.
--
Dave Chinne
On Tue, Jun 19, 2007 at 03:25:50PM +0200, [EMAIL PROTECTED] wrote:
> i386 struct xfs_fsop_geom_v1 has no padding after the last member, so
> the size is different.
Looks good. Added to my qa tree...
Cheers,
Dave.
--
Dave Chinner
Principal Engineer
SGI Australian Software Group
-
To unsubscribe
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
On Wed, 27 Jun 2007, Linus Torvalds wrote:
> On Wed, 27 Jun 2007, Davide Libenzi wrote:
>
> > On Wed, 27 Jun 2007, Linus Torvalds wrote:
> > >
> > > Stores never "leak up". They only ever leak down (ie past subsequent
> > > loads
> > > or stores), so you don't need to worry about them. That's
I did the first crack at a powerpc port. I'd appreciate your comments on
this patch. It should not be incorporated, isn't finished, probably breaks
ptrace, etc. I'm posting it now just to get any thoughts you have raised
by seeing the second machine share the intended arch-independent code.
I j
On Wed, 27 Jun 2007, Davide Libenzi wrote:
> On Wed, 27 Jun 2007, Nicholas Miell wrote:
>
> > 1) euid is not sufficient, you need to store away arbitrary LSM
> > information and call LSM hooks to decide security equivalence. The same
> > applies to VServer or whatever other container system you u
On Wed, Jun 27, 2007 at 07:36:13PM -0700, Andrew Morton wrote:
> How's this?
Makes sense to me, thanks. I guess fs/nsfd/nfssvc:nfsd_create_serv()
should be similarly modified? It calculates the size of per-nfsd-thread
buffers used to hold requests, which will eventually be allocated with
an allo
On Wednesday 27 June 2007 22:37:42 Alexandre Oliva wrote:
> On Jun 27, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
> > Behind a barrier is not on a medium customarily used for software
> > interchange, which 3a requires.
>
> Are you per chance claiming that you've never heard of anyone
> rece
Quoting James Morris ([EMAIL PROTECTED]):
> On Wed, 27 Jun 2007, Serge E. Hallyn wrote:
>
> > Patch tests fine for me for expected capability behavior with lsm=n,
> > lsm=y, lsm=y+capability=y, lsm=y+selinux=y, and lsm=y+caps=y+selinux=y.
> >
> > So while I'm opposed to the patch, it appears to b
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:
> > prepar
On Jun 27, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
> Behind a barrier is not on a medium customarily used for software
> interchange, which 3a requires.
Are you per chance claiming that you've never heard of anyone
receiving encrypted software in a CD, or pre-installed in a computer?
>
On Wed, 27 Jun 2007 22:15:52 -0400 "J. Bruce Fields" <[EMAIL PROTECTED]> wrote:
> + /*
> + * Allow at most 4 delegations per megabyte of RAM. Quick
> + * estimates suggest that in the worst case (where every delegation
> + * is for a different inode), a delegation could take ab
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 -
This code would benefit from a little more explanation.
Also, I screwed up the previous patch and forgot to delete a line, so the
calculation here is off; fix it.
Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
---
fs/nfsd/nfs4state.c | 16 +++-
1 files changed, 15 insertions(+
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-bi
On 06/28/2007 02:18 AM, Patrick Draper wrote:
Please always use Reply-to-All on this list -- subscribers here like to also
get personal copies.
Rene Herman wrote:
KDE has finally dropped aRts from KDE4 and, again, ALSA has been
mixing by default for some time now so we're talking history any
> On Jun 27, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
>
> > Alexandre Oliva writes:
>
> >> Yes, but in the scenario I proposed, the source code *is* in the
> >> preferred form for making modifications, it just so happens to be
> >> behind a barrier you cannot trespass. This is not differ
Serge E. Hallyn wrote:
Here's the first patch (of several or many to come) to address some of
Andrew's comments.
Kaigai, IIUC cap_names.h will eventually be automatically updated? (I
had to manually tweak it for testing as the new kernel sources were not
located on the test system)
The origin
On Jun 27, 2007, "David Schwartz" <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva writes:
>> Yes, but in the scenario I proposed, the source code *is* in the
>> preferred form for making modifications, it just so happens to be
>> behind a barrier you cannot trespass. This is not different from
>> s
On Wed, 27 Jun 2007, Davide Libenzi wrote:
> On Wed, 27 Jun 2007, Linus Torvalds wrote:
> >
> > Stores never "leak up". They only ever leak down (ie past subsequent loads
> > or stores), so you don't need to worry about them. That's actually already
> > documented (although not in those terms
Hi Oleg,
On 6/27/07, Oleg Nesterov <[EMAIL PROTECTED]> wrote:
On 06/27, Satyam Sharma wrote:
>
> Thanks for your comments, I'm still not convinced, however.
An perhaps you are right. I don't have a very strong opinion on that.
Still I can't understand why it is better if kthread_stop() sends a
On Wed, Jun 27, 2007 at 04:35:44PM +0800, Zhang Wei wrote:
> Add the explanation and a sample of RapidIO DTS sector to the document of
> booting-without-of.txt file.
>
> Signed-off-by: Zhang Wei <[EMAIL PROTECTED]>
> ---
> Documentation/powerpc/booting-without-of.txt | 34
> ++
From: Casey Schaufler <[EMAIL PROTECTED]>
Date: Wed, 27 Jun 2007 17:27:17 -0700 (PDT)
> --- David Miller <[EMAIL PROTECTED]> wrote:
>
> > 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
On Thursday 28 June 2007 00:30:52 Kyle Moffett wrote:
> On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote:
> > AFAIR the Intel compiler claims to be gcc.
> >
> > But these are by far not the only C compilers under Linux, and the
> > more important points are:
> >
> > Is there any userspace Linux co
--- 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 hi
>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.
Rename set_file_caps to get_file_caps, sin
Rene Herman wrote:
KDE has finally dropped aRts from KDE4 and, again, ALSA has been mixing
by default for some time now so we're talking history anyway. You want
mixing on your card? You got it.
I've been following this discussion with some interest, to learn more
about ALSA. I've been creati
On Wed, 27 Jun 2007, Nicholas Miell wrote:
> 1) euid is not sufficient, you need to store away arbitrary LSM
> information and call LSM hooks to decide security equivalence. The same
> applies to VServer or whatever other container system you use.
The EUID that is used now, can easily be any cook
On Fri, 8 Jun 2007 13:53:49 +0100
[EMAIL PROTECTED] (Mel Gorman) wrote:
> Currently PAGE_OWNER depends on CONFIG_X86. This appears to be due to
> pfn_to_page() being called in an inappropriate for many memory models
> and the presense of memory holes. This patch ensures that pfn_valid()
> and pfn_
Alexandre Oliva writes:
> Yes, but in the scenario I proposed, the source code *is* in the
> preferred form for making modifications, it just so happens to be
> behind a barrier you cannot trespass. This is not different from
> shipping binaries and sources in a CD inside a locked box that you
>
> .config and contents of /proc/cpuinfo would be helpful...
Apologies! I'm still working on the bisection, but...
The following is from 2.6.21-gae1ee11b, which works.
$ cat /tmp/cpuinfo
processor : 0
vendor_id : GenuineTMx86
cpu family : 6
model : 4
model name :
On Wed, 27 Jun 2007, Linus Torvalds wrote:
> > IOW shouldn't an mfence always be there? Not only loads could leak up
> > into the wait phase, but stores too, if they have no dependency with the
> > "head" and "tail" loads.
>
> Stores never "leak up". They only ever leak down (ie past subsequent
Hi,
On Tue, 26 Jun 2007, Jeremy Fitzhardinge wrote:
> > We have the __ASSEMBLY__ define for this, so just for asm code we don't need
> > a separate header.
> >
>
> Hm. The number of __ASSEMBLY__s end up being pretty large, and it just seemed
> cleaner to put them in separate headers.
This c
On Wed, 27 Jun 2007 15:57:15 -0700 Randy Dunlap wrote:
> On Wed, 27 Jun 2007 18:30:52 -0400 Kyle Moffett wrote:
>
> > On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote:
> > > AFAIR the Intel compiler claims to be gcc.
> > >
> > > But these are by far not the only C compilers under Linux, and the
On 06/27/2007 09:10 PM, Andreas Hartmetz wrote:
I don't like random applications blocking my sound card.
So don't use random applications.
I imitated the style of the mail I replied to. Besides, choosing apps
based on sound system is retarded if you wanted to indicate that this
should be don
Just a quick plug for a utility I wrote a number of years ago and have
recently open sourced. It's been around as an internal tool for about 4
years and so has been pretty well shaken out. There's a pretty good
description and some example output at
http://collectl.sourceforge.net/index.html
On Thu, Jun 28, 2007 at 01:32:23AM +0300, Al Boldi wrote:
> > > You are effectively inhibiting the development of an out-of-tree GPL
> > > module pool, by constantly pulling the rug under that community.
> >
> > The same thing happens with any yet-to-be-merged code.
> >
> > > Do you think this is f
On Thu, 28 Jun 2007 00:57:07 +0200
Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
> Hello,
>
> Build problems on iMac G3.
>
> 1) allnoconfig results in this:
>
> CC arch/powerpc/mm/tlb_32.o
> In file included from include/asm/tlb.h:60,
> from arch/powerpc/mm/tlb_32.c:
I believe I have the right way of going about it. I agree with the
kernel developers who've stated that ZFS is a layering violation, and
we can do better.
Consider a filesystem on a set of drives; it may want some data to be
in a raid5 and some to be mirrored. The correct interface for the
filesy
> @Jörg: The responsibility to maintain clean headers shifted only recently,
yes.. from distro to the kernel ;)
in the old case it was always a distro bug...
> and there is possibly still a lot to do. If you can point out errors, they
> can and probably will be fixed. But as you know, having a
On Jun 26, 2007, Jan Harkes <[EMAIL PROTECTED]> wrote:
> GPLv2 section 3.
> The source code for a work means the preferred form of the work for
> making modifications to it.
> I believe this states that the source code has to be in the preferred
> form for making modifications and not som
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
On Wed, 27 Jun 2007 18:30:52 -0400 Kyle Moffett wrote:
> On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote:
> > AFAIR the Intel compiler claims to be gcc.
> >
> > But these are by far not the only C compilers under Linux, and the
> > more important points are:
> >
> > Is there any userspace Linux
Hello,
Build problems on iMac G3.
1) allnoconfig results in this:
CC arch/powerpc/mm/tlb_32.o
In file included from include/asm/tlb.h:60,
from arch/powerpc/mm/tlb_32.c:30:
include/asm-generic/tlb.h: In function 'tlb_flush_mmu':
include/asm-generic/tlb.h:76: error:
Hi Oliver
You are initialising an interrupt urb with an initializer for
a bulk urb. The behavior is undefined. In older kernels
by random chance a sensible interval was set.
You need to use the correct initializer and the correct interval,
which usually can be read from the device's descriptors
Sean wrote:
> On Wed, 27 Jun 2007 14:06:04 -0700
> Crispin Cowan <[EMAIL PROTECTED]> wrote:
>
>> I am hoping for a reconciliation where the people who don't like
>> AppArmor live with it by not using it. AppArmor is not intended to
>> replace SELinux, it is intended to address a different set of
On Wed, Jun 27, 2007 at 06:49:48PM +0100, David Woodhouse wrote:
>
> Looks better. All I can find to complain about is the fact that you
> return whatever copy_from_user() returns. Don't -- that's the number of
> bytes left to copy. It should be if (copy_from_user(..)) return -EFAULT;
Ok, I'll fi
Nevermind. I realized I was being an idiot. Sorry for the wasted bandwidth.
Basically, if we have a page that get_user_pages() returned to us, the only
way any part of the PGD/PUD/PMD maping hierarchy can be missing is if the page
is the ZERO_PAGE(). Thus I can use this to detect my ZERO_PA
Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-06-27 at 18:41 +0200, Joerg Schilling wrote:
>> Well, I did report these kind of problems many years ago and as it has not
>> been fixed after some years, I was asuming that it is still the way I see it
>> on Suse 10.0.
>
> I'd suggest re
On Wed, Jun 27, 2007 at 07:50:56AM -0400, Chris Mason wrote:
> On Wed, Jun 27, 2007 at 07:32:45AM +0200, Nick Piggin wrote:
> > On Tue, Jun 26, 2007 at 08:34:49AM -0400, Chris Mason wrote:
> > > On Tue, Jun 26, 2007 at 07:23:09PM +1000, David Chinner wrote:
> > > > On Tue, Jun 26, 2007 at 01:55:11P
Adrian Bunk wrote:
> On Wed, Jun 27, 2007 at 04:53:58PM +0300, Al Boldi wrote:
> > Al Viro wrote:
> > > On Wed, Jun 27, 2007 at 11:18:36AM +0200, Zolt?n HUBERT wrote:
> > > > And as I understand it, this is (was ?) the whole point of
> > > > stable/development kernels. "We" can trust a newer stable
Al Viro wrote:
> On Wed, Jun 27, 2007 at 04:53:58PM +0300, Al Boldi wrote:
> > Al Viro wrote:
> > > On Wed, Jun 27, 2007 at 11:18:36AM +0200, Zolt?n HUBERT wrote:
> > > > And as I understand it, this is (was ?) the whole point of
> > > > stable/development kernels. "We" can trust a newer stable
> >
On Jun 27, 2007, at 13:32:40, Adrian Bunk wrote:
AFAIR the Intel compiler claims to be gcc.
But these are by far not the only C compilers under Linux, and the
more important points are:
Is there any userspace Linux compiler that does not support "long
long"?
Don't know, but I'd guess not
Joerg Schilling wrote:
After copying /usr/include/linux/types.h to
/opt/sunstudio12/prod/include/cc/linux/types.h and removing all
#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
...
#endif
stuff, I got cdrtools compiled using "suncc" and I did even get a woring
cdrecord.
Indeed, t
On 06/27/2007 11:31 AM, [EMAIL PROTECTED] wrote:
> Hardware: Fujitsu Lifebook P-2040, TM5800 800 MHz processor
> 2.6.21: Closing the lid causes APM suspend. Opening it resumes just fine.
> 2.6.22-rc5/-rc6: On resume, backlight comes on, but system is otherwise
> frozen. Nothing happens unti
On Jun 27 2007 14:05, Chris Shoemaker wrote:
>
>What I'd really like to see is, _why_ is trailing whitespace
>considered harmful?
Consumes bytes you'll never see :)
>Something about MUAs not preserving it or something?
Well, there is format=flowed. text/plain mails with a trailing blank at the
On Jun 27 2007 12:31, Andrew Morton wrote:
>
>quilt has ways of detecting and/or correcting newly-added trailing
>whitespace, but I don't know the details.
Upon `quilt ref`, it usually barfs about every line you touched where you
added or kept whitespace at EOL.
>One could share the various scri
On Wed, 27 Jun 2007, Davide Libenzi wrote:
> >
> > Now, I have good reason to believe that all Intel and AMD CPU's have a
> > stricter-than-documented memory ordering, and that your spinlock may
> > actually work perfectly well. But it still worries me. As far as I can
> > tell, there's a the
(not CCing security, since it's not a security bug and it's too late to
verify if they should be on cc. Will do later.)
Anand Jahagirdar <[EMAIL PROTECTED]> wrote:
> This patch Warns the administrator about the fork bombing attack
> (whenever any user is crossing its process limit). I have used
On Wed, 2007-06-27 at 11:45 -0700, Davide Libenzi wrote:
> On Wed, 27 Jun 2007, Hugh Dickins wrote:
>
> > On Wed, 27 Jun 2007, Davide Libenzi wrote:
> > > On Wed, 27 Jun 2007, Hugh Dickins wrote:
> > >
> > > > In honesty, I should add that I dislike and distrust Davide's
> > > > MAP_NOZERO very m
> Newsgroups: gmane.linux.kernel
> Date: Wed, 27 Jun 2007 12:31:22 -0700
>
>
> akpm:/usr/src/25> grep -l "^+.*[]$" patches/git-*.patch
> patches/git-acpi.patch
> patches/git-alsa.patch
> patches/git-battery.patch
> patches/git-cifs.patch
> patches/git-drm.patch
> patches/git-gfs2-nmw.patch
On Wed, 27 Jun 2007 22:22:00 +0200
Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
> Hello,
>
> This patch balances the parenthesis imbalance in serial core.
>
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
Ack although the right thing to do is to remove these checks (and I'm
doing s
Hello,
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.
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
drivers/mtd/mtd
[Please consider as 2.6.22 material.]
---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Commit 52ade9b3b97fd3bea42842a056fe0786c28d0555 changed the suspend code
ordering to execute pm_ops->prepare() after the device model per-device
.suspend() calls in order to fix some ACPI-related issues. Unfortu
--- Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-06-27 at 11:53 -0700, Casey Leedom wrote:
> > Sorry, my bad. I'm just diving into Linux for the first time and wasn't
> > aware of the protocols. Here's the code fragment I'm currently using:
>
> code fragments are only very limi
Greetings,
I have been troubleshooting a problem for over a year now, and to make a
long story short, I think the sata_sil driver has a bug during writing when
there are multiple cards that are using different models of SiI chips in the
system.
I will be watching the list, although cc'ing me
1 - 100 of 396 matches
Mail list logo