Re: How to secure erase PCI-E NVME SSD connected via USB3?

[Jeff Chua]

On Thu, Aug 2, 2018 at 8:29 PM, Alan Cox  wrote:
>> # hdparm --user-master u --security-erase p /dev/sda
>> (returns immediately and does nothing).
>>
>> I've tried hdparm on an SSD connected via USB3 and it secure-erased ok.
>>
>> Anyone working on this?
>
> Sounds to me like you need to contact the vendor of the interface in
> question. If it accepted a security erase command and didn't do it then
> it's broken. It's at liberty to refuse it, or report it doesn't know what
> you are talking about, but if it just returned and after re-plugging the
> device its still using the old keys then it or the device is busted and
> it's not something the OS can do much about.

Alan,

You're right. I wrote to JMicron, and they are kind to reply that
"hdparm not support secure-erase feature with USB to NVMe device", and
told me to plug the card into a PCI slot to perform the
security-erase.

I'm asking JMicron again if the JMS583 even support security-erase.

Thanks,
Jeff

Re: How to secure erase PCI-E NVME SSD connected via USB3?

[Jeff Chua]

On Thu, Aug 2, 2018 at 8:29 PM, Alan Cox  wrote:
>> # hdparm --user-master u --security-erase p /dev/sda
>> (returns immediately and does nothing).
>>
>> I've tried hdparm on an SSD connected via USB3 and it secure-erased ok.
>>
>> Anyone working on this?
>
> Sounds to me like you need to contact the vendor of the interface in
> question. If it accepted a security erase command and didn't do it then
> it's broken. It's at liberty to refuse it, or report it doesn't know what
> you are talking about, but if it just returned and after re-plugging the
> device its still using the old keys then it or the device is busted and
> it's not something the OS can do much about.

Alan,

You're right. I wrote to JMicron, and they are kind to reply that
"hdparm not support secure-erase feature with USB to NVMe device", and
told me to plug the card into a PCI slot to perform the
security-erase.

I'm asking JMicron again if the JMS583 even support security-erase.

Thanks,
Jeff

Re: How to secure erase PCI-E NVME SSD connected via USB3?

[Jeff Chua]

On Wed, Aug 1, 2018 at 1:02 PM, Jeff Chua  wrote:
> On Tue, Jul 31, 2018 at 7:07 PM, Ming Lei  wrote:
>> On Sun, Jul 29, 2018 at 5:09 PM, Jeff Chua  wrote:
>>> I'm testing the USB3-to-PCI-E NVME SSD. It's works using uas module,
>>> recognized it as /dev/sda.
>>>
>>> Since it's an USB device, the nvme-cli tools won't work, nor does
>>> hdparm, as it's a NVME SSD.
>>>
>>> So, how to secure-erase the NVME SSD connected via the JMS583 chip?
>>
>> You may try 'blkdiscard --secure' and see if you are luck.
>
> Interesting, will try that.

# blkdiscard --secure /dev/sda
blkdiscard: /dev/sda: BLKSECDISCARD ioctl failed: Operation not supported

# hdparm --user-master u --security-erase p /dev/sda
(returns immediately and does nothing).

I've tried hdparm on an SSD connected via USB3 and it secure-erased ok.

Anyone working on this?

Thanks,
Jeff

Re: How to secure erase PCI-E NVME SSD connected via USB3?

[Jeff Chua]

On Wed, Aug 1, 2018 at 1:02 PM, Jeff Chua  wrote:
> On Tue, Jul 31, 2018 at 7:07 PM, Ming Lei  wrote:
>> On Sun, Jul 29, 2018 at 5:09 PM, Jeff Chua  wrote:
>>> I'm testing the USB3-to-PCI-E NVME SSD. It's works using uas module,
>>> recognized it as /dev/sda.
>>>
>>> Since it's an USB device, the nvme-cli tools won't work, nor does
>>> hdparm, as it's a NVME SSD.
>>>
>>> So, how to secure-erase the NVME SSD connected via the JMS583 chip?
>>
>> You may try 'blkdiscard --secure' and see if you are luck.
>
> Interesting, will try that.

# blkdiscard --secure /dev/sda
blkdiscard: /dev/sda: BLKSECDISCARD ioctl failed: Operation not supported

# hdparm --user-master u --security-erase p /dev/sda
(returns immediately and does nothing).

I've tried hdparm on an SSD connected via USB3 and it secure-erased ok.

Anyone working on this?

Thanks,
Jeff

Re: How to secure erase PCI-E NVME SSD connected via USB3?

[Jeff Chua]

On Tue, Jul 31, 2018 at 7:07 PM, Ming Lei  wrote:
> On Sun, Jul 29, 2018 at 5:09 PM, Jeff Chua  wrote:
>> I'm testing the USB3-to-PCI-E NVME SSD. It's works using uas module,
>> recognized it as /dev/sda.
>>
>> Since it's an USB device, the nvme-cli tools won't work, nor does
>> hdparm, as it's a NVME SSD.
>>
>> So, how to secure-erase the NVME SSD connected via the JMS583 chip?
>
> You may try 'blkdiscard --secure' and see if you are luck.

Interesting, will try that.

Thanks for the pointer.

Jeff.

Re: How to secure erase PCI-E NVME SSD connected via USB3?

[Jeff Chua]

On Tue, Jul 31, 2018 at 7:07 PM, Ming Lei  wrote:
> On Sun, Jul 29, 2018 at 5:09 PM, Jeff Chua  wrote:
>> I'm testing the USB3-to-PCI-E NVME SSD. It's works using uas module,
>> recognized it as /dev/sda.
>>
>> Since it's an USB device, the nvme-cli tools won't work, nor does
>> hdparm, as it's a NVME SSD.
>>
>> So, how to secure-erase the NVME SSD connected via the JMS583 chip?
>
> You may try 'blkdiscard --secure' and see if you are luck.

Interesting, will try that.

Thanks for the pointer.

Jeff.

How to secure erase PCI-E NVME SSD connected via USB3?

[Jeff Chua]

I'm testing the USB3-to-PCI-E NVME SSD. It's works using uas module,
recognized it as /dev/sda.

Since it's an USB device, the nvme-cli tools won't work, nor does
hdparm, as it's a NVME SSD.

So, how to secure-erase the NVME SSD connected via the JMS583 chip?

Thanks,
Jeff.

How to secure erase PCI-E NVME SSD connected via USB3?

[Jeff Chua]

I'm testing the USB3-to-PCI-E NVME SSD. It's works using uas module,
recognized it as /dev/sda.

Since it's an USB device, the nvme-cli tools won't work, nor does
hdparm, as it's a NVME SSD.

So, how to secure-erase the NVME SSD connected via the JMS583 chip?

Thanks,
Jeff.

Re: can't boot with reiserfs on linux-4.6.0+

[Jeff Chua]

On Thu, May 26, 2016 at 3:46 PM, Hillf Danton  wrote:
>> > See if this fixes your reproducer.
>> >
>> > diff --git a/fs/xattr.c b/fs/xattr.c
>> > index b11945e..49b8eab 100644
>> > --- a/fs/xattr.c
>> > +++ b/fs/xattr.c
>> > @@ -667,6 +667,9 @@ xattr_resolve_name(const struct xattr_handler 
>> > **handlers, const char **name)
>> >  {
>> > const struct xattr_handler *handler;
>> >
>> > +   if (!handlers)
>> > +   return NULL;
>> > +
>> > if (!*name)
>> > return NULL;
>> >
>>
>> Tried, but doesn't work.
>>
> See if this fixes your reproducer.
>
> --- linux-4.6/fs/xattr.cMon May 16 06:43:13 2016
> +++ b/fs/xattr.cThu May 26 15:36:14 2016
> @@ -667,8 +667,8 @@ xattr_resolve_name(const struct xattr_ha
>  {
> const struct xattr_handler *handler;
>
> -   if (!*name)
> -   return NULL;
> +   if (!handlers || !*name)
> +   return ERR_PTR(-EINVAL);
>
> for_each_xattr_handler(handlers, handler) {
> const char *n;
> --

Hillf,

That worked and it's already in Linus's latest tree.

Thanks for sharing.

Jeff

Re: can't boot with reiserfs on linux-4.6.0+

[Jeff Chua]

On Thu, May 26, 2016 at 3:46 PM, Hillf Danton  wrote:
>> > See if this fixes your reproducer.
>> >
>> > diff --git a/fs/xattr.c b/fs/xattr.c
>> > index b11945e..49b8eab 100644
>> > --- a/fs/xattr.c
>> > +++ b/fs/xattr.c
>> > @@ -667,6 +667,9 @@ xattr_resolve_name(const struct xattr_handler 
>> > **handlers, const char **name)
>> >  {
>> > const struct xattr_handler *handler;
>> >
>> > +   if (!handlers)
>> > +   return NULL;
>> > +
>> > if (!*name)
>> > return NULL;
>> >
>>
>> Tried, but doesn't work.
>>
> See if this fixes your reproducer.
>
> --- linux-4.6/fs/xattr.cMon May 16 06:43:13 2016
> +++ b/fs/xattr.cThu May 26 15:36:14 2016
> @@ -667,8 +667,8 @@ xattr_resolve_name(const struct xattr_ha
>  {
> const struct xattr_handler *handler;
>
> -   if (!*name)
> -   return NULL;
> +   if (!handlers || !*name)
> +   return ERR_PTR(-EINVAL);
>
> for_each_xattr_handler(handlers, handler) {
> const char *n;
> --

Hillf,

That worked and it's already in Linus's latest tree.

Thanks for sharing.

Jeff

Re: can't boot with reiserfs on linux-4.6.0+

[Jeff Chua]

On Wed, May 25, 2016 at 11:51 PM, Al Viro <v...@zeniv.linux.org.uk> wrote:
> On Wed, May 25, 2016 at 05:30:22PM +0800, Jeff Chua wrote:
>> On Wed, May 25, 2016 at 2:37 AM, Al Viro <v...@zeniv.linux.org.uk> wrote:
>> > On Tue, May 24, 2016 at 04:59:02PM +0100, Al Viro wrote:
>> >
>> >> Umm...  Any chance of getting the function names to go with the addresses?
>> >> I'll try to reproduce it here, but the things would be easier with that
>> >> information...
>> >
>> > See if this fixes your reproducer.
>> >
>> > diff --git a/fs/xattr.c b/fs/xattr.c
>> > index b11945e..49b8eab 100644
>> > --- a/fs/xattr.c
>> > +++ b/fs/xattr.c
>> > @@ -667,6 +667,9 @@ xattr_resolve_name(const struct xattr_handler 
>> > **handlers, const char **name)
>> >  {
>> > const struct xattr_handler *handler;
>> >
>> > +   if (!handlers)
>> > +   return NULL;
>> > +
>> > if (!*name)
>> > return NULL;
>> >
>>
>> Tried, but doesn't work.
>
> D'oh...  Since "vfs: Distinguish between full xattr names and proper prefixes"
> we really need to return ERR_PTR() there (and I even have a patch from Andreas
> fixing that if (!*name) return NULL; in my queue).  Combined delta to test
> (that'll go as two commits, one mine, one his):
>

Al, Linus,

Great that worked! And I see the patch is already in Linus's tree.

Thanks for the quick response and fixes.

Jeff.


> diff --git a/fs/xattr.c b/fs/xattr.c
> index b11945e..fc81e77 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -655,6 +655,7 @@ strcmp_prefix(const char *a, const char *a_prefix)
>   * operations to the correct xattr_handler.
>   */
>  #define for_each_xattr_handler(handlers, handler)  \
> +   if (handlers)   \
> for ((handler) = *(handlers)++; \
> (handler) != NULL;  \
> (handler) = *(handlers)++)
> @@ -668,7 +669,7 @@ xattr_resolve_name(const struct xattr_handler **handlers, 
> const char **name)
> const struct xattr_handler *handler;
>
> if (!*name)
> -   return NULL;
> +   return ERR_PTR(-EINVAL);
>
> for_each_xattr_handler(handlers, handler) {
> const char *n;

Re: can't boot with reiserfs on linux-4.6.0+

[Jeff Chua]

On Wed, May 25, 2016 at 11:51 PM, Al Viro  wrote:
> On Wed, May 25, 2016 at 05:30:22PM +0800, Jeff Chua wrote:
>> On Wed, May 25, 2016 at 2:37 AM, Al Viro  wrote:
>> > On Tue, May 24, 2016 at 04:59:02PM +0100, Al Viro wrote:
>> >
>> >> Umm...  Any chance of getting the function names to go with the addresses?
>> >> I'll try to reproduce it here, but the things would be easier with that
>> >> information...
>> >
>> > See if this fixes your reproducer.
>> >
>> > diff --git a/fs/xattr.c b/fs/xattr.c
>> > index b11945e..49b8eab 100644
>> > --- a/fs/xattr.c
>> > +++ b/fs/xattr.c
>> > @@ -667,6 +667,9 @@ xattr_resolve_name(const struct xattr_handler 
>> > **handlers, const char **name)
>> >  {
>> > const struct xattr_handler *handler;
>> >
>> > +   if (!handlers)
>> > +   return NULL;
>> > +
>> > if (!*name)
>> > return NULL;
>> >
>>
>> Tried, but doesn't work.
>
> D'oh...  Since "vfs: Distinguish between full xattr names and proper prefixes"
> we really need to return ERR_PTR() there (and I even have a patch from Andreas
> fixing that if (!*name) return NULL; in my queue).  Combined delta to test
> (that'll go as two commits, one mine, one his):
>

Al, Linus,

Great that worked! And I see the patch is already in Linus's tree.

Thanks for the quick response and fixes.

Jeff.


> diff --git a/fs/xattr.c b/fs/xattr.c
> index b11945e..fc81e77 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -655,6 +655,7 @@ strcmp_prefix(const char *a, const char *a_prefix)
>   * operations to the correct xattr_handler.
>   */
>  #define for_each_xattr_handler(handlers, handler)  \
> +   if (handlers)   \
> for ((handler) = *(handlers)++; \
> (handler) != NULL;  \
> (handler) = *(handlers)++)
> @@ -668,7 +669,7 @@ xattr_resolve_name(const struct xattr_handler **handlers, 
> const char **name)
> const struct xattr_handler *handler;
>
> if (!*name)
> -   return NULL;
> +   return ERR_PTR(-EINVAL);
>
> for_each_xattr_handler(handlers, handler) {
> const char *n;

Re: can't boot with reiserfs on linux-4.6.0+

[Jeff Chua]

On Wed, May 25, 2016 at 2:37 AM, Al Viro  wrote:
> On Tue, May 24, 2016 at 04:59:02PM +0100, Al Viro wrote:
>
>> Umm...  Any chance of getting the function names to go with the addresses?
>> I'll try to reproduce it here, but the things would be easier with that
>> information...
>
> See if this fixes your reproducer.
>
> diff --git a/fs/xattr.c b/fs/xattr.c
> index b11945e..49b8eab 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -667,6 +667,9 @@ xattr_resolve_name(const struct xattr_handler **handlers, 
> const char **name)
>  {
> const struct xattr_handler *handler;
>
> +   if (!handlers)
> +   return NULL;
> +
> if (!*name)
> return NULL;
>

Tried, but doesn't work.

Here's dmesg with symbols ...


[   35.565534] BUG: unable to handle kernel NULL pointer dereference
at 0020
[   35.566200] IP: [] generic_getxattr+0x4f/0x5d
[   35.566828] PGD 409992067 PUD 409993067 PMD 0
[   35.567469] Oops:  [#1] SMP
[   35.568082] Modules linked in: usbhid
[   35.568731] CPU: 1 PID: 1873 Comm: bash Not tainted 4.6.0 #5
[   35.569339] Hardware name: LENOVO 20F5000RSG/20F5000RSG, BIOS
R02ET44W (1.17 ) 01/25/2016
[   35.569981] task: 88040c3f2580 ti: 88040990c000 task.ti:
88040990c000
[   35.570603] RIP: 0010:[]  []
generic_getxattr+0x4f/0x5d
[   35.571246] RSP: 0018:88040990fdd8  EFLAGS: 00010207
[   35.571843] RAX:  RBX: 88041043d6c0 RCX: 819e2917
[   35.572436] RDX: 8804104b4310 RSI: 88041043d6c0 RDI: 
[   35.573085] RBP: 8804104b4310 R08: 88040990fe0c R09: 0014
[   35.573673] R10:  R11:  R12: 88040990fe0c
[   35.574257] R13: 88040e60a6c0 R14: 0022 R15: 
[   35.574868] FS:  7f092f53e700() GS:88042144()
knlGS:
[   35.575446] CS:  0010 DS:  ES:  CR0: 80050033
[   35.576013] CR2: 0020 CR3: 000409991000 CR4: 003406e0
[   35.576621] DR0:  DR1:  DR2: 
[   35.577186] DR3:  DR6: fffe0ff0 DR7: 0400
[   35.577748] Stack:
[   35.578342]  0014 819e2917 88040990fe3c

[   35.578960]  8800d25ce600 8123 810c75a2

[   35.579583]   88040e607000 81299bc1

[   35.580172] Call Trace:
[   35.580749]  [] ? get_vfs_caps_from_disk+0x51/0xcf
[   35.581365]  [] ? __vma_link_rb+0x58/0x73
[   35.581933]  [] ? cap_bprm_set_creds+0x1b0/0x420
[   35.582504]  [] ? prepare_binprm+0xce/0x107
[   35.583095]  [] ? do_execveat_common.isra.49+0x3d0/0x5b4
[   35.583657]  [] ? do_execve+0x1a/0x1c
[   35.584248]  [] ? SyS_execve+0x23/0x2a
[   35.584801]  [] ? do_syscall_64+0x51/0x89
[   35.585345]  [] ? entry_SYSCALL64_slow_path+0x25/0x25
[   35.585882] Code: 8b b8 a0 00 00 00 e8 6c fc ff ff 4c 8b 04 24 48
3d 00 f0 ff ff 77 19 4d 89 c1 48 8b 4c 24 08 4d 89 e0 48 89 ea 48 89
de 48 89 c7  50 20 48 98 48 83 c4 10 5b 5d 41 5c c3 41 54 48 c7 c0
18 4e
[   35.587155] RIP  [] generic_getxattr+0x4f/0x5d
[   35.587776]  RSP 
[   35.588351] CR2: 0020
[   35.588974] ---[ end trace 1ac6eb2a9a9b2964 ]---

Thanks,
Jeff

Re: can't boot with reiserfs on linux-4.6.0+

[Jeff Chua]

On Wed, May 25, 2016 at 2:37 AM, Al Viro  wrote:
> On Tue, May 24, 2016 at 04:59:02PM +0100, Al Viro wrote:
>
>> Umm...  Any chance of getting the function names to go with the addresses?
>> I'll try to reproduce it here, but the things would be easier with that
>> information...
>
> See if this fixes your reproducer.
>
> diff --git a/fs/xattr.c b/fs/xattr.c
> index b11945e..49b8eab 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -667,6 +667,9 @@ xattr_resolve_name(const struct xattr_handler **handlers, 
> const char **name)
>  {
> const struct xattr_handler *handler;
>
> +   if (!handlers)
> +   return NULL;
> +
> if (!*name)
> return NULL;
>

Tried, but doesn't work.

Here's dmesg with symbols ...


[   35.565534] BUG: unable to handle kernel NULL pointer dereference
at 0020
[   35.566200] IP: [] generic_getxattr+0x4f/0x5d
[   35.566828] PGD 409992067 PUD 409993067 PMD 0
[   35.567469] Oops:  [#1] SMP
[   35.568082] Modules linked in: usbhid
[   35.568731] CPU: 1 PID: 1873 Comm: bash Not tainted 4.6.0 #5
[   35.569339] Hardware name: LENOVO 20F5000RSG/20F5000RSG, BIOS
R02ET44W (1.17 ) 01/25/2016
[   35.569981] task: 88040c3f2580 ti: 88040990c000 task.ti:
88040990c000
[   35.570603] RIP: 0010:[]  []
generic_getxattr+0x4f/0x5d
[   35.571246] RSP: 0018:88040990fdd8  EFLAGS: 00010207
[   35.571843] RAX:  RBX: 88041043d6c0 RCX: 819e2917
[   35.572436] RDX: 8804104b4310 RSI: 88041043d6c0 RDI: 
[   35.573085] RBP: 8804104b4310 R08: 88040990fe0c R09: 0014
[   35.573673] R10:  R11:  R12: 88040990fe0c
[   35.574257] R13: 88040e60a6c0 R14: 0022 R15: 
[   35.574868] FS:  7f092f53e700() GS:88042144()
knlGS:
[   35.575446] CS:  0010 DS:  ES:  CR0: 80050033
[   35.576013] CR2: 0020 CR3: 000409991000 CR4: 003406e0
[   35.576621] DR0:  DR1:  DR2: 
[   35.577186] DR3:  DR6: fffe0ff0 DR7: 0400
[   35.577748] Stack:
[   35.578342]  0014 819e2917 88040990fe3c

[   35.578960]  8800d25ce600 8123 810c75a2

[   35.579583]   88040e607000 81299bc1

[   35.580172] Call Trace:
[   35.580749]  [] ? get_vfs_caps_from_disk+0x51/0xcf
[   35.581365]  [] ? __vma_link_rb+0x58/0x73
[   35.581933]  [] ? cap_bprm_set_creds+0x1b0/0x420
[   35.582504]  [] ? prepare_binprm+0xce/0x107
[   35.583095]  [] ? do_execveat_common.isra.49+0x3d0/0x5b4
[   35.583657]  [] ? do_execve+0x1a/0x1c
[   35.584248]  [] ? SyS_execve+0x23/0x2a
[   35.584801]  [] ? do_syscall_64+0x51/0x89
[   35.585345]  [] ? entry_SYSCALL64_slow_path+0x25/0x25
[   35.585882] Code: 8b b8 a0 00 00 00 e8 6c fc ff ff 4c 8b 04 24 48
3d 00 f0 ff ff 77 19 4d 89 c1 48 8b 4c 24 08 4d 89 e0 48 89 ea 48 89
de 48 89 c7  50 20 48 98 48 83 c4 10 5b 5d 41 5c c3 41 54 48 c7 c0
18 4e
[   35.587155] RIP  [] generic_getxattr+0x4f/0x5d
[   35.587776]  RSP 
[   35.588351] CR2: 0020
[   35.588974] ---[ end trace 1ac6eb2a9a9b2964 ]---

Thanks,
Jeff

Re: can't boot with reiserfs on linux-4.6.0+

[Jeff Chua]

On Wed, May 25, 2016 at 12:10 AM, Linus Torvalds
 wrote:
> On Tue, May 24, 2016 at 8:59 AM, Al Viro  wrote:
>>
>> Umm...  Any chance of getting the function names to go with the addresses?
>> I'll try to reproduce it here, but the things would be easier with that
>> information...
>
> Yeah, we shouldn't even allow non-KALLSYMS builds. In fact, unless you
> pick EXPERT (which you shouldn't, unless you're doing some embedded
> development) you can't even disable it.
>
> Jeff, please don't use non-KALLSYMS builds. They are completely undebuggable.
>
>  Linus

Got it. Will compile with CONFIG_KALLSYMS=y :)

Thanks,
Jeff

Re: can't boot with reiserfs on linux-4.6.0+

[Jeff Chua]

On Wed, May 25, 2016 at 12:10 AM, Linus Torvalds
 wrote:
> On Tue, May 24, 2016 at 8:59 AM, Al Viro  wrote:
>>
>> Umm...  Any chance of getting the function names to go with the addresses?
>> I'll try to reproduce it here, but the things would be easier with that
>> information...
>
> Yeah, we shouldn't even allow non-KALLSYMS builds. In fact, unless you
> pick EXPERT (which you shouldn't, unless you're doing some embedded
> development) you can't even disable it.
>
> Jeff, please don't use non-KALLSYMS builds. They are completely undebuggable.
>
>  Linus

Got it. Will compile with CONFIG_KALLSYMS=y :)

Thanks,
Jeff

can't boot with reiserfs on linux-4.6.0+

[Jeff Chua]

Seems to break after index 348619f..d55dc5a 100644

Boot up with ext4 works, but try anything to access anything on the
reiser partition such as "/mnt/bin/passwd" resulted in the following
...

[   93.380353] BUG: unable to handle kernel NULL pointer dereference
at   (null)
[   93.380924] IP: [] 0x81101ad7
[   93.381476] PGD 40520a067 PUD 4052f0067 PMD 0
[   93.381974] Oops:  [#6] SMP
[   93.382480] Modules linked in: usbhid
[   93.382972] CPU: 0 PID: 1888 Comm: bash Tainted: G  D 4.6.0 #3
[   93.383468] Hardware name: LENOVO 20F5000RSG/20F5000RSG, BIOS
R02ET44W (1.17 ) 01/25/2016
[   93.383986] task: 88040c313200 ti: 88040526c000 task.ti:
88040526c000
[   93.384486] RIP: 0010:[]  []
0x81101ad7
[   93.384985] RSP: 0018:88040526fdd0  EFLAGS: 00010282
[   93.385475] RAX:  RBX: 880410784b40 RCX: 88040526fe0c
[   93.385988] RDX: 81951fc2 RSI: 88040526fde0 RDI: 
[   93.386478] RBP: 88041065d538 R08: 0014 R09: 81951fc2
[   93.386970] R10:  R11:  R12: 88040526fe0c
[   93.387475] R13: 88040c364540 R14: 0022 R15: 
[   93.387963] FS:  7f56f4879700() GS:88042140()
knlGS:
[   93.388458] CS:  0010 DS:  ES:  CR0: 80050033
[   93.388964] CR2:  CR3: 000404c3c000 CR4: 003406f0
[   93.389454] DR0:  DR1:  DR2: 
[   93.389937] DR3:  DR6: fffe0ff0 DR7: 0400
[   93.390437] Stack:
[   93.390956]  81101e5c 0014 81951fc2
88040526fe3c
[   93.391496]   8800d2441800 81298232
810c60c4
[   93.391996]    8800d254f000
81298460
[   93.392528] Call Trace:
[   93.393011]  [] ? 0x81101e5c
[   93.393495]  [] ? 0x81298232
[   93.394006]  [] ? 0x810c60c4
[   93.394481]  [] ? 0x81298460
[   93.394955]  [] ? 0x810eb8fd
[   93.395447]  [] ? 0x810ec20f
[   93.395919]  [] ? 0x810ec40d
[   93.396422]  [] ? 0x810ec605
[   93.396892]  [] ? 0x81000fe6
[   93.397361]  [] ? 0x816c04c0
[   93.397829] Code: 48 c7 c0 a1 ff ff ff c3 48 8b 47 30 48 8b 40 20
48 8b 80 90 00 00 00 48 85 c0 74 02 ff e0 31 c0 c3 4c 8b 0e 31 c0 4d
85 c9 74 6e <48> 8b 07 4c 8d 47 08 48 85 c0 74 36 48 8b 78 08 48 85 ff
48 89
[   93.398970] RIP  [] 0x81101ad7
[   93.399449]  RSP 
[   93.399919] CR2: 
[   93.400419] ---[ end trace 78efe26e2c832ba1 ]---


Thanks,
Jeff

can't boot with reiserfs on linux-4.6.0+

[Jeff Chua]

Seems to break after index 348619f..d55dc5a 100644

Boot up with ext4 works, but try anything to access anything on the
reiser partition such as "/mnt/bin/passwd" resulted in the following
...

[   93.380353] BUG: unable to handle kernel NULL pointer dereference
at   (null)
[   93.380924] IP: [] 0x81101ad7
[   93.381476] PGD 40520a067 PUD 4052f0067 PMD 0
[   93.381974] Oops:  [#6] SMP
[   93.382480] Modules linked in: usbhid
[   93.382972] CPU: 0 PID: 1888 Comm: bash Tainted: G  D 4.6.0 #3
[   93.383468] Hardware name: LENOVO 20F5000RSG/20F5000RSG, BIOS
R02ET44W (1.17 ) 01/25/2016
[   93.383986] task: 88040c313200 ti: 88040526c000 task.ti:
88040526c000
[   93.384486] RIP: 0010:[]  []
0x81101ad7
[   93.384985] RSP: 0018:88040526fdd0  EFLAGS: 00010282
[   93.385475] RAX:  RBX: 880410784b40 RCX: 88040526fe0c
[   93.385988] RDX: 81951fc2 RSI: 88040526fde0 RDI: 
[   93.386478] RBP: 88041065d538 R08: 0014 R09: 81951fc2
[   93.386970] R10:  R11:  R12: 88040526fe0c
[   93.387475] R13: 88040c364540 R14: 0022 R15: 
[   93.387963] FS:  7f56f4879700() GS:88042140()
knlGS:
[   93.388458] CS:  0010 DS:  ES:  CR0: 80050033
[   93.388964] CR2:  CR3: 000404c3c000 CR4: 003406f0
[   93.389454] DR0:  DR1:  DR2: 
[   93.389937] DR3:  DR6: fffe0ff0 DR7: 0400
[   93.390437] Stack:
[   93.390956]  81101e5c 0014 81951fc2
88040526fe3c
[   93.391496]   8800d2441800 81298232
810c60c4
[   93.391996]    8800d254f000
81298460
[   93.392528] Call Trace:
[   93.393011]  [] ? 0x81101e5c
[   93.393495]  [] ? 0x81298232
[   93.394006]  [] ? 0x810c60c4
[   93.394481]  [] ? 0x81298460
[   93.394955]  [] ? 0x810eb8fd
[   93.395447]  [] ? 0x810ec20f
[   93.395919]  [] ? 0x810ec40d
[   93.396422]  [] ? 0x810ec605
[   93.396892]  [] ? 0x81000fe6
[   93.397361]  [] ? 0x816c04c0
[   93.397829] Code: 48 c7 c0 a1 ff ff ff c3 48 8b 47 30 48 8b 40 20
48 8b 80 90 00 00 00 48 85 c0 74 02 ff e0 31 c0 c3 4c 8b 0e 31 c0 4d
85 c9 74 6e <48> 8b 07 4c 8d 47 08 48 85 c0 74 36 48 8b 78 08 48 85 ff
48 89
[   93.398970] RIP  [] 0x81101ad7
[   93.399449]  RSP 
[   93.399919] CR2: 
[   93.400419] ---[ end trace 78efe26e2c832ba1 ]---


Thanks,
Jeff

Re: how to check how much data left to sync to disk at umount?

[Jeff Chua]

On Thu, Sep 17, 2015 at 9:50 AM, Dave Chinner  wrote:
> On Mon, Sep 07, 2015 at 01:29:33PM +0800, Jeff Chua wrote:
>> When umount a slow device such as an SD card, the command will take a
>> while to run depending on how much data is left to write to the
>> device. Is there way to check how much data is remaining waiting to
>> write to the device?
>
> $ grep "Dirty\|Writeback" /proc/meminfo
>
> And infer from that.

It be a big challenge if the SD write is not the only disk activity!

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: how to check how much data left to sync to disk at umount?

[Jeff Chua]

On Thu, Sep 17, 2015 at 9:50 AM, Dave Chinner <da...@fromorbit.com> wrote:
> On Mon, Sep 07, 2015 at 01:29:33PM +0800, Jeff Chua wrote:
>> When umount a slow device such as an SD card, the command will take a
>> while to run depending on how much data is left to write to the
>> device. Is there way to check how much data is remaining waiting to
>> write to the device?
>
> $ grep "Dirty\|Writeback" /proc/meminfo
>
> And infer from that.

It be a big challenge if the SD write is not the only disk activity!

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

how to check how much data left to sync to disk at umount?

[Jeff Chua]

When umount a slow device such as an SD card, the command will take a
while to run depending on how much data is left to write to the
device. Is there way to check how much data is remaining waiting to
write to the device?

Thanks,
Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

how to check how much data left to sync to disk at umount?

[Jeff Chua]

When umount a slow device such as an SD card, the command will take a
while to run depending on how much data is left to write to the
device. Is there way to check how much data is remaining waiting to
write to the device?

Thanks,
Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Stop SSD from waiting for "Spinning up disk..."

[Jeff Chua]

On Thu, Jun 25, 2015 at 2:08 PM, Martin Steigerwald  wrote:
> Am Mittwoch, 24. Juni 2015, 18:41:52 schrieb Greg Kroah-Hartman:
>> On Thu, Jun 25, 2015 at 07:55:45AM +0800, Jeff Chua wrote:
>> > On Thu, Jun 25, 2015 at 12:28 AM, Greg Kroah-Hartman
>> >
>> >  wrote:
>> > > On Thu, Jun 25, 2015 at 12:22:47AM +0800, Jeff Chua wrote:
>> > >> Both sda and sdb have the same SSD model.
>> > >
>> > > That's a bug in your USB bridge chip, odds are it is not reporting the
>> > > value properly.  There's nothing the scsi core or USB stack can do
>> > > about
>> > > this, sorry.  Please complain to the hardware manufacturer.
>> >
>> > There are workaround boot cmdline parameters for other things ... any
>> > chance to consider  one to fix broken rotational option? I'm not sure
>> > how many out there are broken, but I really would like a faster way to
>> > access my USB SSD without waiting for the "disk spinup".
>>
>> Just like module paramaters, boot command lines are not for device
>> specific attributes, sorry.  Again, please contact the manufacturer to
>> get this fixed.  We can't add a quirk for this bridge because it would
>> not work if you really put a rotational disk behind it.
>
> How about a way to override it in sysfs directly during runtime just for a
> device individually, like choosing an I/O scheduler for example?
>
>> Given the cheap cost of these types of bridges, I recommend just getting
>> one that works.
>
> That is an option as well and may educate hardware manufacturers to look a
> bit better at the quality of those devices (at least then Linux market share
> in that market increases).

I just needed something. "throwing" those cheap USB3 ... like I've a
bunch of them. It's just a waste... and they are perfectly fast "uas"
interfaces!

Thanks,
Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Stop SSD from waiting for Spinning up disk...

[Jeff Chua]

On Thu, Jun 25, 2015 at 2:08 PM, Martin Steigerwald mar...@lichtvoll.de wrote:
 Am Mittwoch, 24. Juni 2015, 18:41:52 schrieb Greg Kroah-Hartman:
 On Thu, Jun 25, 2015 at 07:55:45AM +0800, Jeff Chua wrote:
  On Thu, Jun 25, 2015 at 12:28 AM, Greg Kroah-Hartman
 
  gre...@linuxfoundation.org wrote:
   On Thu, Jun 25, 2015 at 12:22:47AM +0800, Jeff Chua wrote:
   Both sda and sdb have the same SSD model.
  
   That's a bug in your USB bridge chip, odds are it is not reporting the
   value properly.  There's nothing the scsi core or USB stack can do
   about
   this, sorry.  Please complain to the hardware manufacturer.
 
  There are workaround boot cmdline parameters for other things ... any
  chance to consider  one to fix broken rotational option? I'm not sure
  how many out there are broken, but I really would like a faster way to
  access my USB SSD without waiting for the disk spinup.

 Just like module paramaters, boot command lines are not for device
 specific attributes, sorry.  Again, please contact the manufacturer to
 get this fixed.  We can't add a quirk for this bridge because it would
 not work if you really put a rotational disk behind it.

 How about a way to override it in sysfs directly during runtime just for a
 device individually, like choosing an I/O scheduler for example?

 Given the cheap cost of these types of bridges, I recommend just getting
 one that works.

 That is an option as well and may educate hardware manufacturers to look a
 bit better at the quality of those devices (at least then Linux market share
 in that market increases).

I just needed something. throwing those cheap USB3 ... like I've a
bunch of them. It's just a waste... and they are perfectly fast uas
interfaces!

Thanks,
Jeff.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Stop SSD from waiting for "Spinning up disk..."

[Jeff Chua]

On Thu, Jun 25, 2015 at 12:28 AM, Greg Kroah-Hartman
 wrote:
> On Thu, Jun 25, 2015 at 12:22:47AM +0800, Jeff Chua wrote:

>> Both sda and sdb have the same SSD model.
>
> That's a bug in your USB bridge chip, odds are it is not reporting the
> value properly.  There's nothing the scsi core or USB stack can do about
> this, sorry.  Please complain to the hardware manufacturer.

There are workaround boot cmdline parameters for other things ... any
chance to consider  one to fix broken rotational option? I'm not sure
how many out there are broken, but I really would like a faster way to
access my USB SSD without waiting for the "disk spinup".

Thanks,
Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Stop SSD from waiting for "Spinning up disk..."

[Jeff Chua]

On Wed, Jun 24, 2015 at 2:55 AM, Martin Steigerwald  wrote:
> Am Dienstag, 23. Juni 2015, 20:26:12 schriebst Du:
>> Hi,
>
> Hi,
>
>> [proper In-Reply-To trail missing since lkml.org now fails to provide it]
> […]
>> > Greg,
>> >
>> > SSD is coming mainstream and it doesn't make sense wasting time
>> > spinning up "disk" ...
>>
>> ...which probably is not truly being achieved
>> by providing a *custom* kernel parameter
>> which does apply to only those disk instances
>> which some users *specifically* care about.
>>
>> Some things come to mind:
>>
>> - at this scope, generally spoken
>>   one shouldn't be concerned with whether "we are SSD",
>>   but rather whether "we (do not) need spinup"
>>   (which might apply to a ton of different SCSI-based storage devices,
>>   even some SAN-based platter-based ones)
>>   *This* is what this is about
>>   (and this could then have been reflected in kernel parameter naming)
> […]
>> - the kernel must already have some mechanisms to discern between
>> (non-)platters (e.g. perhaps for knowing whether to support SSD TRIM
>> command)
>
> Yep, for the first SSD in this laptop:
>
> merkaba:/sys> cat
> ./devices/pci:00/:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda/queue/rotational
> 0


It seems "rotational" is not reporting the correct status on USB devices ...

# cat 
/sys/devices/pci:00/:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/queue/rotational
0
# cat 
sys/devices/pci:00/:00:14.0/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/block/sdb/queue/rotational
1

# dmesg
scsi host11: uas
scsi 10:0:0:0: Direct-Access JMicron  Generic  0114 PQ: 0 ANSI: 6

# cat /sys/kernel/debug/usb/devices
T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  4 Spd=5000 MxCh= 0
D:  Ver= 3.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=152d ProdID=0567 Rev= 1.14
S:  Manufacturer=JMicron
S:  Product=USB to ATA/ATAPI Bridge
S:  SerialNumber=3186E514500030
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  8mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=uas


Both sda and sdb have the same SSD model.


Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Stop SSD from waiting for Spinning up disk...

[Jeff Chua]

On Thu, Jun 25, 2015 at 12:28 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
 On Thu, Jun 25, 2015 at 12:22:47AM +0800, Jeff Chua wrote:

 Both sda and sdb have the same SSD model.

 That's a bug in your USB bridge chip, odds are it is not reporting the
 value properly.  There's nothing the scsi core or USB stack can do about
 this, sorry.  Please complain to the hardware manufacturer.

There are workaround boot cmdline parameters for other things ... any
chance to consider  one to fix broken rotational option? I'm not sure
how many out there are broken, but I really would like a faster way to
access my USB SSD without waiting for the disk spinup.

Thanks,
Jeff.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Stop SSD from waiting for Spinning up disk...

[Jeff Chua]

On Wed, Jun 24, 2015 at 2:55 AM, Martin Steigerwald mar...@lichtvoll.de wrote:
 Am Dienstag, 23. Juni 2015, 20:26:12 schriebst Du:
 Hi,

 Hi,

 [proper In-Reply-To trail missing since lkml.org now fails to provide it]
 […]
  Greg,
 
  SSD is coming mainstream and it doesn't make sense wasting time
  spinning up disk ...

 ...which probably is not truly being achieved
 by providing a *custom* kernel parameter
 which does apply to only those disk instances
 which some users *specifically* care about.

 Some things come to mind:

 - at this scope, generally spoken
   one shouldn't be concerned with whether we are SSD,
   but rather whether we (do not) need spinup
   (which might apply to a ton of different SCSI-based storage devices,
   even some SAN-based platter-based ones)
   *This* is what this is about
   (and this could then have been reflected in kernel parameter naming)
 […]
 - the kernel must already have some mechanisms to discern between
 (non-)platters (e.g. perhaps for knowing whether to support SSD TRIM
 command)

 Yep, for the first SSD in this laptop:

 merkaba:/sys cat
 ./devices/pci:00/:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sda/queue/rotational
 0


It seems rotational is not reporting the correct status on USB devices ...

# cat 
/sys/devices/pci:00/:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/queue/rotational
0
# cat 
sys/devices/pci:00/:00:14.0/usb2/2-1/2-1:1.0/host10/target10:0:0/10:0:0:0/block/sdb/queue/rotational
1

# dmesg
scsi host11: uas
scsi 10:0:0:0: Direct-Access JMicron  Generic  0114 PQ: 0 ANSI: 6

# cat /sys/kernel/debug/usb/devices
T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  4 Spd=5000 MxCh= 0
D:  Ver= 3.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=152d ProdID=0567 Rev= 1.14
S:  Manufacturer=JMicron
S:  Product=USB to ATA/ATAPI Bridge
S:  SerialNumber=3186E514500030
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  8mA
I:  If#= 0 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=uas


Both sda and sdb have the same SSD model.


Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Stop SSD from waiting for "Spinning up disk..."

[Jeff Chua]

On Mon, Jun 22, 2015 at 11:36 PM, Greg Kroah-Hartman
 wrote:
> On Mon, Jun 22, 2015 at 03:25:29PM +0800, Jeff Chua wrote:
>>
>> There's no need to wait for disk spin-up for USB SSD devices. This patch
>> allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1 during
>> boot-up.
>>
>> If there's a better way to handle this, please share.
>
> Module parameters are never a solution for a device-specific property,
> sorry.

Greg,

SSD is coming mainstream and it doesn't make sense wasting time
spinning up "disk" ...


Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Stop SSD from waiting for Spinning up disk...

[Jeff Chua]

On Mon, Jun 22, 2015 at 11:36 PM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
 On Mon, Jun 22, 2015 at 03:25:29PM +0800, Jeff Chua wrote:

 There's no need to wait for disk spin-up for USB SSD devices. This patch
 allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1 during
 boot-up.

 If there's a better way to handle this, please share.

 Module parameters are never a solution for a device-specific property,
 sorry.

Greg,

SSD is coming mainstream and it doesn't make sense wasting time
spinning up disk ...


Jeff.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Stop SSD from waiting for "Spinning up disk..."

[Jeff Chua]

There's no need to wait for disk spin-up for USB SSD devices. This 
patch allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1 
during boot-up.


If there's a better way to handle this, please share.


Thanks,
Jeff

--- linux/drivers/scsi/sd.c 2015-05-25 07:29:44.0 +0800
+++ linux/drivers/scsi/sd.c 2015-06-19 22:17:35.0 +0800
@@ -92,6 +92,9 @@
MODULE_ALIAS_SCSI_DEVICE(TYPE_MOD);
MODULE_ALIAS_SCSI_DEVICE(TYPE_RBC);

+static int ssd = 0;
+module_param(ssd, int, 0);
+
#if !defined(CONFIG_DEBUG_BLOCK_EXT_DEVT)
#define SD_MINORS   16
#else
@@ -2738,7 +2741,9 @@
goto out;
}

-   sd_spinup_disk(sdkp);
+   sd_printk(KERN_NOTICE, sdkp, "ssd %s\n", ssd == 0 ? "off" : "on");
+   if(!ssd)
+   sd_spinup_disk(sdkp);

/*
 * Without media there is no reason to ask; moreover, some devices
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Please read the FAQ at  http://www.tux.org/lkml/

Stop SSD from waiting for Spinning up disk...

[Jeff Chua]

There's no need to wait for disk spin-up for USB SSD devices. This 
patch allow the SSD to skip waiting disk spin-up by passing sd_mod.ssd=1 
during boot-up.


If there's a better way to handle this, please share.


Thanks,
Jeff

--- linux/drivers/scsi/sd.c 2015-05-25 07:29:44.0 +0800
+++ linux/drivers/scsi/sd.c 2015-06-19 22:17:35.0 +0800
@@ -92,6 +92,9 @@
MODULE_ALIAS_SCSI_DEVICE(TYPE_MOD);
MODULE_ALIAS_SCSI_DEVICE(TYPE_RBC);

+static int ssd = 0;
+module_param(ssd, int, 0);
+
#if !defined(CONFIG_DEBUG_BLOCK_EXT_DEVT)
#define SD_MINORS   16
#else
@@ -2738,7 +2741,9 @@
goto out;
}

-   sd_spinup_disk(sdkp);
+   sd_printk(KERN_NOTICE, sdkp, ssd %s\n, ssd == 0 ? off : on);
+   if(!ssd)
+   sd_spinup_disk(sdkp);

/*
 * Without media there is no reason to ask; moreover, some devices
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
Please read the FAQ at  http://www.tux.org/lkml/

Re: frequent lockups in 3.18rc4

[Jeff Chua]

I started seeing this behavior somewhere around 3.16 with
CONFIG_PREEMPT set. Setting CONFIG_PREEMPT off seems to help. And,
yes, it happens on high load (compiling mozilla, xul) and using qemu
chroot to compile mesa.

I'm seeing a few persons bisecting already. If you want, I could start
bisecting too, but 3.16 was unstable for me as I'm still on reiserfs.

Jeff.



On Sat, Dec 13, 2014 at 8:44 AM, Linus Torvalds
 wrote:
> On Fri, Dec 12, 2014 at 4:34 PM, Sasha Levin  wrote:
>>
>> Right, it's virtio-9p. However, virtio-9p acts merely as a proxy to an 
>> underlying
>> tmpfs - so while it's slow, I don't think it's way slower than the average 
>> disk
>> backed ext4.
>
> I was thinking more in the sense of "how much of the trouble is about
> something like tmpfs eating tons of memory when trinity starts doing
> random system calls on those files".
>
> I was also thinking that some of it might be filesystem-specific. We
> already *did* see one trace where it was in the loop getting virtio
> channel data. Maybe it's actually possible to overwhelm the 9p
> filesystem exactly because the backing store is tmpfs, and basically
> have a CPU 100% busy handling ring events from the virtual
> filesystem..
>
> But I'm just flailing..
>
>  Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: frequent lockups in 3.18rc4

[Jeff Chua]

I started seeing this behavior somewhere around 3.16 with
CONFIG_PREEMPT set. Setting CONFIG_PREEMPT off seems to help. And,
yes, it happens on high load (compiling mozilla, xul) and using qemu
chroot to compile mesa.

I'm seeing a few persons bisecting already. If you want, I could start
bisecting too, but 3.16 was unstable for me as I'm still on reiserfs.

Jeff.



On Sat, Dec 13, 2014 at 8:44 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Fri, Dec 12, 2014 at 4:34 PM, Sasha Levin sasha.le...@oracle.com wrote:

 Right, it's virtio-9p. However, virtio-9p acts merely as a proxy to an 
 underlying
 tmpfs - so while it's slow, I don't think it's way slower than the average 
 disk
 backed ext4.

 I was thinking more in the sense of how much of the trouble is about
 something like tmpfs eating tons of memory when trinity starts doing
 random system calls on those files.

 I was also thinking that some of it might be filesystem-specific. We
 already *did* see one trace where it was in the loop getting virtio
 channel data. Maybe it's actually possible to overwhelm the 9p
 filesystem exactly because the backing store is tmpfs, and basically
 have a CPU 100% busy handling ring events from the virtual
 filesystem..

 But I'm just flailing..

  Linus
 --
 To unsubscribe from this list: send the line unsubscribe linux-kernel in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Regression] 3.15 mmc related ext4 corruption with qemu-system-arm

[Jeff Chua]

On Fri, Jun 13, 2014 at 8:28 PM, Ulf Hansson  wrote:
> On 13 June 2014 01:51, John Stultz  wrote:
>> On Wed, Jun 11, 2014 at 10:35 PM, John Stultz john.stu...@linaro.org> wrote:

> I have quickly implemented my proposal 1). I am testing them on real
> HW now, will post the patches as soon as I can and keep you on cc.
>
> I would also really appreciate if you could help out giving them a
> quick try for your QEMU environment.

Please cc me the patch. I'm seeing my host's reiserfs corrupted with
qemu all over the places in linux-3.15.0 (linux-3.16-rc1). Pretty sure
it's qemu as it doesn't seem to happen if I don't run qemu.

Thanks,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Regression] 3.15 mmc related ext4 corruption with qemu-system-arm

[Jeff Chua]

On Fri, Jun 13, 2014 at 8:28 PM, Ulf Hansson ulf.hans...@linaro.org wrote:
 On 13 June 2014 01:51, John Stultz john.stu...@linaro.org wrote:
 On Wed, Jun 11, 2014 at 10:35 PM, John Stultz john.stu...@linaro.org wrote:

 I have quickly implemented my proposal 1). I am testing them on real
 HW now, will post the patches as soon as I can and keep you on cc.

 I would also really appreciate if you could help out giving them a
 quick try for your QEMU environment.

Please cc me the patch. I'm seeing my host's reiserfs corrupted with
qemu all over the places in linux-3.15.0 (linux-3.16-rc1). Pretty sure
it's qemu as it doesn't seem to happen if I don't run qemu.

Thanks,
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

HCI_AUTO_OFF ... how to do that from hcitool?

[Jeff Chua]

commit ab81cbf99c881ca2b9a83682a8722fc84b2483d2
Author: Johan Hedberg 
Date:   Wed Dec 15 13:53:18 2010 +0200

Bluetooth: Implement automatic setup procedure for local adapters

A new HCI_AUTO_OFF flag is added that user space needs to clear to
avoid the automatic power off


Help, how do I clear the HCI_AUTO_OFF flag using "hcitool cmd" ?

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

HCI_AUTO_OFF ... how to do that from hcitool?

[Jeff Chua]

commit ab81cbf99c881ca2b9a83682a8722fc84b2483d2
Author: Johan Hedberg johan.hedb...@nokia.com
Date:   Wed Dec 15 13:53:18 2010 +0200

Bluetooth: Implement automatic setup procedure for local adapters

A new HCI_AUTO_OFF flag is added that user space needs to clear to
avoid the automatic power off


Help, how do I clear the HCI_AUTO_OFF flag using hcitool cmd ?

Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Lenovo X240 (haswell) suspend-to-ram hangs on 3-14.0-rc2

[Jeff Chua]

Here's my .config  ...


On Wed, Feb 19, 2014 at 5:32 AM, Theodore Ts'o  wrote:
> On Tue, Feb 18, 2014 at 09:28:02PM +0100, Takashi Iwai wrote:
>>
>> I checked CONFIG_SND_HDA_INTEL=y on my HP laptop with Haswell, but it
>> worked fine.  Could you give config?
>
> I don't have that config any more.  But I started with my the 3.14-rc3
> config, turned off changed CONFIG_SND_HDA_INTEL to be =y, and then ran
> "make oldconfig ; make deb-pkg".  See attached
>
> - Ted
>


config.gz
Description: GNU Zip compressed data

Re: Lenovo X240 (haswell) suspend-to-ram hangs on 3-14.0-rc2

[Jeff Chua]

Here's my .config  ...


On Wed, Feb 19, 2014 at 5:32 AM, Theodore Ts'o ty...@mit.edu wrote:
 On Tue, Feb 18, 2014 at 09:28:02PM +0100, Takashi Iwai wrote:

 I checked CONFIG_SND_HDA_INTEL=y on my HP laptop with Haswell, but it
 worked fine.  Could you give config?

 I don't have that config any more.  But I started with my the 3.14-rc3
 config, turned off changed CONFIG_SND_HDA_INTEL to be =y, and then ran
 make oldconfig ; make deb-pkg.  See attached

 - Ted



config.gz
Description: GNU Zip compressed data

Re: Lenovo X240 (haswell) suspend-to-ram hangs on 3-14.0-rc2

[Jeff Chua]

On Sat, Feb 15, 2014 at 4:07 AM, Takashi Iwai  wrote:

>> # bad
>> CONFIG_SND_HDA_CODEC_HDMI =y
>> CONFIG_SND_HDA_INTEL=y
>> CONFIG_SND_HDA_INPUT_BEEP=y
 CONFIG_SND_HDA_GENERIC=m
>
> It might be the remaining bugs of modularization in 3.14-rc2.
> A few patches are found in for-linus branch of sound git tree, which
> are included in Today's pull request.  Could you give it a try?

Pulled, but still the same. Modularized works fine -- even the modules
remains, s2r works. But setting to "Yes" ... won't suspend. I don't
kow how to capture those errors above the screens :(

Any suggestion on how to debug this? bisect? Ted, does your T540p work
with CONFIG_SND_HDA_INTEL=y instead of "m" ?

Thanks,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Lenovo X240 (haswell) suspend-to-ram hangs on 3-14.0-rc2

[Jeff Chua]

On Sat, Feb 15, 2014 at 4:07 AM, Takashi Iwai ti...@suse.de wrote:

 # bad
 CONFIG_SND_HDA_CODEC_HDMI =y
 CONFIG_SND_HDA_INTEL=y
 CONFIG_SND_HDA_INPUT_BEEP=y
 CONFIG_SND_HDA_GENERIC=m

 It might be the remaining bugs of modularization in 3.14-rc2.
 A few patches are found in for-linus branch of sound git tree, which
 are included in Today's pull request.  Could you give it a try?

Pulled, but still the same. Modularized works fine -- even the modules
remains, s2r works. But setting to Yes ... won't suspend. I don't
kow how to capture those errors above the screens :(

Any suggestion on how to debug this? bisect? Ted, does your T540p work
with CONFIG_SND_HDA_INTEL=y instead of m ?

Thanks,
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Lenovo X240 (haswell) suspend-to-ram hangs on 3-14.0-rc2

[Jeff Chua]

On Fri, Feb 14, 2014 at 9:57 PM, Takashi Iwai  wrote:
> The other possible change in hda_intel.c is the enablement of runtime
> PM for Panther Point.  But it's been working for other chips, so
> wondering why it hits anything.  In anyway, please give the full
> Oops messages not only the stack trace.

> Any difference in the sound hardware, i.e. PCI controller and codec
> chips?

# X230 reported the sound card as:
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset
Family High Definition Audio Controller (rev 04)
== HDA Intel PCH, ALC269VC Analog

# X240 reported the sound card as:
00:1b.0 Audio device: Intel Corporation Lynx Point-LP HD Audio
Controller (rev 04)
==  HDA Intel PCH, ALC292 Analog

Now I managed to make suspend-to-ram work by using sound as module
instead of build-in.

Here's the difference ...

# bad
CONFIG_SND_HDA_CODEC_HDMI =y
CONFIG_SND_HDA_INTEL=y
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_CODEC_HDMI=y
CONFIG_SND_HDA_GENERIC=y


# good
CONFIG_SND_HDA_CODEC_HDMI =m
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDA_INPUT_BEEP=m
CONFIG_SND_HDA_CODEC_HDMI=m
CONFIG_SND_HDA_GENERIC=m


Strange?

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Lenovo X240 (haswell) suspend-to-ram hangs on 3-14.0-rc2

[Jeff Chua]

On Fri, Feb 14, 2014 at 1:28 AM, Takashi Iwai  wrote:
> At Thu, 13 Feb 2014 12:14:58 -0500,  Peter Hurley wrote:
> Apparently there's no maintainer but I've cc'ed people who might
> have a clue about this.

Peter ... thanks for pointer.

> On Fri, Feb 14, 2014 at 1:28 AM, Takashi Iwai  wrote:
> Is it a Intel+Nvidia hybrid?  If so, does it happen even with
> CONFIG_VGA_SWITCHEROO=n?

It's not Intel+Nvidia. It's Intel Core i7-4600U 2.1 GHz, Intel HD Graphics 4400.

I checked my config. CONFIG_VGA_SWITCHEROO is not set.

On Fri, Feb 14, 2014 at 5:21 AM, Theodore Ts'o  wrote:
> For what it's worth, I have a the X240's bigger brother --- a T540p
> (with intel graphics and the 3k panel) running 3.14-rc2, and
> suspend-to-ram is working without any problems on my laptop.

Interesting. Perhaps it's the USB options. I had these set to "y"

CONFIG_USB_XHCI_HCD=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=y

Again, These same config works find on X230. It's very strange. The
same hard disk (SSD) can suspend-to-ram on the X230 but not on the
X240. The X230 has i7-3520M vs X240 i7-4600U.

I've even tried with all the USB set to "n" and still couldn't S2D.
May be the graphic?

Thanks,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Lenovo X240 (haswell) suspend-to-ram hangs on 3-14.0-rc2

[Jeff Chua]

On Fri, Feb 14, 2014 at 1:28 AM, Takashi Iwai ti...@suse.de wrote:
 At Thu, 13 Feb 2014 12:14:58 -0500,  Peter Hurley wrote:
 Apparently there's no maintainer but I've cc'ed people who might
 have a clue about this.

Peter ... thanks for pointer.

 On Fri, Feb 14, 2014 at 1:28 AM, Takashi Iwai ti...@suse.de wrote:
 Is it a Intel+Nvidia hybrid?  If so, does it happen even with
 CONFIG_VGA_SWITCHEROO=n?

It's not Intel+Nvidia. It's Intel Core i7-4600U 2.1 GHz, Intel HD Graphics 4400.

I checked my config. CONFIG_VGA_SWITCHEROO is not set.

On Fri, Feb 14, 2014 at 5:21 AM, Theodore Ts'o ty...@mit.edu wrote:
 For what it's worth, I have a the X240's bigger brother --- a T540p
 (with intel graphics and the 3k panel) running 3.14-rc2, and
 suspend-to-ram is working without any problems on my laptop.

Interesting. Perhaps it's the USB options. I had these set to y

CONFIG_USB_XHCI_HCD=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=y

Again, These same config works find on X230. It's very strange. The
same hard disk (SSD) can suspend-to-ram on the X230 but not on the
X240. The X230 has i7-3520M vs X240 i7-4600U.

I've even tried with all the USB set to n and still couldn't S2D.
May be the graphic?

Thanks,
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Lenovo X240 (haswell) suspend-to-ram hangs on 3-14.0-rc2

[Jeff Chua]

On Fri, Feb 14, 2014 at 9:57 PM, Takashi Iwai ti...@suse.de wrote:
 The other possible change in hda_intel.c is the enablement of runtime
 PM for Panther Point.  But it's been working for other chips, so
 wondering why it hits anything.  In anyway, please give the full
 Oops messages not only the stack trace.

 Any difference in the sound hardware, i.e. PCI controller and codec
 chips?

# X230 reported the sound card as:
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset
Family High Definition Audio Controller (rev 04)
== HDA Intel PCH, ALC269VC Analog

# X240 reported the sound card as:
00:1b.0 Audio device: Intel Corporation Lynx Point-LP HD Audio
Controller (rev 04)
==  HDA Intel PCH, ALC292 Analog

Now I managed to make suspend-to-ram work by using sound as module
instead of build-in.

Here's the difference ...

# bad
CONFIG_SND_HDA_CODEC_HDMI =y
CONFIG_SND_HDA_INTEL=y
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_CODEC_HDMI=y
CONFIG_SND_HDA_GENERIC=y


# good
CONFIG_SND_HDA_CODEC_HDMI =m
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDA_INPUT_BEEP=m
CONFIG_SND_HDA_CODEC_HDMI=m
CONFIG_SND_HDA_GENERIC=m


Strange?

Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Lenovo X240 (haswell) suspend-to-ram hangs on 3-14.0-rc2

[Jeff Chua]

Can't suspend to ram/disk on the Lenovo X240 with Intel i7-4600.

kernel 3.14.0-rc2

The same kernel works find on Lenovo X230 with Intel i7-3520M.

Here's the trace ..


[] ? do_exit+0x852/0x89d
[] ? prinfk+0x4f/0x54
[] ? oops_end+0x78/0x7d
[] ? no_context+0x1e6/0x1f5
[] ? __do_page_fault+0x348/0x3c7
[] ? __schedule+0x6Z3/0x775
[] ? page_fault+0x2Z/8x30
[] ? azx_enter_link_reset.isra.26+0x9/0x51
[] ? azx_clear_irq_pending+0x12/0x3e
[1 ? azx_suspend+0xa1/0x105
[] ? pci_pm_suspend+0x6e/0xee
[] ? pci_pm_poweroff+0xb4/0xb4
[] ? dpm_run_callback.isra.8+0x24/8x52
[] ? __device_suspend+8x138/0x19b
[] ? async_suspend+0x16/0x7d
[] ? async_run_entry_fn+0x55/0x10b
[] ? process_one_work+0x1be/0x2ef
[] ? worker_thread+0x1cb/0x2c4
[] ? rescuer_thread+0x25d/0x25d
[] ? kthread+0xc5/0xcd
[] ? SyS_setpriority+0x179/0x233
[l ? kthread_freezable_should_stop+0x3b/0x3b
[] ? rat_from_fork+0x7c/0xb0
[l ? kthread_freezable_should_stop+0x3b/0x3b


Thanks,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Lenovo X240 (haswell) suspend-to-ram hangs on 3-14.0-rc2

[Jeff Chua]

Can't suspend to ram/disk on the Lenovo X240 with Intel i7-4600.

kernel 3.14.0-rc2

The same kernel works find on Lenovo X230 with Intel i7-3520M.

Here's the trace ..


[81034ba6] ? do_exit+0x852/0x89d
[8158e5d8] ? prinfk+0x4f/0x54
[iiff81005060] ? oops_end+0x78/0x7d
[8158dc00] ? no_context+0x1e6/0x1f5
[810274f8] ? __do_page_fault+0x348/0x3c7
[8159376a] ? __schedule+0x6Z3/0x775
[81596562] ? page_fault+0x2Z/8x30
[814e76e4] ? azx_enter_link_reset.isra.26+0x9/0x51
[814e68ac] ? azx_clear_irq_pending+0x12/0x3e
[814e78211 ? azx_suspend+0xa1/0x105
[8128f543] ? pci_pm_suspend+0x6e/0xee
[8128f4d5] ? pci_pm_poweroff+0xb4/0xb4
[81333479] ? dpm_run_callback.isra.8+0x24/8x52
[813335df] ? __device_suspend+8x138/0x19b
[81333658] ? async_suspend+0x16/0x7d
[8104d743] ? async_run_entry_fn+0x55/0x10b
[81044abf] ? process_one_work+0x1be/0x2ef
[8104503d] ? worker_thread+0x1cb/0x2c4
[81044e72] ? rescuer_thread+0x25d/0x25d
[81049a93] ? kthread+0xc5/0xcd
[8104] ? SyS_setpriority+0x179/0x233
[810499cel ? kthread_freezable_should_stop+0x3b/0x3b
[8159697c] ? rat_from_fork+0x7c/0xb0
[810499cel ? kthread_freezable_should_stop+0x3b/0x3b


Thanks,
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: binfmt_misc broken

[Jeff Chua]

On Tue, Jun 11, 2013 at 9:51 AM, Al Viro  wrote:


> Patch is complete BS and I really wonder what kernel have you observed that 
> bug on -
> with mainline on amd64 your example yields
> root@kvm-amd64:~# cat /proc/sys/fs/binfmt_misc/arm
> enabled
> interpreter /usr/bin/qemu-arm-static
> flags:
> offset 0
> magic 7f454c460101010002002800
> mask ff00feff
>
> A reproducer, please...  As for the memcmp() Linus has suggested - it's 
> !Magic case, i.e.
> what we are comparing there is not the file contents, it's the extension.  
> IOW, strcmp()
> is the right thing to use there - pathnames do not contain NULs in the 
> middle...

BS ... yes, after testing it again, you may be right. Not intented, sorry.

I did another test with bash.

# bash -version
GNU bash, version 4.2.45(2)-release (x86_64-unknown-linux-gnu)

# echo 
':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:'
:arm:M::ELF(:ÿÿÿþÿÿÿ:/usr/bin/qemu-arm-static:

# echo 
':arm:M::\\x7fELF\\x01\\x01\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x02\\x00\\x28\\x00:\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\x00\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xfe\\xff\\xff\\xff:/usr/bin/qemu-arm-static:'
:arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:

I supposed it's my bash configured with opt_xpg_echo=yes that's
sending in different data to the kernel.

Sending in the double-escape solved the problem. BS totally! My fault.

Thanks,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

binfmt_misc broken

[Jeff Chua]

According to Documentation/binfmt_misc.txt, the 'magic' and 'mask' can be 
set by echoing it to /proc/sys/fs/binfmt_misc/register.


Here's the problem I can across while working on ARM.

# echo 
':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:' 

/proc/sys/fs/binfmt_misc/register


# cat /proc/sys/fs/binfmt_misc/arm
wrong ...
magic 7f454c46010101
mask ff

right ...
magic 7f454c460101010002002800
mask ff00feff


binfmt_misc is truncating e->size, so once ARM's magic is loaded, 32-bit 
x86 can no longer run.


Here's a patch for it. It's looking for the delimiter ":" instead of \0. 
Now 32-bit x86 can run concurrent while qemu-arm is handling ARM's magic.


Thanks,
Jeff


--- linux/fs/binfmt_misc.c  2013-05-01 12:59:39.0 +0800
+++ linux/fs/binfmt_misc.c  2013-06-10 21:29:45.0 +0800
@@ -276,6 +276,7 @@
int memsize, err;
char *buf, *p;
char del;
+   int esize = 0;

/* some sanity checks */
err = -EINVAL;
@@ -323,6 +324,15 @@
e->offset = simple_strtoul(p, , 10);
if (*p++)
goto Einval;
+
+   while(*(p + esize) != ':' && esize < BINPRM_BUF_SIZE) {
+   if(*(p + esize) == '\\' && *(p + esize + 1) == 'x') {
+   esize +=3;
+   } else
+   esize++;
+   }
+   e->size = esize;
+
e->magic = p;
p = scanarg(p, del);
if (!p)
@@ -337,10 +347,6 @@
p[-1] = '\0';
if (!e->mask[0])
e->mask = NULL;
-   e->size = string_unescape_inplace(e->magic, UNESCAPE_HEX);
-   if (e->mask &&
-   string_unescape_inplace(e->mask, UNESCAPE_HEX) != e->size)
-   goto Einval;
if (e->size + e->offset > BINPRM_BUF_SIZE)
goto Einval;
} else {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

binfmt_misc broken

[Jeff Chua]

According to Documentation/binfmt_misc.txt, the 'magic' and 'mask' can be 
set by echoing it to /proc/sys/fs/binfmt_misc/register.


Here's the problem I can across while working on ARM.

# echo 
':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:' 

/proc/sys/fs/binfmt_misc/register


# cat /proc/sys/fs/binfmt_misc/arm
wrong ...
magic 7f454c46010101
mask ff

right ...
magic 7f454c460101010002002800
mask ff00feff


binfmt_misc is truncating e-size, so once ARM's magic is loaded, 32-bit 
x86 can no longer run.


Here's a patch for it. It's looking for the delimiter : instead of \0. 
Now 32-bit x86 can run concurrent while qemu-arm is handling ARM's magic.


Thanks,
Jeff


--- linux/fs/binfmt_misc.c  2013-05-01 12:59:39.0 +0800
+++ linux/fs/binfmt_misc.c  2013-06-10 21:29:45.0 +0800
@@ -276,6 +276,7 @@
int memsize, err;
char *buf, *p;
char del;
+   int esize = 0;

/* some sanity checks */
err = -EINVAL;
@@ -323,6 +324,15 @@
e-offset = simple_strtoul(p, p, 10);
if (*p++)
goto Einval;
+
+   while(*(p + esize) != ':'  esize  BINPRM_BUF_SIZE) {
+   if(*(p + esize) == '\\'  *(p + esize + 1) == 'x') {
+   esize +=3;
+   } else
+   esize++;
+   }
+   e-size = esize;
+
e-magic = p;
p = scanarg(p, del);
if (!p)
@@ -337,10 +347,6 @@
p[-1] = '\0';
if (!e-mask[0])
e-mask = NULL;
-   e-size = string_unescape_inplace(e-magic, UNESCAPE_HEX);
-   if (e-mask 
-   string_unescape_inplace(e-mask, UNESCAPE_HEX) != e-size)
-   goto Einval;
if (e-size + e-offset  BINPRM_BUF_SIZE)
goto Einval;
} else {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: binfmt_misc broken

[Jeff Chua]

On Tue, Jun 11, 2013 at 9:51 AM, Al Viro v...@zeniv.linux.org.uk wrote:


 Patch is complete BS and I really wonder what kernel have you observed that 
 bug on -
 with mainline on amd64 your example yields
 root@kvm-amd64:~# cat /proc/sys/fs/binfmt_misc/arm
 enabled
 interpreter /usr/bin/qemu-arm-static
 flags:
 offset 0
 magic 7f454c460101010002002800
 mask ff00feff

 A reproducer, please...  As for the memcmp() Linus has suggested - it's 
 !Magic case, i.e.
 what we are comparing there is not the file contents, it's the extension.  
 IOW, strcmp()
 is the right thing to use there - pathnames do not contain NULs in the 
 middle...

BS ... yes, after testing it again, you may be right. Not intented, sorry.

I did another test with bash.

# bash -version
GNU bash, version 4.2.45(2)-release (x86_64-unknown-linux-gnu)

# echo 
':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:'
:arm:M::ELF(:ÿÿÿþÿÿÿ:/usr/bin/qemu-arm-static:

# echo 
':arm:M::\\x7fELF\\x01\\x01\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x02\\x00\\x28\\x00:\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\x00\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xfe\\xff\\xff\\xff:/usr/bin/qemu-arm-static:'
:arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:

I supposed it's my bash configured with opt_xpg_echo=yes that's
sending in different data to the kernel.

Sending in the double-escape solved the problem. BS totally! My fault.

Thanks,
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-3.10-rc1 procfs interface breaks vmware, eicon, fio .... any fix?

[Jeff Chua]

> And now you have a chutzpah to come and
complain about that? Better yet, we are expected to be working on
fixing those?

Al,

Complaining about something that I can't fix, yep. But asking you to
fix those, nop! That's not my intent. All I'm trying to say is there's
too many out there who don't care about linux-next until the vanilla
version came out and then everyone (may be just me) complained that it
doesn't work anymore, So, would it be reasonable to allow the
old-method to still function may be via CONFIG_OLD_PROCFS but warning
that the old interface should not be used anymore. That's to allow
"me" to continue to be able to work on the latest linux-3.10.0-rc1
while waiting for someone to fix those old modules. Reasonable?

Thanks,
Jeff

On Mon, May 13, 2013 at 10:04 AM, Al Viro  wrote:
> On Mon, May 13, 2013 at 08:19:46AM +0800, Jeff Chua wrote:
>> Anyone on lkml working on patches for vmware to make it run on
>> Linux-3.10-rc1? The recent change in procfs interface breaks vmware,
>> diva/eicon and fio modules.
>>
>> Every modules is now broken and needs to be reworked. Is there a more
>> subtle way to handle this like give more time to allow developers to
>> handle the move rather than killing off the "tranditional" procfs
>> access
>
> I might feel bad about those, if not for one thing - their authors
> had explicitly chosen to keep them out of tree and did not bother
> to watch what was going on in linux-next - these changes had been
> there for quite a while.  And now you have a chutzpah to come and
> complain about that?  Better yet, we are expected to be working on
> fixing those?  Really?  It's not a rethorical question - I seriously
> want to know whether I'd misparsed what you meant to say.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-3.10-rc1 procfs interface breaks vmware, eicon, fio .... any fix?

[Jeff Chua]

Anyone on lkml working on patches for vmware to make it run on
Linux-3.10-rc1? The recent change in procfs interface breaks vmware,
diva/eicon and fio modules.

Every modules is now broken and needs to be reworked. Is there a more
subtle way to handle this like give more time to allow developers to
handle the move rather than killing off the "tranditional" procfs
access ... like a warning that the interface is going away soon?


Thanks,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-3.10-rc1 procfs interface breaks vmware, eicon, fio .... any fix?

[Jeff Chua]

Anyone on lkml working on patches for vmware to make it run on
Linux-3.10-rc1? The recent change in procfs interface breaks vmware,
diva/eicon and fio modules.

Every modules is now broken and needs to be reworked. Is there a more
subtle way to handle this like give more time to allow developers to
handle the move rather than killing off the tranditional procfs
access ... like a warning that the interface is going away soon?


Thanks,
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-3.10-rc1 procfs interface breaks vmware, eicon, fio .... any fix?

[Jeff Chua]

 And now you have a chutzpah to come and
complain about that? Better yet, we are expected to be working on
fixing those?

Al,

Complaining about something that I can't fix, yep. But asking you to
fix those, nop! That's not my intent. All I'm trying to say is there's
too many out there who don't care about linux-next until the vanilla
version came out and then everyone (may be just me) complained that it
doesn't work anymore, So, would it be reasonable to allow the
old-method to still function may be via CONFIG_OLD_PROCFS but warning
that the old interface should not be used anymore. That's to allow
me to continue to be able to work on the latest linux-3.10.0-rc1
while waiting for someone to fix those old modules. Reasonable?

Thanks,
Jeff

On Mon, May 13, 2013 at 10:04 AM, Al Viro v...@zeniv.linux.org.uk wrote:
 On Mon, May 13, 2013 at 08:19:46AM +0800, Jeff Chua wrote:
 Anyone on lkml working on patches for vmware to make it run on
 Linux-3.10-rc1? The recent change in procfs interface breaks vmware,
 diva/eicon and fio modules.

 Every modules is now broken and needs to be reworked. Is there a more
 subtle way to handle this like give more time to allow developers to
 handle the move rather than killing off the tranditional procfs
 access

 I might feel bad about those, if not for one thing - their authors
 had explicitly chosen to keep them out of tree and did not bother
 to watch what was going on in linux-next - these changes had been
 there for quite a while.  And now you have a chutzpah to come and
 complain about that?  Better yet, we are expected to be working on
 fixing those?  Really?  It's not a rethorical question - I seriously
 want to know whether I'd misparsed what you meant to say.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2nd attempt: help with dma_alloc_coherent() + dma_free_coherent()

[Jeff Chua]

On Wed, Jan 9, 2013 at 1:24 AM, Linus Torvalds
 wrote:
> On Tue, Jan 8, 2013 at 9:17 AM, Jeff Chua  wrote:
>>
>> Interesting, but there are 54 lines under the kernel directories that
>> use "dma_alloc_coherent(NULL," followed by "dma_free_coherent(NULL,"
>
> As mentioned, it works on some platforms. That doesn't make it right.
>
>> So, shouldn't they be fixed as well? ... unless they are so old that
>> nobody cares anymore ...
>
> Some of the ones I saw are in MIPS or blackfin. Others probably *are*
> so old that nobody cares, and happen to work because there's iommu's
> or other things that simply don't care about the device.
>
>> # find . -exec grep -H "dma_alloc_coherent(NULL" {} \; | wc -l
>> 54
>>
>> #find . -exec grep -H "dma_free_coherent(NULL" {} \; | wc -l
>> 72
>
> Let me tell you about "git grep", so that you never need to do that
> disgusting "find -exec grep" ever again.
>
> It does threading, it's fast, and it just works.
>
> Linus

Yes, "git grep" is really fast. Cool! ... didn't know that before.

Thanks again for the help.

Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2nd attempt: help with dma_alloc_coherent() + dma_free_coherent()

[Jeff Chua]

On Wed, Jan 9, 2013 at 12:39 AM, Linus Torvalds
 wrote:
> On Tue, Jan 8, 2013 at 7:51 AM, Jeff Chua  wrote:
>> No response so far ... I'm sure someone know this stuff ...  Thanks, Jeff.
>>
>> I'm trying to understand how this oops in the diva driver and it's just a
>> simple dma_alloc_coherent() followed by dma_free_coherent(), but it oops.
>> Why?
>
> Umm. You're using a NULL 'dev' pointer?
>
> iommu_no_mapping() will look if the device is a PCI device, and that's
> where it oopses.
>
> Now, it looks like some users "know" that the device doesn't matter
> (which is true on some platforms), but that's bogus. The device is how
> you even find out what the rules for DMA access are (see for example
> dma_set_mask() etc), so giving a NULL device is insane.
>
>   Linus


Interesting, but there are 54 lines under the kernel directories that
use "dma_alloc_coherent(NULL," followed by "dma_free_coherent(NULL,"

So, shouldn't they be fixed as well? ... unless they are so old that
nobody cares anymore ...


# find . -exec grep -H "dma_alloc_coherent(NULL" {} \; | wc -l
54

#find . -exec grep -H "dma_free_coherent(NULL" {} \; | wc -l
72



Thanks,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2nd attempt: help with dma_alloc_coherent() + dma_free_coherent()

[Jeff Chua]

On Wed, Jan 9, 2013 at 12:39 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Tue, Jan 8, 2013 at 7:51 AM, Jeff Chua jeff.chua.li...@gmail.com wrote:
 No response so far ... I'm sure someone know this stuff ...  Thanks, Jeff.

 I'm trying to understand how this oops in the diva driver and it's just a
 simple dma_alloc_coherent() followed by dma_free_coherent(), but it oops.
 Why?

 Umm. You're using a NULL 'dev' pointer?

 iommu_no_mapping() will look if the device is a PCI device, and that's
 where it oopses.

 Now, it looks like some users know that the device doesn't matter
 (which is true on some platforms), but that's bogus. The device is how
 you even find out what the rules for DMA access are (see for example
 dma_set_mask() etc), so giving a NULL device is insane.

   Linus


Interesting, but there are 54 lines under the kernel directories that
use dma_alloc_coherent(NULL, followed by dma_free_coherent(NULL,

So, shouldn't they be fixed as well? ... unless they are so old that
nobody cares anymore ...


# find . -exec grep -H dma_alloc_coherent(NULL {} \; | wc -l
54

#find . -exec grep -H dma_free_coherent(NULL {} \; | wc -l
72



Thanks,
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2nd attempt: help with dma_alloc_coherent() + dma_free_coherent()

[Jeff Chua]

On Wed, Jan 9, 2013 at 1:24 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
 On Tue, Jan 8, 2013 at 9:17 AM, Jeff Chua jeff.chua.li...@gmail.com wrote:

 Interesting, but there are 54 lines under the kernel directories that
 use dma_alloc_coherent(NULL, followed by dma_free_coherent(NULL,

 As mentioned, it works on some platforms. That doesn't make it right.

 So, shouldn't they be fixed as well? ... unless they are so old that
 nobody cares anymore ...

 Some of the ones I saw are in MIPS or blackfin. Others probably *are*
 so old that nobody cares, and happen to work because there's iommu's
 or other things that simply don't care about the device.

 # find . -exec grep -H dma_alloc_coherent(NULL {} \; | wc -l
 54

 #find . -exec grep -H dma_free_coherent(NULL {} \; | wc -l
 72

 Let me tell you about git grep, so that you never need to do that
 disgusting find -exec grep ever again.

 It does threading, it's fast, and it just works.

 Linus

Yes, git grep is really fast. Cool! ... didn't know that before.

Thanks again for the help.

Jeff.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /usr/include/linux/errno.h:1:23: fatal error: asm/errno.h: No such file or directory

[Jeff Chua]

On Sun, Dec 16, 2012 at 9:53 AM, Al Viro  wrote:
> On Sun, Dec 16, 2012 at 09:39:01AM +0800, Jeff Chua wrote:
>> On Sun, Dec 16, 2012 at 9:28 AM, Al Viro  wrote:
>> > On Sun, Dec 16, 2012 at 09:23:38AM +0800, Jeff Chua wrote:
>> >> How should the symbolic links be setup to compile the latest kernel?
>> >>
>> >>
>> >> Currently I had these links and kernels compiled fine until 2 days ago.
>> >>
>> >>  asm -> /usr/src/linux/include/uapi/asm-generic/
>> >>  asm-generic -> /usr/src/linux/include/uapi/asm-generic
>> >>  linux -> /usr/src/linux/include/uapi/linux
>> >
>> > What symlinks?  /usr/include/* should not contain any symlinks into
>> > the kernel source.  At all.
>>
>> Al,
>>
>> Oh, perhaps I'm having the right setup. Where should I get the kernel
>> headers.
>
> From your libc.  Which ought to have its own copies, normally coming from
> make headers_install in kernel source.  And yes, it had been that way
> for many years by now.  Userland should *not* blindly grab the kernel
> headers.
>
> Incidentally, your 'asm' is obviously bogus - the headers that should end
> up there ought to come from arch//include/uapi/asm (and _not_
> by pointing a symlink to it); yours points to the place where asm-generic
> ones ought to have been copied from.

Al,

Thanks for the pointers. Will try as what you suggested:)

Merry Christmas.

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /usr/include/linux/errno.h:1:23: fatal error: asm/errno.h: No such file or directory

[Jeff Chua]

On Sun, Dec 16, 2012 at 9:39 AM, Jeff Chua  wrote:
> On Sun, Dec 16, 2012 at 9:28 AM, Al Viro  wrote:
>> On Sun, Dec 16, 2012 at 09:23:38AM +0800, Jeff Chua wrote:
>>> How should the symbolic links be setup to compile the latest kernel?
>>>
>>>
>>> Currently I had these links and kernels compiled fine until 2 days ago.
>>>
>>>  asm -> /usr/src/linux/include/uapi/asm-generic/
>>>  asm-generic -> /usr/src/linux/include/uapi/asm-generic
>>>  linux -> /usr/src/linux/include/uapi/linux
>>
>> What symlinks?  /usr/include/* should not contain any symlinks into
>> the kernel source.  At all.
>
> Al,
>
> Oh, perhaps I'm having the right setup. Where should I get the kernel
> headers. After removing the links to the kernel source, here what I
> got ...
>
> make[1]: Nothing to be done for `all'.
>   HOSTCC  scripts/basic/fixdep
> In file included from /usr/include/bits/posix1_lim.h:160:0,
>  from /usr/include/limits.h:144,
>  from scripts/basic/fixdep.c:114:
> /usr/include/bits/local_lim.h:38:26: fatal error: linux/limits.h: No
> such file or directory
> compilation terminated.

> Oh, perhaps I'm having the right setup. Where should I get the kernel

NOT having the right setup.


Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /usr/include/linux/errno.h:1:23: fatal error: asm/errno.h: No such file or directory

[Jeff Chua]

On Sun, Dec 16, 2012 at 9:28 AM, Al Viro  wrote:
> On Sun, Dec 16, 2012 at 09:23:38AM +0800, Jeff Chua wrote:
>> How should the symbolic links be setup to compile the latest kernel?
>>
>>
>> Currently I had these links and kernels compiled fine until 2 days ago.
>>
>>  asm -> /usr/src/linux/include/uapi/asm-generic/
>>  asm-generic -> /usr/src/linux/include/uapi/asm-generic
>>  linux -> /usr/src/linux/include/uapi/linux
>
> What symlinks?  /usr/include/* should not contain any symlinks into
> the kernel source.  At all.

Al,

Oh, perhaps I'm having the right setup. Where should I get the kernel
headers. After removing the links to the kernel source, here what I
got ...

make[1]: Nothing to be done for `all'.
  HOSTCC  scripts/basic/fixdep
In file included from /usr/include/bits/posix1_lim.h:160:0,
 from /usr/include/limits.h:144,
 from scripts/basic/fixdep.c:114:
/usr/include/bits/local_lim.h:38:26: fatal error: linux/limits.h: No
such file or directory
compilation terminated.

Thanks,
Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /usr/include/linux/errno.h:1:23: fatal error: asm/errno.h: No such file or directory

[Jeff Chua]

On Sun, Dec 16, 2012 at 9:28 AM, Al Viro v...@zeniv.linux.org.uk wrote:
 On Sun, Dec 16, 2012 at 09:23:38AM +0800, Jeff Chua wrote:
 How should the symbolic links be setup to compile the latest kernel?


 Currently I had these links and kernels compiled fine until 2 days ago.

  asm - /usr/src/linux/include/uapi/asm-generic/
  asm-generic - /usr/src/linux/include/uapi/asm-generic
  linux - /usr/src/linux/include/uapi/linux

 What symlinks?  /usr/include/* should not contain any symlinks into
 the kernel source.  At all.

Al,

Oh, perhaps I'm having the right setup. Where should I get the kernel
headers. After removing the links to the kernel source, here what I
got ...

make[1]: Nothing to be done for `all'.
  HOSTCC  scripts/basic/fixdep
In file included from /usr/include/bits/posix1_lim.h:160:0,
 from /usr/include/limits.h:144,
 from scripts/basic/fixdep.c:114:
/usr/include/bits/local_lim.h:38:26: fatal error: linux/limits.h: No
such file or directory
compilation terminated.

Thanks,
Jeff.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /usr/include/linux/errno.h:1:23: fatal error: asm/errno.h: No such file or directory

[Jeff Chua]

On Sun, Dec 16, 2012 at 9:39 AM, Jeff Chua jeff.chua.li...@gmail.com wrote:
 On Sun, Dec 16, 2012 at 9:28 AM, Al Viro v...@zeniv.linux.org.uk wrote:
 On Sun, Dec 16, 2012 at 09:23:38AM +0800, Jeff Chua wrote:
 How should the symbolic links be setup to compile the latest kernel?


 Currently I had these links and kernels compiled fine until 2 days ago.

  asm - /usr/src/linux/include/uapi/asm-generic/
  asm-generic - /usr/src/linux/include/uapi/asm-generic
  linux - /usr/src/linux/include/uapi/linux

 What symlinks?  /usr/include/* should not contain any symlinks into
 the kernel source.  At all.

 Al,

 Oh, perhaps I'm having the right setup. Where should I get the kernel
 headers. After removing the links to the kernel source, here what I
 got ...

 make[1]: Nothing to be done for `all'.
   HOSTCC  scripts/basic/fixdep
 In file included from /usr/include/bits/posix1_lim.h:160:0,
  from /usr/include/limits.h:144,
  from scripts/basic/fixdep.c:114:
 /usr/include/bits/local_lim.h:38:26: fatal error: linux/limits.h: No
 such file or directory
 compilation terminated.

 Oh, perhaps I'm having the right setup. Where should I get the kernel

NOT having the right setup.


Jeff.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: /usr/include/linux/errno.h:1:23: fatal error: asm/errno.h: No such file or directory

[Jeff Chua]

On Sun, Dec 16, 2012 at 9:53 AM, Al Viro v...@zeniv.linux.org.uk wrote:
 On Sun, Dec 16, 2012 at 09:39:01AM +0800, Jeff Chua wrote:
 On Sun, Dec 16, 2012 at 9:28 AM, Al Viro v...@zeniv.linux.org.uk wrote:
  On Sun, Dec 16, 2012 at 09:23:38AM +0800, Jeff Chua wrote:
  How should the symbolic links be setup to compile the latest kernel?
 
 
  Currently I had these links and kernels compiled fine until 2 days ago.
 
   asm - /usr/src/linux/include/uapi/asm-generic/
   asm-generic - /usr/src/linux/include/uapi/asm-generic
   linux - /usr/src/linux/include/uapi/linux
 
  What symlinks?  /usr/include/* should not contain any symlinks into
  the kernel source.  At all.

 Al,

 Oh, perhaps I'm having the right setup. Where should I get the kernel
 headers.

 From your libc.  Which ought to have its own copies, normally coming from
 make headers_install in kernel source.  And yes, it had been that way
 for many years by now.  Userland should *not* blindly grab the kernel
 headers.

 Incidentally, your 'asm' is obviously bogus - the headers that should end
 up there ought to come from arch/whatever/include/uapi/asm (and _not_
 by pointing a symlink to it); yours points to the place where asm-generic
 ones ought to have been copied from.

Al,

Thanks for the pointers. Will try as what you suggested:)

Merry Christmas.

Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Introduce a method to catch mmap_region (was: Recent kernel "mount" slow)

[Jeff Chua]

On Thu, Nov 29, 2012 at 2:45 PM, Al Viro  wrote:
> On Wed, Nov 28, 2012 at 10:37:27PM -0800, Linus Torvalds wrote:
>> On Wed, Nov 28, 2012 at 10:30 PM, Al Viro  wrote:
>> >
>> > Note that sync_blockdev() a few lines prior to that is good only if we
>> > have no other processes doing write(2) (or dirtying the mmapped pages,
>> > for that matter).  The window isn't too wide, but...
>>
>> So with Mikulas' patches, the write actually would block (at write
>> level) due to the locking. The mmap'ed patches may be around and
>> flushed, but the logic to not allow currently *active* mmaps (with the
>> rather nasty random -EBUSY return value) should mean that there is no
>> race.
>>
>> Or rather, there's a race, but it results in that EBUSY thing.
>
> Same as with fs mounted on it, or the sucker having been claimed for
> RAID array, etc.  Frankly, I'm more than slightly tempted to make
> bdev mmap() just claim the sodding device exclusive for as long as
> it's mmapped...
>
> In principle, I agree, but...  I still have nightmares from mmap/truncate
> races way back.  You are stepping into what used to be a really nasty
> minefield.  I'll look into that, but it's *definitely* not -rc8 fodder.

Just let me know which relevant patch(es) you want me to test or break.

Thanks,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Introduce a method to catch mmap_region (was: Recent kernel mount slow)

[Jeff Chua]

On Thu, Nov 29, 2012 at 2:45 PM, Al Viro v...@zeniv.linux.org.uk wrote:
 On Wed, Nov 28, 2012 at 10:37:27PM -0800, Linus Torvalds wrote:
 On Wed, Nov 28, 2012 at 10:30 PM, Al Viro v...@zeniv.linux.org.uk wrote:
 
  Note that sync_blockdev() a few lines prior to that is good only if we
  have no other processes doing write(2) (or dirtying the mmapped pages,
  for that matter).  The window isn't too wide, but...

 So with Mikulas' patches, the write actually would block (at write
 level) due to the locking. The mmap'ed patches may be around and
 flushed, but the logic to not allow currently *active* mmaps (with the
 rather nasty random -EBUSY return value) should mean that there is no
 race.

 Or rather, there's a race, but it results in that EBUSY thing.

 Same as with fs mounted on it, or the sucker having been claimed for
 RAID array, etc.  Frankly, I'm more than slightly tempted to make
 bdev mmap() just claim the sodding device exclusive for as long as
 it's mmapped...

 In principle, I agree, but...  I still have nightmares from mmap/truncate
 races way back.  You are stepping into what used to be a really nasty
 minefield.  I'll look into that, but it's *definitely* not -rc8 fodder.

Just let me know which relevant patch(es) you want me to test or break.

Thanks,
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] block_dev: don't take the write lock if block size doesn't change

[Jeff Chua]

On Wed, Nov 28, 2012 at 12:01 PM, Mikulas Patocka  wrote:
> block_dev: don't take the write lock if block size doesn't change
>
> Taking the write lock has a big performance impact on the whole system
> (because of synchronize_sched_expedited). This patch avoids taking the
> write lock if the block size doesn't change (i.e. when mounting
> filesystem with block size equal to the default block size).
>
> The logic to test if the block device is mapped was moved to a separate
> function is_bdev_mapped to avoid code duplication.
>
> Signed-off-by: Mikulas Patocka 
>
> ---
>  fs/block_dev.c |   25 ++---
>  1 file changed, 18 insertions(+), 7 deletions(-)
>
> Index: linux-3.7-rc7/fs/block_dev.c
> ===
> --- linux-3.7-rc7.orig/fs/block_dev.c   2012-11-28 04:09:01.0 +0100
> +++ linux-3.7-rc7/fs/block_dev.c2012-11-28 04:13:53.0 +0100
> @@ -114,10 +114,18 @@ void invalidate_bdev(struct block_device
>  }
>  EXPORT_SYMBOL(invalidate_bdev);
>
> -int set_blocksize(struct block_device *bdev, int size)
> +static int is_bdev_mapped(struct block_device *bdev)
>  {
> -   struct address_space *mapping;
> +   int ret_val;
> +   struct address_space *mapping = bdev->bd_inode->i_mapping;
> +   mutex_lock(>i_mmap_mutex);
> +   ret_val = mapping_mapped(mapping);
> +   mutex_unlock(>i_mmap_mutex);
> +   return ret_val;
> +}
>
> +int set_blocksize(struct block_device *bdev, int size)
> +{
> /* Size must be a power of two, and between 512 and PAGE_SIZE */
> if (size > PAGE_SIZE || size < 512 || !is_power_of_2(size))
> return -EINVAL;
> @@ -126,18 +134,21 @@ int set_blocksize(struct block_device *b
> if (size < bdev_logical_block_size(bdev))
> return -EINVAL;
>
> +   /*
> +* If the block size doesn't change, don't take the write lock.
> +* We check for is_bdev_mapped anyway, for consistent behavior.
> +*/
> +   if (size == bdev->bd_block_size)
> +   return is_bdev_mapped(bdev) ? -EBUSY : 0;
> +
> /* Prevent starting I/O or mapping the device */
> percpu_down_write(>bd_block_size_semaphore);
>
> /* Check that the block device is not memory mapped */
> -   mapping = bdev->bd_inode->i_mapping;
> -   mutex_lock(>i_mmap_mutex);
> -   if (mapping_mapped(mapping)) {
> -   mutex_unlock(>i_mmap_mutex);
> +   if (is_bdev_mapped(bdev)) {
> percpu_up_write(>bd_block_size_semaphore);
> return -EBUSY;
> }
> -   mutex_unlock(>i_mmap_mutex);
>
> /* Don't change the size if it is same as current */
> if (bdev->bd_block_size != size) {


This patch didn't really make any difference for ext2/3/4 but for
reiserfs it does.

With the synchronize_sched_expedited() patch applied, it didn't make
any difference.


Thanks,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] percpu-rwsem: use synchronize_sched_expedited

[Jeff Chua]

On Wed, Nov 28, 2012 at 11:59 AM, Mikulas Patocka  wrote:
>
>
> On Tue, 27 Nov 2012, Jeff Chua wrote:
>
>> On Tue, Nov 27, 2012 at 3:38 PM, Jens Axboe  wrote:
>> > On 2012-11-27 06:57, Jeff Chua wrote:
>> >> On Sun, Nov 25, 2012 at 7:23 AM, Jeff Chua  
>> >> wrote:
>> >>> On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka  
>> >>> wrote:
>> >>>> So it's better to slow down mount.
>> >>>
>> >>> I am quite proud of the linux boot time pitting against other OS. Even
>> >>> with 10 partitions. Linux can boot up in just a few seconds, but now
>> >>> you're saying that we need to do this semaphore check at boot up. By
>> >>> doing so, it's inducing additional 4 seconds during boot up.
>> >>
>> >> By the way, I'm using a pretty fast SSD (Samsung PM830) and fast CPU
>> >> (2.8GHz). I wonder if those on slower hard disk or slower CPU, what
>> >> kind of degradation would this cause or just the same?
>> >
>> > It'd likely be the same slow down time wise, but as a percentage it
>> > would appear smaller on a slower disk.
>> >
>> > Could you please test Mikulas' suggestion of changing
>> > synchronize_sched() in include/linux/percpu-rwsem.h to
>> > synchronize_sched_expedited()?
>>
>> Tested. It seems as fast as before, but may be a "tick" slower. Just
>> perception. I was getting pretty much 0.012s with everything reverted.
>> With synchronize_sched_expedited(), it seems to be 0.012s ~ 0.013s.
>> So, it's good.
>>
>>
>> > linux-next also has a re-write of the per-cpu rw sems, out of Andrews
>> > tree. It would be a good data point it you could test that, too.
>>
>> Tested. It's slower. 0.350s. But still faster than 0.500s without the patch.
>>
>> # time mount /dev/sda1 /mnt; sync; sync; umount /mnt
>>
>>
>> So, here's the comparison ...
>>
>> 0.500s 3.7.0-rc7
>> 0.168s 3.7.0-rc2
>> 0.012s 3.6.0
>> 0.013s 3.7.0-rc7 + synchronize_sched_expedited()
>> 0.350s 3.7.0-rc7 + Oleg's patch.
>>
>>
>> Thanks,
>> Jeff.
>
> OK, I'm seinding two patches to reduce mount times. If it is possible to
> put them to 3.7.0, put them there.
>
> Mikulas
>
> ---
>
> percpu-rwsem: use synchronize_sched_expedited
>
> Use synchronize_sched_expedited() instead of synchronize_sched()
> to improve mount speed.
>
> This patch improves mount time from 0.500s to 0.013s.
>
> Note: if realtime people complain about the use
> synchronize_sched_expedited() and synchronize_rcu_expedited(), I suggest
> that they introduce an option CONFIG_REALTIME or
> /proc/sys/kernel/realtime and turn off these *_expedited functions if
> the option is enabled (i.e. turn synchronize_sched_expedited into
> synchronize_sched and synchronize_rcu_expedited into synchronize_rcu).
>
> Signed-off-by: Mikulas Patocka 
>
> ---
>  include/linux/percpu-rwsem.h |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Index: linux-3.7-rc7/include/linux/percpu-rwsem.h
> ===
> --- linux-3.7-rc7.orig/include/linux/percpu-rwsem.h 2012-11-28 
> 02:41:03.0 +0100
> +++ linux-3.7-rc7/include/linux/percpu-rwsem.h  2012-11-28 02:41:15.0 
> +0100
> @@ -13,7 +13,7 @@ struct percpu_rw_semaphore {
>  };
>
>  #define light_mb() barrier()
> -#define heavy_mb() synchronize_sched()
> +#define heavy_mb() synchronize_sched_expedited()
>
>  static inline void percpu_down_read(struct percpu_rw_semaphore *p)
>  {
> @@ -51,7 +51,7 @@ static inline void percpu_down_write(str
>  {
> mutex_lock(>mtx);
> p->locked = true;
> -   synchronize_sched(); /* make sure that all readers exit the 
> rcu_read_lock_sched region */
> +   synchronize_sched_expedited(); /* make sure that all readers exit the 
> rcu_read_lock_sched region */
> while (__percpu_count(p->counters))
> msleep(1);
> heavy_mb(); /* C, between read of p->counter and write to data, 
> paired with B */


Mikulas,

Tested this one and this is good! Back to 3.6.0 behavior.

As for the 2nd patch (block_dev.c),  it didn't really make any
difference for ext2/3/4, but for reiserfs, it does. So, won't just the
patch about(synchronize_sched_expedited) be good enough?


Thanks,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel "mount" slow

[Jeff Chua]

On Wed, Nov 28, 2012 at 4:33 PM, Jens Axboe  wrote:
> On 2012-11-28 04:57, Mikulas Patocka wrote:
>>
>>
>> On Tue, 27 Nov 2012, Jens Axboe wrote:
>>
>>> On 2012-11-27 11:06, Jeff Chua wrote:
>>>> On Tue, Nov 27, 2012 at 3:38 PM, Jens Axboe  wrote:
>>>>> On 2012-11-27 06:57, Jeff Chua wrote:
>>>>>> On Sun, Nov 25, 2012 at 7:23 AM, Jeff Chua  
>>>>>> wrote:
>>>>>>> On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka  
>>>>>>> wrote:
>>>>>>>> So it's better to slow down mount.
>>>>>>>
>>>>>>> I am quite proud of the linux boot time pitting against other OS. Even
>>>>>>> with 10 partitions. Linux can boot up in just a few seconds, but now
>>>>>>> you're saying that we need to do this semaphore check at boot up. By
>>>>>>> doing so, it's inducing additional 4 seconds during boot up.
>>>>>>
>>>>>> By the way, I'm using a pretty fast SSD (Samsung PM830) and fast CPU
>>>>>> (2.8GHz). I wonder if those on slower hard disk or slower CPU, what
>>>>>> kind of degradation would this cause or just the same?
>>>>>
>>>>> It'd likely be the same slow down time wise, but as a percentage it
>>>>> would appear smaller on a slower disk.
>>>>>
>>>>> Could you please test Mikulas' suggestion of changing
>>>>> synchronize_sched() in include/linux/percpu-rwsem.h to
>>>>> synchronize_sched_expedited()?
>>>>
>>>> Tested. It seems as fast as before, but may be a "tick" slower. Just
>>>> perception. I was getting pretty much 0.012s with everything reverted.
>>>> With synchronize_sched_expedited(), it seems to be 0.012s ~ 0.013s.
>>>> So, it's good.
>>>
>>> Excellent
>>>
>>>>> linux-next also has a re-write of the per-cpu rw sems, out of Andrews
>>>>> tree. It would be a good data point it you could test that, too.
>>>>
>>>> Tested. It's slower. 0.350s. But still faster than 0.500s without the 
>>>> patch.
>>>
>>> Makes sense, it's 2 synchronize_sched() instead of 3. So it doesn't fix
>>> the real issue, which is having to do synchronize_sched() in the first
>>> place.
>>>
>>>> # time mount /dev/sda1 /mnt; sync; sync; umount /mnt
>>>>
>>>>
>>>> So, here's the comparison ...
>>>>
>>>> 0.500s 3.7.0-rc7
>>>> 0.168s 3.7.0-rc2
>>>> 0.012s 3.6.0
>>>> 0.013s 3.7.0-rc7 + synchronize_sched_expedited()
>>>> 0.350s 3.7.0-rc7 + Oleg's patch.
>>>
>>> I wonder how many of them are due to changing to the same block size.
>>> Does the below patch make a difference?
>>
>> This patch is wrong because you must check if the device is mapped while
>> holding bdev->bd_block_size_semaphore (because
>> bdev->bd_block_size_semaphore prevents new mappings from being created)
>
> No it doesn't. If you read the patch, that was moved to i_mmap_mutex.
>
>> I'm sending another patch that has the same effect.
>>
>>
>> Note that ext[234] filesystems set blocksize to 1024 temporarily during
>> mount, so it doesn't help much (it only helps for other filesystems, such
>> as jfs). For ext[234], you have a device with default block size 4096, the
>> filesystem sets block size to 1024 during mount, reads the super block and
>> sets it back to 4096.
>
> That is true, hence I was hesitant to think it'll actually help. In any
> case, basically any block device will have at least one blocksize
> transitioned when being mounted for the first time. I wonder if we just
> shouldn't default to having a 4kb soft block size to avoid that one,
> though it is working around the issue to some degree.

I tested on reiserfs. It helped. 0.012s as in 3.6.0, but as Mikulas
mentioned, it didn't really improve much for ext2.

Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel mount slow

[Jeff Chua]

On Wed, Nov 28, 2012 at 4:33 PM, Jens Axboe ax...@kernel.dk wrote:
 On 2012-11-28 04:57, Mikulas Patocka wrote:


 On Tue, 27 Nov 2012, Jens Axboe wrote:

 On 2012-11-27 11:06, Jeff Chua wrote:
 On Tue, Nov 27, 2012 at 3:38 PM, Jens Axboe ax...@kernel.dk wrote:
 On 2012-11-27 06:57, Jeff Chua wrote:
 On Sun, Nov 25, 2012 at 7:23 AM, Jeff Chua jeff.chua.li...@gmail.com 
 wrote:
 On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka mpato...@redhat.com 
 wrote:
 So it's better to slow down mount.

 I am quite proud of the linux boot time pitting against other OS. Even
 with 10 partitions. Linux can boot up in just a few seconds, but now
 you're saying that we need to do this semaphore check at boot up. By
 doing so, it's inducing additional 4 seconds during boot up.

 By the way, I'm using a pretty fast SSD (Samsung PM830) and fast CPU
 (2.8GHz). I wonder if those on slower hard disk or slower CPU, what
 kind of degradation would this cause or just the same?

 It'd likely be the same slow down time wise, but as a percentage it
 would appear smaller on a slower disk.

 Could you please test Mikulas' suggestion of changing
 synchronize_sched() in include/linux/percpu-rwsem.h to
 synchronize_sched_expedited()?

 Tested. It seems as fast as before, but may be a tick slower. Just
 perception. I was getting pretty much 0.012s with everything reverted.
 With synchronize_sched_expedited(), it seems to be 0.012s ~ 0.013s.
 So, it's good.

 Excellent

 linux-next also has a re-write of the per-cpu rw sems, out of Andrews
 tree. It would be a good data point it you could test that, too.

 Tested. It's slower. 0.350s. But still faster than 0.500s without the 
 patch.

 Makes sense, it's 2 synchronize_sched() instead of 3. So it doesn't fix
 the real issue, which is having to do synchronize_sched() in the first
 place.

 # time mount /dev/sda1 /mnt; sync; sync; umount /mnt


 So, here's the comparison ...

 0.500s 3.7.0-rc7
 0.168s 3.7.0-rc2
 0.012s 3.6.0
 0.013s 3.7.0-rc7 + synchronize_sched_expedited()
 0.350s 3.7.0-rc7 + Oleg's patch.

 I wonder how many of them are due to changing to the same block size.
 Does the below patch make a difference?

 This patch is wrong because you must check if the device is mapped while
 holding bdev-bd_block_size_semaphore (because
 bdev-bd_block_size_semaphore prevents new mappings from being created)

 No it doesn't. If you read the patch, that was moved to i_mmap_mutex.

 I'm sending another patch that has the same effect.


 Note that ext[234] filesystems set blocksize to 1024 temporarily during
 mount, so it doesn't help much (it only helps for other filesystems, such
 as jfs). For ext[234], you have a device with default block size 4096, the
 filesystem sets block size to 1024 during mount, reads the super block and
 sets it back to 4096.

 That is true, hence I was hesitant to think it'll actually help. In any
 case, basically any block device will have at least one blocksize
 transitioned when being mounted for the first time. I wonder if we just
 shouldn't default to having a 4kb soft block size to avoid that one,
 though it is working around the issue to some degree.

I tested on reiserfs. It helped. 0.012s as in 3.6.0, but as Mikulas
mentioned, it didn't really improve much for ext2.

Jeff.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] percpu-rwsem: use synchronize_sched_expedited

[Jeff Chua]

On Wed, Nov 28, 2012 at 11:59 AM, Mikulas Patocka mpato...@redhat.com wrote:


 On Tue, 27 Nov 2012, Jeff Chua wrote:

 On Tue, Nov 27, 2012 at 3:38 PM, Jens Axboe ax...@kernel.dk wrote:
  On 2012-11-27 06:57, Jeff Chua wrote:
  On Sun, Nov 25, 2012 at 7:23 AM, Jeff Chua jeff.chua.li...@gmail.com 
  wrote:
  On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka mpato...@redhat.com 
  wrote:
  So it's better to slow down mount.
 
  I am quite proud of the linux boot time pitting against other OS. Even
  with 10 partitions. Linux can boot up in just a few seconds, but now
  you're saying that we need to do this semaphore check at boot up. By
  doing so, it's inducing additional 4 seconds during boot up.
 
  By the way, I'm using a pretty fast SSD (Samsung PM830) and fast CPU
  (2.8GHz). I wonder if those on slower hard disk or slower CPU, what
  kind of degradation would this cause or just the same?
 
  It'd likely be the same slow down time wise, but as a percentage it
  would appear smaller on a slower disk.
 
  Could you please test Mikulas' suggestion of changing
  synchronize_sched() in include/linux/percpu-rwsem.h to
  synchronize_sched_expedited()?

 Tested. It seems as fast as before, but may be a tick slower. Just
 perception. I was getting pretty much 0.012s with everything reverted.
 With synchronize_sched_expedited(), it seems to be 0.012s ~ 0.013s.
 So, it's good.


  linux-next also has a re-write of the per-cpu rw sems, out of Andrews
  tree. It would be a good data point it you could test that, too.

 Tested. It's slower. 0.350s. But still faster than 0.500s without the patch.

 # time mount /dev/sda1 /mnt; sync; sync; umount /mnt


 So, here's the comparison ...

 0.500s 3.7.0-rc7
 0.168s 3.7.0-rc2
 0.012s 3.6.0
 0.013s 3.7.0-rc7 + synchronize_sched_expedited()
 0.350s 3.7.0-rc7 + Oleg's patch.


 Thanks,
 Jeff.

 OK, I'm seinding two patches to reduce mount times. If it is possible to
 put them to 3.7.0, put them there.

 Mikulas

 ---

 percpu-rwsem: use synchronize_sched_expedited

 Use synchronize_sched_expedited() instead of synchronize_sched()
 to improve mount speed.

 This patch improves mount time from 0.500s to 0.013s.

 Note: if realtime people complain about the use
 synchronize_sched_expedited() and synchronize_rcu_expedited(), I suggest
 that they introduce an option CONFIG_REALTIME or
 /proc/sys/kernel/realtime and turn off these *_expedited functions if
 the option is enabled (i.e. turn synchronize_sched_expedited into
 synchronize_sched and synchronize_rcu_expedited into synchronize_rcu).

 Signed-off-by: Mikulas Patocka mpato...@redhat.com

 ---
  include/linux/percpu-rwsem.h |4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

 Index: linux-3.7-rc7/include/linux/percpu-rwsem.h
 ===
 --- linux-3.7-rc7.orig/include/linux/percpu-rwsem.h 2012-11-28 
 02:41:03.0 +0100
 +++ linux-3.7-rc7/include/linux/percpu-rwsem.h  2012-11-28 02:41:15.0 
 +0100
 @@ -13,7 +13,7 @@ struct percpu_rw_semaphore {
  };

  #define light_mb() barrier()
 -#define heavy_mb() synchronize_sched()
 +#define heavy_mb() synchronize_sched_expedited()

  static inline void percpu_down_read(struct percpu_rw_semaphore *p)
  {
 @@ -51,7 +51,7 @@ static inline void percpu_down_write(str
  {
 mutex_lock(p-mtx);
 p-locked = true;
 -   synchronize_sched(); /* make sure that all readers exit the 
 rcu_read_lock_sched region */
 +   synchronize_sched_expedited(); /* make sure that all readers exit the 
 rcu_read_lock_sched region */
 while (__percpu_count(p-counters))
 msleep(1);
 heavy_mb(); /* C, between read of p-counter and write to data, 
 paired with B */


Mikulas,

Tested this one and this is good! Back to 3.6.0 behavior.

As for the 2nd patch (block_dev.c),  it didn't really make any
difference for ext2/3/4, but for reiserfs, it does. So, won't just the
patch about(synchronize_sched_expedited) be good enough?


Thanks,
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] block_dev: don't take the write lock if block size doesn't change

[Jeff Chua]

On Wed, Nov 28, 2012 at 12:01 PM, Mikulas Patocka mpato...@redhat.com wrote:
 block_dev: don't take the write lock if block size doesn't change

 Taking the write lock has a big performance impact on the whole system
 (because of synchronize_sched_expedited). This patch avoids taking the
 write lock if the block size doesn't change (i.e. when mounting
 filesystem with block size equal to the default block size).

 The logic to test if the block device is mapped was moved to a separate
 function is_bdev_mapped to avoid code duplication.

 Signed-off-by: Mikulas Patocka mpato...@redhat.com

 ---
  fs/block_dev.c |   25 ++---
  1 file changed, 18 insertions(+), 7 deletions(-)

 Index: linux-3.7-rc7/fs/block_dev.c
 ===
 --- linux-3.7-rc7.orig/fs/block_dev.c   2012-11-28 04:09:01.0 +0100
 +++ linux-3.7-rc7/fs/block_dev.c2012-11-28 04:13:53.0 +0100
 @@ -114,10 +114,18 @@ void invalidate_bdev(struct block_device
  }
  EXPORT_SYMBOL(invalidate_bdev);

 -int set_blocksize(struct block_device *bdev, int size)
 +static int is_bdev_mapped(struct block_device *bdev)
  {
 -   struct address_space *mapping;
 +   int ret_val;
 +   struct address_space *mapping = bdev-bd_inode-i_mapping;
 +   mutex_lock(mapping-i_mmap_mutex);
 +   ret_val = mapping_mapped(mapping);
 +   mutex_unlock(mapping-i_mmap_mutex);
 +   return ret_val;
 +}

 +int set_blocksize(struct block_device *bdev, int size)
 +{
 /* Size must be a power of two, and between 512 and PAGE_SIZE */
 if (size  PAGE_SIZE || size  512 || !is_power_of_2(size))
 return -EINVAL;
 @@ -126,18 +134,21 @@ int set_blocksize(struct block_device *b
 if (size  bdev_logical_block_size(bdev))
 return -EINVAL;

 +   /*
 +* If the block size doesn't change, don't take the write lock.
 +* We check for is_bdev_mapped anyway, for consistent behavior.
 +*/
 +   if (size == bdev-bd_block_size)
 +   return is_bdev_mapped(bdev) ? -EBUSY : 0;
 +
 /* Prevent starting I/O or mapping the device */
 percpu_down_write(bdev-bd_block_size_semaphore);

 /* Check that the block device is not memory mapped */
 -   mapping = bdev-bd_inode-i_mapping;
 -   mutex_lock(mapping-i_mmap_mutex);
 -   if (mapping_mapped(mapping)) {
 -   mutex_unlock(mapping-i_mmap_mutex);
 +   if (is_bdev_mapped(bdev)) {
 percpu_up_write(bdev-bd_block_size_semaphore);
 return -EBUSY;
 }
 -   mutex_unlock(mapping-i_mmap_mutex);

 /* Don't change the size if it is same as current */
 if (bdev-bd_block_size != size) {


This patch didn't really make any difference for ext2/3/4 but for
reiserfs it does.

With the synchronize_sched_expedited() patch applied, it didn't make
any difference.


Thanks,
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel "mount" slow

[Jeff Chua]

On Tue, Nov 27, 2012 at 3:38 PM, Jens Axboe  wrote:
> On 2012-11-27 06:57, Jeff Chua wrote:
>> On Sun, Nov 25, 2012 at 7:23 AM, Jeff Chua  wrote:
>>> On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka  
>>> wrote:
>>>> So it's better to slow down mount.
>>>
>>> I am quite proud of the linux boot time pitting against other OS. Even
>>> with 10 partitions. Linux can boot up in just a few seconds, but now
>>> you're saying that we need to do this semaphore check at boot up. By
>>> doing so, it's inducing additional 4 seconds during boot up.
>>
>> By the way, I'm using a pretty fast SSD (Samsung PM830) and fast CPU
>> (2.8GHz). I wonder if those on slower hard disk or slower CPU, what
>> kind of degradation would this cause or just the same?
>
> It'd likely be the same slow down time wise, but as a percentage it
> would appear smaller on a slower disk.
>
> Could you please test Mikulas' suggestion of changing
> synchronize_sched() in include/linux/percpu-rwsem.h to
> synchronize_sched_expedited()?

Tested. It seems as fast as before, but may be a "tick" slower. Just
perception. I was getting pretty much 0.012s with everything reverted.
With synchronize_sched_expedited(), it seems to be 0.012s ~ 0.013s.
So, it's good.


> linux-next also has a re-write of the per-cpu rw sems, out of Andrews
> tree. It would be a good data point it you could test that, too.

Tested. It's slower. 0.350s. But still faster than 0.500s without the patch.

# time mount /dev/sda1 /mnt; sync; sync; umount /mnt


So, here's the comparison ...

0.500s 3.7.0-rc7
0.168s 3.7.0-rc2
0.012s 3.6.0
0.013s 3.7.0-rc7 + synchronize_sched_expedited()
0.350s 3.7.0-rc7 + Oleg's patch.


Thanks,
Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel "mount" slow

[Jeff Chua]

Jens,

Limited access now at Incheon Airport. Will try the patch out when I arrived.

Thanks,
Jeff

On 11/27/12, Jens Axboe  wrote:
> On 2012-11-27 08:38, Jens Axboe wrote:
>> On 2012-11-27 06:57, Jeff Chua wrote:
>>> On Sun, Nov 25, 2012 at 7:23 AM, Jeff Chua 
>>> wrote:
>>>> On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka 
>>>> wrote:
>>>>> So it's better to slow down mount.
>>>>
>>>> I am quite proud of the linux boot time pitting against other OS. Even
>>>> with 10 partitions. Linux can boot up in just a few seconds, but now
>>>> you're saying that we need to do this semaphore check at boot up. By
>>>> doing so, it's inducing additional 4 seconds during boot up.
>>>
>>> By the way, I'm using a pretty fast SSD (Samsung PM830) and fast CPU
>>> (2.8GHz). I wonder if those on slower hard disk or slower CPU, what
>>> kind of degradation would this cause or just the same?
>>
>> It'd likely be the same slow down time wise, but as a percentage it
>> would appear smaller on a slower disk.
>>
>> Could you please test Mikulas' suggestion of changing
>> synchronize_sched() in include/linux/percpu-rwsem.h to
>> synchronize_sched_expedited()?
>>
>> linux-next also has a re-write of the per-cpu rw sems, out of Andrews
>> tree. It would be a good data point it you could test that, too.
>>
>> In any case, the slow down definitely isn't acceptable. Fixing an
>> obscure issue like block sizes changing while O_DIRECT is in flight
>> definitely does NOT warrant a mount slow down.
>
> Here's Olegs patch, might be easier for you than switching to
> linux-next. Please try that.
>
> From: Oleg Nesterov 
> Subject: percpu_rw_semaphore: reimplement to not block the readers
> unnecessarily
>
> Currently the writer does msleep() plus synchronize_sched() 3 times to
> acquire/release the semaphore, and during this time the readers are
> blocked completely.  Even if the "write" section was not actually started
> or if it was already finished.
>
> With this patch down_write/up_write does synchronize_sched() twice and
> down_read/up_read are still possible during this time, just they use the
> slow path.
>
> percpu_down_write() first forces the readers to use rw_semaphore and
> increment the "slow" counter to take the lock for reading, then it
> takes that rw_semaphore for writing and blocks the readers.
>
> Also.  With this patch the code relies on the documented behaviour of
> synchronize_sched(), it doesn't try to pair synchronize_sched() with
> barrier.
>
> Signed-off-by: Oleg Nesterov 
> Reviewed-by: Paul E. McKenney 
> Cc: Linus Torvalds 
> Cc: Mikulas Patocka 
> Cc: Peter Zijlstra 
> Cc: Ingo Molnar 
> Cc: Srikar Dronamraju 
> Cc: Ananth N Mavinakayanahalli 
> Cc: Anton Arapov 
> Cc: Jens Axboe 
> Signed-off-by: Andrew Morton 
> ---
>
>  include/linux/percpu-rwsem.h |   85 +++---
>  lib/Makefile |2
>  lib/percpu-rwsem.c   |  123 +
>  3 files changed, 138 insertions(+), 72 deletions(-)
>
> diff -puN
> include/linux/percpu-rwsem.h~percpu_rw_semaphore-reimplement-to-not-block-the-readers-unnecessarily
> include/linux/percpu-rwsem.h
> ---
> a/include/linux/percpu-rwsem.h~percpu_rw_semaphore-reimplement-to-not-block-the-readers-unnecessarily
> +++ a/include/linux/percpu-rwsem.h
> @@ -2,82 +2,25 @@
>  #define _LINUX_PERCPU_RWSEM_H
>
>  #include 
> +#include 
>  #include 
> -#include 
> -#include 
> +#include 
>
>  struct percpu_rw_semaphore {
> - unsigned __percpu *counters;
> - bool locked;
> - struct mutex mtx;
> + unsigned int __percpu   *fast_read_ctr;
> + struct mutexwriter_mutex;
> + struct rw_semaphore rw_sem;
> + atomic_tslow_read_ctr;
> + wait_queue_head_t   write_waitq;
>  };
>
> -#define light_mb()   barrier()
> -#define heavy_mb()   synchronize_sched()
> +extern void percpu_down_read(struct percpu_rw_semaphore *);
> +extern void percpu_up_read(struct percpu_rw_semaphore *);
>
> -static inline void percpu_down_read(struct percpu_rw_semaphore *p)
> -{
> - rcu_read_lock_sched();
> - if (unlikely(p->locked)) {
> - rcu_read_unlock_sched();
> - mutex_lock(>mtx);
> - this_cpu_inc(*p->counters);
> - mutex_unlock(>mtx);
> - return;
> - }
> - this_cpu_inc(*p->counters);
> - rcu_read_unlock_sched();
> - light_mb(); /* A, between read of p->locked and read of data, paired

Re: Recent kernel mount slow

[Jeff Chua]

Jens,

Limited access now at Incheon Airport. Will try the patch out when I arrived.

Thanks,
Jeff

On 11/27/12, Jens Axboe ax...@kernel.dk wrote:
 On 2012-11-27 08:38, Jens Axboe wrote:
 On 2012-11-27 06:57, Jeff Chua wrote:
 On Sun, Nov 25, 2012 at 7:23 AM, Jeff Chua jeff.chua.li...@gmail.com
 wrote:
 On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka mpato...@redhat.com
 wrote:
 So it's better to slow down mount.

 I am quite proud of the linux boot time pitting against other OS. Even
 with 10 partitions. Linux can boot up in just a few seconds, but now
 you're saying that we need to do this semaphore check at boot up. By
 doing so, it's inducing additional 4 seconds during boot up.

 By the way, I'm using a pretty fast SSD (Samsung PM830) and fast CPU
 (2.8GHz). I wonder if those on slower hard disk or slower CPU, what
 kind of degradation would this cause or just the same?

 It'd likely be the same slow down time wise, but as a percentage it
 would appear smaller on a slower disk.

 Could you please test Mikulas' suggestion of changing
 synchronize_sched() in include/linux/percpu-rwsem.h to
 synchronize_sched_expedited()?

 linux-next also has a re-write of the per-cpu rw sems, out of Andrews
 tree. It would be a good data point it you could test that, too.

 In any case, the slow down definitely isn't acceptable. Fixing an
 obscure issue like block sizes changing while O_DIRECT is in flight
 definitely does NOT warrant a mount slow down.

 Here's Olegs patch, might be easier for you than switching to
 linux-next. Please try that.

 From: Oleg Nesterov o...@redhat.com
 Subject: percpu_rw_semaphore: reimplement to not block the readers
 unnecessarily

 Currently the writer does msleep() plus synchronize_sched() 3 times to
 acquire/release the semaphore, and during this time the readers are
 blocked completely.  Even if the write section was not actually started
 or if it was already finished.

 With this patch down_write/up_write does synchronize_sched() twice and
 down_read/up_read are still possible during this time, just they use the
 slow path.

 percpu_down_write() first forces the readers to use rw_semaphore and
 increment the slow counter to take the lock for reading, then it
 takes that rw_semaphore for writing and blocks the readers.

 Also.  With this patch the code relies on the documented behaviour of
 synchronize_sched(), it doesn't try to pair synchronize_sched() with
 barrier.

 Signed-off-by: Oleg Nesterov o...@redhat.com
 Reviewed-by: Paul E. McKenney paul...@linux.vnet.ibm.com
 Cc: Linus Torvalds torva...@linux-foundation.org
 Cc: Mikulas Patocka mpato...@redhat.com
 Cc: Peter Zijlstra pet...@infradead.org
 Cc: Ingo Molnar mi...@elte.hu
 Cc: Srikar Dronamraju sri...@linux.vnet.ibm.com
 Cc: Ananth N Mavinakayanahalli ana...@in.ibm.com
 Cc: Anton Arapov an...@redhat.com
 Cc: Jens Axboe ax...@kernel.dk
 Signed-off-by: Andrew Morton a...@linux-foundation.org
 ---

  include/linux/percpu-rwsem.h |   85 +++---
  lib/Makefile |2
  lib/percpu-rwsem.c   |  123 +
  3 files changed, 138 insertions(+), 72 deletions(-)

 diff -puN
 include/linux/percpu-rwsem.h~percpu_rw_semaphore-reimplement-to-not-block-the-readers-unnecessarily
 include/linux/percpu-rwsem.h
 ---
 a/include/linux/percpu-rwsem.h~percpu_rw_semaphore-reimplement-to-not-block-the-readers-unnecessarily
 +++ a/include/linux/percpu-rwsem.h
 @@ -2,82 +2,25 @@
  #define _LINUX_PERCPU_RWSEM_H

  #include linux/mutex.h
 +#include linux/rwsem.h
  #include linux/percpu.h
 -#include linux/rcupdate.h
 -#include linux/delay.h
 +#include linux/wait.h

  struct percpu_rw_semaphore {
 - unsigned __percpu *counters;
 - bool locked;
 - struct mutex mtx;
 + unsigned int __percpu   *fast_read_ctr;
 + struct mutexwriter_mutex;
 + struct rw_semaphore rw_sem;
 + atomic_tslow_read_ctr;
 + wait_queue_head_t   write_waitq;
  };

 -#define light_mb()   barrier()
 -#define heavy_mb()   synchronize_sched()
 +extern void percpu_down_read(struct percpu_rw_semaphore *);
 +extern void percpu_up_read(struct percpu_rw_semaphore *);

 -static inline void percpu_down_read(struct percpu_rw_semaphore *p)
 -{
 - rcu_read_lock_sched();
 - if (unlikely(p-locked)) {
 - rcu_read_unlock_sched();
 - mutex_lock(p-mtx);
 - this_cpu_inc(*p-counters);
 - mutex_unlock(p-mtx);
 - return;
 - }
 - this_cpu_inc(*p-counters);
 - rcu_read_unlock_sched();
 - light_mb(); /* A, between read of p-locked and read of data, paired 
 with
 D */
 -}
 -
 -static inline void percpu_up_read(struct percpu_rw_semaphore *p)
 -{
 - light_mb(); /* B, between read of the data and write to p-counter, 
 paired
 with C */
 - this_cpu_dec(*p-counters);
 -}
 -
 -static inline unsigned __percpu_count(unsigned __percpu *counters)
 -{
 - unsigned total = 0;
 - int cpu

Re: Recent kernel mount slow

[Jeff Chua]

On Tue, Nov 27, 2012 at 3:38 PM, Jens Axboe ax...@kernel.dk wrote:
 On 2012-11-27 06:57, Jeff Chua wrote:
 On Sun, Nov 25, 2012 at 7:23 AM, Jeff Chua jeff.chua.li...@gmail.com wrote:
 On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka mpato...@redhat.com 
 wrote:
 So it's better to slow down mount.

 I am quite proud of the linux boot time pitting against other OS. Even
 with 10 partitions. Linux can boot up in just a few seconds, but now
 you're saying that we need to do this semaphore check at boot up. By
 doing so, it's inducing additional 4 seconds during boot up.

 By the way, I'm using a pretty fast SSD (Samsung PM830) and fast CPU
 (2.8GHz). I wonder if those on slower hard disk or slower CPU, what
 kind of degradation would this cause or just the same?

 It'd likely be the same slow down time wise, but as a percentage it
 would appear smaller on a slower disk.

 Could you please test Mikulas' suggestion of changing
 synchronize_sched() in include/linux/percpu-rwsem.h to
 synchronize_sched_expedited()?

Tested. It seems as fast as before, but may be a tick slower. Just
perception. I was getting pretty much 0.012s with everything reverted.
With synchronize_sched_expedited(), it seems to be 0.012s ~ 0.013s.
So, it's good.


 linux-next also has a re-write of the per-cpu rw sems, out of Andrews
 tree. It would be a good data point it you could test that, too.

Tested. It's slower. 0.350s. But still faster than 0.500s without the patch.

# time mount /dev/sda1 /mnt; sync; sync; umount /mnt


So, here's the comparison ...

0.500s 3.7.0-rc7
0.168s 3.7.0-rc2
0.012s 3.6.0
0.013s 3.7.0-rc7 + synchronize_sched_expedited()
0.350s 3.7.0-rc7 + Oleg's patch.


Thanks,
Jeff.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel "mount" slow

[Jeff Chua]

On Sun, Nov 25, 2012 at 7:23 AM, Jeff Chua  wrote:
> On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka  wrote:
>> So it's better to slow down mount.
>
> I am quite proud of the linux boot time pitting against other OS. Even
> with 10 partitions. Linux can boot up in just a few seconds, but now
> you're saying that we need to do this semaphore check at boot up. By
> doing so, it's inducing additional 4 seconds during boot up.

By the way, I'm using a pretty fast SSD (Samsung PM830) and fast CPU
(2.8GHz). I wonder if those on slower hard disk or slower CPU, what
kind of degradation would this cause or just the same?

Thanks,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel mount slow

[Jeff Chua]

On Sun, Nov 25, 2012 at 7:23 AM, Jeff Chua jeff.chua.li...@gmail.com wrote:
 On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka mpato...@redhat.com wrote:
 So it's better to slow down mount.

 I am quite proud of the linux boot time pitting against other OS. Even
 with 10 partitions. Linux can boot up in just a few seconds, but now
 you're saying that we need to do this semaphore check at boot up. By
 doing so, it's inducing additional 4 seconds during boot up.

By the way, I'm using a pretty fast SSD (Samsung PM830) and fast CPU
(2.8GHz). I wonder if those on slower hard disk or slower CPU, what
kind of degradation would this cause or just the same?

Thanks,
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel "mount" slow

[Jeff Chua]

On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka  wrote:
> So it's better to slow down mount.

I am quite proud of the linux boot time pitting against other OS. Even
with 10 partitions. Linux can boot up in just a few seconds, but now
you're saying that we need to do this semaphore check at boot up. By
doing so, it's inducing additional 4 seconds during boot up.

What about moving the locking mechanism to the "mount" program itself?
Won't that be more feasible?

As for the cases of simultaneous mounts, it's usually administrator
that's doing something bad. I would say this is not a kernel issue.

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel mount slow

[Jeff Chua]

On Sun, Nov 25, 2012 at 5:09 AM, Mikulas Patocka mpato...@redhat.com wrote:
 So it's better to slow down mount.

I am quite proud of the linux boot time pitting against other OS. Even
with 10 partitions. Linux can boot up in just a few seconds, but now
you're saying that we need to do this semaphore check at boot up. By
doing so, it's inducing additional 4 seconds during boot up.

What about moving the locking mechanism to the mount program itself?
Won't that be more feasible?

As for the cases of simultaneous mounts, it's usually administrator
that's doing something bad. I would say this is not a kernel issue.

Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel "mount" slow

[Jeff Chua]

On Sat, Nov 24, 2012 at 7:31 AM, Jeff Chua  wrote:
> On Sat, Nov 24, 2012 at 6:21 AM, Jeff Chua  wrote:
>> On Fri, Nov 23, 2012 at 9:24 PM, Jens Axboe  wrote:
>>> On 2012-11-22 20:21, Linus Torvalds wrote:
>>>> Doesn't sound like a fsdevel issue since it seems to be independent of
>>>> filesystems. More like some generic block layer thing. Adding Jens
>>>> (and quoting the whole thing)
>>>>
>>>> Jens, any ideas? Most of your stuff came in after -rc2, which would
>>>> fit with the fact that most of the slowdown seems to be after -rc2
>>>> according to Jeff.
>>>
>>> No ideas. Looking at what went in from my side, only the rq plug sorting
>>> is a core change, and that should not cause any change in behaviour for
>>> a single device. That's commit 975927b9.
>>>
>>>> Jeff, more bisecting would be good, though.
>>>
>>> Probably required, yes...
>>
>>
>> This one slows mount from 0.012s to 0.168s.
>>
>> commit 62ac665ff9fc07497ca524bd20d6a96893d11071
>> Author: Mikulas Patocka 
>> Date:   Wed Sep 26 07:46:43 2012 +0200
>>
>> blockdev: turn a rw semaphore into a percpu rw semaphore
>>
>>
>> There were couple of more changes to percpu-rw-semaphores after
>> 3.7.0-rc2 and those slows mount further from 0.168s to 0.500s. I don't
>> really know, but I'm suspecting these. Still bisecting.
>>
>> commit 5c1eabe68501d1e1b1586c7f4c46cc531828c4ab
>> Author: Mikulas Patocka 
>> Date:   Mon Oct 22 19:37:47 2012 -0400
>>
>> percpu-rw-semaphores: use light/heavy barriers
>>
>>
>> commit 1bf11c53535ab87e3bf14ecdf6747bf46f601c5d
>> Author: Mikulas Patocka 
>> Date:   Mon Oct 22 19:39:16 2012 -0400
>>
>> percpu-rw-semaphores: use rcu_read_lock_sched
>
>
> I reverted these 3 patches and mount time is now 0.012s.
>
> # time mount /dev/sda1 /mnt; sync; sync; umount /mnt
>
>
>> commit 1a25b1c4ce189e3926f2981f3302352a930086db
>> Author: Mikulas Patocka 
>> Date:   Mon Oct 15 17:20:17 2012 -0400
>>
>> Lock splice_read and splice_write functions
>
> Looks like this one is not the problem. But I reverted it anyway
> because it's part of the same chunk.
>
>
> Happy Thanksgiving!

I'm on latest git 3.7.0-rc6 5e351cdc998db82935d1248a053a1be37d1160fd
and with the above patches reverted and mount time is now 0.012s.

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel "mount" slow

[Jeff Chua]

On Sat, Nov 24, 2012 at 6:21 AM, Jeff Chua  wrote:
> On Fri, Nov 23, 2012 at 9:24 PM, Jens Axboe  wrote:
>> On 2012-11-22 20:21, Linus Torvalds wrote:
>>> Doesn't sound like a fsdevel issue since it seems to be independent of
>>> filesystems. More like some generic block layer thing. Adding Jens
>>> (and quoting the whole thing)
>>>
>>> Jens, any ideas? Most of your stuff came in after -rc2, which would
>>> fit with the fact that most of the slowdown seems to be after -rc2
>>> according to Jeff.
>>
>> No ideas. Looking at what went in from my side, only the rq plug sorting
>> is a core change, and that should not cause any change in behaviour for
>> a single device. That's commit 975927b9.
>>
>>> Jeff, more bisecting would be good, though.
>>
>> Probably required, yes...
>
>
> This one slows mount from 0.012s to 0.168s.
>
> commit 62ac665ff9fc07497ca524bd20d6a96893d11071
> Author: Mikulas Patocka 
> Date:   Wed Sep 26 07:46:43 2012 +0200
>
> blockdev: turn a rw semaphore into a percpu rw semaphore
>
>
> There were couple of more changes to percpu-rw-semaphores after
> 3.7.0-rc2 and those slows mount further from 0.168s to 0.500s. I don't
> really know, but I'm suspecting these. Still bisecting.
>
> commit 5c1eabe68501d1e1b1586c7f4c46cc531828c4ab
> Author: Mikulas Patocka 
> Date:   Mon Oct 22 19:37:47 2012 -0400
>
> percpu-rw-semaphores: use light/heavy barriers
>
>
> commit 1bf11c53535ab87e3bf14ecdf6747bf46f601c5d
> Author: Mikulas Patocka 
> Date:   Mon Oct 22 19:39:16 2012 -0400
>
> percpu-rw-semaphores: use rcu_read_lock_sched


I reverted these 3 patches and mount time is now 0.012s.

# time mount /dev/sda1 /mnt; sync; sync; umount /mnt


> commit 1a25b1c4ce189e3926f2981f3302352a930086db
> Author: Mikulas Patocka 
> Date:   Mon Oct 15 17:20:17 2012 -0400
>
> Lock splice_read and splice_write functions

Looks like this one is not the problem. But I reverted it anyway
because it's part of the same chunk.


Happy Thanksgiving!

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel "mount" slow

[Jeff Chua]

On Fri, Nov 23, 2012 at 9:24 PM, Jens Axboe  wrote:
> On 2012-11-22 20:21, Linus Torvalds wrote:
>> Doesn't sound like a fsdevel issue since it seems to be independent of
>> filesystems. More like some generic block layer thing. Adding Jens
>> (and quoting the whole thing)
>>
>> Jens, any ideas? Most of your stuff came in after -rc2, which would
>> fit with the fact that most of the slowdown seems to be after -rc2
>> according to Jeff.
>
> No ideas. Looking at what went in from my side, only the rq plug sorting
> is a core change, and that should not cause any change in behaviour for
> a single device. That's commit 975927b9.
>
>> Jeff, more bisecting would be good, though.
>
> Probably required, yes...


This one slows mount from 0.012s to 0.168s.

commit 62ac665ff9fc07497ca524bd20d6a96893d11071
Author: Mikulas Patocka 
Date:   Wed Sep 26 07:46:43 2012 +0200

blockdev: turn a rw semaphore into a percpu rw semaphore


There were couple of more changes to percpu-rw-semaphores after
3.7.0-rc2 and those slows mount further from 0.168s to 0.500s. I don't
really know, but I'm suspecting these. Still bisecting.

commit 5c1eabe68501d1e1b1586c7f4c46cc531828c4ab
Author: Mikulas Patocka 
Date:   Mon Oct 22 19:37:47 2012 -0400

percpu-rw-semaphores: use light/heavy barriers


commit 1bf11c53535ab87e3bf14ecdf6747bf46f601c5d
Author: Mikulas Patocka 
Date:   Mon Oct 22 19:39:16 2012 -0400

percpu-rw-semaphores: use rcu_read_lock_sched


commit 1a25b1c4ce189e3926f2981f3302352a930086db
Author: Mikulas Patocka 
Date:   Mon Oct 15 17:20:17 2012 -0400

Lock splice_read and splice_write functions



I couldn't unpatch with the latest kernel, but still trying.

Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel mount slow

[Jeff Chua]

On Fri, Nov 23, 2012 at 9:24 PM, Jens Axboe ax...@kernel.dk wrote:
 On 2012-11-22 20:21, Linus Torvalds wrote:
 Doesn't sound like a fsdevel issue since it seems to be independent of
 filesystems. More like some generic block layer thing. Adding Jens
 (and quoting the whole thing)

 Jens, any ideas? Most of your stuff came in after -rc2, which would
 fit with the fact that most of the slowdown seems to be after -rc2
 according to Jeff.

 No ideas. Looking at what went in from my side, only the rq plug sorting
 is a core change, and that should not cause any change in behaviour for
 a single device. That's commit 975927b9.

 Jeff, more bisecting would be good, though.

 Probably required, yes...


This one slows mount from 0.012s to 0.168s.

commit 62ac665ff9fc07497ca524bd20d6a96893d11071
Author: Mikulas Patocka mpato...@redhat.com
Date:   Wed Sep 26 07:46:43 2012 +0200

blockdev: turn a rw semaphore into a percpu rw semaphore


There were couple of more changes to percpu-rw-semaphores after
3.7.0-rc2 and those slows mount further from 0.168s to 0.500s. I don't
really know, but I'm suspecting these. Still bisecting.

commit 5c1eabe68501d1e1b1586c7f4c46cc531828c4ab
Author: Mikulas Patocka mpato...@redhat.com
Date:   Mon Oct 22 19:37:47 2012 -0400

percpu-rw-semaphores: use light/heavy barriers


commit 1bf11c53535ab87e3bf14ecdf6747bf46f601c5d
Author: Mikulas Patocka mpato...@redhat.com
Date:   Mon Oct 22 19:39:16 2012 -0400

percpu-rw-semaphores: use rcu_read_lock_sched


commit 1a25b1c4ce189e3926f2981f3302352a930086db
Author: Mikulas Patocka mpato...@redhat.com
Date:   Mon Oct 15 17:20:17 2012 -0400

Lock splice_read and splice_write functions



I couldn't unpatch with the latest kernel, but still trying.

Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel mount slow

[Jeff Chua]

On Sat, Nov 24, 2012 at 6:21 AM, Jeff Chua jeff.chua.li...@gmail.com wrote:
 On Fri, Nov 23, 2012 at 9:24 PM, Jens Axboe ax...@kernel.dk wrote:
 On 2012-11-22 20:21, Linus Torvalds wrote:
 Doesn't sound like a fsdevel issue since it seems to be independent of
 filesystems. More like some generic block layer thing. Adding Jens
 (and quoting the whole thing)

 Jens, any ideas? Most of your stuff came in after -rc2, which would
 fit with the fact that most of the slowdown seems to be after -rc2
 according to Jeff.

 No ideas. Looking at what went in from my side, only the rq plug sorting
 is a core change, and that should not cause any change in behaviour for
 a single device. That's commit 975927b9.

 Jeff, more bisecting would be good, though.

 Probably required, yes...


 This one slows mount from 0.012s to 0.168s.

 commit 62ac665ff9fc07497ca524bd20d6a96893d11071
 Author: Mikulas Patocka mpato...@redhat.com
 Date:   Wed Sep 26 07:46:43 2012 +0200

 blockdev: turn a rw semaphore into a percpu rw semaphore


 There were couple of more changes to percpu-rw-semaphores after
 3.7.0-rc2 and those slows mount further from 0.168s to 0.500s. I don't
 really know, but I'm suspecting these. Still bisecting.

 commit 5c1eabe68501d1e1b1586c7f4c46cc531828c4ab
 Author: Mikulas Patocka mpato...@redhat.com
 Date:   Mon Oct 22 19:37:47 2012 -0400

 percpu-rw-semaphores: use light/heavy barriers


 commit 1bf11c53535ab87e3bf14ecdf6747bf46f601c5d
 Author: Mikulas Patocka mpato...@redhat.com
 Date:   Mon Oct 22 19:39:16 2012 -0400

 percpu-rw-semaphores: use rcu_read_lock_sched


I reverted these 3 patches and mount time is now 0.012s.

# time mount /dev/sda1 /mnt; sync; sync; umount /mnt


 commit 1a25b1c4ce189e3926f2981f3302352a930086db
 Author: Mikulas Patocka mpato...@redhat.com
 Date:   Mon Oct 15 17:20:17 2012 -0400

 Lock splice_read and splice_write functions

Looks like this one is not the problem. But I reverted it anyway
because it's part of the same chunk.


Happy Thanksgiving!

Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel mount slow

[Jeff Chua]

On Sat, Nov 24, 2012 at 7:31 AM, Jeff Chua jeff.chua.li...@gmail.com wrote:
 On Sat, Nov 24, 2012 at 6:21 AM, Jeff Chua jeff.chua.li...@gmail.com wrote:
 On Fri, Nov 23, 2012 at 9:24 PM, Jens Axboe ax...@kernel.dk wrote:
 On 2012-11-22 20:21, Linus Torvalds wrote:
 Doesn't sound like a fsdevel issue since it seems to be independent of
 filesystems. More like some generic block layer thing. Adding Jens
 (and quoting the whole thing)

 Jens, any ideas? Most of your stuff came in after -rc2, which would
 fit with the fact that most of the slowdown seems to be after -rc2
 according to Jeff.

 No ideas. Looking at what went in from my side, only the rq plug sorting
 is a core change, and that should not cause any change in behaviour for
 a single device. That's commit 975927b9.

 Jeff, more bisecting would be good, though.

 Probably required, yes...


 This one slows mount from 0.012s to 0.168s.

 commit 62ac665ff9fc07497ca524bd20d6a96893d11071
 Author: Mikulas Patocka mpato...@redhat.com
 Date:   Wed Sep 26 07:46:43 2012 +0200

 blockdev: turn a rw semaphore into a percpu rw semaphore


 There were couple of more changes to percpu-rw-semaphores after
 3.7.0-rc2 and those slows mount further from 0.168s to 0.500s. I don't
 really know, but I'm suspecting these. Still bisecting.

 commit 5c1eabe68501d1e1b1586c7f4c46cc531828c4ab
 Author: Mikulas Patocka mpato...@redhat.com
 Date:   Mon Oct 22 19:37:47 2012 -0400

 percpu-rw-semaphores: use light/heavy barriers


 commit 1bf11c53535ab87e3bf14ecdf6747bf46f601c5d
 Author: Mikulas Patocka mpato...@redhat.com
 Date:   Mon Oct 22 19:39:16 2012 -0400

 percpu-rw-semaphores: use rcu_read_lock_sched


 I reverted these 3 patches and mount time is now 0.012s.

 # time mount /dev/sda1 /mnt; sync; sync; umount /mnt


 commit 1a25b1c4ce189e3926f2981f3302352a930086db
 Author: Mikulas Patocka mpato...@redhat.com
 Date:   Mon Oct 15 17:20:17 2012 -0400

 Lock splice_read and splice_write functions

 Looks like this one is not the problem. But I reverted it anyway
 because it's part of the same chunk.


 Happy Thanksgiving!

I'm on latest git 3.7.0-rc6 5e351cdc998db82935d1248a053a1be37d1160fd
and with the above patches reverted and mount time is now 0.012s.

Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel "mount" slow

[Jeff Chua]

On Wed, Nov 21, 2012 at 11:46 PM, Jeff Chua  wrote:
> On Wed, Nov 21, 2012 at 2:09 AM, Jan Kara  wrote:
>>   I haven't heard about such problem so far. What filesystem are you using?
>
> I've tried ext2/ext3/ext4/reiserfs/btrfs ... all seems to be slower
> than before. Seems to be fs independent.
>
>> Can you quantify 'is slower'? Bisecting would be welcome of course.
>
> Haven't measure, but it seems to be 1 sec instead of .3 sec to mount.
> I'll start bisecting:(
> So, since I've 6 mounts on start up, now it takes 4 seconds longer to boot up.

I started bisecting, and it seems to have multiple points of slowing
down. The latest kernel is really slow mounting /dev/sda1 (fs
independent) ... 0.529sec. Kernel 3.6.0 took 0.012sec, Kernel
3.7.0-rc2 took 0.168sec. Again, these are very early results. I'm
verifying them again.


Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel mount slow

[Jeff Chua]

On Wed, Nov 21, 2012 at 11:46 PM, Jeff Chua jeff.chua.li...@gmail.com wrote:
 On Wed, Nov 21, 2012 at 2:09 AM, Jan Kara j...@suse.cz wrote:
   I haven't heard about such problem so far. What filesystem are you using?

 I've tried ext2/ext3/ext4/reiserfs/btrfs ... all seems to be slower
 than before. Seems to be fs independent.

 Can you quantify 'is slower'? Bisecting would be welcome of course.

 Haven't measure, but it seems to be 1 sec instead of .3 sec to mount.
 I'll start bisecting:(
 So, since I've 6 mounts on start up, now it takes 4 seconds longer to boot up.

I started bisecting, and it seems to have multiple points of slowing
down. The latest kernel is really slow mounting /dev/sda1 (fs
independent) ... 0.529sec. Kernel 3.6.0 took 0.012sec, Kernel
3.7.0-rc2 took 0.168sec. Again, these are very early results. I'm
verifying them again.


Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel "mount" slow

[Jeff Chua]

On Wed, Nov 21, 2012 at 2:09 AM, Jan Kara  wrote:
>   I haven't heard about such problem so far. What filesystem are you using?

I've tried ext2/ext3/ext4/reiserfs/btrfs ... all seems to be slower
than before. Seems to be fs independent.

> Can you quantify 'is slower'? Bisecting would be welcome of course.

Haven't measure, but it seems to be 1 sec instead of .3 sec to mount.
I'll start bisecting:(
So, since I've 6 mounts on start up, now it takes 4 seconds longer to boot up.

Thanks,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Recent kernel mount slow

[Jeff Chua]

On Wed, Nov 21, 2012 at 2:09 AM, Jan Kara j...@suse.cz wrote:
   I haven't heard about such problem so far. What filesystem are you using?

I've tried ext2/ext3/ext4/reiserfs/btrfs ... all seems to be slower
than before. Seems to be fs independent.

 Can you quantify 'is slower'? Bisecting would be welcome of course.

Haven't measure, but it seems to be 1 sec instead of .3 sec to mount.
I'll start bisecting:(
So, since I've 6 mounts on start up, now it takes 4 seconds longer to boot up.

Thanks,
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Recent kernel "mount" slow

[Jeff Chua]

It seems the recent kernel is slower mounting hard disk than older
kernels. I've not bisect down to exact when this happen as it might
already been reported or solved. I'm on the latest commit, but it
doesn't seems to be fixed yet.

commit 3587b1b097d70c2eb9fee95ea7995d13c05f66e5
Author: Al Viro 
Date:   Sun Nov 18 19:19:00 2012 +

fanotify: fix FAN_Q_OVERFLOW case of fanotify_read()


Thanks,
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Recent kernel mount slow

[Jeff Chua]

It seems the recent kernel is slower mounting hard disk than older
kernels. I've not bisect down to exact when this happen as it might
already been reported or solved. I'm on the latest commit, but it
doesn't seems to be fixed yet.

commit 3587b1b097d70c2eb9fee95ea7995d13c05f66e5
Author: Al Viro v...@zeniv.linux.org.uk
Date:   Sun Nov 18 19:19:00 2012 +

fanotify: fix FAN_Q_OVERFLOW case of fanotify_read()


Thanks,
Jeff
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p - resume hang

[Jeff Chua]

On Tue, Feb 26, 2008 at 4:45 AM, Michael S. Tsirkin 
<[EMAIL PROTECTED]> wrote:
On Mon, Feb 25, 2008 at 9:46 PM, Andrew Morton 

<[EMAIL PROTECTED]> wrote:
> On Mon, 25 Feb 2008 21:19:24 +0200 "Michael S. Tsirkin" 

<[EMAIL PROTECTED]> wrote:

 >  You mean suspend-to-ram works correctly on your t61p?
 >  Mine suspends, then five seconds later magically resumes itself and 

the

 >  screen is all black.
 Sorry, have not noticed what you were asking about.
 Yes, rc2 seems to suspend/resume fine.
 And after reverting
 revert commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2.


commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2
Author: Pavel Machek <[EMAIL PROTECTED]>
Date:   Thu Feb 21 13:56:55 2008 +0100

power_state: get rid of write-only variable in SATA

power_state is scheduled for removal, and libata uses it in write-only
mode. Remove it.

Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>


I'm experiencing hang after resume from STR with the latest Linus's git 
tree. Reverting the above patch solved the problem.



Thanks,
Jeff


Here's the patch for reference ...


diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4cf8662..9812bbf 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6560,8 +6560,6 @@ int ata_host_suspend(struct ata_host *host, pm_message_t 
mesg)
ata_lpm_enable(host);

rc = ata_host_request_pm(host, mesg, 0, ATA_EHI_QUIET, 1);
-   if (rc == 0)
-   host->dev->power.power_state = mesg;
return rc;
 }

@@ -6580,7 +6578,6 @@ void ata_host_resume(struct ata_host *host)
 {
ata_host_request_pm(host, PMSG_ON, ATA_EH_SOFTRESET,
ATA_EHI_NO_AUTOPSY | ATA_EHI_QUIET, 0);
-   host->dev->power.power_state = PMSG_ON;

/* reenable link pm */
ata_lpm_disable(host);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: new regression in 2.6.25-rc3: no keyboard/lid acpi events on thinkpad T61p - resume hang

[Jeff Chua]

On Tue, Feb 26, 2008 at 4:45 AM, Michael S. Tsirkin 
[EMAIL PROTECTED] wrote:
On Mon, Feb 25, 2008 at 9:46 PM, Andrew Morton 

[EMAIL PROTECTED] wrote:
 On Mon, 25 Feb 2008 21:19:24 +0200 Michael S. Tsirkin 

[EMAIL PROTECTED] wrote:

   You mean suspend-to-ram works correctly on your t61p?
   Mine suspends, then five seconds later magically resumes itself and 

the

   screen is all black.
 Sorry, have not noticed what you were asking about.
 Yes, rc2 seems to suspend/resume fine.
 And after reverting
 revert commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2.


commit 559bbe6cbd0d8c68d40076a5f7dc98e3bf5864b2
Author: Pavel Machek [EMAIL PROTECTED]
Date:   Thu Feb 21 13:56:55 2008 +0100

power_state: get rid of write-only variable in SATA

power_state is scheduled for removal, and libata uses it in write-only
mode. Remove it.

Signed-off-by: Pavel Machek [EMAIL PROTECTED]
Signed-off-by: Jeff Garzik [EMAIL PROTECTED]


I'm experiencing hang after resume from STR with the latest Linus's git 
tree. Reverting the above patch solved the problem.



Thanks,
Jeff


Here's the patch for reference ...


diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 4cf8662..9812bbf 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -6560,8 +6560,6 @@ int ata_host_suspend(struct ata_host *host, pm_message_t 
mesg)
ata_lpm_enable(host);

rc = ata_host_request_pm(host, mesg, 0, ATA_EHI_QUIET, 1);
-   if (rc == 0)
-   host-dev-power.power_state = mesg;
return rc;
 }

@@ -6580,7 +6578,6 @@ void ata_host_resume(struct ata_host *host)
 {
ata_host_request_pm(host, PMSG_ON, ATA_EH_SOFTRESET,
ATA_EHI_NO_AUTOPSY | ATA_EHI_QUIET, 0);
-   host-dev-power.power_state = PMSG_ON;

/* reenable link pm */
ata_lpm_disable(host);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM: Introduce PM_EVENT_HIBERNATE (was: Re: i915 hibernation patch (was: Re: 2.6.25-rc2 System no longer ...))

[Jeff Chua]

On Sun, Feb 24, 2008 at 2:43 AM, Linus Torvalds
<[EMAIL PROTECTED]> wrote:
>
>
>  On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
>  >
>
> > Thanks for testing.  Below is the final version of the patch with a 
> > changelog
>  > etc.
>
>  Thanks, applied.
>
>  With this, I also find that I dislike the use of suspend/resume for
>  freezing for STD a lot less. It's still too easy to get confused, but at
>  least now drivers always have total knowledge about what is really going
>  on. I'd not like this interface as a driver writer, but now it's not
>  fundamentally broken any more, just slightly confusing.

Tested and working.

Thanks again,
Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM: Introduce PM_EVENT_HIBERNATE (was: Re: i915 hibernation patch (was: Re: 2.6.25-rc2 System no longer ...))

[Jeff Chua]

On Sun, Feb 24, 2008 at 2:43 AM, Linus Torvalds
[EMAIL PROTECTED] wrote:


  On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
  

  Thanks for testing.  Below is the final version of the patch with a 
  changelog
   etc.

  Thanks, applied.

  With this, I also find that I dislike the use of suspend/resume for
  freezing for STD a lot less. It's still too easy to get confused, but at
  least now drivers always have total knowledge about what is really going
  on. I'd not like this interface as a driver writer, but now it's not
  fundamentally broken any more, just slightly confusing.

Tested and working.

Thanks again,
Jeff.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 hibernation patch (was: Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.)

[Jeff Chua]

On Sat, Feb 23, 2008 at 10:07 AM, Linus Torvalds
<[EMAIL PROTECTED]> wrote:

>  On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
>  > OK, please have a look at the modified patch below.
>
>  All right, I'm fine with it. Now we just need to confirm that it works for
>  people..

Looks good. Applied Rafael patch on top of your latest git tree that
has Jesse's i915 fix.

No green screen. Tested with STD (platform), STR, and plain echo mem >
/sys/power/state.

Thanks,
Jeff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: i915 hibernation patch (was: Re: [Suspend-devel] 2.6.25-rc2 System no longer powers off aftersuspend-to-disk. Screen becomes green.)

[Jeff Chua]

On Sat, Feb 23, 2008 at 10:07 AM, Linus Torvalds
[EMAIL PROTECTED] wrote:

  On Sat, 23 Feb 2008, Rafael J. Wysocki wrote:
   OK, please have a look at the modified patch below.

  All right, I'm fine with it. Now we just need to confirm that it works for
  people..

Looks good. Applied Rafael patch on top of your latest git tree that
has Jesse's i915 fix.

No green screen. Tested with STD (platform), STR, and plain echo mem 
/sys/power/state.

Thanks,
Jeff.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/