Re: Problems booting 2.6.18 on SunBlade 100/150

Re: Problems booting 2.6.18 on SunBlade 100/150

[Per Øyvind Karlsen]

Torsdag 19 oktober 2006 08:38, skrev Jim Watson:
> On 19/10/2006, at 5:30 AM, David Miller wrote:
> > Are you sure you're enabling ATYFB video support in your kernel?
> > That's a common error when folks build their own kernels.
>
> Success! I used the later patch [0] and the config file from debian
> 2.6.18-1-sparc64 as mentioned by Jurij[1]
> which includes - hopefully relevant ;)
>
> CONFIG_FB_ATY128=y
> CONFIG_FB_ATY=y
> CONFIG_FB_ATY_CT=y
> # CONFIG_FB_ATY_GENERIC_LCD is not set
> CONFIG_FB_ATY_GX=y
>
> Using LCD Benq FP767 here,
>
> I could only get it it to boot this way:
>
> boot:mylinux18 video=atyfb:off
>
> which is what I need as it also gets rid of those pesky red dots ;)
>
> I am happy to report anything else that might assist...
>
> thanks to David for the patches and thanks to Jurij for guidance,
>
> jim
>
> [0] http://marc.theaimsgroup.com/?l=linux-sparc&m\x116120447318793&w=2
> [1] http://marc.theaimsgroup.com/?l=linux-sparc&m\x116120045100433&w=2
> -
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
I'm left puzzled here now, will your display work correctly when disabling 
framebuffer with 'video=atyfb:off'? And if you're disabling it, why do you 
need to compile support for it?

My experience is that I need atyfb properly working to intialize display, 
otherwise it'll boot with not display (openboot screen will stay and no linux 
output is displayed, while machine is actually booting and serial can be 
used).

Am I missing something here..? (I'm fairly new to sparc, so please have 
patience:o)
-- 
Regards,
Per Øyvind Karlsen
Mandriva

Problems booting 2.6.18 on SunBlade 100/150

[Jurij Smakov]

Hi,

We have two reports now of boot failures of 2.6.18 on SunBlade 100 and 
150. According to the reporters (who are CC'd), they see the following 
during boot:

Booting Linux...
NVRAM: Low Battery Voltage!
CLOCK: Clock was stopped. Kick start

Then machine hangs. Any ideas on how to fix it will be appreciated.

Thanks,
-- 
Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

Re: Problems booting 2.6.18 on SunBlade 100/150

[David Miller]

From: Jurij Smakov <jurij@wooyd.org>
Date: Sun, 8 Oct 2006 19:29:54 -0700

> We have two reports now of boot failures of 2.6.18 on SunBlade 100 and 
> 150. According to the reporters (who are CC'd), they see the following 
> during boot:
> 
> Booting Linux...
> NVRAM: Low Battery Voltage!
> CLOCK: Clock was stopped. Kick start
> 
> Then machine hangs. Any ideas on how to fix it will be appreciated.

It's probably a device probing regression caused by the
new in-kernel device tree code I added to 2.6.18

I'll try to hook up my SB100 and see if I can reproduce.

Re: Problems booting 2.6.18 on SunBlade 100/150

[Jurij Smakov]

On Mon, Oct 09, 2006 at 01:21:56AM -0700, David Miller wrote:
> From: Jurij Smakov <jurij@wooyd.org>
> Date: Sun, 8 Oct 2006 19:29:54 -0700
> 
> > We have two reports now of boot failures of 2.6.18 on SunBlade 100 and 
> > 150. According to the reporters (who are CC'd), they see the following 
> > during boot:
> > 
> > Booting Linux...
> > NVRAM: Low Battery Voltage!
> > CLOCK: Clock was stopped. Kick start
> > 
> > Then machine hangs. Any ideas on how to fix it will be appreciated.
> 
> It's probably a device probing regression caused by the
> new in-kernel device tree code I added to 2.6.18

Thanks to the debugging performed by Jim Watson, we have now confirmed 
that the addresses of the clock registers calculated in clock_probe()
(arch/sparc64/sparc/time.c) differ in 2.6.16 and 2.6.18. On 2.6.16 it 
gets 

mstk48t59_regs\00001ff011800000

while on 2.6.18 it's

mstk48t59_regs\00001fff1000000

More information, including prtconf output from 3 affected machines is 
available in the bug trail at

http://bugs.debian.org/392078

Best regards,
-- 
Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

Re: Problems booting 2.6.18 on SunBlade 100/150

[Jim Watson]

> (arch/sparc64/sparc/time.c) differ in 2.6.16 and 2.6.18. On 2.6.16 it
> gets
> mstk48t59_regs\00001ff011800000
>
my apologies for the extra digit, this should read:

mstk48t59_regs\00001ff01800000

Re: Problems booting 2.6.18 on SunBlade 100/150

[David Miller]

From: Jim Watson <jim@amarooas.com.au>
Date: Sun, 15 Oct 2006 14:57:58 +1000

> > (arch/sparc64/sparc/time.c) differ in 2.6.16 and 2.6.18. On 2.6.16 it
> > gets
> > mstk48t59_regs\00001ff011800000
> >
> my apologies for the extra digit, this should read:
> 
> mstk48t59_regs\00001ff01800000

Thanks for all the info.  I'll try to nail this one by the
end of the week.  I started looking at the details tonight.

Re: Problems booting 2.6.18 on SunBlade 100/150

[David Miller]

From: Jim Watson <jim@amarooas.com.au>
Date: Sun, 15 Oct 2006 14:57:58 +1000

> > (arch/sparc64/sparc/time.c) differ in 2.6.16 and 2.6.18. On 2.6.16 it
> > gets
> > mstk48t59_regs\00001ff011800000
> >
> my apologies for the extra digit, this should read:
> 
> mstk48t59_regs\00001ff01800000

Ok, I figured it out.  Please test the patch below as soon as you can,
it seems to work on my SB100.

The bug wasn't introduced by the new code in 2.6.18, rather the new
code in 2.6.18 uncovered an obscure old bug that's been with us
forever :-)

The deal is that on Hummingbird systems like SB100/SB150, the PCI
memory space is the full 32-bit 4GB range, minus the IOMMU translated
area.  In my thinking when writing the Hummingbird support code, I
believed that the IOMMU area would always be at the very top of the
4GB range, but this assumption is incorrect.

For example, the IOMMU DMA range on my SB100 is 0xc0000000 to
0xdfffffff, this means that 0xe0000000-->0xffffffff are valid PCI mem
space mapping areas for devices.  As a consequence of this mistake,
any device mapped by OBP into this upper area would be deemed an
invalid mapping by Linux.  So we'd remap that device somewhere else.

The new OBP device code in 2.6.18 assumes that any mapping created
by the OBP firmware is valid and won't get remapped by the kernel.
And this is what caused the clock to have an incorrect register
address.  If we use the PROM properties to compute the address, as
the new OBP device code does, we miss the fixup the PCI layer does
to the EBUS PCI device which determines the clock register address.
This remapping should never happen in the first place and that's
the bug.

Fix below, and some loosening of the resource conflict message
suppression so we can spot more problems like this in the future.

diff --git a/arch/sparc64/kernel/pci_common.c b/arch/sparc64/kernel/pci_common.c
index 7a59cc7..827ae30 100644
--- a/arch/sparc64/kernel/pci_common.c
+++ b/arch/sparc64/kernel/pci_common.c
@@ -330,19 +330,6 @@ #endif
 	return res;
 }
 
-static int __init pdev_resource_collisions_expected(struct pci_dev *pdev)
-{
-	if (pdev->vendor != PCI_VENDOR_ID_SUN)
-		return 0;
-
-	if (pdev->device = PCI_DEVICE_ID_SUN_RIO_EBUS ||
-	    pdev->device = PCI_DEVICE_ID_SUN_RIO_1394 ||
-	    pdev->device = PCI_DEVICE_ID_SUN_RIO_USB)
-		return 1;
-
-	return 0;
-}
-
 static void __init pdev_record_assignments(struct pci_pbm_info *pbm,
 					   struct pci_dev *pdev)
 {
@@ -400,19 +387,23 @@ static void __init pdev_record_assignmen
 		pbm->parent->resource_adjust(pdev, res, root);
 
 		if (request_resource(root, res) < 0) {
+			int rnum;
+
 			/* OK, there is some conflict.  But this is fine
 			 * since we'll reassign it in the fixup pass.
 			 *
-			 * We notify the user that OBP made an error if it
-			 * is a case we don't expect.
+			 * Do not print the warning for ROM resources
+			 * as such a conflict is quite common and
+			 * harmless as the ROM bar is disabled.
 			 */
-			if (!pdev_resource_collisions_expected(pdev)) {
-				printk(KERN_ERR "PCI: Address space collision on region %ld "
+			rnum = (res - &pdev->resource[0]);
+			if (rnum != PCI_ROM_RESOURCE)
+				printk(KERN_ERR "PCI: Resource collision, "
+				       "region %d "
 				       "[%016lx:%016lx] of device %s\n",
-				       (res - &pdev->resource[0]),
+				       rnum,
 				       res->start, res->end,
 				       pci_name(pdev));
-			}
 		}
 	}
 }
diff --git a/arch/sparc64/kernel/pci_sabre.c b/arch/sparc64/kernel/pci_sabre.c
index 6ec5698..de7f785 100644
--- a/arch/sparc64/kernel/pci_sabre.c
+++ b/arch/sparc64/kernel/pci_sabre.c
@@ -1196,7 +1196,7 @@ static void pbm_register_toplevel_resour
 					    &pbm->mem_space);
 }
 
-static void sabre_pbm_init(struct pci_controller_info *p, struct device_node *dp, u32 dma_begin)
+static void sabre_pbm_init(struct pci_controller_info *p, struct device_node *dp, u32 dma_start, u32 dma_end)
 {
 	struct pci_pbm_info *pbm;
 	struct device_node *node;
@@ -1261,6 +1261,8 @@ static void sabre_pbm_init(struct pci_co
 		node = node->sibling;
 	}
 	if (simbas_found = 0) {
+		struct resource *rp;
+
 		/* No APBs underneath, probably this is a hummingbird
 		 * system.
 		 */
@@ -1302,8 +1304,10 @@ static void sabre_pbm_init(struct pci_co
 		pbm->io_space.end   = pbm->io_space.start + (1UL << 24) - 1UL;
 		pbm->io_space.flags = IORESOURCE_IO;
 
-		pbm->mem_space.start = p->pbm_A.controller_regs + SABRE_MEMSPACE;
-		pbm->mem_space.end   = pbm->mem_space.start + (unsigned long)dma_begin - 1UL;
+		pbm->mem_space.start +			(p->pbm_A.controller_regs + SABRE_MEMSPACE);
+		pbm->mem_space.end +			(pbm->mem_space.start + ((1UL << 32UL) - 1UL));
 		pbm->mem_space.flags = IORESOURCE_MEM;
 
 		if (request_resource(&ioport_resource, &pbm->io_space) < 0) {
@@ -1315,6 +1319,17 @@ static void sabre_pbm_init(struct pci_co
 			prom_halt();
 		}
 
+		rp = kmalloc(sizeof(*rp), GFP_KERNEL);
+		if (!rp) {
+			prom_printf("Cannot allocate IOMMU resource.\n");
+			prom_halt();
+		}
+		rp->name = "IOMMU";
+		rp->start = pbm->mem_space.start + (unsigned long) dma_start;
+		rp->end = pbm->mem_space.start + (unsigned long) dma_end - 1UL;
+		rp->flags = IORESOURCE_BUSY;
+		request_resource(&pbm->mem_space, rp);
+
 		pci_register_legacy_regions(&pbm->io_space,
 					    &pbm->mem_space);
 	}
@@ -1450,5 +1465,5 @@ void sabre_init(struct device_node *dp, 
 	/*
 	 * Look for APB underneath.
 	 */
-	sabre_pbm_init(p, dp, vdma[0]);
+	sabre_pbm_init(p, dp, vdma[0], vdma[1]);
 }

Re: Problems booting 2.6.18 on SunBlade 100/150

[Jim Watson]

On 18/10/2006, at 11:56 AM, David Miller wrote:

>
> Ok, I figured it out.  Please test the patch below as soon as you can,
> it seems to work on my SB100.
>

David, thanks - I tried the patch on 2.6.18 but it still hangs up for  
me. This is not conclusive however as I could not get my build of  
2.6.16 to run either. The output from the regs remains as before.

jim

Re: Problems booting 2.6.18 on SunBlade 100/150

[Jason Wever]

[-- Attachment #1: Type: text/plain, Size: 2442 bytes --]

On Tue, 17 Oct 2006 18:56:44 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

> Ok, I figured it out.  Please test the patch below as soon as you can,
> it seems to work on my SB100.

The patch allows me to boot 2.6.18 and 2.6.19-rc2 on a Blade 100
(kernels built with gcc-4.1.1 on Gentoo).

In what may be in relation to the loosening of the resource conflict
message suppression, I see two call traces related to registering
devices in 2.6.18 that I don't recall seeing in 2.6.17 and one IRQ
handler problem  in 2.6.19-rc2.    If these aren't related, then
just ignore this part of the message :)  Errors are below:

2.6.18 errors:
kobject_add failed for isa@7 with -EEXIST, don't try to register things
with the
 same name in the same directory.
Call Trace:
 [0000000000427504] of_device_register+0x2c/0x60
 [00000000006e403c] scan_one_device+0x8b8/0x924
 [00000000006e40bc] scan_tree+0x14/0x3c
 [00000000006e40cc] scan_tree+0x24/0x3c
 [00000000006e4180] of_bus_driver_init+0x9c/0xa4
 [0000000000416a58] init+0x9c/0x28c
 [00000000004174b8] kernel_thread+0x38/0x48
 [0000000000416c60] rest_init+0x18/0x2c
/pci@1f,0/isa@7: Could not register of device.
kobject_add failed for pmu@3 with -EEXIST, don't try to register things
with the
 same name in the same directory.
Call Trace:
 [0000000000427504] of_device_register+0x2c/0x60
 [00000000006e403c] scan_one_device+0x8b8/0x924
 [00000000006e40bc] scan_tree+0x14/0x3c
 [00000000006e40cc] scan_tree+0x24/0x3c
 [00000000006e4180] of_bus_driver_init+0x9c/0xa4
 [0000000000416a58] init+0x9c/0x28c
 [00000000004174b8] kernel_thread+0x38/0x48
 [0000000000416c60] rest_init+0x18/0x2c



2.6.19-rc2 errors:
ebus0: [flashprom] [eeprom] [idprom]
power: Control reg at 1fe02000800 ... powerd running.
power: Control reg at 1fe02000800 ... powerd running.
IRQ handler type mismatch for IRQ 8
Call Trace:
 [00000000004232f4] power_probe+0xb0/0x100
 [0000000000427770] of_device_probe+0x50/0x70
 [0000000000544a6c] really_probe+0x48/0xf0
 [0000000000544c10] __driver_attach+0x44/0x68
 [000000000054411c] bus_for_each_dev+0x38/0x6c
 [0000000000544444] bus_add_driver+0x60/0x19c
 [00000000006ea814] pcibios_init+0x88/0x90
 [0000000000416a44] init+0xa8/0x298
 [0000000000417478] kernel_thread+0x38/0x48
 [0000000000416c4c] rest_init+0x18/0x2c
power: Error, cannot register IRQ handler.

Cheers,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Problems booting 2.6.18 on SunBlade 100/150

[David Miller]

From: Jim Watson <jim@amarooas.com.au>
Date: Wed, 18 Oct 2006 21:50:24 +1000

> David, thanks - I tried the patch on 2.6.18 but it still hangs up for  
> me. This is not conclusive however as I could not get my build of  
> 2.6.16 to run either. The output from the regs remains as before.

It should remain the same.

Are you sure you're enabling ATYFB video support in your kernel?
That's a common error when folks build their own kernels.

Re: Problems booting 2.6.18 on SunBlade 100/150

[David Miller]

From: Jason Wever <weeve@gentoo.org>
Date: Wed, 18 Oct 2006 06:38:04 -0600

> 2.6.18 errors:
> kobject_add failed for isa@7 with -EEXIST, don't try to register things
> with the
>  same name in the same directory.

I fixed these recently, I believe the fix for that is in 2.6.18.1

I'll look into the IRQ problems but the power device registered it's
IRQ just fine on my SB100 in current 2.6.19-GIT.

Re: Problems booting 2.6.18 on SunBlade 100/150

[Per Øyvind Karlsen]

Onsdag 18 oktober 2006 21:30, skrev David Miller:
> From: Jim Watson <jim@amarooas.com.au>
> Date: Wed, 18 Oct 2006 21:50:24 +1000
>
> > David, thanks - I tried the patch on 2.6.18 but it still hangs up for
> > me. This is not conclusive however as I could not get my build of
> > 2.6.16 to run either. The output from the regs remains as before.
>
> It should remain the same.
>
> Are you sure you're enabling ATYFB video support in your kernel?
> That's a common error when folks build their own kernels.
> -
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
I was meaning to post on this topic earlier as I hoped it was fixed in more 
recent releases, but ATYFB in kernel seems to be broken on my sb100 since 
somewhere after 2.6.17-rc3..

I have to use a serial console now, haven't done extensive debugging on it, 
but now I see the topic mentioned, what is the situation? :)
-- 
Regards,
Per Øyvind Karlsen
Mandriva

Re: Problems booting 2.6.18 on SunBlade 100/150

[Jurij Smakov]

> From: Jim Watson <jim@amarooas.com.au>
> Date: Wed, 18 Oct 2006 21:50:24 +1000
>
>> David, thanks - I tried the patch on 2.6.18 but it still hangs up for
>> me. This is not conclusive however as I could not get my build of
>> 2.6.16 to run either. The output from the regs remains as before.
>
> It should remain the same.
>
> Are you sure you're enabling ATYFB video support in your kernel?
> That's a common error when folks build their own kernels.

Jim, if you have a recent Debian's linux-image package installed, you can
just use the config Debian uses. It is installed in
/boot/config-2.6.18-1-sparc64 or something like that. Just copy it into
your build directory as .config and run 'make oldconfig'. That will
probably take a bit longer to build, but will have all the required
pieces.

I've tried to build the patched Debian packages overnight, but the build
failed for unrelated reasons. I'll try again tonight.

Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

Re: Problems booting 2.6.18 on SunBlade 100/150

[David Miller]

From: Per Øyvind Karlsen <pkarlsen@mandriva.com>
Date: Wed, 18 Oct 2006 20:36:16 +0100

> I have to use a serial console now, haven't done extensive debugging on it, 
> but now I see the topic mentioned, what is the situation? :)

Unfortunately it's working fine here on my SB100 so I can't
reproduce your problem at all.

Re: Problems booting 2.6.18 on SunBlade 100/150

[David Miller]

From: "Jurij Smakov" <jurij@wooyd.org>
Date: Wed, 18 Oct 2006 12:38:38 -0700 (PDT)

> I've tried to build the patched Debian packages overnight, but the build
> failed for unrelated reasons. I'll try again tonight.

I need to fixup the patch to take care of an error I just discovered
in it, so wait for me to send you that second before you start up
the new package builds...

Re: Problems booting 2.6.18 on SunBlade 100/150

[Per Øyvind Karlsen]

Onsdag 18 oktober 2006 21:45, skrev David Miller:
> From: Per Øyvind Karlsen <pkarlsen@mandriva.com>
> Date: Wed, 18 Oct 2006 20:36:16 +0100
>
> > I have to use a serial console now, haven't done extensive debugging on
> > it, but now I see the topic mentioned, what is the situation? :)
>
> Unfortunately it's working fine here on my SB100 so I can't
> reproduce your problem at all.
oh, too bad, I thought that it was known as you were referring to atyfb 
things, I'll try dig up some info to be provided :)
-- 
Regards,
Per Øyvind Karlsen
Mandriva

Re: Problems booting 2.6.18 on SunBlade 100/150

[Per Øyvind Karlsen]

Onsdag 18 oktober 2006 22:15, skrev Per Øyvind Karlsen:
> Onsdag 18 oktober 2006 21:45, skrev David Miller:
> > From: Per Øyvind Karlsen <pkarlsen@mandriva.com>
> > Date: Wed, 18 Oct 2006 20:36:16 +0100
> >
> > > I have to use a serial console now, haven't done extensive debugging on
> > > it, but now I see the topic mentioned, what is the situation? :)
> >
> > Unfortunately it's working fine here on my SB100 so I can't
> > reproduce your problem at all.
>
> oh, too bad, I thought that it was known as you were referring to atyfb
> things, I'll try dig up some info to be provided :)
okay, tried booting with display, got these errors:

SABRE0: Uncorrectable Error, primary error type[DMA Write:Translation Error]
SABRE0: bytemask[00ff] dword_offset[0] was_block(0)
SABRE0: UE AFAR [000000006fd7c000]
SABRE0: UE Secondary errors [(none)]
SABRE0: IOMMU Error, type[Invalid Error]
SABRE0: IOMMU TAG(3)[RAW(0000000000c6f800)error(Invalid 
Error)wr(0)sz(8K)vpg(df000000)]
SABRE0: IOMMU DATA(3)
[RAW(000000006fe379ec)valid(1)used(1)cache(0)ppg(000000006f3d8000)

makes any sense?
-- 
Regards,
Per Øyvind Karlsen
Mandriva

Re: Problems booting 2.6.18 on SunBlade 100/150

[David Miller]

From: Per Øyvind Karlsen <pkarlsen@mandriva.com>
Date: Wed, 18 Oct 2006 21:28:55 +0100

> okay, tried booting with display, got these errors:
> 
> SABRE0: Uncorrectable Error, primary error type[DMA Write:Translation Error]
> SABRE0: bytemask[00ff] dword_offset[0] was_block(0)
> SABRE0: UE AFAR [000000006fd7c000]
> SABRE0: UE Secondary errors [(none)]
> SABRE0: IOMMU Error, type[Invalid Error]
> SABRE0: IOMMU TAG(3)[RAW(0000000000c6f800)error(Invalid 
> Error)wr(0)sz(8K)vpg(df000000)]
> SABRE0: IOMMU DATA(3)
> [RAW(000000006fe379ec)valid(1)used(1)cache(0)ppg(000000006f3d8000)
> 
> makes any sense?

That's coming from a DMA transaction which your ATY video
card isn't going to do :-)

What kind of devices are in this computer?  Any add-in
network or storage PCI cards?

Re: Problems booting 2.6.18 on SunBlade 100/150

[David Miller]

From: "Jurij Smakov" <jurij@wooyd.org>
Date: Wed, 18 Oct 2006 12:38:38 -0700 (PDT)

> I've tried to build the patched Debian packages overnight, but the build
> failed for unrelated reasons. I'll try again tonight.

Jurij, please use this updated version of the patch
against 2.6.18, thanks.

[SPARC64]: Fix PCI memory space root resource on Hummingbird.

For Hummingbird PCI controllers, we should create the root
PCI memory space resource as the full 4GB area, and then
allocate the IOMMU DMA translation window out of there.

The old code just assumed that the IOMMU DMA translation base
to the top of the 4GB area was unusable.  This is not true on
many systems such as SB100 and SB150, where the IOMMU DMA
translation window sits at 0xc0000000->0xdfffffff.

So what would happen is that any device mapped by the firmware
at the top section 0xe0000000->0xffffffff would get remapped
by Linux somewhere else leading to all kinds of problems and
boot failures.

While we're here, report more cases of OBP resource assignment
conflicts.  The only truly valid ones are ROM resource conflicts.

Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/arch/sparc64/kernel/pci_common.c b/arch/sparc64/kernel/pci_common.c
index 7a59cc7..827ae30 100644
--- a/arch/sparc64/kernel/pci_common.c
+++ b/arch/sparc64/kernel/pci_common.c
@@ -330,19 +330,6 @@ #endif
 	return res;
 }
 
-static int __init pdev_resource_collisions_expected(struct pci_dev *pdev)
-{
-	if (pdev->vendor != PCI_VENDOR_ID_SUN)
-		return 0;
-
-	if (pdev->device = PCI_DEVICE_ID_SUN_RIO_EBUS ||
-	    pdev->device = PCI_DEVICE_ID_SUN_RIO_1394 ||
-	    pdev->device = PCI_DEVICE_ID_SUN_RIO_USB)
-		return 1;
-
-	return 0;
-}
-
 static void __init pdev_record_assignments(struct pci_pbm_info *pbm,
 					   struct pci_dev *pdev)
 {
@@ -400,19 +387,23 @@ static void __init pdev_record_assignmen
 		pbm->parent->resource_adjust(pdev, res, root);
 
 		if (request_resource(root, res) < 0) {
+			int rnum;
+
 			/* OK, there is some conflict.  But this is fine
 			 * since we'll reassign it in the fixup pass.
 			 *
-			 * We notify the user that OBP made an error if it
-			 * is a case we don't expect.
+			 * Do not print the warning for ROM resources
+			 * as such a conflict is quite common and
+			 * harmless as the ROM bar is disabled.
 			 */
-			if (!pdev_resource_collisions_expected(pdev)) {
-				printk(KERN_ERR "PCI: Address space collision on region %ld "
+			rnum = (res - &pdev->resource[0]);
+			if (rnum != PCI_ROM_RESOURCE)
+				printk(KERN_ERR "PCI: Resource collision, "
+				       "region %d "
 				       "[%016lx:%016lx] of device %s\n",
-				       (res - &pdev->resource[0]),
+				       rnum,
 				       res->start, res->end,
 				       pci_name(pdev));
-			}
 		}
 	}
 }
diff --git a/arch/sparc64/kernel/pci_sabre.c b/arch/sparc64/kernel/pci_sabre.c
index 4589185..f04c6d2 100644
--- a/arch/sparc64/kernel/pci_sabre.c
+++ b/arch/sparc64/kernel/pci_sabre.c
@@ -1196,7 +1196,7 @@ static void pbm_register_toplevel_resour
 					    &pbm->mem_space);
 }
 
-static void sabre_pbm_init(struct pci_controller_info *p, struct device_node *dp, u32 dma_begin)
+static void sabre_pbm_init(struct pci_controller_info *p, struct device_node *dp, u32 dma_start, u32 dma_end)
 {
 	struct pci_pbm_info *pbm;
 	struct device_node *node;
@@ -1261,6 +1261,8 @@ static void sabre_pbm_init(struct pci_co
 		node = node->sibling;
 	}
 	if (simbas_found = 0) {
+		struct resource *rp;
+
 		/* No APBs underneath, probably this is a hummingbird
 		 * system.
 		 */
@@ -1302,8 +1304,10 @@ static void sabre_pbm_init(struct pci_co
 		pbm->io_space.end   = pbm->io_space.start + (1UL << 24) - 1UL;
 		pbm->io_space.flags = IORESOURCE_IO;
 
-		pbm->mem_space.start = p->pbm_A.controller_regs + SABRE_MEMSPACE;
-		pbm->mem_space.end   = pbm->mem_space.start + (unsigned long)dma_begin - 1UL;
+		pbm->mem_space.start +			(p->pbm_A.controller_regs + SABRE_MEMSPACE);
+		pbm->mem_space.end +			(pbm->mem_space.start + ((1UL << 32UL) - 1UL));
 		pbm->mem_space.flags = IORESOURCE_MEM;
 
 		if (request_resource(&ioport_resource, &pbm->io_space) < 0) {
@@ -1315,6 +1319,17 @@ static void sabre_pbm_init(struct pci_co
 			prom_halt();
 		}
 
+		rp = kmalloc(sizeof(*rp), GFP_KERNEL);
+		if (!rp) {
+			prom_printf("Cannot allocate IOMMU resource.\n");
+			prom_halt();
+		}
+		rp->name = "IOMMU";
+		rp->start = pbm->mem_space.start + (unsigned long) dma_start;
+		rp->end = pbm->mem_space.start + (unsigned long) dma_end - 1UL;
+		rp->flags = IORESOURCE_BUSY;
+		request_resource(&pbm->mem_space, rp);
+
 		pci_register_legacy_regions(&pbm->io_space,
 					    &pbm->mem_space);
 	}
@@ -1450,5 +1465,5 @@ void sabre_init(struct device_node *dp, 
 	/*
 	 * Look for APB underneath.
 	 */
-	sabre_pbm_init(p, dp, vdma[0]);
+	sabre_pbm_init(p, dp, vdma[0], vdma[0] + vdma[1]);
 }

Re: Problems booting 2.6.18 on SunBlade 100/150

[Per Øyvind Karlsen]

Onsdag 18 oktober 2006 22:36, skrev David Miller:
> From: Per Øyvind Karlsen <pkarlsen@mandriva.com>
> Date: Wed, 18 Oct 2006 21:28:55 +0100
>
> > okay, tried booting with display, got these errors:
> >
> > SABRE0: Uncorrectable Error, primary error type[DMA Write:Translation
> > Error] SABRE0: bytemask[00ff] dword_offset[0] was_block(0)
> > SABRE0: UE AFAR [000000006fd7c000]
> > SABRE0: UE Secondary errors [(none)]
> > SABRE0: IOMMU Error, type[Invalid Error]
> > SABRE0: IOMMU TAG(3)[RAW(0000000000c6f800)error(Invalid
> > Error)wr(0)sz(8K)vpg(df000000)]
> > SABRE0: IOMMU DATA(3)
> > [RAW(000000006fe379ec)valid(1)used(1)cache(0)ppg(000000006f3d8000)
> >
> > makes any sense?
>
> That's coming from a DMA transaction which your ATY video
> card isn't going to do :-)
>
> What kind of devices are in this computer?  Any add-in
> network or storage PCI cards?
Yes, I have a hpt366 ide controller for hard disks.

I failed to be able to have to openboot boot of the disks, so I have a DOM 
(disk on module) disk for boot partition on onboard controller..

-- 
Regards,
Per Øyvind Karlsen
Mandriva

Re: Problems booting 2.6.18 on SunBlade 100/150

[David Miller]

From: Per Øyvind Karlsen <pkarlsen@mandriva.com>
Date: Wed, 18 Oct 2006 21:41:24 +0100

> Yes, I have a hpt366 ide controller for hard disks.

That's almost certainly the driver where the bug is.

Re: Problems booting 2.6.18 on SunBlade 100/150

[Jim Watson]

On 19/10/2006, at 5:30 AM, David Miller wrote:
>
> Are you sure you're enabling ATYFB video support in your kernel?
> That's a common error when folks build their own kernels.

Success! I used the later patch [0] and the config file from debian  
2.6.18-1-sparc64 as mentioned by Jurij[1]
which includes - hopefully relevant ;)

CONFIG_FB_ATY128=y
CONFIG_FB_ATY=y
CONFIG_FB_ATY_CT=y
# CONFIG_FB_ATY_GENERIC_LCD is not set
CONFIG_FB_ATY_GX=y

Using LCD Benq FP767 here,

I could only get it it to boot this way:

boot:mylinux18 video=atyfb:off

which is what I need as it also gets rid of those pesky red dots ;)

I am happy to report anything else that might assist...

thanks to David for the patches and thanks to Jurij for guidance,

jim

[0] http://marc.theaimsgroup.com/?l=linux-sparc&m\x116120447318793&w=2
[1] http://marc.theaimsgroup.com/?l=linux-sparc&m\x116120045100433&w=2

Re: Problems booting 2.6.18 on SunBlade 100/150

[Per Øyvind Karlsen]

Torsdag 19 oktober 2006 13:07, skrev Jim Watson:
> On 07/01/2004, at 5:29 PM, Per Øyvind Karlsen wrote:
> > I'm left puzzled here now, will your display work correctly when
> > disabling
> > framebuffer with 'video=atyfb:off'? And if you're disabling it, why
> > do you
> > need to compile support for it?
> >
> > My experience is that I need atyfb properly working to intialize
> > display,
> > otherwise it'll boot with not display (openboot screen will stay
> > and no linux
> > output is displayed, while machine is actually booting and serial
> > can be
> > used).
> >
> > Am I missing something here..? (I'm fairly new to sparc, so please
> > have
> > patience:o)
>
> Hi Per,
>
> i am puzzled too - lets wait and see if anyone provides some
> explanation...
>
> There are two issues here:
>
> (a) i chose to use the debian config file to build a kernel that will
> run - the explanation is that I have no idea what to configure, but
> the debian config is known to work
>
> (b) the kernel that I did build that way, will not run, unless I boot
> with video:atyfb=off
>
> This is on a sunblade100, it may be different on other sparc...you
> need to report what you are using
>
> regrads
>
> jim
Yes, but what I was wondering about is if you got any display at all or were 
relying on serial console or something? Is it possible to have display 
without framebuffer?

My config etc. were working fine with 2.6.17-rc3, don't know when the atyfb 
breakage occured, but in 2.6.17 it was broken...
-- 
Regards,
Per Øyvind Karlsen
Mandriva

Re: Problems booting 2.6.18 on SunBlade 100/150

[Jim Watson]

On 19/10/2006, at 9:18 PM, Per Øyvind Karlsen wrote:

> Yes, but what I was wondering about is if you got any display at  
> all or were
> relying on serial console or something? Is it possible to have display
> without framebuffer?
>
> My config etc. were working fine with 2.6.17-rc3, don't know when  
> the atyfb
> breakage occured, but in 2.6.17 it was broken...


Sorry I dont know about that breakage. All I know is:
(a) my patched 2.6.18 kernel is built with the debian config file
(b) my kernel would not boot at all, unless i used video:atyfb=off

The X (xorg) display works fine with that parameter but the console  
is weird. The only reason I tried that parameter is because of word  
association,  it was known to me previously as a fix for some "red  
dots" issue, not for any other reason,

jim

Re: Problems booting 2.6.18 on SunBlade 100/150

[Jurij Smakov]

On Wed, Oct 18, 2006 at 01:37:42PM -0700, David Miller wrote:
> From: "Jurij Smakov" <jurij@wooyd.org>
> Date: Wed, 18 Oct 2006 12:38:38 -0700 (PDT)
> 
> > I've tried to build the patched Debian packages overnight, but the build
> > failed for unrelated reasons. I'll try again tonight.
> 
> Jurij, please use this updated version of the patch
> against 2.6.18, thanks.
> 
> [SPARC64]: Fix PCI memory space root resource on Hummingbird.

The linux-image debs with this patch included are now available at

http://www.wooyd.org/debian/kernels/

Thanks a lot, Dave.
--
Jurij Smakov                                           jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                      KeyID: C99E03CC

Re: Problems booting 2.6.18 on SunBlade 100/150

[Riccardo Tortorici]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Oct 19, 2006, at 6:40 PM, Jurij Smakov wrote:

> On Wed, Oct 18, 2006 at 01:37:42PM -0700, David Miller wrote:
>> From: "Jurij Smakov" <jurij@wooyd.org>
>> Date: Wed, 18 Oct 2006 12:38:38 -0700 (PDT)
>>
>>> I've tried to build the patched Debian packages overnight, but  
>>> the build
>>> failed for unrelated reasons. I'll try again tonight.
>>
>> Jurij, please use this updated version of the patch
>> against 2.6.18, thanks.
>>
>> [SPARC64]: Fix PCI memory space root resource on Hummingbird.
>
> The linux-image debs with this patch included are now available at
>
> http://www.wooyd.org/debian/kernels/

Guys,
I installed the new image, this time the error does not appear,  
however it freezes on "Booting Linux".
How can I help to trace this error?
Regs,
Ric



- - Riccardo Tortorici -
Linux Registered User #365170
Count yourself @ http://counter.li.org/ !
- --
Encrypted Mails Welcome
GPG key: 0xF3FCE306 available on  wwwkeys.pgp.net
GPG key fingerprint = C1C4 CA17 5135 8F5C 94C2  3347 4A22 67DB F3FC E306


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFFOAhsSiJn2/P84wYRAvY5AKCGAnuB4PXocP817NWkA8f3RE/yFgCeMase
tAHdL4tFqpVo/UNOFe23HtI=GiBC
-----END PGP SIGNATURE-----

Re: Problems booting 2.6.18 on SunBlade 100/150

[Jim Watson]

On 20/10/2006, at 9:21 AM, Riccardo Tortorici wrote:

>
> Guys,
> I installed the new image, this time the error does not appear,  
> however it freezes on "Booting Linux".
> How can I help to trace this error?
> Regs,
> Ric
>
I see the same with Jurij's new image, but it boots this way:

boot:Linux video=atyfb:off

same thing is seen in my own builds of 2.6.16 and 2.6.18 but not seen  
in debian 2.6.16

thanks

jim

Re: Problems booting 2.6.18 on SunBlade 100/150

[Riccardo Tortorici]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Oct 20, 2006, at 1:43 AM, Jim Watson wrote:

>
> On 20/10/2006, at 9:21 AM, Riccardo Tortorici wrote:
>
>>
>> Guys,
>> I installed the new image, this time the error does not appear,  
>> however it freezes on "Booting Linux".
>> How can I help to trace this error?
>> Regs,
>> Ric
>>
> I see the same with Jurij's new image, but it boots this way:
>
> boot:Linux video=atyfb:off
>
> same thing is seen in my own builds of 2.6.16 and 2.6.18 but not  
> seen in debian 2.6.16

Turning off FB works for me also, but only extend the agony.. :)
this time freezes on:

hda: cache flushes not supported
hda: hda1 hda2 hda3 hda4
hdc: max request size: 128KiB

Before running Jurij's image I ran 2.6.8 and everything was ok...
By the way...I get this behavior also with 2.6.16.
Regs,
Ric


- - Riccardo Tortorici -
Linux Registered User #365170
Count yourself @ http://counter.li.org/ !
- --
Encrypted Mails Welcome
GPG key: 0xF3FCE306 available on  wwwkeys.pgp.net
GPG key fingerprint = C1C4 CA17 5135 8F5C 94C2  3347 4A22 67DB F3FC E306


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFFOBnzSiJn2/P84wYRAmNeAJ9beYdGeJ4yR3CcsD3T8S7+grjH+wCgmb66
5RHqLlU7JDfUQN1Vy6Zu8WU=yphL
-----END PGP SIGNATURE-----

Re: Problems booting 2.6.18 on SunBlade 100/150

[Jim Watson]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]


On 20/10/2006, at 10:36 AM, Riccardo Tortorici wrote:

>
> Turning off FB works for me also, but only extend the agony.. :)
> this time freezes on:
>
> hda: cache flushes not supported
> hda: hda1 hda2 hda3 hda4
> hdc: max request size: 128KiB

I see different with Juri's kernel, packaged 2.6.18-2 with atyfb:off

hda: cache flushes not supported
hda: hda1 hda2 hda3 hda4 hda5
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.

Full dmesg is attached...

jim

[-- Attachment #2: dmesg.txt --]
[-- Type: text/plain, Size: 6078 bytes --]

PROMLIB: Sun IEEE Boot Prom 'OBP 4.0.45 2001/02/08 14:33'
PROMLIB: Root node compatible: 
Linux version 2.6.18-1-sparc64 (Debian 2.6.18-2) (waldi@debian.org) (gcc version 4.1.2 20061007 (prerelease) (Debian 4.1.1-16)) #1 Wed Oct 18 23:44:13 PDT 2006
ARCH: SUN4U
Ethernet address: 00:03:ba:04:a4:ab
PROM: Built device tree with 53980 bytes of memory.
On node 0 totalpages: 31947
  DMA zone: 31947 pages, LIFO batch:7
CPU[0]: Caches D[sz(16384):line_sz(32)] I[sz(16384):line_sz(32)] E[sz(262144):line_sz(64)]
Built 1 zonelists.  Total pages: 31947
Kernel command line: root=/dev/hda2 ro video=atyfb:off
PID hash table entries: 1024 (order: 10, 8192 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 4, 131072 bytes)
Memory: 252960k available (2200k kernel code, 784k data, 136k init) [fffff80000000000,000000000ff24000]
Calibrating delay using timer specific routine.. 11.12 BogoMIPS (lpj=22244)
Security Framework v1.0.0 initialized
SELinux:  Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512
checking if image is initramfs... it is
Freeing initrd memory: 1026k freed
NET: Registered protocol family 16
PCI: Probing for controllers.
/pci@1f,0: SABRE PCI Bus Module
PCI quirk: region 0800-083f claimed by ali7101 ACPI
PCI quirk: region 0600-061f claimed by ali7101 SMB
PCI0(PBMA): Bus running at 33MHz
isa0: [dma -> (floppy) (parallel)] [power] [serial] [serial]
ebus0: [flashprom] [eeprom] [idprom]
power: Control reg at 1fe02000800 ... powerd running.
usbcore: registered new driver usbfs
usbcore: registered new driver hub
/pci@1f,0/ebus@c/eeprom@1,0: Clock regs at 000001fff1000000
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 16384 bytes)
TCP established hash table entries: 8192 (order: 3, 65536 bytes)
TCP bind hash table entries: 4096 (order: 2, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 4096)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(1161336996.228:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 8192 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Activating ISA DMA hang workarounds.
Console: switching to mono PROM 80x34
rtc_init: no PC rtc found
[drm] Initialized drm 1.0.1 20051102
serial@0,3f8: ttyS0 at MMIO 0x1fe020003f8 (irq = 9) is a 16550A
serial@0,2e8: ttyS1 at MMIO 0x1fe020002e8 (irq = 9) is a 16550A
RAMDISK driver initialized: 16 RAM disks of 16384K size 1024 blocksize
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
rtc_sun_init: Registered Mostek RTC driver.
usbmon: debugfs is not available
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.6:USB HID core driver
mice: PS/2 mouse device common for all mice
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ohci_hcd 0000:00:0c.3: OHCI Host Controller
ohci_hcd 0000:00:0c.3: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:0c.3: irq 12, io mem 0x1ff02000000
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 4 ports detected
ALI15X3: IDE controller at PCI slot 0000:00:0d.0
ALI15X3: chipset revision 195
ALI15X3: 100% native mode on irq 15
    ide0: BM-DMA at 0x1fe02000a20-0x1fe02000a27, BIOS settings: hda:pio, hdb:pio
    ide1: BM-DMA at 0x1fe02000a28-0x1fe02000a2f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
usb 1-1: new low speed USB device using ohci_hcd and address 2
hda: ST315320A, ATA DISK drive
usb 1-1: configuration #1 chosen from 1 choice
input: Logitech USB Receiver as /class/input/input0
input: USB HID v1.10 Mouse [Logitech USB Receiver] on usb-0000:00:0c.3-1
usb 1-4: new low speed USB device using ohci_hcd and address 3
hdb: LTN485S, ATAPI CD/DVD-ROM drive
ide0 at 0x1fe02000a00-0x1fe02000a07,0x1fe02000a1a on irq 15
Probing IDE interface ide1...
usb 1-4: configuration #1 chosen from 1 choice
input: HID 0430:0005 as /class/input/input1
input: USB HID v1.00 Keyboard [HID 0430:0005] on usb-0000:00:0c.3-4
hda: max request size: 128KiB
hda: 29888820 sectors (15303 MB) w/2048KiB Cache, CHS=29651/16/63, UDMA(66)
hda: cache flushes not supported
 hda: hda1 hda2 hda3 hda4 hda5
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
sungem.c:v0.98 8/24/03 David S. Miller (davem@redhat.com)
PHY ID: 437421, addr: 1
eth0: Sun GEM (PCI) 10/100/1000BaseT Ethernet 00:03:ba:04:a4:ab 
eth0: Found Generic MII PHY
ieee1394: Initialized config rom entry `ip1394'
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[11]  MMIO=[1ff00420000-1ff004207ff]  Max Packet=[2048]  IR/IT contexts=[4/4]
hdb: ATAPI 48X CD-ROM drive, 120kB Cache
Uniform CD-ROM driver Revision: 3.20
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[0003bafffe04a4ab]
eth0: Link is up at 10 Mbps, half-duplex.
Kernel unaligned access at TPC[101780bc] ether1394_reset_priv+0x20/0xac [eth1394]
eth1394: eth1: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
ali_stimer_read: stimer is not ready.
Adding 511544k swap on /dev/hda4.  Priority:-1 extents:1 across:511544k
EXT3 FS on hda2, internal journal
Probing IDE interface ide1...
device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
eth0: Link is up at 10 Mbps, half-duplex.
eth0: Pause is disabled
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
IPv6 over IPv4 tunneling driver
eth0: no IPv6 routers present

Re: Problems booting 2.6.18 on SunBlade 100/150

[Jason Wever]

[-- Attachment #1: Type: text/plain, Size: 1475 bytes --]

On Wed, 18 Oct 2006 12:31:51 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:

Sorry for the late reply here.

> I fixed these recently, I believe the fix for that is in 2.6.18.1

I tried 2.6.18.1 but the same warnings were still there.  I'll
attempt to pull the git tree for 2.6.18.x and see if I can reproduce
there.

> I'll look into the IRQ problems but the power device registered it's
> IRQ just fine on my SB100 in current 2.6.19-GIT.

Hrm, I pulled the git source this afternoon and still get the same
thing:

ebus0: [flashprom] [eeprom] [idprom]
power: Control reg at 1fe02000800 ... powerd running.
power: Control reg at 1fe02000800 ... powerd running.
IRQ handler type mismatch for IRQ 8
Call Trace:
 [00000000004232f4] power_probe+0xb0/0x100
 [0000000000427628] of_device_probe+0x50/0x70
 [00000000005a5a20] really_probe+0x48/0xf0
 [00000000005a5bd0] __driver_attach+0x44/0x68
 [00000000005a50d4] bus_for_each_dev+0x38/0x6c
 [00000000005a540c] bus_add_driver+0x60/0x190
 [00000000007be7f0] pcibios_init+0x88/0x90
 [0000000000416a44] init+0xa8/0x298
 [0000000000417478] kernel_thread+0x38/0x48
 [0000000000416c4c] rest_init+0x18/0x2c
power: Error, cannot register IRQ handler.

I tried building with both CONFIG_CC_OPTIMIZE_FOR_SIZE enabled and
disabled but it didn't appear to make any difference.  Not sure if it
would matter or not but I'm using OBP 4.17.1 here.

Thanks,
-- 
Jason Wever
Gentoo/Sparc Team Co-Lead

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Problems booting 2.6.18 on SunBlade 100/150

[Per Øyvind Karlsen]

Tirsdag 24 oktober 2006 10:34, skrev du :
> From: Per Øyvind Karlsen <pkarlsen@mandriva.com>
> Date: Tue, 24 Oct 2006 09:45:16 +0200
>
> > But now, should I try tremble through changes between -rc3 & -rc4 on
> > my own and hope that I spot the exact code that breaks it?
>
> I misread your original email, sorry.
>
> It really would have been nice if you had CC:'d the mailing
> list with your finding so that this datapoint is logged
> somewhere permanently just in cast I didn't have time
> to read your email and deleted it.  Although it appears this
> way, I am not the only Linux/sparc developer on the planet :)
So, did we get to any conclusion on this one?

Should I dig through changes between -rc3 & -rc4 to exactly pinpoint the 
breakage, or do you have enough info on the matter to work with?

Just give the word and I'm at your service!

(ps: I CC'ed this time!;)
-- 
Regards,
Per Øyvind Karlsen
Mandriva

Re: Problems booting 2.6.18 on SunBlade 100/150

[David Miller]

From: Per Øyvind Karlsen <pkarlsen@mandriva.com>
Date: Wed, 25 Oct 2006 01:31:23 +0200

> So, did we get to any conclusion on this one?
> 
> Should I dig through changes between -rc3 & -rc4 to exactly pinpoint the 
> breakage, or do you have enough info on the matter to work with?

I have enough info to look into this.

Re: Problems booting 2.6.18 on SunBlade 100/150

[David Miller]

From: David Miller <davem@davemloft.net>
Date: Tue, 24 Oct 2006 16:32:59 -0700 (PDT)

> From: Per Øyvind Karlsen <pkarlsen@mandriva.com>
> Date: Wed, 25 Oct 2006 01:31:23 +0200
> 
> > So, did we get to any conclusion on this one?
> > 
> > Should I dig through changes between -rc3 & -rc4 to exactly pinpoint the 
> > breakage, or do you have enough info on the matter to work with?
> 
> I have enough info to look into this.

Well, I just did a diff between 2.6.17-rc3 and 2.6.17-rc4, which is
where you say the breakage got introduced, and there is nothing that
even remotely could cause atyfb breaking.

All sparc64 changes are:

1) Changes to arguments passed to audit_syscall_{entry,exit}()
   Cannot possibly effect framebuffer operation.

2) Add support for vmsplice() system call, again cannot possibly
   break your framebuffer.

3) Add preempt() protection around flush_tlb_pending(), again cannot
   possible break your framebuffer.

4) Remove prototype for a function whose implementation got deleted
   years ago.  Cannot possibly break anything.

All PCI layer changes are:

1) MSI layer memory leak fix, sparc64 does not turn on CONFIG_MSI
   and thus can't even execute this code.

2) printk message change in quirk layer, can't break anything.

All framebuffer layer changes are:

1) Help text added to FB_ASILIANT kernel config option, cannot
   break atyfb.

2) Changes to au1200fb.c driver, not used by sparc64 nor every built
   into the sparc64 kernel image.

3) SYSFS changes for framebuffer, wrt. cmap writes to /sys filesystem
   files after boot.  Cannot break the atyfb framebuffer on bootup.

4) Minor changes to the Makefile rule that builds the video
   framebuffer logo image file, cannot break atyfb.

So there is absolutely nothing for me to work with.

Does the kernel in 2.6.17-rc4 say anything interesting if you
boot with the "-p" option on the kernel boot command line?
Do you get an OOPS or some other kind of crash message?

Re: Problems booting 2.6.18 on SunBlade 100/150

[Per Øyvind Karlsen]

Onsdag 25 oktober 2006 01:44, skrev David Miller:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 24 Oct 2006 16:32:59 -0700 (PDT)
>
> > From: Per Øyvind Karlsen <pkarlsen@mandriva.com>
> > Date: Wed, 25 Oct 2006 01:31:23 +0200
> >
> > > So, did we get to any conclusion on this one?
> > >
> > > Should I dig through changes between -rc3 & -rc4 to exactly pinpoint
> > > the breakage, or do you have enough info on the matter to work with?
> >
> > I have enough info to look into this.
>
> Well, I just did a diff between 2.6.17-rc3 and 2.6.17-rc4, which is
> where you say the breakage got introduced, and there is nothing that
> even remotely could cause atyfb breaking.
>
> All sparc64 changes are:
>
> 1) Changes to arguments passed to audit_syscall_{entry,exit}()
>    Cannot possibly effect framebuffer operation.
>
> 2) Add support for vmsplice() system call, again cannot possibly
>    break your framebuffer.
>
> 3) Add preempt() protection around flush_tlb_pending(), again cannot
>    possible break your framebuffer.
>
> 4) Remove prototype for a function whose implementation got deleted
>    years ago.  Cannot possibly break anything.
>
> All PCI layer changes are:
>
> 1) MSI layer memory leak fix, sparc64 does not turn on CONFIG_MSI
>    and thus can't even execute this code.
>
> 2) printk message change in quirk layer, can't break anything.
>
> All framebuffer layer changes are:
>
> 1) Help text added to FB_ASILIANT kernel config option, cannot
>    break atyfb.
>
> 2) Changes to au1200fb.c driver, not used by sparc64 nor every built
>    into the sparc64 kernel image.
>
> 3) SYSFS changes for framebuffer, wrt. cmap writes to /sys filesystem
>    files after boot.  Cannot break the atyfb framebuffer on bootup.
>
> 4) Minor changes to the Makefile rule that builds the video
>    framebuffer logo image file, cannot break atyfb.
>
> So there is absolutely nothing for me to work with.
>
> Does the kernel in 2.6.17-rc4 say anything interesting if you
> boot with the "-p" option on the kernel boot command line?
> Do you get an OOPS or some other kind of crash message?
I'll investigate these issues later, I'm on my way to bed :)
-- 
Regards,
Per Øyvind Karlsen
Mandriva

Re: Problems booting 2.6.18 on SunBlade 100/150

[Per Øyvind Karlsen]

Onsdag 25 oktober 2006 01:44, skrev David Miller:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 24 Oct 2006 16:32:59 -0700 (PDT)
>
> > From: Per Øyvind Karlsen <pkarlsen@mandriva.com>
> > Date: Wed, 25 Oct 2006 01:31:23 +0200
> >
> > > So, did we get to any conclusion on this one?
> > >
> > > Should I dig through changes between -rc3 & -rc4 to exactly pinpoint
> > > the breakage, or do you have enough info on the matter to work with?
> >
> > I have enough info to look into this.
>
> Well, I just did a diff between 2.6.17-rc3 and 2.6.17-rc4, which is
> where you say the breakage got introduced, and there is nothing that
> even remotely could cause atyfb breaking.
>
> All sparc64 changes are:
>
> 1) Changes to arguments passed to audit_syscall_{entry,exit}()
>    Cannot possibly effect framebuffer operation.
>
> 2) Add support for vmsplice() system call, again cannot possibly
>    break your framebuffer.
>
> 3) Add preempt() protection around flush_tlb_pending(), again cannot
>    possible break your framebuffer.
>
> 4) Remove prototype for a function whose implementation got deleted
>    years ago.  Cannot possibly break anything.
>
> All PCI layer changes are:
>
> 1) MSI layer memory leak fix, sparc64 does not turn on CONFIG_MSI
>    and thus can't even execute this code.
>
> 2) printk message change in quirk layer, can't break anything.
>
> All framebuffer layer changes are:
>
> 1) Help text added to FB_ASILIANT kernel config option, cannot
>    break atyfb.
>
> 2) Changes to au1200fb.c driver, not used by sparc64 nor every built
>    into the sparc64 kernel image.
>
> 3) SYSFS changes for framebuffer, wrt. cmap writes to /sys filesystem
>    files after boot.  Cannot break the atyfb framebuffer on bootup.
>
> 4) Minor changes to the Makefile rule that builds the video
>    framebuffer logo image file, cannot break atyfb.
>
> So there is absolutely nothing for me to work with.
>
> Does the kernel in 2.6.17-rc4 say anything interesting if you
> boot with the "-p" option on the kernel boot command line?
> Do you get an OOPS or some other kind of crash message?
Okay, I did some more testing, and just to be on the safe side to ensure 
kernel actually being the one to blame I recompiled -rc3 with the same config 
(from /proc/config.gz) and now I have the same problem with 2.4.17-rc3 too 
(even the same messages related to PCI/DMA stuff)!

So I'm really puzzled, could it be related to any possible changes in 
toolchain causing this or something similar?

I did try booting with -p and I saw it booting up, no oopses when trying to 
change to framebuffer as far as I could see, but then again, I only catched a 
glimpse ;) Is there any way to log these messages to somewhere? I'm unable to 
get serial cnsole & framebuffer working at same time and heard rumours about 
it not being doable..

Btw. if you have a kernel with atyfb booting without any issues on your SB100, 
could you maybe put it up somewhere for me to test? If it boots without 
screwing things up, it must be the toolchain, I see my old kernel was 
compiled with another release of gcc..
-- 
Regards,
Per Øyvind Karlsen
Mandriva

Re: Problems booting 2.6.18 on SunBlade 100/150

[Per Øyvind Karlsen]

Onsdag 25 oktober 2006 17:23, skrev Per Øyvind Karlsen:
> So I'm really puzzled, could it be related to any possible changes in
> toolchain causing this or something similar?
I reverted back to old gcc 4.0.3 to build kernel, now -rc3 seemed to initiate 
display properly at least, so it seems to be related to the compiler..

Will now build latest kernel release with 4.0.3 to see if it works properly 
now :)

davem: thanks for your patience and for troubling you with this one
-- 
Regards,
Per Øyvind Karlsen
Mandriva

Re: Problems booting 2.6.18 on SunBlade 100/150

[David Miller]

From: Per Øyvind Karlsen <pkarlsen@mandriva.com>
Date: Wed, 25 Oct 2006 22:08:45 +0200

> davem: thanks for your patience and for troubling you with this one

No problem.

I had stopped suspecting Debian's gcc automatically as the culprit of
kernel bugs, perhaps I should start doing that again :-)

Re: Problems booting 2.6.18 on SunBlade 100/150

[Per Øyvind Karlsen]

Torsdag 26 oktober 2006 11:25, skrev David Miller:
> From: Per Øyvind Karlsen <pkarlsen@mandriva.com>
> Date: Wed, 25 Oct 2006 22:08:45 +0200
>
> > davem: thanks for your patience and for troubling you with this one
>
> No problem.
>
> I had stopped suspecting Debian's gcc automatically as the culprit of
> kernel bugs, perhaps I should start doing that again :-)
okay, 2.6.19-rc3 built with gcc 4.0.3 boots nice with framebuffer working 
now! :)
-- 
Regards,
Per Øyvind Karlsen
Mandriva