LinuxLists.cc - Linux 2.6.10-rc2

[permalink] [raw]

Subject: 2.6.10-rc2 doesn't boot

I don't know what might have caused this:

Both 2.6.9 and 2.6.10-rc1-mm5 boot fine on my computer.

2.6.10-rc2 doesn't boot.

It stops at the following place (from a 2.6.10-rc1-mm5 log):

<-- snip -->

...
ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PS/2 Keyboard Controller [PS2K] at I/O 0x60, 0x64, irq 1
ACPI: PS/2 Mouse Controller [PS2M] at irq 12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing
disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
parport0: irq 7 detected
lp0: using parport0 (polling).
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered

----> 2.6.10-rc2 stops here

loop: loaded (max 8 devices)
sis900.c: v1.08.07 11/02/2003
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 6
PCI: setting IRQ 6 as level-triggered
ACPI: PCI interrupt 0000:00:04.0[A] -> GSI 6 (level, low) -> IRQ 6
eth0: Realtek RTL8201 PHY transceiver found at address 1.
eth0: Using transceiver found at address 1 as default
eth0: SiS 900 PCI Fast Ethernet at 0xdc00, IRQ 6, 00:0b:6a:3b:93:a8.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx
SIS5513: IDE controller at PCI slot 0000:00:02.5
SIS5513: chipset revision 0
SIS5513: not 100% native mode: will probe irqs later
SIS5513: SiS 962/963 MuTIOL IDE UDMA133 controller
ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:DMA, hdd:DMA
...

<-- snip -->

My .config is attached.

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

Attachments:

(No filename) (1.96 kB)
.config (29.36 kB)
Download all attachments

2004-11-15 04:48:43

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot

On Mon, 15 Nov 2004, Adrian Bunk wrote:
> io scheduler deadline registered
> io scheduler cfq registered
>
> ----> 2.6.10-rc2 stops here
>
> loop: loaded (max 8 devices)

Strange. There is not a lot in between those two registrations. The "cfq
registered" comes from cfq_init(), and the "loop: loaded" thing comes from
loop_init(), and in between them in the link there is just floppy.o.

And I don't see that _any_ of those three has changed. Yes, cfq got an
__exit added to its exit function, and floppy got __initdata added, but
neither of those should make any difference what-so-ever.

Just for interest, what happens if you disable floppy support? It doesn't
look like you have a floppy on that system..

Linus

2004-11-15 05:40:25

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot

On Sun, Nov 14, 2004 at 08:48:22PM -0800, Linus Torvalds wrote:
>
>
> On Mon, 15 Nov 2004, Adrian Bunk wrote:
> > io scheduler deadline registered
> > io scheduler cfq registered
> >
> > ----> 2.6.10-rc2 stops here
> >
> > loop: loaded (max 8 devices)
>
> Strange. There is not a lot in between those two registrations. The "cfq
> registered" comes from cfq_init(), and the "loop: loaded" thing comes from
> loop_init(), and in between them in the link there is just floppy.o.
>
> And I don't see that _any_ of those three has changed. Yes, cfq got an
> __exit added to its exit function, and floppy got __initdata added, but
> neither of those should make any difference what-so-ever.
>
> Just for interest, what happens if you disable floppy support? It doesn't
> look like you have a floppy on that system..

Bingo.

I don't have a floppy and floppy support is disabled in the BIOS.

And thinking about it, I had exactly the same problem in -mm three
months ago (the thread subject was "2.6.8-rc4-mm1 doesn't boot").
(I didn't think it might be the same problem again since this was so
long ago...).

It seems Bjorns "PCI: remove unconditional PCI ACPI IRQ routing" was
merged now into your tree, but his patch to fix floppy.c wasn't
merged...

> Linus

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2004-11-15 07:25:47

by Andrew Morton

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot

Adrian Bunk <[email protected]> wrote:
>
> 2.6.10-rc2 doesn't boot.
>
> It stops at the following place (from a 2.6.10-rc1-mm5 log):
>
> <-- snip -->
>
> ...
> ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
> ACPI: PS/2 Keyboard Controller [PS2K] at I/O 0x60, 0x64, irq 1
> ACPI: PS/2 Mouse Controller [PS2M] at irq 12
> serio: i8042 AUX port at 0x60,0x64 irq 12
> serio: i8042 KBD port at 0x60,0x64 irq 1
> Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing
> disabled
> ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
> parport0: irq 7 detected
> lp0: using parport0 (polling).
> io scheduler noop registered
> io scheduler anticipatory registered
> io scheduler deadline registered
> io scheduler cfq registered
>
>
> ----> 2.6.10-rc2 stops here
>
>
> loop: loaded (max 8 devices)

Suggest you add initcall_debug to the kernel boot command line so we can
see which subsystem is causing the hang.

2004-11-15 10:27:13

by Russell King

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2

On Sun, Nov 14, 2004 at 06:49:04PM -0800, Linus Torvalds wrote:
> Ok, the -rc2 changes are almost as big as the -rc1 changes, and we should
> now calm down, so I do not want to see anything but bug-fixes until 2.6.10
> is released. Otherwise we'll never get there.

There's a few more non-bugfix changes which need merging first though.
Namely an update to the S3C2410 serial driver from Ben to allow the
s3c2410 changes which are now in 2.6.10-rc2 to work. Otherwise I
suspect s3c2410 is going to be dead in the water for 2.6.10.

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core

2004-11-15 11:25:04

by Ben Dooks

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2

On Mon, Nov 15, 2004 at 10:26:20AM +0000, Russell King wrote:
> On Sun, Nov 14, 2004 at 06:49:04PM -0800, Linus Torvalds wrote:
> > Ok, the -rc2 changes are almost as big as the -rc1 changes, and we should
> > now calm down, so I do not want to see anything but bug-fixes until 2.6.10
> > is released. Otherwise we'll never get there.
>
> There's a few more non-bugfix changes which need merging first though.
> Namely an update to the S3C2410 serial driver from Ben to allow the
> s3c2410 changes which are now in 2.6.10-rc2 to work. Otherwise I
> suspect s3c2410 is going to be dead in the water for 2.6.10.

The new patch for the serial driver fixes/updates has been sent to
rmk, so hopefully this should complete the patch set.

--
Ben ([email protected], http://www.fluff.org/)

'a smiley only costs 4 bytes'

2004-11-15 11:56:44

by Nick Piggin

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2

Linus Torvalds wrote:
> Ok, the -rc2 changes are almost as big as the -rc1 changes, and we should
> now calm down, so I do not want to see anything but bug-fixes until 2.6.10
> is released. Otherwise we'll never get there.
>

I'd like to get included that patch to restore the buffer of memory
reserved for GFP_ATOMIC allocations (ie. the difference between GFP_KERNEL
and GFP_ATOMIC allocations).

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm5/broken-out/mm-restore-atomic-buffer.patch

It is not actually a regression versus 2.6.9 (it is vs 2.6.8), although I
think it is responsible for the increased reports of page allocation failures.

It would be nice to let it have more testing in -mm first, but OTOH if we
_really_ want it in 2.6.10 it would make sense to merge it ASAP so it can get
wider testing.

Any feelings on the matter yet, Andrew? Or were you thinking it would be OK for
post 2.6.10?

2004-11-15 20:22:12

by Andrew Morton

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2

Nick Piggin <[email protected]> wrote:
>
> I'd like to get included that patch to restore the buffer of memory
> reserved for GFP_ATOMIC allocations (ie. the difference between GFP_KERNEL
> and GFP_ATOMIC allocations).
>
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm5/broken-out/mm-restore-atomic-buffer.patch
>
> It is not actually a regression versus 2.6.9 (it is vs 2.6.8), although I
> think it is responsible for the increased reports of page allocation failures.
>
> It would be nice to let it have more testing in -mm first, but OTOH if we
> _really_ want it in 2.6.10 it would make sense to merge it ASAP so it can get
> wider testing.
>
> Any feelings on the matter yet, Andrew? Or were you thinking it would be OK for
> post 2.6.10?

That one should be in 2.6.10, yes.

2004-11-15 20:25:05

by Paul Blazejowski

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2

Starting up ut2004 or doom3 games produces ALSA segfaults, dmesg prints:

scheduling while atomic: ut2004-bin/0x00000001/8390
[<c0331508>] schedule+0x508/0x510
[<c03319a3>] schedule_timeout+0x63/0xc0
[<c0122c90>] process_timeout+0x0/0x10
[<c012306f>] msleep+0x2f/0x40
[<f8b9e02f>] snd_intel8x0_setup_pcm_out+0xbf/0x150 [snd_intel8x0]
[<f8b9e14c>] snd_intel8x0_pcm_prepare+0x8c/0xb0 [snd_intel8x0]
[<f8bfda84>] snd_pcm_do_prepare+0x14/0x40 [snd_pcm]
[<f8bfcdd8>] snd_pcm_action_single+0x38/0x80 [snd_pcm]
[<f8bfcfd0>] snd_pcm_action_nonatomic+0x80/0x90 [snd_pcm]
[<f8bfdb37>] snd_pcm_prepare+0x57/0x80 [snd_pcm]
[<f8c001b2>] snd_pcm_playback_ioctl1+0x52/0x310 [snd_pcm]
[<f8d25ae9>] snd_pcm_oss_poll+0x49/0x1a0 [snd_pcm_oss]
[<c016901a>] poll_freewait+0x3a/0x50
[<f8c00828>] snd_pcm_kernel_playback_ioctl+0x38/0x50 [snd_pcm]
[<f8d23026>] snd_pcm_oss_prepare+0x26/0x60 [snd_pcm_oss]
[<f8d2309d>] snd_pcm_oss_make_ready+0x3d/0x60 [snd_pcm_oss]
[<f8d2358d>] snd_pcm_oss_write1+0x3d/0x210 [snd_pcm_oss]
[<f8d259d0>] snd_pcm_oss_write+0x40/0x60 [snd_pcm_oss]
[<f8d25990>] snd_pcm_oss_write+0x0/0x60 [snd_pcm_oss]
[<c01563e8>] vfs_write+0xb8/0x130
[<c0156531>] sys_write+0x51/0x80
[<c010317b>] syscall_call+0x7/0xb

.config attached

Regards,

Paul B.
--
FreeBSD the Power to Serve!

Attachments:

(No filename) (1.27 kB)
.config (30.31 kB)
Download all attachments

2004-11-15 23:27:40

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot

* Adrian Bunk ([email protected]) wrote:
> It seems Bjorns "PCI: remove unconditional PCI ACPI IRQ routing" was
> merged now into your tree, but his patch to fix floppy.c wasn't
> merged...

What's the likelihood of getting some derivative of Bjorn's patch
merged? W/out the patch (and w/ floppy built) I've the same issue.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

2004-11-15 23:59:13

by Andrew Morton

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot

Chris Wright <[email protected]> wrote:
>
> * Adrian Bunk ([email protected]) wrote:
> > It seems Bjorns "PCI: remove unconditional PCI ACPI IRQ routing" was
> > merged now into your tree, but his patch to fix floppy.c wasn't
> > merged...
>
> What's the likelihood of getting some derivative of Bjorn's patch
> merged? W/out the patch (and w/ floppy built) I've the same issue.
>

I've had no bug reports against it for some time, but I was hoping to talk
Len into merging it up because ACPI makes my head swim.

From: Bjorn Helgaas <[email protected]>

This can be disabled with "floppy=no_acpi", which should only be required
if your BIOS supplies incorrect ACPI _CRS information about I/O ports,
IRQs, or DMA channels.

Signed-off-by: Bjorn Helgaas <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---

25-akpm/Documentation/floppy.txt | 6 +
25-akpm/drivers/block/floppy.c | 183 +++++++++++++++++++++++++++++++++++++++
2 files changed, 189 insertions(+)

diff -puN Documentation/floppy.txt~add-acpi-based-floppy-controller-enumeration Documentation/floppy.txt
--- 25/Documentation/floppy.txt~add-acpi-based-floppy-controller-enumeration 2004-11-11 01:19:18.835616160 -0800
+++ 25-akpm/Documentation/floppy.txt 2004-11-11 01:19:18.840615400 -0800
@@ -204,6 +204,12 @@ in /etc/modprobe.conf.
It's been recommended that take about 1/4 of the default speed
in some more extreme cases."

+ floppy=no_acpi
+ Don't enumerate floppy controllers using ACPI namespace.
+ You may need this if your ACPI is buggy and doesn't report
+ a floppy controller when it actually exists, or if it
+ reports incorrect I/O port, IRQ, or DMA information.
+

Supporting utilities and additional documentation:
==================================================
diff -puN drivers/block/floppy.c~add-acpi-based-floppy-controller-enumeration drivers/block/floppy.c
--- 25/drivers/block/floppy.c~add-acpi-based-floppy-controller-enumeration 2004-11-11 01:19:18.837615856 -0800
+++ 25-akpm/drivers/block/floppy.c 2004-11-11 01:31:30.094447920 -0800
@@ -181,6 +181,13 @@ static int print_unex = 1;
#include <linux/device.h>
#include <linux/buffer_head.h> /* for invalidate_buffers() */

+#ifdef CONFIG_ACPI
+#include <linux/acpi.h>
+#include <acpi/acpi_bus.h>
+
+static int no_acpi_floppy;
+#endif
+
/*
* PS/2 floppies have much slower step rates than regular floppies.
* It's been recommended that take about 1/4 of the default speed
@@ -4150,6 +4157,9 @@ static struct param_table {
{"slow", NULL, &slow_floppy, 1, 0},
{"unexpected_interrupts", NULL, &print_unex, 1, 0},
{"no_unexpected_interrupts", NULL, &print_unex, 0, 0},
+#ifdef CONFIG_ACPI
+ {"no_acpi", NULL, &no_acpi_floppy, 1, 0},
+#endif
{"L40SX", NULL, &print_unex, 0, 0}

EXTRA_FLOPPY_PARAMS
@@ -4222,11 +4232,180 @@ static struct kobject *floppy_find(dev_t
return get_disk(disks[drive]);
}

+#ifdef CONFIG_ACPI
+static int acpi_floppy_registered;
+static int acpi_floppies;
+
+struct region {
+ unsigned int base;
+ unsigned int size;
+};
+
+struct floppy_resources {
+ unsigned int nr_io_regions;
+ struct region io_region[2];
+ unsigned int irq;
+ unsigned int dma_channel;
+};
+
+static acpi_status acpi_floppy_resource(struct acpi_resource *res, void *data)
+{
+ struct floppy_resources *fd = (struct floppy_resources *) data;
+ struct acpi_resource_io *io;
+ struct acpi_resource_irq *irq;
+ struct acpi_resource_ext_irq *ext_irq;
+ struct acpi_resource_dma *dma;
+ int n;
+
+ if (res->id == ACPI_RSTYPE_IO) {
+ io = &res->data.io;
+ if (io->range_length) {
+ n = fd->nr_io_regions;
+ if (n < 2) {
+ fd->io_region[n].base = io->min_base_address;
+ fd->io_region[n].size = io->range_length;
+ fd->nr_io_regions++;
+ } else {
+ printk(KERN_WARNING "%s: ignoring I/O port region 0x%x-0x%x\n",
+ DEVICE_NAME, io->min_base_address,
+ io->min_base_address + io->range_length - 1);
+ }
+ }
+ } else if (res->id == ACPI_RSTYPE_IRQ) {
+ irq = &res->data.irq;
+ if (irq->number_of_interrupts > 0)
+ fd->irq = acpi_register_gsi(irq->interrupts[0],
+ irq->edge_level, irq->active_high_low);
+ } else if (res->id == ACPI_RSTYPE_EXT_IRQ) {
+ ext_irq = &res->data.extended_irq;
+ if (ext_irq->number_of_interrupts > 0)
+ fd->irq = acpi_register_gsi(ext_irq->interrupts[0],
+ ext_irq->edge_level, ext_irq->active_high_low);
+ } else if (res->id == ACPI_RSTYPE_DMA) {
+ dma = &res->data.dma;
+ if (dma->number_of_channels > 0)
+ fd->dma_channel = dma->channels[0];
+ }
+ return AE_OK;
+}
+
+static int acpi_floppy_add(struct acpi_device *device)
+{
+ struct floppy_resources fd;
+ acpi_status status;
+ unsigned int base, dcr;
+
+ memset(&fd, 0, sizeof(fd));
+ status = acpi_walk_resources(device->handle, METHOD_NAME__CRS,
+ acpi_floppy_resource, &fd);
+ if (ACPI_FAILURE(status))
+ return -ENODEV;
+
+ strncpy(acpi_device_name(device), "Floppy Controller",
+ sizeof(acpi_device_name(device)));
+ printk("ACPI: %s [%s] at I/O 0x%x-0x%x",
+ acpi_device_name(device), acpi_device_bid(device),
+ fd.io_region[0].base,
+ fd.io_region[0].base + fd.io_region[0].size - 1);
+ if (fd.nr_io_regions > 1) {
+ if (fd.io_region[1].size == 1)
+ printk(", 0x%x", fd.io_region[1].base);
+ else
+ printk(", 0x%x-0x%x", fd.io_region[1].base,
+ fd.io_region[1].base + fd.io_region[1].size - 1);
+ }
+ printk(" irq %d dma channel %d\n", fd.irq, fd.dma_channel);
+
+ /*
+ * The most correct resource description is probably of the form
+ * 0x3f2-0x3f5, 0x3f7
+ * Those are the only ports this driver actually uses.
+ *
+ * 0x3f0 and 0x3f1 were apparently used on PS/2 systems (though
+ * this driver doesn't touch them), and 0x3f6 is used by IDE.
+ * Some BIOS's erroneously include those ports, or omit 0x3f7,
+ * so we should also be able to handle the following:
+ * 0x3f0-0x3f5
+ * 0x3f0-0x3f5, 0x3f7
+ * 0x3f0-0x3f7
+ * 0x3f2-0x3f7
+ */
+ base = fd.io_region[0].base & ~0x7;
+ dcr = base + 7;
+
+#define contains(region, port) ((region).base <= (port) && \
+ (port) < (region).base + (region).size)
+
+ if (!(contains(fd.io_region[0], dcr) || contains(fd.io_region[1], dcr))) {
+ printk(KERN_WARNING "ACPI: [%s] doesn't declare FD_DCR; also claiming 0x%x\n",
+ acpi_device_bid(device), dcr);
+ }
+
+#undef contains
+
+ if (acpi_floppies == 0) {
+ FDC1 = base;
+ FLOPPY_IRQ = fd.irq;
+ FLOPPY_DMA = fd.dma_channel;
+ } else if (acpi_floppies == 1) {
+ FDC2 = base;
+ if (fd.irq != FLOPPY_IRQ || fd.dma_channel != FLOPPY_DMA)
+ printk(KERN_WARNING "%s: different IRQ/DMA info for [%s]; may not work\n",
+ DEVICE_NAME, acpi_device_bid(device));
+ } else {
+ printk(KERN_ERR "%s: only 2 controllers supported; [%s] ignored\n",
+ DEVICE_NAME, acpi_device_bid(device));
+ return -ENODEV;
+ }
+
+ acpi_floppies++;
+ return 0;
+}
+
+static struct acpi_driver acpi_floppy_driver = {
+ .name = "floppy",
+ .ids = "PNP0700",
+ .ops = {
+ .add = acpi_floppy_add,
+ },
+};
+
+static int acpi_floppy_init(void)
+{
+ int err;
+
+ if (no_acpi_floppy) {
+ printk("%s: ACPI detection disabled\n", DEVICE_NAME);
+ return -ENODEV;
+ }
+ err = acpi_bus_register_driver(&acpi_floppy_driver);
+ if (err >= 0)
+ acpi_floppy_registered = 1;
+ return err;
+}
+
+static void acpi_floppy_exit(void)
+{
+ if (acpi_floppy_registered) {
+ acpi_bus_unregister_driver(&acpi_floppy_driver);
+ acpi_floppy_registered = 0;
+ }
+}
+#else
+static inline int acpi_floppy_init(void) { return -ENODEV; }
+static inline void acpi_floppy_exit(void) { }
+#endif
+
int __init floppy_init(void)
{
int i, unit, drive;
int err, dr;

+ if (acpi_floppy_init() == 0) {
+ err = -ENODEV;
+ goto out_put_acpi;
+ }
+
raw_cmd = NULL;

for (dr = 0; dr < N_DRIVE; dr++) {
@@ -4411,6 +4590,8 @@ out_put_disk:
del_timer(&motor_off_timer[dr]);
put_disk(disks[dr]);
}
+out_put_acpi:
+ acpi_floppy_exit();
return err;
}

@@ -4627,6 +4808,8 @@ void cleanup_module(void)
/* eject disk, if any */
fd_eject(0);

+ acpi_floppy_exit();
+
wait_for_completion(&device_release);
}

_

2004-11-16 00:30:22

by Eyal Lebedinsky

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2 [dvb-bt8xx unload oops]

Linus Torvalds wrote:
> Ok, the -rc2 changes are almost as big as the -rc1 changes, and we should
> now calm down, so I do not want to see anything but bug-fixes until 2.6.10
> is released. Otherwise we'll never get there.
>
> A lot of driver updates, many of them of the small and trivial kind,
> others less so. USB, ALSA, fbdev, IDE, i2c, v4l, you name it. With a

Did you say 'v4l'? The following crash is a result of unloading the dvb system using:
modprobe -r mt352
modprobe -r sp887x
modprobe -r dvb-bt8xx
modprobe -r bt878
modprobe -r bttv
modprobe -r dvb-core
I assume it is the third unload that triggered this oops.

This is vanilla 2.6.10-rc2 on P4. This was a problem with -rc1 but some patches off the list
[attached] fixed it. I expected these to be in -rc2, I am not able to say which patch is
missing.

Nov 16 11:13:00 eyal kernel: xxx detach
Nov 16 11:13:00 eyal kernel: xxx detach
Nov 16 11:13:00 eyal kernel: f899f3ea
Nov 16 11:13:00 eyal kernel: PREEMPT SMP
Nov 16 11:13:00 eyal kernel: Modules linked in: tsdev psmouse v4l1_compat dvb_bt8xx dvb_core i810_audio ac97_codec sr_mod sg ide_scsi ide_cd cdrom it87 eeprom i2c_isa i2c_i801 i2c_sensor eth1394 ohci1394 ieee1394 dc395x scsi_mod snd_bt87x bt878 bttv tuner video_buf firmware_class i2c_algo_bit v4l2_common btcx_risc i2c_core videodev e1000 snd_intel8x0 snd_ac97_codec snd_pcm snd_timer snd_page_alloc gameport snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore cfi_cmdset_0002 cfi_util mtdpart jedec_probe cfi_probe gen_probe ichxrom mtdcore chipreg ehci_hcd uhci_hcd usbcore shpchp pciehp pci_hotplug intel_mch_agp intel_agp agpgart parport_pc parport 8250_pnp 8250 serial_core evdev nls_cp437 msdos fat dm_mod rtc unix
Nov 16 11:13:00 eyal kernel: CPU: 0
Nov 16 11:13:00 eyal kernel: EIP: 0060:[pg0+945243114/1069364224] Not tainted VLI
Nov 16 11:13:00 eyal kernel: EFLAGS: 00010282 (2.6.9-d)
Nov 16 11:13:00 eyal kernel: EIP is at dvb_bt8xx_remove+0x89/0xc3 [dvb_bt8xx]
Nov 16 11:13:00 eyal kernel: eax: 00000000 ebx: ce3eb438 ecx: f9d0edf8 edx: 00000000
Nov 16 11:13:00 eyal kernel: esi: ce3eb400 edi: 00000000 ebp: f899f4a0 esp: d6130ef8
Nov 16 11:13:00 eyal kernel: ds: 007b es: 007b ss: 0068
Nov 16 11:13:00 eyal kernel: Process modprobe (pid: 3959, threadinfo=d6130000 task=eff88330)
Nov 16 11:13:00 eyal kernel: Stack: ecb907c0 ce3eb68c f7c6d980 f89a0620 c022507e f7c6d980 f7c6d9a8 f7c6d590
Nov 16 11:13:00 eyal kernel: f89a0670 c02250a0 f7c6d980 f89a0620 c03168c4 c02254b4 f89a0620 f89a0620
Nov 16 11:13:00 eyal kernel: f89a0620 c03168c4 c0225980 f89a0620 f89a0700 f9b93858 f89a0620 f899f4af
Nov 16 11:13:00 eyal kernel: Call Trace:
Nov 16 11:13:00 eyal kernel: [device_release_driver+100/102] device_release_driver+0x64/0x66
Nov 16 11:13:00 eyal kernel: [driver_detach+32/46] driver_detach+0x20/0x2e
Nov 16 11:13:00 eyal kernel: [bus_remove_driver+77/134] bus_remove_driver+0x4d/0x86
Nov 16 11:13:00 eyal kernel: [driver_unregister+19/42] driver_unregister+0x13/0x2a
Nov 16 11:13:00 eyal kernel: [pg0+964069464/1069364224] bttv_sub_unregister+0xf/0x15 [bttv]
Nov 16 11:13:00 eyal kernel: [pg0+945243311/1069364224] dvb_bt8xx_exit+0xf/0x13 [dvb_bt8xx]
Nov 16 11:13:00 eyal kernel: [sys_delete_module+343/396] sys_delete_module+0x157/0x18c
Nov 16 11:13:00 eyal kernel: [sys_munmap+81/118] sys_munmap+0x51/0x76
Nov 16 11:13:00 eyal kernel: [syscall_call+7/11] syscall_call+0x7/0xb
Nov 16 11:13:00 eyal kernel: Code: 24 04 ff 56 78 8d 86 34 02 00 00 89 04 24 e8 f8 e2 35 01 89 1c 24 e8 32 00 36 01 8b 46 2c 89 04 24 e8 27 c3 35 01 8b 06 8b 56 04 <89> 50 04 89 02 c7 46 04 00 02 20 00 c7 06 00 01 10 00 89 34 24

--
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>

2004-11-16 01:33:23

by Lee Revell

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2

Please report ALSA issues to [email protected]. I have
added them to the cc:.

Lee

On Mon, 2004-11-15 at 15:23 -0500, Paul Blazejowski wrote:
> Starting up ut2004 or doom3 games produces ALSA segfaults, dmesg prints:
>
> scheduling while atomic: ut2004-bin/0x00000001/8390
> [<c0331508>] schedule+0x508/0x510
> [<c03319a3>] schedule_timeout+0x63/0xc0
> [<c0122c90>] process_timeout+0x0/0x10
> [<c012306f>] msleep+0x2f/0x40
> [<f8b9e02f>] snd_intel8x0_setup_pcm_out+0xbf/0x150 [snd_intel8x0]
> [<f8b9e14c>] snd_intel8x0_pcm_prepare+0x8c/0xb0 [snd_intel8x0]
> [<f8bfda84>] snd_pcm_do_prepare+0x14/0x40 [snd_pcm]
> [<f8bfcdd8>] snd_pcm_action_single+0x38/0x80 [snd_pcm]
> [<f8bfcfd0>] snd_pcm_action_nonatomic+0x80/0x90 [snd_pcm]
> [<f8bfdb37>] snd_pcm_prepare+0x57/0x80 [snd_pcm]
> [<f8c001b2>] snd_pcm_playback_ioctl1+0x52/0x310 [snd_pcm]
> [<f8d25ae9>] snd_pcm_oss_poll+0x49/0x1a0 [snd_pcm_oss]
> [<c016901a>] poll_freewait+0x3a/0x50
> [<f8c00828>] snd_pcm_kernel_playback_ioctl+0x38/0x50 [snd_pcm]
> [<f8d23026>] snd_pcm_oss_prepare+0x26/0x60 [snd_pcm_oss]
> [<f8d2309d>] snd_pcm_oss_make_ready+0x3d/0x60 [snd_pcm_oss]
> [<f8d2358d>] snd_pcm_oss_write1+0x3d/0x210 [snd_pcm_oss]
> [<f8d259d0>] snd_pcm_oss_write+0x40/0x60 [snd_pcm_oss]
> [<f8d25990>] snd_pcm_oss_write+0x0/0x60 [snd_pcm_oss]
> [<c01563e8>] vfs_write+0xb8/0x130
> [<c0156531>] sys_write+0x51/0x80
> [<c010317b>] syscall_call+0x7/0xb
>
> .config attached
>
> Regards,
>
> Paul B.
--
Lee Revell <[email protected]>

2004-11-16 07:56:57

by Philipp Matthias Hahn

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2 SAVAGEFB startup crash

Hello LKML!

2.6.10-rc2 on Debian i586 crashed during startup.

On Sun, Nov 14, 2004 at 06:49:04PM -0800, Linus Torvalds wrote:
> Summary of changes from v2.6.10-rc1 to v2.6.10-rc2
> ============================================
> Antonino Daplas:
...
> o fbdev: S3 Savage Framebuffer Driver

Copied by hand:

show_stack+0x7f/0xa0
show_registers+0x156/0x1c0
die+0xc8/0x150
do_page_fault+0x326/0x6a2
error_code+0x2b/0x30
savagefb_create_i2c_busses+0x44/0xf0
savagefb_probe+0xe2/0x460
pci_device_probe_static+0x4d/0x60
__pci_device_probe+0x3c/0x50
pci_device_probe+0x2x/0x50
driver_probe_device+0x2e/0x80
driver_attach+0x5c/0xa0
bus_add_driver+0x95/0xd0
driver_register+0x31/0x40
pci_register_driver+0x64/0x80
savagefb_init+0x39/0x41
do_initcalls+0x2b/0xc0
init+0x28/0x110
kernel_thread_helper+0x5/0x10

(gdb) disassemble savagefb_create_i2c_busses
Dump of assembler code for function savagefb_create_i2c_busses:
0x02b0 <savagefb_create_i2c_busses+0>: push %ebp
0x02b1 <savagefb_create_i2c_busses+1>: mov %esp,%ebp
0x02b3 <savagefb_create_i2c_busses+3>: sub $0x8,%esp
0x02b6 <savagefb_create_i2c_busses+6>: mov 0x8(%ebp),%eax
0x02b9 <savagefb_create_i2c_busses+9>: mov 0x234(%eax),%edx
0x02bf <savagefb_create_i2c_busses+15>: mov %edx,0x8(%edx)
0x02c2 <savagefb_create_i2c_busses+18>: mov 0xe0(%eax),%eax
0x02c8 <savagefb_create_i2c_busses+24>: cmp $0x88,%eax
0x02cd <savagefb_create_i2c_busses+29>: je 0x350 <savagefb_create_i2c_busses+160>
0x02d3 <savagefb_create_i2c_busses+35>: ja 0x340 <savagefb_create_i2c_busses+144>
0x02d5 <savagefb_create_i2c_busses+37>: add $0xffffff80,%eax
0x02d8 <savagefb_create_i2c_busses+40>: je 0x2f8 <savagefb_create_i2c_busses+72>
0x02da <savagefb_create_i2c_busses+42>: lea 0x0(%esi),%esi
0x02e0 <savagefb_create_i2c_busses+48>: mov $0x1,%eax
0x02e5 <savagefb_create_i2c_busses+53>: mov %eax,0x4(%esp)
0x02e9 <savagefb_create_i2c_busses+57>: lea 0x8(%edx),%eax
0x02ec <savagefb_create_i2c_busses+60>: mov %eax,(%esp)
0x02ef <savagefb_create_i2c_busses+63>: call 0x1c0 <savage_setup_i2c_bus>
0x02f4 <savagefb_create_i2c_busses+68>: mov %ebp,%esp
0x02f6 <savagefb_create_i2c_busses+70>: pop %ebp
0x02f7 <savagefb_create_i2c_busses+71>: ret

$ grep 'SAVAGE\|I2C' /boot/config-2.6.10-rc2
# I2C support
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=m
# I2C Algorithms
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m
# I2C Hardware Bus support
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
CONFIG_I2C_ELEKTOR=m
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
CONFIG_I2C_ISA=m
# CONFIG_I2C_NFORCE2 is not set
CONFIG_I2C_PARPORT=m
CONFIG_I2C_PARPORT_LIGHT=m
CONFIG_I2C_PIIX4=m
CONFIG_I2C_PROSAVAGE=m
CONFIG_I2C_SAVAGE4=m
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set
CONFIG_I2C_SENSOR=m
# Other I2C Chip support
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
CONFIG_FB_SAVAGE=y
CONFIG_FB_SAVAGE_I2C=y
CONFIG_FB_SAVAGE_ACCEL=y

BYtE
Philipp
--
/ / (_)__ __ ____ __ Philipp Hahn
/ /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ [email protected]

2004-11-16 08:18:22

by Colin Leroy

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2 SAVAGEFB startup crash

On 16 Nov 2004 at 08h11, Philipp Matthias Hahn wrote:

Hi,

> savagefb_create_i2c_busses+0x44/0xf0

You can also try
gdb> list *savagefb_create_i2c_busses+0x44

to get the corresponding chunk of code if your kernel has CONFIG_DEBUG.
--
Colin

2004-11-16 09:53:20

by Takashi Iwai

[permalink] [raw]

Subject: Re: [Alsa-devel] Re: Linux 2.6.10-rc2

At Mon, 15 Nov 2004 16:16:31 -0500,
Lee Revell wrote:
>
> Please report ALSA issues to [email protected]. I have
> added them to the cc:.

The attached patch should fix this.

Takashi

==
Summary: [ALSA] fix sleep in atomic during prepare callback

Fixed the sleep in spinlock during prepare callback.
This happened only on Nforce chips.

Signed-off-by: Takashi Iwai <[email protected]>

--- linux/sound/pci/intel8x0.c 15 Nov 2004 14:19:52 -0000 1.173
+++ linux/sound/pci/intel8x0.c 16 Nov 2004 09:41:47 -0000
@@ -1020,7 +1020,9 @@ static void snd_intel8x0_setup_pcm_out(i
*/
if (cnt & ICH_PCM_246_MASK) {
iputdword(chip, ICHREG(GLOB_CNT), cnt & ~ICH_PCM_246_MASK);
+ spin_unlock_irq(&chip->reg_lock);
msleep(50); /* grrr... */
+ spin_lock_irq(&chip->reg_lock);
}
} else if (chip->device_type == DEVICE_INTEL_ICH4) {
if (runtime->sample_bits > 16)

2004-11-16 10:03:41

by Eyal Lebedinsky

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2 [dvb-bt8xx unload oops]

At first the attachement was not posted. I then posted with "reply" so I now
have another copy of it.

Let's try "Reply to All"... this should get through.

--
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>

Attachments:

2.6.10-rc1-dvb.zip (41.93 kB)

2004-11-16 12:53:41

by Antonino A. Daplas

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2 SAVAGEFB startup crash

On Tuesday 16 November 2004 15:55, Philipp Matthias Hahn wrote:
> Hello LKML!
>
> 2.6.10-rc2 on Debian i586 crashed during startup.
>
> On Sun, Nov 14, 2004 at 06:49:04PM -0800, Linus Torvalds wrote:
> > Summary of changes from v2.6.10-rc1 to v2.6.10-rc2
> > ============================================
> > Antonino Daplas:

Try rc1-mm5, rc2-mm1 or apply this particular changeset:

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm5/broken-out/fbdev-allow-mode-change-even-if-edid-block-is-not-found.patch

Tony

2004-11-16 16:39:37

by Guido Günther

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2

Hi,
On Sun, Nov 14, 2004 at 06:49:04PM -0800, Linus Torvalds wrote:
>
> Ok, the -rc2 changes are almost as big as the -rc1 changes, and we should
> now calm down, so I do not want to see anything but bug-fixes until 2.6.10
> is released. Otherwise we'll never get there.
here's a simple compile fix necessary due to dev.power changes:

--- linux-2.6.10-rc2/drivers/macintosh/mediabay.c.orig 2004-11-16 17:13:53.165493040 +0100
+++ linux-2.6.10-rc2/drivers/macintosh/mediabay.c 2004-11-16 17:16:13.587145704 +0100
@@ -713,13 +713,13 @@
{
struct media_bay_info *bay = macio_get_drvdata(mdev);

- if (state != mdev->ofdev.dev.power_state && state >= 2) {
+ if (state != mdev->ofdev.dev.power.power_state && state >= 2) {
down(&bay->lock);
bay->sleeping = 1;
set_mb_power(bay, 0);
up(&bay->lock);
msleep(MB_POLL_DELAY);
- mdev->ofdev.dev.power_state = state;
+ mdev->ofdev.dev.power.power_state = state;
}
return 0;
}
@@ -728,8 +728,8 @@
{
struct media_bay_info *bay = macio_get_drvdata(mdev);

- if (mdev->ofdev.dev.power_state != 0) {
- mdev->ofdev.dev.power_state = 0;
+ if (mdev->ofdev.dev.power.power_state != 0) {
+ mdev->ofdev.dev.power.power_state = 0;

/* We re-enable the bay using it's previous content
only if it did not change. Note those bozo timings,

Signed-off-by: Guido Guenther <[email protected]>
Cheers,
-- Guido

2004-11-16 17:28:12

by Philipp Matthias Hahn

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2 SAVAGEFB startup crash

Hello Antonio, LKML!

On Tue, Nov 16, 2004 at 08:43:22PM +0800, Antonino A. Daplas wrote:
> On Tuesday 16 November 2004 15:55, Philipp Matthias Hahn wrote:
> > 2.6.10-rc2 on Debian i586 crashed during startup.
...
> Try rc1-mm5, rc2-mm1 or apply this particular changeset:
>
> http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1/2.6.10-rc1-mm5/broken-out/fbdev-allow-mode-change-even-if-edid-block-is-not-found.patch

That fixed the crash, but the screen looks very broken on my notebook
after boot. Switching between XFree86 and SavageFB also locked up the
kernel hard.

BYtE
Philipp
--
/ / (_)__ __ ____ __ Philipp Hahn
/ /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ [email protected]

2004-11-16 21:24:44

by Antonino A. Daplas

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2 SAVAGEFB startup crash

On Wednesday 17 November 2004 01:27, Philipp Matthias Hahn wrote:
> Hello Antonio, LKML!
>
> On Tue, Nov 16, 2004 at 08:43:22PM +0800, Antonino A. Daplas wrote:
> > On Tuesday 16 November 2004 15:55, Philipp Matthias Hahn wrote:
> > > 2.6.10-rc2 on Debian i586 crashed during startup.
>
> ...
>
> > Try rc1-mm5, rc2-mm1 or apply this particular changeset:
> >
> > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.10-rc1
> >/2.6.10-rc1-mm5/broken-out/fbdev-allow-mode-change-even-if-edid-block-is-n
> >ot-found.patch
>
> That fixed the crash, but the screen looks very broken on my notebook
> after boot. Switching between XFree86 and SavageFB also locked up the
> kernel hard.

Try booting at the native resolution of your notebook, for example:

video=savagefb:1024x768@60

Tony

2004-11-16 21:47:11

by Antonino A. Daplas

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2 SAVAGEFB startup crash

On Wednesday 17 November 2004 01:27, Philipp Matthias Hahn wrote:
> Hello Antonio, LKML!
>
> On Tue, Nov 16, 2004 at 08:43:22PM +0800, Antonino A. Daplas wrote:
> > On Tuesday 16 November 2004 15:55, Philipp Matthias Hahn wrote:

> after boot. Switching between XFree86 and SavageFB also locked up the

As for the lockup between X and the console, can you try this patch?

Tony

diff -Nru a/drivers/video/savage/savagefb.c b/drivers/video/savage/savagefb.c
--- a/drivers/video/savage/savagefb.c 2004-11-11 07:58:25 +08:00
+++ b/drivers/video/savage/savagefb.c 2004-11-17 05:40:47 +08:00
@@ -1797,23 +1797,23 @@
switch (info->fix.accel) {
case FB_ACCEL_SUPERSAVAGE:
par->chip = S3_SUPERSAVAGE;
- snprintf (info->fix.id, 16, "S3 SuperSavage");
+ snprintf (info->fix.id, 16, "SuperSavage");
break;
case FB_ACCEL_SAVAGE4:
par->chip = S3_SAVAGE4;
- snprintf (info->fix.id, 16, "S3 Savage4");
+ snprintf (info->fix.id, 16, "Savage4");
break;
case FB_ACCEL_SAVAGE3D:
par->chip = S3_SAVAGE3D;
- snprintf (info->fix.id, 16, "S3 Savage3D");
+ snprintf (info->fix.id, 16, "Savage3D");
break;
case FB_ACCEL_SAVAGE3D_MV:
par->chip = S3_SAVAGE3D;
- snprintf (info->fix.id, 16, "S3 Savage3D-MV");
+ snprintf (info->fix.id, 16, "Savage3D-MV");
break;
case FB_ACCEL_SAVAGE2000:
par->chip = S3_SAVAGE2000;
- snprintf (info->fix.id, 16, "S3 Savage2000");
+ snprintf (info->fix.id, 16, "Savage2000");
break;
case FB_ACCEL_SAVAGE_MX_MV:
par->chip = S3_SAVAGE_MX;
@@ -1878,7 +1878,8 @@
info->fbops = &savagefb_ops;
info->flags = FBINFO_DEFAULT |
FBINFO_HWACCEL_YPAN |
- FBINFO_HWACCEL_XPAN;
+ FBINFO_HWACCEL_XPAN |
+ FBINFO_MISC_MODESWITCHLATE;

info->pseudo_palette = par->pseudo_palette;

2004-11-17 11:55:34

by Philipp Matthias Hahn

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2 SAVAGEFB startup crash

Hello!

On Wed, Nov 17, 2004 at 05:20:58AM +0800, Antonino A. Daplas wrote:
> > That fixed the crash, but the screen looks very broken on my notebook
> > after boot. Switching between XFree86 and SavageFB also locked up the
> > kernel hard.
>
> Try booting at the native resolution of your notebook, for example:
>
> video=savagefb:1024x768@60

The "@60" did it. (Reading "man 4x savage" -> "UseBIOS" gives my the
impression, that this is important for some mobile chips.)

On Wed, Nov 17, 2004 at 05:43:02AM +0800, Antonino A. Daplas wrote:
> > after boot. Switching between XFree86 and SavageFB also locked up the
>
> As for the lockup between X and the console, can you try this patch?
...
> - FBINFO_HWACCEL_XPAN;
> + FBINFO_HWACCEL_XPAN |
> + FBINFO_MISC_MODESWITCHLATE;

That (partly) solved the lockup: I was able start XFree86, switch back
to Console, but on return to X11, the X11 screen wasn't restored
correctly, the mouse left a trail behind and switching to console
again didn't work. (a remove "chvt 1" as root still worked). Exiting
and than restarting XFree86 sometimes didn't initialize the screen
correctly.

While writing this email, my notebook locked up again hard and I had to
powercycle it.

BYtE
Philipp
--
/ / (_)__ __ ____ __ Philipp Hahn
/ /__/ / _ \/ // /\ \/ /
/____/_/_//_/\_,_/ /_/\_\ [email protected]

2004-11-17 15:55:38

by Andrew Walrond

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2

On Monday 15 Nov 2004 02:49, Linus Torvalds wrote:
>
> Antonino Daplas:
...
> o fbdev: Fix IO access in rivafb

FYI

changeset 1.2563 breaks the rivafb for x86_64 (64bit). I'm looking into it
with the fbdev guys help, so I'm sure a fix will be forthcoming soon.

Andrew Walrond

2004-11-17 17:02:22

by Vladimir B. Savkin

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2 OOPS on boot with 3ware + reiserfs

Nov 17 18:19:18 behemoth kernel: arq->state 2
Nov 17 18:19:18 behemoth kernel: Badness in as_requeue_request at drivers/block/as-iosched.c:1478
Nov 17 18:19:18 behemoth kernel: [dump_stack+23/32] dump_stack+0x17/0x20
Nov 17 18:19:18 behemoth kernel: [as_requeue_request+102/224] as_requeue_request+0x66/0xe0
Nov 17 18:19:18 behemoth kernel: [elv_requeue_request+38/80] elv_requeue_request+0x26/0x50
Nov 17 18:19:18 behemoth kernel: [blk_insert_request+171/176] blk_insert_request+0xab/0xb0
Nov 17 18:19:18 behemoth kernel: [scsi_queue_insert+100/160] scsi_queue_insert+0x64/0xa0
Nov 17 18:19:18 behemoth kernel: [scsi_softirq+164/192] scsi_softirq+0xa4/0xc0
Nov 17 18:19:18 behemoth kernel: [__do_softirq+184/208] __do_softirq+0xb8/0xd0
Nov 17 18:19:18 behemoth kernel: [do_softirq+53/64] do_softirq+0x35/0x40
Nov 17 18:19:18 behemoth kernel: [do_IRQ+33/48] do_IRQ+0x21/0x30
Nov 17 18:19:18 behemoth kernel: [common_interrupt+26/32] common_interrupt+0x1a/0x20
Nov 17 18:19:18 behemoth kernel: [search_by_key+2122/4688] search_by_key+0x84a/0x1250
Nov 17 18:19:18 behemoth kernel: [reiserfs_update_sd_size+159/512] reiserfs_update_sd_size+0x9f/0x200
Nov 17 18:19:18 behemoth kernel: [reiserfs_dirty_inode+116/144] reiserfs_dirty_inode+0x74/0x90
Nov 17 18:19:18 behemoth kernel: [reiserfs_submit_file_region_for_write+541/656] reiserfs_submit_file_region_for_write+0x21d/0x290
Nov 17 18:19:18 behemoth kernel: [reiserfs_file_write+1453/1856] reiserfs_file_write+0x5ad/0x740
Nov 17 18:19:18 behemoth kernel: [do_readv_writev+364/544] do_readv_writev+0x16c/0x220
Nov 17 18:19:18 behemoth kernel: [vfs_writev+73/96] vfs_writev+0x49/0x60
Nov 17 18:19:18 behemoth kernel: [sys_writev+65/112] sys_writev+0x41/0x70
Nov 17 18:19:18 behemoth kernel: [syscall_call+7/11] syscall_call+0x7/0xb

~
:wq
With best regards,
Vladimir Savkin.

2004-11-17 19:36:36

by Andrew Walrond

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2 start_udev very slow

I noticed that when upgrading from 2.6.8.1 to rc2, start_udev now takes 10-15s
after printing

"Creating initial udev device nodes:"

Any known reason? should I upgrade udev? (030 installed)

Andrew Walrond

2004-11-17 23:17:12

by Greg KH

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2 start_udev very slow

On Wed, Nov 17, 2004 at 07:32:47PM +0000, Andrew Walrond wrote:
> I noticed that when upgrading from 2.6.8.1 to rc2, start_udev now takes 10-15s
> after printing
>
> "Creating initial udev device nodes:"
>
> Any known reason? should I upgrade udev? (030 installed)

Well, 045 is the latest version, so 030 is a bit old :)

thanks,

greg k-h

2004-11-17 23:21:21

by Eyal Lebedinsky

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2 [dvb-bt8xx unload oops]

I now can say that this problem does not show with rc2-mm1.

--
Eyal Lebedinsky ([email protected]) <http://samba.org/eyal/>

2004-11-18 16:21:23

by Bill Davidsen

[permalink] [raw]

Subject: Re: [Alsa-devel] Re: Linux 2.6.10-rc2

Takashi Iwai wrote:
> At Mon, 15 Nov 2004 16:16:31 -0500,
> Lee Revell wrote:
>
>>Please report ALSA issues to [email protected]. I have
>>added them to the cc:.
>
>
> The attached patch should fix this.
>
>
> Takashi
>
> ==
> Summary: [ALSA] fix sleep in atomic during prepare callback
>
> Fixed the sleep in spinlock during prepare callback.
> This happened only on Nforce chips.
>
> Signed-off-by: Takashi Iwai <[email protected]>
>
> --- linux/sound/pci/intel8x0.c 15 Nov 2004 14:19:52 -0000 1.173
> +++ linux/sound/pci/intel8x0.c 16 Nov 2004 09:41:47 -0000
> @@ -1020,7 +1020,9 @@ static void snd_intel8x0_setup_pcm_out(i
> */
> if (cnt & ICH_PCM_246_MASK) {
> iputdword(chip, ICHREG(GLOB_CNT), cnt & ~ICH_PCM_246_MASK);
> + spin_unlock_irq(&chip->reg_lock);
> msleep(50); /* grrr... */
> + spin_lock_irq(&chip->reg_lock);
> }
> } else if (chip->device_type == DEVICE_INTEL_ICH4) {
> if (runtime->sample_bits > 16)

Might this make it into 2.6.10?

--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

2004-11-18 17:38:02

by Vladimir B. Savkin

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2

On Sun, Nov 14, 2004 at 06:49:04PM -0800, Linus Torvalds wrote:
>
> Ok, the -rc2 changes are almost as big as the -rc1 changes, and we should
> now calm down, so I do not want to see anything but bug-fixes until 2.6.10
> is released. Otherwise we'll never get there.

Please accept this fix:

[PATCH] fix posix_locks_deadlock().

"blocked_list" may contain both leases and flock locks. Since the latter in
particular do not initialize the fl_owner field, we have to beware not to
call posix_same_owner() on them.

Signed-off-by: Trond Myklebust <[email protected]>
---
locks.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)

Index: linux-2.6.9-rc2-up/fs/locks.c
===================================================================
--- linux-2.6.9-rc2-up.orig/fs/locks.c 2004-09-19 13:55:33.680258334 -0700
+++ linux-2.6.9-rc2-up/fs/locks.c 2004-09-19 15:37:32.595634679 -0700
@@ -634,14 +634,13 @@
int posix_locks_deadlock(struct file_lock *caller_fl,
struct file_lock *block_fl)
{
- struct list_head *tmp;
+ struct file_lock *fl;

next_task:
if (posix_same_owner(caller_fl, block_fl))
return 1;
- list_for_each(tmp, &blocked_list) {
- struct file_lock *fl = list_entry(tmp, struct file_lock, fl_link);
- if (posix_same_owner(fl, block_fl)) {
+ list_for_each_entry(fl, &blocked_list, fl_link) {
+ if (IS_POSIX(fl) && posix_same_owner(fl, block_fl)) {
fl = fl->fl_next;
block_fl = fl;
goto next_task;

~
:wq
With best regards,
Vladimir Savkin.

2004-11-18 18:03:38

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2

On Thu, 18 Nov 2004, Vladimir B. Savkin wrote:
>
> Please accept this fix:
>
> [PATCH] fix posix_locks_deadlock().
>
> "blocked_list" may contain both leases and flock locks. Since the latter in
> particular do not initialize the fl_owner field, we have to beware not to
> call posix_same_owner() on them.

Nope. It got fixed differently: by only adding POSIX locks to the list.
See locks_insert_block(). Since a non-posix lock cannot be blocked by a
POSIX lock, the "if (IS_POSIX(blocker))" test should make sure we're
always proper.

At least that's Willy claims. If you think he's wrong, holler.

Willy Cc'd, once more.

Linus
----
> Signed-off-by: Trond Myklebust <[email protected]>
> ---
> locks.c | 7 +++----
> 1 files changed, 3 insertions(+), 4 deletions(-)
>
> Index: linux-2.6.9-rc2-up/fs/locks.c
> ===================================================================
> --- linux-2.6.9-rc2-up.orig/fs/locks.c 2004-09-19 13:55:33.680258334 -0700
> +++ linux-2.6.9-rc2-up/fs/locks.c 2004-09-19 15:37:32.595634679 -0700
> @@ -634,14 +634,13 @@
> int posix_locks_deadlock(struct file_lock *caller_fl,
> struct file_lock *block_fl)
> {
> - struct list_head *tmp;
> + struct file_lock *fl;
>
> next_task:
> if (posix_same_owner(caller_fl, block_fl))
> return 1;
> - list_for_each(tmp, &blocked_list) {
> - struct file_lock *fl = list_entry(tmp, struct file_lock, fl_link);
> - if (posix_same_owner(fl, block_fl)) {
> + list_for_each_entry(fl, &blocked_list, fl_link) {
> + if (IS_POSIX(fl) && posix_same_owner(fl, block_fl)) {
> fl = fl->fl_next;
> block_fl = fl;
> goto next_task;
>
> ~
> :wq
> With best regards,
> Vladimir Savkin.
>

2004-11-18 23:19:52

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

Chris,

Please apply this debug patch and boot with
apic=debug acpi_dbg_level=1

If the disabled floppy hardware doesn't cause the floppy.c
to hang the system, (or if running Linus' recent floppy.c
update, if the floppy.c doesn't nuke IRQ6) then please
send me the dmesg.

Then try with apic=debug pci=routeirq and capture that dmesg.

If the patch makes no functional difference, then please
add pci=routeirq to the cmdline above and send me that dmesg.

apic=debug
enables print_PIC() so we can see what the BIOS gave us,
and what we do to the PIC.

acpi_dbg_level=1
will prevent ACPI from blindly disabling the
PCI Interrupt Link Devices, which I'm guessing
may be confusing the BIOS on this box.

if you can send me the acpidmp and lspci -vv for
this box, that would help too.

thanks,
-Len

Attachments:

debug.patch (1.05 kB)

2004-11-18 18:20:58

by Matthew Wilcox

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2

On Thu, Nov 18, 2004 at 09:59:00AM -0800, Linus Torvalds wrote:
> Nope. It got fixed differently: by only adding POSIX locks to the list.
> See locks_insert_block(). Since a non-posix lock cannot be blocked by a
> POSIX lock, the "if (IS_POSIX(blocker))" test should make sure we're
> always proper.
>
> At least that's Willy claims. If you think he's wrong, holler.
>
> Willy Cc'd, once more.

The problem certainly should have been fixed. I'd like to know if it
still occurs.

--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain

2004-11-19 07:09:57

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

* Len Brown ([email protected]) wrote:
> Chris,
>
> Please apply this debug patch and boot with
> apic=debug acpi_dbg_level=1

Len, unfortunately the disk drive went south on my laptop. So testing
will take a bit longer as I piece things back together.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

2004-11-19 08:43:53

by Vladimir B. Savkin

[permalink] [raw]

Subject: Re: Linux 2.6.10-rc2

On Thu, Nov 18, 2004 at 06:01:00PM +0000, Matthew Wilcox wrote:
> On Thu, Nov 18, 2004 at 09:59:00AM -0800, Linus Torvalds wrote:
> > Nope. It got fixed differently: by only adding POSIX locks to the list.
> > See locks_insert_block(). Since a non-posix lock cannot be blocked by a
> > POSIX lock, the "if (IS_POSIX(blocker))" test should make sure we're
> > always proper.
> >
> > At least that's Willy claims. If you think he's wrong, holler.
> >
> > Willy Cc'd, once more.
>
> The problem certainly should have been fixed. I'd like to know if it
> still occurs.
>

It does not, thank you.

~
:wq
With best regards,
Vladimir Savkin.

2004-11-19 13:48:21

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Thu, Nov 18, 2004 at 06:14:46PM -0500, Len Brown wrote:

> Chris,

Hi Len,

I have the same problem Chris has.

> Please apply this debug patch and boot with
> apic=debug acpi_dbg_level=1
>...

It doesn't compile since I don't have APIC support enabled.

> thanks,
> -Len
>...

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2004-11-20 09:03:49

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

Please try this updated debug patch.

It clears the ELCR on Linux boot.

Also, it prints out the ICH PIRQ registers which
are the hardware underlying the ACPI PCI Interrupt Links.
It no longer depends on IOAPIC support in the kernel,
nor the apic=debug flag.

Please boot it with no kernel parameters
and report if it makes the floppy probe failure
(or 8042 probe failure) go away, and send dmesg.

If it still fails, please boot it with pci=routeirq
and capture the dmesg; also boot it with
acpi_dbg_level=1 and capture the dmesg.
The former will program all the links
before device probe, the later will
cause the kernel to skip disabling
the links and skip clearning the ELCR.

thanks,
-Len

ps. what I think is happening...

To its credit, he BIOS correctly recognizes that there is
no floppy, and it routes a PIRQ to IRQ6. It correctly sets the
ELCR bit for this IRQ.

Linux boots and disables all the PCI Interrupt Links,
which un-programs the PIRQ directed to IRQ6.

However, Linux doesn't clear the ELCR first,
and for some reason that causes an interrupt
to latch in IRQ6 -- though it is masked.

Along comes the broken floppy driver before
the PCI devices probe. floppy
doesn't realize there is no hardware and
unwittingly does a request_irq(6).

Since nobody is camped on IRQ6, this exclusive
request succeeds, IRQ6 is unmasked and the
floppy driver takes the outstaning interrupt.
For some reason it is unable to clear the IRQ.
I don't think it is because the line is being
driven by the PIRQ, that is disabled. It may
have something to do with the ELCR still
being set to level senstive for this IRQ.

So this hangs the system, or with Linus'
update to floppy.c, it nukes IRQ6.

I'm hopeful that with a cleared ELCR, the
misguided legacy floppy probe will work
as it always has, and floppy will then
unload so the PCI device can later claim
IRQ6 and program the link and the ELCR
accordingly.

I do believe that Linux should continue to disable
the PCI Interrupt Links at boot and enable them
only on demand. We used to leave them
all enabled and on some systems that caused
spurious interrupts, duplicated interrupts,
and all kinds of crazy things.

Note if the floppy driver had not requested
IRQ6, then a PCI device would have requested it,
the link would be programmed, and ELCR would
be set (redundant), and the interrupt unmasked.
The device would take the initial interrupt,
it would clear it successfully, and run normally
from then on.

Attachments:

debug.patch (4.52 kB)

2004-11-20 12:40:41

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Sat, Nov 20, 2004 at 04:02:04AM -0500, Len Brown wrote:

> Please try this updated debug patch.
>
> It clears the ELCR on Linux boot.
>
> Also, it prints out the ICH PIRQ registers which
> are the hardware underlying the ACPI PCI Interrupt Links.
> It no longer depends on IOAPIC support in the kernel,
> nor the apic=debug flag.
>
> Please boot it with no kernel parameters
> and report if it makes the floppy probe failure
> (or 8042 probe failure) go away, and send dmesg.
>...

With your patch, the boot failure goes away.
This was with a kernel without Linus' patch applied.

desg is below.

> thanks,
> -Len
>...

cu
Adrian

BTW: Is all what ACPI does really required, if all I need ACPI for is to
turn the power off after halting my computer?

Linux version 2.6.10-rc2 ([email protected]) (gcc version 3.4.2 (Debian 3.4.2-3)) #2 Sat Nov 20 13:20:42 CET 2004
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000000fff0000 (usable)
BIOS-e820: 000000000fff0000 - 000000000fff8000 (ACPI data)
BIOS-e820: 000000000fff8000 - 0000000010000000 (ACPI NVS)
BIOS-e820: 00000000fec00000 - 00000000fec01000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
BIOS-e820: 00000000ffee0000 - 00000000fff00000 (reserved)
BIOS-e820: 00000000fffc0000 - 0000000100000000 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65520
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 61424 pages, LIFO batch:14
HighMem zone: 0 pages, LIFO batch:1
DMI 2.3 present.
... PIC IMR: fffb
... PIC IRR: 0001
... PIC ISR: 0000
... PIC ELCR: 0c68
PIRQA -> IRQ15 disabled
PIRQB -> IRQ15 disabled
PIRQC -> IRQ15 disabled
PIRQD -> IRQ15 disabled
PIRQE -> IRQ15 disabled
PIRQF -> IRQ15 disabled
PIRQG -> IRQ15 disabled
PIRQH -> IRQ15 disabled
ACPI: RSDP (v000 AMI ) @ 0x000fab70
ACPI: RSDT (v001 AMIINT SiS740XX 0x00001000 MSFT 0x0100000b) @ 0x0fff0000
ACPI: FADT (v001 AMIINT SiS740XX 0x00000011 MSFT 0x0100000b) @ 0x0fff0030
ACPI: MADT (v001 AMIINT SiS740XX 0x00001000 MSFT 0x0100000b) @ 0x0fff00c0
ACPI: DSDT (v001 SiS 746 0x00000100 MSFT 0x0100000d) @ 0x00000000
Built 1 zonelists
Kernel command line: BOOT_IMAGE=test ro root=301 mode=1280x1024@760
Initializing CPU#0
CPU 0 irqstacks, hard=c0466000 soft=c0465000
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 1800.276 MHz processor.
Using tsc for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 255340k/262080k available (2365k kernel code, 6172k reserved, 942k data, 144k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 3563.52 BogoMIPS (lpj=1781760)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0383fbff c1c3fbff 00000000 00000000
CPU: After vendor identify, caps: 0383fbff c1c3fbff 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After all inits, caps: 0383fbff c1c3fbff 00000000 00000020
CPU: AMD Athlon(tm) XP 2200+ stepping 01
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
clear ELCR
... PIC IMR: fffa
... PIC IRR: 0000
... PIC ISR: 0000
... PIC ELCR: 0000
PIRQA -> IRQ15 disabled
PIRQB -> IRQ15 disabled
PIRQC -> IRQ15 disabled
PIRQD -> IRQ15 disabled
PIRQE -> IRQ15 disabled
PIRQF -> IRQ15 disabled
PIRQG -> IRQ15 disabled
PIRQH -> IRQ15 disabled
ACPI: IRQ9 SCI: Edge set to Level Trigger.
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfdb31, last bus=2
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20041105
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
LENB: ACPI has not touched Links yet
... PIC IMR: fdfa
... PIC IRR: 0000
... PIC ISR: 0000
... PIC ELCR: 0200
PIRQA -> IRQ15 disabled
PIRQB -> IRQ15 disabled
PIRQC -> IRQ15 disabled
PIRQD -> IRQ15 disabled
PIRQE -> IRQ15 disabled
PIRQF -> IRQ15 disabled
PIRQG -> IRQ15 disabled
PIRQH -> IRQ15 disabled
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
Uncovering SIS963 that hid as a SIS503 (compatible=0)
Enabling SiS 96x SMBus.
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: Power Resource [URP1] (off)
ACPI: Power Resource [URP2] (off)
ACPI: Power Resource [FDDP] (off)
ACPI: Power Resource [LPTP] (off)
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
_DISabled
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
_DISabled
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
_DISabled
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 *6 7 10 11 12 14 15)
_DISabled
ACPI: PCI Interrupt Link [LNKE] (IRQs *3 4 5 6 7 10 11 12 14 15)
_DISabled
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 *5 6 7 10 11 12 14 15)
_DISabled
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
_DISabled
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 *10 11 12 14 15)
_DISabled
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
... PIC IMR: fdfa
... PIC IRR: 0c68
... PIC ISR: 0000
... PIC ELCR: 0200
PIRQA -> IRQ15 disabled
PIRQB -> IRQ15 disabled
PIRQC -> IRQ15 disabled
PIRQD -> IRQ15 disabled
PIRQE -> IRQ15 disabled
PIRQF -> IRQ15 disabled
PIRQG -> IRQ15 disabled
PIRQH -> IRQ15 disabled
** PCI interrupts are no longer routed automatically. If this
** causes a device to stop working, it is probably because the
** driver failed to call pci_enable_device(). As a temporary
** workaround, the "pci=routeirq" argument restores the old
** behavior. If this argument makes the device work again,
** please email the output of "lspci" to [email protected]
** so I can fix the driver.
... PIC IMR: fdfa
... PIC IRR: 0c68
... PIC ISR: 0000
... PIC ELCR: 0200
PIRQA -> IRQ15 disabled
PIRQB -> IRQ15 disabled
PIRQC -> IRQ15 disabled
PIRQD -> IRQ15 disabled
PIRQE -> IRQ15 disabled
PIRQF -> IRQ15 disabled
PIRQG -> IRQ15 disabled
PIRQH -> IRQ15 disabled
NTFS driver 2.1.22 [Flags: R/O].
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retreived PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=155.00 Mhz, System=155.00 MHz
radeonfb: PLL min 12000 max 35000
radeonfb: Monitor 1 type DFP found
radeonfb: EDID probed
radeonfb: Monitor 2 type no found
Console: switching to colour frame buffer device 160x64
radeonfb: ATI Radeon QY DDR SGRAM 64 MB
lp: driver loaded but no devices found
Real Time Clock Driver v1.12
Non-volatile memory driver v1.2
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected SiS 746 chipset
agpgart: Maximum main memory to use for agp memory: 203M
agpgart: AGP aperture is 64M @ 0xd0000000
ACPI: PCI interrupt 0000:01:00.0[A] -> GSI 11 (level, low) -> IRQ 11
[drm] Initialized radeon 1.11.0 20020828 on minor 0: ATI Technologies Inc Radeon RV100 QY [Radeon 7000/VE]
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP]
parport0: irq 7 detected
lp0: using parport0 (polling).
io scheduler noop registered
io scheduler cfq registered
elevator: using cfq as default io scheduler
floppy0: no floppy controllers found
loop: loaded (max 8 devices)
sis900.c: v1.08.07 11/02/2003
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 6
PCI: setting IRQ 6 as level-triggered
ACPI: PCI interrupt 0000:00:04.0[A] -> GSI 6 (level, low) -> IRQ 6
eth0: Realtek RTL8201 PHY transceiver found at address 1.
eth0: Using transceiver found at address 1 as default
eth0: SiS 900 PCI Fast Ethernet at 0xdc00, IRQ 6, 00:00:00:00:00:00.
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
SIS5513: IDE controller at PCI slot 0000:00:02.5
SIS5513: chipset revision 0
SIS5513: not 100% native mode: will probe irqs later
SIS5513: SiS 962/963 MuTIOL IDE UDMA133 controller
ide0: BM-DMA at 0xff00-0xff07, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xff08-0xff0f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
hda: SAMSUNG SV1604N, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: LITE-ON LTR-12101B, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 1024KiB
hda: 312581808 sectors (160041 MB) w/2048KiB Cache, CHS=19457/255/63, UDMA(100)
hda: cache flushes supported
hda: hda1 hda2 hda3 hda4
hdc: ATAPI 32X CD-ROM CD-R/RW drive, 2048kB Cache, DMA
Uniform CD-ROM driver Revision: 3.20
ACPI: PCI Interrupt Link [LNKH] enabled at IRQ 10
PCI: setting IRQ 10 as level-triggered
ACPI: PCI interrupt 0000:00:03.2[D] -> GSI 10 (level, low) -> IRQ 10
ehci_hcd 0000:00:03.2: Silicon Integrated Systems [SiS] USB 2.0 Controller
ehci_hcd 0000:00:03.2: irq 10, pci mem 0xcffff000
ehci_hcd 0000:00:03.2: new USB bus registered, assigned bus number 1
PCI: cache line size of 64 is not supported by device 0000:00:03.2
ehci_hcd 0000:00:03.2: USB 2.0 initialized, EHCI 1.00, driver 26 Oct 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 6 ports detected
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard on isa0060/serio0
input: ImPS/2 Generic Wheel Mouse on isa0060/serio1
i2c /dev entries driver
Advanced Linux Sound Architecture Driver Version 1.0.6 (Sun Aug 15 07:17:53 2004 UTC).
ACPI: PCI interrupt 0000:00:0c.0[A] -> GSI 11 (level, low) -> IRQ 11
ALSA device list:
#0: Ensoniq AudioPCI ENS1371 at 0xd800, irq 11
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
ip_conntrack version 2.1 (2047 buckets, 16376 max) - 176 bytes per conntrack
ip_tables: (C) 2000-2002 Netfilter core team
NET: Registered protocol family 1
NET: Registered protocol family 17
... PIC IMR: 20f8
... PIC IRR: 00a8
... PIC ISR: 0000
... PIC ELCR: 0e40
PIRQA -> IRQ15 disabled
PIRQB -> IRQ15 disabled
PIRQC -> IRQ15 disabled
PIRQD -> IRQ15 disabled
PIRQE -> IRQ15 disabled
PIRQF -> IRQ15 disabled
PIRQG -> IRQ15 disabled
PIRQH -> IRQ15 disabled
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 144k freed
Adding 987988k swap on /dev/hda2. Priority:-1 extents:1
eth0: Media Link On 10mbps half-duplex
agpgart: Found an AGP 2.0 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode
agpgart: SiS delay workaround: giving bridge time to recover.
agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode

2004-11-20 16:41:55

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Sat, 20 Nov 2004, Len Brown wrote:
>
> It clears the ELCR on Linux boot.

I think this is _really_ wrong.

Basically, you're screwing up more and more PIC state.

Len, the PIC was _correct_ before ACPI touched it. We don't want to touch
it MORE, we want to touch it LESS.

I'll try this for debugging, but what I want to figure out is where ACPI
is doing something it shouldn't be doing, and _removing_ that.

We already had one patch where people tried to hide this problem by adding
more code. Clearly, that patch was bogus. Yes, it hid the problem for
floppies, but as shown by my other case (and as I was trying to say from
the beginning), it's not about floppies. It's about _any_ non-PCI
interrupt that apparently ACPI has done something _wrong_ for.

So ACPI seems to assume that all interrupts are PCI interrupts, and that's
just totally wrong. Clearing ELCR is more of this total wrongness. ELCR
exists for a reason, namely that not all interrupts are PCI.

Also, you seem to still totally concentrate on PIRQ routing etc. Totally
ignoring the fact that the problematic cases are about interrupts that
have _nothing_ to do with PCI. Not the floppy, not the PS/2 mouse. NOT
PCI! They're both on the southbridge behind a very special interface that
may or may not look like a PCI bus internally, but might quite as well be
something totally special-case (ie a perfectly normal case is that
somebody literally just bolted an old 8042 controller core into the system
and set up special case magic irq routing).

> ps. what I think is happening...
>
> To its credit, he BIOS correctly recognizes that there is
> no floppy, and it routes a PIRQ to IRQ6. It correctly sets the
> ELCR bit for this IRQ.
>
> Linux boots and disables all the PCI Interrupt Links,
> which un-programs the PIRQ directed to IRQ6.

And this is what I think is the bug. There is no reason to disable the PCI
interrupt link unless you have a damn good reason to do so.

> However, Linux doesn't clear the ELCR first,
> and for some reason that causes an interrupt
> to latch in IRQ6 -- though it is masked.
>
> Along comes the broken floppy driver before
> the PCI devices probe. floppy
> doesn't realize there is no hardware and
> unwittingly does a request_irq(6).

You are totally ignoring my other bug report which was for a (existing)
PSAUX mouse driver on irq12.

If I had had a mouse on that port, it would not have worked.

So the fact is, ACPI does something WRONG.

Linus

2004-11-20 18:28:53

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Sat, 20 Nov 2004, Adrian Bunk wrote:
>
> With your patch, the boot failure goes away.
> This was with a kernel without Linus' patch applied.

It boots for me too, but it all seems pretty accidental.

In particular, the code will disable irq12 (mouse interrupt), so the mouse
has no chance of working. Having tested it, it so happens that if I boot
with a mouse actually conntected, the BIOS will not use irq12 for PCI
devices, so that will hide the problem since ACPI won't try to disable it
when it doesn't see it.

But if I had more PCI devices, or another legacy device that doesn't have
the same kind of "test if something is connected" logic, it really looks
like it would break again. (It's entirely possible that Windows has the
exact same issue, of course, at which point it's fairly safe to say that
manufacturers will have tested this and just not done it, but I don't feel
all that safe making that assumption).

So I think the simpler fix is just this one-liner: we should not disable
preexisting links, because non-PCI devices may depend on the same routing
information, and thus the comments about "being activated on use" is not
actually true.

Linus

===== drivers/acpi/pci_link.c 1.34 vs edited =====
--- 1.34/drivers/acpi/pci_link.c 2004-11-01 23:40:09 -08:00
+++ edited/drivers/acpi/pci_link.c 2004-11-20 09:43:56 -08:00
@@ -685,9 +685,6 @@
acpi_link.count++;

end:
- /* disable all links -- to be activated on use */
- acpi_ut_evaluate_object(link->handle, "_DIS", 0, NULL);
-
if (result)
kfree(link);

2004-11-20 19:12:33

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Sat, 20 Nov 2004, Linus Torvalds wrote:
>
> In particular, the code will disable irq12 (mouse interrupt), so the mouse
> has no chance of working.

Btw, looking closer still, this all will most likely vary wildly according
to southbridge (and BIOS setups). At least some SB's seem to put the
legacy interrupts totally separately from the PIRQ stuff, in which case
the PIRQ disable will not matter one whit - the legacy interrupt is
inserted "after" the PIRQ gating/translation anyway. This seems to be
especially common for controllers for keyboard/mouse/i2c etc that are
actually on the southbridge itself.

But the basic notion remains: disabling a PIRQ line is valid only if you
know it's only used by PCI devices. There might be other special devices
on the board that don't show up as PCI devices, eg things like the Sony
programmable I/O thing that doesn't show up as a PCI device at all, it's
just "invisibly" connected to the bus (it just hijacks port 0x66 or
something - the range 0-0x3ff is generally reserved for "motherboard
devices").

These kinds of things hopefully aren't all that common (there can't be a
lot of extra hw required to follow the PCI spec _properly_), but if I were
a hw designer, I'd connect such a chip to the PIRQ input, and just make
the BIOS enable it automatically.

Linus

2004-11-21 16:35:18

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Sat, Nov 20, 2004 at 10:28:27AM -0800, Linus Torvalds wrote:
>...
> So I think the simpler fix is just this one-liner: we should not disable
> preexisting links, because non-PCI devices may depend on the same routing
> information, and thus the comments about "being activated on use" is not
> actually true.

I can confirm this patch fixes the problem for me in an otherwise
unmodified 2.6.10-rc2.

> Linus
>
> ===== drivers/acpi/pci_link.c 1.34 vs edited =====
> --- 1.34/drivers/acpi/pci_link.c 2004-11-01 23:40:09 -08:00
> +++ edited/drivers/acpi/pci_link.c 2004-11-20 09:43:56 -08:00
> @@ -685,9 +685,6 @@
> acpi_link.count++;
>
> end:
> - /* disable all links -- to be activated on use */
> - acpi_ut_evaluate_object(link->handle, "_DIS", 0, NULL);
> -
> if (result)
> kfree(link);

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2004-11-22 18:33:49

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Sat, 2004-11-20 at 07:40, Adrian Bunk wrote:
> On Sat, Nov 20, 2004 at 04:02:04AM -0500, Len Brown wrote:
>
> > Please try this updated debug patch.
> >
> > It clears the ELCR on Linux boot.

> With your patch, the boot failure goes away.
> This was with a kernel without Linus' patch applied.

Thanks for running this test Adrian.

>
> BTW: Is all what ACPI does really required, if all I need ACPI for is
> to turn the power off after halting my computer?

On this system ACPI is required to configure the IOAPIC.

It may be possible to save power in idle with c-states
and at run-time with p-states (cpufreq) on this box,
but I couldn't tell that from the dmesg if CONFIG_ACPI_PROCESSOR
was included or not.

If you don't care about interrupt performance and you don't
mind pressing the power button when you halt the system,
go ahead and run with CONFIG_ACPI=n.

cheers,
-Len

2004-11-22 19:13:33

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Sat, 2004-11-20 at 11:41, Linus Torvalds wrote:
>
> On Sat, 20 Nov 2004, Len Brown wrote:
> >
> > It clears the ELCR on Linux boot.
>
> I think this is _really_ wrong.
>
> Basically, you're screwing up more and more PIC state.
>
> Len, the PIC was _correct_ before ACPI touched it. We don't want to
> touch it MORE, we want to touch it LESS.
>
> I'll try this for debugging, but what I want to figure out is where
> ACPI is doing something it shouldn't be doing, and _removing_ that.
>
> We already had one patch where people tried to hide this problem by
> adding more code. Clearly, that patch was bogus. Yes, it hid the
> problem for floppies, but as shown by my other case (and as I was
> trying to say from the beginning), it's not about floppies. It's about
> _any_ non-PCI interrupt that apparently ACPI has done something
> _wrong_ for.

I agree that the system should work properly even if the legacy device
drivers are broken. Please understand, however, that the legacy device
drivers _are_ broken. The BIOS via ACPI clearly tells them if the
devices are present or not, and Linux isn't yet listening.

> So ACPI seems to assume that all interrupts are PCI interrupts, and
> that's just totally wrong. Clearing ELCR is more of this total
> wrongness. ELCR exists for a reason, namely that not all interrupts
> are PCI.

ACPI-compliant systems have three types of interrupts:
1. legacy
2. PCI
3. the ACPI SCI

The first two are described in the DSDT legacy devices and _PRT,
respectively. The third is described in the FADT. The MADT overrides
are available to handle any special cases, though that applies only to
IOAPIC mode.

If there are other interrupts, then it isn't an ACPI-compliant system
and it the BIOS should not enable ACPI. If the BIOS erroneously enables
ACPI on such a system, the workaround is to boot with acpi=off. I'd be
extremly interested to know of such a system, as I've not yet
encountered one.

> Also, you seem to still totally concentrate on PIRQ routing etc.
> Totally ignoring the fact that the problematic cases are about
> interrupts that have _nothing_ to do with PCI. Not the floppy, not the
> PS/2 mouse. NOT PCI! They're both on the southbridge behind a very
> special interface that may or may not look like a PCI bus internally,
> but might quite as well be something totally special-case (ie a
> perfectly normal case is that somebody literally just bolted an old
> 8042 controller core into the system and set up special case magic irq
> routing).

If somebody bolts motherboard hardware on and doesn't tell ACPI about
it, then they need to disable ACPI, which _owns_ configuration of
motherboard devices when it is enabled.

The problem at hand has everything to do with PCI interrupts, and how
they can conflict with legacy interrupts.

PIC hardware is level-HIGH sensitive, it cannot be programmed like
APIC INTIN's can. The only way to effectively use it as level-LOW
sensitive such as that supplied by PCI devices, it so attach those
interrupts sources through inverters. This is what the PIRQ routers
do. I printed out the underlying PIRQ routers for the ICH in
the debug patch because all of the failures at hand seemed
to be in ICH systems and these registers tell us the state
not of the abstract PCI Interrupt link, but of the actual hardware that
can be driving that (legacy) interrupt input.

> > ps. what I think is happening...
> >
> > To its credit, he BIOS correctly recognizes that there is
> > no floppy, and it routes a PIRQ to IRQ6. It correctly sets the
> > ELCR bit for this IRQ.
> >
> > Linux boots and disables all the PCI Interrupt Links,
> > which un-programs the PIRQ directed to IRQ6.
>
> And this is what I think is the bug. There is no reason to disable the
> PCI interrupt link unless you have a damn good reason to do so.

The damn good reason is that doing otherwise breaks systems.
This is the cset comment for the line of code disabling the links:

ChangeSet 1.1608.11.11 2004/06/17 23:21:03 [email protected]
[ACPI] avoid spurious interrupts on VIA
http://bugzilla.kernel.org/show_bug.cgi?id=2243
drivers/acpi/pci_link.c 1.28.1.1 2004/06/11 10:38:46 [email protected]
disable all PCI Interrupt Links to be enabled by _SRS

It would sure make my life easier if we didn't support
these VIA/Phoenix systems, but I don't think that breaking
them is what the community wants.

> > However, Linux doesn't clear the ELCR first,
> > and for some reason that causes an interrupt
> > to latch in IRQ6 -- though it is masked.
> >
> > Along comes the broken floppy driver before
> > the PCI devices probe. floppy
> > doesn't realize there is no hardware and
> > unwittingly does a request_irq(6).
>
> You are totally ignoring my other bug report which was for a
> (existing) PSAUX mouse driver on irq12.
>
> If I had had a mouse on that port, it would not have worked.
>
> So the fact is, ACPI does something WRONG.

The PS2 IRQ12 situation is exactly the same as the IRQ6 floppy
situation. If the mouse or floppy were present, the BIOS would not have
given that interrupt to PCI.

-Len

2004-11-22 19:39:12

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Sat, 2004-11-20 at 13:28, Linus Torvalds wrote:
>
> On Sat, 20 Nov 2004, Adrian Bunk wrote:
> >
> > With your patch, the boot failure goes away.
> > This was with a kernel without Linus' patch applied.
>
> It boots for me too, but it all seems pretty accidental.
>
> In particular, the code will disable irq12 (mouse interrupt), so the
> mouse has no chance of working. Having tested it, it so happens that
> if I boot with a mouse actually conntected, the BIOS will not use
> irq12 for PCI devices, so that will hide the problem since ACPI won't
> try to disable it when it doesn't see it.

This is not an accident that is being hidden by mistake.
The BIOS probes for the legacy mouse.

If it finds one, it gives it IRQ12.
If it doesn't find one it gives IRQ12 to PCI.

Other BIOS's are not as good as these and they don't give the free IRQs
to PCI. Sub-optimal, but perfectly legal.

Exact same situation Chris and Adrian see with the floppy and IRQ6.
Exact same situation could potentially be seen with any motherboard
device and any IRQ -- except, of course, those that can't be probed or
are otherwise hard-coded for well known legacy devices, such as the RTC
on IRQ8.

> But if I had more PCI devices, or another legacy device that doesn't
> have the same kind of "test if something is connected" logic, it
> really looks like it would break again. (It's entirely possible that
> Windows has the exact same issue, of course, at which point it's
> fairly safe to say that manufacturers will have tested this and just
> not done it, but I don't feel all that safe making that assumption).

Windows uses ACPI to probe the legacy motherboard devices, and ACPI uses
what the BIOS finds. If the BIOS and ACPI don't know about the
motherboard device, then it isn't an ACPI system and among other
failures, it would never have got a nifty Made for Windows sticker, and
thus would have market penetration of approximately 0.

Linux is just now learning to use ACPI for probing legacy motherboard
devices. I believe that this transition can be made safely and that
legacy probes should continue to work both during and after the
transition.

> So I think the simpler fix is just this one-liner: we should not
> disable preexisting links, because non-PCI devices may depend on the
> same routing information, and thus the comments about "being activated
> on use" is not actually true.
>

> Linus
>
> ===== drivers/acpi/pci_link.c 1.34 vs edited =====
> --- 1.34/drivers/acpi/pci_link.c 2004-11-01 23:40:09 -08:00
> +++ edited/drivers/acpi/pci_link.c 2004-11-20 09:43:56 -08:00
> @@ -685,9 +685,6 @@
> acpi_link.count++;
>
> end:
> - /* disable all links -- to be activated on use */
> - acpi_ut_evaluate_object(link->handle, "_DIS", 0, NULL);
> -
> if (result)
> kfree(link);

This is not a fix, it will break systems in the field.

When we enable a link, we must set the ELCR.
When we disable a link, we must clear the ELCR.
We need to be able to enable and disable all links in the system.

The bug was that while we were were setting the ELCR
when we enabled a link, we were not clearing it when we disabled one.

We also have an issue when we move the destiation of a link,
though we don't do that very often.

My debug patch cleared every bit in the ELCR even if no PCI interrupt
link device pointed to that entry. Yes, this assumes that ACPI knows
about every level triggered interrupt in the system.

I think that is a valid assumption on an ACPI-compliant system.

But if you're more comfortable with disabling the associated ELCR bit
only when we disable links directed at that entry, we can do that too.
The complication with that approach is that links are many to one, so
clearing the bit without disabling all links directed to that entry
would result in a failure. Also, the SCI uses the ELCR too, and it
isn't described by links at all.

-Len

2004-11-22 19:35:53

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Mon, 22 Nov 2004, Len Brown wrote:
>
> I agree that the system should work properly even if the legacy device
> drivers are broken. Please understand, however, that the legacy device
> drivers _are_ broken. The BIOS via ACPI clearly tells them if the
> devices are present or not, and Linux isn't yet listening.

I really disagree.

I realize that you like ACPI, or you would have shot yourself long long
ago.

But I have a totally different view on things. To me, firmware is not
something cool to be used. It's a necessary evil, and it should be avoided
and mistrusted as far as humanly possible, because it is always buggy, and
we can't fix the bugs in it.

Yes, the current ACPI layer in the kernel is a lot better at working
around the bugs, and it's getting to the point where I suspect Linux
vendors actually decide that enabing ACPI by default causes fewer problems
than it solves. That clearly didn't use to be true.

> ACPI-compliant systems have three types of interrupts:

Stop right there.

"ACPI-compliant systems". The fact is, there is no such thing. There are
systems that users buy, and they are not "ACPI compliant", they are "one
implementation of ACPI that was tested with a single vendor usage test".

Call me cynical, but I believe in standards papers just about as much as I
believe in the voices in my attic that tell me to kill the Queen of
England.

Papers is so much dead trees. The only thing that matters is real life.
And like it or not, real life does NOT implement standards properly, even
if the standards are well written and unambiguous (which also doesn't
actually happen in real life).

> If somebody bolts motherboard hardware on and doesn't tell ACPI about
> it, then they need to disable ACPI, which _owns_ configuration of
> motherboard devices when it is enabled.

No. The only thing that owns the motherboard is the user. ACPI shouldn't
get uppity.

> The damn good reason is that doing otherwise breaks systems.

And not doing it breaks systems.

See a pattern?

This is why I don't trust firmware. It's always buggy.

Linus

2004-11-22 19:59:31

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Sat, 2004-11-20 at 14:10, Linus Torvalds wrote:
>
> On Sat, 20 Nov 2004, Linus Torvalds wrote:
> >
> > In particular, the code will disable irq12 (mouse interrupt), so the
> mouse
> > has no chance of working.
>
> Btw, looking closer still, this all will most likely vary wildly
> according to southbridge (and BIOS setups). At least some SB's seem to
> put the legacy interrupts totally separately from the PIRQ stuff, in
> which case the PIRQ disable will not matter one whit - the legacy
> interrupt is inserted "after" the PIRQ gating/translation anyway. This
> seems to be especially common for controllers for keyboard/mouse/i2c
> etc that are actually on the southbridge itself.

Right, programming a PIRQ router to an IRQ doesn't mean that a legacy
device isn't still attached to that IRQ.

> But the basic notion remains: disabling a PIRQ line is valid only if
> you know it's only used by PCI devices. There might be other special
> devices on the board that don't show up as PCI devices, eg things like
> the Sony programmable I/O thing that doesn't show up as a PCI device
> at all, it's just "invisibly" connected to the bus (it just hijacks
> port 0x66 or something - the range 0-0x3ff is generally reserved for
> "motherboard devices").

> These kinds of things hopefully aren't all that common (there can't be
> a lot of extra hw required to follow the PCI spec _properly_), but if
> I were a hw designer, I'd connect such a chip to the PIRQ input, and
> just make the BIOS enable it automatically.

While there may be non-standard non-PCI legacy devices that
(erroneously) use PIRQ routers on legacy systms, that isn't the issue at
hand.

The issue at hand is what to do in ACPI mode.

ACPI PCI Interrupt Link Devices, by definition, are used only by PCI
devices, or devices that look like them. You look up the device in the
_PRT by its devid. Although links are often implemented underneath by
PIRQ routers, they are much more general. ACPI PCI Interrupt Links can
specificy any trigger/polarity, as well as connect to IOAPIC inputs.

If there is "special" hardware using an ACPI PCI Interrupt Link without
being listed in the DSDT _PRT that describes the link, then the BIOS is
simply broken.

-Len

2004-11-22 20:14:05

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Mon, 22 Nov 2004, Linus Torvalds wrote:
>
> This is exactly what you are already doing with SCI, thanks to
> "acpi_pic_sci_set_trigger()", no?
>
> So I'm really suggesting that instead of disabling the PCI irq routing, it
> should do exactly the same thing that SCI already does. Namely make sure
> that ELCR is set correctly for it.

In fact, we would even use the same function for it (the only thing that
makes it SCI-specific right now is the "printk()" that says "SCI IRQ", the
rest really is totally generic.

So how about renaming "acpi_pic_sci_set_trigger()" to not have the "sci"
part in there, and remove it's dependence on CONFIG_ACPI_BUS, and just
using it in "apic_pci_link_add()" to make sure that any PCI links we find
to be enabled have the right ELCR. That's _logical_, since if we were to
actually enable them, we'd set ELCR right. So literally the only
difference between disabling them at boot (and then re-enabling them when
a driver finds them) _is_ that ELCR setting..

And that would make me much happier, because it's a "minimally intrusive"
thing to do.

Linus

2004-11-22 20:10:41

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Mon, 22 Nov 2004, Len Brown wrote:
>
> Windows uses ACPI to probe the legacy motherboard devices, and ACPI uses
> what the BIOS finds. If the BIOS and ACPI don't know about the
> motherboard device, then it isn't an ACPI system and among other
> failures, it would never have got a nifty Made for Windows sticker, and
> thus would have market penetration of approximately 0.

One thing that matters is definitely "how does Windows do things", because
that's what has been tested. However, "Windows" clearly does not use ACPI
for all enumeration, since there are different versions of Windows, and
some of them don't (and some of them very much don't boot on all hardware
either).

In other words, Linux actually needs to be _more_ careful than Windows,
because it's supposed to just magically work on pretty much anything out
there. Nasty. So "what windows does" can never be anything but a hint on
what kind of functionality has ever been tested.

> When we enable a link, we must set the ELCR.
> When we disable a link, we must clear the ELCR.
> We need to be able to enable and disable all links in the system.
>
> The bug was that while we were were setting the ELCR
> when we enabled a link, we were not clearing it when we disabled one.

Fair enough. That may be a good fix too, but so far I can see the bug on a
system I actually have access to, and my one-liner fixes it in a
fundamentally more acceptable manner than any other patch I've seen.

Why? Because _not_ touching things is the other thing that _has_ been
tested on machines, ie mb manufacturers actually tend to test things that
have no ACPI knowledge at all, still. DOS comes to mind, but so do pretty
much all other operating systems.

Because of that, there's this dichtonomy: you either do everything exactly
like Windows does things, or you try very carefully to do the minimal
amount of untrusted accesses possible. Linux ends up mixing the two
approaches as best it can.

But feel free to send me a patch that doesn't just clear ELCR totally, but
clears the bits we are disabling. I just don't believe in the "let's just
clear everything" approach. In particular, I don't have the same kind of
"ACPI will provide" belief in higher powers that you seem to have.

> But if you're more comfortable with disabling the associated ELCR bit
> only when we disable links directed at that entry, we can do that too.
> The complication with that approach is that links are many to one, so
> clearing the bit without disabling all links directed to that entry
> would result in a failure. Also, the SCI uses the ELCR too, and it
> isn't described by links at all.

Wouldn't it be nicer to take the _reverse_ approach: let's assume that any
PCI interrupts that we have already enabled are fine and should not be
disabled? Mark them in the ELCR, and _report_ when the ELCR seems to be
incorrect (let's make a wild guess here, and realize that the screaming
VIA interrupts you talk about are exactly because the ELCR was wrong).

This is exactly what you are already doing with SCI, thanks to
"acpi_pic_sci_set_trigger()", no?

So I'm really suggesting that instead of disabling the PCI irq routing, it
should do exactly the same thing that SCI already does. Namely make sure
that ELCR is set correctly for it.

So in "acpi_pci_link_add()", when you find a link that is enabled, add a
call to make sure that it is set to level triggered in the ELCR. That's
not even ACPI-specific, now we're talking fundamental PCI behaviour, so
the likelihood of that being wrong is pretty low, no?

That seems like a _safe_ thing to do.

Linus

2004-11-22 20:26:21

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Mon, 2004-11-22 at 14:23, Linus Torvalds wrote:

> To me, firmware is not
> something cool to be used. It's a necessary evil, and it should be
> avoided and mistrusted as far as humanly possible, because it is
> always buggy, and we can't fix the bugs in it.

Mistrusting firmware is why I disabled all the links, some system
firmware didn't leave them in a self-consistent state.

Re: liking ACPI
Consider it a love/hate thing;-)

> > The damn good reason is that doing otherwise breaks systems.
>
> And not doing it breaks systems.

I'm not aware (yet) of any systems where disabling all the links (which
we've been doing since June, BTW) and clearing the entire ELCR, and then
re-enabling them both only as we use them causes a failure.

> This is why I don't trust firmware. It's always buggy.

I'm with you on that one.

-Len

2004-11-22 20:37:17

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Mon, 22 Nov 2004, Len Brown wrote:
> >
> > And not doing it breaks systems.
>
> I'm not aware (yet) of any systems where disabling all the links (which
> we've been doing since June, BTW)

We have been doing it since June, but we also immediately _re-enabled_
them.

And the moment we _didn't_ re-enable them, people started sending in
bug-reports. So the "since June" is clearly true only in a very limited
sense.

A more correct way to say it would be that within hours of releasing a
test-kernel (not even a real release) that _really_ disabled the links, we
got people reporting boot failures.

> and clearing the entire ELCR, and then re-enabling them both only as we
> use them causes a failure.

Now, the clearing the entire ELCR thing has been tested by all of three
people, all of whom saw problems with the non-clearing thing. So not only
is the base for that claim very thin indeed, the small base was totally
self-selected, ie statistically completely meaningless even if it had
been much much larger.

Nobody who didn't actually see the problem in the first place would have
tested it.

IOW, I'll claim that the only thing that has really gotten testing since
June is the thing that disables and immediately re-enables the links.

And that's exactly why I think the "minimally disruptive" fix is to not
disable them at all, but just fix up ELCR for anything that was already
enabled. Since that _is_ what "disable + re-enable" ends up actually
doing.

See my argument?

Linus

2004-11-22 20:42:39

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Mon, 22 Nov 2004, Linus Torvalds wrote:
>
> And that's exactly why I think the "minimally disruptive" fix is to not
> disable them at all, but just fix up ELCR for anything that was already
> enabled. Since that _is_ what "disable + re-enable" ends up actually
> doing.

Oh, and I think one alternative at this point is obviously to just go back
to the "re-enable all interrupts early in the boot" code. Clearly we need
to do _something_ for 2.6.10, and I want it to be something that is pretty
much equivalent to what we _do_ have testing coverage of. Just to keep
safe.

I actually _like_ the "enable links only when needed" thing, which is why
I'd prefer to look for alternatives. But I like even more not having to
worry about strange hw setups, so "minimal fixing" really is pretty
important.

Linus

2004-11-22 20:42:40

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Mon, 2004-11-22 at 15:02, Linus Torvalds wrote:
>
> On Mon, 22 Nov 2004, Len Brown wrote:
> >
> > When we enable a link, we must set the ELCR.
> > When we disable a link, we must clear the ELCR.
> > We need to be able to enable and disable all links in the system.
> >
> > The bug was that while we were were setting the ELCR
> > when we enabled a link, we were not clearing it when we disabled
> one.
>
> Fair enough. ...

> But feel free to send me a patch that doesn't just clear ELCR totally,
> but clears the bits we are disabling. I just don't believe in the
> "let's just clear everything" approach.

Will do.

>
> > But if you're more comfortable with disabling the associated ELCR
> bit> only when we disable links directed at that entry, we can do that
> too.
> > The complication with that approach is that links are many to one,
> so
> > clearing the bit without disabling all links directed to that entry
> > would result in a failure. Also, the SCI uses the ELCR too, and it
> > isn't described by links at all.
>
> Wouldn't it be nicer to take the _reverse_ approach: let's assume that
> any PCI interrupts that we have already enabled are fine and should
> not be disabled? Mark them in the ELCR, and _report_ when the ELCR
> seems to be incorrect (let's make a wild guess here, and realize that
> the screaming VIA interrupts you talk about are exactly because the
> ELCR was wrong).

I think the VIA case is more complicated than that, but I'll take
another look at it.

thanks,
-Len

2004-11-22 20:59:15

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Mon, 2004-11-22 at 15:31, Linus Torvalds wrote:
>
> On Mon, 22 Nov 2004, Len Brown wrote:
> > >
> > > And not doing it breaks systems.
> >
> > I'm not aware (yet) of any systems where disabling all the links
> (which
> > we've been doing since June, BTW)
>
> We have been doing it since June, but we also immediately _re-enabled_
> them.

Mostly true.

We re-enabled all the links for which we found PCI devices.
This is a super-set of all the links with device-drivers.

But it is also a sub-set of the total population of links -- some BIOSs
enabled links for which there were no devices attached. This caused two
problems. First there were suprious interrupts on some boxes, and
second in the case where we enabling balacing IRQs (default in IOAPIC
mode, requires "acpi_irq_balance" in PIC mode) it ate up IRQs and forced
more sharing.

> IOW, I'll claim that the only thing that has really gotten testing
> since June is the thing that disables and immediately re-enables the
> links.
>
> And that's exactly why I think the "minimally disruptive" fix is to
> not disable them at all, but just fix up ELCR for anything that was
> already enabled. Since that _is_ what "disable + re-enable" ends up
> actually doing.
>
> See my argument?

"minimally distruptive" undertood, Yes.

"minimal risk", OTOH is to return to what we did in 2.6.9.

Note, for the record, that Bjorn's patch to remove the paranoia loop and
add the pci=routeirq override came to you through the -mm tree, not
through the ACPI tree. I think that Bjorn was as surprised as I was
that it appeared in 2.6.10-rc2.

-Len

2004-11-22 21:01:59

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Mon, 2004-11-22 at 15:36, Linus Torvalds wrote:
>
> Oh, and I think one alternative at this point is obviously to just go
> back to the "re-enable all interrupts early in the boot" code. Clearly
> we need to do _something_ for 2.6.10, and I want it to be something
> that is pretty much equivalent to what we _do_ have testing coverage
> of. Just to keep safe.

I'm okay with this, and testing the interrupt fixes in -mm in the
mean-time -- particularly if you're planning a relatively short 2.6.10
rc cycle.

-Len

2004-11-23 00:48:17

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Mon, Nov 22, 2004 at 01:28:59PM -0500, Len Brown wrote:
>...
> > BTW: Is all what ACPI does really required, if all I need ACPI for is
> > to turn the power off after halting my computer?
>
> On this system ACPI is required to configure the IOAPIC.
>
> It may be possible to save power in idle with c-states
> and at run-time with p-states (cpufreq) on this box,
> but I couldn't tell that from the dmesg if CONFIG_ACPI_PROCESSOR
> was included or not.

It's not.

> If you don't care about interrupt performance and you don't
> mind pressing the power button when you halt the system,
> go ahead and run with CONFIG_ACPI=n.

Not needed "pressing the power button when you halt the system" is the
"killer application" for using ACPI for me...

> cheers,
> -Len

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2004-11-23 01:12:37

[permalink] [raw]

Subject: why use ACPI (Re: 2.6.10-rc2 doesn't boot (if no floppy device))

On Mon, 2004-11-22 at 19:46, Adrian Bunk wrote:

> Not needed "pressing the power button when you halt the system" is the
> "killer application" for using ACPI for me...

Yes, thats certainly one that people notice right away. Laptops have
had soft poweroff with APM for a while, but desktops and servers never
adopted APM, so soft-power-off is generally a new feature with ACPI for
them.

Enabling IOAPIC is one that a lot of people like, because it results in
less interrupt sharing and better performance than PIC mode. But if you
don't load your system much you may not notice any difference.

Next people tend to notice fan speed, because they can hear it.
If you load processor and thermal, you'll probably see some
/proc/acpi/thermal/thermal_zone/*/temperature and you'll
probably find that it stays lower if you keep processor
loaded versus when you do not.

This is usually because of power-saving c-csates in idle,
which you can observe in /proc/acpi/processor/*/power
and the higher the C-state, the more power you save.

Also, CPUFREQ usually often on ACPI, and that can save
power even when the system is not idle, and this results
in lower temperatures and hopefully slower fan speeds.

cheers,
-Len

2004-11-23 01:28:41

by Dave Jones

[permalink] [raw]

Subject: Re: why use ACPI (Re: 2.6.10-rc2 doesn't boot (if no floppy device))

On Mon, Nov 22, 2004 at 08:07:36PM -0500, Len Brown wrote:

> Laptops have had soft poweroff with APM for a while, but desktops and
> servers never adopted APM, so soft-power-off is generally a new feature
> with ACPI for them.

Nonsense.

My 4-way compaq server disagrees with you. No ACPI on that
at all, and it has fully working APM, even in SMP. Likewise,
I don't think I've ever seen a desktop without APM.
(modulo broken biosen).

IIRC, APM supported this since the arrival of ATX power supplies,
which was a _long_ time ago. 1996/1997 ?

Dave

2004-11-23 01:45:39

[permalink] [raw]

Subject: Re: why use ACPI (Re: 2.6.10-rc2 doesn't boot (if no floppy device))

On Mon, Nov 22, 2004 at 08:07:36PM -0500, Len Brown wrote:
> On Mon, 2004-11-22 at 19:46, Adrian Bunk wrote:
>
> > Not needed "pressing the power button when you halt the system" is the
> > "killer application" for using ACPI for me...
>
> Yes, thats certainly one that people notice right away. Laptops have
> had soft poweroff with APM for a while, but desktops and servers never
> adopted APM, so soft-power-off is generally a new feature with ACPI for
> them.

That's wrong.

My old desktop computer (with a VIA MVP3 chipset and an AMD K6 cpu)
I bought in 1998 did power off fine under Linux using APM.

> Enabling IOAPIC is one that a lot of people like, because it results in
> less interrupt sharing and better performance than PIC mode. But if you
> don't load your system much you may not notice any difference.

I saw

kernel: APIC error on CPU0: 00(02)
...
kernel: APIC error on CPU0: 02(02)

on my computer and decided disabling APIC was the easiest way to solve
them...

> Next people tend to notice fan speed, because they can hear it.
> If you load processor and thermal, you'll probably see some
> /proc/acpi/thermal/thermal_zone/*/temperature and you'll
> probably find that it stays lower if you keep processor
> loaded versus when you do not.

/proc/acpi/thermal/thermal_zone is empty on my computer.

> This is usually because of power-saving c-csates in idle,
> which you can observe in /proc/acpi/processor/*/power
> and the higher the C-state, the more power you save.

active state: C1
default state: C1
bus master activity: 00000000
states:
*C1: promotion[--] demotion[--] latency[000] usage[00000000]
C2: <not supported>
C3: <not supported>

> Also, CPUFREQ usually often on ACPI, and that can save
> power even when the system is not idle, and this results
> in lower temperatures and hopefully slower fan speeds.

My computer has a desktop Athlon...

> cheers,
> -Len

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2004-11-23 01:53:35

[permalink] [raw]

Subject: Re: why use ACPI (Re: 2.6.10-rc2 doesn't boot (if no floppy device))

On Mon, Nov 22, 2004 at 08:23:33PM -0500, Dave Jones wrote:
>...
> I don't think I've ever seen a desktop without APM.
> (modulo broken biosen).
>...

For my old computer (bought 1998) this was true.

Unfortunately, my new computer (bought early this year) says:
kernel: apm: BIOS not found.

I don't know whether it's a hardware problem or "only" a BIOS problem,
but it forces me to use ACPI to power off my computer. :-(

> Dave

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

2004-11-23 02:00:41

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

For the record...

* Len Brown ([email protected]) wrote:
> Please try this updated debug patch.
>
> It clears the ELCR on Linux boot.

This boots as expected (no irq6 storm). I have dmesg if you're still
interested.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

2004-11-23 02:06:22

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

Also for the record...

* Linus Torvalds ([email protected]) wrote:
> So I think the simpler fix is just this one-liner: we should not disable
> preexisting links, because non-PCI devices may depend on the same routing
> information, and thus the comments about "being activated on use" is not
> actually true.

This boots as expected (no irq6 storm).

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

2004-11-23 02:06:32

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

For the record...

* Len Brown ([email protected]) wrote:
> Please apply this debug patch and boot with
> apic=debug acpi_dbg_level=1

acpi_dbg_level=1 boots as expected. w/out it, irq6 interrupt storm.
I have dmesg if you're still interested.

thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net

2004-11-23 02:51:26

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Mon, 22 Nov 2004, Len Brown wrote:
>
> I think the VIA case is more complicated than that, but I'll take
> another look at it.

Ok, having looked at the bugzilla entry, I have to concur. Looks like we
do need to disable the PCI interrupts and re-enable them. Mea culpa.

So what's the right way to get ELCR into a useful state? I'm starting to
lean towards your "just clear it all" after all, but that does the wrong
thing for SCI (which is _usually_ level-triggered), and I worry that there
are other cases too.

Any reasonably simple patch that likely gets it right?

Linus

2004-11-23 02:56:17

by Dave Jones

[permalink] [raw]

Subject: Re: why use ACPI (Re: 2.6.10-rc2 doesn't boot (if no floppy device))

On Mon, Nov 22, 2004 at 09:47:32PM -0500, Len Brown wrote:
> > > Also, CPUFREQ usually often on ACPI, and that can save
> > > power even when the system is not idle, and this results
> > > in lower temperatures and hopefully slower fan speeds.
> >
> > My computer has a desktop Athlon...
>
> maybe Dave can determine if there is a governor that can help you.
>
> cheers,
> -Len

desktop athlons tend not to have powernow. And those that do
(usually by someone transplanting a mobile part into a desktop
board), hit the problem where the BIOS has no idea what the
hell is going on, and sets up no PST tables.

Dave

2004-11-23 03:05:38

[permalink] [raw]

Subject: Re: why use ACPI (Re: 2.6.10-rc2 doesn't boot (if no floppy device))

On Mon, 2004-11-22 at 20:37, Adrian Bunk wrote:
> On Mon, Nov 22, 2004 at 08:07:36PM -0500, Len Brown wrote:
> > On Mon, 2004-11-22 at 19:46, Adrian Bunk wrote:

>
> My old desktop computer (with a VIA MVP3 chipset and an AMD K6 cpu)
> I bought in 1998 did power off fine under Linux using APM.

I stand corrected. ACPI wasn't widely deployed until 1998, so I expect
everything at that time was APM. grepping my logs for more modern
systems, I see APM still in many of the laptops, about half the
desktops, and none of the servers -- YMMV.

> > Enabling IOAPIC is one that a lot of people like, because it results
> in
> > less interrupt sharing and better performance than PIC mode. But if
> you
> > don't load your system much you may not notice any difference.
>
> I saw
>
> kernel: APIC error on CPU0: 00(02)
> ...
> kernel: APIC error on CPU0: 02(02)
>
> on my computer and decided disabling APIC was the easiest way to solve
> them...

yup, this is common on some hardware.

Frankly, I don't know if it is something to be concerned about if you
don't see it that much, but if the hardware loses interrupts when the
IOAPIC is enabled, then disabling it is a reasonable workaround.

> > Next people tend to notice fan speed, because they can hear it.
> > If you load processor and thermal, you'll probably see some
> > /proc/acpi/thermal/thermal_zone/*/temperature and you'll
> > probably find that it stays lower if you keep processor
> > loaded versus when you do not.
>
> /proc/acpi/thermal/thermal_zone is empty on my computer.
>
> > This is usually because of power-saving c-csates in idle,
> > which you can observe in /proc/acpi/processor/*/power
> > and the higher the C-state, the more power you save.
>
> active state: C1
> default state: C1
> bus master activity: 00000000
> states:
> *C1: promotion[--] demotion[--] latency[000]
> usage[00000000]
> C2: <not supported>
> C3: <not supported>
>

You'll get C1 even without ACPI, so ACPI processor driver doesn't give
you any additional power savings c-states on this hardware.

> > Also, CPUFREQ usually often on ACPI, and that can save
> > power even when the system is not idle, and this results
> > in lower temperatures and hopefully slower fan speeds.
>
> My computer has a desktop Athlon...

maybe Dave can determine if there is a governor that can help you.

cheers,
-Len

2004-11-23 03:16:39

by Gene Heskett

[permalink] [raw]

Subject: Re: why use ACPI (Re: 2.6.10-rc2 doesn't boot (if no floppy device))

On Monday 22 November 2004 21:50, Dave Jones wrote:
>On Mon, Nov 22, 2004 at 09:47:32PM -0500, Len Brown wrote:
> > > > Also, CPUFREQ usually often on ACPI, and that can save
> > > > power even when the system is not idle, and this results
> > > > in lower temperatures and hopefully slower fan speeds.
> > >
> > > My computer has a desktop Athlon...
> >
> > maybe Dave can determine if there is a governor that can help
> > you.
> >
> > cheers,
> > -Len
>
>desktop athlons tend not to have powernow. And those that do
>(usually by someone transplanting a mobile part into a desktop
> board), hit the problem where the BIOS has no idea what the
>hell is going on, and sets up no PST tables.
>
> Dave
>
A link to a neat util was posted earlier today, to 'gcccpuopt', which
scans things and reports the appropriate options to put in the
Makefile. But it doesn't even contain the 'powernow' string. Does
this need updated?

--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.29% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.

2004-11-23 05:04:15

[permalink] [raw]

Subject: Re: 2.6.10-rc2 doesn't boot (if no floppy device)

On Mon, 22 Nov 2004, Linus Torvalds wrote:
>
> So what's the right way to get ELCR into a useful state? I'm starting to
> lean towards your "just clear it all" after all, but that does the wrong
> thing for SCI (which is _usually_ level-triggered), and I worry that there
> are other cases too.
>
> Any reasonably simple patch that likely gets it right?

Len, how about this patch - it re-enables the link disable and then
re-codes the ELCR setting to match.

Basically it just computes the new ELCR: if acpi_noirq is set, it leaves
it at the old value, otherwise it zeroes it - and in both cases it fixes
the SCI entry.

Your argument for doing this ended up being convincing, so the only
difference between this and your debug patch is really just the obvious
organizational ones, and the test for "acpi_noirq", which I think is
needed (since if acpi_noirq is set, we're not going to disable and
re-enable the PCI interrupts, so we'll just have to trust ELCR).

Linus

----
===== arch/i386/kernel/acpi/boot.c 1.75 vs edited =====
--- 1.75/arch/i386/kernel/acpi/boot.c 2004-11-11 16:08:40 -08:00
+++ edited/arch/i386/kernel/acpi/boot.c 2004-11-22 20:55:57 -08:00
@@ -409,28 +409,38 @@
void __init
acpi_pic_sci_set_trigger(unsigned int irq, u16 trigger)
{
- unsigned char mask = 1 << (irq & 7);
- unsigned int port = 0x4d0 + (irq >> 3);
- unsigned char val = inb(port);
+ unsigned int mask = 1 << irq;
+ unsigned int old, new;

-
- printk(PREFIX "IRQ%d SCI:", irq);
- if (!(val & mask)) {
- printk(" Edge");
+ /* Real old ELCR mask */
+ old = inb(0x4d0) | (inb(0x4d1) << 8);

- if (trigger == 3) {
- printk(" set to Level");
- outb(val | mask, port);
- }
- } else {
- printk(" Level");
+ /*
+ * If we use ACPI to set PCI irq's, then we should clear ELCR
+ * since we will set it correctly as we enable the PCI irq
+ * routing.
+ */
+ new = acpi_noirq ? old : 0;

- if (trigger == 1) {
- printk(" set to Edge");
- outb(val & ~mask, port);
- }
+ /*
+ * Update SCI information in the ELCR, it isn't in the PCI
+ * routing tables..
+ */
+ switch (trigger) {
+ case 1: /* Edge - clear */
+ new &= ~mask;
+ break;
+ case 3: /* Level - set */
+ new |= mask;
+ break;
}
- printk(" Trigger.\n");
+
+ if (old == new)
+ return;
+
+ printk(PREFIX "setting ELCR to %04x (from %04x)\n", new, old);
+ outb(new, 0x4d0);
+ outb(new >> 8, 0x4d1);
}

===== drivers/acpi/pci_link.c 1.35 vs edited =====
--- 1.35/drivers/acpi/pci_link.c 2004-11-22 10:41:11 -08:00
+++ edited/drivers/acpi/pci_link.c 2004-11-22 20:02:53 -08:00
@@ -685,6 +685,9 @@
acpi_link.count++;

end:
+ /* disable all links -- to be activated on use */
+ acpi_ut_evaluate_object(link->handle, "_DIS", 0, NULL);
+
if (result)
kfree(link);

2004-11-23 05:01:03

by Dave Jones

[permalink] [raw]

Subject: Re: why use ACPI (Re: 2.6.10-rc2 doesn't boot (if no floppy device))

On Mon, Nov 22, 2004 at 10:13:21PM -0500, Gene Heskett wrote:

> A link to a neat util was posted earlier today, to 'gcccpuopt', which
> scans things and reports the appropriate options to put in the
> Makefile. But it doesn't even contain the 'powernow' string. Does
> this need updated?

Very likely not. What would you expect it to do ?

Dave

2004-11-23 07:08:30