Linux 2.6.21-rc1
Subsystems (10)
Re: SATA resume slowness, e1000 MSI warning
In reply to Michael S. TsirkinQuoted 102 lines · Michael S. Tsirkin
Quoted 13 lines
Quoting Eric W. Biederman <[email protected]>:
Subject: Re: SATA resume slowness, e1000 MSI warningQuoted 8 lines · Michael S. Tsirkin
Quoted 3 lines
The only case I can see which might trigger this is if we saved pci-X state and then didn't restore it because we could not find the capability on restore.
Hmm. pci_save_pcix_state/pci_restore_pcix_state seem to only handle regular devices and seem to ignore the fact that for bridge PCI-X capability has a different structure.
Quoted 7 lines
Quoted 1 line
Is this intentional?
Probably not a such. I don't think we have any drivers for bridge devices so I don't think it matters. It likely wouldn't hurt to fix it just in case though.
Do any of the mellanox cards do anything with the bridge on the card?
Yes but they do their own thing wrt saving/restoring registers. Look at
drivers/infiniband/hw/mthca/mthca_reset.cQuoted 4 lines
Quoted 1 line
If not, here's a patch to fix this. Warning: completely untested.
If you fix the offsets and diff this against my last fix (to never free the buffer) I think your patch makes sense.
Let's agree what the correct offsets are.
Quoted 49 lines
Quoted 17 lines
PCI: restore bridge PCI-X capability registers after PM event
Restore PCI-X bridge up/downstream capability registers after PM event. This includes maxumum split transaction commitment limit which might be vital for PCI X.
Signed-off-by Michael S. Tsirkin <[email protected]>drivers/pci/pci.c +0
-1@@ -597,14 +597,19 @@ static int pci_save_pcix_state(struct pci_dev *dev)if (pos <=0 )return 0 ; - save_state =kzalloc (sizeof (*save_state) +sizeof (u16),GFP_KERNEL );drivers/pci/pci.c static int pci_save_pcix_state(struct pci_dev *dev) · line 607
Quoted 10 lines
drivers/pci/pci.c +3
-2+ save_state =kzalloc (sizeof (*save_state) +sizeof (u16) *2 ,GFP_KERNEL );if (!save_state) { -dev_err (&dev->dev,"Out of memory in pci_save_pcie_state\n" ); +dev_err (&dev->dev,"Out of memory in pci_save_pcix_state\n" );return -ENOMEM ; } cap = (u16 *)&save_state->data[0 ]; -pci_read_config_word (dev, pos +PCI_X_CMD , &cap[i++]); +if (dev->hdr_type ==PCI_HEADER_TYPE_BRIDGE ) {This appears to be the proper test.
Quoted 9 lines
drivers/pci/pci.c +5
-0+pci_read_config_word (dev, pos +PCI_X_BRIDGE_UP_SPL_CTL , &cap[i++]); +pci_read_config_word (dev, pos +PCI_X_BRIDGE_DN_SPL_CTL , &cap[i++]); + }else +pci_read_config_word (dev, pos +PCI_X_CMD , &cap[i++]); +pci_add_saved_cap (dev, save_state);return 0 ; }drivers/pci/pci.c static void pci_restore_pcix_state(struct pci_dev *dev) · line 631
Quoted 7 lines
drivers/pci/pci.c +3
-1@@ -621,7 +626,11 @@ static void pci_restore_pcix_state(struct pci_dev *dev)return ; cap = (u16 *)&save_state->data[0 ]; -pci_write_config_word (dev, pos +PCI_X_CMD , cap[i++]); +if (dev->hdr_type ==PCI_HEADER_TYPE_BRIDGE ) { +pci_write_config_word (dev, pos +PCI_X_BRIDGE_UP_SPL_CTL , cap[i++]); +pci_write_config_word (dev, pos +PCI_X_BRIDGE_DN_SPL_CTL , cap[i++]);These look like the proper two registers to save.
Quoted 11 lines
include/linux/pci_regs.h line 332
Quoted 11 lines
drivers/pci/pci.c +2
-0+ }else +pci_write_config_word (dev, pos +PCI_X_CMD , cap[i++]);pci_remove_saved_cap (save_state);kfree (save_state); }include/linux/pci_regs.h +0
-0@@ -332,6 +332,8 @@#define PCI_X_STATUS_SPL_ERR 0x20000000/* Rcvd Split Completion Error Msg */
Quoted 3 lines
include/linux/pci_regs.h
Quoted 3 lines
include/linux/pci_regs.h +1
-0#define PCI_X_STATUS_266MHZ 0x40000000/* 266 MHz capable */ #define PCI_X_STATUS_533MHZ 0x80000000/* 533 MHz capable */ +#define PCI_X_BRIDGE_UP_SPL_CTL 10/* PCI-X upstream split transaction limit */
Quoted 1 line
include/linux/pci_regs.h line 336
Quoted 1 line
include/linux/pci_regs.h +1
-0+#define PCI_X_BRIDGE_DN_SPL_CTL 14/* PCI-X downstream split transaction limit */
Quoted 3 lines
Unless I am completely misreading the spec. While you have picked the right register to save the offsets should be
0x08and0x0cor 8 and 12....
Quoted 8 lines
No, the spec is written in terms of dwords (32 bit), we are storing words (16 bits).
The data at offsets 8 and 12 is read-only split transaction capacity. Split transaction limit starts at bit 16 so you need to add 2 to byte offset.Right?
From that perspective it makes sense. So I will agree with the way you are
thinking the code works.
The read-only and the read-write part are all defined as part of the same register so I didn't expect them to be separate. And I hadn't paid attention enough to see that the code was only saving 16bit values.
Rumor has it that some pci devices can't tolerate < 32bit accesses. Although I have never met one. The two factors together suggest that for generic code it probably makes sense to operate on 32bit quantities, and just to ignore the read-only portion.
Eric
Re: SATA resume slowness, e1000 MSI warning
Quoted 2 lines
Rumor has it that some pci devices can't tolerate < 32bit accesses. Although I have never met one.
hopefully not bridge devices?
Quoted 3 lines
The two factors together suggest that
for generic code it probably makes sense to operate on 32bit quantities, and just to ignore the read-only portion.
The code for regular devices seems to use 16-bit accesses, so I think it's best to stay consistent. Or do you want to change this too?
Signature · 1 line
MST
Re: SATA resume slowness, e1000 MSI warning
Quoted 11 lines · Michael S. Tsirkin
Quoted 2 lines
Rumor has it that some pci devices can't tolerate < 32bit accesses. Although I have never met one.
hopefully not bridge devices?
Quoted 3 lines
The two factors together suggest that
for generic code it probably makes sense to operate on 32bit quantities, and just to ignore the read-only portion.The code for regular devices seems to use 16-bit accesses, so I think it's best to stay consistent. Or do you want to change this too?
If we are stomping rare probabilities we might as well change that too. The code to save pci-x state is relatively recent. So it probably just hasn't met a problem device yet (assuming they exist).
Eric
Re: SATA resume slowness, e1000 MSI warning
Quoted 14 lines
Quoting Eric W. Biederman <[email protected]>:
Subject: Re: SATA resume slowness, e1000 MSI warningQuoted 9 lines · Michael S. Tsirkin
Quoted 2 lines
Rumor has it that some pci devices can't tolerate < 32bit accesses. Although I have never met one.
hopefully not bridge devices?
Quoted 3 lines
The two factors together suggest that
for generic code it probably makes sense to operate on 32bit quantities, and just to ignore the read-only portion.
Quoted 6 lines
Quoted 2 lines
The code for regular devices seems to use 16-bit accesses, so I think it's best to stay consistent. Or do you want to change this too?
If we are stomping rare probabilities we might as well change that too. The code to save pci-x state is relatively recent. So it probably just hasn't met a problem device yet (assuming they exist).
OK I guess. I gather we assume writing read-only registers has no side effects? Are there rumors circulating wrt to these?
Signature · 1 line
MST
Re: SATA resume slowness, e1000 MSI warning
Quoted 2 lines · Michael S. Tsirkin
OK I guess. I gather we assume writing read-only registers has no side effects? Are there rumors circulating wrt to these?
I haven't heard anything about that, and if we are writing the same value back it should be pretty safe.
I have heard it asserted that at least one version of the pci spec only required 32bit accesses to be supported by the hardware. One of these days I will have to look that and see if it is true. I do know it can be weird for hardware developers to support multiple kinds of
decode. As I recall for pci and pci-x at the hardware level the only
difference in between 32bit transactions and smaller ones is the state of the byte-enable lines.
Eric
Re: SATA resume slowness, e1000 MSI warning
Quoted 8 lines
Quoting Eric W. Biederman <[email protected]>:
Subject: Re: SATA resume slowness, e1000 MSI warningQuoted 2 lines · Michael S. Tsirkin
OK I guess. I gather we assume writing read-only registers has no side effects? Are there rumors circulating wrt to these?
Quoted 6 lines
I haven't heard anything about that, and if we are writing the same value back it should be pretty safe.
I have heard it asserted that at least one version of the pci spec only required 32bit accesses to be supported by the hardware. One of these days I will have to look that and see if it is true.
Maybe. But surely before the PCI-X days.
Quoted 3 lines
I do know
it can be weird for hardware developers to support multiple kinds of decode.
Is this the only place where Linux uses pci_read_config_word/pci_read_config_dword? I think such hardware will be pretty much DOA on all OS-es. Why don't we wait and see whether someone reports a broken config?
Quoted 3 lines
As I recall for pci and pci-x at the hardware level the only difference in between 32bit transactions and smaller ones is the state of the byte-enable lines.
True, and same holds for PCI-Express.
So let's assume hardware implements RO correctly but ignores the BE bits - nothing bad happens then, right?
Signature · 1 line
MST
Re: SATA resume slowness, e1000 MSI warning
In reply to Michael S. TsirkinQuoted 90 lines
Quoted 11 lines
Quoted 5 lines
Hmm. pci_save_pcix_state/pci_restore_pcix_state seem to only handle regular devices and seem to ignore the fact that for bridge PCI-X capability has a different structure.
Is this intentional?
Probably not a such. I don't think we have any drivers for bridge devices so I don't think it matters. It likely wouldn't hurt to fix it just in case though.
Do any of the mellanox cards do anything with the bridge on the card?
Yes but they do their own thing wrt saving/restoring registers. Look at
drivers/infiniband/hw/mthca/mthca_reset.cQuoted 4 lines
Quoted 1 line
If not, here's a patch to fix this. Warning: completely untested.
If you fix the offsets and diff this against my last fix (to never free the buffer) I think your patch makes sense.
Let's agree what the correct offsets are.
Quoted 59 lines
Quoted 17 lines
PCI: restore bridge PCI-X capability registers after PM event
Restore PCI-X bridge up/downstream capability registers after PM event. This includes maxumum split transaction commitment limit which might be vital for PCI X.
Signed-off-by Michael S. Tsirkin <[email protected]>drivers/pci/pci.c +0
-1@@ -597,14 +597,19 @@ static int pci_save_pcix_state(struct pci_dev *dev)if (pos <=0 )return 0 ; - save_state =kzalloc (sizeof (*save_state) +sizeof (u16),GFP_KERNEL );drivers/pci/pci.c static int pci_save_pcix_state(struct pci_dev *dev) · line 607
Quoted 10 lines
drivers/pci/pci.c +3
-2+ save_state =kzalloc (sizeof (*save_state) +sizeof (u16) *2 ,GFP_KERNEL );if (!save_state) { -dev_err (&dev->dev,"Out of memory in pci_save_pcie_state\n" ); +dev_err (&dev->dev,"Out of memory in pci_save_pcix_state\n" );return -ENOMEM ; } cap = (u16 *)&save_state->data[0 ]; -pci_read_config_word (dev, pos +PCI_X_CMD , &cap[i++]); +if (dev->hdr_type ==PCI_HEADER_TYPE_BRIDGE ) {This appears to be the proper test.
Quoted 9 lines
drivers/pci/pci.c +5
-0+pci_read_config_word (dev, pos +PCI_X_BRIDGE_UP_SPL_CTL , &cap[i++]); +pci_read_config_word (dev, pos +PCI_X_BRIDGE_DN_SPL_CTL , &cap[i++]); + }else +pci_read_config_word (dev, pos +PCI_X_CMD , &cap[i++]); +pci_add_saved_cap (dev, save_state);return 0 ; }drivers/pci/pci.c static void pci_restore_pcix_state(struct pci_dev *dev) · line 631
Quoted 7 lines
drivers/pci/pci.c +3
-1@@ -621,7 +626,11 @@ static void pci_restore_pcix_state(struct pci_dev *dev)return ; cap = (u16 *)&save_state->data[0 ]; -pci_write_config_word (dev, pos +PCI_X_CMD , cap[i++]); +if (dev->hdr_type ==PCI_HEADER_TYPE_BRIDGE ) { +pci_write_config_word (dev, pos +PCI_X_BRIDGE_UP_SPL_CTL , cap[i++]); +pci_write_config_word (dev, pos +PCI_X_BRIDGE_DN_SPL_CTL , cap[i++]);These look like the proper two registers to save.
Quoted 10 lines
drivers/pci/pci.c +2
-0+ }else +pci_write_config_word (dev, pos +PCI_X_CMD , cap[i++]);pci_remove_saved_cap (save_state);kfree (save_state); }include/linux/pci_regs.h +0
-0@@ -332,6 +332,8 @@Quoted 8 lines
include/linux/pci_regs.h line 336
Quoted 5 lines
include/linux/pci_regs.h +2
-0#define PCI_X_STATUS_SPL_ERR 0x20000000/* Rcvd Split Completion Error Msg */ #define PCI_X_STATUS_266MHZ 0x40000000/* 266 MHz capable */ #define PCI_X_STATUS_533MHZ 0x80000000/* 533 MHz capable */ +#define PCI_X_BRIDGE_UP_SPL_CTL 10/* PCI-X upstream split transaction limit */ +#define PCI_X_BRIDGE_DN_SPL_CTL 14/* PCI-X downstream split transaction limit */ Unless I am completely misreading the spec. While you have picked the right register to save the offsets should be
0x08and0x0cor 8 and 12....
Quoted 3 lines
No, the spec is written in terms of dwords (32 bit), we are storing words (16 bits). The data at offsets 8 and 12 is read-only split transaction capacity. Split transaction limit starts at bit 16 so you need to add 2 to byte offset.
So, Eric, what are your thoughts on this patch (probably wrt 2.6.22)? Since the rest of the save/restore code uses 16 bit transactions, it should be safe here too?
Signature · 1 line
MST
Re: SATA resume slowness, e1000 MSI warning
In reply to Eric W. BiedermanEric W. Biederman wrote:
[CHOP]
Quoted 2 lines
Below is an additional set of warnings that should help debug this. The old code just got lucky that it triggered a warning when this happens.
I'm trying this patch together with the other 2 that you sent out a few days ago. I'm seeing some minor issues with this and lots of bogus warnings as far as I can see.
If I suspend/resume and unload e1000, then reinsert e1000.ko, I immediately hit the WARN_ON at msi.c:516: WARN_ON(!hlist_empty(&dev->saved_cap_space));
I'm not sure that's useful debugging information. even though saved state exists the module has been removed, so you might want to purge the state table when the driver gets removed?
anyway, back to testing.
Auke
Quoted 51 lines
drivers/pci/msi.c +6
-0@@ -613,6 +613,7 @@ int pci_enable_msi(struct pci_dev* dev)return -EINVAL ;WARN_ON (!!dev->msi_enabled); +WARN_ON (!hlist_empty (&dev->saved_cap_space));/* Check whether driver already requested for MSI-X irqs */ if (dev->msix_enabled) {@@ -638,6 +639,8 @@ void pci_disable_msi(struct pci_dev* dev)if (!dev->msi_enabled)return ; +WARN_ON (!hlist_empty (&dev->saved_cap_space)); +msi_set_enable (dev,0 );pci_intx (dev,1 );/* enable intx */ dev->msi_enabled =0 ;@@ -739,6 +742,7 @@ int pci_enable_msix(struct pci_dev* dev, struct msix_entry *entries, int nvec) } }WARN_ON (!!dev->msix_enabled); +WARN_ON (!hlist_empty (&dev->saved_cap_space));/* Check whether driver already requested for MSI irq */ if (dev->msi_enabled) {@@ -763,6 +767,8 @@ void pci_disable_msix(struct pci_dev* dev)if (!dev->msix_enabled)return ; +WARN_ON (!hlist_empty (&dev->saved_cap_space)); +msix_set_enable (dev,0 );pci_intx (dev,1 );/* enable intx */ dev->msix_enabled =0 ;drivers/pci/pci.c +1
-0@@ -677,6 +677,7 @@ pci_restore_state(struct pci_dev *dev) }pci_restore_pcix_state (dev);pci_restore_msi_state (dev); +WARN_ON (!hlist_empty (&dev->saved_cap_space));return 0 ; }
Re: SATA resume slowness, e1000 MSI warning
Quoted 15 lines · Auke
Eric W. Biederman wrote:
[CHOP]
Quoted 2 lines
Below is an additional set of warnings that should help debug this. The old code just got lucky that it triggered a warning when this happens.
I'm trying this patch together with the other 2 that you sent out a few days ago. I'm seeing some minor issues with this and lots of bogus warnings as far as I can see.
If I suspend/resume and unload e1000, then reinsert e1000.ko, I immediately hit the
WARN_ONatmsi.c:516: WARN_ON(!hlist_empty(&dev->saved_cap_space));
Quoted 6 lines
I'm not sure that's useful debugging information. even though saved state exists the module has been removed, so you might want to purge the state table when the driver gets removed?
anyway, back to testing.
Sorry I should have been clear.
With the last two patches I sent out:
pci: Repair pci_save/restore_state so we can restore one save many times.
msi: Safer state caching.
Those WARN_ON's are now totally bogus.
In essence the WARN_ON's were testing to ensure pci_save_state and pci_restore_state were paired.
The assumptions was that pci_restore_state would remove everything from the list that pci_save_state placed on it.
When I reworked the code and removed the bogus pairing requirement it meant that if we ever save state and have a pci-e or pci-x capability we will have a state structure on the list until the kernel reboots.
In summary:pci_save_state and pci_restore_state were making a wrong assumption about the world. The WARN_ON patch tested to ensure the world matched those functions. When I fixed those functions to match the world the WARN_ON's became completely bogus.
Eric
Re: SATA resume slowness, e1000 MSI warning
In reply to Ingo MolnarQuoted 2 lines · Ingo Molnar
with real resume it takes even longer time - but i dont see where the delays come from in that case - i suspect it's SATA.
update: Thomas' PIT/HPET resume-fix patch fixed the delay for me.
Ingo
Re: SATA resume slowness, e1000 MSI warning
In reply to Ingo MolnarQuoted 14 lines · Ingo Molnar
the spin-up takes a few seconds here under suspend/resume simulation:
| ata1: waiting for device to spin up (7 secs)
| Restarting tasks ... done.[5-10 seconds pass]
| ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) | ata1.00: configured for UDMA/100 | SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB) | sda: Write Protect is off | sda: Mode Sense: 00 3a 00 00 | SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Quoted 2 lines
with real resume it takes even longer time - but i dont see where the delays come from in that case - i suspect it's SATA.
SATA has another nice feature. Somehow there is an interrupt pending on the SATA controller, which comes in somewhere in the middle of resume. If it happens before the SATA code resumed, the SATA code ignores the interrupt and the interrupt is disabled due to "nobody cared", which in turn prevents SATA to ever become functional again.
Any idea on that one ?
tglx
Re: SATA resume slowness, e1000 MSI warning
Quoted 6 lines · Thomas Gleixner
SATA has another nice feature. Somehow there is an interrupt pending on the SATA controller, which comes in somewhere in the middle of resume. If it happens before the SATA code resumed, the SATA code ignores the interrupt and the interrupt is disabled due to "nobody cared", which in turn prevents SATA to ever become functional again.
Jeff - that sounds like a SATA bug.
If you have an interrupt handler registered, you'd better handle the interrupt regardless of whether you think the hardware might be gone or not.
It's generally *not* ok to do
if (device_offline()) return IRQ_NONE;
at the top of an interrupt handler.
Of course, if you think the hardware is supposed to be quiescent, then the only thing you should do is generally just do the "shut up" operation (ie read status, write it back or whatever). You must generally *not* try to pass any data upwards (ie if the higher layers have told you to shut up, you may need to handle the hardware, but you must not involve the higher layers themselves any more, because they expect you to be quiet).
And if you cannot do that because you need to resume in order to have the status register mapped, then you need to have an "early_resume()" function which gets called *before* interrupts are enabled. That's what early-resume (and late-suspend) are designed for: doing things that happen very early in the resume sequence before everything is up.
And if you don't want to do any of these things (or are unable to, because of some ordering constraint or bad design), then you simply need to unregister and re-register the interrupt handler over sleep.
Quoted 1 line
Any idea on that one ?
Jeff, Auke, does this ring any bells?
Linus
Re: SATA resume slowness, e1000 MSI warning
Quoted 8 lines · Linus Torvalds
Quoted 5 lines · Thomas Gleixner
SATA has another nice feature. Somehow there is an interrupt pending on the SATA controller, which comes in somewhere in the middle of resume. If it happens before the SATA code resumed, the SATA code ignores the interrupt and the interrupt is disabled due to "nobody cared", which in turn prevents SATA to ever become functional again. >
Quoted 7 lines
And if you don't want to do any of these things (or are unable to, because of some ordering constraint or bad design), then you simply need to unregister and re-register the interrupt handler over sleep.
Quoted 1 line
Any idea on that one ?
Jeff, Auke, does this ring any bells?
For the e1000 issue, the problem is solved with Eric Biederman's 3-patch msi cleanups. You should have another message in your mailbox confirming that I tested his patches and the MSI warning for e1000 suspend-resume is gone with them.
Cheers,
Auke
Re: [linux-pm] 2.6.21-rc1: known regressions (part 2)
In reply to Michael S. TsirkinHi!
Quoted 15 lines
Pavel, I tried with your .config, and indeed the system came back to life after 2-3 minutes after I press Fn/F4, indeed the issue seems to be with the disk. It could be that the same takes place with my original .config - maybe I just wasn't patient enough. I'll need to re-test that.
However, I noticed that, after resume, when the system is presumably functional, if I try to suspend to ram again, this second suspend hangs, displaying the following on screen:
[ 17.170000] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 20 [ 17.170000] PCI: Setting latency timer of device 0000:02:00.0 to 64 [ 17.250000] e1000: 0000:02:00.0: e1000_probe: (PCI Express:2.5Gb/s:Width x1) 00:16:41:5 4:6c:47 [ 17.330000] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection
Quoted 5 lines
the crescent LED starts blinking and does not seem to stop for at lest 10 min, I've run out of patience after that. It could be that it's just very slow again.
Pavel, did you try suspend to RAM after a successfull resume from RAM?
Seems to work ok in -rc3... as long as I do not mix s2ram with s2disk.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: 2.6.21-rc1: known regressions (part 2)
In reply to Ingo MolnarQuoted 11 lines
Quoting Ingo Molnar <[email protected]>:
Subject: Re: 2.6.21-rc1: known regressions (part 2)Quoted 1 line · Jens Axboe
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38works for me, [...]update:
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38works for me too, and01363220f5d23ef68276db8974e46a502e43d01dis broken. I too will attempt to bisect this.
f3ccb06f3b8e0cf42b579db21f3ca7f17fcc3f38 works for me, too.
Signature · 1 line
MST
Re: 2.6.21-rc1: known regressions (part 2)
In reply to Jens AxboeQuoted 20 lines · Jens Axboe
Quoted 11 lines · Adrian Bunk
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20 that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Quoted 7 lines
Subject : ThinkPad T60: system doesn't come out of suspend to RAM
(CONFIG_NO_HZ)References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin <[email protected]>
Thomas Gleixner <[email protected]>Handled-By Ingo Molnar <[email protected]>Status : unknown
Quoted 2 lines
x60 doesn't resume from S2R either, it doesn't matter if
CONFIG_NO_HZis set or not though. 2.6.20 worked fine.
Is this
Subject : ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin <[email protected]>
Ingo Molnar <[email protected]>
Status : unknown
or doesn't it resume at all?
Quoted 1 line
Jens Axboe
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: 2.6.21-rc1: known regressions (part 2)
Quoted 26 lines · Adrian Bunk
Quoted 20 lines · Jens Axboe
Quoted 11 lines · Adrian Bunk
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20 that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Quoted 7 lines
Subject : ThinkPad T60: system doesn't come out of suspend to RAM
(CONFIG_NO_HZ)References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin <[email protected]>
Thomas Gleixner <[email protected]>Handled-By Ingo Molnar <[email protected]>Status : unknown
Quoted 2 lines
x60 doesn't resume from S2R either, it doesn't matter if
CONFIG_NO_HZis set or not though. 2.6.20 worked fine.Is this
Quoted 8 lines
Subject : ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin <[email protected]>
Ingo Molnar <[email protected]>Handled-By Ingo Molnar <[email protected]>Status : unknown
or doesn't it resume at all?
It doesn't resume at all.
Signature · 1 line
Jens Axboe
2.6.21-rc1: known regressions (part 3)
In reply to Linus TorvaldsThis email lists some known regressions in 2.6.21-rc1 compared to 2.6.20 that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : forcedeth: skb_over_panic
References : http://bugzilla.kernel.org/show_bug.cgi?id=8058
Submitter : Albert Hopkins <[email protected]>
Status : unknown
Subject : natsemi ethernet card not detected correctly
References : http://lkml.org/lkml/2007/2/23/4
http://lkml.org/lkml/2007/2/23/7
Submitter : Bob Tracy <[email protected]>
Patch : http://lkml.org/lkml/2007/2/23/142
Status : patch available
Subject : request_module: runaway loop modprobe net-pf-1
References : http://lkml.org/lkml/2007/2/21/206
Submitter : YOSHIFUJI Hideaki / 吉藤英明 <[email protected]>
commit c353c3fb0700a3c17ea2b0237710a184232ccd7f
Status : problem is being discussed
Subject : IPV6=m, SUNRPC=y compile error
References : http://bugzilla.kernel.org/show_bug.cgi?id=8050
http://lkml.org/lkml/2007/2/12/442 http://lkml.org/lkml/2007/2/20/384
Submitter : Michael-Luke Jones <[email protected]>
Pete Clements <[email protected]> Sid Boyce <[email protected]>
Status : patch available
Subject : WARNING: "compat_agp_ioctl" undefined!
References : http://lkml.org/lkml/2007/2/21/272
Submitter : Andreas Schwab <[email protected]>
Status : patch available
Re: 2.6.21-rc1: known regressions (part 3)
Quoted 9 lines · Adrian Bunk
Subject :
request_module: runaway loop modprobe net-pf-1
References : http://lkml.org/lkml/2007/2/21/206
Submitter : YOSHIFUJI Hideaki / ???????????? <[email protected]>Caused-By Kay Sievers <[email protected]>commit c353c3fb0700a3c17ea2b0237710a184232ccd7fHandled-By Greg KH <[email protected]>Status : problem is being discussed
Patch has been reverted and submitted to Linus to pull, but he's out of town right now...
thanks,
greg k-h
2.6.21-rc1: known regressions (v2) (part 1)
In reply to Linus TorvaldsThis email lists some known regressions in 2.6.21-rc1 compared to 2.6.20 that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : resume: slab error in verify_redzone_free(): cache `size-512':
memory outside object was overwritten
References : http://lkml.org/lkml/2007/2/24/41
Submitter : Pavel Machek <[email protected]>
Status : unknown
Subject : ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin <[email protected]>
Status : unknown
Subject : HP nx6325 notebook: usb mouse stops working after suspend to ram
References : http://lkml.org/lkml/2007/2/21/413
Submitter : Arkadiusz Miskiewicz <[email protected]>
commit 0a6139027f3986162233adc17285151e78b39cac
Status : unknown
Subject : ACPI update breaks kpowersave
References : http://lkml.org/lkml/2007/2/10/7
Submitter : Ismail Dönmez <[email protected]>
Fabio Comolli <[email protected]>
Status : unknown
Subject : MacBook: AE_NOT_FOUND ACPI messages
References : http://bugzilla.kernel.org/show_bug.cgi?id=8066
Submitter : Thomas Meyer <[email protected]>
Status : unknown
Subject : Asus A8N-VM motherboard:
framebuffer/console boot failure boot failure (ACPI related)
References : http://lkml.org/lkml/2007/2/23/132
Submitter : Andrew Nelless <[email protected]>
Status : problem is being debugged
Subject : Asus M6Ne notebook: ACPI: First battery is not detected
References : http://bugzilla.kernel.org/show_bug.cgi?id=8080
Submitter : Janosch Machowinski <[email protected]>
Status : unknown
Subject : Asus M6Ne/M6A notebooks: SATA_ACPI errors during kernel boot
References : http://bugzilla.kernel.org/show_bug.cgi?id=8080
http://bugzilla.kernel.org/show_bug.cgi?id=8046
Submitter : Janosch Machowinski <[email protected]>
Lukas Hejtmanek <[email protected]>
Status : unknown
Subject : ata-piix ACPI errors (40/80 pin cable mix)
References : http://lkml.org/lkml/2007/2/22/159
Submitter : Meelis Roos <[email protected]>
Status : unknown
Subject : libata: PATA UDMA/100 configured as UDMA/33
References : http://lkml.org/lkml/2007/2/20/294
http://www.mail-archive.com/[email protected]/msg04115.html
Submitter : Fabio Comolli <[email protected]>
Status : problem is being discussed
Subject : sata_via failure
References : http://bugzilla.kernel.org/show_bug.cgi?id=8025
Submitter : Jean-Luc Coulon <[email protected]>
Markus Trippelsdorf <[email protected]>
Patch : http://www.mail-archive.com/[email protected]/msg03945.html
Status : patch available
Subject : BUG: at drivers/pci/pci.c:817 pcim_enable_device() (libata)
References : http://lkml.org/lkml/2007/2/14/275
http://lkml.org/lkml/2007/2/22/367
Submitter : Rafael J. Wysocki <[email protected]>
Lukas Hejtmanek <[email protected]>
Patch : http://lkml.org/lkml/2007/2/25/102
Status : patch available
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.21-rc1: known regressions (v2) (part 1)
Quoted 4 lines · Adrian Bunk
Subject : MacBook:
AE_NOT_FOUNDACPI messages
References : http://bugzilla.kernel.org/show_bug.cgi?id=8066
Submitter : Thomas Meyer <[email protected]>
Status : unknown
I think , Messages is not a regression
Appears AE_NOT_FOUND messages could be good
Signature · 1 line
Sérgio M.B.
Re: 2.6.21-rc1: known regressions (v2) (part 1)
In reply to Adrian Bunk27 Şub 2007 Sal tarihinde, Adrian Bunk şunları yazmıştı:
Quoted 7 lines
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20 that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues.
...
Quoted 5 lines
Subject : ACPI update breaks kpowersave
References : http://lkml.org/lkml/2007/2/10/7
Submitter : Ismail Dönmez <[email protected]>
Fabio Comolli <[email protected]>
Status : unknown
That regression fixed by c2b6705b75d9c7aff98a4602a32230639e10891c according to İsmail [1]
[1] http://lkml.org/lkml/2007/2/13/105
Signature · 4 lines
S.Çağlar Onur <[email protected]> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
Re: 2.6.21-rc1: known regressions (v2) (part 1)
Quoted 17 lines · On Tuesday 27 February 2007 14:50:17 S.Çağlar Onur wrote:
27 Şub 2007 Sal tarihinde, Adrian Bunk şunları yazmıştı:
Quoted 7 lines
This email lists some known regressions in 2.6.21-rc1 compared to 2.6.20 that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues.
...
Quoted 5 lines
Subject : ACPI update breaks kpowersave
References : http://lkml.org/lkml/2007/2/10/7
Submitter : Ismail Dönmez <[email protected]>
Fabio Comolli <[email protected]>
Status : unknown
Quoted 4 lines
That regression fixed by
c2b6705b75d9c7aff98a4602a32230639e10891caccording to İsmail [1]
Not quite, my laptop died the same day. So I can't do any reliable test. Also Fabio seems to reproduce it with 2.6.21-rc1.
Regards,
ismail
Signature · 6 lines
In God We Trust Others We Monitor _______________________________________________ linux-pm mailing list [email protected] https://lists.osdl.org/mailman/listinfo/linux-pm
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: 2.6.21-rc1: known regressions (v2) (part 1)
27 Şub 2007 Sal tarihinde, Fabio Comolli şunları yazmıştı:
Quoted 6 lines
Confirmed, although the problem I see is probably different from Ismael's one: in my case
/proc/acpi/adapter/ACis present but kpowersave does not work (it works in 2.6.20).The only file I seem to be missing is
/proc/acpi/info, but I don't know it is important or not.
Then these problems are not same, İsmail's problem was an ACPI one and im sure that solved but yours seems a userspace problem (hal checks /proc/acpi/info and kpowersave uses hal) introduced by "/proc/acpi/info deprecated by /sys/firmware/acpi/info" [1]. You can try untested attached patch against hal-git tree, so i'm adding hal list into CC also.
[1] http://www.mail-archive.com/[email protected]/msg04285.html
Signature · 4 lines
S.Çağlar Onur <[email protected]> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
hald/linux/acpi.c +8 -2
@@ -1055,7 +1055,7 @@ acpi_synthesize_hotplug_events (void)HalDevice *computer;gchar path[HAL_PATH_MAX ]; -if (!g_file_test ("/proc/acpi/info" ,G_FILE_TEST_EXISTS )) +if (!g_file_test ("/proc/acpi/" ,G_FILE_TEST_IS_DIR ))return FALSE; if ((computer = hal_device_store_find (hald_get_gdl (), "/org/freedesktop/Hal/devices/computer")) == NULL &&
@@ -1066,8 +1066,14 @@ acpi_synthesize_hotplug_events (void)/* Set appropriate properties on the computer object */ hal_device_property_set_string (computer,"power_management.type" ,"acpi" ); -hal_util_set_string_elem_from_file (computer,"power_management.acpi.linux.version" , +if (g_file_test ("/proc/acpi/info" ,G_FILE_TEST_EXISTS )) { +hal_util_set_string_elem_from_file (computer,"power_management.acpi.linux.version" ,"/proc/acpi" ,"info" ,"version" ,0 , FALSE); + } +else { +hal_util_set_string_elem_from_file (computer,"power_management.acpi.linux.version" , +"%s/firmware/acpi" , sysfs_path,"info" ,"version" ,0 , FALSE); + }/* collect batteries */ snprintf (path,sizeof (path),"%s/acpi/battery" ,get_hal_proc_path ());
Re: 2.6.21-rc1: known regressions (v2) (part 1)
27 Şub 2007 Sal tarihinde, S.Çağlar Onur şunları yazmıştı:
Quoted 8 lines
27 Şub 2007 Sal tarihinde, Fabio Comolli şunları yazmıştı:
Quoted 6 lines
Confirmed, although the problem I see is probably different from Ismael's one: in my case
/proc/acpi/adapter/ACis present but kpowersave does not work (it works in 2.6.20).The only file I seem to be missing is
/proc/acpi/info, but I don't know it is important or not.
Quoted 7 lines
Then these problems are not same, İsmail's problem was an ACPI one and im sure that solved but yours seems a userspace problem (hal checks
/proc/acpi/infoand kpowersave uses hal) introduced by "/proc/acpi/infodeprecated by/sys/firmware/acpi/info" [1]. You can try untested attached patch against hal-git tree, so i'm adding hal list into CC also.[1] http://www.mail-archive.com/[email protected]/msg04285.html
Try that one (thas one at least compiles :P) [1] instead of previous one please...
[1] http://cekirdek.pardus.org.tr/~caglar/hal_acpi.patch
Signature · 4 lines
S.Çağlar Onur <[email protected]> http://cekirdek.pardus.org.tr/~caglar/ Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
Re: 2.6.21-rc1: known regressions (v2) (part 1)
In reply to Adrian BunkQuoted 4 lines
Subject : ata-piix ACPI errors (40/80 pin cable mix)
References : http://lkml.org/lkml/2007/2/22/159
Submitter : Meelis Roos <[email protected]>
Status : unknown
Still appears, but this does not seem to be 40/80 pin cable problem to be but rather ata-piix calling some acpi methods and this rulsts in acpi errors.
Signature · 1 line
Meelis Roos ([email protected])
Re: 2.6.21-rc1: known regressions (v2) (part 1)
Quoted 8 lines · On Tue, 27 Feb 2007 15:00:29 +0200 (EET) Meelis Roos <[email protected]> wrote:
Quoted 4 lines
Subject : ata-piix ACPI errors (40/80 pin cable mix)
References : http://lkml.org/lkml/2007/2/22/159
Submitter : Meelis Roos <[email protected]>
Status : unknownStill appears, but this does not seem to be 40/80 pin cable problem to be but rather ata-piix calling some acpi methods and this rulsts in acpi errors.
There are two separate problems showing up in the one trace - broken ACPI spew and wrong cable detect. I don't think they are related
Re: 2.6.21-rc1: known regressions (v2) (part 1)
In reply to Adrian BunkQuoted 5 lines
Subject : ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin <[email protected]>Handled-By Ingo Molnar <[email protected]>Status : unknown
Just reproduced this in -rc2.
Another thing I noticed:
with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.
On 2.6.21-rc2, after resume (when the box is accessible from network), pressing Fn/F4 again does not seem to have any effect.
Signature · 1 line
MST
Re: 2.6.21-rc1: known regressions (v2) (part 1)
Quoted 6 lines · Michael S. Tsirkin
Quoted 5 lines
Subject : ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin <[email protected]>Handled-By Ingo Molnar <[email protected]>Status : unknown
Quoted 6 lines
Just reproduced this in -rc2.
Another thing I noticed:
with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.On 2.6.21-rc2, after resume (when the box is accessible from network), pressing Fn/F4 again does not seem to have any effect.
Can you please get the dmesg output after resume via the network ?
tglx
Re: 2.6.21-rc1: known regressions (v2) (part 1)
Quoted 10 lines
Quoting Thomas Gleixner <[email protected]>:
Subject: Re: 2.6.21-rc1: known regressions (v2) (part 1)Quoted 6 lines · Michael S. Tsirkin
Quoted 5 lines
Subject : ThinkPad T60: no screen after suspend to RAM
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin <[email protected]>Handled-By Ingo Molnar <[email protected]>Status : unknown
Quoted 8 lines
Quoted 6 lines
Just reproduced this in -rc2.
Another thing I noticed:
with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.On 2.6.21-rc2, after resume (when the box is accessible from network), pressing Fn/F4 again does not seem to have any effect.
Can you please get the dmesg output after resume via the network ?
The link above has it.
Signature · 1 line
MST
Re: 2.6.21-rc1: known regressions (v2) (part 1)
In reply to Michael S. TsirkinQuoted 4 lines · Michael S. Tsirkin
with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.
On 2.6.21-rc2, after resume (when the box is accessible from network), pressing Fn/F4 again does not seem to have any effect.
I have the same problem on my IBM X60s on rc1 and rc2. Can't resume from RAM, can't suspend to disk. It is possible to revert all the changes to ACPI and test it?
Jeff.
Re: [linux-pm] 2.6.21-rc1: known regressions (v2) (part 1)
Quoted 10 lines · Jeff Chua
Quoted 4 lines · Michael S. Tsirkin
with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.
On 2.6.21-rc2, after resume (when the box is accessible from network), pressing Fn/F4 again does not seem to have any effect.
I have the same problem on my IBM X60s on rc1 and rc2. Can't resume from RAM, can't suspend to disk. It is possible to revert all the changes to ACPI and test it?
As I said elsewhere in the thread, suspend/resume to RAM works ok on my thinkpad x60. I posted my .config there, perhaps difference is in it? Ingo identified KVM as possible culprit.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [linux-pm] 2.6.21-rc1: known regressions (v2) (part 1)
Quoted 8 lines · Pavel Machek
Quoted 7 lines · Jeff Chua
Quoted 4 lines · Michael S. Tsirkin
with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.
On 2.6.21-rc2, after resume (when the box is accessible from network), pressing Fn/F4 again does not seem to have any effect.
Quoted 7 lines
Quoted 3 lines
I have the same problem on my IBM X60s on rc1 and rc2. Can't resume from RAM, can't suspend to disk. It is possible to revert all the changes to ACPI and test it?
As I said elsewhere in the thread, suspend/resume to RAM works ok on my thinkpad x60. I posted my .config there, perhaps difference is in it? Ingo identified KVM as possible culprit.
I'll try your .config for kicks, the problem that Ingo pin pointed is not what is affecting me.
Signature · 1 line
Jens Axboe
Re: 2.6.21-rc1: known regressions (v2) (part 1)
In reply to Jeff ChuaQuoted 11 lines · Jeff Chua
Quoted 5 lines · Michael S. Tsirkin
with 2.6.20, pressing Fn/F4 generates an ACPI event and triggers suspend to RAM.
On 2.6.21-rc2, after resume (when the box is accessible from network), pressing Fn/F4 again does not seem to have any effect.
I have the same problem on my IBM X60s on rc1 and rc2. Can't resume from RAM, can't suspend to disk. It is possible to revert all the changes to ACPI and test it?
This is with CONFIG_KVM=n?
Quoted 1 line
Jeff.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: 2.6.21-rc1: known regressions (v2) (part 1)
Quoted 5 lines · Adrian Bunk
Quoted 3 lines
I have the same problem on my IBM X60s on rc1 and rc2. Can't resume from RAM, can't suspend to disk. It is possible to revert all the changes to ACPI and test it?
This is with
CONFIG_KVM=n?
Yes.
Re: 2.6.21-rc1: known regressions (v2) (part 1)
Quoted 9 lines · Jeff Chua
Quoted 5 lines · Adrian Bunk
Quoted 3 lines
I have the same problem on my IBM X60s on rc1 and rc2. Can't resume from RAM, can't suspend to disk. It is possible to revert all the changes to ACPI and test it?
This is with
CONFIG_KVM=n?Yes.
I've tried with CONFIG_KVM=n and CONFIG_KVM=y and both does not suspend.
Re: 2.6.21-rc1: known regressions (v2) (part 1)
Quoted 10 lines
Quoting Jeff Chua <[email protected]>:
Subject: Re: 2.6.21-rc1: known regressions (v2) (part 1)Quoted 6 lines · Jeff Chua
Quoted 4 lines · Adrian Bunk
Quoted 3 lines
I have the same problem on my IBM X60s on rc1 and rc2. Can't resume from RAM, can't suspend to disk. It is possible to revert all the changes to ACPI and test it?
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
This is with
CONFIG_KVM=n?Yes.
I've tried with
CONFIG_KVM=nandCONFIG_KVM=yand both does not suspend.
Do you mean that they "do not resume after suspend"?
Signature · 1 line
MST
Re: 2.6.21-rc1: known regressions (v2) (part 1)
Quoted 10 lines · Michael S. Tsirkin
Quoted 10 lines
Quoting Jeff Chua <[email protected]>:
Subject: Re: 2.6.21-rc1: known regressions (v2) (part 1)Quoted 6 lines · Jeff Chua
Quoted 4 lines · Adrian Bunk
Quoted 3 lines
I have the same problem on my IBM X60s on rc1 and rc2. Can't resume from RAM, can't suspend to disk. It is possible to revert all the changes to ACPI and test it?
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
This is with
CONFIG_KVM=n?Yes.
I've tried with
CONFIG_KVM=nandCONFIG_KVM=yand both does not suspend.Do you mean that they "do not resume after suspend"?
I can't even suspend to disk/ram. It just hangs and the lights just blink and everything else hangs. With 2.6.20, it works fine.
Jeff.
Re: 2.6.21-rc1: known regressions (v2) (part 1)
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 4 lines
I have the same problem on my IBM X60s on rc1 and rc2. Can't resume from RAM, can't suspend to disk. It is possible to revert all the changes to ACPI and test it?
This is with
CONFIG_KVM=n?
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Yes.
I've tried with
CONFIG_KVM=nandCONFIG_KVM=yand both does not suspend.Do you mean that they "do not resume after suspend"?
I can't even suspend to disk/ram. It just hangs and the lights just blink and everything else hangs. With 2.6.20, it works fine.
Turn up console loglevel, and see where it hangs...
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: 2.6.21-rc1: known regressions (v2) (part 1)
Quoted 9 lines · Pavel Machek
Quoted 9 lines
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
I have the same problem on my IBM X60s on rc1 and rc2. Can't resume from RAM, can't suspend to disk. It is possible to revert all the changes to ACPI and test it?
This is with
CONFIG_KVM=n?Yes.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
I've tried with
CONFIG_KVM=nandCONFIG_KVM=yand both does not suspend.Do you mean that they "do not resume after suspend"?
I can't even suspend to disk/ram. It just hangs and the lights just blink and everything else hangs. With 2.6.20, it works fine.
Turn up console loglevel, and see where it hangs...
I think CONFIG_DISABLE_CONSOLE_SUSPEND would have to be set for this purpose too.
Greetings,
Rafael
2.6.21-rc1: known regressions (v2) (part 2)
In reply to Linus TorvaldsThis email lists some known regressions in 2.6.21-rc1 compared to 2.6.20 that are not yet fixed in Linus' tree.
If you find your name in the Cc header, you are either submitter of one of the bugs, maintainer of an affectected subsystem or driver, a patch of you caused a breakage or I'm considering you in any other way possibly involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : forcedeth no longer works
References : http://bugzilla.kernel.org/show_bug.cgi?id=8090
Submitter : David P. Reed <[email protected]>
Status : unknown
Subject : forcedeth: skb_over_panic
References : http://bugzilla.kernel.org/show_bug.cgi?id=8058
Submitter : Albert Hopkins <[email protected]>
Status : unknown
Subject : natsemi ethernet card not detected correctly
References : http://lkml.org/lkml/2007/2/23/4
http://lkml.org/lkml/2007/2/23/7
Submitter : Bob Tracy <[email protected]>
Patch : http://lkml.org/lkml/2007/2/23/142
Status : patch available
Subject : ThinkPad T60: system doesn't come out of suspend to RAM
(CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/22/391
Submitter : Michael S. Tsirkin <[email protected]>
Ingo Molnar <[email protected]>
Status : unknown
Subject : kernel BUG at kernel/time/tick-sched.c:168 (CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/16/346
Submitter : Michal Piotrowski <[email protected]>
Status : problem is being debugged
Subject : BUG: soft lockup detected on CPU#0
NOHZ: local_softirq_pending 20 (SMT scheduler)
References : http://lkml.org/lkml/2007/2/20/257
Submitter : Michal Piotrowski <[email protected]>
Ingo Molnar <[email protected]>
Status : problem is being debugged
Subject : i386: no boot with nmi_watchdog=1 (clockevents)
References : http://lkml.org/lkml/2007/2/21/208
Submitter : Daniel Walker <[email protected]>
commit e9e2cdb412412326c4827fc78ba27f410d837e6e
Status : problem is being debugged
Re: 2.6.21-rc1: known regressions (v2) (part 2)
Adrian,
Quoted 5 lines · Adrian Bunk
Subject : kernel BUG at
kernel/time/tick-sched.c:168(CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/16/346
Submitter : Michal Piotrowski <[email protected]>Handled-By Thomas Gleixner <[email protected]>Status : problem is being debugged
The BUG_ON() was replaced by a warning printk(). The BUG_ON() exposed a problem with the SMT scheduler. See below.
Quoted 7 lines
Subject : BUG: soft lockup detected on CPU#0
NOHZ:local_softirq_pending20 (SMT scheduler)
References : http://lkml.org/lkml/2007/2/20/257
Submitter : Michal Piotrowski <[email protected]>Handled-By Thomas Gleixner <[email protected]>Ingo Molnar <[email protected]>
Status : problem is being debugged
Patch available, not confirmed yet.
tglx
Re: 2.6.21-rc1: known regressions (v2) (part 2)
Thomas Gleixner napisał(a):
Quoted 20 lines
Adrian,
Quoted 5 lines · Adrian Bunk
Subject : kernel BUG at
kernel/time/tick-sched.c:168(CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/16/346
Submitter : Michal Piotrowski <[email protected]>Handled-By Thomas Gleixner <[email protected]>Status : problem is being debugged
The
BUG_ON()was replaced by a warningprintk(). TheBUG_ON()exposed a problem with the SMT scheduler. See below.Quoted 7 lines
Subject : BUG: soft lockup detected on CPU#0
NOHZ:local_softirq_pending20 (SMT scheduler)
References : http://lkml.org/lkml/2007/2/20/257
Submitter : Michal Piotrowski <[email protected]>Handled-By Thomas Gleixner <[email protected]>Ingo Molnar <[email protected]>
Status : problem is being debugged
Quoted 2 lines
Patch available, not confirmed yet.
I can confirm that the bug is fixed (over 20 hours of testing should be enough).
Huge thanks!
Regards,
Michal
Signature · 5 lines
Michal K. K. Piotrowski LTG - Linux Testers Group (PL) (http://www.stardust.webpages.pl/ltg/) LTG - Linux Testers Group (EN) (http://www.stardust.webpages.pl/linux_testers_group_en/)
Re: 2.6.21-rc1: known regressions (v2) (part 2)
Michal Piotrowski napisał(a):
Quoted 19 lines
Thomas Gleixner napisał(a):
Quoted 18 lines
Adrian,
Quoted 5 lines · Adrian Bunk
Subject : kernel BUG at
kernel/time/tick-sched.c:168(CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/16/346
Submitter : Michal Piotrowski <[email protected]>Handled-By Thomas Gleixner <[email protected]>Status : problem is being debugged
The
BUG_ON()was replaced by a warningprintk(). TheBUG_ON()exposed a problem with the SMT scheduler. See below.Quoted 7 lines
Subject : BUG: soft lockup detected on CPU#0
NOHZ:local_softirq_pending20 (SMT scheduler)
References : http://lkml.org/lkml/2007/2/20/257
Submitter : Michal Piotrowski <[email protected]>Handled-By Thomas Gleixner <[email protected]>Ingo Molnar <[email protected]>
Status : problem is being debugged
Quoted 4 lines
Quoted 2 lines
Patch available, not confirmed yet.
I can confirm that the bug is fixed (over 20 hours of testing should be enough).
^^^^ almost ;)
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
Re: 2.6.21-rc1: known regressions (v2) (part 2)
In reply to Michal PiotrowskiQuoted 21 lines · Michal Piotrowski
Thomas Gleixner napisał(a):
Quoted 20 lines
Adrian,
Quoted 5 lines · Adrian Bunk
Subject : kernel BUG at
kernel/time/tick-sched.c:168(CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/16/346
Submitter : Michal Piotrowski <[email protected]>Handled-By Thomas Gleixner <[email protected]>Status : problem is being debugged
The
BUG_ON()was replaced by a warningprintk(). TheBUG_ON()exposed a problem with the SMT scheduler. See below.Quoted 7 lines
Subject : BUG: soft lockup detected on CPU#0
NOHZ:local_softirq_pending20 (SMT scheduler)
References : http://lkml.org/lkml/2007/2/20/257
Submitter : Michal Piotrowski <[email protected]>Handled-By Thomas Gleixner <[email protected]>Ingo Molnar <[email protected]>
Status : problem is being debugged
Quoted 5 lines
Quoted 2 lines
Patch available, not confirmed yet.
I can confirm that the bug is fixed (over 20 hours of testing should be enough).
thanks alot! I think this thing was a long-term performance/latency regression in HT scheduling as well.
Ingo
Re: 2.6.21-rc1: known regressions (v2) (part 2)
Quoted 23 lines · Ingo Molnar
Quoted 21 lines · Michal Piotrowski
Thomas Gleixner napisał(a):
Quoted 20 lines
Adrian,
Quoted 5 lines · Adrian Bunk
Subject : kernel BUG at
kernel/time/tick-sched.c:168(CONFIG_NO_HZ)
References : http://lkml.org/lkml/2007/2/16/346
Submitter : Michal Piotrowski <[email protected]>Handled-By Thomas Gleixner <[email protected]>Status : problem is being debugged
The
BUG_ON()was replaced by a warningprintk(). TheBUG_ON()exposed a problem with the SMT scheduler. See below.Quoted 7 lines
Subject : BUG: soft lockup detected on CPU#0
NOHZ:local_softirq_pending20 (SMT scheduler)
References : http://lkml.org/lkml/2007/2/20/257
Submitter : Michal Piotrowski <[email protected]>Handled-By Thomas Gleixner <[email protected]>Ingo Molnar <[email protected]>
Status : problem is being debugged
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Patch available, not confirmed yet.
I can confirm that the bug is fixed (over 20 hours of testing should be enough).
thanks alot! I think this thing was a long-term performance/latency regression in HT scheduling as well.
Agreed.
I was recently looking at that spot because I found that niced tasks were taking latency hits, and disabled it, which helped a bunch. I also can't understand why it would be OK to interleave a normal task with an RT task sometimes, but not others.. that's meaningless to the RT task.
IMHO, SMT scheduling should be a buyer beware thing. Maximizing your core utilization comes at a price, but so does disabling it, so I think letting the user decide what he wants is the right thing to do.
-Mike
Re: 2.6.21-rc1: known regressions (v2) (part 2)
Apologies for the resend, lkml address got mangled...
Quoted 6 lines · Mike Galbraith
Quoted 5 lines · Ingo Molnar
Quoted 4 lines · Michal Piotrowski
Thomas Gleixner napisał(a):
Quoted 3 lines
Adrian,
On Mon, 2007-02-26 at 23:05 +0100, Adrian Bunk wrote:
Quoted 8 lines
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
Subject : kernel BUG at
kernel/time/tick-sched.c:168
(CONFIG_NO_HZ) References : http://lkml.org/lkml/2007/2/16/346
Submitter : Michal Piotrowski <[email protected]>I can confirm that the bug is fixed (over 20 hours of testing should be enough).
thanks alot! I think this thing was a long-term performance/latency regression in HT scheduling as well.
Ingo I'm going to have to partially disagree with you on this.
This has only become a problem because of what happens with dynticks now when rq->curr == rq->idle. Prior to this, that particular SMT code only leads to relative delays in scheduling for lower priority tasks. Whether or not that task is ksoftirqd should not matter because it is not like they are starved indefinitely, it is only that nice 19 tasks are relatively delayed, which by definition is implied with the usage of nice as a scheduler hint wouldn't you say? I know it has been discussed many times before as to whether 'nice' means less cpu and/or more latency, but in our current implementation, nice means both less cpu and more latency. So to me, the kernels without dynticks do not have a regression. This seems to only be a problem in the setting of the new dynticks code IMHO. That's not to say it isn't a bug! Nor am I saying that dynticks is a problem! Please don't misinterpret that.
The second issue is that this is a problem because of the fuzzy definition of what idle is for a runqueue in the setting of this SMT code. Normally, rq->curr==rq->idle means the runqueue is idle, but not with this code since there are still rq->nr_running on that runqueue. What dynticks in this implementation is doing is trying to idle a hyperthread sibling on a cpu whose logical partner is busy. I did not find that added any power saving on my earlier dynticks implementation, and found it easier to keep that sibling ticking at the same rate as its partner. Of course you may have found something different, and I definitely agree with what you are likely to say in response to this- we shouldn't have to special case logical siblings as having a different definition of idle than any other smp case. Ultimately, that leaves us with your simple patch as a reasonable solution for the dynticks case even though it does change the behaviour dramatically for a more loaded cpu. I don't see this code as presenting a problem without or prior to the dynticks implementation. You being the scheduler maintainer means you get to choose what is the best way to tackle this problem.
Quoted 4 lines
Agreed.
I was recently looking at that spot because I found that niced tasks were taking latency hits, and disabled it, which helped a bunch.
Ok... as I said above to Ingo, nice means more latency too, and there is no doubt that if we disable nice as a working feature then the niced tasks will have less latency. Of course, this ends up meaning that un-niced tasks no longer receive their better cpu performance.. You're basically saying that you prefer nice not to work in the setting of HT.
Quoted 3 lines
I also
can't understand why it would be OK to interleave a normal task with an RT task sometimes, but not others.. that's meaningless to the RT task.
Clearly there would be a reason that code is there... The whole problem with HT is that as soon as you load up a sibling, you slow down the logical sibling, hence why this code is there in the first place. Since I know you're one to test things for yourself, I will put it to you this way:
Boot into UP. Time how long it takes to do a million of these in a real time task:
asm volatile("" : : : "memory");
Then start up a SCHED_NORMAL task fully cpu bound such as "yes > /dev/null" and time that again. Obviously the former being a realtime task will take the same amount of time and the SCHED_NORMAL task will be starved until the realtime task finishes.
Now try the same experiment with hyperthreading enabled and an ordinary SMP kernel. You'll find the realtime task runs at only ~60% performance. That's a serious performance hit for realtime tasks considering you're running a SCHED_NORMAL task. The SMT code that you seem to dislike fixes this problem. The reason for interleaving is that there are a few cycles to be gained by using the second core for a separate SCHED_NORMAL task, and you don't want to disable access to the second core entirely for the duration the realtime task is running. Since there is no simple relationship between SCHED_NORMAL timeslices and realtime timeslices, we have to use some form of interleaving based on the expected extra cycles and HZ is the obvious choice.
Quoted 3 lines
IMHO, SMT scheduling should be a buyer beware thing. Maximizing your core utilization comes at a price, but so does disabling it, so I think letting the user decide what he wants is the right thing to do.
To me this is like arguing that we should not implement 'nice' within the cpu scheduler at all and only allow nice to work on the few architectures that support hardware priorities in the cpu (like power5). Now there is no doubt that if we do away with nice entirely everywhere in the scheduler we'll gain some throughput. However, nice is a basic unix/linux function and if hardware comes along that breaks it working we should be working to make sure that it keeps working in software. That is why smt nice and smp nice was implemented. Of course it is our duty to ensure we do that at minimal overhead at all times. That's a different argument to what you are debating here. The throughput should not be adversely affected by this SMT priority code because although the nice 19 task gets less throughput, the higher priority task gets more as a result, which is essentially what nice is meant to do.
Signature · 1 line
-ck
Re: 2.6.21-rc1: known regressions (v2) (part 2)
(hrmph. having to copy/paste/try again. evolution seems to be broken.. RCPT TO <[email protected]> failed: Cannot resolve your domain {mp049} ..caused me to be unable to send despite receipts being disabled)
Quoted 4 lines · Con Kolivas
Quoted 2 lines · Mike Galbraith
Agreed.
Quoted 8 lines
Quoted 2 lines
I was recently looking at that spot because I found that niced tasks were taking latency hits, and disabled it, which helped a bunch.
Ok... as I said above to Ingo, nice means more latency too, and there is no doubt that if we disable nice as a working feature then the niced tasks will have less latency. Of course, this ends up meaning that un-niced tasks no longer receive their better cpu performance.. You're basically saying that you prefer nice not to work in the setting of HT.
No I'm not, but let's go further in that direction just for the sake of argument. You're then saying that you prefer realtime priorities to not work in the HT setting, given that realtime tasks don't participate in the 'single stream me' program.
I'm saying only that we're defeating the purpose of HT, and overriding a user decision every time we force a sibling idle.
Quoted 9 lines
Quoted 3 lines
I also
can't understand why it would be OK to interleave a normal task with an RT task sometimes, but not others.. that's meaningless to the RT task.Clearly there would be a reason that code is there... The whole problem with HT is that as soon as you load up a sibling, you slow down the logical sibling, hence why this code is there in the first place. Since I know you're one to test things for yourself, I will put it to you this way:
Quoted 8 lines
Boot into UP. Time how long it takes to do a million of these in a real time task:
asmvolatile("" : : : "memory");Then start up a
SCHED_NORMALtask fully cpu bound such as "yes >/dev/null" and time that again. Obviously the former being a realtime task will take the same amount of time and theSCHED_NORMALtask will be starved until the realtime task finishes.
Sure.
Quoted 2 lines
Now try the same experiment with hyperthreading enabled and an ordinary SMP kernel. You'll find the realtime task runs at only ~60% performance.
So? User asked for HT. That's hardware multiplexing. It ain't free. Buyer beware.
Quoted 3 lines
That's a
serious performance hit for realtime tasks considering you're running aSCHED_NORMALtask. The SMT code that you seem to dislike fixes this problem.
I don't think it does actually. Let your RT task sleep regularly, and ever so briefly. We don't evict lower priority tasks from siblings upon wakeup, we only prevent entry... sometimes.
Quoted 6 lines
The reason for interleaving is that there are a few cycles to be gained by using the second core for a separate
SCHED_NORMALtask, and you don't want to disable access to the second core entirely for the duration the realtime task is running. Since there is no simple relationship betweenSCHED_NORMALtimeslices and realtime timeslices, we have to use some form of interleaving based on the expected extra cycles and HZ is the obvious choice.
To me, the reason for interleaving is solely about keeping the core busy . It has nothing to do with SCHED_POLICY_X what so ever.
Quoted 4 lines
Quoted 3 lines
IMHO, SMT scheduling should be a buyer beware thing. Maximizing your core utilization comes at a price, but so does disabling it, so I think letting the user decide what he wants is the right thing to do.
Quoted 12 lines
To me this is like arguing that we should not implement 'nice' within the cpu scheduler at all and only allow nice to work on the few architectures that support hardware priorities in the cpu (like power5). Now there is no doubt that if we do away with nice entirely everywhere in the scheduler we'll gain some throughput. However, nice is a basic unix/linux function and if hardware comes along that breaks it working we should be working to make sure that it keeps working in software. That is why smt nice and smp nice was implemented. Of course it is our duty to ensure we do that at minimal overhead at all times. That's a different argument to what you are debating here. The throughput should not be adversely affected by this SMT priority code because although the nice 19 task gets less throughput, the higher priority task gets more as a result, which is essentially what nice is meant to do.
Re-read this paragraph with realtime task priorities in mind, or for that matter, dynamic priorities. If you carry your priority/throughput argument to it's logical conclusion, only instruction streams of absolutely equal priority should be able to share the core at any given time. You may as well just disable HT and be done with it.
To me, siblings are logically separate units, and should be treated as such (as they mostly are). They share an important resource, but so do physically discrete units.
-Mike
Re: 2.6.21-rc1: known regressions (v2) (part 2)
Quoted 3 lines · Mike Galbraith
(hrmph. having to copy/paste/try again. evolution seems to be broken.. RCPT TO <[email protected]> failed: Cannot resolve your domain {mp049} ..caused me to be unable to send despite receipts being disabled)
Apologies for mangling the email address as I said :-(
Quoted 13 lines · Con Kolivas
Quoted 11 lines · Mike Galbraith
Quoted 4 lines
Agreed.
I was recently looking at that spot because I found that niced tasks were taking latency hits, and disabled it, which helped a bunch.
Ok... as I said above to Ingo, nice means more latency too, and there is no doubt that if we disable nice as a working feature then the niced tasks will have less latency. Of course, this ends up meaning that un-niced tasks no longer receive their better cpu performance.. You're basically saying that you prefer nice not to work in the setting of HT.
Quoted 4 lines
No I'm not, but let's go further in that direction just for the sake of argument. You're then saying that you prefer realtime priorities to not work in the HT setting, given that realtime tasks don't participate in the 'single stream me' program.
Where do I say that? I do not presume to manage realtime priorities in any way. You're turning my argument about nice levels around and somehow saying that because hyperthreading breaks the single stream me semantics by parallelising them that I would want to stop that happening. Nowhere have I argued that realtime semantics should be changed to somehow work around hyperthreading. SMT nice is about managing nice only, and not realtime priorities which are independent entities.
Quoted 22 lines
I'm saying only that we're defeating the purpose of HT, and overriding a user decision every time we force a sibling idle.
Quoted 10 lines
Quoted 3 lines
I also
can't understand why it would be OK to interleave a normal task with an RT task sometimes, but not others.. that's meaningless to the RT task.Clearly there would be a reason that code is there... The whole problem with HT is that as soon as you load up a sibling, you slow down the logical sibling, hence why this code is there in the first place. Since I know you're one to test things for yourself, I will put it to you this way:
Quoted 8 lines
Boot into UP. Time how long it takes to do a million of these in a real time task:
asmvolatile("" : : : "memory");Then start up a
SCHED_NORMALtask fully cpu bound such as "yes >/dev/null" and time that again. Obviously the former being a realtime task will take the same amount of time and theSCHED_NORMALtask will be starved until the realtime task finishes.
Quoted 7 lines
Sure.
Quoted 2 lines
Now try the same experiment with hyperthreading enabled and an ordinary SMP kernel. You'll find the realtime task runs at only ~60% performance.
So? User asked for HT. That's hardware multiplexing. It ain't free. Buyer beware.
But the buyer is not aware. You are aware because you tinker, but the vast majority of users who enable hyperthreading in their shiny pcs are not aware. The only thing they know is that if they enable hyperthreading their programs run slower in multitasking environments no matter how much they nice the other processes. Buyers do not buy hardware knowing that the internal design breaks something as fundamental as 'nice'. You seem to presume that most people who get hyperthreading are happy to compromise 'nice' in order to get their second core working and I put it to you that they do not make that decision.
Quoted 8 lines
Quoted 4 lines
That's a
serious performance hit for realtime tasks considering you're running aSCHED_NORMALtask. The SMT code that you seem to dislike fixes this problem.I don't think it does actually. Let your RT task sleep regularly, and ever so briefly. We don't evict lower priority tasks from siblings upon wakeup, we only prevent entry... sometimes.
Well you know as well as I do that you're selecting out the exception rather than the rule, and statistically overall, it does work.
Quoted 29 lines
Quoted 7 lines
The reason for interleaving is that there are a few cycles to be gained by using the second core for a separate
SCHED_NORMALtask, and you don't want to disable access to the second core entirely for the duration the realtime task is running. Since there is no simple relationship betweenSCHED_NORMALtimeslices and realtime timeslices, we have to use some form of interleaving based on the expected extra cycles and HZ is the obvious choice.To me, the reason for interleaving is solely about keeping the core busy . It has nothing to do with
SCHED_POLICY_Xwhat so ever.Quoted 4 lines
Quoted 3 lines
IMHO, SMT scheduling should be a buyer beware thing. Maximizing your core utilization comes at a price, but so does disabling it, so I think letting the user decide what he wants is the right thing to do.
Quoted 13 lines
To me this is like arguing that we should not implement 'nice' within the cpu scheduler at all and only allow nice to work on the few architectures that support hardware priorities in the cpu (like power5). Now there is no doubt that if we do away with nice entirely everywhere in the scheduler we'll gain some throughput. However, nice is a basic unix/linux function and if hardware comes along that breaks it working we should be working to make sure that it keeps working in software. That is why smt nice and smp nice was implemented. Of course it is our duty to ensure we do that at minimal overhead at all times. That's a different argument to what you are debating here. The throughput should not be adversely affected by this SMT priority code because although the nice 19 task gets less throughput, the higher priority task gets more as a result, which is essentially what nice is meant to do.
Quoted 5 lines
Re-read this paragraph with realtime task priorities in mind, or for that matter, dynamic priorities. If you carry your priority/throughput argument to it's logical conclusion, only instruction streams of absolutely equal priority should be able to share the core at any given time. You may as well just disable HT and be done with it.
Well that's certainly taking my logic for a ride. This is about managing _nice_ and _only_ nice. Nice specifies fixed interval static priorities where (in the risk of repeating myself) you are specifying that higher nice values tasks you wish to receive less cpu and more latency. Dynamic priorities have absolutely no effect on what the discrepancies are between the static priorities of differing nice values. As for realtime priorities, again, I do not presume to be managing them with SMT nice. They are unique entities unrelated to nice values. The only thing they have in common with nice levels is that if something is running without a realtime priority, it should be preempted by the realtime task as you have specified that the realtime task should receive all the cpu over the non-realtime task. I don't pretend that there is some cpu percentage relationship between different _realtime priorities_ and do not try to manage them in any way.
Quoted 3 lines
To me, siblings are logically separate units, and should be treated as such (as they mostly are). They share an important resource, but so do physically discrete units.
Again you're saying here that if the hardware breaks nice levels we should not bother trying to enforce them. As I said before, this is an extension of arguing that we should not try to enforce nice except on hardware that has priority support within the cpu.
We're going to have to agree to disagree, but feel free to have the final word of course.
--
-ck
--
'In general this practice is meant to exhaust the opposition in some debate, and when they fail to respond, claim the silence as assent, to prevent an "unfavorable" conclusion of a debate from being reached by refusing to allow the discussion to conclude so long as its conclusion is unfavorable, and to discourage future "challenges".' -wli
Re: 2.6.21-rc1: known regressions (v2) (part 2)
Quoted 20 lines · Con Kolivas
Quoted 13 lines · Mike Galbraith
Quoted 11 lines · Con Kolivas
Quoted 4 lines · Mike Galbraith
Agreed.
I was recently looking at that spot because I found that niced tasks were taking latency hits, and disabled it, which helped a bunch.
Ok... as I said above to Ingo, nice means more latency too, and there is no doubt that if we disable nice as a working feature then the niced tasks will have less latency. Of course, this ends up meaning that un-niced tasks no longer receive their better cpu performance.. You're basically saying that you prefer nice not to work in the setting of HT.
Quoted 4 lines
No I'm not, but let's go further in that direction just for the sake of argument. You're then saying that you prefer realtime priorities to not work in the HT setting, given that realtime tasks don't participate in the 'single stream me' program.
Quoted 7 lines
Where do I say that? I do not presume to manage realtime priorities in any way. You're turning my argument about nice levels around and somehow saying that because hyperthreading breaks the single stream me semantics by parallelising them that I would want to stop that happening. Nowhere have I argued that realtime semantics should be changed to somehow work around hyperthreading. SMT nice is about managing nice only, and not realtime priorities which are independent entities.
I see no real difference between the two assertions. Nice is just a mechanism to set priority, so I applied your assertion to a different range of priorities than nice covers, and returned it to show that the code contradicts itself. It can't be bad for a nice 1 task to run with a nice 0 task, but OK for a minimum RT task to run with a maximum RT task. Iff HT without corrective measures breaks nice, then it breaks realtime priorities as well.
Quoted 24 lines
Quoted 24 lines
I'm saying only that we're defeating the purpose of HT, and overriding a user decision every time we force a sibling idle.
Quoted 10 lines
Quoted 3 lines
I also
can't understand why it would be OK to interleave a normal task with an RT task sometimes, but not others.. that's meaningless to the RT task.Clearly there would be a reason that code is there... The whole problem with HT is that as soon as you load up a sibling, you slow down the logical sibling, hence why this code is there in the first place. Since I know you're one to test things for yourself, I will put it to you this way:
Quoted 8 lines
Boot into UP. Time how long it takes to do a million of these in a real time task:
asmvolatile("" : : : "memory");Then start up a
SCHED_NORMALtask fully cpu bound such as "yes >/dev/null" and time that again. Obviously the former being a realtime task will take the same amount of time and theSCHED_NORMALtask will be starved until the realtime task finishes.Sure.
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines
Now try the same experiment with hyperthreading enabled and an ordinary SMP kernel. You'll find the realtime task runs at only ~60% performance.
So? User asked for HT. That's hardware multiplexing. It ain't free. Buyer beware.
But the buyer is not aware. You are aware because you tinker, but the vast majority of users who enable hyperthreading in their shiny pcs are not aware.
Then we need to make them aware of what they're enabling?
Quoted 7 lines
The only thing they know is that if they enable hyperthreading their programs run slower in multitasking environments no matter how much they nice the other processes. Buyers do not buy hardware knowing that the internal design breaks something as fundamental as 'nice'. You seem to presume that most people who get hyperthreading are happy to compromise 'nice' in order to get their second core working and I put it to you that they do not make that decision.
To me it's pretty much black and white. Either you want to split your cpu into logical units, which means each has less to offer than the total, or you want all your processing power in one bucket.
Quoted 11 lines
Quoted 8 lines
Quoted 4 lines
That's a
serious performance hit for realtime tasks considering you're running aSCHED_NORMALtask. The SMT code that you seem to dislike fixes this problem.I don't think it does actually. Let your RT task sleep regularly, and ever so briefly. We don't evict lower priority tasks from siblings upon wakeup, we only prevent entry... sometimes.
Well you know as well as I do that you're selecting out the exception rather than the rule, and statistically overall, it does work.
I don't agree that it's the exception, and if you look at this HT thing from the split cpu perspective, I'm not sure there's even a problem.
Scrolling down, I see that this is getting too long, and we aren't communicating anyway, so I'll cut it off here.
Quoted 2 lines
We're going to have to agree to disagree, but feel free to have the final word of course.
The above will have to do.
-Mike
Re: 2.6.21-rc1: known regressions (v2) (part 2)
Quoted 7 lines · Mike Galbraith
I see no real difference between the two assertions. Nice is just a mechanism to set priority, so I applied your assertion to a different range of priorities than nice covers, and returned it to show that the code contradicts itself. It can't be bad for a nice 1 task to run with a nice 0 task, but OK for a minimum RT task to run with a maximum RT task. Iff HT without corrective measures breaks nice, then it breaks realtime priorities as well.
i'm starting to lean towards your view that we should not artificially keep tasks from running, when there's a free CPU available. We should still keep the 'other half' of SMT scheduling: the immediate pushing of tasks to a related core, but this bit of 'do not run tasks on this CPU' dependent-sleeper logic is i think a bit fragile. Plus these days SMT siblings do not tend to influence each other in such a negative way as older P4 ones where a HT sibling would slow down the other sibling significantly.
plus with an increasing number of siblings (which seems like an inevitable thing on the hardware side), the dependent-sleeper logic becomes less and less scalable. We'd have to cross-check every other 'related' CPU's current priority to decide what to run.
if then there should be a mechanism /in the hardware/ to set the priority of a CPU - and then the hardware could decide how to prioritize between siblings. Doing this in software is really hard.
Ingo
Re: 2.6.21-rc1: known regressions (v2) (part 2)
Quoted 9 lines · Ingo Molnar
Quoted 7 lines · Mike Galbraith
I see no real difference between the two assertions. Nice is just a mechanism to set priority, so I applied your assertion to a different range of priorities than nice covers, and returned it to show that the code contradicts itself. It can't be bad for a nice 1 task to run with a nice 0 task, but OK for a minimum RT task to run with a maximum RT task. Iff HT without corrective measures breaks nice, then it breaks realtime priorities as well.
Quoted 8 lines
i'm starting to lean towards your view that we should not artificially keep tasks from running, when there's a free CPU available. We should still keep the 'other half' of SMT scheduling: the immediate pushing of tasks to a related core, but this bit of 'do not run tasks on this CPU' dependent-sleeper logic is i think a bit fragile. Plus these days SMT siblings do not tend to influence each other in such a negative way as older P4 ones where a HT sibling would slow down the other sibling significantly.
Well it is meant to be tuned to the cpu type in per_cpu_gain. So it should be easy to be set to the appropriate scaling. It was never meant to be a one value fits all as the processors changed.
Quoted 4 lines
plus with an increasing number of siblings (which seems like an inevitable thing on the hardware side), the dependent-sleeper logic becomes less and less scalable. We'd have to cross-check every other 'related' CPU's current priority to decide what to run.
Yes even I've commented before that this current system is unworkable come multiple shared power threads. This I do see as a real problem with it - in the future.
Quoted 3 lines
if then there should be a mechanism /in the hardware/ to set the priority of a CPU - and then the hardware could decide how to prioritize between siblings. Doing this in software is really hard.
And that's the depressing part because of course I was interested in that as the original approach to the problem (and it was a big problem). When I spoke to Intel and AMD (of course to date no SMT AMD chip exists) at kernel summit they said it was too hard to implement hardware priorities well. Which is real odd since IBM have already done it with Power...
Still I think it has been working fine in software till now, but now it has to deal with the added confusion of dynticks, so I already know what will happen to it.
Hrm it's been a good time for my code all round... I think I'll just swap prefetch myself up the staircase to some pluggable scheduler that would hyperthread me to sleep as an idle priority task.
Signature · 1 line
-ck
Re: 2.6.21-rc1: known regressions (v2) (part 2)
Quoted 10 lines · Con Kolivas
Quoted 3 lines
if then there should be a mechanism /in the hardware/ to set the priority of a CPU - and then the hardware could decide how to prioritize between siblings. Doing this in software is really hard.
And that's the depressing part because of course I was interested in that as the original approach to the problem (and it was a big problem). When I spoke to Intel and AMD (of course to date no SMT AMD chip exists) at kernel summit they said it was too hard to implement hardware priorities well. Which is real odd since IBM have already done it with Power...
Quoted 3 lines
Still I think it has been working fine in software till now, but now it has to deal with the added confusion of dynticks, so I already know what will happen to it.
Well, it's not a dyntick problem in the first place. Even w/o dynticks we go idle with local_softirq_pending(). Dynticks contains an explicit check for that, which makes it visible.
tglx
Re: 2.6.21-rc1: known regressions (v2) (part 2)
Quoted 11 lines · Thomas Gleixner
Quoted 10 lines · Con Kolivas
Quoted 3 lines
if then there should be a mechanism /in the hardware/ to set the priority of a CPU - and then the hardware could decide how to prioritize between siblings. Doing this in software is really hard.
And that's the depressing part because of course I was interested in that as the original approach to the problem (and it was a big problem). When I spoke to Intel and AMD (of course to date no SMT AMD chip exists) at kernel summit they said it was too hard to implement hardware priorities well. Which is real odd since IBM have already done it with Power...
Quoted 7 lines
Quoted 3 lines
Still I think it has been working fine in software till now, but now it has to deal with the added confusion of dynticks, so I already know what will happen to it.
Well, it's not a dyntick problem in the first place. Even w/o dynticks we go idle with
local_softirq_pending(). Dynticks contains an explicit check for that, which makes it visible.
Oops I'm sorry if I made it sound like there's a dynticks problem. That was not my intent and I said as much in an earlier email. Even though I'm finding myself defending code that has already been softly tagged for redundancy, let's be clear here; we're talking about at most a further 70ms delay in scheduling a niced task in the presence of a nice 0 task, which is a reasonable delay for ksoftirqd which we nice the eyeballs out of in mainline. Considering under load our scheduler has been known to cause scheduling delays of 10 seconds I still don't see this as a bug. Dynticks just "points it out to us".
Signature · 1 line
-ck
Re: 2.6.21-rc1: known regressions (v2) (part 2)
Quoted 14 lines · Con Kolivas
Quoted 6 lines
Quoted 6 lines
And that's the depressing part because of course I was interested in that as the original approach to the problem (and it was a big problem). When I spoke to Intel and AMD (of course to date no SMT AMD chip exists) at kernel summit they said it was too hard to implement hardware priorities well. Which is real odd since IBM have already done it with Power...
Quoted 7 lines
Quoted 3 lines
Still I think it has been working fine in software till now, but now it has to deal with the added confusion of dynticks, so I already know what will happen to it.
Well, it's not a dyntick problem in the first place. Even w/o dynticks we go idle with
local_softirq_pending(). Dynticks contains an explicit check for that, which makes it visible.
Quoted 9 lines
Oops I'm sorry if I made it sound like there's a dynticks problem. That was not my intent and I said as much in an earlier email. Even though I'm finding myself defending code that has already been softly tagged for redundancy, let's be clear here; we're talking about at most a further 70ms delay in scheduling a niced task in the presence of a nice 0 task, which is a reasonable delay for ksoftirqd which we nice the eyeballs out of in mainline. Considering under load our scheduler has been known to cause scheduling delays of 10 seconds I still don't see this as a bug. Dynticks just "points it out to us".
Well, dyntick might end up to delay it for X seconds as well, which _is_ observable and that's why the check was put there in the first place.
tglx
Re: 2.6.21-rc1: known regressions (v2) (part 2)
In reply to Con KolivasQuoted 7 lines · Con Kolivas
[...] Even though I'm finding myself defending code that has already been softly tagged for redundancy, let's be clear here; we're talking about at most a further 70ms delay in scheduling a niced task in the presence of a nice 0 task, which is a reasonable delay for ksoftirqd which we nice the eyeballs out of in mainline. Considering under load our scheduler has been known to cause scheduling delays of 10 seconds I still don't see this as a bug. Dynticks just "points it out to us".
well, not running softirqs when we could is a bug. It's not a big bug, but it's a bug nevertheless. It doesnt matter that softirqs could be delayed even worse under high load - there was no 'high load' here.
Ingo
Re: 2.6.21-rc1: known regressions (v2) (part 2)
Quoted 9 lines · Ingo Molnar
Quoted 7 lines · Con Kolivas
[...] Even though I'm finding myself defending code that has already been softly tagged for redundancy, let's be clear here; we're talking about at most a further 70ms delay in scheduling a niced task in the presence of a nice 0 task, which is a reasonable delay for ksoftirqd which we nice the eyeballs out of in mainline. Considering under load our scheduler has been known to cause scheduling delays of 10 seconds I still don't see this as a bug. Dynticks just "points it out to us".
Quoted 3 lines
well, not running softirqs when we could is a bug. It's not a big bug, but it's a bug nevertheless. It doesnt matter that softirqs could be delayed even worse under high load - there was no 'high load' here.
Gotcha. I'll prepare a smt-nice removal patch shortly.
Signature · 1 line
-ck
PATCH 1/1 sched: remove SMT nice
Remove the SMT-nice feature which idles sibling cpus on SMT cpus to facilitiate nice working properly where cpu power is shared. The idling of cpus in the presence of runnable tasks is considered too fragile, easy to break with outside code, and the complexity of managing this system if an architecture comes along with many logical cores sharing cpu power will be unworkable.
Remove the associated per_cpu_gain variable in sched_domains used only by this code.
--- include/asm-i386/topology.h | 1 include/asm-ia64/topology.h | 2 include/asm-mips/mach-ip27/topology.h | 1 include/asm-powerpc/topology.h | 1 include/asm-x86_64/topology.h | 1 include/linux/sched.h | 1 include/linux/topology.h | 4 kernel/sched.c | 155 ---------------------------------- 8 files changed, 1 insertion(+), 165 deletions(-)
kernel/sched.c +1 -154
@@ -3006,23 +3006,6 @@ static inline void idle_balance(int cpu, }#endif -static inline void wake_priority_sleeper (struct rq *rq) -{ -#ifdef CONFIG_SCHED_SMT -if (!rq->nr_running) -return ; - -spin_lock (&rq->lock); -/* -* If an SMT sibling task has been put to sleep for priority -* reasons reschedule the idle task to see if it can now run. -*/ -if (rq->nr_running) -resched_task (rq->idle); -spin_unlock (&rq->lock); -#endif -} - DEFINE_PER_CPU(struct kernel_stat, kstat);EXPORT_PER_CPU_SYMBOL (kstat);
@@ -3239,10 +3222,7 @@ void scheduler_tick(void)update_cpu_clock (p, rq, now); -if (p == rq->idle) -/* Task on the idle queue */ -wake_priority_sleeper (rq); -else +if (p != rq->idle)task_running_tick (rq, p);#ifdef CONFIG_SMP update_load (rq);
@@ -3251,136 +3231,6 @@ void scheduler_tick(void)#endif } -#ifdef CONFIG_SCHED_SMT -static inline void wakeup_busy_runqueue (struct rq *rq) -{ -/* If an SMT runqueue is sleeping due to priority reasons wake it up */ -if (rq->curr == rq->idle && rq->nr_running) -resched_task (rq->idle); -} - -/* -* Called with interrupt disabled and this_rq's runqueue locked. -*/ -static void wake_sleeping_dependent (int this_cpu) -{ -struct sched_domain *tmp, *sd =NULL ; -int i; - -for_each_domain (this_cpu, tmp) { -if (tmp->flags &SD_SHARE_CPUPOWER ) { - sd = tmp; -break ; - } - } - -if (!sd) -return ; - -for_each_cpu_mask (i, sd->span) { -struct rq *smt_rq =cpu_rq (i); - -if (i == this_cpu) -continue ; -if (unlikely (!spin_trylock (&smt_rq->lock))) -continue ; - -wakeup_busy_runqueue (smt_rq); -spin_unlock (&smt_rq->lock); - } -} - -/* -* number of 'lost' timeslices this task wont be able to fully -* utilize, if another task runs on a sibling. This models the -* slowdown effect of other tasks running on siblings: -*/ -static inline unsigned long -smt_slice (struct task_struct *p,struct sched_domain *sd) -{ -return p->time_slice * (100 - sd->per_cpu_gain) /100 ; -} - -/* -* To minimise lock contention and not have to drop this_rq's runlock we only -* trylock the sibling runqueues and bypass those runqueues if we fail to -* acquire their lock. As we only trylock the normal locking order does not -* need to be obeyed. -*/ -static int -dependent_sleeper (int this_cpu,struct rq *this_rq,struct task_struct *p) -{ -struct sched_domain *tmp, *sd =NULL ; -int ret =0 , i; - -/* kernel/rt threads do not participate in dependent sleeping */ -if (!p->mm ||rt_task (p)) -return 0 ; - -for_each_domain (this_cpu, tmp) { -if (tmp->flags &SD_SHARE_CPUPOWER ) { - sd = tmp; -break ; - } - } - -if (!sd) -return 0 ; - -for_each_cpu_mask (i, sd->span) { -struct task_struct *smt_curr; -struct rq *smt_rq; - -if (i == this_cpu) -continue ; - - smt_rq =cpu_rq (i); -if (unlikely (!spin_trylock (&smt_rq->lock))) -continue ; - - smt_curr = smt_rq->curr; - -if (!smt_curr->mm) - goto unlock; - -/* -* If a user task with lower static priority than the -* running task on the SMT sibling is trying to schedule, -* delay it till there is proportionately less timeslice -* left of the sibling task to prevent a lower priority -* task from using an unfair proportion of the -* physical cpu's resources. -ck -*/ -if (rt_task (smt_curr)) { -/* -* With real time tasks we run non-rt tasks only -* per_cpu_gain% of the time. -*/ -if ((jiffies %DEF_TIMESLICE ) > - (sd->per_cpu_gain *DEF_TIMESLICE /100 )) - ret =1 ; - }else { -if (smt_curr->static_prio < p->static_prio && - !TASK_PREEMPTS_CURR (p, smt_rq) && -smt_slice (smt_curr, sd) >task_timeslice (p)) - ret =1 ; - } -unlock: -spin_unlock (&smt_rq->lock); - } -return ret; -} -#else -static inline void wake_sleeping_dependent (int this_cpu) -{ -} -static inline int -dependent_sleeper (int this_cpu,struct rq *this_rq,struct task_struct *p) -{ -return 0 ; -} -#endif -#if defined(CONFIG_PREEMPT ) && defined(CONFIG_DEBUG_PREEMPT ) void fastcall add_preempt_count(int val)
@@ -3507,7 +3357,6 @@ need_resched_nonpreemptible:if (!rq->nr_running) { next = rq->idle; rq->expired_timestamp =0 ; -wake_sleeping_dependent (cpu); goto switch_tasks; } }
@@ -3547,8 +3396,6 @@ need_resched_nonpreemptible: } } next->sleep_type =SLEEP_NORMAL ; -if (dependent_sleeper (cpu, rq, next)) - next = rq->idle; switch_tasks:if (next == rq->idle)schedstat_inc (rq, sched_goidle);
include/asm-i386/topology.h +0 -1
@@ -85,7 +85,6 @@ static inline int node_to_first_cpu(int .idle_idx = 1, \ .newidle_idx = 2, \ .wake_idx =1 , \ - .per_cpu_gain =100 , \ .flags = SD_LOAD_BALANCE \ |SD_BALANCE_EXEC \ |SD_BALANCE_FORK \
include/asm-ia64/topology.h +0 -2
@@ -65,7 +65,6 @@ void build_cpu_to_node_map(void); .max_interval = 4, \ .busy_factor = 64, \ .imbalance_pct = 125, \ - .per_cpu_gain = 100, \ .cache_nice_tries = 2, \ .busy_idx = 2, \ .idle_idx = 1, \
@@ -97,7 +96,6 @@ void build_cpu_to_node_map(void); .newidle_idx = 0, /* unused */ \ .wake_idx = 1, \ .forkexec_idx =1 , \ - .per_cpu_gain =100 , \ .flags = SD_LOAD_BALANCE \ |SD_BALANCE_EXEC \ |SD_BALANCE_FORK \
include/asm-mips/mach-ip27/topology.h +0 -1
@@ -28,7 +28,6 @@ extern unsigned char __node_distances[MA .busy_factor = 32, \ .imbalance_pct = 125, \ .cache_nice_tries = 1, \ - .per_cpu_gain = 100, \ .flags =SD_LOAD_BALANCE \ |SD_BALANCE_EXEC \ | SD_WAKE_BALANCE, \
include/asm-powerpc/topology.h +0 -1
@@ -57,7 +57,6 @@ static inline int pcibus_to_node(struct .busy_factor = 32, \ .imbalance_pct = 125, \ .cache_nice_tries = 1, \ - .per_cpu_gain = 100, \ .busy_idx = 3, \ .idle_idx = 1, \ .newidle_idx = 2, \
include/asm-x86_64/topology.h +0 -1
@@ -43,7 +43,6 @@ extern int __node_distance(int, int); .newidle_idx = 0, \ .wake_idx = 1, \ .forkexec_idx =1 , \ - .per_cpu_gain =100 , \ .flags = SD_LOAD_BALANCE \ |SD_BALANCE_FORK \ |SD_BALANCE_EXEC \
include/linux/sched.h +0 -1
@@ -684,7 +684,6 @@ struct sched_domain {unsigned int imbalance_pct;/* No balance until over watermark */ unsigned long long cache_hot_time;/* Task considered cache hot (ns) */ unsigned int cache_nice_tries;/* Leave cache hot tasks for # tries */ -unsigned int per_cpu_gain;/* CPU % gained by adding domain cpus */ unsigned int busy_idx;unsigned int idle_idx;unsigned int newidle_idx;
include/linux/topology.h +0 -4
@@ -96,7 +96,6 @@ .busy_factor = 64, \ .imbalance_pct = 110, \ .cache_nice_tries = 0, \ - .per_cpu_gain = 25, \ .busy_idx = 0, \ .idle_idx = 0, \ .newidle_idx = 1, \
@@ -128,7 +127,6 @@ .busy_factor = 64, \ .imbalance_pct = 125, \ .cache_nice_tries = 1, \ - .per_cpu_gain = 100, \ .busy_idx = 2, \ .idle_idx = 1, \ .newidle_idx = 2, \
@@ -159,7 +157,6 @@ .busy_factor = 64, \ .imbalance_pct = 125, \ .cache_nice_tries = 1, \ - .per_cpu_gain = 100, \ .busy_idx = 2, \ .idle_idx = 1, \ .newidle_idx = 2, \
@@ -193,7 +190,6 @@ .newidle_idx = 0, /* unused */ \ .wake_idx = 0, /* unused */ \ .forkexec_idx = 0, /* unused */ \ - .per_cpu_gain = 100, \ .flags =SD_LOAD_BALANCE \ | SD_SERIALIZE, \ .last_balance = jiffies, \
Signature · 1 line
-ck
A message that is not in the archive (sent off-list or not yet received): [email protected]
Re: [PATCH] sched: remove SMT nice
Quoted 10 lines · Andrew Morton
On Fri, 2 Mar 2007 09:33:37 +1100
Quoted 7 lines · Con Kolivas
Remove the SMT-nice feature which idles sibling cpus on SMT cpus to facilitiate nice working properly where cpu power is shared. The idling of cpus in the presence of runnable tasks is considered too fragile, easy to break with outside code, and the complexity of managing this system if an architecture comes along with many logical cores sharing cpu power will be unworkable.
Quoted 5 lines
Quoted 2 lines
Remove the associated
per_cpu_gainvariable insched_domainsused only by this code.Seems like a somewhat serious step. Is this urgent enough for 2.6.21? If so, why? The mysql thing?
No, Nish showed improvement in fact with SCHED_SMT enabled so this is unrelated.
The reason is that with dynticks enabled, this code breaks without yet further tweaks so dynticks brought on the rapid demise of this code. So either we tweak this code or kill it off entirely. It was Ingo's preference to kill it off. Either way this needs to happen for 2.6.21 since dynticks has gone in.
Signature · 1 line
-ck