Laptop hangt door cardbus

[Verwijderd]

Hoi,

ik heb een Sony VAIO fr285e laptop. Als ik in het bovenste PCMCIA slot een E-tech cardbus netwerkkaart (eth1) prop, en deze activeer, dan hangt m'n laptop op het moment dat ik data ontvang vanaf het netwerk. Het onderste slot werkt wel goed. Het rare met het bovenste slot is dat de computer weer tot leven komt op het moment dat ik mijn USB muis beweeg. Hij hangt weer op het moment dat ie weer data ontvangt van het netwerk. Ik gebruik kernel 2.4.22.

0: 32344 XT-PIC timer
1: 747 XT-PIC keyboard
2: 0 XT-PIC cascade
8: 2 XT-PIC rtc
9: 30 XT-PIC acpi, ehci_hcd
10: 1773066 XT-PIC ohci1394, Ricoh Co Ltd RL5c476 II (#2), usb-uhci, usb-uhci, via82cxxx, eth0, nvidia
11: 3293 XT-PIC Ricoh Co Ltd RL5c476 II, usb-uhci, eth1
14: 5283 XT-PIC ide0
15: 5 XT-PIC ide1
NMI: 0
LOC: 32306
ERR: 224
MIS: 0

00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333]
00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP]
00:0c.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:0e.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa)
00:0e.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev aa)
00:0e.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 02)
00:10.0 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. USB (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT8233/A/C/VT8235 PIPC Bus Master IDE (rev 06)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235 AC97 Audio Controller (rev 50)
00:11.6 Communication controller: VIA Technologies, Inc. Intel 537 [AC97 Modem] (rev 80)
01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 420 Go] (rev a3)

In bovenste slot:
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

In onderste slot:
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

Iemand enig idee wat hier fout gaat?? Ik snap er geen kont van.

[Zwerver]

ik ga er vanuit dat je gentoo gebruikt? En dat je forums.gentoo.org ook al gechecked hebt? Verder heb je de goede modules voor de cardbus ingeladen alsmede gecontroleerd of dit probleem zich ook met andere netwerkkaarten voordoet? Ietsje meer info ajb

[ Voor 48% gewijzigd door Zwerver op 02-10-2003 13:47 . Reden: extra zeur zut ]

[Verwijderd]

Zwerver schreef op 02 oktober 2003 @ 13:46:
ik ga er vanuit dat je gentoo gebruikt?

ja

En dat je forums.gentoo.org ook al gechecked hebt?

ja. op dat forum daar krijg ik geen reactie. op irc weet ook niemand wat er gebeurd.

Verder heb je de goede modules voor de cardbus ingeladen

ja. het onderste slot werkt perfect.

alsmede gecontroleerd of dit probleem zich ook met andere netwerkkaarten voordoet? Ietsje meer info ajb

nee, ik beschik niet over een hele partij verschillende cardbus netwerkkaarten
Meer info.. tja wat wil je weten. 2.6.0-test6 heb ik getest, geeft hetzelfde probleem.

[u_nix_we_all]

Hmm, aan je interrupts te zien , hangt er nogal wat achter interrupt 10.
Ik weet niet of dit voor jou ook geldt, maar bij mijn laptop wordt de routing van de
interrupts door acpi gedaan ( heb je acpi ?) en had ik problemen met verschillende
kernel versies en acpi.
Ik gebruik nu een kernel zonder acpi, dat draait tenminste stabiel. Dan maar geen power management,
geen battery indicatie e.d.
Probeer eens te booten met "append noacpi" (of zoiets was het).......

[Zwerver]

wat ik wil weten is of het probleem in de cardbus kaart zit of in je vaio... als jij zegt dat het onderste slot goed werkt, dan zit het waarschijnlijk in de samenwerking tussen het bovenste slot en de linux driver... maar daar het in het onderste slot wel goed gaat zou je gaan denken dat er iets mis gaat met irq's etc. Of. en dat is niet uit te sluiten, je krijgt problemen met de data transfer omdat er in je VAIO its niet helemaal lekker functioneerd.
Om maar even heel eerlijk te zijn, ik heb [u]dit[/url] probleem nog nooit eerder meegemaakt.

Wat mij wel gelukt is om te vinden: Oud bug report met het zelfde probleem voor kernel 2.4.7
Verder deze Baat het niet dan schaad het niet denk ik

[ Voor 8% gewijzigd door Zwerver op 02-10-2003 14:29 . Reden: patch voor vaio toegevoegd ]

[Verwijderd]

Oke, effe zonder ACPI proberen.

[u_nix_we_all]

OH , dat moet (voor lilo) append="pci=noacpi" zijn dan

[Zwerver]

maaruh, dat zal wel grub zijn u_nix_we_all --> tis gentoo

[Verwijderd]

dat 'append noacpi' niet werkte, had ik al door. Keb een nieuwe kernel gemaakt zonder ACPI. Is op mijn laptop in 1 minuut gedaan.

Maar, het is nu idd opgelost. Hij hangt nu niet meer. u_nix_we_all, bedankt voor de tip!!! Eens kijken of APM hetzelfde gezeik geeft. (vind een battery metertje toch wel handig).

Moet ik hier nou wat over opsturen naar de kernel code kloppers? Is dit een fout in de linux ACPI implementatie of iets van mijn laptop specifief?

[u_nix_we_all]

@zwerver: lilo / grub, kan beiden, maar ik ken grub niet goed en lilo wel

Gentoo , het is maar de vraag of je apm hebt, bij mij vervangt acpi de apm.
Kernel bakken met acpi is wat tricky , het is mij ook nog niet lekker gelukt.
Wat ik ervan begreep is dat je de kernel / acpi drivers moet patchen of wijzigen
om gebruik te maken van de acpi tables die specifiek voor jouw laptop zijn......

edit:
Oh en de acpi patches natuurlijk

Ben nooit een duidelijk handleiding tegengekomen , en heb het maar opgegeven

[ Voor 6% gewijzigd door u_nix_we_all op 02-10-2003 14:53 ]

[Verwijderd]

u_nix_we_all schreef op 02 October 2003 @ 14:20:
Hmm, aan je interrupts te zien , hangt er nogal wat achter interrupt 10.

btw, het gaat hier om eth1 (eth0 is de onboard nw jetser). Dus interrupt 11. Daar hangt minder aan, dan aan 10..... maar goed.

[Verwijderd]

u_nix_we_all schreef op 02 oktober 2003 @ 14:52:
Gentoo , het is maar de vraag of je apm hebt, bij mij vervangt acpi de apm.
Kernel bakken met acpi is wat tricky , het is mij ook nog niet lekker gelukt.
Wat ik ervan begreep is dat je de kernel / acpi drivers moet patchen of wijzigen
om gebruik te maken van de acpi tables die specifiek voor jouw laptop zijn......

edit:
Oh en de acpi patches natuurlijk

Geen idee. Ik heb mijn laptop pas 2 weken. Dus dat hele APM / ACPI gedoe is voor mij nieuw. Heb dat op mijn PC allemaal uit staan.

(nou kan een batterij meter op mijn PC wel eens handig zijn. Energie Delfland scheid er nog wel eens mee uit Heee, geen stroom meer volgens mijn batterij meter. *poef* compu uit....)

[Verwijderd]

Verwijderd schreef op 02 October 2003 @ 13:41:
ik heb een Sony VAIO fr285e laptop. Als ik in het bovenste PCMCIA slot een E-tech cardbus netwerkkaart (eth1) prop, en deze activeer, dan hangt m'n laptop op het moment dat ik data ontvang vanaf het netwerk. Het onderste slot werkt wel goed. Het rare met het bovenste slot is dat de computer weer tot leven komt op het moment dat ik mijn USB muis beweeg. Hij hangt weer op het moment dat ie weer data ontvangt van het netwerk. Ik gebruik kernel 2.4.22.

Dit gedrag scheen (graaf, graaf) iets te maken te hebben met een USB module die conflicteert. Er zijn (als het goed is) twee module varianten voor jouw hardware, EHCI en OHCI, gebruik de andere eens?

[Verwijderd]

Beelzebubu, bedankt. Maar ik ben er al uit. Is geen USB, maar een ACPI issue.

[ajvdvegt]

Misschien wordt het ACPI-probleem enkel getriggered door die USB module, dus is het wellicht toch het proberen waard? Op mijn laptop werkt ACPI prima namelijk (Kernel 2.6.0-test5, zonder patches oid), en dat wordt denk ik toch de nieuwe standaard ipv. APM.

[Tony Vroon]

ACPI kan toch wel handig zijn, vooral voor je batterijmetertje.
Je kunt eens een kernel met ACPI bouwen en de commandline optie pci=noacpi gebruiken. Alle andere ACPI-opties blijven dan wel gewoon actief (batterij-statusmeting, button events...).

Dat gebeurt wel vaker op laptops, dat je qua ACPI alles kunt gebruiken behalve de IRQ-routing.