On Wed, Mar 21, 2007 at 10:28:02PM -0800, Andrew Morton wrote:
On Thu, 22 Mar 2007 07:11:19 +0100 Jarek Poplawski [EMAIL PROTECTED] wrote:
Here is some joke:
[PATCH] lockdep: lockdep_depth vs. debug_locks
lockdep really shouldn't be used when debug_locks == 0!
This isn't a
On Wed, 21 Mar 2007 15:14:29 -0400, Mike Frysinger wrote:
On 3/21/07, Bob Copeland [EMAIL PROTECTED] wrote:
+config I2C_BLACKFIN_TWI
+ tristate Blackfin TWI I2C support
+ depends on I2C (BF534 || BF536 || BF537)
+ help
+ This is the TWI I2C device driver
This is a rather long message, and isn't directed at anyone in
particular, it's for others who may be digging into their own problems
with RSDL, and for others (if any other than Con exist) who understand
RSDL well enough to tell me if I'm missing something. Anyone who's not
interested in RSDL's
On Wed, Mar 21, 2007 at 10:28:02PM -0800, Andrew Morton wrote:
...
I assume that some codepath is incrementing -lockdep_depth even when
debug_locks==0. Isn't that wrong of it?
lockdep simply stops to update lockdep_depth just after (during)
a bug or a WARN.
Jarek P.
-
To unsubscribe from
On 3/22/07, Jean Delvare [EMAIL PROTECTED] wrote:
On Wed, 21 Mar 2007 15:14:29 -0400, Mike Frysinger wrote:
On 3/21/07, Bob Copeland [EMAIL PROTECTED] wrote:
+config I2C_BLACKFIN_TWI
+ tristate Blackfin TWI I2C support
+ depends on I2C (BF534 || BF536 || BF537)
+
On Thu, 2007-03-22 at 05:49 +0100, Willy Tarreau wrote:
Mike, if you need my old scheddos, I can resend it to you as well as to
any people working on the scheduler and asking for it. Although trivial,
I'm a bit reluctant to publish it to the whole world because I suspect
that distros based on
On Thu, Mar 22, 2007 at 08:06:44AM +0100, Jarek Poplawski wrote:
...
This should definitely solve this problem - as it was said
a few times before lockdep stops registering locks after
a bug, so even the lock which caused the warning isn't
reported. Here lockdep found a bug in a workqueue
On Thursday, 22 March 2007 05:51, David Chinner wrote:
On Wed, Mar 21, 2007 at 10:38:33PM +0100, Rafael J. Wysocki wrote:
I think this is the XFS problem with freezable workqueues.
Maxim, please try to apply the appended patch and see if it helps.
Greetings,
Rafael
---
On Thu, 2007-03-22 at 07:11 +0100, Jarek Poplawski wrote:
Here is some joke:
[PATCH] lockdep: lockdep_depth vs. debug_locks
lockdep really shouldn't be used when debug_locks == 0!
This happens then lockdep reports a fatal error, at which point
it will stop tracking locks and leave whatever
On Thu, 2007-03-22 at 07:57 +0100, Jarek Poplawski wrote:
And here is some addition.
[PATCH] lockdep: debug_show_all_locks debug_show_held_locks vs. debug_locks
lockdep's data shouldn't be used when debug_locks == 0
because it's not updated after this, so it's more misleading
than
Benjamin Herrenschmidt wrote:
!!! This is a first cut, and there are still cleanups to be done in various
areas touched by that code. I also haven't done descriptions yet for the
individual patches.
The current get_unmapped_area code calls the f_ops-get_unmapped_area or
the arch one (via the
Rusty Russell wrote:
+static inline unsigned long long native_read_msr(unsigned int msr, int *err)
+{
+ unsigned long long val;
+
+ asm volatile(2: rdmsr ; xorl %0,%0\n
+1:\n\t
+.section .fixup,\ax\\n\t
+3: movl %3,%0 ; jmp
On Thu, Mar 22, 2007 at 01:15:25AM -0400, Dave Jones wrote:
make help implies that supplying $CHECK on the command line
should override sparse as the checker used when building with C=1
Yet, this doesn't seem to be the case.
This would be useful for cases where for eg, sparse isn't in
the
On Thu, 22 Mar 2007 08:23:39 +0100 Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
On Thursday, 22 March 2007 05:51, David Chinner wrote:
On Wed, Mar 21, 2007 at 10:38:33PM +0100, Rafael J. Wysocki wrote:
I think this is the XFS problem with freezable workqueues.
Maxim, please try to
You didn't explain _why_ you need to sleep for such a long time,
and as you didn't give a pointer to your code, there's not
much people can do to recommend changes other than don't do that.
The code which is executed between the local_irq_disable and enable,
is just a function call into our
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
Mar 21 15:06:52 cinder kernel: firmware_loading_store: unexpected
value (0)
Mar
On Thu, 22 Mar 2007 00:29:54 -0700 Miles Lane [EMAIL PROTECTED] wrote:
kobject :01:06.0: cleaning up
kobject firmware: cleaning up
BUG: unable to handle kernel paging request at virtual address 6b6b6ceb
printing eip:
c0137c22
*pde =
Oops: 0002 [#1]
last sysfs file:
On Wed, March 21, 2007 16:50, Tasos Parisinos wrote:
A malicious person may want to alter code on the detachable (and unsafe)
file system.
Lots of stuff including the kernel will be in a trapped casing (opening,
probing it, power
analyzing it, heating it etc will result in system suicide
Hi Mike,
On Thu, 22 Mar 2007 01:39:28 -0400, Mike Frysinger wrote:
On 3/21/07, Jean Delvare [EMAIL PROTECTED] wrote:
+ p_adap-class = I2C_CLASS_ALL;
This pretty much voids the point of these probing classes. You should
only select the classes matching devices which may actually be
On Thu, 2007-03-22 at 09:30 +0200, Avi Kivity wrote:
Rusty Russell wrote:
+static inline unsigned long long native_read_msr(unsigned int msr, int
*err)
+{
+ unsigned long long val;
+
+ asm volatile(2: rdmsr ; xorl %0,%0\n
+1:\n\t
+.section
Jon Masters wrote:
Sergey Vlasov wrote:
Has a final decision about generated files been made? I don't see any
updates in the git repo, and man pages are still broken
I'm doing some patching this afternoon anyway, and it's on my todo.
I pushed up v3.3-pre11 just now. If all goes to plan,
Rusty Russell wrote:
The behaviour change (don't oops when an invalid rdmsr is used) was
there with CONFIG_PARAVIRT=y, the cleanup just made !CONFIG_PARAVIRT the
same. Is it important?
We could always fling a BUG_ON in the non-safe versions, which would
probably be more informative than a
Rusty Russell wrote:
+#define rdmsr(msr,val1,val2) \
+ do {\
+ int __err; \
+ unsigned long long __val =
On 3/22/07, Jean Delvare [EMAIL PROTECTED] wrote:
On Thu, 22 Mar 2007 01:39:28 -0400, Mike Frysinger wrote:
On 3/21/07, Jean Delvare [EMAIL PROTECTED] wrote:
+ p_adap-class = I2C_CLASS_ALL;
This pretty much voids the point of these probing classes. You should
only select the
Hi Rusty,
On Thu, 22 Mar 2007 10:58:30 +1100 Rusty Russell [EMAIL PROTECTED] wrote:
On Wed, 2007-03-21 at 10:51 -0600, Eric W. Biederman wrote:
Rusty Russell [EMAIL PROTECTED] writes:
On Wed, 2007-03-21 at 03:31 -0600, Eric W. Biederman wrote:
Rusty Russell [EMAIL PROTECTED]
On Thursday, 22 March 2007 08:31, Andrew Morton wrote:
On Thu, 22 Mar 2007 08:23:39 +0100 Rafael J. Wysocki [EMAIL PROTECTED]
wrote:
On Thursday, 22 March 2007 05:51, David Chinner wrote:
On Wed, Mar 21, 2007 at 10:38:33PM +0100, Rafael J. Wysocki wrote:
I think this is the XFS
Hi Alexey,
It seems you are fix-rmmod-read-write-races-in-proc-entries.patch author ?
/proc/kcore is no longer seekable (or mappable)
Also, do we really need to proxy via proc_reg_file_ops files that are not
provided by a module ?
I think not.
Could you please add in proc_get_inode() a check
On Wed, Mar 21, 2007 at 10:28:02PM -0800, Andrew Morton wrote:
On Thu, 22 Mar 2007 07:11:19 +0100 Jarek Poplawski [EMAIL PROTECTED] wrote:
Here is some joke:
[PATCH] lockdep: lockdep_depth vs. debug_locks
lockdep really shouldn't be used when debug_locks == 0!
This isn't a
On Thu, Mar 22, 2007 at 09:14:45AM +0100, Eric Dumazet wrote:
Also, do we really need to proxy via proc_reg_file_ops files that are not
provided by a module ?
I think not.
Could you please add in proc_get_inode() a check against de-proc_fops-owner
?
Let's _not_. Bugs that depend on
Andy Whitcroft wrote:
Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/
[All of the below is from the pre hot-fix runs. The very few
Hi,
Lots of good progress here, but still a few comments below.
Needs to apply to current mainline.
What do you mean by mainline?
Most (probably all) of these functions should also be static
unless they are meant for use outside of this module.
Which leads to the question: which
Hello,
this is my first code submitted to kernel, I hope you won't hate it.
This 4-lines-change patch adds support for nearly two-times more loop
devices. Explanation follows:
The maximum amount of loop devices has been 255 for many years, while
there is a lot of space for more. The maximum
On Thu, 22 Mar 2007 00:56:08 +0100 Johannes Weiner [EMAIL PROTECTED] wrote:
On Thu, Mar 22, 2007 at 12:48:05AM +0100, roland wrote:
fs/block_dev.c: In function `bd_claim_by_kobject':
fs/block_dev.c:953: warning: `found' might be used uninitialized in this
function
found actually _is_
On 3/20/07, Bill Nottingham [EMAIL PROTECTED] wrote:
I was fiddling with the 'new' (no CONFIG_SYSFS_DEPRECATED) layout
and ethernet device names, and noticed that the new layout effectively
restricts the availability of certain device names.
By making a directory for the ethernet device name in
On Wed, Mar 21, 2007 at 04:01:11PM -0700, Andrew Morton wrote:
On Wed, 21 Mar 2007 23:19:05 +0100
Sam Ravnborg [EMAIL PROTECTED] wrote:
On Tue, Mar 20, 2007 at 09:47:14PM -0800, Andrew Morton wrote:
On Tue, 20 Mar 2007 12:20:16 -0700 Kees Cook [EMAIL PROTECTED] wrote:
I can't
* Peter Zijlstra [EMAIL PROTECTED] wrote:
On Thu, 2007-03-22 at 07:11 +0100, Jarek Poplawski wrote:
Here is some joke:
[PATCH] lockdep: lockdep_depth vs. debug_locks
lockdep really shouldn't be used when debug_locks == 0!
This happens then lockdep reports a fatal error, at which
* Peter Zijlstra [EMAIL PROTECTED] wrote:
On Thu, 2007-03-22 at 07:57 +0100, Jarek Poplawski wrote:
And here is some addition.
[PATCH] lockdep: debug_show_all_locks debug_show_held_locks vs.
debug_locks
lockdep's data shouldn't be used when debug_locks == 0
because it's not
anyway - i wonder if anybody is ever using 2.6.21+ on a system with one of
those legacy mitsumi single-speed (LU-005/FX-001) and double-speed (FX-001D)
cd-rom drives !?
iirc, these where the first drives available on the market (must have been
around '94) and those were no ide/atapi
Auto unlock sectors on resume for auto locking flash on power up.
Signed-off-by: Rodolfo Giometti [EMAIL PROTECTED]
diff --git a/drivers/mtd/chips/cfi_cmdset_0001.c
b/drivers/mtd/chips/cfi_cmdset_0001.c
index f69184a..8a4395e 100644
--- a/drivers/mtd/chips/cfi_cmdset_0001.c
+++
On Wed, 2007-03-21 at 12:59 +0100, Sam Ravnborg wrote:
I will give it a shot tonight.
Thanks. I'll delete the syscalls-2.6.git tree now that you have it.
One issue I have with current approach is that the ARCH specific
things are in a single .h file.
Que? There aren't really any
* Mike Galbraith [EMAIL PROTECTED] wrote:
Actually, the numbers are an interesting curiosity point, but not as
interesting as the fact that the deadline mechanism isn't kicking in.
it's not just the scheduling accounting being off, RSDL also seems to be
accessing stale data here:
From
On Thu, 22 Mar 2007 04:12:37 -0400, Mike Frysinger wrote:
it isnt obvious to me how to leverage the normal platform_device and
resource structures to achieve moving the class out of the driver and
into a boards file ... i'm perfectly happy doing this knowing what the
correct direction to take
On Thu, 2007-03-22 at 09:10 +0100, Sébastien Dugué wrote:
Why not take on the opportunity to rename boot_gt_table to boot_gtd,
to avoid the duplicate T(able)?
That's not a bad idea, but IMHO deserves its own patch.
I look forward to it!
Rusty.
-
To unsubscribe from this list: send the line
On Thu, 22 Mar 2007 01:14:41 -0700 Miles Lane [EMAIL PROTECTED] wrote:
I still encounter the BUG with the reverted patch. In these two
builds hitting the BUG, more stuff is built as a module, so perhaps
that is why I am triggering this. I am appending my .config file.
I hope this helps,
* Michal Piotrowski [EMAIL PROTECTED] wrote:
Hi Ingo,
2.6.21-rc4-rt0
BUG: at kernel/fork.c:1033 copy_process()
thanks Michal - this is a real bug that affects upstream too. Find the
fix below - i've test-booted it and it fixes the warning.
Linus, Andrew, this is a must-have for v2.6.21.
On Thu, 2007-03-22 at 10:18 +0100, Ingo Molnar wrote:
* Mike Galbraith [EMAIL PROTECTED] wrote:
Actually, the numbers are an interesting curiosity point, but not as
interesting as the fact that the deadline mechanism isn't kicking in.
it's not just the scheduling accounting being off,
Am Donnerstag, 22. März 2007 10:14 schrieb roland:
i wonder if there still exist any of those devices in functional state in
this world, at least not attached to some system being able to boot
2.6.21+ - so, maybe mcdx driver is something for
Documentation/feature-removal-schedule.txt ,
On Thu, 2007-03-22 at 10:34 +0100, Mike Galbraith wrote:
Erk!
bzzt. singletasking brain :)
-
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
Andy Whitcroft wrote:
Andy Whitcroft wrote:
Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
Will appear later at
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc4/2.6.21-rc4-mm1/
[All of the below is from the pre hot-fix
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
---
fs/proc/inode.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -167,8 +167,9 @@ static loff_t proc_reg_llseek(struct fil
llseek = pde-proc_fops-llseek;
On Thu, 2007-03-22 at 10:09 +0200, Avi Kivity wrote:
Right, scratch that. Was confused by rdmsr_safe().
Heh... me too 8)
The behaviour change (don't oops when an invalid rdmsr is used) was
there with CONFIG_PARAVIRT=y, the cleanup just made !CONFIG_PARAVIRT the
same. Is it important?
On Thursday 22 March 2007 20:48, Andy Whitcroft wrote:
Andy Whitcroft wrote:
Andy Whitcroft wrote:
Andrew Morton wrote:
Temporarily at
http://userweb.kernel.org/~akpm/2.6.21-rc4-mm1/
Will appear later at
Hi,
Considering the recent attention on CPU schedulers, so here is an updated
version of my scheduler against 2.6.21-rc4. I often run it on my own
desktop here here and it works well for me, no guarantees! I would be
happy if anyone was interested in testing it :)
Thanks,
Nick
--
SUSE Labs,
Great, this is long overdue for a cleanup.
Indeed... lots of redundant checks, dead code, etc...
I haven't looked at all users of this, but does it make sense to switch
to an API that takes an address range and modifies / filters it? Perhaps
also filling in some other annotations (eg.
Benjamin Herrenschmidt wrote:
Great, this is long overdue for a cleanup.
Indeed... lots of redundant checks, dead code, etc...
I haven't looked at all users of this, but does it make sense to switch
to an API that takes an address range and modifies / filters it? Perhaps
also filling in
Jean Delvare wrote:
On Mon, 19 Mar 2007 17:43:38 -0400, Bob Copeland wrote:
I tried out an earlier version of this patch several months ago just to play
around with the joystick part of the accelerometer driver on my MacBook, and
found that it was backwards in the y-direction compared to
On Wed, Mar 21, 2007 at 02:43:48PM -0500, Adam Litke wrote:
The main reason I am advocating a set of pagetable_operations is to
enable the development of a new hugetlb interface. During the hugetlb
BOFS at OLS last year, we talked about a character device that would
behave like /dev/zero.
Well if we use a set of valid ranges, then we can start with generic code
that will set up ranges allowed by the syscall semantics.
Then the arch code could be called with that set of ranges, and perform
its modifications to that set.
A bit complicated in practice... set of ranges can be
On Wed, Mar 21, 2007 at 11:39:08PM +0100, Pavel Machek wrote:
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
On Wed, Mar 21, 2007 at 06:42:58PM -0700, Randy Dunlap wrote:
On Thu, 22 Mar 2007 01:32:36 + Sid Boyce wrote:
...
There's not a lot of docs out there.
The man-page: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
Linus's email doc:
* Tomas M [EMAIL PROTECTED] wrote:
I hope you will like it and you will include it in kernel.
Or, if not, maybe this patch will start some debate regarding
the current insufficient limit of 255 loop devices.
255 loop devices are insufficient? What kind of scenario do you have
in mind?
--
Thomas Gleixner wrote:
You said, that the breakage came between 2.6.20 and rc2. Can you bisect
it ?
The XFS workqueue patch [1] fixes my problem [2].
Marcus
[1] http://permalink.gmane.org/gmane.linux.kernel/507616
[2] http://permalink.gmane.org/gmane.linux.kernel/505570
pgpv6EWLbYBMj.pgp
On Wed, 21 Mar 2007 13:22:17 -0700 Venkatesh Pallipadi [EMAIL PROTECTED]
wrote:
Introduce a new flag for timers - 'deferrable timer'
Timers that work normally when system is busy. But, will not cause CPU to
come out of idle (just to service this timer), when CPU is idle. Instead,
this
On Wed, 21 Mar 2007 23:39:17 -0800,
Andrew Morton [EMAIL PROTECTED] 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
255 loop devices are insufficient? What kind of scenario do you have
in mind?
Thank you very much for replying.
In 1981, Bill Gates said that 64KB of memory is enough for everybody.
And you know how much RAM do you have right now. :)
Every limit is bad. The limit of 255 loop devices has
Tomoki Sekiyama wrote:
Hi,
Thanks for your comments.
I'm sorry for my late reply.
Bill Davidsen wrote:
Andrew Morton wrote:
- I wonder if dirty_limit_ratio is the best name we could choose.
vm_dirty_blocking_ratio, perhaps? Dunno.
I don't like it, but I dislike it less than
Hi!
(Machine was suspended/resumed before this).
mount /dev/mmc1 /mnt
Buffer I/O error on device mmcblk0p1, logical block 1
BUG: unable to handle kernel NULL pointer dereference at virtual
address 0024
printing eip:
c04cb2ec
*pde =
Oops: [#1]
SMP
Modules linked in:
CPU:0
On Thu, Mar 22, 2007 at 09:17:00AM +, David Woodhouse wrote:
On Wed, 2007-03-21 at 12:59 +0100, Sam Ravnborg wrote:
I will give it a shot tonight.
Thanks. I'll delete the syscalls-2.6.git tree now that you have it.
One issue I have with current approach is that the ARCH specific
Pavel Machek wrote:
Hi!
(Machine was suspended/resumed before this).
mount /dev/mmc1 /mnt
Driver? Reproducable? Vanilla git kernel?
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainerhttp://www.kernel.org
PulseAudio, core developer http://pulseaudio.org
On Thu, Mar 22, 2007 at 03:18:26AM -0800, Andrew Morton wrote:
On Wed, 21 Mar 2007 13:22:17 -0700 Venkatesh Pallipadi [EMAIL PROTECTED]
wrote:
Introduce a new flag for timers - 'deferrable timer'
Timers that work normally when system is busy. But, will not cause CPU to
come out of
From: David Howells [EMAIL PROTECTED]
Fix the /proc/pid/stat representation of executable boundaries. It should show
the bounds of the executable, but instead shows the bounds of the loader.
Before the patch is applied, the bug can be seen by examining, say, inetd:
# ps | grep inetd
I use 2.6.20.2 kernel with ext3 rootfs on 4Gb SD on sharp zaurus sl-750
(PXA255).
After suspend/resume filesystem stay clean. But some i-nodes become broken.
Some files looks like block device or pipe with strange permissions, owner etc.
I'm sure that there is no bad blocks on SD.
I'll send any
Hi folks.
1) Are there any new developments in this issue? Does someone know if
AMD and Nvidia is still investigating?
2) Steve Langasek from Debian sent me a patch that disables the hw-iommu
per default on Nvidia boards.
I've attached it in the kernel bugzilla and asked for inclusion in the
On Wed, 2007-03-21 at 20:59 +0100, Jens Axboe wrote:
On Wed, Mar 21 2007, Dale Blount wrote:
On Wed, 2007-03-21 at 14:09 -0400, Chuck Ebbert wrote:
Dale Blount wrote:
I'm puzzled why this is hitting Dan, but no one else has reported
anything. Dan, did 2.6.19 work for you?
On 22/03/07, Ingo Molnar [EMAIL PROTECTED] wrote:
* Michal Piotrowski [EMAIL PROTECTED] wrote:
Hi Ingo,
2.6.21-rc4-rt0
BUG: at kernel/fork.c:1033 copy_process()
thanks Michal - this is a real bug that affects upstream too. Find the
fix below - i've test-booted it and it fixes the
Hi,
On Sun, 18 Mar 2007, Alexander E. Patrakov wrote:
More details on what the patch does:
* Rewords the description of CONFIG_NLS_DEFAULT, because at some point in the
past it confused some people
* Removes CONFIG_FAT_DEFAULT_IOCHARSET, now CONFIG_NLS_DEFAULT is used for
this purpose.
(Please don't trim me from the CC list if you're replying to what I've said,
thanks.)
On Thu, March 22, 2007 00:31, David Schwartz wrote:
If you can't read protect your kernel, you can't write protect it
either.
This is so misleading as to basically be false.
Please elaborate. Short of ROM I
On Thu, 2007-03-22 at 12:56 +0300, Alexey Dobriyan wrote:
Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED]
---
fs/proc/inode.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
--- a/fs/proc/inode.c
+++ b/fs/proc/inode.c
@@ -167,8 +167,9 @@ static loff_t
Marti Raudsepp wrote:
This is a reproducible demonstration of the problem initially reported in my
first e-mail, titled PROBLEM: 'bio too big device' after moving to a USB
disk (http://lkml.org/lkml/2007/3/7/657)
...
06. Observe bio too big device dm-0 (256 240) messages in dmesg
[non]#
My previous warning fix broke lguest if your text size wasn't correct
to make the __start_paravirtprobe aligned correctly. Put the separate
paravirtprobe section back, but inside the init section so it gets
discarded.
It also fixes the remaining warnings, except one. The code in
modpost.c which
On Thu, Mar 22, 2007 at 09:09:42PM +1100, Rusty Russell wrote:
My previous warning fix broke lguest if your text size wasn't correct
to make the __start_paravirtprobe aligned correctly. Put the separate
paravirtprobe section back, but inside the init section so it gets
discarded.
It also
Additions and removal from tty_drivers list were just done as well as
iterating on it for /proc/tty/drivers generation.
testing: modprobe/rmmod loop of simple module which does nothing but
tty_register_driver() vs cat /proc/tty/drivers loop
BUG: unable to handle kernel paging request at virtual
Roman Zippel wrote:
I agree that these parameters should be changable not just at compile time
and the iocharset should be a global default, but the on disk encoding is
often filesystem specific, so I'd rather keep this option per filesystem.
You are right, the on-disk encoding is filesystem
I couldn't find the original thread so I am restarting one adding I hope
the appropriate people to the cc list.
Andrew thanks for forwarding this one. I finally see enough of this to
see what is going on.
The question is about the following sequence from libata.
pci_enable_msi();
Michal Piotrowski napisał(a):
On 22/03/07, Ingo Molnar [EMAIL PROTECTED] wrote:
* Michal Piotrowski [EMAIL PROTECTED] wrote:
Hi Ingo,
2.6.21-rc4-rt0
BUG: at kernel/fork.c:1033 copy_process()
thanks Michal - this is a real bug that affects upstream too. Find the
fix below - i've
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
So is the pid used for anything other than debugging?
In any case, here is a replacement patch which sends the pid number
in the pid_namespace of the process which did the autofs4 mount.
Still
Quoting Ian Kent ([EMAIL PROTECTED]):
On Wed, 2007-03-21 at 21:19 -0500, Serge E. Hallyn wrote:
Quoting Ian Kent ([EMAIL PROTECTED]):
On Tue, 2007-03-20 at 16:01 -0600, Eric W. Biederman wrote:
Serge E. Hallyn [EMAIL PROTECTED] writes:
void autofs4_dentry_release(struct
Con Kolivas wrote:
Here is the best fix for the bug pointed out. Thanks.
Ensure niced tasks are not inappropriately limiting sleeping unniced tasks
by explicitly checking what the best static priority that has run this
major rotation was.
yes, this made the machine usable again.
After
On Thu, 22 Mar 2007 12:37:54 +0100
Tomas M [EMAIL PROTECTED] wrote:
The question is not Why do we need more than 255 loops?.
The question should be Why do we need the hardcoded 255-limit in kernel
while there is no reason for it at all?
My patch simply removes the hardcoded limitation.
On Thu, Mar 22 2007, Eric Dumazet wrote:
On Thu, 22 Mar 2007 12:37:54 +0100
Tomas M [EMAIL PROTECTED] wrote:
The question is not Why do we need more than 255 loops?.
The question should be Why do we need the hardcoded 255-limit in kernel
while there is no reason for it at all?
My
Hi,
On Thu, 22 Mar 2007, Alexander E. Patrakov wrote:
It is exposed as a mount parameter and kernel configuration option only for
fat and smbfs (the two filesystems that my patch touches for this matter), and
both of these filesystems come from DOS days, where there was one codepage for
a
On Thu, 22 Mar 2007 14:42:31 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
This time, you would be limited to 16384 loop devices on x86_64, 32768 on
i386 :)
But this still wastes memory, why not just allocate each loop device
dynamically when it is set up? The current approach is crap, it
oh - i forgot sending this to the list, since this was copypaste via
webmailer.
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED]
Gesendet: 22.03.07 14:42:45
An: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]
Betreff: Re: max_loop limit
Hi Tomas,
you`re completely right.
I
On Thu, Mar 22 2007, Eric Dumazet wrote:
On Thu, 22 Mar 2007 14:42:31 +0100
Jens Axboe [EMAIL PROTECTED] wrote:
This time, you would be limited to 16384 loop devices on x86_64, 32768 on
i386 :)
But this still wastes memory, why not just allocate each loop device
dynamically
Roman Zippel wrote:
hfs has a codepage option as well, but I don't know its default in the
various countries, but it could be different from DOS.
Yes. Since this comes from Mac world, it definitely makes sense to add
CONFIG_MAC_CODEPAGE_DEFAULT, the corresponding module parameter, and make
On Thu, Mar 22 2007, Eric Dumazet wrote:
Sure, but it's the first Tomas patch :)
On Thu, Mar 22, 2007 at 02:54:57PM +0100, Jens Axboe wrote:
The more the reason to guide him in the direction of a right solution,
instead of extending the current bad one!
On Thu, Mar 22 2007, Eric Dumazet
You might want a more radical patch :
I agree that my patch is not the perfect solution for max_loop problem.
But it nearly doubles max_loop for me (using 386 arch) and moreover it
is a FIX for incorrect implementation in kernel IMHO. So I can see
REASON to include it in Kernel. Do I cry at
On Thu, Mar 22, 2007 at 11:28:43AM +0900, Ian Kent wrote:
On Wed, 2007-03-21 at 15:58 -0500, Serge E. Hallyn wrote:
Quoting Eric W. Biederman ([EMAIL PROTECTED]):
Serge E. Hallyn [EMAIL PROTECTED] writes:
void autofs4_dentry_release(struct dentry *);
extern void
On Thu, Mar 22, 2007 at 02:42:31PM +0100, Jens Axboe wrote:
But this still wastes memory, why not just allocate each loop device
dynamically when it is set up? The current approach is crap, it is just
wasting memory for loop devices, queues, etc.
Correction: current ABI is crap. To set the
Nick Piggin wrote:
Forward port of nicksched to 2.6.21-rc4.
Great!
Can't find my old
design/description document for it, but it is yet another scheduler. Focus
is on simplicity and fairness.
Simplicity is really key.
This one tends to require X to be reniced to -10 or so for best results
1 - 100 of 769 matches
Mail list logo
