Hi,
>> Sat, 24 Mar 2007 14:22:53 -0700
>> [Subject: (usagi-core 32638) Re: [linux-usb-devel] [PATCH 0/2] [SERIAL]
>> [USB] fixed to skip NULL entry in struct serial usb_serial_port.]
>> Greg KH <[EMAIL PROTECTED]> wrote...
> This should already be fixed in the -git snapshots that have come out
vatsa wrote:
> Not just this, continuing further we have more trouble:
>
>
> CPU0 (attach_task T1 to CS2) CPU1 (T1 is exiting)
>
>
>
Hi Pete,
On Monday 19 March 2007 21:02, Pete Zaitcev wrote:
> On Wed, 7 Mar 2007 17:23:05 -0500, "Dmitry Torokhov" <[EMAIL PROTECTED]>
> wrote:
>
> > It seems that if a process keeps a character device open then other
> > processes will also be able to get into filp->f_op->open(inode,filp)
> >
On 3/25/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
On Sunday 25 March 2007 01:27, Parag Warudkar wrote:
> >
> > Actually the keyboard driver should not emit input events for that key code.
> > Is this a USB keyboard?
> >
> > --
> > Dmitry
> >
>
> Yes this is a USB keyboard.
>
> Any hint as
OK, another data point. The config below boots and works with
2.6.21-rc4-rt1, but enabling CONFIG_CRITICAL_IRQSOFF_TIMING causes the
early boot hang.
Any idea?
Thanks,
Roland
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.21-rc4-rt1
# Sat Mar 24 22:06:44 2007
On Sunday 25 March 2007 01:27, Parag Warudkar wrote:
> >
> > Actually the keyboard driver should not emit input events for that key code.
> > Is this a USB keyboard?
> >
> > --
> > Dmitry
> >
>
> Yes this is a USB keyboard.
>
> Any hint as to where I should start looking to make the driver not
>
Actually the keyboard driver should not emit input events for that key code.
Is this a USB keyboard?
--
Dmitry
Yes this is a USB keyboard.
Any hint as to where I should start looking to make the driver not
emit input event for keycode==0?
Parag
-
To unsubscribe from this list: send the
On Saturday 24 March 2007 23:38, Parag Warudkar wrote:
>
> >
> > Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]>
> >
> > --- linux-2.6-wk/drivers/char/keyboard.c2007-03-24 23:01:19.0
> > -0400
> > +++ linux-2.6/drivers/char/keyboard.c 2007-03-24 21:43:58.0
> > -0400
David Miller <[EMAIL PROTECTED]> writes:
> Furthermore, his scripts don't even execute properly when
> I try to run them myself, for example server.py gives me
> this syntax error when python tries to parse the script:
>
> [EMAIL PROTECTED]:~/src/GIT/net-2.6$ /usr/bin/python server.py
> File
> So what gcc does may be technically legal, but it's still a horribly
> bad thing to do. Sadly, some gcc people seem to care more
> about "letter
> of the law" than "sanity and quality of implementation".
You know, it would be one thing if they were consistent. A policy that, by
default, you
> I will try to send out a patch later today to fix
Thanks!
> Agreed, but good to keep code clean isn't it? :)
Definitely.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
On Sat, Mar 24, 2007 at 09:45:50PM -0700, Paul Jackson wrote:
> Nice work - thanks. Yes, both an extra cpuset count and a negative
> cpuset count are bad news, opening the door to the usual catastrophes.
>
> Would you like the honor of submitting the patch to add a task_lock
> to cpuset_exit()?
vatsa wrote:
> Now consider:
Nice work - thanks. Yes, both an extra cpuset count and a negative
cpuset count are bad news, opening the door to the usual catastrophes.
Would you like the honor of submitting the patch to add a task_lock
to cpuset_exit()? If you do, be sure to fix, or at least
From: Adrian Bunk <[EMAIL PROTECTED]>
Date: Fri, 23 Mar 2007 19:48:17 +0100
> Subject: problem with sockets
> References : http://lkml.org/lkml/2007/3/21/248
> Submitter : Jose Alberto Reguero <[EMAIL PROTECTED]>
> Status : unknown
Not enough information in his report, for example for
On Sun, 25 Mar 2007 03:42:25 + "yuan cooper" <[EMAIL PROTECTED]> wrote:
> Hi all:
>
> during my work, I found there is a bug with GCC4 O2 optimization.
>
> -
> float ftmp;
> unsigned long tmp;
> ftmp = 1.0/1024.0;
> tmp = *(unsigned long *)();
> tmp = (tmp >> 11) &&
On Sun, 25 Mar 2007 04:21:56 +0200 Herbert Poetzl <[EMAIL PROTECTED]> wrote:
> > a) slice the machine into 128 fake NUMA nodes, use each node as the
> >basic block of memory allocation, manage the binding between these
> >memory hunks and process groups with cpusets.
>
> 128 sounds a
On Sun, 25 Mar 2007, yuan cooper wrote:
> �
> during my work, I found�there is a bug with GCC4 O2 optimization.
Technically, it's a misfeature fo gcc4, not a bug.
The C language allows for type-based alias detection, and gcc notices that
a "float *" cannot ever alias with a "unsigned long *",
On Sun, Mar 25, 2007 at 07:58:16AM +0530, Srivatsa Vaddagiri wrote:
> Not just this, continuing further we have more trouble:
>
>
> CPU0 (attach_task T1 to CS2) CPU1 (T1 is exiting)
>
Thomas Meyer <[EMAIL PROTECTED]> writes:
> Eric W. Biederman schrieb:
>>
>> Odd. I would have thought the oops happened in the first resume, not
>> the second.
>>
>> Hmm. It may have something to do with the ``managed'' driver
>> aspect of this as well..
>>
> No. I don't think so. The
Signed-off-by: Parag Warudkar <[EMAIL PROTECTED]>
--- linux-2.6-wk/drivers/char/keyboard.c 2007-03-24 23:01:19.0
-0400
+++ linux-2.6/drivers/char/keyboard.c 2007-03-24 21:43:58.0 -0400
@@ -1161,7 +1161,7 @@
if ((raw_mode = (kbd->kbdmode == VC_RAW)) && !hw_raw)
I use Apple keyboard and mouse which seem to generate events with
keycode==0.
keyboard.c floods dmesg endlessly with below messages. This happens at a
very fast rate and never stops, leaving the dmesg unusable.
[46591.96] keyboard.c: can't emulate rawmode for keycode 0
[46591.996000]
On Sat, Mar 24, 2007 at 12:19:06PM -0800, Andrew Morton wrote:
> On Sat, 24 Mar 2007 19:38:06 +0100 Herbert Poetzl <[EMAIL PROTECTED]> wrote:
>
> > On Fri, Mar 23, 2007 at 09:42:35PM -0800, Andrew Morton wrote:
> > > On Fri, 23 Mar 2007 20:30:00 +0100 Herbert Poetzl <[EMAIL PROTECTED]>
> > >
On Sat, Mar 24, 2007 at 06:41:28PM -0700, Paul Jackson wrote:
> > the following code becomes racy with cpuset_exit() ...
> >
> > atomic_inc(>count);
> > rcu_assign_pointer(tsk->cpuset, cs);
> > task_unlock(tsk);
>
> eh ... so ... ?
>
> I don't know of any sequence where
On Sunday 25 March 2007 11:59, Con Kolivas wrote:
> For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
>
> ---
> Currently we only do cpu accounting to userspace based on what is actually
> happening precisely on each tick. The accuracy of that accounting gets
> progressively worse the
Hello,
[ ... fixed one minor typo and adapted the word order ... ]
--- linux-2.6.20-o/drivers/isdn/capi/Kconfig2007-03-18
00:04:54.0 +0100
+++ linux-2.6.20/drivers/isdn/capi/Kconfig2007-03-25
04:10:24.0 +0200
@@ -17,7 +17,7 @@
help
If you say Y here, the
> I don't understand your need to try to rush an api change like this in
> so quickly in an area that has a lot of churn and disagreement lately.
> _Especially_ so late in the release cycle, and with no hardware publicly
> availble.
I'm not sure I understood this thread properly, but if I did
For an rsdl 0.33 patched kernel. Comments? Overhead worth it?
---
Currently we only do cpu accounting to userspace based on what is actually
happening precisely on each tick. The accuracy of that accounting gets
progressively worse the lower HZ is. As we already keep accounting of
nanosecond
I some circumstances, mincore can succeed when it shouldn't.
Example:
Two files are mmapped to a process and they are adjacent in memory.
If mincore is run with a requested length that is too large, the
function does not differentiate between the different file pointers
within the different vma
vatsa wrote:
> > if (tsk->flags & PF_EXITING) {
>
> What if PF_EXITING is set after this check? If that happens then,
>
> > task_unlock(tsk);
> > mutex_unlock(_mutex);
> > put_task_struct(tsk);
> > return -ESRCH;
> >
Hello,
[ ... Fixed two minor typos. ...]
The following patch is against 2.6.21-rc4:
--- linux-2.6.20-o/drivers/block/Kconfig2007-03-18 00:04:53.0
+0100
+++ linux-2.6.20/drivers/block/Kconfig 2007-03-25 03:35:19.0 +0200
@@ -383,7 +383,7 @@
default "16"
Hello,
this is just a QA / cosmetic fix .. nevertheless the documentation about
modules / drivers should be appropriate to the great work of those who
write all the real important stuff. :-)
The following patch is against 2.6.21-rc4:
--- linux-2.6.20-o/drivers/block/Kconfig2007-03-18
On Friday 23 March 2007 16:42:44 Rafael J. Wysocki wrote:
> On Friday, 23 March 2007 00:30, Rafael J. Wysocki wrote:
> > On Thursday, 22 March 2007 00:53, Rafael J. Wysocki wrote:
> > > On Thursday, 22 March 2007 00:39, Maxim wrote:
> > > > On Thursday 22 March 2007 01:24:25 Rafael J. Wysocki
On Sat, Mar 10, 2007 at 10:55:16AM -0500, Ryan Hope wrote:
> Ever since I started playing with suspend I started turning on PCI Hot
> Plug support since then I have been seeing messages like whats
> below from dmesg I'm not exactly sure how this actually impacts me
> if it does at all. I
On Sat, Mar 24, 2007 at 12:25:59PM -0700, Paul Jackson wrote:
> > P.S : cpuset.c checks for PF_EXITING twice in attach_task(), while this
> > patch seems to be checking only once. Is that fine?
>
> I think the cpuset code is ok, because, as you note, it locks the task,
> picks off the cpuset
On 3/23/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
@@ -1383,7 +1380,7 @@ int loop_unregister_transfer(int number)
xfer_funcs[n] = NULL;
- for (lo = _dev[0]; lo < _dev[max_loop]; lo++) {
+ list_for_each_entry(lo, _devices, lo_list) {
On 3/23/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
Sadly, it locks up the foreground process (losetup that would be), and I
have not yet figured out why. And the mpt regression elsewhere is
hindering me in finding out faster.
You need to tell the block layer that each loop device is a whole
This is the Trec driver, Makefile, header files.
Enable trec in Kernel hacking configuration menu.
Signed-off-by: Wink Saville <[EMAIL PROTECTED]>
---
drivers/Makefile |1 +
drivers/trec/Makefile |5 +
drivers/trec/trec.c| 404
Trec's are initialized early in main.c and then dump
trec's in die(), panic() and do_page_fault().
Signed-off-by: Wink Saville <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/traps.c |5 +
arch/x86_64/mm/fault.c |6 ++
init/main.c|4
kernel/panic.c
Trec is a light weight tracing mechanism that places
trace information into a buffer. The contents of the
buffer is dumped when errors occurs or when enabled
via SYSRQ commands.
Signed-off-by: Wink Saville <[EMAIL PROTECTED]>
---
Documentation/trec.txt | 87
I have some doubts about the loop to find the gfporder of a cache. For
the code below, its main purpose is to find a gfporder value that can
make the internal fragmentation less that 1/8 of the total slab size.
It is done by increase gfporder for low number to high(possibly 0 to
MAX_GFP_ORDER).
On Sat, Mar 24, 2007 at 04:33:41PM -0700, Kok, Auke wrote:
> Greg KH wrote:
> >On Fri, Mar 23, 2007 at 05:28:02PM -0700, Greg KH wrote:
> >>On Fri, Mar 23, 2007 at 05:24:23PM -0700, Williams, Mitch A wrote:
> >>>Greg KH wrote:
> Well, I'm sure you can agree that it is _very_ late in the 2.6.21
Greg KH wrote:
On Fri, Mar 23, 2007 at 05:28:02PM -0700, Greg KH wrote:
On Fri, Mar 23, 2007 at 05:24:23PM -0700, Williams, Mitch A wrote:
Greg KH wrote:
Well, I'm sure you can agree that it is _very_ late in the 2.6.21
release cycle to expect to get this in for that kernel. How about
Hello,
this is just a QA / cosmetic fix .. nevertheless the documentation about
modules / drivers should be appropriate to the great work of those who
write all the real important stuff. :-)
The following patch is against 2.6.21-rc4:
--- /root/dev/linux-2.6.20-o/net/ieee80211/Kconfig
Location:
ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/
git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
Changes since 2.6.16.44:
Adrian Bunk (1):
Linux 2.6.16.45-rc1
Alexey Dobriyan (1):
[NET]: Copy mac_len in
On Wed, Mar 21, 2007 at 11:39:17PM -0800, Andrew Morton wrote:
> On Wed, 21 Mar 2007 15:22:25 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > With the latest -mm, I'm now getting this:
> >
> > Mar 21 15:06:52 cinder kernel: ipw2200: Detected Intel PRO/Wireless
> > 2200BG Network Connection
>
* Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> >+static int tsc_enabled;
>
> So, now we have tsc_disable, tsc_enabled and tsc_unstable. I can
> understand the latter, but this lacks orthogonality IMHO.
tsc_disable should be renamed to tsc_disable_override or so, to signal
that it's only
+static int tsc_enabled;
So, now we have tsc_disable, tsc_enabled and tsc_unstable.
I can understand the latter, but this lacks orthogonality IMHO.
--
Guillaume
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
* Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> commit f9690982b8c2f9a2c65acdc113e758ec356676a3 removed the check for
> cpu_khz from sched_clock(), which prevented early access to the TSC by
> non obvious magic.
>
> This is harmless as long as the CPU has a TSC. On TSCless systems this
>
Justin Piszcz wrote:
Without NCQ, performance is MUCH better on almost every operation, with
the exception of 2-3 items.
/usr/sbin/bonnie++ -d /x/bonnie -s 7952 -m p34 -n 16:10:16:64 >
run.txt;
# Average of 3 runs with NCQ on for Quad Raptor ADFD 150 RAID 5 Software
RAID:
From: Miklos Szeredi <[EMAIL PROTECTED]>
Changes:
v3:
o rename is_page_modified to test_clear_page_modified
v2:
o set AS_CMTIME flag in clear_page_dirty_for_io() too
o don't clear AS_CMTIME in file_update_time()
o check the dirty bit in the page tables
v1:
o moved check from __fput() to
From: Miklos Szeredi <[EMAIL PROTECTED]>
Dirty page accounting/limiting doesn't work for nonlinear mappings, so
for non-ram backed filesystems emulate with linear mappings. This
retains ABI compatibility with previous kernels at minimal code cost.
All known users of nonlinear mappings actually
From: Miklos Szeredi <[EMAIL PROTECTED]>
This is a straightforward split of do_mmap_pgoff() into two functions:
- do_mmap_pgoff() checks the parameters, and calculates the vma
flags. Then it calls
- mmap_region(), which does the actual mapping
Signed-off-by: Miklos Szeredi <[EMAIL
From: Miklos Szeredi <[EMAIL PROTECTED]>
This patch adds support for finding out the current file position,
open flags and possibly other info in the future.
These new entries are added:
/proc/PID/fdinfo/FD
/proc/PID/task/TID/fdinfo/FD
For each fd the information is provided in the
From: Miklos Szeredi <[EMAIL PROTECTED]>
The function do_lo_send_aops() should call
balance_dirty_pages_ratelimited() after each page similarly to
generic_file_buffered_write().
Without this, writing the loop device directly (not through a
filesystem) is very slow, and also slows the whole
From: Miklos Szeredi <[EMAIL PROTECTED]>
Remove this function. It's purpose was to limit the global number of
writeback pages from submitted by direct reclaim. But this is equally
well accomplished by limited queue lengths. When this function was
added, the device queues had much larger
commit f9690982b8c2f9a2c65acdc113e758ec356676a3 removed the check for
cpu_khz from sched_clock(), which prevented early access to the TSC by
non obvious magic.
This is harmless as long as the CPU has a TSC. On TSCless systems this
results in an illegal instruction trap.
Replace tsc_disabled and
This is a slightly different take on the fix for the deadlock in fuse
with dirty balancing. David Chinner convinced me, that per-bdi
counters are too expensive, and that it's not worth trying to account
the number of pages under writeback, as they will be limited by the
queue anyway.
From:
> On Fri, 23 Mar 2007 11:32:44 +0100 Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> I'm not as concerned about the contended performance of spinlocks
>
The contended case matters. Back in 2.5.something I screwed up the debug
version of one of the locks (rwlock, iirc) - it was simply missing a
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Sat, 24 Mar 2007 10:16:53 -0800
> On Sat, 24 Mar 2007 18:18:42 +0100 "Michal Piotrowski" <[EMAIL PROTECTED]>
> wrote:
>
> > On 24/03/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > > The mm snapshot broken-out-2007-03-24-00-14.tar.gz has been
From: David Miller <[EMAIL PROTECTED]>
Date: Mon, 19 Mar 2007 19:38:29 -0700 (PDT)
> From: Adrian Bunk <[EMAIL PROTECTED]>
> Date: Sun, 18 Mar 2007 19:49:38 +0100
>
> > Subject: ipv6 crash
> > References : http://lkml.org/lkml/2007/3/10/2
> > Submitter : Len Brown <[EMAIL PROTECTED]>
> >
On Sun, Mar 25, 2007 at 12:52:27AM +0900, Noriaki TAKAMIYA wrote:
> Hi,
>
> When I boot using linux-2.6.21-rc4 on ThinkPad T41 with pl2303 USB
> serial device plugged in, the kernel crashes.
>
> The reason is struct usb_serial_port is referenced without checking
> whether it is NULL or
Eric W. Biederman schrieb:
>
> Odd. I would have thought the oops happened in the first resume, not
> the second.
>
> Hmm. It may have something to do with the ``managed'' driver
> aspect of this as well..
>
No. I don't think so. The problem is caused by this sequence: (the info
is always
On Fri, 2007-03-23 at 21:41 +0100, Christoph Maier wrote:
> Jan C. Nordholz wrote:
> > I think I'm experiencing a race condition: Irregularly my kernel runs
> > into an Oops when it tries to initialize my crypt containers.
>
> FYI, there are similiar reports on the net, going as far back as May
On Sat, 24 Mar 2007 19:38:06 +0100 Herbert Poetzl <[EMAIL PROTECTED]> wrote:
> On Fri, Mar 23, 2007 at 09:42:35PM -0800, Andrew Morton wrote:
> > On Fri, 23 Mar 2007 20:30:00 +0100 Herbert Poetzl <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > Hi Eric!
> > > Hi Folks!
> > >
> > > here is a real
On Fri, 2007-03-23 at 13:43 +, David Howells wrote:
> [Resend - this time with a comma in the addresses, not a dot]
>
> Lennert Buytenhek <[EMAIL PROTECTED]> wrote:
>
> > [ background: On ARM, SMP synchronisation does need barriers but device
> > synchronisation does not. The question is
> IMO, we need to use task_lock() in container_exit() to avoid this race.
>
> (I think this race already exists in mainline cpuset.c?)
>
> P.S : cpuset.c checks for PF_EXITING twice in attach_task(), while this
> patch seems to be checking only once. Is that fine?
I think the cpuset code is ok,
* Ray Lee <[EMAIL PROTECTED]> wrote:
> Subject: [PATCH] x86_64: avoid sending LOCAL_TIMER_VECTOR IPI to
> itself
>
> Ray Lee reported, that on an UP kernel with "noapic" command line
> option set, the box locks hard during boot.
i think this bug deserves a bit more attention, because similar
Ingo Molnar writes:
>
> * Nikita Danilov <[EMAIL PROTECTED]> wrote:
>
> > Indeed, this technique is very well known. E.g.,
> > http://citeseer.ist.psu.edu/anderson01sharedmemory.html has a whole
> > section (3. Local-spin Algorithms) on them, citing papers from the
> > 1990 onward.
>
Thomas Meyer <[EMAIL PROTECTED]> writes:
> Eric W. Biederman schrieb:
>> Thomas Meyer <[EMAIL PROTECTED]> writes:
>>
>>
>>> Adrian Bunk schrieb:
>>>
Subject: second suspend to disk in a row results in an oops (libata?)
References : http://lkml.org/lkml/2007/3/17/43
On Fri, Mar 23, 2007 at 09:42:35PM -0800, Andrew Morton wrote:
> On Fri, 23 Mar 2007 20:30:00 +0100 Herbert Poetzl <[EMAIL PROTECTED]> wrote:
>
> >
> > Hi Eric!
> > Hi Folks!
> >
> > here is a real world example result from one of my tests
> > regarding the benefit of sharing over separate
Thomas Gleixner wrote:
>> Patch reproduced below, with an acked-by (and, uhm, a couple of spelling
>> fixes in the description -- don't hate me, 'kay?).
>
> I know that my English sucks.
Your English is fantastic, and far better than my German ever will be, so
no worries :-).
~r.
-
To
Eric W. Biederman schrieb:
> Thomas Meyer <[EMAIL PROTECTED]> writes:
>
>
>> Adrian Bunk schrieb:
>>
>>> Subject: second suspend to disk in a row results in an oops (libata?)
>>> References : http://lkml.org/lkml/2007/3/17/43
>>> Submitter : Thomas Meyer <[EMAIL PROTECTED]>
>>>
On Sat, 24 Mar 2007 18:18:42 +0100 "Michal Piotrowski" <[EMAIL PROTECTED]>
wrote:
> On 24/03/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > The mm snapshot broken-out-2007-03-24-00-14.tar.gz has been uploaded to
> >
> >
> >
At one time, if a BIOS ROM shadow was detected for the boot video
device (stored at offset 0xc), we'd set a special resource flag,
IORESOURCE_ROM_SHADOW, so that the sysfs ROM file code could handle
it properly. That broke along the way somewhere though, so current
kernels will be missing
Thomas Meyer <[EMAIL PROTECTED]> writes:
> Adrian Bunk schrieb:
>> Subject: second suspend to disk in a row results in an oops (libata?)
>> References : http://lkml.org/lkml/2007/3/17/43
>> Submitter : Thomas Meyer <[EMAIL PROTECTED]>
>> Status : unknown
>>
>
> The problem is
Can I build recent glibc such that it will work both on
2.6 and on 2.4 ? (multithreading-wise, I suppose). I tried
to boot recent 2.6-based distro with 2.4 kernel and it did not work.
Do I need to set some env.vars maybe (LD_ASSUME_KERNEL ?
GNU_LIBPTHREAD_VERSION ?) for glibc when I switch
On Sat, 24 Mar 2007 12:38:02 -0400 (EDT)
Justin Piszcz <[EMAIL PROTECTED]> wrote:
> Without NCQ, performance is MUCH better on almost every operation, with
> the exception of 2-3 items.
It depends on the drive. Generally NCQ is better but some drive firmware
isn't too bright and there are
* Nikita Danilov <[EMAIL PROTECTED]> wrote:
> Indeed, this technique is very well known. E.g.,
> http://citeseer.ist.psu.edu/anderson01sharedmemory.html has a whole
> section (3. Local-spin Algorithms) on them, citing papers from the
> 1990 onward.
that is a cool reference! So i'd suggest to
On 24/03/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
The mm snapshot broken-out-2007-03-24-00-14.tar.gz has been uploaded to
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-03-24-00-14.tar.gz
My network doesn't work
"RTNETLINK answers: Invalid argument"
Hi Brian,
On Sat, Mar 24, 2007 at 01:56:50AM -0700, Brian Braunstein wrote:
>
> Linus,
>
> According to Documentation/SubmittingPatches "bug fixes" or "obvious"
> changes
> should CCed to you, so this is why I have done this.
>
IMHO these days patches got reviewed on LKML, then tested
Adrian Bunk schrieb:
> Subject: second suspend to disk in a row results in an oops (libata?)
> References : http://lkml.org/lkml/2007/3/17/43
> Submitter : Thomas Meyer <[EMAIL PROTECTED]>
> Status : unknown
>
The problem is identified: http://lkml.org/lkml/2007/3/22/150
-
To
On Sat, Mar 24, 2007 at 12:11:05PM -0400, Douglas Gilbert wrote:
> Adrian Bunk wrote:
> > On Mon, Mar 19, 2007 at 08:56:23PM -0800, Andrew Morton wrote:
> >> ...
> >> Changes since 2.6.21-rc3-mm1:
> >> ...
> >> git-scsi-misc.patch
> >> ...
> >> git trees
> >> ...
> >
> >
> > This patch makes
Without NCQ, performance is MUCH better on almost every operation, with
the exception of 2-3 items.
/usr/sbin/bonnie++ -d /x/bonnie -s 7952 -m p34 -n 16:10:16:64 > run.txt;
# Average of 3 runs with NCQ on for Quad Raptor ADFD 150 RAID 5 Software RAID:
On Sat, 24 Mar 2007 15:21:16 +0100 Boris Andratzek wrote:
> Boris Andratzek wrote:
> > Hello members of the kernel-list,
> >
> >
> > I'm new to this and hope I don't misuse the list in any way.
> >
> > Doing the update from debian sarge to etch on my server I ran into the
> > bug documented
On Sat, Mar 24, 2007 at 10:35:37AM +0530, Srivatsa Vaddagiri wrote:
> > +static int ns_create(struct container_subsys *ss, struct container *cont)
> > +{
> > + struct nscont *ns;
> > +
> > + if (!capable(CAP_SYS_ADMIN))
> > + return -EPERM;
>
> Does this check break existing
On 24/03/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
On Sat, 2007-03-24 at 14:59 +0100, Michal Piotrowski wrote:
> On 23/03/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> > > Subject: soft lockup detected on CPU#0
> > >
On Sat, 24 Mar 2007 16:45:46 +0100
Thibaud Hulin <[EMAIL PROTECTED]> wrote:
> I'm triyng to compile the kernel 2.6.19 on Debian Testing 4.0
> Unfortunately, I can't success.
> This is my error message :
>
> CC [M] drivers/scsi/lpfc/lpfc_sli.o
> In file included from
Adrian Bunk wrote:
> On Mon, Mar 19, 2007 at 08:56:23PM -0800, Andrew Morton wrote:
>> ...
>> Changes since 2.6.21-rc3-mm1:
>> ...
>> git-scsi-misc.patch
>> ...
>> git trees
>> ...
>
>
> This patch makes two needlessly global functions static.
>
> Signed-off-by: Adrian Bunk <[EMAIL
Bartlomiej Zolnierkiewicz wrote:
On Sunday 18 March 2007, Patrick Ringl wrote:
Bartlomiej Zolnierkiewicz wrote:
Hello,
On Sunday 18 March 2007, Patrick Ringl wrote:
Hello,
Hi,
since especially Serial ATA has it's own menu point now, I guess we can
change the
Hi,
While booting, this entry is set to NULL in destroy_serial(),
but serial->port is referred again in pl2303_shutdown() via
serial->type->shutdown.
---
drivers/usb/serial/pl2303.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/usb/serial/pl2303.c
Sorry for resending.
While booting, this entry is set to NULL in destroy_serial(),
but serial->port is referred again in pl2303_shutdown() via
serial->type->shutdown.
Signed-off-by: Noriaki TAKAMIYA <[EMAIL PROTECTED]>
---
drivers/usb/serial/pl2303.c |2 ++
1 files changed, 2
Hi,
This patch fixes to skip serial->port[i] if it is set NULL.
---
include/linux/usb/serial.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/include/linux/usb/serial.h b/include/linux/usb/serial.h
index 32acbae..85ed5ef 100644
--- a/include/linux/usb/serial.h
+++
Sorry for resending
Hi,
While booting, this entry is set to NULL in destroy_serial(),
but serial->port is referred again in pl2303_shutdown() via
serial->type->shutdown.
---
drivers/usb/serial/pl2303.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git
Hi,
When I boot using linux-2.6.21-rc4 on ThinkPad T41 with pl2303 USB
serial device plugged in, the kernel crashes.
The reason is struct usb_serial_port is referenced without checking
whether it is NULL or not.
Regards,
--
Noriaki TAKAMIYA
-
To unsubscribe from this list: send the
Sorry for resending.
Hi,
This patch fixes to skip serial->port[i] if it is set NULL.
Signed-off-by: Noriaki TAKAMIYA <[EMAIL PROTECTED]>
---
include/linux/usb/serial.h |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/include/linux/usb/serial.h
Nick Piggin writes:
> On Fri, Mar 23, 2007 at 11:04:18AM +0100, Ingo Molnar wrote:
> >
> > * Nick Piggin <[EMAIL PROTECTED]> wrote:
> >
> > > Implement queued spinlocks for i386. [...]
> >
> > isnt this patented by MS? (which might not worry you SuSE/Novell guys,
> > but it might be a
Hello !
I'm triyng to compile the kernel 2.6.19 on Debian Testing 4.0
Unfortunately, I can't success.
This is my error message :
CC [M] drivers/scsi/lpfc/lpfc_sli.o
In file included from drivers/scsi/lpfc/lpfc_sli.c:23:
include/linux/pci.h:251: internal compiler error: in build_int_cst_wide,
On Sat, 24 Mar 2007 12:35:33 +0100 Michal Piotrowski <[EMAIL PROTECTED]> wrote:
>
> [EMAIL PROTECTED] napisał(a):
> > The mm snapshot broken-out-2007-03-24-00-14.tar.gz has been uploaded to
> >
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-03-24-00-14.tar.gz
>
On Sat, Mar 24, 2007 at 02:49:42PM +0100, Armin Schindler wrote:
> On Sat, 24 Mar 2007, Adrian Bunk wrote:
> > Randy Dunlap reported in kernel Bugzilla #8241 the following compile
> > error with CONFIG_ISDN_CAPI=m, CONFIG_ISDN_DIVAS=y:
> >
> > <-- snip -->
> >
> > ...
> > WARNING:
On Sat, 2007-03-24 at 14:59 +0100, Michal Piotrowski wrote:
> On 23/03/07, Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> > On Fri, 2007-03-23 at 19:50 +0100, Adrian Bunk wrote:
> > > Subject: soft lockup detected on CPU#0
> > > References : http://lkml.org/lkml/2007/3/3/152
> > > Submitter :
1 - 100 of 288 matches
Mail list logo
