whacked out 2.2.18pre17?

whacked out 2.2.18pre17?

[Stefan Jeglinski]

I have a PowerTowerPro with a 500/1M PowerLogix G3 upgrade, have been
running Paul's 2.2.17 linux-pmac-stable for a while now (originally
rsynced from penguinppc.org), with great success, using BootX 1.1.3.

But for the last 4 nights I've been trying to run 2.2.18pre17 (also
rsynced from penguinppc.org) with no luck. The compile always
succeeds (just a vanilla compile, no changes to the default config),
but I either cannot boot completely, or the boot completes but is
seriously messed up.

The first night, all it would do is freeze at "booting..."

The second night, it booted, but the no video checkbox was somehow
inverted in operation. IOW, with no video turned on (I have a twin
turbo card, OFfb is my only choice in running X), I never get the
OFfb driver, it always insists on loading the imsttfb driver, so X is
impossible.

Last night, the video anomaly was still in effect, but the boot never
completed (kernel panic after an error that I cannot recall to save
me now)

Tonight, again the video anomaly is also still in effect, but the
boot never completes again, however for a different reason (kernel
panic after "machine check in kernel mode" which leads to the message
"unknown values in srr1").

I am aware that this kernel is being worked on daily (that's why I
try to rebuild it each night), but I'm a little surprised that I am
having so much trouble with a pre17 kernel. Anybody know what's up?
Is this thing going through such big changes that I should let it go
for a while instead of trying each night?


Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: whacked out 2.2.18pre17?

[Benjamin Herrenschmidt]

>I am aware that this kernel is being worked on daily (that's why I
>try to rebuild it each night), but I'm a little surprised that I am
>having so much trouble with a pre17 kernel. Anybody know what's up?
>Is this thing going through such big changes that I should let it go
>for a while instead of trying each night?

Well, first try with a more recent bootx.. that may help.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: whacked out 2.2.18pre17?

[Stefan Jeglinski]

>  >I am aware that this kernel is being worked on daily (that's why I
>>try to rebuild it each night), but I'm a little surprised that I am
>>having so much trouble with a pre17 kernel. Anybody know what's up?
>>Is this thing going through such big changes that I should let it go
>>for a while instead of trying each night?
>
>Well, first try with a more recent bootx.. that may help.


After a long evening of playing with this, I stand by my original assertion :-)

I did update to BootX 1.2.2, and started from scratch by playing with
several settings. I also scrounged several 2.2.18 versions, newly
rsynced from penguinppc.org::linux-pmac-stable and
ppc.linuxcare.com::linux-pmac-stable, and also earlier 2.2.18 rsyncs
that were stored on different computers available to me.

The two things that are constant on my hardware (PowerTowerPro +
PowerLogix G3, 6 PCI cards, most of which are not seen anyway,
2940UW):

1. Full boot is impossible, always with one of the following circumstances:
	a) freeze at "booting..."
	b) can't find MAC address for MACE device -> kernel panic
	c) "machine check in kernel mode" -> "unknown values in srr1" ->
		kernel panic

2. no video checkbox is ignored, on or off. There is no way to force
OFfb, regardless of kernel args or video checkboxes. The imstt card
is -always- found and the driver -always- loaded. Most odd, I've
never seen this one before.


Reverting to 2.2.17-linux-pmac-stable fixes everything. Looks to me
like 2.2.18-linux-pmac-stable is undergoing serious under-the-hood
changes, at least for my hardware. It makes me pretty nervous. I
don't think I have the expertise to sleuth this, I just wanted to
post to the list in case the info helped anyone.


Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: whacked out 2.2.18pre17?

[Benjamin Herrenschmidt]

>The two things that are constant on my hardware (PowerTowerPro +
>PowerLogix G3, 6 PCI cards, most of which are not seen anyway,
>2940UW):
>
>1. Full boot is impossible, always with one of the following circumstances:
>	a) freeze at "booting..."
>	b) can't find MAC address for MACE device -> kernel panic
>	c) "machine check in kernel mode" -> "unknown values in srr1" ->
>		kernel panic

That's weird. The symptoms you describe are typicall of a kernel beeing
damaged by bus-mastering devices (your 6 PCI cards frighten me ...).

But in this case, 2.2.17 should have the same problems.

No explanation come to my mind. Did you try removing some PCI cards to
see if one could be the cause of the problem ? I don't see any of the
2.2.18 change that could explain your problem.

Ben.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: whacked out 2.2.18pre17?

[Stefan Jeglinski]

>  >The two things that are constant on my hardware (PowerTowerPro +
>>PowerLogix G3, 6 PCI cards, most of which are not seen anyway,
>>2940UW):
>>
>>1. Full boot is impossible, always with one of the following circumstances:
>>	a) freeze at "booting..."
>>	b) can't find MAC address for MACE device -> kernel panic
>>	c) "machine check in kernel mode" -> "unknown values in srr1" ->
>>		kernel panic
>
>That's weird. The symptoms you describe are typicall of a kernel beeing
>damaged by bus-mastering devices (your 6 PCI cards frighten me ...).


Me too :-) FWIW, here they are in order from top to bottom:

Adaptec 2940UW
Farallon ethernet 10/100
OrangeLink firewire/usb combo
Matrox Mystique card
ixMicro TV card
ixMicro Twin Turbo card

lspci gives (only):

00:0b.0 Host bridge: Apple Computer Inc. Bandit PowerPC host bridge (rev 03)
00:0d.0 SCSI storage controller: Adaptec AIC-7881U
00:0e.0 Ethernet controller: Digital Equipment Corporation DECchip
21142/43 (rev 41)
00:0f.0 PCI bridge: Action Tec Electronics Inc: Unknown device 0100 (rev 11)
00:10.0 Class ff00: Apple Computer Inc. Grand Central I/O (rev 02)
01:0c.0 FireWire (IEEE 1394): NEC Corporation: Unknown device 00cd (rev 01)
01:0d.0 USB Controller: OPTi Inc. 82C861 (rev 10)


I had a long go-round with Tom Rini looking at this, because I was
wanting to try XF4 and run dual monitors, just like I do on the Mac
side. My understanding from discussing it with him is that it's
pretty much hopeless because of the current kernel's inability to
detangle (my unofficial word for it) all the pci issues. I believe he
said maybe in late 2.4 or 2.5 I'd get some help. I really really hope
by that time that machines like mine haven't been orphaned because of
a lack of resources and the prevalence of newworld machines.


>But in this case, 2.2.17 should have the same problems.

I finally located a pristine 2.2.17-linux-pmac-stable on a 6500 I
have. I'm going to retry that, although the 2.2.17 I've been using on
the PowerTower so far was rsynced to the same source. I haven't tried
the bk 2_2 in a while... Someone please verify, the 2 sources of
Paul's linux-pmac-stable are penguinppc.org and ppc.linuxcare.com,
correct? AFAICT, these are -not- generally the same code (although
close), which means I need to always try both?


>No explanation come to my mind. Did you try removing some PCI cards to
>see if one could be the cause of the problem ? I don't see any of the
>2.2.18 change that could explain your problem.

Not yet. I am really loathe to do that, but will if I must.

Speculation:

lspci does see the USB side of my OrangeLink card. My real goal in
starting all this to begin with is to try to get a Logitech USB mouse
working, for which I have to turn on a lot of USB stuff in the
kernel. So far I have tried building the 2.2.18 kernel -without- USB,
just to make sure it works (which is where I am right now). Is it
possible that with 2.2.18 and the USB card, I -must- turn on USB in
the kernel config?

This still wouldn't explain the symptom of the BootX video switch
being ignored. That's sure a weird one, but I've tried so many
different things I'm convinced it's real.

Here's hoping this can be solved. I'll try whatever is necessary,
although the PTP is my workhorse and Linux still has to take a back
seat (I'm trying to change that). From time to time things like this
have cropped up, and I always fear it's the end of the line for Linux
on my hardware. I guess that comes from being beaten up by Apple so
many times :-)


Stefan Jeglinski


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: whacked out 2.2.18pre17?

[Michel Lanners]

On   4 Nov, this message from Stefan Jeglinski echoed through cyberspace:
>>That's weird. The symptoms you describe are typicall of a kernel beeing
>>damaged by bus-mastering devices (your 6 PCI cards frighten me ...).
>
>
> Me too :-) FWIW, here they are in order from top to bottom:
>
> Adaptec 2940UW
> Farallon ethernet 10/100
> OrangeLink firewire/usb combo
> Matrox Mystique card
> ixMicro TV card
> ixMicro Twin Turbo card

OK, 6 slots, so I suppose this is a 9x00 or compatible box?

> lspci gives (only):
>
> 00:0b.0 Host bridge: Apple Computer Inc. Bandit PowerPC host bridge (rev 03)
> 00:0d.0 SCSI storage controller: Adaptec AIC-7881U
> 00:0e.0 Ethernet controller: Digital Equipment Corporation DECchip
> 21142/43 (rev 41)
> 00:0f.0 PCI bridge: Action Tec Electronics Inc: Unknown device 0100 (rev 11)
> 00:10.0 Class ff00: Apple Computer Inc. Grand Central I/O (rev 02)
> 01:0c.0 FireWire (IEEE 1394): NEC Corporation: Unknown device 00cd (rev 01)
> 01:0d.0 USB Controller: OPTi Inc. 82C861 (rev 10)

Hmm, there's one bus missing here, the one with the Matrox and the
ixMicro cards. And the accompanying bandit host bridge is missing. You
might want to try my PCI patches (see:
http://www.cpu.lu/~mlan/linux/dev/pci.html). The relevant part is this
here, in arch/ppc/kernel/pmac_pci.c:

 pmac_pcibios_fixup(void))
 {
        struct pci_dev *dev;
-
+       int i, has_io, has_mem;
+       unsigned short cmd;
+       struct bridge_data *bp;
+
        /*
-        * FIXME: This is broken: We should not assign IRQ's to IRQless
-        *        devices (look at PCI_INTERRUPT_PIN) and we also should
-        *        honor the existence of multi-function devices where
-        *        different functions have different interrupt pins. [mj]
+        * The generic PCI code scans only bus 0 for devices and P2P
+        * bridges. We fix this here based on the array of host
+        * bridges.
+        *
+        * However, we need to treat the bus behind chaos with special
+        * care. chaos doesn't like being poked at while scanning that
+        * bus...
+        *
+        * Comments on everything below to mlan@cpu.lu...
         */
+       for (bp = bridge_list; bp != NULL; bp = bp->next) {
+               if (bp->bus_number == 0) continue;
+               if (strcmp(bp->node->name, "chaos") != 0)
+                       pci_scan_peer_bridge (bp->bus_number);
+       }
+
        for(dev=pci_devices; dev; dev=dev->next)
        {

Mind you, the patch is not complete; but it should make your other PCI
primary bus appear in lspci's output.

Ben, Paul, any chance to get this code snippet into 2.2.18? At least,
then, 9x00 and clones would be supported for their second PCI bus....
Note that I'm simply avoiding chaos at all.

Stefan, a final note, if you want to turn multihead, it might be a good
idea performance-wise to put both of your graphics boards not in the
same PCI bus... ie one into slots 1-3, and the other in slots 4-6.

Cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: whacked out 2.2.18pre17?

[Stefan Jeglinski]

>  > Me too :-) FWIW, here they are in order from top to bottom:
>>
>>  Adaptec 2940UW
>>  Farallon ethernet 10/100
>>  OrangeLink firewire/usb combo
>>  Matrox Mystique card
>>  ixMicro TV card
>>  ixMicro Twin Turbo card
>
>OK, 6 slots, so I suppose this is a 9x00 or compatible box?

PowerTowerPro, most comparable to the 9500 AFAIK. I also have a
500/1Mb PowerLogix upgrade card in it.


>  > lspci gives (only):
>>
>>  00:0b.0 Host bridge: Apple Computer Inc. Bandit PowerPC host bridge (rev 03)
>>  00:0d.0 SCSI storage controller: Adaptec AIC-7881U
>>  00:0e.0 Ethernet controller: Digital Equipment Corporation DECchip
>>  21142/43 (rev 41)
>>  00:0f.0 PCI bridge: Action Tec Electronics Inc: Unknown device 0100 (rev 11)
>>  00:10.0 Class ff00: Apple Computer Inc. Grand Central I/O (rev 02)
>>  01:0c.0 FireWire (IEEE 1394): NEC Corporation: Unknown device 00cd (rev 01)
>>  01:0d.0 USB Controller: OPTi Inc. 82C861 (rev 10)
>
>Hmm, there's one bus missing here, the one with the Matrox and the
>ixMicro cards.

Yes, I've known this for a while. But this leads to a long-standing
question of mine: how is it that the Twin Turbo card is still somehow
recognized? Because the imsttfb driver will load and appears
functional in console mode (although not in X as described on other
linuxppc lists).

>And the accompanying bandit host bridge is missing. You
>might want to try my PCI patches (see:
>http://www.cpu.lu/~mlan/linux/dev/pci.html). The relevant part is this
>here, in arch/ppc/kernel/pmac_pci.c:

Thanks I will try this.


>Stefan, a final note, if you want to turn multihead, it might be a good
>idea performance-wise to put both of your graphics boards not in the
>same PCI bus... ie one into slots 1-3, and the other in slots 4-6.

Given my list of cards, are there any other general pointers as to
which bus which cards should go? The order I have now took a long
time to create - I'm not sure if it's the unique workable one, but
several other orders cause OpenTransport crashes when I am running
the ixTV (!). But it looks like removing cards and/or changing order
is my only choice, given 2.2.18's new proclivity (for me anyway) to
not boot - bummer. I'll be back with a report when I can try it all.


Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: whacked out 2.2.18pre17?

[Michel Lanners]

On   5 Nov, this message from Stefan Jeglinski echoed through cyberspace:
>>  > Me too :-) FWIW, here they are in order from top to bottom:
>>>
>>>  Adaptec 2940UW
>>>  Farallon ethernet 10/100
>>>  OrangeLink firewire/usb combo
>>>  Matrox Mystique card
>>>  ixMicro TV card
>>>  ixMicro Twin Turbo card
>>
>>OK, 6 slots, so I suppose this is a 9x00 or compatible box?
>
> PowerTowerPro, most comparable to the 9500 AFAIK. I also have a
> 500/1Mb PowerLogix upgrade card in it.

Mine is a 7600 (first generation PCI as well), and I have a G3 upgrade
as well... but 2.2 kernels have always booted for me. I have no luck
with 2.4 kernels... no way to reliably boot those.

>>  > lspci gives (only):
>>>
>>>  00:0b.0 Host bridge: Apple Computer Inc. Bandit PowerPC host bridge (rev 03)
>>>  00:0d.0 SCSI storage controller: Adaptec AIC-7881U
>>>  00:0e.0 Ethernet controller: Digital Equipment Corporation DECchip
>>>  21142/43 (rev 41)
>>>  00:0f.0 PCI bridge: Action Tec Electronics Inc: Unknown device 0100 (rev 11)
>>>  00:10.0 Class ff00: Apple Computer Inc. Grand Central I/O (rev 02)
>>>  01:0c.0 FireWire (IEEE 1394): NEC Corporation: Unknown device 00cd (rev 01)
>>>  01:0d.0 USB Controller: OPTi Inc. 82C861 (rev 10)
>>
>>Hmm, there's one bus missing here, the one with the Matrox and the
>>ixMicro cards.
>
> Yes, I've known this for a while. But this leads to a long-standing
> question of mine: how is it that the Twin Turbo card is still somehow
> recognized? Because the imsttfb driver will load and appears
> functional in console mode (although not in X as described on other
> linuxppc lists).

That's probably because imsttfb looks for the device in the OpenFirmware
device tree, not in PCI device tree. And, since OpenFirmware uses tat
display, it is available anyway to offb. Keep in mind that it's absence
on the lspci listing doesn't mean it's unavailable. It's just invisible
to drivers searching the PCI device chain.

> Given my list of cards, are there any other general pointers as to
> which bus which cards should go?

Well, only that you should know all your 'internal' devices are on PCI
bus 0 (that is, top slots, AFAIR). Internal and external SCSI count
here, as well as built-in ethernet and the serial ports. So, if you use
your internal SCSI as well, you might want to exchange the Matrox with
either the SCSI or the ethernet card. But it depends on your usage as
well...

> The order I have now took a long
> time to create - I'm not sure if it's the unique workable one, but
> several other orders cause OpenTransport crashes when I am running
> the ixTV (!).

In that case, there might not be too much gain in swapping your cards
around... If you do graphics-intensive thngs on dual monitors, maybe
swap the matrox as said above; but other than that, it's probably ok.

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

whacked out 2.2.18pre21?

[Stefan Jeglinski]

Last week I called this "whacked out 2.2.18pre17?"

I'm the one with the 6 cards in the PowerTowerPro, who can compile
2.2.18preX (linux-pmac-stable from penguinppc.org or
ppc.linuxcare.com or ppc.samba.org) but not boot it without a kernel
panic. I know that some think I should remove cards, but I've been
able to narrow things down a bit, and no longer do I think I have a
BootX problem, and I'm not so sure this is a PCI issue (although
maybe still).

Upgrading to BootX 1.2.2 didn't make a difference in any boot issues.

Always compiling the kernel for both video cards (imstt and matrox)
finally allowed BootX to pay attn to its no-video checkbox. Problem
solved.

Compiling without the "early BootX text" switch (or whatever that is)
eliminated all my freezes at "booting..." Problem solved.

Next I will start removing cards :-(, but I am highly suspicious of
the code involving the 2940UW card in the box. The -only- drives I
have are 2 9G atlases connected to the 2940. All 2.2.17 kernels I've
tried work fine. OTOH, every linux-pmac-stable 2.2.18preX kernel
panics just as it is beginning to register (poll? discover?) the SCSI
devices, at the same place where 2.2.17 properly recognizes the 2
drives and the 2940.

I have the pertinent debug info (backtrace, other registers,
System.map). Can I just post them here? I've never tried analyzing
one of these things. From what little sense I can make of it, it sure
looks like the panic has something to do with the aic7xxx code, or
related code. Roughly speaking, just after the fd0 (floppy) message
appears in the boot, I get :

Machine check in kernel mode
Caused by (from srr1): Unknown values in srr1
<debug info>
[kernel panic]

I'm compiling the kernel with default settings, other than including
the matrox driver. How might I compile the kernel differently w.r.t.
aic7xxx to try to nail this one down, if at all?

Once during the 2.2.17 linux-pmac-stable series, I got exactly this
srr1 error. I waited a couple of days and rsynced again and it was
gone. I always assumed that was due to some obscure bug creeping in
and then back out again. I feel in my bones this is the same
situation. I've written to Paul a couple of times about this, but I'm
sure to be low on his radar. Meanwhile, I rsync and try again each
day, without luck. BTW, I've tried this same troublesome 2.2.18
kernel on similar PowerTowerPro that I use and it works fine. That
PTP doesn't have a 2940 card in it, but it doesn't have all the PCI
slots filled either.

Any and all ideas welcome.


Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: whacked out 2.2.18pre21?

[Stefan Jeglinski]

in my original post, I said:

>but I am highly suspicious of
>the code involving the 2940UW card in the box. The -only- drives I
>have are 2 9G atlases connected to the 2940. All 2.2.17 kernels I've
>tried work fine. OTOH, every linux-pmac-stable 2.2.18preX kernel
>panics just as it is beginning to register (poll? discover?) the SCSI
>devices, at the same place where 2.2.17 properly recognizes the 2
>drives and the 2940.
>
>From what little sense I can make of it, it sure
>looks like the panic has something to do with the aic7xxx code, or
>related code. Roughly speaking, just after the fd0 (floppy) message
>appears in the boot, I get :
>
>Machine check in kernel mode
>Caused by (from srr1): Unknown values in srr1
><debug info>
>[kernel panic]

This is the same place in 2.2.17 where the 2940 card and my dual 9G
atlas drives are normally and successfully probed/discovered. Here is
the backtrace and the relevant sections from the System.map. I've
included the address before the backtrace value to the address after
the backtrace value, inclusive.

C000F508:
	c000f4f4 T ioremap
	c000f518 T __ioremap

C013CAC8:
	c013b454 t aic7xxx_load_seeprom
	c013c444 T aic7xxx_detect
	c013d9f8 t aic7xxx_allocate_negotiation_command

C01FABC0:
	c01fab0c T scsi_init
	c01fad08 T st_setup

C01FA8EC:
	c01fa840 T scsi_luns_setup
	c01fa884 T scsi_dev_init
	c01fab0c T scsi_init		[yes, same as above]

C01F6058:
	c01f6038 T device_setup
	c01f61ec T rd_init

C01EC9E4:
	c01ec910 t do_basic_setup
	c01ecafc T pmac_display_supported

C0004434:
	c0004420 t init
	c00045c8 T machine_restart

C00095EC:						[last in backtrace]
	c00095c0 T kernel_thread
	c00095f8 T idle


I hope I've presented the info in a way that can be used. Just an
answer or some clues would be helpful; what would be fantastic would
be a mini-tutorial on how to use this info to figure it out for
myself :-)

Looking at the above, there appears to be no reason to believe that
there was any problem in the scsi initialization? If so, why then did
I never get the boot messages about the 2940 and scsi devices?

Is "machine_restart" where the kernel panic says it will restart in
180 seconds?

As you may have guessed, I'm not in front of the box at this moment
to check it directly, but can I do a search through the source to
find, for example, "aic7xxx_detect"?

It almost looks like it went -through- the scsi setup fine and went
on to something else related to the display? Or is it possible that
my problems started all the way back at ioremap and finally caught up
with me?



Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: aic7xxx panic in 2.2.18pre21

[Hollis R Blanchard]

On Sat, 18 Nov 2000, Stefan Jeglinski wrote:
>
[snip]
>
> C000F508:
> 	c000f4f4 T ioremap
> 	c000f518 T __ioremap
>
> C013CAC8:
> 	c013b454 t aic7xxx_load_seeprom
> 	c013c444 T aic7xxx_detect
> 	c013d9f8 t aic7xxx_allocate_negotiation_command
>
> C01FABC0:
> 	c01fab0c T scsi_init
> 	c01fad08 T st_setup
>
> C01FA8EC:
> 	c01fa840 T scsi_luns_setup
> 	c01fa884 T scsi_dev_init
> 	c01fab0c T scsi_init		[yes, same as above]
>
> C01F6058:
> 	c01f6038 T device_setup
> 	c01f61ec T rd_init
>
> C01EC9E4:
> 	c01ec910 t do_basic_setup
> 	c01ecafc T pmac_display_supported
>
> C0004434:
> 	c0004420 t init
> 	c00045c8 T machine_restart
>
> C00095EC:						[last in backtrace]
> 	c00095c0 T kernel_thread
> 	c00095f8 T idle
>
[snip]
> As you may have guessed, I'm not in front of the box at this moment
> to check it directly, but can I do a search through the source to
> find, for example, "aic7xxx_detect"?
>
> It almost looks like it went -through- the scsi setup fine and went
> on to something else related to the display? Or is it possible that
> my problems started all the way back at ioremap and finally caught up
> with me?

The backtrace is in reverse order; the topmost item is the most recent
function called. So ioremap is crashing near the end, after being called
by aic7xxx_detect.

And yes, you can find aic7xxx_detect() in the
sources, probably in linux/drivers/scsi/aic7xxx.c

-Hollis


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: aic7xxx panic in 2.2.18pre21

[Stefan Jeglinski]

>  > C000F508:
>>	c000f4f4 T ioremap
>>	c000f518 T __ioremap
>>
>>  C013CAC8:
>>	c013b454 t aic7xxx_load_seeprom
>>	c013c444 T aic7xxx_detect
>  >	c013d9f8 t aic7xxx_allocate_negotiation_command

<snip>

>The backtrace is in reverse order; the topmost item is the most recent
>function called. So ioremap is crashing near the end, after being called
>by aic7xxx_detect.

And indeed, I just compiled a kernel without the aic7xxx driver. It
breezed right through the previous panic point and found the mesh
(internal) and external scsi busses, but of course could not mount
the root partition.


>And yes, you can find aic7xxx_detect() in the
>sources, probably in linux/drivers/scsi/aic7xxx.c


I'm off to find ioremap.c. What's the difference between ioremap and
__ioremap? Should I add kernel messages in ioremap.c to find out
exactly where the crash occurs? I assume if I diff the old (2.2.17)
versus new (2.2.18pre21) ioremap.c, the culprit will jump out pretty
quick? Or might the error be more subtle than that? Does anyone know
if ioremap.c has been the subject of a lot of changes recently? I
doubt seriously I can just take the old ioremap and use it in place
of the new...

Thanks Hollis. I feel a bit less helpless now...


Stefan Jeglinski


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: whacked out 2.2.18pre17? [partly solved]

[Stefan Jeglinski]

The problems were:

1: BootX no-video checkbox was being overridden, with twin turbo
video acceleration always turned on, regardless of checkbox setting.

2. 2.2.18pre17-18 never finished booting. Rsyncing each night led to
a different boot failure.


I now know how to work around #1. I have 2 video cards installed, a
Twin Turbo and a Matrox Mystique. It turns out that the kernel must
have support for -both- cards compiled in. If both are, then the
BootX no-video switch is -obeyed-. What I had done though was to stop
compiling in the matrox card, because it is never discovered during
boot, as measured by dmesg. Somewhere along the way, I forgot that I
quit compiling it in <oops>.

I don't know -why- this is true. But I'm pretty sure it didn't used
to be the case that I -had- to compile both drivers in.

As far as #2 goes, a rebuild of 2.2.18pre18 each night still fails on
boot, in a variety of ways previously noted:

	a) freeze at "booting..."
	b) can't find MAC address for MACE device -> kernel panic
	c) "machine check in kernel mode" -> "unknown values in srr1" ->
		kernel panic

a and c are now most prevalent. Haven't seen the MACE error for a few days.


Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: whacked out 2.2.18pre17?

[Tony Mantler]

At 11:53 PM -0600 11/2/2000, Stefan Jeglinski wrote:
>The second night, it booted, but the no video checkbox was somehow
>inverted in operation. IOW, with no video turned on (I have a twin
>turbo card, OFfb is my only choice in running X), I never get the
>OFfb driver, it always insists on loading the imsttfb driver, so X is
>impossible.

The IMS TT in my 9600/200mp has never given me any troubles at all with
imsttfb and X. The only quirk is that the dotclock values are off, but read
and write consistently and reliably.

This is using a Linus-2.2.17 with PCI and IDE patches, and the latest
debian-unstable packaging of X.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: whacked out 2.2.18pre17?

[Stefan Jeglinski]

>  >The second night, it booted, but the no video checkbox was somehow
>>inverted in operation. IOW, with no video turned on (I have a twin
>>turbo card, OFfb is my only choice in running X), I never get the
>>OFfb driver, it always insists on loading the imsttfb driver, so X is
>>impossible.
>
>The IMS TT in my 9600/200mp has never given me any troubles at all with
>imsttfb and X. The only quirk is that the dotclock values are off, but read
>and write consistently and reliably.
>
>This is using a Linus-2.2.17 with PCI and IDE patches, and the latest
>debian-unstable packaging of X.


Well, this is unlike most users of Twin Turbo cards, if the past list
traffic is any measure. Interestingly, I have seen comments before
that the issue is not the imsttfb driver, but X itself. This would
not be inconsistent with your setup, given the debian X. I would love
to get the twin turbo working, I have been waiting for X4 to get far
enough along, but it appears to still be lacking in even
straightforward atyfb support (debugged that is), as per the last I
read. Older ATI Rage Pro card(s) are what else I have, but it won't
do me any good to get one card working if another that I have breaks.


Stefan Jeglinski

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: whacked out 2.2.18pre17?

[Tony Mantler]

At 7:15 PM -0600 11/3/2000, Stefan Jeglinski wrote:
[...]
>Well, this is unlike most users of Twin Turbo cards, if the past list
>traffic is any measure. Interestingly, I have seen comments before
>that the issue is not the imsttfb driver, but X itself. This would
>not be inconsistent with your setup, given the debian X. I would love
>to get the twin turbo working, I have been waiting for X4 to get far
>enough along, but it appears to still be lacking in even
>straightforward atyfb support (debugged that is), as per the last I
>read. Older ATI Rage Pro card(s) are what else I have, but it won't
>do me any good to get one card working if another that I have breaks.

>From a kterm 5 seconds ago:

merida:~# cat /proc/fb
0 IMS TT (IBM)
merida:~# uname -a
Linux merida 2.2.17 #8 SMP Sun Oct 29 10:17:32 CST 2000 ppc unknown
merida:~# dpkg -l xserver-fbdev
[...]
ii  xserver-fbdev  3.3.6-11       X server for framebuffer-based graphics driv
merida:~# fbset -x

Mode "1280x1024"
	# D: 135.007 MHz, H: 102.278 kHz, v: 96.126 Hz
	DotClock 135.008
	HTimings 1280 1296 1304 1320
	VTimings 1024 1040 1048 1064
	Flags     "+HSync" "+VSync"
EndMode


Of course, the actual dotclock is really only 105.336 MHz (1280x1024x75Hz),
but the modeline works. 1280x1024x96Hz would be nice, mind you, but I don't
quite think my monitor could take it. ;)


I'm not holding my breath on XF4. I think the project is taking the '86'
part of XFree86 a little too seriously. X is a user program like any other,
it's not a special case where the dividing lines between userland and
kernelspace need to be trampled in broken x86-centric ways.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: whacked out 2.2.18pre17?

[Simon Piette]

Hi,

* Tony Mantler (nicoya@apia.dhs.org) [001103 21:14]:
>
> At 7:15 PM -0600 11/3/2000, Stefan Jeglinski wrote:
> [...]
> >Well, this is unlike most users of Twin Turbo cards, if the past list
> >traffic is any measure. Interestingly, I have seen comments before
> >that the issue is not the imsttfb driver, but X itself. This would
> >not be inconsistent with your setup, given the debian X. I would love
> >to get the twin turbo working, I have been waiting for X4 to get far
> >enough along, but it appears to still be lacking in even
> >straightforward atyfb support (debugged that is), as per the last I
> >read. Older ATI Rage Pro card(s) are what else I have, but it won't
> >do me any good to get one card working if another that I have breaks.
>
> >From a kterm 5 seconds ago:
>
> merida:~# cat /proc/fb
> 0 IMS TT (IBM)
> merida:~# uname -a
> Linux merida 2.2.17 #8 SMP Sun Oct 29 10:17:32 CST 2000 ppc unknown
> merida:~# dpkg -l xserver-fbdev
> [...]
> ii  xserver-fbdev  3.3.6-11       X server for framebuffer-based graphics driv
> merida:~# fbset -x
>
> Mode "1280x1024"
> 	# D: 135.007 MHz, H: 102.278 kHz, v: 96.126 Hz
> 	DotClock 135.008
> 	HTimings 1280 1296 1304 1320
> 	VTimings 1024 1040 1048 1064
> 	Flags     "+HSync" "+VSync"
> EndMode
>
>
> Of course, the actual dotclock is really only 105.336 MHz (1280x1024x75Hz),
> but the modeline works. 1280x1024x96Hz would be nice, mind you, but I don't
> quite think my monitor could take it. ;)
>

Could you elaborate on that? I have an IMSTT 128 (2Mb VRAM) and I'm
unable to accelerated video on a plain pmac kernel. I am currently stuck
at kernel 2.2.12 because this is the only kernel that will accept a
patch from Ryen Nielsen (http://krazynet.com/~ran/linux/imsttfb.c).
The last pmac I tried is 2.2.16

Here's some info about my system:

$ uname -a
Linux xim.dyndns.org 2.2.12-9a #2 Thu Jul 20 01:34:31 EDT 2000 ppc
unknown
$ cat /proc/cmdline
root=/dev/sdb6 video=imsttfb:vmode:17,cmode:16 idebus=66 hda=noautotune
$ lspci -vv
[snip]
00:0e.0 Display controller: Integrated Micro Solutions Inc. IMS9129 (rev 01)
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 8 min, 8 max, 32 set
        Interrupt: pin A routed to IRQ 24
        Region 0: Memory at 82000000
        (32-bit, prefetchable)
[snip]

Simon Piette
--
PGP key ID: 1024D/99290743 	Simon Piette <spiette@generation.net>
PGP Key fingerprint: 9AF9 33F9 A900 E153 9DF3  0625 8928 CB52 9929 0743

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: whacked out 2.2.18pre17?

[Tony Mantler]

At 6:35 AM -0600 11/4/2000, Simon Piette wrote:
[...]
>Could you elaborate on that? I have an IMSTT 128 (2Mb VRAM) and I'm
>unable to accelerated video on a plain pmac kernel. I am currently stuck
>at kernel 2.2.12 because this is the only kernel that will accept a
>patch from Ryen Nielsen (http://krazynet.com/~ran/linux/imsttfb.c).
>The last pmac I tried is 2.2.16

I'm not sure how much I can elaborate on it, since I've never actually
managed to get it to not work.


[...]
>$ cat /proc/cmdline
>root=/dev/sdb6 video=imsttfb:vmode:17,cmode:16 idebus=66 hda=noautotune

merida:~# cat /proc/cmdline
root=/dev/hde1 adb_buttons=113,107


>$ lspci -vv
>[snip]
>00:0e.0 Display controller: Integrated Micro Solutions Inc. IMS9129 (rev 01)
>        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
>ParErr- Stepping- SERR- FastB2B-
>        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
><TAbort- <MAbort- >SERR- <PERR-
>        Latency: 8 min, 8 max, 32 set
>        Interrupt: pin A routed to IRQ 24
>        Region 0: Memory at 82000000
>        (32-bit, prefetchable)

merida:~# lspci -vv
[...]
01:0f.0 Display controller: Integrated Micro Solutions Inc. IMS9129 [Twin
turbo 128] (rev 01)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
	Status: Cat- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (2000ns min, 2000ns max)
	Interrupt: pin A routed to IRQ 29
	Region 0: Memory at 92000000 (32-bit, prefetchable)
	Expansion ROM at 90000000 [disabled]
[...]

looking through /var/log/kern.log, we have...
[...]
MacOS display is /bandit/IMS,tt128mbA
Console: switching to colour frame buffer device 160x64
fb0: IMS TT (IBM) frame buffer; 4MB vram; chip version 2
[...]

And that's about it. I'm booting with BootX, by the way.


Cheers - Tony 'Nicoya' Mantler :)


--
Tony "Nicoya" Mantler - Renaissance Nerd Extraordinaire - nicoya@apia.dhs.org
Winnipeg, Manitoba, Canada           --           http://nicoya.feline.pp.se/


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/