Hello,
On Fri, Dec 29, 2006 at 04:01:32PM +0100, Ard -kwaak- van Breemen wrote:
> On Fri, Dec 29, 2006 at 03:10:58PM +0100, Ard -kwaak- van Breemen wrote:
> > Preliminary patches:
> > - pci fix of Andrews patches
> The printk might be too verbose. I think removing them is ok
I stick with the
On Fri, Dec 29, 2006 at 04:01:32PM +0100, Ard -kwaak- van Breemen wrote:
> > - parse-one detection of Yanmin
> It doesn't flag it. I am working on that.
As said: it was doing a callback to obsolete_...
This replaces the patch into not being bloated and still gives
enough info. It won't check voor
On Fri, Dec 22, 2006 at 03:35:20PM +0100, Ard -kwaak- van Breemen wrote:
> On Fri, Dec 22, 2006 at 12:30:29AM -0800, Andrew Morton wrote:
> > I expect that you'll find that the ide code ends up doing
> > down_write(pci_bus_sem), which will enable interrupts.
> will: down_read(_bus_sem);
>
On Fri, Dec 29, 2006 at 04:01:32PM +0100, Ard -kwaak- van Breemen wrote:
> > - parse-one detection of Yanmin
> It doesn't flag it. I am working on that.
Since it goes to a callback to obsolete_checksetup()
Argh... my calltree was a little flawed :-(...
--
program signature;
begin {
On Fri, Dec 29, 2006 at 03:10:58PM +0100, Ard -kwaak- van Breemen wrote:
> Preliminary patches:
> - pci fix of Andrews patches
The printk might be too verbose. I think removing them is ok
since the only thing that has happened is that it prevents
entering the loop and the semaphores. The only
On Fri, Dec 29, 2006 at 02:27:59PM +0100, Ard -kwaak- van Breemen wrote:
> I will clean up the patches found on this list to fix and detect this.
Preliminary patches:
- pci fix of Andrews patches
- parse-one detection of Yanmin
- start_kernel detection and workaround (disable them again)
These
On Fri, Dec 29, 2006 at 01:51:08PM +0100, Ard -kwaak- van Breemen wrote:
> I will try it on the right function, and see what we get.
In function: 186 static struct pci_dev * pci_find_subsys(unsigned
int vendor,
203if (unlikely(list_empty(_devices))) {
204 printk("Pci
Hello Andrew,
On Thu, Dec 28, 2006 at 03:51:48PM -0800, Andrew Morton wrote:
> Could someone please test this?
Without testing I declare it won't fix it 8-D
> Ard has worked out the call tree:
>
> init/main.c start_kernel
> kernel/params.c parse_args("Booting kernel"
>
Il giorno gio, 28/12/2006 alle 15.51 -0800, Andrew Morton ha scritto:
> Could someone please test this?
> diff -puN drivers/pci/search.c~pci-avoid-taking-pci_bus_sem-early-in-boot
> drivers/pci/search.c
> --- a/drivers/pci/search.c~pci-avoid-taking-pci_bus_sem-early-in-boot
> +++
Il giorno gio, 28/12/2006 alle 15.51 -0800, Andrew Morton ha scritto:
Could someone please test this?
diff -puN drivers/pci/search.c~pci-avoid-taking-pci_bus_sem-early-in-boot
drivers/pci/search.c
--- a/drivers/pci/search.c~pci-avoid-taking-pci_bus_sem-early-in-boot
+++
Hello Andrew,
On Thu, Dec 28, 2006 at 03:51:48PM -0800, Andrew Morton wrote:
Could someone please test this?
Without testing I declare it won't fix it 8-D
Ard has worked out the call tree:
init/main.c start_kernel
kernel/params.c parse_args(Booting kernel
kernel/params.c
On Fri, Dec 29, 2006 at 01:51:08PM +0100, Ard -kwaak- van Breemen wrote:
I will try it on the right function, and see what we get.
In function: 186 static struct pci_dev * pci_find_subsys(unsigned
int vendor,
203if (unlikely(list_empty(pci_devices))) {
204 printk(Pci
On Fri, Dec 29, 2006 at 02:27:59PM +0100, Ard -kwaak- van Breemen wrote:
I will clean up the patches found on this list to fix and detect this.
Preliminary patches:
- pci fix of Andrews patches
- parse-one detection of Yanmin
- start_kernel detection and workaround (disable them again)
These
On Fri, Dec 29, 2006 at 03:10:58PM +0100, Ard -kwaak- van Breemen wrote:
Preliminary patches:
- pci fix of Andrews patches
The printk might be too verbose. I think removing them is ok
since the only thing that has happened is that it prevents
entering the loop and the semaphores. The only thing
On Fri, Dec 29, 2006 at 04:01:32PM +0100, Ard -kwaak- van Breemen wrote:
- parse-one detection of Yanmin
It doesn't flag it. I am working on that.
Since it goes to a callback to obsolete_checksetup()
Argh... my calltree was a little flawed :-(...
--
program signature;
begin { telegraaf.com
}
On Fri, Dec 22, 2006 at 03:35:20PM +0100, Ard -kwaak- van Breemen wrote:
On Fri, Dec 22, 2006 at 12:30:29AM -0800, Andrew Morton wrote:
I expect that you'll find that the ide code ends up doing
down_write(pci_bus_sem), which will enable interrupts.
will: down_read(pci_bus_sem);
also
On Fri, Dec 29, 2006 at 04:01:32PM +0100, Ard -kwaak- van Breemen wrote:
- parse-one detection of Yanmin
It doesn't flag it. I am working on that.
As said: it was doing a callback to obsolete_...
This replaces the patch into not being bloated and still gives
enough info. It won't check voor
Hello,
On Fri, Dec 29, 2006 at 04:01:32PM +0100, Ard -kwaak- van Breemen wrote:
On Fri, Dec 29, 2006 at 03:10:58PM +0100, Ard -kwaak- van Breemen wrote:
Preliminary patches:
- pci fix of Andrews patches
The printk might be too verbose. I think removing them is ok
I stick with the verbose
Could someone please test this?
From: Andrew Morton <[EMAIL PROTECTED]>
Various people have reported machines failing to boot since pci_bus_sem was
switched from a spinlock to an rwsem.
The reason for this is that these people had "ide=" on the kernel commandline,
and ide_setup() can end up
Could someone please test this?
From: Andrew Morton [EMAIL PROTECTED]
Various people have reported machines failing to boot since pci_bus_sem was
switched from a spinlock to an rwsem.
The reason for this is that these people had ide= on the kernel commandline,
and ide_setup() can end up
> I am pretty sure the i386 tree has the same problem but I haven't checked yet.
> Anyway: the panic is just a way of noticing. The bug is that irq's are enabled
> before the irq controller is set up.
A very similar i386 linux installation works fine on my laptop, but that
i386 kernel never had
On Fri, 22 Dec 2006 15:16:55 +0100
Ard -kwaak- van Breemen <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 22, 2006 at 03:00:59PM +0100, Ard -kwaak- van Breemen wrote:
> > 262 if (!irqs_disabled()) printk(__FILE__ "%s(): blaat:
> > interrupts were enabled [EMAIL
Hello,
On Thu, Dec 21, 2006 at 04:04:04PM +0800, Zhang, Yanmin wrote:
> I couldn't reproduce it on my EM64T machine. I instrumented function
> start_kernel and
> didn't find irq was enabled before calling init_IRQ. It'll be better if the
> reporter could
> instrument function start_kernel to
On Fri, Dec 22, 2006 at 03:41:34PM +0100, Ard -kwaak- van Breemen wrote:
> Repeating: I am very stupid, so I don't know if saving the irq state is ok or
> not in down_read.
The Andrew Morton patch but the rewritten for down_read makes the
symptoms go away.
The problem obviously is that the
On Fri, Dec 22, 2006 at 12:30:29AM -0800, Andrew Morton wrote:
> To whom do I have to pay how much to get this darn patch tested?
I've altered your patch to do the spin_lock_irqsave in down_read.
I am very ignorant and stupid. That's why I am doing it without
thinking why or why not de irqsave is
On Fri, Dec 22, 2006 at 12:30:29AM -0800, Andrew Morton wrote:
> I expect that you'll find that the ide code ends up doing
> down_write(pci_bus_sem), which will enable interrupts.
will: down_read(_bus_sem);
also enable interrupts?
Since that is called:
init/main.c start_kernel
On Fri, Dec 22, 2006 at 03:00:59PM +0100, Ard -kwaak- van Breemen wrote:
> 262 if (!irqs_disabled()) printk(__FILE__ "%s(): blaat:
> interrupts were enabled [EMAIL PROTECTED]",__FUNCTION__,__LINE__);
> 263
> 264 ide_init_hwif_ports(, ide_default_io_base(index), 0,
>
On Fri, Dec 22, 2006 at 11:30:05AM +0100, Ard -kwaak- van Breemen wrote:
> Anyway: on to the ide_setup tracking
> (I've noticed that the notifier of this problem als has idebus=66
> or something similar, so that explains in his case the
> early call to ide_setup.)
Aaarrgh...
Somewhere between
Il giorno ven, 22/12/2006 alle 01.43 -0800, Andrew Morton ha scritto:
> On Fri, 22 Dec 2006 10:32:51 +0100
> Stefano Takekawa <[EMAIL PROTECTED]> wrote:
>
> > Applied to 2.6.19 it doesn't change anything. It still panics.
>
> Really?
>
> And you can confirm that converting pci_bus_sem back into
Hello,
On Fri, Dec 22, 2006 at 12:30:29AM -0800, Andrew Morton wrote:
> To whom do I have to pay how much to get this darn patch tested?
I've already tested that (as I said somewhere in the bugzilla so
it probably got lost somehow :-) ): It doesn't solve the booting
problem, and I really don't
On Fri, 22 Dec 2006 10:32:51 +0100
Stefano Takekawa <[EMAIL PROTECTED]> wrote:
> Applied to 2.6.19 it doesn't change anything. It still panics.
Really?
And you can confirm that converting pci_bus_sem back into a spinlock fixes
it?
> How can I have something similar to a serial console on a
Il giorno ven, 22/12/2006 alle 00.30 -0800, Andrew Morton ha scritto:
> On Fri, 22 Dec 2006 09:22:48 +0100
> Ard -kwaak- van Breemen <[EMAIL PROTECTED]> wrote:
>
> > Hello,
> > On Fri, Dec 22, 2006 at 12:41:46PM +0800, Zhang, Yanmin wrote:
> > > I think parse_args enables irq when it calls
On Fri, 22 Dec 2006 09:22:48 +0100
Ard -kwaak- van Breemen <[EMAIL PROTECTED]> wrote:
> Hello,
> On Fri, Dec 22, 2006 at 12:41:46PM +0800, Zhang, Yanmin wrote:
> > I think parse_args enables irq when it calls callbacks.
> > Could you try below?
> > 1) Test Andrew's patch of sema down_write;
> >
Hello,
On Fri, Dec 22, 2006 at 12:41:46PM +0800, Zhang, Yanmin wrote:
> I think parse_args enables irq when it calls callbacks.
> Could you try below?
> 1) Test Andrew's patch of sema down_write;
> 2) Apply below patch and see what the output is when booting. If the output
> has
>
Hello,
On Fri, Dec 22, 2006 at 12:41:46PM +0800, Zhang, Yanmin wrote:
I think parse_args enables irq when it calls callbacks.
Could you try below?
1) Test Andrew's patch of sema down_write;
2) Apply below patch and see what the output is when booting. If the output
has
[BUG]..address., Pls.
On Fri, 22 Dec 2006 09:22:48 +0100
Ard -kwaak- van Breemen [EMAIL PROTECTED] wrote:
Hello,
On Fri, Dec 22, 2006 at 12:41:46PM +0800, Zhang, Yanmin wrote:
I think parse_args enables irq when it calls callbacks.
Could you try below?
1) Test Andrew's patch of sema down_write;
2) Apply
Il giorno ven, 22/12/2006 alle 00.30 -0800, Andrew Morton ha scritto:
On Fri, 22 Dec 2006 09:22:48 +0100
Ard -kwaak- van Breemen [EMAIL PROTECTED] wrote:
Hello,
On Fri, Dec 22, 2006 at 12:41:46PM +0800, Zhang, Yanmin wrote:
I think parse_args enables irq when it calls callbacks.
On Fri, 22 Dec 2006 10:32:51 +0100
Stefano Takekawa [EMAIL PROTECTED] wrote:
Applied to 2.6.19 it doesn't change anything. It still panics.
Really?
And you can confirm that converting pci_bus_sem back into a spinlock fixes
it?
How can I have something similar to a serial console on a laptop
Hello,
On Fri, Dec 22, 2006 at 12:30:29AM -0800, Andrew Morton wrote:
To whom do I have to pay how much to get this darn patch tested?
I've already tested that (as I said somewhere in the bugzilla so
it probably got lost somehow :-) ): It doesn't solve the booting
problem, and I really don't have
Il giorno ven, 22/12/2006 alle 01.43 -0800, Andrew Morton ha scritto:
On Fri, 22 Dec 2006 10:32:51 +0100
Stefano Takekawa [EMAIL PROTECTED] wrote:
Applied to 2.6.19 it doesn't change anything. It still panics.
Really?
And you can confirm that converting pci_bus_sem back into a spinlock
On Fri, Dec 22, 2006 at 11:30:05AM +0100, Ard -kwaak- van Breemen wrote:
Anyway: on to the ide_setup tracking
(I've noticed that the notifier of this problem als has idebus=66
or something similar, so that explains in his case the
early call to ide_setup.)
Aaarrgh...
Somewhere between the
On Fri, Dec 22, 2006 at 03:00:59PM +0100, Ard -kwaak- van Breemen wrote:
262 if (!irqs_disabled()) printk(__FILE__ %s(): blaat:
interrupts were enabled [EMAIL PROTECTED],__FUNCTION__,__LINE__);
263
264 ide_init_hwif_ports(hw, ide_default_io_base(index), 0,
On Fri, Dec 22, 2006 at 12:30:29AM -0800, Andrew Morton wrote:
I expect that you'll find that the ide code ends up doing
down_write(pci_bus_sem), which will enable interrupts.
will: down_read(pci_bus_sem);
also enable interrupts?
Since that is called:
init/main.c start_kernel
On Fri, Dec 22, 2006 at 12:30:29AM -0800, Andrew Morton wrote:
To whom do I have to pay how much to get this darn patch tested?
I've altered your patch to do the spin_lock_irqsave in down_read.
I am very ignorant and stupid. That's why I am doing it without
thinking why or why not de irqsave is
On Fri, Dec 22, 2006 at 03:41:34PM +0100, Ard -kwaak- van Breemen wrote:
Repeating: I am very stupid, so I don't know if saving the irq state is ok or
not in down_read.
The Andrew Morton patch but the rewritten for down_read makes the
symptoms go away.
The problem obviously is that the
Hello,
On Thu, Dec 21, 2006 at 04:04:04PM +0800, Zhang, Yanmin wrote:
I couldn't reproduce it on my EM64T machine. I instrumented function
start_kernel and
didn't find irq was enabled before calling init_IRQ. It'll be better if the
reporter could
instrument function start_kernel to capture
On Fri, 22 Dec 2006 15:16:55 +0100
Ard -kwaak- van Breemen [EMAIL PROTECTED] wrote:
On Fri, Dec 22, 2006 at 03:00:59PM +0100, Ard -kwaak- van Breemen wrote:
262 if (!irqs_disabled()) printk(__FILE__ %s(): blaat:
interrupts were enabled [EMAIL PROTECTED],__FUNCTION__,__LINE__);
I am pretty sure the i386 tree has the same problem but I haven't checked yet.
Anyway: the panic is just a way of noticing. The bug is that irq's are enabled
before the irq controller is set up.
A very similar i386 linux installation works fine on my laptop, but that
i386 kernel never had
IL PROTECTED]; Eric W. Biederman
>>Subject: Re: [Bug 7505] Linux-2.6.18 fails to boot on AMD64 machine
>>
>>On Thu, Dec 21, 2006 at 04:04:04PM +0800, Zhang, Yanmin wrote:
>>> I couldn't reproduce it on my EM64T machine. I instrumented function
>>> start_kerne
On Thu, Dec 21, 2006 at 04:04:04PM +0800, Zhang, Yanmin wrote:
> I couldn't reproduce it on my EM64T machine. I instrumented function
> start_kernel and
> didn't find irq was enabled before calling init_IRQ. It'll be better if the
> reporter could
> instrument function start_kernel to capture
Hello,
On Thu, Dec 21, 2006 at 04:04:04PM +0800, Zhang, Yanmin wrote:
> I couldn't reproduce it on my EM64T machine. I instrumented function
> start_kernel and
> didn't find irq was enabled before calling init_IRQ. It'll be better if the
> reporter could
> instrument function start_kernel to
On Thu, 21 Dec 2006 20:52:40 +0100
Ard -kwaak- van Breemen <[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Thu, Dec 21, 2006 at 04:04:04PM +0800, Zhang, Yanmin wrote:
> > I couldn't reproduce it on my EM64T machine. I instrumented function
> > start_kernel and
> > didn't find irq was enabled before
W. Biederman; Zhang, Yanmin
>>Subject: Re: [Bug 7505] Linux-2.6.18 fails to boot on AMD64 machine
>>
>>On Wed, 20 Dec 2006 04:59:19 -0500
>>Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>>
>>> > On 12/19/06, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
] Linux-2.6.18 fails to boot on AMD64 machine
On Wed, 20 Dec 2006 04:59:19 -0500
Chuck Ebbert [EMAIL PROTECTED] wrote:
On 12/19/06, Chuck Ebbert [EMAIL PROTECTED] wrote:
So an external interrupt occurred, the system tried to use interrupt
descriptor #39 decimal (irq 7), but the descriptor
On Thu, 21 Dec 2006 20:52:40 +0100
Ard -kwaak- van Breemen [EMAIL PROTECTED] wrote:
Hello,
On Thu, Dec 21, 2006 at 04:04:04PM +0800, Zhang, Yanmin wrote:
I couldn't reproduce it on my EM64T machine. I instrumented function
start_kernel and
didn't find irq was enabled before calling
Hello,
On Thu, Dec 21, 2006 at 04:04:04PM +0800, Zhang, Yanmin wrote:
I couldn't reproduce it on my EM64T machine. I instrumented function
start_kernel and
didn't find irq was enabled before calling init_IRQ. It'll be better if the
reporter could
instrument function start_kernel to capture
On Thu, Dec 21, 2006 at 04:04:04PM +0800, Zhang, Yanmin wrote:
I couldn't reproduce it on my EM64T machine. I instrumented function
start_kernel and
didn't find irq was enabled before calling init_IRQ. It'll be better if the
reporter could
instrument function start_kernel to capture which
] Linux-2.6.18 fails to boot on AMD64 machine
On Thu, Dec 21, 2006 at 04:04:04PM +0800, Zhang, Yanmin wrote:
I couldn't reproduce it on my EM64T machine. I instrumented function
start_kernel and
didn't find irq was enabled before calling init_IRQ. It'll be better if the
reporter could
On Wed, 2006-12-20 at 02:37 -0800, Andrew Morton wrote:
> On Wed, 20 Dec 2006 04:59:19 -0500
> Chuck Ebbert <[EMAIL PROTECTED]> wrote:
>
> > > On 12/19/06, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> > > > So an external interrupt occurred, the system tried to use interrupt
> > > > descriptor #39
On Wed, 20 Dec 2006 04:59:19 -0500
Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> > On 12/19/06, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> > > So an external interrupt occurred, the system tried to use interrupt
> > > descriptor #39 decimal (irq 7), but the descriptor was invalid.
> >
> > but the irq
On 12/20/06, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
But it seems interrupts are on--look at the flags:
RSP: 0018:803cdf68 EFLAGS: 00010246
Yes, the IF bit is set.
maybe someone (reporters) could add !irq_disabled() and printk in
start_kernel init/main.c to see which
> On 12/19/06, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> > So an external interrupt occurred, the system tried to use interrupt
> > descriptor #39 decimal (irq 7), but the descriptor was invalid.
>
> but the irq is disabled at that time.
>
> can you use attached diff to verify if the irq is
On 12/19/06, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
So an external interrupt occurred, the system tried to use interrupt
descriptor #39 decimal (irq 7), but the descriptor was invalid.
but the irq is disabled at that time.
can you use attached diff to verify if the irq is enable somehow?
YH
On 12/19/06, Chuck Ebbert [EMAIL PROTECTED] wrote:
So an external interrupt occurred, the system tried to use interrupt
descriptor #39 decimal (irq 7), but the descriptor was invalid.
but the irq is disabled at that time.
can you use attached diff to verify if the irq is enable somehow?
YH
On 12/19/06, Chuck Ebbert [EMAIL PROTECTED] wrote:
So an external interrupt occurred, the system tried to use interrupt
descriptor #39 decimal (irq 7), but the descriptor was invalid.
but the irq is disabled at that time.
can you use attached diff to verify if the irq is enable somehow?
On 12/20/06, Chuck Ebbert [EMAIL PROTECTED] wrote:
But it seems interrupts are on--look at the flags:
RSP: 0018:803cdf68 EFLAGS: 00010246
Yes, the IF bit is set.
maybe someone (reporters) could add !irq_disabled() and printk in
start_kernel init/main.c to see which function
On Wed, 20 Dec 2006 04:59:19 -0500
Chuck Ebbert [EMAIL PROTECTED] wrote:
On 12/19/06, Chuck Ebbert [EMAIL PROTECTED] wrote:
So an external interrupt occurred, the system tried to use interrupt
descriptor #39 decimal (irq 7), but the descriptor was invalid.
but the irq is disabled at
On Wed, 2006-12-20 at 02:37 -0800, Andrew Morton wrote:
On Wed, 20 Dec 2006 04:59:19 -0500
Chuck Ebbert [EMAIL PROTECTED] wrote:
On 12/19/06, Chuck Ebbert [EMAIL PROTECTED] wrote:
So an external interrupt occurred, the system tried to use interrupt
descriptor #39 decimal (irq 7),
In-Reply-To: <[EMAIL PROTECTED]>
On Tue, 19 Dec 2006 17:29:00 -0800, Andrew Morton wrote:
> Quoting the bug report:
> general protection fault: 013b [1] PREEMPT
That '013b' is critical information.
Bit 0: 1: exception source is external to the processor
Bit 1: 1: there is a problem with an
On Mon, 18 Dec 2006 09:48:01 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> [EMAIL PROTECTED] writes:
>
> > http://bugzilla.kernel.org/show_bug.cgi?id=7505
> >
> > --- Additional Comments From [EMAIL PROTECTED] 2006-12-18 07:39 ---
> > OK, fixed.
>
>
> Greg.
>
> It appears
On Mon, 18 Dec 2006 09:48:01 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
[EMAIL PROTECTED] writes:
http://bugzilla.kernel.org/show_bug.cgi?id=7505
--- Additional Comments From [EMAIL PROTECTED] 2006-12-18 07:39 ---
OK, fixed.
Greg.
It appears commit
In-Reply-To: [EMAIL PROTECTED]
On Tue, 19 Dec 2006 17:29:00 -0800, Andrew Morton wrote:
Quoting the bug report:
general protection fault: 013b [1] PREEMPT
That '013b' is critical information.
Bit 0: 1: exception source is external to the processor
Bit 1: 1: there is a problem with an
[EMAIL PROTECTED] writes:
> http://bugzilla.kernel.org/show_bug.cgi?id=7505
>
> --- Additional Comments From [EMAIL PROTECTED] 2006-12-18 07:39 ---
> OK, fixed.
Greg.
It appears commit d71374dafbba7ec3f67371d3b7e9f6310a588808 which
replaced the pci bus spinlock with a semaphore causes
[EMAIL PROTECTED] writes:
http://bugzilla.kernel.org/show_bug.cgi?id=7505
--- Additional Comments From [EMAIL PROTECTED] 2006-12-18 07:39 ---
OK, fixed.
Greg.
It appears commit d71374dafbba7ec3f67371d3b7e9f6310a588808 which
replaced the pci bus spinlock with a semaphore causes
74 matches
Mail list logo
