Re: [PATCH 11/22] ACPI: EC: Don't use Global Lock if not asked to do so

Does this patch obsolete the patch to "release global lock in acpi_ec_wait"? It's part of bugzilla 6749 "Thinkpad A21m freeze after second supedn to RAM" and its direct url is . Or did

Re: [PATCH 2.6.18 1/1] ACPI: limit cstate on noisy thinkpad t43/p models

Interesting! > Are there any T43 users who do not hear this noise? Not sure about a T43 but I hear a high-pitched noise on my T60. > Do you hear this noise for both AC and battery modes? It happens as soon as I pull out the AC power. Well, more like half a second after. It comes from the lowe

Re: the role of the dstd

Interesting; thanks for the correction. So acpi_serialize isn't necessarily the right option to use? -Sanjoy `Never underestimate the evil of which men of power are capable.' --Bertrand Russell, _War Crimes in Vietnam_, chapter 1. - To unsubscribe from this list: send the line "unsubscr

Re: the role of the dstd

> Is this option "act like windows" really available? Is it a boot > parameter? It is. Add these options to your boot parameters: acpi_os_name="Microsoft Windows" acpi_serialize -Sanjoy `Never underestimate the evil of which men of power are capable.' --Bertrand Russell, _War Crimes

Re: the role of the dstd

> For one, if the DSTD is part of the BIOS, how come windows does > work, while it must rely on the same data I'm not an ACPI expert but here is my understanding. Hopefully it's close enough to reality that the experts need to make only minor corrections and can keep hacking. Often, or rather al

Re: S3 suspend fails with lockdep BUG warning (TP T60, 2.6.18-rc1)

>> > I just did that, but found no /sys/power/state file (or anything under >> > /sys). > You need to mount /sys, first...?! Right. But /proc was also not there, so I just rebooted to runlevel 1 to get both. > > > $ echo mem > /sys/power/state > > > bash: echo: write error: Operation not

Re: S3 suspend fails with lockdep BUG warning (TP T60, 2.6.18-rc1)

[Added LKML to the CC: since lockdep reports more problems when the S3 suspend fails. The hardware is a TP T60, T2400 dual-core, compiled with SMP and PREEMPT, SATA drive, and now also compiled with hotpluggable CPUs. Kernel is 2.6.18-rc1. Suspend worked with 2.6.15-25-386 from Ubuntu using the

Re: S3 suspend fails with lockdep BUG warning (TP T60, 2.6.18-rc1)

> This is a warning from the lock validation code and I think you > should report it separately on LKML. Done. > You can also boot the kernel with init=/bin/bash and trigger the > suspend with 'echo mem > /sys/power/state'. I just did that, but found no /sys/power/state file (or anything under /

S3 suspend fails with lockdep BUG warning (TP T60, 2.6.18-rc1)

I'm trying 2.6.18-rc1, on a Thinkpad T60 (dual-core, T2400) running Ubuntu 6.06. The kernel is SMP, PREEMPT, and has many of the lock validation options turned on. It has a SATA hard drive. During boot the lockdep checker reports good news: [ 20.936404] Good, all 218 testcases passed! | When

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

[Trimmed lists that seemed unrelated: [EMAIL PROTECTED], video4linux-list@redhat.com, linux-usb-devel@lists.sourceforge.net, linux-ide@vger.kernel.org, [EMAIL PROTECTED] > But this Samsung P35 don't have _GLK. So, I think TP 600x has > a different problem with Samsung P35. You're right. I trie

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> This sounds like the problem Daniel had on his Samsung P35 recently. > He could fix it by getting rid of some asus_unhide_smbus stuff or the > otherway around, adding asus_unhide_smbus quirks in the S3 resume code. > > This thread was recently posted on lkml: > Re: [patch] smbus unhiding kills t

Re: Power-button event after resume from S3

> if(acpi_during_suspend_resume) > don't generate power button event to confuse user space daemon This patch might be useful useful in setting and unsetting acpi_during_suspend_resume (and also using it, but you should ignore those as they are hacks for a different problem). The equivalent

Re: Power-button event after resume from S3

> I am investigating a problem where acpid receives a power-button > event immediately after resuming from S3. I looked at the mailing > list archives and found that this problem is not entirely uncommon. Yes, I noticed this problem once I turned on acpi_serialize and told ACPI to pretend I'm runn

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

Some light at the end of a long tunnel of debugging, so the end of this email has a patch for review. This was done with lots of help from Luming Yu. The discussions that went off list for a while are on the bugzilla page [kernel bugzilla #5989]. When ec_intr=1 became the default, my TP 600X sta

Re: ACPI-Problems with debian-etch & Kernel 2.6.16

> These messages appear every 10 seconds! Do you have thermal polling turned on? more /proc/acpi/thermal_zone/*/polling_frequency Not that you should turn the polling off, but maybe every time a thermal poll is run, the embedded controller (ec) does an UPDT, which also means it looks at the batt

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

>> So perhaps I should bisect in _SST and put in the debug lines there? >> Here's another idea, which is a terrible hack. But there are lots of >> lines in the DSDT like >>If (LOr (SPS, WNTF)) >> which I imagine is saying "If something or if WinNT". So, >> what if Linux >> pretends to be WinN

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> Does it mean we need to slow down acpi_ec_intr_read/write ? > Could you try to insert acpi_os_stall (100) after ACPI_DEBUG_PRINT > statement both in acpi_ec_intr_read/write. I added that line in those two places. The result refused to hang with acpi_debug_layer=0x00100010, but it did hang (o

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

Good, then the hang should be caused by: Store (Arg0, HCSL) Store (ShiftLeft (Arg1, 0x01), HMAD) Store (Arg2, HMCM) Store (0x0B, HMPR) Could you add this at the beginning of t

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

How about this. The side effect of this change is that _BIF, _BST could NOT work. But I think it's just ok. Method (I2RB, 3, NotSerialized) { Store (Arg0, HCSL) Store (ShiftLeft (Arg1, 0x01), HMAD)

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

So the kernel with this UPDT() hung at the 2nd sleep: Method (UPDT, 0, NotSerialized) { If (IGNR) { Decrement (IGNR) } Else

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

I tried the following kernels (all with only THM0): 1. No other changes: It hangs, as before and as expected. 2. Commented out a large chunk of the UPDT() method: diff -r ac2b38909dfa -r c431c477d3b6 dsdt/600x.dsl --- a/dsdt/600x.dsl Tue Mar 21 17:12:47 2006 -0500 +++ b/dsdt/600x.dsl Wed

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> Please don't give up . :-) I haven't! > I need to know which statement in EC0.UPDT that could trigger the > problem. That is very important to understand the problem > correctly. > This is still my assumption that some AML code needed to be avoided > in suspend/resume, I need data support. So

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> We can do bisection in EC0.UPDT to find out which statement cause > hang? Yes, though see below for why I don't think it'll help no matter what we find there. > My assumption is that since Windows works well, then these BIOS code > should have been tested ok. The only possible excuse for BIOS i

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

Two more experiments: With a vanilla kernel, I faked EC0.UPDT() to just return 0x00, and the system hung on the second sleep. Then, again in the DSDT, I also faked the 4 _TMP methods (one in each thermal zone), and the system hung on the second sleep. I think we've raced too far ahead by

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

The following tests all have acpi_evaluate_integer() hacked to return _TMP=27C. >> The kernel panic for the don't-load-THM2 kernel is very strange. I >> had another kernel panic while doing another set of tests, which I >> also couldn't explain. The only difference between the no-THM0 and >> the

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

With _TMP faked in the kernel and one whole zone ignored, this is what I get: Zone to ignore | Result THM0OK (10 cycles) THM2"kernel panic! attempted to kill init" THM6

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> From pervious experience, we know _THM0._TMP causes problem. If you > fake _TMP for all THM, what could happen? It still hangs on the second sleep. I faked them in the kernel instead of the DSDT, by faking them in acpi_evaluate_integer() like so: diff -r ac486e270597 -r 959c4fa10a36 drivers/a

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> I think you need to continue to find out which THMs, which methods > cause s3 hang when THM0._TMP disabled. So far I've found that if (with no THM0 loaded) I load exactly one of THM2, THM6, or THM7, then there's no hang. Now I am looking for which combinations of the THM[0267] zones cause the p

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> Maybe I need to make a summary here for this issue: > 1. The s3 hang is in While-loop in SMPI that looks like > waiting BIOS response. Right. > 2. If THM2, THM6, THM7 disabled, disabling THM0._TMP > fix the s3 hang. Right. And many ways of disabling THM0._TMP fix the hang: 1. making acpi_eva

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> Do you load processor driver? It's loads at boot. When thermal loads, it pulls in processor: $ lsmod | grep thermal thermal17224 0 processor 30080 1 thermal -Sanjoy `Never underestimate the evil of which men of power are capable.' --Bertrand Russell,

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

>> PM: Preparing system for mem sleep >> Stopping tasks: >> ===| > Did you see any methods before and after this line in hang case on > screen? If yes, do you recall what they are? I capture across a serial console, so here are the exact msgs

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> just return AE_OK, because we are hacking. :-) I found that out the hard way. I first tried AE_BAD_PARAMETER but the kernel paniced on boot, which I don't understand. So then I switched to returning AE_OK, and it booted fine. But it hung on the *second* sleep cycle. So the problem got worse,

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> Please try additional ugly hack > 5. in acpi_os_queue_for_execution: > if(acpi_in_suspend == YES) > do nothing. Am compiling it. If acpi_in_suspend, I've had it do return_ACPI_STATUS(AE_BAD_PARAMETER). Is there a better error code to use? I didn't want to use AE_OK, since

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> Hmm, probably, you need to do : > > 4. in acpi_thermal_notify, > if (acpi_in_suspend == YES) > do nothing. I've just tested that. It suspended twice without problem, which made me think the problem was solved. But it hung on the third suspend! I placed all the source unde

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

>> Which is why I think the minimal change is the diff above to >> utils.c [to make acpi_evaluate_integer fake _TMP]. With that >> change the system never hung. > Good, this is exactly what I wanted. How many times you tested with > this hack without hang? Sadly, I just tried it again and it hu

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> So, please try hack thermal.c by removing calls to _TMP. I did something like that before, by changing acpi_evaluate_integer() to return 3000 if it is asked for _TMP. --- a/utils.c 2006-03-15 01:42:34.0 -0500 +++ b/utils.c 2006-03-14 23:36:59.0 -0500 @@ -270,7 +270,15 @@ a

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> How about re-testing dummy _PSV and dummy _AC0 in DSDT? Just retested and you were right. This time I managed to get it to hang, after many cycles of sleep.sh and "modprobe -r thermal ; modprobe thermal" mixed in. -Sanjoy `Never underestimate the evil of which men of power are capable.'

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

By the way, I wonder if this problem is the same as , about S3 hangs with kernel pre-empts enabled. > How about re-testing dummy _PSV and dummy _AC0 in DSDT? I'll do that. It's the one data point that I'm not sure about. With dummy _PSV, it hangs

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> Hmm, we can continue to have fun with debugging. Right? Definitely, I haven't given up. >> The second sleep.sh hangs going to sleep. It is in an endless loop >> printing the following line, once per second (from the >> polling_frequency): >> >> Execute Method: [\_TZ_.THM0._TMP] (Node c157bf8

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

Bad news. It hangs when I do the usual stress test: echo 1 > THM0/polling_frequency sleep.sh sleep.sh The second sleep.sh hangs going to sleep. It is in an endless loop printing the following line, once per second (from the polling_frequency): Execute Method: [\_TZ_.THM0._TMP] (Node c157bf88

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> To verify this, please hack acpi_thermal_active. Do you mean hack it for now to return without doing anything (like if 'tz' wasn't valid)? Or do it farther in the function, like by changing result = acpi_bus_set_power(active->

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> I found the common code in _PSV and _AC0 >Store (DerefOf (Index (DerefOf (MODP (0x01)), Local1)), Local0) > Could you just comment out that? It doesn't hang. Though it seemed close to hanging a couple times, but after a 5-10 second pause always managed to go to sleep. I tried about 15 slee

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

Okay it's compiling with that change. Now those two methods look like: Method (_PSV, 0, NotSerialized) { /* Store (DerefOf (Index (DerefOf (MODP (0x00)), 0x01)), Local0) */ Return (Local0) } Method (_AC0, 0, NotSerialized) { If (H8DR)

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

I started subdividing the _TMP method, and found that hangs: -AC0 (as reported in the last email) okay: -AC0-TMP (also in last email) but okay: -AC0-one line of TMP, by which I mean getting rid of the EC0.UPDT() line below: Method (_TMP, 0, NotSerialized) {

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

Here the test results on the DSDT variants, as a tree. THM0 is the root (meaning a DSDT with only THM0). -XYZ means 'fake the method XYZ in THM0, relative to the situation in the parent DSDT': hang:THM0 okay: -TMP hang: -PSV okay: -AC0 (i.e. THM0 methods

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

Your intuition was right. Testing by changing only the DSDT gives slightly different results than by changing the kernel drivers. So far the results: with only THM0 in the DSDT: HANGS (but only on the second sleep, not the first one, so a slight difference with the kernel-testing data) with

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

[Sorry, forgot to reply to all the first time.] How about this plan (basically what you suggested, but I want to confirm its sensibility since these tests take a while): Since I know (or think I know) that just THM0 with just _TMP causes problems when investigating it by modifying the kernel, I'l

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> If you do it in this way, all thermal zone's _TMP will be faked. Loading 'thermal' with zone_to_keep=0 meant that it skipped THM{2,6,7} (the only other zones). But only THM0 was loaded, so any path that included, say, THM2._TMP wouldn't get executed because of lines like: if (!tz)

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

One sad piece of data that I came across, perhaps worth investigating further after this one is chased down: As described in the last email, the combination of _TMP fakery (in utils.c) plus the bisecting version of thermal.c (loading only the zone THM0 and then only up to bisect_get_info=1) got ri

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> Could you just comment out _TMP in kernel or in DSDT, I think it needs both excisions: If I comment out just the kernel _TMP calls, the DSDT might slip one in through the interpreter. If I comment out just the DSDT _TMP calls, then the kernel can still call _TMP. So instead I modified acpi_ev

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

[I've trimmed non-relevant lists ([EMAIL PROTECTED], video4linux-list@redhat.com, linux-ide@vger.kernel.org, [EMAIL PROTECTED], linux-usb-devel@lists.sourceforge.net) from the CC. Let me know if anyone else wants to be trimmed.] > Could you do bisection to find out which methods or which thermal

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> Hmm, could you file dmesgs with thermal module loaded and unloaded? Filed at bugzilla. > I saw this acpi_debug=0x. Sorry, it's a legacy from trying to debug #5112, and I've removed it for getting the above dmesgs. I'm not even sure what that option does since it's not documented in th

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> Could you try to mute thermal poll? Done. The sleep.sh script now has echo 0 > /proc/acpi/thermal_zone/THM2/polling_frequency echo 0 > /proc/acpi/thermal_zone/THM0/polling_frequency sleep 1 > I need the full log for S3 suspend failure not just snippets. > Please attach it on bugzilla.kernel.

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> I need the acpi trace log before _PTS to see what kind of thermal > related methods got called. Alas, I've included all the dmesg's. Below is the script that I use to enter S3 sleep. It unloads rid of troublesome modules and stop services that don't sleep well. Then (for debugging) it sends

Re: acpi resume

> The "acpi drivers" themselves don't have suspend/resume methods yet. > Others need them too, the biggest is the button driver that needs to > forget events that happened during suspend, and the next one is > probably thermal, which doesn't restore the user-supplied > trip-points. The change to t

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

Actually, there's no point only attaching it at bugzilla, since the relevant output is shorter than I thought: /proc/cmdline: auto BOOT_IMAGE=16-rc5 ro root=305 idebus=66 apm=off acpi=force pci=noacpi console=ttyS0,115200 console=tty0 acpi_sleep=s3_bios cpufreq.debug=7 acpi_debug=0x whe

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> What do you mean of "slither away" ? > bug go away? I can no longer trigger it, at least not with the usual procedure. I doubt that it goes away (i.e. that it is solved), only that it slithers into hiding, like bugs that disappear when compiling a C program with -g but show up when compiling w

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

> I assume you have tested ec_intr=0 and ec_intr=1. Right: I forgot to mention it, but I did test it both ways, and ec_intr=0 is fine. >> These noises happen when printing via the wireless card or via USB >> (to a different HP inkjet), > Interesting, open bug for this. I cannot reproduce it wit

Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

[Re: bugme #5989, head no longer hanging in shame] From: "Yu, Luming" <[EMAIL PROTECTED]> > I suggest you to retest, and post dmesg with UN-modified BIOS. I'm now running/testing an unmodified DSDT with 2.6.16-rc5. For a while I had no S3 hangs, but I just noticed them again. The error is the s

Re: 2.6.16-rc5: known regressions

>> I'll try it, although I don't think I'll get any data on the problem. >> The unmodified DSDT (bios 1.11) lacks an S3 sleep object, so I had to >> modify the DSDT even to get S3 to sleep at all. See >> for that discussion. > I think it's arguabl

Re: 2.6.16-rc5: known regressions [600X S3 sleep]

Subject: S3 sleep hangs the second time - 600X References : http://bugzilla.kernel.org/show_bug.cgi?id=5989 >>From: "Yu, Luming" <[EMAIL PROTECTED]> >>> According to bug report, the BIOS DSDT is modified. I don't know >>> how these changes affect the results of suspend/resume. But,

Re: 2.6.16-rc5: known regressions

>> Subject: S3 sleep hangs the second time - 600X >> References : http://bugzilla.kernel.org/show_bug.cgi?id=5989 From: "Yu, Luming" <[EMAIL PROTECTED]> > According to bug report, the BIOS DSDT is modified. I don't know > how these changes affect the results of suspend/resume. But, it is > cl

Re: [linux-usb-devel] Re: Linux 2.6.16-rc3

>>> I don't think anybody claimed this isn't a regression for the 600X. >> I narrowed it further. The short story is that this commit (diff >> below sig) makes the second S3 sleep go into the endless loop, if >> the loaded modules are exactly thermal, processor, intel_agp, and >> agpgart: > If y

confused fan after S3 resume (TP 600X)

System: 2.6.16-rc2 (and on many kernels in between 2.6.15 and 2.6.16-rc2) Hardware: TP 600X + modified DSDT After S3 resume, the fan returns confused. Before the suspend, all is good. When it's hot the fan is on, and the system thinks that the fan is on: $ acpi -t Battery 1: charged, 9

Re: Linux 2.6.16-rc3

> I don't think anybody claimed this isn't a regression for the 600X. I narrowed it further. The short story is that this commit (diff below sig) makes the second S3 sleep go into the endless loop, if the loaded modules are exactly thermal, processor, intel_agp, and agpgart: 53f11d4ff8797bcceaf0

Re: Linux 2.6.16-rc3

> I think we can assume that it will be seen there. 2.6.16 is going into > distros and will have more exposure than 2.6.15, let alone > 2.6.16-rcX. A related point is that S3 sleep/wake problems are very difficult to debug. The bug is often not reproducible (I've had a few of those). Or it happe

Re: Linux 2.6.16-rc3

> systems newer than 6 years old. According to the sticker on the bottom, this model was made in 04/2000, so the 6 years is right. > We're talking here about a system from 1999 where Windows 98 refuses > to run in ACPI mode and instead runs in APM mode. I haven't tried Windows 98 on this machine

S3 sleep regression bisected (was Re: Linux 2.6.16-rc3)

> In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy Mahajan has > another regression, but he's off collecting more info. Now collected. The problematic commit is: bad: [292dd876ee765c478b27c93cc51e93a558ed58bf] Pull release into acpica branch The longer story follows (and I

Re: Linux 2.6.16-rc3

> In http://bugzilla.kernel.org/show_bug.cgi?id=5989, Sanjoy Mahajan has > another regression, but he's off collecting more info. I'm nearly done with bisecting (spent a day on a wild bisect goose chase due to being careless) and I'm 95% sure the problem is i

Re: S3 sleep regression / 2.6.16-rc1+acpi-release-20060113

> After the first suspend, do you have any processes sucking all > available cpu? This sounds like a thread that has been added since > 2.6.15, which is being told to enter the freezer, but isn't doing > it. They usually end up sucking cpu afterwards. A good thought. I just tried it again. The s

S3 sleep regression / 2.6.16-rc1+acpi-release-20060113

The gory details are at , but the short summary: With 2.6.15, S3 sleep and wake were 98% fine (once in a while waking would hang, but I haven't managed to reproduce it). However, with 2.6.16-rc1 with the acpi-20060113 patch, the first sleep and wak

Re: debugging 600E

>> osl-0854 [545] os_wait_semaphore : Failed to acquire >>semaphore[e3fce660|1|100], AE_TIME > Probably an EC issue. Do you still see this with the latest > ACPI patch or mm tree (which includes EC interrupt mode). I just tried 2.6.16-rc1 + acpi-release-20060113-2.6.16-rc1.diff.

Re: debugging 600E

>From > Looking at the Thinkpad web site, there is a newer BIOS for the > 600E. I've got INET28WW (1.08), and INET36WW (1.16) is available. Just a word of warning about the 600X bios dates, which might apply to the 600E as well. On the 600X, the

truncated output from /proc/acpi/debug_level

[bug #5076] 'cat /proc/acpi/debug_level' will truncate output sometimes (to reproduce it for sure, read one byte at a time unbuffered, e.g. using the C program in the bugzilla entry). I submitted a patch via the bugzilla in the 2.6.13 era, but it doesn't seem to have made it into mainline, so I'v