_dest(struct ip_vs_service *sv
> write_lock_bh(&__ip_vs_svc_lock);
>
> /* Wait until all other svc users go away */
> - while (atomic_read(>usecnt) > 1) {};
> + IP_VS_WAIT_WHILE(atomic_read(>usecnt) > 1);
>
> /* call
-usecnt) 1) {};
+ IP_VS_WAIT_WHILE(atomic_read(svc-usecnt) 1);
/* call the update_service, because server weight may be changed */
svc-scheduler-update_service(svc);
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list
> IA64
>
> Subject : Regression in serial console on ia64 after 2.6.22
> References : http://marc.info/?l=linux-ia64=118483645914066=2
> Last known good : ?
> Submitter : Horms <[EMAIL PROTECTED]>
> Caused-By : Yinghai Lu <[EMAIL PROTECTE
IA64
Subject : Regression in serial console on ia64 after 2.6.22
References : http://marc.info/?l=linux-ia64m=118483645914066w=2
Last known good : ?
Submitter : Horms [EMAIL PROTECTED]
Caused-By : Yinghai Lu [EMAIL PROTECTED]
commit
On Tue, Jul 24, 2007 at 04:57:32PM -0700, Yinghai Lu wrote:
>
> IA64
>
> Subject : Regression in serial console on ia64 after 2.6.22
> References : http://marc.info/?l=linux-ia64=118483645914066=2
> Last known good : ?
> Submitter : Horms <[EM
On Tue, Jul 24, 2007 at 04:57:32PM -0700, Yinghai Lu wrote:
IA64
Subject : Regression in serial console on ia64 after 2.6.22
References : http://marc.info/?l=linux-ia64m=118483645914066w=2
Last known good : ?
Submitter : Horms [EMAIL PROTECTED]
Caused
ated version is below.
> > +#define KEXEC_NOTE_BYTES ( (KEXEC_NOTE_HEAD_BYTES * 2) + \
>
> Why are we multiplying KEXEC_NOTE_HEAD_BYTES with 2?
The way that the note merging code works in vmcore it assumes that
the area is a list of notes. And there is a terminating note that
h
the header values set to 0, and nothing else. So the time 2
is for the space to store the terminating note.
This structure isn't entirely neccessary, and if we were to modify the
mergeing code in vmcore (which runs in the second kernel) it could be
changed.
--
Horms
H: http://www.vergenet.net/~horms
On Fri, Mar 16, 2007 at 07:17:43AM +, Ian Campbell wrote:
> On Fri, 2007-03-16 at 08:48 +0900, Horms wrote:
> > > >
> > > > Signed-off-by: Ian Campbell <[EMAIL PROTECTED]>
> > > >
> > > > diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore
On Fri, Mar 16, 2007 at 08:52:30AM +0530, Vivek Goyal wrote:
> On Fri, Mar 16, 2007 at 11:40:07AM +0900, Magnus Damm wrote:
> > On 3/16/07, Horms <[EMAIL PROTECTED]> wrote:
> > >On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
> > >> On Thu, M
On Fri, Mar 16, 2007 at 07:17:43AM +, Ian Campbell wrote:
On Fri, 2007-03-16 at 08:48 +0900, Horms wrote:
Signed-off-by: Ian Campbell [EMAIL PROTECTED]
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index d960507..523e109 100644
--- a/fs/proc/vmcore.c
+++ b/fs
On Fri, Mar 16, 2007 at 08:52:30AM +0530, Vivek Goyal wrote:
On Fri, Mar 16, 2007 at 11:40:07AM +0900, Magnus Damm wrote:
On 3/16/07, Horms [EMAIL PROTECTED] wrote:
On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
On Thu, Mar 15, 2007 at 12:22:57PM +, Ian Campbell wrote
). For now most patches go in either through Andrew or the
relevant architecture maintainers.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTEC
m-i386/kexec.h
> > +++ b/include/asm-i386/kexec.h
> > @@ -47,6 +47,9 @@
> > /* The native architecture */
> > #define KEXEC_ARCH KEXEC_ARCH_386
> >
> > +/* We can also handle crash dumps from 64 bit kernel. */
> > +#define vmcore_elf_check_arch_c
On Thu, Mar 15, 2007 at 11:17:26AM +0530, Vivek Goyal wrote:
> On Thu, Mar 15, 2007 at 02:07:56PM +0900, Horms wrote:
> > On Thu, Mar 15, 2007 at 10:25:36AM +0530, Vivek Goyal wrote:
> > > On Thu, Mar 15, 2007 at 10:46:38AM +0900, Horms wrote:
> > > > On Wed, Mar 14,
On Thu, Mar 15, 2007 at 11:17:26AM +0530, Vivek Goyal wrote:
On Thu, Mar 15, 2007 at 02:07:56PM +0900, Horms wrote:
On Thu, Mar 15, 2007 at 10:25:36AM +0530, Vivek Goyal wrote:
On Thu, Mar 15, 2007 at 10:46:38AM +0900, Horms wrote:
On Wed, Mar 14, 2007 at 05:00:09PM +, Ian Campbell
architecture maintainers.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
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
archtectures as
vmcore_elf_check_arch_cross isn't defined for them?
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
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
On Thu, Mar 15, 2007 at 10:25:36AM +0530, Vivek Goyal wrote:
> On Thu, Mar 15, 2007 at 10:46:38AM +0900, Horms wrote:
> > On Wed, Mar 14, 2007 at 05:00:09PM +, Ian Campbell wrote:
> > > The specific case I am encountering is kdump under Xen with a 64 bit
> > > h
On Wed, Mar 14, 2007 at 05:00:09PM +, Ian Campbell wrote:
> The specific case I am encountering is kdump under Xen with a 64 bit
> hypervisor and 32 bit kernel/userspace. The dump created is a 64 bit due
> to the hypervisor but the dump kernel is 32 bit to match the domain 0
> kernel.
>
>
On Wed, Mar 14, 2007 at 05:00:09PM +, Ian Campbell wrote:
The specific case I am encountering is kdump under Xen with a 64 bit
hypervisor and 32 bit kernel/userspace. The dump created is a 64 bit due
to the hypervisor but the dump kernel is 32 bit to match the domain 0
kernel.
It's
On Thu, Mar 15, 2007 at 10:25:36AM +0530, Vivek Goyal wrote:
On Thu, Mar 15, 2007 at 10:46:38AM +0900, Horms wrote:
On Wed, Mar 14, 2007 at 05:00:09PM +, Ian Campbell wrote:
The specific case I am encountering is kdump under Xen with a 64 bit
hypervisor and 32 bit kernel/userspace
On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
> With the advent of kdump, the assumption that the boot CPU when running
> an UP kernel is always the CPU with a hardware ID of 0 (usually referred
> to as BSP on some architectures) does not hold true anymore. The reason
On Thu, Mar 01, 2007 at 04:16:13PM +0900, Fernando Luis Vázquez Cao wrote:
With the advent of kdump, the assumption that the boot CPU when running
an UP kernel is always the CPU with a hardware ID of 0 (usually referred
to as BSP on some architectures) does not hold true anymore. The reason
from certain hardware errors.
>
> Signed-off-by: John Keller <[EMAIL PROTECTED]>
I made a similar change when porting to xen, but I hadn't thought
to see if mainline linux needs it to.
Acked-by: Simon Horman <[EMAIL PROTECTED]>
--
Horms
H: http://www.vergenet.net/~horms/
errors.
Signed-off-by: John Keller [EMAIL PROTECTED]
I made a similar change when porting to xen, but I hadn't thought
to see if mainline linux needs it to.
Acked-by: Simon Horman [EMAIL PROTECTED]
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe
On Fri, Jan 19, 2007 at 12:12:28PM -0500, Benjamin Romer wrote:
> On the Unisys ES7000/ONE system, we encountered a problem where performing
> a kexec reboot or dump on any cell other than cell 0 causes the system
> timer to stop working, resulting in a hang during timer calibration in the
> new
On Fri, Jan 19, 2007 at 12:12:28PM -0500, Benjamin Romer wrote:
On the Unisys ES7000/ONE system, we encountered a problem where performing
a kexec reboot or dump on any cell other than cell 0 causes the system
timer to stop working, resulting in a hang during timer calibration in the
new
On Wed, Dec 13, 2006 at 10:35:08AM +0900, Horms wrote:
> On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote:
> > > >Is there a kexec-tools patch too? How does second kernel know about
> > > >the location of the first kernel's initrd to be reused?
> >
On Wed, Dec 13, 2006 at 10:35:08AM +0900, Horms wrote:
On Fri, Dec 08, 2006 at 10:32:15AM +1100, Michael Neuling wrote:
Is there a kexec-tools patch too? How does second kernel know about
the location of the first kernel's initrd to be reused?
kexec-tools has to be modified
more comfortable with the stub
approach, I have no objections.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
n is to fix the ipvs side, is the fix
just to remove the call to cancel_rearming_delayed_work() in
ip_vs_control_cleanup() ?
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
defense_work_handler() is still running/preempted.
Unless I missed something, which side should be fixed?
Assuming the decision is to fix the ipvs side, is the fix
just to remove the call to cancel_rearming_delayed_work() in
ip_vs_control_cleanup() ?
--
Horms
H: http://www.vergenet.net/~horms
inside kexec.h
for the #ifndef CONFIG_KEXEC case?
Good catch :)
I think that #define in the process.c vs an empty stub inside
asm/kexec.h is really a style issue. I'm quite ok with things
the way they are. But If you are more comfortable with the stub
approach, I have no objections.
--
Horms
gt; +* Boot parameter "1" boots the dump-capture kernel into single-user mode
> > + without networking. If you want networking, use "3".
>
> i'm not sure you want to totally remove those first two lines, they
> appear to talk about getting to run level 1 *from a run
t into run level 1, so
> that minimum scripts run in user space and probability of capturing the
> dump increases.
>
> Fedora doc does say that appending "1" on command line will boot it
> into runlevel 1. I hope same is true for other distributions too.
>
> Thanks
&
* Make use of spaces and tabs consistent
* Make long line < 80col
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/include/asm-ia64/sal.h
===
--- linux-2.6.orig/include/asm-ia64/sal.h 2007-02-07
kexec.h is needed by arch/ia64/kernel/process.c so for the
declaration of kexec_disable_iosapic() which is used in machine_shutdown().
Signed-off-by: Simon Horman <[EMAIL PROTECTED]>
Index: linux-2.6/arch/ia64/kernel/process.c
===
that appending 1 on command line will boot it
into runlevel 1. I hope same is true for other distributions too.
Thanks
Vivek
This seems fine to me. Lets see if we can get it included.
--
Simon Horman (Horms)
[EMAIL PROTECTED]
http://verge.net.au/~horms/
kexec: fix references to init
that it is refering to a kernel command line parameter,
not a shell command executed on a running system, so I think the patch
is correct in that respect.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line unsubscribe linux
* Make use of spaces and tabs consistent
* Make long line 80col
Signed-off-by: Simon Horman [EMAIL PROTECTED]
Index: linux-2.6/include/asm-ia64/sal.h
===
--- linux-2.6.orig/include/asm-ia64/sal.h 2007-02-07 11:53:12.0
kexec.h is needed by arch/ia64/kernel/process.c so for the
declaration of kexec_disable_iosapic() which is used in machine_shutdown().
Signed-off-by: Simon Horman [EMAIL PROTECTED]
Index: linux-2.6/arch/ia64/kernel/process.c
===
---
it may be better to fail miserably during the build than
> fail silently in the case of CONFIG_SMP=y but CONFIG_HOTPLUG_CPU=n.
There used to be alternate code for the CONFIG_SMP +
!CONFIG_HOTPLUG_CPU, but this was removed because it was determined to
be flakey and not maintainable (I can dig up t
this is expressable in Kconfig
somehow.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
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
al doesn't return.
> >
> > So do I. The main problem with the compilation seems to be that
> > ia64_jump_to_sal() only exists if CONFIG_HOTPLUG_CPU=y.
> > (include/asm-ia64/sal.h, arch/ia64/kernel/head.S)
> >
> This may cause problem on SN platform.
> I rememb
rendez loop to do IRQ redirection.
However this needs SGI people to confirm...
Does this mean that CONFIG_HOTPLUG_CPU may be required for kdump
on the SN platform?
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line
Hi,
this patch fills in the portions for ia64 kexec.
I'm actually not sure what options are required for the dump-capture
kernel, but "init 1 irqpoll maxcpus=1" has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.
This patch requires the documentation
On Fri, Jan 12, 2007 at 11:46:39AM -0800, Jay Lan wrote:
> Horms wrote:
> > Hi,
> >
> > this patch fills in the portions for ia64 kexec.
> >
> > I'm actually not sure what options are required for the dump-capture
> > kernel, but "init 1 irq
Hi,
this patch fills in the portions for ia64 kexec.
I'm actually not sure what options are required for the dump-capture
kernel, but "init 1 irqpoll maxcpus=1" has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.
This patch requires the documentation
Hi,
this patch fills in the portions for ia64 kexec.
I'm actually not sure what options are required for the dump-capture
kernel, but init 1 irqpoll maxcpus=1 has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.
This patch requires the documentation
Hi,
this patch fills in the portions for ia64 kexec.
I'm actually not sure what options are required for the dump-capture
kernel, but init 1 irqpoll maxcpus=1 has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.
This patch requires the documentation
On Fri, Jan 12, 2007 at 11:46:39AM -0800, Jay Lan wrote:
Horms wrote:
Hi,
this patch fills in the portions for ia64 kexec.
I'm actually not sure what options are required for the dump-capture
kernel, but init 1 irqpoll maxcpus=1 has been working fine for me.
Or more to the point
Hi,
this patch fills in the portions for ia64 kexec.
I'm actually not sure what options are required for the dump-capture
kernel, but "init 1 irqpoll maxcpus=1" has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.
This patch requires the documentation
12
14:37:18.0 +0900
+++ linux-2.6/Documentation/kdump/kdump.txt 2007-01-12 14:56:42.0
+0900
@@ -61,7 +61,12 @@
2) Download the kexec-tools user-space package from the following URL:
-http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing-20
n as the root user.
>
> 2) Download the kexec-tools user-space package from the following URL:
>
> - http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz
> +http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing-20061214.tar
as the root user.
2) Download the kexec-tools user-space package from the following URL:
- http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz
+http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing-20061214.tar.gz
-3) Unpack
Hi,
this patch fills in the portions for ia64 kexec.
I'm actually not sure what options are required for the dump-capture
kernel, but init 1 irqpoll maxcpus=1 has been working fine for me.
Or more to the point, I'm not sure if irqpoll is needed or not.
This patch requires the documentation
:37:18.0 +0900
+++ linux-2.6/Documentation/kdump/kdump.txt 2007-01-12 14:56:42.0
+0900
@@ -61,7 +61,12 @@
2) Download the kexec-tools user-space package from the following URL:
-http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing-20061214
common interface, maybe we should support it by ignore this
> arg like ppc does.
That sounds reasonable to me. Vivek, what do you think?
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscribe from this list: send the line "unsubscribe linux
On Tue, Jan 09, 2007 at 08:17:08PM +0530, Vivek Goyal wrote:
> On Tue, Jan 09, 2007 at 10:18:47AM +0900, Horms wrote:
> > > Download and build the system and dump-capture kernels
> > > --
> > > +There are two p
On Tue, Jan 09, 2007 at 08:17:08PM +0530, Vivek Goyal wrote:
On Tue, Jan 09, 2007 at 10:18:47AM +0900, Horms wrote:
Download and build the system and dump-capture kernels
--
+There are two possible methods of using Kdump.
+
+ 1
you think?
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
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
t; 1) Login as the root user.
>
> 2) Download the kexec-tools user-space package from the following URL:
>
> - http://www.xmission.com/~ebiederm/files/kexec/kexec-tools-1.101.tar.gz
> +http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing-20061214.t
/files/kexec/kexec-tools-1.101.tar.gz
+http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/kexec-tools-testing-20061214.tar.gz
-3) Unpack the tarball with the tar command, as follows:
-
- tar xvpzf kexec-tools-1.101.tar.gz
-
-4) Download the latest consolidated Kdump patch from
On Wed, Dec 27, 2006 at 08:27:02AM +, Al Viro wrote:
> On Wed, Dec 27, 2006 at 05:17:02PM +0900, Horms wrote:
> > It seems that linux/preempt.h needs to include linux/thread_info.h
> > in order to access current_thread_info(), which is used in
> > preempt_count().
>
It seems that linux/preempt.h needs to include linux/thread_info.h
in order to access current_thread_info(), which is used in
preempt_count().
I guess that all callers of preempt_count() must include
both linux/thread_info.h and linux/preempt.h directly or indirectly,
as this does not cause a
It seems that linux/preempt.h needs to include linux/thread_info.h
in order to access current_thread_info(), which is used in
preempt_count().
I guess that all callers of preempt_count() must include
both linux/thread_info.h and linux/preempt.h directly or indirectly,
as this does not cause a
On Wed, Dec 27, 2006 at 08:27:02AM +, Al Viro wrote:
On Wed, Dec 27, 2006 at 05:17:02PM +0900, Horms wrote:
It seems that linux/preempt.h needs to include linux/thread_info.h
in order to access current_thread_info(), which is used in
preempt_count().
I guess that all callers
d then move it out to generic code later. That said, if
you're feeling particularly entergetic, feel free to do the generic
stuff now and just add null stubs for the other architectures (does
that makes sense?).
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
To unsubscr
null stubs for the other architectures (does
that makes sense?).
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
-
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
On Thu, Sep 08, 2005 at 12:49:17PM -0400, Brian Gerst wrote:
> Horms wrote:
> >Hi Andy,
> >
> >that does indeed seem to be a problem. I have narrowed it down to
> >a combination of using K6 and CONFIG_REGPARM. Hunting around a bit
> >I found this http://my.execp
atile__("rep; outs" #bwl : "+S"(addr), "+c"(count) :
"d"(port)); \
} \
static inline void ins##bwl(int port, void *addr, unsigned long count) { \
__asm__ __volatile__("rep; ins" #bwl : "+D"(addr), "+c"(count) :
"d&qu
) { \
__asm__ __volatile__(rep; ins #bwl : +D(addr), +c(count) :
d(port)); \
}
--
Horms
On Sat, Sep 03, 2005 at 10:49:48AM -0700, [EMAIL PROTECTED] wrote:
Package: linux-source-2.6.12
Version: 2.6.12-5
Severity: normal
# make-kpkg --initrd --append-to-version=-ahrairah --revision=ahrairah.1
On Thu, Sep 08, 2005 at 12:49:17PM -0400, Brian Gerst wrote:
Horms wrote:
Hi Andy,
that does indeed seem to be a problem. I have narrowed it down to
a combination of using K6 and CONFIG_REGPARM. Hunting around a bit
I found this http://my.execpc.com/~geezer/osd/gotchas/, which
suggests
On Mon, Sep 05, 2005 at 02:42:43PM +0200, Bartlomiej Zolnierkiewicz wrote:
> Should be fixed in 2.6.13.
>
> On 8/16/05, Kyle Moffett <[EMAIL PROTECTED]> wrote:
> > On Aug 13, 2005, at 18:54:30, LT-P wrote:
> > > Le lun 08 aoû 2005 17:57:04 CEST, Horms <[EMAIL PR
On Mon, Sep 05, 2005 at 02:42:43PM +0200, Bartlomiej Zolnierkiewicz wrote:
Should be fixed in 2.6.13.
On 8/16/05, Kyle Moffett [EMAIL PROTECTED] wrote:
On Aug 13, 2005, at 18:54:30, LT-P wrote:
Le lun 08 aoû 2005 17:57:04 CEST, Horms [EMAIL PROTECTED] a écrit:
Can you please enable
over - its bogus but harmless.
Signed-off-by: Horms <[EMAIL PROTECTED]>
--- a/fs/isofs/inode.c 2005-08-03 14:46:33.0 +0900
+++ b/fs/isofs/inode.c 2005-08-16 17:23:04.0 +0900
@@ -340,13 +337,13 @@
else if (!strcmp(value,"acorn&q
;
} else
#endif
On inspection it turns out that because of use of strtok(),
*value is already NULL terminated, and thus the code snippet
above is largely bogus. The following patch should remove the
bogus code without changing functionality.
Signed-off-by: Horms <[EMAIL PROTECTED]&
over - its bogus but harmless.
Signed-off-by: Horms [EMAIL PROTECTED]
--- a/fs/isofs/inode.c 2005-08-03 14:46:33.0 +0900
+++ b/fs/isofs/inode.c 2005-08-16 17:23:04.0 +0900
@@ -340,13 +337,13 @@
else if (!strcmp(value,acorn)) popt-map
it turns out that because of use of strtok(),
*value is already NULL terminated, and thus the code snippet
above is largely bogus. The following patch should remove the
bogus code without changing functionality.
Signed-off-by: Horms [EMAIL PROTECTED]
--- ../build-386/fs/isofs/inode.c 2005
On Mon, Aug 15, 2005 at 10:11:21PM -0300, Marcelo Tosatti wrote:
>
> Hi folks,
>
> On Fri, Aug 12, 2005 at 05:29:36PM +0900, Horms wrote:
> > On Fri, Aug 12, 2005 at 10:44:17AM +0300, Alexander Pytlev wrote:
> > > Hello Debian,
> > >
> > > Kernel 2.4
On Mon, Aug 15, 2005 at 10:11:21PM -0300, Marcelo Tosatti wrote:
Hi folks,
On Fri, Aug 12, 2005 at 05:29:36PM +0900, Horms wrote:
On Fri, Aug 12, 2005 at 10:44:17AM +0300, Alexander Pytlev wrote:
Hello Debian,
Kernel 2.4.27-10
With mount isofs filesystem, any mount parameters
On Fri, Aug 12, 2005 at 05:29:36PM +0900, Horms wrote:
> On Fri, Aug 12, 2005 at 10:44:17AM +0300, Alexander Pytlev wrote:
> > Hello Debian,
> >
> > Kernel 2.4.27-10
> > With mount isofs filesystem, any mount parameters after
> > iocharset=,map=,sess
te.
I have also CCed Marcelo and the LKML for their consideration,
as this problem still seems to be present in the lastest 2.4 tree.
--
Horms
simply patch:
===
--- kernel-source-2.4.27/fs/isofs/inode.c 2005-
for their consideration,
as this problem still seems to be present in the lastest 2.4 tree.
--
Horms
simply patch:
===
--- kernel-source-2.4.27/fs/isofs/inode.c 2005-05-19 13:29:39.0
+0300
+++ kernel-source/fs/isofs
On Fri, Aug 12, 2005 at 05:29:36PM +0900, Horms wrote:
On Fri, Aug 12, 2005 at 10:44:17AM +0300, Alexander Pytlev wrote:
Hello Debian,
Kernel 2.4.27-10
With mount isofs filesystem, any mount parameters after
iocharset=,map=,session= are ignored.
Sample:
mount -t isofs -o uid
at resolves your
problem. If it does, then the following patch should fix Kconfig
so that BLK_DEV_IDEDMA_PCI needs to be enabled for BLK_DEV_IDE_PMAC
to be enabled. It should patch cleanly against Debian's 2.6.8 and
Linus' current Git tree.
--
Horms
BLK_DEV_IDEDMA_PCI seems to be needed for BLK_DE
to be enabled. It should patch cleanly against Debian's 2.6.8 and
Linus' current Git tree.
--
Horms
BLK_DEV_IDEDMA_PCI seems to be needed for BLK_DEV_IDE_PMAC to compile
Signed-off-by: Horms [EMAIL PROTECTED]
--- a/drivers/ide/Kconfig.orig 2005-08-08 17:48:17.0 +0900
+++ b/drivers/ide
h device (e.g., media were just removed) */
> if (!get_capacity(disk))
> --- fs/devfs/base.c.orig 2005-07-29 00:32:03.329992027 +0200
> +++ fs/devfs/base.c 2005-07-29 00:32:52.08934 +0200
> @@ -1644,7 +1644,7 @@
> va_start(args, fmt);
> n = vsnpri
On Tue, Aug 02, 2005 at 08:41:27AM -0400, Michael Krufky wrote:
> Horms wrote:
>
> >Hi Marcelo,
> >
> >Another fix from 2.6.12.3 that seems approprite for 2.4.
> >Should apply cleanly to your tree.
> >
> >
> Horms-
>
> Thank you for the
On Tue, Aug 02, 2005 at 08:41:27AM -0400, Michael Krufky wrote:
Horms wrote:
Hi Marcelo,
Another fix from 2.6.12.3 that seems approprite for 2.4.
Should apply cleanly to your tree.
Horms-
Thank you for the effort of trying to get this into 2.4, but I don't
think there is any
., __FUNCTION__);
+ printk(KERN_WARNING %s: invalid argument.\n, __FUNCTION__);
return -EINVAL;
}
--
Horms
-
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
On Tue, Aug 02, 2005 at 04:20:00PM +0900, Horms wrote:
> Hi Marcelo,
>
> Another fix from 2.6.12.3 that seems approprite for 2.4.
> Should apply cleanly to your tree.
Please ignore this. I sent the wrong patch.
I don't think thie cx88 driver is in 2.4 at all.
> Signed-off-by
Hi Marcelo,
is this appropriate for 2.4? It seems to apply cleanly to
your current git tree.
Signed-off-by: Horms <[EMAIL PROTECTED]>
From: john stultz <[EMAIL PROTECTED]>
Date: Fri, 1 Jul 2005 05:08:54 + (+1000)
Subject: [PATCH] ppc32: stop misusing ntps time_offset val
Hi Marcelo,
Another fix from 2.6.12.3 that seems approprite for 2.4.
Should apply cleanly to your tree.
Signed-off-by: Horms <[EMAIL PROTECTED]>
From: Michael Krufky <[EMAIL PROTECTED]>
Date: Thu, 30 Jun 2005 20:06:41 + (-0400)
Subject: [PATCH] v4l cx88 hue offset fix
X-Git-Ta
Hi Marcelo,
Another fix from 2.6.12.3 that seems approprite for 2.4.
Should apply cleanly to your tree.
Signed-off-by: Horms [EMAIL PROTECTED]
From: Michael Krufky [EMAIL PROTECTED]
Date: Thu, 30 Jun 2005 20:06:41 + (-0400)
Subject: [PATCH] v4l cx88 hue offset fix
X-Git-Tag: v2.6.12.3
X
Hi Marcelo,
is this appropriate for 2.4? It seems to apply cleanly to
your current git tree.
Signed-off-by: Horms [EMAIL PROTECTED]
From: john stultz [EMAIL PROTECTED]
Date: Fri, 1 Jul 2005 05:08:54 + (+1000)
Subject: [PATCH] ppc32: stop misusing ntps time_offset value
X-Git-Tag: v2.6.12.3
On Tue, Aug 02, 2005 at 04:20:00PM +0900, Horms wrote:
Hi Marcelo,
Another fix from 2.6.12.3 that seems approprite for 2.4.
Should apply cleanly to your tree.
Please ignore this. I sent the wrong patch.
I don't think thie cx88 driver is in 2.4 at all.
Signed-off-by: Horms [EMAIL PROTECTED
On Tue, Apr 12, 2005 at 12:14:56PM -0700, George Anzinger wrote:
> Horms wrote:
> >
> >Use netdev as the mailing list contact instead of the mostly dead
> >linux-net list.
> >
> ~
> > PHRAM MTD DRIVER
> >@@ -1795,7 +1795,7 @@
> > POSIX CLOCKS a
: Andrew Morton
> > M: [EMAIL PROTECTED]
> > P: Jeff Garzik
> > M: [EMAIL PROTECTED]
> > L: linux-net@vger.kernel.org
> > S: Maintained
>
> Maybe one of the two maintainers might want to change that? ;)
Use netdev as the mailing
1 - 100 of 110 matches
Mail list logo
