LinuxLists.cc - BUG: 2.4.18 & ALI15X3 DMA hang on boot

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

>> There seems to be some fundamental incompatibility between the kernel
>> and the IDE chipset. On several kernels in the 2.4 series including
>> 2.4.18, I observe a hang in the bootsequence at:
>>
>> ALI15X3: IDE controller on PCI bus 00 dev 78
>> PCI: No IRQ known for interrupt pin A of device 00:0f.0. Please try using pc
>i=biosirq.
>> ALI15X3: chipset revision 195
>> ALI15X3: not 100% native mode: will probe irqs later
>> <hang>
>
>And does pci=bios help ?

pci=biosirq doesn't help. Same failure mode.

>The kernel can't find out how the IDE IRQ routing is happening.

I haven't tried reserving IRQs in the bios (which is possible, but too
much like blind search unless I get some more advice).

-John

2002-03-22 00:52:49

by Dave Zarzycki

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

On Thu, 21 Mar 2002, Alan Cox wrote:

> > There seems to be some fundamental incompatibility between the kernel
> > and the IDE chipset. On several kernels in the 2.4 series including
> > 2.4.18, I observe a hang in the bootsequence at:
> >
> > ALI15X3: IDE controller on PCI bus 00 dev 78
> > PCI: No IRQ known for interrupt pin A of device 00:0f.0. Please try using pci=biosirq.
> > ALI15X3: chipset revision 195
> > ALI15X3: not 100% native mode: will probe irqs later
> > <hang>
>
> And does pci=bios help ?

Nope. Neither does pci=biosirq.

I'm seeing the same problem on the Sony Vaio PictureBook C1MV/M.

Disabling the ALI 15X3 driver avoids the problem for me. If I can find
some free time, I'm going to start adding printf()s to see where things
are hanging...

davez

--
Dave Zarzycki
http://zarzycki.org/~dave/

2002-03-22 01:42:59

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

>Disabling the ALI 15X3 driver avoids the problem for me. If I can find
>some free time, I'm going to start adding printf()s to see where things
>are hanging...

I haven't tried that combination of options yet. I'll check tomorrow.

-John

2002-03-22 10:57:33

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

Alan Cox wrote:
>>There seems to be some fundamental incompatibility between the kernel
>>and the IDE chipset. On several kernels in the 2.4 series including
>>2.4.18, I observe a hang in the bootsequence at:
>>
>>ALI15X3: IDE controller on PCI bus 00 dev 78
>>PCI: No IRQ known for interrupt pin A of device 00:0f.0. Please try using pci=biosirq.
>>ALI15X3: chipset revision 195
>>ALI15X3: not 100% native mode: will probe irqs later
>><hang>
>
>
> And does pci=bios help ?

There is a but in this driver, where it is refferencing hwif->index instead
of hwif->channel. It may cause a hossed setup.

2002-03-22 11:26:15

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

Martin,

You go and play in 2.5, please.

The correct answer is ....

Because of the requirements of WinXP, where as NO resources can be
assigned to the device(PCI) until they are setup by the HOST OS, otherwise
it will skip the device since it will assume it already registered.

Since you are so knowledgeble about ATA, I am shocked that such as simple
concept and a requirement of WHQL (Windows Hardware Qualifications Lab)
tool kit is not in the front of you mind. Do yourself a favor, and go
learn about the hardware and what the REAL CUSTOMERS are requiring of it
and then come back to play. You are truly showing your total lack of
knowledge of the global hardware industry.

So please continue on the top layer interface that we both know you
clearly are better in implimentation, and one day I will come back and fix
the basics of the transport layer provided you leave something in tact.
By now if you or your friends understood the transport layer you would
have fixed it. Since there are hardware requirements that are not x86
centric under Linux, you may want to start considering a broader vision of
the driver.

The answer you all can not figure out and I will now take you to school so
you, Jens, Pavel, and Vojtech will learn something, gawd willing ...

Here is your hint.

HOW does the command block execution enter the data handler?
HOW does driver expect the data handler to be entered?

Please go look at -ac5 for a clue.

Now I would like to thank you for the clean ups you did and have borrowed
a few and will acknowledge the point.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Fri, 22 Mar 2002, Martin Dalecki wrote:

> Alan Cox wrote:
> >>There seems to be some fundamental incompatibility between the kernel
> >>and the IDE chipset. On several kernels in the 2.4 series including
> >>2.4.18, I observe a hang in the bootsequence at:
> >>
> >>ALI15X3: IDE controller on PCI bus 00 dev 78
> >>PCI: No IRQ known for interrupt pin A of device 00:0f.0. Please try using pci=biosirq.
> >>ALI15X3: chipset revision 195
> >>ALI15X3: not 100% native mode: will probe irqs later
> >><hang>
> >
> >
> > And does pci=bios help ?
>
> There is a but in this driver, where it is refferencing hwif->index instead
> of hwif->channel. It may cause a hossed setup.
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>

2002-03-22 11:52:01

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

Andre Hedrick wrote:
> Martin,
>
> You go and play in 2.5, please.

I didn't look at the issue but anyway the following is still
obviously wrong. hwif->index should be hwif->channel

Anyway please note the following:

diff -urN linux-2.5.7/drivers/ide/alim15x3.c linux/drivers/ide/alim15x3.c
--- linux-2.5.7/drivers/ide/alim15x3.c Thu Mar 21 23:54:16 2002
+++ linux/drivers/ide/alim15x3.c Fri Mar 22 02:08:58 2002
@@ -247,8 +247,8 @@
int s_time, a_time, c_time;
byte s_clc, a_clc, r_clc;
unsigned long flags;
int port = hwif->index ? 0x5c : 0x58;
int portFIFO = hwif->channel ? 0x55 : 0x54;

The usage of hwif->index *is* wrong.

2002-03-22 13:26:50

by Jens Axboe

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

On Fri, Mar 22 2002, Andre Hedrick wrote:
> The answer you all can not figure out and I will now take you to school so
> you, Jens, Pavel, and Vojtech will learn something, gawd willing ...

Please get off the drugs and the mighty high chair you put yourself on.
Last I checked, most of the teaching went in the opposite direction.

Your attitude makes me sick. Time for my very first kill file entry,
ever.

--
Jens Axboe

2002-03-22 14:34:15

by Alan

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

> Since you are so knowledgeble about ATA, I am shocked that such as simple

Where did Martin ever claim that ?

> concept and a requirement of WHQL (Windows Hardware Qualifications Lab)
> tool kit is not in the front of you mind. Do yourself a favor, and go
> learn about the hardware and what the REAL CUSTOMERS are requiring of it
> and then come back to play. You are truly showing your total lack of
> knowledge of the global hardware industry.

He's trying to learn. Imagine if learning to drive consisted of someone
with a megaphone telling you you'll fail and doing nothing but laugh when
you crash ?

Now why do you think it'll work any better for IDE ?

2002-03-22 15:59:07

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

> int port = hwif->index ? 0x5c : 0x58;
> int portFIFO = hwif->channel ? 0x55 : 0x54;
>
>The usage of hwif->index *is* wrong.

Switching hwif->index to hwif->channel doesn't help here - same
failure mode.

I've confirmed that the problem is isolated to
"CONFIG_BLK_DEV_ALI15X3=y" as Dave suggested.

Any other ideas?

-John

2002-03-22 19:56:04

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

I went nuts with printk statements and managed to isolate the hang to
one particular line of code. The final printk in this code fragment
never gets executed.

} else if (m5229_revision >= 0xC3) {
/*
* 1553/1535 (m1533, 0x79, bit 1)
*/
printk("ata66_ali15x3 } else if (m5229_revisi\on >= 0xC3) {\n");
pci_write_config_byte(isa_dev, 0x79, tmpbyte | 0x02);
}
printk("ata66_ali15x3 endif\n");

Art, Dave, and Ben may or may not have the same problem. It would be
interesting to know if they get a hang here.

Any ideas for fixing?

-John

2002-03-22 20:46:11

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

I did a small tweak and "it seems to work". I have no idea whether or
not this breaks other configs.

-John

--- linux/drivers/ide/alim15x3.c Sun Jul 15 19:22:23 2001
+++ linux-2.4.18-hack/drivers/ide/alim15x3.c Fri Mar 22 12:31:28 2002
@@ -574,17 +574,7 @@
* set south-bridge's enable bit, m1533, 0x79
*/
pci_read_config_byte(isa_dev, 0x79, &tmpbyte);
- if (m5229_revision == 0xC2) {
- /*
- * 1543C-B0 (m1533, 0x79, bit 2)
- */
- pci_write_config_byte(isa_dev, 0x79, tmpbyte | 0x04);
- } else if (m5229_revision >= 0xC3) {
- /*
- * 1553/1535 (m1533, 0x79, bit 1)
- */
- pci_write_config_byte(isa_dev, 0x79, tmpbyte | 0x02);
- }
+ pci_write_config_byte(isa_dev, 0x79, tmpbyte | 0x04);
/*
* Ultra66 cable detection (from Host View)
* m5229, 0x4a, bit0: primary, bit1: secondary 80 pin

2002-03-22 20:55:22

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

On Fri, 22 Mar 2002, Alan Cox wrote:

> > Since you are so knowledgeble about ATA, I am shocked that such as simple
>
> Where did Martin ever claim that ?

Recall his comments during the clean up stages of where he had studied
many other OS's ATA/ATAPI sub systems. This clearly indicates one has or
is presenting themselves withe a deep understanding if the issues. One
should recall the comments of comparing "taskfile" to MS Windows API.
Since he has clearly pointed out the useless nature of the IOCTL and
removed it in 2.5, he must have a better means of diagnotsics and testing
than the rest of the industry. So I am waiting on pins and needles for
this evolution to reveal itself.

> > concept and a requirement of WHQL (Windows Hardware Qualifications Lab)
> > tool kit is not in the front of you mind. Do yourself a favor, and go
> > learn about the hardware and what the REAL CUSTOMERS are requiring of it
> > and then come back to play. You are truly showing your total lack of
> > knowledge of the global hardware industry.
>
> He's trying to learn. Imagine if learning to drive consisted of someone
> with a megaphone telling you you'll fail and doing nothing but laugh when
> you crash ?
>
> Now why do you think it'll work any better for IDE ?

Point taken and agreed, so as long has Mr. Dalecki will agree to a point
of peace, we can move forward. Obviously there is much about the top
layer interface to the kernel that is not significant to me at this point,
and he has a stronger grasp than I have an interest. However the mockery
of my knowledge of the physical/host transport is not acceptable. I am
perfectly will and agreeable to grant and give him the respect deserved,
but I also expect and require the same.

Regards,

Andre Hedrick
LAD Storage Consulting Group

2002-03-22 21:53:41

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

Alan,

I sent this out a heart beat early.

To totally clarify the very last part, this a standing offer of PEACE.
So if it is not accepted, the offer still stands. Since I will most
likely be migrating into other storage areas, the object and goal of
"Taskfile" was to leave and infrastructure which totally described the
sub-system in closed form. I had hoped to finish it before the transition
out of the development kernel happened but oh well, things did not work
out as planned.

If Martin will permit I will fix the transport, otherwise I can not tied
to it. This will require him forcing the BLOCK layer to be modified per
the model that Suparna and I co-authored. This will benefit many other
devices.

The closing point is that I can flush the ego, and work w/ Martin.
He has a strong and weak suit just as I do. The difference and benefit is
they oddly compliment.

Your serve Martin, volley up.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

On Fri, 22 Mar 2002, Andre Hedrick wrote:

> On Fri, 22 Mar 2002, Alan Cox wrote:
>
> > > Since you are so knowledgeble about ATA, I am shocked that such as simple
> >
> > Where did Martin ever claim that ?
>
> Recall his comments during the clean up stages of where he had studied
> many other OS's ATA/ATAPI sub systems. This clearly indicates one has or
> is presenting themselves withe a deep understanding if the issues. One
> should recall the comments of comparing "taskfile" to MS Windows API.
> Since he has clearly pointed out the useless nature of the IOCTL and
> removed it in 2.5, he must have a better means of diagnotsics and testing
> than the rest of the industry. So I am waiting on pins and needles for
> this evolution to reveal itself.
>
> > > concept and a requirement of WHQL (Windows Hardware Qualifications Lab)
> > > tool kit is not in the front of you mind. Do yourself a favor, and go
> > > learn about the hardware and what the REAL CUSTOMERS are requiring of it
> > > and then come back to play. You are truly showing your total lack of
> > > knowledge of the global hardware industry.
> >
> > He's trying to learn. Imagine if learning to drive consisted of someone
> > with a megaphone telling you you'll fail and doing nothing but laugh when
> > you crash ?
> >
> > Now why do you think it'll work any better for IDE ?
>
> Point taken and agreed, so as long has Mr. Dalecki will agree to a point
> of peace, we can move forward. Obviously there is much about the top
> layer interface to the kernel that is not significant to me at this point,
> and he has a stronger grasp than I have an interest. However the mockery
> of my knowledge of the physical/host transport is not acceptable. I am
> perfectly will and agreeable to grant and give him the respect deserved,
> but I also expect and require the same.
>
> Regards,
>
> Andre Hedrick
> LAD Storage Consulting Group
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

2002-03-22 21:55:12

by Vojtech Pavlik

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

On Fri, Mar 22, 2002 at 02:56:43PM -0500, John Langford wrote:

> I went nuts with printk statements and managed to isolate the hang to
> one particular line of code. The final printk in this code fragment
> never gets executed.
>
> } else if (m5229_revision >= 0xC3) {
> /*
> * 1553/1535 (m1533, 0x79, bit 1)
> */
> printk("ata66_ali15x3 } else if (m5229_revisi\on >= 0xC3) {\n");
> pci_write_config_byte(isa_dev, 0x79, tmpbyte | 0x02);
> }
> printk("ata66_ali15x3 endif\n");
>
> Art, Dave, and Ben may or may not have the same problem. It would be
> interesting to know if they get a hang here.
>
> Any ideas for fixing?

What happens if you just remove the pci_write_config_byte() call?
It should be pretty harmless to remove it (on normal systems).

--
Vojtech Pavlik
SuSE Labs

2002-03-23 03:46:02

by Ian Molton

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

Andre Hedrick wrote ...

<cut>
> [respect] but I also expect and require the same.

Im not an IDE coder, but I've had to work through your IDE code before now,
and its fugly.

Im not a violent man, but I suspect if I ever met you the only respect
you'd see from me would come from the toe of my boot and leave through your
throat.

Your attitude to the programmers trying to WORK on the ide code frankly
disgusts me.

I dont like to speak out like this, but I feel I must. Sorry to anyone on
LKML who has /real/ hacking to do.

2002-03-23 03:51:42

by Ian Molton

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

Ian Molton wrote...

> Andre Hedrick wrote ...
>

Oopsie. moment of passion there. I think I degraded myself. sorry.

2002-03-23 05:17:55

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

On Fri, 22 Mar 2002, Martin Dalecki wrote:

> I didn't look at the issue but anyway the following is still
> obviously wrong. hwif->index should be hwif->channel
>
> Anyway please note the following:
>
> diff -urN linux-2.5.7/drivers/ide/alim15x3.c linux/drivers/ide/alim15x3.c
> --- linux-2.5.7/drivers/ide/alim15x3.c Thu Mar 21 23:54:16 2002
> +++ linux/drivers/ide/alim15x3.c Fri Mar 22 02:08:58 2002
> @@ -247,8 +247,8 @@
> int s_time, a_time, c_time;
> byte s_clc, a_clc, r_clc;
> unsigned long flags;
> int port = hwif->index ? 0x5c : 0x58;
> int portFIFO = hwif->channel ? 0x55 : 0x54;
>
> The usage of hwif->index *is* wrong.

I stand corrected, it is a real bug and I let it slip in from the
ali.com.tw folks. I recant the point and error here is mine.

However, one should note this would only be found if a person was booting
an add-in card. This is why it has masked its self for so long. Now the
much harder issue trace is the following. So I am impressed that you
caught this very tiny bug that would be big and messy later. Tip of the
hat to you.

Noting that in the special case of who/what is allowed to have access to
"ide0/ide1" this is an onboard host and generally would have the results:

hwif->index == hwif->channel

If and only if the host had rights and priviledges to "ide0/ide1", would
it be masked.

So as the previous offer still stands point to have peace again, I am
still waiting for a reply on are going to be able to work through the
inital bumps an bangs from the beginning.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

2002-03-23 13:13:13

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

John Langford wrote:
> I went nuts with printk statements and managed to isolate the hang to
> one particular line of code. The final printk in this code fragment
> never gets executed.
>
> } else if (m5229_revision >= 0xC3) {
> /*
> * 1553/1535 (m1533, 0x79, bit 1)
> */
> printk("ata66_ali15x3 } else if (m5229_revisi\on >= 0xC3) {\n");
> pci_write_config_byte(isa_dev, 0x79, tmpbyte | 0x02);

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

pci_write_config to isa_dev???? This looks at least suspicious.
You may very well check whatever isa_dev is trully a PCI device
handle or just some random IO base for ISA bus!

> }
> printk("ata66_ali15x3 endif\n");
>
> Art, Dave, and Ben may or may not have the same problem. It would be
> interesting to know if they get a hang here.
>
> Any ideas for fixing?

See above :-)

2002-03-23 13:07:53

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

Andre Hedrick wrote:
> On Fri, 22 Mar 2002, Martin Dalecki wrote:
>
>
>>I didn't look at the issue but anyway the following is still
>>obviously wrong. hwif->index should be hwif->channel
>>
>>Anyway please note the following:
>>
>>diff -urN linux-2.5.7/drivers/ide/alim15x3.c linux/drivers/ide/alim15x3.c
>>--- linux-2.5.7/drivers/ide/alim15x3.c Thu Mar 21 23:54:16 2002
>>+++ linux/drivers/ide/alim15x3.c Fri Mar 22 02:08:58 2002
>>@@ -247,8 +247,8 @@
>> int s_time, a_time, c_time;
>> byte s_clc, a_clc, r_clc;
>> unsigned long flags;
>> int port = hwif->index ? 0x5c : 0x58;
>> int portFIFO = hwif->channel ? 0x55 : 0x54;
>>
>>The usage of hwif->index *is* wrong.
>
>
> I stand corrected, it is a real bug and I let it slip in from the
> ali.com.tw folks. I recant the point and error here is mine.
>
> However, one should note this would only be found if a person was booting
> an add-in card. This is why it has masked its self for so long. Now the
> much harder issue trace is the following. So I am impressed that you
> caught this very tiny bug that would be big and messy later. Tip of the
> hat to you.
>
> Noting that in the special case of who/what is allowed to have access to
> "ide0/ide1" this is an onboard host and generally would have the results:
>
> hwif->index == hwif->channel

Yes right of course. Becouse the values in index are consecutive 0,1,2
and so on... and fortunately the channels are discriminated by
the very same values 0,1.

> If and only if the host had rights and priviledges to "ide0/ide1", would
> it be masked.
>
> So as the previous offer still stands point to have peace again, I am
> still waiting for a reply on are going to be able to work through the
> inital bumps an bangs from the beginning.

Ehhhh beleve me or not. At least I was *never* at war with you.
There is a difference between supporting my own opinnions and
having some disagreements then making *war* at somebody :-).

(I'm a European!!!)

2002-03-23 13:27:03

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

John Langford wrote:
> I did a small tweak and "it seems to work". I have no idea whether or
> not this breaks other configs.
>
> -John
>
> --- linux/drivers/ide/alim15x3.c Sun Jul 15 19:22:23 2001
> +++ linux-2.4.18-hack/drivers/ide/alim15x3.c Fri Mar 22 12:31:28 2002
> @@ -574,17 +574,7 @@
> * set south-bridge's enable bit, m1533, 0x79
> */
> pci_read_config_byte(isa_dev, 0x79, &tmpbyte);
> - if (m5229_revision == 0xC2) {
> - /*
> - * 1543C-B0 (m1533, 0x79, bit 2)
> - */
> - pci_write_config_byte(isa_dev, 0x79, tmpbyte | 0x04);
> - } else if (m5229_revision >= 0xC3) {
> - /*
> - * 1553/1535 (m1533, 0x79, bit 1)
> - */
> - pci_write_config_byte(isa_dev, 0x79, tmpbyte | 0x02);
> - }
> + pci_write_config_byte(isa_dev, 0x79, tmpbyte | 0x04);
> /*
> * Ultra66 cable detection (from Host View)
> * m5229, 0x4a, bit0: primary, bit1: secondary 80 pin

According to the fact that this is setting the enable bit
of the south bridge on this host, the issue appears to be
not tactile. (If your fix where wrong, your system would simply
not work at all.) I will therefore just simply take this patch as
it is... And then I couldn't find any other places
where the 0x02 bit would be used on register 0x79.

Possibly someone just misscounted the bits reading some
errate for different reviaions... or just the errata was wrong.

But before could you just tell the m5229_revision value
on your system?

2002-03-23 13:45:18

by Jeff Garzik

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

Martin Dalecki wrote:

> John Langford wrote:
>
>> I went nuts with printk statements and managed to isolate the hang to
>> one particular line of code. The final printk in this code fragment
>> never gets executed.
>> } else if (m5229_revision >= 0xC3) {
>> /*
>> * 1553/1535 (m1533, 0x79, bit 1)
>> */
>> printk("ata66_ali15x3 } else if
>> (m5229_revisi\on >= 0xC3) {\n");
>> pci_write_config_byte(isa_dev, 0x79, tmpbyte
>> | 0x02);
>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
> pci_write_config to isa_dev???? This looks at least suspicious.
> You may very well check whatever isa_dev is trully a PCI device
> handle or just some random IO base for ISA bus!

Nope, look at the code and comments around "isa_dev" :)

isa_dev is the PCI device structure for the ALi ISA bridge... very
definitely a PCI device.

some background:
It is normal in some situations that you need to examine or set PCI
config registers for the ISA bridge, when dealing with some IDE
motherboards. The southbridge is typically the chip that actually
implements IDE on your motherboard. Even though IDE is normally
exported as a separate PCI device, you still have to deal with the ATA
register blocks at hardcoded legacy ISA addresses 0x1f0 and 0x170. So,
when you write the ATA registers for channel 0 or channel 1, you are
writing to 0x1f? or 0x17?, the ISA bridge is most likely the portion of
the southbridge chip actually decoding those addresses for you.

Jeff

2002-03-23 13:48:58

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

Jeff Garzik wrote:
> Martin Dalecki wrote:
>
>> John Langford wrote:
>>
>>> I went nuts with printk statements and managed to isolate the hang to
>>> one particular line of code. The final printk in this code fragment
>>> never gets executed. } else if (m5229_revision >=
>>> 0xC3) {
>>> /*
>>> * 1553/1535 (m1533, 0x79, bit 1)
>>> */
>>> printk("ata66_ali15x3 } else if
>>> (m5229_revisi\on >= 0xC3) {\n");
>>> pci_write_config_byte(isa_dev, 0x79, tmpbyte
>>> | 0x02);
>>
>>
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>
>> pci_write_config to isa_dev???? This looks at least suspicious.
>> You may very well check whatever isa_dev is trully a PCI device
>> handle or just some random IO base for ISA bus!
>
>
>
> Nope, look at the code and comments around "isa_dev" :)

OK OK - this was just a blind guess without looking at the actual
code :-).

> isa_dev is the PCI device structure for the ALi ISA bridge... very
> definitely a PCI device.

Sure i know.

> some background:
> It is normal in some situations that you need to examine or set PCI
> config registers for the ISA bridge, when dealing with some IDE
> motherboards. The southbridge is typically the chip that actually
> implements IDE on your motherboard. Even though IDE is normally
> exported as a separate PCI device, you still have to deal with the ATA
> register blocks at hardcoded legacy ISA addresses 0x1f0 and 0x170. So,
> when you write the ATA registers for channel 0 or channel 1, you are
> writing to 0x1f? or 0x17?, the ISA bridge is most likely the portion of
> the southbridge chip actually decoding those addresses for you.

Thank you for elaborating on this, but I did already know this...

2002-03-23 14:20:24

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

>But before could you just tell the m5229_revision value
>on your system?

I'm not sure what you mean. Certainly, lspci says:

>00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c3) (prog-if fa)
^^^^^^^^

-John

2002-03-23 14:24:25

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

John Langford wrote:
>>But before could you just tell the m5229_revision value
>>on your system?
>
>
> I'm not sure what you mean. Certainly, lspci says:
>
>
>>00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c3)

That's it. Thank you.

2002-03-23 14:40:58

by Art Haas

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

On Sat, Mar 23, 2002 at 03:22:26PM +0100, Martin Dalecki wrote:
> John Langford wrote:
> >>But before could you just tell the m5229_revision value
> >>on your system?
> >
> >I'm not sure what you mean. Certainly, lspci says:
> >
> >
> >>00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c3)
>
> That's it. Thank you.
>

Hi.

I've been 'cc'd on the mail going to John Langford and everyone else
having trouble with the alim15x3 driver. As another data point, here's
what my machine has ...

$ lspci -vv
00:00.0 Host bridge: Acer Laboratories Inc. [ALi] M1531 [Aladdin IV] (rev b3)
Subsystem: Acer Laboratories Inc. [ALi] M1531 [Aladdin IV]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 32

00:02.0 ISA bridge: Acer Laboratories Inc. [ALi] M1533 PCI to ISA Bridge [Aladdin IV] (rev b4)
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: 0

00:05.0 VGA compatible controller: S3 Inc. ViRGE/DX or /GX (rev 01) (prog-if 00 [VGA])
Subsystem: S3 Inc. ViRGE/DX
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: 64 (1000ns min, 63750ns max)
Interrupt: pin A routed to IRQ 0
Region 0: Memory at ec000000 (32-bit, non-prefetchable) [size=64M]
Expansion ROM at ebff0000 [disabled] [size=64K]

00:0b.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev 20) (prog-if fa)
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: 32 (500ns min, 1000ns max)
Interrupt: pin A routed to IRQ 14
Region 4: I/O ports at ffa0 [size=16]
$

I'm currently running 2.4.19-pre3-ac6, and when I boot I've added "pci=biosirq"
to the command line.

--
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
-- Benjamin Franklin, Historical Review of Pennsylvania, 1759

2002-03-23 19:52:35

by Dave Zarzycki

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

On Sat, 23 Mar 2002, Martin Dalecki wrote:

> John Langford wrote:
> >>But before could you just tell the m5229_revision value
> >>on your system?
> > I'm not sure what you mean. Certainly, lspci says:
> >>00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c3)
>
> That's it. Thank you.

To add another data-point, I've been seeing the same problem on a rev c4
version of device.

davez

--
Dave Zarzycki
http://zarzycki.org/~dave/

2002-03-23 20:24:36

by Vojtech Pavlik

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

On Sat, Mar 23, 2002 at 02:11:21PM +0100, Martin Dalecki wrote:
> John Langford wrote:
> > I went nuts with printk statements and managed to isolate the hang to
> > one particular line of code. The final printk in this code fragment
> > never gets executed.
> >
> > } else if (m5229_revision >= 0xC3) {
> > /*
> > * 1553/1535 (m1533, 0x79, bit 1)
> > */
> > printk("ata66_ali15x3 } else if (m5229_revisi\on >= 0xC3) {\n");
> > pci_write_config_byte(isa_dev, 0x79, tmpbyte | 0x02);
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> pci_write_config to isa_dev???? This looks at least suspicious.
> You may very well check whatever isa_dev is trully a PCI device
> handle or just some random IO base for ISA bus!

You may wanted to check yourself:

isa_dev = pci_find_device(PCI_VENDOR_ID_AL, PCI_DEVICE_ID_AL_M1533, NULL);

so the command is valid.

> > printk("ata66_ali15x3 endif\n");
> >
> > Art, Dave, and Ben may or may not have the same problem. It would be
> > interesting to know if they get a hang here.
> >
> > Any ideas for fixing?
>
> See above :-)

--
Vojtech Pavlik
SuSE Labs

2002-03-23 21:44:25

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

On Sat, 23 Mar 2002, Martin Dalecki wrote:

> John Langford wrote:
> > I went nuts with printk statements and managed to isolate the hang to
> > one particular line of code. The final printk in this code fragment
> > never gets executed.
> >
> > } else if (m5229_revision >= 0xC3) {
> > /*
> > * 1553/1535 (m1533, 0x79, bit 1)
> > */
> > printk("ata66_ali15x3 } else if (m5229_revisi\on >= 0xC3) {\n");
> > pci_write_config_byte(isa_dev, 0x79, tmpbyte | 0x02);
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> pci_write_config to isa_dev???? This looks at least suspicious.
> You may very well check whatever isa_dev is trully a PCI device
> handle or just some random IO base for ISA bus!

Martin, recall the WinXP issue on resources. This is that hook. I will
try to get more details out of the US base ALI people in a few days.

Just a heads up, 95% of all hosts have hooks in function zero of the
southbridge. This is why I commented the other day about a perferred
ruleset of device hunting.

> > }
> > printk("ata66_ali15x3 endif\n");
> >
> > Art, Dave, and Ben may or may not have the same problem. It would be
> > interesting to know if they get a hang here.
> >
> > Any ideas for fixing?
>
> See above :-)

I have now several reports about Transmeta LifeBooks that are doing things
bad and not conforming to the docs. This is not good.

Regards,

Andre Hedrick
LAD Storage Consulting Group

2002-03-24 22:49:41

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

Dave Zarzycki wrote:
> On Sat, 23 Mar 2002, Martin Dalecki wrote:
>
>
>>John Langford wrote:
>>
>>>>But before could you just tell the m5229_revision value
>>>>on your system?
>>>
>>>I'm not sure what you mean. Certainly, lspci says:
>>>
>>>>00:0f.0 IDE interface: Acer Laboratories Inc. [ALi] M5229 IDE (rev c3)
>>>
>>That's it. Thank you.
>
>
> To add another data-point, I've been seeing the same problem on a rev c4
> version of device.

Thank's - that makes the picture complete.

2002-03-24 22:52:01

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

Andre Hedrick wrote:

> I have now several reports about Transmeta LifeBooks that are doing things
> bad and not conforming to the docs. This is not good.

Do they use the same design cells for ATA as ALI?
That's interresting.

2002-03-25 01:27:17

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

On Sun, 24 Mar 2002, Martin Dalecki wrote:

> Andre Hedrick wrote:
>
>
> > I have now several reports about Transmeta LifeBooks that are doing things
> > bad and not conforming to the docs. This is not good.
>
> Do they use the same design cells for ATA as ALI?
> That's interresting.

You got it!

Ones with profiles that should work in the current driver.
They are all C3 or C4 revisions function 1 and have a proper ISA mapping.
So unless this is a new SB core which has moved the enable hook or it is
an old one which has done the same ... well the mess is obvious.

Cheers,

Andre Hedrick
LAD Storage Consulting Group

2002-03-25 02:27:37

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

On Sat, 23 Mar 2002, Martin Dalecki wrote:

> > inital bumps an bangs from the beginning.
>
> Ehhhh beleve me or not. At least I was *never* at war with you.
> There is a difference between supporting my own opinnions and
> having some disagreements then making *war* at somebody :-).
>
> (I'm a European!!!)

Cool !!

(I'm a pissen!!!) but not anymore. ;-)

Cheers,

Andre Hedrick
LAD Storage Consulting Group

2002-03-25 09:25:41

by Vojtech Pavlik

[permalink] [raw]

Subject: Re: BUG: 2.4.18 & ALI15X3 DMA hang on boot

On Sun, Mar 24, 2002 at 05:26:23PM -0800, Andre Hedrick wrote:
> On Sun, 24 Mar 2002, Martin Dalecki wrote:
>
> > Andre Hedrick wrote:
> >
> >
> > > I have now several reports about Transmeta LifeBooks that are doing things
> > > bad and not conforming to the docs. This is not good.
> >
> > Do they use the same design cells for ATA as ALI?
> > That's interresting.
>
> You got it!
>
> Ones with profiles that should work in the current driver.
> They are all C3 or C4 revisions function 1 and have a proper ISA mapping.
> So unless this is a new SB core which has moved the enable hook or it is
> an old one which has done the same ... well the mess is obvious.

>From the lspci's I've seen, this looks like the LifeBooks, although
using the Crusoe chip with integrated northbridge, are using a standard
ALI southbridge - not a design of their own with licensed cells.

--
Vojtech Pavlik
SuSE Labs

2002-03-25 09:42:19