You are not logged in.

#26 2013-02-13 08:00:47

David Batson
Member
Registered: 2011-10-13
Posts: 640

Re: [solved?] possible reasons for random shutdowns

You might try sending a PM to Mark_Lenovo on Lenovo's forum regarding your warranty issue.  He's been known to cut through the red-tape (at least in the past).  You also might try posting your issue over there in the appropriate forum.

http://forums.lenovo.com/t5/Welcome-FAQs/bd-p/Hello

Offline

#27 2013-02-13 09:06:36

Lord Bo
Member
Registered: 2012-11-11
Posts: 168

Re: [solved?] possible reasons for random shutdowns

cfr wrote:

Today it didn't correspond with any such messages from wicd so I think it was pure coincidence.

What I don't understand is why the problem should be so much more severe when I'm on campus than when I'm at home, for example. Is the damn thing just antisocial?

Hi, I'm sorry to hear, that you dont have any luck. But If these errors have a regional connection, then all the more I would suspect the wireless device. Have you tried to shut it down, whilst you are at the university?
edit: The shutdowns of course could also stem from any other communication interface: bluetooth, ... etc.; and it could be necessary to should them down physically.

Last edited by Lord Bo (2013-02-13 10:23:44)

Offline

#28 2013-02-14 00:59:10

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [solved?] possible reasons for random shutdowns

Do you mean have I tried shutting the wifi off? If so, just in software, soft blocking or in the BIOS?


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#29 2013-02-14 11:19:09

Lord Bo
Member
Registered: 2012-11-11
Posts: 168

Re: [solved?] possible reasons for random shutdowns

I am not sure about that, but if I could disable it in bios, I would do that (just to test, if that stops the laptop from shutting down after that, one has to think about what to do next).
It may be a bit off-topic, but well, have it for your entertainment: Our software engineering professor told us the following story:
There was a car manufactoring company, which once got aware of some very strange behaviour of their cars. In a special region (I think it was in Canada, but I'm not sure.) their cars lost their whole battery capacity overnight. (They know that, because they get statistics when and why car owners are frequenting repair stattions.) So they did, what these companies do usually in such cases: They took some of these cars back and put them into their garages overnight, to see, what happens. Unfortunatly nothing did happen. (As I said, this problem was confined to some very special region.)
Of course by now they know what caused the problem: In this very special region, there was a radio station broadcasting a signal on a frequency, which shouldn't have been used at all. God knows why... What happend was, that the radios inside the cars got hold of this frequency and when the cars were shut down, the radios powered up and then with it the rest of the cars' systems. Overnight, these cars lost all their battery power...
Well, I am not sure, if there is somthing at your campus, that provokes your systems to shut down your laptop, but I would give it a try. And of course this is not restricted to wlan, but to any device which could be affected by some foreign signal.

Last edited by Lord Bo (2013-02-14 11:22:28)

Offline

#30 2013-03-26 14:57:48

zeroos
Member
Registered: 2013-03-26
Posts: 1

Re: [solved?] possible reasons for random shutdowns

Did you manage to solve the problem somehow? Around a week ago exactly the same thing started happening to me on Lenovo TP X61. I've tried everything that was suggested in this thread except for running my laptop on AC without battery. I have my old battery at home, so today I'll check if replacing it helps...

Offline

#31 2013-03-26 17:14:33

mich41
Member
Registered: 2012-06-22
Posts: 796

Re: [solved?] possible reasons for random shutdowns

Did you update the kernel (or any other packages) at this time?

Maybe acpi=off ?

Offline

#32 2013-03-26 17:36:25

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: [solved?] possible reasons for random shutdowns

Some things I would check, based on the struggle I've had in the past, to get my laptop stable:

Add to the bootloader's kernel commandline, for clocksource:

hpet=disable processor.max_cstate=1 nohz=off

And check that your HZ is under 1000, since I strongly suspect that was causing occasional hanging on my laptop:

zgrep HZ /proc/config.gz

300 HZ, and also custom entries of 432 and 600, have been OK for me. My laptop's perfectly stable.

Offline

#33 2013-03-26 23:20:57

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [solved?] possible reasons for random shutdowns

@zeroos,

Not yet. I'm assuming it is hardware related somehow.

@mich41,

Don't really want to lose acpi... This has happened through many kernels and many updates so I doubt it is that specific.

@brebs,

Hmm... Thanks. What do those do? I followed the link but am not much the wiser, to be honest. That is, I have no idea what that discussion is even about. I get 300 HZ for the zgrep command, by the way. I'm using the stock, stable kernel so I guess that's the default.

Last edited by cfr (2013-03-26 23:21:47)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#34 2013-03-27 05:27:31

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: [solved?] possible reasons for random shutdowns

cfr wrote:

What do those do?

C'mon, Google is your friend, as your sig implies wink

A quick check of what you're using:

dmesg | grep -i clock

You may well be using HPET, which is a bad choice (that the kernel makes) for some hardware.

TSC is fastest, and a very reasonable choice of clocksource. processor.max_cstate=1 may be needed, to make TSC stable/usable, as it is for me.

nohz=off turns off NOHZ, which is just an unnecessary complication when one is trying to stabilize a system.

They are safe options. Basically they say: any clocksource except HPET, with some power-saving turned off.

Offline

#35 2013-03-27 09:35:48

mich41
Member
Registered: 2012-06-22
Posts: 796

Re: [solved?] possible reasons for random shutdowns

Disabling acpi or nohz for one day may (or may not smile) help in nailing down the source of your problems.

BTW, i3 shouldn't need max_cstate=1 to make tsc usable and tsc should already be used by your system (check /sys/devices/system/clocksource/clocksource0/current_clocksource). Disabling C-states will have the side effect of switching your laptop to so-called space heater mode smile

Offline

#36 2013-03-27 17:30:36

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: [solved?] possible reasons for random shutdowns

No, max_cstate=1 isn't that bad. 1 is the first power-saving mode, so it still allows some power-saving. It's not the idle=poll bad option wink

Heat-wise, I don't notice a difference with max_cstate=1, and I'm in a hot climate.

Offline

#37 2013-03-27 20:49:11

combuster
Member
From: Serbia
Registered: 2008-09-30
Posts: 711
Website

Re: [solved?] possible reasons for random shutdowns

Ok, can you upload full dmesg output on the laptop after a decent uptime (~1hr). Also can you do

grep . /sys/class/power_supply/*/*

once when plugged and once when unplugged from AC and post  it here.

This sounds as ACPI related. Bad BIOS/UEFI programming can lead to this.

Please install iasl compiler from the repos and do the following as root:

cat /sys/firmware/acpi/tables/DSDT > ~/dsdt.dat
iasl -d ~/dsdt.dat

and upload dsdt.dsl from your root home directory.

Offline

#38 2013-03-28 00:08:15

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [solved?] possible reasons for random shutdowns

It uses hpet for less than 1 second before switching to tsc. There are 3 sources available: hpet tsc acpi_pm. But it is using tsc.

Sorry about the question. I thought that clocksource would return a bunch of stuff about clocks. I didn't think about it being a single word, for some reason. Instead, I found stuff saying hpet was a good option and tsc was not which is the opposite of what people here are saying.

Contents of power supply files on AC:

ACAD/online:1
ACAD/type:Mains
ACAD/uevent:POWER_SUPPLY_NAME=ACAD
ACAD/uevent:POWER_SUPPLY_ONLINE=1
BAT1/alarm:3108000
BAT1/capacity:95
BAT1/cycle_count:0
BAT1/energy_full:46970000
BAT1/energy_full_design:62160000
BAT1/energy_now:45040000
BAT1/manufacturer:SANYO
BAT1/model_name:42T4957
BAT1/power_now:0
BAT1/present:1
BAT1/serial_number: 1755
BAT1/status:Unknown
BAT1/technology:Li-ion
BAT1/type:Battery
BAT1/uevent:POWER_SUPPLY_NAME=BAT1
BAT1/uevent:POWER_SUPPLY_STATUS=Unknown
BAT1/uevent:POWER_SUPPLY_PRESENT=1
BAT1/uevent:POWER_SUPPLY_TECHNOLOGY=Li-ion
BAT1/uevent:POWER_SUPPLY_CYCLE_COUNT=0
BAT1/uevent:POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11100000
BAT1/uevent:POWER_SUPPLY_VOLTAGE_NOW=12745000
BAT1/uevent:POWER_SUPPLY_POWER_NOW=0
BAT1/uevent:POWER_SUPPLY_ENERGY_FULL_DESIGN=62160000
BAT1/uevent:POWER_SUPPLY_ENERGY_FULL=46970000
BAT1/uevent:POWER_SUPPLY_ENERGY_NOW=45040000
BAT1/uevent:POWER_SUPPLY_CAPACITY=95
BAT1/uevent:POWER_SUPPLY_MODEL_NAME=42T4957
BAT1/uevent:POWER_SUPPLY_MANUFACTURER=SANYO
BAT1/uevent:POWER_SUPPLY_SERIAL_NUMBER= 1755
BAT1/voltage_min_design:11100000
BAT1/voltage_now:12745000

Do you want the sub-directory names it lists as well? I have no idea what I am looking for.

And on battery:

ACAD/online:0
ACAD/type:Mains
ACAD/uevent:POWER_SUPPLY_NAME=ACAD
ACAD/uevent:POWER_SUPPLY_ONLINE=0
BAT1/alarm:3108000
BAT1/capacity:95
BAT1/cycle_count:0
BAT1/energy_full:46970000
BAT1/energy_full_design:62160000
BAT1/energy_now:44780000
BAT1/manufacturer:SANYO
BAT1/model_name:42T4957
BAT1/power_now:8084000
BAT1/present:1
BAT1/serial_number: 1755
BAT1/status:Discharging
BAT1/technology:Li-ion
BAT1/type:Battery
BAT1/uevent:POWER_SUPPLY_NAME=BAT1
BAT1/uevent:POWER_SUPPLY_STATUS=Discharging
BAT1/uevent:POWER_SUPPLY_PRESENT=1
BAT1/uevent:POWER_SUPPLY_TECHNOLOGY=Li-ion
BAT1/uevent:POWER_SUPPLY_CYCLE_COUNT=0
BAT1/uevent:POWER_SUPPLY_VOLTAGE_MIN_DESIGN=11100000
BAT1/uevent:POWER_SUPPLY_VOLTAGE_NOW=12553000
BAT1/uevent:POWER_SUPPLY_POWER_NOW=8084000
BAT1/uevent:POWER_SUPPLY_ENERGY_FULL_DESIGN=62160000
BAT1/uevent:POWER_SUPPLY_ENERGY_FULL=46970000
BAT1/uevent:POWER_SUPPLY_ENERGY_NOW=44780000
BAT1/uevent:POWER_SUPPLY_CAPACITY=95
BAT1/uevent:POWER_SUPPLY_MODEL_NAME=42T4957
BAT1/uevent:POWER_SUPPLY_MANUFACTURER=SANYO
BAT1/uevent:POWER_SUPPLY_SERIAL_NUMBER= 1755
BAT1/voltage_min_design:11100000
BAT1/voltage_now:12553000

If it is ACPI related, why is it so environmentally sensitive? And how would that affect the machine's ability to start up - it doesn't even make POST reliably. (Of course, I realise that could be a different issue.)

More later...

dmesg is uninteresting - iptables fills it too quickly. I can get stuff from the journal, though. (That's how I got the information about the switch hpet -> tsc on boot.)

Last edited by cfr (2013-03-28 00:11:18)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#39 2013-03-28 00:29:11

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: [solved?] possible reasons for random shutdowns

cfr wrote:

It uses hpet for less than 1 second before switching to tsc. There are 3 sources available: hpet tsc acpi_pm. But it is using tsc.

Hah. Wrong. That's what I thought, initially, until I still got this garbage in the log:

CE: hpet increased min_delta_ns to 20113 nsec

Obviously, HPET was still being used in some way (not sure of how or why).

So, you still need hpet=disable, if doing the test I mentioned.

Offline

#40 2013-03-28 00:51:21

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [solved?] possible reasons for random shutdowns

How can I tell if it is doing that? There is no occurrence of hpet in the output of journalctl -b after the switch to tsc.

I've started looking through the output of the iasl decompilation but there is a lot of it. Is there anything I should remove before posting it somewhere? I can't see anything obvious but it does not help that I don't have much idea what I'm looking at.

I hate doing this stuff blind.

I'm still not sure how this stuff could affect the machine differentially in different environments. And it would have to be a separate issue affecting the ability to boot at all, right? Since that issue occurs prior to anything to do with the boot manager, boot loader or OS...

Last edited by cfr (2013-03-28 00:52:06)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#41 2013-03-28 02:05:53

brebs
Member
Registered: 2007-04-03
Posts: 3,742

Re: [solved?] possible reasons for random shutdowns

cfr wrote:

There is no occurrence of hpet in the output of journalctl -b after the switch to tsc.

Look *before* also. If you have e.g. "ACPI: HPET id:", then that's bad, if you're doing my test.

Just change your bootup commandline, and reboot, and see if the laptop's more stable. Too much chatter.

Offline

#42 2013-03-28 06:22:40

combuster
Member
From: Serbia
Registered: 2008-09-30
Posts: 711
Website

Re: [solved?] possible reasons for random shutdowns

I was wondering if it's detecting the parameters when on/off battery correctly. It does.

Regarding ACPI dsdt, do a "cat dsdt.dsl | grep Windows" and try to add kernel parameter

acpi_os_name="Windows XXXX" where XXXX should be replaced with 2009 or anything that above command returned as a result. Try with different versions of Windows XXXX parameter and see if that helps.

I'm still not sure how this stuff could affect the machine differentially in different environments. And it would have to be a separate issue affecting the ability to boot at all, right? Since that issue occurs prior to anything to do with the boot manager, boot loader or OS...

but you said yourself:

The "reboot" messages still suggest something software to me. How would a "reboot" entry get into the log if it was hardware? Not that I want to rule anything out and the issue is definitely weird enough for me to believe almost anything at this point.

So we first have to look what affects both hardware and software and usually gives headaches to a lot of Linux users (on laptops mostly). Almost every other issue is ACPI related (power management, backlighting, propper device detection etc...). About enviromental issues - could it actually be a nasty coincidence ?

Offline

#43 2013-03-28 09:07:59

mich41
Member
Registered: 2012-06-22
Posts: 796

Re: [solved?] possible reasons for random shutdowns

cfr wrote:

If it is ACPI related, why is it so environmentally sensitive? And how would that affect the machine's ability to start up - it doesn't even make POST reliably.

???

So it dies randomly during POST as well?

Last edited by mich41 (2013-03-28 09:08:18)

Offline

#44 2013-03-28 11:17:09

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,848

Re: [solved?] possible reasons for random shutdowns

About 3 years ago i was assisting in troubleshooting an erratic problem with a laptop :
In some locations it would have connection problems, random hangs or need several tries to even get passed POST.
In the majority of locations it worked fine hoewever.

The cause was found to be EM interference, and EM tests by the manufacturer on the laptop showed the shielding was at the lower end of specifications.
(Setting up a metal screen around the laptop made the problems go away completely).

Cfr, has the EM shielding of your laptop been tested ?


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Offline

#45 2013-03-28 22:45:17

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [solved?] possible reasons for random shutdowns

@Lone_Wolf,
EM being electromagnetic emissions? As far as I know, no, that's not been tested (unless the IT dept or Lenovo did it and didn't mention it).

@brebs/combuster,
I'll try disabling hpet and/or the osi thing. One reason I'm asking questions is because there is no simple way to test it. That is, if it doesn't work, I may know quickly but if it does, I'd have to wait a while.  (Possibly months to be sure.) Also, booting is something which I'm scared may not work at all each time I have to do it.

@combuster,
It seems very unlikely, at this point, that the environmental sensitivity is sheer coincidence. I can't rule that out but it seems very unlikely. I don't think the environment is the cause but I think something about some environments exacerbates the issue.

@mich41,
Not in the same way. It does not just stop. It "stutters". A bit like a car trying to start on a cold morning but not quite catching. It makes some noise and the think led flashes, and it fails, so it tries again and again. The only way to end it, that I know of, is to hold the power switch to shut the power off and then try again. I don't get anything on the screen. I think that means it does not make POST but I could be wrong about that as I'm not sure why I believe it.

Anyway, just now, it seemed to be getting rather hot. I put it to sleep and it "stuttered" when I tried to wake it and I had to cold reboot. It has never stuttered like that except at power on before so the problem is definitely escalating. (This is another reason I suspect hardware - either that or Linux is getting worse for it.)

Edit: I realised that the filesystem error dosfsck is finding is really a different issue so I have put it in a new thread at https://bbs.archlinux.org/viewtopic.php … 7#p1250937. It may be caused by the issue(s) in this thread, but it is nonetheless a different issue, I take it. I should have done this originally and hope moving it there is acceptable. (I didn't ask a mod to move the thread because it is just part of one post.)

Last edited by cfr (2013-03-28 23:59:12)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#46 2013-03-28 23:12:20

mich41
Member
Registered: 2012-06-22
Posts: 796

Re: [solved?] possible reasons for random shutdowns

So it randomly doesn't even POST and Lenovo says it's all OK?

Last edited by mich41 (2013-03-28 23:13:18)

Offline

#47 2013-03-28 23:28:15

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [solved?] possible reasons for random shutdowns

Well, it is rather hard to reproduce and I've spent the past 4 months trying to get them to recognise that the machine is covered by warranty, so it isn't at all clear what they say.

But I would be very interested to know if *software* could do that.

What I don't know, of course, is whether I'm looking at one issue, two issues or three or more.

Update: just FYI: I am currently trying to reproduce the issue using different (less memory). So far, I can compile gcc-gcj successfully with 2G memory, a bunch of stuff unmounted and bluetooth disabled. Now I've reset bios to get bluetooth etc. working and I've already reproduced the boot-stuttering issue with the 2G memory. Something odd seems to have happened to my function keys, as well. Sigh. And the laptop claimed it could not unmount /var when I shutdown so I had to hold the power off. Anyway, I want to try this without making any other changes for now just to rule out a non-Lenovo hardware issue. (Though clearly if it can't boot reliably with all-Lenovo hardware something is wrong somewhere.) I think I've done this before but the issue has been so persistent I'm starting to lose track somewhat.

Anyway, I will return to the other suggestions shortly and report back. Thanks again.

Last edited by cfr (2013-03-29 23:33:35)


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#48 2013-03-31 15:54:57

WonderWoofy
Member
From: Los Gatos, CA
Registered: 2012-05-19
Posts: 8,414

Re: [solved?] possible reasons for random shutdowns

cfr, instead of doing a hard shutdown with the power button, you need to learn how to use the magic SysRq key.  I assume your keyboard is similar to mine, in that it does not have all th fact ThinkVantage buttons and whatnot.  But because of this there is also no marked SysRq key either.  But mine turned out to be the PrtSc (Print Screen) key as it typically is on other machines.

Do "xmodmap -pke | grep -i sys_req" to see if your keyboard has this key assigned.  If it does, hold Alt (Mod1), then SysRq (in my case PrtSc), then in this order, do R, E, I, S, U, B.

The R will change the keyboard mode.  The E will send a SIGTERM to all processes.  The I will send a SIGKILL.  The S will do an emergency sync.  The U will remount all filesystems read-only.  And finally the B will reboot the machine safely.

This is all assuming the keyboard is still repsonding of course.  But I was having some dependency issues which was stalling my shutdown process (hanging it actually, as I tried waiting for quite a while a few times), and this definitely feels a whole hell of a lot better than the power button for 5-10 seconds.

To remember it: REISUB = (R)eboot (E)ven (I)f (S)ystem (U)tterly (B)orked

The SysRq key does a whole bunch of other things in Linux.  Here is more info.  It just kind of pains me to hear you doing so many hard shutdowns on an already struggling machine. sad

Offline

#49 2013-03-31 16:35:56

cfr
Member
From: Cymru
Registered: 2011-11-27
Posts: 7,130

Re: [solved?] possible reasons for random shutdowns

Thanks. I'll try that. I tried using this before but I'm pretty sure I used different instructions and I never managed to get the machine to reboot so I'll definitely try with yours. (PrtSc is correct on mine - second level is SysReq.)

Most of my poweroffs occur during boot when the machine stutters and fails to "catch" so to speak. I'm guessing nothing else will work then because the machine hasn't even made post so certainly doesn't know about anything to do with Linux. But if it hangs again on shutdown, I'll try it. (This hardly ever happens, though, so I may not get a chance to try it for a while. Hope not anyway - this machine has enough issues.)

I've ruled out a non-Lenovo hardware cause. I reproduced both issues with Lenovo's original memory so I guess whatever this is, it ain't memory. The problem is definitely worse if I try to compile gcc-gcj. Mostly, this will cause the machine to just stop. Not always, though. I'm ignoring the latest update for now! I don't understand why it is worse, though, since heat has been ruled out.


CLI Paste | How To Ask Questions

Arch Linux | x86_64 | GPT | EFI boot | refind | stub loader | systemd | LVM2 on LUKS
Lenovo x270 | Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz | Intel Wireless 8265/8275 | US keyboard w/ Euro | 512G NVMe INTEL SSDPEKKF512G7L

Offline

#50 2013-03-31 17:20:02

Strike0
Member
From: Germany
Registered: 2011-09-05
Posts: 1,429

Re: [solved?] possible reasons for random shutdowns

I did not manage to get it to REISUB yet (some of the keys are not recognised), but great tip. I'll be looking into that again too.

Writing here since I read the word "stutter" and I had a _little_ bit of the same a while ago with the same notebook model (legacy bios mode):

What happened was that pretty frequently the trackpoint and mouse keys did not work after a cold boot. Touchpad & clickpad did. It was ok to use it, but it seemed to hang/stutter occasionally and system load was odd. A reboot _always_ fixed it. Since the model has a touchpad which runs right to the edge of the case (easy to hit/palm accidently while it boots), I started to take care not to touch it during POST a while ago. Can't be sure it was it, but the stutter/ borked-up trackpoint never happened again till now (& the bug maybe was not inside, but in front of the machine in this instance). Easy one to try.  Good luck.

Offline

Board footer

Powered by FluxBB