On Mon, Mar 19, 2007 at 07:21:47AM +0100, Mike Galbraith wrote:
On Sun, 2007-03-18 at 19:27 -0700, David Schwartz wrote:
Wrong. I call a good job giving a _preference_ to the desktop. I call
rigid fairness impractical for the desktop, and a denial of reality.
Assuming you *want*
On Mon, 19 Mar 2007, Nick Piggin wrote:
So you could just attempt a trylock, and if it works, then you
could revoke the vma right then and there. OTOH, the patch you
subsequently posted looks fine, so unless this is performance
critical then I wouldn't bother ;)
The patch in -mm uses trylock.
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git
Which contains:
Hideo Saito (1):
sh: Fix PCI BAR address-space wraparound.
Mike Frysinger (1):
sh: Convert struct ioctls to static defines.
Paul Mundt (4):
sh: Define missing
In article [EMAIL PROTECTED] you wrote:
2) Output of yes --help from the same terminal
Question: what do you expect?
# yes --version
#yes (GNU coreutils) 5.2.1
#Written by David MacKenzie.
#
#Copyright (C) 2004 Free Software Foundation, Inc.
#This is free software; see the source for copying
On Monday 19 March 2007 03:48:14 you wrote:
Christian wrote:
On Sunday 18 March 2007 06:43:09 you wrote:
Christian wrote:
This does indeed look like a drive side issue to me (the controller is
reporting CPBs with response flags 2 which as far as I can tell
indicates it's still waiting
From: Márton Németh [EMAIL PROTECTED]
Typo: iwithout - without.
Signed-off-by: Márton Németh [EMAIL PROTECTED]
---
--- linux-2.6.21-rc4.orig/drivers/base/platform.c 2007-03-16
01:20:01.0 +0100
+++ linux-2.6.21-rc4/drivers/base/platform.c2007-03-19 08:08:33.0
+0100
Andrew Morton wrote:
On Mon, 19 Mar 2007 13:19:00 +0800 Nicolas Boichat [EMAIL PROTECTED] wrote:
This driver provides support for the Apple System Management Controller,
which
provides an accelerometer (Apple Sudden Motion Sensor), light sensors,
temperature sensors, keyboard backlight
Christian wrote:
Yes, for me the problem was introduced recently. I have moved around
terabytes
(sic!) on my discs with older kernels and I never got errors.
There is always the possibility of disk going bad, so it would be great
if you can boot an older kernel and verify that the problem
Hi Richard,
On Sun, 18 Mar 2007 14:36:08 -0500, Richard Voigt wrote:
On 3/3/07, Jean Delvare wrote:
On Fri, 2 Mar 2007 21:12:51 +, Matthew Garrett wrote:
Assuming arbitration of access, what's the problem with having two
drivers accessing the same hardware? Do these chips generally
On Mon, Mar 19, 2007 at 08:41:33AM +0200, Meelis Roos wrote:
I was using my laptop as the serial console of another computer with
pl2303 usb-to-serial cable. minicom was running but I do not remember
whether the other end was connected or was already disconnected. Anyway,
I unplugged the
On 3/19/07, Andrew Morton [EMAIL PROTECTED] wrote:
BUG_ON(!PageSlab(page));
that's seriously screwed up. Do you have CONFIG_DEBUG_SLAB enabled? If
not, please enable it and retest.
This is scary. Looking at disassembly of the OOPS:
Disassembly of section .text:
.text:
On Mon, Mar 19, 2007 at 05:37:03PM +1100, Nick Piggin wrote:
David Chinner wrote:
+/*
+ * block_page_mkwrite() is not allowed to change the file size as it gets
+ * called from a page fault handler when a page is first dirtied. Hence
we must
+ * be careful to check for EOF conditions
Oh... that's just weird. It seems you'll have to continue
boot with the
timeouts for the time being. Sorry about that.
Would you agree to a patch to add a kernel boot parameter to skip some
ata ports ?
I found some archives refering to some ataX=noprobe, but it seems
to have no effect, and
Paul Rolland wrote:
Oh... that's just weird. It seems you'll have to continue
boot with the
timeouts for the time being. Sorry about that.
Would you agree to a patch to add a kernel boot parameter to skip some
ata ports ?
I found some archives refering to some ataX=noprobe, but it seems
to
Bernd Eckenfels wrote:
In article [EMAIL PROTECTED] you wrote:
2) Output of yes --help from the same terminal
Question: what do you expect?
A Japanese version of the help text. Unfortunately, LKML rejected it as SPAM,
so I'll redirect you to the graphical rendering of it:
Alistair John Strachan wrote:
On Monday 12 March 2007 13:25, Frank van Maarseveen wrote:
[snip]
So, are /dev/hd* going to disappear in a few years? iow, does it make
sense to _slowly_ start to migrate to /dev/sd*?
How would you propose doing this? I'm sure modern distros with an
From: Pekka Enberg [EMAIL PROTECTED]
This changes kmem_cache_free() to deal with NULL objects passed to it. The
current behavior is inconsistent with kfree() so there are callers
passing NULL to kmem_cache_free().
Andreas, can you please confirm this fixes the oops you reported on
linux-scsi?
John wrote:
I've tweaked patch-2.6.20-rt8 so that it applies to 2.6.20.3
The unified diff is attached to this message.
I'd be happy to hear comments on what I've done wrong!
Would anybody care to comment on the patch? :-)
I made 4 simple edits.
linux/Makefile
trivial fix for
On Thu, Mar 08, 2007 at 06:47:48AM +0100, Pierre Ossman wrote:
Adrian Bunk wrote:
On Tue, Mar 06, 2007 at 12:44:08AM -0800, Andrew Morton wrote:
...
Changes since 2.6.20-rc2-mm1:
...
git-mmc.patch
...
git trees
...
mmc_deselect_cards() is no longer used.
Signed-off-by:
The Coverity checker spotted that the following part of
commit bd44e2b007bc9024bce3357c185b38c73f87c3dd is obviously bogus:
-- snip --
--- a/fs/dlm/lowcomms-tcp.c
+++ b/fs/dlm/lowcomms-tcp.c
@@ -327,6 +327,9 @@ static int receive_from_sock(struct connection *con)
if (ret = 0)
The Coverity checker spotted the following incorrect part of
commit 94bebf4d1b8e7719f0f3944c037a21cfd99a4af7:
-- snip --
...
void sysfs_drop_dentry(struct sysfs_dirent * sd, struct dentry * parent)
{
struct dentry * dentry = sd-s_dentry;
+ struct inode *inode;
if
The Coverity checker spotted the following two array overruns in
drivers/video/aty/atyfb_base.c:
-- snip --
...
static const u32 lt_lcd_regs[] = {
CONFIG_PANEL_LG,
LCD_GEN_CNTL_LG,
DSTN_CONTROL_LG,
HFB_PITCH_ADDR_LG,
HORZ_STRETCHING_LG,
The Coverity checker spotted this bogus for() loop that produces an
array overrun.
It seems what actually should be done is quite simple?
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
sound/pci/ice1712/wtm.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
---
NULL checks should be before the first dereference.
Spotted by the Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- linux-2.6.21-rc3-mm2/drivers/video/s3fb.c.old 2007-03-19
09:20:22.0 +0100
+++ linux-2.6.21-rc3-mm2/drivers/video/s3fb.c 2007-03-19
This patch fixes an off-by-one spotted by the Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- linux-2.6.21-rc3-mm2/drivers/mfd/sm501.c.old2007-03-19
09:09:57.0 +0100
+++ linux-2.6.21-rc3-mm2/drivers/mfd/sm501.c2007-03-19 09:15:12.0
+0100
@@
The return value of kernel_recvmsg() should be assigned to err, not
compared with the random value of a never initialized err
(and the 0 check wrongly always returned false since == comparisons
never have a result 0).
Spotted by the Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL
On Sun, 18 Mar 2007 13:08:34 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
While researching the tty layer pid leaks I found a weird case in
selinux when we drop a controlling tty because of inadequate
permissions we don't do the normal hangup processing. Which is a
problem if it
The Coverity checker spotted the following code introduced by
commit 839fcaba355abaffb7b44f0f4504093acb0b11cf:
-- snip --
...
static void path_rec_completion(int status,
struct ib_sa_path_rec *pathrec,
void *path_ptr)
{
...
This patch fixes two NULL dereferences spotted by the Coverity checker.
For a better understanding, the diff -uwp output (that ignores the
indentation changes) is:
--- linux-2.6.21-rc3-mm2/net/x25/x25_forward.c.old 2007-03-19
02:28:34.0 +0100
+++
The Coverity checker spotted that npages will be used uninitialized in
the following code if !(mr_rereg_mask IB_MR_REREG_TRANS):
-- snip --
...
static int iwch_reregister_phys_mem(struct ib_mr *mr,
int mr_rereg_mask,
Quoting Adrian Bunk [EMAIL PROTECTED]:
Subject: [ofa-general] drivers/infiniband/ulp/ipoib/ipoib_main.c:
use-after-free
The Coverity checker spotted the following code introduced by
commit 839fcaba355abaffb7b44f0f4504093acb0b11cf:
-- snip --
...
static void path_rec_completion(int
On Fri, Mar 16, 2007 at 08:27:29PM +, Paulo Marques wrote:
Andrew Morton wrote:
On Fri, 16 Mar 2007 17:16:39 + Paulo Marques [EMAIL PROTECTED]
wrote:
Does freeze_processes() / unfreeze_processes() solve this by only
freezing processes that have voluntarily scheduled (opposed to
IMHO the problem with classifying RxRPC as a reliable datagram
socket is that even an atomic unidirectional communication isn't a
single datagram, it's at least 3; there is shared connection state
Thats fine. Any *reliable* protocol sends more than one packet per
message you send. RDM is
Am Montag, 19. März 2007 10:22 schrieb Adrian Bunk:
void sysfs_drop_dentry(struct sysfs_dirent * sd, struct dentry * parent)
{
struct dentry * dentry = sd-s_dentry;
+ struct inode *inode;
if (dentry) {
spin_lock(dcache_lock);
At Mon, 19 Mar 2007 10:24:38 +0100,
Adrian Bunk wrote:
The Coverity checker spotted this bogus for() loop that produces an
array overrun.
Hmm, I'm dense now before a caffee, but how can it overrun...?
It seems what actually should be done is quite simple?
Yes... unless someone wants to
Sorry, I tried the kernel 2.6.19 and patched it with suspend2 for 2.6.19
For 2.6.20, suspend2 is on development, so I can't use it
Adrian Bunk a écrit :
On Sun, Mar 18, 2007 at 12:07:51AM +0100, Thibaud Hulin wrote:
Hi,
I can't compile with success my kernel, i've got this error message :
Hi Andrew
Here is the new version of this patch. Could you please update mm with it ?
As noticed by Oleg, first version was wrong, reporting three times SELF
values, and no support for RUSAGE_CHILDREN.
RUSAGE_CHILDREN support imply we add cinblock and coublock in signal_struct,
to be able to
Antonio Vargas wrote:
IIRC, about 2 or three years ago (or maybe on the 2.6.10 timeframe),
there was a patch which managed to pass the interactive from one app
to another when there was a pipe or udp connection between them. This
meant that a marked-as-interactive xterm would, when blocked
On 03/19, Eric Dumazet wrote:
+static inline unsigned long task_io_get_inblock(const struct task_struct *p)
+{
+ return p-ioac.read_bytes 9;
+}
[...snip...]
@@ -2021,6 +2022,8 @@ static void k_getrusage(struct task_stru
r-ru_nivcsw = p-signal-cnivcsw;
And those machines are basically identical to perfectly regular i386
platforms.
For modern (2001+) i386 platforms sure. The problem is the old and the weird.
So the whole argument that it would diverge is total crap. It obviously
won't diverge, simply because the support for old setups
On Monday 19 March 2007 11:53, Oleg Nesterov wrote:
On 03/19, Eric Dumazet wrote:
+static inline unsigned long task_io_get_inblock(const struct task_struct
*p) +{
+ return p-ioac.read_bytes 9;
+}
[...snip...]
@@ -2021,6 +2022,8 @@ static void k_getrusage(struct task_stru
On Sun, 18 Mar 2007, Ahmed S. Darwish wrote:
Hi list,
Reading the kernel threads initialization code I see:
int kernel_thread(...) {
struct pt_regs regs;
memset(regs, 0, sizeof(regs));
[...]
**regs.xds = __USER_DS;
**regs.xes = __USER_DS;
[...]
On Mon, 19 Mar 2007 10:27:18 +0200 (EET) Pekka J Enberg [EMAIL PROTECTED]
wrote:
From: Pekka Enberg [EMAIL PROTECTED]
This changes kmem_cache_free() to deal with NULL objects passed to it. The
current behavior is inconsistent with kfree() so there are callers
passing NULL to
Hello,
Here is a patch that adds a mount option named posixtime that, when
enabled, causes the fat/vfat code to not adjust timestamps as they are
read/written to/from disk. The intent of the adjustment as performed
by the existing code appears to be to present correct timestamps to
Windows and
Hi,
On Mon, 19 Mar 2007, Andrew Morton wrote:
err, we don't want to do this, do we? It adds overhead for something which
we've carefully taught all our programmers to not do. The only known code
which will benefit from this is buggy.
Well, I actually disagree with that. It makes little
Hi Andrew
Here is the third version of this patch. Could you please update mm with it ?
As noticed by Oleg, previous versions were wrong, reporting three times SELF
values, and no support for RUSAGE_CHILDREN.
RUSAGE_CHILDREN support imply we add four fields in signal_struct,
to be able to
From: Tasos Parisinos [EMAIL PROTECTED]
This patch changes the crypto/Kconfig and crypto/Makefile and adds
crypto/rsa.c and crypto/rsa.h in the source tree. These files add module
rsa.o (or rsa.ko) in the
kernel (built-in or as a kernel module) and offer an API to do fast
modular
On Sun, Mar 18, 2007 at 03:50:10AM +0100, Nick Piggin wrote:
Yes, that should be the case. So would this mean that nonlinear protections
don't work on regular files? I guess that's OK if Oracle and UML both use
tmpfs/shm?
Sometimes ramfs is also used in the Oracle case. I presume that's even
Christian wrote:
On Monday 19 March 2007 03:48:14 you wrote:
Christian wrote:
On Sunday 18 March 2007 06:43:09 you wrote:
Christian wrote:
This does indeed look like a drive side issue to me (the controller is
reporting CPBs with response flags 2 which as far as I can tell
indicates it's
Ingo Molnar wrote:
what do you think about the idea i suggested: to do an x32_/x64_ prefix
(or _32/_64 postfix), in a brute-force way, _right away_. I.e. do not
have any overlap of having both arch/i386/ and arch/x86_64/ and
arch/x86/ - move everything to arch/x86/ right now.
On Sun, Mar
Christian wrote:
On Sunday 18 March 2007 06:43:09 you wrote:
Christian wrote:
This does indeed look like a drive side issue to me (the controller is
reporting CPBs with response flags 2 which as far as I can tell
indicates it's still waiting for the drive to complete the request).
On 3/19/07, Pekka Enberg [EMAIL PROTECTED] wrote:
EIP is at kmem_cache_free+0x29/0x5a
eax: c180 ebx: f0ae12c0 ecx: c18f73c0 edx: c180
esi: c1919de0 edi: ebp: 1000 esp: f1fe7e14
ds: 007b es: 007b ss: 0068
But somehow eax and edx have the same value 0xc180
On 3/19/07, Pekka Enberg [EMAIL PROTECTED] wrote:
You can see that mempool_free is passing a NULL pointer to
kmem_cache_free() which doesn't handle it properly. The NULL pointer
comes from bio_free() where -bi_io_vec is NULL because nr_iovecs
passed to bio_alloc_bioset() was zero.
The question
The Coverity checker spotted the following inconsequent NULL checking in
drivers/message/fusion/mptscsih.c:
-- snip --
...
int
mptscsih_qcmd(struct scsi_cmnd *SCpnt, void (*done)(struct scsi_cmnd *))
{
...
if (vdev
(vdev-vtarget-tflags MPT_TARGET_FLAGS_Q_YES)
The Coverity checker spotted the following inconsequent NULL checking in
drivers/message/fusion/mptsas.c:
-- snip --
...
static void
mptsas_delete_expander_phys(MPT_ADAPTER *ioc)
{
...
if (port_info-phy_info
(!(port_info-phy_info[0].identify.device_info
On Mon, Mar 19, 2007 at 10:30:08AM +1100, David Chinner wrote:
Generic page_mkwrite functionality.
Filesystems that make use of the VM -page_mkwrite() callout will generally
use
the same core code to implement it. There are several tricky truncate-related
issues that we need to deal with
David Chinner wrote:
On Mon, Mar 19, 2007 at 05:37:03PM +1100, Nick Piggin wrote:
David Chinner wrote:
+block_page_mkwrite(struct vm_area_struct *vma, struct page *page,
+ get_block_t get_block)
+{
+ struct inode *inode = vma-vm_file-f_path.dentry-d_inode;
+
Christoph Hellwig wrote:
On Mon, Mar 19, 2007 at 10:30:08AM +1100, David Chinner wrote:
Generic page_mkwrite functionality.
Filesystems that make use of the VM -page_mkwrite() callout will generally use
the same core code to implement it. There are several tricky truncate-related
issues that
Nick Piggin wrote:
David Chinner wrote:
On Mon, Mar 19, 2007 at 05:37:03PM +1100, Nick Piggin wrote:
David Chinner wrote:
+block_page_mkwrite(struct vm_area_struct *vma, struct page *page,
+ get_block_t get_block)
+{
+struct inode *inode = vma-vm_file-f_path.dentry-d_inode;
On Fri, Mar 16, 2007 at 04:21:03PM +0100, Heiko Carstens wrote:
On Fri, Mar 16, 2007 at 08:01:01PM +0530, Amit K. Arora wrote:
First of all, thanks for the overwhelming response!
Based on the suggestions received, I have added a new parameter to the
sys_fallocate() system call - an
On Sat, Mar 17, 2007 at 04:33:50PM +1100, Stephen Rothwell wrote:
On Fri, 16 Mar 2007 20:01:01 +0530 Amit K. Arora [EMAIL PROTECTED] wrote:
+asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t len);
--- linux-2.6.20.1.orig/include/asm-powerpc/systbl.h
+++
On Mon, Mar 19, 2007 at 02:54:04PM +0530, Amit K. Arora wrote:
On Fri, Mar 16, 2007 at 04:21:03PM +0100, Heiko Carstens wrote:
On Fri, Mar 16, 2007 at 08:01:01PM +0530, Amit K. Arora wrote:
asmlinkage long sys_fallocate(int fd, int mode, loff_t offset, loff_t
len)
Currently we
On Sat, Mar 17, 2007 at 08:37:18PM +1100, Rusty Russell wrote:
On Fri, 2007-03-16 at 12:51 +0100, Ingo Molnar wrote:
* Alexey Dobriyan [EMAIL PROTECTED] wrote:
[cc'ing folks whose proc files are affected]
kallsyms_lookup() can call module_address_lookup() which iterates over
If generic_file_direct_write() has fail (ENOSPC condition) inside
__generic_file_aio_write_nolock() it may have instantiated a few blocks outside
i_size in case of non blockdev files. At least ext2, ext3 and reiserfs interpret
i_size and biggest block difference as error. Later fsck will complain
Where are several places where the same code used for iovec checks.
This patch just move this code to separate helper function, and replace
duplicated code with it. IMHO it is better because these are checks that
we want for all filesystems/drivers that use vectored I/O.
Signed-off-by: Dmitriy
On Mon, Mar 19, 2007 at 10:49:01AM +0300, Dmitriy Monakhov wrote:
Where are several places where the same code used for iovec checks.
This patch just move this code to separate helper function, and replace
duplicated code with it. IMHO it is better because these are checks that
we want for
On Mon, Mar 19, 2007 at 09:11:31PM +1100, Nick Piggin wrote:
I've got the patches in -mm now. I hope they will get merged when the
the next window opens.
I didn't submit the -page_mkwrite conversion yet, because I didn't
have any callers to look at. It is is slightly less trivial than for
Hi all:
I am tracking a driver bug in arm linux when I got a scheduling in
interrupt context
panic.
I traced into kernel schedule() function, and found that schedulingin
interrupt is a
check point when the process scheduler is invoked, and the callstack
reveals that
the scheduler is invoked due
On Mon, Mar 19, 2007 at 08:37:57PM +0800, railroad seeker wrote:
After that, the program counter must located in BUG(), that is something
like
(void *)0 = 0 if we really do scheduling in interrupt contxt, and
should cause
the kernel to panic. However, what i got is that the latest program
Hi!
We have a discussion on alpha mailinglist at the moment, because of
uname -mpi.
AFAIK, uname -m should do some glibc call, which calls kernel, right?
However, I have two machines:
AS1000A:
[EMAIL PROTECTED] ~]# uname -mpi cat /proc/cpuinfo | grep model
alpha alpha alpha
cpu model
On Mon, Mar 19, 2007 at 10:25:52AM +0100, Adrian Bunk wrote:
NULL checks should be before the first dereference.
Spotted by the Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Ondrej Zajicek [EMAIL PROTECTED]
--
Elen sila lumenn' omentielvo
Ondrej 'SanTiago'
From: Ralph Wuerthner [EMAIL PROTECTED]
[S390] zcrypt: fix possible dead lock in AP bus module
AP bus module uses bus_for_each_dev() in software interrupt context to
poll for completed requests which might cause dead locks. Solution: use
private AP device list for polling in software interrupt
From: Ralph Wuerthner [EMAIL PROTECTED]
[S390] zcrypt: fix possible race when unloading zcrypt driver modules
Move try_module_get() call into spin protected block to prevent zcrypt
driver module unload while submitting a request to driver.
Signed-off-by: Ralph Wuerthner [EMAIL PROTECTED]
From: Martin Schwidefsky [EMAIL PROTECTED]
[S390] no execute support cleanup.
Simplify the signal_return function that checks for the two special
system calls sigreturn and rt_sigreturn. No need to do a page table
walk, a call to copy_from_user while disabled page faults will work
as well.
From: Peter Oberparleiter [EMAIL PROTECTED]
[S390] cio: allow 0 and 1 as input for channel path status attribute
Channel path status can now be modified by writing '0' and '1'
to the sysfs status attribute in addition to 'offline' and
'online' respectively.
Signed-off-by: Peter Oberparleiter
From: Peter Oberparleiter [EMAIL PROTECTED]
[S390] cio: introduce separate files for channel-path related code
Signed-off-by: Peter Oberparleiter [EMAIL PROTECTED]
Signed-off-by: Martin Schwidefsky [EMAIL PROTECTED]
---
drivers/s390/cio/Makefile |2
drivers/s390/cio/chp.c|
From: Martin Schwidefsky [EMAIL PROTECTED]
[S390] minor fault path optimization.
The minor fault path has grown a lot in terms of cycles. In particular
the kprobes hook is very costly. Optimize the path to save a couple of
cycles. If kprobes is enabled more than 300 cycles can be avoided if
On Mon, Mar 19, 2007 at 11:27:52AM +0100, Takashi Iwai wrote:
At Mon, 19 Mar 2007 10:24:38 +0100,
Adrian Bunk wrote:
The Coverity checker spotted this bogus for() loop that produces an
array overrun.
Hmm, I'm dense now before a caffee, but how can it overrun...?
Looking again, it
William Lee Irwin III wrote:
Ingo Molnar wrote:
what do you think about the idea i suggested: to do an x32_/x64_ prefix
(or _32/_64 postfix), in a brute-force way, _right away_. I.e. do not
have any overlap of having both arch/i386/ and arch/x86_64/ and
arch/x86/ - move everything to
Please pull from 'for-linus' branch of
git://git390.osdl.marist.edu/pub/scm/linux-2.6.git for-linus
to receive the following updates:
arch/s390/kernel/compat_wrapper.S | 17 +
arch/s390/kernel/debug.c |2 +-
arch/s390/kernel/early.c | 10
On 3/19/07, David Schwartz [EMAIL PROTECTED] wrote:
I didn't suggest adding any unfairness! I suggested being fair by
user/job/process instead of being fair by thread (which is actually
unfair as it favors multi threaded processes over single threaded
processes).
Wouldn't that be unfair
BUG: unable to handle kernel NULL pointer dereference at virtual address
printing eip:
*pde =
Oops: [#1]
Modules linked in: lp parport_pc parport rt73 8139too mii fuse unionfs
nls_iso8859_1 nls_cp437 sr_mod ide_cd cdrom ohci_hcd usbcore
CPU:0
EIP:
and gain nothing anyway.
That's my gripe about the common files directory too.
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Alexander E. Patrakov [EMAIL PROTECTED] writes:
OGAWA Hirofumi wrote:
I don't care about read, because it doesn't corrupt filesystem. I care
about only write, because it can corrupt filesystem.
If it's read-only, I'll not care at all, and will agree.
Here you are right, but please tell
Martin Bligh wrote:
Christoph Lameter wrote:
On Fri, 16 Mar 2007, Martin Bligh wrote:
You have to do some sort of lookup anyway, and Andy seemed to have them
all folded into one.
What lookup would you need to do? On x86_64 even the TLB use is hidden
by the existing 2M entries for 1-1
Paul Collins [EMAIL PROTECTED] writes:
Hello,
Hello,
Here is a patch that adds a mount option named posixtime that, when
enabled, causes the fat/vfat code to not adjust timestamps as they are
read/written to/from disk. The intent of the adjustment as performed
by the existing code appears
On 03/19, Eric Dumazet wrote:
[...snip...]
do {
utime = cputime_add(utime, t-utime);
@@ -2040,6 +2045,8 @@ static void k_getrusage(struct task_stru
r-ru_nivcsw += t-nivcsw;
On Mon, 19 Mar 2007 17:37:23 +0300
Oleg Nesterov [EMAIL PROTECTED] wrote:
(offtopic)
Well..., it *is* ontopic I'm afraid...
We are reading u64 read_bytes/write_bytes which could be updated
asynchronously.
/proc/pid/io does the same.
Of course, I don't blame this patch, just a stupid
Jeremy Fitzhardinge [EMAIL PROTECTED] writes:
Andi Kleen wrote:
On Wednesday 14 March 2007 23:24, Jeremy Fitzhardinge wrote:
The reboot_fixups stuff seems to be a bit of a mess, specifically the
header is in linux/ when its a purely i386-specific piece of code. I'm
not sure why it has
OGAWA Hirofumi wrote:
No, the utf8 support of vfat is wrong. This is implementation
thing, and it is not recommended until it is fixed.
Could you please explain your specific problem with screenshots, preferrably
by running my LiveCD or Debian Etch in an emulator such as qemu or VMware?
Just so you know the context, I'm coming at this from the point of view
of an embedded call server designer.
Mark Hahn wrote:
why do you think fairness is good, especially always good?
Fairness is good because it promotes predictability. See the
deterministic section below.
even
On Tue 2007-03-13 19:42:07, Tim Gardner wrote:
Pavel Machek wrote:
Hi1
I've chased one of the 'Suspend to RAM' resume problems to a specific
line in drivers/char/vt.c, see attached 2.6.21-rc3 diff with
Has suspend/resume ever worked on that hardware?
TRACE_RESUME()
OGAWA Hirofumi wrote:
I'm talking about two filesystems on a system here, not two encoding
on one filesystem. You can change locale on each filesystems, or each
directory, of course if it's not vfat.
Note that you can still achieve this insane result by specifying iocharset
manually for each
Greetings people,
A while back I promised to do some floppy.c cleanups and created an initial
set of patches. Those patches got some good feedback but never got merged.
I want to continue with more substantial cleanups, but it would be nice to get
the initial (rather trivial) bits in first so I
This is a basic CodingStyle cleanup for drivers/block/floppy.c
There are no functional changes in this patch.
Changes made are :
- remove some blank lines and insers others where it improves readability
- make comments a bit more similar in style
- make most
This patch removes the use of the 'register' keyword from floppy.c
Marking some variables 'register' may have made sense in the past (though I
doubt it for these ones), but these days I very much suspect that we would
rather grant gcc more freedom in how to handle the
This removes commented out/dead code from floppy.c
The code in question has been commented out for quite a while (at least as
far as I can see) and I see no reason for it to clutter up the source any
longer.
If, in the future, someone sees a real need to resurrect this
There are lots of printk() statements in floppy.c - more or less all of
them without explicit message levels.
Since a lot of these levels (IMHO) are not warnings, but of a more
informational nature, this patch adds explicit levels to most of the
printk()'s and modifies some of
This fixes the warning
warning: ignoring return value of `device_create_file', declared with
attribute warn_unused_result in function `floppy_init'.
It does this by checking the return value and printing a warning message in
case of no success.
Signed-off-by: Jesper Juhl
- device_create_file(floppy_device[drive].dev,dev_attr_cmos);
+ err = device_create_file(floppy_device[drive].dev,
dev_attr_cmos);
+ if (err)
+ printk(KERN_WARNING Unable to create sysfs attribute
+
1 - 100 of 965 matches
Mail list logo
