Jim Radford wrote:
...
This patch reverts d9a7ecacac5f8274d2afce09aadcf37bdb42b93a since it
breaks drivers that need to access the ->port[] array in shutdown
(most of them).
Patch applied, tested, works for me.
Signed-Off: Jim Radford <[EMAIL PROTECTED]>
Acked-by: Mark Lord <[EMAIL
On Tue, Mar 13, 2007 at 06:41:05PM +0300, Pavel Emelianov wrote:
> >>> PS: atomic_add_unless() didn't exist back then
> >>> (at least I think so) but that might be an option
> >>> too ...
> >> I think as far as having this discussion if you can remove that race
> >> people will be more willing to
The serial_txx9 driver have abused device numbers (major 4, minor 128)
if CONFIG_SERIAL_TXX9_STDSERIAL was not set. This patch makes the
driver allocate minor numbers from major 204 (Low-density serial
ports). I suppose a typical user of this driver set
CONFIG_SERIAL_TXX9_STDSERIAL to Y (i.e.
The current Linux scheduler makes one big assumption: that 1ms of CPU
time is the same as any other 1ms of CPU time, and that therefore a
process makes the same amount of progress regardless of which particular
ms of time it gets.
This assumption is wrong now, and will become more wrong as
On Tue, 13 Mar 2007, Jiri Slaby wrote:
> On 3/13/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> > I don't see anything in the UHCI snapshots to explain the difference in
> > behavior. One thing that stands out is the other, low-speed device (a
> > mouse?) -- in the bad kernel dump its driver was
On 3/12/2007, "David Miller" <[EMAIL PROTECTED]> wrote:
>From: Samuel Ortiz <[EMAIL PROTECTED]>
>Date: Mon, 12 Mar 2007 02:38:43 +0200
>
>> On Sat, Mar 10, 2007 at 07:43:26PM +0200, Samuel Ortiz wrote:
>> > Hi Dave,
>> >
>> > On Thu, Mar 08, 2007 at 05:54:36PM -0500, Dave Jones wrote:
>> > >
On Mon, Mar 12, 2007 at 06:12:26PM +0530, Srivatsa Vaddagiri wrote:
> I happened to read the entire thread (@ http://lkml.org/lkml/2007/3/1/159)
> all over again and felt it may be usefull to summarize the discussions so far.
>
> If I have missed any imp. points or falsely represented someone's
On 3/13/07, David Miller <[EMAIL PROTECTED]> wrote:
You're not even safe over standard output, simply run the program over
ssh and you suddenly have socket semantics to deal with.
I'm intimately familiar with this one. Easily worked around by piping
the output through cat or tee. Not that
On Mon, Mar 12, 2007 at 06:35:10PM -0400, Mark Lord wrote:>
Off topic: do your USB ports power off when the system shuts down?
Mine don't -- the +5V continues on them.. I'd love a tip on how to
turn them off completely at shutdown.
Most Asus boards have jumpers for the USB ports to select
Hi,
On Tue, Mar 13, 2007 at 04:51:39PM +0100, [EMAIL PROTECTED] wrote:
> Can you please try to compile without nohz and without hrtimers and try it
> again?
A colleage told me to try this yesterday and if I remember correctly, it did
not help. I may try it again because I'm not sure whether it
On Tue, Mar 13, 2007 at 09:07:09AM -0700, Chris Wright wrote:
> * Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> > In other words, regardless of whether this particular pv_op lives or
> > dies, we're going to need to have to deal with stolen time properly. I
> > think this hook is reasonable
Cc: Anssi Hannula <[EMAIL PROTECTED]>
On 3/7/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
On 3/7/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
> Dmitry Torokhov napsal(a):
> > Hi Jiri,
>
> Hi.
>
> > On 3/7/07, Jiri Slaby <[EMAIL PROTECTED]> wrote:
> >> add sensable phantom driver
> > ...
> >
> >
On 3/13/07, Alan Stern <[EMAIL PROTECTED]> wrote:
I don't see anything in the UHCI snapshots to explain the difference in
behavior. One thing that stands out is the other, low-speed device (a
mouse?) -- in the bad kernel dump its driver was running and in the good
kernel dump its driver wasn't.
On Wednesday 14 March 2007 03:03, Con Kolivas wrote:
> On Wednesday 14 March 2007 02:31, Con Kolivas wrote:
> > On Monday 12 March 2007 22:26, Al Boldi wrote:
> > > I think, it should be possible to spread this max expiration latency
> > > across the rotation, should it not?
> >
> > Can you try
On Tue, Mar 13, 2007 at 07:27:06AM +0530, Balbir Singh wrote:
> > hmm, it is very unlikely that this would happen,
> > for several reasons ... and indeed, checking the
> > thread in my mailbox shows that akpm dropped you ...
>
> But, I got Andrew's email.
>
> >
* Jeremy Fitzhardinge ([EMAIL PROTECTED]) wrote:
> In other words, regardless of whether this particular pv_op lives or
> dies, we're going to need to have to deal with stolen time properly. I
> think this hook is reasonable and useful step towards doing that.
Exactly. Normal interrupts we can
On Wednesday 14 March 2007 02:31, Con Kolivas wrote:
> On Monday 12 March 2007 22:26, Al Boldi wrote:
> > I think, it should be possible to spread this max expiration latency
> > across the rotation, should it not?
>
> Can you try the attached patch please Al and Mike? It "dithers" the
> priority
Nick Piggin <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>>
>> First touch page ownership does not guarantee give me anything useful
>> for knowing if I can run my application or not. Because of page
>> sharing my application might run inside the rss limit only because
>> I got lucky
On Mon, 12 Mar 2007, Jiri Slaby wrote:
> Alan, sorry for the previous bad post, I mismatched 2 files. This is
> hopefully correct.
>
> > thanks. Could you also please redo the test with the offending uhci patch
> > reverted and send the output of a working situation?
>
> - BAD kernel:
>
>
On Tue, Mar 13, 2007 at 05:23:52PM +1100, Rusty Russell wrote:
> On Tue, 2007-03-13 at 08:59 +1100, Rusty Russell wrote:
> > On Mon, 2007-03-12 at 10:48 +0100, Andi Kleen wrote:
> > > > Rusty's pda->per_cpu patch will deal with this once and for all; have
> > >
> > > Not on x86-64.
> >
> >
On Tue, Mar 13, 2007 at 06:41:05PM +0300, Pavel Emelianov wrote:
> > right, but atomic ops have much less impact on most
> > architectures than locks :)
>
> Right. But atomic_add_unless() is slower as it is
> essentially a loop. See my previous letter in this sub-thread.
If I am not mistaken,
On 3/13/07, Ash Milsted <[EMAIL PROTECTED]> wrote:
Desktop use whilst talking on Wengophone (run at nice -5): Under RSDL
some GUI use e.g. opening a new folder in nautilus causes pops (buffer
underruns) which do not occur with mainline. I suppose the changes in
RSDL might require a lower nice
On Mon, Mar 12, 2007 at 07:25:48PM -0700, Paul Menage wrote:
> On 3/12/07, Herbert Poetzl <[EMAIL PROTECTED]> wrote:
> >
> > why? you simply enter that specific space and
> > use the existing mechanisms (netlink, proc, whatever)
> > to retrieve the information with _existing_ tools,
>
> That's
> Subject : suspend/resume hangs until keypress
> References : http://bugzilla.kernel.org/show_bug.cgi?id=8181
> Submitter : Tomas Janousek <[EMAIL PROTECTED]>
> Status : unknown
Can you please try to compile without nohz and without hrtimers and try it
again?
This is maybe the same error i
On Tue, Mar 13, 2007 at 07:41:37PM +0530, Srivatsa Vaddagiri wrote:
> On Tue, Mar 13, 2007 at 02:55:05PM +0100, Herbert Poetzl wrote:
> > yes, tons of locking, complicated indirections and
> > a lot of (partially hard to understand) code ...
>
> Are you referring to these issues in the general
On Wednesday 14 March 2007 02:35, Ash Milsted wrote:
> Here's my experience with RSDL 0.30 on 2.6.21-rc3-git6 under my normal
> usage scenarios...
>
> Plain desktop use (web browsing, music, etc): no noticeable change
>
> Desktop use during kernel compile (no -j): The compile impacts desktop
> use
Herbert,
>>Just curious why current vserver code kills arbitrary
>>task in container then?
>
>
> because it obviously lacks the finess of OpenVZ code :)
>
> seriously, handling the OOM kills inside a container
> has never been a real world issue, as once you are
> really out of memory (and OOM
Greg KH wrote:
>>[NETFILTER]: nfnetlink_log: fix reference counting
>>
> As this patch does nothing, it's now dropped. It was my fault as the
> original patch didn't apply and I messed up using quilt here.
Sorry, I must have messed up something. I've fixed up the original
patch, this one should
>>> PS: atomic_add_unless() didn't exist back then
>>> (at least I think so) but that might be an option
>>> too ...
>> I think as far as having this discussion if you can remove that race
>> people will be more willing to talk about what vserver does.
>
> well, shouldn't be a big deal to brush
Quoting Mimi Zohar ([EMAIL PROTECTED]):
> On Thu, 2007-03-08 at 22:19 -0500, [EMAIL PROTECTED] wrote:
> > On Thu, 08 Mar 2007 17:58:16 EST, Mimi Zohar said:
> > > This is a request for comments for a new Integrity Based Access
> > > Control(IBAC) LSM module which bases access control decisions
> >
> "Serge" == Serge Belyshev <[EMAIL PROTECTED]> writes:
Serge> Mike Galbraith <[EMAIL PROTECTED]> writes:
Serge> [snip]
>> It seems to be a plain linear slowdown. The lurchiness I'm experiencing
>> varies in intensity, and is impossible to quantify. I see neither
>> lurchiness nor slowdown
On Fri, Mar 09, 2007 at 06:41:45PM +0100, Jiri Slaby wrote:
> Hi.
>
> I got this message after suspend;resume on my notebook
> Clocksource tsc unstable (delta = -154983451 ns)
>
I am getting the exact same line on bootup on my Fujitsu Siemens
Lifebook E8110. After that line the boot halts with
On Tue, Mar 13, 2007 at 09:55:41AM -0400, Mark Lord wrote:
> Jim Radford wrote:
> >On Mon, Mar 12, 2007 at 09:55:14PM -0400, Mark Lord wrote:
> >
> >>So where does the memory get freed -- the structure pointed at
> >>by the serial->port[i] thingie ? It's not a leak, is it?
> >
> >It gets free'd
On Monday 12 March 2007 22:26, Al Boldi wrote:
> I think, it should be possible to spread this max expiration latency across
> the rotation, should it not?
Can you try the attached patch please Al and Mike? It "dithers" the priority
bitmap which tends to fluctuate the latency a lot more but in a
On Mon, Mar 12, 2007 at 06:35:10PM -0400, Mark Lord wrote:
> Is that a PATA cd-drive? If so, then you must have hooked it up
> to the JMicron IDE controller. That driver is just plain buggy.
>
> I gave up on it for my own P5B-VM. The libata version works better
> than the drivers/ide, but I
On Mon, 12 Mar 2007 10:58:11 +1100
Con Kolivas <[EMAIL PROTECTED]> wrote:
> There are updated patches for 2.6.20, 2.6.20.2, 2.6.21-rc3 and 2.6.21-rc3-mm2
> to bring RSDL up to version 0.30 for download here:
>
> Full patches:
>
>
Paul Mackerras wrote:
> There is a fundamental problem with using __thread, which is that gcc
> assumes that the addresses of __thread variables are constant within
> one thread, and that therefore it can cache the result of address
> calculations. However, with preempt, threads in the kernel
Herbert Poetzl wrote:
> On Tue, Mar 13, 2007 at 10:17:54AM +0300, Pavel Emelianov wrote:
>> Herbert Poetzl wrote:
>>> On Mon, Mar 12, 2007 at 12:02:01PM +0300, Pavel Emelianov wrote:
>>> Maybe you have some ideas how we can decide on this?
>> We need to work out what the requirements are
Eric,
>>>And misses every resource sharing opportunity in sight.
>>
>>that was my point too.
>>
>>
>>>Except for
>>>filtering the which pages are eligible for reclaim an RSS limit should
>>>not need to change the existing reclaim logic, and with things like the
>>>memory zones we have had that
Andi Kleen wrote:
> On Thu, Mar 01, 2007 at 06:54:24PM -0800, Zachary Amsden wrote:
>
>> The custom_sched_clock hook is broken. The result from sched_clock needs to
>> be
>> in nanoseconds, not in CPU cycles. The TSC is insufficient for this purpose,
>> because TSC is poorly defined in a
On Tue, Mar 13, 2007 at 03:09:06AM -0600, Eric W. Biederman wrote:
> Herbert Poetzl <[EMAIL PROTECTED]> writes:
>
> > On Sun, Mar 11, 2007 at 01:00:15PM -0600, Eric W. Biederman wrote:
> >> Herbert Poetzl <[EMAIL PROTECTED]> writes:
> >>
> >> >
> >> > Linux-VServer does the accounting with
> * Mike Galbraith <[EMAIL PROTECTED]> wrote:
>
> > [...] The situation as we speak is that you can run cpu intensive
> > tasks while watching eye-candy. With RSDL, you can't, you feel the
> > non-interactive load instantly. [...]
>
> i have to agree with Mike that this is a material regression
> Subject: AMD Elan: Crash after "Allocating PCI resources"
> References : http://bugzilla.kernel.org/show_bug.cgi?id=8161
> Submitter : Vladimir Brik <[EMAIL PROTECTED]>
> Handled-By : Andi Kleen <[EMAIL PROTECTED]>
> Status : problem is being debugged
It uses RDTSC when it shouldn't.
On Tue, Mar 13, 2007 at 06:10:55PM +0300, Kirill Korotaev wrote:
> >>So what to do when virtual physical limit is hit?
> >>OOM-kill current task?
> >
> >
> > when the RSS limit is hit, but there _are_ enough
> > pages left on the physical system, there is no
> > good reason to swap out the page
On Tue, Mar 13, 2007 at 10:17:54AM +0300, Pavel Emelianov wrote:
> Herbert Poetzl wrote:
> > On Mon, Mar 12, 2007 at 12:02:01PM +0300, Pavel Emelianov wrote:
> > Maybe you have some ideas how we can decide on this?
> We need to work out what the requirements are before we can
>
On Tue. 6 Mar 2007, Hugh Dickins wrote:
> But suspend to RAM still hanging, unless I "chmod a-x /usr/sbin/docker"
> on SuSE 10.2: docker undock tries to unregister /sys/block/sr0 and hangs:
>
> 60x60 D B0415080 0 10778 10771 (NOTLB)
>e8227e04 0086
On Tue, Mar 13, 2007 at 03:48:34AM -0800, Andrew Morton wrote:
> > On Tue, 13 Mar 2007 13:19:53 +0300 Kirill Korotaev <[EMAIL PROTECTED]>
> > wrote:
> > Andrew Morton wrote:
> > - shared mappings of 'shared' files (binaries
> > and libraries) to allow for reduced memory
> >
>>So what to do when virtual physical limit is hit?
>>OOM-kill current task?
>
>
> when the RSS limit is hit, but there _are_ enough
> pages left on the physical system, there is no
> good reason to swap out the page at all
>
> - there is no benefit in doing so (performance
>wise, that is)
On Tue, Mar 13, 2007 at 12:08:28AM -0400, Dave Jones wrote:
> I spent considerable time over the last day or so bisecting to
> find out why an X60 stopped resuming somewhen between 2.6.20 and current -git.
> (Total lockup, black screen of death).
>
> The bisect log looked like this.
>
...
> Any
On Tue, Mar 13, 2007 at 10:33:18AM +0100, Mike Galbraith wrote:
> On Tue, 2007-03-13 at 09:18 +0100, Ingo Molnar wrote:
>
> > Con, we want RSDL to /improve/ interactivity. Having new scheduler
> > interactivity logic that behaves /worse/ in the presence of CPU hogs,
> > which CPU hogs are even
> From: Hansen donotmail <[EMAIL PROTECTED]>
> To: Herbert Poetzl <[EMAIL PROTECTED]>
> Cc: Andrew Morton <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED], linux-kernel@vger.kernel.org,
> [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: [RFC][PATCH 2/7] RSS controller core
> Date: Mon, 12 Mar 2007
WARN_ON(de && de->deleted); is sooo unreliable. Why?
proc_lookup remove_proc_entry
=== =
lock_kernel();
spin_lock(_subdir_lock);
[find proc entry]
spin_unlock(_subdir_lock);
Linus,
The following kvm stability and correctness fixes since commit
8b9909ded6922c33c221b105b26917780cfa497d:
Linus Torvalds (1):
Merge branch 'merge' of master.kernel.org:/.../paulus/powerpc
are found in the 'linus' branch of the git repository at:
Lundi 12 mars 2007, vers 20:16:30 (+0100), H. Peter Anvin a écrit:
> This script cleans up various classes of stealth whitespace. In
> particular, it cleans up:
>
> - Whitespace (spaces or tabs)before newline;
> - DOS line endings (CR before LF);
> - Space before tab (spaces are deleted or
On Tue, Mar 13, 2007 at 01:39:12AM -0700, Roland McGrath wrote:
> The OPEN_MAX constant is an arbitrary number with no useful relation to
> anything. Nothing should be using it. This patch changes SCM_MAX_FD to
> use NR_OPEN instead of OPEN_MAX. This increases the size of the struct
>
On Tue, Mar 13, 2007 at 02:55:05PM +0100, Herbert Poetzl wrote:
> yes, tons of locking, complicated indirections and
> a lot of (partially hard to understand) code ...
Are you referring to these issues in the general Paul Menage's container code
or in the RSS-control code posted by Pavel?
--
On Tue, 2007-03-13 at 02:24 +, Alan Cox wrote:
> > purports to handle short writes but has never been exercised is
> > arguably worse than code that simply bombs on short write. So if I
> > can't shim in an induce-short-writes-randomly-on-purpose mechanism
> > during development, I don't want
On Thu, Mar 01, 2007 at 06:54:24PM -0800, Zachary Amsden wrote:
> The custom_sched_clock hook is broken. The result from sched_clock needs to
> be
> in nanoseconds, not in CPU cycles. The TSC is insufficient for this purpose,
> because TSC is poorly defined in a virtual environment, and mostly
On Wed, 31 Jan 2007, Geert Uytterhoeven wrote:
> Move the external declarations for the various linux logo structures to
> . As a consequence, I had to remove the `const', as
> `const'
> is incompatible with `__initdata'.
>
> Signed-off-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
> ---
>
Jim Radford wrote:
On Mon, Mar 12, 2007 at 09:55:14PM -0400, Mark Lord wrote:
So where does the memory get freed -- the structure pointed at
by the serial->port[i] thingie ? It's not a leak, is it?
It gets free'd through device_unregister
for (i = 0; i < num_ports; ++i) {
...
On Tue, Mar 13, 2007 at 11:28:06AM +0300, Kirill Korotaev wrote:
> >>>well, Linux-VServer is "working", "secure", "flexible"
> >>>_and_ non-intrusive ... it is quite natural that less
> >>>won't work for me ... and regarding patches, there
> >>>will be a 2.2 release soon, with all the patches ...
Am Dienstag, 13. März 2007 14:39 schrieb Mark Lord:
> Oliver Neukum wrote:
> >
> > If we get to destroy_serial(), how can ports still be open?
>
> (1) open up a ckermit session on /dev/usb_serial_port_0.
> (2) suspend the machine (to RAM).
> (3) the suspend logic "removes" all USB devices.
No,
On Tue, Mar 13, 2007 at 05:39:36PM +1100, Rusty Russell wrote:
> GCC (4.1 at least) unrolls it anyway, but I can't believe this code
Are you sure? Normally it doesn't unroll without -funroll-loops which
the kernel does normally not set. Especially not with -Os builds.
-Andi
-
To unsubscribe from
At Tue, 13 Mar 2007 13:49:57 +0100,
Adrian Bunk wrote:
>
> Subject: snd-intel8x0: no 3d surround sound
> References : http://lkml.org/lkml/2007/3/5/164
> Submitter : Michal Piotrowski <[EMAIL PROTECTED]>
> Caused-By : Randy Cushman <[EMAIL PROTECTED]>
> commit
Oliver Neukum wrote:
If we get to destroy_serial(), how can ports still be open?
(1) open up a ckermit session on /dev/usb_serial_port_0.
(2) suspend the machine (to RAM).
(3) the suspend logic "removes" all USB devices.
Cheers
-
To unsubscribe from this list: send the line "unsubscribe
Am Dienstag, 13. März 2007 14:08 schrieb Pierre Ossman:
> Adrian Bunk wrote:
> >
> > Subject: mmc card reader no longer works
> > References : http://lkml.org/lkml/2007/2/27/91
> > Submitter : Pavel Machek <[EMAIL PROTECTED]>
> > Handled-By : Oliver Neukum <[EMAIL PROTECTED]>
> > Status
Cornelia Huck wrote:
On Tue, 13 Mar 2007 13:50:03 +0100,
Adrian Bunk <[EMAIL PROTECTED]> wrote:
Subject: ThinkPad X60: bluetooth hardlocks
References : http://lkml.org/lkml/2007/3/2/85
Submitter : Pavel Machek <[EMAIL PROTECTED]>
Handled-By : Marcel Holtmann <[EMAIL PROTECTED]>
Status
On Tue, Mar 13, 2007 at 01:50:16PM +0100, Adrian Bunk wrote:
> Subject: suspend to disk breaks ACPI
> References : http://lkml.org/lkml/2007/3/5/127
> Submitter : Lukas Hejtmanek <[EMAIL PROTECTED]>
> Status : unknown
seems to be fixed in 2.6.21-rc3
--
Lukáš Hejtmánek
-
To unsubscribe
On Tue, 13 Mar 2007 13:50:03 +0100,
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Subject: ThinkPad X60: bluetooth hardlocks
> References : http://lkml.org/lkml/2007/3/2/85
> Submitter : Pavel Machek <[EMAIL PROTECTED]>
> Handled-By : Marcel Holtmann <[EMAIL PROTECTED]>
> Status : unknown
On Tue, Mar 13, 2007 at 10:22:53AM +0100, Rafael J. Wysocki wrote:
> On Tuesday, 13 March 2007 05:08, Dave Jones wrote:
> > I spent considerable time over the last day or so bisecting to
> > find out why an X60 stopped resuming somewhen between 2.6.20 and current
> > -git.
> > (Total lockup,
Adrian Bunk wrote:
>
> Subject: mmc card reader no longer works
> References : http://lkml.org/lkml/2007/2/27/91
> Submitter : Pavel Machek <[EMAIL PROTECTED]>
> Handled-By : Oliver Neukum <[EMAIL PROTECTED]>
> Status : unknown
>
First I heard of this. The error report is a bit thin so
On 3/13/07, Willy Tarreau <[EMAIL PROTECTED]> wrote:
On Tue, Mar 13, 2007 at 02:05:23PM +1100, Con Kolivas wrote:
> On Tuesday 13 March 2007 10:46, David Miller wrote:
> > From: Con Kolivas <[EMAIL PROTECTED]>
> > Date: Mon, 12 Mar 2007 10:58:11 +1100
> >
> > >
> Subject: libata: PATA UDMA/100 configured as UDMA/33
> References : http://lkml.org/lkml/2007/2/20/294
>
> http://www.mail-archive.com/linux-ide@vger.kernel.org/msg04115.html
> http://bugzilla.kernel.org/show_bug.cgi?id=8133
>
> On Tue, 13 Mar 2007 13:45:06 +0100 Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Tuesday 13 March 2007 07:46, Zachary Amsden wrote:
> > Andrew Morton wrote:
> > > Really truly? I think we have a _lot_ of declarations which omit the
> > > section qualifier altogether. How come they don't all
Tejun Heo a écrit :
> > Mathieu Bérard wrote:
>> >> Jeff Garzik a écrit :
>>> >>> Adrian Bunk wrote:
Subject: NCQ problem with ahci and Hitachi drive
References : http://lkml.org/lkml/2007/3/4/178
Submitter : Mathieu Bérard <[EMAIL PROTECTED]>
Status
CC [M] sound/pci/ice1712/ice1712.o
sound/pci/ice1712/ice1712.c:290: error: snd_ice1712_mixer_digmix_route_ac97
causes a section type conflict
sound/pci/ice1712/ice1712.c:1630: error: snd_ice1712_eeprom causes a section
type conflict
sound/pci/ice1712/ice1712.c:1894: error:
On Tue, Mar 13, 2007 at 05:33:09AM -0700, Randy.Dunlap wrote:
> On Tue, 13 Mar 2007, Glauber de Oliveira Costa wrote:
>
> > Tiny cleanup:
> >
> > In x86_64, the same functions for reading cr3 and writing cr{3,4} are
> > defined in tlbflush.h and system.h, whith just a name change.
> > The only
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly
This email lists some known regressions in Linus' tree compared to 2.6.20.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way
possibly
On Tuesday 13 March 2007 07:46, Zachary Amsden wrote:
> Andrew Morton wrote:
> > Really truly? I think we have a _lot_ of declarations which omit the
> > section qualifier altogether. How come they don't all break too?
>
> User build was smoking this:
>
> make O=build -j16
>
> This and
On Sat, Mar 10, 2007 at 11:16:39PM +0100, Pavel Machek wrote:
> Hi!
>
> > I'm not sure what version did exacly caused susped to disk problems but
> > anyway, in 2.6.21-rc2-git1, suspend to disk breaks ACPI. ACPI events do not
> > even emit ACPI interrupts. Suspend to ram works nicely.
>
> Is
> Ah, that's a nasty part of C const. It should be like
> const struct snd_ice1712_card_info *c;
> but for pointer-of-pointer, something like
> struct snd_ice1712_card_info * const *tbl;
Well, that works.
Andrew, I'm going to post an updated patch in separate email.
Ralf
-
To
Can you apply the attached patch and report what the kernel says with
ACPI turned on?
--
tejun
diff --git a/drivers/ata/libata-acpi.c b/drivers/ata/libata-acpi.c
index 019d8ff..6a27a7f 100644
--- a/drivers/ata/libata-acpi.c
+++ b/drivers/ata/libata-acpi.c
@@ -473,8 +473,8 @@ static void
On Tue, 13 Mar 2007 13:13:12 +0100 (CET)
[EMAIL PROTECTED] wrote:
> Hi,
> I reported this also for 2.6.20 kernel.
> new libata with controller nVidia CK804 initializes the disk in DMA/33,
> with with 2.6.19.5 and previous the disk is correctly inizialized in
> DMA/100.
> Tha cable is OK, and
On Tue, 13 Mar 2007, Mockern wrote:
> Hi,
>
> I use kthread in my driver. The problem is that I can't kill process
> with kill_proc function. After rmmod my_driver, ps command shows again SW
> my_driver.
>
> How can I remove this process?
>
> Thank you
>
You need to follow the procedures used
Tiny cleanup:
In x86_64, the same functions for reading cr3 and writing cr{3,4} are
defined in tlbflush.h and system.h, whith just a name change.
The only difference is the clobbering of memory, which seems a safe, and
even needed change for the write_cr4. This patch removes the duplicate.
On Tue, Mar 13, 2007 at 01:02:44PM +0100, Eric Dumazet wrote:
> On Tuesday 13 March 2007 12:42, Andrea Arcangeli wrote:
>
> > My wild guess is that they're allocating memory after taking
> > futexes. If they do, something like this will happen:
> >
> > taskA taskB taskC
>
Andrew Morton wrote:
On Tue, 13 Mar 2007 23:01:11 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
Andrew Morton wrote:
It would be interesting to look at a) leave the page full of random garbage
if we're releasing the whole mm and b) return it straight to the page allocator.
Well we have the
[EMAIL PROTECTED] wrote:
> Hi,
> I reported this also for 2.6.20 kernel.
> new libata with controller nVidia CK804 initializes the disk in DMA/33,
> with with 2.6.19.5 and previous the disk is correctly inizialized in
> DMA/100.
> Tha cable is OK, and with older kernels the disks runs without
Hi,
I reported this also for 2.6.20 kernel.
new libata with controller nVidia CK804 initializes the disk in DMA/33,
with with 2.6.19.5 and previous the disk is correctly inizialized in
DMA/100.
Tha cable is OK, and with older kernels the disks runs without troubles.
The sistem has two sata
> But on that note -- do you have any idea how one might get ltrace to
> work on a multi-threaded program, or how one might enhance it to
> instrument function calls from one shared library to another? Or
I don't know a vast amount about ARM ELF user space so no.
> better yet, can you advise me
Andrea Arcangeli wrote:
On Tue, Mar 13, 2007 at 10:12:19PM +1100, Nick Piggin wrote:
They'll be sleeping in futex_wait in the kernel, I think. One thread
will hold the critical mutex, some will be off doing their own thing,
but importantly there will be many sleeping for the mutex to become
> On Tue, 13 Mar 2007 23:01:11 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> >>On Tue, 13 Mar 2007 22:30:19 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
> >>We don't actually have to zap_pte_range the entire page table in
> >>order to free it (IIRC we used to have to,
On Tue, 13 Mar 2007 01:00:50 -0700 (PDT)
Roland McGrath <[EMAIL PROTECTED]> wrote:
> > Well, I can add in the test for 0, but finding the set of always-on bits
> > in DR6 will have to be done separately. Isn't it possible that different
> > CPUs could have different bits?
>
> I don't know, but
On Tuesday 13 March 2007 12:42, Andrea Arcangeli wrote:
> My wild guess is that they're allocating memory after taking
> futexes. If they do, something like this will happen:
>
> taskAtaskB taskC
> user lock
> mmap_sem lock
> mmap sem ->
Andrew Morton wrote:
On Tue, 13 Mar 2007 22:30:19 +1100 Nick Piggin <[EMAIL PROTECTED]> wrote:
We don't actually have to zap_pte_range the entire page table in
order to free it (IIRC we used to have to, before the 4lpt patches).
I'm trying to remember why we ever would have needed to zero out
201 - 300 of 802 matches
Mail list logo
