Re: BUG: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on boot
On 10/22/12 07:40, Jacob Shin wrote: > On Sun, Oct 21, 2012 at 02:23:58PM -0700, Tom Rini wrote: >> On 10/21/12 14:06, Jacob Shin wrote: >>> Ah, sorry, this one should apply on top of 3.7-rc2: >>> >>> https://lkml.org/lkml/2012/8/24/469 >>> >>> Could you try that? Just that single patch, not the whole patchset. >> >> That fixes it, replied with a note and Tested-by, thanks! > > Thanks for testing! > > hpa, so sorry, but it looks like we need one more patch [PATCH 2/5] x86: > find_early_table_space based on memory ranges that are being mapped: > > https://lkml.org/lkml/2012/8/24/469 > > on top of this, because find_early_table_space calculation does not come out > correctly for this particular E820 table that Tom has: > > http://pastebin.com/4eSPEAvB > > The reason why we hit this now, and never hit it before is because before the > start was hard coded to 1UL<<32. As a final follow-up, v3.7-rc3 does not have the problem I reported previously. -- Tom -- 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: [PATCHv3] ARM: OMAP2+: am335x-bone*: add DT for BeagleBone Black
On 09/08/2013 07:12 AM, Koen Kooi wrote: > The BeagleBone Black is basically a regular BeagleBone with eMMC and HDMI > added, > so create a common dtsi both can use. > > IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI > transceiver > after a dozen boots with an uSD card inserted because LDO will be at 3.3V > instead > of 1.8. > > MMC support for AM335x still isn't in, so only the LDO change has been added. > > Signed-off-by: Koen Kooi Grabbed my beaglebone white and black and tested them both on top of e5c832d (top of Linus' tree atm), came up with a ramdisk. Tested-by: Tom Rini -- Tom -- 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/
BUG: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on boot
Hello all, I grabbed 3.7-rc2 and found the following on boot: PANIC: early exception 08 rip 246:10 error 81441d7f cr2 0 A git bisect says that this problems came from: 1e779aabe1f0768c2bf8f8c0a5583679b54a is the first bad commit commit 1e779aabe1f0768c2bf8f8c0a5583679b54a Author: Jacob Shin Date: Thu Oct 20 16:15:26 2011 -0500 x86: Exclude E820_RESERVED regions and memory holes above 4 GB from direct mapping. On systems with very large memory (1 TB in our case), BIOS may report a reserved region or a hole in the E820 map, even above the 4 GB range. Exclude these from the direct mapping. The box in question is an Asus motherboard with AMD Phenom(tm) II X6 1100T and 16GB memory. Happy to provide any other information required. -- Tom -- 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: BUG: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on boot
On 10/20/12 17:11, Shin, Jacob wrote: > Hi could you please attach the dmesg output? Before rc2 is fine as well. > I would like to see the E820 table. Thank you, dmesg is quite long so I've put it on pastebin: http://pastebin.com/4eSPEAvB -- Tom -- 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: BUG: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on boot
On 10/20/12 21:18, Jacob Shin wrote: > On Sat, Oct 20, 2012 at 09:01:43PM -0700, Yinghai Lu wrote: >> On Sat, Oct 20, 2012 at 5:17 PM, Tom Rini wrote: >>> On 10/20/12 17:11, Shin, Jacob wrote: >>>> Hi could you please attach the dmesg output? Before rc2 is fine as well. >>>> I would like to see the E820 table. Thank you, >>> >>> dmesg is quite long so I've put it on pastebin: http://pastebin.com/4eSPEAvB >>> >>> -- >> >> [0.00] BIOS-e820: [mem 0x00011000-0x00042fff] usable >> >> pre-calculate table size is too small, so it crashes. > > Right, > > I think just this one patch 3/6 on top of -rc2 should work: > > https://lkml.org/lkml/2012/8/29/223 > > That would be a simpler path for 3.7, It doesn't apply easily (for me) on top of 3.7-rc2 however. Happy to test a patch on top of 3.7-rc2 when you're able to. -- Tom -- 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: BUG: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on boot
On 10/20/12 21:01, Yinghai Lu wrote: > On Sat, Oct 20, 2012 at 5:17 PM, Tom Rini wrote: >> On 10/20/12 17:11, Shin, Jacob wrote: >>> Hi could you please attach the dmesg output? Before rc2 is fine as well. >>> I would like to see the E820 table. Thank you, >> >> dmesg is quite long so I've put it on pastebin: http://pastebin.com/4eSPEAvB >> >> -- > > [0.00] BIOS-e820: [mem 0x00011000-0x00042fff] usable > > pre-calculate table size is too small, so it crashes. > > can you please try > > git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git > for-x86-mm > > and post bootlog? This boots but I'm bisecting another failure later on and can't post the boot log (just finished bisecting that issue now). -- Tom -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5] x86: find_early_table_space based on memory ranges that are being mapped
On Fri, Aug 24, 2012 at 06:55:13PM -0500, Jacob Shin wrote: > Current logic finds enough space for direct mapping page tables from 0 > to end. Instead, we only need to find enough space to cover mr[0].start > to mr[nr_range].end -- the range that is actually being mapped by > init_memory_mapping() > > This patch also reportedly fixes suspend/resume issue reported in: > > https://lkml.org/lkml/2012/8/11/83 > > Signed-off-by: Jacob Shin This fixes a bug I see that was introduced in 1e7 Tested-by: Tom Rini -- Tom -- 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: BUG: 1bbbbe7 (x86: Exclude E820_RESERVED regions...) PANIC on boot
On 10/21/12 14:06, Jacob Shin wrote: > On Sun, Oct 21, 2012 at 10:51:35AM -0700, Tom Rini wrote: >> On 10/20/12 21:18, Jacob Shin wrote: >>> On Sat, Oct 20, 2012 at 09:01:43PM -0700, Yinghai Lu wrote: >>>> On Sat, Oct 20, 2012 at 5:17 PM, Tom Rini wrote: >>>>> On 10/20/12 17:11, Shin, Jacob wrote: >>>>>> Hi could you please attach the dmesg output? Before rc2 is fine as well. >>>>>> I would like to see the E820 table. Thank you, >>>>> >>>>> dmesg is quite long so I've put it on pastebin: >>>>> http://pastebin.com/4eSPEAvB >>>>> >>>>> -- >>>> >>>> [0.00] BIOS-e820: [mem 0x00011000-0x00042fff] >>>> usable >>>> >>>> pre-calculate table size is too small, so it crashes. >>> >>> Right, >>> >>> I think just this one patch 3/6 on top of -rc2 should work: >>> >>> https://lkml.org/lkml/2012/8/29/223 >>> >>> That would be a simpler path for 3.7, >> >> It doesn't apply easily (for me) on top of 3.7-rc2 however. Happy to >> test a patch on top of 3.7-rc2 when you're able to. > > Ah, sorry, this one should apply on top of 3.7-rc2: > > https://lkml.org/lkml/2012/8/24/469 > > Could you try that? Just that single patch, not the whole patchset. That fixes it, replied with a note and Tested-by, thanks! -- Tom -- 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: compile x86_64 waring
On 07/24/2013 05:05 PM, Paul Bolle wrote:
> [Added Tom and Rusty because they might be able to say what's really
> going on here.]
>
> On Fri, 2013-07-05 at 19:56 +0800, majianpeng wrote:
>> Compile x86_64 meet those messages:
>> WARNING: arch/x86/mm/built-in.o(.text.unlikely+0xbf8): Section mismatch in
>> reference from the function __node_set.constprop.0() to the variable
>> .init.data:numa_nodes_parsed
>> The function __node_set.constprop.0() references
>> the variable __initdata numa_nodes_parsed.
>> This is often because __node_set.constprop.0 lacks a __initdata
>> annotation or the annotation of numa_nodes_parsed is wrong.
>>
>> WARNING: arch/x86/built-in.o(.text.unlikely+0x171d): Section mismatch in
>> reference from the function __node_set.constprop.0() to the variable
>> .init.data:numa_nodes_parsed
>> The function __node_set.constprop.0() references
>> the variable __initdata numa_nodes_parsed.
>> This is often because __node_set.constprop.0 lacks a __initdata
>> annotation or the annotation of numa_nodes_parsed is wrong.
>
> 0) I noticed these too, on v3.11-rc1 and v3.12.-rc2. I assume Jianpeng
> Ma reported these for a linux-next release that preceded v3.11-rc1.
>
> 1) The only hits for node_set and numa_nodes_parsed in arch/x86/mm are
> in amdtopology.c, numa.c, and srat.c. If I peek at the object files
> generated for these three files I notice that numa.o and srat.o have
> node_set() in their .text.unlikely section. (amdtopology.o doesn't have
> a .text.unlikely section.)
>
> 2) I guess that since commit 06df44ee41442d83be061c5fd1b1de4f5fc6fbbf
> ("modpost.c: Add .text.unlikely to TEXT_SECTIONS"), which was included
> in v3.11-rc1, code in .text.unlikely sections generates a mismatch
> warning if it references __initdata code (and numa_nodes_parsed is
> __initdata). But all calls of node_set() in these two files are from
> within functions that are marked __init. And I think references from
> __init code to __initdata code shouldn't lead to mismatch warnings,
> should they?
>
> 3) So this looks like a false positive to me (but I'm not at all
> familiar with, well, the section mismatch checks). Would there be a way
> to silence this warning? Other than dropping __initdata from
> numa_nodes_parsed, of course.
I suspect you have a real problem, in that either numa_nodes_parsed
needs to not be __initdata (as it's being called by both __init and
non-__init functions, and hence the problem), or the other caller(s) of
numa_nodes_parsed need to also be __init. Is this seen in top-of-tree
Linus? If so, I can take a peek took, if someone shoots me a config
file. Thanks!
--
Tom
--
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] numa: Mark __node_set as __always_inline
It is posible for some compilers to decide that __node_set does not need
to be made turned into an inline function. When the compiler does this
on an __init function calling it on __initdata we get a section mismatch
warning now.
Reported-by: Paul Bolle
Cc: Jianpeng Ma
Cc: Rusty Russell
Cc: Lai Jiangshan
Cc: Yasuaki Ishimatsu
Cc: Wen Congyang
Cc: Jiang Liu
Cc: KOSAKI Motohiro
Cc: Minchan Kim
Cc: Mel Gorman
Cc: David Rientjes
Cc: Yinghai Lu
Cc: Greg KH
Signed-off-by: Tom Rini
---
include/linux/nodemask.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/nodemask.h b/include/linux/nodemask.h
index 4e2cbfa..10d0fd9 100644
--- a/include/linux/nodemask.h
+++ b/include/linux/nodemask.h
@@ -99,7 +99,7 @@ typedef struct { DECLARE_BITMAP(bits, MAX_NUMNODES); }
nodemask_t;
extern nodemask_t _unused_nodemask_arg_;
#define node_set(node, dst) __node_set((node), &(dst))
-static inline void __node_set(int node, volatile nodemask_t *dstp)
+static __always_inline void __node_set(int node, volatile nodemask_t *dstp)
{
set_bit(node, dstp->bits);
}
--
1.7.9.5
--
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: compile x86_64 waring
On 07/25/2013 05:41 AM, Paul Bolle wrote:
> Tom,
>
> On Thu, 2013-07-25 at 10:53 +0200, Paul Bolle wrote:
>> But I've just pulled top-of-tree Linus, ie commit 07bc9dc1b0
>> ("git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc'"). I'll
>> try to build that and I 'll send you my .config if this all is still
>> triggered.
>
> It is still seen with "make bzImage" at v3.11-rc2-185-g07bc9dc (current
> Linus' tip-of-tree). I get, in summary:
> WARNING: arch/x86/mm/built-in.o(.text.unlikely+0xbf2): Section mismatch
> in reference from the function __node_set.constprop.0() to the variable
> .init.data:numa_nodes_parsed
> WARNING: arch/x86/built-in.o(.text.unlikely+0x140e): Section mismatch in
> reference from the function __node_set.constprop.0() to the variable
> .init.data:numa_nodes_parsed
> WARNING: vmlinux.o(.text.unlikely+0x1444): Section mismatch in reference
> from the function __node_set.constprop.0() to the variable
> .init.data:numa_nodes_parsed
>
> But it is all the same thing (the issue apparently just repeat itself
> when arch/x86/mm/built-in.o is merged into arch/x86/built-in.o, and
> again when arch/x86/built-in.o is merged into vmlinux.o).
OK, thanks. I just posted a patch that fixes the warning here. The
problem is that __node_set wasn't being inlined by the compiler, so you
have the section mis-match above.
--
Tom
--
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] numa: Mark __node_set as __always_inline
On 07/25/2013 02:08 PM, KOSAKI Motohiro wrote:
> (7/25/13 8:14 AM), Tom Rini wrote:
>> It is posible for some compilers to decide that __node_set does not need
>> to be made turned into an inline function. When the compiler does this
>> on an __init function calling it on __initdata we get a section mismatch
>> warning now.
>>
>> Reported-by: Paul Bolle
>> Cc: Jianpeng Ma
>> Cc: Rusty Russell
>> Cc: Lai Jiangshan
>> Cc: Yasuaki Ishimatsu
>> Cc: Wen Congyang
>> Cc: Jiang Liu
>> Cc: KOSAKI Motohiro
>> Cc: Minchan Kim
>> Cc: Mel Gorman
>> Cc: David Rientjes
>> Cc: Yinghai Lu
>> Cc: Greg KH
>> Signed-off-by: Tom Rini
>> ---
>> include/linux/nodemask.h |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/include/linux/nodemask.h b/include/linux/nodemask.h
>> index 4e2cbfa..10d0fd9 100644
>> --- a/include/linux/nodemask.h
>> +++ b/include/linux/nodemask.h
>> @@ -99,7 +99,7 @@ typedef struct { DECLARE_BITMAP(bits, MAX_NUMNODES); }
>> nodemask_t;
>> extern nodemask_t _unused_nodemask_arg_;
>>
>> #define node_set(node, dst) __node_set((node), &(dst))
>> -static inline void __node_set(int node, volatile nodemask_t *dstp)
>> +static __always_inline void __node_set(int node, volatile nodemask_t *dstp)
>
> The change looks ok. But, this code doesn't tell us why you changed. Please
> write
> down proper comments here.
Done, v2 submitted.
--
Tom
--
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 v2] numa: Mark __node_set as __always_inline
It is posible for some compilers to decide that __node_set does not need
to be made turned into an inline function. When the compiler does this
on an __init function calling it on __initdata we get a section mismatch
warning now. Use __always_inline to ensure that we will be inlined.
Reported-by: Paul Bolle
Cc: Jianpeng Ma
Cc: Rusty Russell
Cc: Lai Jiangshan
Cc: Yasuaki Ishimatsu
Cc: Wen Congyang
Cc: Jiang Liu
Cc: KOSAKI Motohiro
Cc: Minchan Kim
Cc: Mel Gorman
Cc: David Rientjes
Cc: Yinghai Lu
Cc: Greg KH
Signed-off-by: Tom Rini
---
Changes in v2:
- As per KOSAKI Motohiro, add a comment as well about why we need
__always_inline to the header.
---
include/linux/nodemask.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/linux/nodemask.h b/include/linux/nodemask.h
index 4e2cbfa..58b9a02 100644
--- a/include/linux/nodemask.h
+++ b/include/linux/nodemask.h
@@ -98,8 +98,17 @@
typedef struct { DECLARE_BITMAP(bits, MAX_NUMNODES); } nodemask_t;
extern nodemask_t _unused_nodemask_arg_;
+/*
+ * The inline keyword gives the compiler room to decide to inline, or
+ * not inline a function as it sees best. However, as these functions
+ * are called in both __init and non-__init functions, if they are not
+ * inlined we will end up with a section mis-match error (of the type of
+ * freeable items not being freed). So we must use __always_inline here
+ * to fix the problem. If other functions in the future also end up in
+ * this situation they will also need to be annotated as __always_inline
+ */
#define node_set(node, dst) __node_set((node), &(dst))
-static inline void __node_set(int node, volatile nodemask_t *dstp)
+static __always_inline void __node_set(int node, volatile nodemask_t *dstp)
{
set_bit(node, dstp->bits);
}
--
1.7.9.5
--
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] modpost.c: Add .text.unlikely to TEXT_SECTIONS
On 04/30/2013 10:19 PM, Rusty Russell wrote: > Tom Rini writes: >> On 04/28/2013 10:59 PM, Rusty Russell wrote: >>> Tom Rini writes: >>> >>>> Recent gcc's may place functions into the .text.unlikely section and we >>>> need to check this section as well for section mismatches now otherwise >>>> we may have false negatives for this test. >>> >>> Hmm, I don't think it's all that recent, is it? I can find it back to >>> gcc 4.0.4: >>> >>> `-freorder-functions' >>> Reorder functions in the object file in order to improve code >>> locality. This is implemented by using special subsections >>> `.text.hot' for most frequently executed functions and >>> `.text.unlikely' for unlikely executed functions. Reordering is >>> done by the linker so object file format must support named >>> sections and linker must place them in a reasonable way. >>> >>> Also profile feedback must be available in to make this option >>> effective. See `-fprofile-arcs' for details. >>> >>> Enabled at levels `-O2', `-O3', `-Os'. >>> >>> The comment is the same in in gcc 4.7. >>> >>> So is your real issue that this section is generated with >>> -fprofile-arcs, or has something changed with gcc 4.8, or...? >> >> I've started seeing this with Linaro based 4.7 toolchains. I can go >> back through their releases and see when it starts showing up there if >> it helps. I didn't add .text.hot as I didn't have that section at all, >> fwiw. > > Weird, did you turn on CONFIG_GCOV_KERNEL? AFAICT you shouldn't see > this section without that. Nope, CONFIG_GCOV_KERNEL is off. Must be related to whatever flags the Linaro folks set as default on -O2 (at least in their 2013.03 release), after reading over one of the .o.cmd files in the build. Do you want me to re-word the commit message a bit or ? Thanks! -- Tom -- 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] modpost.c: Add .text.unlikely to TEXT_SECTIONS
On 05/01/2013 07:18 AM, Tom Rini wrote: > On 04/30/2013 10:19 PM, Rusty Russell wrote: >> Tom Rini writes: >>> On 04/28/2013 10:59 PM, Rusty Russell wrote: >>>> Tom Rini writes: >>>> >>>>> Recent gcc's may place functions into the .text.unlikely section and we >>>>> need to check this section as well for section mismatches now otherwise >>>>> we may have false negatives for this test. >>>> >>>> Hmm, I don't think it's all that recent, is it? I can find it back to >>>> gcc 4.0.4: >>>> >>>> `-freorder-functions' >>>> Reorder functions in the object file in order to improve code >>>> locality. This is implemented by using special subsections >>>> `.text.hot' for most frequently executed functions and >>>> `.text.unlikely' for unlikely executed functions. Reordering is >>>> done by the linker so object file format must support named >>>> sections and linker must place them in a reasonable way. >>>> >>>> Also profile feedback must be available in to make this option >>>> effective. See `-fprofile-arcs' for details. >>>> >>>> Enabled at levels `-O2', `-O3', `-Os'. >>>> >>>> The comment is the same in in gcc 4.7. >>>> >>>> So is your real issue that this section is generated with >>>> -fprofile-arcs, or has something changed with gcc 4.8, or...? >>> >>> I've started seeing this with Linaro based 4.7 toolchains. I can go >>> back through their releases and see when it starts showing up there if >>> it helps. I didn't add .text.hot as I didn't have that section at all, >>> fwiw. >> >> Weird, did you turn on CONFIG_GCOV_KERNEL? AFAICT you shouldn't see >> this section without that. > > Nope, CONFIG_GCOV_KERNEL is off. Must be related to whatever flags the > Linaro folks set as default on -O2 (at least in their 2013.03 release), > after reading over one of the .o.cmd files in the build. > > Do you want me to re-word the commit message a bit or ? Thanks! I poked around, and every Linaro binary I can grab (2012.01 and gcc 4.6 to 2013.04 and gcc 4.8) has this behaviour. -- Tom -- 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] modpost.c: Add .text.unlikely to TEXT_SECTIONS
Recent gcc's may place functions into the .text.unlikely section and we need to check this section as well for section mismatches now otherwise we may have false negatives for this test. Cc: Rusty Russell Cc: Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org Cc: linux-kbu...@vger.kernel.org Signed-off-by: Tom Rini --- scripts/mod/modpost.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c index ff36c50..13ff12f 100644 --- a/scripts/mod/modpost.c +++ b/scripts/mod/modpost.c @@ -880,7 +880,7 @@ static void check_section(const char *modname, struct elf_info *elf, #define ALL_EXIT_SECTIONS EXIT_SECTIONS, ALL_XXXEXIT_SECTIONS #define DATA_SECTIONS ".data$", ".data.rel$" -#define TEXT_SECTIONS ".text$" +#define TEXT_SECTIONS ".text$", ".text.unlikely$" #define INIT_SECTIONS ".init.*" #define CPU_INIT_SECTIONS ".cpuinit.*" -- 1.7.9.5 -- 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] modpost.c: Add .text.unlikely to TEXT_SECTIONS
On 04/28/2013 10:59 PM, Rusty Russell wrote: > Tom Rini writes: > >> Recent gcc's may place functions into the .text.unlikely section and we >> need to check this section as well for section mismatches now otherwise >> we may have false negatives for this test. > > Hmm, I don't think it's all that recent, is it? I can find it back to > gcc 4.0.4: > > `-freorder-functions' > Reorder functions in the object file in order to improve code > locality. This is implemented by using special subsections > `.text.hot' for most frequently executed functions and > `.text.unlikely' for unlikely executed functions. Reordering is > done by the linker so object file format must support named > sections and linker must place them in a reasonable way. > > Also profile feedback must be available in to make this option > effective. See `-fprofile-arcs' for details. > > Enabled at levels `-O2', `-O3', `-Os'. > > The comment is the same in in gcc 4.7. > > So is your real issue that this section is generated with > -fprofile-arcs, or has something changed with gcc 4.8, or...? I've started seeing this with Linaro based 4.7 toolchains. I can go back through their releases and see when it starts showing up there if it helps. I didn't add .text.hot as I didn't have that section at all, fwiw. -- Tom -- 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 v3 0/3] DaVinci DMA engine conversion
On Wed, Aug 22, 2012 at 09:09:33PM -0400, Matt Porter wrote: [snip] > Matt Porter (3): > dmaengine: add TI EDMA DMA engine driver > mmc: davinci_mmc: convert to DMA engine API > spi: spi-davinci: convert to DMA engine API > > drivers/dma/Kconfig| 10 + > drivers/dma/Makefile |1 + > drivers/dma/edma.c | 671 > > drivers/mmc/host/davinci_mmc.c | 271 +--- > drivers/spi/spi-davinci.c | 292 - > include/linux/edma.h | 29 ++ > 6 files changed, 923 insertions(+), 351 deletions(-) > create mode 100644 drivers/dma/edma.c > create mode 100644 include/linux/edma.h On the Logic PD AM1808 EVM: mmc0 rootfs: http://pastebin.com/HKVdmA0G jffs2 on the SPI flash rootfs: http://pastebin.com/cpAHgdug Tested-by: Tom Rini -- Tom signature.asc Description: Digital signature
Re: [PATCH] 2.4.3 and SysRq over serial console
On Tue, Apr 03, 2001 at 09:07:44PM +0100, Russell King wrote: > On Sat, Mar 31, 2001 at 04:38:08PM -0700, Tom Rini wrote: > > Hello all. Without the attached patch, SysRq doesn't work over a serial > > console here. Has anyone else seen this problem? > > It is handled at the serial port driver level, not the tty level. You need > to turn on CONFIG_SERIAL_CONSOLE and CONFIG_MAGIC_SYSRQ, and issue a break > followed by the relevent character within 5 seconds on the serial TTY being > used as the kernel console. That wasn't working here however. Unless minicom isn't sending the proper break. Doing the keycombo which slips my mind to send a break, followed by 'h' in minicom does nothing. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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] 2.4.3 and SysRq over serial console
On Tue, Apr 03, 2001 at 09:07:44PM +0100, Russell King wrote: > On Sat, Mar 31, 2001 at 04:38:08PM -0700, Tom Rini wrote: > > Hello all. Without the attached patch, SysRq doesn't work over a serial > > console here. Has anyone else seen this problem? > > It is handled at the serial port driver level, not the tty level. You need > to turn on CONFIG_SERIAL_CONSOLE and CONFIG_MAGIC_SYSRQ, and issue a break > followed by the relevent character within 5 seconds on the serial TTY being > used as the kernel console. After talking with the person who originally did the patch, yeah, that does make sense (and the serial driver we're using needs to be fixed). Thanks. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: CML2 1.1.4 is available
On Tue, Apr 17, 2001 at 02:13:35PM -0400, Eric S. Raymond wrote: > The latest version is always available at http://www.tuxedo.org/~esr/cml2/ > > Release 1.1.4: Tue Apr 17 14:02:17 EDT 2001 > * Tom Rini's patches for the ARM port tree. Er, that should read PPC. :) > * Correct handling of booleans when trits are disabled. > * `nohelp' tie symbol introduced. > * Code audited with PyChecker. [snip] > So let's try to shift our attention to auditing and fixing the rules files, > shall we? Well, I've got more to come anyways. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
On Fri, Apr 20, 2001 at 10:59:34AM -0400, Eric S. Raymond wrote: > Alan Cox <[EMAIL PROTECTED]>: > > > well, though. One is the kind I'm bumping into right now, where > > > somebody legitimately needs to make small (almost trivial) changes > > > scattered all through the tree. > > > > Yep. But such changes are rare. Or should be. > > Knowing that doesn't help me much, since I'm trying to fix up a global > namespace that touches everybody :-(. Which does boil down to having to work with trees other than Linus or Alans. Remember, the official tree is not always the up-to-date tree, or in the case of other arches, the most relevant tree. But if you send something off to a maintainer, there's a good chance (if they're still active) they'll do what you ask, and it'll get to Linus/Alan the next time they sync. As long as the problem gets fixed, it shouldn't be as important if it's fixed in everyones tree right now, or in a release or two. If it's some sort of huge bug it just might get fixed sooner. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
On Fri, Apr 20, 2001 at 12:35:12PM -0400, Nicolas Pitre wrote: > There is kind of a ridiculous situation here where people want to withhold > their own changes in their own trees for all good reasons until it is mature > and stable enough to be fed upstream in the appropriate way, while insisting > for Linus' tree to remain incomplete and inconsistent. And we're not > talking about deep architectural changes here -- only about configure > symbols and help text. The answer is simple, noise. > Why not having everybody's tree consistent with themselves and have whatever > CONFIGURE_* symbols and help text be merged along with the very code it > refers to? It's worthless to have config symbols be merged into Linus' or > Alan's tree if the code isn't there (yet). It simply makes no sense. Well, this depends a lot on a) The project to be merged (arch, mtd, whatever) and b) how far something has gotten in being merged someplace else, and of course c) the maintainer(s). Whatever the exact case, and in general, it should be handled via the maintainer. Why? They maintain the code. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: [parisc-linux] Re: OK, let's try cleaning up another nit. Is anyone paying attention?
On Fri, Apr 20, 2001 at 02:48:18PM -0400, Nicolas Pitre wrote: > > > On Fri, 20 Apr 2001, Tom Rini wrote: > > > On Fri, Apr 20, 2001 at 12:35:12PM -0400, Nicolas Pitre wrote: > > > > > Why not having everybody's tree consistent with themselves and have whatever > > > CONFIGURE_* symbols and help text be merged along with the very code it > > > refers to? It's worthless to have config symbols be merged into Linus' or > > > Alan's tree if the code isn't there (yet). It simply makes no sense. > > > > Well, this depends a lot on a) The project to be merged (arch, mtd, whatever) > > and b) how far something has gotten in being merged someplace else, and of > > course c) the maintainer(s). Whatever the exact case, and in general, it > > should be handled via the maintainer. Why? They maintain the code. > > Therefore it's the maintainer's job to submit coherent patches and accept to > see inconsistent CONFIG_* references be removed from the official tree until > further patch submission is due. It's only a question of discipline. > Otherwise how can you distinguish between dead wood which must be removed > and potentially valid symbols referring to code existing only in a remote > tree? Er, I think we agree, but I'm not sure. :) The only people who actually know the difference between dead wood and partily merged code are the maintainers. IMHO it's silly to remove a piece of code like: #ifdef CONFIG_SOMETHING_NOT_MERGED ... #endif If the rest of the code, which would make the above useful is heading toward Linus. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: [upatch] lib/Makefile
On Mon, Apr 23, 2001 at 05:16:24PM -0500, Peter Samuelson wrote: > Introduced in 2.4.4pre4, I believe. $(export-objs) need not be > conditional, and the if statement was not really correct either, > although in this case it probably worked. Er, are you sure changing the test for !"nn" is correct here? I _think_ at least that is intentional and correct (since you can have one on but not the other). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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/
CONFIG_MODVERSIONS and same named files
Hey all. The modversions code has a slight problem with files of the same name, but in different directories. eg: drivers/a/foo.c exports FOO, and drivers/b/foo.c exports BAR, include/linux/modules/foo.ver will only have the information about drivers/b/foo.c. Anyone got an idea on how to fix this? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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] make nfsroot accept server addresses from BOOTP root
On Mon, Feb 19, 2001 at 06:12:12PM -0500, Ben LaHaise wrote: > Here's a handy little patch that makes the kernel parse out the ip > address of the nfs server from the bootp root path. Otherwise it's > impossible to boot the kernel without command line options on diskless > workstations (I hate RPL). Er, say that again? Right now, for bootp if you specify "sa=xxx.xxx.xxx.xxx" Linux uses that as the host for the NFS server (which does have the side effect of if TFTP server != NFS server, you don't boot). Are you saying your patch takes "rp=xxx.xxx.xxx.xxx:/foo/root" ? Just curious, since I don't know, whats the RFC say about this? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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] make nfsroot accept server addresses from BOOTP root
On Tue, Feb 20, 2001 at 01:12:28PM -0500, Ben LaHaise wrote: > On Tue, 20 Feb 2001, Tom Rini wrote: > > > Er, say that again? Right now, for bootp if you specify "sa=xxx.xxx.xxx.xxx" > > Linux uses that as the host for the NFS server (which does have the side > > effect of if TFTP server != NFS server, you don't boot). Are you saying > > your patch takes "rp=xxx.xxx.xxx.xxx:/foo/root" ? Just curious, since I > > don't know, whats the RFC say about this? > > Yeah, that's the problem I was trying to work around, mostly because the Er, the problem of having to use sa (which is TFTP server) to specify the NFS server? > docs on dhcpd are sufficiently vague and obscure. Personally, I don't > actually need tftp support, so I've just configured the system to now > point at the NFS server. For anyone who cares, the last patch was wrong, > this one is right. If the RFC doesn't say anything about the format rp= has to be in, this is probably right. Assuming it works. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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] make nfsroot accept server addresses from BOOTP root
On Tue, Feb 20, 2001 at 11:02:10PM +, Russell King wrote:
> Ben LaHaise writes:
> > Yeah, that's the problem I was trying to work around, mostly because the
> > docs on dhcpd are sufficiently vague and obscure. Personally, I don't
> > actually need tftp support, so I've just configured the system to now
> > point at the NFS server. For anyone who cares, the last patch was wrong,
> > this one is right.
>
> This is the dhcp entry for a host that I use to tftp a kernel from a
> different machine to that running dhcpd:
>
> host tasslehoff
> {
> hardware ethernet 00:10:57:00:03:EC;
> fixed-address tasslehoff;
> next-server raistlin;
> filename"/usr/src/k/tasslehoff";
> }
>
> The booting host is called "tasslehoff". The tftp server host is called
> "raistlin", and the dhcp server is called "flint".
>
> According to Tom, this should also cause Linux to nfs mount from the
> "next-server" address, and it is fair that this is not documented by
> the dhcp man pages since it appears to be a Linux Kernel quirk.
Well, assuming next-server gets translated into TFTP server by the
dhcp-doing-bootp bit, yes. I'm using that right now to bootp on
one box and NFS off another.
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
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: [linux-fbdev] [PATCH] clgenfb on PPC
On Wed, Jan 03, 2001 at 01:50:46PM +0100, Geert Uytterhoeven wrote: > On Tue, 2 Jan 2001, Tom Rini wrote: > > Hey all. While going through the 2.4 tree and removing dead CONFIG_xxx's for > > PPC stuff, I noticed clgenfb still had CONFIG_PREP stuff (which may have > > partily explained why it no longer worked here). I've attached a patch, that > > with another patch to fix some PCI issues on certain machines, gives me a > > working (so far, can't test heavily yet tho) framebuffer on my powerstack. > > > > Comments? > > To me it looks like most of them depend on `big endian', not on `PReP'. Possibly... I don't have or know anyone with the MacPicasso video card, which is the only other card which may have this. :) > BTW, doesn't the Cirrus Logic graphics chip have a big endian aperture? I > don't like things like green.offset = -3, since it will probably break some > applications (did you run X?). I finally got the machine up w/ an nfsroot, and played around a bit. w/o the patch (ie isPReP always 0) I don't get a console, but a few lines of pixels in a row, and random pixels here and there. Since the original logic was for PReP only, I'm inclined to think that keeping it at just _machine == _MACH_prep is the safest way to go, for the moment. BTW, with or w/o the patch, XF4 (fbdev) wouldn't quite work right. The logs didn't indicate anything wrong, but the monitor went black, like X was starting, but never did. (ShadowFB on / off) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: gcc 2.95.2 is buggy
On Thu, Nov 23, 2000 at 11:47:04PM -0500, Alexander Viro wrote: > > > On Thu, 23 Nov 2000, Gregory Maxwell wrote: > > > On Fri, Nov 24, 2000 at 02:57:45AM +0100, [EMAIL PROTECTED] wrote: > > > but in the meantime there is good confirmation. > > > This really is a bug in gcc 2.95.2. > > > > ... RedHat's GCC snapshot "2.96" handles this case just fine. > > Now, if you can isolate the relevant part of the diff between 2.95.2 and > RH 2.96... Well, now that there is a testcase, has anyone sent this on to the relevant gcc lists? (The CCs I saw haven't) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] modutils 2.3.20 and beyond
On Sun, Nov 26, 2000 at 05:03:34PM -0700, Jeff V. Merkey wrote: > Great. Then tell RedHat to rewrite it without the need for these switches. > They will say NO. It's a trivial change, and would save me a lot of hours > rewriting scripts. I did it once, but if RedHat has standardized on this > set of switches, why not add them as alias commands? It's a trivial > patch. I hate to jump in here in the middle of a perfectly good argument but I'd like to point out a few things: a) If RedHat/RedHat-like distros needs these changes they can include this patch. The plus side is it won't piss off the people that seem to care and don't use said distros the down side is that if/when another security update comes out people will have to hope this patch applies easily still, if they update themselves. b) Are these switches which used to be valid in modutils 2.3.x? If so, why? It makes perfect sense to keep this patch around until modutils 2.4 (or 2.5 if modutils version is still supposed to match kernel version). If these are old modutils 2.2.x switches, see part a). And c) Why does it matter if RedHat/etc would have to adapt their scripts. There's always part a, or what debian does for stable sometimes, backporting fixes. Or even lots of sed & awk magic. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] modutils 2.3.20 and beyond
On Sun, Nov 26, 2000 at 07:46:43PM -0700, Jeff V. Merkey wrote: > Anaconda is open sourced, so it's not technically tied to any one > distributor any more Technically, yes it is opensourced. But one of the things that does kinda distinguish one distro from another is the installer[1]. So yes, it is opensource. So, counter-question. Why should this non distro owned program require a specific distro's program? :) But this all of course a moot point. [1] The sum difference between YellowDogLinux 1.0, LinuxPPC, Inc 1999 and LinuxPPC Reference Release was that two changed/help port the installer the 3rd did, which was RedHat's newt-based installer. Some confusion ensused. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre24
On Wed, Nov 29, 2000 at 02:09:59AM +, Alan Cox wrote:
...
> 2.2.18pre21
...
> o Resnchronize Apple PowerMac codebase(Paul Mackerras & co)
> o Merge powermac tree fixes into usb
> o Powermac input device handling changes
As Dave Miller pointed out, DEV_MAC_HID sysctl conflicts with the RAID patches
which are in much wider use. And as nothing yet uses this sysctl, I've
attached a patch vs pre24 which changes the number from 3 to 5 (which is what
2.4.0-testX uses.)
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
--- linux/include/linux/sysctl.h.orig Wed Nov 29 15:01:09 2000
+++ linux/include/linux/sysctl.hWed Nov 29 15:01:25 2000
@@ -435,7 +435,7 @@
enum {
DEV_CDROM=1,
DEV_HWMON=2,
- DEV_MAC_HID=3
+ DEV_MAC_HID=5
};
/* /proc/sys/dev/cdrom */
Re: Linux 2.2.18pre24
On Thu, Nov 30, 2000 at 06:17:40PM +0100, Andrea Arcangeli wrote: > On Wed, Nov 29, 2000 at 03:01:59PM -0700, Tom Rini wrote: > > As Dave Miller pointed out, DEV_MAC_HID sysctl conflicts with the RAID patches > > That's right but OTOH I'd simply declare the sysctl-by-number interface dead > for new introduced sysctl. We need to preserve backwards compatibility of > course but that's not a problem. I'd preferred if we killed it completly (just > providing backwards compatibility) during the 2.4.x cycle. Only reliable > way to use new sysctl is sysctl-by-name IMHO. Right. But the problem here was a new, unused sysctl-by-number, conflicted with an old-but-not-integrated sysctl-by-number that is used. :) The only reason I made the number match the one in 2.4 was because a) i figured it's not going to conflict. :) and b) incase something does come along and use it. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-test12-pre7
On Thu, Dec 07, 2000 at 08:01:13PM +0100, Kai Germaschewski wrote: > Maybe I'm stating something which is obvious to everybody, but note > that pci_assign_unassigned_resources is only called from Possibly, but I don't know either. :) > ./arch/alpha/kernel/pci.c: pci_assign_unassigned_resources(); > ./arch/mips/ddb5074/pci.c: pci_assign_unassigned_resources(); > ./arch/arm/kernel/bios32.c: pci_assign_unassigned_resources(); > > so it looks like most archs don't use it anyway. (And that's supposedly > why pci_set_master helped people on x86) You're assuming all arches are up to date. Silly you. :) I know there's a patch to use this for some PReP (PPC) machines. It's quite possible other arches might be using this but aren't synced up to Linus. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[rgooch@ras.ucalgary.ca: Re: devfs config patch]
- Forwarded message from Richard Gooch <[EMAIL PROTECTED]> - Date: Sat, 2 Sep 2000 23:34:55 -0600 From: Richard Gooch <[EMAIL PROTECTED]> To: Tom Rini <[EMAIL PROTECTED]> Subject: Re: devfs config patch In-Reply-To: <[EMAIL PROTECTED]> Tom Rini writes: > > Hello. I've attached a minor config patch for devfs. It's vs 2.4.0-test7 > but really should be fine vs your current version. Basically, I made > the mount & debug config options dependant on devfs being set first. > This removes 2 extra lines from .config when devfs isn't used (cosmetic) > and if you later choose to use devfs, the mount & debug options aren't already > set for you. > > --- fs/Config.in.orig Sat Sep 2 19:49:13 2000 > +++ fs/Config.in Sat Sep 2 19:50:04 2000 > @@ -44,8 +44,10 @@ > bool '/proc file system support' CONFIG_PROC_FS > > dep_bool '/dev file system support (EXPERIMENTAL)' CONFIG_DEVFS_FS >$CONFIG_EXPERIMENTAL > -dep_bool ' Automatically mount at boot' CONFIG_DEVFS_MOUNT $CONFIG_DEVFS_FS > -dep_bool ' Debug devfs' CONFIG_DEVFS_DEBUG $CONFIG_DEVFS_FS > +if [ "$CONFIG_DEVFS" != "n" ] ; then > + dep_bool ' Automatically mount at boot' CONFIG_DEVFS_MOUNT $CONFIG_DEVFS_FS > + dep_bool ' Debug devfs' CONFIG_DEVFS_DEBUG $CONFIG_DEVFS_FS > +fi This is what I had originally. It looks like someone has changed it. Complain to Linus (and send him your patch). Please Cc: me so I can see any discussions that might ensue. Regards, Richard Permanent: [EMAIL PROTECTED] Current: [EMAIL PROTECTED] - End forwarded message - In keeping with Richards wishes, what happened? Did this just get accidently backed out, or was it intentional? I know there are a few other config options which are like this (inital ramdisk is set to n if ramdisk is m, all of the raid options are set to n if raid is n, instead of being not set at all). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Tue, Sep 12, 2000 at 03:00:29PM +0100, Paul Jakma wrote: > On Mon, 11 Sep 2000, Alan Cox wrote: > > > Shrug. So you want me to make it worse by shipping unproven code in a way > > I can't test it ? > > > > the code is in 2.4 and has been tested there though. the patches are a > backport of the 2.4 code. ..so it should be at least as well tested as the USB backport in 2.2.18preX, if not more so? Or so is implied. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: New topic (PowerPC Linux PCI HELL)
On Thu, Sep 14, 2000 at 09:59:35AM +0200, Vojtech Pavlik wrote:
> On Wed, Sep 13, 2000 at 05:29:58PM -0700, Andre Hedrick wrote:
>
> > Okay who can teach me how to force hooks and ram this down the PPC
> >
> > pci_write_config_word(dev, PCI_COMMAND, 0x05);
> >
> > I have all the address registered.
> > My new PPC G3 (7600/132) toy is not allowing IO's on PCI cards to come
> > alive. Thus I get some of the most beuatiful lockups ever.
> > I suspect that this needs to be handled down in the arch.
> >
> > ./linux/arch/ppc/kernel/{chrp_pci.c|mbx_pci.c|pmac_pci.c|prep_pci.c}
> >
> > Basically I can not get the IO's active, regardless of BIOS on the card.
> > Yes this is the old trick that used to work of making ix86 cards run in
> > non ix86-pci slots.
> >
> > Here is the fun part, I have a native mac/ppc Ultra-66 card that is fin
> > under Mac OS, but the IO's are not enable in linux and it crash like a big
> > dog also.
>
> The same happens for OHCI on new Macs. The correct function to use is:
>
> pci_enable_device(dev);
>
> This function will enable the i/o, mem and irqs, and assign them if they
> were not assigned for some reason, too.
Once all the PCI oddities are worked out of 2.4.0-testX on PPC, yes :)
Right now I have to disable that call in aic7xxx to use my adaptec card
(none of the pci patches yet seem to work on all machines).
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
On Mon, Sep 18, 2000 at 05:11:35PM +0100, David Woodhouse wrote: > > [EMAIL PROTECTED] said: > > Linus, > > > Where do architecture maintainers stand when they don't submit their > > problems to linux-kernel or the great Ted Bug List(tm)? > > Up against the wall so we can shoot them? I know that was a joke, but it's a good question. I know PPC still has some issues that need to be sorted out (We got lots of PCI resource collisions on most(all?) new machines, which really shouldn't be). I'm sure other arches have problems which haven't been posted on l-k but have been on their respective -dev list. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2 (version numbering)
On Tue, Sep 19, 2000 at 09:26:44PM -0700, Barry K. Nathan wrote: > > to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like > > small stuff (maybe my memory just sucks tho). > > I don't think there ever were any 2.2.0-testX patches - my recollection is > that we went from 2.1.1xx to 2.2.0-preX, with no -testX in between like we > seem to be having now. Ah yes, oops. I also then think people are assuming (possibly wrongly) that 2.4.0-testX == 2.4.0-preX. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 09:36:30PM -0700, David Ford wrote: > Tom Rini wrote: > > > >that. I see that 2.4 is getting all kinds of changes merged in > > >that should be going on with 2.5. The recent VM changes have left > > >us with deadlocks that we didn't have before. Shouldn't that have > > >gone into 2.5 not 2.4? > > Well, I think the bitterness comes from (partily anyways) it going into > > 2.4.0-test9-pre1, along with other seemingly large updates, which did need > > to go in but really don't sound right for a -test. I guess Linus didn't want > > to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like > > small stuff (maybe my memory just sucks tho). > > The VM work has been scheduled to go in for a while. If you check the TODO > emails from months back, it's always been there. I wasn't arguing that (really) it's just that it really should have gone in sooner. It's all really a moot point I understand, but still. major overhauls should get in before the -testX IMHO. This is the point I think Cort was going after. Sure it's been well tested. But it's a major rewrite and it has introduced deadlocks (I'm going to have to track one down myself I think, this weekend) that weren't there. I'm sure it also fixed some. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fs/nls/Config.in
Hello all. The attached patch changes the behavoir of fs/nls/Config.in from: CONFIG_SMB_FS != n to CONFIG_INET = y && CONFIG_SMB_FS != n. This is neeed because if CONFIG_INET isn't set, CONFIG_SMB_FS isn't asked about and therefor isn't set at all, so CONFIG_NLS is set to y. My only question about this patch is if it shouldn't have depended on CONFIG_SMB_NLS_DEFAULT to start with? (Maintainer CC'ed). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs/nls/Config.in
On Thu, Oct 19, 2000 at 07:55:42PM +0200, Sven Krohlas wrote: > Hello, > > > Hello all. The attached patch changes the behavoir of fs/nls/Config.in from: > > There's nothing attached...? D'oh. Look now. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- fs/nls/Config.in.orig Thu Oct 19 09:11:48 2000 +++ fs/nls/Config.inThu Oct 19 09:49:53 2000 @@ -4,8 +4,13 @@ # msdos and Joliet want NLS if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \ - -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \ - -o "$CONFIG_SMB_FS" != "n" ]; then + -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" ]; then + define_bool CONFIG_NLS y +else + define_bool CONFIG_NLS n +fi + +if [ "$CONFIG_INET" = "y" -a "$CONFIG_SMB_FS" != "n" ]; then define_bool CONFIG_NLS y else define_bool CONFIG_NLS n
Re: [PATCH] fs/nls/Config.in
On Thu, Oct 19, 2000 at 08:29:47PM +, Petr Vandrovec wrote: > It is not correct. At first, duplicated define_bool breaks xconfig (AFAIK), > and worse, first test is ignored at all by your code. Maybe something > like (untested) > > if [ "$CONFIG_SMB_FS" = "m" -o "$CONFIG_SMB_FS" = "y" ]; then > define_bool CONFIG_SMB_NLS y > else > define_bool CONFIG_SMB_NLS n > fi > > if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \ > -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \ > -o "$CONFIG_SMB_NLS" = "y"; then > define_bool CONFIG_NLS y > else > define_bool CONFIG_NLS n > fi > > could work (I did not checked whether CONFIG_FAT_FS & CONFIG_NTFS_FS > are always defined). This works as well, and FAT and NTFS are always defined. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fs/nls/Config.in -- Take 2
Hello again all. I've taken what Petr suggested and put into a patch. Now, are there any suggestions this time around? I'm still wondering if the whole thing shouldn't be dependant on CONFIG_SMB_NLS_DEFAULT, but since I don't know the smbfs code at all, I can't say. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- fs/nls/Config.in.orig Thu Oct 19 12:54:09 2000 +++ fs/nls/Config.inThu Oct 19 12:54:32 2000 @@ -2,10 +2,17 @@ # Native language support configuration # +# smb wants NLS +if [ "$CONFIG_SMB_FS" = "m" -o "$CONFIG_SMB_FS" = "y" ]; then + define_bool CONFIG_SMB_NLS y +else + define_bool CONFIG_SMB_NLS n +fi + # msdos and Joliet want NLS if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \ -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \ - -o "$CONFIG_SMB_FS" != "n" ]; then + -o "$CONFIG_SMB_NLS" = "y" ]; then define_bool CONFIG_NLS y else define_bool CONFIG_NLS n
Re: [PATCH] fs/nls/Config.in
On Thu, Oct 19, 2000 at 10:20:25PM +0200, Urban Widmark wrote: > On Thu, 19 Oct 2000, Tom Rini wrote: > > > Hello all. The attached patch changes the behavoir of fs/nls/Config.in from: > > CONFIG_SMB_FS != n to CONFIG_INET = y && CONFIG_SMB_FS != n. This is neeed > > because if CONFIG_INET isn't set, CONFIG_SMB_FS isn't asked about and > > therefor isn't set at all, so CONFIG_NLS is set to y. My only question about > > this patch is if it shouldn't have depended on CONFIG_SMB_NLS_DEFAULT to start > > with? (Maintainer CC'ed). > It was supposed to be ok to not have a default nls value set but still be > able to activate nls if you want to. Giving it the old no-nls behaviour > until you say otherwise. Missing support from smbmount is the main reason > for having the default. Ah, ok. > One solution might be to change the smbfs config to look more like the > ncpfs config and force a 'n' value if CONFIG_INET isn't 'y'. Patch for > this below, but the second patch you sent looks fine too. You didn't say > which kernel version you are using ... Sorry, this was on 2.4.0-test10-pre3, but I'm sure it applies to a good deal of 2.4.0-testX. > You could also try the cml2 config tool. The cml2 config language is much > better at handling unset values and the current version has no problems > with this (n is the same as undefined, as I understand it). > http://www.tuxedo.org/~esr/kbuild > (if you test it, kernel-rules.cml may need a search&replace of INTEGRATOR > with ARCH_INTEGRATOR) CML2 later, hopefully. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fs/nls/Config.in -- Again
This is the suggestion that Petr made and was approved by the maintainer. Can we get this in 2.4.0-test10-pre6 please? Without this patch, if you have CONFIG_INET turned off, you have to go through the CONFIG_NLS stuffs. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- fs/nls/Config.in.orig Thu Oct 19 12:54:09 2000 +++ fs/nls/Config.inThu Oct 19 12:54:32 2000 @@ -2,10 +2,17 @@ # Native language support configuration # +# smb wants NLS +if [ "$CONFIG_SMB_FS" = "m" -o "$CONFIG_SMB_FS" = "y" ]; then + define_bool CONFIG_SMB_NLS y +else + define_bool CONFIG_SMB_NLS n +fi + # msdos and Joliet want NLS if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \ -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \ - -o "$CONFIG_SMB_FS" != "n" ]; then + -o "$CONFIG_SMB_NLS" = "y" ]; then define_bool CONFIG_NLS y else define_bool CONFIG_NLS n
Re: [PATCH] make my life easier ...
On Wed, Oct 25, 2000 at 01:42:52PM +0200, Martin Mares wrote: > Hello! > > > "The Linux 'original' IDE guy' Mark Lord showed Alan what was trying to > > bang over everyone's head, without success. > > > > Here is his sample code for cs5530 chipset. > > > > Look at this and comment. I have part of the space setup to complete the > > APM extenstion calls. This will get you and me out of a jam with laptops. > > This doesn't make much sense to me: Why don't we just reinitialize the timings > as we do when programming the chipset instead of saving/restoring the state? Aside from all of the other comments that've been made, because the user might have tweeked them at boot. ie turn on UDMA. If we just re-initalized on wakeup, you loose this. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test10
On Tue, Oct 31, 2000 at 12:41:55PM -0800, Linus Torvalds wrote: > Ok, test10-final is out there now. This has no _known_ bugs that I > consider show-stoppers, for what it's worth. Sure, it's not a critical bug or anything but hey. One more time: This is a very minor patch for fs/nls/Config.in, which Petr Vandrovec came up with. The problem is that if CONFIG_INET is n, CONFIG_SMB_FS is never set so fs/nls/Config.in assumes that the user wants to select some NLS options. This fixes it and works on config/menuconfig/xconfig. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- fs/nls/Config.in.orig Thu Oct 19 12:54:09 2000 +++ fs/nls/Config.inThu Oct 19 12:54:32 2000 @@ -2,10 +2,17 @@ # Native language support configuration # +# smb wants NLS +if [ "$CONFIG_SMB_FS" = "m" -o "$CONFIG_SMB_FS" = "y" ]; then + define_bool CONFIG_SMB_NLS y +else + define_bool CONFIG_SMB_NLS n +fi + # msdos and Joliet want NLS if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \ -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \ - -o "$CONFIG_SMB_FS" != "n" ]; then + -o "$CONFIG_SMB_NLS" = "y" ]; then define_bool CONFIG_NLS y else define_bool CONFIG_NLS n
Re: Where did kgcc go in 2.4.0-test10 ?
On Wed, Nov 01, 2000 at 11:30:50PM +, Alan Cox wrote: > > Yes, but what's more important is that all of these "kgcc" variants are > > gcc 2.7.2.x-based (unless there's one I don't know about). And we don't want > > 2.7.2.x, we want egcs 1.1.2 or newer (but not gcc 2.9x, unless you know what > > you're doing and are trying to fix the compiler. :)). > > Conectiva kgcc is egcs 1.1.2 > Red Hat kgcc is egcs 1.1.2 > Mandrake kgcc I believe is egcs 1.1.2 heh, ok. i'm wrong. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test11-pre1
On Tue, Nov 07, 2000 at 01:06:27PM -0800, Linus Torvalds wrote: > Mostly driver updates. > > With a few notable exceptions: two rather subtle MM race conditions that > happened with SMP and highmem respectively. And the FXCSR and file locking > that was already discussed on the list. I've once again attached this very small patch for !CONFIG_INET. Summary: This is a very minor patch for fs/nls/Config.in, which Petr Vandrovec came up with. The problem is that if CONFIG_INET is n, CONFIG_SMB_FS is never set so fs/nls/Config.in assumes that the user wants to select some NLS options. This fixes it and works on config/menuconfig/xconfig. It's been ok'ed by the SMB maintainer, so could this please go in? This is still vs 2.4.10-test8 or so, but the file hasn't changed any, nor has the problem, so... -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ --- fs/nls/Config.in.orig Thu Oct 19 12:54:09 2000 +++ fs/nls/Config.inThu Oct 19 12:54:32 2000 @@ -2,10 +2,17 @@ # Native language support configuration # +# smb wants NLS +if [ "$CONFIG_SMB_FS" = "m" -o "$CONFIG_SMB_FS" = "y" ]; then + define_bool CONFIG_SMB_NLS y +else + define_bool CONFIG_SMB_NLS n +fi + # msdos and Joliet want NLS if [ "$CONFIG_JOLIET" = "y" -o "$CONFIG_FAT_FS" != "n" \ -o "$CONFIG_NTFS_FS" != "n" -o "$CONFIG_NCPFS_NLS" = "y" \ - -o "$CONFIG_SMB_FS" != "n" ]; then + -o "$CONFIG_SMB_NLS" = "y" ]; then define_bool CONFIG_NLS y else define_bool CONFIG_NLS n
Re: Linux 2.2.18 almost...
On Sat, Dec 09, 2000 at 11:00:41PM +, Alan Cox wrote: > The patch I intend to be 2.2.18 is out as 2.2.18pre26 in the usual place. > I'll move it over tomorrow if nobody reports any horrors, missing files etc I haven't checked anywhere yet, but is there a changelog someplace? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] aty128fb & >8bit
Hello. I just noticed that in 2.2.18pre27 you can only use the aty128fb driver at 8 bit, because of some missing bits to drivers/video/Config.in. w/o this you can't use console at > 8 bit nor X. I would consider this to be a good thing to squash for 2.2.18 final because 2.2.18 is the 1st release in a while that works well on PPC, and lots of PPCs have a rage128. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ = drivers/video/Config.in 1.10 vs edited = --- 1.10/drivers/video/Config.inFri Oct 20 22:20:29 2000 +++ edited/drivers/video/Config.in Sun Dec 10 13:33:45 2000 @@ -188,7 +188,8 @@ "$CONFIG_FB_VALKYRIE" = "y" -o "$CONFIG_FB_PLATINUM" = "y" -o \ "$CONFIG_FB_IGA" = "y" -o "$CONFIG_FB_MATROX" = "y" -o \ "$CONFIG_FB_CT65550" = "y" -o "$CONFIG_FB_PM2" = "y" -o \ -"$CONFIG_FB_SGIVW" = "y" -o "$CONFIG_FB_CYBER2000" = "y" ]; then +"$CONFIG_FB_SGIVW" = "y" -o "$CONFIG_FB_CYBER2000" = "y" -o \ +"$CONFIG_FB_ATY128" = "y" ]; then define_bool CONFIG_FBCON_CFB8 y else if [ "$CONFIG_FB_ACORN" = "m" -o "$CONFIG_FB_ATARI" = "m" -o \ @@ -202,14 +203,15 @@ "$CONFIG_FB_VALKYRIE" = "m" -o "$CONFIG_FB_PLATINUM" = "m" -o \ "$CONFIG_FB_IGA" = "m" -o "$CONFIG_FB_MATROX" = "m" -o \ "$CONFIG_FB_CT65550" = "m" -o "$CONFIG_FB_PM2" = "m" -o \ - "$CONFIG_FB_SGIVW" = "m" -o "$CONFIG_FB_CYBER2000" = "m" ]; then + "$CONFIG_FB_SGIVW" = "m" -o "$CONFIG_FB_CYBER2000" = "m" -o \ + "$CONFIG_FB_ATY128" = "m" ]; then define_bool CONFIG_FBCON_CFB8 m fi fi if [ "$CONFIG_FB_ATARI" = "y" -o "$CONFIG_FB_ATY" = "y" -o \ "$CONFIG_FB_MAC" = "y" -o "$CONFIG_FB_VESA" = "y" -o \ "$CONFIG_FB_VIRTUAL" = "y" -o "$CONFIG_FB_TBOX" = "y" -o \ -"$CONFIG_FB_Q40" = "y" -o \ +"$CONFIG_FB_Q40" = "y" -o "$CONFIG_FB_ATY128" = "y" -o \ "$CONFIG_FB_CONTROL" = "y" -o "$CONFIG_FB_CLGEN" = "y" -o \ "$CONFIG_FB_VIRGE" = "y" -o "$CONFIG_FB_CYBER" = "y" -o \ "$CONFIG_FB_VALKYRIE" = "y" -o "$CONFIG_FB_PLATINUM" = "y" -o \ @@ -221,7 +223,7 @@ if [ "$CONFIG_FB_ATARI" = "m" -o "$CONFIG_FB_ATY" = "m" -o \ "$CONFIG_FB_MAC" = "m" -o "$CONFIG_FB_VESA" = "m" -o \ "$CONFIG_FB_VIRTUAL" = "m" -o "$CONFIG_FB_TBOX" = "m" -o \ -"$CONFIG_FB_Q40" = "m" -o \ + "$CONFIG_FB_Q40" = "m" -o "$CONFIG_FB_ATY128" = "m" -o \ "$CONFIG_FB_CONTROL" = "m" -o "$CONFIG_FB_CLGEN" = "m" -o \ "$CONFIG_FB_VIRGE" = "m" -o "$CONFIG_FB_CYBER" = "m" -o \ "$CONFIG_FB_VALKYRIE" = "m" -o "$CONFIG_FB_PLATINUM" = "m" -o \ @@ -233,14 +235,14 @@ fi if [ "$CONFIG_FB_ATY" = "y" -o "$CONFIG_FB_VIRTUAL" = "y" -o \ "$CONFIG_FB_CLGEN" = "y" -o "$CONFIG_FB_VESA" = "y" -o \ - "$CONFIG_FB_MATROX" = "y" -o "$CONFIG_FB_PM2" = "y" -o \ -"$CONFIG_FB_CYBER2000" = "y" ]; then +"$CONFIG_FB_MATROX" = "y" -o "$CONFIG_FB_PM2" = "y" -o \ +"$CONFIG_FB_CYBER2000" = "y" -o "$CONFIG_FB_ATY128" = "y" ]; then define_bool CONFIG_FBCON_CFB24 y else if [ "$CONFIG_FB_ATY" = "m" -o "$CONFIG_FB_VIRTUAL" = "m" -o \ "$CONFIG_FB_CLGEN" = "m" -o "$CONFIG_FB_VESA" = "m" -o \ "$CONFIG_FB_MATROX" = "m" -o "$CONFIG_FB_PM2" = "m" -o \ - "$CONFIG_FB_CYBER2000" = "m" ]; then + "$CONFIG_FB_CYBER2000" = "m" -o "$CONFIG_FB_ATY128" = "m" ]; then define_bool CONFIG_FBCON_CFB24 m fi fi @@ -249,7 +251,8 @@ "$CONFIG_FB_CONTROL" = "y" -o "$CONFIG_FB_CLGEN" = "y" -o \ "$CONFIG_FB_TGA" = "y" -o "$CONFIG_FB_PLATINUM" = "y" -o \ "$CONFIG_FB_MATROX" = "y" -o "$CONFIG_FB_PM2" = "y" -o \ -"$CONFIG_FB_FM2" = "y" -o "$CONFIG_FB_SGIVW" = "y" ]; then +"$CONFIG_FB_FM2" = "y" -o "$CONFIG_FB_SGIVW" = "y" -o \ +"$CONFIG_FB_ATY128" = "y" ]; then define_bool CONFIG_FBCON_CFB32 y else if [ "$CONFIG_FB_ATARI" = "m" -o "$CONFIG_FB_ATY" = "m" -o \ @@ -257,7 +260,7 @@ "$CONFIG_FB_CONTROL" = "m" -o "$CONFIG_FB_CLGEN" = "m" -o \ "$CONFIG_FB_TGA" = "m" -o "$CONFIG_FB_PLATINUM" = "m" -o \ "$CONFIG_FB_MATROX" = "m" -o "$CONFIG_FB_PM2" = "m" -o \ - "$CONFIG_FB_SGIVW" = "m" ]; then + "$CONFIG_FB_SGIVW" = "m" -o "$CONFIG_FB_ATY128" = "m" ]; then define_bool CONFIG_FBCON_CFB32 m fi fi
Re: test13-pre1 changelog
On Thu, Dec 14, 2000 at 03:31:54PM -0800, Linus Torvalds wrote: > I'm hoping that most of the fall-out from switching over exclusively to > the new-style Makefiles will be over in a day or two, at which point > I'll make a pre2 that is worth announcing. Does this mean other arches will have a chance to sync in 2.4.0-test13? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.19pre1
On Fri, Dec 15, 2000 at 07:51:04PM +, Alan Cox wrote: > Ok this is the first block of changes before we merge the VM stuff. This is > mostly the bits left over from the 2.2.18 port that were deferred as too > risky near the end of a prerelease set and some bug swats I believe Brad Douglas has soemthing for aty128fb as well, but the attached patch defines the correct CONFIG_FBCON_CFBXXs for aty128. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ = drivers/video/Config.in 1.10 vs edited = --- 1.10/drivers/video/Config.inFri Oct 20 22:20:29 2000 +++ edited/drivers/video/Config.in Sun Dec 10 13:33:45 2000 @@ -188,7 +188,8 @@ "$CONFIG_FB_VALKYRIE" = "y" -o "$CONFIG_FB_PLATINUM" = "y" -o \ "$CONFIG_FB_IGA" = "y" -o "$CONFIG_FB_MATROX" = "y" -o \ "$CONFIG_FB_CT65550" = "y" -o "$CONFIG_FB_PM2" = "y" -o \ -"$CONFIG_FB_SGIVW" = "y" -o "$CONFIG_FB_CYBER2000" = "y" ]; then +"$CONFIG_FB_SGIVW" = "y" -o "$CONFIG_FB_CYBER2000" = "y" -o \ +"$CONFIG_FB_ATY128" = "y" ]; then define_bool CONFIG_FBCON_CFB8 y else if [ "$CONFIG_FB_ACORN" = "m" -o "$CONFIG_FB_ATARI" = "m" -o \ @@ -202,14 +203,15 @@ "$CONFIG_FB_VALKYRIE" = "m" -o "$CONFIG_FB_PLATINUM" = "m" -o \ "$CONFIG_FB_IGA" = "m" -o "$CONFIG_FB_MATROX" = "m" -o \ "$CONFIG_FB_CT65550" = "m" -o "$CONFIG_FB_PM2" = "m" -o \ - "$CONFIG_FB_SGIVW" = "m" -o "$CONFIG_FB_CYBER2000" = "m" ]; then + "$CONFIG_FB_SGIVW" = "m" -o "$CONFIG_FB_CYBER2000" = "m" -o \ + "$CONFIG_FB_ATY128" = "m" ]; then define_bool CONFIG_FBCON_CFB8 m fi fi if [ "$CONFIG_FB_ATARI" = "y" -o "$CONFIG_FB_ATY" = "y" -o \ "$CONFIG_FB_MAC" = "y" -o "$CONFIG_FB_VESA" = "y" -o \ "$CONFIG_FB_VIRTUAL" = "y" -o "$CONFIG_FB_TBOX" = "y" -o \ -"$CONFIG_FB_Q40" = "y" -o \ +"$CONFIG_FB_Q40" = "y" -o "$CONFIG_FB_ATY128" = "y" -o \ "$CONFIG_FB_CONTROL" = "y" -o "$CONFIG_FB_CLGEN" = "y" -o \ "$CONFIG_FB_VIRGE" = "y" -o "$CONFIG_FB_CYBER" = "y" -o \ "$CONFIG_FB_VALKYRIE" = "y" -o "$CONFIG_FB_PLATINUM" = "y" -o \ @@ -221,7 +223,7 @@ if [ "$CONFIG_FB_ATARI" = "m" -o "$CONFIG_FB_ATY" = "m" -o \ "$CONFIG_FB_MAC" = "m" -o "$CONFIG_FB_VESA" = "m" -o \ "$CONFIG_FB_VIRTUAL" = "m" -o "$CONFIG_FB_TBOX" = "m" -o \ -"$CONFIG_FB_Q40" = "m" -o \ + "$CONFIG_FB_Q40" = "m" -o "$CONFIG_FB_ATY128" = "m" -o \ "$CONFIG_FB_CONTROL" = "m" -o "$CONFIG_FB_CLGEN" = "m" -o \ "$CONFIG_FB_VIRGE" = "m" -o "$CONFIG_FB_CYBER" = "m" -o \ "$CONFIG_FB_VALKYRIE" = "m" -o "$CONFIG_FB_PLATINUM" = "m" -o \ @@ -233,14 +235,14 @@ fi if [ "$CONFIG_FB_ATY" = "y" -o "$CONFIG_FB_VIRTUAL" = "y" -o \ "$CONFIG_FB_CLGEN" = "y" -o "$CONFIG_FB_VESA" = "y" -o \ - "$CONFIG_FB_MATROX" = "y" -o "$CONFIG_FB_PM2" = "y" -o \ -"$CONFIG_FB_CYBER2000" = "y" ]; then +"$CONFIG_FB_MATROX" = "y" -o "$CONFIG_FB_PM2" = "y" -o \ +"$CONFIG_FB_CYBER2000" = "y" -o "$CONFIG_FB_ATY128" = "y" ]; then define_bool CONFIG_FBCON_CFB24 y else if [ "$CONFIG_FB_ATY" = "m" -o "$CONFIG_FB_VIRTUAL" = "m" -o \ "$CONFIG_FB_CLGEN" = "m" -o "$CONFIG_FB_VESA" = "m" -o \ "$CONFIG_FB_MATROX" = "m" -o "$CONFIG_FB_PM2" = "m" -o \ - "$CONFIG_FB_CYBER2000" = "m" ]; then + "$CONFIG_FB_CYBER2000" = "m" -o "$CONFIG_FB_ATY128" = "m" ]; then define_bool CONFIG_FBCON_CFB24 m fi fi @@ -249,7 +251,8 @@ "$CONFIG_FB_CONTROL" = "y" -o "$CONFIG_FB_CLGEN" = "y" -o \ "$CONFIG_FB_TGA" = "y" -o "$CONFIG_FB_PLATINUM" = "y" -o \ "$CONFIG_FB_MATROX" = "y" -o "$CONFIG_FB_PM2" = "y" -o \ -"$CONFIG_FB_FM2" = "y" -o "$CONFIG_FB_SGIVW" = "y" ]; then +"$CONFIG_FB_FM2" = "y" -o "$CONFIG_FB_SGIVW" = "y" -o \ +"$CONFIG_FB_ATY128" = "y" ]; then define_bool CONFIG_FBCON_CFB32 y else if [ "$CONFIG_FB_ATARI" = "m" -o "$CONFIG_FB_ATY" = "m" -o \ @@ -257,7 +260,7 @@ "$CONFIG_FB_CONTROL" = "m" -o "$CONFIG_FB_CLGEN" = "m" -o \ "$CONFIG_FB_TGA" = "m" -o "$CONFIG_FB_PLATINUM" = "m" -o \ "$CONFIG_FB_MATROX" = "m" -o "$CONFIG_FB_PM2" = "m" -o \ - "$CONFIG_FB_SGIVW" = "m" ]; then + "$CONFIG_FB_SGIVW" = "m" -o "$CONFIG_FB_ATY128" = "m" ]; then define_bool CONFIG_FBCON_CFB32 m fi fi
Re: PowerPC branch out of date
On Fri, Dec 29, 2000 at 02:40:41PM -0200, Rik van Riel wrote: > On Fri, 29 Dec 2000 [EMAIL PROTECTED] wrote: > > > How it's got there etc etc etc at this stage isn't important. > > First how to fix it and how to make sure it doesn't happen again > > does concern me. > > > I would REALLY appreciate it if this could be made to happen. > > Send patches to Linus and Alan ? test13-pre5-acXX is up-to-date with everything that's important anyways. Weather that makes it into Linus' tree is the important and unknown bit. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: test13-pre5
On Thu, Dec 28, 2000 at 12:25:23PM -0800, Linus Torvalds wrote: > - pre5: >- NIIBE Yutaka: SuperH update >- Geert Uytterhoeven: m68k update >- David Miller: TCP RTO calc fix, UDP multicast fix etc >- Duncan Laurie: ServerWorks PIRQ routing definition. >- mm PageDirty cleanups, added sanity checks, and don't lose the bit. I just noticed this (playing with some other stuff), but ext2 as a module is currently broken: $ make INSTALL_MOD_PATH=/tmp/foo modules_install ... if [ -r System.map ]; then /sbin/depmod -ae -F System.map -b /tmp/foo -r 2.4.0-test12; fi depmod: *** Unresolved symbols in /tmp/foo/lib/modules/2.4.0-test12/kernel/fs/ext2/ext2.o depmod: buffer_insert_inode_queue depmod: fsync_inode_buffers I tried the following locally and it fixes it. -- --- fs/Makefile.origFri Dec 29 10:35:50 2000 +++ fs/Makefile Fri Dec 29 10:36:06 2000 @@ -7,7 +7,7 @@ O_TARGET := fs.o -export-objs := filesystems.o +export-objs := filesystems.o buffer.o mod-subdirs := nls obj-y := open.o read_write.o devices.o file_table.o buffer.o \ --- fs/buffer.c.origFri Dec 29 10:33:21 2000 +++ fs/buffer.c Fri Dec 29 10:35:46 2000 @@ -29,6 +29,7 @@ /* async buffer flushing, 1999 Andrea Arcangeli <[EMAIL PROTECTED]> */ #include +#include #include #include #include @@ -579,6 +580,8 @@ spin_unlock(&lru_list_lock); } +EXPORT_SYMBOL(buffer_insert_inode_queue); + /* The caller must have the lru_list lock before calling the remove_inode_queue functions. */ static void __remove_inode_queue(struct buffer_head *bh) @@ -900,6 +903,7 @@ return err2; } +EXPORT_SYMBOL(fsync_inode_buffers); /* * osync is designed to support O_SYNC io. It waits synchronously for -- -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4test-ac merge status
On Sun, Dec 31, 2000 at 02:17:12AM +, Alan Cox wrote: > This is to help give folks an idea of what -ac stuff has been pushed to Linus, > is still in need of work, has been dumped in the bitbucket of bad ideas etc > > Most of the important driver stuff is now in the Linus tree. There are a few > I'd like to see sorted before 2.4.0 release still. I'll be working on those > as a priority. Other stuff like the fusion drivers can wait. I'm sure at least a few people want to know where the PowerPC port falls in all of that. :) ...hopeing we aren't in the bitbucket.. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4test-ac merge status
On Sun, Dec 31, 2000 at 02:33:50AM +, Alan Cox wrote: > > I'm sure at least a few people want to know where the PowerPC port falls in > > all of that. :) > > > > ...hopeing we aren't in the bitbucket.. > > It might be the ppc port is 2.4.0ac1 and 2.4.2 Linus or something. I don't think > that is likely to be a big problem. I need to get on top of 2.2.19pre4 and > the rest of the Linus resync then I'm going to dump chunks of stuff out of > -ac and try and get a nice clean -ac tree. If folks want to sync non x86 > ports with that initially go ahead. Oh well. I guess our problem is we can never get Linus to notice the smaller chunks and he always seems to hate big patches. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.0-prerelease
On Sun, Dec 31, 2000 at 02:38:16PM -0800, J Sloan wrote: > Of course, adding > > #include > > to drivers/char/drm/drmP.h makes it all work Right, but that _shouldn't_ be needed. iirc, modversions.h should be included when needed, so this is covering up the bug not fixing it. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] clgenfb on PPC
Hey all. While going through the 2.4 tree and removing dead CONFIG_xxx's for
PPC stuff, I noticed clgenfb still had CONFIG_PREP stuff (which may have
partily explained why it no longer worked here). I've attached a patch, that
with another patch to fix some PCI issues on certain machines, gives me a
working (so far, can't test heavily yet tho) framebuffer on my powerstack.
Comments?
Also, rivafb needs something similar to this, but since no PReP boxes I know
of anyways ship with something rivafb controlls, it's probably easier to just
remove the bits inside CONFIG_PREP
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
# This is a BitKeeper generated patch for the following project:
# Project Name:
# This patch format is intended for GNU patch command version 2.5 or higher.
# This patch includes the following deltas:
# ChangeSet1.393.1.12 -> 1.393.1.13
# drivers/video/clgenfb.c 1.19-> 1.20
#
# The following is the BitKeeper ChangeSet Log
#
# 00/12/27 [EMAIL PROTECTED] 1.393.1.13
# Fix up clgenfb.
#
#
diff -Nru a/drivers/video/clgenfb.c b/drivers/video/clgenfb.c
--- a/drivers/video/clgenfb.c Tue Jan 2 09:42:09 2001
+++ b/drivers/video/clgenfb.c Tue Jan 2 09:42:09 2001
@@ -56,6 +56,12 @@
#ifdef CONFIG_AMIGA
#include
#endif
+#ifdef CONFIG_ALL_PPC
+#include
+#define isPReP (_machine == _MACH_prep)
+#else
+#define isPReP 0
+#endif
#include
#include
@@ -876,15 +882,15 @@
case 16:
_par->line_length = _par->var.xres_virtual * 2;
_par->visual = FB_VISUAL_DIRECTCOLOR;
-#ifdef CONFIG_PREP
- _par->var.red.offset = 2;
- _par->var.green.offset = -3;
- _par->var.blue.offset = 8;
-#else
- _par->var.red.offset = 10;
- _par->var.green.offset = 5;
- _par->var.blue.offset = 0;
-#endif
+ if(isPReP) {
+ _par->var.red.offset = 2;
+ _par->var.green.offset = -3;
+ _par->var.blue.offset = 8;
+ } else {
+ _par->var.red.offset = 10;
+ _par->var.green.offset = 5;
+ _par->var.blue.offset = 0;
+ }
_par->var.red.length = 5;
_par->var.green.length = 5;
_par->var.blue.length = 5;
@@ -893,15 +899,15 @@
case 24:
_par->line_length = _par->var.xres_virtual * 3;
_par->visual = FB_VISUAL_DIRECTCOLOR;
-#ifdef CONFIG_PREP
- _par->var.red.offset = 8;
- _par->var.green.offset = 16;
- _par->var.blue.offset = 24;
-#else
- _par->var.red.offset = 16;
- _par->var.green.offset = 8;
- _par->var.blue.offset = 0;
-#endif
+ if(isPReP) {
+ _par->var.red.offset = 8;
+ _par->var.green.offset = 16;
+ _par->var.blue.offset = 24;
+ } else {
+ _par->var.red.offset = 16;
+ _par->var.green.offset = 8;
+ _par->var.blue.offset = 0;
+ }
_par->var.red.length = 8;
_par->var.green.length = 8;
_par->var.blue.length = 8;
@@ -910,15 +916,15 @@
case 32:
_par->line_length = _par->var.xres_virtual * 4;
_par->visual = FB_VISUAL_DIRECTCOLOR;
-#ifdef CONFIG_PREP
- _par->var.red.offset = 8;
- _par->var.green.offset = 16;
- _par->var.blue.offset = 24;
-#else
- _par->var.red.offset = 16;
- _par->var.green.offset = 8;
- _par->var.blue.offset = 0;
-#endif
+ if(isPReP) {
+ _par->var.red.offset = 8;
+ _par->var.green.offset = 16;
+ _par->var.blue.offset = 24;
+ } else {
+ _par->var.red.offset = 16;
+ _par->var.green.offset = 8;
+ _par->var.blue.offset = 0;
+ }
_par->var.red.length = 8;
_par->var.green.length = 8;
_par->var.blue.length = 8;
@@ -1680,18 +1686,18 @@
#ifdef FBCON_HAS_CFB16
case 16:
assert (regno < 16);
-#ifdef CONFIG_PREP
- fb_info->fbcon_cmap.cfb16[regno] =
- ((red & 0xf800) >> 9) |
- ((green & 0xf800) >> 14) |
- ((green & 0xf800) << 2) |
- ((blue & 0xf800) >&
Re: [linux-fbdev] [PATCH] clgenfb on PPC
On Wed, Jan 03, 2001 at 01:50:46PM +0100, Geert Uytterhoeven wrote: > On Tue, 2 Jan 2001, Tom Rini wrote: > > Hey all. While going through the 2.4 tree and removing dead CONFIG_xxx's for > > PPC stuff, I noticed clgenfb still had CONFIG_PREP stuff (which may have > > partily explained why it no longer worked here). I've attached a patch, that > > with another patch to fix some PCI issues on certain machines, gives me a > > working (so far, can't test heavily yet tho) framebuffer on my powerstack. > > > > Comments? > > To me it looks like most of them depend on `big endian', not on `PReP'. Well, I was trying to base things off the prior logic. > BTW, doesn't the Cirrus Logic graphics chip have a big endian aperture? I > don't like things like green.offset = -3, since it will probably break some > applications (did you run X?). Nope, I still need to NFS root the machine to try. I'm also wondering tho if on ppc anything other than Xbh (the Xserver writtten for these machines) will even work. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH] matroxfb as a module (PPC)
Hello all. I've recently been playing with modules on my PPC system, and
noticed that matroxfb doesn't work as a module, because of mac_vmode_to_par.
But, after looking at other drivers which did work (aty and aty128) I noticed
matroxfb was doing something it didn't need to be doing.
First, the code should never get compiled, if this is a module, and even then
the code only needs to be compiled on ALL_PPC (which is Pmac/PReP/CHRP).
Second, it's only valid to call the default_{vmode,cmode} code on a PMAC
(tested on a pmac, and ran it by one of the IBM guys who agrees it shouldn't
break anything, but he's still working on making the machine boot to start
with. :))
Third, the nvram_read_byte needs to be protected by CONFIG_NVRAM.
Finally, the VMODE_CHOOSE stuff is 0'ed out in atyfb with a comment about this
not actually working, so I removed it.
Comments?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
= drivers/video/matrox/matroxfb_base.c 1.13 vs edited =
--- 1.13/drivers/video/matrox/matroxfb_base.c Fri Dec 15 14:12:43 2000
+++ edited/drivers/video/matrox/matroxfb_base.c Sun Dec 31 10:39:11 2000
@@ -1842,33 +1842,33 @@
}
/* FIXME: Where to move this?! */
-#if defined(CONFIG_PPC)
+#if defined(CONFIG_ALL_PPC)
#if defined(CONFIG_FB_COMPAT_XPMAC)
strcpy(ACCESS_FBINFO(matrox_name), "MTRX,");/* OpenFirmware naming
convension */
strncat(ACCESS_FBINFO(matrox_name), b->name, 26);
if (!console_fb_info)
console_fb_info = &ACCESS_FBINFO(fbcon);
#endif
- if ((xres <= 640) && (yres <= 480)) {
+#ifndef MODULE
+ if (_machine == _MACH_Pmac) {
struct fb_var_screeninfo var;
- if (default_vmode == VMODE_NVRAM) {
- default_vmode = nvram_read_byte(NV_VMODE);
- if (default_vmode <= 0 || default_vmode > VMODE_MAX)
- default_vmode = VMODE_CHOOSE;
- }
if (default_vmode <= 0 || default_vmode > VMODE_MAX)
default_vmode = VMODE_640_480_60;
+#ifdef CONFIG_NVRAM
if (default_cmode == CMODE_NVRAM)
default_cmode = nvram_read_byte(NV_CMODE);
+#endif
if (default_cmode < CMODE_8 || default_cmode > CMODE_32)
default_cmode = CMODE_8;
if (!mac_vmode_to_var(default_vmode, default_cmode, &var)) {
var.accel_flags = vesafb_defined.accel_flags;
var.xoffset = var.yoffset = 0;
- vesafb_defined = var; /* Note: mac_vmode_to_var() doesnot set
all parameters */
+ /* Note: mac_vmode_to_var() does not set all parameters */
+ vesafb_defined = var;
}
}
-#endif /* CONFIG_PPC */
+#endif /* !MODULE */
+#endif /* CONFIG_ALL_PPC */
vesafb_defined.xres_virtual = vesafb_defined.xres;
if (nopan) {
vesafb_defined.yres_virtual = vesafb_defined.yres;
Re: [linux-fbdev] [PATCH] matroxfb as a module (PPC)
On Wed, Jan 03, 2001 at 06:44:59PM +0100, Geert Uytterhoeven wrote: > On Wed, 3 Jan 2001, Tom Rini wrote: > > Third, the nvram_read_byte needs to be protected by CONFIG_NVRAM. > > I'd really like to move the nvram part to mac_fb_find_mode() in macmodes.c, so > it will work automagically for all drivers on PowerMac. > > I'd also like to remove the `vmode' and `cmode' `video=' arguments, in favor of > the archictecture-neutral `x[-][@]' and > `[-][@]' arguments (which already work on mac, BTW). Quite wonderfully, almost. My monitor (ViewSonic G810) claims it can do 1280x1024@90, but when i boot with that on my x86 box, it comes up at 87.5 or so (and shifted to the left ~1 penguin). But anyways.. > You can already use `mac' instead of `vmode:'. Ah, is this documented anywhere? I'm sure it'd make some peoples life easier. > IMHO, the less PowerMac-specific code in _each_ driver, the better. I agree this sounds good. I just think it's too late to do it now. :) The vmode/cmode/vesa number stuff should stick around in 2.4 (it's too late now to remove it) but documented as obsolete, and removed in 2.5. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.4-test9 kernel header flaw
On Fri, Sep 29, 2000 at 01:41:09AM +0200, Andries Brouwer wrote: > On Thu, Sep 28, 2000 at 03:41:41PM -0700, Jack Howarth wrote: > > > I find that the compile of gnome-utils fails as follows... > > > > In file included from /usr/include/linux/string.h:21, > > from /usr/include/linux/fs.h:23, > > from badblocks.c:43: > > Yes, a well-known phenomenon. > Kernel headers are to compile the kernel. > They are not for inclusion in user programs. Yes. I think what Jack was saying is it doesn't seem anyways like the kernel needs to include linux/string.h in fs.h. If it does need linux/string.h either a) The #include should be in #ifdef __KERNEL__/#endif or the contents of linux/string.h should be in #ifdef __KERNEL__/#endif. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre4
On Sun, Sep 10, 2000 at 07:57:38PM -0700, David S. Miller wrote: >From: "Albert D. Cahalan" <[EMAIL PROTECTED]> >Date: Sun, 10 Sep 2000 23:05:29 -0400 (EDT) > >Over on the freebsd-questions mailing list you can see desperate >people trying to convert Linux systems over to that other OS to >escape Linux 2.2.xx NFS. This is kind of serious, you know? > > So basically the situation is that people prefer to switch the whole > OS as opposed to applying a kernel patch? Well, it seems a good many people don't know there are patches out there for NFS that make it bearable or don't want to try and compile a kernel. As an aside, anyone know which vendors kernel source either a) has some variant of the NFS patches or b) has a clean enough tree that new ones apply fine? -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.4.0-test9-pre2
On Tue, Sep 19, 2000 at 05:14:39PM -0700, David S. Miller wrote: >Date: Tue, 19 Sep 2000 18:07:20 -0600 >From: Cort Dougan <[EMAIL PROTECTED]> > >Do you really think that's forcing people to concentrate of fixing >bugs? Tell me if you disagree, I'd like to understand how you see >that. I see that 2.4 is getting all kinds of changes merged in >that should be going on with 2.5. The recent VM changes have left >us with deadlocks that we didn't have before. Shouldn't that have >gone into 2.5 not 2.4? > > The VM performance in 2.4.x was a major regression from 2.2.x and is > required to be fixed for 2.4.0 release. Riel did the bulk of this > work, and it's now just dealing with a few remaining details on very > low memory systems. His changes fixed a major problem, and > structurally I believe his changes are completely sound and were > justifiably included in 2.4.x. > > So I think this was a bad example. Well, I think the bitterness comes from (partily anyways) it going into 2.4.0-test9-pre1, along with other seemingly large updates, which did need to go in but really don't sound right for a -test. I guess Linus didn't want to see 2.3.1xx like we did with 2.1. But the 2.2.0-testX patches seemed like small stuff (maybe my memory just sucks tho). > I'll say this much, if 2.5.x existed I'd be spending most of my time > on a clean zero-copy TCP framework instead of walking over the net > stack and sparc64 code verifying things every day, that is for sure. > So yes, I am really thinking that it is forcing people to concentrate > on fixing bugs, because at least it is doing so for me. I know that > the faster 2.4.x happens the faster the "fun" 2.5.x stuff comes along. What Cort didn't mention is that at least some of this fun experimental stuff is things like better support for new machines, along with bug fixing for 2.4 (ie people can use all their PCI cards without resource conflicts again). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: RedHat 7.0 anaconda installer doesn't support devfs
On Fri, Oct 06, 2000 at 09:19:45PM -0400, Joseph Fannin wrote: > Jeff Merkey wrote: > > >On Sat, Oct 07, 2000 at 12:31:05AM -0400, jeff millar wrote: > >> Redhat support got back to me today and said 7.0 doesnt support > >> upgrades to systems running devfs. But I thought sure than Linus > >> blessed it! :-) > >> Does anyone have a fix? > > > >Good question. I noticed this as well. > > > I couldn't run devfs on a fresh install of RedHat 7 either; the > use of labels in fstab to identify partitions seems to preclude this. Eh? That doesn't make sense. I've used devfs & LABELs in my fstab before fine. That really shouldn't be the problem. Your root gets mounted, yes? Then /proc and /proc is needed (I don't know the file) for the LABEL/UUID-> device stuff. > Well, I *could* have hacked all the necessary scripts if I knew what > they were, I guess. The rawhide scripts used to start devfs all by themselves. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler)
On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote: > On Tue, 10 Oct 2000, Ingo Oeser wrote: > > > before you argue endlessly about the "Right OOM Killer (TM)", I > > did a small patch to allow replacing the OOM killer at runtime. > > > > So now you can stop arguing about the one and only OOM killer, > > implement it, provide it as module and get back to the important > > stuff ;-) > > This is definately a cool toy for people who have doubts > that my OOM killer will do the wrong thing in their > workloads. I think this can be useful for more than just a cool toy. I think that the main thing that this discusion has shown is no OOM killer will please 100% of the people 100% of the time. I think we should try and have a good generic OOM killer that kills the right process most of the time. People can impliment (and submit) different-style OOM killers as needed. Or at least get 'em on freshmeat. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] OOM killer API (was: [PATCH] VM fix for 2.4.0-test9 & OOM handler)
On Tue, Oct 10, 2000 at 05:58:46PM -0300, Rik van Riel wrote: > On Tue, 10 Oct 2000, Tom Rini wrote: > > On Tue, Oct 10, 2000 at 12:32:50PM -0300, Rik van Riel wrote: > > > On Tue, 10 Oct 2000, Ingo Oeser wrote: > > > > > > > before you argue endlessly about the "Right OOM Killer (TM)", I > > > > did a small patch to allow replacing the OOM killer at runtime. > > > > > > > > So now you can stop arguing about the one and only OOM killer, > > > > implement it, provide it as module and get back to the important > > > > stuff ;-) > > > > > > This is definately a cool toy for people who have doubts > > > that my OOM killer will do the wrong thing in their > > > workloads. > > > > I think this can be useful for more than just a cool toy. I > > think that the main thing that this discusion has shown is no > > OOM killer will please 100% of the people 100% of the time. I > > think we should try and have a good generic OOM killer that > > kills the right process most of the time. People can impliment > > (and submit) different-style OOM killers as needed. > > Indeed, though I suspect most of the people trying this would > fall into the trap of over-engineering their OOM killer, after > which it mostly becomes less predictable ;) I was thinking more along the lines of ones w/ "safety" features that not everyone might like/need (ie /usr/local/bin/foo is always good, those sugjestions). It seems like useful functionality at little/no cost. And a neat toy for now. :) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remove CONFIG_NCR885E from Configure.help
On Thu, Mar 08, 2001 at 05:21:32PM +0100, Geert Uytterhoeven wrote: > On Thu, 8 Mar 2001, Steven Cole wrote: > > It appears that use of CONFIG_NCR885E was removed in 2.4.2-ac2, > > in Config.in and the Makefile in drivers/net. > > > > If it really is the case that CONFIG_NCR885E is history, then it > > should be history in Configure.help as well. > > I'm still wondering whether there really are no other boards with a Sym53c885 > than the Synergy PPC board (which is no longer supported). ...which is supposed to be coming back as well. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: sysrq.txt
On Sun, Mar 18, 2001 at 11:39:55PM +0100, Pavel Machek wrote: > Hi! > > > I've found that the Sysrq Keys on Apple Computers > > are 'Keypad+-F13-', maybe it would > > be a good idea to include that in Documentation/sysrq.txt. > > > > The Patch: > > This patch is reversed, but otherwise looks okay. Generate > non-reversed one and mail it to linus, possibly saying I agree. Speaking of reversed, there's a slightly "nicer" one in 2.2.18+: On PowerPC - You press 'ALT-Print Screen-'. (And yes, all the apple keyboards I've seen w/ F13 have Print Screen right below it). Tho I'm also rather sure this didn't get into Linus' tree until after the 2.3 split.. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: sysrq.txt
On Mon, Mar 19, 2001 at 08:37:00PM +0100, J. Michael Kolbe wrote: > On Mon, Mar 19, 2001 at 09:15:59AM -0700, Tom Rini wrote: > > Speaking of reversed, there's a slightly "nicer" one in 2.2.18+: > > On PowerPC - You press 'ALT-Print Screen-'. > > > > (And yes, all the apple keyboards I've seen w/ F13 have Print Screen > > right below it). Tho I'm also rather sure this didn't get into > > Linus' tree until after the 2.3 split.. > > > Well, my Apple Keyboard doesn't. It's F13. And it doesn't work with 'ALT'. Which? And it should indeed work with the "alt" key (ie the one for changing VCs). > I suppose that's why it didn't get into the mainstream tree. Er, 2.2 is mainstream. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: sysrq.txt
On Mon, Mar 19, 2001 at 08:37:00PM +0100, J. Michael Kolbe wrote: > On Mon, Mar 19, 2001 at 09:15:59AM -0700, Tom Rini wrote: > > Speaking of reversed, there's a slightly "nicer" one in 2.2.18+: > > On PowerPC - You press 'ALT-Print Screen-'. > > > > (And yes, all the apple keyboards I've seen w/ F13 have Print Screen > > right below it). Tho I'm also rather sure this didn't get into > > Linus' tree until after the 2.3 split.. > > > Well, my Apple Keyboard doesn't. It's F13. And it doesn't work with 'ALT'. > I suppose that's why it didn't get into the mainstream tree. But anyways. My objects were it's not just "macs". And not all keyboards have "F13" written on them as well as Print Screen. Which is why I think what 2.2 has is what 2.4 should have. Or if yours doesn't say Print Screen: On PowerPC - You press 'ALT-Print Screen (or F13)- As to weather or not it's the key which says "ALT" on it or not, it is the key which provides the ALT keycode in linux. Or it very well should be, for consistencys sake. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: sysrq.txt
On Mon, Mar 19, 2001 at 11:56:19PM +0100, J. Michael Kolbe wrote: > On Mon, Mar 19, 2001 at 01:46:53PM -0700, Tom Rini wrote: > > On Mon, Mar 19, 2001 at 08:37:00PM +0100, J. Michael Kolbe wrote: > > > On Mon, Mar 19, 2001 at 09:15:59AM -0700, Tom Rini wrote: > > > > Speaking of reversed, there's a slightly "nicer" one in 2.2.18+: > > > > On PowerPC - You press 'ALT-Print Screen-'. > > > > > > > > (And yes, all the apple keyboards I've seen w/ F13 have Print Screen > > > > right below it). Tho I'm also rather sure this didn't get into > > > > Linus' tree until after the 2.3 split.. > > > > > > > Well, my Apple Keyboard doesn't. It's F13. And it doesn't work with 'ALT'. > > > I suppose that's why it didn't get into the mainstream tree. > > > > But anyways. My objects were it's not just "macs". And not all keyboards > > have "F13" written on them as well as Print Screen. Which is why I think > > what 2.2 has is what 2.4 should have. Or if yours doesn't say Print Screen: > > > > On PowerPC - You press 'ALT-Print Screen (or F13)- > > > > As to weather or not it's the key which says "ALT" on it or not, it is the > > key which provides the ALT keycode in linux. Or it very well should be, for > > consistencys sake. > > > Keypad'+''s keycode is 69, while ALT's keycode is 58. Err, so? The sysrq code is triggered by "ALT" (which on PPC can be any number of things, depending on keyboard and other stuff) and the SYSRQ key. It's either 0x69 or 0x54, which is "F13" in either translated keycodes or ADB respectivly. > Besides, I have never seen an Apple Keyboard without an F13 Key. All of the USB keyboards, up until recently. > So, it's "Keypad'+'-F13 (or Print Screen)-". > Any objection? Well, where does that work? My PReP works fine w/ ALT-printscrn-key My old pmac is ALT-printscrn-key, and I don't have F13 on my other keyboard. So yes, I object because I'm not sure where your sugjestion works. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: sysrq.txt
On Tue, Mar 20, 2001 at 01:00:53AM +0100, J. Michael Kolbe wrote: > Hi. > > On Mon, Mar 19, 2001 at 04:21:35PM -0700, Tom Rini wrote: > > On Mon, Mar 19, 2001 at 11:14:03PM +, Andrew Morton wrote: > > > > > I included Mr Kolbe's one-liner in the SAK patch which I put > > > out on Sunday. Now my head is spinning. > > > > > > What *should* the change to sysrq.txt say? > > > > Well, I think: > > > > On PowerPC - You press 'ALT-Print Screen (or F13)- > > > > Which is what 2.2 says, but mentions F13 directly (incase print screen isn't > > on the key.). The above even makes sense for 2 of my machines which have > > working sysrq and keyboards. > > Well, I've just found an old USB Keyboard, none of the mentioned > Keyboard combos work, as there is neither F13 nor PrintScreen. Yes, as SysRq quite possibly doesn't work on (since none of the keys on it send the right keycode.) > > Btw, I'm using an old Newworld G3, the one with ADB. The old one. :) > I'd say sysrq.txt should say: > > On PowerPC - Press 'ALT - Print Screen (or F13) - > On Newworld PPC - You press 'Keypad+ - Print Screen (or F13) - > > I'm still trying to figure out how to do it with the F13-less Keyboard.. Er, I thought you just said you did? What keycodes are you using? Most "Newworld" only have the F13-less keyboard. Which sort of raises the question of how 'Keypad +' worked instead of the "ALT" key (either option/alt or the scroll key, whichever changes VC). Which sounds more like a fluke then anything else. Which keyboard worked with 'Keypad +' ? The ADB one? After some quick playing with my oldworld machine, Just F13 - is sufficient. I'm not sure about PReP tho (so it's probably not worth saying you don't need "ALT"). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: sysrq.txt
On Tue, Mar 20, 2001 at 02:07:13AM +0100, J. Michael Kolbe wrote: [snip] > Well, as there is no keyboard combo that works on every Mac, I think we should > list every known to be working combo. > > Like: > > On PowerPC - Press 'ALT - Print Screen (or F13) - , > Print Screen (or F13) - may suffice. Sounds good. > Maybe it's a good idea to include F13's keycode, which I don't know. Nah. I think we should try and fix this sometime tho. Perhaps the round powerbutton on the keyboard could do 'F13' (and add this to the list..) -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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: CML1 cleanup patch, take 2
On Mon, Mar 26, 2001 at 09:50:53AM -0500, Jeff Garzik wrote: > esr wrote: > > (3) Fix up 10 configuration symbols of the form CONFIG_[0-9]*; specific > > changes are those suggested 8 Jan 2001 by PPC port maintainer Tom Rini. > > This change has been APPROVED by an authorized maintainer. > > Maybe I am not caught up with the times... I thought Cort Dougan was > the overall PowerPC maintainer. That's what MAINTAINERS says. Yes. Cort is indeed the overall, head PPC guy. Paul M does a lot too. :) However, all of these name changes have gone past not only those two, but a large portion of the PPC kernel community as well. Everyone likes 'em, or at least agrees they aren't bad changes. > Anyway, this is up to the PowerPC guys, but I disagree with this change > nonetheless. MandrakeSoft has a PPC port, and as I mentioned earlier, > some utilities in the build process etc. look at CONFIG_xxx. Yes, they do. Which is partily why I was actually going to wait until 2.5 for many of these to come in. > PPC guys: this is a gratuitous renaming change that is not required. > If you have been following the "CML1 cleanup patch" thread, you see that > Eric is blindly dictating policy when he says that CONFIG_[0-9] needs to > be cleaned up. The counter point to this is what does "CONFIG_6xx" or 8xx mean? It's as bad as CONFIG_Mxxx imho :) > > This leaves ten symbols in a form that breaks CML2. I'll go after > > the other individual maintainers about those. Sigh > > > > No actual object code will be changed by this patch; it merely does > > one-to-one substitutions on some configuration symbols. > > > > Let me repeat that. This patch changes *no* object code. None. > > However, merging it before the 2.5 fork will save me (and probably > > Alan) some nasty large headaches later on... > > Object code changes are not the only thing we are concerned with in a > stable series. > Let me repeat myself for the cheap seats: Changing the 2.4.x > CONFIG_xxx namespace changes the source code API provided to other > kernel code. It affects software not in the Linux kernel tree. Yes. Symbol changes should be a 2.5 thing anyways. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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] 2.4.3 and SysRq over serial console
Hello all. Without the attached patch, SysRq doesn't work over a serial
console here. Has anyone else seen this problem?
--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
diff -Nru a/linux/drivers/char/n_tty.c b/linux/drivers/char/n_tty.c
--- a/linux/drivers/char/n_tty.cSat Mar 31 16:30:44 2001
+++ b/linux/drivers/char/n_tty.cSat Mar 31 16:30:44 2001
@@ -40,6 +40,10 @@
#include
#include
#include
+#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */
+#include
+#include
+#endif
#include
#include
@@ -458,6 +462,12 @@
static inline void n_tty_receive_break(struct tty_struct *tty)
{
+#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */
+ struct console *c = console_drivers;
+ if (c && c->device && (c->device(c) == tty->device)
+ && !test_and_change_bit(TTY_DOING_SYSRQ, &tty->flags))
+ return;
+#endif
if (I_IGNBRK(tty))
return;
if (I_BRKINT(tty)) {
@@ -506,6 +516,12 @@
{
unsigned long flags;
+#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */
+ if (test_and_clear_bit(TTY_DOING_SYSRQ, &tty->flags)) {
+ handle_sysrq(c, NULL, NULL, tty);
+ return;
+ }
+#endif
if (tty->raw) {
put_tty_queue(c, tty);
return;
diff -Nru a/linux/include/linux/tty.h b/linux/include/linux/tty.h
--- a/linux/include/linux/tty.h Sat Mar 31 16:30:44 2001
+++ b/linux/include/linux/tty.h Sat Mar 31 16:30:44 2001
@@ -329,6 +329,9 @@
#define TTY_PUSH 6
#define TTY_CLOSING 7
#define TTY_DONT_FLIP 8
+#ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */
+#define TTY_DOING_SYSRQ 9
+#endif
#define TTY_HW_COOK_OUT 14
#define TTY_HW_COOK_IN 15
#define TTY_PTY_LOCK 16
Re: final problem pre10 & ppc
On Wed, Jan 24, 2001 at 11:42:52PM +0100, [EMAIL PROTECTED] wrote: > when linking Can you privately email me your .config? pre10 should mostly work otherwise as only a few things are missing now (new bugfixes, old fixes in drivers/macintosh, and some fb updates to send off to maintainers). -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: FW: 2.4.1 - ppc - compile problems
On Sun, Jan 28, 2001 at 03:32:33PM +0100, Micha? 'CeFeK' Nazarewicz wrote: > There appears to be undefined variable (in pmac_pci), called > PCI_DEVICE_ID_APPLE_KL_USB. When anyone tries to compile the newest kernel > on PPC machine with USB support on, there is an error saying that this is > undefined. 2.4.x from kernel.org currently does not work on PPC. Take a look at: http://www.fsmlabs.com/linuxppcbk.html -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre1
On Sat, Feb 03, 2001 at 08:24:27PM -0800, Linus Torvalds wrote: ... > -pre1: ... > - riva FB driver update Er, what exactly is the CONFIG_PREP stuff in this driver supposed to be for? "CONFIG_PREP" doesn't exist anymore to start with, and secondly I'm not sure if any PReP boxes ever shipped with a riva card to start with. The only real way to handle this in 2.4 is something like: #ifdef CONFIG_ALL_PPC /* CHRP/PMAC/PREP */ #include #define isPReP (_machine == _MACH_prep) #else #define isPReP 0 #endif That is, if there's really any need to test explicitly for a PReP box. I asked Ani Joshi about this a while ago, and he wasn't quite sure why they were in there either.. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: 2.4.2-pre1
On Tue, Feb 06, 2001 at 01:52:36PM -0500, Jeff Garzik wrote: > Tom Rini wrote: > > Er, what exactly is the CONFIG_PREP stuff in this driver supposed to be > > for? "CONFIG_PREP" doesn't exist anymore to start with, and secondly I'm > > not sure if any PReP boxes ever shipped with a riva card to start with. The > > only real way to handle this in 2.4 is something like: > > #ifdef CONFIG_ALL_PPC /* CHRP/PMAC/PREP */ > > #include > > #define isPReP (_machine == _MACH_prep) > > #else > > #define isPReP 0 > > #endif > > > > That is, if there's really any need to test explicitly for a PReP box. > > I asked Ani Joshi about this a while ago, and he wasn't quite sure why they > > were in there either.. > > It looks like it might have come from drivers/video/clgenfb.c, perhaps > for use with big endian framebuffers? It is indeed from clgen, but even there it's only needed on the PReP boxes with a cirrus logic card. The MacPicasso cards (also clgen) need some other magic (see linux-fbdev). > If the driver works on PPC without CONFIG_PREP code, let's get rid of > it. Well, it's definatly not doing anything now. It probably shouldn't be there anyways, as in clgen it seems to be for PReP black magic. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.12-rc1] ppc32: Fix mpc8xx watchdog
The CONFIG_8xx_WDT option got broken in the generic hardirq update as
ppc32 had its own different request_irq that worked when other arches
used setup_irq. This is the trivial fix for the problem.
From: Carsten Juttner <[EMAIL PROTECTED]>
Signed-off-by: Tom Rini <[EMAIL PROTECTED]>
diff -Nru a/arch/ppc/syslib/m8xx_wdt.c b/arch/ppc/syslib/m8xx_wdt.c
--- a/arch/ppc/syslib/m8xx_wdt.c2005-02-11 07:08:20 +01:00
+++ b/arch/ppc/syslib/m8xx_wdt.c2005-02-11 07:08:20 +01:00
@@ -11,6 +11,7 @@
#include
#include
+#include
#include
#include
#include
@@ -18,6 +19,12 @@
static int wdt_timeout;
+static irqreturn_t m8xx_wdt_interrupt(int, void *, struct pt_regs *);
+static struct irqaction m8xx_wdt_irqaction = {
+ .handler = m8xx_wdt_interrupt,
+ .name = "watchdog",
+};
+
void m8xx_wdt_reset(void)
{
volatile immap_t *imap = (volatile immap_t *)IMAP_ADDR;
@@ -84,8 +93,8 @@
imap->im_sit.sit_piscr =
(mk_int_int_mask(PIT_INTERRUPT) << 8) | PISCR_PIE | PISCR_PTE;
- if (request_irq(PIT_INTERRUPT, m8xx_wdt_interrupt, 0, "watchdog", NULL))
- panic("m8xx_wdt: could not allocate watchdog irq!");
+ if (setup_irq(PIT_INTERRUPT, &m8xx_wdt_irqaction))
+ panic("m8xx_wdt: error setting up the watchdog irq!");
printk(KERN_NOTICE
"m8xx_wdt: keep-alive trigger installed (PITC: 0x%04X)\n", pitc);
--
Tom Rini
http://gate.crashing.org/~trini/
-
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 2.6.12-rc2]: ppc32: Fix a problem with NTP on !(chrp||gemini)
The following problem was found by Giovambattista Pulcini <[EMAIL PROTECTED]>, who also provided a partial patch, and this has been verified by our time guru Gabriel Paubert <[EMAIL PROTECTED]>. The problem is that in do_settimeofday() we always set time_state to TIME_ERROR and except on two platforms, never re-set it. This meant that ntp_gettime() and ntp_adjtime() always returned TIME_ERROR, incorrectly. Based on Gabriel's analysis, time_state is used for leap-second processing, and ppc shouldn't be mucking with it. From: Giovambattista Pulcini <[EMAIL PROTECTED]> Signed-off-by: Tom Rini <[EMAIL PROTECTED]> --- 1.37/arch/ppc/kernel/time.c 2005-01-20 22:02:08 -07:00 +++ edited/arch/ppc/kernel/time.c 2005-04-08 07:30:46 -07:00 @@ -272,7 +272,6 @@ time_adjust = 0;/* stop active adjtime() */ time_status |= STA_UNSYNC; - time_state = TIME_ERROR;/* p. 24, (a) */ time_maxerror = NTP_PHASE_LIMIT; time_esterror = NTP_PHASE_LIMIT; write_sequnlock_irqrestore(&xtime_lock, flags); --- 1.11/arch/ppc/platforms/chrp_time.c 2005-01-25 14:50:14 -07:00 +++ edited/arch/ppc/platforms/chrp_time.c 2005-04-08 07:30:53 -07:00 @@ -115,8 +115,6 @@ chrp_cmos_clock_write(save_control, RTC_CONTROL); chrp_cmos_clock_write(save_freq_select, RTC_FREQ_SELECT); - if ( (time_state == TIME_ERROR) || (time_state == TIME_BAD) ) - time_state = TIME_OK; spin_unlock(&rtc_lock); return 0; } --- 1.17/arch/ppc/platforms/gemini_setup.c 2005-03-13 16:29:43 -07:00 +++ edited/arch/ppc/platforms/gemini_setup.c2005-04-08 07:30:56 -07:00 @@ -433,9 +433,6 @@ /* done writing */ gemini_rtc_write(reg, M48T35_RTC_CONTROL); - if ((time_state == TIME_ERROR) || (time_state == TIME_BAD)) - time_state = TIME_OK; - return 0; } -- Tom Rini http://gate.crashing.org/~trini/ - 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: CML2 design philosophy heads-up
On Thu, May 17, 2001 at 05:35:49AM -0400, Michael Meissner wrote: > On Thu, May 17, 2001 at 05:47:41PM +1000, Keith Owens wrote: > > On Thu, 17 May 2001 03:26:36 -0400, > > "Eric S. Raymond" <[EMAIL PROTECTED]> wrote: > > >Pavel Machek <[EMAIL PROTECTED]>: > > >> And If I want scsi-on-atapi emulation but not vme147_scsi? > > > > > >Help me understand this case, please. What is scsi-on-atapi? > > >Is SCSI on when you enable it? And is it a realistic case for an SBC? > > > > SCSI emulation over IDE, CONFIG_BLK_DEV_IDESCSI. You have the SCSI mid > > layer code but no SCSI hardware drivers. It is a realistic case for an > > embedded CD-RW appliance. > > Or alternatively, you want to enable SCSI code, with no hardware driver, > because you are going to build pcmcia, which builds the scsi drivers only if > CONFIG_SCSI is defined, and the user might put in an Adaptec 1460B or 1480 scsi > card into your pcmcia slot. Both of these 'problems' assume that you can have IDE or PCMCIA on these particular boxes. Does anyone know if that's actually true? What eric is trying to do, can work, if done very carefully, and in very limited cases as well. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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] ppc xconfig 2.2.5-pre4
On Mon, May 21, 2001 at 03:29:31AM +0200, Andrzej Krzysztofowicz wrote: > The following patch fixes ppc xconfig potential problem introduced in > 2.4.5-pre4. xconfig has other issues on PPC at the momement, if you select and 8xx or 8260 CPU. See the inlined. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ = drivers/net/Config.in 1.14 vs edited = --- 1.14/drivers/net/Config.in Wed Apr 25 19:35:07 2001 +++ edited/drivers/net/Config.inWed May 2 14:44:24 2001 @@ -38,7 +38,31 @@ tristate ' BMAC (G3 ethernet) support' CONFIG_BMAC tristate ' GMAC (G4/iBook ethernet) support' CONFIG_GMAC tristate ' Symbios 53c885 (Synergy ethernet) support' CONFIG_NCR885E - tristate ' National DP83902AV (Oak ethernet) support' CONFIG_OAKNET + if [ "$CONFIG_4xx" = "y" ]; then + tristate ' National DP83902AV (Oak ethernet) support' CONFIG_OAKNET + fi + if [ "$CONFIG_8xx" = "y" -o "$CONFIG_8260" = "y" ]; then + bool 'CPM SCC Ethernet' CONFIG_SCC_ENET + if [ "$CONFIG_SCC_ENET" = "y" ]; then +choice 'SCC used for Ethernet (SCC3 valid only on 8xx)'\ + "SCC1 CONFIG_SCC1_ENET\ +SCC2 CONFIG_SCC2_ENET\ + SCC3CONFIG_SCC3_ENET" SCC1 + fi + bool 'FCC Ethernet' CONFIG_FEC_ENET + if [ "$CONFIG_FEC_ENET" = "y" -a "$CONFIG_8260" = "y" ]; then +bool 'Ethernet on FCC1' CONFIG_FCC1_ENET +bool 'Ethernet on FCC2' CONFIG_FCC2_ENET +bool 'Ethernet on FCC3' CONFIG_FCC3_ENET + fi + if [ "$CONFIG_FEC_ENET" = "y" -a "$CONFIG_8xx" = "y" ]; then +bool 'Use MDIO for PHY configuration' CONFIG_USE_MDIO + fi + if [ "$CONFIG_8xx" = "y" -a "$CONFIG_FEC_ENET" = "y" \ + -o "$CONFIG_SCC_ENET" = "y" ]; then +bool 'Use Big CPM Ethernet Buffers' CONFIG_ENET_BIG_BUFFERS + fi + fi fi if [ "$CONFIG_ZORRO" = "y" ]; then tristate ' Ariadne support' CONFIG_ARIADNE = arch/ppc/config.in 1.17 vs edited = --- 1.17/arch/ppc/config.in Thu Apr 19 15:50:05 2001 +++ edited/arch/ppc/config.in Wed May 2 14:44:42 2001 @@ -337,12 +337,13 @@ endmenu if [ "$CONFIG_8xx" = "y" ]; then -source arch/ppc/8xx_io/Config.in + source arch/ppc/8xx_io/Config.in fi -if [ "$CONFIG_8260" = "y" ]; then -source arch/ppc/8260_io/Config.in -fi +# Empty for now, but it will come back -- Tom +#if [ "$CONFIG_8260" = "y" ]; then +# source arch/ppc/8260_io/Config.in +#fi source drivers/usb/Config.in = arch/ppc/8xx_io/Config.in 1.4 vs edited = --- 1.4/arch/ppc/8xx_io/Config.in Thu Apr 26 15:34:57 2001 +++ edited/arch/ppc/8xx_io/Config.inWed May 2 14:42:11 2001 @@ -4,20 +4,6 @@ mainmenu_option next_comment comment 'MPC8xx CPM Options' -if [ "$CONFIG_NET_ETHERNET" = "y" ]; then - bool 'CPM SCC Ethernet' CONFIG_SCC_ENET - if [ "$CONFIG_SCC_ENET" = "y" ]; then -choice 'SCC used for Ethernet' \ - "SCC1 CONFIG_SCC1_ENET\ -SCC2 CONFIG_SCC2_ENET\ -SCC3 CONFIG_SCC3_ENET" SCC1 - fi - bool '860T FEC Ethernet' CONFIG_FEC_ENET - if [ "$CONFIG_FEC_ENET" = "y" ]; then -bool 'Use MDIO for PHY configuration' CONFIG_USE_MDIO - fi - bool 'Use Big CPM Ethernet Buffers' CONFIG_ENET_BIG_BUFFERS -fi bool 'Use SMC2 for UART' CONFIG_SMC2_UART if [ "$CONFIG_SMC2_UART" = "y" ]; then bool 'Use Alternate SMC2 I/O (823/850)' CONFIG_ALTSMC2 = arch/ppc/8260_io/Config.in 1.1 vs edited = --- 1.1/arch/ppc/8260_io/Config.in Sat Jan 6 00:30:23 2001 +++ edited/arch/ppc/8260_io/Config.in Wed May 2 14:42:37 2001 @@ -3,23 +3,5 @@ # if [ "$CONFIG_NET_ETHERNET" = "y" ]; then mainmenu_option next_comment - comment 'MPC8260 Communication Options' - bool 'CPM SCC Ethernet' CONFIG_SCC_ENET - if [ "$CONFIG_SCC_ENET" = "y" ]; then - bool 'Ethernet on SCC1' CONFIG_SCC1_ENET -if [ "$CONFIG_SCC1_ENET" != "y" ]; then - bool 'Ethernet on SCC2' CONFIG_SCC2_ENET -fi - fi -# -# CONFIG_FEC_ENET is only used to get netdevices to call our init -#function. Any combination of FCC1,2,3 are supported. -# - bool 'FCC Ethernet' CONFIG_FEC_ENET - if [ "$CONFIG_FEC_ENET" = "y" ]; then -bool 'Ethernet on FCC1' CONFIG_FCC1_ENET -bool 'Ethernet on FCC2' CONFIG_FCC2_ENET -bool 'Ethernet on FCC3' CONFIG_FCC3_ENET - fi endmenu fi - 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: [kbuild-devel] Re: CML2 design philosophy heads-up
On Mon, May 21, 2001 at 11:58:34AM +0200, Jes Sorensen wrote: > >>>>> "Jakob" == Jakob ?stergaard <[EMAIL PROTECTED]> writes: > > Jakob> On Sun, May 20, 2001 at 10:10:49PM -0400, Robert M. Love wrote: > >> I think this is a very important point, and one I agree with. I > >> tend to let my distribution handle stuff like python. now, I use > >> RedHat's on-going devel, RawHide. it is not using python2. in > >> fact, since switching to python2 may break old stuff, I don't > >> expect python2 until 8.0. that wont be for 9 months. 90% of > >> RedHat's configuration tools, et al, are written in python1 and > >> they just are not going to change on someone's whim. > > Jakob> 2.6.0 isn't going to happen for at least a year or two. What's > Jakob> the problem ? > > Jakob> Want 2.5.X ? Get the tools too. > > Some people grab the latest devel kernels because thats all that works > on their hardware. And they can grab the latest tools too. Why is this a problem again? python1.5.x is compatiable w/ python2 EXCEPT in the cases where the script uses undocumented things which did work in python1.5.x. But that's not as big of a problem since they can co-exist. Debian already does this (And thus CML2 already deals with python2 being called 'python2') and I wouldn't be supprised if the PowerTools python2 rpm someone pointed out makes them co-exist as well. Which brings up another point, RedHat (7.1?) and Debian/woody both have the option of having python2 around. Anyone know about mandrake? My point is that some dists are already dealing with python2. > Jakob> I'm in no position to push people around, but I think the > Jakob> whining about CML2 tool requirements is completely unjustified. > Jakob> If we required that everything worked with GCC 2.7.2 and nmake, > Jakob> where would we be today ? I'm a lot more worried about CML2 > Jakob> itself than about the tools it requires :) > > gcc-2.7.2 is broken it miscompiles the kernel, Python1 or bash are > not. Well no, but python1 requires another 2k lines of python code or so. Eric, would it be easy/possible to go back to requiring python 1.5.x for CML2, since that is what many dists ship with? > Jakob> Whether CML2 requires python2 or not, the distributions will > Jakob> change. This is not about Eric pushing something down people's > Jakob> throats. Tools evolve, and new revisions introduce > Jakob> incompatibilities, but distributions still follow the > Jakob> evolution. Nobody ships perl4 today either. > > The point is that Eric has been trying to push distributions to ship > P2. Maybe, maybe not. Forgetting about the QA time and whatnot, there's good odds that all of the python scripts RedHat (for example) ships will just work with python2. I know one of the PPC dists didn't ship with python2 (which does have a lot of python bits to it) entirely because they were already in testing when it came out. It's not something the distros can switch to at a whim, but it's also something which shouldn't cause them problems when they do. -- Tom Rini (TR1265) http://gate.crashing.org/~trini/ - 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 header policy
On Tue, Jul 12, 2005 at 09:08:53PM +0200, Eric Piel wrote: > 12.07.2005 20:38, Jim Nance wrote/a écrit: > > > > > >Perhaps a little history would help. In the beginning, the kernel was > >written with the intention that userland would be including the headers. > >And libc did include the kernel headers. > > > >This did provide an effective way to get new kernel features to show > >up in userland, but it created all sorts of other problems. Eventually > >it was decided/decreed that userland would NOT include kernel headers. > >Instead, libc would provide a set of headers which would either be > >compatable, or would marshel data into the form the kernel wanted. > > > > So does this mean that all the "#ifdef __KERNEL__" are useless or are > they still used? Because a large number of things aren't "fixed", __KERNEL__ is still used so that nothing more breaks. -- Tom Rini http://gate.crashing.org/~trini/ - 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 2.6.13-rc3] kbuild: When checking depmod version, redirect stderr
When running depmod to check for the correct version number, extra output we don't need to see, such as "depmod: QM_MODULES: Function not implemented" may show up. Redirect stderr to /dev/null as the version information that we do care about comes to stdout. Signed-off-by: Tom Rini <[EMAIL PROTECTED]> diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -875,7 +875,7 @@ modules_install: _modinst_ _modinst_post .PHONY: _modinst_ _modinst_: - @if [ -z "`$(DEPMOD) -V | grep module-init-tools`" ]; then \ + @if [ -z "`$(DEPMOD) -V 2>/dev/null | grep module-init-tools`" ]; then \ echo "Warning: you may need to install module-init-tools"; \ echo "See http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt";\ sleep 1; \ -- Tom Rini http://gate.crashing.org/~trini/ - 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 2.6.13-rc3] kbuild: When checking depmod version, redirect stderr
On Fri, Jul 15, 2005 at 02:24:32PM -0700, randy_dunlap wrote: > On Fri, 15 Jul 2005 07:56:36 -0700 Tom Rini wrote: > > > When running depmod to check for the correct version number, extra > > output we don't need to see, such as "depmod: QM_MODULES: Function not > > implemented" may show up. Redirect stderr to /dev/null as the version > > information that we do care about comes to stdout. > > > > Signed-off-by: Tom Rini <[EMAIL PROTECTED]> > > > > diff --git a/Makefile b/Makefile > > --- a/Makefile > > +++ b/Makefile > > @@ -875,7 +875,7 @@ modules_install: _modinst_ _modinst_post > > > > .PHONY: _modinst_ > > _modinst_: > > - @if [ -z "`$(DEPMOD) -V | grep module-init-tools`" ]; then \ > > + @if [ -z "`$(DEPMOD) -V 2>/dev/null | grep module-init-tools`" ]; then \ > > echo "Warning: you may need to install module-init-tools"; \ > > echo "See > > http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt";\ > > sleep 1; \ > > Well, seeing "QM_MODULES" is a great indicator that someone is using > modutils instead of module-init-tools, so I'd like to see it stay. > IOW, I somewhat disagree with "extra output we don't need to see." This shows up when building a 2.6 kernel with incorrect tools installed. What shows up when building a 2.6 kernel on a 2.4 machine that's properly setup to do both is "depmod: Can't open /lib/modules/.../modules.dep for writing". -- Tom Rini http://gate.crashing.org/~trini/ - 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 07/15] Basic x86_64 support
On Sun, Aug 07, 2005 at 10:48:02AM +1000, Keith Owens wrote:
> On Thu, 4 Aug 2005 14:39:00 +0200,
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> >> > That doesn't make much sense here. tasklet will only run when interrupts
> >> > are enabled, and that is much later. You could move it to there.
> >>
> >> Where? Keep in mind it's really only x86_64 that isn't able to break
> >> sooner.
> >
> >The local_irq_enable() call in init/main.c:start_kernel()
> >
> >If you want to run gdb earlier you need to do it without a tasklet.
> >
> >> > > --- linux-2.6.13-rc3/include/asm-x86_64/hw_irq.h~x86_64-lite
> >> > > 2005-07-29 13:19:10.0 -0700
> >> > > +++ linux-2.6.13-rc3-trini/include/asm-x86_64/hw_irq.h 2005-07-29
> >> > > 13:19:10.0 -0700
> >> > > @@ -55,6 +55,7 @@ struct hw_interrupt_type;
> >> > > #define TASK_MIGRATION_VECTOR 0xfb
> >> > > #define CALL_FUNCTION_VECTOR 0xfa
> >> > > #define KDB_VECTOR0xf9
> >> > > +#define KGDB_VECTOR 0xf8
> >> >
> >> > I already allocated these vectors for something else.
> >>
> >> Is there another we can use? Just following what looked to be the
> >> logical order.
> >
> >How about you use KDB_VECTOR and rename it to DEBUG_VECTOR
> >and then just check if kgdb is currently active?
> >
> >KDB can do the same.
> >
> >I changed the assignment in my tree like this:
> >
> >#define SPURIOUS_APIC_VECTOR0xff
> >#define ERROR_APIC_VECTOR 0xfe
> >#define RESCHEDULE_VECTOR 0xfd
> >#define CALL_FUNCTION_VECTOR0xfc
> >#define KDB_VECTOR 0xfb/* reserved for KDB */
> >#define THERMAL_APIC_VECTOR 0xfa
> >/* 0xf9 free */
> >#define INVALIDATE_TLB_VECTOR_END 0xf8
> >#define INVALIDATE_TLB_VECTOR_START 0xf0/* f0-f8 used for TLB flush
> >*/
>
> Don't call it {KDB,KGDB,DEBUG}_VECTOR, call it NMI_VECTOR, which is
> what it really is. default_do_nmi() determines if the nmi is due to a
> debugger or some other event. That requires the debuggers to record if
> they are expecting their own nmi, putting all the load on the
> debuggers, where it belongs.
>
> IOW, add NMI_VECTOR to the base code, then add debugger support on top of
> NMI_VECTOR.
Works for me. I'll post something vs 2.6.13-rc6 later today hopefully
that does the rename.
--
Tom Rini
http://gate.crashing.org/~trini/
-
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 1/1] x86_64: Rename KDB_VECTOR to DEBUGGER_VECTOR
CC: Andi Kleen <[EMAIL PROTECTED]>, Keith Owens <[EMAIL PROTECTED]>
The existing hook from KDB in the IPI code is really just a hook for the
NMI vector. We rename the vector thusly and then it's up to the
debugger to handle things from default_do_nmi().
---
linux-2.6.13-rc6-trini/arch/x86_64/kernel/i8259.c |2 +-
linux-2.6.13-rc6-trini/arch/x86_64/kernel/smp.c|2 +-
linux-2.6.13-rc6-trini/arch/x86_64/kernel/traps.c |2 +-
linux-2.6.13-rc6-trini/include/asm-x86_64/hw_irq.h |2 +-
linux-2.6.13-rc6-trini/include/asm-x86_64/ipi.h|2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff -puN arch/x86_64/kernel/i8259.c~x86_64-rename_kdb_vector
arch/x86_64/kernel/i8259.c
--- linux-2.6.13-rc6/arch/x86_64/kernel/i8259.c~x86_64-rename_kdb_vector
2005-08-08 12:22:37.0 -0700
+++ linux-2.6.13-rc6-trini/arch/x86_64/kernel/i8259.c 2005-08-08
12:22:37.0 -0700
@@ -544,7 +544,7 @@ void __init init_IRQ(void)
int vector = FIRST_EXTERNAL_VECTOR + i;
if (i >= NR_IRQS)
break;
- if (vector != IA32_SYSCALL_VECTOR && vector != KDB_VECTOR) {
+ if (vector != IA32_SYSCALL_VECTOR && vector != NMI_VECTOR) {
set_intr_gate(vector, interrupt[i]);
}
}
diff -puN arch/x86_64/kernel/smp.c~x86_64-rename_kdb_vector
arch/x86_64/kernel/smp.c
--- linux-2.6.13-rc6/arch/x86_64/kernel/smp.c~x86_64-rename_kdb_vector
2005-08-08 12:22:37.0 -0700
+++ linux-2.6.13-rc6-trini/arch/x86_64/kernel/smp.c 2005-08-08
12:22:37.0 -0700
@@ -252,7 +252,7 @@ void flush_tlb_all(void)
void smp_kdb_stop(void)
{
- send_IPI_allbutself(KDB_VECTOR);
+ send_IPI_allbutself(NMI_VECTOR);
}
/*
diff -puN arch/x86_64/kernel/traps.c~x86_64-rename_kdb_vector
arch/x86_64/kernel/traps.c
--- linux-2.6.13-rc6/arch/x86_64/kernel/traps.c~x86_64-rename_kdb_vector
2005-08-08 12:22:37.0 -0700
+++ linux-2.6.13-rc6-trini/arch/x86_64/kernel/traps.c 2005-08-08
12:22:37.0 -0700
@@ -931,7 +931,7 @@ void __init trap_init(void)
set_system_gate(IA32_SYSCALL_VECTOR, ia32_syscall);
#endif
- set_intr_gate(KDB_VECTOR, call_debug);
+ set_intr_gate(NMI_VECTOR, call_debug);
/*
* Should be a barrier for any external CPU state.
diff -puN include/asm-x86_64/hw_irq.h~x86_64-rename_kdb_vector
include/asm-x86_64/hw_irq.h
--- linux-2.6.13-rc6/include/asm-x86_64/hw_irq.h~x86_64-rename_kdb_vector
2005-08-08 12:22:37.0 -0700
+++ linux-2.6.13-rc6-trini/include/asm-x86_64/hw_irq.h 2005-08-08
12:22:37.0 -0700
@@ -54,7 +54,7 @@ struct hw_interrupt_type;
#define RESCHEDULE_VECTOR 0xfc
#define TASK_MIGRATION_VECTOR 0xfb
#define CALL_FUNCTION_VECTOR 0xfa
-#define KDB_VECTOR 0xf9
+#define NMI_VECTOR 0xf9
#define THERMAL_APIC_VECTOR0xf0
diff -puN include/asm-x86_64/ipi.h~x86_64-rename_kdb_vector
include/asm-x86_64/ipi.h
--- linux-2.6.13-rc6/include/asm-x86_64/ipi.h~x86_64-rename_kdb_vector
2005-08-08 12:22:37.0 -0700
+++ linux-2.6.13-rc6-trini/include/asm-x86_64/ipi.h 2005-08-08
12:22:37.0 -0700
@@ -32,7 +32,7 @@
static inline unsigned int __prepare_ICR (unsigned int shortcut, int vector,
unsigned int dest)
{
unsigned int icr = APIC_DM_FIXED | shortcut | vector | dest;
- if (vector == KDB_VECTOR)
+ if (vector == NMI_VECTOR)
icr = (icr & (~APIC_VECTOR_MASK)) | APIC_DM_NMI;
return icr;
}
_
-
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 2.6.13-rc3] Change PowerPC MPC8xx maintainer
As Marcelo has been spending a great deal of time working on MPC8xx systems of late (thanks!) and has more time than I do now for it, I'm handing this over to him. Signed-off-by: Tom Rini <[EMAIL PROTECTED]> diff --git a/MAINTAINERS b/MAINTAINERS --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1416,13 +1416,20 @@ W: http://www.penguinppc.org/ L: [EMAIL PROTECTED] S: Maintained -LINUX FOR POWERPC EMBEDDED PPC8XX AND BOOT CODE +LINUX FOR POWERPC BOOT CODE P: Tom Rini M: [EMAIL PROTECTED] W: http://www.penguinppc.org/ L: [EMAIL PROTECTED] S: Maintained +LINUX FOR POWERPC EMBEDDED PPC8XX +P: Marcelo Tosatti +M: [EMAIL PROTECTED] +W: http://www.penguinppc.org/ +L: [EMAIL PROTECTED] +S: Maintained + LINUX FOR POWERPC EMBEDDED PPC83XX AND PPC85XX P: Kumar Gala M: [EMAIL PROTECTED] -- Tom Rini http://gate.crashing.org/~trini/ - 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 06/15] Basic IA64 support
CC: Robert Picco <[EMAIL PROTECTED]>, Tony Luck <[EMAIL PROTECTED]> This is support of the IA64 arch for KGDB. This is primarily the work of Robert Picco. There are also some IA64 changes in the serial patch so that IA64 can pass in IRQ and iomembase, and all of this is documented in the DocBook files. --- linux-2.6.13-rc3-trini/arch/ia64/kernel/Makefile |1 linux-2.6.13-rc3-trini/arch/ia64/kernel/entry.S|4 linux-2.6.13-rc3-trini/arch/ia64/kernel/ivt.S | 15 linux-2.6.13-rc3-trini/arch/ia64/kernel/kgdb-jmp.S | 238 linux-2.6.13-rc3-trini/arch/ia64/kernel/kgdb.c | 1038 + linux-2.6.13-rc3-trini/arch/ia64/kernel/mca.c | 10 linux-2.6.13-rc3-trini/arch/ia64/kernel/process.c |6 linux-2.6.13-rc3-trini/arch/ia64/kernel/smp.c | 17 linux-2.6.13-rc3-trini/arch/ia64/kernel/traps.c| 36 linux-2.6.13-rc3-trini/arch/ia64/kernel/unwind.c | 87 + linux-2.6.13-rc3-trini/arch/ia64/mm/extable.c |6 linux-2.6.13-rc3-trini/arch/ia64/mm/fault.c|5 linux-2.6.13-rc3-trini/include/asm-ia64/kgdb.h | 37 linux-2.6.13-rc3-trini/lib/Kconfig.debug |2 14 files changed, 1497 insertions(+), 5 deletions(-) diff -puN arch/ia64/kernel/entry.S~ia64-lite arch/ia64/kernel/entry.S --- linux-2.6.13-rc3/arch/ia64/kernel/entry.S~ia64-lite 2005-07-29 11:55:31.0 -0700 +++ linux-2.6.13-rc3-trini/arch/ia64/kernel/entry.S 2005-07-29 11:55:31.0 -0700 @@ -929,9 +929,9 @@ GLOBAL_ENTRY(ia64_leave_kernel) shr.u r18=r19,16// get byte size of existing "dirty" partition ;; mov r16=ar.bsp // get existing backing store pointer - addl r17=THIS_CPU(ia64_phys_stacked_size_p8),r0 +(pUStk)addl r17=THIS_CPU(ia64_phys_stacked_size_p8),r0 ;; - ld4 r17=[r17] // r17 = cpu_data->phys_stacked_size_p8 +(pUStk)ld4 r17=[r17] // r17 = cpu_data->phys_stacked_size_p8 (pKStk)br.cond.dpnt skip_rbs_switch /* diff -puN arch/ia64/kernel/ivt.S~ia64-lite arch/ia64/kernel/ivt.S --- linux-2.6.13-rc3/arch/ia64/kernel/ivt.S~ia64-lite 2005-07-29 11:55:31.0 -0700 +++ linux-2.6.13-rc3-trini/arch/ia64/kernel/ivt.S 2005-07-29 11:55:31.0 -0700 @@ -69,6 +69,13 @@ # define DBG_FAULT(i) #endif +#ifdef CONFIG_KGDB +#defineKGDB_ENABLE_PSR_DB mov r31=psr;; movl r30=IA64_PSR_DB;; or r31=r31,r30;; \ + mov psr.l=r31;; srlz.i;; +#else +#defineKGDB_ENABLE_PSR_DB +#endif + #define MINSTATE_VIRT /* needed by minstate.h */ #include "minstate.h" @@ -479,6 +486,7 @@ ENTRY(page_fault) movl r14=ia64_leave_kernel ;; SAVE_REST + KGDB_ENABLE_PSR_DB mov rp=r14 ;; adds out2=16,r12// out2 = pointer to pt_regs @@ -820,6 +828,7 @@ ENTRY(interrupt) srlz.i // ensure everybody knows psr.ic is back on ;; SAVE_REST + KGDB_ENABLE_PSR_DB ;; alloc r14=ar.pfs,0,0,2,0 // must be first in an insn group mov out0=cr.ivr // pass cr.ivr as first arg @@ -1066,6 +1075,7 @@ ENTRY(non_syscall) movl r15=ia64_leave_kernel ;; SAVE_REST + KGDB_ENABLE_PSR_DB mov rp=r15 ;; br.call.sptk.many b6=ia64_bad_break // avoid WAW on CFM and ignore return addr @@ -1099,6 +1109,7 @@ ENTRY(dispatch_unaligned_handler) adds r3=8,r2// set up second base pointer ;; SAVE_REST + KGDB_ENABLE_PSR_DB movl r14=ia64_leave_kernel ;; mov rp=r14 @@ -1141,6 +1152,10 @@ ENTRY(dispatch_to_fault_handler) adds r3=8,r2// set up second base pointer for SAVE_REST ;; SAVE_REST + cmp.eq p6,p0=29,out0 +(p6) br.cond.spnt 1f;; // debug_vector + KGDB_ENABLE_PSR_DB +1: movl r14=ia64_leave_kernel ;; mov rp=r14 diff -puN /dev/null arch/ia64/kernel/kgdb.c --- /dev/null 2005-07-25 10:57:32.312383000 -0700 +++ linux-2.6.13-rc3-trini/arch/ia64/kernel/kgdb.c 2005-07-29 11:55:31.0 -0700 @@ -0,0 +1,1038 @@ +/* + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2, or (at your option) any + * later version. + * + * This program is distributed in the hope that it will be useful, but + * WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * General Public License for more details. + * + */ + +/* + * Copyright (C) 2000-2001 VERITAS Software Corporation. + */ +/* + * Contributor: Lake Stevens Instrument Division$ + * Written by: Glenn Engel $ + * Updated by: Amit Kale<[EMAIL PROTECTED]> + * Modi
[patch 13/15] Minor SysRq keyboard bugfix for KGDB
CC: George Anzginer
It is possible that when SysRq-G is triggered via the keyboard that we will
miss the "up" event and once KGDB lets the kernel go another SysRq will be
required to clear this, without this change.
---
linux-2.6.13-rc3-trini/drivers/char/keyboard.c |1 +
1 files changed, 1 insertion(+)
diff -puN drivers/char/keyboard.c~sysrq_bugfix drivers/char/keyboard.c
--- linux-2.6.13-rc3/drivers/char/keyboard.c~sysrq_bugfix 2005-07-29
11:55:34.0 -0700
+++ linux-2.6.13-rc3-trini/drivers/char/keyboard.c 2005-07-29
11:55:34.0 -0700
@@ -1070,6 +1070,7 @@ static void kbd_keycode(unsigned int key
}
if (sysrq_down && down && !rep) {
handle_sysrq(kbd_sysrq_xlate[keycode], regs, tty);
+ sysrq_down = 0; /* In case we miss the 'up' event. */
return;
}
#endif
_
-
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 14/15] Allow KGDB to work well with loaded modules
CC: Amit S. Kale <[EMAIL PROTECTED]>
This allows for KGDB to better deal with autoloaded modules.
---
linux-2.6.13-rc3-trini/include/linux/module.h | 16 +++
linux-2.6.13-rc3-trini/kernel/module.c| 56 ++
2 files changed, 72 insertions(+)
diff -puN include/linux/module.h~module include/linux/module.h
--- linux-2.6.13-rc3/include/linux/module.h~module 2005-07-29
11:55:34.0 -0700
+++ linux-2.6.13-rc3-trini/include/linux/module.h 2005-07-29
11:55:34.0 -0700
@@ -210,8 +210,17 @@ enum module_state
MODULE_STATE_LIVE,
MODULE_STATE_COMING,
MODULE_STATE_GOING,
+ MODULE_STATE_GONE,
};
+#ifdef CONFIG_KGDB
+#define MAX_SECTNAME 31
+struct mod_section {
+ void *address;
+ char name[MAX_SECTNAME + 1];
+};
+#endif
+
/* Similar stuff for section attributes. */
#define MODULE_SECT_NAME_LEN 32
struct module_sect_attr
@@ -239,6 +248,13 @@ struct module
/* Unique handle for this module */
char name[MODULE_NAME_LEN];
+#ifdef CONFIG_KGDB
+ /* keep kgdb info at the begining so that gdb doesn't have a chance to
+* miss out any fields */
+ unsigned long num_sections;
+ struct mod_section *mod_sections;
+#endif
+
/* Sysfs stuff. */
struct module_kobject mkobj;
struct module_param_attrs *param_attrs;
diff -puN kernel/module.c~module kernel/module.c
--- linux-2.6.13-rc3/kernel/module.c~module 2005-07-29 11:55:34.0
-0700
+++ linux-2.6.13-rc3-trini/kernel/module.c 2005-07-29 11:55:34.0
-0700
@@ -617,6 +617,12 @@ sys_delete_module(const char __user *nam
if (ret != 0)
goto out;
+ down(¬ify_mutex);
+ notifier_call_chain(&module_notify_list, MODULE_STATE_GOING,
+ mod);
+ up(¬ify_mutex);
+
+
/* Never wait if forced. */
if (!forced && module_refcount(mod) != 0)
wait_for_zero_refcount(mod);
@@ -629,6 +635,11 @@ sys_delete_module(const char __user *nam
}
free_module(mod);
+ down(¬ify_mutex);
+ notifier_call_chain(&module_notify_list, MODULE_STATE_GONE,
+ NULL);
+ up(¬ify_mutex);
+
out:
up(&module_mutex);
return ret;
@@ -1167,6 +1178,11 @@ static void free_module(struct module *m
/* Arch-specific cleanup. */
module_arch_cleanup(mod);
+#ifdef CONFIG_KGDB
+ /* kgdb info */
+ vfree(mod->mod_sections);
+#endif
+
/* Module unload stuff */
module_unload_free(mod);
@@ -1401,6 +1417,31 @@ static void setup_modinfo(struct module
}
#endif
+#ifdef CONFIG_KGDB
+int add_modsects (struct module *mod, Elf_Ehdr *hdr, Elf_Shdr *sechdrs, const
+char *secstrings)
+{
+int i;
+
+mod->num_sections = hdr->e_shnum - 1;
+mod->mod_sections = vmalloc((hdr->e_shnum - 1)*
+ sizeof (struct mod_section));
+
+if (mod->mod_sections == NULL) {
+return -ENOMEM;
+}
+
+for (i = 1; i < hdr->e_shnum; i++) {
+mod->mod_sections[i - 1].address = (void *)sechdrs[i].sh_addr;
+strncpy(mod->mod_sections[i - 1].name, secstrings +
+sechdrs[i].sh_name, MAX_SECTNAME);
+mod->mod_sections[i - 1].name[MAX_SECTNAME] = '\0';
+ }
+
+ return 0;
+}
+#endif
+
#ifdef CONFIG_KALLSYMS
int is_exported(const char *name, const struct module *mod)
{
@@ -1768,6 +1809,12 @@ static struct module *load_module(void _
add_kallsyms(mod, sechdrs, symindex, strindex, secstrings);
+#ifdef CONFIG_KGDB
+if ((err = add_modsects(mod, hdr, sechdrs, secstrings)) < 0) {
+goto nomodsectinfo;
+}
+#endif
+
err = module_finalize(hdr, sechdrs, mod);
if (err < 0)
goto cleanup;
@@ -1815,6 +1862,11 @@ static struct module *load_module(void _
arch_cleanup:
module_arch_cleanup(mod);
cleanup:
+
+#ifdef CONFIG_KGDB
+nomodsectinfo:
+ vfree(mod->mod_sections);
+#endif
module_unload_free(mod);
module_free(mod, mod->module_init);
free_core:
@@ -1902,6 +1954,10 @@ sys_init_module(void __user *umod,
/* Init routine failed: abort. Try to protect us from
buggy refcounters. */
mod->state = MODULE_STATE_GOING;
+ down(¬ify_mutex);
+ notifier_call_chain(&module_notify_list, MODULE_STATE_GOING,
+ mod);
+ up(¬ify_mutex);
synchronize_sched();
if (mod->unsafe)
printk(KERN_ERR "%s: module is now stuck!\n",
_
-
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 09/15] KGDB: Basic ARM support.
CC: Russell King <[EMAIL PROTECTED]>, Deepak Saxena <[EMAIL PROTECTED]>, George
Davis <[EMAIL PROTECTED]>, Geoff Levand <[EMAIL PROTECTED]>, Nicolas Pitre
<[EMAIL PROTECTED]>
This adds a backend, written by Deepak Saxena <[EMAIL PROTECTED]> and George
Davis <[EMAIL PROTECTED]> as well as support for the TI OMAP boards, ADI
Coyote, PXA2xx, and ARM Versatile. Geoff Levand <[EMAIL PROTECTED]>
Nicolas Pitre, and Manish Lachwani have contributed various fixups here as
well. This should only require (on boards that don't have a custom uart)
registering the uart with KGDB to add any other boards, or using kgdboe it
should Just Work.
---
linux-2.6.13-rc3-trini/arch/arm/kernel/Makefile |1
linux-2.6.13-rc3-trini/arch/arm/kernel/kgdb-jmp.S| 30 +
linux-2.6.13-rc3-trini/arch/arm/kernel/kgdb.c| 208 +++
linux-2.6.13-rc3-trini/arch/arm/kernel/setup.c |5
linux-2.6.13-rc3-trini/arch/arm/kernel/traps.c | 11
linux-2.6.13-rc3-trini/arch/arm/mach-ixp2000/core.c |5
linux-2.6.13-rc3-trini/arch/arm/mach-ixp2000/ixdp2x01.c |6
linux-2.6.13-rc3-trini/arch/arm/mach-ixp4xx/coyote-setup.c |5
linux-2.6.13-rc3-trini/arch/arm/mach-ixp4xx/ixdp425-setup.c | 10
linux-2.6.13-rc3-trini/arch/arm/mach-omap1/board-osk.c |6
linux-2.6.13-rc3-trini/arch/arm/mach-omap1/serial.c |4
linux-2.6.13-rc3-trini/arch/arm/mach-pxa/Makefile|1
linux-2.6.13-rc3-trini/arch/arm/mach-pxa/kgdb-serial.c | 98 +
linux-2.6.13-rc3-trini/arch/arm/mach-versatile/kgdb_serial.c | 121 ++
linux-2.6.13-rc3-trini/arch/arm/mm/extable.c |7
linux-2.6.13-rc3-trini/drivers/serial/amba-pl011.c |2
linux-2.6.13-rc3-trini/drivers/serial/kgdb_8250.c| 16
linux-2.6.13-rc3-trini/include/asm-arm/kgdb.h| 90
linux-2.6.13-rc3-trini/include/asm-arm/system.h | 41 ++
linux-2.6.13-rc3-trini/lib/Kconfig.debug | 35 +
20 files changed, 695 insertions(+), 7 deletions(-)
diff -puN /dev/null arch/arm/kernel/kgdb.c
--- /dev/null 2005-07-25 10:57:32.312383000 -0700
+++ linux-2.6.13-rc3-trini/arch/arm/kernel/kgdb.c 2005-07-29
11:55:32.0 -0700
@@ -0,0 +1,208 @@
+/*
+ * arch/arm/kernel/kgdb.c
+ *
+ * ARM KGDB support
+ *
+ * Copyright (c) 2002-2004 MontaVista Software, Inc
+ *
+ * Authors: George Davis <[EMAIL PROTECTED]>
+ * Deepak Saxena <[EMAIL PROTECTED]>
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Make a local copy of the registers passed into the handler (bletch) */
+void regs_to_gdb_regs(unsigned long *gdb_regs, struct pt_regs *kernel_regs)
+{
+ int regno;
+
+ /* Initialize all to zero (??) */
+ for (regno = 0; regno < GDB_MAX_REGS; regno++)
+ gdb_regs[regno] = 0;
+
+ gdb_regs[_R0] = kernel_regs->ARM_r0;
+ gdb_regs[_R1] = kernel_regs->ARM_r1;
+ gdb_regs[_R2] = kernel_regs->ARM_r2;
+ gdb_regs[_R3] = kernel_regs->ARM_r3;
+ gdb_regs[_R4] = kernel_regs->ARM_r4;
+ gdb_regs[_R5] = kernel_regs->ARM_r5;
+ gdb_regs[_R6] = kernel_regs->ARM_r6;
+ gdb_regs[_R7] = kernel_regs->ARM_r7;
+ gdb_regs[_R8] = kernel_regs->ARM_r8;
+ gdb_regs[_R9] = kernel_regs->ARM_r9;
+ gdb_regs[_R10] = kernel_regs->ARM_r10;
+ gdb_regs[_FP] = kernel_regs->ARM_fp;
+ gdb_regs[_IP] = kernel_regs->ARM_ip;
+ gdb_regs[_SP] = kernel_regs->ARM_sp;
+ gdb_regs[_LR] = kernel_regs->ARM_lr;
+ gdb_regs[_PC] = kernel_regs->ARM_pc;
+ gdb_regs[_CPSR] = kernel_regs->ARM_cpsr;
+}
+
+/* Copy local gdb registers back to kgdb regs, for later copy to kernel */
+void gdb_regs_to_regs(unsigned long *gdb_regs, struct pt_regs *kernel_regs)
+{
+ kernel_regs->ARM_r0 = gdb_regs[_R0];
+ kernel_regs->ARM_r1 = gdb_regs[_R1];
+ kernel_regs->ARM_r2 = gdb_regs[_R2];
+ kernel_regs->ARM_r3 = gdb_regs[_R3];
+ kernel_regs->ARM_r4 = gdb_regs[_R4];
+ kernel_regs->ARM_r5 = gdb_regs[_R5];
+ kernel_regs->ARM_r6 = gdb_regs[_R6];
+ kernel_regs->ARM_r7 = gdb_regs[_R7];
+ kernel_regs->ARM_r8 = gdb_regs[_R8];
+ kernel_regs->ARM_r9 = gdb_regs[_R9];
+ kernel_regs->ARM_r10 = gdb_regs[_R10];
+ kernel_regs->ARM_fp = gdb_regs[_FP];
+ kernel_regs->ARM_ip = gdb_regs[_IP];
+ kernel_regs->ARM_sp = gdb_regs[_SP];
+ kernel_regs->ARM_lr = gdb_regs[_LR];
+ kernel_regs->ARM_pc = gdb_regs[_PC];
+ kernel_regs->ARM_cpsr = gdb_regs[GDB_MAX_REGS - 1];
+}
+
+static inline struct pt_regs *kgdb_get_user_regs(struct task_struct *task)
+{
+ return (struct pt_regs *)
+ ((unsigned long)task->thread_info + THREAD_SIZE -
+
[patch 07/15] Basic x86_64 support
+ struct pt_regs *r =
+ (void *)init_tss[cpu].ist[i] + EXCEPTION_STKSZ;
+ return r - 1;
+ }
+ return NULL;
+}
+
+void kgdb_shadowinfo(struct pt_regs *regs, char *buffer, unsigned threadid)
+{
+ static char intr_desc[] = "Stack at interrupt entrypoint";
+ static char exc_desc[] = "Stack at exception entrypoint";
+ struct pt_regs *stregs;
+ int cpu = hard_smp_processor_id();
+
+ if ((stregs = in_interrupt_stack(regs->rsp, cpu))) {
+ kgdb_mem2hex(intr_desc, buffer, strlen(intr_desc));
+ } else if ((stregs = in_exception_stack(regs->rsp, cpu))) {
+ kgdb_mem2hex(exc_desc, buffer, strlen(exc_desc));
+ }
+}
+
+struct task_struct *kgdb_get_shadow_thread(struct pt_regs *regs, int threadid)
+{
+ struct pt_regs *stregs;
+ int cpu = hard_smp_processor_id();
+
+ if ((stregs = in_interrupt_stack(regs->rsp, cpu)))
+ return current;
+ else if ((stregs = in_exception_stack(regs->rsp, cpu)))
+ return current;
+
+ return NULL;
+}
+
+struct pt_regs *kgdb_shadow_regs(struct pt_regs *regs, int threadid)
+{
+ struct pt_regs *stregs;
+ int cpu = hard_smp_processor_id();
+
+ if ((stregs = in_interrupt_stack(regs->rsp, cpu)))
+ return stregs;
+ else if ((stregs = in_exception_stack(regs->rsp, cpu)))
+ return stregs;
+
+ return NULL;
+}
+
+/* Register KGDB with the die_chain so that we hook into all of the right
+ * spots. */
+static int kgdb_notify(struct notifier_block *self, unsigned long cmd,
+ void *ptr)
+{
+ struct die_args *args = ptr;
+ struct pt_regs *regs = args->regs;
+
+ if (cmd == DIE_PAGE_FAULT && strcmp(args->str, "no context") == 0 &&
+ atomic_read(&debugger_active) && kgdb_may_fault) {
+ kgdb_fault_longjmp(kgdb_fault_jmp_regs);
+ return NOTIFY_STOP;
+ /* CPU roundup? */
+ } else if (atomic_read(&debugger_active) && cmd == DIE_NMI_IPI) {
+ kgdb_nmihook(smp_processor_id(), regs);
+ return NOTIFY_STOP;
+ /* See if KGDB is interested. */
+ } else if (cmd == DIE_PAGE_FAULT || user_mode(regs) ||
+ cmd == DIE_NMI_IPI || (cmd == DIE_DEBUG &&
+ atomic_read(&debugger_active)))
+ /* Userpace events, normal watchdog event, or spurious
+* debug exception. Ignore. */
+ return NOTIFY_DONE;
+
+ kgdb_handle_exception(args->trapnr, args->signr, args->err, regs);
+
+ return NOTIFY_STOP;
+}
+
+static struct notifier_block kgdb_notifier = {
+ .notifier_call = kgdb_notify,
+ .priority = 0x7fff, /* we need to notified first */
+};
+
+int kgdb_arch_init(void)
+{
+ notifier_chain_register(&die_chain, &kgdb_notifier);
+ return 0;
+}
+
+struct kgdb_arch arch_kgdb_ops = {
+ .gdb_bpt_instr = {0xcc},
+ .flags = KGDB_HW_BREAKPOINT,
+ .shadowth = 1,
+};
diff -puN /dev/null arch/x86_64/kernel/kgdb-jmp.S
--- /dev/null 2005-07-25 10:57:32.312383000 -0700
+++ linux-2.6.13-rc3-trini/arch/x86_64/kernel/kgdb-jmp.S2005-07-29
13:19:10.0 -0700
@@ -0,0 +1,65 @@
+/*
+ * arch/x86_64/kernel/kgdb-jmp.S
+ *
+ * Save and restore system registers so that within a limited frame we
+ * may have a fault and "jump back" to a known safe location.
+ *
+ * Author: Tom Rini <[EMAIL PROTECTED]>
+ *
+ * Cribbed from glibc, which carries the following:
+ * Copyright (C) 2001, 2003, 2004 Free Software Foundation, Inc.
+ * Copyright (C) 2005 by MontaVista Software.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program as licensed "as is" without any warranty of
+ * any kind, whether express or implied.
+ */
+
+#include
+
+#define JB_RBX 0
+#define JB_RBP 1
+#define JB_R12 2
+#define JB_R13 3
+#define JB_R14 4
+#define JB_R15 5
+#define JB_RSP 6
+#define JB_PC 7
+
+ .code64
+
+/* This must be called prior to kgdb_fault_longjmp and
+ * kgdb_fault_longjmp must not be called outside of the context of the
+ * last call to kgdb_fault_setjmp.
+ */
+ENTRY(kgdb_fault_setjmp)
+ /* Save registers. */
+ movq %rbx, (JB_RBX*8)(%rdi)
+ movq %rbp, (JB_RBP*8)(%rdi)
+ movq %r12, (JB_R12*8)(%rdi)
+ movq %r13, (JB_R13*8)(%rdi)
+ movq %r14, (JB_R14*8)(%rdi)
+ movq %r15, (JB_R15*8)(%rdi)
+ leaq 8(%rsp), %rdx /* Save SP as it will be after we return. */
+ movq %rdx, (JB_RSP*8)(%rdi)
+ movq (%rsp), %rax /* Save PC we are returning to now. */
+ movq %rax, (JB_PC*
