Re: drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer
On Fri, 9 Sep 2016 13:55:45 +0200 Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Thu, Sep 08, 2016 at 04:59:53PM +0100, Nick Warne wrote: > > On Thu, 8 Sep 2016 08:29:37 +0200 > > Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > > > > > On Wed, Sep 07, 2016 at 05:38:52PM +0100, Nick Warne wrote: > > > > Hi Daniel, > > > > > > > > kernel build 4.4.20 - I am still seeing this warning: > > > > > > > > drivers/gpu/drm/i915/intel_display.c: In function > > > > ‘intel_plane_obj_offset’: > > > > drivers/gpu/drm/i915/intel_display.c:2969:11: warning: cast to > > > > pointer from integer of different size [-Wint-to-pointer-cast] > > > > offset = (unsigned char *)vma->node.start; > > > > > > > > but according to here: > > > > > > > > https://patchwork.kernel.org/patch/7897461/ > > > > > > > > this has been fixed up. Any reason why it hasn't in the latest > > > > 4.4.x longterm tree? > > > > > > What is the commit id that fixed this in Linus's tree? > > > > Took me a while to find it if this is it - a bit of a re-write in > > the whole file I think: > > > > https://github.com/torvalds/linux/commit/44eb0cb9620c6a53ec8e7073262e2af8079b727f > > > > Ick, messy. > > Why not just use 4.7? Why are you stuck at 4.4? OK, running on 4.7.3 - no issues, all Hunky Dory. Thanks Greg and kernel people - grand job you all do! Best regards, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
Re: drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer
On Fri, 9 Sep 2016 13:55:45 +0200 Greg Kroah-Hartman wrote: > On Thu, Sep 08, 2016 at 04:59:53PM +0100, Nick Warne wrote: > > On Thu, 8 Sep 2016 08:29:37 +0200 > > Greg Kroah-Hartman wrote: > > > > > On Wed, Sep 07, 2016 at 05:38:52PM +0100, Nick Warne wrote: > > > > Hi Daniel, > > > > > > > > kernel build 4.4.20 - I am still seeing this warning: > > > > > > > > drivers/gpu/drm/i915/intel_display.c: In function > > > > ‘intel_plane_obj_offset’: > > > > drivers/gpu/drm/i915/intel_display.c:2969:11: warning: cast to > > > > pointer from integer of different size [-Wint-to-pointer-cast] > > > > offset = (unsigned char *)vma->node.start; > > > > > > > > but according to here: > > > > > > > > https://patchwork.kernel.org/patch/7897461/ > > > > > > > > this has been fixed up. Any reason why it hasn't in the latest > > > > 4.4.x longterm tree? > > > > > > What is the commit id that fixed this in Linus's tree? > > > > Took me a while to find it if this is it - a bit of a re-write in > > the whole file I think: > > > > https://github.com/torvalds/linux/commit/44eb0cb9620c6a53ec8e7073262e2af8079b727f > > > > Ick, messy. > > Why not just use 4.7? Why are you stuck at 4.4? OK, running on 4.7.3 - no issues, all Hunky Dory. Thanks Greg and kernel people - grand job you all do! Best regards, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
Re: drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer
On Fri, 9 Sep 2016 13:55:45 +0200 Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Thu, Sep 08, 2016 at 04:59:53PM +0100, Nick Warne wrote: > > On Thu, 8 Sep 2016 08:29:37 +0200 > > Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > > > > > On Wed, Sep 07, 2016 at 05:38:52PM +0100, Nick Warne wrote: > > > > Hi Daniel, > > > > > > > > kernel build 4.4.20 - I am still seeing this warning: > > > > > > > > drivers/gpu/drm/i915/intel_display.c: In function > > > > ‘intel_plane_obj_offset’: > > > > drivers/gpu/drm/i915/intel_display.c:2969:11: warning: cast to > > > > pointer from integer of different size [-Wint-to-pointer-cast] > > > > offset = (unsigned char *)vma->node.start; > > > > > > > > but according to here: > > > > > > > > https://patchwork.kernel.org/patch/7897461/ > > > > > > > > this has been fixed up. Any reason why it hasn't in the latest > > > > 4.4.x longterm tree? > > > > > > What is the commit id that fixed this in Linus's tree? > > > > Took me a while to find it if this is it - a bit of a re-write in > > the whole file I think: > > > > https://github.com/torvalds/linux/commit/44eb0cb9620c6a53ec8e7073262e2af8079b727f > > > > Ick, messy. > > Why not just use 4.7? Why are you stuck at 4.4? I only recently moved over to 4.4 from 3.18.x as it's longterm support. I may try 4.7 over the weekend - or maybe even just use the patchwork diff on my own local builds. > And is this a real bug in 4.4 or just a build warning? No, it's not a bug (that I have found or seen, anyway), just GCC squinnying. Thanks for your help, and sorry for the noise. Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
Re: drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer
On Fri, 9 Sep 2016 13:55:45 +0200 Greg Kroah-Hartman wrote: > On Thu, Sep 08, 2016 at 04:59:53PM +0100, Nick Warne wrote: > > On Thu, 8 Sep 2016 08:29:37 +0200 > > Greg Kroah-Hartman wrote: > > > > > On Wed, Sep 07, 2016 at 05:38:52PM +0100, Nick Warne wrote: > > > > Hi Daniel, > > > > > > > > kernel build 4.4.20 - I am still seeing this warning: > > > > > > > > drivers/gpu/drm/i915/intel_display.c: In function > > > > ‘intel_plane_obj_offset’: > > > > drivers/gpu/drm/i915/intel_display.c:2969:11: warning: cast to > > > > pointer from integer of different size [-Wint-to-pointer-cast] > > > > offset = (unsigned char *)vma->node.start; > > > > > > > > but according to here: > > > > > > > > https://patchwork.kernel.org/patch/7897461/ > > > > > > > > this has been fixed up. Any reason why it hasn't in the latest > > > > 4.4.x longterm tree? > > > > > > What is the commit id that fixed this in Linus's tree? > > > > Took me a while to find it if this is it - a bit of a re-write in > > the whole file I think: > > > > https://github.com/torvalds/linux/commit/44eb0cb9620c6a53ec8e7073262e2af8079b727f > > > > Ick, messy. > > Why not just use 4.7? Why are you stuck at 4.4? I only recently moved over to 4.4 from 3.18.x as it's longterm support. I may try 4.7 over the weekend - or maybe even just use the patchwork diff on my own local builds. > And is this a real bug in 4.4 or just a build warning? No, it's not a bug (that I have found or seen, anyway), just GCC squinnying. Thanks for your help, and sorry for the noise. Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
Re: drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer
On Thu, 8 Sep 2016 08:29:37 +0200 Greg Kroah-Hartman <gre...@linuxfoundation.org> wrote: > On Wed, Sep 07, 2016 at 05:38:52PM +0100, Nick Warne wrote: > > Hi Daniel, > > > > kernel build 4.4.20 - I am still seeing this warning: > > > > drivers/gpu/drm/i915/intel_display.c: In function > > ‘intel_plane_obj_offset’: > > drivers/gpu/drm/i915/intel_display.c:2969:11: warning: cast to > > pointer from integer of different size [-Wint-to-pointer-cast] > > offset = (unsigned char *)vma->node.start; > > > > but according to here: > > > > https://patchwork.kernel.org/patch/7897461/ > > > > this has been fixed up. Any reason why it hasn't in the latest > > 4.4.x longterm tree? > > What is the commit id that fixed this in Linus's tree? Took me a while to find it if this is it - a bit of a re-write in the whole file I think: https://github.com/torvalds/linux/commit/44eb0cb9620c6a53ec8e7073262e2af8079b727f Thanks, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
Re: drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer
On Thu, 8 Sep 2016 08:29:37 +0200 Greg Kroah-Hartman wrote: > On Wed, Sep 07, 2016 at 05:38:52PM +0100, Nick Warne wrote: > > Hi Daniel, > > > > kernel build 4.4.20 - I am still seeing this warning: > > > > drivers/gpu/drm/i915/intel_display.c: In function > > ‘intel_plane_obj_offset’: > > drivers/gpu/drm/i915/intel_display.c:2969:11: warning: cast to > > pointer from integer of different size [-Wint-to-pointer-cast] > > offset = (unsigned char *)vma->node.start; > > > > but according to here: > > > > https://patchwork.kernel.org/patch/7897461/ > > > > this has been fixed up. Any reason why it hasn't in the latest > > 4.4.x longterm tree? > > What is the commit id that fixed this in Linus's tree? Took me a while to find it if this is it - a bit of a re-write in the whole file I think: https://github.com/torvalds/linux/commit/44eb0cb9620c6a53ec8e7073262e2af8079b727f Thanks, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer
Hi Daniel, kernel build 4.4.20 - I am still seeing this warning: drivers/gpu/drm/i915/intel_display.c: In function ‘intel_plane_obj_offset’: drivers/gpu/drm/i915/intel_display.c:2969:11: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] offset = (unsigned char *)vma->node.start; but according to here: https://patchwork.kernel.org/patch/7897461/ this has been fixed up. Any reason why it hasn't in the latest 4.4.x longterm tree? Thanks, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer
Hi Daniel, kernel build 4.4.20 - I am still seeing this warning: drivers/gpu/drm/i915/intel_display.c: In function ‘intel_plane_obj_offset’: drivers/gpu/drm/i915/intel_display.c:2969:11: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] offset = (unsigned char *)vma->node.start; but according to here: https://patchwork.kernel.org/patch/7897461/ this has been fixed up. Any reason why it hasn't in the latest 4.4.x longterm tree? Thanks, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara"
Re: [PATCH] net/core/sysctl_net_core.c unused variable
On 06/09/15 16:51, Joe Perches wrote:
On Sun, 2015-09-06 at 16:36 +0100, Nick Warne wrote:
On 06/09/15 16:28, Joe Perches wrote:
> On Sun, 2015-09-06 at 16:16 +0100, Nick Warne wrote:
>> On 06/09/15 15:52, Joe Perches wrote:
>> > On Sun, 2015-09-06 at 15:13 +0100, Nick Warne wrote:
>> >> gcc version 4.8.2 (GCC) warns that 'static int one = 1;' is declared but
>> >> not used in file net/core/sysctl_net_core.c.
>> >
>> > Only when CONFIG_NET isn't set.
>>
>> CONFIG_NET=y
>>
>> Peculiar indeed.
>>
>> >> Reading the file, that is
>> >> the case. Attached is a patch to remove it.
>> >
>> > $ git grep -w -n one net/core/sysctl_net_core.c
>> > net/core/sysctl_net_core.c:26:static int one = 1;
>> > net/core/sysctl_net_core.c:332: .extra2 =
>> >
>> >> Signed-off-by: Nick Warne
>> >
>> > Please use grep to augment reading.
>>
>> grep -w -n one net/core/sysctl_net_core.c
>> 26:static int one = 1;
>>
>> ?
>>
>> I just don't have the
>>
>> I am confused now.
>
> What source tree are you using?
Latest longterm 3.18.21
OK, it's important to mention that otherwise the
assumption would be a git tree like net or net-next.
> What changes in what branch exist?
I am not using git (if that is what you mean by 'branches') - just
tarballs from kernel.org
(OK, using git and linux-stable)
$ git grep -w -n one v3.18.21 -- net/core/sysctl_net_core.c
v3.18.21:net/core/sysctl_net_core.c:26:static int one = 1;
And the responsible commit:
commit c48cf4f27d4555a455c3fef71137bd0fc44d1656
("net: sysctl_net_core: check SNDBUF and RCVBUF for min length")
Ah, OK. GCC was right - just the variable declaration was overlooked to
be removed too.
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=c48cf4f27d4555a455c3fef71137bd0fc44d1656
My patch was right then (but wrong) :)
Thanks Joe,
Nick
--
Gosh that takes me back... or is it forward? That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"
--
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] net/core/sysctl_net_core.c unused variable
On 06/09/15 16:28, Joe Perches wrote: On Sun, 2015-09-06 at 16:16 +0100, Nick Warne wrote: On 06/09/15 15:52, Joe Perches wrote: > On Sun, 2015-09-06 at 15:13 +0100, Nick Warne wrote: >> gcc version 4.8.2 (GCC) warns that 'static int one = 1;' is declared but >> not used in file net/core/sysctl_net_core.c. > > Only when CONFIG_NET isn't set. CONFIG_NET=y Peculiar indeed. >> Reading the file, that is >> the case. Attached is a patch to remove it. > > $ git grep -w -n one net/core/sysctl_net_core.c > net/core/sysctl_net_core.c:26:static int one = 1; > net/core/sysctl_net_core.c:332: .extra2 = > >> Signed-off-by: Nick Warne > > Please use grep to augment reading. grep -w -n one net/core/sysctl_net_core.c 26:static int one = 1; ? I just don't have the I am confused now. What source tree are you using? Latest longterm 3.18.21 What changes in what branch exist? I am not using git (if that is what you mean by 'branches') - just tarballs from kernel.org btw: please use scripts/get_maintainer.pl to better determine who should be cc'd on your patches. you left out netdev. Sorry, my bad, I need to learn/read more. Thanks for your help/advice :) Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara" -- 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] net/core/sysctl_net_core.c unused variable
On 06/09/15 15:52, Joe Perches wrote: On Sun, 2015-09-06 at 15:13 +0100, Nick Warne wrote: gcc version 4.8.2 (GCC) warns that 'static int one = 1;' is declared but not used in file net/core/sysctl_net_core.c. Only when CONFIG_NET isn't set. CONFIG_NET=y Peculiar indeed. Reading the file, that is the case. Attached is a patch to remove it. $ git grep -w -n one net/core/sysctl_net_core.c net/core/sysctl_net_core.c:26:static int one = 1; net/core/sysctl_net_core.c:332: .extra2 = Signed-off-by: Nick Warne Please use grep to augment reading. grep -w -n one net/core/sysctl_net_core.c 26:static int one = 1; ? I just don't have the I am confused now. Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara" -- 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/
[PATCH] net/core/sysctl_net_core.c unused variable
gcc version 4.8.2 (GCC) warns that 'static int one = 1;' is declared but not used in file net/core/sysctl_net_core.c. Reading the file, that is the case. Attached is a patch to remove it. Signed-off-by: Nick Warne Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara" --- linux-3.18.21/net/core/sysctl_net_core.c.orig 2015-09-06 15:03:05.066306670 +0100 +++ linux-3.18.21/net/core/sysctl_net_core.c2015-09-06 15:03:14.501034348 +0100 @@ -23,7 +23,6 @@ #include static int zero = 0; -static int one = 1; static int ushort_max = USHRT_MAX; static int min_sndbuf = SOCK_MIN_SNDBUF; static int min_rcvbuf = SOCK_MIN_RCVBUF;
[PATCH] net/core/sysctl_net_core.c unused variable
gcc version 4.8.2 (GCC) warns that 'static int one = 1;' is declared but not used in file net/core/sysctl_net_core.c. Reading the file, that is the case. Attached is a patch to remove it. Signed-off-by: Nick Warne <n...@linicks.net> Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara" --- linux-3.18.21/net/core/sysctl_net_core.c.orig 2015-09-06 15:03:05.066306670 +0100 +++ linux-3.18.21/net/core/sysctl_net_core.c2015-09-06 15:03:14.501034348 +0100 @@ -23,7 +23,6 @@ #include static int zero = 0; -static int one = 1; static int ushort_max = USHRT_MAX; static int min_sndbuf = SOCK_MIN_SNDBUF; static int min_rcvbuf = SOCK_MIN_RCVBUF;
Re: [PATCH] net/core/sysctl_net_core.c unused variable
On 06/09/15 15:52, Joe Perches wrote: On Sun, 2015-09-06 at 15:13 +0100, Nick Warne wrote: gcc version 4.8.2 (GCC) warns that 'static int one = 1;' is declared but not used in file net/core/sysctl_net_core.c. Only when CONFIG_NET isn't set. CONFIG_NET=y Peculiar indeed. Reading the file, that is the case. Attached is a patch to remove it. $ git grep -w -n one net/core/sysctl_net_core.c net/core/sysctl_net_core.c:26:static int one = 1; net/core/sysctl_net_core.c:332: .extra2 = Signed-off-by: Nick Warne <n...@linicks.net> Please use grep to augment reading. grep -w -n one net/core/sysctl_net_core.c 26:static int one = 1; ? I just don't have the I am confused now. Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara" -- 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] net/core/sysctl_net_core.c unused variable
On 06/09/15 16:51, Joe Perches wrote:
On Sun, 2015-09-06 at 16:36 +0100, Nick Warne wrote:
On 06/09/15 16:28, Joe Perches wrote:
> On Sun, 2015-09-06 at 16:16 +0100, Nick Warne wrote:
>> On 06/09/15 15:52, Joe Perches wrote:
>> > On Sun, 2015-09-06 at 15:13 +0100, Nick Warne wrote:
>> >> gcc version 4.8.2 (GCC) warns that 'static int one = 1;' is declared but
>> >> not used in file net/core/sysctl_net_core.c.
>> >
>> > Only when CONFIG_NET isn't set.
>>
>> CONFIG_NET=y
>>
>> Peculiar indeed.
>>
>> >> Reading the file, that is
>> >> the case. Attached is a patch to remove it.
>> >
>> > $ git grep -w -n one net/core/sysctl_net_core.c
>> > net/core/sysctl_net_core.c:26:static int one = 1;
>> > net/core/sysctl_net_core.c:332: .extra2 =
>> >
>> >> Signed-off-by: Nick Warne <n...@linicks.net>
>> >
>> > Please use grep to augment reading.
>>
>> grep -w -n one net/core/sysctl_net_core.c
>> 26:static int one = 1;
>>
>> ?
>>
>> I just don't have the
>>
>> I am confused now.
>
> What source tree are you using?
Latest longterm 3.18.21
OK, it's important to mention that otherwise the
assumption would be a git tree like net or net-next.
> What changes in what branch exist?
I am not using git (if that is what you mean by 'branches') - just
tarballs from kernel.org
(OK, using git and linux-stable)
$ git grep -w -n one v3.18.21 -- net/core/sysctl_net_core.c
v3.18.21:net/core/sysctl_net_core.c:26:static int one = 1;
And the responsible commit:
commit c48cf4f27d4555a455c3fef71137bd0fc44d1656
("net: sysctl_net_core: check SNDBUF and RCVBUF for min length")
Ah, OK. GCC was right - just the variable declaration was overlooked to
be removed too.
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=c48cf4f27d4555a455c3fef71137bd0fc44d1656
My patch was right then (but wrong) :)
Thanks Joe,
Nick
--
Gosh that takes me back... or is it forward? That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"
--
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] net/core/sysctl_net_core.c unused variable
On 06/09/15 16:28, Joe Perches wrote: On Sun, 2015-09-06 at 16:16 +0100, Nick Warne wrote: On 06/09/15 15:52, Joe Perches wrote: > On Sun, 2015-09-06 at 15:13 +0100, Nick Warne wrote: >> gcc version 4.8.2 (GCC) warns that 'static int one = 1;' is declared but >> not used in file net/core/sysctl_net_core.c. > > Only when CONFIG_NET isn't set. CONFIG_NET=y Peculiar indeed. >> Reading the file, that is >> the case. Attached is a patch to remove it. > > $ git grep -w -n one net/core/sysctl_net_core.c > net/core/sysctl_net_core.c:26:static int one = 1; > net/core/sysctl_net_core.c:332: .extra2 = > >> Signed-off-by: Nick Warne <n...@linicks.net> > > Please use grep to augment reading. grep -w -n one net/core/sysctl_net_core.c 26:static int one = 1; ? I just don't have the I am confused now. What source tree are you using? Latest longterm 3.18.21 What changes in what branch exist? I am not using git (if that is what you mean by 'branches') - just tarballs from kernel.org btw: please use scripts/get_maintainer.pl to better determine who should be cc'd on your patches. you left out netdev. Sorry, my bad, I need to learn/read more. Thanks for your help/advice :) Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara" -- 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/
3.18.18 - synaptics.c regression
I am just building 3.18.18, and GCC threw up a warning about 'missing
curly braces' in drivers/input/mouse/synaptics.c
Looking at the file, line 152 has the min_max_pnpid_table[3].board_id’
stuff missing:
*snip*
{
(const char * const []){"LEN0034", "LEN0036", "LEN0037",
"LEN0039", "LEN2002", "LEN2004",
NULL},
{ANY_BOARD_ID, 2961},
1024, 5112, 2024, 4832
},
{
(const char * const []){"LEN2000", NULL},
1024, 5113, 2021, 4832<---line missing above here
},
{
(const char * const []){"LEN2001", NULL},
{ANY_BOARD_ID, ANY_BOARD_ID},
1024, 5022, 2508, 4832
},
*snip*
I am not sure what goes here, maybe just {ANY_BOARD_ID, ANY_BOARD_ID}?
Regards,
Nick
--
Gosh that takes me back... or is it forward? That's the trouble with
time travel, you never can tell."
-- Doctor Who "Androids of Tara"
--
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/
3.18.18 - synaptics.c regression
I am just building 3.18.18, and GCC threw up a warning about 'missing
curly braces' in drivers/input/mouse/synaptics.c
Looking at the file, line 152 has the min_max_pnpid_table[3].board_id’
stuff missing:
*snip*
{
(const char * const []){LEN0034, LEN0036, LEN0037,
LEN0039, LEN2002, LEN2004,
NULL},
{ANY_BOARD_ID, 2961},
1024, 5112, 2024, 4832
},
{
(const char * const []){LEN2000, NULL},
1024, 5113, 2021, 4832---line missing above here
},
{
(const char * const []){LEN2001, NULL},
{ANY_BOARD_ID, ANY_BOARD_ID},
1024, 5022, 2508, 4832
},
*snip*
I am not sure what goes here, maybe just {ANY_BOARD_ID, ANY_BOARD_ID}?
Regards,
Nick
--
Gosh that takes me back... or is it forward? That's the trouble with
time travel, you never can tell.
-- Doctor Who Androids of Tara
--
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/
Question: kernel->memtest documentation
Hi all, I have had an issue on my server for a few months with random shutdowns. Today I configured the kernel option 'memtest' (on 3.19) and it appears to work when I reading boot logs... but trying to research on what it does is non-existent. Reading the code there appears to be no log if bad memory is found (or not, I dunno?). Would I see anything in particular in logs if memtest does find something? Is there a way to see if memory is mapped out to not use? This appears to be a great option, but nothing on it's usage. Maybe I am an idiot... Thanks, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell." -- Doctor Who "Androids of Tara" -- 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/
Question: kernel-memtest documentation
Hi all, I have had an issue on my server for a few months with random shutdowns. Today I configured the kernel option 'memtest' (on 3.19) and it appears to work when I reading boot logs... but trying to research on what it does is non-existent. Reading the code there appears to be no log if bad memory is found (or not, I dunno?). Would I see anything in particular in logs if memtest does find something? Is there a way to see if memory is mapped out to not use? This appears to be a great option, but nothing on it's usage. Maybe I am an idiot... Thanks, Nick -- Gosh that takes me back... or is it forward? That's the trouble with time travel, you never can tell. -- Doctor Who Androids of Tara -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.18.4
Wow. On my amd64 it usually takes about 19 minutes to build my bespoke kernel. After I downloaded/untarball/setup issued 'make' and then watched TV for a bit. Bloody hell, next time I looked it was built... in about 13 minutes. I suspected something was wrong, as I added new ipsets classes tonight prior to this and had to double check. Nope, all hunky dory :) So, I just updated my lowly Samsung notebook bespoke build - normal build time on this is about 57 minutes - 3.18.4 is now < 45 minutes. Great stuff - I dunno what you guys changed, but it's good. Many thanks, Nick P.S. also the Intel driver is fixed toboot too :) -- Q. What's the difference between a duck and an elephant? A. You can't get down off an elephant. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.18.4
Wow. On my amd64 it usually takes about 19 minutes to build my bespoke kernel. After I downloaded/untarball/setup issued 'make' and then watched TV for a bit. Bloody hell, next time I looked it was built... in about 13 minutes. I suspected something was wrong, as I added new ipsets classes tonight prior to this and had to double check. Nope, all hunky dory :) So, I just updated my lowly Samsung notebook bespoke build - normal build time on this is about 57 minutes - 3.18.4 is now 45 minutes. Great stuff - I dunno what you guys changed, but it's good. Many thanks, Nick P.S. also the Intel driver is fixed toboot too :) -- Q. What's the difference between a duck and an elephant? A. You can't get down off an elephant. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.18.3
On 17/01/15 09:43, Nick Warne wrote: On 17.01.2015, Heinz Diehl wrote: > Since 3.18, machines with Ironlake Intel Graphics are left with a > black screen when booting into X. I reported the bug here: > > https://www.libreoffice.org/bugzilla/show_bug.cgi?id=87330 Yes (since 3.18.), and on my notebook with: 00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller 00:02.1 Display controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller if I use the Intel sna driver, just running glxgears crashes X to the console, and videos run in mplayer but just appear black. Strangely enough, after X crashes, if I restart it, all works fine? I am currently using the Intel uxa driver which works OK on any occasion. The above symptoms are still the same in 3.18.3 OK, perhaps I should have reported this when it happened, but I thought it was the notebook/me/the dog causing it. I applied the changes from here: http://cgit.freedesktop.org/drm-intel/patch/?id=d472fcc8379c062bd56a3876fc6ef22258f14a91 albeit on different code lines on 3.18.3 and all is hunky dory again using driver sna! Greg, me thinks this should go in next -stable. Thanks! Nick -- "A bug in the code is worth two in the documentation." http://linicks.net/ http://slackpi.linicks.net/ http://fishpi.linicks.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.18.3
On 17.01.2015, Heinz Diehl wrote: > Since 3.18, machines with Ironlake Intel Graphics are left with a > black screen when booting into X. I reported the bug here: > > https://www.libreoffice.org/bugzilla/show_bug.cgi?id=87330 Yes (since 3.18.), and on my notebook with: 00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller 00:02.1 Display controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller if I use the Intel sna driver, just running glxgears crashes X to the console, and videos run in mplayer but just appear black. Strangely enough, after X crashes, if I restart it, all works fine? I am currently using the Intel uxa driver which works OK on any occasion. The above symptoms are still the same in 3.18.3 Nick -- "A bug in the code is worth two in the documentation." http://linicks.net/ http://slackpi.linicks.net/ http://fishpi.linicks.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.18.3
On 17.01.2015, Heinz Diehl wrote: Since 3.18, machines with Ironlake Intel Graphics are left with a black screen when booting into X. I reported the bug here: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=87330 Yes (since 3.18.), and on my notebook with: 00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller 00:02.1 Display controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller if I use the Intel sna driver, just running glxgears crashes X to the console, and videos run in mplayer but just appear black. Strangely enough, after X crashes, if I restart it, all works fine? I am currently using the Intel uxa driver which works OK on any occasion. The above symptoms are still the same in 3.18.3 Nick -- A bug in the code is worth two in the documentation. http://linicks.net/ http://slackpi.linicks.net/ http://fishpi.linicks.net/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.18.3
On 17/01/15 09:43, Nick Warne wrote: On 17.01.2015, Heinz Diehl wrote: Since 3.18, machines with Ironlake Intel Graphics are left with a black screen when booting into X. I reported the bug here: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=87330 Yes (since 3.18.), and on my notebook with: 00:02.0 VGA compatible controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller 00:02.1 Display controller: Intel Corporation Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller if I use the Intel sna driver, just running glxgears crashes X to the console, and videos run in mplayer but just appear black. Strangely enough, after X crashes, if I restart it, all works fine? I am currently using the Intel uxa driver which works OK on any occasion. The above symptoms are still the same in 3.18.3 OK, perhaps I should have reported this when it happened, but I thought it was the notebook/me/the dog causing it. I applied the changes from here: http://cgit.freedesktop.org/drm-intel/patch/?id=d472fcc8379c062bd56a3876fc6ef22258f14a91 albeit on different code lines on 3.18.3 and all is hunky dory again using driver sna! Greg, me thinks this should go in next -stable. Thanks! Nick -- A bug in the code is worth two in the documentation. http://linicks.net/ http://slackpi.linicks.net/ http://fishpi.linicks.net/ -- 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/
[QUESTION] Unnamed syslog kernel logs
Hello developers, Not being very familiar with kernel debugging, I have a question about strange syslogs. History: I have been trying to tie-down a strange problem on my headless AMD64 box - it occasionally just turns-off if just as if the power supply is cut. It can happen anywhere between 2 months or 2 days - just intermittent. Analysing logs (which when this occurs they do not report anything), I noticed this in syslog (typical): Dec 28 09:37:19 sauron kernel: ACPI: PCI Interrupt Link [APCL] enabled at IRQ 22 Dec 28 09:37:19 sauron kernel: ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16 Dec 28 09:37:19 sauron kernel: 1030 Dec 28 09:37:19 sauron kernel: 0200 Dec 28 09:37:19 sauron kernel: 0110 Dec 28 09:37:19 sauron kernel: 0111 Dec 28 09:37:19 sauron kernel: 0113 Dec 28 09:37:19 sauron kernel: 0362 Dec 28 09:37:19 sauron kernel: ACPI: PCI Interrupt Link [APSI] enabled at IRQ 21 Dec 28 09:37:19 sauron kernel: ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 20 I don't understand what the middle lines are telling me here? Anyway, today I took the machine down, and removed ram a module (as I found it's sister slot was bad) and also the graphics card as I don't use it. Now when I boot, these mysterious line have vanished from syslog: ec 29 13:05:49 sauron kernel: ACPI: Enabled 1 GPEs in block 00 to 1F Dec 29 13:05:49 sauron kernel: ACPI: PCI Interrupt Link [APCF] enabled at IRQ 23 Dec 29 13:05:49 sauron kernel: ACPI: PCI Interrupt Link [APCL] enabled at IRQ 22 Dec 29 13:05:49 sauron kernel: ACPI: PCI Interrupt Link [APSI] enabled at IRQ 21 Dec 29 13:05:49 sauron kernel: ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 20 Dec 29 13:05:49 sauron kernel: ACPI: PCI Interrupt Link [APCH] enabled at IRQ 23 is all I get now in that section. Was the kernel attempting to tell me something was bad with them funny unnamed lines? Thanks for any help, Regards, Nick -- "A bug in the code is worth two in the documentation." http://linicks.net/ http://slackpi.linicks.net/ -- 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/
[QUESTION] Unnamed syslog kernel logs
Hello developers, Not being very familiar with kernel debugging, I have a question about strange syslogs. History: I have been trying to tie-down a strange problem on my headless AMD64 box - it occasionally just turns-off if just as if the power supply is cut. It can happen anywhere between 2 months or 2 days - just intermittent. Analysing logs (which when this occurs they do not report anything), I noticed this in syslog (typical): Dec 28 09:37:19 sauron kernel: ACPI: PCI Interrupt Link [APCL] enabled at IRQ 22 Dec 28 09:37:19 sauron kernel: ACPI: PCI Interrupt Link [APC5] enabled at IRQ 16 Dec 28 09:37:19 sauron kernel: 1030 Dec 28 09:37:19 sauron kernel: 0200 Dec 28 09:37:19 sauron kernel: 0110 Dec 28 09:37:19 sauron kernel: 0111 Dec 28 09:37:19 sauron kernel: 0113 Dec 28 09:37:19 sauron kernel: 0362 Dec 28 09:37:19 sauron kernel: ACPI: PCI Interrupt Link [APSI] enabled at IRQ 21 Dec 28 09:37:19 sauron kernel: ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 20 I don't understand what the middle lines are telling me here? Anyway, today I took the machine down, and removed ram a module (as I found it's sister slot was bad) and also the graphics card as I don't use it. Now when I boot, these mysterious line have vanished from syslog: ec 29 13:05:49 sauron kernel: ACPI: Enabled 1 GPEs in block 00 to 1F Dec 29 13:05:49 sauron kernel: ACPI: PCI Interrupt Link [APCF] enabled at IRQ 23 Dec 29 13:05:49 sauron kernel: ACPI: PCI Interrupt Link [APCL] enabled at IRQ 22 Dec 29 13:05:49 sauron kernel: ACPI: PCI Interrupt Link [APSI] enabled at IRQ 21 Dec 29 13:05:49 sauron kernel: ACPI: PCI Interrupt Link [APSJ] enabled at IRQ 20 Dec 29 13:05:49 sauron kernel: ACPI: PCI Interrupt Link [APCH] enabled at IRQ 23 is all I get now in that section. Was the kernel attempting to tell me something was bad with them funny unnamed lines? Thanks for any help, Regards, Nick -- A bug in the code is worth two in the documentation. http://linicks.net/ http://slackpi.linicks.net/ -- 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: 3.15.2 build error on AMD64
On 30/06/14 14:26, Borislav Petkov wrote: On Sun, Jun 29, 2014 at 11:24:23PM +0200, Borislav Petkov wrote: Btw, I thought you had that gcc 4.2.x from some distro or so. Because if it is in some ancient distro, one could install it in kvm and test and play with it. Ok, I did dig out an ancient debian I had lying around here with gcc 4.1.2. The patch I pointed you at does really fix the issue. So all is fine and solved now. :-) Ummm, interesting. But is it solved? Suppose developer a.n.other submits a patch that works with his/her GCC version but doesn't with some other GCC version. I guess this will be picked up in GIT build tests, but that only then tells everybody to upgrade GCC or find a patch that fixes the issue (like you did, but I couldn't find it). Is there a document or something that stipulates what is the minimum version[s] of GCC to build a particular version of the kernel? If not, perhaps this is something that needs addressing. Nick -- "A bug in the code is worth two in the documentation." FSF Associate Member 5508 http://linicks.net/ http://pi.linicks.net/ -- 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: 3.15.2 build error on AMD64
On 30/06/14 14:26, Borislav Petkov wrote: On Sun, Jun 29, 2014 at 11:24:23PM +0200, Borislav Petkov wrote: Btw, I thought you had that gcc 4.2.x from some distro or so. Because if it is in some ancient distro, one could install it in kvm and test and play with it. Ok, I did dig out an ancient debian I had lying around here with gcc 4.1.2. The patch I pointed you at does really fix the issue. So all is fine and solved now. :-) Ummm, interesting. But is it solved? Suppose developer a.n.other submits a patch that works with his/her GCC version but doesn't with some other GCC version. I guess this will be picked up in GIT build tests, but that only then tells everybody to upgrade GCC or find a patch that fixes the issue (like you did, but I couldn't find it). Is there a document or something that stipulates what is the minimum version[s] of GCC to build a particular version of the kernel? If not, perhaps this is something that needs addressing. Nick -- A bug in the code is worth two in the documentation. FSF Associate Member 5508 http://linicks.net/ http://pi.linicks.net/ -- 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: 3.15.2 build error on AMD64
On 29/06/14 20:44, Borislav Petkov wrote:
This then is an old(er) version of GCC issue (but I dunno what).
Right, so the error points at
__spin_lock_mb_cache_entry(struct mb_cache_entry *ce)
{
spin_lock(bgl_lock_ptr(mb_cache_bg_lock, <---
(hash_64((unsigned long)ce, __builtin_log2(8);
}
somewhere here and I'd guess that old gcc is issuing some lib function
which uses SSE. And after we disabled all FPU stuff in the kernel with
b399fe355b30 ("x86: Disable generation of traditional x87 instructions")
that would issue such an error.
And I was about to point at that __builtin_log2 thing which looked
suspicious and found this by chance:
http://lkml.kernel.org/r/1401471304-37479-1-git-send-email-t...@hp.com
You could test this patch with that old gcc 4.2.x as it looks like a
good candidate for a fix for your issue.
Thanks Boris, but unfortunately I had to trash GCC 4.2.4 to build the
new 4.7.4 version - so I can't test the patch :(
At least this issue is now on record so others will not need to go to
penalties.
Many thanks,
Nick
--
"A bug in the code is worth two in the documentation."
FSF Associate Member 5508
http://linicks.net/
http://pi.linicks.net/
--
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: 3.15.2 build error on AMD64
On 28/06/14 14:09, Nick Warne wrote: On 28/06/14 13:23, Borislav Petkov wrote: On Sat, Jun 28, 2014 at 11:55:07AM +0100, Nick Warne wrote: Whoops - that is WRONG (too many ssh terminals) gcc version 4.2.4 That's some old compiler. Anyway, I can't trigger it here with gcc 4.6 and 4.9. Can you do $ make clean $ make V=1 fs/mbcache.i >>w.log 2>&1 $ make V=1 fs/mbcache.s >>w.log 2>&1 and zip and send me fs/mbcache.i, fs/mbcache.s and w.log. OK, fs/mbcache.s didn't appear. logs attached. OK, I just spent three months building GCC 4.7.4 today (thank god the world cup is on to watch instead) and 3.15.2 built fine, and server is up and running great. This then is an old(er) version of GCC issue (but I dunno what). Sorry for the noise and thanks. Nick -- "A bug in the code is worth two in the documentation." FSF Associate Member 5508 http://linicks.net/ http://pi.linicks.net/ -- 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: 3.15.2 build error on AMD64
On 28/06/14 14:09, Nick Warne wrote: On 28/06/14 13:23, Borislav Petkov wrote: On Sat, Jun 28, 2014 at 11:55:07AM +0100, Nick Warne wrote: Whoops - that is WRONG (too many ssh terminals) gcc version 4.2.4 That's some old compiler. Anyway, I can't trigger it here with gcc 4.6 and 4.9. Can you do $ make clean $ make V=1 fs/mbcache.i w.log 21 $ make V=1 fs/mbcache.s w.log 21 and zip and send me fs/mbcache.i, fs/mbcache.s and w.log. OK, fs/mbcache.s didn't appear. logs attached. OK, I just spent three months building GCC 4.7.4 today (thank god the world cup is on to watch instead) and 3.15.2 built fine, and server is up and running great. This then is an old(er) version of GCC issue (but I dunno what). Sorry for the noise and thanks. Nick -- A bug in the code is worth two in the documentation. FSF Associate Member 5508 http://linicks.net/ http://pi.linicks.net/ -- 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: 3.15.2 build error on AMD64
On 29/06/14 20:44, Borislav Petkov wrote:
This then is an old(er) version of GCC issue (but I dunno what).
Right, so the error points at
__spin_lock_mb_cache_entry(struct mb_cache_entry *ce)
{
spin_lock(bgl_lock_ptr(mb_cache_bg_lock, ---
(hash_64((unsigned long)ce, __builtin_log2(8);
}
somewhere here and I'd guess that old gcc is issuing some lib function
which uses SSE. And after we disabled all FPU stuff in the kernel with
b399fe355b30 (x86: Disable generation of traditional x87 instructions)
that would issue such an error.
And I was about to point at that __builtin_log2 thing which looked
suspicious and found this by chance:
http://lkml.kernel.org/r/1401471304-37479-1-git-send-email-t...@hp.com
You could test this patch with that old gcc 4.2.x as it looks like a
good candidate for a fix for your issue.
Thanks Boris, but unfortunately I had to trash GCC 4.2.4 to build the
new 4.7.4 version - so I can't test the patch :(
At least this issue is now on record so others will not need to go to
penalties.
Many thanks,
Nick
--
A bug in the code is worth two in the documentation.
FSF Associate Member 5508
http://linicks.net/
http://pi.linicks.net/
--
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: 3.15.2 build error on AMD64
On 28/06/14 11:26, Nick Warne wrote: On 28/06/14 11:12, Borislav Petkov wrote: On Sat, Jun 28, 2014 at 10:52:24AM +0100, Nick Warne wrote: Hi Everybody, Today I was trying to build 3.15.2 on AMD64 from kernel 3.14.8 and get this: CC fs/mbcache.o fs/mbcache.c: In function ‘__spin_lock_mb_cache_entry’: fs/mbcache.c:134: error: SSE register return with SSE disabled make[1]: *** [fs/mbcache.o] Error 1 I can't trigger that here. Please send your .config. Also, before building, did you clean up your source tree properly by saving the .config somewhere else and doing "make mrproper"? Thanks for prompt reply. I always do a mrproper followed by grabbing current .config from /proc and issuing make oldconfig. Attached is my config file. Also, for what it is worth: gcc version 4.8.2 (GCC) Whoops - that is WRONG (too many ssh terminals) gcc version 4.2.4 Nick -- "A bug in the code is worth two in the documentation." FSF Associate Member 5508 http://linicks.net/ http://pi.linicks.net/ -- 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/
3.15.2 build error on AMD64
Hi Everybody, Today I was trying to build 3.15.2 on AMD64 from kernel 3.14.8 and get this: CC fs/mbcache.o fs/mbcache.c: In function ‘__spin_lock_mb_cache_entry’: fs/mbcache.c:134: error: SSE register return with SSE disabled make[1]: *** [fs/mbcache.o] Error 1 google doesn't reveal much except that floating point shouldn't be used in the kernel, but I am not experienced enough to see how or what is going on here. Any help appreciated. Please cc me. Nick -- "A bug in the code is worth two in the documentation." FSF Associate Member 5508 http://linicks.net/ http://pi.linicks.net/ -- 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/
3.15.2 build error on AMD64
Hi Everybody, Today I was trying to build 3.15.2 on AMD64 from kernel 3.14.8 and get this: CC fs/mbcache.o fs/mbcache.c: In function ‘__spin_lock_mb_cache_entry’: fs/mbcache.c:134: error: SSE register return with SSE disabled make[1]: *** [fs/mbcache.o] Error 1 google doesn't reveal much except that floating point shouldn't be used in the kernel, but I am not experienced enough to see how or what is going on here. Any help appreciated. Please cc me. Nick -- A bug in the code is worth two in the documentation. FSF Associate Member 5508 http://linicks.net/ http://pi.linicks.net/ -- 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: 3.15.2 build error on AMD64
On 28/06/14 11:26, Nick Warne wrote: On 28/06/14 11:12, Borislav Petkov wrote: On Sat, Jun 28, 2014 at 10:52:24AM +0100, Nick Warne wrote: Hi Everybody, Today I was trying to build 3.15.2 on AMD64 from kernel 3.14.8 and get this: CC fs/mbcache.o fs/mbcache.c: In function ‘__spin_lock_mb_cache_entry’: fs/mbcache.c:134: error: SSE register return with SSE disabled make[1]: *** [fs/mbcache.o] Error 1 I can't trigger that here. Please send your .config. Also, before building, did you clean up your source tree properly by saving the .config somewhere else and doing make mrproper? Thanks for prompt reply. I always do a mrproper followed by grabbing current .config from /proc and issuing make oldconfig. Attached is my config file. Also, for what it is worth: gcc version 4.8.2 (GCC) Whoops - that is WRONG (too many ssh terminals) gcc version 4.2.4 Nick -- A bug in the code is worth two in the documentation. FSF Associate Member 5508 http://linicks.net/ http://pi.linicks.net/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.14.5
On 01/06/14 13:04, Nick Warne wrote: I am getting hundreds of the same build warnings on this release - usually I get none - typical warnings: include/linux/sched.h:1691: warning: ‘pid_alive’ declared inline after being called include/linux/sched.h:1691: warning: previous declaration of ‘pid_alive’ was here Info: Machine AMD64 gcc version 4.2.4 Any more info required please CC me. OK, revisiting this between decorating, changing line 1691 in include/linux/sched.h to reflect 'inline': from: static int pid_alive(const struct task_struct *p); to: static inline int pid_alive(const struct task_struct *p); stops GCC yelling at me. Nick -- "A bug in the code is worth two in the documentation." FSF Associate Member 5508 http://linicks.net/ http://pi.linicks.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.14.5
I am getting hundreds of the same build warnings on this release - usually I get none - typical warnings: include/linux/sched.h:1691: warning: ‘pid_alive’ declared inline after being called include/linux/sched.h:1691: warning: previous declaration of ‘pid_alive’ was here Info: Machine AMD64 gcc version 4.2.4 Any more info required please CC me. Nick -- "A bug in the code is worth two in the documentation." FSF Associate Member 5508 http://linicks.net/ http://pi.linicks.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.14.5
I am getting hundreds of the same build warnings on this release - usually I get none - typical warnings: include/linux/sched.h:1691: warning: ‘pid_alive’ declared inline after being called include/linux/sched.h:1691: warning: previous declaration of ‘pid_alive’ was here Info: Machine AMD64 gcc version 4.2.4 Any more info required please CC me. Nick -- A bug in the code is worth two in the documentation. FSF Associate Member 5508 http://linicks.net/ http://pi.linicks.net/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.14.5
On 01/06/14 13:04, Nick Warne wrote: I am getting hundreds of the same build warnings on this release - usually I get none - typical warnings: include/linux/sched.h:1691: warning: ‘pid_alive’ declared inline after being called include/linux/sched.h:1691: warning: previous declaration of ‘pid_alive’ was here Info: Machine AMD64 gcc version 4.2.4 Any more info required please CC me. OK, revisiting this between decorating, changing line 1691 in include/linux/sched.h to reflect 'inline': from: static int pid_alive(const struct task_struct *p); to: static inline int pid_alive(const struct task_struct *p); stops GCC yelling at me. Nick -- A bug in the code is worth two in the documentation. FSF Associate Member 5508 http://linicks.net/ http://pi.linicks.net/ -- 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/
[RFC] Rollback FS
Hi, > Recently, I just do some stupid stuffs as follows. > > # mv /lib/x86_64-linux-gnu/libc.so.6 /tmp > > After move "/lib/x86_64-linux-gnu/libc.so.6" away, you could not run lots > of commands, which show you some errors like this. > > # ls > ls: error while loading shared libraries: libc.so.6: cannot open > shared object file: No such file or directory > # mv > mv: error while loading shared libraries: libc.so.6: cannot open > shared object file: No such file or directory Well we all do stupid things sometimes... I done similar to you once, but copied (and overwrote) a different version trying to fix something... /sbin/sln is your friend (if you don't panic when it happens). No need for a large vfs to monitor user errors like this. /sbin/sln is a statically built ln, so you can symlink back the file to get userspace going, then copy the file (fix it) back properly. Nick -- FSF Associate Member 5508 http://linicks.net/ -- 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/
[RFC] Rollback FS
Hi, Recently, I just do some stupid stuffs as follows. # mv /lib/x86_64-linux-gnu/libc.so.6 /tmp After move /lib/x86_64-linux-gnu/libc.so.6 away, you could not run lots of commands, which show you some errors like this. # ls ls: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory # mv mv: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory Well we all do stupid things sometimes... I done similar to you once, but copied (and overwrote) a different version trying to fix something... /sbin/sln is your friend (if you don't panic when it happens). No need for a large vfs to monitor user errors like this. /sbin/sln is a statically built ln, so you can symlink back the file to get userspace going, then copy the file (fix it) back properly. Nick -- FSF Associate Member 5508 http://linicks.net/ -- 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: Samsung N145 Plus lid state issue on sleep
On Sat, Sep 28, 2013 at 10:14:26PM +0100, Nick Warne wrote: > On Thu, Sep 26, 2013 at 06:25:00PM +0100, Nick Warne wrote: > > Hi all, > > > > I have a strange problem, which has been on going on for ages, and I > > finally decided to look at it (as it is a pain in the arse). > > > > Brief details: > > > > Samsung N145 Plus running Slack 14 with handbuilt kernel > > Kernel: Linux 3.11.1 #3 SMP Mon Sep 23 19:09:00 BST 2013 i686 Intel(R) > > Atom(TM) CPU N455 @ 1.66GHz GenuineIntel GNU/Linux > > I have no modules built in (.config on request if it helps). > > > > This issue also happened with 'distro' kernel builds... so either it is > > BIOS issue or hardware fault. But just in case: > > > > Boot laptop into console - no X - so running pure acpi events. > > > > cat /proc/acpi/button/lid/LID0/state > > state: open > > > > shut lid > > > > laptop goes to sleep all great. > > > > open lid. Laptop wakes up, video, wlan0 all comes on line, everything > > hunky dory - but: > > > > cat /proc/acpi/button/lid/LID0/state > > state: closed > > > > The lid is open, of course! > > > > OK, shut lid. LCD backlight goes off (so something knows the lid is shut), > > but no sleep event. Open lid after a few seconds (maybe 10), and screen > > lights up and then laptop goes to sleep! > > > > Shut lid (wait for a few seconds), open lid, laptop wakes up fine again, > > and now: > > > > cat /proc/acpi/button/lid/LID0/state > > state: open > > > > ! > > > > So it appears that closing lid flags 'closed' state but opening it doesn't > > flag 'open' state... unless I then close it again and open which then flags > > 'closed' state when open so goes to sleep. So no open it again, and 'state > > now reports 'open' again. At this point, back to square one (confused? I > > am!). > > > > Using Fn [sleep] in any mode above works OK. The same happens in X using > > xfce4 PM or similar. > > > > What is confusing me is that something can see the lid flapping as > > backlight works on lid open/close. > > > > acpi_listen reports the events as described above, but I can't work out how > > to record the events when a sleep :) > > > > And ideas/help etc. appreciated, and also I am in the position to be able > > to debug (with help, of course)! > > OK, doing a lot of research, it appears the dsdt is well fubarred. > > I have now managed to get a clean build of the extracted dsdt, and testing > with various (LIDS) stuff in the code it seems that something is drastically > wrong. > > Anyhow, I have now got a decent working dsdt that at least sleeps everytime > on lid close - although it then goes to sleep again after lid is open, but I > can handle that (reverse of my original problem, almost, but at least lid > close makes it sleep 100%). > > Sleep button (Fn Esc) works as it should. > > Anybody good at asl coding? There is some thing obvioulsy wrong with the > logic in this code. OK, I have hung myself. Even finding this bug report, and shipping off a quick mail, deadly, spookily all quiet on the DSDT front. https://bugzilla.kernel.org/show_bug.cgi?id=17081 So for googlers everywhere, I have at least got a dirty hack: http://www.linicks.net/dsdt/ It's not right, nor even wrong, but at least it works (sorta). Nick -- FSF Associate Member 5508 http://linicks.net/ -- 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: Samsung N145 Plus lid state issue on sleep
On Sat, Sep 28, 2013 at 10:14:26PM +0100, Nick Warne wrote: On Thu, Sep 26, 2013 at 06:25:00PM +0100, Nick Warne wrote: Hi all, I have a strange problem, which has been on going on for ages, and I finally decided to look at it (as it is a pain in the arse). Brief details: Samsung N145 Plus running Slack 14 with handbuilt kernel Kernel: Linux 3.11.1 #3 SMP Mon Sep 23 19:09:00 BST 2013 i686 Intel(R) Atom(TM) CPU N455 @ 1.66GHz GenuineIntel GNU/Linux I have no modules built in (.config on request if it helps). This issue also happened with 'distro' kernel builds... so either it is BIOS issue or hardware fault. But just in case: Boot laptop into console - no X - so running pure acpi events. cat /proc/acpi/button/lid/LID0/state state: open shut lid laptop goes to sleep all great. open lid. Laptop wakes up, video, wlan0 all comes on line, everything hunky dory - but: cat /proc/acpi/button/lid/LID0/state state: closed The lid is open, of course! OK, shut lid. LCD backlight goes off (so something knows the lid is shut), but no sleep event. Open lid after a few seconds (maybe 10), and screen lights up and then laptop goes to sleep! Shut lid (wait for a few seconds), open lid, laptop wakes up fine again, and now: cat /proc/acpi/button/lid/LID0/state state: open ! So it appears that closing lid flags 'closed' state but opening it doesn't flag 'open' state... unless I then close it again and open which then flags 'closed' state when open so goes to sleep. So no open it again, and 'state now reports 'open' again. At this point, back to square one (confused? I am!). Using Fn [sleep] in any mode above works OK. The same happens in X using xfce4 PM or similar. What is confusing me is that something can see the lid flapping as backlight works on lid open/close. acpi_listen reports the events as described above, but I can't work out how to record the events when a sleep :) And ideas/help etc. appreciated, and also I am in the position to be able to debug (with help, of course)! OK, doing a lot of research, it appears the dsdt is well fubarred. I have now managed to get a clean build of the extracted dsdt, and testing with various (LIDS) stuff in the code it seems that something is drastically wrong. Anyhow, I have now got a decent working dsdt that at least sleeps everytime on lid close - although it then goes to sleep again after lid is open, but I can handle that (reverse of my original problem, almost, but at least lid close makes it sleep 100%). Sleep button (Fn Esc) works as it should. Anybody good at asl coding? There is some thing obvioulsy wrong with the logic in this code. OK, I have hung myself. Even finding this bug report, and shipping off a quick mail, deadly, spookily all quiet on the DSDT front. https://bugzilla.kernel.org/show_bug.cgi?id=17081 So for googlers everywhere, I have at least got a dirty hack: http://www.linicks.net/dsdt/ It's not right, nor even wrong, but at least it works (sorta). Nick -- FSF Associate Member 5508 http://linicks.net/ -- 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: Samsung N145 Plus lid state issue on sleep
On Thu, Sep 26, 2013 at 06:25:00PM +0100, Nick Warne wrote: > Hi all, > > I have a strange problem, which has been on going on for ages, and I finally > decided to look at it (as it is a pain in the arse). > > Brief details: > > Samsung N145 Plus running Slack 14 with handbuilt kernel > Kernel: Linux 3.11.1 #3 SMP Mon Sep 23 19:09:00 BST 2013 i686 Intel(R) > Atom(TM) CPU N455 @ 1.66GHz GenuineIntel GNU/Linux > I have no modules built in (.config on request if it helps). > > This issue also happened with 'distro' kernel builds... so either it is BIOS > issue or hardware fault. But just in case: > > Boot laptop into console - no X - so running pure acpi events. > > cat /proc/acpi/button/lid/LID0/state > state: open > > shut lid > > laptop goes to sleep all great. > > open lid. Laptop wakes up, video, wlan0 all comes on line, everything hunky > dory - but: > > cat /proc/acpi/button/lid/LID0/state > state: closed > > The lid is open, of course! > > OK, shut lid. LCD backlight goes off (so something knows the lid is shut), > but no sleep event. Open lid after a few seconds (maybe 10), and screen > lights up and then laptop goes to sleep! > > Shut lid (wait for a few seconds), open lid, laptop wakes up fine again, and > now: > > cat /proc/acpi/button/lid/LID0/state > state: open > > ! > > So it appears that closing lid flags 'closed' state but opening it doesn't > flag 'open' state... unless I then close it again and open which then flags > 'closed' state when open so goes to sleep. So no open it again, and 'state > now reports 'open' again. At this point, back to square one (confused? I > am!). > > Using Fn [sleep] in any mode above works OK. The same happens in X using > xfce4 PM or similar. > > What is confusing me is that something can see the lid flapping as backlight > works on lid open/close. > > acpi_listen reports the events as described above, but I can't work out how > to record the events when a sleep :) > > And ideas/help etc. appreciated, and also I am in the position to be able to > debug (with help, of course)! OK, doing a lot of research, it appears the dsdt is well fubarred. I have now managed to get a clean build of the extracted dsdt, and testing with various (LIDS) stuff in the code it seems that something is drastically wrong. Anyhow, I have now got a decent working dsdt that at least sleeps everytime on lid close - although it then goes to sleep again after lid is open, but I can handle that (reverse of my original problem, almost, but at least lid close makes it sleep 100%). Sleep button (Fn Esc) works as it should. Anybody good at asl coding? There is some thing obvioulsy wrong with the logic in this code. Nick -- FSF Associate Member 5508 http://linicks.net/ -- 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: Samsung N145 Plus lid state issue on sleep
On Thu, Sep 26, 2013 at 06:25:00PM +0100, Nick Warne wrote: Hi all, I have a strange problem, which has been on going on for ages, and I finally decided to look at it (as it is a pain in the arse). Brief details: Samsung N145 Plus running Slack 14 with handbuilt kernel Kernel: Linux 3.11.1 #3 SMP Mon Sep 23 19:09:00 BST 2013 i686 Intel(R) Atom(TM) CPU N455 @ 1.66GHz GenuineIntel GNU/Linux I have no modules built in (.config on request if it helps). This issue also happened with 'distro' kernel builds... so either it is BIOS issue or hardware fault. But just in case: Boot laptop into console - no X - so running pure acpi events. cat /proc/acpi/button/lid/LID0/state state: open shut lid laptop goes to sleep all great. open lid. Laptop wakes up, video, wlan0 all comes on line, everything hunky dory - but: cat /proc/acpi/button/lid/LID0/state state: closed The lid is open, of course! OK, shut lid. LCD backlight goes off (so something knows the lid is shut), but no sleep event. Open lid after a few seconds (maybe 10), and screen lights up and then laptop goes to sleep! Shut lid (wait for a few seconds), open lid, laptop wakes up fine again, and now: cat /proc/acpi/button/lid/LID0/state state: open ! So it appears that closing lid flags 'closed' state but opening it doesn't flag 'open' state... unless I then close it again and open which then flags 'closed' state when open so goes to sleep. So no open it again, and 'state now reports 'open' again. At this point, back to square one (confused? I am!). Using Fn [sleep] in any mode above works OK. The same happens in X using xfce4 PM or similar. What is confusing me is that something can see the lid flapping as backlight works on lid open/close. acpi_listen reports the events as described above, but I can't work out how to record the events when a sleep :) And ideas/help etc. appreciated, and also I am in the position to be able to debug (with help, of course)! OK, doing a lot of research, it appears the dsdt is well fubarred. I have now managed to get a clean build of the extracted dsdt, and testing with various (LIDS) stuff in the code it seems that something is drastically wrong. Anyhow, I have now got a decent working dsdt that at least sleeps everytime on lid close - although it then goes to sleep again after lid is open, but I can handle that (reverse of my original problem, almost, but at least lid close makes it sleep 100%). Sleep button (Fn Esc) works as it should. Anybody good at asl coding? There is some thing obvioulsy wrong with the logic in this code. Nick -- FSF Associate Member 5508 http://linicks.net/ -- 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/
Samsung N145 Plus lid state issue on sleep
Hi all, I have a strange problem, which has been on going on for ages, and I finally decided to look at it (as it is a pain in the arse). Brief details: Samsung N145 Plus running Slack 14 with handbuilt kernel Kernel: Linux 3.11.1 #3 SMP Mon Sep 23 19:09:00 BST 2013 i686 Intel(R) Atom(TM) CPU N455 @ 1.66GHz GenuineIntel GNU/Linux I have no modules built in (.config on request if it helps). This issue also happened with 'distro' kernel builds... so either it is BIOS issue or hardware fault. But just in case: Boot laptop into console - no X - so running pure acpi events. cat /proc/acpi/button/lid/LID0/state state: open shut lid laptop goes to sleep all great. open lid. Laptop wakes up, video, wlan0 all comes on line, everything hunky dory - but: cat /proc/acpi/button/lid/LID0/state state: closed The lid is open, of course! OK, shut lid. LCD backlight goes off (so something knows the lid is shut), but no sleep event. Open lid after a few seconds (maybe 10), and screen lights up and then laptop goes to sleep! Shut lid (wait for a few seconds), open lid, laptop wakes up fine again, and now: cat /proc/acpi/button/lid/LID0/state state: open ! So it appears that closing lid flags 'closed' state but opening it doesn't flag 'open' state... unless I then close it again and open which then flags 'closed' state when open so goes to sleep. So no open it again, and 'state now reports 'open' again. At this point, back to square one (confused? I am!). Using Fn [sleep] in any mode above works OK. The same happens in X using xfce4 PM or similar. What is confusing me is that something can see the lid flapping as backlight works on lid open/close. acpi_listen reports the events as described above, but I can't work out how to record the events when a sleep :) And ideas/help etc. appreciated, and also I am in the position to be able to debug (with help, of course)! Thanks, Nick -- http://linicks.net/ -- 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/
Samsung N145 Plus lid state issue on sleep
Hi all, I have a strange problem, which has been on going on for ages, and I finally decided to look at it (as it is a pain in the arse). Brief details: Samsung N145 Plus running Slack 14 with handbuilt kernel Kernel: Linux 3.11.1 #3 SMP Mon Sep 23 19:09:00 BST 2013 i686 Intel(R) Atom(TM) CPU N455 @ 1.66GHz GenuineIntel GNU/Linux I have no modules built in (.config on request if it helps). This issue also happened with 'distro' kernel builds... so either it is BIOS issue or hardware fault. But just in case: Boot laptop into console - no X - so running pure acpi events. cat /proc/acpi/button/lid/LID0/state state: open shut lid laptop goes to sleep all great. open lid. Laptop wakes up, video, wlan0 all comes on line, everything hunky dory - but: cat /proc/acpi/button/lid/LID0/state state: closed The lid is open, of course! OK, shut lid. LCD backlight goes off (so something knows the lid is shut), but no sleep event. Open lid after a few seconds (maybe 10), and screen lights up and then laptop goes to sleep! Shut lid (wait for a few seconds), open lid, laptop wakes up fine again, and now: cat /proc/acpi/button/lid/LID0/state state: open ! So it appears that closing lid flags 'closed' state but opening it doesn't flag 'open' state... unless I then close it again and open which then flags 'closed' state when open so goes to sleep. So no open it again, and 'state now reports 'open' again. At this point, back to square one (confused? I am!). Using Fn [sleep] in any mode above works OK. The same happens in X using xfce4 PM or similar. What is confusing me is that something can see the lid flapping as backlight works on lid open/close. acpi_listen reports the events as described above, but I can't work out how to record the events when a sleep :) And ideas/help etc. appreciated, and also I am in the position to be able to debug (with help, of course)! Thanks, Nick -- http://linicks.net/ -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.12-rc2
Hi all, I have couple of build warnings. Not sure if this happened with rc1, as I only have moved across to the rc trees: gcc (GCC) 4.2.4 on amd64 - no modules build: 1) ... GEN lib/crc32table.h CC lib/crc32.o lib/crc32.c: In function ‘crc32_be’: lib/crc32.c:263: warning: passing argument 4 of ‘crc32_be_generic’ from incompatible pointer type lib/crc32.c: In function ‘__crc32c_le’: lib/crc32.c:199: warning: passing argument 4 of ‘crc32_le_generic’ from incompatible pointer type lib/crc32.c: In function ‘crc32_le’: lib/crc32.c:194: warning: passing argument 4 of ‘crc32_le_generic’ from incompatible pointer type CC lib/fonts/fonts.o ... 2) CC lib/radix-tree.o lib/radix-tree.c: In function ‘radix_tree_next_chunk’: lib/radix-tree.c:805: warning: comparison is always false due to limited range of data type CC lib/ratelimit.o ... Nick -- http://linicks.net/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 3.12-rc2
Hi all, I have couple of build warnings. Not sure if this happened with rc1, as I only have moved across to the rc trees: gcc (GCC) 4.2.4 on amd64 - no modules build: 1) ... GEN lib/crc32table.h CC lib/crc32.o lib/crc32.c: In function ‘crc32_be’: lib/crc32.c:263: warning: passing argument 4 of ‘crc32_be_generic’ from incompatible pointer type lib/crc32.c: In function ‘__crc32c_le’: lib/crc32.c:199: warning: passing argument 4 of ‘crc32_le_generic’ from incompatible pointer type lib/crc32.c: In function ‘crc32_le’: lib/crc32.c:194: warning: passing argument 4 of ‘crc32_le_generic’ from incompatible pointer type CC lib/fonts/fonts.o ... 2) CC lib/radix-tree.o lib/radix-tree.c: In function ‘radix_tree_next_chunk’: lib/radix-tree.c:805: warning: comparison is always false due to limited range of data type CC lib/ratelimit.o ... Nick -- http://linicks.net/ -- 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/
IGNORE_THIS Re: Samsung laptop - missing documentation
On Sun, Sep 22, 2013 at 11:40:23AM +0100, Nick Warne wrote: > running 3.11.12-rc1, config help refers: Errr 3.12-rc1 And it's there anyway - my FAULT Sorry for the noise. > Documentation/ABI/testing/sysfs-driver-samsung-laptop > > But this is now missing - by design? but I can't find any patch that removed > it. Nick -- http://linicks.net/ -- 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/
Samsung laptop - missing documentation
running 3.11.12-rc1, config help refers: Documentation/ABI/testing/sysfs-driver-samsung-laptop But this is now missing - by design? but I can't find any patch that removed it. Nick -- http://linicks.net/ -- 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/
Samsung laptop - missing documentation
running 3.11.12-rc1, config help refers: Documentation/ABI/testing/sysfs-driver-samsung-laptop But this is now missing - by design? but I can't find any patch that removed it. Nick -- http://linicks.net/ -- 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/
IGNORE_THIS Re: Samsung laptop - missing documentation
On Sun, Sep 22, 2013 at 11:40:23AM +0100, Nick Warne wrote: running 3.11.12-rc1, config help refers: Errr 3.12-rc1 And it's there anyway - my FAULT Sorry for the noise. Documentation/ABI/testing/sysfs-driver-samsung-laptop But this is now missing - by design? but I can't find any patch that removed it. Nick -- http://linicks.net/ -- 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/
[PATCH] Correct wording in config COMPILE_TEST
Hi All, A small patch to correct English grammar usage. Signed-off-by: Nick Warne --- linux-3.12-rc1/init/Kconfig 2013-09-16 21:17:51.0 +0100 +++ linux-3.12-rc1/init/Kconfignew 2013-09-20 20:46:57.730316831 +0100 @@ -54,18 +54,19 @@ directory to select the cross-compiler automatically. config COMPILE_TEST - bool "Compile also drivers which will not load" + bool "Also build drivers which will not load on this platform" default n help Some drivers can be compiled on a different platform than they are - intended to be run on. Despite they cannot be loaded there (or even - when they load they cannot be used due to missing HW support), - developers still, opposing to distributors, might want to build such - drivers to compile-test them. + intended to be run on. Despite the fact they cannot be loaded (or + even when they load they cannot be used due to missing HW + support etc.), developers, differing from distributors, may need + to build such drivers to compile-test them. If you are a developer and want to build everything available, say Y here. If you are a user/distributor, say N here to exclude useless - drivers to be distributed. + drivers to be distributed. (P.S. no drivers are useless unless you + need them for testing). config LOCALVERSION string "Local version - append to kernel release" Nick -- http://linicks.net/ -- 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/
[PATCH] Correct wording in config COMPILE_TEST
Hi All, A small patch to correct English grammar usage. Signed-off-by: Nick Warne n...@linicks.net --- linux-3.12-rc1/init/Kconfig 2013-09-16 21:17:51.0 +0100 +++ linux-3.12-rc1/init/Kconfignew 2013-09-20 20:46:57.730316831 +0100 @@ -54,18 +54,19 @@ directory to select the cross-compiler automatically. config COMPILE_TEST - bool Compile also drivers which will not load + bool Also build drivers which will not load on this platform default n help Some drivers can be compiled on a different platform than they are - intended to be run on. Despite they cannot be loaded there (or even - when they load they cannot be used due to missing HW support), - developers still, opposing to distributors, might want to build such - drivers to compile-test them. + intended to be run on. Despite the fact they cannot be loaded (or + even when they load they cannot be used due to missing HW + support etc.), developers, differing from distributors, may need + to build such drivers to compile-test them. If you are a developer and want to build everything available, say Y here. If you are a user/distributor, say N here to exclude useless - drivers to be distributed. + drivers to be distributed. (P.S. no drivers are useless unless you + need them for testing). config LOCALVERSION string Local version - append to kernel release Nick -- http://linicks.net/ -- 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: Driver 'sd' needs updating
On Thu, 10 Jan 2008 12:27:22 -0600 James Bottomley <[EMAIL PROTECTED]> wrote: > > > OK, updated to git rc7 yesterday - I now see this in syslog: > >"Driver 'sd' needs updating - please use bus_type methods" > > > > Do I need to fix up something here? > > > > No, you don't. It's harmless, a side effect of: > > > > commit 751bf4d7865e4ced406be93b04c7436d866d3684 > > Author: James Bottomley <[EMAIL PROTECTED]> > > Date: Wed Jan 2 11:14:30 2008 -0600 > > > > [SCSI] scsi_sysfs: restore prep_fn when ULD is removed > > > > > > It would be better to silence this warning. > > > > James, we need to reset prep_fn in each ULD? though it's not nice... > > Really not nice ... to the extent that we shouldn't do it. The reset > is in exactly the correct place currently. If we make it a > requirement of the ULDs its duplication and someone is bound to > forget. > > It looks like the problem is the warning in > base/driver.c:driver_register() apparently it wants an either/or for > ->remove methods (either bus type or driver). We're actually using > the bus_type methods, but we also have a driver component, sigh. I > suppose what it's wanting is for me to add a scsi_driver type with > remove methods ... which looks a bit silly since all of the SCSI > drivers want different remove methods. OK, actually, this is wierd for me now. Is this warning ONLY generated on modules? I build with no modules, but do have modules enabled due to nVidia. I did post about a module called 'scsi_wait' being built, even though I didn't want it/need it but can't stop it - please refer: http://marc.info/?t=11970549357=1=2 If this is true, what I have now is a module being built I don't want/need and can't stop it being built, and a warning about it not using bus_type methods anyway. Nick -- Free Software Foundation Associate Member 5508 -- 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: Driver 'sd' needs updating
On Thu, 10 Jan 2008 20:38:45 +0900 FUJITA Tomonori <[EMAIL PROTECTED]> wrote: > >"Driver 'sd' needs updating - please use bus_type methods" > > > > The warning never appeared in RC6, and all google reveals are other > > peoples logs that are posted about other issues. > > > > Do I need to fix up something here? > > No, you don't. It's harmless, a side effect of: > > commit 751bf4d7865e4ced406be93b04c7436d866d3684 > Author: James Bottomley <[EMAIL PROTECTED]> > Date: Wed Jan 2 11:14:30 2008 -0600 > > [SCSI] scsi_sysfs: restore prep_fn when ULD is removed Ah, I see. Thanks for clarification. Nick -- Free Software Foundation Associate Member 5508 -- 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/
Driver 'sd' needs updating
Hi everybody - Happy New Year to you all! OK, updated to git rc7 yesterday - I now see this in syslog: "Driver 'sd' needs updating - please use bus_type methods" The warning never appeared in RC6, and all google reveals are other peoples logs that are posted about other issues. Do I need to fix up something here? Thanks, Nick -- Free Software Foundation Associate Member 5508 -- 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/
Driver 'sd' needs updating
Hi everybody - Happy New Year to you all! OK, updated to git rc7 yesterday - I now see this in syslog: Driver 'sd' needs updating - please use bus_type methods The warning never appeared in RC6, and all google reveals are other peoples logs that are posted about other issues. Do I need to fix up something here? Thanks, Nick -- Free Software Foundation Associate Member 5508 -- 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: Driver 'sd' needs updating
On Thu, 10 Jan 2008 20:38:45 +0900 FUJITA Tomonori [EMAIL PROTECTED] wrote: Driver 'sd' needs updating - please use bus_type methods The warning never appeared in RC6, and all google reveals are other peoples logs that are posted about other issues. Do I need to fix up something here? No, you don't. It's harmless, a side effect of: commit 751bf4d7865e4ced406be93b04c7436d866d3684 Author: James Bottomley [EMAIL PROTECTED] Date: Wed Jan 2 11:14:30 2008 -0600 [SCSI] scsi_sysfs: restore prep_fn when ULD is removed Ah, I see. Thanks for clarification. Nick -- Free Software Foundation Associate Member 5508 -- 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: Driver 'sd' needs updating
On Thu, 10 Jan 2008 12:27:22 -0600 James Bottomley [EMAIL PROTECTED] wrote: OK, updated to git rc7 yesterday - I now see this in syslog: Driver 'sd' needs updating - please use bus_type methods Do I need to fix up something here? No, you don't. It's harmless, a side effect of: commit 751bf4d7865e4ced406be93b04c7436d866d3684 Author: James Bottomley [EMAIL PROTECTED] Date: Wed Jan 2 11:14:30 2008 -0600 [SCSI] scsi_sysfs: restore prep_fn when ULD is removed It would be better to silence this warning. James, we need to reset prep_fn in each ULD? though it's not nice... Really not nice ... to the extent that we shouldn't do it. The reset is in exactly the correct place currently. If we make it a requirement of the ULDs its duplication and someone is bound to forget. It looks like the problem is the warning in base/driver.c:driver_register() apparently it wants an either/or for -remove methods (either bus type or driver). We're actually using the bus_type methods, but we also have a driver component, sigh. I suppose what it's wanting is for me to add a scsi_driver type with remove methods ... which looks a bit silly since all of the SCSI drivers want different remove methods. OK, actually, this is wierd for me now. Is this warning ONLY generated on modules? I build with no modules, but do have modules enabled due to nVidia. I did post about a module called 'scsi_wait' being built, even though I didn't want it/need it but can't stop it - please refer: http://marc.info/?t=11970549357r=1w=2 If this is true, what I have now is a module being built I don't want/need and can't stop it being built, and a warning about it not using bus_type methods anyway. Nick -- Free Software Foundation Associate Member 5508 -- 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: Peculiar out-of-sync boot log lines
On Sun, 2 Dec 2007 19:30:34 +0100
Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
Hi Bart,
Top posting! g.
This patch works fine on my system with this peculiar DVD drive, and
log reports are perfect.
Updated to Linus' git today - 2.6.24-rc6-g5b825ed2
/var/log/messages:
Dec 23 09:36:04 linuxamd kernel: ide0: BM-DMA at 0xd000-0xd007, BIOS
settings: hda:DMA, hdb:DMA
Dec 23 09:36:04 linuxamd kernel: ide1: BM-DMA at 0xd008-0xd00f, BIOS
settings: hdc:DMA, hdd:DMA
Dec 23 09:36:04 linuxamd kernel: hda: UDMA/66 mode selected
Dec 23 09:36:04 linuxamd kernel: hdb: UDMA/66 mode selected
Dec 23 09:36:04 linuxamd kernel: hdc: UDMA/66 mode selected
Dec 23 09:36:04 linuxamd kernel: hdd: UDMA/66 mode selected
Dec 23 09:36:04 linuxamd kernel: hda: max request size: 128KiB
Dec 23 09:36:04 linuxamd kernel: hda: 160086528 sectors (81964 MB) w/2048KiB
Cache, CHS=65535/16/63
Dec 23 09:36:04 linuxamd kernel: hda: cache flushes supported
Dec 23 09:36:04 linuxamd kernel: hda: hda1 hda2 hda3 hda4
Dec 23 09:36:04 linuxamd kernel: hdb: max request size: 128KiB
Dec 23 09:36:04 linuxamd kernel: hdb: 30015216 sectors (15367 MB) w/2048KiB
Cache, CHS=29777/16/63
Dec 23 09:36:04 linuxamd kernel: hdb: cache flushes not supported
Dec 23 09:36:04 linuxamd kernel: hdb: hdb1
Dec 23 09:36:04 linuxamd kernel: hdc: max request size: 128KiB
Dec 23 09:36:04 linuxamd kernel: hdc: 39876480 sectors (20416 MB) w/2048KiB
Cache, CHS=39560/16/63
Dec 23 09:36:04 linuxamd kernel: hdc: cache flushes not supported
Dec 23 09:36:04 linuxamd kernel: hdc: hdc1
Dec 23 09:36:04 linuxamd kernel: hdd: ATAPI 48X DVD-ROM DVD-R-RAM
CD-R/RW drive, 2048kB Cache
and
/var/log/syslog
Dec 23 09:36:04 linuxamd kernel: hdb: Maxtor 51536H2, ATA DISK drive
Dec 23 09:36:04 linuxamd kernel: hda: Maxtor 6Y080L0, ATA DISK drive
Dec 23 09:36:04 linuxamd kernel: hdd: TSSTcorp CDDVDW SH-S202J, ATAPI
CD/DVD-ROM drive
Dec 23 09:36:04 linuxamd kernel: hdc: Maxtor 52049H3, ATA DISK drive
> On Sunday 02 December 2007, Randy Dunlap wrote:
> > On Sat, 1 Dec 2007 22:59:35 +0100 Bartlomiej Zolnierkiewicz wrote:
> >
> > > Thanks for reporting/debugging it guys!
> > >
> > > > Something in there needs to insert a '\n' before the "skipping
> > > > word" message. Since it doesn't do that right now, the
> > > > KERN_DEBUG string appears as "<7>"
> > >
> > > This seems like a good occasion to fix ide_dma_verbose() for good
> > > so... :)
> > >
> > > [ patch is against current Linus tree so might not apply to
> > > 2.6.23.9 ]
> > >
> > > [PATCH] ide: DMA reporting and validity checking fixes
> > >
> > > * ide_xfer_verbose() fixups:
> > > - beautify returned mode names
> > > - fix PIO5 reporting
> > > - make it return 'const char *'
> > >
> > > * Change printk() level from KERN_DEBUG to KERN_INFO in
> > > ide_find_dma_mode().
> > >
> > > * Add ide_id_dma_bug() helper based on ide_dma_verbose() to check
> > > for invalid DMA info in identify block.
> > >
> > > * Use ide_id_dma_bug() in ide_tune_dma() and ide_driveid_update().
> > >
> > > As a result DMA won't be tuned or will be disabled after tuning
> > > if device reports inconsistent info about enabled DMA mode
> > > (ide_dma_verbose() does the same checks while the IDE device is
> > > probed by ide-{cd,disk} device driver).
> > >
> > > * Since (id->capability & 1) && id->tDMA is a valid configuration
> > > handle it correctly in ide_id_dma_bug().
> > >
> > > * Remove no longer needed ide_dma_verbose().
> > >
> > > This patch should fix the following problem with out-of-sync IDE
> > > messages reported by Nick Warned:
> > >
> > >hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB
> > > Cache<7>hdd: skipping word 93 validity check
> > > , UDMA(66)
> > >
> > > and later debugged by Mark Lord to be caused by:
> > >
> > > ide_dma_verbose()
> > > printk( ... "2048kB Cache");
> > > eighty_ninty_three()
> > > printk(KERN_DEBUG "%s: skipping word 93 validity
> > > check\n"); ide_dma_verbose()
> > > printk(", UDMA(66)"
> > >
> > > Please note that as a result ide-{cd,disk} device drivers won't
> > > report the DMA speed used but this is intended since now DMA mode
> > > being used is always reported by IDE core code.
> > >
> > > Cc: Nick Warne <[EMAIL PROTECTED]>
> > > Cc: Mark Lord <[EMAIL PROTECTED]>
> > > Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
~ skip
Nick
--
Free Software Foundation Associate Member 5508
--
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: Peculiar out-of-sync boot log lines
On Sun, 2 Dec 2007 19:30:34 +0100
Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote:
Hi Bart,
Top posting! g.
This patch works fine on my system with this peculiar DVD drive, and
log reports are perfect.
Updated to Linus' git today - 2.6.24-rc6-g5b825ed2
/var/log/messages:
Dec 23 09:36:04 linuxamd kernel: ide0: BM-DMA at 0xd000-0xd007, BIOS
settings: hda:DMA, hdb:DMA
Dec 23 09:36:04 linuxamd kernel: ide1: BM-DMA at 0xd008-0xd00f, BIOS
settings: hdc:DMA, hdd:DMA
Dec 23 09:36:04 linuxamd kernel: hda: UDMA/66 mode selected
Dec 23 09:36:04 linuxamd kernel: hdb: UDMA/66 mode selected
Dec 23 09:36:04 linuxamd kernel: hdc: UDMA/66 mode selected
Dec 23 09:36:04 linuxamd kernel: hdd: UDMA/66 mode selected
Dec 23 09:36:04 linuxamd kernel: hda: max request size: 128KiB
Dec 23 09:36:04 linuxamd kernel: hda: 160086528 sectors (81964 MB) w/2048KiB
Cache, CHS=65535/16/63
Dec 23 09:36:04 linuxamd kernel: hda: cache flushes supported
Dec 23 09:36:04 linuxamd kernel: hda: hda1 hda2 hda3 hda4
Dec 23 09:36:04 linuxamd kernel: hdb: max request size: 128KiB
Dec 23 09:36:04 linuxamd kernel: hdb: 30015216 sectors (15367 MB) w/2048KiB
Cache, CHS=29777/16/63
Dec 23 09:36:04 linuxamd kernel: hdb: cache flushes not supported
Dec 23 09:36:04 linuxamd kernel: hdb: hdb1
Dec 23 09:36:04 linuxamd kernel: hdc: max request size: 128KiB
Dec 23 09:36:04 linuxamd kernel: hdc: 39876480 sectors (20416 MB) w/2048KiB
Cache, CHS=39560/16/63
Dec 23 09:36:04 linuxamd kernel: hdc: cache flushes not supported
Dec 23 09:36:04 linuxamd kernel: hdc: hdc1
Dec 23 09:36:04 linuxamd kernel: hdd: ATAPI 48X DVD-ROM DVD-R-RAM
CD-R/RW drive, 2048kB Cache
and
/var/log/syslog
Dec 23 09:36:04 linuxamd kernel: hdb: Maxtor 51536H2, ATA DISK drive
Dec 23 09:36:04 linuxamd kernel: hda: Maxtor 6Y080L0, ATA DISK drive
Dec 23 09:36:04 linuxamd kernel: hdd: TSSTcorp CDDVDW SH-S202J, ATAPI
CD/DVD-ROM drive
Dec 23 09:36:04 linuxamd kernel: hdc: Maxtor 52049H3, ATA DISK drive
On Sunday 02 December 2007, Randy Dunlap wrote:
On Sat, 1 Dec 2007 22:59:35 +0100 Bartlomiej Zolnierkiewicz wrote:
Thanks for reporting/debugging it guys!
Something in there needs to insert a '\n' before the skipping
word message. Since it doesn't do that right now, the
KERN_DEBUG string appears as 7
This seems like a good occasion to fix ide_dma_verbose() for good
so... :)
[ patch is against current Linus tree so might not apply to
2.6.23.9 ]
[PATCH] ide: DMA reporting and validity checking fixes
* ide_xfer_verbose() fixups:
- beautify returned mode names
- fix PIO5 reporting
- make it return 'const char *'
* Change printk() level from KERN_DEBUG to KERN_INFO in
ide_find_dma_mode().
* Add ide_id_dma_bug() helper based on ide_dma_verbose() to check
for invalid DMA info in identify block.
* Use ide_id_dma_bug() in ide_tune_dma() and ide_driveid_update().
As a result DMA won't be tuned or will be disabled after tuning
if device reports inconsistent info about enabled DMA mode
(ide_dma_verbose() does the same checks while the IDE device is
probed by ide-{cd,disk} device driver).
* Since (id-capability 1) id-tDMA is a valid configuration
handle it correctly in ide_id_dma_bug().
* Remove no longer needed ide_dma_verbose().
This patch should fix the following problem with out-of-sync IDE
messages reported by Nick Warned:
hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB
Cache7hdd: skipping word 93 validity check
, UDMA(66)
and later debugged by Mark Lord to be caused by:
ide_dma_verbose()
printk( ... 2048kB Cache);
eighty_ninty_three()
printk(KERN_DEBUG %s: skipping word 93 validity
check\n); ide_dma_verbose()
printk(, UDMA(66)
Please note that as a result ide-{cd,disk} device drivers won't
report the DMA speed used but this is intended since now DMA mode
being used is always reported by IDE core code.
Cc: Nick Warne [EMAIL PROTECTED]
Cc: Mark Lord [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
~ skip
Nick
--
Free Software Foundation Associate Member 5508
--
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: scsi_wait_scan Kconfig option
On Sat, 08 Dec 2007 14:11:44 +0100 Clemens Koller <[EMAIL PROTECTED]> wrote: > Nick Warne schrieb: > > I am bringing this up again - primarily as I forgot about it after > > patching my build tree ages ago: > > > > http://lkml.org/lkml/2007/10/27/68 Subject: Re: Fw: scsi_wait_scan Kconfig option Date: Fri, 7 Dec 2007 12:47:56 -0700 On Fri, Dec 07, 2007 at 07:39:53PM +, Nick Warne wrote: > I try not to build a modular kernel, but only have modules ON due to > nVidia (sigh). So I was semi-surprised when I saw the scsi_wait_scan > module being built again, yet NO WHERE in menuconfig is it present to > turn OFF. Even if I hand edit .config, make puts it back again... On Fri, 7 Dec 2007 12:47:56 -0700 Matthew Wilcox <[EMAIL PROTECTED]> wrote: > You have modules on ... which means you might decide to load a scsi > driver as a module. Maybe one that isn't part of the source tree. > The scsi_wait_scan module is only 1500 bytes. Apart from a sense of > ideological purity (odd in someone who chooses to use nVidia rather > than, say, nv or nouveau), this really isn't a problem. > > Please see the patch I sent some days ago, which does the very > same thing: http://marc.info/?l=linux-kernel=119677244318528=2 > > True... Well, that's two of us would that like to be able to stop it building :-) Nick -- Free Software Foundation Associate Member 5508 -- 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: scsi_wait_scan Kconfig option
On Sat, 08 Dec 2007 14:11:44 +0100 Clemens Koller [EMAIL PROTECTED] wrote: Nick Warne schrieb: I am bringing this up again - primarily as I forgot about it after patching my build tree ages ago: http://lkml.org/lkml/2007/10/27/68 Subject: Re: Fw: scsi_wait_scan Kconfig option Date: Fri, 7 Dec 2007 12:47:56 -0700 On Fri, Dec 07, 2007 at 07:39:53PM +, Nick Warne wrote: I try not to build a modular kernel, but only have modules ON due to nVidia (sigh). So I was semi-surprised when I saw the scsi_wait_scan module being built again, yet NO WHERE in menuconfig is it present to turn OFF. Even if I hand edit .config, make puts it back again... On Fri, 7 Dec 2007 12:47:56 -0700 Matthew Wilcox [EMAIL PROTECTED] wrote: You have modules on ... which means you might decide to load a scsi driver as a module. Maybe one that isn't part of the source tree. The scsi_wait_scan module is only 1500 bytes. Apart from a sense of ideological purity (odd in someone who chooses to use nVidia rather than, say, nv or nouveau), this really isn't a problem. Please see the patch I sent some days ago, which does the very same thing: http://marc.info/?l=linux-kernelm=119677244318528w=2 True... Well, that's two of us would that like to be able to stop it building :-) Nick -- Free Software Foundation Associate Member 5508 -- 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/
scsi_wait_scan Kconfig option
Hi all, I am bringing this up again - primarily as I forgot about it after patching my build tree ages ago: http://lkml.org/lkml/2007/10/27/68 Today I built and installed git for the first time and cloned Linus' tree (very trick!). I try not to build a modular kernel, but only have modules ON due to nVidia (sigh). So I was semi-surprised when I saw the scsi_wait_scan module being built again, yet NO WHERE in menuconfig is it present to turn OFF. Even if I hand edit .config, make puts it back again... .config # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_TGT is not set # CONFIG_SCSI_NETLINK is not set # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set CONFIG_SCSI_WAIT_SCAN=m I have attached my patch again :-) Nick -- Free Software Foundation Associate Member 5508--- linux-current/drivers/scsi/Kconfig_old 2007-10-20 12:44:50.0 +0100 +++ linux-current/drivers/scsi/Kconfig 2007-10-20 12:57:13.0 +0100 @@ -248,10 +248,17 @@ or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate "Wait for SCSI scan completion" default m depends on SCSI depends on MODULES + help + The SCSI subsystem can probe for devices while the rest of the + system continues booting, and even probe devices on different + busses in parallel, leading to a significant speed-up. + + You can load the scsi_wait_scan module to ensure that all scans + have completed. menu "SCSI Transports" depends on SCSI
[PATCH] Dell ik8
This small patch adds the Dell UK 6400 Inspiron model (MM061) to allow
the i8k module to load correctly without using 'force=1'
signed-off-by: "Nick Warne" <[EMAIL PROTECTED]>
Nick
--- i8k.cORIG 2007-12-07 10:30:42.0 +
+++ i8k.c 2007-12-07 13:10:57.0 +
@@ -439,6 +439,13 @@
DMI_MATCH(DMI_PRODUCT_NAME, "Latitude"),
},
},
+ { /* UK Inspiron 6400 */
+ .ident = "Dell Inspiron 3",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MM061"),
+ },
+ },
{ }
};
[PATCH] Dell ik8
This small patch adds the Dell UK 6400 Inspiron model (MM061) to allow
the i8k module to load correctly without using 'force=1'
signed-off-by: Nick Warne [EMAIL PROTECTED]
Nick
--- i8k.cORIG 2007-12-07 10:30:42.0 +
+++ i8k.c 2007-12-07 13:10:57.0 +
@@ -439,6 +439,13 @@
DMI_MATCH(DMI_PRODUCT_NAME, Latitude),
},
},
+ { /* UK Inspiron 6400 */
+ .ident = Dell Inspiron 3,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, Dell Inc.),
+ DMI_MATCH(DMI_PRODUCT_NAME, MM061),
+ },
+ },
{ }
};
scsi_wait_scan Kconfig option
Hi all, I am bringing this up again - primarily as I forgot about it after patching my build tree ages ago: http://lkml.org/lkml/2007/10/27/68 Today I built and installed git for the first time and cloned Linus' tree (very trick!). I try not to build a modular kernel, but only have modules ON due to nVidia (sigh). So I was semi-surprised when I saw the scsi_wait_scan module being built again, yet NO WHERE in menuconfig is it present to turn OFF. Even if I hand edit .config, make puts it back again... .config # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_TGT is not set # CONFIG_SCSI_NETLINK is not set # CONFIG_SCSI_PROC_FS is not set # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y # CONFIG_CHR_DEV_ST is not set # CONFIG_CHR_DEV_OSST is not set # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set CONFIG_SCSI_WAIT_SCAN=m I have attached my patch again :-) Nick -- Free Software Foundation Associate Member 5508--- linux-current/drivers/scsi/Kconfig_old 2007-10-20 12:44:50.0 +0100 +++ linux-current/drivers/scsi/Kconfig 2007-10-20 12:57:13.0 +0100 @@ -248,10 +248,17 @@ or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate Wait for SCSI scan completion default m depends on SCSI depends on MODULES + help + The SCSI subsystem can probe for devices while the rest of the + system continues booting, and even probe devices on different + busses in parallel, leading to a significant speed-up. + + You can load the scsi_wait_scan module to ensure that all scans + have completed. menu SCSI Transports depends on SCSI
Re: Peculiar out-of-sync boot log lines
On Sat, 1 Dec 2007 22:59:35 +0100 Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote: > Thanks for reporting/debugging it guys! > > > Something in there needs to insert a '\n' before the "skipping > > word" message. Since it doesn't do that right now, the KERN_DEBUG > > string appears as "<7>" > > This seems like a good occasion to fix ide_dma_verbose() for good > so... :) > This patch should fix the following problem with out-of-sync IDE > messages reported by Nick Warned: ... I was only reporting it... not warning anybody ;-) Nick -- Free Software Foundation Associate Member 5508 -- 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: Peculiar out-of-sync boot log lines
On Sat, 1 Dec 2007 22:59:35 +0100 Bartlomiej Zolnierkiewicz [EMAIL PROTECTED] wrote: Thanks for reporting/debugging it guys! Something in there needs to insert a '\n' before the skipping word message. Since it doesn't do that right now, the KERN_DEBUG string appears as 7 This seems like a good occasion to fix ide_dma_verbose() for good so... :) This patch should fix the following problem with out-of-sync IDE messages reported by Nick Warned: ... I was only reporting it... not warning anybody ;-) Nick -- Free Software Foundation Associate Member 5508 -- 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: Peculiar out-of-sync boot log lines
Hi Jon, On Thu, 29 Nov 2007 14:51:11 -0500 Jon Masters <[EMAIL PROTECTED]> wrote: > > On Thu, 2007-11-29 at 19:37 +, Nick Warne wrote: > > Hi all, > > > > 2.6.23.9 > > > > I have noticed after applying Bart's patch to word93 blacklist my > > new DVD drive: > > > > http://lkml.org/lkml/2007/10/23/475 > > > > I see now in logs (look at the hdd line: > > > > [dmesg] > > hdc: 39876480 sectors (20416 MB) w/2048KiB Cache, CHS=39560/16/63, > > UDMA(66) > > hdc: cache flushes not supported > > hdc: hdc1 > > hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache<7>hdd: > > skipping word 93 validity check > > , UDMA(66) > > Uniform CD-ROM driver Revision: 3.20 > > Only very early in boot are you guaranteed for things to execute > sequentially, and for logs to look nice and pretty. > Yes, but where does the <7> come from? Nick -- Free Software Foundation Associate Member 5508 - 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/
Peculiar out-of-sync boot log lines
Hi all, 2.6.23.9 I have noticed after applying Bart's patch to word93 blacklist my new DVD drive: http://lkml.org/lkml/2007/10/23/475 I see now in logs (look at the hdd line: [dmesg] hdc: 39876480 sectors (20416 MB) w/2048KiB Cache, CHS=39560/16/63, UDMA(66) hdc: cache flushes not supported hdc: hdc1 hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache<7>hdd: skipping word 93 validity check , UDMA(66) Uniform CD-ROM driver Revision: 3.20 <7> ?? And the ", UDMA(66)" gets new lined, so in syslog it appears all by itself: [/var/log/syslog] Nov 29 19:22:00 linuxamd kernel: hda: Maxtor 6Y080L0, ATA DISK drive Nov 29 19:22:00 linuxamd kernel: hdb: Maxtor 51536H2, ATA DISK drive Nov 29 19:22:00 linuxamd kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Nov 29 19:22:00 linuxamd kernel: hdc: Maxtor 52049H3, ATA DISK drive Nov 29 19:22:00 linuxamd kernel: hdd: TSSTcorp CDDVDW SH-S202J, ATAPI CD/DVD-ROM drive Nov 29 19:22:00 linuxamd kernel: ide1 at 0x170-0x177,0x376 on irq 15 Nov 29 19:22:00 linuxamd kernel: , UDMA(66) I have tried to trace this, but cannot see anywhere printk does this. Nick -- Free Software Foundation Associate Member 5508 - 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/
Peculiar out-of-sync boot log lines
Hi all, 2.6.23.9 I have noticed after applying Bart's patch to word93 blacklist my new DVD drive: http://lkml.org/lkml/2007/10/23/475 I see now in logs (look at the hdd line: [dmesg] hdc: 39876480 sectors (20416 MB) w/2048KiB Cache, CHS=39560/16/63, UDMA(66) hdc: cache flushes not supported hdc: hdc1 hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache7hdd: skipping word 93 validity check , UDMA(66) Uniform CD-ROM driver Revision: 3.20 7 ?? And the , UDMA(66) gets new lined, so in syslog it appears all by itself: [/var/log/syslog] Nov 29 19:22:00 linuxamd kernel: hda: Maxtor 6Y080L0, ATA DISK drive Nov 29 19:22:00 linuxamd kernel: hdb: Maxtor 51536H2, ATA DISK drive Nov 29 19:22:00 linuxamd kernel: ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Nov 29 19:22:00 linuxamd kernel: hdc: Maxtor 52049H3, ATA DISK drive Nov 29 19:22:00 linuxamd kernel: hdd: TSSTcorp CDDVDW SH-S202J, ATAPI CD/DVD-ROM drive Nov 29 19:22:00 linuxamd kernel: ide1 at 0x170-0x177,0x376 on irq 15 Nov 29 19:22:00 linuxamd kernel: , UDMA(66) I have tried to trace this, but cannot see anywhere printk does this. Nick -- Free Software Foundation Associate Member 5508 - 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: Peculiar out-of-sync boot log lines
Hi Jon, On Thu, 29 Nov 2007 14:51:11 -0500 Jon Masters [EMAIL PROTECTED] wrote: On Thu, 2007-11-29 at 19:37 +, Nick Warne wrote: Hi all, 2.6.23.9 I have noticed after applying Bart's patch to word93 blacklist my new DVD drive: http://lkml.org/lkml/2007/10/23/475 I see now in logs (look at the hdd line: [dmesg] hdc: 39876480 sectors (20416 MB) w/2048KiB Cache, CHS=39560/16/63, UDMA(66) hdc: cache flushes not supported hdc: hdc1 hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache7hdd: skipping word 93 validity check , UDMA(66) Uniform CD-ROM driver Revision: 3.20 Only very early in boot are you guaranteed for things to execute sequentially, and for logs to look nice and pretty. Yes, but where does the 7 come from? Nick -- Free Software Foundation Associate Member 5508 - 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: sb live (emu10k1) stops working between 2.6.23.1 and 2.6.23.7
> I've done some more testing this morning, and it appears that the "ALSA: > emu10k1 - Fix memory corruption" patch from 2.6.23.6 has broken digital > output on my SB Live Value card. Simply replacing the 2.6.23.7 emumixer.c > with the version included in 2.6.23.1 I was able to get digital output > working again under 2.6.23.7. Hi Jim, Just to prove you are not alone, I also get the exactly the same issue: lspci: 00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07) log: Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09:12:58 2007 UTC). PCI: Found IRQ 5 for device :00:0f.0 ALSA device list: #0: SBLive 5.1 [SB0060] (rev.7, serial:0x80611102) at 0xe000, irq 5 I use a restore file at boot, so run /sbin/alsactl restore And updating this morning to 2.6.23.8 produces: /usr/sbin/alsactl: set_control:991: warning: name mismatch (IEC958 Playback Mask/IEC958 Playback Default) for control #228 /usr/sbin/alsactl: set_control:993: warning: index mismatch (3/0) for control #228 /usr/sbin/alsactl: set_control:993: warning: index mismatch (0/1) for control #229 /usr/sbin/alsactl: set_control:993: warning: index mismatch (1/2) for control #230 /usr/sbin/alsactl: set_control:985: warning: iface mismatch (3/2) for control #231 /usr/sbin/alsactl: set_control:987: warning: device mismatch (2/0) for control #231 /usr/sbin/alsactl: set_control:989: warning: subdevice mismatch (0/0) for control #231 /usr/sbin/alsactl: set_control:991: warning: name mismatch (IEC958 Playback Default/SB Live Analog/Digital Output Jack) for control #231 Nick > On Fri, 16 Nov 2007, Jim Faulkner wrote: > > Hello, > > I have an SB Live Value card which uses the emu10k1 driver. I use digital > output to an external amplifier. This has worked fine for many years, up > to and including kernel 2.6.23.1. Under 2.6.23.7, I have been unable > to get any audio output. I get the following errors when loading my > asound.state under 2.6.23.7 using `alsactl restore`: > alsactl: set_control:991: warning: name mismatch (IEC958 Playback > Mask/IEC958 Playback Default) for control #222 > alsactl: set_control:993: warning: index mismatch (3/0) for control #222 > alsactl: set_control:993: warning: index mismatch (0/1) for control #223 > alsactl: set_control:993: warning: index mismatch (1/2) for control #224 > alsactl: set_control:985: warning: iface mismatch (3/2) for control #225 > alsactl: set_control:987: warning: device mismatch (2/0) for control #225 > alsactl: set_control:989: warning: subdevice mismatch (0/0) for control > #225 > alsactl: set_control:991: warning: name mismatch (IEC958 Playback > Default/SB Live Analog/Digital Output Jack) for control #225 > alsactl: set_control:993: warning: index mismatch (2/0) for control #225 > alsactl: set_control:995: failed to obtain info for control #225 > (Operation not permitted) > > I receive no errors when I load my asound.state under 2.6.23.1. -- Free Software Foundation Associate Member 5508 - 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: sb live (emu10k1) stops working between 2.6.23.1 and 2.6.23.7
I've done some more testing this morning, and it appears that the ALSA: emu10k1 - Fix memory corruption patch from 2.6.23.6 has broken digital output on my SB Live Value card. Simply replacing the 2.6.23.7 emumixer.c with the version included in 2.6.23.1 I was able to get digital output working again under 2.6.23.7. Hi Jim, Just to prove you are not alone, I also get the exactly the same issue: lspci: 00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07) log: Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09:12:58 2007 UTC). PCI: Found IRQ 5 for device :00:0f.0 ALSA device list: #0: SBLive 5.1 [SB0060] (rev.7, serial:0x80611102) at 0xe000, irq 5 I use a restore file at boot, so run /sbin/alsactl restore And updating this morning to 2.6.23.8 produces: /usr/sbin/alsactl: set_control:991: warning: name mismatch (IEC958 Playback Mask/IEC958 Playback Default) for control #228 /usr/sbin/alsactl: set_control:993: warning: index mismatch (3/0) for control #228 /usr/sbin/alsactl: set_control:993: warning: index mismatch (0/1) for control #229 /usr/sbin/alsactl: set_control:993: warning: index mismatch (1/2) for control #230 /usr/sbin/alsactl: set_control:985: warning: iface mismatch (3/2) for control #231 /usr/sbin/alsactl: set_control:987: warning: device mismatch (2/0) for control #231 /usr/sbin/alsactl: set_control:989: warning: subdevice mismatch (0/0) for control #231 /usr/sbin/alsactl: set_control:991: warning: name mismatch (IEC958 Playback Default/SB Live Analog/Digital Output Jack) for control #231 Nick On Fri, 16 Nov 2007, Jim Faulkner wrote: Hello, I have an SB Live Value card which uses the emu10k1 driver. I use digital output to an external amplifier. This has worked fine for many years, up to and including kernel 2.6.23.1. Under 2.6.23.7, I have been unable to get any audio output. I get the following errors when loading my asound.state under 2.6.23.7 using `alsactl restore`: alsactl: set_control:991: warning: name mismatch (IEC958 Playback Mask/IEC958 Playback Default) for control #222 alsactl: set_control:993: warning: index mismatch (3/0) for control #222 alsactl: set_control:993: warning: index mismatch (0/1) for control #223 alsactl: set_control:993: warning: index mismatch (1/2) for control #224 alsactl: set_control:985: warning: iface mismatch (3/2) for control #225 alsactl: set_control:987: warning: device mismatch (2/0) for control #225 alsactl: set_control:989: warning: subdevice mismatch (0/0) for control #225 alsactl: set_control:991: warning: name mismatch (IEC958 Playback Default/SB Live Analog/Digital Output Jack) for control #225 alsactl: set_control:993: warning: index mismatch (2/0) for control #225 alsactl: set_control:995: failed to obtain info for control #225 (Operation not permitted) I receive no errors when I load my asound.state under 2.6.23.1. -- Free Software Foundation Associate Member 5508 - 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] Kconfig bug
Am I the only one seeing this issue? On Saturday 20 October 2007 12:57:55 Nick Warne wrote: > Hi all, > > I noticed I had a module option being built that wasn't in menuconfig. > > It is missing description. I also added a brief help message. > > Signed off by: Nick Warne <[EMAIL PROTECTED]> Not using this patch, using menuconfig the scsi_wait option doesn't appear anywhere for me to be able to it turn off - yet grep'ing .config will always show this option as being built as a module. Nick -- Free Software Foundation Associate Member 5508 --- linux-current/drivers/scsi/Kconfig_old 2007-10-20 12:44:50.0 +0100 +++ linux-current/drivers/scsi/Kconfig 2007-10-20 12:57:13.0 +0100 @@ -248,10 +248,17 @@ or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate "Wait for SCSI scan completion" default m depends on SCSI depends on MODULES + help + The SCSI subsystem can probe for devices while the rest of the + system continues booting, and even probe devices on different + busses in parallel, leading to a significant speed-up. + + You can load the scsi_wait_scan module to ensure that all scans + have completed. menu "SCSI Transports" depends on SCSI
Re: [PATCH] Kconfig bug
Am I the only one seeing this issue? On Saturday 20 October 2007 12:57:55 Nick Warne wrote: Hi all, I noticed I had a module option being built that wasn't in menuconfig. It is missing description. I also added a brief help message. Signed off by: Nick Warne [EMAIL PROTECTED] Not using this patch, using menuconfig the scsi_wait option doesn't appear anywhere for me to be able to it turn off - yet grep'ing .config will always show this option as being built as a module. Nick -- Free Software Foundation Associate Member 5508 --- linux-current/drivers/scsi/Kconfig_old 2007-10-20 12:44:50.0 +0100 +++ linux-current/drivers/scsi/Kconfig 2007-10-20 12:57:13.0 +0100 @@ -248,10 +248,17 @@ or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate Wait for SCSI scan completion default m depends on SCSI depends on MODULES + help + The SCSI subsystem can probe for devices while the rest of the + system continues booting, and even probe devices on different + busses in parallel, leading to a significant speed-up. + + You can load the scsi_wait_scan module to ensure that all scans + have completed. menu SCSI Transports depends on SCSI
Re: New CD/DVD drive - 80-wire cable detection failure
Hi Bart,
On Wednesday 24 October 2007 00:33:08 Bartlomiej Zolnierkiewicz wrote:
> Hi,
>
> > > hdparm --Istdout /dev/hdd
>
> Thanks, the identify block looks quite "interesting".
[...]
> word 93 is 0x2000
>
> bit 0x4000 is not set despite the fact that ATA spec (>= ATA-5) requires
> it to be set (the device claims ATA/ATAPI-3/4/5/6/7 compatiblity, a bit too
> optimistic since it looks like the firmware was based on ATA/ATAPI-4 spec)
>
> bit 0x2000 is set which would indicate that the 80-wires cable is
> correctly detected by the device
>
> => the device/firmware pair is a good candidate for ivb_list[]
Interesting, I fully understand.
> There seems to be a new firmware (SB01) for this device:
> http://www.samsungodd.com/Lib/popup/Download.asp?path=FW_FWDownload=2
>00710011656260232_SH-S202J_%20SB01.exe
> It would be useful to know whether it has the same problem...
I cannot use this - I haven't used windows at home for a few years, and have
no way to flash the device up. It would be interesting though if this does
make it conform.
> Could you try this patch?
>
> [PATCH] ide: add SH-S202J to ivb_list[]
Thank you! This works very well!
hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache<7>hdd: skipping
word 93 validity check
, UDMA(66)
Many thanks indeed!
Nick
> From the report by Nick Warne.
>
> Cc: Nick Warne <[EMAIL PROTECTED]>
> Cc: Lennart Sorensen <[EMAIL PROTECTED]>
> Signed-off-by: Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]>
> ---
> drivers/ide/ide-iops.c |3 +++
> 1 file changed, 3 insertions(+)
>
> Index: b/drivers/ide/ide-iops.c
> ===
> --- a/drivers/ide/ide-iops.c
> +++ b/drivers/ide/ide-iops.c
> @@ -582,9 +582,12 @@ EXPORT_SYMBOL_GPL(ide_in_drive_list);
> /*
> * Early UDMA66 devices don't set bit14 to 1, only bit13 is valid.
> * We list them here and depend on the device side cable detection for
> them. + *
> + * Some optical devices with the buggy firmwares have the same problem.
> */
> static const struct drive_list_entry ivb_list[] = {
> { "QUANTUM FIREBALLlct10 05", "A03.0900"},
> + { "TSSTcorp CDDVDW SH-S202J", "SB00"},
> { NULL , NULL }
> };
--
Free Software Foundation Associate Member 5508
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: New CD/DVD drive - 80-wire cable detection failure
Hi Bart,
On Wednesday 24 October 2007 00:33:08 Bartlomiej Zolnierkiewicz wrote:
Hi,
hdparm --Istdout /dev/hdd
Thanks, the identify block looks quite interesting.
[...]
word 93 is 0x2000
bit 0x4000 is not set despite the fact that ATA spec (= ATA-5) requires
it to be set (the device claims ATA/ATAPI-3/4/5/6/7 compatiblity, a bit too
optimistic since it looks like the firmware was based on ATA/ATAPI-4 spec)
bit 0x2000 is set which would indicate that the 80-wires cable is
correctly detected by the device
= the device/firmware pair is a good candidate for ivb_list[]
Interesting, I fully understand.
There seems to be a new firmware (SB01) for this device:
http://www.samsungodd.com/Lib/popup/Download.asp?path=FW_FWDownloadfname=2
00710011656260232_SH-S202J_%20SB01.exe
It would be useful to know whether it has the same problem...
I cannot use this - I haven't used windows at home for a few years, and have
no way to flash the device up. It would be interesting though if this does
make it conform.
Could you try this patch?
[PATCH] ide: add SH-S202J to ivb_list[]
Thank you! This works very well!
hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache7hdd: skipping
word 93 validity check
, UDMA(66)
Many thanks indeed!
Nick
From the report by Nick Warne.
Cc: Nick Warne [EMAIL PROTECTED]
Cc: Lennart Sorensen [EMAIL PROTECTED]
Signed-off-by: Bartlomiej Zolnierkiewicz [EMAIL PROTECTED]
---
drivers/ide/ide-iops.c |3 +++
1 file changed, 3 insertions(+)
Index: b/drivers/ide/ide-iops.c
===
--- a/drivers/ide/ide-iops.c
+++ b/drivers/ide/ide-iops.c
@@ -582,9 +582,12 @@ EXPORT_SYMBOL_GPL(ide_in_drive_list);
/*
* Early UDMA66 devices don't set bit14 to 1, only bit13 is valid.
* We list them here and depend on the device side cable detection for
them. + *
+ * Some optical devices with the buggy firmwares have the same problem.
*/
static const struct drive_list_entry ivb_list[] = {
{ QUANTUM FIREBALLlct10 05, A03.0900},
+ { TSSTcorp CDDVDW SH-S202J, SB00},
{ NULL , NULL }
};
--
Free Software Foundation Associate Member 5508
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: New CD/DVD drive - 80-wire cable detection failure
Hi all, SOLVED! On Saturday 20 October 2007 10:37:31 Nick Warne wrote: > On Friday 19 October 2007 23:28:21 Bartlomiej Zolnierkiewicz wrote: > > On Saturday 20 October 2007, Nick Warne wrote: > > > On Friday 19 October 2007 22:44:27 Bartlomiej Zolnierkiewicz wrote: > > > > > > hdparm -I > > > > It should have been hdparm --Istdout (sorry, once again). > > hdparm --Istdout /dev/hdd I built a new kernel today 2.6.23.1, and looked very closely at kernel options. Setting: CONFIG_IDEDMA_IVB did the trick! hdd: TSSTcorp CDDVDW SH-S202J, ATAPI CD/DVD-ROM drive hdd: selected mode 0x44 hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(66) Thank you all for looking at this non-issue. Sorry for the noise!!! Nick > > There is some confusion on this drive now. Somebody sent me a link to tech > specs and that states it only does udma2 mode - but the specs I found state > it does udma4? > > http://downloadcenter.samsung.com/content/UM/200708/20070823084759796_SH-S2 >02J_ENG.pdf > > So knowing what these hardware firms are like, maybe it _is_ only udma2? > > Thanks, > > Nick -- Free Software Foundation Associate Member 5508 - 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/
[PATCH] Kconfig bug
Hi all, I noticed I had a module option being built that wasn't in menuconfig. It is missing description. I also added a brief help message. Signed off by: Nick Warne <[EMAIL PROTECTED]> Nick -- Free Software Foundation Associate Member 5508 --- linux-current/drivers/scsi/Kconfig_old 2007-10-20 12:44:50.0 +0100 +++ linux-current/drivers/scsi/Kconfig 2007-10-20 12:57:13.0 +0100 @@ -248,10 +248,17 @@ or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate "Wait for SCSI scan completion" default m depends on SCSI depends on MODULES + help + The SCSI subsystem can probe for devices while the rest of the + system continues booting, and even probe devices on different + busses in parallel, leading to a significant speed-up. + + You can load the scsi_wait_scan module to ensure that all scans + have completed. menu "SCSI Transports" depends on SCSI
Re: New CD/DVD drive - 80-wire cable detection failure
On Friday 19 October 2007 23:28:21 Bartlomiej Zolnierkiewicz wrote:
> On Saturday 20 October 2007, Nick Warne wrote:
> > On Friday 19 October 2007 22:44:27 Bartlomiej Zolnierkiewicz wrote:
> >
> > hdparm -I
>
> It should have been hdparm --Istdout (sorry, once again).
>
hdparm --Istdout /dev/hdd
/dev/hdd:
85c0
2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 5342
3030 2020 2020 5453 5354 636f 7270 2043
5644 5720 5348 2d53 3230 324a 2020
2020 2020 2020 2020 2020 2020 2020
0b00 0200 0200 0006
0007
0003 0078 0078 017f 0078
00f8 0210
00f8 0210 0210
041f 8005 3200 005b 2000
a8a5
There is some confusion on this drive now. Somebody sent me a link to tech
specs and that states it only does udma2 mode - but the specs I found state
it does udma4?
http://downloadcenter.samsung.com/content/UM/200708/20070823084759796_SH-S202J_ENG.pdf
So knowing what these hardware firms are like, maybe it _is_ only udma2?
Thanks,
Nick
--
Free Software Foundation Associate Member 5508
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: New CD/DVD drive - 80-wire cable detection failure
On Friday 19 October 2007 23:28:21 Bartlomiej Zolnierkiewicz wrote:
On Saturday 20 October 2007, Nick Warne wrote:
On Friday 19 October 2007 22:44:27 Bartlomiej Zolnierkiewicz wrote:
hdparm -I
It should have been hdparm --Istdout (sorry, once again).
hdparm --Istdout /dev/hdd
/dev/hdd:
85c0
2020 2020 2020 2020 2020 2020
2020 2020 2020 2020 5342
3030 2020 2020 5453 5354 636f 7270 2043
5644 5720 5348 2d53 3230 324a 2020
2020 2020 2020 2020 2020 2020 2020
0b00 0200 0200 0006
0007
0003 0078 0078 017f 0078
00f8 0210
00f8 0210 0210
041f 8005 3200 005b 2000
a8a5
There is some confusion on this drive now. Somebody sent me a link to tech
specs and that states it only does udma2 mode - but the specs I found state
it does udma4?
http://downloadcenter.samsung.com/content/UM/200708/20070823084759796_SH-S202J_ENG.pdf
So knowing what these hardware firms are like, maybe it _is_ only udma2?
Thanks,
Nick
--
Free Software Foundation Associate Member 5508
-
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/
[PATCH] Kconfig bug
Hi all, I noticed I had a module option being built that wasn't in menuconfig. It is missing description. I also added a brief help message. Signed off by: Nick Warne [EMAIL PROTECTED] Nick -- Free Software Foundation Associate Member 5508 --- linux-current/drivers/scsi/Kconfig_old 2007-10-20 12:44:50.0 +0100 +++ linux-current/drivers/scsi/Kconfig 2007-10-20 12:57:13.0 +0100 @@ -248,10 +248,17 @@ or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate Wait for SCSI scan completion default m depends on SCSI depends on MODULES + help + The SCSI subsystem can probe for devices while the rest of the + system continues booting, and even probe devices on different + busses in parallel, leading to a significant speed-up. + + You can load the scsi_wait_scan module to ensure that all scans + have completed. menu SCSI Transports depends on SCSI
Re: New CD/DVD drive - 80-wire cable detection failure
Hi all, SOLVED! On Saturday 20 October 2007 10:37:31 Nick Warne wrote: On Friday 19 October 2007 23:28:21 Bartlomiej Zolnierkiewicz wrote: On Saturday 20 October 2007, Nick Warne wrote: On Friday 19 October 2007 22:44:27 Bartlomiej Zolnierkiewicz wrote: hdparm -I It should have been hdparm --Istdout (sorry, once again). hdparm --Istdout /dev/hdd I built a new kernel today 2.6.23.1, and looked very closely at kernel options. Setting: CONFIG_IDEDMA_IVB did the trick! hdd: TSSTcorp CDDVDW SH-S202J, ATAPI CD/DVD-ROM drive hdd: selected mode 0x44 hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(66) Thank you all for looking at this non-issue. Sorry for the noise!!! Nick There is some confusion on this drive now. Somebody sent me a link to tech specs and that states it only does udma2 mode - but the specs I found state it does udma4? http://downloadcenter.samsung.com/content/UM/200708/20070823084759796_SH-S2 02J_ENG.pdf So knowing what these hardware firms are like, maybe it _is_ only udma2? Thanks, Nick -- Free Software Foundation Associate Member 5508 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New CD/DVD drive - 80-wire cable detection failure
On Friday 19 October 2007 22:44:27 Bartlomiej Zolnierkiewicz wrote: > > Ah, so the patch won't help (sorry, I didn't pay enough attention). > > Len's advices are worth the try, also please send the output > of hdparm -I /dev/hdd. > > Thanks, > Bart Yes, Len's advice has me wondering now. Do I have a dodgy cable? I will have to change that tomorrow. But more info. The old drive played DVD movies etc. OK, but slowly it became worse until I couldn't read any one of them 9 times out of 10. CD play back/burning was OK 100% all the time though - so I guessed the dvd laser (whatever it does) was dead - hence why I bought a new one. The new drive works perfectly, but for the udma33 issue. If it was the cable, why would it read/burn CD OK, but not DVD sometimes on the old drive? hdparm -I /dev/hdd: ATAPI CD-ROM, with removable media Model Number: TSSTcorp CDDVDW SH-S202J Serial Number: Firmware Revision: SB00 Standards: Supported: CD-ROM ATAPI-3 -4 -5 -6 -7 Configuration: DRQ response: 50us. Packet size: 12 bytes Capabilities: LBA, IORDY(cannot be disabled) DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=383ns IORDY flow control=120ns BTW, thanks for help all. Nick -- Free Software Foundation Associate Member 5508 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New CD/DVD drive - 80-wire cable detection failure
On Friday 19 October 2007 22:07:43 Lennart Sorensen wrote: > On Fri, Oct 19, 2007 at 10:03:09PM +0100, Nick Warne wrote: > > No change: > > > > ide_setup: hdd=ide-cd > > ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA > > hdd: TSSTcorp CDDVDW SH-S202J, ATAPI CD/DVD-ROM drive > > hdd: drive side 80-wire cable detection failed, limiting max speed to > > UDMA33 hdd: selected mode 0x42 > > hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33) > > Did you try another cable? DId you try using both the old IDE drivers > and the new PATA libata drivers? What is the hdd=ide-cd supposed to > do? Do you have a device present as hdc and if not, then why not? > (Hint: ATA spec requires a master before you can have a slave, even > though it frequently does work with just a slave. Of course cable > select seems even nicer since then the device at the end of an 80 wire > cable is automatically master, and any additional device added to the > middle connector on the cable becomes slave, and you should not connect > a device to the middle connector without one on the end). > > Also make sure the right end of the cable is connected to the mainboard, > just in case that matters. I have (since 2.6.15 at least) hda, hdb, hdc, and hdd. hda and hdb are mounted at boot. hdc is not mounted, as I leave that drive for backups and mount as needed. All I done was replace a duff cd/dvd drive (hdd) with a new one. Nick -- Free Software Foundation Associate Member 5508 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New CD/DVD drive - 80-wire cable detection failure
Hi Bart,
Thanks for assistance.
On Friday 19 October 2007 21:28:43 Bartlomiej Zolnierkiewicz wrote:
> > No help anyone? Did I buy a taboo drive?
> >
> > [EMAIL PROTECTED]:nick$ /usr/sbin/hdparm -i /dev/hdd
> >
> > /dev/hdd:
> >
> > Model=TSSTcorp CDDVDW SH-S202J, FwRev=SB00, SerialNo=
> > Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
> > RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
> > BuffType=unknown, BuffSize=0kB, MaxMultSect=0
> > (maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
> > IORDY=yes, tPIO={min:383,w/IORDY:120}, tDMA={min:120,rec:120}
> > PIO modes: pio0 pio1 pio2 pio3 pio4
> > DMA modes: mdma0 mdma1 mdma2
> > UDMA modes: udma0 udma1 *udma2 udma3 udma4
> > AdvancedPM=no
> > Drive conforms to: unknown:
> >
> > * signifies the current active mode
> >
> >
> > Any help to get this fixed (by me) would be welcome. I cannot find any
> > information on why this happens (or rather why the 'drive side') refuses
> > to see 80-wire ide cable.
>
> Please try:
>
> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm
>1/broken-out/ide-ide-change-master-slave-identify-order.patch
No change:
ide_setup: hdd=ide-cd
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
hdd: TSSTcorp CDDVDW SH-S202J, ATAPI CD/DVD-ROM drive
hdd: drive side 80-wire cable detection failed, limiting max speed to UDMA33
hdd: selected mode 0x42
hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
Nick
--
Free Software Foundation Associate Member 5508
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: New CD/DVD drive - 80-wire cable detection failure
On Thursday 18 October 2007 18:32:42 Nick Warne wrote:
> Hi all,
>
> Please CC, not subscribed.
>
> kernel 2.6.23
>
> My DVD/CDrom stopped reading DVD's, so I purchased a new one today.
>
> Old:
> Oct 10 21:01:01 linuxamd kernel: ide0: BM-DMA at 0xd000-0xd007, BIOS
> settings: hda:DMA, hdb:DMA
> Oct 10 21:01:01 linuxamd kernel: ide1: BM-DMA at 0xd008-0xd00f, BIOS
> settings: hdc:DMA, hdd:DMA
>
> Oct 10 21:01:01 linuxamd kernel: hdd: ATAPI 48X DVD-ROM DVD-R CD-R/RW
> drive, 2048kB Cache, UDMA(66)
> Oct 10 21:01:01 linuxamd kernel: Uniform CD-ROM driver Revision: 3.20
>
> New:
> Oct 18 17:32:20 linuxamd kernel: ide0: BM-DMA at 0xd000-0xd007, BIOS
> settings: hda:DMA, hdb:DMA
> Oct 18 17:32:20 linuxamd kernel: ide1: BM-DMA at 0xd008-0xd00f, BIOS
> settings: hdc:DMA, hdd:DMA
>
> Oct 18 17:32:20 linuxamd kernel: hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW
> drive, 2048kB Cache, UDMA(33)
> Oct 18 17:32:20 linuxamd kernel: Uniform CD-ROM driver Revision: 3.20
>
> For some reason the new drive produces:
>
> hdd: TSSTcorp CDDVDW SH-S202J, ATAPI CD/DVD-ROM drive
> hdd: drive side 80-wire cable detection failed, limiting max speed to
> UDMA33
>
> I boot with hdd=ide-cd
>
> How to debug this to find out what is going on?
>
> Thanks,
>
> Nick
No help anyone? Did I buy a taboo drive?
[EMAIL PROTECTED]:nick$ /usr/sbin/hdparm -i /dev/hdd
/dev/hdd:
Model=TSSTcorp CDDVDW SH-S202J, FwRev=SB00, SerialNo=
Config={ Fixed Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=yes, tPIO={min:383,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2 udma3 udma4
AdvancedPM=no
Drive conforms to: unknown:
* signifies the current active mode
Any help to get this fixed (by me) would be welcome. I cannot find any
information on why this happens (or rather why the 'drive side') refuses to
see 80-wire ide cable.
Thanks,
Nick
--
Free Software Foundation Associate Member 5508
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: New CD/DVD drive - 80-wire cable detection failure
On Friday 19 October 2007 22:44:27 Bartlomiej Zolnierkiewicz wrote: Ah, so the patch won't help (sorry, I didn't pay enough attention). Len's advices are worth the try, also please send the output of hdparm -I /dev/hdd. Thanks, Bart Yes, Len's advice has me wondering now. Do I have a dodgy cable? I will have to change that tomorrow. But more info. The old drive played DVD movies etc. OK, but slowly it became worse until I couldn't read any one of them 9 times out of 10. CD play back/burning was OK 100% all the time though - so I guessed the dvd laser (whatever it does) was dead - hence why I bought a new one. The new drive works perfectly, but for the udma33 issue. If it was the cable, why would it read/burn CD OK, but not DVD sometimes on the old drive? hdparm -I /dev/hdd: ATAPI CD-ROM, with removable media Model Number: TSSTcorp CDDVDW SH-S202J Serial Number: Firmware Revision: SB00 Standards: Supported: CD-ROM ATAPI-3 -4 -5 -6 -7 Configuration: DRQ response: 50us. Packet size: 12 bytes Capabilities: LBA, IORDY(cannot be disabled) DMA: mdma0 mdma1 mdma2 udma0 udma1 *udma2 udma3 udma4 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=383ns IORDY flow control=120ns BTW, thanks for help all. Nick -- Free Software Foundation Associate Member 5508 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New CD/DVD drive - 80-wire cable detection failure
On Friday 19 October 2007 22:07:43 Lennart Sorensen wrote: On Fri, Oct 19, 2007 at 10:03:09PM +0100, Nick Warne wrote: No change: ide_setup: hdd=ide-cd ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA hdd: TSSTcorp CDDVDW SH-S202J, ATAPI CD/DVD-ROM drive hdd: drive side 80-wire cable detection failed, limiting max speed to UDMA33 hdd: selected mode 0x42 hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33) Did you try another cable? DId you try using both the old IDE drivers and the new PATA libata drivers? What is the hdd=ide-cd supposed to do? Do you have a device present as hdc and if not, then why not? (Hint: ATA spec requires a master before you can have a slave, even though it frequently does work with just a slave. Of course cable select seems even nicer since then the device at the end of an 80 wire cable is automatically master, and any additional device added to the middle connector on the cable becomes slave, and you should not connect a device to the middle connector without one on the end). Also make sure the right end of the cable is connected to the mainboard, just in case that matters. I have (since 2.6.15 at least) hda, hdb, hdc, and hdd. hda and hdb are mounted at boot. hdc is not mounted, as I leave that drive for backups and mount as needed. All I done was replace a duff cd/dvd drive (hdd) with a new one. Nick -- Free Software Foundation Associate Member 5508 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: New CD/DVD drive - 80-wire cable detection failure
Hi Bart,
Thanks for assistance.
On Friday 19 October 2007 21:28:43 Bartlomiej Zolnierkiewicz wrote:
No help anyone? Did I buy a taboo drive?
[EMAIL PROTECTED]:nick$ /usr/sbin/hdparm -i /dev/hdd
/dev/hdd:
Model=TSSTcorp CDDVDW SH-S202J, FwRev=SB00, SerialNo=
Config={ Fixed Removeable DTR=5Mbs DTR10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=yes, tPIO={min:383,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2 udma3 udma4
AdvancedPM=no
Drive conforms to: unknown:
* signifies the current active mode
Any help to get this fixed (by me) would be welcome. I cannot find any
information on why this happens (or rather why the 'drive side') refuses
to see 80-wire ide cable.
Please try:
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm
1/broken-out/ide-ide-change-master-slave-identify-order.patch
No change:
ide_setup: hdd=ide-cd
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
hdd: TSSTcorp CDDVDW SH-S202J, ATAPI CD/DVD-ROM drive
hdd: drive side 80-wire cable detection failed, limiting max speed to UDMA33
hdd: selected mode 0x42
hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33)
Nick
--
Free Software Foundation Associate Member 5508
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: New CD/DVD drive - 80-wire cable detection failure
On Thursday 18 October 2007 18:32:42 Nick Warne wrote:
Hi all,
Please CC, not subscribed.
kernel 2.6.23
My DVD/CDrom stopped reading DVD's, so I purchased a new one today.
Old:
Oct 10 21:01:01 linuxamd kernel: ide0: BM-DMA at 0xd000-0xd007, BIOS
settings: hda:DMA, hdb:DMA
Oct 10 21:01:01 linuxamd kernel: ide1: BM-DMA at 0xd008-0xd00f, BIOS
settings: hdc:DMA, hdd:DMA
Oct 10 21:01:01 linuxamd kernel: hdd: ATAPI 48X DVD-ROM DVD-R CD-R/RW
drive, 2048kB Cache, UDMA(66)
Oct 10 21:01:01 linuxamd kernel: Uniform CD-ROM driver Revision: 3.20
New:
Oct 18 17:32:20 linuxamd kernel: ide0: BM-DMA at 0xd000-0xd007, BIOS
settings: hda:DMA, hdb:DMA
Oct 18 17:32:20 linuxamd kernel: ide1: BM-DMA at 0xd008-0xd00f, BIOS
settings: hdc:DMA, hdd:DMA
Oct 18 17:32:20 linuxamd kernel: hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW
drive, 2048kB Cache, UDMA(33)
Oct 18 17:32:20 linuxamd kernel: Uniform CD-ROM driver Revision: 3.20
For some reason the new drive produces:
hdd: TSSTcorp CDDVDW SH-S202J, ATAPI CD/DVD-ROM drive
hdd: drive side 80-wire cable detection failed, limiting max speed to
UDMA33
I boot with hdd=ide-cd
How to debug this to find out what is going on?
Thanks,
Nick
No help anyone? Did I buy a taboo drive?
[EMAIL PROTECTED]:nick$ /usr/sbin/hdparm -i /dev/hdd
/dev/hdd:
Model=TSSTcorp CDDVDW SH-S202J, FwRev=SB00, SerialNo=
Config={ Fixed Removeable DTR=5Mbs DTR10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=yes, tPIO={min:383,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 *udma2 udma3 udma4
AdvancedPM=no
Drive conforms to: unknown:
* signifies the current active mode
Any help to get this fixed (by me) would be welcome. I cannot find any
information on why this happens (or rather why the 'drive side') refuses to
see 80-wire ide cable.
Thanks,
Nick
--
Free Software Foundation Associate Member 5508
-
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/
New CD/DVD drive - 80-wire cable detection failure
Hi all, Please CC, not subscribed. kernel 2.6.23 My DVD/CDrom stopped reading DVD's, so I purchased a new one today. Old: Oct 10 21:01:01 linuxamd kernel: ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA Oct 10 21:01:01 linuxamd kernel: ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA Oct 10 21:01:01 linuxamd kernel: hdd: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(66) Oct 10 21:01:01 linuxamd kernel: Uniform CD-ROM driver Revision: 3.20 New: Oct 18 17:32:20 linuxamd kernel: ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA Oct 18 17:32:20 linuxamd kernel: ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA Oct 18 17:32:20 linuxamd kernel: hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33) Oct 18 17:32:20 linuxamd kernel: Uniform CD-ROM driver Revision: 3.20 For some reason the new drive produces: hdd: TSSTcorp CDDVDW SH-S202J, ATAPI CD/DVD-ROM drive hdd: drive side 80-wire cable detection failed, limiting max speed to UDMA33 I boot with hdd=ide-cd How to debug this to find out what is going on? Thanks, Nick -- Free Software Foundation Associate Member 5508 - 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/
New CD/DVD drive - 80-wire cable detection failure
Hi all, Please CC, not subscribed. kernel 2.6.23 My DVD/CDrom stopped reading DVD's, so I purchased a new one today. Old: Oct 10 21:01:01 linuxamd kernel: ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA Oct 10 21:01:01 linuxamd kernel: ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA Oct 10 21:01:01 linuxamd kernel: hdd: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache, UDMA(66) Oct 10 21:01:01 linuxamd kernel: Uniform CD-ROM driver Revision: 3.20 New: Oct 18 17:32:20 linuxamd kernel: ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA Oct 18 17:32:20 linuxamd kernel: ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA Oct 18 17:32:20 linuxamd kernel: hdd: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33) Oct 18 17:32:20 linuxamd kernel: Uniform CD-ROM driver Revision: 3.20 For some reason the new drive produces: hdd: TSSTcorp CDDVDW SH-S202J, ATAPI CD/DVD-ROM drive hdd: drive side 80-wire cable detection failed, limiting max speed to UDMA33 I boot with hdd=ide-cd How to debug this to find out what is going on? Thanks, Nick -- Free Software Foundation Associate Member 5508 - 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/
