[Erledigt] Ultrabay Serial Port deaktiviert nach Standby

[xudabit]

Hallo.

bevor ich gleich mit Fragen beginne, hier mal ganz kurz eine kleine Vorstellung. Ich heiße Marcel und habe ein T61. Vor kurzem hatte ich ein Dell D630 ausprobiert (wegen der RS232-Schnittstelle), welches mir aber dann doch nicht so ganz zugesagt hatte. Jetzt benutze ich wieder mein T61. Hier die Daten dazu:

T61 mit Intel-Grafikkarte - gemoddetes BIOS
T7300 (Bald T9300)
Samsung 840 EVO mit 120GB
3GB Ram (Bald 4GB)
DVD-Multi / Serieller Port für Ultrabay
14,1 Wide (WXGA)
Linux Mint 16

Jetzt zu meinem "Problem". Der serielle Port funktioniert soweit eigentlich gut. Allerdings schaltet er sich ab sobald das Notebook einmal zugeklappt war. Dann muss ich erst einen kompletten Neustart machen um den Port wieder zum laufen zu bekommen. Irgendeiner eine Idee wie ich das ändern könnte? An sich ist das eher unproblematisch wenn man den Port wirklich nur für Diagnose verwendet. Aktuell bin ich allerdings dabei die Befehle des Diagnose-Programms (Windows) über einen Sniffer aufzuzeichnen und möchte diese in Java implementieren um zumindest auch einen Teil der Daten über Linux direkt auslesen zu können. Vor jedem Test muss ich dann den Rechner neustarten wenn er mal zugeklappt war. Das ist etwas nervig.

Es geht übrigens erst beim Aufwachen aus und nicht schon beim "in den Standby gehen".

Gruß
Marcel

 

[Mornsgrans]

Stelle im BIOS unter Config - Serial auf "Enabled". Ich vermute, dass "OS controlled" aktiv ist.

 

[xudabit]

Leider nein.

Ich hatte gerade extra nochmal nachgeschaut, da ich mir sicher war, dass es nur "Enabled" und "Disabled" als Option gab. Das ist auch der Fall. In der Beschreibung rechts steht "OS Controlled" nur in Klammern. Aktuell steht es also schon auf Enabled.

 

[Mornsgrans]

Ist das BIOS aktuell? - Es kann auch an einem veralteten BIOS liegen.

 

[xudabit]

Habe vor ein paar Tagen erst das Middleton-Bios drauf gepackt. (Version ist 2.29)

 

[think_pad]

Das PM-Device des T61 ist wahrscheinlich nicht für eine RSC232-Schnittstelle geschrieben worden, wenn Du aber einen ganz heißen Tip willst:

Noch nie gab es für 33 Euro eine komplette Messstation mit sehr vielen, direkten Schnittstellen, die Du mit WIN 2000 oder XP bespielen kannst. Lagere das Problem einfach auf ein externes Gerät aus...

 

[xudabit]

Wenn Du einen ganz heißen Tip willst:

Noch nie gab es für 33 Euro eine komplette Messstation mit sehr vielen, direkten Schnittstellen, die Du mit WIN 2000 oder XP bespielen kannst. Lagere das Problem einfach auf ein externes Gerät aus...

Genau das möchte ich eben nicht. Ich möchte das ganze über eine VM (wegen der Portierbarkeit bei Neuinstallation des Systems) an meinem Haupt-Laptop haben und kein extra Laptop dafür verwenden. Und dass die RS232 sich einfach abschaltet durch Standby muss ja irgendwie zu lösen sein.

 

[think_pad]

Genau das möchte ich eben nicht. Ich möchte das ganze über eine VM (wegen der Portierbarkeit bei Neuinstallation des Systems) an meinem Haupt-Laptop haben und kein extra Laptop dafür verwenden. Und dass die RS232 sich einfach abschaltet durch Standby muss ja irgendwie zu lösen sein.

Das ist zwar klug gedacht, aber nicht wirklich schlau: Die VM muss die Schnittstelle dann auch noch an den Adapter durchreichen, Du hast dann zwei bis fünf PM-Fehlerquellen, das lässt sich dann überhaupt nicht mehr handeln. Und wie wie soll bitte die VM in den Standby gehen, wenn Du den Host in den Standby gehen lässt?

Glaube mir: Eine direkte Schnittstelle ist eine direkte Schnittstelle, alles andere wirst Du früher oder später bereuen, oder Du lässt den T61 volle Zeit durchlaufen...

 

[xudabit]

Das ist zwar klug gedacht, aber nicht wirklich schlau: Die VM muss die Schnittstelle dann auch noch an den Adapter durchreichen, Du hast dann zwei Fehlerquellen, das lässt sich dann überhaupt nicht mehr handeln.

Keine Sorge. Hier gibt es keinerlei Probleme. Die Lösung mit der VM passt wunderbar und biergt hier auch überhaupt keine Probleme. Außerdem geht es mir hier nicht um die Übertragung über die Schnittstelle, sondern dass diese sich nach Standby nicht einfach ausschalten soll!

Und wie wie soll die VM in den Standby gehen, wenn Du den Host in den Standby gehen lässt?

Was hat das denn damit zu tun? Die VM stoppt sobald der Host in den Standby geht. Wo sollen hier dann bitte Probleme auftreten? Aber wie gesagt. Das ist nicht das Problem. Mein Problem ist das unbegründete Ausschalten des Ultrabay-Einschubs!

Glaube mir: Eine direkte Schnittstelle ist eine direkte Schnittstelle, alles andere wirst Du früher oder später bereuen, oder Du lässt den T61 volle Zeit durchlaufen...

Und glaube du mir: Die serielle Schnittstelle funktioniert. Sie wird direkt an die VM durchgeleitet und macht hier üüüüüberhaupt keine Schwierigkeiten. Das ganze habe ich schon ausgiebig getestet. Ich brauche das Laptop ab und zu mal für die Diagnose an meinem Auto. Dafür lasse ich den Rechner sicher nicht durchlaufen. Im schlimmsten Fall müsste ich den Laptop vor der Diagnose eben neustarten.

 

[think_pad]

Die VM stoppt sobald der Host in den Standby geht.

Muss sie ja, was soll sie machen..? Aber wacht sie auch wieder auf? Und wacht sie sie so auf, dass die RSC232-Schnittstelle wieder durchgereicht wird? Offenbar nicht...

Keine Sorge. Hier gibt es keinerlei Probleme. Die Lösung mit der VM passt wunderbar und biergt hier auch überhaupt keine Probleme. Außerdem geht es mir hier nicht um die Übertragung über die Schnittstelle, sondern dass diese sich nach Standby nicht einfach ausschalten soll!

Aber Dir ist klar, dass es sich bei dem Serial Port im Ultraby-Adapter um einen Konverter handelt, der Festplattenbefehle auf Portbefehle umbiegt. Du schiebst ihn rein und das Betriebsystem erkennt diesen Adapter und intialisiert ihn, damit er sich als Serial Port nutzen lässt.

Wenn er nun "nach dem Aufwachen" unfreiwillig sich abschaltet, bekommt er vom PM-Device den falschen Initialisierungsbefehl, nämlich den für ein Laufwerk. Wie willst Du das ändern, außer das richtige PM-Device zu finden, dass mit diesem speziellen Problem umgehen kann?

 

[xudabit]

Muss sie ja, was soll sie machen..? Aber wacht sie auch wieder auf? Und wacht sie sie so auf, dass die RSC232-Schnittstelle wieder durchgereicht wird? Offenbar nicht...

Du scheinst dich hier etwas auf die VM zu versteifen. Ignoriere das doch einfach mal. Die RS232 wird komplett "deaktiviert". Nicht von der VM, sondern eindeutig vom Host, da der Host die RS232 auch nicht mehr ansprechen kann. Also ignoriere bitte einfach die VM und lass das meine Sorge sein. Die schläft, wacht auf und macht alles wie sie es soll

Aber Dir ist klar, dass es sich bei dem Serial Port im Ultraby-Adapter um einen Konverter handelt, der Festplattenbefehle auf Portbefehle umbiegt. Du schiebst ihn rein und das Betriebsystem erkennt diesen Adapter und intialisiert ihn, damit er sich als Serial Port nutzen lässt.

Dann zeig mir mal bitte die Quelle wo du diese Info her hast ... Dir ist schon bewusst, dass der Ultra-Bay-Adapter für die RS232 an einen ganz anderen Anschluss kommt, als beispielsweise das Laufwerk oder? Die RS232 ist praktisch eine native Schnittstelle ohne Konverter oder so ein Zeug. ich habe die nicht umsonst gewählt, da es mit Konvertern oftmals Probleme gibt.

Nur das deaktivieren stört. Sie wird ja explizit nach dem Standby vom System DEAKTIVIERT. Nicht beim "In Standby gehen"! Es scheint hier also ein Befehl vom System zu kommen, welcher diese nach dem Standby deaktiviert.

 

[think_pad]

Es scheint hier also ein Befehl vom System zu kommen, welcher diese nach dem Standby deaktiviert.

Es scheint wohl eher ein falscher Befehl zu kommen, der sie nicht wieder aktiviert bzw. der falsche Befehl löst einen Fehler aus.

Es geht auch nicht um Hotswap, da nichts getauscht wird: http://www.thinkwiki.org/wiki/How_to_hotswap_Ultrabay_devices

Es geht um einen Wake-Up Befehl, der nicht kommt oder falsch ist, und der wird beim T61 vom PM-Device bzw. vom Intel-Driver geliefert. Da man serielle Schnittstellen auch nach Geschwindigkeiten im BIOS einstellen kann, kann auch da der Fehler liegen, falsche Synchronisation. Schließlich und endlich gab es zu Zeiten der seriellen Schnittstellen meiner Ansicht nach noch kein ausgereiftes ACPI, so dass man eine RSC232-Schnittstelle systematisch in den Schlaf schickt und wieder aufweckt.

 

[xudabit]

Entweder wird sie nach dem Standby nicht anständig geweckt oder sie wird danach fälschlicherweise schlafen gelegt. Anhand der LED, welche bei funktionstüchtiger RS232 leuchtet, würde ich aber sagen, dass die Schnittstelle nach dem Standby schlafen gelegt wird. Das lämpchen leuchtet nämlich nach einem Neustart -> Alles Top. Während des Standbys leuchtet es auch. Erst beim aufwachen geht es aus -> Schnittstelle wird nicht mehr erkannt.

Jetzt ist nur die Frage wie ich das kontrollieren kann ...

Im übrigen: Wieso RSC232? Meines Wissens nennt sich die Schnittstelle RS232 und nicht RSC232 ...

 

[think_pad]

1. Jetzt ist nur die Frage wie ich das kontrollieren kann ...
2. Im übrigen: Wieso RSC232? Meines Wissens nennt sich die Schnittstelle RS232 und nicht RSC232 ...

1. Du bräuchtest die Initialisierungssequenz für den Adapter, ähnlich dem "Magic Packet" des "Wake on LAN"; diesen Befehl kann man nach dem Aufwachen auch vom Desktop aus schicken. Da gibt es bestimmt bei IBM ein kleines Programm für, so eine Art Konfigurationsmanager für Ultrabay...

Serial Port -> On/Off (Bitte klicken Sie .... jetzt!)

2. Du hast recht, beginnende Demenz... :facepalm:

 

[xudabit]

Über "dmesg" habe ich beim letzten Standby die Fehlermeldung "ttyS0: LSR safety check engaged!" bekommen. Allerdings kann ich damit nicht viel anfangen. Bin aktuell bei der Google-Suche und werde mal ein paar sachen ausprobieren.

 

[think_pad]

Über "dmesg" habe ich beim letzten Standby die Fehlermeldung "ttyS0: LSR safety check engaged!" bekommen. Allerdings kann ich damit nicht viel anfangen. Bin aktuell bei der Google-Suche und werde mal ein paar sachen ausprobieren.

http://www.thinkwiki.org/wiki/Ultrabay_Slim_Serial/Parallel_Port_Adapter

Mir fällt noch der Trick mit dem WLAN-Adapter ein: Wenn das Netz hakt, Disabeln / Enabeln, dann geht es wieder.

Wenn Du im Gerätemanager den Serial Port einfach mal deaktivierst und aktivierst? Dann sendet er das "Magic Packet"...

Fehlermeldung "ttyS0: LSR safety check engaged!" heißt sinngemäß, ein anderes Gerät belegt die Ressourcen des angeforderten Geräts, oft falsche IRQ-Zuweisung o.ä. Das sagt aber nach einem Standby nicht viel, außer, dass das Gerät nicht ordentlich abgemeldet wurde...

Du solltest es mal disabeln, und nach dem Standby enabeln... Ich glaube, es hat mit dem IRQ-Sharing zu tun: Hätte der Adapter seine eigene IRQ, würde er auch wieder aufwachen...

 

[xudabit]

Wenn Du im Gerätemanager den Serial Port einfach mal deaktivierst und aktivierst?

Das könnte ich nur in der VM (Windows XP) machen. Unter Linux wüsste ich aktuell nicht wie ich die Serielle einfach ausschalten kann.

 

[think_pad]

Das könnte ich nur in der VM (Windows XP) machen. Unter Linux wüsste ich aktuell nicht wie ich die Serielle einfach ausschalten kann.

Ich auch nicht, aber unter LINUX gibt es auch kein reguläres PM-Device. Niemand hat beim Programmieren daran gedacht, dass jemand seinen COM-Port am Ultrabay-Adapter in den Standby schicken will. COM-Ports ab- und anmelden machte man eigentlich nur, um neue Geräte anzuschließen. (Modem, Zeilendrucker, Drucker, Fax-Modem o.ä.)

Ich würde aber sowieso den Weg eines eigenen IRQs für den COM-Port oder den Adapter über das BIOS gehen. Damit ist das Problem isoliert...

Oder Du nimmst das gute, alte WINDOWS 98 und stellst den COM-Port regulär an und aus...

-
​

 

[xudabit]

Der Com-Port hat sowieso IRQ 4. Daher verstehe ich nicht so ganz was du damit meinst.

Windows 98 wird mir hier wahrscheinlich auch nicht weiterhelfen. Also zumindest nicht in der VM.

 

[think_pad]

Der Com-Port hat sowieso IRQ 4. Daher verstehe ich nicht so ganz was du damit meinst.

Damit böte sich rein theoretisch die Möglichkeit, vor dem Standy eine Off-Sequenz und nach dem Standby eine On-Sequenz an den Adapter bzw. Port zu schicken. Der Fehler scheint zu sein, dass sich das Adapter-Gerät nicht abmeldet. Nach dem Aufwachen versucht der Treiber, den IRQ seines eigenen Geräts neu zu belegen und findet ihn von einem "fremden" Gerät bereits belegt vor, und schaltet sich und das Gerät ab.

Windows 98 wird mir hier wahrscheinlich auch nicht weiterhelfen. Also zumindest nicht in der VM.

Unter Host-WINDOWS könntest Du aber bei IBM/Lenovo rein theoretisch einklagen, dass der regulär erworbene Ultra-Bay-Adapter offenbar nicht ACPI-tauglich ist. Unter LINUX kann man das nicht verlangen, schon deshalb, weil der COM-Port kein reguläres, direktes Gerät des ThinkPad ist, es müssen Adapter-Befehle umgesetzt werden. Es gibt aber bestimmt jemand, der schon mal über dieses Problem gestolpert ist und ein solches Konfigurations-Programm für diesen Adapter hat.