ThinkWiki - User contributions [en]

Talk:ThinkPad Advanced Mini-Dock

2007-10-24T13:57:05Z

Sridhar:

We do have 8 Advanced Mini Dock in our company, but none of my collegues can manage to dock in properly. To do so you have to press very hard in the middle of the edge on your notebook, I cannot imagine that the display will survive this for a longer time.
You control to have connected properly by lifting your notebook - if connected properly, it will not disconnect.
In all cases, ours do disconnect, even when locked with the key.
Our unsatisfying solution: We place a mouse-pad under each Mini-Dock - now connecting is no problem any more.

Lenovo is unable to reproduce this problem with their own hardware - the support asked me to send one notebook and one Mini-Dock to them to schottland so that they can investigate in that case. That means one collegue will have to survive without his comuter for I don't know how many weeks. Lenovo cannot send somebody to confirm the problem inside our house. This kind of Support is very poor!
And, of course, I am wondering: I am the one who bought exactly this 8 notebooks together with this 8 Mini-Docks, which don't want to fit together.

Are all the others connecting without problems ?

Please tell me your experiences.

I have the same problem. I put some rubber feet on the bottom of the dock, but it's still pretty hard to dock the computer reliably and it requires lots of force. I'll try the mousepad trick, for what that's worth. --[[User:Dave abrahams|Dave abrahams]] 17:20, 25 April 2007 (CEST)

It seems to be a problem with T60 models manufactured in August 2006 (?) (S/N L3-FL??? 06/08), I do have some other T60 now without this problem. Meanwhile IBM/Lenovo has confirmed the problem (to me), but this was a long way. I sent my T60 and Minidock to them in 5 Feb. 07, today we have 22 May and it is still not back. At least IBM/Lenovo has given me another T60 for this time.
If I had this choice again, I wouldn't complain to IBM/Lenovo, I'd just try to buy some "rubber-feet" for my Minidock. --[[User:Holzbein]] 16:40, 22 May 2007 (CEST)

== Mini-dock power problem ==
I have a T60p, and if I place the machine onto the Advanced Mini Dock when it is asleep, it turns off. The only way I can prevent this from happening is to wake the machine up before I put it on the dock. Does anyone else have this problem? --[[User:Sridhar|Sridhar]] 14:38, 2 January 2007 (CET)

I have the problem about half the time even when the machine is already awake. --[[User:Dave abrahams|Dave abrahams]] 17:17, 25 April 2007 (CEST)

We also have another problem with Keyboards connected to the Minidock's PS/2-Port. Sometimes it is behaving like the SHIFT key is held permanently, and to escape from this situation you have to press SHIFT many times (or reboot). This happens with different PS/2 Keyboards of different manufacturers, but it happens not every day, maybe once a week. So how should I complain about this ? How can I demonstrate the problem ? I don't expect it to be solved, only to cost my nerves. So I better buy some new USB-Keyboards and stop using the Minidock's PS/2-Port. --[[User:Holzbein]] 16:45, 22 May 2007 (CEST)

I have this problem as well. It wreaks havoc when I'm in vi. I'm thinking this model dock might just be a lemon. [[User:Sridhar|Sridhar]] 13:57, 24 October 2007 (UTC)

Talk:Problems with ACPI suspend-to-ram

2007-01-02T16:51:03Z

Sridhar:

After a few resumes with my T43, I get "big green boxes" on my consoles tty1 and tty2.
tyy3 to tty6 stays completly black (there should be login prompt).
But X still working fine.

This is a minor issue, but anyone with the same problem and a fix/workaround?

--[[User:Defiant|Defiant]] 13:40, 02 Jun 2006 (CEST)
----
I have a similar issue on my T60. It seems like the problem is with the framebuffer; that the card is attempting to use the lowest resolution possible when I have the framebuffer set much higher, but that's just my intuition. I'm using hibernate with both <code>EnableVbetool</code> and <code>VbetoolPost</code> set to <code>yes</code>.

An interesting thing is that if I manually call hibernate from an xterm inside X, I get no negative effects. It even fixes the console "big green boxes" if I previously suspended not in X. Also, on resume I see the following messages on the xterm (all previous output is cleared):

Allocated buffer at 0x11010 (base is 0x0)
ES: 0x1101 EBX: 0x0000
Calling INT 0x15 (F000: 5E79)
EAX is 0x1005F08
Calling INT 0x15 (F000: 5E79)
EAX is 0x1005F08
Calling INT 0x15 (F000: 5E79)
EAX is 0x5F08
Calling INT 0x15 (F000: 5E79)
EAX is 0x5F08
Calling INT 0x15 (F000: 5E79)
EAX is 0x45F08
Function not supported

Any ideas?

-- [[User:Deason|Deason]] 05:39, 14 July 2006 (CEST)
----
Just to update/confirm: suspend to RAM only works if I have X running, and I switch to the console running X after resuming. Editing the ACPI sleep script to switch to vt 7 before switching back to the original console seems to work fine, though. It just means that I can't suspend to RAM if I'm not running X. (Putting a check for that in the ACPI sleep script would also be a good idea.) I've tried using <code>EnableVbetool</code>, <code>VbetoolPost</code>, <code>RestoreVCSAData</code>, and <code>RestoreVbeStateFrom</code> from hiberante, but none seem to solve this without switching to X.

-- [[User:Deason|Deason]] 21:48, 16 July 2006 (CEST)
----
Yes it's the vga framebuffer freaking out at you. Try adding '''acpi_sleep=s3_bios,s3_mode''' kernel option to /boot/grub/menu.lst

The s3_mode part fixed the green boxes for me. (debian testing, kernel 2.6.16, TP x41)

--[[User:Ladoga|Ladoga]] 06:46, 5 August 2006 (CEST)
----
Yay, that did it. Also, I'm not sure which option it is, but one of the options in hibernate (either <code>EnableVbetool</code>, <code>VbetoolPost</code>, <code>RestoreVCSAData</code>, or <code>RestoreVbeStateFrom</code>, or all of them) causes the framebuffer to freak out again. Disabling them, and enabling that s3_mode makes it all work again. (Debian Sid, 2.6.17, T60). Putting this in the article, I guess.

--[[User:Deason|Deason]]

== Intermittent lock-up on resume with X31 ==

I have an {{X31}} running 2.6.16 (Debian). I'm running Debian patches, with the addition of ieee80211 1.1.14 and ipw2200 1.1.13

Suspend/resume generally works first time, but locks up during resume after a few cycles. Usually the sleep light stays flashing.

A possibly related symptom is that on a few occasions, I've had the wireless connectivity work for a few seconds after resume, and then fail (though this could be fixed by {{cmdroot|ifdown eth1; rmmod ipw2200; modprobe ipw2200; ifup eth1}}).

I've tried the following boot options to no avail: {{bootparm|ec_intr|0}}; <tt>nolapic</tt>; <tt>nolapic noapic</tt>

--[[User:Mbg71|Malcolm]] 06:42, 1 September 2006 (CEST)

I've had no more lock-ups since my last post (knock on wood) i.e. about 20 suspend/resume cycles.

Nothing has changed in my config, but I've been manually doing a

{{cmdroot|sync}}

before each suspend, according to the theory that race conditions etc. will be less likely to be tickled if I reduce the interrupt load while ACPI does its work.

Incidentally, it turns out that I was running the equivalent of <tt>nolapic</tt> all along; dmesg output says:

<code>
Local APIC disabled by BIOS -- you can enable it with "lapic"
</code>

--[[User:Mbg71|Malcolm]] 10:11, 21 September 2006 (CEST)

Two lock-ups since my last post: after 30 cycles and after 10.

It loooks like this is [http://bugzilla.kernel.org/show_bug.cgi?id=5555 kernel bug #5555]

--[[User:Mbg71|Malcolm]] 00:04, 3 October 2006 (CEST)

== Unable to resume R40e after suspend-to-RAM ==

Suspend-To-RAM works fine, but after going to sleep,
the laptop (R40e) can't be woken up. It doesn't respond to
anything, the battery has to be removed in order to
reset it. I tried many different setups, but the
problem persists. Any ideas, please?

== T60p Docking While Suspended ==

My T60p exhibits the problem where if I dock it while it's asleep, it shuts off. Has anyone gotten a response from Lenovo about this problem? Is there a fix? I'm getting tired of waking up my laptop before docking it.

--[[User:Sridhar|Sridhar]] 17:50, 2 January 2007 (CET)

Talk:Problems with ACPI suspend-to-ram

2007-01-02T16:50:37Z

Sridhar:

After a few resumes with my T43, I get "big green boxes" on my consoles tty1 and tty2.
tyy3 to tty6 stays completly black (there should be login prompt).
But X still working fine.

This is a minor issue, but anyone with the same problem and a fix/workaround?

--[[User:Defiant|Defiant]] 13:40, 02 Jun 2006 (CEST)
----
I have a similar issue on my T60. It seems like the problem is with the framebuffer; that the card is attempting to use the lowest resolution possible when I have the framebuffer set much higher, but that's just my intuition. I'm using hibernate with both <code>EnableVbetool</code> and <code>VbetoolPost</code> set to <code>yes</code>.

An interesting thing is that if I manually call hibernate from an xterm inside X, I get no negative effects. It even fixes the console "big green boxes" if I previously suspended not in X. Also, on resume I see the following messages on the xterm (all previous output is cleared):

Allocated buffer at 0x11010 (base is 0x0)
ES: 0x1101 EBX: 0x0000
Calling INT 0x15 (F000: 5E79)
EAX is 0x1005F08
Calling INT 0x15 (F000: 5E79)
EAX is 0x1005F08
Calling INT 0x15 (F000: 5E79)
EAX is 0x5F08
Calling INT 0x15 (F000: 5E79)
EAX is 0x5F08
Calling INT 0x15 (F000: 5E79)
EAX is 0x45F08
Function not supported

Any ideas?

-- [[User:Deason|Deason]] 05:39, 14 July 2006 (CEST)
----
Just to update/confirm: suspend to RAM only works if I have X running, and I switch to the console running X after resuming. Editing the ACPI sleep script to switch to vt 7 before switching back to the original console seems to work fine, though. It just means that I can't suspend to RAM if I'm not running X. (Putting a check for that in the ACPI sleep script would also be a good idea.) I've tried using <code>EnableVbetool</code>, <code>VbetoolPost</code>, <code>RestoreVCSAData</code>, and <code>RestoreVbeStateFrom</code> from hiberante, but none seem to solve this without switching to X.

-- [[User:Deason|Deason]] 21:48, 16 July 2006 (CEST)
----
Yes it's the vga framebuffer freaking out at you. Try adding '''acpi_sleep=s3_bios,s3_mode''' kernel option to /boot/grub/menu.lst

The s3_mode part fixed the green boxes for me. (debian testing, kernel 2.6.16, TP x41)

--[[User:Ladoga|Ladoga]] 06:46, 5 August 2006 (CEST)
----
Yay, that did it. Also, I'm not sure which option it is, but one of the options in hibernate (either <code>EnableVbetool</code>, <code>VbetoolPost</code>, <code>RestoreVCSAData</code>, or <code>RestoreVbeStateFrom</code>, or all of them) causes the framebuffer to freak out again. Disabling them, and enabling that s3_mode makes it all work again. (Debian Sid, 2.6.17, T60). Putting this in the article, I guess.

--[[User:Deason|Deason]]

== Intermittent lock-up on resume with X31 ==

I have an {{X31}} running 2.6.16 (Debian). I'm running Debian patches, with the addition of ieee80211 1.1.14 and ipw2200 1.1.13

Suspend/resume generally works first time, but locks up during resume after a few cycles. Usually the sleep light stays flashing.

A possibly related symptom is that on a few occasions, I've had the wireless connectivity work for a few seconds after resume, and then fail (though this could be fixed by {{cmdroot|ifdown eth1; rmmod ipw2200; modprobe ipw2200; ifup eth1}}).

I've tried the following boot options to no avail: {{bootparm|ec_intr|0}}; <tt>nolapic</tt>; <tt>nolapic noapic</tt>

--[[User:Mbg71|Malcolm]] 06:42, 1 September 2006 (CEST)

I've had no more lock-ups since my last post (knock on wood) i.e. about 20 suspend/resume cycles.

Nothing has changed in my config, but I've been manually doing a

{{cmdroot|sync}}

before each suspend, according to the theory that race conditions etc. will be less likely to be tickled if I reduce the interrupt load while ACPI does its work.

Incidentally, it turns out that I was running the equivalent of <tt>nolapic</tt> all along; dmesg output says:

<code>
Local APIC disabled by BIOS -- you can enable it with "lapic"
</code>

--[[User:Mbg71|Malcolm]] 10:11, 21 September 2006 (CEST)

Two lock-ups since my last post: after 30 cycles and after 10.

It loooks like this is [http://bugzilla.kernel.org/show_bug.cgi?id=5555 kernel bug #5555]

--[[User:Mbg71|Malcolm]] 00:04, 3 October 2006 (CEST)

== Unable to resume R40e after suspend-to-RAM ==

Suspend-To-RAM works fine, but after going to sleep,
the laptop (R40e) can't be woken up. It doesn't respond to
anything, the battery has to be removed in order to
reset it. I tried many different setups, but the
problem persists. Any ideas, please?

== T60p Docking While Suspended ==

My T60p exhibits the problem where if I dock it while it's asleep, it shuts off. Has anyone gotten a response from Lenovo about this problem? Is there a fix? I'm getting tired of waking up my laptop before docking it.
--[[User:Sridhar|Sridhar]] 17:50, 2 January 2007 (CET)

Talk:Problems with ACPI suspend-to-ram

2007-01-02T16:50:18Z

Sridhar:

After a few resumes with my T43, I get "big green boxes" on my consoles tty1 and tty2.
tyy3 to tty6 stays completly black (there should be login prompt).
But X still working fine.

This is a minor issue, but anyone with the same problem and a fix/workaround?

--[[User:Defiant|Defiant]] 13:40, 02 Jun 2006 (CEST)
----
I have a similar issue on my T60. It seems like the problem is with the framebuffer; that the card is attempting to use the lowest resolution possible when I have the framebuffer set much higher, but that's just my intuition. I'm using hibernate with both <code>EnableVbetool</code> and <code>VbetoolPost</code> set to <code>yes</code>.

An interesting thing is that if I manually call hibernate from an xterm inside X, I get no negative effects. It even fixes the console "big green boxes" if I previously suspended not in X. Also, on resume I see the following messages on the xterm (all previous output is cleared):

Allocated buffer at 0x11010 (base is 0x0)
ES: 0x1101 EBX: 0x0000
Calling INT 0x15 (F000: 5E79)
EAX is 0x1005F08
Calling INT 0x15 (F000: 5E79)
EAX is 0x1005F08
Calling INT 0x15 (F000: 5E79)
EAX is 0x5F08
Calling INT 0x15 (F000: 5E79)
EAX is 0x5F08
Calling INT 0x15 (F000: 5E79)
EAX is 0x45F08
Function not supported

Any ideas?

-- [[User:Deason|Deason]] 05:39, 14 July 2006 (CEST)
----
Just to update/confirm: suspend to RAM only works if I have X running, and I switch to the console running X after resuming. Editing the ACPI sleep script to switch to vt 7 before switching back to the original console seems to work fine, though. It just means that I can't suspend to RAM if I'm not running X. (Putting a check for that in the ACPI sleep script would also be a good idea.) I've tried using <code>EnableVbetool</code>, <code>VbetoolPost</code>, <code>RestoreVCSAData</code>, and <code>RestoreVbeStateFrom</code> from hiberante, but none seem to solve this without switching to X.

-- [[User:Deason|Deason]] 21:48, 16 July 2006 (CEST)
----
Yes it's the vga framebuffer freaking out at you. Try adding '''acpi_sleep=s3_bios,s3_mode''' kernel option to /boot/grub/menu.lst

The s3_mode part fixed the green boxes for me. (debian testing, kernel 2.6.16, TP x41)

--[[User:Ladoga|Ladoga]] 06:46, 5 August 2006 (CEST)
----
Yay, that did it. Also, I'm not sure which option it is, but one of the options in hibernate (either <code>EnableVbetool</code>, <code>VbetoolPost</code>, <code>RestoreVCSAData</code>, or <code>RestoreVbeStateFrom</code>, or all of them) causes the framebuffer to freak out again. Disabling them, and enabling that s3_mode makes it all work again. (Debian Sid, 2.6.17, T60). Putting this in the article, I guess.

--[[User:Deason|Deason]]

== Intermittent lock-up on resume with X31 ==

I have an {{X31}} running 2.6.16 (Debian). I'm running Debian patches, with the addition of ieee80211 1.1.14 and ipw2200 1.1.13

Suspend/resume generally works first time, but locks up during resume after a few cycles. Usually the sleep light stays flashing.

A possibly related symptom is that on a few occasions, I've had the wireless connectivity work for a few seconds after resume, and then fail (though this could be fixed by {{cmdroot|ifdown eth1; rmmod ipw2200; modprobe ipw2200; ifup eth1}}).

I've tried the following boot options to no avail: {{bootparm|ec_intr|0}}; <tt>nolapic</tt>; <tt>nolapic noapic</tt>

--[[User:Mbg71|Malcolm]] 06:42, 1 September 2006 (CEST)

I've had no more lock-ups since my last post (knock on wood) i.e. about 20 suspend/resume cycles.

Nothing has changed in my config, but I've been manually doing a

{{cmdroot|sync}}

before each suspend, according to the theory that race conditions etc. will be less likely to be tickled if I reduce the interrupt load while ACPI does its work.

Incidentally, it turns out that I was running the equivalent of <tt>nolapic</tt> all along; dmesg output says:

<code>
Local APIC disabled by BIOS -- you can enable it with "lapic"
</code>

--[[User:Mbg71|Malcolm]] 10:11, 21 September 2006 (CEST)

Two lock-ups since my last post: after 30 cycles and after 10.

It loooks like this is [http://bugzilla.kernel.org/show_bug.cgi?id=5555 kernel bug #5555]

--[[User:Mbg71|Malcolm]] 00:04, 3 October 2006 (CEST)

== Unable to resume R40e after suspend-to-RAM ==

Suspend-To-RAM works fine, but after going to sleep,
the laptop (R40e) can't be woken up. It doesn't respond to
anything, the battery has to be removed in order to
reset it. I tried many different setups, but the
problem persists. Any ideas, please?

== T60p Docking While Suspended ==

My T60p exhibits the problem where if I dock it while it's asleep, it shuts off. Has anyone gotten a response from Lenovo about this problem? Is there a fix? I'm getting tired of waking up my laptop before docking it.--[[User:Sridhar|Sridhar]] 17:50, 2 January 2007 (CET)

Talk:ThinkPad Advanced Mini-Dock

2007-01-02T13:38:38Z

Sridhar: