Re: [PATCH] HID: i2c-hid: Prevent sending reports from racing with device reset

[Nish Aravamudan]

On Mon, Dec 21, 2015 at 5:26 AM, Mika Westerberg
 wrote:

> Below is what happens to touchpad on Lenovo Yoga 900 during resume from
> system sleep:



> Reported-by: Nish Aravamudan 
> Reported-by: Linus Torvalds 
> Suggested-by: Benjamin Tissoires 
> Signed-off-by: Mika Westerberg 

Probably not necessary, but this can be updated to

Reported-and-tested-by: Nish Aravamudan 

-Nish
--
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] HID: i2c-hid: Prevent sending reports from racing with device reset

[Nish Aravamudan]

On Mon, Dec 21, 2015 at 5:26 AM, Mika Westerberg
<mika.westerb...@linux.intel.com> wrote:

> Below is what happens to touchpad on Lenovo Yoga 900 during resume from
> system sleep:



> Reported-by: Nish Aravamudan <nish.aravamu...@gmail.com>
> Reported-by: Linus Torvalds <torva...@linux-foundation.org>
> Suggested-by: Benjamin Tissoires <benjamin.tissoi...@redhat.com>
> Signed-off-by: Mika Westerberg <mika.westerb...@linux.intel.com>

Probably not necessary, but this can be updated to

Reported-and-tested-by: Nish Aravamudan <nish.aravamu...@gmail.com>

-Nish
--
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: [RESEND] Lenovo Yoga 900 touchpad issues

[Nish Aravamudan]

On Fri, Dec 18, 2015 at 7:38 AM, Mika Westerberg
 wrote:
> On Fri, Dec 18, 2015 at 04:42:09PM +0200, Mika Westerberg wrote:
>> On another occasion the faulty input report was received immediatelly
>> after we call i2c_hid_set_power().
>>
>> With below hack patch suspend/resume works fine but it is far from being
>> suitable for merging. Still, it would be nice if you could try it out
>> and see if it helps in your case.
>
> Actually it looks like we can handle this by just ignoring input reports
> while we are resetting the device. Following seems to work as well.

FWIW,

Tested-by: Nishanth Aravamudan 

and if you can Cc me on any follow-up/alternative patches, I will be
happy to test those too!

Thanks!
-Nish

> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> index 10bd8e6..eeaf33a 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -352,13 +352,24 @@ static int i2c_hid_set_power(struct i2c_client *client, 
> int power_state)
>  static int i2c_hid_hwreset(struct i2c_client *client)
>  {
> struct i2c_hid *ihid = i2c_get_clientdata(client);
> +   bool started;
> int ret;
>
> i2c_hid_dbg(ihid, "%s\n", __func__);
>
> +   /*
> +* Some touchpads seem to send input reports once their power is
> +* turned back on after resume. This confuses our reset logic
> +* below.
> +*
> +* Prevent handling any input reports while we are resetting the
> +* device.
> +*/
> +   started = test_and_clear_bit(I2C_HID_STARTED, >flags);
> +
> ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
> if (ret)
> -   return ret;
> +   goto out;
>
> i2c_hid_dbg(ihid, "resetting...\n");
>
> @@ -366,10 +377,14 @@ static int i2c_hid_hwreset(struct i2c_client *client)
> if (ret) {
> dev_err(>dev, "failed to reset device.\n");
> i2c_hid_set_power(client, I2C_HID_PWR_SLEEP);
> -   return ret;
> +   goto out;
> }
>
> -   return 0;
> +out:
> +   if (started)
> +   set_bit(I2C_HID_STARTED, >flags);
> +
> +   return ret;
>  }
>
>  static void i2c_hid_get_input(struct i2c_hid *ihid)
--
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: [RESEND] Lenovo Yoga 900 touchpad issues

[Nish Aravamudan]

On Fri, Dec 18, 2015 at 7:38 AM, Mika Westerberg
 wrote:
> On Fri, Dec 18, 2015 at 04:42:09PM +0200, Mika Westerberg wrote:
>> On another occasion the faulty input report was received immediatelly
>> after we call i2c_hid_set_power().
>>
>> With below hack patch suspend/resume works fine but it is far from being
>> suitable for merging. Still, it would be nice if you could try it out
>> and see if it helps in your case.
>
> Actually it looks like we can handle this by just ignoring input reports
> while we are resetting the device. Following seems to work as well.

FWIW,

Tested-by: Nishanth Aravamudan 

and if you can Cc me on any follow-up/alternative patches, I will be
happy to test those too!

Thanks!
-Nish

> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
> index 10bd8e6..eeaf33a 100644
> --- a/drivers/hid/i2c-hid/i2c-hid.c
> +++ b/drivers/hid/i2c-hid/i2c-hid.c
> @@ -352,13 +352,24 @@ static int i2c_hid_set_power(struct i2c_client *client, 
> int power_state)
>  static int i2c_hid_hwreset(struct i2c_client *client)
>  {
> struct i2c_hid *ihid = i2c_get_clientdata(client);
> +   bool started;
> int ret;
>
> i2c_hid_dbg(ihid, "%s\n", __func__);
>
> +   /*
> +* Some touchpads seem to send input reports once their power is
> +* turned back on after resume. This confuses our reset logic
> +* below.
> +*
> +* Prevent handling any input reports while we are resetting the
> +* device.
> +*/
> +   started = test_and_clear_bit(I2C_HID_STARTED, >flags);
> +
> ret = i2c_hid_set_power(client, I2C_HID_PWR_ON);
> if (ret)
> -   return ret;
> +   goto out;
>
> i2c_hid_dbg(ihid, "resetting...\n");
>
> @@ -366,10 +377,14 @@ static int i2c_hid_hwreset(struct i2c_client *client)
> if (ret) {
> dev_err(>dev, "failed to reset device.\n");
> i2c_hid_set_power(client, I2C_HID_PWR_SLEEP);
> -   return ret;
> +   goto out;
> }
>
> -   return 0;
> +out:
> +   if (started)
> +   set_bit(I2C_HID_STARTED, >flags);
> +
> +   return ret;
>  }
>
>  static void i2c_hid_get_input(struct i2c_hid *ihid)
--
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: iio/hid-sensor-accel-3d: no output from /dev/iio:device*?

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 6:50 PM, Pandruvada, Srinivas
 wrote:
> On Thu, 2015-12-17 at 18:33 -0800, Nish Aravamudan wrote:
>> On Thu, Dec 17, 2015 at 5:11 PM, Pandruvada, Srinivas
>>  wrote:
>> > On Thu, 2015-12-17 at 17:08 -0800, Nish Aravamudan wrote:
>> > > On Thu, Dec 17, 2015 at 5:00 PM, Pandruvada, Srinivas
>> > >  wrote:
>> > > > Hi Andy,
>> > > >
>> > > > As per Nish these patches are impacting sensors on Yoga.
>> > > > https://lkml.org/lkml/2015/11/30/441
>> > >
>> > > To be clear, without that series, the touchpad and touchscreen on
>> > > the
>> > > Yoga 900 don't work at all. So they are necessary for
>> > > functioning. I
>> > > don't know (I will test it now), if removing the series makes the
>> > > IIO
>> > > sensors work properly in /dev/.
>> > This is important to know before we take Andy's time.
>>
>> It seems like Andy's patches are not the problem. That is, with stock
>> 4.4-rc5, the accelerommeter /dev files still do not update.
>>
> Can you not use raw values by polling from user space? Send me
> report description. It should be in
> /sys/kernel/debug/hid/ "your device id" /redesc.

The underlying issue is that iio-sensor-proxy relies on values from
the corresponding /dev nodes to automatically rotate the screen, etc.
in the desktop environment.

Attached due to its size.

> Also device id ("your device id") above.

0018:048D:8396.0002

-Nish


rdesc
Description: Binary data

Re: iio/hid-sensor-accel-3d: no output from /dev/iio:device*?

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 5:11 PM, Pandruvada, Srinivas
 wrote:
> On Thu, 2015-12-17 at 17:08 -0800, Nish Aravamudan wrote:
>> On Thu, Dec 17, 2015 at 5:00 PM, Pandruvada, Srinivas
>>  wrote:
>> > Hi Andy,
>> >
>> > As per Nish these patches are impacting sensors on Yoga.
>> > https://lkml.org/lkml/2015/11/30/441
>>
>> To be clear, without that series, the touchpad and touchscreen on the
>> Yoga 900 don't work at all. So they are necessary for functioning. I
>> don't know (I will test it now), if removing the series makes the IIO
>> sensors work properly in /dev/.
> This is important to know before we take Andy's time.

It seems like Andy's patches are not the problem. That is, with stock
4.4-rc5, the accelerommeter /dev files still do not update.

-Nish
--
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: iio/hid-sensor-accel-3d: no output from /dev/iio:device*?

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 5:16 PM, Srinivas Pandruvada
 wrote:
> On Thu, 2015-12-17 at 17:07 -0800, Nish Aravamudan wrote:
>> On Thu, Dec 17, 2015 at 4:51 PM, Srinivas Pandruvada
>>  wrote:
>> > On Thu, 2015-12-17 at 15:38 -0800, Nish Aravamudan wrote:
>> > > [Starting a new thread from https://lkml.org/lkml/2015/12/15/663,
>> > > as
>> > > now my laptop is displaying values in the sysfs *raw* files.]
>> > >
>> > > So I'm trying to understand exactly how the hid-sensor-accel-3d
>> > > driver works.
>> > >
>> > > If I turn up debugging, when I `cat
>> > > /sys/bus/iio/devices/device*/*raw*`, I see "iio iio:device3:
>> > > accel_3d_proc_event" and I think that means that
>> > > hid_sensor_push_data() is getting called.
>> > >
>> > > But read()'s on /dev/iio:device3 never produces anything, which
>> > > is
>> > > what iio-sensor-proxy uses to translate events to dbus.
>> > >
>> > > Is it expected that the dev-node is "silent"? Just trying to
>> > > understand if an extension to the driver to support a chardev
>> > > based
>> > > output is appropriate, or if iio-sensor-proxy needs to be changed
>> > > to
>> > > handle this device.
>> >
>> > You are saying there is some regression. This used to work and now
>> > it
>> > doesn't work. Is raw values are displayed correctly, when you do
>> > "cat"?
>> > If cat of raw values is working then power on of sensors is
>> > working.
>>
>> Sorry, I was unclear. I don't know if this is a regression. I can try
>> going back to an older kernel to see if the /dev/iio:device* files
>> produced any output.
>>
>> Yes, the *raw* files in sysfs are producing output, that is changing
>> as I move the laptop around. But the /dev/ nodes seem to produce no
>> output (I'm still reading through the driver code to understand where
>> that data should be coming from.
>>
>> > Turn on HID debug prints. If it is regression we can do git bisect.
>> > Any ACPI or PM changes can break this. Usually there will be GPIOs
>> > which will be involved in power on, where ACPI comes into play.
>> > This
>> > will be done by i2c-hid. There are some prints in i2c-hid which can
>> > be
>> > enabled also.
>>
>> Ok, I will try this, as well.
>>
>
> Try increasing in_accel_sampling_frequency
> echo 100 > in_accel_sampling_frequency
> Adjust hysteresis to a low value
> echo 0 > in_accel_hysteresis
> These values are very vendor specific.

Adjusting the values in this way didn't seem to make any difference.
Also, `cat in_accel_hysteresis` gave EINVAL, but I was able to echo 0
to it.

-Nish
--
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: iio/hid-sensor-accel-3d: no output from /dev/iio:device*?

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 5:00 PM, Pandruvada, Srinivas
 wrote:
> Hi Andy,
>
> As per Nish these patches are impacting sensors on Yoga.
> https://lkml.org/lkml/2015/11/30/441

To be clear, without that series, the touchpad and touchscreen on the
Yoga 900 don't work at all. So they are necessary for functioning. I
don't know (I will test it now), if removing the series makes the IIO
sensors work properly in /dev/.

-Nish

> On Thu, 2015-12-17 at 16:51 -0800, Srinivas Pandruvada wrote:
>> On Thu, 2015-12-17 at 15:38 -0800, Nish Aravamudan wrote:
>> > [Starting a new thread from https://lkml.org/lkml/2015/12/15/663,
>> > as
>> > now my laptop is displaying values in the sysfs *raw* files.]
>> >
>> > So I'm trying to understand exactly how the hid-sensor-accel-3d
>> > driver works.
>> >
>> > If I turn up debugging, when I `cat
>> > /sys/bus/iio/devices/device*/*raw*`, I see "iio iio:device3:
>> > accel_3d_proc_event" and I think that means that
>> > hid_sensor_push_data() is getting called.
>> >
>> > But read()'s on /dev/iio:device3 never produces anything, which is
>> > what iio-sensor-proxy uses to translate events to dbus.
>> >
>> > Is it expected that the dev-node is "silent"? Just trying to
>> > understand if an extension to the driver to support a chardev based
>> > output is appropriate, or if iio-sensor-proxy needs to be changed
>> > to
>> > handle this device.
>>
>> You are saying there is some regression. This used to work and now it
>> doesn't work. Is raw values are displayed correctly, when you do
>> "cat"?
>> If cat of raw values is working then power on of sensors is working.
>>
>> Turn on HID debug prints. If it is regression we can do git bisect.
>> Any ACPI or PM changes can break this. Usually there will be GPIOs
>> which will be involved in power on, where ACPI comes into play. This
>> will be done by i2c-hid. There are some prints in i2c-hid which can
>> be
>> enabled also.
>>
>> Thanks,
>> Srinivas
>>
>> >
--
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: iio/hid-sensor-accel-3d: no output from /dev/iio:device*?

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 4:51 PM, Srinivas Pandruvada
 wrote:
> On Thu, 2015-12-17 at 15:38 -0800, Nish Aravamudan wrote:
>> [Starting a new thread from https://lkml.org/lkml/2015/12/15/663, as
>> now my laptop is displaying values in the sysfs *raw* files.]
>>
>> So I'm trying to understand exactly how the hid-sensor-accel-3d
>> driver works.
>>
>> If I turn up debugging, when I `cat
>> /sys/bus/iio/devices/device*/*raw*`, I see "iio iio:device3:
>> accel_3d_proc_event" and I think that means that
>> hid_sensor_push_data() is getting called.
>>
>> But read()'s on /dev/iio:device3 never produces anything, which is
>> what iio-sensor-proxy uses to translate events to dbus.
>>
>> Is it expected that the dev-node is "silent"? Just trying to
>> understand if an extension to the driver to support a chardev based
>> output is appropriate, or if iio-sensor-proxy needs to be changed to
>> handle this device.
>
> You are saying there is some regression. This used to work and now it
> doesn't work. Is raw values are displayed correctly, when you do "cat"?
> If cat of raw values is working then power on of sensors is working.

Sorry, I was unclear. I don't know if this is a regression. I can try
going back to an older kernel to see if the /dev/iio:device* files
produced any output.

Yes, the *raw* files in sysfs are producing output, that is changing
as I move the laptop around. But the /dev/ nodes seem to produce no
output (I'm still reading through the driver code to understand where
that data should be coming from.

> Turn on HID debug prints. If it is regression we can do git bisect.
> Any ACPI or PM changes can break this. Usually there will be GPIOs
> which will be involved in power on, where ACPI comes into play. This
> will be done by i2c-hid. There are some prints in i2c-hid which can be
> enabled also.

Ok, I will try this, as well.

-Nish
--
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/

iio/hid-sensor-accel-3d: no output from /dev/iio:device*?

[Nish Aravamudan]

[Starting a new thread from https://lkml.org/lkml/2015/12/15/663, as
now my laptop is displaying values in the sysfs *raw* files.]

So I'm trying to understand exactly how the hid-sensor-accel-3d driver works.

If I turn up debugging, when I `cat
/sys/bus/iio/devices/device*/*raw*`, I see "iio iio:device3:
accel_3d_proc_event" and I think that means that
hid_sensor_push_data() is getting called.

But read()'s on /dev/iio:device3 never produces anything, which is
what iio-sensor-proxy uses to translate events to dbus.

Is it expected that the dev-node is "silent"? Just trying to
understand if an extension to the driver to support a chardev based
output is appropriate, or if iio-sensor-proxy needs to be changed to
handle this device.

-Nish
--
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: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 12:05 PM, Nish Aravamudan
 wrote:
> On Thu, Dec 17, 2015 at 10:38 AM, Crt Mori  wrote:
>> On 17 December 2015 at 19:10, Nish Aravamudan  
>> wrote:
>>> On Thu, Dec 17, 2015 at 9:32 AM, Nish Aravamudan
>>>  wrote:
>>>> On Thu, Dec 17, 2015 at 12:41 AM, Crt Mori  wrote:
>>>>> On 17 December 2015 at 06:27, Nish Aravamudan  
>>>>> wrote:
>>>>>> On Wed, Dec 16, 2015 at 3:05 PM, Nish Aravamudan
>>>>>>  wrote:
>>>>>>> On Wed, Dec 16, 2015 at 2:55 PM, Crt Mori  wrote:
>>>>>>>>
>>>>>>>> On Dec 16, 2015 11:37 PM, "Nish Aravamudan" 
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori  wrote:
>>>>>>>>> > On 16 December 2015 at 22:41, Nish Aravamudan
>>>>>>>>> >  wrote:
>>>>>>>>> >> Hi Daniel,
>>>>>>>>> >>
>>>>>>>>> >> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta
>>>>>>>>> >>  wrote:
>>>>>>>>> >>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>>>>>>>>> >>>  wrote:
>>>>>>>>> >>>> So, I apologize in advance for this relatively vague report, but 
>>>>>>>>> >>>> I'm
>>>>>>>>> >>>> fairly sure
>>>>>>>>> >>>> the Yoga 900 has an accelerometer amongst other sensors (ambient
>>>>>>>>> >>>> light?)
>>>>>>>>> >>>> exported over IIO.
>>>>>>>>> >>>>
>>>>>>>>> >>>> But, these sensors seem to not be updating at all with a 4.4-rc5+
>>>>>>>>> >>>> kernel (a
>>>>>>>>> >>>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied 
>>>>>>>>> >>>> to
>>>>>>>>> >>>> Linus'
>>>>>>>>> >>>> tree).
>>>>>>>>> >>>>
>>>>>>>>> >>>> The odd part is at some point in messing with this, I'm fairly 
>>>>>>>>> >>>> sure
>>>>>>>>> >>>> it did work!
>>>>>>>>> >>>> That is,
>>>>>>>>> >>>>
>>>>>>>>> >>>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>>>>>>>>> >>>
>>>>>>>>> >>> Can you send us a sample of the output? Also, would be
>>>>>>>>> >>> good to identify the exact driver for accel.
>>>>>>>>> >>
>>>>>>>>> >> cat /sys/bus/iio/devices/iio:device*/*raw*
>>>>>>>>> >> 65478
>>>>>>>>> >> 7
>>>>>>>>> >> 1023
>>>>>>>>> >> 0
>>>>>>>>> >> 0
>>>>>>>>> >> 0
>>>>>>>>> >> 100
>>>>>>>>> >> -539062
>>>>>>>>> >> -742187
>>>>>>>>> >> 1292968
>>>>>>>>> >> 1592
>>>>>>>>> >> 64932
>>>>>>>>> >> 2
>>>>>>>>> >> 275
>>>>>>>>> >> 0 0 0 0
>>>>>>>>> >>
>>>>>>>>> >> Now, I should say that I distinctly remember at some point waving 
>>>>>>>>> >> my
>>>>>>>>> >> laptop around and seeing these values change ... but now they seem 
>>>>>>>>> >> to
>>>>>>>>> >> be "stuck". Maybe it's a hardware issue or something special that
>>>>>>>>> >> WIndows does to leverage the IIO sensors?
>>>>>>>>> >>
>>>>>>>>> >>> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name
>>>>>>>

Re: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 10:38 AM, Crt Mori  wrote:
> On 17 December 2015 at 19:10, Nish Aravamudan  
> wrote:
>> On Thu, Dec 17, 2015 at 9:32 AM, Nish Aravamudan
>>  wrote:
>>> On Thu, Dec 17, 2015 at 12:41 AM, Crt Mori  wrote:
>>>> On 17 December 2015 at 06:27, Nish Aravamudan  
>>>> wrote:
>>>>> On Wed, Dec 16, 2015 at 3:05 PM, Nish Aravamudan
>>>>>  wrote:
>>>>>> On Wed, Dec 16, 2015 at 2:55 PM, Crt Mori  wrote:
>>>>>>>
>>>>>>> On Dec 16, 2015 11:37 PM, "Nish Aravamudan" 
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori  wrote:
>>>>>>>> > On 16 December 2015 at 22:41, Nish Aravamudan
>>>>>>>> >  wrote:
>>>>>>>> >> Hi Daniel,
>>>>>>>> >>
>>>>>>>> >> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta
>>>>>>>> >>  wrote:
>>>>>>>> >>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>>>>>>>> >>>  wrote:
>>>>>>>> >>>> So, I apologize in advance for this relatively vague report, but 
>>>>>>>> >>>> I'm
>>>>>>>> >>>> fairly sure
>>>>>>>> >>>> the Yoga 900 has an accelerometer amongst other sensors (ambient
>>>>>>>> >>>> light?)
>>>>>>>> >>>> exported over IIO.
>>>>>>>> >>>>
>>>>>>>> >>>> But, these sensors seem to not be updating at all with a 4.4-rc5+
>>>>>>>> >>>> kernel (a
>>>>>>>> >>>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied 
>>>>>>>> >>>> to
>>>>>>>> >>>> Linus'
>>>>>>>> >>>> tree).
>>>>>>>> >>>>
>>>>>>>> >>>> The odd part is at some point in messing with this, I'm fairly 
>>>>>>>> >>>> sure
>>>>>>>> >>>> it did work!
>>>>>>>> >>>> That is,
>>>>>>>> >>>>
>>>>>>>> >>>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>>>>>>>> >>>
>>>>>>>> >>> Can you send us a sample of the output? Also, would be
>>>>>>>> >>> good to identify the exact driver for accel.
>>>>>>>> >>
>>>>>>>> >> cat /sys/bus/iio/devices/iio:device*/*raw*
>>>>>>>> >> 65478
>>>>>>>> >> 7
>>>>>>>> >> 1023
>>>>>>>> >> 0
>>>>>>>> >> 0
>>>>>>>> >> 0
>>>>>>>> >> 100
>>>>>>>> >> -539062
>>>>>>>> >> -742187
>>>>>>>> >> 1292968
>>>>>>>> >> 1592
>>>>>>>> >> 64932
>>>>>>>> >> 2
>>>>>>>> >> 275
>>>>>>>> >> 0 0 0 0
>>>>>>>> >>
>>>>>>>> >> Now, I should say that I distinctly remember at some point waving my
>>>>>>>> >> laptop around and seeing these values change ... but now they seem 
>>>>>>>> >> to
>>>>>>>> >> be "stuck". Maybe it's a hardware issue or something special that
>>>>>>>> >> WIndows does to leverage the IIO sensors?
>>>>>>>> >>
>>>>>>>> >>> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name
>>>>>>>> >>
>>>>>>>> >> $ cat /sys/bus/iio/devices/iio:device*/name
>>>>>>>> >> accel_3d
>>>>>>>> >
>>>>>>>> > Can you list the directory of iio:device with this name (it is:
>>>>>>>> > drivers/iio/accel/hid-sensor-accel-3d.c).
>>>&g

Re: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 9:32 AM, Nish Aravamudan
 wrote:
> On Thu, Dec 17, 2015 at 12:41 AM, Crt Mori  wrote:
>> On 17 December 2015 at 06:27, Nish Aravamudan  
>> wrote:
>>> On Wed, Dec 16, 2015 at 3:05 PM, Nish Aravamudan
>>>  wrote:
>>>> On Wed, Dec 16, 2015 at 2:55 PM, Crt Mori  wrote:
>>>>>
>>>>> On Dec 16, 2015 11:37 PM, "Nish Aravamudan" 
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori  wrote:
>>>>>> > On 16 December 2015 at 22:41, Nish Aravamudan
>>>>>> >  wrote:
>>>>>> >> Hi Daniel,
>>>>>> >>
>>>>>> >> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta
>>>>>> >>  wrote:
>>>>>> >>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>>>>>> >>>  wrote:
>>>>>> >>>> So, I apologize in advance for this relatively vague report, but I'm
>>>>>> >>>> fairly sure
>>>>>> >>>> the Yoga 900 has an accelerometer amongst other sensors (ambient
>>>>>> >>>> light?)
>>>>>> >>>> exported over IIO.
>>>>>> >>>>
>>>>>> >>>> But, these sensors seem to not be updating at all with a 4.4-rc5+
>>>>>> >>>> kernel (a
>>>>>> >>>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied to
>>>>>> >>>> Linus'
>>>>>> >>>> tree).
>>>>>> >>>>
>>>>>> >>>> The odd part is at some point in messing with this, I'm fairly sure
>>>>>> >>>> it did work!
>>>>>> >>>> That is,
>>>>>> >>>>
>>>>>> >>>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>>>>>> >>>
>>>>>> >>> Can you send us a sample of the output? Also, would be
>>>>>> >>> good to identify the exact driver for accel.
>>>>>> >>
>>>>>> >> cat /sys/bus/iio/devices/iio:device*/*raw*
>>>>>> >> 65478
>>>>>> >> 7
>>>>>> >> 1023
>>>>>> >> 0
>>>>>> >> 0
>>>>>> >> 0
>>>>>> >> 100
>>>>>> >> -539062
>>>>>> >> -742187
>>>>>> >> 1292968
>>>>>> >> 1592
>>>>>> >> 64932
>>>>>> >> 2
>>>>>> >> 275
>>>>>> >> 0 0 0 0
>>>>>> >>
>>>>>> >> Now, I should say that I distinctly remember at some point waving my
>>>>>> >> laptop around and seeing these values change ... but now they seem to
>>>>>> >> be "stuck". Maybe it's a hardware issue or something special that
>>>>>> >> WIndows does to leverage the IIO sensors?
>>>>>> >>
>>>>>> >>> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name
>>>>>> >>
>>>>>> >> $ cat /sys/bus/iio/devices/iio:device*/name
>>>>>> >> accel_3d
>>>>>> >
>>>>>> > Can you list the directory of iio:device with this name (it is:
>>>>>> > drivers/iio/accel/hid-sensor-accel-3d.c).
>>>>>> > This is something you will be looking at for accel debugging, but it
>>>>>> > seems more like
>>>>>> > standard
>>>>>>
>>>>>> /sys/bus/iio/devices/iio:device0/name
>>>>>> gyro_3d
>>>>>> /sys/bus/iio/devices/iio:device1/name
>>>>>> dev_rotation
>>>>>> /sys/bus/iio/devices/iio:device2/name
>>>>>> als
>>>>>> /sys/bus/iio/devices/iio:device3/name
>>>>>> magn_3d
>>>>>> /sys/bus/iio/devices/iio:device4/name
>>>>>> accel_3d
>>>>>> /sys/bus/iio/devices/iio:device5/name
>>>>>> incli_3d
>>>>>>
>>>>>> are all the IIO sensors, sorry about that!
>>>>>>
>>>>>

Re: [RESEND] Lenovo Yoga 900 touchpad issues

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 9:28 AM, Benjamin Tissoires
 wrote:
> On Dec 17 2015 or thereabouts, Nish Aravamudan wrote:
>> Hi Benjamin,
>>
>> On Thu, Dec 17, 2015 at 1:53 AM, Benjamin Tissoires
>>  wrote:
>> > On Dec 16 2015 or thereabouts, Nish Aravamudan wrote:
>> >> Hi Jiri,
>> >>
>> >> On Wed, Dec 16, 2015 at 5:18 AM, Jiri Kosina  wrote:
>> >> > On Wed, 16 Dec 2015, Mika Westerberg wrote:
>> >> >
>> >> >> > [Apologies for the resend, didn't realize I hadn't changed my GMail 
>> >> >> > settings
>> >> >> > to not use HTML.]
>> >> >> >
>> >> >> > I have recently purchased a Lenovo Yoga 900 and most everything is 
>> >> >> > working
>> >> >> > with a slightly modified 4.4-rc5 
>> >> >> > (https://lkml.org/lkml/2015/11/30/441 applied
>> >> >> > to enable the touchpad itself), I am seeing two issues:
>> >> >> >
>> >> >> > 1) On suspend/resume, the touchpad is non-functional. A `modprobe -r 
>> >> >> > i2c-hid;
>> >> >> >  modprobe i2c-hid` "fixes" it.
>> >> >> >
>> >> >> > The kernel emits:
>> >> >> >
>> >> >> > i2c_hid i2c-SYNA2B29:00: failed to reset device.
>> >> >> > dpm_run_callback(): i2c_hid_resume+0x0/0xc0 [i2c_hid] returns -61
>> >> >> > PM: Device i2c-SYNA2B29:00 failed to resume: error -61
>> >> >> >
>> >> >> > During the resume. So perhaps this is a timing issue (given that once
>> >> >> > resumed, the
>> >> >> > module reload does work?).
>> >> >>
>> >> >> Linus noticed this as well and Jiri suggested the below patch which
>> >> >> seemed to fix the issue (although it increased resume time a bit).
>> >> >>
>> >> >> I was supposed to get one Lenovo Yoga 900 here to debug this issue but
>> >> >> I'm still waiting for it (sloow big corporation bureaucracy takes some
>> >> >> time to get things purchased outside).
>> >> >>
>> >> >> diff --git a/drivers/hid/i2c-hid/i2c-hid.c 
>> >> >> b/drivers/hid/i2c-hid/i2c-hid.c
>> >> >> index 55d8f9d..52dd03a0 100644
>> >> >> --- a/drivers/hid/i2c-hid/i2c-hid.c
>> >> >> +++ b/drivers/hid/i2c-hid/i2c-hid.c
>> >> >> @@ -1121,10 +1121,16 @@ static int i2c_hid_resume(struct device *dev)
>> >> >>   struct i2c_client *client = to_i2c_client(dev);
>> >> >>   struct i2c_hid *ihid = i2c_get_clientdata(client);
>> >> >>   struct hid_device *hid = ihid->hid;
>> >> >> - int wake_status;
>> >> >> + int wake_status, tries = 3;
>> >> >>
>> >> >>   enable_irq(ihid->irq);
>> >> >> - ret = i2c_hid_hwreset(client);
>> >> >> +
>> >> >> + do {
>> >> >> + ret = i2c_hid_hwreset(client);
>> >> >> + if (ret)
>> >> >> + msleep(1000);
>> >> >> + } while (tries-- > 0 && ret);
>> >> >> +
>> >> >>   if (ret)
>> >> >>   return ret;
>> >> >
>> >> > As a possible alternative, please test the patch above on top of 
>> >> > for-next
>> >> > branch of
>> >> >
>> >> > git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git
>> >> >
>> >> > It contains 64bebefcf3 ("HID: enable hid device to suspend/resume
>> >> > asynchronously") and knowing whether that changes something might be
>> >> > interesting datapoint as well.
>> >>
>> >> What should I be looking for to be different wrt. that tree? Should I
>> >> not see the failure to reset the device? Or would it be (relatively)
>> >> speedier than the stock kernel?
>> >>
>> >
>> > Basically, does the resume time gets better? Linus experienced something
>> > like 9 secs of resume before this patch, and now I hope it should be
>> > saner (the touchpad might still be a little bit long to respond).
>> >
>> > Also, we have a bug re

Re: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 12:41 AM, Crt Mori  wrote:
> On 17 December 2015 at 06:27, Nish Aravamudan  
> wrote:
>> On Wed, Dec 16, 2015 at 3:05 PM, Nish Aravamudan
>>  wrote:
>>> On Wed, Dec 16, 2015 at 2:55 PM, Crt Mori  wrote:
>>>>
>>>> On Dec 16, 2015 11:37 PM, "Nish Aravamudan" 
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori  wrote:
>>>>> > On 16 December 2015 at 22:41, Nish Aravamudan
>>>>> >  wrote:
>>>>> >> Hi Daniel,
>>>>> >>
>>>>> >> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta
>>>>> >>  wrote:
>>>>> >>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>>>>> >>>  wrote:
>>>>> >>>> So, I apologize in advance for this relatively vague report, but I'm
>>>>> >>>> fairly sure
>>>>> >>>> the Yoga 900 has an accelerometer amongst other sensors (ambient
>>>>> >>>> light?)
>>>>> >>>> exported over IIO.
>>>>> >>>>
>>>>> >>>> But, these sensors seem to not be updating at all with a 4.4-rc5+
>>>>> >>>> kernel (a
>>>>> >>>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied to
>>>>> >>>> Linus'
>>>>> >>>> tree).
>>>>> >>>>
>>>>> >>>> The odd part is at some point in messing with this, I'm fairly sure
>>>>> >>>> it did work!
>>>>> >>>> That is,
>>>>> >>>>
>>>>> >>>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>>>>> >>>
>>>>> >>> Can you send us a sample of the output? Also, would be
>>>>> >>> good to identify the exact driver for accel.
>>>>> >>
>>>>> >> cat /sys/bus/iio/devices/iio:device*/*raw*
>>>>> >> 65478
>>>>> >> 7
>>>>> >> 1023
>>>>> >> 0
>>>>> >> 0
>>>>> >> 0
>>>>> >> 100
>>>>> >> -539062
>>>>> >> -742187
>>>>> >> 1292968
>>>>> >> 1592
>>>>> >> 64932
>>>>> >> 2
>>>>> >> 275
>>>>> >> 0 0 0 0
>>>>> >>
>>>>> >> Now, I should say that I distinctly remember at some point waving my
>>>>> >> laptop around and seeing these values change ... but now they seem to
>>>>> >> be "stuck". Maybe it's a hardware issue or something special that
>>>>> >> WIndows does to leverage the IIO sensors?
>>>>> >>
>>>>> >>> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name
>>>>> >>
>>>>> >> $ cat /sys/bus/iio/devices/iio:device*/name
>>>>> >> accel_3d
>>>>> >
>>>>> > Can you list the directory of iio:device with this name (it is:
>>>>> > drivers/iio/accel/hid-sensor-accel-3d.c).
>>>>> > This is something you will be looking at for accel debugging, but it
>>>>> > seems more like
>>>>> > standard
>>>>>
>>>>> /sys/bus/iio/devices/iio:device0/name
>>>>> gyro_3d
>>>>> /sys/bus/iio/devices/iio:device1/name
>>>>> dev_rotation
>>>>> /sys/bus/iio/devices/iio:device2/name
>>>>> als
>>>>> /sys/bus/iio/devices/iio:device3/name
>>>>> magn_3d
>>>>> /sys/bus/iio/devices/iio:device4/name
>>>>> accel_3d
>>>>> /sys/bus/iio/devices/iio:device5/name
>>>>> incli_3d
>>>>>
>>>>> are all the IIO sensors, sorry about that!
>>>>>
>>>>
>>>> I was more thinking what else is in iio:device4 directory, so that we can
>>>> see if it was initialized OK. Can you also grep the dmesg for any errors?
>>>
>>> Well, I just noticed the device #s are not consistent boot-to-boot, so
>>> this time it was device0. Trimming out the directories:
>>>
>
> This is correct/intended. You need to confirm "d

Re: [RESEND] Lenovo Yoga 900 touchpad issues

[Nish Aravamudan]

Hi Benjamin,

On Thu, Dec 17, 2015 at 1:53 AM, Benjamin Tissoires
 wrote:
> On Dec 16 2015 or thereabouts, Nish Aravamudan wrote:
>> Hi Jiri,
>>
>> On Wed, Dec 16, 2015 at 5:18 AM, Jiri Kosina  wrote:
>> > On Wed, 16 Dec 2015, Mika Westerberg wrote:
>> >
>> >> > [Apologies for the resend, didn't realize I hadn't changed my GMail 
>> >> > settings
>> >> > to not use HTML.]
>> >> >
>> >> > I have recently purchased a Lenovo Yoga 900 and most everything is 
>> >> > working
>> >> > with a slightly modified 4.4-rc5 (https://lkml.org/lkml/2015/11/30/441 
>> >> > applied
>> >> > to enable the touchpad itself), I am seeing two issues:
>> >> >
>> >> > 1) On suspend/resume, the touchpad is non-functional. A `modprobe -r 
>> >> > i2c-hid;
>> >> >  modprobe i2c-hid` "fixes" it.
>> >> >
>> >> > The kernel emits:
>> >> >
>> >> > i2c_hid i2c-SYNA2B29:00: failed to reset device.
>> >> > dpm_run_callback(): i2c_hid_resume+0x0/0xc0 [i2c_hid] returns -61
>> >> > PM: Device i2c-SYNA2B29:00 failed to resume: error -61
>> >> >
>> >> > During the resume. So perhaps this is a timing issue (given that once
>> >> > resumed, the
>> >> > module reload does work?).
>> >>
>> >> Linus noticed this as well and Jiri suggested the below patch which
>> >> seemed to fix the issue (although it increased resume time a bit).
>> >>
>> >> I was supposed to get one Lenovo Yoga 900 here to debug this issue but
>> >> I'm still waiting for it (sloow big corporation bureaucracy takes some
>> >> time to get things purchased outside).
>> >>
>> >> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
>> >> index 55d8f9d..52dd03a0 100644
>> >> --- a/drivers/hid/i2c-hid/i2c-hid.c
>> >> +++ b/drivers/hid/i2c-hid/i2c-hid.c
>> >> @@ -1121,10 +1121,16 @@ static int i2c_hid_resume(struct device *dev)
>> >>   struct i2c_client *client = to_i2c_client(dev);
>> >>   struct i2c_hid *ihid = i2c_get_clientdata(client);
>> >>   struct hid_device *hid = ihid->hid;
>> >> - int wake_status;
>> >> + int wake_status, tries = 3;
>> >>
>> >>   enable_irq(ihid->irq);
>> >> - ret = i2c_hid_hwreset(client);
>> >> +
>> >> + do {
>> >> + ret = i2c_hid_hwreset(client);
>> >> + if (ret)
>> >> + msleep(1000);
>> >> + } while (tries-- > 0 && ret);
>> >> +
>> >>   if (ret)
>> >>   return ret;
>> >
>> > As a possible alternative, please test the patch above on top of for-next
>> > branch of
>> >
>> > git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git
>> >
>> > It contains 64bebefcf3 ("HID: enable hid device to suspend/resume
>> > asynchronously") and knowing whether that changes something might be
>> > interesting datapoint as well.
>>
>> What should I be looking for to be different wrt. that tree? Should I
>> not see the failure to reset the device? Or would it be (relatively)
>> speedier than the stock kernel?
>>
>
> Basically, does the resume time gets better? Linus experienced something
> like 9 secs of resume before this patch, and now I hope it should be
> saner (the touchpad might still be a little bit long to respond).
>
> Also, we have a bug report concerning this laptop and it looks like the
> i2c controller needs to be updated (see
> https://bugzilla.redhat.com/show_bug.cgi?id=1275718).
>
> I am not entirely sure why those on the rhbz needs to update the i2c
> controller while you don't have to, but it may also be worth checking if
> the i2c patch series mentioned in this rhbz (comment #20) fixes by itself
> the resume issue (without Jiri's patch).

Yep, I applied the series from https://lkml.org/lkml/2015/11/30/441
already. Without that series, I don't have a working touchscreen and
touchpad. Touchpad resume doesn't work with just that series.

With that series + Jiri's patch it seems to resume pretty quickly. But
I guess I don't see exactly what would change with the resume if the
same loop is present on top of hid:for-next? Still on my list to test,
though.

Also, even with that series, there does appear maybe there is an I2C
issue, though:

i2c_hid i2c-ITE8396:00: error in i2c_hid_init_report size:19 / ret_size:18

as I mentioned in my first e-mail; which might be affecting the IIO sensors?

-Nish
--
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: [RESEND] Lenovo Yoga 900 touchpad issues

[Nish Aravamudan]

Hi Benjamin,

On Thu, Dec 17, 2015 at 1:53 AM, Benjamin Tissoires
<benjamin.tissoi...@redhat.com> wrote:
> On Dec 16 2015 or thereabouts, Nish Aravamudan wrote:
>> Hi Jiri,
>>
>> On Wed, Dec 16, 2015 at 5:18 AM, Jiri Kosina <ji...@kernel.org> wrote:
>> > On Wed, 16 Dec 2015, Mika Westerberg wrote:
>> >
>> >> > [Apologies for the resend, didn't realize I hadn't changed my GMail 
>> >> > settings
>> >> > to not use HTML.]
>> >> >
>> >> > I have recently purchased a Lenovo Yoga 900 and most everything is 
>> >> > working
>> >> > with a slightly modified 4.4-rc5 (https://lkml.org/lkml/2015/11/30/441 
>> >> > applied
>> >> > to enable the touchpad itself), I am seeing two issues:
>> >> >
>> >> > 1) On suspend/resume, the touchpad is non-functional. A `modprobe -r 
>> >> > i2c-hid;
>> >> >  modprobe i2c-hid` "fixes" it.
>> >> >
>> >> > The kernel emits:
>> >> >
>> >> > i2c_hid i2c-SYNA2B29:00: failed to reset device.
>> >> > dpm_run_callback(): i2c_hid_resume+0x0/0xc0 [i2c_hid] returns -61
>> >> > PM: Device i2c-SYNA2B29:00 failed to resume: error -61
>> >> >
>> >> > During the resume. So perhaps this is a timing issue (given that once
>> >> > resumed, the
>> >> > module reload does work?).
>> >>
>> >> Linus noticed this as well and Jiri suggested the below patch which
>> >> seemed to fix the issue (although it increased resume time a bit).
>> >>
>> >> I was supposed to get one Lenovo Yoga 900 here to debug this issue but
>> >> I'm still waiting for it (sloow big corporation bureaucracy takes some
>> >> time to get things purchased outside).
>> >>
>> >> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
>> >> index 55d8f9d..52dd03a0 100644
>> >> --- a/drivers/hid/i2c-hid/i2c-hid.c
>> >> +++ b/drivers/hid/i2c-hid/i2c-hid.c
>> >> @@ -1121,10 +1121,16 @@ static int i2c_hid_resume(struct device *dev)
>> >>   struct i2c_client *client = to_i2c_client(dev);
>> >>   struct i2c_hid *ihid = i2c_get_clientdata(client);
>> >>   struct hid_device *hid = ihid->hid;
>> >> - int wake_status;
>> >> + int wake_status, tries = 3;
>> >>
>> >>   enable_irq(ihid->irq);
>> >> - ret = i2c_hid_hwreset(client);
>> >> +
>> >> + do {
>> >> + ret = i2c_hid_hwreset(client);
>> >> + if (ret)
>> >> + msleep(1000);
>> >> + } while (tries-- > 0 && ret);
>> >> +
>> >>   if (ret)
>> >>   return ret;
>> >
>> > As a possible alternative, please test the patch above on top of for-next
>> > branch of
>> >
>> > git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git
>> >
>> > It contains 64bebefcf3 ("HID: enable hid device to suspend/resume
>> > asynchronously") and knowing whether that changes something might be
>> > interesting datapoint as well.
>>
>> What should I be looking for to be different wrt. that tree? Should I
>> not see the failure to reset the device? Or would it be (relatively)
>> speedier than the stock kernel?
>>
>
> Basically, does the resume time gets better? Linus experienced something
> like 9 secs of resume before this patch, and now I hope it should be
> saner (the touchpad might still be a little bit long to respond).
>
> Also, we have a bug report concerning this laptop and it looks like the
> i2c controller needs to be updated (see
> https://bugzilla.redhat.com/show_bug.cgi?id=1275718).
>
> I am not entirely sure why those on the rhbz needs to update the i2c
> controller while you don't have to, but it may also be worth checking if
> the i2c patch series mentioned in this rhbz (comment #20) fixes by itself
> the resume issue (without Jiri's patch).

Yep, I applied the series from https://lkml.org/lkml/2015/11/30/441
already. Without that series, I don't have a working touchscreen and
touchpad. Touchpad resume doesn't work with just that series.

With that series + Jiri's patch it seems to resume pretty quickly. But
I guess I don't see exactly what would change with the resume if the
same loop is present on top of hid:for-next? Still on my list to test,
though.

Also, even with that series, there does appear maybe there is an I2C
issue, though:

i2c_hid i2c-ITE8396:00: error in i2c_hid_init_report size:19 / ret_size:18

as I mentioned in my first e-mail; which might be affecting the IIO sensors?

-Nish
--
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: [RESEND] Lenovo Yoga 900 touchpad issues

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 9:28 AM, Benjamin Tissoires
<benjamin.tissoi...@redhat.com> wrote:
> On Dec 17 2015 or thereabouts, Nish Aravamudan wrote:
>> Hi Benjamin,
>>
>> On Thu, Dec 17, 2015 at 1:53 AM, Benjamin Tissoires
>> <benjamin.tissoi...@redhat.com> wrote:
>> > On Dec 16 2015 or thereabouts, Nish Aravamudan wrote:
>> >> Hi Jiri,
>> >>
>> >> On Wed, Dec 16, 2015 at 5:18 AM, Jiri Kosina <ji...@kernel.org> wrote:
>> >> > On Wed, 16 Dec 2015, Mika Westerberg wrote:
>> >> >
>> >> >> > [Apologies for the resend, didn't realize I hadn't changed my GMail 
>> >> >> > settings
>> >> >> > to not use HTML.]
>> >> >> >
>> >> >> > I have recently purchased a Lenovo Yoga 900 and most everything is 
>> >> >> > working
>> >> >> > with a slightly modified 4.4-rc5 
>> >> >> > (https://lkml.org/lkml/2015/11/30/441 applied
>> >> >> > to enable the touchpad itself), I am seeing two issues:
>> >> >> >
>> >> >> > 1) On suspend/resume, the touchpad is non-functional. A `modprobe -r 
>> >> >> > i2c-hid;
>> >> >> >  modprobe i2c-hid` "fixes" it.
>> >> >> >
>> >> >> > The kernel emits:
>> >> >> >
>> >> >> > i2c_hid i2c-SYNA2B29:00: failed to reset device.
>> >> >> > dpm_run_callback(): i2c_hid_resume+0x0/0xc0 [i2c_hid] returns -61
>> >> >> > PM: Device i2c-SYNA2B29:00 failed to resume: error -61
>> >> >> >
>> >> >> > During the resume. So perhaps this is a timing issue (given that once
>> >> >> > resumed, the
>> >> >> > module reload does work?).
>> >> >>
>> >> >> Linus noticed this as well and Jiri suggested the below patch which
>> >> >> seemed to fix the issue (although it increased resume time a bit).
>> >> >>
>> >> >> I was supposed to get one Lenovo Yoga 900 here to debug this issue but
>> >> >> I'm still waiting for it (sloow big corporation bureaucracy takes some
>> >> >> time to get things purchased outside).
>> >> >>
>> >> >> diff --git a/drivers/hid/i2c-hid/i2c-hid.c 
>> >> >> b/drivers/hid/i2c-hid/i2c-hid.c
>> >> >> index 55d8f9d..52dd03a0 100644
>> >> >> --- a/drivers/hid/i2c-hid/i2c-hid.c
>> >> >> +++ b/drivers/hid/i2c-hid/i2c-hid.c
>> >> >> @@ -1121,10 +1121,16 @@ static int i2c_hid_resume(struct device *dev)
>> >> >>   struct i2c_client *client = to_i2c_client(dev);
>> >> >>   struct i2c_hid *ihid = i2c_get_clientdata(client);
>> >> >>   struct hid_device *hid = ihid->hid;
>> >> >> - int wake_status;
>> >> >> + int wake_status, tries = 3;
>> >> >>
>> >> >>   enable_irq(ihid->irq);
>> >> >> - ret = i2c_hid_hwreset(client);
>> >> >> +
>> >> >> + do {
>> >> >> + ret = i2c_hid_hwreset(client);
>> >> >> + if (ret)
>> >> >> + msleep(1000);
>> >> >> + } while (tries-- > 0 && ret);
>> >> >> +
>> >> >>   if (ret)
>> >> >>   return ret;
>> >> >
>> >> > As a possible alternative, please test the patch above on top of 
>> >> > for-next
>> >> > branch of
>> >> >
>> >> > git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git
>> >> >
>> >> > It contains 64bebefcf3 ("HID: enable hid device to suspend/resume
>> >> > asynchronously") and knowing whether that changes something might be
>> >> > interesting datapoint as well.
>> >>
>> >> What should I be looking for to be different wrt. that tree? Should I
>> >> not see the failure to reset the device? Or would it be (relatively)
>> >> speedier than the stock kernel?
>> >>
>> >
>> > Basically, does the resume time gets better? Linus experienced something
>> > like 9 secs of resume before this patch, and now I hope it should be
>> > saner (the touchpad might

Re: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 12:41 AM, Crt Mori <c...@melexis.com> wrote:
> On 17 December 2015 at 06:27, Nish Aravamudan <nish.aravamu...@gmail.com> 
> wrote:
>> On Wed, Dec 16, 2015 at 3:05 PM, Nish Aravamudan
>> <nish.aravamu...@gmail.com> wrote:
>>> On Wed, Dec 16, 2015 at 2:55 PM, Crt Mori <c...@melexis.com> wrote:
>>>>
>>>> On Dec 16, 2015 11:37 PM, "Nish Aravamudan" <nish.aravamu...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori <c...@melexis.com> wrote:
>>>>> > On 16 December 2015 at 22:41, Nish Aravamudan
>>>>> > <nish.aravamu...@gmail.com> wrote:
>>>>> >> Hi Daniel,
>>>>> >>
>>>>> >> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta
>>>>> >> <daniel.bal...@gmail.com> wrote:
>>>>> >>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>>>>> >>> <nish.aravamu...@gmail.com> wrote:
>>>>> >>>> So, I apologize in advance for this relatively vague report, but I'm
>>>>> >>>> fairly sure
>>>>> >>>> the Yoga 900 has an accelerometer amongst other sensors (ambient
>>>>> >>>> light?)
>>>>> >>>> exported over IIO.
>>>>> >>>>
>>>>> >>>> But, these sensors seem to not be updating at all with a 4.4-rc5+
>>>>> >>>> kernel (a
>>>>> >>>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied to
>>>>> >>>> Linus'
>>>>> >>>> tree).
>>>>> >>>>
>>>>> >>>> The odd part is at some point in messing with this, I'm fairly sure
>>>>> >>>> it did work!
>>>>> >>>> That is,
>>>>> >>>>
>>>>> >>>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>>>>> >>>
>>>>> >>> Can you send us a sample of the output? Also, would be
>>>>> >>> good to identify the exact driver for accel.
>>>>> >>
>>>>> >> cat /sys/bus/iio/devices/iio:device*/*raw*
>>>>> >> 65478
>>>>> >> 7
>>>>> >> 1023
>>>>> >> 0
>>>>> >> 0
>>>>> >> 0
>>>>> >> 100
>>>>> >> -539062
>>>>> >> -742187
>>>>> >> 1292968
>>>>> >> 1592
>>>>> >> 64932
>>>>> >> 2
>>>>> >> 275
>>>>> >> 0 0 0 0
>>>>> >>
>>>>> >> Now, I should say that I distinctly remember at some point waving my
>>>>> >> laptop around and seeing these values change ... but now they seem to
>>>>> >> be "stuck". Maybe it's a hardware issue or something special that
>>>>> >> WIndows does to leverage the IIO sensors?
>>>>> >>
>>>>> >>> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name
>>>>> >>
>>>>> >> $ cat /sys/bus/iio/devices/iio:device*/name
>>>>> >> accel_3d
>>>>> >
>>>>> > Can you list the directory of iio:device with this name (it is:
>>>>> > drivers/iio/accel/hid-sensor-accel-3d.c).
>>>>> > This is something you will be looking at for accel debugging, but it
>>>>> > seems more like
>>>>> > standard
>>>>>
>>>>> /sys/bus/iio/devices/iio:device0/name
>>>>> gyro_3d
>>>>> /sys/bus/iio/devices/iio:device1/name
>>>>> dev_rotation
>>>>> /sys/bus/iio/devices/iio:device2/name
>>>>> als
>>>>> /sys/bus/iio/devices/iio:device3/name
>>>>> magn_3d
>>>>> /sys/bus/iio/devices/iio:device4/name
>>>>> accel_3d
>>>>> /sys/bus/iio/devices/iio:device5/name
>>>>> incli_3d
>>>>>
>>>>> are all the IIO sensors, sorry about that!
>>>>>
>>>>
>>>> I was more thinking what else is in iio:device4 directory, so that we can
>>>> see if it was initialized OK. Can you also

Re: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 9:32 AM, Nish Aravamudan
<nish.aravamu...@gmail.com> wrote:
> On Thu, Dec 17, 2015 at 12:41 AM, Crt Mori <c...@melexis.com> wrote:
>> On 17 December 2015 at 06:27, Nish Aravamudan <nish.aravamu...@gmail.com> 
>> wrote:
>>> On Wed, Dec 16, 2015 at 3:05 PM, Nish Aravamudan
>>> <nish.aravamu...@gmail.com> wrote:
>>>> On Wed, Dec 16, 2015 at 2:55 PM, Crt Mori <c...@melexis.com> wrote:
>>>>>
>>>>> On Dec 16, 2015 11:37 PM, "Nish Aravamudan" <nish.aravamu...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori <c...@melexis.com> wrote:
>>>>>> > On 16 December 2015 at 22:41, Nish Aravamudan
>>>>>> > <nish.aravamu...@gmail.com> wrote:
>>>>>> >> Hi Daniel,
>>>>>> >>
>>>>>> >> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta
>>>>>> >> <daniel.bal...@gmail.com> wrote:
>>>>>> >>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>>>>>> >>> <nish.aravamu...@gmail.com> wrote:
>>>>>> >>>> So, I apologize in advance for this relatively vague report, but I'm
>>>>>> >>>> fairly sure
>>>>>> >>>> the Yoga 900 has an accelerometer amongst other sensors (ambient
>>>>>> >>>> light?)
>>>>>> >>>> exported over IIO.
>>>>>> >>>>
>>>>>> >>>> But, these sensors seem to not be updating at all with a 4.4-rc5+
>>>>>> >>>> kernel (a
>>>>>> >>>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied to
>>>>>> >>>> Linus'
>>>>>> >>>> tree).
>>>>>> >>>>
>>>>>> >>>> The odd part is at some point in messing with this, I'm fairly sure
>>>>>> >>>> it did work!
>>>>>> >>>> That is,
>>>>>> >>>>
>>>>>> >>>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>>>>>> >>>
>>>>>> >>> Can you send us a sample of the output? Also, would be
>>>>>> >>> good to identify the exact driver for accel.
>>>>>> >>
>>>>>> >> cat /sys/bus/iio/devices/iio:device*/*raw*
>>>>>> >> 65478
>>>>>> >> 7
>>>>>> >> 1023
>>>>>> >> 0
>>>>>> >> 0
>>>>>> >> 0
>>>>>> >> 100
>>>>>> >> -539062
>>>>>> >> -742187
>>>>>> >> 1292968
>>>>>> >> 1592
>>>>>> >> 64932
>>>>>> >> 2
>>>>>> >> 275
>>>>>> >> 0 0 0 0
>>>>>> >>
>>>>>> >> Now, I should say that I distinctly remember at some point waving my
>>>>>> >> laptop around and seeing these values change ... but now they seem to
>>>>>> >> be "stuck". Maybe it's a hardware issue or something special that
>>>>>> >> WIndows does to leverage the IIO sensors?
>>>>>> >>
>>>>>> >>> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name
>>>>>> >>
>>>>>> >> $ cat /sys/bus/iio/devices/iio:device*/name
>>>>>> >> accel_3d
>>>>>> >
>>>>>> > Can you list the directory of iio:device with this name (it is:
>>>>>> > drivers/iio/accel/hid-sensor-accel-3d.c).
>>>>>> > This is something you will be looking at for accel debugging, but it
>>>>>> > seems more like
>>>>>> > standard
>>>>>>
>>>>>> /sys/bus/iio/devices/iio:device0/name
>>>>>> gyro_3d
>>>>>> /sys/bus/iio/devices/iio:device1/name
>>>>>> dev_rotation
>>>>>> /sys/bus/iio/devices/iio:device2/name
>>>>>> als
>>>>>> /sys/bus/iio/devices/iio:device3/name
>>>>>> magn_3d
>>>>>> /sys/bus

Re: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 10:38 AM, Crt Mori <c...@melexis.com> wrote:
> On 17 December 2015 at 19:10, Nish Aravamudan <nish.aravamu...@gmail.com> 
> wrote:
>> On Thu, Dec 17, 2015 at 9:32 AM, Nish Aravamudan
>> <nish.aravamu...@gmail.com> wrote:
>>> On Thu, Dec 17, 2015 at 12:41 AM, Crt Mori <c...@melexis.com> wrote:
>>>> On 17 December 2015 at 06:27, Nish Aravamudan <nish.aravamu...@gmail.com> 
>>>> wrote:
>>>>> On Wed, Dec 16, 2015 at 3:05 PM, Nish Aravamudan
>>>>> <nish.aravamu...@gmail.com> wrote:
>>>>>> On Wed, Dec 16, 2015 at 2:55 PM, Crt Mori <c...@melexis.com> wrote:
>>>>>>>
>>>>>>> On Dec 16, 2015 11:37 PM, "Nish Aravamudan" <nish.aravamu...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori <c...@melexis.com> wrote:
>>>>>>>> > On 16 December 2015 at 22:41, Nish Aravamudan
>>>>>>>> > <nish.aravamu...@gmail.com> wrote:
>>>>>>>> >> Hi Daniel,
>>>>>>>> >>
>>>>>>>> >> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta
>>>>>>>> >> <daniel.bal...@gmail.com> wrote:
>>>>>>>> >>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>>>>>>>> >>> <nish.aravamu...@gmail.com> wrote:
>>>>>>>> >>>> So, I apologize in advance for this relatively vague report, but 
>>>>>>>> >>>> I'm
>>>>>>>> >>>> fairly sure
>>>>>>>> >>>> the Yoga 900 has an accelerometer amongst other sensors (ambient
>>>>>>>> >>>> light?)
>>>>>>>> >>>> exported over IIO.
>>>>>>>> >>>>
>>>>>>>> >>>> But, these sensors seem to not be updating at all with a 4.4-rc5+
>>>>>>>> >>>> kernel (a
>>>>>>>> >>>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied 
>>>>>>>> >>>> to
>>>>>>>> >>>> Linus'
>>>>>>>> >>>> tree).
>>>>>>>> >>>>
>>>>>>>> >>>> The odd part is at some point in messing with this, I'm fairly 
>>>>>>>> >>>> sure
>>>>>>>> >>>> it did work!
>>>>>>>> >>>> That is,
>>>>>>>> >>>>
>>>>>>>> >>>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>>>>>>>> >>>
>>>>>>>> >>> Can you send us a sample of the output? Also, would be
>>>>>>>> >>> good to identify the exact driver for accel.
>>>>>>>> >>
>>>>>>>> >> cat /sys/bus/iio/devices/iio:device*/*raw*
>>>>>>>> >> 65478
>>>>>>>> >> 7
>>>>>>>> >> 1023
>>>>>>>> >> 0
>>>>>>>> >> 0
>>>>>>>> >> 0
>>>>>>>> >> 100
>>>>>>>> >> -539062
>>>>>>>> >> -742187
>>>>>>>> >> 1292968
>>>>>>>> >> 1592
>>>>>>>> >> 64932
>>>>>>>> >> 2
>>>>>>>> >> 275
>>>>>>>> >> 0 0 0 0
>>>>>>>> >>
>>>>>>>> >> Now, I should say that I distinctly remember at some point waving my
>>>>>>>> >> laptop around and seeing these values change ... but now they seem 
>>>>>>>> >> to
>>>>>>>> >> be "stuck". Maybe it's a hardware issue or something special that
>>>>>>>> >> WIndows does to leverage the IIO sensors?
>>>>>>>> >>
>>>>>>>> >>> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name
>>>>>>>> >>
>>>>>>

Re: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 12:05 PM, Nish Aravamudan
<nish.aravamu...@gmail.com> wrote:
> On Thu, Dec 17, 2015 at 10:38 AM, Crt Mori <c...@melexis.com> wrote:
>> On 17 December 2015 at 19:10, Nish Aravamudan <nish.aravamu...@gmail.com> 
>> wrote:
>>> On Thu, Dec 17, 2015 at 9:32 AM, Nish Aravamudan
>>> <nish.aravamu...@gmail.com> wrote:
>>>> On Thu, Dec 17, 2015 at 12:41 AM, Crt Mori <c...@melexis.com> wrote:
>>>>> On 17 December 2015 at 06:27, Nish Aravamudan <nish.aravamu...@gmail.com> 
>>>>> wrote:
>>>>>> On Wed, Dec 16, 2015 at 3:05 PM, Nish Aravamudan
>>>>>> <nish.aravamu...@gmail.com> wrote:
>>>>>>> On Wed, Dec 16, 2015 at 2:55 PM, Crt Mori <c...@melexis.com> wrote:
>>>>>>>>
>>>>>>>> On Dec 16, 2015 11:37 PM, "Nish Aravamudan" <nish.aravamu...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori <c...@melexis.com> wrote:
>>>>>>>>> > On 16 December 2015 at 22:41, Nish Aravamudan
>>>>>>>>> > <nish.aravamu...@gmail.com> wrote:
>>>>>>>>> >> Hi Daniel,
>>>>>>>>> >>
>>>>>>>>> >> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta
>>>>>>>>> >> <daniel.bal...@gmail.com> wrote:
>>>>>>>>> >>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>>>>>>>>> >>> <nish.aravamu...@gmail.com> wrote:
>>>>>>>>> >>>> So, I apologize in advance for this relatively vague report, but 
>>>>>>>>> >>>> I'm
>>>>>>>>> >>>> fairly sure
>>>>>>>>> >>>> the Yoga 900 has an accelerometer amongst other sensors (ambient
>>>>>>>>> >>>> light?)
>>>>>>>>> >>>> exported over IIO.
>>>>>>>>> >>>>
>>>>>>>>> >>>> But, these sensors seem to not be updating at all with a 4.4-rc5+
>>>>>>>>> >>>> kernel (a
>>>>>>>>> >>>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied 
>>>>>>>>> >>>> to
>>>>>>>>> >>>> Linus'
>>>>>>>>> >>>> tree).
>>>>>>>>> >>>>
>>>>>>>>> >>>> The odd part is at some point in messing with this, I'm fairly 
>>>>>>>>> >>>> sure
>>>>>>>>> >>>> it did work!
>>>>>>>>> >>>> That is,
>>>>>>>>> >>>>
>>>>>>>>> >>>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>>>>>>>>> >>>
>>>>>>>>> >>> Can you send us a sample of the output? Also, would be
>>>>>>>>> >>> good to identify the exact driver for accel.
>>>>>>>>> >>
>>>>>>>>> >> cat /sys/bus/iio/devices/iio:device*/*raw*
>>>>>>>>> >> 65478
>>>>>>>>> >> 7
>>>>>>>>> >> 1023
>>>>>>>>> >> 0
>>>>>>>>> >> 0
>>>>>>>>> >> 0
>>>>>>>>> >> 100
>>>>>>>>> >> -539062
>>>>>>>>> >> -742187
>>>>>>>>> >> 1292968
>>>>>>>>> >> 1592
>>>>>>>>> >> 64932
>>>>>>>>> >> 2
>>>>>>>>> >> 275
>>>>>>>>> >> 0 0 0 0
>>>>>>>>> >>
>>>>>>>>> >> Now, I should say that I distinctly remember at some point waving 
>>>>>>>>> >> my
>>>>>>>>> >> laptop around and seeing these values change ... but now they seem 
>>>>>>>>> &

iio/hid-sensor-accel-3d: no output from /dev/iio:device*?

[Nish Aravamudan]

[Starting a new thread from https://lkml.org/lkml/2015/12/15/663, as
now my laptop is displaying values in the sysfs *raw* files.]

So I'm trying to understand exactly how the hid-sensor-accel-3d driver works.

If I turn up debugging, when I `cat
/sys/bus/iio/devices/device*/*raw*`, I see "iio iio:device3:
accel_3d_proc_event" and I think that means that
hid_sensor_push_data() is getting called.

But read()'s on /dev/iio:device3 never produces anything, which is
what iio-sensor-proxy uses to translate events to dbus.

Is it expected that the dev-node is "silent"? Just trying to
understand if an extension to the driver to support a chardev based
output is appropriate, or if iio-sensor-proxy needs to be changed to
handle this device.

-Nish
--
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: iio/hid-sensor-accel-3d: no output from /dev/iio:device*?

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 6:50 PM, Pandruvada, Srinivas
<srinivas.pandruv...@intel.com> wrote:
> On Thu, 2015-12-17 at 18:33 -0800, Nish Aravamudan wrote:
>> On Thu, Dec 17, 2015 at 5:11 PM, Pandruvada, Srinivas
>> <srinivas.pandruv...@intel.com> wrote:
>> > On Thu, 2015-12-17 at 17:08 -0800, Nish Aravamudan wrote:
>> > > On Thu, Dec 17, 2015 at 5:00 PM, Pandruvada, Srinivas
>> > > <srinivas.pandruv...@intel.com> wrote:
>> > > > Hi Andy,
>> > > >
>> > > > As per Nish these patches are impacting sensors on Yoga.
>> > > > https://lkml.org/lkml/2015/11/30/441
>> > >
>> > > To be clear, without that series, the touchpad and touchscreen on
>> > > the
>> > > Yoga 900 don't work at all. So they are necessary for
>> > > functioning. I
>> > > don't know (I will test it now), if removing the series makes the
>> > > IIO
>> > > sensors work properly in /dev/.
>> > This is important to know before we take Andy's time.
>>
>> It seems like Andy's patches are not the problem. That is, with stock
>> 4.4-rc5, the accelerommeter /dev files still do not update.
>>
> Can you not use raw values by polling from user space? Send me
> report description. It should be in
> /sys/kernel/debug/hid/ "your device id" /redesc.

The underlying issue is that iio-sensor-proxy relies on values from
the corresponding /dev nodes to automatically rotate the screen, etc.
in the desktop environment.

Attached due to its size.

> Also device id ("your device id") above.

0018:048D:8396.0002

-Nish


rdesc
Description: Binary data

Re: iio/hid-sensor-accel-3d: no output from /dev/iio:device*?

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 5:16 PM, Srinivas Pandruvada
<srinivas.pandruv...@linux.intel.com> wrote:
> On Thu, 2015-12-17 at 17:07 -0800, Nish Aravamudan wrote:
>> On Thu, Dec 17, 2015 at 4:51 PM, Srinivas Pandruvada
>> <srinivas.pandruv...@linux.intel.com> wrote:
>> > On Thu, 2015-12-17 at 15:38 -0800, Nish Aravamudan wrote:
>> > > [Starting a new thread from https://lkml.org/lkml/2015/12/15/663,
>> > > as
>> > > now my laptop is displaying values in the sysfs *raw* files.]
>> > >
>> > > So I'm trying to understand exactly how the hid-sensor-accel-3d
>> > > driver works.
>> > >
>> > > If I turn up debugging, when I `cat
>> > > /sys/bus/iio/devices/device*/*raw*`, I see "iio iio:device3:
>> > > accel_3d_proc_event" and I think that means that
>> > > hid_sensor_push_data() is getting called.
>> > >
>> > > But read()'s on /dev/iio:device3 never produces anything, which
>> > > is
>> > > what iio-sensor-proxy uses to translate events to dbus.
>> > >
>> > > Is it expected that the dev-node is "silent"? Just trying to
>> > > understand if an extension to the driver to support a chardev
>> > > based
>> > > output is appropriate, or if iio-sensor-proxy needs to be changed
>> > > to
>> > > handle this device.
>> >
>> > You are saying there is some regression. This used to work and now
>> > it
>> > doesn't work. Is raw values are displayed correctly, when you do
>> > "cat"?
>> > If cat of raw values is working then power on of sensors is
>> > working.
>>
>> Sorry, I was unclear. I don't know if this is a regression. I can try
>> going back to an older kernel to see if the /dev/iio:device* files
>> produced any output.
>>
>> Yes, the *raw* files in sysfs are producing output, that is changing
>> as I move the laptop around. But the /dev/ nodes seem to produce no
>> output (I'm still reading through the driver code to understand where
>> that data should be coming from.
>>
>> > Turn on HID debug prints. If it is regression we can do git bisect.
>> > Any ACPI or PM changes can break this. Usually there will be GPIOs
>> > which will be involved in power on, where ACPI comes into play.
>> > This
>> > will be done by i2c-hid. There are some prints in i2c-hid which can
>> > be
>> > enabled also.
>>
>> Ok, I will try this, as well.
>>
>
> Try increasing in_accel_sampling_frequency
> echo 100 > in_accel_sampling_frequency
> Adjust hysteresis to a low value
> echo 0 > in_accel_hysteresis
> These values are very vendor specific.

Adjusting the values in this way didn't seem to make any difference.
Also, `cat in_accel_hysteresis` gave EINVAL, but I was able to echo 0
to it.

-Nish
--
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: iio/hid-sensor-accel-3d: no output from /dev/iio:device*?

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 5:11 PM, Pandruvada, Srinivas
<srinivas.pandruv...@intel.com> wrote:
> On Thu, 2015-12-17 at 17:08 -0800, Nish Aravamudan wrote:
>> On Thu, Dec 17, 2015 at 5:00 PM, Pandruvada, Srinivas
>> <srinivas.pandruv...@intel.com> wrote:
>> > Hi Andy,
>> >
>> > As per Nish these patches are impacting sensors on Yoga.
>> > https://lkml.org/lkml/2015/11/30/441
>>
>> To be clear, without that series, the touchpad and touchscreen on the
>> Yoga 900 don't work at all. So they are necessary for functioning. I
>> don't know (I will test it now), if removing the series makes the IIO
>> sensors work properly in /dev/.
> This is important to know before we take Andy's time.

It seems like Andy's patches are not the problem. That is, with stock
4.4-rc5, the accelerommeter /dev files still do not update.

-Nish
--
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: iio/hid-sensor-accel-3d: no output from /dev/iio:device*?

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 5:00 PM, Pandruvada, Srinivas
<srinivas.pandruv...@intel.com> wrote:
> Hi Andy,
>
> As per Nish these patches are impacting sensors on Yoga.
> https://lkml.org/lkml/2015/11/30/441

To be clear, without that series, the touchpad and touchscreen on the
Yoga 900 don't work at all. So they are necessary for functioning. I
don't know (I will test it now), if removing the series makes the IIO
sensors work properly in /dev/.

-Nish

> On Thu, 2015-12-17 at 16:51 -0800, Srinivas Pandruvada wrote:
>> On Thu, 2015-12-17 at 15:38 -0800, Nish Aravamudan wrote:
>> > [Starting a new thread from https://lkml.org/lkml/2015/12/15/663,
>> > as
>> > now my laptop is displaying values in the sysfs *raw* files.]
>> >
>> > So I'm trying to understand exactly how the hid-sensor-accel-3d
>> > driver works.
>> >
>> > If I turn up debugging, when I `cat
>> > /sys/bus/iio/devices/device*/*raw*`, I see "iio iio:device3:
>> > accel_3d_proc_event" and I think that means that
>> > hid_sensor_push_data() is getting called.
>> >
>> > But read()'s on /dev/iio:device3 never produces anything, which is
>> > what iio-sensor-proxy uses to translate events to dbus.
>> >
>> > Is it expected that the dev-node is "silent"? Just trying to
>> > understand if an extension to the driver to support a chardev based
>> > output is appropriate, or if iio-sensor-proxy needs to be changed
>> > to
>> > handle this device.
>>
>> You are saying there is some regression. This used to work and now it
>> doesn't work. Is raw values are displayed correctly, when you do
>> "cat"?
>> If cat of raw values is working then power on of sensors is working.
>>
>> Turn on HID debug prints. If it is regression we can do git bisect.
>> Any ACPI or PM changes can break this. Usually there will be GPIOs
>> which will be involved in power on, where ACPI comes into play. This
>> will be done by i2c-hid. There are some prints in i2c-hid which can
>> be
>> enabled also.
>>
>> Thanks,
>> Srinivas
>>
>> >
--
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: iio/hid-sensor-accel-3d: no output from /dev/iio:device*?

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 4:51 PM, Srinivas Pandruvada
<srinivas.pandruv...@linux.intel.com> wrote:
> On Thu, 2015-12-17 at 15:38 -0800, Nish Aravamudan wrote:
>> [Starting a new thread from https://lkml.org/lkml/2015/12/15/663, as
>> now my laptop is displaying values in the sysfs *raw* files.]
>>
>> So I'm trying to understand exactly how the hid-sensor-accel-3d
>> driver works.
>>
>> If I turn up debugging, when I `cat
>> /sys/bus/iio/devices/device*/*raw*`, I see "iio iio:device3:
>> accel_3d_proc_event" and I think that means that
>> hid_sensor_push_data() is getting called.
>>
>> But read()'s on /dev/iio:device3 never produces anything, which is
>> what iio-sensor-proxy uses to translate events to dbus.
>>
>> Is it expected that the dev-node is "silent"? Just trying to
>> understand if an extension to the driver to support a chardev based
>> output is appropriate, or if iio-sensor-proxy needs to be changed to
>> handle this device.
>
> You are saying there is some regression. This used to work and now it
> doesn't work. Is raw values are displayed correctly, when you do "cat"?
> If cat of raw values is working then power on of sensors is working.

Sorry, I was unclear. I don't know if this is a regression. I can try
going back to an older kernel to see if the /dev/iio:device* files
produced any output.

Yes, the *raw* files in sysfs are producing output, that is changing
as I move the laptop around. But the /dev/ nodes seem to produce no
output (I'm still reading through the driver code to understand where
that data should be coming from.

> Turn on HID debug prints. If it is regression we can do git bisect.
> Any ACPI or PM changes can break this. Usually there will be GPIOs
> which will be involved in power on, where ACPI comes into play. This
> will be done by i2c-hid. There are some prints in i2c-hid which can be
> enabled also.

Ok, I will try this, as well.

-Nish
--
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: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

On Wed, Dec 16, 2015 at 3:05 PM, Nish Aravamudan
 wrote:
> On Wed, Dec 16, 2015 at 2:55 PM, Crt Mori  wrote:
>>
>> On Dec 16, 2015 11:37 PM, "Nish Aravamudan" 
>> wrote:
>>>
>>> Hi,
>>>
>>> On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori  wrote:
>>> > On 16 December 2015 at 22:41, Nish Aravamudan
>>> >  wrote:
>>> >> Hi Daniel,
>>> >>
>>> >> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta
>>> >>  wrote:
>>> >>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>>> >>>  wrote:
>>> >>>> So, I apologize in advance for this relatively vague report, but I'm
>>> >>>> fairly sure
>>> >>>> the Yoga 900 has an accelerometer amongst other sensors (ambient
>>> >>>> light?)
>>> >>>> exported over IIO.
>>> >>>>
>>> >>>> But, these sensors seem to not be updating at all with a 4.4-rc5+
>>> >>>> kernel (a
>>> >>>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied to
>>> >>>> Linus'
>>> >>>> tree).
>>> >>>>
>>> >>>> The odd part is at some point in messing with this, I'm fairly sure
>>> >>>> it did work!
>>> >>>> That is,
>>> >>>>
>>> >>>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>>> >>>
>>> >>> Can you send us a sample of the output? Also, would be
>>> >>> good to identify the exact driver for accel.
>>> >>
>>> >> cat /sys/bus/iio/devices/iio:device*/*raw*
>>> >> 65478
>>> >> 7
>>> >> 1023
>>> >> 0
>>> >> 0
>>> >> 0
>>> >> 100
>>> >> -539062
>>> >> -742187
>>> >> 1292968
>>> >> 1592
>>> >> 64932
>>> >> 2
>>> >> 275
>>> >> 0 0 0 0
>>> >>
>>> >> Now, I should say that I distinctly remember at some point waving my
>>> >> laptop around and seeing these values change ... but now they seem to
>>> >> be "stuck". Maybe it's a hardware issue or something special that
>>> >> WIndows does to leverage the IIO sensors?
>>> >>
>>> >>> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name
>>> >>
>>> >> $ cat /sys/bus/iio/devices/iio:device*/name
>>> >> accel_3d
>>> >
>>> > Can you list the directory of iio:device with this name (it is:
>>> > drivers/iio/accel/hid-sensor-accel-3d.c).
>>> > This is something you will be looking at for accel debugging, but it
>>> > seems more like
>>> > standard
>>>
>>> /sys/bus/iio/devices/iio:device0/name
>>> gyro_3d
>>> /sys/bus/iio/devices/iio:device1/name
>>> dev_rotation
>>> /sys/bus/iio/devices/iio:device2/name
>>> als
>>> /sys/bus/iio/devices/iio:device3/name
>>> magn_3d
>>> /sys/bus/iio/devices/iio:device4/name
>>> accel_3d
>>> /sys/bus/iio/devices/iio:device5/name
>>> incli_3d
>>>
>>> are all the IIO sensors, sorry about that!
>>>
>>
>> I was more thinking what else is in iio:device4 directory, so that we can
>> see if it was initialized OK. Can you also grep the dmesg for any errors?
>
> Well, I just noticed the device #s are not consistent boot-to-boot, so
> this time it was device0. Trimming out the directories:
>
> /sys/bus/iio/devices/iio:device0/buffer
> cat: /sys/bus/iio/devices/iio:device0/buffer: Is a directory
> /sys/bus/iio/devices/iio:device0/dev
> 250:0
> /sys/bus/iio/devices/iio:device0/in_accel_hysteresis
> cat: /sys/bus/iio/devices/iio:device0/in_accel_hysteresis: Invalid argument
> /sys/bus/iio/devices/iio:device0/in_accel_offset
> 0
> /sys/bus/iio/devices/iio:device0/in_accel_sampling_frequency
> 8.00
> /sys/bus/iio/devices/iio:device0/in_accel_scale
> 0.009806
> /sys/bus/iio/devices/iio:device0/in_accel_x_raw
> 65478
> /sys/bus/iio/devices/iio:device0/in_accel_y_raw
> 7
> /sys/bus/iio/devices/iio:device0/in_accel_z_raw
> 1023
> /sys/bus/iio/devices/iio:device0/name
> accel_3d
> /sys/bus/iio/devices/iio:device0/uevent
> MAJOR=250
> MINOR=0
> DEVNAME=iio:device0
> DEVTYPE=iio_device
>
> Another thing I just noticed:
>
> /sys

Re: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

On Wed, Dec 16, 2015 at 2:55 PM, Crt Mori  wrote:
>
> On Dec 16, 2015 11:37 PM, "Nish Aravamudan" 
> wrote:
>>
>> Hi,
>>
>> On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori  wrote:
>> > On 16 December 2015 at 22:41, Nish Aravamudan
>> >  wrote:
>> >> Hi Daniel,
>> >>
>> >> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta
>> >>  wrote:
>> >>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>> >>>  wrote:
>> >>>> So, I apologize in advance for this relatively vague report, but I'm
>> >>>> fairly sure
>> >>>> the Yoga 900 has an accelerometer amongst other sensors (ambient
>> >>>> light?)
>> >>>> exported over IIO.
>> >>>>
>> >>>> But, these sensors seem to not be updating at all with a 4.4-rc5+
>> >>>> kernel (a
>> >>>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied to
>> >>>> Linus'
>> >>>> tree).
>> >>>>
>> >>>> The odd part is at some point in messing with this, I'm fairly sure
>> >>>> it did work!
>> >>>> That is,
>> >>>>
>> >>>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>> >>>
>> >>> Can you send us a sample of the output? Also, would be
>> >>> good to identify the exact driver for accel.
>> >>
>> >> cat /sys/bus/iio/devices/iio:device*/*raw*
>> >> 65478
>> >> 7
>> >> 1023
>> >> 0
>> >> 0
>> >> 0
>> >> 100
>> >> -539062
>> >> -742187
>> >> 1292968
>> >> 1592
>> >> 64932
>> >> 2
>> >> 275
>> >> 0 0 0 0
>> >>
>> >> Now, I should say that I distinctly remember at some point waving my
>> >> laptop around and seeing these values change ... but now they seem to
>> >> be "stuck". Maybe it's a hardware issue or something special that
>> >> WIndows does to leverage the IIO sensors?
>> >>
>> >>> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name
>> >>
>> >> $ cat /sys/bus/iio/devices/iio:device*/name
>> >> accel_3d
>> >
>> > Can you list the directory of iio:device with this name (it is:
>> > drivers/iio/accel/hid-sensor-accel-3d.c).
>> > This is something you will be looking at for accel debugging, but it
>> > seems more like
>> > standard
>>
>> /sys/bus/iio/devices/iio:device0/name
>> gyro_3d
>> /sys/bus/iio/devices/iio:device1/name
>> dev_rotation
>> /sys/bus/iio/devices/iio:device2/name
>> als
>> /sys/bus/iio/devices/iio:device3/name
>> magn_3d
>> /sys/bus/iio/devices/iio:device4/name
>> accel_3d
>> /sys/bus/iio/devices/iio:device5/name
>> incli_3d
>>
>> are all the IIO sensors, sorry about that!
>>
>
> I was more thinking what else is in iio:device4 directory, so that we can
> see if it was initialized OK. Can you also grep the dmesg for any errors?

Well, I just noticed the device #s are not consistent boot-to-boot, so
this time it was device0. Trimming out the directories:

/sys/bus/iio/devices/iio:device0/buffer
cat: /sys/bus/iio/devices/iio:device0/buffer: Is a directory
/sys/bus/iio/devices/iio:device0/dev
250:0
/sys/bus/iio/devices/iio:device0/in_accel_hysteresis
cat: /sys/bus/iio/devices/iio:device0/in_accel_hysteresis: Invalid argument
/sys/bus/iio/devices/iio:device0/in_accel_offset
0
/sys/bus/iio/devices/iio:device0/in_accel_sampling_frequency
8.00
/sys/bus/iio/devices/iio:device0/in_accel_scale
0.009806
/sys/bus/iio/devices/iio:device0/in_accel_x_raw
65478
/sys/bus/iio/devices/iio:device0/in_accel_y_raw
7
/sys/bus/iio/devices/iio:device0/in_accel_z_raw
1023
/sys/bus/iio/devices/iio:device0/name
accel_3d
/sys/bus/iio/devices/iio:device0/uevent
MAJOR=250
MINOR=0
DEVNAME=iio:device0
DEVTYPE=iio_device

Another thing I just noticed:

/sys/bus/iio/devices/iio:device0/buffer/enable
0

The only error I'm getting consistently is:

[1.115327] i2c_hid i2c-ITE8396:00: error in i2c_hid_init_report
size:19 / ret_size:18

which I don't think is relevant, but I might be wrong.

>> >> gyro_3d
>> >> als
>> >> magn_3d
>> >> incli_3d
>> >> dev_rotation
>> >>
>> >>
>> >>>>
>> >>>> showed updating values as I moved the laptop around.
>> >>>>
>> >>>> I've not do

Re: [RESEND] Lenovo Yoga 900 touchpad issues

[Nish Aravamudan]

Hi Jiri,

On Wed, Dec 16, 2015 at 5:18 AM, Jiri Kosina  wrote:
> On Wed, 16 Dec 2015, Mika Westerberg wrote:
>
>> > [Apologies for the resend, didn't realize I hadn't changed my GMail 
>> > settings
>> > to not use HTML.]
>> >
>> > I have recently purchased a Lenovo Yoga 900 and most everything is working
>> > with a slightly modified 4.4-rc5 (https://lkml.org/lkml/2015/11/30/441 
>> > applied
>> > to enable the touchpad itself), I am seeing two issues:
>> >
>> > 1) On suspend/resume, the touchpad is non-functional. A `modprobe -r 
>> > i2c-hid;
>> >  modprobe i2c-hid` "fixes" it.
>> >
>> > The kernel emits:
>> >
>> > i2c_hid i2c-SYNA2B29:00: failed to reset device.
>> > dpm_run_callback(): i2c_hid_resume+0x0/0xc0 [i2c_hid] returns -61
>> > PM: Device i2c-SYNA2B29:00 failed to resume: error -61
>> >
>> > During the resume. So perhaps this is a timing issue (given that once
>> > resumed, the
>> > module reload does work?).
>>
>> Linus noticed this as well and Jiri suggested the below patch which
>> seemed to fix the issue (although it increased resume time a bit).
>>
>> I was supposed to get one Lenovo Yoga 900 here to debug this issue but
>> I'm still waiting for it (sloow big corporation bureaucracy takes some
>> time to get things purchased outside).
>>
>> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
>> index 55d8f9d..52dd03a0 100644
>> --- a/drivers/hid/i2c-hid/i2c-hid.c
>> +++ b/drivers/hid/i2c-hid/i2c-hid.c
>> @@ -1121,10 +1121,16 @@ static int i2c_hid_resume(struct device *dev)
>>   struct i2c_client *client = to_i2c_client(dev);
>>   struct i2c_hid *ihid = i2c_get_clientdata(client);
>>   struct hid_device *hid = ihid->hid;
>> - int wake_status;
>> + int wake_status, tries = 3;
>>
>>   enable_irq(ihid->irq);
>> - ret = i2c_hid_hwreset(client);
>> +
>> + do {
>> + ret = i2c_hid_hwreset(client);
>> + if (ret)
>> + msleep(1000);
>> + } while (tries-- > 0 && ret);
>> +
>>   if (ret)
>>   return ret;
>
> As a possible alternative, please test the patch above on top of for-next
> branch of
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git
>
> It contains 64bebefcf3 ("HID: enable hid device to suspend/resume
> asynchronously") and knowing whether that changes something might be
> interesting datapoint as well.

What should I be looking for to be different wrt. that tree? Should I
not see the failure to reset the device? Or would it be (relatively)
speedier than the stock kernel?

Thanks,
Nish
--
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: [RESEND] Lenovo Yoga 900 touchpad issues

[Nish Aravamudan]

On Wed, Dec 16, 2015 at 1:28 AM, Mika Westerberg
 wrote:
> On Tue, Dec 15, 2015 at 11:14:32AM -0800, Nish Aravamudan wrote:
>> [Apologies for the resend, didn't realize I hadn't changed my GMail settings
>> to not use HTML.]
>>
>> I have recently purchased a Lenovo Yoga 900 and most everything is working
>> with a slightly modified 4.4-rc5 (https://lkml.org/lkml/2015/11/30/441 
>> applied
>> to enable the touchpad itself), I am seeing two issues:
>>
>> 1) On suspend/resume, the touchpad is non-functional. A `modprobe -r i2c-hid;
>>  modprobe i2c-hid` "fixes" it.
>>
>> The kernel emits:
>>
>> i2c_hid i2c-SYNA2B29:00: failed to reset device.
>> dpm_run_callback(): i2c_hid_resume+0x0/0xc0 [i2c_hid] returns -61
>> PM: Device i2c-SYNA2B29:00 failed to resume: error -61
>>
>> During the resume. So perhaps this is a timing issue (given that once
>> resumed, the
>> module reload does work?).
>
> Linus noticed this as well and Jiri suggested the below patch which
> seemed to fix the issue (although it increased resume time a bit).
>
> I was supposed to get one Lenovo Yoga 900 here to debug this issue but
> I'm still waiting for it (sloow big corporation bureaucracy takes some
> time to get things purchased outside).

With the patch applied to my patched 4.4-rc5, things seem to be
working now. I do get one "failed to reset device" message in the
logs, but then I'm guessing the second one succeeds and I don't see
the "failed to resume" message.

-Nish
--
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: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

Hi,

On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori  wrote:
> On 16 December 2015 at 22:41, Nish Aravamudan  
> wrote:
>> Hi Daniel,
>>
>> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta  
>> wrote:
>>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>>>  wrote:
>>>> So, I apologize in advance for this relatively vague report, but I'm 
>>>> fairly sure
>>>> the Yoga 900 has an accelerometer amongst other sensors (ambient light?)
>>>> exported over IIO.
>>>>
>>>> But, these sensors seem to not be updating at all with a 4.4-rc5+ kernel (a
>>>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied to Linus'
>>>> tree).
>>>>
>>>> The odd part is at some point in messing with this, I'm fairly sure it did 
>>>> work!
>>>> That is,
>>>>
>>>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>>>
>>> Can you send us a sample of the output? Also, would be
>>> good to identify the exact driver for accel.
>>
>> cat /sys/bus/iio/devices/iio:device*/*raw*
>> 65478
>> 7
>> 1023
>> 0
>> 0
>> 0
>> 100
>> -539062
>> -742187
>> 1292968
>> 1592
>> 64932
>> 2
>> 275
>> 0 0 0 0
>>
>> Now, I should say that I distinctly remember at some point waving my
>> laptop around and seeing these values change ... but now they seem to
>> be "stuck". Maybe it's a hardware issue or something special that
>> WIndows does to leverage the IIO sensors?
>>
>>> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name
>>
>> $ cat /sys/bus/iio/devices/iio:device*/name
>> accel_3d
>
> Can you list the directory of iio:device with this name (it is:
> drivers/iio/accel/hid-sensor-accel-3d.c).
> This is something you will be looking at for accel debugging, but it
> seems more like
> standard

/sys/bus/iio/devices/iio:device0/name
gyro_3d
/sys/bus/iio/devices/iio:device1/name
dev_rotation
/sys/bus/iio/devices/iio:device2/name
als
/sys/bus/iio/devices/iio:device3/name
magn_3d
/sys/bus/iio/devices/iio:device4/name
accel_3d
/sys/bus/iio/devices/iio:device5/name
incli_3d

are all the IIO sensors, sorry about that!

>> gyro_3d
>> als
>> magn_3d
>> incli_3d
>> dev_rotation
>>
>>
>>>>
>>>> showed updating values as I moved the laptop around.
>>>>
>>>> I've not done any accelerometer debugging before, so any suggestion on
>>>> where to start would be greatly appreciated!
>>>
>>> Did you applied some patches and recompiled the kernel? Or when it did 
>>> stopped
>>> working?
>>
>> As far as I can tell, it only worked that one one time and hasn't
>> since. Although your question does make me wonder *which* kernel I was
>> on that I experienced the values changing. Let me go back to a stock
>> 4.4-rc5 and see.
>
> Did you compile the stock kernel? It might be that .dts file you are
> using (or defconfig)
> is not correct.

I compiled the stock kernel, based off the the Ubuntu 15.04 .config,
trimmed to account for the hardware I have on the system. I can attach
the .config if that will be useful.

I just went back to 4.4-rc4 and it also didn't seem to have any
updates to the raw file contents.

-Nish
--
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: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

Hi Daniel,

On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta  wrote:
> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>  wrote:
>> So, I apologize in advance for this relatively vague report, but I'm fairly 
>> sure
>> the Yoga 900 has an accelerometer amongst other sensors (ambient light?)
>> exported over IIO.
>>
>> But, these sensors seem to not be updating at all with a 4.4-rc5+ kernel (a
>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied to Linus'
>> tree).
>>
>> The odd part is at some point in messing with this, I'm fairly sure it did 
>> work!
>> That is,
>>
>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>
> Can you send us a sample of the output? Also, would be
> good to identify the exact driver for accel.

cat /sys/bus/iio/devices/iio:device*/*raw*
65478
7
1023
0
0
0
100
-539062
-742187
1292968
1592
64932
2
275
0 0 0 0

Now, I should say that I distinctly remember at some point waving my
laptop around and seeing these values change ... but now they seem to
be "stuck". Maybe it's a hardware issue or something special that
WIndows does to leverage the IIO sensors?

> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name

$ cat /sys/bus/iio/devices/iio:device*/name
accel_3d
gyro_3d
als
magn_3d
incli_3d
dev_rotation


>>
>> showed updating values as I moved the laptop around.
>>
>> I've not done any accelerometer debugging before, so any suggestion on
>> where to start would be greatly appreciated!
>
> Did you applied some patches and recompiled the kernel? Or when it did stopped
> working?

As far as I can tell, it only worked that one one time and hasn't
since. Although your question does make me wonder *which* kernel I was
on that I experienced the values changing. Let me go back to a stock
4.4-rc5 and see.

-Nish
--
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: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

On Wed, Dec 16, 2015 at 1:31 AM, Crt Mori  wrote:
> Hi,
> So you were using 4.4-rc5 before and it worked, but after applying a
> patch it stopped?

Sorry, I should have explained it better. Without the patchset
referred to in my original e-mail, the touchpad simply doesn't work.
However, I do have an external mouse, so let me go back to stock
4.4-rc5 and test the IIO inputs.

Thanks,
Nish
--
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: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

On Wed, Dec 16, 2015 at 2:55 PM, Crt Mori <c...@melexis.com> wrote:
>
> On Dec 16, 2015 11:37 PM, "Nish Aravamudan" <nish.aravamu...@gmail.com>
> wrote:
>>
>> Hi,
>>
>> On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori <c...@melexis.com> wrote:
>> > On 16 December 2015 at 22:41, Nish Aravamudan
>> > <nish.aravamu...@gmail.com> wrote:
>> >> Hi Daniel,
>> >>
>> >> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta
>> >> <daniel.bal...@gmail.com> wrote:
>> >>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>> >>> <nish.aravamu...@gmail.com> wrote:
>> >>>> So, I apologize in advance for this relatively vague report, but I'm
>> >>>> fairly sure
>> >>>> the Yoga 900 has an accelerometer amongst other sensors (ambient
>> >>>> light?)
>> >>>> exported over IIO.
>> >>>>
>> >>>> But, these sensors seem to not be updating at all with a 4.4-rc5+
>> >>>> kernel (a
>> >>>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied to
>> >>>> Linus'
>> >>>> tree).
>> >>>>
>> >>>> The odd part is at some point in messing with this, I'm fairly sure
>> >>>> it did work!
>> >>>> That is,
>> >>>>
>> >>>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>> >>>
>> >>> Can you send us a sample of the output? Also, would be
>> >>> good to identify the exact driver for accel.
>> >>
>> >> cat /sys/bus/iio/devices/iio:device*/*raw*
>> >> 65478
>> >> 7
>> >> 1023
>> >> 0
>> >> 0
>> >> 0
>> >> 100
>> >> -539062
>> >> -742187
>> >> 1292968
>> >> 1592
>> >> 64932
>> >> 2
>> >> 275
>> >> 0 0 0 0
>> >>
>> >> Now, I should say that I distinctly remember at some point waving my
>> >> laptop around and seeing these values change ... but now they seem to
>> >> be "stuck". Maybe it's a hardware issue or something special that
>> >> WIndows does to leverage the IIO sensors?
>> >>
>> >>> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name
>> >>
>> >> $ cat /sys/bus/iio/devices/iio:device*/name
>> >> accel_3d
>> >
>> > Can you list the directory of iio:device with this name (it is:
>> > drivers/iio/accel/hid-sensor-accel-3d.c).
>> > This is something you will be looking at for accel debugging, but it
>> > seems more like
>> > standard
>>
>> /sys/bus/iio/devices/iio:device0/name
>> gyro_3d
>> /sys/bus/iio/devices/iio:device1/name
>> dev_rotation
>> /sys/bus/iio/devices/iio:device2/name
>> als
>> /sys/bus/iio/devices/iio:device3/name
>> magn_3d
>> /sys/bus/iio/devices/iio:device4/name
>> accel_3d
>> /sys/bus/iio/devices/iio:device5/name
>> incli_3d
>>
>> are all the IIO sensors, sorry about that!
>>
>
> I was more thinking what else is in iio:device4 directory, so that we can
> see if it was initialized OK. Can you also grep the dmesg for any errors?

Well, I just noticed the device #s are not consistent boot-to-boot, so
this time it was device0. Trimming out the directories:

/sys/bus/iio/devices/iio:device0/buffer
cat: /sys/bus/iio/devices/iio:device0/buffer: Is a directory
/sys/bus/iio/devices/iio:device0/dev
250:0
/sys/bus/iio/devices/iio:device0/in_accel_hysteresis
cat: /sys/bus/iio/devices/iio:device0/in_accel_hysteresis: Invalid argument
/sys/bus/iio/devices/iio:device0/in_accel_offset
0
/sys/bus/iio/devices/iio:device0/in_accel_sampling_frequency
8.00
/sys/bus/iio/devices/iio:device0/in_accel_scale
0.009806
/sys/bus/iio/devices/iio:device0/in_accel_x_raw
65478
/sys/bus/iio/devices/iio:device0/in_accel_y_raw
7
/sys/bus/iio/devices/iio:device0/in_accel_z_raw
1023
/sys/bus/iio/devices/iio:device0/name
accel_3d
/sys/bus/iio/devices/iio:device0/uevent
MAJOR=250
MINOR=0
DEVNAME=iio:device0
DEVTYPE=iio_device

Another thing I just noticed:

/sys/bus/iio/devices/iio:device0/buffer/enable
0

The only error I'm getting consistently is:

[1.115327] i2c_hid i2c-ITE8396:00: error in i2c_hid_init_report
size:19 / ret_size:18

which I don't think is relevant, but I might be wrong.

>> >> gyro_3d
>> >> als
>> >> magn_3d
>> >> incli_3d
>> >> dev_rotation
>> >>
>>

Re: [RESEND] Lenovo Yoga 900 touchpad issues

[Nish Aravamudan]

Hi Jiri,

On Wed, Dec 16, 2015 at 5:18 AM, Jiri Kosina  wrote:
> On Wed, 16 Dec 2015, Mika Westerberg wrote:
>
>> > [Apologies for the resend, didn't realize I hadn't changed my GMail 
>> > settings
>> > to not use HTML.]
>> >
>> > I have recently purchased a Lenovo Yoga 900 and most everything is working
>> > with a slightly modified 4.4-rc5 (https://lkml.org/lkml/2015/11/30/441 
>> > applied
>> > to enable the touchpad itself), I am seeing two issues:
>> >
>> > 1) On suspend/resume, the touchpad is non-functional. A `modprobe -r 
>> > i2c-hid;
>> >  modprobe i2c-hid` "fixes" it.
>> >
>> > The kernel emits:
>> >
>> > i2c_hid i2c-SYNA2B29:00: failed to reset device.
>> > dpm_run_callback(): i2c_hid_resume+0x0/0xc0 [i2c_hid] returns -61
>> > PM: Device i2c-SYNA2B29:00 failed to resume: error -61
>> >
>> > During the resume. So perhaps this is a timing issue (given that once
>> > resumed, the
>> > module reload does work?).
>>
>> Linus noticed this as well and Jiri suggested the below patch which
>> seemed to fix the issue (although it increased resume time a bit).
>>
>> I was supposed to get one Lenovo Yoga 900 here to debug this issue but
>> I'm still waiting for it (sloow big corporation bureaucracy takes some
>> time to get things purchased outside).
>>
>> diff --git a/drivers/hid/i2c-hid/i2c-hid.c b/drivers/hid/i2c-hid/i2c-hid.c
>> index 55d8f9d..52dd03a0 100644
>> --- a/drivers/hid/i2c-hid/i2c-hid.c
>> +++ b/drivers/hid/i2c-hid/i2c-hid.c
>> @@ -1121,10 +1121,16 @@ static int i2c_hid_resume(struct device *dev)
>>   struct i2c_client *client = to_i2c_client(dev);
>>   struct i2c_hid *ihid = i2c_get_clientdata(client);
>>   struct hid_device *hid = ihid->hid;
>> - int wake_status;
>> + int wake_status, tries = 3;
>>
>>   enable_irq(ihid->irq);
>> - ret = i2c_hid_hwreset(client);
>> +
>> + do {
>> + ret = i2c_hid_hwreset(client);
>> + if (ret)
>> + msleep(1000);
>> + } while (tries-- > 0 && ret);
>> +
>>   if (ret)
>>   return ret;
>
> As a possible alternative, please test the patch above on top of for-next
> branch of
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid.git
>
> It contains 64bebefcf3 ("HID: enable hid device to suspend/resume
> asynchronously") and knowing whether that changes something might be
> interesting datapoint as well.

What should I be looking for to be different wrt. that tree? Should I
not see the failure to reset the device? Or would it be (relatively)
speedier than the stock kernel?

Thanks,
Nish
--
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: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

On Wed, Dec 16, 2015 at 1:31 AM, Crt Mori  wrote:
> Hi,
> So you were using 4.4-rc5 before and it worked, but after applying a
> patch it stopped?

Sorry, I should have explained it better. Without the patchset
referred to in my original e-mail, the touchpad simply doesn't work.
However, I do have an external mouse, so let me go back to stock
4.4-rc5 and test the IIO inputs.

Thanks,
Nish
--
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: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

Hi,

On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori <c...@melexis.com> wrote:
> On 16 December 2015 at 22:41, Nish Aravamudan <nish.aravamu...@gmail.com> 
> wrote:
>> Hi Daniel,
>>
>> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta <daniel.bal...@gmail.com> 
>> wrote:
>>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>>> <nish.aravamu...@gmail.com> wrote:
>>>> So, I apologize in advance for this relatively vague report, but I'm 
>>>> fairly sure
>>>> the Yoga 900 has an accelerometer amongst other sensors (ambient light?)
>>>> exported over IIO.
>>>>
>>>> But, these sensors seem to not be updating at all with a 4.4-rc5+ kernel (a
>>>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied to Linus'
>>>> tree).
>>>>
>>>> The odd part is at some point in messing with this, I'm fairly sure it did 
>>>> work!
>>>> That is,
>>>>
>>>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>>>
>>> Can you send us a sample of the output? Also, would be
>>> good to identify the exact driver for accel.
>>
>> cat /sys/bus/iio/devices/iio:device*/*raw*
>> 65478
>> 7
>> 1023
>> 0
>> 0
>> 0
>> 100
>> -539062
>> -742187
>> 1292968
>> 1592
>> 64932
>> 2
>> 275
>> 0 0 0 0
>>
>> Now, I should say that I distinctly remember at some point waving my
>> laptop around and seeing these values change ... but now they seem to
>> be "stuck". Maybe it's a hardware issue or something special that
>> WIndows does to leverage the IIO sensors?
>>
>>> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name
>>
>> $ cat /sys/bus/iio/devices/iio:device*/name
>> accel_3d
>
> Can you list the directory of iio:device with this name (it is:
> drivers/iio/accel/hid-sensor-accel-3d.c).
> This is something you will be looking at for accel debugging, but it
> seems more like
> standard

/sys/bus/iio/devices/iio:device0/name
gyro_3d
/sys/bus/iio/devices/iio:device1/name
dev_rotation
/sys/bus/iio/devices/iio:device2/name
als
/sys/bus/iio/devices/iio:device3/name
magn_3d
/sys/bus/iio/devices/iio:device4/name
accel_3d
/sys/bus/iio/devices/iio:device5/name
incli_3d

are all the IIO sensors, sorry about that!

>> gyro_3d
>> als
>> magn_3d
>> incli_3d
>> dev_rotation
>>
>>
>>>>
>>>> showed updating values as I moved the laptop around.
>>>>
>>>> I've not done any accelerometer debugging before, so any suggestion on
>>>> where to start would be greatly appreciated!
>>>
>>> Did you applied some patches and recompiled the kernel? Or when it did 
>>> stopped
>>> working?
>>
>> As far as I can tell, it only worked that one one time and hasn't
>> since. Although your question does make me wonder *which* kernel I was
>> on that I experienced the values changing. Let me go back to a stock
>> 4.4-rc5 and see.
>
> Did you compile the stock kernel? It might be that .dts file you are
> using (or defconfig)
> is not correct.

I compiled the stock kernel, based off the the Ubuntu 15.04 .config,
trimmed to account for the hardware I have on the system. I can attach
the .config if that will be useful.

I just went back to 4.4-rc4 and it also didn't seem to have any
updates to the raw file contents.

-Nish
--
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: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

Hi Daniel,

On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta <daniel.bal...@gmail.com> wrote:
> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
> <nish.aravamu...@gmail.com> wrote:
>> So, I apologize in advance for this relatively vague report, but I'm fairly 
>> sure
>> the Yoga 900 has an accelerometer amongst other sensors (ambient light?)
>> exported over IIO.
>>
>> But, these sensors seem to not be updating at all with a 4.4-rc5+ kernel (a
>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied to Linus'
>> tree).
>>
>> The odd part is at some point in messing with this, I'm fairly sure it did 
>> work!
>> That is,
>>
>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>
> Can you send us a sample of the output? Also, would be
> good to identify the exact driver for accel.

cat /sys/bus/iio/devices/iio:device*/*raw*
65478
7
1023
0
0
0
100
-539062
-742187
1292968
1592
64932
2
275
0 0 0 0

Now, I should say that I distinctly remember at some point waving my
laptop around and seeing these values change ... but now they seem to
be "stuck". Maybe it's a hardware issue or something special that
WIndows does to leverage the IIO sensors?

> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name

$ cat /sys/bus/iio/devices/iio:device*/name
accel_3d
gyro_3d
als
magn_3d
incli_3d
dev_rotation


>>
>> showed updating values as I moved the laptop around.
>>
>> I've not done any accelerometer debugging before, so any suggestion on
>> where to start would be greatly appreciated!
>
> Did you applied some patches and recompiled the kernel? Or when it did stopped
> working?

As far as I can tell, it only worked that one one time and hasn't
since. Although your question does make me wonder *which* kernel I was
on that I experienced the values changing. Let me go back to a stock
4.4-rc5 and see.

-Nish
--
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: [RESEND] Lenovo Yoga 900 touchpad issues

[Nish Aravamudan]

On Wed, Dec 16, 2015 at 1:28 AM, Mika Westerberg
<mika.westerb...@linux.intel.com> wrote:
> On Tue, Dec 15, 2015 at 11:14:32AM -0800, Nish Aravamudan wrote:
>> [Apologies for the resend, didn't realize I hadn't changed my GMail settings
>> to not use HTML.]
>>
>> I have recently purchased a Lenovo Yoga 900 and most everything is working
>> with a slightly modified 4.4-rc5 (https://lkml.org/lkml/2015/11/30/441 
>> applied
>> to enable the touchpad itself), I am seeing two issues:
>>
>> 1) On suspend/resume, the touchpad is non-functional. A `modprobe -r i2c-hid;
>>  modprobe i2c-hid` "fixes" it.
>>
>> The kernel emits:
>>
>> i2c_hid i2c-SYNA2B29:00: failed to reset device.
>> dpm_run_callback(): i2c_hid_resume+0x0/0xc0 [i2c_hid] returns -61
>> PM: Device i2c-SYNA2B29:00 failed to resume: error -61
>>
>> During the resume. So perhaps this is a timing issue (given that once
>> resumed, the
>> module reload does work?).
>
> Linus noticed this as well and Jiri suggested the below patch which
> seemed to fix the issue (although it increased resume time a bit).
>
> I was supposed to get one Lenovo Yoga 900 here to debug this issue but
> I'm still waiting for it (sloow big corporation bureaucracy takes some
> time to get things purchased outside).

With the patch applied to my patched 4.4-rc5, things seem to be
working now. I do get one "failed to reset device" message in the
logs, but then I'm guessing the second one succeeds and I don't see
the "failed to resume" message.

-Nish
--
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: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

On Wed, Dec 16, 2015 at 3:05 PM, Nish Aravamudan
<nish.aravamu...@gmail.com> wrote:
> On Wed, Dec 16, 2015 at 2:55 PM, Crt Mori <c...@melexis.com> wrote:
>>
>> On Dec 16, 2015 11:37 PM, "Nish Aravamudan" <nish.aravamu...@gmail.com>
>> wrote:
>>>
>>> Hi,
>>>
>>> On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori <c...@melexis.com> wrote:
>>> > On 16 December 2015 at 22:41, Nish Aravamudan
>>> > <nish.aravamu...@gmail.com> wrote:
>>> >> Hi Daniel,
>>> >>
>>> >> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta
>>> >> <daniel.bal...@gmail.com> wrote:
>>> >>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>>> >>> <nish.aravamu...@gmail.com> wrote:
>>> >>>> So, I apologize in advance for this relatively vague report, but I'm
>>> >>>> fairly sure
>>> >>>> the Yoga 900 has an accelerometer amongst other sensors (ambient
>>> >>>> light?)
>>> >>>> exported over IIO.
>>> >>>>
>>> >>>> But, these sensors seem to not be updating at all with a 4.4-rc5+
>>> >>>> kernel (a
>>> >>>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied to
>>> >>>> Linus'
>>> >>>> tree).
>>> >>>>
>>> >>>> The odd part is at some point in messing with this, I'm fairly sure
>>> >>>> it did work!
>>> >>>> That is,
>>> >>>>
>>> >>>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>>> >>>
>>> >>> Can you send us a sample of the output? Also, would be
>>> >>> good to identify the exact driver for accel.
>>> >>
>>> >> cat /sys/bus/iio/devices/iio:device*/*raw*
>>> >> 65478
>>> >> 7
>>> >> 1023
>>> >> 0
>>> >> 0
>>> >> 0
>>> >> 100
>>> >> -539062
>>> >> -742187
>>> >> 1292968
>>> >> 1592
>>> >> 64932
>>> >> 2
>>> >> 275
>>> >> 0 0 0 0
>>> >>
>>> >> Now, I should say that I distinctly remember at some point waving my
>>> >> laptop around and seeing these values change ... but now they seem to
>>> >> be "stuck". Maybe it's a hardware issue or something special that
>>> >> WIndows does to leverage the IIO sensors?
>>> >>
>>> >>> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name
>>> >>
>>> >> $ cat /sys/bus/iio/devices/iio:device*/name
>>> >> accel_3d
>>> >
>>> > Can you list the directory of iio:device with this name (it is:
>>> > drivers/iio/accel/hid-sensor-accel-3d.c).
>>> > This is something you will be looking at for accel debugging, but it
>>> > seems more like
>>> > standard
>>>
>>> /sys/bus/iio/devices/iio:device0/name
>>> gyro_3d
>>> /sys/bus/iio/devices/iio:device1/name
>>> dev_rotation
>>> /sys/bus/iio/devices/iio:device2/name
>>> als
>>> /sys/bus/iio/devices/iio:device3/name
>>> magn_3d
>>> /sys/bus/iio/devices/iio:device4/name
>>> accel_3d
>>> /sys/bus/iio/devices/iio:device5/name
>>> incli_3d
>>>
>>> are all the IIO sensors, sorry about that!
>>>
>>
>> I was more thinking what else is in iio:device4 directory, so that we can
>> see if it was initialized OK. Can you also grep the dmesg for any errors?
>
> Well, I just noticed the device #s are not consistent boot-to-boot, so
> this time it was device0. Trimming out the directories:
>
> /sys/bus/iio/devices/iio:device0/buffer
> cat: /sys/bus/iio/devices/iio:device0/buffer: Is a directory
> /sys/bus/iio/devices/iio:device0/dev
> 250:0
> /sys/bus/iio/devices/iio:device0/in_accel_hysteresis
> cat: /sys/bus/iio/devices/iio:device0/in_accel_hysteresis: Invalid argument
> /sys/bus/iio/devices/iio:device0/in_accel_offset
> 0
> /sys/bus/iio/devices/iio:device0/in_accel_sampling_frequency
> 8.00
> /sys/bus/iio/devices/iio:device0/in_accel_scale
> 0.009806
> /sys/bus/iio/devices/iio:device0/in_accel_x_raw
> 65478
> /sys/bus/iio/devices/iio:device0/in_accel_y_raw
> 7
> /sys/bus/iio/devices/iio:device0/in_accel_z_raw
> 1023
> /sys/bus/i

"special" key when Lenovo Yoga 900 in tablet mode

[Nish Aravamudan]

So the Lenovo Yoga 900 has 4 "modes" (laptop, tent, stand and tablet).
In tablet mode, it appears that the following is printed roughly every
second:

atkbd serio0: Unknown key pressed (translated set 2, code 0xbf on
isa0060/serio0).
atkbd serio0: Use 'setkeycodes e03f ' to make it known.
ideapad_laptop: Unknown event: 1
atkbd serio0: Unknown key released (translated set 2, code 0xbf on
isa0060/serio0).
atkbd serio0: Use 'setkeycodes e03f ' to make it known.
ideapad_laptop: Unknown event: 1

What I would like to do is rotate the screen when I see the unknown
key (a la https://gist.github.com/emiller/6488449), although that's not
super-efficient, but is fine. But I'm wondering if the ideapad event
should actually be properly handled and how that would be done? I
guess it could also just emit a key like the other ideapad values?

Thanks,
Nish
--
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/

[RESEND] Lenovo Yoga 900 touchpad issues

[Nish Aravamudan]

[Apologies for the resend, didn't realize I hadn't changed my GMail settings
to not use HTML.]

I have recently purchased a Lenovo Yoga 900 and most everything is working
with a slightly modified 4.4-rc5 (https://lkml.org/lkml/2015/11/30/441 applied
to enable the touchpad itself), I am seeing two issues:

1) On suspend/resume, the touchpad is non-functional. A `modprobe -r i2c-hid;
 modprobe i2c-hid` "fixes" it.

The kernel emits:

i2c_hid i2c-SYNA2B29:00: failed to reset device.
dpm_run_callback(): i2c_hid_resume+0x0/0xc0 [i2c_hid] returns -61
PM: Device i2c-SYNA2B29:00 failed to resume: error -61

During the resume. So perhaps this is a timing issue (given that once
resumed, the
module reload does work?).

2) During boot, the following is emitted:

i2c_hid i2c-ITE8396:00: error in i2c_hid_init_report size:19 / ret_size:18

I'm not sure if this indicates a hardware or driver bug? With
i2c-hid.debug=1, I see:

i2c_hid i2c-ITE8396:00: report (len=19): 12 00 5a ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff 06
i2c_hid i2c-ITE8396:00: error in i2c_hid_init_report size:19 / ret_size:18

Any suggestions?

Thanks,
Nish
--
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/

Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

So, I apologize in advance for this relatively vague report, but I'm fairly sure
the Yoga 900 has an accelerometer amongst other sensors (ambient light?)
exported over IIO.

But, these sensors seem to not be updating at all with a 4.4-rc5+ kernel (a
set of patches from https://lkml.org/lkml/2015/11/30/441 applied to Linus'
tree).

The odd part is at some point in messing with this, I'm fairly sure it did work!
That is,

`watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`

showed updating values as I moved the laptop around.

I've not done any accelerometer debugging before, so any suggestion on
where to start would be greatly appreciated!

-Nish
--
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/

Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

So, I apologize in advance for this relatively vague report, but I'm fairly sure
the Yoga 900 has an accelerometer amongst other sensors (ambient light?)
exported over IIO.

But, these sensors seem to not be updating at all with a 4.4-rc5+ kernel (a
set of patches from https://lkml.org/lkml/2015/11/30/441 applied to Linus'
tree).

The odd part is at some point in messing with this, I'm fairly sure it did work!
That is,

`watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`

showed updating values as I moved the laptop around.

I've not done any accelerometer debugging before, so any suggestion on
where to start would be greatly appreciated!

-Nish
--
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/

[RESEND] Lenovo Yoga 900 touchpad issues

[Nish Aravamudan]

[Apologies for the resend, didn't realize I hadn't changed my GMail settings
to not use HTML.]

I have recently purchased a Lenovo Yoga 900 and most everything is working
with a slightly modified 4.4-rc5 (https://lkml.org/lkml/2015/11/30/441 applied
to enable the touchpad itself), I am seeing two issues:

1) On suspend/resume, the touchpad is non-functional. A `modprobe -r i2c-hid;
 modprobe i2c-hid` "fixes" it.

The kernel emits:

i2c_hid i2c-SYNA2B29:00: failed to reset device.
dpm_run_callback(): i2c_hid_resume+0x0/0xc0 [i2c_hid] returns -61
PM: Device i2c-SYNA2B29:00 failed to resume: error -61

During the resume. So perhaps this is a timing issue (given that once
resumed, the
module reload does work?).

2) During boot, the following is emitted:

i2c_hid i2c-ITE8396:00: error in i2c_hid_init_report size:19 / ret_size:18

I'm not sure if this indicates a hardware or driver bug? With
i2c-hid.debug=1, I see:

i2c_hid i2c-ITE8396:00: report (len=19): 12 00 5a ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff 06
i2c_hid i2c-ITE8396:00: error in i2c_hid_init_report size:19 / ret_size:18

Any suggestions?

Thanks,
Nish
--
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/

"special" key when Lenovo Yoga 900 in tablet mode

[Nish Aravamudan]

So the Lenovo Yoga 900 has 4 "modes" (laptop, tent, stand and tablet).
In tablet mode, it appears that the following is printed roughly every
second:

atkbd serio0: Unknown key pressed (translated set 2, code 0xbf on
isa0060/serio0).
atkbd serio0: Use 'setkeycodes e03f ' to make it known.
ideapad_laptop: Unknown event: 1
atkbd serio0: Unknown key released (translated set 2, code 0xbf on
isa0060/serio0).
atkbd serio0: Use 'setkeycodes e03f ' to make it known.
ideapad_laptop: Unknown event: 1

What I would like to do is rotate the screen when I see the unknown
key (a la https://gist.github.com/emiller/6488449), although that's not
super-efficient, but is fine. But I'm wondering if the ideapad event
should actually be properly handled and how that would be done? I
guess it could also just emit a key like the other ideapad values?

Thanks,
Nish
--
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: [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os

[Nish Aravamudan]

On 2/22/08, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Fri, 22 Feb 2008 19:08:15 +0100 Sam Ravnborg wrote:
>
>  > On Thu, Feb 21, 2008 at 05:38:52PM -0800, Nish Aravamudan wrote:
>  > > On 2/21/08, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>  > > > On Thu, Feb 21, 2008 at 10:54:40AM -0800, Nish Aravamudan wrote:
>  > > >  > On 2/20/08, Len Brown <[EMAIL PROTECTED]> wrote:
>  > > >  > > On Saturday 16 February 2008 14:47, Kamalesh Babulal wrote:
>  > > >  > >  > Hi Andrew,
>  > > >  > >  >
>  > > >  > >  > The 2.6.25-rc2-mm1 kernel with randconfig build option, fails
>  > > >  > >  > to build on x86_64 machine
>  > > >  > >  >
>  > > >  > >  >   CC  drivers/acpi/osl.o
>  > > >  > >  > drivers/acpi/osl.c:60:38: error: empty filename in #include
>  > > >  > >  > drivers/acpi/osl.c: In function 'acpi_os_table_override':
>  > > >  > >  > drivers/acpi/osl.c:399: error: 'AmlCode' undeclared (first use 
> in this function)
>  > > >  > >  > drivers/acpi/osl.c:399: error: (Each undeclared identifier is 
> reported only once
>  > > >  > >  > drivers/acpi/osl.c:399: error: for each function it appears 
> in.)
>  > > >  > >  > make[2]: *** [drivers/acpi/osl.o] Error 1
>  > > >  > >  > make[1]: *** [drivers/acpi] Error 2
>  > > >  > >  > make: *** [drivers] Error 2
>  > > >  > >  >
>  > > >  > >  > #
>  > > >  > >  > # Automatically generated make config: don't edit
>  > > >  > >  > # Linux kernel version: 2.6.25-rc2-mm1
>  > > >  > >  > # Sun Feb 17 08:07:17 2008
>  > > >  > >  > #
>  > > >  > >
>  > > >  > >
>  > > >  > > > CONFIG_ACPI_CUSTOM_DSDT=y
>  > > >  > >  > CONFIG_ACPI_CUSTOM_DSDT_FILE=""
>  > > >  > >
>  > > >  > >
>  > > >  > > garbage in, garbage out.
>  > > >  >
>  > > >  > garbage explicitly *allowed* by Kconfig in this case, though.
>  > > >  >
>  > > >  > >  If you don't give this build option a file name where AmlCode 
> lives,
>  > > >  > >  then the build will be unable to find AmlCode[].
>  > > >  > >
>  > > >  > >  http://www.lesswatts.org/projects/acpi/overridingDSDT.php
>  > > >  >
>  > > >  > So we have a .config option whose sole purpose is to use another
>  > > >  > .config option? That seems ... less than ideal. Is there not some
>  > > >  > Kconfig voodoo we can do to only require the one option? Maybe
>  > > >  > something like how CONFIG_INITRAMFS_SOURCE is done? Adding Sam to 
> the
>  > > >  > Cc, in case he has any ideas.
>  > > >
>  > > >
>  > > > Make sure STANDALONE is y for your randconfig builds.
>  > > >  See README for examples.
>  > >
>  > > Hrm, if this is needed for randconfig to work, perhaps randconfig
>  > > itself should somehow be specifying it?
>  > >
>  > > >  STANALONE is there exactly to prevent the above but we cannot
>  > > >  control randconfig.
>  > >
>  > > While setting STANDALONE does fix the above, it doesn't answer the
>  > > more basic question I had -- do we really need both .config options in
>  > > this case? If it's simply a case of "That's how it is, won't be fixed,
>  > > there are higher priorities", that's good enough by me. Just seems a
>  > > shame that we have an option to enable another option, which is
>  > > required for the first option to be sensible -- seems like we should
>  > > only need the second option...
>  >
>  > I really do not see what problem you are trying to address.
>  >
>  > STANDALONE is there as an easy way to turn of the options that requires
>  > sensible input to make a kernel compile.
>  >
>  > And that makes _perfect_ sense when you do randconfig builds.
>
>
>  > CONFIG_ACPI_CUSTOM_DSDT=y
>  > CONFIG_ACPI_CUSTOM_DSDT_FILE=""
>
>
> Is there a way to generate (in Kconfig language) the boolean
>  CONFIG_ACPI_CUSTOM_DSDT based on whether CONFIG_ACPI_CUSTOM_DSDT_FILE
>  == "" or != "" ?  I tried to muck around with that last night but
>  couldn't get it to work.  I.e., just present the ACPI_CUSTOM_DSDT_FILE
>  config symbol to the user and then generate the ACPI_CUSTOM_DSDT bool
>  based on the string value.

Thanks for re-expressing my question, Randy, this is exactly what I'm wondering.

Thanks,
Nish
--
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: [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os

[Nish Aravamudan]

On 2/22/08, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 21, 2008 at 05:38:52PM -0800, Nish Aravamudan wrote:
>  > On 2/21/08, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
>  > > On Thu, Feb 21, 2008 at 10:54:40AM -0800, Nish Aravamudan wrote:
>  > >  > On 2/20/08, Len Brown <[EMAIL PROTECTED]> wrote:
>  > >  > > On Saturday 16 February 2008 14:47, Kamalesh Babulal wrote:
>  > >  > >  > Hi Andrew,
>  > >  > >  >
>  > >  > >  > The 2.6.25-rc2-mm1 kernel with randconfig build option, fails
>  > >  > >  > to build on x86_64 machine
>  > >  > >  >
>  > >  > >  >   CC  drivers/acpi/osl.o
>  > >  > >  > drivers/acpi/osl.c:60:38: error: empty filename in #include
>  > >  > >  > drivers/acpi/osl.c: In function 'acpi_os_table_override':
>  > >  > >  > drivers/acpi/osl.c:399: error: 'AmlCode' undeclared (first use 
> in this function)
>  > >  > >  > drivers/acpi/osl.c:399: error: (Each undeclared identifier is 
> reported only once
>  > >  > >  > drivers/acpi/osl.c:399: error: for each function it appears in.)
>  > >  > >  > make[2]: *** [drivers/acpi/osl.o] Error 1
>  > >  > >  > make[1]: *** [drivers/acpi] Error 2
>  > >  > >  > make: *** [drivers] Error 2
>  > >  > >  >
>  > >  > >  > #
>  > >  > >  > # Automatically generated make config: don't edit
>  > >  > >  > # Linux kernel version: 2.6.25-rc2-mm1
>  > >  > >  > # Sun Feb 17 08:07:17 2008
>  > >  > >  > #
>  > >  > >
>  > >  > >
>  > >  > > > CONFIG_ACPI_CUSTOM_DSDT=y
>  > >  > >  > CONFIG_ACPI_CUSTOM_DSDT_FILE=""
>  > >  > >
>  > >  > >
>  > >  > > garbage in, garbage out.
>  > >  >
>  > >  > garbage explicitly *allowed* by Kconfig in this case, though.
>  > >  >
>  > >  > >  If you don't give this build option a file name where AmlCode 
> lives,
>  > >  > >  then the build will be unable to find AmlCode[].
>  > >  > >
>  > >  > >  http://www.lesswatts.org/projects/acpi/overridingDSDT.php
>  > >  >
>  > >  > So we have a .config option whose sole purpose is to use another
>  > >  > .config option? That seems ... less than ideal. Is there not some
>  > >  > Kconfig voodoo we can do to only require the one option? Maybe
>  > >  > something like how CONFIG_INITRAMFS_SOURCE is done? Adding Sam to the
>  > >  > Cc, in case he has any ideas.
>  > >
>  > >
>  > > Make sure STANDALONE is y for your randconfig builds.
>  > >  See README for examples.
>  >
>  > Hrm, if this is needed for randconfig to work, perhaps randconfig
>  > itself should somehow be specifying it?
>  >
>  > >  STANALONE is there exactly to prevent the above but we cannot
>  > >  control randconfig.
>  >
>  > While setting STANDALONE does fix the above, it doesn't answer the
>  > more basic question I had -- do we really need both .config options in
>  > this case? If it's simply a case of "That's how it is, won't be fixed,
>  > there are higher priorities", that's good enough by me. Just seems a
>  > shame that we have an option to enable another option, which is
>  > required for the first option to be sensible -- seems like we should
>  > only need the second option...
>
>
> I really do not see what problem you are trying to address.
>
>  STANDALONE is there as an easy way to turn of the options that requires
>  sensible input to make a kernel compile.
>
>  And that makes _perfect_ sense when you do randconfig builds.

Yes it does. As I said above I'm *not* arguing about using STANDALONE
for randconfig builds.

What I was doing, perhaps unclearly, was asking if there was a real
Kconfig need to have both CONFIG_ACPI_CUSTOM_DSDT and
CONFIG_ACPI_CUSTOM_DSDT_FILE, when the latter *only* is visible with
the former and the former *only* makes sense with the latter. Couldn't
we just have CONFIG_ACPI_CUSTOM_DSDT_FILE and check that in the code?
Why do we need a boolean option to make another string option
available?

Thanks,
Nish
--
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: [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os

[Nish Aravamudan]

On 2/22/08, Sam Ravnborg [EMAIL PROTECTED] wrote:
 On Thu, Feb 21, 2008 at 05:38:52PM -0800, Nish Aravamudan wrote:
   On 2/21/08, Sam Ravnborg [EMAIL PROTECTED] wrote:
On Thu, Feb 21, 2008 at 10:54:40AM -0800, Nish Aravamudan wrote:
  On 2/20/08, Len Brown [EMAIL PROTECTED] wrote:
   On Saturday 16 February 2008 14:47, Kamalesh Babulal wrote:
 Hi Andrew,

 The 2.6.25-rc2-mm1 kernel with randconfig build option, fails
 to build on x86_64 machine

   CC  drivers/acpi/osl.o
 drivers/acpi/osl.c:60:38: error: empty filename in #include
 drivers/acpi/osl.c: In function 'acpi_os_table_override':
 drivers/acpi/osl.c:399: error: 'AmlCode' undeclared (first use 
 in this function)
 drivers/acpi/osl.c:399: error: (Each undeclared identifier is 
 reported only once
 drivers/acpi/osl.c:399: error: for each function it appears in.)
 make[2]: *** [drivers/acpi/osl.o] Error 1
 make[1]: *** [drivers/acpi] Error 2
 make: *** [drivers] Error 2

 #
 # Automatically generated make config: don't edit
 # Linux kernel version: 2.6.25-rc2-mm1
 # Sun Feb 17 08:07:17 2008
 #
  
  
CONFIG_ACPI_CUSTOM_DSDT=y
 CONFIG_ACPI_CUSTOM_DSDT_FILE=
  
  
   garbage in, garbage out.
 
  garbage explicitly *allowed* by Kconfig in this case, though.
 
If you don't give this build option a file name where AmlCode 
 lives,
then the build will be unable to find AmlCode[].
  
http://www.lesswatts.org/projects/acpi/overridingDSDT.php
 
  So we have a .config option whose sole purpose is to use another
  .config option? That seems ... less than ideal. Is there not some
  Kconfig voodoo we can do to only require the one option? Maybe
  something like how CONFIG_INITRAMFS_SOURCE is done? Adding Sam to the
  Cc, in case he has any ideas.
   
   
Make sure STANDALONE is y for your randconfig builds.
 See README for examples.
  
   Hrm, if this is needed for randconfig to work, perhaps randconfig
   itself should somehow be specifying it?
  
 STANALONE is there exactly to prevent the above but we cannot
 control randconfig.
  
   While setting STANDALONE does fix the above, it doesn't answer the
   more basic question I had -- do we really need both .config options in
   this case? If it's simply a case of That's how it is, won't be fixed,
   there are higher priorities, that's good enough by me. Just seems a
   shame that we have an option to enable another option, which is
   required for the first option to be sensible -- seems like we should
   only need the second option...


 I really do not see what problem you are trying to address.

  STANDALONE is there as an easy way to turn of the options that requires
  sensible input to make a kernel compile.

  And that makes _perfect_ sense when you do randconfig builds.

Yes it does. As I said above I'm *not* arguing about using STANDALONE
for randconfig builds.

What I was doing, perhaps unclearly, was asking if there was a real
Kconfig need to have both CONFIG_ACPI_CUSTOM_DSDT and
CONFIG_ACPI_CUSTOM_DSDT_FILE, when the latter *only* is visible with
the former and the former *only* makes sense with the latter. Couldn't
we just have CONFIG_ACPI_CUSTOM_DSDT_FILE and check that in the code?
Why do we need a boolean option to make another string option
available?

Thanks,
Nish
--
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: [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os

[Nish Aravamudan]

On 2/22/08, Randy Dunlap [EMAIL PROTECTED] wrote:
 On Fri, 22 Feb 2008 19:08:15 +0100 Sam Ravnborg wrote:

   On Thu, Feb 21, 2008 at 05:38:52PM -0800, Nish Aravamudan wrote:
On 2/21/08, Sam Ravnborg [EMAIL PROTECTED] wrote:
 On Thu, Feb 21, 2008 at 10:54:40AM -0800, Nish Aravamudan wrote:
   On 2/20/08, Len Brown [EMAIL PROTECTED] wrote:
On Saturday 16 February 2008 14:47, Kamalesh Babulal wrote:
  Hi Andrew,
 
  The 2.6.25-rc2-mm1 kernel with randconfig build option, fails
  to build on x86_64 machine
 
CC  drivers/acpi/osl.o
  drivers/acpi/osl.c:60:38: error: empty filename in #include
  drivers/acpi/osl.c: In function 'acpi_os_table_override':
  drivers/acpi/osl.c:399: error: 'AmlCode' undeclared (first use 
 in this function)
  drivers/acpi/osl.c:399: error: (Each undeclared identifier is 
 reported only once
  drivers/acpi/osl.c:399: error: for each function it appears 
 in.)
  make[2]: *** [drivers/acpi/osl.o] Error 1
  make[1]: *** [drivers/acpi] Error 2
  make: *** [drivers] Error 2
 
  #
  # Automatically generated make config: don't edit
  # Linux kernel version: 2.6.25-rc2-mm1
  # Sun Feb 17 08:07:17 2008
  #
   
   
 CONFIG_ACPI_CUSTOM_DSDT=y
  CONFIG_ACPI_CUSTOM_DSDT_FILE=
   
   
garbage in, garbage out.
  
   garbage explicitly *allowed* by Kconfig in this case, though.
  
 If you don't give this build option a file name where AmlCode 
 lives,
 then the build will be unable to find AmlCode[].
   
 http://www.lesswatts.org/projects/acpi/overridingDSDT.php
  
   So we have a .config option whose sole purpose is to use another
   .config option? That seems ... less than ideal. Is there not some
   Kconfig voodoo we can do to only require the one option? Maybe
   something like how CONFIG_INITRAMFS_SOURCE is done? Adding Sam to 
 the
   Cc, in case he has any ideas.


 Make sure STANDALONE is y for your randconfig builds.
  See README for examples.
   
Hrm, if this is needed for randconfig to work, perhaps randconfig
itself should somehow be specifying it?
   
  STANALONE is there exactly to prevent the above but we cannot
  control randconfig.
   
While setting STANDALONE does fix the above, it doesn't answer the
more basic question I had -- do we really need both .config options in
this case? If it's simply a case of That's how it is, won't be fixed,
there are higher priorities, that's good enough by me. Just seems a
shame that we have an option to enable another option, which is
required for the first option to be sensible -- seems like we should
only need the second option...
  
   I really do not see what problem you are trying to address.
  
   STANDALONE is there as an easy way to turn of the options that requires
   sensible input to make a kernel compile.
  
   And that makes _perfect_ sense when you do randconfig builds.


   CONFIG_ACPI_CUSTOM_DSDT=y
   CONFIG_ACPI_CUSTOM_DSDT_FILE=


 Is there a way to generate (in Kconfig language) the boolean
  CONFIG_ACPI_CUSTOM_DSDT based on whether CONFIG_ACPI_CUSTOM_DSDT_FILE
  ==  or !=  ?  I tried to muck around with that last night but
  couldn't get it to work.  I.e., just present the ACPI_CUSTOM_DSDT_FILE
  config symbol to the user and then generate the ACPI_CUSTOM_DSDT bool
  based on the string value.

Thanks for re-expressing my question, Randy, this is exactly what I'm wondering.

Thanks,
Nish
--
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: [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os

[Nish Aravamudan]

On 2/21/08, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 21, 2008 at 10:54:40AM -0800, Nish Aravamudan wrote:
>  > On 2/20/08, Len Brown <[EMAIL PROTECTED]> wrote:
>  > > On Saturday 16 February 2008 14:47, Kamalesh Babulal wrote:
>  > >  > Hi Andrew,
>  > >  >
>  > >  > The 2.6.25-rc2-mm1 kernel with randconfig build option, fails
>  > >  > to build on x86_64 machine
>  > >  >
>  > >  >   CC  drivers/acpi/osl.o
>  > >  > drivers/acpi/osl.c:60:38: error: empty filename in #include
>  > >  > drivers/acpi/osl.c: In function 'acpi_os_table_override':
>  > >  > drivers/acpi/osl.c:399: error: 'AmlCode' undeclared (first use in 
> this function)
>  > >  > drivers/acpi/osl.c:399: error: (Each undeclared identifier is 
> reported only once
>  > >  > drivers/acpi/osl.c:399: error: for each function it appears in.)
>  > >  > make[2]: *** [drivers/acpi/osl.o] Error 1
>  > >  > make[1]: *** [drivers/acpi] Error 2
>  > >  > make: *** [drivers] Error 2
>  > >  >
>  > >  > #
>  > >  > # Automatically generated make config: don't edit
>  > >  > # Linux kernel version: 2.6.25-rc2-mm1
>  > >  > # Sun Feb 17 08:07:17 2008
>  > >  > #
>  > >
>  > >
>  > > > CONFIG_ACPI_CUSTOM_DSDT=y
>  > >  > CONFIG_ACPI_CUSTOM_DSDT_FILE=""
>  > >
>  > >
>  > > garbage in, garbage out.
>  >
>  > garbage explicitly *allowed* by Kconfig in this case, though.
>  >
>  > >  If you don't give this build option a file name where AmlCode lives,
>  > >  then the build will be unable to find AmlCode[].
>  > >
>  > >  http://www.lesswatts.org/projects/acpi/overridingDSDT.php
>  >
>  > So we have a .config option whose sole purpose is to use another
>  > .config option? That seems ... less than ideal. Is there not some
>  > Kconfig voodoo we can do to only require the one option? Maybe
>  > something like how CONFIG_INITRAMFS_SOURCE is done? Adding Sam to the
>  > Cc, in case he has any ideas.
>
>
> Make sure STANDALONE is y for your randconfig builds.
>  See README for examples.

Hrm, if this is needed for randconfig to work, perhaps randconfig
itself should somehow be specifying it?

>  STANALONE is there exactly to prevent the above but we cannot
>  control randconfig.

While setting STANDALONE does fix the above, it doesn't answer the
more basic question I had -- do we really need both .config options in
this case? If it's simply a case of "That's how it is, won't be fixed,
there are higher priorities", that's good enough by me. Just seems a
shame that we have an option to enable another option, which is
required for the first option to be sensible -- seems like we should
only need the second option...

Thanks,
Nish
--
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: [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os

[Nish Aravamudan]

On 2/20/08, Len Brown <[EMAIL PROTECTED]> wrote:
> On Saturday 16 February 2008 14:47, Kamalesh Babulal wrote:
>  > Hi Andrew,
>  >
>  > The 2.6.25-rc2-mm1 kernel with randconfig build option, fails
>  > to build on x86_64 machine
>  >
>  >   CC  drivers/acpi/osl.o
>  > drivers/acpi/osl.c:60:38: error: empty filename in #include
>  > drivers/acpi/osl.c: In function 'acpi_os_table_override':
>  > drivers/acpi/osl.c:399: error: 'AmlCode' undeclared (first use in this 
> function)
>  > drivers/acpi/osl.c:399: error: (Each undeclared identifier is reported 
> only once
>  > drivers/acpi/osl.c:399: error: for each function it appears in.)
>  > make[2]: *** [drivers/acpi/osl.o] Error 1
>  > make[1]: *** [drivers/acpi] Error 2
>  > make: *** [drivers] Error 2
>  >
>  > #
>  > # Automatically generated make config: don't edit
>  > # Linux kernel version: 2.6.25-rc2-mm1
>  > # Sun Feb 17 08:07:17 2008
>  > #
>
>
> > CONFIG_ACPI_CUSTOM_DSDT=y
>  > CONFIG_ACPI_CUSTOM_DSDT_FILE=""
>
>
> garbage in, garbage out.

garbage explicitly *allowed* by Kconfig in this case, though.

>  If you don't give this build option a file name where AmlCode lives,
>  then the build will be unable to find AmlCode[].
>
>  http://www.lesswatts.org/projects/acpi/overridingDSDT.php

So we have a .config option whose sole purpose is to use another
.config option? That seems ... less than ideal. Is there not some
Kconfig voodoo we can do to only require the one option? Maybe
something like how CONFIG_INITRAMFS_SOURCE is done? Adding Sam to the
Cc, in case he has any ideas.

Thanks,
Nish
--
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: [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os

[Nish Aravamudan]

On 2/20/08, Len Brown [EMAIL PROTECTED] wrote:
 On Saturday 16 February 2008 14:47, Kamalesh Babulal wrote:
   Hi Andrew,
  
   The 2.6.25-rc2-mm1 kernel with randconfig build option, fails
   to build on x86_64 machine
  
 CC  drivers/acpi/osl.o
   drivers/acpi/osl.c:60:38: error: empty filename in #include
   drivers/acpi/osl.c: In function 'acpi_os_table_override':
   drivers/acpi/osl.c:399: error: 'AmlCode' undeclared (first use in this 
 function)
   drivers/acpi/osl.c:399: error: (Each undeclared identifier is reported 
 only once
   drivers/acpi/osl.c:399: error: for each function it appears in.)
   make[2]: *** [drivers/acpi/osl.o] Error 1
   make[1]: *** [drivers/acpi] Error 2
   make: *** [drivers] Error 2
  
   #
   # Automatically generated make config: don't edit
   # Linux kernel version: 2.6.25-rc2-mm1
   # Sun Feb 17 08:07:17 2008
   #


  CONFIG_ACPI_CUSTOM_DSDT=y
   CONFIG_ACPI_CUSTOM_DSDT_FILE=


 garbage in, garbage out.

garbage explicitly *allowed* by Kconfig in this case, though.

  If you don't give this build option a file name where AmlCode lives,
  then the build will be unable to find AmlCode[].

  http://www.lesswatts.org/projects/acpi/overridingDSDT.php

So we have a .config option whose sole purpose is to use another
.config option? That seems ... less than ideal. Is there not some
Kconfig voodoo we can do to only require the one option? Maybe
something like how CONFIG_INITRAMFS_SOURCE is done? Adding Sam to the
Cc, in case he has any ideas.

Thanks,
Nish
--
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: [BUILD_FAILURE] 2.6.25-rc2-mm1 - Build Failure at acpi_os

[Nish Aravamudan]

On 2/21/08, Sam Ravnborg [EMAIL PROTECTED] wrote:
 On Thu, Feb 21, 2008 at 10:54:40AM -0800, Nish Aravamudan wrote:
   On 2/20/08, Len Brown [EMAIL PROTECTED] wrote:
On Saturday 16 February 2008 14:47, Kamalesh Babulal wrote:
  Hi Andrew,
 
  The 2.6.25-rc2-mm1 kernel with randconfig build option, fails
  to build on x86_64 machine
 
CC  drivers/acpi/osl.o
  drivers/acpi/osl.c:60:38: error: empty filename in #include
  drivers/acpi/osl.c: In function 'acpi_os_table_override':
  drivers/acpi/osl.c:399: error: 'AmlCode' undeclared (first use in 
 this function)
  drivers/acpi/osl.c:399: error: (Each undeclared identifier is 
 reported only once
  drivers/acpi/osl.c:399: error: for each function it appears in.)
  make[2]: *** [drivers/acpi/osl.o] Error 1
  make[1]: *** [drivers/acpi] Error 2
  make: *** [drivers] Error 2
 
  #
  # Automatically generated make config: don't edit
  # Linux kernel version: 2.6.25-rc2-mm1
  # Sun Feb 17 08:07:17 2008
  #
   
   
 CONFIG_ACPI_CUSTOM_DSDT=y
  CONFIG_ACPI_CUSTOM_DSDT_FILE=
   
   
garbage in, garbage out.
  
   garbage explicitly *allowed* by Kconfig in this case, though.
  
 If you don't give this build option a file name where AmlCode lives,
 then the build will be unable to find AmlCode[].
   
 http://www.lesswatts.org/projects/acpi/overridingDSDT.php
  
   So we have a .config option whose sole purpose is to use another
   .config option? That seems ... less than ideal. Is there not some
   Kconfig voodoo we can do to only require the one option? Maybe
   something like how CONFIG_INITRAMFS_SOURCE is done? Adding Sam to the
   Cc, in case he has any ideas.


 Make sure STANDALONE is y for your randconfig builds.
  See README for examples.

Hrm, if this is needed for randconfig to work, perhaps randconfig
itself should somehow be specifying it?

  STANALONE is there exactly to prevent the above but we cannot
  control randconfig.

While setting STANDALONE does fix the above, it doesn't answer the
more basic question I had -- do we really need both .config options in
this case? If it's simply a case of That's how it is, won't be fixed,
there are higher priorities, that's good enough by me. Just seems a
shame that we have an option to enable another option, which is
required for the first option to be sensible -- seems like we should
only need the second option...

Thanks,
Nish
--
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: 2.6.26-git0: IDE oops during boot

[Nish Aravamudan]

On 2/7/08, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
>
> On Thursday 07 February 2008, Kamalesh Babulal wrote:
> > Bartlomiej Zolnierkiewicz wrote:
> > > Hi,
> > >
> > > On Wednesday 06 February 2008, Pavel Machek wrote:
> > >> On Wed 2008-02-06 11:53:34, Pavel Machek wrote:
> > >>> Hi!
> > >>>
> > >>> Trying to boot 2.6.25-git0 (few days old), I get
> > >>>
> > >>> BUG: unable to handle kernel paging request at ..ffb0
> > >>> IP at init_irq+0x42e
> > >
> > > init_irq? hmm...
> > >
> > >>> Call trace:
> > >>> ide_device_add_all
> > >
> > > this comes from ide-generic
> > > (Generic IDE host driver)
> > >
> > >>> ide_generic_init
> > >>> kernel_init
> > >>> child_rip
> > >>> vgacon_cursor
> > >>> kernel_init
> > >>> child_rip
> > >>>
> > >>> Excerpt from config:
> > >>>
> > >>> CONFIG_IDE=y
> > >>> CONFIG_BLK_DEV_IDE=y
> > >> Disabling CONFIG_IDE made my machine boot, as it was using libata
> > >> anyway.
> > >
> > > Kamalesh/Pavel:
> > >
> > > Could you try latest git and see if the OOPS is still there?
> > >
> > > [ Yeah, I'm unable to reproduce it. :( ]
> > >
> > > Thanks,
> > > Bart
> > Hi Bart,
> >
> > The panic is reproducible with the 2.6.24-git16 kernel, the call trace is
> > similar to the previous one
>
> Thanks, I again reviewed ide-probe.c changes but nothing seems wrong...
>
> Could you please bisect it down to the guilty commit?

Kamalesh, were you able to bisect this down? I just got hit by the
same panic on a 4-way x86_64, with 2.6.24-git22.

Thanks,
Nish
--
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: 2.6.26-git0: IDE oops during boot

[Nish Aravamudan]

On 2/7/08, Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:

 On Thursday 07 February 2008, Kamalesh Babulal wrote:
  Bartlomiej Zolnierkiewicz wrote:
   Hi,
  
   On Wednesday 06 February 2008, Pavel Machek wrote:
   On Wed 2008-02-06 11:53:34, Pavel Machek wrote:
   Hi!
  
   Trying to boot 2.6.25-git0 (few days old), I get
  
   BUG: unable to handle kernel paging request at ..ffb0
   IP at init_irq+0x42e
  
   init_irq? hmm...
  
   Call trace:
   ide_device_add_all
  
   this comes from ide-generic
   (Generic IDE host driver)
  
   ide_generic_init
   kernel_init
   child_rip
   vgacon_cursor
   kernel_init
   child_rip
  
   Excerpt from config:
  
   CONFIG_IDE=y
   CONFIG_BLK_DEV_IDE=y
   Disabling CONFIG_IDE made my machine boot, as it was using libata
   anyway.
  
   Kamalesh/Pavel:
  
   Could you try latest git and see if the OOPS is still there?
  
   [ Yeah, I'm unable to reproduce it. :( ]
  
   Thanks,
   Bart
  Hi Bart,
 
  The panic is reproducible with the 2.6.24-git16 kernel, the call trace is
  similar to the previous one

 Thanks, I again reviewed ide-probe.c changes but nothing seems wrong...

 Could you please bisect it down to the guilty commit?

Kamalesh, were you able to bisect this down? I just got hit by the
same panic on a 4-way x86_64, with 2.6.24-git22.

Thanks,
Nish
--
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: missing asm-x86_64 detection

[Nish Aravamudan]

On 1/31/08, Reinaldo Carvalho <[EMAIL PROTECTED]> wrote:
> :/# uname -a
> Linux devil 2.6.22.16-amd64 #15 SMP Sat Jan 19 13:58:02 BRT 2008
> x86_64 GNU/Linux
>
> :/# cd /usr/src/linux-2.6.22
> :/# patch -p1 -R < ../patch-2.6.22.16
> :/# patch -p1 < ../patch-2.6.23
> :/# patch -p1 < ../patch-2.6.24
> :/# cd /usr/src/ ; mv linux-2.6.22 linux-2.6.24; cd linux-2.6.24
> :/usr/src/linux-2.6.24# make oldconfig
> :/usr/src/linux-2.6.24# make all
>   CHK include/linux/version.h
>   CHK include/linux/utsrelease.h
> ERROR: the symlink include/asm points to asm-x86_64 but asm-x86 was expected
>set ARCH or save .config and run 'make mrproper' to fix it
> make: ** [include/asm] Erro 1
>
> :/usr/src/linux-2.6.24# cp .config ../config-2.6.24
> :/usr/src/linux-2.6.24# make mrproper
>   CLEAN   scripts/basic
>   CLEAN   scripts/genksyms
>   CLEAN   scripts/kconfig
>   CLEAN   scripts/mod
>   CLEAN   scripts
>   CLEAN   include/config
>   CLEAN   .config .config.old include/asm .version
> include/linux/autoconf.h include/linux/version.h
> include/linux/utsrelease.h Module.symvers
> devil:/usr/src/linux-2.6.24# cp ../config-2.6.24 .config
> devil:/usr/src/linux-2.6.24# make oldconfig
> devil:/usr/src/linux-2.6.24# make all
> scripts/kconfig/conf -s arch/x86/Kconfig
>   CHK include/linux/version.h
>   UPD include/linux/version.h
>   CHK include/linux/utsrelease.h
>   UPD include/linux/utsrelease.h
>   SYMLINK include/asm -> include/asm-x86
>   CC  arch/x86/kernel/asm-offsets.s
>   GEN include/asm-x86/asm-offsets.h
> ...
>
> system is x86_64!

And your point? The archs are being merged into just x86 (instead of
x86_32 and x86_64 being separate). That's why the asm-x86_64 symlink
was complained about above.

There is no error. Check your config that CONFIG_64BIT and
CONFIG_X86_64 are set.

Thanks,
Nish
--
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: missing asm-x86_64 detection

[Nish Aravamudan]

On 1/31/08, Reinaldo Carvalho [EMAIL PROTECTED] wrote:
 :/# uname -a
 Linux devil 2.6.22.16-amd64 #15 SMP Sat Jan 19 13:58:02 BRT 2008
 x86_64 GNU/Linux

 :/# cd /usr/src/linux-2.6.22
 :/# patch -p1 -R  ../patch-2.6.22.16
 :/# patch -p1  ../patch-2.6.23
 :/# patch -p1  ../patch-2.6.24
 :/# cd /usr/src/ ; mv linux-2.6.22 linux-2.6.24; cd linux-2.6.24
 :/usr/src/linux-2.6.24# make oldconfig
 :/usr/src/linux-2.6.24# make all
   CHK include/linux/version.h
   CHK include/linux/utsrelease.h
 ERROR: the symlink include/asm points to asm-x86_64 but asm-x86 was expected
set ARCH or save .config and run 'make mrproper' to fix it
 make: ** [include/asm] Erro 1

 :/usr/src/linux-2.6.24# cp .config ../config-2.6.24
 :/usr/src/linux-2.6.24# make mrproper
   CLEAN   scripts/basic
   CLEAN   scripts/genksyms
   CLEAN   scripts/kconfig
   CLEAN   scripts/mod
   CLEAN   scripts
   CLEAN   include/config
   CLEAN   .config .config.old include/asm .version
 include/linux/autoconf.h include/linux/version.h
 include/linux/utsrelease.h Module.symvers
 devil:/usr/src/linux-2.6.24# cp ../config-2.6.24 .config
 devil:/usr/src/linux-2.6.24# make oldconfig
 devil:/usr/src/linux-2.6.24# make all
 scripts/kconfig/conf -s arch/x86/Kconfig
   CHK include/linux/version.h
   UPD include/linux/version.h
   CHK include/linux/utsrelease.h
   UPD include/linux/utsrelease.h
   SYMLINK include/asm - include/asm-x86
   CC  arch/x86/kernel/asm-offsets.s
   GEN include/asm-x86/asm-offsets.h
 ...

 system is x86_64!

And your point? The archs are being merged into just x86 (instead of
x86_32 and x86_64 being separate). That's why the asm-x86_64 symlink
was complained about above.

There is no error. Check your config that CONFIG_64BIT and
CONFIG_X86_64 are set.

Thanks,
Nish
--
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] Fake NUMA emulation for PowerPC (Take 2)

[Nish Aravamudan]

On 1/27/08, Balbir Singh <[EMAIL PROTECTED]> wrote:
> * Paul Mackerras <[EMAIL PROTECTED]> [2008-01-27 22:55:43]:
>
> > Balbir Singh writes:
> >
> > > Here's a better and more complete fix for the problem. Could you
> > > please see if it works for you? I tested it on a real NUMA box and it
> > > seemed to work fine there.
> >
> > There are a couple of other changes in behaviour that your patch
> > introduces, and I'd like to understand them better before taking the
> > patch.  First, with your patch we don't set nodes online if they end
> > up having no memory in them because of the memory limit, whereas
> > previously we did.  Secondly, in the case where we don't have NUMA
> > information, we now set node 0 online after adding each LMB, whereas
> > previously we only set it online once.
> >
> > If in fact these changes are benign, then your patch description
> > should mention them and explain why they are benign.
> >
>
> Yes, they are. I'll try and justify the changes with a good detailed
> changelog. If people prefer it, I can hide fake NUMA nodes under a
> config option, so that it does not come enabled by default.

Sigh, there already *is* a fake NUMA config option: CONFIG_NUMA_EMU.

"CONFIG_NUMA_EMU:
  Enable NUMA emulation. A flat machine will be split
  into virtual nodes when booted with "numa=fake=N", where N is the
  number of nodes. This is only useful for debugging."

I have to assume your patch is implementing the same feature for
powerpc (really just extending the x86_64 one), and thus should share
the config option.

Any chance you can just make some of that code common? Maybe as a
follow-on patch. I expect that some of Mel's (added to Cc) work to
allow NUMA to be set on x86 more easily will flow quite simply into
adding fake NUMA support there as well. So moving the code to a common
place (at least the parsing) makes sense.

I also feel like you want to be able to online memoryless nodes --
that's where we've been hitting a number of bugs lately in the VM. I
can't tell from Paul's comment if your patch prevents that from being
faked or not.

Thanks,
Nish
--
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] Fake NUMA emulation for PowerPC (Take 2)

[Nish Aravamudan]

On 1/27/08, Balbir Singh [EMAIL PROTECTED] wrote:
 * Paul Mackerras [EMAIL PROTECTED] [2008-01-27 22:55:43]:

  Balbir Singh writes:
 
   Here's a better and more complete fix for the problem. Could you
   please see if it works for you? I tested it on a real NUMA box and it
   seemed to work fine there.
 
  There are a couple of other changes in behaviour that your patch
  introduces, and I'd like to understand them better before taking the
  patch.  First, with your patch we don't set nodes online if they end
  up having no memory in them because of the memory limit, whereas
  previously we did.  Secondly, in the case where we don't have NUMA
  information, we now set node 0 online after adding each LMB, whereas
  previously we only set it online once.
 
  If in fact these changes are benign, then your patch description
  should mention them and explain why they are benign.
 

 Yes, they are. I'll try and justify the changes with a good detailed
 changelog. If people prefer it, I can hide fake NUMA nodes under a
 config option, so that it does not come enabled by default.

Sigh, there already *is* a fake NUMA config option: CONFIG_NUMA_EMU.

CONFIG_NUMA_EMU:
  Enable NUMA emulation. A flat machine will be split
  into virtual nodes when booted with numa=fake=N, where N is the
  number of nodes. This is only useful for debugging.

I have to assume your patch is implementing the same feature for
powerpc (really just extending the x86_64 one), and thus should share
the config option.

Any chance you can just make some of that code common? Maybe as a
follow-on patch. I expect that some of Mel's (added to Cc) work to
allow NUMA to be set on x86 more easily will flow quite simply into
adding fake NUMA support there as well. So moving the code to a common
place (at least the parsing) makes sense.

I also feel like you want to be able to online memoryless nodes --
that's where we've been hitting a number of bugs lately in the VM. I
can't tell from Paul's comment if your patch prevents that from being
faked or not.

Thanks,
Nish
--
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: crash in kmem_cache_init

[Nish Aravamudan]

On 1/22/08, Olaf Hering <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 22, Mel Gorman wrote:
>
> > http://www.csn.ul.ie/~mel/postings/slab-20080122/partial-revert-slab-changes.patch
> > .. Can you please check on your machine if it fixes your problem?
>
> It does not fix or change the nature of the crash.
>
> > Olaf, please confirm whether you need the patch below as well as the
> > revert to make your machine boot.
>
> It crashes now in a different way if the patch below is applied:

Was this with the revert Mel mentioned applied as well? I get the
feeling both patches are needed to fix up the memoryless SLAB issue.

> Linux version 2.6.24-rc8-ppc64 ([EMAIL PROTECTED]) (gcc version 4.1.2 
> 20070115 (prerelease) (SUSE Linux)) #43 SMP Tue Jan 22 22:39:05 CET 2008



> early_node_map[1] active PFN ranges
> 1:0 ->   892928



> Unable to handle kernel paging request for data at address 0x0058
> Faulting instruction address: 0xc00fe018
> cpu 0x0: Vector: 300 (Data Access) at [c075bac0]
> pc: c00fe018: .setup_cpu_cache+0x184/0x1f4
> lr: c00fdfa8: .setup_cpu_cache+0x114/0x1f4
> sp: c075bd40
>msr: 80009032
>dar: 58
>  dsisr: 4200
>   current = 0xc0665a50
>   paca= 0xc0666380
> pid   = 0, comm = swapper
> enter ? for help
> [c075bd40] c00fb368 .kmem_cache_create+0x3c0/0x478 
> (unreliable)
> [c075be20] c05e6780 .kmem_cache_init+0x284/0x4f4
> [c075bee0] c05bf8ec .start_kernel+0x2f8/0x3fc
> [c075bf90] c0008590 .start_here_common+0x60/0xd0
> 0:mon>
>
> 0xc00fe018 is in setup_cpu_cache 
> (/home/olaf/kernel/git/linux-2.6-numa/mm/slab.c:2111).
> 2106BUG_ON(!cachep->nodelists[node]);
> 2107
> kmem_list3_init(cachep->nodelists[node]);

I might be barking up the wrong tree, but this block above is supposed
to set up the cachep->nodeslists[*] that are used immediately below.
But if the loop wasn't changed from N_NORMAL_MEMORY to N_ONLINE or
whatever, you might get a bad access right below for node 0 that has
no memory, if that's the node we're running on...

> 2108}
> 2109}
> 2110}
> 2111cachep->nodelists[numa_node_id()]->next_reap =
> 2112jiffies + REAPTIMEOUT_LIST3 +
> 2113((unsigned long)cachep) % REAPTIMEOUT_LIST3;
> 2114
> 2115cpu_cache_get(cachep)->avail = 0;

Thanks,
Nish
--
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: crash in kmem_cache_init

[Nish Aravamudan]

On 1/22/08, Olaf Hering [EMAIL PROTECTED] wrote:
 On Tue, Jan 22, Mel Gorman wrote:

  http://www.csn.ul.ie/~mel/postings/slab-20080122/partial-revert-slab-changes.patch
  .. Can you please check on your machine if it fixes your problem?

 It does not fix or change the nature of the crash.

  Olaf, please confirm whether you need the patch below as well as the
  revert to make your machine boot.

 It crashes now in a different way if the patch below is applied:

Was this with the revert Mel mentioned applied as well? I get the
feeling both patches are needed to fix up the memoryless SLAB issue.

 Linux version 2.6.24-rc8-ppc64 ([EMAIL PROTECTED]) (gcc version 4.1.2 
 20070115 (prerelease) (SUSE Linux)) #43 SMP Tue Jan 22 22:39:05 CET 2008

snip

 early_node_map[1] active PFN ranges
 1:0 -   892928

snip

 Unable to handle kernel paging request for data at address 0x0058
 Faulting instruction address: 0xc00fe018
 cpu 0x0: Vector: 300 (Data Access) at [c075bac0]
 pc: c00fe018: .setup_cpu_cache+0x184/0x1f4
 lr: c00fdfa8: .setup_cpu_cache+0x114/0x1f4
 sp: c075bd40
msr: 80009032
dar: 58
  dsisr: 4200
   current = 0xc0665a50
   paca= 0xc0666380
 pid   = 0, comm = swapper
 enter ? for help
 [c075bd40] c00fb368 .kmem_cache_create+0x3c0/0x478 
 (unreliable)
 [c075be20] c05e6780 .kmem_cache_init+0x284/0x4f4
 [c075bee0] c05bf8ec .start_kernel+0x2f8/0x3fc
 [c075bf90] c0008590 .start_here_common+0x60/0xd0
 0:mon

 0xc00fe018 is in setup_cpu_cache 
 (/home/olaf/kernel/git/linux-2.6-numa/mm/slab.c:2111).
 2106BUG_ON(!cachep-nodelists[node]);
 2107
 kmem_list3_init(cachep-nodelists[node]);

I might be barking up the wrong tree, but this block above is supposed
to set up the cachep-nodeslists[*] that are used immediately below.
But if the loop wasn't changed from N_NORMAL_MEMORY to N_ONLINE or
whatever, you might get a bad access right below for node 0 that has
no memory, if that's the node we're running on...

 2108}
 2109}
 2110}
 2111cachep-nodelists[numa_node_id()]-next_reap =
 2112jiffies + REAPTIMEOUT_LIST3 +
 2113((unsigned long)cachep) % REAPTIMEOUT_LIST3;
 2114
 2115cpu_cache_get(cachep)-avail = 0;

Thanks,
Nish
--
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: crash in kmem_cache_init

[Nish Aravamudan]

On 1/18/08, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> Could you try this patch?
>
> Memoryless nodes: Set N_NORMAL_MEMORY for a node if we do not support
> HIGHMEM
>
> It seems that we only scan through zones to set N_NORMAL_MEMORY only if
> CONFIG_HIGHMEM and CONFIG_NUMA are set. We need to set
> N_NORMAL_MEMORY
> in the !CONFIG_HIGHMEM case.

I'm testing this exact patch right now on the machine Mel saw the issues with.

Thanks,
Nish
--
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: crash in kmem_cache_init

[Nish Aravamudan]

On 1/18/08, Christoph Lameter [EMAIL PROTECTED] wrote:
 Could you try this patch?

 Memoryless nodes: Set N_NORMAL_MEMORY for a node if we do not support
 HIGHMEM

 It seems that we only scan through zones to set N_NORMAL_MEMORY only if
 CONFIG_HIGHMEM and CONFIG_NUMA are set. We need to set
 N_NORMAL_MEMORY
 in the !CONFIG_HIGHMEM case.

I'm testing this exact patch right now on the machine Mel saw the issues with.

Thanks,
Nish
--
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] [6/8] GBPAGES: Add an option to disable direct mapping gbpages and a global variable

[Nish Aravamudan]

On 1/3/08, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>



> Index: linux/Documentation/x86_64/boot-options.txt
> ===
> --- linux.orig/Documentation/x86_64/boot-options.txt
> +++ linux/Documentation/x86_64/boot-options.txt
> @@ -307,3 +307,6 @@ Debugging
> stuck (default)
>
>  Miscellaneous
> +
> +   direct_gbpages=off
> +   Do not use GB pages for kernel direct mapping.

Sorry if this is a FAQ, but why do we have this file in addition to
kernel-parameters.txt? I see that kernel-parameters.txt refers to this
file, so I guess it's ok, but shouldn't we try to consolidate?

Thanks,
Nish
--
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: [2.6 patch] hwmon/ibmpex.c: fix NULL dereference

[Nish Aravamudan]

On 10/17/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> Don't dereference "data" when we know for sure it's NULL.
>
> Spotted by the Coverity checker.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
> 66bec2ef5c6d55fc30ef6ac5bb97fdfcfaf394f2
> diff --git a/drivers/hwmon/ibmpex.c b/drivers/hwmon/ibmpex.c
> index c462824..e14ce3d 100644
> --- a/drivers/hwmon/ibmpex.c
> +++ b/drivers/hwmon/ibmpex.c
> @@ -457,7 +457,7 @@ static void ibmpex_register_bmc(int iface, struct device 
> *dev)
> data = kzalloc(sizeof(*data), GFP_KERNEL);
> if (!data) {
> printk(KERN_ERR DRVNAME ": Insufficient memory for BMC "
> -  "interface %d.\n", data->interface);
> +  "interface.\n");

Hrm but what data->interface would be is specified by the iface
parameter? Just spit that out instead?

Thanks,
Nish
-
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: [2.6 patch] hwmon/ibmpex.c: fix NULL dereference

[Nish Aravamudan]

On 10/17/07, Adrian Bunk [EMAIL PROTECTED] wrote:
 Don't dereference data when we know for sure it's NULL.

 Spotted by the Coverity checker.

 Signed-off-by: Adrian Bunk [EMAIL PROTECTED]

 ---
 66bec2ef5c6d55fc30ef6ac5bb97fdfcfaf394f2
 diff --git a/drivers/hwmon/ibmpex.c b/drivers/hwmon/ibmpex.c
 index c462824..e14ce3d 100644
 --- a/drivers/hwmon/ibmpex.c
 +++ b/drivers/hwmon/ibmpex.c
 @@ -457,7 +457,7 @@ static void ibmpex_register_bmc(int iface, struct device 
 *dev)
 data = kzalloc(sizeof(*data), GFP_KERNEL);
 if (!data) {
 printk(KERN_ERR DRVNAME : Insufficient memory for BMC 
 -  interface %d.\n, data-interface);
 +  interface.\n);

Hrm but what data-interface would be is specified by the iface
parameter? Just spit that out instead?

Thanks,
Nish
-
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: atm: panic when loading clip 2nd time

[Nish Aravamudan]

On 10/16/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> 2.6.23-git7, using SLAB (not SLUB) [config attached]:
>
> # modprobe clip
> # rmmod clip
> # modprobe clip
>
> results in panic:
>
> kmem_cache_create: duplicate cache clip_arp_cache
>
> Call Trace:
>  [] kmem_cache_create+0x3bf/0x3fd
>  [] neigh_table_init_no_netlink+0x6c/0x242
>  [] :clip:atm_clip_init+0x10/0x8a
>  [] sys_init_module+0x146c/0x15cd
>  [] neigh_lookup+0x0/0xd5
>  [] syscall_trace_enter+0x95/0x99
>  [] tracesys+0xdc/0xe1
>
> Kernel panic - not syncing: kmem_cache_create(): failed to create slab 
> `clip_arp_cache'

>From a quick read through the code, looks like
net/core/neighbour.c:neigh_table_clear() needs a kmem_cache_destroy()?

I only see three callers of neight_table_clear() and they all seem to
be in exit routines, so that should be safe?

-Nish
-
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: atm: panic when loading clip 2nd time

[Nish Aravamudan]

On 10/16/07, Randy Dunlap [EMAIL PROTECTED] wrote:
 2.6.23-git7, using SLAB (not SLUB) [config attached]:

 # modprobe clip
 # rmmod clip
 # modprobe clip

 results in panic:

 kmem_cache_create: duplicate cache clip_arp_cache

 Call Trace:
  [8028c682] kmem_cache_create+0x3bf/0x3fd
  [8046ba1d] neigh_table_init_no_netlink+0x6c/0x242
  [8800a010] :clip:atm_clip_init+0x10/0x8a
  [80258ba4] sys_init_module+0x146c/0x15cd
  [8046be0a] neigh_lookup+0x0/0xd5
  [8020ef44] syscall_trace_enter+0x95/0x99
  [8020beec] tracesys+0xdc/0xe1

 Kernel panic - not syncing: kmem_cache_create(): failed to create slab 
 `clip_arp_cache'

From a quick read through the code, looks like
net/core/neighbour.c:neigh_table_clear() needs a kmem_cache_destroy()?

I only see three callers of neight_table_clear() and they all seem to
be in exit routines, so that should be safe?

-Nish
-
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: 2.6.23-rc7-mm1 -- powerpc rtas panic

[Nish Aravamudan]

On 10/5/07, Linas Vepstas <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 04, 2007 at 05:01:47PM -0700, Nish Aravamudan wrote:
> > On 10/2/07, Tony Breeds <[EMAIL PROTECTED]> wrote:
> > > On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote:
> > >
> > > > I realise it'll make the patch bigger, but this doesn't seem like a
> > > > particularly good name for the variable anymore.
> > >
> > > Sure, what about?
> > >
> > > Clarify when RTAS logging is enabled.
> > >
> > > Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>
> >
> > For what it's worth, on a different ppc64 box, this resolves a similar
> > panic for me.
> >
> > Tested-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
>
> For the reasons explained, I'd really like to nack Tony's patch.

I see. Can you reply in this thread with the patch you mentioned in
your other reply? (or point me to a copy of it)

Thanks,
Nish
-
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: 2.6.23-rc7-mm1 -- powerpc rtas panic

[Nish Aravamudan]

On 10/5/07, Linas Vepstas [EMAIL PROTECTED] wrote:
 On Thu, Oct 04, 2007 at 05:01:47PM -0700, Nish Aravamudan wrote:
  On 10/2/07, Tony Breeds [EMAIL PROTECTED] wrote:
   On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote:
  
I realise it'll make the patch bigger, but this doesn't seem like a
particularly good name for the variable anymore.
  
   Sure, what about?
  
   Clarify when RTAS logging is enabled.
  
   Signed-off-by: Tony Breeds [EMAIL PROTECTED]
 
  For what it's worth, on a different ppc64 box, this resolves a similar
  panic for me.
 
  Tested-by: Nishanth Aravamudan [EMAIL PROTECTED]

 For the reasons explained, I'd really like to nack Tony's patch.

I see. Can you reply in this thread with the patch you mentioned in
your other reply? (or point me to a copy of it)

Thanks,
Nish
-
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: 2.6.23-rc7-mm1 -- powerpc rtas panic

[Nish Aravamudan]

On 10/2/07, Tony Breeds <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote:
>
> > I realise it'll make the patch bigger, but this doesn't seem like a
> > particularly good name for the variable anymore.
>
> Sure, what about?
>
> Clarify when RTAS logging is enabled.
>
> Signed-off-by: Tony Breeds <[EMAIL PROTECTED]>

For what it's worth, on a different ppc64 box, this resolves a similar
panic for me.

Tested-by: Nishanth Aravamudan <[EMAIL PROTECTED]>

Thanks,
Nish
-
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: 2.6.23-rc7-mm1 -- powerpc rtas panic

[Nish Aravamudan]

On 10/2/07, Tony Breeds [EMAIL PROTECTED] wrote:
 On Wed, Oct 03, 2007 at 10:30:16AM +1000, Michael Ellerman wrote:

  I realise it'll make the patch bigger, but this doesn't seem like a
  particularly good name for the variable anymore.

 Sure, what about?

 Clarify when RTAS logging is enabled.

 Signed-off-by: Tony Breeds [EMAIL PROTECTED]

For what it's worth, on a different ppc64 box, this resolves a similar
panic for me.

Tested-by: Nishanth Aravamudan [EMAIL PROTECTED]

Thanks,
Nish
-
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: x86 patches was Re: -mm merge plans for 2.6.24

[Nish Aravamudan]

On 10/2/07, KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> On Tue, 2 Oct 2007 00:18:09 -0700
> Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > > How come?  Memoryless node can and do occur in real-world machines.  
> > > > Kernel
> > > > should support that?
> > >
> > > But a node is just defined by its memory?
> >
> > Don't think so.  A node is a lump of circuitry which can have zero or more
> > CPUs, IO and memory.
> >
> > It may initially have been conceived as a memory-only concept in the Linux
> > kernel, but that doesn't fully map onto reality (does it?)
> >
> > There was a real-world need for this, I think from the Fujitsu guys.  That
> > should be spelled out in the changelog but isn't.
>
> Yes, Fujitsu and HP guys really need this memory-less-node support.

Anton's post (http://marc.info/?l=linux-mm=118133042025995=2) (and
my subsequent reposts) may have helped prompt this full series, which
then was picked up and shown to be useful to other folks. NUMA systems
with memoryless nodes exist in the wild and Linux did not do the right
thing there. Admittedly, Anton's case is hugetlb-specific, but the fix
I've been proposing (and hope to repost soon) depends on Christoph's
patches, especially the THISNODE fix.

Thanks,
Nish
-
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: x86 patches was Re: -mm merge plans for 2.6.24

[Nish Aravamudan]

On 10/2/07, KAMEZAWA Hiroyuki [EMAIL PROTECTED] wrote:
 On Tue, 2 Oct 2007 00:18:09 -0700
 Andrew Morton [EMAIL PROTECTED] wrote:
  
How come?  Memoryless node can and do occur in real-world machines.  
Kernel
should support that?
  
   But a node is just defined by its memory?
 
  Don't think so.  A node is a lump of circuitry which can have zero or more
  CPUs, IO and memory.
 
  It may initially have been conceived as a memory-only concept in the Linux
  kernel, but that doesn't fully map onto reality (does it?)
 
  There was a real-world need for this, I think from the Fujitsu guys.  That
  should be spelled out in the changelog but isn't.

 Yes, Fujitsu and HP guys really need this memory-less-node support.

Anton's post (http://marc.info/?l=linux-mmm=118133042025995w=2) (and
my subsequent reposts) may have helped prompt this full series, which
then was picked up and shown to be useful to other folks. NUMA systems
with memoryless nodes exist in the wild and Linux did not do the right
thing there. Admittedly, Anton's case is hugetlb-specific, but the fix
I've been proposing (and hope to repost soon) depends on Christoph's
patches, especially the THISNODE fix.

Thanks,
Nish
-
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: Make checkpatch warn about pointless casting of kalloc returns.

[Nish Aravamudan]

On 8/8/07, jschopp <[EMAIL PROTECTED]> wrote:
> >  > > +WARN("No need to cast return value.\n");
> >  >
> >  > Could the warning be more descriptive?  This describes what, but it 
> > should also describe
> >  > why; after all if somebody made this error they may not know they why.
> >
> > I'm open to suggestions..
>
> How about
>
> WARN("No need to cast return value, it is unnecessary and can hide real bugs. 
>  See
> http://c-faq.com/malloc/mallocnocast.html for more details\n");

That's a long line. Can it be split into two? Otherwise seems sane.

Thanks,
Nish
-
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: Make checkpatch warn about pointless casting of kalloc returns.

[Nish Aravamudan]

On 8/8/07, jschopp [EMAIL PROTECTED] wrote:
 +WARN(No need to cast return value.\n);
   
Could the warning be more descriptive?  This describes what, but it 
  should also describe
why; after all if somebody made this error they may not know they why.
 
  I'm open to suggestions..

 How about

 WARN(No need to cast return value, it is unnecessary and can hide real bugs. 
  See
 http://c-faq.com/malloc/mallocnocast.html for more details\n);

That's a long line. Can it be split into two? Otherwise seems sane.

Thanks,
Nish
-
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] Add missing newlines to some uses of dev_ messages

[Nish Aravamudan]

On 8/7/07, Joe Perches <[EMAIL PROTECTED]> wrote:
> Found these while looking at printk uses.
>
> Add missing newlines to dev_ uses
> Add missing KERN_ prefixes to multiline dev_s
> Fixed a wierd->weird spelling typo
> Added a newline to a printk

I think these should have been split logically into 4 groups of
patches (except perhaps where they touched the same file for the first
two and the last).

The third type should go through trivial.

And they should have been split logically by subsystem, most likely?



> diff --git a/arch/ia64/sn/kernel/xpnet.c b/arch/ia64/sn/kernel/xpnet.c
> index e58fcad..a5df672 100644
> --- a/arch/ia64/sn/kernel/xpnet.c
> +++ b/arch/ia64/sn/kernel/xpnet.c
> @@ -269,8 +269,9 @@ xpnet_receive(partid_t partid, int channel, struct 
> xpnet_message *msg)
> skb->protocol = eth_type_trans(skb, xpnet_device);
> skb->ip_summed = CHECKSUM_UNNECESSARY;
>
> -   dev_dbg(xpnet, "passing skb to network layer; \n\tskb->head=0x%p "
> -   "skb->data=0x%p skb->tail=0x%p skb->end=0x%p skb->len=%d\n",
> +   dev_dbg(xpnet, "passing skb to network layer\n"
> +   KERN_DEBUG "\tskb->head=0x%p skb->data=0x%p skb->tail=0x%p "
> +   "skb->end=0x%p skb->len=%d\n",
> (void *)skb->head, (void *)skb->data, skb_tail_pointer(skb),
> skb_end_pointer(skb), skb->len);



I'm not a maintainer of any code by any means, but it seems odd,
redundant and visually confusing to me to use the dev_dbg() function
and have KERN_DEBUG's inside the string -- makes me question every
time why there isn't one for the first line too.

Perhaps these multi-line debug statements should simply be split into
multiple dev_dbg() calls? Similar for the other dev_ functions. I
think it might look cleaner, at least. Just my two cents, not a NAK or
anything.

Thanks,
Nish
-
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] Add missing newlines to some uses of dev_level messages

[Nish Aravamudan]

On 8/7/07, Joe Perches [EMAIL PROTECTED] wrote:
 Found these while looking at printk uses.

 Add missing newlines to dev_level uses
 Add missing KERN_level prefixes to multiline dev_levels
 Fixed a wierd-weird spelling typo
 Added a newline to a printk

I think these should have been split logically into 4 groups of
patches (except perhaps where they touched the same file for the first
two and the last).

The third type should go through trivial.

And they should have been split logically by subsystem, most likely?

snip diffstat

 diff --git a/arch/ia64/sn/kernel/xpnet.c b/arch/ia64/sn/kernel/xpnet.c
 index e58fcad..a5df672 100644
 --- a/arch/ia64/sn/kernel/xpnet.c
 +++ b/arch/ia64/sn/kernel/xpnet.c
 @@ -269,8 +269,9 @@ xpnet_receive(partid_t partid, int channel, struct 
 xpnet_message *msg)
 skb-protocol = eth_type_trans(skb, xpnet_device);
 skb-ip_summed = CHECKSUM_UNNECESSARY;

 -   dev_dbg(xpnet, passing skb to network layer; \n\tskb-head=0x%p 
 -   skb-data=0x%p skb-tail=0x%p skb-end=0x%p skb-len=%d\n,
 +   dev_dbg(xpnet, passing skb to network layer\n
 +   KERN_DEBUG \tskb-head=0x%p skb-data=0x%p skb-tail=0x%p 
 +   skb-end=0x%p skb-len=%d\n,
 (void *)skb-head, (void *)skb-data, skb_tail_pointer(skb),
 skb_end_pointer(skb), skb-len);

snip

I'm not a maintainer of any code by any means, but it seems odd,
redundant and visually confusing to me to use the dev_dbg() function
and have KERN_DEBUG's inside the string -- makes me question every
time why there isn't one for the first line too.

Perhaps these multi-line debug statements should simply be split into
multiple dev_dbg() calls? Similar for the other dev_ functions. I
think it might look cleaner, at least. Just my two cents, not a NAK or
anything.

Thanks,
Nish
-
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] remove hugetlb_instantiation_mutex

[Nish Aravamudan]

On 8/3/07, Adam Litke <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-07-30 at 15:15 +0800, Zhang, Yanmin wrote:
> > On Fri, 2007-07-27 at 11:37 -0500, Adam Litke wrote:
> > > Hey... I am amazed at how quickly you came back with a patch for this :)
> > > Thanks for looking at it.  Unfortunately there is one show-stopper and I
> > > have some reservations (pun definitely intended) with your approach:
> > Thanks for your great comments.
>
> Sorry for such a long delay in responding.  I have been pretty busy
> lately.
>
> > > First, your patch does not pass the libhugetlbfs test
> > > 'alloc-instantiate-race' which was written to tickle the the race which
> > > the mutex was introduced to solve.  Your patch works for shared
> > > mappings, but not for the private case.
> > My testing about private might not be thorough. Function hugetlb_cow has a 
> > race
> > for multi-thread to fault on the same private page index. But after I fixed 
> > it,
> > alloc-instantiate-race still failed.
> >
> > I tried to google the source code tarball of libhugetlbfs test suite, but 
> > couldn't
> > find it. Would you like to send me a copy of the test source codes?
>
> http://libhugetlbfs.ozlabs.org/releases/libhugetlbfs-1.2-pre1.tar.gz
>
> The tarball will contain a test called alloc-instantiate-race.  Make
> sure to run it in private and shared mode.  Let me know what you find
> out.

Actually, please use
http://libhugetlbfs.ozlabs.org/snapshots/libhugetlbfs-dev-20070718.tar.gz.
1.2-pre1 had a build error that is fixed in the development snapshot.

Thanks,
Nish
-
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] remove hugetlb_instantiation_mutex

[Nish Aravamudan]

On 8/3/07, Adam Litke [EMAIL PROTECTED] wrote:
 On Mon, 2007-07-30 at 15:15 +0800, Zhang, Yanmin wrote:
  On Fri, 2007-07-27 at 11:37 -0500, Adam Litke wrote:
   Hey... I am amazed at how quickly you came back with a patch for this :)
   Thanks for looking at it.  Unfortunately there is one show-stopper and I
   have some reservations (pun definitely intended) with your approach:
  Thanks for your great comments.

 Sorry for such a long delay in responding.  I have been pretty busy
 lately.

   First, your patch does not pass the libhugetlbfs test
   'alloc-instantiate-race' which was written to tickle the the race which
   the mutex was introduced to solve.  Your patch works for shared
   mappings, but not for the private case.
  My testing about private might not be thorough. Function hugetlb_cow has a 
  race
  for multi-thread to fault on the same private page index. But after I fixed 
  it,
  alloc-instantiate-race still failed.
 
  I tried to google the source code tarball of libhugetlbfs test suite, but 
  couldn't
  find it. Would you like to send me a copy of the test source codes?

 http://libhugetlbfs.ozlabs.org/releases/libhugetlbfs-1.2-pre1.tar.gz

 The tarball will contain a test called alloc-instantiate-race.  Make
 sure to run it in private and shared mode.  Let me know what you find
 out.

Actually, please use
http://libhugetlbfs.ozlabs.org/snapshots/libhugetlbfs-dev-20070718.tar.gz.
1.2-pre1 had a build error that is fixed in the development snapshot.

Thanks,
Nish
-
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: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)

[Nish Aravamudan]

On 8/1/07, Zan Lynx <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-08-01 at 08:52 -0700, Nish Aravamudan wrote:
> > On 7/31/07, Zan Lynx <[EMAIL PROTECTED]> wrote:
> > > On Tue, 2007-07-31 at 15:02 -0700, Randy Dunlap wrote:
> > > > On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote:
> > > >
> > > > > I was playing with huge pages and libhugetlbfs.  Small programs like
> > > > > "ls" work fine.  I tried running Evolution through libhugetlbfs and 
> > > > > the
> > > > > system slowly stops running.  One interesting thing is the "ps" 
> > > > > command,
> > > > > it gets stuck like this:
> > > >
> > > > Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
> > >
> > > D'oh!  I mean 2.6.23-rc1-mm1, the 22 was a typo.  Cut & paste to be
> > > sure:
> > > Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT 2007
> > > x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux
> >
> > Just to confirm, still happens with -mm2?
>
> No, it does not seem to.  Evolution runs OK.  ps, top, pmap all work
> fine.

Interesting.

> However, a couple of other things happened.  Could be unrelated or only
> loosely related.
>
> Evolution launches spamd (spamassassin) to filter junk mail.  spamd died
> and I have this in dmesg to show for it:
>
> VM: killing process spamd
>
> spamd would have inherited the libhugetlbfs.so environment variables.
> There are no other clues as to why it died though.

Interesting. Any chance spamd can be run manually with those env
variables, but with HUGETLB_VERBOSE=99 (and/or in gdb) to see what
happens to it?

> Also, immediately after launching evolution with libhugetlbfs, I got
> that USB bug where the mouse starts creating keyboard input.  I got some
> of these in dmesg:
> keyboard.c: can't emulate rawmode for keycode 240
>
> That could be pure coincidence, although I had been using the system
> almost all day before that, and it hadn't happened.

Had you started evolution w/o libhugetlbs at all before that?

It does seem like that would be coincidence.

Thanks,
Nish
-
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: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)

[Nish Aravamudan]

On 8/1/07, Zan Lynx [EMAIL PROTECTED] wrote:
 On Wed, 2007-08-01 at 08:52 -0700, Nish Aravamudan wrote:
  On 7/31/07, Zan Lynx [EMAIL PROTECTED] wrote:
   On Tue, 2007-07-31 at 15:02 -0700, Randy Dunlap wrote:
On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote:
   
 I was playing with huge pages and libhugetlbfs.  Small programs like
 ls work fine.  I tried running Evolution through libhugetlbfs and 
 the
 system slowly stops running.  One interesting thing is the ps 
 command,
 it gets stuck like this:
   
Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
  
   D'oh!  I mean 2.6.23-rc1-mm1, the 22 was a typo.  Cut  paste to be
   sure:
   Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT 2007
   x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux
 
  Just to confirm, still happens with -mm2?

 No, it does not seem to.  Evolution runs OK.  ps, top, pmap all work
 fine.

Interesting.

 However, a couple of other things happened.  Could be unrelated or only
 loosely related.

 Evolution launches spamd (spamassassin) to filter junk mail.  spamd died
 and I have this in dmesg to show for it:

 VM: killing process spamd

 spamd would have inherited the libhugetlbfs.so environment variables.
 There are no other clues as to why it died though.

Interesting. Any chance spamd can be run manually with those env
variables, but with HUGETLB_VERBOSE=99 (and/or in gdb) to see what
happens to it?

 Also, immediately after launching evolution with libhugetlbfs, I got
 that USB bug where the mouse starts creating keyboard input.  I got some
 of these in dmesg:
 keyboard.c: can't emulate rawmode for keycode 240

 That could be pure coincidence, although I had been using the system
 almost all day before that, and it hadn't happened.

Had you started evolution w/o libhugetlbs at all before that?

It does seem like that would be coincidence.

Thanks,
Nish
-
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: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)

[Nish Aravamudan]

On 7/31/07, Zan Lynx <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-07-31 at 15:02 -0700, Randy Dunlap wrote:
> > On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote:
> >
> > > I was playing with huge pages and libhugetlbfs.  Small programs like
> > > "ls" work fine.  I tried running Evolution through libhugetlbfs and the
> > > system slowly stops running.  One interesting thing is the "ps" command,
> > > it gets stuck like this:
> >
> > Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
>
> D'oh!  I mean 2.6.23-rc1-mm1, the 22 was a typo.  Cut & paste to be
> sure:
> Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT 2007
> x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux

Also, are we at all sure this isn't a reiser4 issue? I assume you're
able to use Evolution w/o libhuge on rc1-mm1 ok? Any chance to remove
reiser4 from the picture? Have you been using libhuge this way
regularly? Any chance you know it worked ok with some recent kernel
(say 2.6.23-rc1?).

Thanks,
Nish
-
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: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)

[Nish Aravamudan]

On 7/31/07, Zan Lynx <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-07-31 at 15:02 -0700, Randy Dunlap wrote:
> > On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote:
> >
> > > I was playing with huge pages and libhugetlbfs.  Small programs like
> > > "ls" work fine.  I tried running Evolution through libhugetlbfs and the
> > > system slowly stops running.  One interesting thing is the "ps" command,
> > > it gets stuck like this:
> >
> > Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
>
> D'oh!  I mean 2.6.23-rc1-mm1, the 22 was a typo.  Cut & paste to be
> sure:
> Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT 2007
> x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux

Just to confirm, still happens with -mm2?

Thanks,
Nish
-
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: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)

[Nish Aravamudan]

On 8/1/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> Nish Aravamudan wrote:
> > On 7/31/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> >> On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote:
> >>
> >>> I was playing with huge pages and libhugetlbfs.  Small programs like
> >>> "ls" work fine.  I tried running Evolution through libhugetlbfs and the
> >>> system slowly stops running.  One interesting thing is the "ps" command,
> >>> it gets stuck like this:
> >> Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
> >>
> >> There was a hugepage problem fixed very recently, in 2.6.23-rc1 IIRC.
> >
> > Actually fixed just after 2.6.23-rc1:
> >
> > git describe 5ab3ee7b1cd5c91eb2272764f9d7d1fe4749681e
> > v2.6.23-rc1-14-g5ab3ee7
>
> Looks to me like Andrew included Ken's patch in his rc1-mm1 anyway,
> so that shouldn't be the issue.  Or did I not read mm/hugetlb.c correctly?

Yeah you're right, the -mm tree has that bug fixed.

Thanks,
Nish
-
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: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)

[Nish Aravamudan]

On 7/31/07, Zan Lynx <[EMAIL PROTECTED]> wrote:
> On Tue, 2007-07-31 at 15:02 -0700, Randy Dunlap wrote:
> > On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote:
> >
> > > I was playing with huge pages and libhugetlbfs.  Small programs like
> > > "ls" work fine.  I tried running Evolution through libhugetlbfs and the
> > > system slowly stops running.  One interesting thing is the "ps" command,
> > > it gets stuck like this:
> >
> > Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
>
> D'oh!  I mean 2.6.23-rc1-mm1, the 22 was a typo.  Cut & paste to be
> sure:
> Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT 2007
> x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux

Hrm -- if you kill Evolution does the system come back? Or is it
unkillable/unusable. I guess you were able to run ps at the same time.

What is Evolution doing (sysrq+t)? For that matter, what was the
output from libhuge?

Thanks,
Nish
-
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: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)

[Nish Aravamudan]

On 7/31/07, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote:
>
> > I was playing with huge pages and libhugetlbfs.  Small programs like
> > "ls" work fine.  I tried running Evolution through libhugetlbfs and the
> > system slowly stops running.  One interesting thing is the "ps" command,
> > it gets stuck like this:
>
> Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
>
> There was a hugepage problem fixed very recently, in 2.6.23-rc1 IIRC.

Actually fixed just after 2.6.23-rc1:

git describe 5ab3ee7b1cd5c91eb2272764f9d7d1fe4749681e
v2.6.23-rc1-14-g5ab3ee7

Thanks,
Nish
-
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: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)

[Nish Aravamudan]

On 7/31/07, Randy Dunlap [EMAIL PROTECTED] wrote:
 On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote:

  I was playing with huge pages and libhugetlbfs.  Small programs like
  ls work fine.  I tried running Evolution through libhugetlbfs and the
  system slowly stops running.  One interesting thing is the ps command,
  it gets stuck like this:

 Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?

 There was a hugepage problem fixed very recently, in 2.6.23-rc1 IIRC.

Actually fixed just after 2.6.23-rc1:

git describe 5ab3ee7b1cd5c91eb2272764f9d7d1fe4749681e
v2.6.23-rc1-14-g5ab3ee7

Thanks,
Nish
-
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: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)

[Nish Aravamudan]

On 8/1/07, Randy Dunlap [EMAIL PROTECTED] wrote:
 Nish Aravamudan wrote:
  On 7/31/07, Randy Dunlap [EMAIL PROTECTED] wrote:
  On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote:
 
  I was playing with huge pages and libhugetlbfs.  Small programs like
  ls work fine.  I tried running Evolution through libhugetlbfs and the
  system slowly stops running.  One interesting thing is the ps command,
  it gets stuck like this:
  Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?
 
  There was a hugepage problem fixed very recently, in 2.6.23-rc1 IIRC.
 
  Actually fixed just after 2.6.23-rc1:
 
  git describe 5ab3ee7b1cd5c91eb2272764f9d7d1fe4749681e
  v2.6.23-rc1-14-g5ab3ee7

 Looks to me like Andrew included Ken's patch in his rc1-mm1 anyway,
 so that shouldn't be the issue.  Or did I not read mm/hugetlb.c correctly?

Yeah you're right, the -mm tree has that bug fixed.

Thanks,
Nish
-
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: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)

[Nish Aravamudan]

On 7/31/07, Zan Lynx [EMAIL PROTECTED] wrote:
 On Tue, 2007-07-31 at 15:02 -0700, Randy Dunlap wrote:
  On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote:
 
   I was playing with huge pages and libhugetlbfs.  Small programs like
   ls work fine.  I tried running Evolution through libhugetlbfs and the
   system slowly stops running.  One interesting thing is the ps command,
   it gets stuck like this:
 
  Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?

 D'oh!  I mean 2.6.23-rc1-mm1, the 22 was a typo.  Cut  paste to be
 sure:
 Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT 2007
 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux

Just to confirm, still happens with -mm2?

Thanks,
Nish
-
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: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)

[Nish Aravamudan]

On 7/31/07, Zan Lynx [EMAIL PROTECTED] wrote:
 On Tue, 2007-07-31 at 15:02 -0700, Randy Dunlap wrote:
  On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote:
 
   I was playing with huge pages and libhugetlbfs.  Small programs like
   ls work fine.  I tried running Evolution through libhugetlbfs and the
   system slowly stops running.  One interesting thing is the ps command,
   it gets stuck like this:
 
  Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?

 D'oh!  I mean 2.6.23-rc1-mm1, the 22 was a typo.  Cut  paste to be
 sure:
 Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT 2007
 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux

Hrm -- if you kill Evolution does the system come back? Or is it
unkillable/unusable. I guess you were able to run ps at the same time.

What is Evolution doing (sysrq+t)? For that matter, what was the
output from libhuge?

Thanks,
Nish
-
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: 2.6.22-rc1-mm1 huge pages VM freeze (maybe?)

[Nish Aravamudan]

On 7/31/07, Zan Lynx [EMAIL PROTECTED] wrote:
 On Tue, 2007-07-31 at 15:02 -0700, Randy Dunlap wrote:
  On Tue, 31 Jul 2007 15:44:21 -0600 Zan Lynx wrote:
 
   I was playing with huge pages and libhugetlbfs.  Small programs like
   ls work fine.  I tried running Evolution through libhugetlbfs and the
   system slowly stops running.  One interesting thing is the ps command,
   it gets stuck like this:
 
  Do you mean 2.6.22-rc1-mm1 or 2.6.23-rc1-mm1?

 D'oh!  I mean 2.6.23-rc1-mm1, the 22 was a typo.  Cut  paste to be
 sure:
 Linux zephyr 2.6.23-rc1-mm1 #1 SMP PREEMPT Wed Jul 25 17:33:04 MDT 2007
 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux

Also, are we at all sure this isn't a reiser4 issue? I assume you're
able to use Evolution w/o libhuge on rc1-mm1 ok? Any chance to remove
reiser4 from the picture? Have you been using libhuge this way
regularly? Any chance you know it worked ok with some recent kernel
(say 2.6.23-rc1?).

Thanks,
Nish
-
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/RFC] msleep() with hrtimers

[Nish Aravamudan]

On 7/16/07, Nick Piggin <[EMAIL PROTECTED]> wrote:

Nish Aravamudan wrote:

> Well, before these changes, the only guarantee msleep() could make,
> just like the only guarantee schedule_timeout() could make, was that
> it would not return early. The 1-jiffy sleep was always tough to deal
> with, because of rounding and such. And it's simply exacerbated with
> HZ=100. It's not technically 20 times longer in all cases, it's 2
> jiffies longer, which depends on HZ, so varies from 2 msecs longer to
> 20 msecs longer.

I don't think you should rely on anything else actually, because Linux
is not an RT OS. If your driver needs a specific sequence in a given
amount of time, you have to do something like disable interrupts and
use delays.


I agree -- I wasn't trying to indicate what one should or should not
do. Just tried to provide some insight into the intent behind the
interfaces. They were never meant to be precise, per se -- simply
guaranteeing the request would be satisfied, with no upper bound. I
agree that if timing really is that critical then delays or more
accurate timing specifications would be appropriate (one reason to use
msecs_to_jiffies() and co. rather than jiffies directly in drivers,
perhaps).

Thanks,
Nish
-
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/RFC] msleep() with hrtimers

[Nish Aravamudan]

On 7/16/07, Nick Piggin [EMAIL PROTECTED] wrote:

Nish Aravamudan wrote:

 Well, before these changes, the only guarantee msleep() could make,
 just like the only guarantee schedule_timeout() could make, was that
 it would not return early. The 1-jiffy sleep was always tough to deal
 with, because of rounding and such. And it's simply exacerbated with
 HZ=100. It's not technically 20 times longer in all cases, it's 2
 jiffies longer, which depends on HZ, so varies from 2 msecs longer to
 20 msecs longer.

I don't think you should rely on anything else actually, because Linux
is not an RT OS. If your driver needs a specific sequence in a given
amount of time, you have to do something like disable interrupts and
use delays.


I agree -- I wasn't trying to indicate what one should or should not
do. Just tried to provide some insight into the intent behind the
interfaces. They were never meant to be precise, per se -- simply
guaranteeing the request would be satisfied, with no upper bound. I
agree that if timing really is that critical then delays or more
accurate timing specifications would be appropriate (one reason to use
msecs_to_jiffies() and co. rather than jiffies directly in drivers,
perhaps).

Thanks,
Nish
-
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/RFC] msleep() with hrtimers

[Nish Aravamudan]

On 7/16/07, Ray Lee <[EMAIL PROTECTED]> wrote:

On 7/16/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
> On Mon, 16 Jul 2007, Jonathan Corbet wrote:
> > > One possible problem here is that setting up that timer can be
> > > considerably more expensive, for a relative timer you have to read the
> > > current time, which can be quite expensive (e.g. your machine now uses the
> > > PIT timer, because TSC was deemed unstable).
> >
> > That's a possibility, I admit I haven't benchmarked it.  I will say that
> > I don't think it will be enough to matter - msleep() is not a hot-path
> > sort of function.  Once the system is up and running it almost never
> > gets called at all - at least, on my setup.
>
> That's a bit my problem - we have to consider other setups as well.
> Is it worth converting all msleep users behind their back or should we
> just a provide a separate function for those who care?

As a driver author (2.4 timeframe, embedded platform, see gitinc.com
for the hardware description), I would rather msleep did what it says
it's going to do. If the current one can wait 20 times longer than you
ask for, then that's just broken.


Well, before these changes, the only guarantee msleep() could make,
just like the only guarantee schedule_timeout() could make, was that
it would not return early. The 1-jiffy sleep was always tough to deal
with, because of rounding and such. And it's simply exacerbated with
HZ=100. It's not technically 20 times longer in all cases, it's 2
jiffies longer, which depends on HZ, so varies from 2 msecs longer to
20 msecs longer.

Thanks,
Nish
-
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/RFC] msleep() with hrtimers

[Nish Aravamudan]

On 7/16/07, Ray Lee [EMAIL PROTECTED] wrote:

On 7/16/07, Roman Zippel [EMAIL PROTECTED] wrote:
 On Mon, 16 Jul 2007, Jonathan Corbet wrote:
   One possible problem here is that setting up that timer can be
   considerably more expensive, for a relative timer you have to read the
   current time, which can be quite expensive (e.g. your machine now uses the
   PIT timer, because TSC was deemed unstable).
 
  That's a possibility, I admit I haven't benchmarked it.  I will say that
  I don't think it will be enough to matter - msleep() is not a hot-path
  sort of function.  Once the system is up and running it almost never
  gets called at all - at least, on my setup.

 That's a bit my problem - we have to consider other setups as well.
 Is it worth converting all msleep users behind their back or should we
 just a provide a separate function for those who care?

As a driver author (2.4 timeframe, embedded platform, see gitinc.com
for the hardware description), I would rather msleep did what it says
it's going to do. If the current one can wait 20 times longer than you
ask for, then that's just broken.


Well, before these changes, the only guarantee msleep() could make,
just like the only guarantee schedule_timeout() could make, was that
it would not return early. The 1-jiffy sleep was always tough to deal
with, because of rounding and such. And it's simply exacerbated with
HZ=100. It's not technically 20 times longer in all cases, it's 2
jiffies longer, which depends on HZ, so varies from 2 msecs longer to
20 msecs longer.

Thanks,
Nish
-
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] Add nid sanity on alloc_pages_node

[Nish Aravamudan]

On 7/14/07, Andrew Morton <[EMAIL PROTECTED]> wrote:

On Sat, 14 Jul 2007 10:40:25 -0700 "Nish Aravamudan" <[EMAIL PROTECTED]> wrote:

> On 7/13/07, Joe Jin <[EMAIL PROTECTED]> wrote:
> > >
> > > Patch gone too ;) I deleted it.  I was hoping that you'd send me the final
> > > finished product (please).
> > >
> >
> > Ha.., the patch against 2.6.22, at your patch have use htlb_alloc_mask, but 
I
> > cannot found it at 2.6.22 kernel tree, I think you must use difference 
kernel
> > tree :)
>
> I believe this patch will be unnecessary if my "Fix hugetlb pool
> allocation with empty nodes" patch gets pulled into -mm.
> alloc_fresh_huge_page() now takes a mempolicy which is created by the
> two callers, rather than reinventing interleaving itself. I believe
> this will avoid the oops you saw. I am still waiting on some test
> results (annoying -mm config changes) before I repost them (and they
> depend on Christoph's fixes for memoryless nodes).

Could be so, but the patch which I have queued is nice and simple and
can be backported into 2.6.22.x.


Fair enough. FWIW, just finished testing my patches and have posted
the current incarnation to linux-mm.

Thanks,
Nish
-
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/