On Tue, Feb 19, 2008 at 09:22:27AM -0800, H. Peter Anvin wrote:
> Rasmus Andersen wrote:
[...]
> You have at least one file on a device mapper device (possibly an LVM
> module), and LILO doesn't understand it.
Hi Peter, and thanks for your reply. That was indeed the issue,
On Tue, Feb 19, 2008 at 09:22:27AM -0800, H. Peter Anvin wrote:
Rasmus Andersen wrote:
[...]
You have at least one file on a device mapper device (possibly an LVM
module), and LILO doesn't understand it.
Hi Peter, and thanks for your reply. That was indeed the issue, my /boot
was not mounted
Hello,
I have just upgraded from 2.6.22 to 2.6.24.2 and after booting into the
new kernel and seeing that everything went right, I wanted to make the
new kernel the default boot kernel. But running LILO I got
Fatal: Linux experimental device 0x04x needs to be defined.
Check 'man lilo.conf'
Hello,
I have just upgraded from 2.6.22 to 2.6.24.2 and after booting into the
new kernel and seeing that everything went right, I wanted to make the
new kernel the default boot kernel. But running LILO I got
Fatal: Linux experimental device 0x04x needs to be defined.
Check 'man lilo.conf'
Hello,
I was hoping that you could help me interpret these SATA errors from my
brand new Western Digital disk (at end). Also, this disk seems to refuse
smart commands:
# smartctl -s on -o on -S on /dev/sda
smartctl version 5.37 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce
Allen
Home page is
Hello,
I was hoping that you could help me interpret these SATA errors from my
brand new Western Digital disk (at end). Also, this disk seems to refuse
smart commands:
# smartctl -s on -o on -S on /dev/sda
smartctl version 5.37 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce
Allen
Home page is
On Mon, May 28, 2007 at 11:57:55AM +0200, Rasmus Andersen wrote:
> My main problem is that a check/repair run of my RAID1 device reports
> errors. Not always the same number of errors and not monotonously
> increasing. It has not always been like this but I have not been able to
> link
Hello,
I have for some time been facing some RAID1 issues which I finally have
been able to take the time to write about. I hope you can help me shed
some light on this.
My main problem is that a check/repair run of my RAID1 device reports
errors. Not always the same number of errors and not
Hello,
I have for some time been facing some RAID1 issues which I finally have
been able to take the time to write about. I hope you can help me shed
some light on this.
My main problem is that a check/repair run of my RAID1 device reports
errors. Not always the same number of errors and not
On Mon, May 28, 2007 at 11:57:55AM +0200, Rasmus Andersen wrote:
My main problem is that a check/repair run of my RAID1 device reports
errors. Not always the same number of errors and not monotonously
increasing. It has not always been like this but I have not been able to
link this to any
Hello,
Let me first start by saying that if a better place to ask these
quesions is to be found, please let me know.
I have a 2.6.20 kernel running a raid 1 set with two SATA disks.
Recently (on an older (gentoo-specific) kernel) I started getting
entries like this after my weekly 'echo check >
Hello,
Let me first start by saying that if a better place to ask these
quesions is to be found, please let me know.
I have a 2.6.20 kernel running a raid 1 set with two SATA disks.
Recently (on an older (gentoo-specific) kernel) I started getting
entries like this after my weekly 'echo check
Hi.
The following patch makes drivers/net/tokenring/ibmtr.c
call iounmap before it returns on error paths, makes it
not use check_region(), makes it check the return
of request_region and init_trdev and adds a few comment
strings on #endifs.
It applies against 246ac5 and my writing this patch
Hi.
The following patch makes drivers/net/tokenring/ibmtr.c
call iounmap before it returns on error paths, makes it
not use check_region(), makes it check the return
of request_region and init_trdev and adds a few comment
strings on #endifs.
It applies against 246ac5 and my writing this patch
On Sun, Jun 24, 2001 at 07:14:00PM -0400, Michael H. Warfield wrote:
[...]
> I'm responsible for the kernel / driver integration end of it
> anyways.
>
> I'll find out what's up with Doug, but this is my issue to deal
> with anyways. And yes, I'm looking at it. I've got a couple
On Sun, Jun 24, 2001 at 07:14:00PM -0400, Michael H. Warfield wrote:
[...]
I'm responsible for the kernel / driver integration end of it
anyways.
I'll find out what's up with Doug, but this is my issue to deal
with anyways. And yes, I'm looking at it. I've got a couple of
On Sun, Jun 24, 2001 at 07:14:00PM -0400, Michael H. Warfield wrote:
> On Sun, Jun 24, 2001 at 11:06:06PM +0200, Rasmus Andersen wrote:
> > Hi.
>
> > (My last mail to [EMAIL PROTECTED] bounced. Is there another
> > maintainer for drivers/char/ip2main.c somewhere?)
&
Hi.
The patch below adds a check for create_proc_entry return code
in drivers/media/video/videodev.c. It applies against 245-ac16
and 246p6.
--- linux-245-ac16-clean/drivers/media/video/videodev.c Sun May 27 22:15:23 2001
+++ linux-245-ac16/drivers/media/video/videodev.c Sun Jun 24
Hi.
The following patch tries to avoid a potential null pointer
dereference. It applies against 245-ac16 and 246p6. The
dereference was originally reported by the Stanford team.
--- linux-245-ac16-clean/drivers/media/video/i2c-parport.c Thu Jul 13 01:24:33
2000
+++
Hi.
(My last mail to [EMAIL PROTECTED] bounced. Is there another
maintainer for drivers/char/ip2main.c somewhere?)
The patch below tries to avoid dereferencing (potential)
NULL pointers. It was reported by the Stanford team way
back and applies against 245ac16 and 246p6. It could
probably be
On Sun, Jun 24, 2001 at 10:52:31PM +0200, Eric Lammerts wrote:
[...]
> There are zillions of functions called 'init_module' in the kernel.
> I think my suggestion was better (and it had a \n at the end!)
Agreed. Actually, 'ouch' on point two :) BTW, was it intentional
that you dropped the
On Sat, Jun 23, 2001 at 02:30:06PM -0300, Arnaldo Carvalho de Melo wrote:
[...]
> printk(KERN_ERR __FUNCTION__ "Out of memory.");
>
> Then if you move the code to other function or if you change the name of
> the function you don't have to go all over the code doing
>
On Sat, Jun 23, 2001 at 02:30:06PM -0300, Arnaldo Carvalho de Melo wrote:
[...]
printk(KERN_ERR __FUNCTION__ Out of memory.);
Then if you move the code to other function or if you change the name of
the function you don't have to go all over the code doing
On Sun, Jun 24, 2001 at 10:52:31PM +0200, Eric Lammerts wrote:
[...]
There are zillions of functions called 'init_module' in the kernel.
I think my suggestion was better (and it had a \n at the end!)
Agreed. Actually, 'ouch' on point two :) BTW, was it intentional
that you dropped the
Hi.
(My last mail to [EMAIL PROTECTED] bounced. Is there another
maintainer for drivers/char/ip2main.c somewhere?)
The patch below tries to avoid dereferencing (potential)
NULL pointers. It was reported by the Stanford team way
back and applies against 245ac16 and 246p6. It could
probably be
Hi.
The following patch tries to avoid a potential null pointer
dereference. It applies against 245-ac16 and 246p6. The
dereference was originally reported by the Stanford team.
--- linux-245-ac16-clean/drivers/media/video/i2c-parport.c Thu Jul 13 01:24:33
2000
+++
On Sun, Jun 24, 2001 at 07:14:00PM -0400, Michael H. Warfield wrote:
On Sun, Jun 24, 2001 at 11:06:06PM +0200, Rasmus Andersen wrote:
Hi.
(My last mail to [EMAIL PROTECTED] bounced. Is there another
maintainer for drivers/char/ip2main.c somewhere?)
I'm still here. :-) Just
Hi.
The patch below adds a check for create_proc_entry return code
in drivers/media/video/videodev.c. It applies against 245-ac16
and 246p6.
--- linux-245-ac16-clean/drivers/media/video/videodev.c Sun May 27 22:15:23 2001
+++ linux-245-ac16/drivers/media/video/videodev.c Sun Jun 24
Hi.
The following patch adds some checks for kmalloc returning NULL
to fs/jffs/intrep.c along with some way of getting that propagated
back. Applies against 245ac16 and 246p5. These dereferences were
reported by the Stanford team a way back.
--- linux-245-ac16-clean/fs/jffs/intrep.c Thu
Hi.
The patch below adds a kmalloc check to drivers/pcmcmia/rsrc_mgr.c.
Against 245-ac16 but aplies to 256p6 also. Reported a while back
by the stanford team.
--- linux-245-ac16-clean/drivers/pcmcia/rsrc_mgr.c Sat May 19 20:59:21 2001
+++ linux-245-ac16/drivers/pcmcia/rsrc_mgr.cSat
Hi.
The patch below adds a kmalloc check to drivers/pcmcmia/rsrc_mgr.c.
Against 245-ac16 but aplies to 256p6 also. Reported a while back
by the stanford team.
--- linux-245-ac16-clean/drivers/pcmcia/rsrc_mgr.c Sat May 19 20:59:21 2001
+++ linux-245-ac16/drivers/pcmcia/rsrc_mgr.cSat
Hi.
The following patch adds some checks for kmalloc returning NULL
to fs/jffs/intrep.c along with some way of getting that propagated
back. Applies against 245ac16 and 246p5. These dereferences were
reported by the Stanford team a way back.
--- linux-245-ac16-clean/fs/jffs/intrep.c Thu
On Fri, Jun 22, 2001 at 05:21:06PM -0300, Arnaldo Carvalho de Melo wrote:
> Hi Rasmus,
>
> I've fixed this ones and its already in 2.4.6-pre5, please take a
> look and see if something is missing.
These patches are very close so I'll of course retract mine[1].
The only thing I'll
Hi.
The patch below adds one instance of vmalloc return code checking
and a number of error path resource release cleanups in build_maps.
It is against 245-ac16.
(The vmalloc non-check was reported by the Stanford team a
while back.)
--- linux-245-ac16-clean/drivers/mtd/ftl.c Sun May 27
Hi.
The following patch #ifdefs a function to be in its preprocessor
scope and eliminates the use of check_region, adds '\n' to printk's,
adds checks for kmalloc and does error path resource releasing
in ip2_init_board. All in drivers/char/ip2main.c and against
245ac16.
(The kmalloc part of
Hi.
The following patch #ifdefs a function to be in its preprocessor
scope and eliminates the use of check_region, adds '\n' to printk's,
adds checks for kmalloc and does error path resource releasing
in ip2_init_board. All in drivers/char/ip2main.c and against
245ac16.
(The kmalloc part of
Hi.
The patch below adds one instance of vmalloc return code checking
and a number of error path resource release cleanups in build_maps.
It is against 245-ac16.
(The vmalloc non-check was reported by the Stanford team a
while back.)
--- linux-245-ac16-clean/drivers/mtd/ftl.c Sun May 27
On Fri, Jun 22, 2001 at 05:21:06PM -0300, Arnaldo Carvalho de Melo wrote:
Hi Rasmus,
I've fixed this ones and its already in 2.4.6-pre5, please take a
look and see if something is missing.
These patches are very close so I'll of course retract mine[1].
The only thing I'll recommend is
On Tue, Jun 19, 2001 at 10:41:51AM +0100, Jeremy Sanders wrote:
> I've found a patch which fixes the hanging problem, so I guess it's not
> linux-kernel which is at fault. Get it from Wayne Davison at:
Works for me too.
--
Rasmus([EMAIL PROTECTED])
"Men kick friendship around like
On Tue, Jun 19, 2001 at 10:41:51AM +0100, Jeremy Sanders wrote:
I've found a patch which fixes the hanging problem, so I guess it's not
linux-kernel which is at fault. Get it from Wayne Davison at:
Works for me too.
--
Rasmus([EMAIL PROTECTED])
Men kick friendship around like a
On Tue, Jun 12, 2001 at 11:23:02AM -0400, Disconnect wrote:
> On Tue, 12 Jun 2001, David S. Miller did have cause to say:
>
> > Look everyone, it was determined to be a deadlock because of some
> > interaction between how rsync sets up it's communication channels
> > with the ssh subprocess,
On Tue, Jun 12, 2001 at 02:59:12PM +0100, Jeremy Sanders wrote:
> I'm getting numerous rsync (v2.4.6) problems under Linux 2.4.2 (RedHat
> 7.1) or stock 2.4.4 on several machines. rsync often hangs copying files
> from NFS or local disks to local disks. Strangely the problem is fixed by
>
On Tue, Jun 12, 2001 at 02:59:12PM +0100, Jeremy Sanders wrote:
I'm getting numerous rsync (v2.4.6) problems under Linux 2.4.2 (RedHat
7.1) or stock 2.4.4 on several machines. rsync often hangs copying files
from NFS or local disks to local disks. Strangely the problem is fixed by
stracing
On Tue, Jun 12, 2001 at 11:23:02AM -0400, Disconnect wrote:
On Tue, 12 Jun 2001, David S. Miller did have cause to say:
Look everyone, it was determined to be a deadlock because of some
interaction between how rsync sets up it's communication channels
with the ssh subprocess, readas:
Hi.
The patch below fixes what I believe is a bug in hysdn_net.c.
I cannot see how we can proceed under _any_ circumstances
after the kmalloc fails. Applies against 245ac1.
--- linux-245-ac1-clean/drivers/isdn/hysdn/hysdn_net.c Sun May 27 22:15:22 2001
+++
(Forgot l-k again... :<)
- Forwarded message from Rasmus Andersen <[EMAIL PROTECTED]> -
Hi.
The following patch removes two superfluous initializations
from aironet4500_proc.c, making the .o ~12K smaller in
size. It applies against 245ac1 and was discovered by Adam
Ritcher
(Forgot l-k again... :)
- Forwarded message from Rasmus Andersen [EMAIL PROTECTED] -
Hi.
The following patch removes two superfluous initializations
from aironet4500_proc.c, making the .o ~12K smaller in
size. It applies against 245ac1 and was discovered by Adam
Ritcher some time ago
Hi.
The patch below fixes what I believe is a bug in hysdn_net.c.
I cannot see how we can proceed under _any_ circumstances
after the kmalloc fails. Applies against 245ac1.
--- linux-245-ac1-clean/drivers/isdn/hysdn/hysdn_net.c Sun May 27 22:15:22 2001
+++
Hi.
The following patch makes irttp_read_proc restore_flags()
in error cases too. Applies against 245ac1.
--- linux-245-ac1-clean/net/irda/irttp.cSun May 27 22:15:34 2001
+++ linux-245-ac1/net/irda/irttp.c Sun May 27 22:37:59 2001
@@ -1598,7 +1598,7 @@
self = (struct
Hi.
The following patch fixes an interrupt flag bug in irtty.c
as per the stanford team's report way back. Applies against
224-ac18.
--- linux-244-ac18-clean/drivers/net/irda/irtty.c Sat May 19 20:59:17 2001
+++ linux-244-ac18/drivers/net/irda/irtty.c Sun May 27 21:56:14 2001
@@
Hi.
The following patch adds a missing restore_flags as per the
stanford team's report way back. Applies against 244ac18.
--- linux-244-ac18-clean/drivers/net/hamradio/soundmodem/sm_wss.c Wed Jul 19
01:55:19 2000
+++ linux-244-ac18/drivers/net/hamradio/soundmodem/sm_wss.c Sun May 27
Forgot l-k when sending this off..
- Forwarded message from Rasmus Andersen <[EMAIL PROTECTED]> -
Hi.
The following patch fixes a missing rio_spin_unlock_irqrestore
in drivers/char/rio/rioroute.c as per the stanford team's
report a way back. It applies against 244ac18.
--- lin
Forgot l-k when sending this off...
- Forwarded message from Rasmus Andersen <[EMAIL PROTECTED]> -
Hi.
The following patch fixes a buggy variable reuse i drivers/char/
rio/riotable.c (244-ac18) as reported by the stanford team way
back.
--- linux-244-ac18-clean/drivers/ch
Forgot l-k when sending this off...
- Forwarded message from Rasmus Andersen [EMAIL PROTECTED] -
Hi.
The following patch fixes a buggy variable reuse i drivers/char/
rio/riotable.c (244-ac18) as reported by the stanford team way
back.
--- linux-244-ac18-clean/drivers/char/rio
sigh Forgot l-k when sending this off..
- Forwarded message from Rasmus Andersen [EMAIL PROTECTED] -
Hi.
The following patch fixes a missing rio_spin_unlock_irqrestore
in drivers/char/rio/rioroute.c as per the stanford team's
report a way back. It applies against 244ac18.
--- linux
Hi.
The following patch adds a missing restore_flags as per the
stanford team's report way back. Applies against 244ac18.
--- linux-244-ac18-clean/drivers/net/hamradio/soundmodem/sm_wss.c Wed Jul 19
01:55:19 2000
+++ linux-244-ac18/drivers/net/hamradio/soundmodem/sm_wss.c Sun May 27
Hi.
The following patch makes irttp_read_proc restore_flags()
in error cases too. Applies against 245ac1.
--- linux-245-ac1-clean/net/irda/irttp.cSun May 27 22:15:34 2001
+++ linux-245-ac1/net/irda/irttp.c Sun May 27 22:37:59 2001
@@ -1598,7 +1598,7 @@
self = (struct
Hi.
The following patch fixes an interrupt flag bug in irtty.c
as per the stanford team's report way back. Applies against
224-ac18.
--- linux-244-ac18-clean/drivers/net/irda/irtty.c Sat May 19 20:59:17 2001
+++ linux-244-ac18/drivers/net/irda/irtty.c Sun May 27 21:56:14 2001
@@
(Forgot l-k when sending this off to [EMAIL PROTECTED] :/)
Hi.
The following patch tries to eliminate the interrupt flag bugs
identified by the stanford team a while back in drivers/net/wan/
comx-hw-mixcom.c. It moves request_region and request_irq outside
the cli()/restore_flags() pair as they
Hi.
The following patch tries to correct the interrupt bugs found
by the stanford team a long time ago in drivers/net/irda/irport.c.
Applies against 2.4.4-ac18.
--- linux-244-ac18-clean/drivers/net/irda/irport.c Sat May 19 20:59:17 2001
+++ linux-244-ac18/drivers/net/irda/irport.cSat
(Forgot l-k when sending this off to [EMAIL PROTECTED] :/)
Hi.
The following patch tries to eliminate the interrupt flag bugs
identified by the stanford team a while back in drivers/net/wan/
comx-hw-mixcom.c. It moves request_region and request_irq outside
the cli()/restore_flags() pair as they
Hi.
The following patch tries to correct the interrupt bugs found
by the stanford team a long time ago in drivers/net/irda/irport.c.
Applies against 2.4.4-ac18.
--- linux-244-ac18-clean/drivers/net/irda/irport.c Sat May 19 20:59:17 2001
+++ linux-244-ac18/drivers/net/irda/irport.cSat
On Fri, May 25, 2001 at 11:11:23PM +0200, Jens Axboe wrote:
[...]
> This isn't right. Granted the locking isn't straight forward here, but
> take a look at ide_write_setting -> ide_spin_wait_hwgroup and the
> latters return value.
Yes, Andre set me straight here. My apologies for being lazy
Hi.
The following patch changes an __init to __initdata. Applies against
2.4.4-ac11.
--- linux-244-ac11-clean/drivers/video/matrox/matroxfb_base.c Sat May 19 20:58:43
2001
+++ linux-244-ac11/drivers/video/matrox/matroxfb_base.c Sun May 20 23:55:24 2001
@@ -2483,7 +2483,7 @@
return
(I forgot to cc l-k on this one when it went to andre.)
Hi.
This patch adds a spin_unlock_irqsave to ide_spin_wait_hwgroup as
reported by the Stanford team way back. It applies against 244ac16.
--- linux-244-ac16-clean/drivers/ide/ide.c Fri May 25 21:11:08 2001
+++
On Fri, May 25, 2001 at 01:47:52PM -0700, Andre Hedrick wrote:
>
> Not valid because the jump to that part of the code is protected.
> If a polling response for a valid status and no timeout, is detected then
> it attempts to the command for real only after success or a test.
>
> Otherwise it
Hi.
This trivial patch adds a kmalloc check to ide-tape.c::
idetape_onstream_read_back_buffer as per the Stanford team's report
way back. It applies against 244ac16.
Reading the code I was not sure if it was OK to just return
or more should be done. Please sanity check this.
---
Hi.
The following patch adds a number of checks for kmalloc returns
to drivers/ide/ide-probe.c. It applies against ac16.
One comment: This patch adds 'drive-present = 0' to the
code path for the EXABYTE case. I could not discern if this was a
shortcoming of the original code or not. Please
Hi.
This patch adds a check for the return value from kmalloc in
ide_cdrom_open. Applies against ac16.
--- linux-244-ac16-clean/drivers/ide/ide-cd.c Fri May 25 21:11:08 2001
+++ linux-244-ac16/drivers/ide/ide-cd.c Fri May 25 21:30:20 2001
@@ -2869,12 +2869,12 @@
int ide_cdrom_open (struct
Hi.
The following patch changes an __init to an __initdata. Applies
against 2.4.4-ac16.
--- linux-244-ac16-clean/arch/ppc/kernel/feature.c Sat May 19 21:06:18 2001+++
linux-244-ac16/arch/ppc/kernel/feature.cMon May 21 00:04:35 2001
@@ -267,7 +267,7 @@
static struct board_features_t
Hi.
The following patch changes an __init to an __initdata. Applies
against 2.4.4-ac16.
--- linux-244-ac16-clean/arch/ppc/kernel/feature.c Sat May 19 21:06:18 2001+++
linux-244-ac16/arch/ppc/kernel/feature.cMon May 21 00:04:35 2001
@@ -267,7 +267,7 @@
static struct board_features_t
Hi.
This patch adds a check for the return value from kmalloc in
ide_cdrom_open. Applies against ac16.
--- linux-244-ac16-clean/drivers/ide/ide-cd.c Fri May 25 21:11:08 2001
+++ linux-244-ac16/drivers/ide/ide-cd.c Fri May 25 21:30:20 2001
@@ -2869,12 +2869,12 @@
int ide_cdrom_open (struct
Hi.
The following patch adds a number of checks for kmalloc returns
to drivers/ide/ide-probe.c. It applies against ac16.
One comment: This patch adds 'drive-present = 0' to the
code path for the EXABYTE case. I could not discern if this was a
shortcoming of the original code or not. Please
Hi.
This trivial patch adds a kmalloc check to ide-tape.c::
idetape_onstream_read_back_buffer as per the Stanford team's report
way back. It applies against 244ac16.
Reading the code I was not sure if it was OK to just return
or more should be done. Please sanity check this.
---
On Fri, May 25, 2001 at 01:47:52PM -0700, Andre Hedrick wrote:
Not valid because the jump to that part of the code is protected.
If a polling response for a valid status and no timeout, is detected then
it attempts to the command for real only after success or a test.
Otherwise it would
(I forgot to cc l-k on this one when it went to andre.)
Hi.
This patch adds a spin_unlock_irqsave to ide_spin_wait_hwgroup as
reported by the Stanford team way back. It applies against 244ac16.
--- linux-244-ac16-clean/drivers/ide/ide.c Fri May 25 21:11:08 2001
+++
Hi.
The following patch changes an __init to __initdata. Applies against
2.4.4-ac11.
--- linux-244-ac11-clean/drivers/video/matrox/matroxfb_base.c Sat May 19 20:58:43
2001
+++ linux-244-ac11/drivers/video/matrox/matroxfb_base.c Sun May 20 23:55:24 2001
@@ -2483,7 +2483,7 @@
return
On Fri, May 25, 2001 at 11:11:23PM +0200, Jens Axboe wrote:
[...]
This isn't right. Granted the locking isn't straight forward here, but
take a look at ide_write_setting - ide_spin_wait_hwgroup and the
latters return value.
Yes, Andre set me straight here. My apologies for being lazy and
On Thu, May 24, 2001 at 09:00:20AM -0700, Jonathan Lundell wrote:
[...]
>
> Fine. But:
>
> At 3:02 AM +0200 2001-05-24, Andrzej Krzysztofowicz wrote:
> >-printk(version);
> >+#ifdef MODULE
> >+printk("s", version);
> > printed_version = 1;
> >+#endif /* MODULE */
>
> ...is playing
On Thu, May 24, 2001 at 09:00:20AM -0700, Jonathan Lundell wrote:
[...]
Fine. But:
At 3:02 AM +0200 2001-05-24, Andrzej Krzysztofowicz wrote:
-printk(version);
+#ifdef MODULE
+printk(s, version);
printed_version = 1;
+#endif /* MODULE */
...is playing it just a little
Hi.
The following trivial patch against 2.4.4(-ac11) makes ps2esdi compile.
--- linux-244-ac10-clean/drivers/block/ps2esdi.cSat May 19 21:06:29 2001
+++ linux-244-ac10/drivers/block/ps2esdi.c Sun May 20 14:47:04 2001
@@ -953,10 +953,10 @@
break;
}
Hi.
The following trivial patch against 2.4.4(-ac11) makes ps2esdi compile.
--- linux-244-ac10-clean/drivers/block/ps2esdi.cSat May 19 21:06:29 2001
+++ linux-244-ac10/drivers/block/ps2esdi.c Sun May 20 14:47:04 2001
@@ -953,10 +953,10 @@
break;
}
Disclaimer: I know nothing of this device/hw, the scsi protocol or
anything remotely applicable the functioning of this driver. The
stuff below is just nit-picking and PITA-ing :) Pro-active kernel
janitoring, if you like.
On Sat, May 12, 2001 at 11:43:04AM -0500, James Bottomley wrote:
[...]
>
Disclaimer: I know nothing of this device/hw, the scsi protocol or
anything remotely applicable the functioning of this driver. The
stuff below is just nit-picking and PITA-ing :) Pro-active kernel
janitoring, if you like.
On Sat, May 12, 2001 at 11:43:04AM -0500, James Bottomley wrote:
[...]
On Tue, Feb 27, 2001 at 10:02:11AM +, Russell King wrote:
> Hi,
>
> I'm seeing odd behaviour with rsync over ssh between two x86 machines -
> one if the is an UP PIII (Katmai) running 2.4.2 (isdn-gw) and the other
> is an UP Pentium 75-200 (pilt-gw) running 2.2.15pre13 with some custom
>
On Tue, Feb 27, 2001 at 10:02:11AM +, Russell King wrote:
Hi,
I'm seeing odd behaviour with rsync over ssh between two x86 machines -
one if the is an UP PIII (Katmai) running 2.4.2 (isdn-gw) and the other
is an UP Pentium 75-200 (pilt-gw) running 2.2.15pre13 with some custom
serial
On Sun, Feb 25, 2001 at 02:46:15PM +, Alan Cox wrote:
> > I am sorry but have I inverted the arguments to the memcpy_*io calls?
> > Or are you referring to something other than the arguments here?
>
> You seem to have swapped the source/dest over in memcpy_toio cases and I need
> to convince
>
> Im running PIO. However while I agree with that one Im dubious about the
> inverts on the memcpy_*io bits
>
I am sorry but have I inverted the arguments to the memcpy_*io calls?
Or are you referring to something other than the arguments here?
--
Rasmus([EMAIL PROTECTED])
"Science
On Sun, Feb 25, 2001 at 02:05:42PM +, Alan Cox wrote:
[...]
> > (An indication of how often this code path is used can be found in
> > the fact that the previous define of NCR5380_write had its payload
> > and address mixed up, probably making for wierd results should
> > the code ever be
Hi.
(Does anybody know who the maintainer for this code is?)
The patch below moves drivers/scsi/g_NCR5380.c from using isa_{read,
write, memcpy} to ioremap and the equivalent non-isa functions. It
also fixes an 'unused variable' warning and exchanges check_region for
request_region (and fixes a
Hi.
(Does anybody know who the maintainer for this code is?)
The patch below moves drivers/scsi/g_NCR5380.c from using isa_{read,
write, memcpy} to ioremap and the equivalent non-isa functions. It
also fixes an 'unused variable' warning and exchanges check_region for
request_region (and fixes a
On Sun, Feb 25, 2001 at 02:05:42PM +, Alan Cox wrote:
[...]
(An indication of how often this code path is used can be found in
the fact that the previous define of NCR5380_write had its payload
and address mixed up, probably making for wierd results should
the code ever be executed.)
Im running PIO. However while I agree with that one Im dubious about the
inverts on the memcpy_*io bits
I am sorry but have I inverted the arguments to the memcpy_*io calls?
Or are you referring to something other than the arguments here?
--
Rasmus([EMAIL PROTECTED])
"Science is
On Sun, Feb 25, 2001 at 02:46:15PM +, Alan Cox wrote:
I am sorry but have I inverted the arguments to the memcpy_*io calls?
Or are you referring to something other than the arguments here?
You seem to have swapped the source/dest over in memcpy_toio cases and I need
to convince myself
Hi.
(I have not been able to find a probable current maintainer for
this code.)
The following patch makes drivers/scsi/seagate.c use ioremap
instead of isa_{read, write} (I have not been able to find
a fitting place to put an iounmap since the driver does not
have a release function). The patch
On Mon, Feb 19, 2001 at 11:09:33PM +0100, Rasmus Andersen wrote:
[...]
(I'll just continue talking to myself in the hope that somebody
will read this and be inspired.)
In order to clear things up I should clearly state that my rsync
problem manifests itself under local operation. Ie., 'rsync
On Mon, Feb 19, 2001 at 11:09:33PM +0100, Rasmus Andersen wrote:
[...]
(I'll just continue talking to myself in the hope that somebody
will read this and be inspired.)
In order to clear things up I should clearly state that my rsync
problem manifests itself under local operation. Ie., 'rsync
Hi.
(I have not been able to find a probable current maintainer for
this code.)
The following patch makes drivers/scsi/seagate.c use ioremap
instead of isa_{read, write} (I have not been able to find
a fitting place to put an iounmap since the driver does not
have a release function). The patch
Hi.
For some time up through the testX kernels I used rsync to
update my "dirty" tree after applying the latest patches to the
clean tree. At some point this stopped working (more about that
later) but as new kernels were coming fast at that time I did
not think much of it, assuming that
Hi.
For some time up through the testX kernels I used rsync to
update my "dirty" tree after applying the latest patches to the
clean tree. At some point this stopped working (more about that
later) but as new kernels were coming fast at that time I did
not think much of it, assuming that
1 - 100 of 388 matches
Mail list logo
