> Quoting Alexey Kuznetsov <[EMAIL PROTECTED]>:
> Subject: Re: dst_ifdown breaks infiniband?
>
> Hello!
>
> > If a device driver sets neigh_destructor in neigh_params, this could
> > get called after the device has been unregistered and the driver module
> > removed.
>
> It is the same problem:
On Mon, 19 Mar 2007 12:46:16 +, Alan Cox wrote:
> > > This duplicates the IDE core LED trigger in the libata core.
> > > I plan to use this by allowing PMU LED control on G5 towers. My test
> > > platform
> > > is a PowerMac 7,3 (Dual G5 2.0GHz, June 2004) with a K2 (sata_svw)
> > >
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
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
Hello!
> If a device driver sets neigh_destructor in neigh_params, this could
> get called after the device has been unregistered and the driver module
> removed.
It is the same problem: if dst->neighbour holds neighbour, it should
not hold device. parms->dev is not supposed to be used after
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
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
> message transmission. You yourself defined RDM to be a datagram service.
> RxRPC is not, in my opinion, a datagram service, and neither is it a stream
> service.
Message is what I should have said.
> Interestingly, searching for SOCK_RDM definitions with google shows there's
> some
Alan Cox <[EMAIL PROTECTED]> wrote:
> > 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
On Mon, 19 Mar 2007 13:42:37 +0900
Tejun Heo <[EMAIL PROTECTED]> wrote:
> Tony Vroon wrote:
> > This duplicates the IDE core LED trigger in the libata core.
> > I plan to use this by allowing PMU LED control on G5 towers. My test
> > platform
> > is a PowerMac 7,3 (Dual G5 2.0GHz, June 2004)
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
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
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
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)
> > >
> > >
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(, 0, sizeof(regs));
> [...]
> **regs.xds = __USER_DS;
> **regs.xes = __USER_DS;
> [...]
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
> 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
On Mon, Mar 19, 2007 at 08:48:00AM +0100, Paul Rolland wrote:
> Would you agree to a patch to add a kernel boot parameter to skip some
> ata ports ?
It should in theory not be neccessary
> I found some archives refering to some "ataX=noprobe", but it seems
> to have no effect, and I'd like to
On Monday 19 March 2007 00:46, Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> > Yes. All inline assembly tells gcc what registers are clobbered
> > and it fills in the tables. Hand clobbering in inline assembly cannot
> > be expressed with the current toolchain, so we moved all those
> > out of
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 =
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
--
HID bus design overview.
--
A. Terms.
The device of an driver: this mean the device that this driver matched.
B. Design.
As we discussed before, The entire HID subsystem is divided into
three layers:
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
Am Montag, 19. März 2007 10:25 schrieb Adrian Bunk:
> The Coverity checker spotted the following NULL dereference:
And this fixes an oops upon allocation failures.
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
-
---
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 :
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
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 =
Am Montag, 19. März 2007 10:25 schrieb Adrian Bunk:
> static ssize_t iowarrior_write(struct file *file,
>const char __user *user_buffer,
>size_t count, loff_t *ppos)
> {
> ...
> if (!int_out_urb) {
>
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
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
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(_lock);
>
> 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.
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 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
> Quoting Michael S. Tsirkin <[EMAIL PROTECTED]>:
> Subject: Re: dst_ifdown breaks infiniband?
>
> > > Any simpler ideas?
> >
> > Well, if inifiniband destructor really needs to take that lock... no.
> > Right now I do not see.
>
> OK, this is actually not hard to fix - for infiniband, we can
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
> 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
> > Any simpler ideas?
>
> Well, if inifiniband destructor really needs to take that lock... no.
> Right now I do not see.
OK, this is actually not hard to fix - for infiniband, we can just look at
neighbour->dev->type or compare neighbour->dev and
neighbour->parms->dev - if they are different,
Hello!
> I think the thing to do is to just leave the loopback references
> in place, try to unregister the per-namespace loopback device,
> and that will safely wait for all the references to go away.
Yes, it is exactly how it works in openvz. All the sockets are killed,
queues are cleared,
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
> Quoting Alexey Kuznetsov <[EMAIL PROTECTED]>:
> Subject: Re: [ofa-general] Re: dst_ifdown breaks infiniband?
>
> > Does this look sane (untested)?
>
> It does not, unfortunately.
>
> Instead of regular crash in infiniband you will get numerous
> random NULL pointer dereferences both due to
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,
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 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
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 Coverity checker spotted the following NULL dereference:
<-- snip -->
...
static ssize_t iowarrior_write(struct file *file,
const char __user *user_buffer,
size_t count, loff_t *ppos)
{
...
if (!int_out_urb) {
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/usb/input/gtco.c.old 2007-03-19
09:29:44.0 +0100
+++ linux-2.6.21-rc3-mm2/drivers/usb/input/gtco.c 2007-03-19
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 &&
Hello!
> Does this look sane (untested)?
It does not, unfortunately.
Instead of regular crash in infiniband you will get numerous
random NULL pointer dereferences both due to dst->neighbour
and due to dst->dev.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
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 -
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 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 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 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)
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
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
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)
Hello!
> Well I don't think the loopback device is currently but as soon
> as we get network namespace support we will have multiple loopback
> devices and they will get unregistered when we remove the network
> namespace.
There is no logical difference. At the moment when namespace is gone
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 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
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
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
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
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:
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
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>:
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
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
> 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,
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
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
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
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
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
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
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
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
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
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
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?
401 - 500 of 965 matches
Mail list logo
