Wilkerson, Bryan P wrote:
Is there an equivalent kernel boot option for kgdbwait in
2.6.13-rc4-mm1? I grep'd the kernel source but didn't find kgdbwait.
Is there any documentation other than the source for the flavor of KGDB
that is included in the akpm kernel patch?
The patch has some
On Wed, Aug 24, 2005 at 09:22:06AM -0700, Wilkerson, Bryan P wrote:
> Is there an equivalent kernel boot option for kgdbwait in
> 2.6.13-rc4-mm1? I grep'd the kernel source but didn't find kgdbwait.
It's 'kgdb' or 'gdb', I forget which.
--
Tom Rini
http://gate.crashing.org/
Is there an equivalent kernel boot option for kgdbwait in
2.6.13-rc4-mm1? I grep'd the kernel source but didn't find kgdbwait.
Is there any documentation other than the source for the flavor of KGDB
that is included in the akpm kernel patch?
Thanks,
-bryan
-
To unsubscribe from this list
Is there an equivalent kernel boot option for kgdbwait in
2.6.13-rc4-mm1? I grep'd the kernel source but didn't find kgdbwait.
Is there any documentation other than the source for the flavor of KGDB
that is included in the akpm kernel patch?
Thanks,
-bryan
-
To unsubscribe from this list
On Wed, Aug 24, 2005 at 09:22:06AM -0700, Wilkerson, Bryan P wrote:
Is there an equivalent kernel boot option for kgdbwait in
2.6.13-rc4-mm1? I grep'd the kernel source but didn't find kgdbwait.
It's 'kgdb' or 'gdb', I forget which.
--
Tom Rini
http://gate.crashing.org/~trini
Wilkerson, Bryan P wrote:
Is there an equivalent kernel boot option for kgdbwait in
2.6.13-rc4-mm1? I grep'd the kernel source but didn't find kgdbwait.
Is there any documentation other than the source for the flavor of KGDB
that is included in the akpm kernel patch?
The patch has some
On Fri, 2005-08-12 at 01:27 +1000, Con Kolivas wrote:
> On Fri, 12 Aug 2005 01:21 am, Dave Kleikamp wrote:
> > Should there be any locking around this? Or should the value of
> > rq->nr_running be saved to a local variable as in this untested patch?
>
> Very sneaky..
>
> On initial inspection
On Fri, 12 Aug 2005 01:21 am, Dave Kleikamp wrote:
> I encounted this trap on a 2-way i386 box running 2.6.13-rc4-mm1:
>
> [70347.743727] divide error: [#2]
> [70347.752979] PREEMPT SMP DEBUG_PAGEALLOC
> [70347.773060] last sysfs file: /devices/pnp0/00:11/id
>
> Pr
I encounted this trap on a 2-way i386 box running 2.6.13-rc4-mm1:
[70347.743727] divide error: [#2]
[70347.752979] PREEMPT SMP DEBUG_PAGEALLOC
[70347.773060] last sysfs file: /devices/pnp0/00:11/id
Program received signal SIGTRAP, Trace/breakpoint trap.
0xc0119556 in find_idlest_group (sd
I encounted this trap on a 2-way i386 box running 2.6.13-rc4-mm1:
[70347.743727] divide error: [#2]
[70347.752979] PREEMPT SMP DEBUG_PAGEALLOC
[70347.773060] last sysfs file: /devices/pnp0/00:11/id
Program received signal SIGTRAP, Trace/breakpoint trap.
0xc0119556 in find_idlest_group (sd
On Fri, 12 Aug 2005 01:21 am, Dave Kleikamp wrote:
I encounted this trap on a 2-way i386 box running 2.6.13-rc4-mm1:
[70347.743727] divide error: [#2]
[70347.752979] PREEMPT SMP DEBUG_PAGEALLOC
[70347.773060] last sysfs file: /devices/pnp0/00:11/id
Program received signal SIGTRAP
On Fri, 2005-08-12 at 01:27 +1000, Con Kolivas wrote:
On Fri, 12 Aug 2005 01:21 am, Dave Kleikamp wrote:
Should there be any locking around this? Or should the value of
rq-nr_running be saved to a local variable as in this untested patch?
Very sneaky..
On initial inspection your patch
On 07/08/05, Patrick McHardy <[EMAIL PROTECTED]> wrote:
> Could be related to the refcnt underflow with conntrack event
> notifications enabled. If you have CONFIG_IP_NF_CONNTRACK_EVENTS
> enabled please try this patch.
>
I can confirm that that patch solved my problems, thank you :)
--
Mvh /
g a clean x86_64 environment.
>>uname -a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44
>>CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD
>>...
Could be related to the refcnt underflow with conntrack event
notifications enabled. If you have CONF
t; > The machine is an amd64, running a clean x86_64 environment.
> > uname -a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44
> > CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD
> >...
>
> Is this reproducible or did it happen only once?
It is
a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44
> CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD
>...
Is this reproducible or did it happen only once?
Are there any messages that might give a hint where to search for the
problem?
You are reporting
After execing "iptables -A INPUT -j DROP" my computer crashes hard. It
dosent hang immediately, but after a couple of seconds.
The machine is an amd64, running a clean x86_64 environment.
uname -a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44
CEST 2005 x86_64 AMD Ath
After execing iptables -A INPUT -j DROP my computer crashes hard. It
dosent hang immediately, but after a couple of seconds.
The machine is an amd64, running a clean x86_64 environment.
uname -a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44
CEST 2005 x86_64 AMD Athlon(tm) 64 Processor
On Sun, Aug 07, 2005 at 07:12:00PM +0200, Espen Fjellvær Olsen wrote:
After execing iptables -A INPUT -j DROP my computer crashes hard. It
dosent hang immediately, but after a couple of seconds.
The machine is an amd64, running a clean x86_64 environment.
uname -a: Linux gentoo 2.6.13-rc4-mm1
x86_64 environment.
uname -a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44
CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD
...
Is this reproducible or did it happen only once?
It is reproducible, happens each time when running iptables -A INPUT
-j DROP, other rules
gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44
CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD
...
Could be related to the refcnt underflow with conntrack event
notifications enabled. If you have CONFIG_IP_NF_CONNTRACK_EVENTS
enabled please try this patch.
[NETFILTER]: Fix
On 07/08/05, Patrick McHardy [EMAIL PROTECTED] wrote:
Could be related to the refcnt underflow with conntrack event
notifications enabled. If you have CONFIG_IP_NF_CONNTRACK_EVENTS
enabled please try this patch.
I can confirm that that patch solved my problems, thank you :)
--
Mvh / Best
gument. Then show_map calls
show_map_internal with NULL as struct mem_size_stats* whereas show_smap calls
it with a real pointer. Now the final
if (m->count < m->size) /* vma is copied successfully */
m->version = (vma != get_gate_vma(task))? vma->vm_start: 0;
Hi,
when trying out smaps I have encountered the following problem:
> cat /proc/$P/smaps | diff - /proc/$P/smaps
239,241c239,241
< bfbaf000-bfbc4000 rw-p bfbaf000 00:00 0 [stack]
< Size:84 kB
< Rss: 24 kB
---
> b7fc4000-b7fc6000 rwxp 00015000 08:02 12558
Hi,
when trying out smaps I have encountered the following problem:
cat /proc/$P/smaps | diff - /proc/$P/smaps
239,241c239,241
bfbaf000-bfbc4000 rw-p bfbaf000 00:00 0 [stack]
Size:84 kB
Rss: 24 kB
---
b7fc4000-b7fc6000 rwxp 00015000 08:02 12558
it with a real pointer. Now the final
if (m-count m-size) /* vma is copied successfully */
m-version = (vma != get_gate_vma(task))? vma-vm_start: 0;
is done only if the whole entry fits into the buffer.
Torsten
--- linux-2.6.13-rc4-mm1/fs/proc/task_mmu.c~ 2005-08-03 12:48
> Date: Sun, 31 Jul 2005 19:02:09 -0700
> From: [EMAIL PROTECTED]
>
> > Date: Sun, 31 Jul 2005 16:02:44 -0700
> > From: Greg KH <[EMAIL PROTECTED]>
> >
> > On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
> > > I think that "continuing" codepath came from someone at Phoenix,
Date: Sun, 31 Jul 2005 19:02:09 -0700
From: [EMAIL PROTECTED]
Date: Sun, 31 Jul 2005 16:02:44 -0700
From: Greg KH [EMAIL PROTECTED]
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
I think that continuing codepath came from someone at Phoenix, FWIW;
the problem
Jiri Slaby napsal(a):
Alan Cox napsal(a):
drivers/char/drm/gamma_dma.c
drivers/char/drm/gamma_drv.c
Gamma is defunct certainly
Removes gamma sources, headers and pointers from Kconfig and Makefile.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
patch is here (about 70 KiB):
Jiri Slaby napsal(a):
Alan Cox napsal(a):
drivers/char/drm/gamma_dma.c
drivers/char/drm/gamma_drv.c
Gamma is defunct certainly
Removes gamma sources, headers and pointers from Kconfig and Makefile.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
patch is here (about 70 KiB):
Alan Cox napsal(a):
drivers/char/drm/gamma_dma.c
drivers/char/drm/gamma_drv.c
Gamma is defunct certainly
Removes gamma sources, headers and pointers from Kconfig and Makefile.
Signed-off-by: Jiri Slaby <[EMAIL PROTECTED]>
patch is here (about 70 KiB):
The following patch is needed for mips to compile with
the spinlock consolidation patch (the include of asm-mips/atomic.h
is moved down to avoid circular dependencies).
Signed-off-by: Benoit Boissinot <[EMAIL PROTECTED]>
--- linux/include/linux/spinlock.h.orig 2005-08-03 20:49:26.0
The following patch is needed for mips to compile with
the spinlock consolidation patch (the include of asm-mips/atomic.h
is moved down to avoid circular dependencies).
Signed-off-by: Benoit Boissinot [EMAIL PROTECTED]
--- linux/include/linux/spinlock.h.orig 2005-08-03 20:49:26.0 +0200
Alan Cox napsal(a):
drivers/char/drm/gamma_dma.c
drivers/char/drm/gamma_drv.c
Gamma is defunct certainly
Removes gamma sources, headers and pointers from Kconfig and Makefile.
Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
patch is here (about 70 KiB):
Hi,
My Athlon64-based notebook (64-bit environment) has just hanged solid under
load on 2.6.13-rc4-mm1. The same happend (on 2.6.13-rc4-mm1) some time ago
to a dual-Opteron box I have access to.
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends
Hi,
My Athlon64-based notebook (64-bit environment) has just hanged solid under
load on 2.6.13-rc4-mm1. The same happend (on 2.6.13-rc4-mm1) some time ago
to a dual-Opteron box I have access to.
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends
Grant Coady <[EMAIL PROTECTED]> wrote:
>
> Greetings,
>
> Automating random config kernel build testing, for 2.6.13-rc4-mm1:
>
> Done processing 752 random builds, from which:
> ### 8 .configs produced errors
> ### 11 .configs produced undefs
> #
Greetings,
Automating random config kernel build testing, for 2.6.13-rc4-mm1:
Done processing 752 random builds, from which:
### 8 .configs produced errors
### 11 .configs produced undefs
### 52 .configs produced warnings
Abbreviated errors (first 2 lines/error):
[EMAIL PROTECTED]:/opt
Hi Andrew,
I noticed a strange return value in smsc_ircc_init in
drivers/net/irda/smsc_ircc2.c in rc4-mm1.
When reaching the line "if (ircc_fir > 0 && ircc_sir > 0)", ret is 0.
So I don't see the point of setting it to 0 in the "else" case.
>From what I see in 2.6.12 it should probably be set to
> >> On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
> >> > I think that "continuing" codepath came from someone at
> >> > Phoenix, FWIW;
>
> That was me.
Thanks. It's good to have BIOS experts involved too. :)
> >> > the problem is that I see the PCI quirks code has
MAIL PROTECTED]
>Subject: Re: [linux-usb-devel] Re: 2.6.13-rc4-mm1
>
>> Date: Sun, 31 Jul 2005 16:02:44 -0700
>> From: Greg KH <[EMAIL PROTECTED]>
>>
>> On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
>> > I think that &qu
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Michael Thonke
>Sent: Sunday, July 31, 2005 8:12 AM
>To: Andrew Morton
>Cc: linux-kernel@vger.kernel.org
>Subject: Re: 2.6.13-rc4-mm1
>
>Hello Andrew,
>
>the ACPI bug o
From: Alexandre Buisse <[EMAIL PROTECTED]>
Date: Mon, 01 Aug 2005 07:52:29 +0200
> I have this when I enable nfnetlink as a module :
>
> net/built-in.o: In function `ip_ct_port_tuple_to_nfattr':
> : undefined reference to `__nfa_fill'
This got fixed in -mm2 and later methinks.
-
To unsubscribe
Hi Andrew,
I have this when I enable nfnetlink as a module :
net/built-in.o: In function `ip_ct_port_tuple_to_nfattr':
: undefined reference to `__nfa_fill'
net/built-in.o: In function `ip_ct_port_tuple_to_nfattr':
: undefined reference to `__nfa_fill'
net/built-in.o: In function
Hi Andrew,
I have this when I enable nfnetlink as a module :
net/built-in.o: In function `ip_ct_port_tuple_to_nfattr':
: undefined reference to `__nfa_fill'
net/built-in.o: In function `ip_ct_port_tuple_to_nfattr':
: undefined reference to `__nfa_fill'
net/built-in.o: In function
From: Alexandre Buisse [EMAIL PROTECTED]
Date: Mon, 01 Aug 2005 07:52:29 +0200
I have this when I enable nfnetlink as a module :
net/built-in.o: In function `ip_ct_port_tuple_to_nfattr':
: undefined reference to `__nfa_fill'
This got fixed in -mm2 and later methinks.
-
To unsubscribe from
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michael Thonke
Sent: Sunday, July 31, 2005 8:12 AM
To: Andrew Morton
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.13-rc4-mm1
Hello Andrew,
the ACPI bug or the problems with 2.6.13-rc3-mm[2,3] gone
-usb-devel] Re: 2.6.13-rc4-mm1
Date: Sun, 31 Jul 2005 16:02:44 -0700
From: Greg KH [EMAIL PROTECTED]
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
I think that continuing codepath came from someone at
Phoenix, FWIW;
That was me.
the problem is that I see the PCI
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
I think that continuing codepath came from someone at
Phoenix, FWIW;
That was me.
Thanks. It's good to have BIOS experts involved too. :)
the problem is that I see the PCI quirks code has evolved
even farther
Hi Andrew,
I noticed a strange return value in smsc_ircc_init in
drivers/net/irda/smsc_ircc2.c in rc4-mm1.
When reaching the line if (ircc_fir 0 ircc_sir 0), ret is 0.
So I don't see the point of setting it to 0 in the else case.
From what I see in 2.6.12 it should probably be set to -ENODEV
Greetings,
Automating random config kernel build testing, for 2.6.13-rc4-mm1:
Done processing 752 random builds, from which:
### 8 .configs produced errors
### 11 .configs produced undefs
### 52 .configs produced warnings
Abbreviated errors (first 2 lines/error):
[EMAIL PROTECTED]:/opt
Grant Coady [EMAIL PROTECTED] wrote:
Greetings,
Automating random config kernel build testing, for 2.6.13-rc4-mm1:
Done processing 752 random builds, from which:
### 8 .configs produced errors
### 11 .configs produced undefs
### 52 .configs produced warnings
Abbreviated errors
> Date: Sun, 31 Jul 2005 16:02:44 -0700
> From: Greg KH <[EMAIL PROTECTED]>
>
> On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
> > I think that "continuing" codepath came from someone at Phoenix, FWIW;
> > the problem is that I see the PCI quirks code has evolved even farther
>
Jesus Delgado <[EMAIL PROTECTED]> wrote:
>
> Im try test with kernels 2.6.13-rc4 and 2.6.13-rc4-mm1, the problems
> is the boot hang:
>my test is different combinations the acpi=off , noacpi, pci=noirq,
> etc.etc both have is the same error not boot.
>
> The
Hi all:
Im try test with kernels 2.6.13-rc4 and 2.6.13-rc4-mm1, the problems
is the boot hang:
my test is different combinations the acpi=off , noacpi, pci=noirq,
etc.etc both have is the same error not boot.
The only information is simple:
..
Uncompressiong Linux... Ok. booting
Hi all:
Im try test with kernels 2.6.13-rc4 and 2.6.13-rc4-mm1, the problems
is the boot hang:
my test is different combinations the acpi=off , noacpi, pci=noirq,
etc.etc both have is the same error not boot.
The only information is simple:
..
Uncompressiong Linux... Ok. booting
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
> I think that "continuing" codepath came from someone at Phoenix, FWIW;
> the problem is that I see the PCI quirks code has evolved even farther
> from the main copy of the init code in the USB tree. Sigh.
I don't like that
Andrew Morton wrote:
> Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
>
>>Andrew Morton wrote:
>> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
>>
>> Andrew,
>> the good news is I can access pcmcia devices w
> > If my Prolific USB-Serialadapter plugged in on reboot
> > the ehci_hcd driver complains about a Hand-off bug in Bios.
> >
> > -> snip
> >
> > ehci_hcd :00:1d.7: EHCI Host Controller
> > ehci_hcd :00:1d.7: debug port 1
> >
> > ehci_hcd :00:1d.7: BIOS handoff failed (104,
Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> >
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
>
> Andrew,
> the good news is I can access pcmcia devices with rc4-mm1 which I
> couldn't w
(cc linux-usb-devel)
Michael Thonke <[EMAIL PROTECTED]> wrote:
>
> Hello Andrew,
>
> the ACPI bug or the problems with 2.6.13-rc3-mm[2,3] gone.
> The system boots now noiseless, except on problem with USB.
>
> If my Prolific USB-Serialadapter plugged in on reboot
> the ehci_hcd driver
On Sun, 31 Jul 2005 02:05:52 -0700 Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
>
> - Dropped the connector patches: turns out that we no longer have a netlink
> slot available for them anyway.
I don't fe
> >Why was the KERNEL_VERSION(a,b,c) macro removed from
> >include/linux/version.h? The removal breaks external drivers like
> >NDISWRAPPER or nVidia propietary.
> >
> Hello Felipe,
>
> I could not regonize a breakage of NVidia (Version 1.0-7667) propietary
> drivers.
> They work just perfect.
Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
Andrew,
the good news is I can access pcmcia devices with rc4-mm1 which I
couldn't with at least rc3-mm1 on my x86_64 laptop. There is at least
one more problem with yenta_soc
Hello Andrew,
the ACPI bug or the problems with 2.6.13-rc3-mm[2,3] gone.
The system boots now noiseless, except on problem with USB.
If my Prolific USB-Serialadapter plugged in on reboot
the ehci_hcd driver complains about a Hand-off bug in Bios.
-> snip
ehci_hcd :00:1d.7: EHCI Host
On Sun, Jul 31, 2005 at 01:37:21PM +0100, James Courtier-Dutton wrote:
> Adrian Bunk wrote:
> >On Sun, Jul 31, 2005 at 12:04:59PM +0200, Felipe Alfaro Solana wrote:
> >
> >
> >>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13
Adrian Bunk wrote:
On Sun, Jul 31, 2005 at 12:04:59PM +0200, Felipe Alfaro Solana wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
Why was the KERNEL_VERSION(a,b,c) macro removed from
include/linux/version.h? The removal breaks external drivers
Felipe Alfaro Solana schrieb:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
Why was the KERNEL_VERSION(a,b,c) macro removed from
include/linux/version.h? The removal breaks external drivers like
NDISWRAPPER or nVidia propietary.
-
To unsubscribe
Hi,
On Sunday, 31 of July 2005 11:05, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
>
>
> - Dropped areca-raid-linux-scsi-driver.patch and iteraid.patch. People who
> need these can get them f
On Sun, Jul 31, 2005 at 12:04:59PM +0200, Felipe Alfaro Solana wrote:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
>
> Why was the KERNEL_VERSION(a,b,c) macro removed from
> include/linux/version.h? The removal breaks extern
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
Why was the KERNEL_VERSION(a,b,c) macro removed from
include/linux/version.h? The removal breaks external drivers like
NDISWRAPPER or nVidia propietary.
-
To unsubscribe from this list: send the l
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
- Dropped areca-raid-linux-scsi-driver.patch and iteraid.patch. People who
need these can get them from 2.6.13-rc3-mm3.
- Dropped the CKRM patches. I don't think they were doing much in -mm and
we
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
- Dropped areca-raid-linux-scsi-driver.patch and iteraid.patch. People who
need these can get them from 2.6.13-rc3-mm3.
- Dropped the CKRM patches. I don't think they were doing much in -mm and
we
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
Why was the KERNEL_VERSION(a,b,c) macro removed from
include/linux/version.h? The removal breaks external drivers like
NDISWRAPPER or nVidia propietary.
-
To unsubscribe from this list: send the line
On Sun, Jul 31, 2005 at 12:04:59PM +0200, Felipe Alfaro Solana wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
Why was the KERNEL_VERSION(a,b,c) macro removed from
include/linux/version.h? The removal breaks external drivers like
It moved
Hi,
On Sunday, 31 of July 2005 11:05, Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
- Dropped areca-raid-linux-scsi-driver.patch and iteraid.patch. People who
need these can get them from 2.6.13-rc3-mm3.
- Dropped
Adrian Bunk wrote:
On Sun, Jul 31, 2005 at 12:04:59PM +0200, Felipe Alfaro Solana wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
Why was the KERNEL_VERSION(a,b,c) macro removed from
include/linux/version.h? The removal breaks external drivers
Felipe Alfaro Solana schrieb:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
Why was the KERNEL_VERSION(a,b,c) macro removed from
include/linux/version.h? The removal breaks external drivers like
NDISWRAPPER or nVidia propietary.
-
To unsubscribe
On Sun, Jul 31, 2005 at 01:37:21PM +0100, James Courtier-Dutton wrote:
Adrian Bunk wrote:
On Sun, Jul 31, 2005 at 12:04:59PM +0200, Felipe Alfaro Solana wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
Why was the KERNEL_VERSION(a,b,c) macro
Hello Andrew,
the ACPI bug or the problems with 2.6.13-rc3-mm[2,3] gone.
The system boots now noiseless, except on problem with USB.
If my Prolific USB-Serialadapter plugged in on reboot
the ehci_hcd driver complains about a Hand-off bug in Bios.
- snip
ehci_hcd :00:1d.7: EHCI Host
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
Andrew,
the good news is I can access pcmcia devices with rc4-mm1 which I
couldn't with at least rc3-mm1 on my x86_64 laptop. There is at least
one more problem with yenta_socket. Please
Why was the KERNEL_VERSION(a,b,c) macro removed from
include/linux/version.h? The removal breaks external drivers like
NDISWRAPPER or nVidia propietary.
Hello Felipe,
I could not regonize a breakage of NVidia (Version 1.0-7667) propietary
drivers.
They work just perfect.
Indeed they do
On Sun, 31 Jul 2005 02:05:52 -0700 Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
- Dropped the connector patches: turns out that we no longer have a netlink
slot available for them anyway.
I don't feel strongly pro or con
Andreas Steinmetz [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
Andrew,
the good news is I can access pcmcia devices with rc4-mm1 which I
couldn't with at least rc3-mm1 on my x86_64 laptop
(cc linux-usb-devel)
Michael Thonke [EMAIL PROTECTED] wrote:
Hello Andrew,
the ACPI bug or the problems with 2.6.13-rc3-mm[2,3] gone.
The system boots now noiseless, except on problem with USB.
If my Prolific USB-Serialadapter plugged in on reboot
the ehci_hcd driver complains about a
Andrew Morton wrote:
Andreas Steinmetz [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
Andrew,
the good news is I can access pcmcia devices with rc4-mm1 which I
couldn't with at least rc3-mm1 on my
If my Prolific USB-Serialadapter plugged in on reboot
the ehci_hcd driver complains about a Hand-off bug in Bios.
- snip
ehci_hcd :00:1d.7: EHCI Host Controller
ehci_hcd :00:1d.7: debug port 1
ehci_hcd :00:1d.7: BIOS handoff failed (104, 01010001)
ehci_hcd
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
I think that continuing codepath came from someone at Phoenix, FWIW;
the problem is that I see the PCI quirks code has evolved even farther
from the main copy of the init code in the USB tree. Sigh.
I don't like that either,
Hi all:
Im try test with kernels 2.6.13-rc4 and 2.6.13-rc4-mm1, the problems
is the boot hang:
my test is different combinations the acpi=off , noacpi, pci=noirq,
etc.etc both have is the same error not boot.
The only information is simple:
..
Uncompressiong Linux... Ok. booting
Hi all:
Im try test with kernels 2.6.13-rc4 and 2.6.13-rc4-mm1, the problems
is the boot hang:
my test is different combinations the acpi=off , noacpi, pci=noirq,
etc.etc both have is the same error not boot.
The only information is simple:
..
Uncompressiong Linux... Ok. booting
Jesus Delgado [EMAIL PROTECTED] wrote:
Im try test with kernels 2.6.13-rc4 and 2.6.13-rc4-mm1, the problems
is the boot hang:
my test is different combinations the acpi=off , noacpi, pci=noirq,
etc.etc both have is the same error not boot.
The only information is simple
Date: Sun, 31 Jul 2005 16:02:44 -0700
From: Greg KH [EMAIL PROTECTED]
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
I think that continuing codepath came from someone at Phoenix, FWIW;
the problem is that I see the PCI quirks code has evolved even farther
from the
92 matches
Mail list logo