Alan,
2.4.19-rc3-ac1 hangs on boot on my laptop (Fujitsu P-series, TM5800
CPU), whereas plain[1] rc3 boots fine. The hang appears to be during IDE
detection:
...
block: 704 slots per queue, batch=176
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=XX
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
With rc-3, I get this same error unless I have 'ide0=ata66 ide1=ata66'
on the kernel command line. However, -ac1 hangs with or without these
options.
[1] Actually, two one-liner patches... one to extend the ext3 journal
commit interval to 30 seconds, and another to fix suspend issues in
sound/trident.c.
On Wed, Jul 24, 2002 at 09:16:05AM -0400, Ian Soboroff wrote:
[snipped]
> [1] Actually, two one-liner patches... one to extend the ext3 journal
> commit interval to 30 seconds, and another to fix suspend issues in
> sound/trident.c.
what's the suspend issue with trident.c?
--
http://vipe.technion.ac.il/~mulix/
http://syscalltrack.sf.net/
Muli Ben-Yehuda <[email protected]> writes:
> On Wed, Jul 24, 2002 at 09:16:05AM -0400, Ian Soboroff wrote:
>
> [snipped]
>
> > [1] Actually, two one-liner patches... one to extend the ext3 journal
> > commit interval to 30 seconds, and another to fix suspend issues in
> > sound/trident.c.
>
> what's the suspend issue with trident.c?
Haven't witnessed personally. Reference web pages (from Linux on
Laptops) are
http://www.geocities.com/robm351/lifebook/ and
http://www4.ncsu.edu/~tscoffe2/Fujitsu/
Apparently there is a problem with losing sound after a suspend.
Another reported fix is to reload the trident.o module. The patch I
use (credited to Eric Lemar) is:
--- linux/drivers/sound/trident.c Thu Mar 28 16:08:51 2002
+++ linux/drivers/sound/trident_new.c Thu Mar 28 16:11:20 2002
@@ -3456,7 +3456,7 @@
static int trident_suspend(struct pci_dev *dev, u32 unused)
{
- struct trident_card *card = (struct trident_card *) dev;
+ struct trident_card *card = pci_get_drvdata(dev);
if(card->pci_id == PCI_DEVICE_ID_ALI_5451) {
ali_save_regs(card);
@@ -3466,7 +3466,7 @@
static int trident_resume(struct pci_dev *dev)
{
- struct trident_card *card = (struct trident_card *) dev;
+ struct trident_card *card = pci_get_drvdata(dev);
if(card->pci_id == PCI_DEVICE_ID_ALI_5451) {
ali_restore_regs(card);
On 24 Jul 2002, Ian Soboroff wrote:
> static int trident_suspend(struct pci_dev *dev, u32 unused)
> {
> - struct trident_card *card = (struct trident_card *) dev;
> + struct trident_card *card = pci_get_drvdata(dev);
>
> if(card->pci_id == PCI_DEVICE_ID_ALI_5451) {
> ali_save_regs(card);
> @@ -3466,7 +3466,7 @@
>
> static int trident_resume(struct pci_dev *dev)
> {
> - struct trident_card *card = (struct trident_card *) dev;
> + struct trident_card *card = pci_get_drvdata(dev);
>
> if(card->pci_id == PCI_DEVICE_ID_ALI_5451) {
> ali_restore_regs(card);
Thats definitely correct, has this patch been sent to lkml before?
Cheers,
Zwane
--
function.linuxpower.ca
Zwane Mwaikambo <[email protected]> writes:
> On 24 Jul 2002, Ian Soboroff wrote:
>
> > static int trident_suspend(struct pci_dev *dev, u32 unused)
> > {
> > - struct trident_card *card = (struct trident_card *) dev;
> > + struct trident_card *card = pci_get_drvdata(dev);
> >
> > if(card->pci_id == PCI_DEVICE_ID_ALI_5451) {
> > ali_save_regs(card);
> > @@ -3466,7 +3466,7 @@
> >
> > static int trident_resume(struct pci_dev *dev)
> > {
> > - struct trident_card *card = (struct trident_card *) dev;
> > + struct trident_card *card = pci_get_drvdata(dev);
> >
> > if(card->pci_id == PCI_DEVICE_ID_ALI_5451) {
> > ali_restore_regs(card);
>
> Thats definitely correct, has this patch been sent to lkml before?
I didn't see it in a quick search at the uwsg.ia.edu archive. The
last ALi patch I see on 2.4 seems to come from Matt Wu at ALi on
4/4/2001.
Anyone have a clue on the IDE part of my question? ;-)
ian
On 24 Jul 2002, Ian Soboroff wrote:
> Anyone have a clue on the IDE part of my question? ;-)
Oh.. yeah that, erm dunno. Hopefully someone with an idea will chime in
soon.
Cheers,
Zwane
Or.. you can try find the last working -ac
--
function.linuxpower.ca
Zwane Mwaikambo <[email protected]> writes:
> On 24 Jul 2002, Ian Soboroff wrote:
>
> > Anyone have a clue on the IDE part of my question? ;-)
>
> Oh.. yeah that, erm dunno. Hopefully someone with an idea will chime in
> soon.
>
> Cheers,
> Zwane
>
> Or.. you can try find the last working -ac
I also had trouble with rc2-ac2. I know Andre's been pushing IDE
changes through Alan, and from a quick scan through the rc3-ac1 patch
there's quite a bit of change in drivers/ide/alim15x3.c.
>From Alan's changelog, it looks like there were "ALi IDE hang fixes"
from Sen Dong in pre4-ac4 that were never pushed to Marcelo (according
to the changelog).
ian
On Wed, Jul 24, 2002 at 10:57:14AM -0400, Ian Soboroff wrote:
> Zwane Mwaikambo <[email protected]> writes:
>
> > On 24 Jul 2002, Ian Soboroff wrote:
> >
> > > static int trident_suspend(struct pci_dev *dev, u32 unused)
> > > {
> > > - struct trident_card *card = (struct trident_card *) dev;
> > > + struct trident_card *card = pci_get_drvdata(dev);
> > >
> > > if(card->pci_id == PCI_DEVICE_ID_ALI_5451) {
> > > ali_save_regs(card);
> > > @@ -3466,7 +3466,7 @@
> > >
> > > static int trident_resume(struct pci_dev *dev)
> > > {
> > > - struct trident_card *card = (struct trident_card *) dev;
> > > + struct trident_card *card = pci_get_drvdata(dev);
> > >
> > > if(card->pci_id == PCI_DEVICE_ID_ALI_5451) {
> > > ali_restore_regs(card);
> >
> > Thats definitely correct, has this patch been sent to lkml before?
>
> I didn't see it in a quick search at the uwsg.ia.edu archive. The
> last ALi patch I see on 2.4 seems to come from Matt Wu at ALi on
> 4/4/2001.
There have been various updates to trident.c in the -ac tree lately,
from Lei Hu and myself. It is my understanding that Alan Cox will push
them to 2.4 when 2.4.20 opens up.
This patch is obviously corrrect, and I'll send it to Alan if no one
has done it yet.
> Anyone have a clue on the IDE part of my question? ;-)
Sorry, nope :)
--
http://vipe.technion.ac.il/~mulix/
http://syscalltrack.sf.net/
Alan,
2.4.19-rc5-ac1 hangs on boot on my laptop (Fujitsu P-series, TM5800
CPU), whereas plain[1] rc5 boots fine. The hang appears to be during IDE
detection:
...
block: 704 slots per queue, batch=176
Uniform Multi-Platform E-IDE driver Revision: 6.31
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=XX
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
With rc5, I get this same error unless I have 'ide0=ata66 ide1=ata66'
on the kernel command line. However, -ac1 hangs with or without these
options.
I had this same problem under rc3-ac1, and rc2-ac2 (last two -ac
kernels I tried), so this looks to be a long-term problem. I'm hoping
maybe I can help debug it before it gets into Marcelo's tree.
ian
[1] Actually, one one-liner patche to extend the ext3 journal
commit interval to 30 seconds.
On 02 Aug 2002 10:45:10 -0400
Ian Soboroff <[email protected]> wrote:
Hi
I have written before regarding the same problem. I noticed that I have mentioned the wrong kernel version. Of course I meant the 2.4.19-rc5-ac1 and 2.4.19-rc3-ac5. It happens on a Sony Vaio Gr114EK. I will now try the same solution like Ian.
greets
marc
>
> Alan,
>
> 2.4.19-rc5-ac1 hangs on boot on my laptop (Fujitsu P-series, TM5800
> CPU), whereas plain[1] rc5 boots fine. The hang appears to be during IDE
> detection:
>
> ...
> block: 704 slots per queue, batch=176
> Uniform Multi-Platform E-IDE driver Revision: 6.31
> ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=XX
> 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
>
> With rc5, I get this same error unless I have 'ide0=ata66 ide1=ata66'
> on the kernel command line. However, -ac1 hangs with or without these
> options.
>
> I had this same problem under rc3-ac1, and rc2-ac2 (last two -ac
> kernels I tried), so this looks to be a long-term problem. I'm hoping
> maybe I can help debug it before it gets into Marcelo's tree.
>
> ian
>
> [1] Actually, one one-liner patche to extend the ext3 journal
> commit interval to 30 seconds.
> -
> 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/
>
--- linux/drivers/ide/alim15x3.c~ 2002-08-03 03:06:10.000000000 +0900
+++ linux/drivers/ide/alim15x3.c 2002-08-03 03:07:15.000000000 +0900
@@ -37,6 +37,7 @@
static int ali_get_info(char *buffer, char **addr, off_t offset, int count);
extern int (*ali_display_info)(char *, char **, off_t, int); /* ide-proc.c */
static struct pci_dev *bmide_dev;
+static int enable_south = 0;
char *fifo[4] = {
"FIFO Off",
@@ -605,6 +606,7 @@
pci_read_config_byte(dev, 0x4b, &tmpbyte);
pci_write_config_byte(dev, 0x4b, tmpbyte | 0x08);
+ if( enable_south ){
/*
* set south-bridge's enable bit, m1533, 0x79
*/
@@ -620,6 +622,7 @@
*/
pci_write_config_byte(isa_dev, 0x79, tmpbyte | 0x02);
}
+ }
} else {
/*
* revision 0x20 (1543-E, 1543-F)
@@ -671,6 +674,7 @@
pci_read_config_byte(dev, 0x4b, &tmpbyte);
pci_write_config_byte(dev, 0x4b, tmpbyte | 0x08);
+ if( enable_south ){
/*
* set south-bridge's enable bit, m1533, 0x79
*/
@@ -686,6 +690,7 @@
*/
pci_write_config_byte(isa_dev, 0x79, tmpbyte | 0x02);
}
+ }
#endif /* ALI_INIT_CODE_TEST */
/*
* Ultra66 cable detection (from Host View)
@@ -821,3 +826,13 @@
ide_setup_pci_device(dev, d);
}
+static int __init enable_south_setup(char *str)
+{
+/* printk("ALI15X3: enable_south_setup %d\n", str); */
+ if(strcmp(str, "enable_south") == 0)
+ enable_south = 1;
+ return 1;
+}
+
+__setup("alim15x3=", enable_south_setup);
+
Hi
I haven't tried the patch yet, but I think it won't help in my case, because it is Ali-chipset related.
My Sony Vaio GR114EK has an Intel (i810 or i820) chipset. I think it's a more general problem.
I hope it will help.
marc
On Sat, 03 Aug 2002 03:26:12 +0900
Go Taniguchi <[email protected]> wrote:
> Hi,
>
> Please apply and test this patch.
> Probably pci_config_byte 0x79 is vendor specifics.
> Newer japanese hardware which use ALi IDE with Crusoe got hang up.
>
> This patch will solve the following problems without option 'ide0=ata66 ide1=ata66'
>