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 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 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"
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 = &one
>> >
>> >> 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 &one.
>>
>> 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 = &one > >> 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 &one. 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 = &one 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 &one. 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;
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/
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/
[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 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 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/
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/
[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 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/
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/
[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/
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&r=1&w=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/
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: 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&m=119677244318528&w=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"),
+ },
+ },
{ }
};
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/
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: 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&fname=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 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 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/
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/
Re: [Bug 5078] Re: kernel status, 5 Sep 2005
Francois Romieu wrote: > [...] >> [Bugme-new] [Bug 5137] New: r8169 - network dies. >> http://bugzilla.kernel.org/show_bug.cgi?id=5137 > > It's cooking. This one looks _so_ familiar to me personally - exactly the same problems I had: http://marc.theaimsgroup.com/?l=linux-kernel&m=112458400611745&w=2 Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.13 new option timer frequency
On Monday 29 August 2005 19:48, Jonathan Corbet wrote: > > I built and installed 2.6.13 today, and oldconfig revealed the new option > > for timer frequency. > > > > I searched the LKML on this, but all I found is the technical stuff - not > > really any layman solutions. > > I wrote a bit about the timer frequency option a few weeks ago: > > http://lwn.net/Articles/145973/ OK, thanks everybody for replies. Jon, that is a near perfect article - I understand it all now. I haven't noticed anything different under 250HZ yet..., if anything machine seems smoother. Lower electricity bills will be handy as well ;-) Thanks, Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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/
2.6.13 new option timer frequency
Hi all, I built and installed 2.6.13 today, and oldconfig revealed the new option for timer frequency. I searched the LKML on this, but all I found is the technical stuff - not really any layman solutions. Two n00b questions here: What does this do/what is it for? I selected default, 250Hz. If this is now an option, what was it before? Thanks, Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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: RTL8139, the final patch ?
On Saturday 20 August 2005 21:53, you wrote: > I have a problem with it: > It's about patching, reverting, patching, reverting,... > I got lost. That's why I asked for a... "straighter" one :-) >> But I looked at what he said and found the real problem on my system (after >> all that): >> http://www.ussg.iu.edu/hypermail/linux/kernel/0403.1/1537.html > It's about a configuration option in the kernel? > The patch is about adding the option, if i'm right. No, what happened was on 2.6.2 all was well. When 2.6.3 came out I got these timeout errors on the NIC's - but using the 2.6.2 8139too.c file in 2.6.3 worked. Mr Hirofumi then took up the challenge and sent me patches. Slowly he resolved the issue, but the conclusion was it wasn't the code causing it. It was an option in my BIOS PCI level/edge settings as I posted. People on laptops get this error, like you, but there is no BIOS option as such... :-/ Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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: RTL8139, the final patch ?
Rakotomandimby Mihamina wrote: > Hi, > > I now use a notebook that uses RTL8139, and I encounter exactly the same > problems as this: > > http://www.ussg.iu.edu/hypermail/linux/kernel/0402.3/1289.html > > I know use Fedora Core 4 on this box. > With a Linux FC4 kernel (not customized yet). > > As well as I still encounter the problem, I guess the solution has not > been found. Hi, this was my original post. I did indeed get a solution - and occasionally I see people still have this issue and some of them mail me, so I have a prepared mail :-) Here is the 'final' post after Mr Hirofumi found the cause of my issues: http://www.ussg.iu.edu/hypermail/linux/kernel/0402.3/1709.html But I looked at what he said and found the real problem on my system (after all that): http://www.ussg.iu.edu/hypermail/linux/kernel/0403.1/1537.html Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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: IDE CD problems in 2.6.13rc6
Voluspa wrote: > On 2005-08-14 20:10:49 Nick Warne wrote: > >>Note the last sentence: >> >>' This variation is designed for use with "libraries" of drive >>identification information, and can also be used on ATAPI drives which may >>give media errors with the standard mechanism. > > My jaw just clonked on the table. And the media error at hand made you > buy a new CD-RW. There is precedence for this (remember the blaming X and > other programs in the keyboard driver?) Just for the record, it was a KDE service daemon that caused these errors for me, like a 24MB log in 12 hours: KDED Media Manager Also trying to remember, I had a CD-RW on /dev/hdc and a CD-R on /dev/hdd. It was /dev/hdd that give those errors, but I only passed the SCSI emulation on kernel line for the CD-RW. So I suppose it uses similar code (of sorts) as HDPARM. I dunno. The old drive was 6 years old anyway - so after I sussed the issue I pretend I did an upgrade ;-) Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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: IDE CD problems in 2.6.13rc6
I just remember a path I took when resolving the issue further to my post
below.
Here is what man hdparm says on -i and -I:
-i Display the identification info that was obtained from the
drive at boot time,
if available. This is a feature of modern IDE drives, and may
not be supported
by older devices. The data returned may or may not be
current, depending on
activity since booting the system. However, the current
multiple sector mode
count is always shown. For a more detailed interpretation of
the identification
info, refer to AT Attachment Interface for Disk Drives (ANSI ASC
X3T9.2 working
draft, revision 4a, April 19/93).
-I Request identification info directly from the drive, which is
displayed in a new
expanded format with considerably more detail than with the
older -i flag.
There is a special "no seatbelts" variation on this option,
-Istdin which cannot
be combined with any other options, and which accepts a drive
identification
block as standard input instead of using a /dev/hd*
parameter. The format of
this block must be exactly the same as that found in
the /proc/ide/*/hd*/iden
tify "files". This variation is designed for use with
"libraries" of drive
identification information, and can also be used on ATAPI drives
which may give
media errors with the standard mechanism.
Note the last sentence:
' This variation is designed for use with "libraries" of drive
identification information, and can also be used on ATAPI drives which may
give media errors with the standard mechanism.
Nick
Voluspa wrote:
> The "hdparm -I /dev/hdc"
>
> hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
> hdc: drive_cmd: error=0x04 { AbortedCommand }
> de: failed opcode was: 0xec
>
> Is present on all kernels that I have locally (oldest 2.6.11.11)
> so it is not related to the threadstarters problems, it seems.
Hi all,
Maybe teaching you all to suck eggs here, but I used to get this a lot on my
CD's - KDE ran some probe and as the CD[s] where empty logs filled up rapidly
with that error. I thought the[a] drive was duff, so bought a new CD-RW.
Made no difference :-/ I then investigated further, and read that instead of
the SCSI emulation, it was superceded by IDE-CD.
kernel 2.6.12.3
Kernel command line: BOOT_IMAGE=Nicks ro root=303 hdc=ide-cd hdd=ide-cd
Fixed the issue for me. But as I say, teaching to suck eggs, but I thought I
would mention it.
Nick
--
"When you're chewing on life's gristle,
Don't grumble, Give a whistle..."
---
--
"When you're chewing on life's gristle,
Don't grumble, Give a whistle..."
-
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: IDE CD problems in 2.6.13rc6
Voluspa wrote:
>
> The "hdparm -I /dev/hdc"
>
> hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
> hdc: drive_cmd: error=0x04 { AbortedCommand }
> de: failed opcode was: 0xec
>
> Is present on all kernels that I have locally (oldest 2.6.11.11)
> so it is not related to the threadstarters problems, it seems.
Hi all,
Maybe teaching you all to suck eggs here, but I used to get this a lot on my
CD's - KDE ran some probe and as the CD[s] where empty logs filled up rapidly
with that error. I thought the[a] drive was duff, so bought a new CD-RW.
Made no difference :-/ I then investigated further, and read that instead of
the SCSI emulation, it was superceded by IDE-CD.
kernel 2.6.12.3
Kernel command line: BOOT_IMAGE=Nicks ro root=303 hdc=ide-cd hdd=ide-cd
Fixed the issue for me. But as I say, teaching to suck eggs, but I thought I
would mention it.
Nick
--
"When you're chewing on life's gristle,
Don't grumble, Give a whistle..."
-
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: These guys can't spell Linux ;)
On Friday 12 August 2005 20:15, Jan Engelhardt wrote: > >>Didn't 'Linux' originate from a mis-spelling of Linus' name when his > >> first account on some box in Helsinki Uni was created /home/linux/? > > > >It was because the ftp admin did not like the original name "freex" so he > > just renamed it to something that suited him well. > > Correction to myself: "freax". Search google for "linus torvalds ftp admin > freax" and maybe add 1991 or 1992 to the list of keywords. OK, I remembered where I read it. A book by Glyn Moody - 'Rebel Code' published 2001 ISBN 0-7382-0333-5. [quote] 'Linus says of a member of the Helsinki University staff called Ari Lemmke. "[Lemmke] had this small area on ftp.funet.fi" - an Internet server at the university where files were stored for visitors to donwload uisng the standard File Transfer Protocol (FTP). "It was called nic.funet.fi at that point, and he said that 'hey, I'm putting a directory aside for you.' So he created the /pub/os/linux diectory,"... "Linux was my working name," Linus continues... [/quote] Buggix was also considered... heh. So, only one man can tell us :-) Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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: [lm-sensors] Re: I2C block reads with i2c-viapro: testers wanted
>> This is a surprising result, as the VT8233 datasheet didn't mention the >> I2C block mode. I'll add this model to the list. This also suggests that >> the VT8233A may support it as well - if someone could test that. >> >> I have to admit I don't know exactly in which order the different south >> bridges were designed and released by VIA. I think the following order >> is correct: >> >> VT82C596 >> VT82C596B >> VT82C686A >> VT82C686B >> VT8235 >> VT8237 >> >> But I don't know where the VT8231, VT8233 and VT8233A should be inserted >> in this list. If anyone can tell me... > > I guess it's just the way it seems: > > VT82C596 > VT82C596B > VT82C686A > VT82C686B > VT8231 > VT8233 > VT8233A > VT8235 > VT8237 I have a VIA board, and remember when I config'ed I2C I was a bit confused with what I have - I guessed logically in the end that VT82C686 _became_ VT82C686A _after_ VT82C686B was released. It all seems to work OK though. bash-2.05b# lspci 00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03) 00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP] 00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22) 00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C/VT8235 PIPC Bus Master IDE (rev 10) 00:07.2 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 10) 00:07.3 USB Controller: VIA Technologies, Inc. VT6202 [USB 2.0 controller] (rev 10) 00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30) 00:09.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) 00:0f.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07) 00:0f.1 Input device controller: Creative Labs SB Live! MIDI/Game Port (rev 07) 01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 MX 440] (rev a3) I am OK for testing the patch if you need. Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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: These guys can't spell Linux ;)
> http://eng.cowon.com/product/iAUDIOU2/feature.html > > Mac and Lynux OS > Use Mac or Lynux? No problem!! > iAUDIO U2 is available to be used on Mac or Lynux OS. Didn't 'Linux' originate from a mis-spelling of Linus' name when his first account on some box in Helsinki Uni was created /home/linux/? I think that is the way the myth goes... Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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: kernel BUG at mm/rmap.c:483!
> But not all cases could be accounted in that way. If you > report back that memtest86 ran cleanly... Hugh, Nothing to do with the 'problem' in this thread, but an aside that is perhaps relevant. On my main gateway, I couldn't get any kernel greater than 2.6.4 to run without an 'oops' after x amount of time. It was always swapd or memory oops that caused it. I ran memtest86 a few times with no errors - reaseated everything, new fans etc. etc. No go. I upgraded memory - all 4 sticks - over Christmas, and after a few weeks uptime, tried 2.4.10 again. I have had no problems since - so perhaps I did have bad memory (it was old). But all tests never showed anything untoward. I was always suspicious why my 2.6.4 build ran OK, but newer builds always failed. Could it be a subtle fault in memory whilst building kernels that does it? Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: make menuconfig
On Monday 14 February 2005 12:45, Roman Zippel wrote: > On Mon, 14 Feb 2005, Nick Warne wrote: > > So I can ignore the debug prints? > > Yes. OK, thanks for your replies. I am since trying 2.6.10 again (with new GCC version and system memory this time), and the messages do not appear in later version of menuconfig as you stated. Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: make menuconfig
On Monday 14 February 2005 12:12, you wrote: > Hi, > > On Mon, 14 Feb 2005, Nick Warne wrote: > > Are the optimize && ? lines normal? > > They are only debug prints, but I'm quite sure they are fixed in recent > versions. > > > This is from a current tree that has an uptime of > 50 days > > Could you specify "current tree"? Yes, sorry, my bad wording. This is kernel 2.6.4 from kernel.org. I meant _my_ 'current' tree that runs perfect on the 233 box. I can't seem to upgrade to later 2.6.x kernels as I get curious swapd oops after a few hours, but that is another story. So I can ignore the debug prints? Thanks, Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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/
make menuconfig
Hi all, I only just noticed this, but been building kernel source for a long time. On my 233 over ssh, it is a bit slow, and I just noticed this output when doing a 'make menuconfig': make[1]: `scripts/fixdep' is up to date. scripts/kconfig/mconf arch/i386/Kconfig optimize && ? optimize && ? optimize && ? optimize && ? Are the optimize && ? lines normal? I investigated, but can't work it out. This is from a current tree that has an uptime of > 50 days - I just needed to change one option in the build, so the existing .config is good. Thanks, Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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: How to disable slow agpgart in kernel config?
On Friday 11 February 2005 22:19, Terence Ripperda wrote: > > > I just read through the nVidia readme file, and there is a > > > comprehensive section on what module to use for what chipset (and > > > card). It recommends using the nVagp for my setup, > > is that the "CONFIGURING AGP" appendix? I didn't think that we > recommended which agp driver to use. the intention was just to > document which chipsets are supported by nvagp and point out that > agpgart may/probably supports more chipsets. that section also > documents some hardware 'issues' that we work around. we work around > these issues regardless of which agp driver is being used. Thats the one. I read this in APPENDIX F: "The following AGP chipsets are supported by NVIDIA's AGP; for all other chipsets it is recommended that you use the AGPGART module." as saying 'if you have one of these chipsets use nVagp' else use agpgart. > for this via kt133 issue, I looked through the agpgart and nvagp > initializations and didn't see anything much different. both > initialize and flush gart mappings the same way. both seem to allocate > memory the same way (nvagp uses __get_free_pages, which eventually > calls alloc_pages) with the GFP_KERNEL flag. I'm not sure why there > would be much difference between the two. I have had no issue at all running agpgart on Slackware 10 with KDE 3.3.x. It was just when I read this thread I didn't realise there was another option of a different NV module. I just tried it after reading deeper in the readme.txt ref. the Quake2 OpenGL 'rippling wave' I get every 5 minutes or so. It fixed it, BTW. I now have a constant clear display 100% in Quake2 :) I haven't noticed any difference at all in 2d desktop stuff (except maybe it is slightly brighter). Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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: How to disable slow agpgart in kernel config?
> > This surprises me, especially considering the in-kernel nvidia-agp driver > > was actually written by NVidia. Are there any agp error messages in > > your dmesg / X log ? > With the nVidia own nv_agp it appears directly in all apps, very fast > under GNOME 2.8.1. Why, I do not know. Also game (opengl) performance is > faster with the nv_agp, that I haven't used the kernel agp for months, now. This is interesting. I always used agpgart without a second thought (2.4.29, GeForce4 MX with Via KT133 chipset). I just read through the nVidia readme file, and there is a comprehensive section on what module to use for what chipset (and card). It recommends using the nVagp for my setup, so I just rebuilt excluding agpgart so I can use the nVdia module. I never had slowness as such in KDE or X apps, but playing quake2 openGL I used to get a 'wave' type effect rippling down the screen occasionally. A quick test using the nVagp module to have fixed that... I will test for a few weeks. Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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: Post install 2.4.29 causes many apps to seg fault.
On Saturday 05 February 2005 02:01, Gary Smith wrote: > Quoting Nick Warne <[EMAIL PROTECTED]>: > > Here is the link that explains it... what to do with many processes > > segfaulting, I don't know. RHEL support is _very_ good - give them a > > ring. > > > > http://people.redhat.com/drepper/assumekernel.html > > > > Nick > > Nick, > > The article seems to make sense about the versioning. I was wondering what > your resolution was. I run two boxes in the UK with RHEL 3 for DNS/DHCP running Lucent's QIP/QMS services (Montreal admins run that). All I am is local SysAdmin on all the other stuff. When I up2dated GLIBC the only thing that went wonky at first was smartmontools (built from src), everything else appeared OK. About 4 days later, I was asked to check why one of the QIP monitoring tools wasn't running (it's a JVM thing, precompiled binaries). I then called the Montreal Linux guy, and he sussed it and told me it was the assume_kernel problem. As it is their area, I never asked what he done exactly to fix it, but he did say that although the GLIBC upgrade broke the tool, once he fixed the problem, it was now working correctly using pthreads (or something) that it wouldn't use before the upgrade. I will ask for more info Monday when back at work. I think Barry K. Nathan reason/problem/solution looks more likely though, re futex in this thread. Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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: Post install 2.4.29 causes many apps to seg fault.
>> Is there something more that I need to compile besides the kernel for >> compatability or is this a sign of some type of bug. I do realize that RHEL3 >> itself has some proprietary items added to their kernel but replacing it >> shouldn't make other applications fails. >> >> Any assistance would be greatly appreciated. >> > If lots of things fail in strange places, I would wonder if your glibc > is compatible with your kernel. I suggest you take it up on a redhat > mailinglist. Yes, I had a similar problems at work when I up2date'd the latest GLIBC for RHEL 3 late last year. A colleague in Montreal (I am in UK) sussed what was going on. I will _presume_ you are seeing similar problems with a kernel build. Here is the link that explains it... what to do with many processes segfaulting, I don't know. RHEL support is _very_ good - give them a ring. http://people.redhat.com/drepper/assumekernel.html Nick -- "When you're chewing on life's gristle, Don't grumble, Give a whistle..." - 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/
