From johnrose at austin.ibm.com Fri Oct 1 01:45:15 2004 From: johnrose at austin.ibm.com (John Rose) Date: Thu, 30 Sep 2004 10:45:15 -0500 Subject: Why do we map PCI IO space so late ? In-Reply-To: <1096532573.32754.13.camel@gaston> References: <1096532573.32754.13.camel@gaston> Message-ID: <1096559115.27021.33.camel@sinatra.austin.ibm.com> Hi Ben- Good questions :) First let me clear something up, and forgive me if I'm telling you stuff you already know. The ioremap()'s that we do at boot are _exclusively_ done for PHBs. This creates mappings that span the ranges for their children buses. Why do we do this when drivers can themselves use ioremap()? Because some drivers still use inb()/outb(), etc, without remapping their own space. The short answer to your questions is that I/O DLPAR required these PHB ioremap()'s to be moved to a later chronological point during boot, so that imalloc records would be kept. Here's the long answer. To dynamically remove a bus (EADS or PHB), we need to iounmap() the range associated with it. The iounmap() function is prototyped in generic code to take one argument, the virtual address in question. In order to know the size of the region to unmap, we need to keep some records of what was ioremap()'ed originally. The imalloc subsystem exists to keep these records. The ppc64 ioremap() implementation has the limitation that if one calls it before mem_init_done, no imalloc records are left behind. If we remap the PHBs early in boot, we have no way to unmap them (or their children) at DLPAR remove time. Does this make sense? As a side note, we didn't similarly defer the remap for ISA, b/c we assumed that we'd never want to unmap this range. I wrote the function that remaps for ISA, and it's a hack, you're right :) Suggestions are welcome. I would ask why your ISA node doesn't have a ranges property, b/c I thought it was mandatory from some spec. You asked about ioremap_explicit(). This is used in two ways. First during boot, to remap the necessary regions for PHBs after mem_init_done. We've saved off the "physical" range info from the ofdt early in boot, and now we explicitly remap starting at virtual addr PHBS_IO_BASE. Second, we use it to remap the range of a newly DLPAR-added bus. You can imagine that in the case of adding an EADS slot, we need the mappings to exist at exact virtual addresses relative to its parent PHB, etc. Hence the creation of ioremap_explicit(). Suggestions on improvements are welcome. Hope this helps, it's before lunch and I'm being wordy. :) Thanks- John On Thu, 2004-09-30 at 03:22, Benjamin Herrenschmidt wrote: > Hi John ! > > I was going through some of the PCI setup code while working on > some bringup stuff, and had an issue which was related to the way > we do the ioremap'ing of the PCI IO space. > > So the current scenario is: > > - early (setup_arch() time basically), we ioremap_explicit the ISA > space and that only > > - later (pcibios_fixup time), we scan all busses and ioremap_explicit > their various IO spaces. > > I have two problems with that at the moment. > > First is, I'm annoyed that during the actual PCI probing, the IO space > is not mapped. That means that any quirk that needs IO accesses to the > device will not work. I wonder also in which conditions we might end up > instanciating a PCI driver as early as the PCI probing and thus crash. > Also, this is all after console_initcalls(), so that leaves a gap of > code that runs with PCI IO space not mapped. So far, it ended up beeing > mostly ok because our console uses legacy serial drivers that use the > ISA space which happen to be mapped early, but that sounds fragile & > bogus to me. (For the short story, I found that while working on a board > for which the "isa" node didn't have a "ranges" property, so we failed > to early map it, thus the serial driver would crash doing IO cycles). > Why can't we do the ioremap_explicit right after setting up the PHBs ? > > The second thing that annoys me is that it seems we are also doing an > ioremap_explicit for each p2p bridge IO space, aren't we ? I don't fully > understand the logic here. Aren't those supposed to be fully enclosed by > their parent PHB IO space, and thus mapped by those ? > > Thanks for enlightening me, > Ben. > > > > From segher at kernel.crashing.org Fri Oct 1 02:38:20 2004 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Thu, 30 Sep 2004 11:38:20 -0500 Subject: reading files in /proc/device-tree In-Reply-To: <1096546849.3081.2.camel@gaston> References: <20040929101700.GA2623@in.ibm.com> <1096546849.3081.2.camel@gaston> Message-ID: <23A68A84-12FF-11D9-8370-000A95A4DC02@kernel.crashing.org> >> Also, the format of the entries is dependent on the >> #address-cells and #sized-cells properties. > > ... of the parent node :) read the OF spec for more details Of the first (not necessarily immediate) parent that has those properties, yes. As memory is a child of the root node, it will be its direct parent, yes. Segher From david at gibson.dropbear.id.au Fri Oct 1 14:03:25 2004 From: david at gibson.dropbear.id.au (David Gibson) Date: Fri, 1 Oct 2004 14:03:25 +1000 Subject: mapping memory in 0xb space In-Reply-To: References: <20040929014017.GC5470@zax> Message-ID: <20041001040325.GB12890@zax> On Wed, Sep 29, 2004 at 12:14:08AM -0500, Igor Grobman wrote: > On Wed, 29 Sep 2004, David Gibson wrote: > > > On Tue, Sep 28, 2004 at 01:52:16PM -0500, Igor Grobman wrote: > > > On Tue, 28 Sep 2004, David Gibson wrote: > > > > > > > Recent kernels don't even > > > > have VSIDs allocated for the 0xb... region. > > > > > > Looking at both 2.6.8 and 2.4.21, I don't see a difference in > > > get_kernel_vsid() code. > > > > Ok, *very* recent kernels. The new VSID algorithm has gone into the > > BK tree since 2.6.8. > > >From the description I read, I might be better off using 0xfff.. addresses > with that algorithm. Not a big deal. Perhaps. However, there are issues there as well: older kernels have the same 41-bit address restriction (maybe somewhat extendable) in the 0xf region, just like 0xb. The new VSID algo gives VSIDs for every address above 0xc000000000000000 *except* the very last segment, 0xfffffffff0000000-0xffffffffffffffff. > > > This leaves segments. Both > > > DataAccess_common and DataAccessSLB_common call > > > do_stab_bolted/do_slb_bolted when confronted with an address in 0xb > > > region. > > > > Oh, so it does. That, I think is a 2.4 thing, long gone in 2.6 (even > > before the SLB rewrite, I'm pretty sure do_slb_bolted was only called > > for 0xc addresses). > > In my 2.4.21 source, do_slb_bolted does get called for 0xb addresses. > And thanks for letting me know about power4 being SLB. I was clueless on > the issue. > > > Presumably, this will fault in the segments I am interested in. > > > > Yes, actually, it should. Ok, I guess the problem is deeper than I > > thought. > > Or is it? > > > > Also, I narrowed it down to > > > working (or appearing to work) as long as the highest 5 bits of the page > > > index (those that end up as partial index in the HPTE) are zero. This may > > > just be a weird coincidence. > > > > Could be. > > > > > > Why on earth do you want to do this? > > > > > > Good question ;-). A long long time ago, I posted on this list and > > > explained. Since then, I found what appeared to be a solution, except > > > that it appears power4 breaks it. I am building a tool that allows > > > dynamic splicing of code into a running kernel (see > > > http://www.paradyn.org/html/kerninst.html). In order for this to work, I > > > need to be able to overwrite a single instruction with a jump to > > > spliced-in code. The target of the jump needs to be within the range (26 > > > bits). Therefore, I have a choice of 0xbfff.. addresses with backward > > > jumps from 0xc region, or the 0xff.. addresses for absolute jumps. I > > > chose 0xbff.., because I found already-working code, originally written > > > for the performance counter interface. Am I making more sense now? > > > > Aha! But this does actually explain the problem - there are only > > VSIDs assigned for the first 2^41 bits of each region - so although > > there are vsids for 0xb000000000000000-0xb00001ffffffffff, there > > aren't any for 0xbff... addresses. Likewise the Linux pagetables only > > cover a 41-bit address range, but that won't matter if you're creating > > HPTEs directly. > > And this is why I avoided explaining fully in my first email :-). I'd > like to solve one problem at a time. What I said in my initial email > is accurate. Even within the valid VSID range, if the highest 5 bits of > the page index are not zero, I get a crash on access (e.g. > 0xb00001FFFFF00000, but works on 0xb00001FFF0000000). Hrm. Ok. I'm not sure why that would be. > As for why I thought 0xbff would work, I reasoned that > since the highest bits are masked out in get_kernel_vsid(), and since > nobody else is using the 0xb region, it doesn't matter if I get a VSID > that is the same as some other VSID in 0xb region. However, I did not > consider the bug in do_slb_bolted that you describe below. Yes, with that bug the collision can be with a segment anywhere, not just in the 0xb region. > > You may have seen the comment in do_slb_bolted which claims to permit > > a full 32-bits of ESID - it's wrong. The code doesn't mask the ESID > > down to 13 bits as get_kernel_vsid() does, but it probably should - an > > overlarge ESID will cause collisions with VSIDs from entirely > > different address places, which would be a Bad Thing. > > This must be happening, although I would still like to know why it > misbehaves even within the valid VSID range. > > > > > Actually, you should be able to allow ESIDs of up to 21 bits there (36 > > bit VSID - 15 bits of "context"). But you will need to make sure > > get_kernel_vsid(), or whatever you're using to calculate the VAs for > > the hash HPTEs is updated to match - at the moment I think it will > > mask down to 13 bits. I'm not sure if that will get you sufficiently > > close to 0xc0... for your purposes. > > No, it's not close enough--I really must have that very last segment. > It sounds like I was simply getting lucky on the power3 machine. > Without the mask, I must have been getting random pages, and > happily overwriting them. > > Any ideas on how I might map that very last segment of 0xb, or for > that matter the very last segment of 0xf ? It need not be pretty, > but it cannot involve modifying the kernel source, though it can rely on > whatever dirty tricks a kernel module might get away with. I don't > want to modify the source, because I would like the tool to work on > unmodified kernels. Um... right. You know, I'm really not sure its possible without changing the kernel source, short of binary patching the do_slb_bolted code from a module. Sorry. The segment code's just really not set up to handle this. Though, come to that, you do only need one segment, so it might not be that hard to binary patch in branch to some code of your own which provides a VSID for that one segment. > It's starting to sound like an impossible task (at least on non-recent > kernels). I think I might go with a backup suboptimal solution, which > involves extra jumps, but at least it might work. That may be a better idea. -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson From benh at kernel.crashing.org Fri Oct 1 17:21:04 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 01 Oct 2004 17:21:04 +1000 Subject: Why do we map PCI IO space so late ? In-Reply-To: <1096559115.27021.33.camel@sinatra.austin.ibm.com> References: <1096532573.32754.13.camel@gaston> <1096559115.27021.33.camel@sinatra.austin.ibm.com> Message-ID: <1096615264.11463.93.camel@gaston> On Fri, 2004-10-01 at 01:45, John Rose wrote: > Hi Ben- > > Good questions :) First let me clear something up, and forgive me if > I'm telling you stuff you already know. The ioremap()'s that we do at > boot are _exclusively_ done for PHBs. This creates mappings that span > the ranges for their children buses. Why do we do this when drivers can > themselves use ioremap()? Because some drivers still use inb()/outb(), > etc, without remapping their own space. Yah, that at least is obvious :) > The short answer to your questions is that I/O DLPAR required these PHB > ioremap()'s to be moved to a later chronological point during boot, so > that imalloc records would be kept. Okay, that makes more sense to me now. > Here's the long answer. To dynamically remove a bus (EADS or PHB), we > need to iounmap() the range associated with it. The iounmap() function > is prototyped in generic code to take one argument, the virtual address > in question. In order to know the size of the region to unmap, we need > to keep some records of what was ioremap()'ed originally. The imalloc > subsystem exists to keep these records. Right. > The ppc64 ioremap() implementation has the limitation that if one calls > it before mem_init_done, no imalloc records are left behind. If we > remap the PHBs early in boot, we have no way to unmap them (or their > children) at DLPAR remove time. Does this make sense? Yup. > As a side note, we didn't similarly defer the remap for ISA, b/c we > assumed that we'd never want to unmap this range. I wrote the function > that remaps for ISA, and it's a hack, you're right :) Suggestions are > welcome. I would ask why your ISA node doesn't have a ranges property, > b/c I thought it was mandatory from some spec. The OF tree of this board is still a work in progress. It has to be mapped early anyway for other reasons, like the console serial driver which will be initialized before we do the real mapping. > You asked about ioremap_explicit(). This is used in two ways. First > during boot, to remap the necessary regions for PHBs after > mem_init_done. We've saved off the "physical" range info from the ofdt > early in boot, and now we explicitly remap starting at virtual addr > PHBS_IO_BASE. Second, we use it to remap the range of a newly > DLPAR-added bus. You can imagine that in the case of adding an EADS > slot, we need the mappings to exist at exact virtual addresses relative > to its parent PHB, etc. Hence the creation of ioremap_explicit(). > > Suggestions on improvements are welcome. Hope this helps, it's before > lunch and I'm being wordy. :) Thanks, it's enough for now, I need to think of alternative (read: simpler) ways to deal with that in the future, but for now, it's fine. Ben. From david at gibson.dropbear.id.au Fri Oct 1 18:45:14 2004 From: david at gibson.dropbear.id.au (David Gibson) Date: Fri, 1 Oct 2004 18:45:14 +1000 Subject: [PPC64] Change bad choice of VSID_MULTIPLIER Message-ID: <20041001084514.GB19046@zax> Andrew/Linus, please apply: We recently changed the VSID allocation on PPC64 to use a new scheme based on a multiplicative hash. It turns out our choice of multiplier (the largest 28-bit prime) wasn't so great: with large contiguous mappings, we can get very poor hash scattering. In particular earlier machines (without 16M pages) which had a reasonable about of RAM (>2G or so) wouldn't boot, because the linear mapping overflowed some hash buckets. This patch changes the multiplier to something which seems to work better (it is, rather arbitrarily, the median of the primes between 2^27 and 2^28). Some more theory should almost certainly go into the choice of this constant, to avoid more pathological cases. But for now, this choice fixes a serious bug, and seems to do at least as well at scattering as the old choice on a handful of simple testcases. Signed-off-by: David Gibson Index: working-2.6/include/asm-ppc64/mmu_context.h =================================================================== --- working-2.6.orig/include/asm-ppc64/mmu_context.h 2004-09-20 10:12:50.000000000 +1000 +++ working-2.6/include/asm-ppc64/mmu_context.h 2004-10-01 18:28:01.565963320 +1000 @@ -108,11 +108,10 @@ * * This scramble is only well defined for proto-VSIDs below * 0xFFFFFFFFF, so both proto-VSID and actual VSID 0xFFFFFFFFF are - * reserved. VSID_MULTIPLIER is prime (the largest 28-bit prime, in - * fact), so in particular it is co-prime to VSID_MODULUS, making this - * a 1:1 scrambling function. Because the modulus is 2^n-1 we can - * compute it efficiently without a divide or extra multiply (see - * below). + * reserved. VSID_MULTIPLIER is prime, so in particular it is + * co-prime to VSID_MODULUS, making this a 1:1 scrambling function. + * Because the modulus is 2^n-1 we can compute it efficiently without + * a divide or extra multiply (see below). * * This scheme has several advantages over older methods: * Index: working-2.6/include/asm-ppc64/mmu.h =================================================================== --- working-2.6.orig/include/asm-ppc64/mmu.h 2004-09-20 10:12:50.000000000 +1000 +++ working-2.6/include/asm-ppc64/mmu.h 2004-10-01 18:28:01.566963168 +1000 @@ -202,7 +202,7 @@ #define SLB_VSID_KERNEL (SLB_VSID_KP|SLB_VSID_C) #define SLB_VSID_USER (SLB_VSID_KP|SLB_VSID_KS) -#define VSID_MULTIPLIER ASM_CONST(268435399) /* largest 28-bit prime */ +#define VSID_MULTIPLIER ASM_CONST(200730139) /* 28-bit prime */ #define VSID_BITS 36 #define VSID_MODULUS ((1UL<>SID_SHIFT) - .llong 0x40bffffd5 /* KERNELBASE VSID */ + .llong 0x408f92c94 /* KERNELBASE VSID */ /* We have to list the bolted VMALLOC segment here, too, so that it * will be restored on shared processor switch */ .llong (VMALLOCBASE>>SID_SHIFT) - .llong 0xb0cffffd1 /* VMALLOCBASE VSID */ + .llong 0xf09b89af5 /* VMALLOCBASE VSID */ .llong 8192 /* # pages to map (32 MB) */ .llong 0 /* Offset from start of loadarea to start of map */ - .llong 0x40bffffd50000 /* VPN of first page to map */ + .llong 0x408f92c940000 /* VPN of first page to map */ . = 0x6100 -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson From grave at ipno.in2p3.fr Sat Oct 2 02:04:14 2004 From: grave at ipno.in2p3.fr (grave) Date: Fri, 01 Oct 2004 16:04:14 +0000 Subject: XServe Node running a debian with only one processor In-Reply-To: <1096548321l.32616l.0l@ipnnarval> (from grave@ipno.in2p3.fr on Thu Sep 30 14:45:21 2004) References: <1096546729l.32147l.0l@ipnnarval> <1096548321l.32616l.0l@ipnnarval> Message-ID: <1096646654l.2901l.2l@ipnnarval> Got the xserve booting (thanks to http://ozlabs.org/ppc64-patches/patch.pl?id=59) But I can only run a single CPU kernel, does somebody know how to get the second CPU on ? The kernel is a ppc64 one with smp compiled in but only able to boot with nosmp option kernel from kernel.org + patch to setup.c and pmac_features.c) Thanks in advance for any hint... xavier From igor at cs.wisc.edu Sat Oct 2 04:05:12 2004 From: igor at cs.wisc.edu (Igor Grobman) Date: Fri, 1 Oct 2004 13:05:12 -0500 (CDT) Subject: mapping memory in 0xb space In-Reply-To: <20041001040325.GB12890@zax> References: <20040929014017.GC5470@zax> <20041001040325.GB12890@zax> Message-ID: A question for the rest of you, who haven't been following this thread. Is there publicly available documentation on the power4 extensions, specifically the large page support, how it effects the HPT hashing, and the SLB, including the new instructions for maintaining it in software? I haven't been able to find anything yet. On Fri, 1 Oct 2004, David Gibson wrote: > On Wed, Sep 29, 2004 at 12:14:08AM -0500, Igor Grobman wrote: > > On Wed, 29 Sep 2004, David Gibson wrote: > > > > > On Tue, Sep 28, 2004 at 01:52:16PM -0500, Igor Grobman wrote: > > > > On Tue, 28 Sep 2004, David Gibson wrote: > > > > > > > > > Recent kernels don't even > > > > > have VSIDs allocated for the 0xb... region. > > > > > > > > Looking at both 2.6.8 and 2.4.21, I don't see a difference in > > > > get_kernel_vsid() code. > > > > > > Ok, *very* recent kernels. The new VSID algorithm has gone into the > > > BK tree since 2.6.8. > > > > >From the description I read, I might be better off using 0xfff.. addresses > > with that algorithm. Not a big deal. > > Perhaps. However, there are issues there as well: older kernels have > the same 41-bit address restriction (maybe somewhat extendable) in the > 0xf region, just like 0xb. The new VSID algo gives VSIDs for every > address above 0xc000000000000000 *except* the very last segment, > 0xfffffffff0000000-0xffffffffffffffff. Lucky me! I'll take a look at what the VSID for the last segment conflicts with, maybe it will be something unused. Or I'll have to think of something else clever. Right now, I still want my 2.4.21 implementation to work. > > > > Also, I narrowed it down to > > > > working (or appearing to work) as long as the highest 5 bits of the page > > > > index (those that end up as partial index in the HPTE) are zero. This may > > > > just be a weird coincidence. > > > > > > Could be. > > > > > > > > Why on earth do you want to do this? > > > > > > > > Good question ;-). A long long time ago, I posted on this list and > > > > explained. Since then, I found what appeared to be a solution, except > > > > that it appears power4 breaks it. I am building a tool that allows > > > > dynamic splicing of code into a running kernel (see > > > > http://www.paradyn.org/html/kerninst.html). In order for this to work, I > > > > need to be able to overwrite a single instruction with a jump to > > > > spliced-in code. The target of the jump needs to be within the range (26 > > > > bits). Therefore, I have a choice of 0xbfff.. addresses with backward > > > > jumps from 0xc region, or the 0xff.. addresses for absolute jumps. I > > > > chose 0xbff.., because I found already-working code, originally written > > > > for the performance counter interface. Am I making more sense now? > > > > > > Aha! But this does actually explain the problem - there are only > > > VSIDs assigned for the first 2^41 bits of each region - so although > > > there are vsids for 0xb000000000000000-0xb00001ffffffffff, there > > > aren't any for 0xbff... addresses. Likewise the Linux pagetables only > > > cover a 41-bit address range, but that won't matter if you're creating > > > HPTEs directly. > > > > And this is why I avoided explaining fully in my first email :-). I'd > > like to solve one problem at a time. What I said in my initial email > > is accurate. Even within the valid VSID range, if the highest 5 bits of > > the page index are not zero, I get a crash on access (e.g. > > 0xb00001FFFFF00000, but works on 0xb00001FFF0000000). > > Hrm. Ok. I'm not sure why that would be. Here is some more background. Maybe it will help you think of what's going wrong here. I noticed that if I write to the remapped 0xb00001FFF0000000, the changes do not show up at the physical address I mapped it to. At this point, I noticed that get_free_page() returns a 4K page frame above 256MB, which means that in reality, it's an address within a large page. SLB entry created by do_slb_bolted likewise has the large page bit set. I changed my code to create an HPTE mapping for the large page, and finally I get a sensible result: changes to the remapped page show up on the physical page. Note that even though I create a mapping for the whole large page, I only write to the 4K chunk that corresponds to the address returned by get_free_page() -- I do not want to clobber random memory. In summary, mapping the first large page of the 0xb00001FFF segment works, but mapping any other within that segment causes a kernel crash. There must be something I don't understand about how large pages fit into the HPT. Could you point me to documentation on the large page extensions of power4, and, while we are at it, documentation on the SLB? So far, I simply guessed on how it works, based on the code I see in the kernel. For what it's worth, here is (roughly) the relevant code I am using: frame = get_free_page(GFP_KERNEL); pa = (unsigned long)__v2a(frame) & 0xFFFFFFFFFF000000; //want physical address to point to the corresponding large page. ea = 0xb00001FFFF000000; vsid = get_kernel_vsid(ea); va = ( vsid << 28 ) | ( ea & 0xfffffff ); vpn = va >> PAGE_SHIFT; rpn = pa >> PAGE_SHIFT; hpteflags = _PAGE_ACCESSED|_PAGE_COHERENT|PP_RWXX; slot = ppc_md->hpte_insert(vpn, rpn, hpteflags, 1, 1); smallpage_offset = ( (unsigned long) __v2a(frame) - pa) return ea + smallpage_offset; //only access the relevant 4K chunk within the large page > > > As for why I thought 0xbff would work, I reasoned that > > since the highest bits are masked out in get_kernel_vsid(), and since > > nobody else is using the 0xb region, it doesn't matter if I get a VSID > > that is the same as some other VSID in 0xb region. However, I did not > > consider the bug in do_slb_bolted that you describe below. > > Yes, with that bug the collision can be with a segment anywhere, not > just in the 0xb region. OK, I will deal with this, somehow. Binary patch idea might just work. > Though, come to that, you do only need one segment, so it might not be > that hard to binary patch in branch to some code of your own which > provides a VSID for that one segment. > > > It's starting to sound like an impossible task (at least on non-recent > > kernels). I think I might go with a backup suboptimal solution, which > > involves extra jumps, but at least it might work. > > That may be a better idea. I'd like to avoid this, but if I only have to incur this for the binary patch to do_slb_bolted, I might be fine. Thanks, Igor From jschopp at austin.ibm.com Sat Oct 2 06:41:55 2004 From: jschopp at austin.ibm.com (Joel Schopp) Date: Fri, 01 Oct 2004 15:41:55 -0500 Subject: [PATCH][0/2] ppc64 pre/post boot memory macros Message-ID: <415DC113.1080007@austin.ibm.com> I'm sending two patches for review and passing upstream. The basic idea is that these patches put in place some macros such that memory management can be easily split into pre and post boot. This is based on the work of Mike Kravetz and Dave Hansen. It should be harmless, as the new macros are currently defined to the same thing the old macros were. It is also isolated to ppc64 files, so the other arch guys don't need to worry. Ultimatly my motivation is to move toward hotplug memory. Acceptance of these patches will allow us to carry smaller patches out of mainline and ease our development greatly. Comments/feedback/flames welcome. Patches against 2.6.9-rc3 and have been boot tested on Power5 LPAR. From jschopp at austin.ibm.com Sat Oct 2 06:43:27 2004 From: jschopp at austin.ibm.com (Joel Schopp) Date: Fri, 01 Oct 2004 15:43:27 -0500 Subject: [PATCH][1/2] ppc64 pre/post boot memory macros In-Reply-To: <415DC113.1080007@austin.ibm.com> References: <415DC113.1080007@austin.ibm.com> Message-ID: <415DC16F.7030402@austin.ibm.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ppc64-daveh.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041001/14bca17c/attachment.txt From jschopp at austin.ibm.com Sat Oct 2 06:43:56 2004 From: jschopp at austin.ibm.com (Joel Schopp) Date: Fri, 01 Oct 2004 15:43:56 -0500 Subject: [PATCH][2/2] ppc64 pre/post boot memory macros In-Reply-To: <415DC113.1080007@austin.ibm.com> References: <415DC113.1080007@austin.ibm.com> Message-ID: <415DC18C.6040501@austin.ibm.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ppc64-dave-hmore.patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041001/52e74dd2/attachment.txt From schwab at suse.de Sat Oct 2 07:40:04 2004 From: schwab at suse.de (Andreas Schwab) Date: Fri, 01 Oct 2004 23:40:04 +0200 Subject: Machine check during PCI scan on PMac G5 Message-ID: Has anyone been able to get 2.6.9-rc3 running on the new PMacs (PowerMac7,3)? I'm getting a machine check during PCI scan in u3_ht_read_config while doing in_8 on 0xe00000008094800e. Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux AG, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From benh at kernel.crashing.org Sat Oct 2 21:17:01 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sat, 02 Oct 2004 21:17:01 +1000 Subject: Machine check during PCI scan on PMac G5 In-Reply-To: References: Message-ID: <1096715821.26913.35.camel@gaston> On Sat, 2004-10-02 at 07:40, Andreas Schwab wrote: > Has anyone been able to get 2.6.9-rc3 running on the new PMacs > (PowerMac7,3)? I'm getting a machine check during PCI scan in > u3_ht_read_config while doing in_8 on 0xe00000008094800e. Argh... again ! Looks like the box doesn't like us to probe the PCI device that is there. Can you print out the precise devfn bus number & offset where the machine check happens ? I wonder if it's something that is turned off by the firmware like one of the K2 internal USB1 controllers that are unused on this machine. K2 is notoriously allergic to us probing things that are turned off. This patch should help by preventing the config space accesses to occur on those devices that aren't in the device-tree, I'll push it to Linus as a temporary fix if you confirm it works. Ben. ===== arch/ppc64/kernel/pmac_pci.c 1.5 vs edited ===== --- 1.5/arch/ppc64/kernel/pmac_pci.c 2004-07-25 14:51:52 +10:00 +++ edited/arch/ppc64/kernel/pmac_pci.c 2004-08-04 10:26:07 +10:00 @@ -271,7 +271,7 @@ int offset, int len, u32 *val) { struct pci_controller *hose; - struct device_node *busdn; + struct device_node *busdn, *dn; unsigned long addr; if (bus->self) @@ -282,6 +282,16 @@ return PCIBIOS_DEVICE_NOT_FOUND; hose = busdn->phb; if (hose == NULL) + return PCIBIOS_DEVICE_NOT_FOUND; + + /* We only allow config cycles to devices that are in OF device-tree + * as we are apparently having some weird things going on with some + * revs of K2 on recent G5s + */ + for (dn = busdn->child; dn; dn = dn->sibling) + if (dn->devfn == devfn) + break; + if (dn == NULL) return PCIBIOS_DEVICE_NOT_FOUND; addr = u3_ht_cfg_access(hose, bus->number, devfn, offset); From benh at kernel.crashing.org Sat Oct 2 21:21:57 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sat, 02 Oct 2004 21:21:57 +1000 Subject: XServe Node running a debian with only one processor In-Reply-To: <1096646654l.2901l.2l@ipnnarval> References: <1096546729l.32147l.0l@ipnnarval> <1096548321l.32616l.0l@ipnnarval> <1096646654l.2901l.2l@ipnnarval> Message-ID: <1096716117.3634.40.camel@gaston> On Sat, 2004-10-02 at 02:04, grave wrote: > Got the xserve booting > (thanks to http://ozlabs.org/ppc64-patches/patch.pl?id=59) > > But I can only run a single CPU kernel, does somebody know how to get > the second CPU on ? > > The kernel is a ppc64 one with smp compiled in but only able to boot > with nosmp option > kernel from kernel.org + patch to setup.c and pmac_features.c) > > Thanks in advance for any hint... What exact version ? what patches ? What happens (last printed on serial console) if you try to boot SMP ? Ben. From schwab at suse.de Sun Oct 3 05:50:54 2004 From: schwab at suse.de (Andreas Schwab) Date: Sat, 02 Oct 2004 21:50:54 +0200 Subject: Machine check during PCI scan on PMac G5 In-Reply-To: <1096715821.26913.35.camel@gaston> (Benjamin Herrenschmidt's message of "Sat, 02 Oct 2004 21:17:01 +1000") References: <1096715821.26913.35.camel@gaston> Message-ID: Benjamin Herrenschmidt writes: > Argh... again ! Looks like the box doesn't like us to probe the > PCI device that is there. Can you print out the precise devfn > bus number & offset where the machine check happens ? The first occurence is devfn 48, bus number 0, offset 14. > This patch should help by preventing the config space accesses to > occur on those devices that aren't in the device-tree, I'll push it > to Linus as a temporary fix if you confirm it works. Thanks, I can confirm that it works. Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux AG, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From benh at kernel.crashing.org Sun Oct 3 10:38:38 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sun, 03 Oct 2004 10:38:38 +1000 Subject: [PATCH] Fix booting on some recent G5s Message-ID: <1096763918.26914.63.camel@gaston> Hi ! Some recent G5s have a problem with PCI/HT probing. They crash (machine check) during the probe of some slot numbers, it seems to be related to some functions beeing disabled by the firmware inside the K2 ASIC. This patch limits the config space accesses to devices that are present in the OF device-tree. This fixes the problem and shouldn't "add" any limitation. If you plug a "random" PCI card with no OF driver, the firmware will still build a node for it with the default set of properties created from the config space. Ben. Signed-off-by: Benjamin Herrenschmidt --- 1.5/arch/ppc64/kernel/pmac_pci.c 2004-07-25 14:51:52 +10:00 +++ edited/arch/ppc64/kernel/pmac_pci.c 2004-08-04 10:26:07 +10:00 @@ -271,7 +271,7 @@ int offset, int len, u32 *val) { struct pci_controller *hose; - struct device_node *busdn; + struct device_node *busdn, *dn; unsigned long addr; if (bus->self) @@ -282,6 +282,16 @@ return PCIBIOS_DEVICE_NOT_FOUND; hose = busdn->phb; if (hose == NULL) + return PCIBIOS_DEVICE_NOT_FOUND; + + /* We only allow config cycles to devices that are in OF device-tree + * as we are apparently having some weird things going on with some + * revs of K2 on recent G5s + */ + for (dn = busdn->child; dn; dn = dn->sibling) + if (dn->devfn == devfn) + break; + if (dn == NULL) return PCIBIOS_DEVICE_NOT_FOUND; addr = u3_ht_cfg_access(hose, bus->number, devfn, offset); --- 1.21/arch/ppc/platforms/pmac_pci.c 2004-07-29 14:58:35 +10:00 +++ edited/arch/ppc/platforms/pmac_pci.c 2004-08-17 14:18:09 +10:00 @@ -315,6 +315,10 @@ unsigned int addr; int i; + struct device_node *np = pci_busdev_to_OF_node(bus, devfn); + if (np == NULL) + return PCIBIOS_DEVICE_NOT_FOUND; + /* * When a device in K2 is powered down, we die on config * cycle accesses. Fix that here. @@ -362,6 +366,9 @@ unsigned int addr; int i; + struct device_node *np = pci_busdev_to_OF_node(bus, devfn); + if (np == NULL) + return PCIBIOS_DEVICE_NOT_FOUND; /* * When a device in K2 is powered down, we die on config * cycle accesses. Fix that here. From benh at kernel.crashing.org Sun Oct 3 10:51:46 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sun, 03 Oct 2004 10:51:46 +1000 Subject: Machine check during PCI scan on PMac G5 In-Reply-To: <4231083A-14D4-11D9-AE7A-000A95A4DC02@kernel.crashing.org> References: <1096715821.26913.35.camel@gaston> <4231083A-14D4-11D9-AE7A-000A95A4DC02@kernel.crashing.org> Message-ID: <1096764706.11996.77.camel@gaston> On Sun, 2004-10-03 at 10:36, Segher Boessenkool wrote: > >> Argh... again ! Looks like the box doesn't like us to probe the > >> PCI device that is there. Can you print out the precise devfn > >> bus number & offset where the machine check happens ? > > > > The first occurence is devfn 48, bus number 0, offset 14. > > That's the "header type" field on the GEM shim. > > I'd rather not have this fixed by the device-tree check, for > various reasons; note that this issue probably is related to the > "config space not readable while GEM is in sleep mode" problem > on older Macs. Is the GEM powered on during boot, on these boxes? I'm suprised, I'm not sure it's actually GEM (Andreas, is the Sungem properly functionning on this box after this fix ?). I think the numbering of the Shims can change from firmware to firmware, it's more probably one of the USBs. There is code in pmac_feature.c to power up the GEM (but only if it has a device-node). I think the proper solution is the filter from the device-tree on Apple G5s, at least for now, though OF itself probably has a property somewhere that tells it which slots to probe and not to probe, I need to find it. Ben. From segher at kernel.crashing.org Sun Oct 3 10:36:26 2004 From: segher at kernel.crashing.org (Segher Boessenkool) Date: Sat, 2 Oct 2004 19:36:26 -0500 Subject: Machine check during PCI scan on PMac G5 In-Reply-To: References: <1096715821.26913.35.camel@gaston> Message-ID: <4231083A-14D4-11D9-AE7A-000A95A4DC02@kernel.crashing.org> >> Argh... again ! Looks like the box doesn't like us to probe the >> PCI device that is there. Can you print out the precise devfn >> bus number & offset where the machine check happens ? > > The first occurence is devfn 48, bus number 0, offset 14. That's the "header type" field on the GEM shim. I'd rather not have this fixed by the device-tree check, for various reasons; note that this issue probably is related to the "config space not readable while GEM is in sleep mode" problem on older Macs. Is the GEM powered on during boot, on these boxes? Segher From benh at kernel.crashing.org Sun Oct 3 13:44:44 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sun, 03 Oct 2004 13:44:44 +1000 Subject: Machine check during PCI scan on PMac G5 In-Reply-To: <1096764706.11996.77.camel@gaston> References: <1096715821.26913.35.camel@gaston> <4231083A-14D4-11D9-AE7A-000A95A4DC02@kernel.crashing.org> <1096764706.11996.77.camel@gaston> Message-ID: <1096775084.9539.4.camel@gaston> > I'm suprised, I'm not sure it's actually GEM (Andreas, is the Sungem > properly functionning on this box after this fix ?). I think the > numbering of the Shims can change from firmware to firmware, it's > more probably one of the USBs. There is code in pmac_feature.c to > power up the GEM (but only if it has a device-node). Ok, after digging in the OF code, it seems that on machines without a PCI-X bridge, shim 6 is just not used and the stuff is really upset when we probe it. K2 is a weird beast that needs care... Ben. From schwab at suse.de Sun Oct 3 21:52:54 2004 From: schwab at suse.de (Andreas Schwab) Date: Sun, 03 Oct 2004 13:52:54 +0200 Subject: Machine check during PCI scan on PMac G5 In-Reply-To: <1096764706.11996.77.camel@gaston> (Benjamin Herrenschmidt's message of "Sun, 03 Oct 2004 10:51:46 +1000") References: <1096715821.26913.35.camel@gaston> <4231083A-14D4-11D9-AE7A-000A95A4DC02@kernel.crashing.org> <1096764706.11996.77.camel@gaston> Message-ID: Benjamin Herrenschmidt writes: > I'm suprised, I'm not sure it's actually GEM (Andreas, is the Sungem > properly functionning on this box after this fix ?). It appears to be. Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux AG, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From schwab at suse.de Sun Oct 3 21:59:47 2004 From: schwab at suse.de (Andreas Schwab) Date: Sun, 03 Oct 2004 13:59:47 +0200 Subject: PM72 works also on PowerMac7,3 Message-ID: The therm_pm72 driver appears to work fine on the PowerMac7,3. Andreas. Signed-off-by: Andreas Schwab --- linux-2.6/drivers/macintosh/therm_pm72.c.~1~ 2004-08-19 11:31:30.000000000 +0200 +++ linux-2.6/drivers/macintosh/therm_pm72.c 2004-10-03 13:55:22.361631501 +0200 @@ -1301,7 +1301,8 @@ static int __init therm_pm72_init(void) { struct device_node *np; - if (!machine_is_compatible("PowerMac7,2")) + if (!machine_is_compatible("PowerMac7,2") && + !machine_is_compatible("PowerMac7,3")) return -ENODEV; printk(KERN_INFO "PowerMac G5 Thermal control driver %s\n", VERSION); -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux AG, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From benh at kernel.crashing.org Sun Oct 3 22:06:45 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sun, 03 Oct 2004 22:06:45 +1000 Subject: PM72 works also on PowerMac7,3 In-Reply-To: References: Message-ID: <1096805205.9514.17.camel@gaston> On Sun, 2004-10-03 at 21:59, Andreas Schwab wrote: > The therm_pm72 driver appears to work fine on the PowerMac7,3. Before commiting this, I'd rather make sure the code & fan IDs is actually the same in Darwin, also, just allowing the 7,3 may enable the code on the new water cooling machines. Before doing so, I'd rather make sure we get that right too. I'm waiting for one of these to be delivered by Apple, they seem to take ages, but hopefully, it should be there soon. Ben. From schwab at suse.de Sun Oct 3 22:20:43 2004 From: schwab at suse.de (Andreas Schwab) Date: Sun, 03 Oct 2004 14:20:43 +0200 Subject: Properly recognize PowerMac7,3 Message-ID: Make the PowerMac7,3 no longer unknown. Andreas. Signed-off-by: Andreas Schwab --- linux-2.6/arch/ppc64/kernel/pmac_feature.c.~1~ 2004-09-28 00:28:34.000000000 +0200 +++ linux-2.6/arch/ppc64/kernel/pmac_feature.c 2004-10-03 14:17:03.458461540 +0200 @@ -343,6 +343,10 @@ static struct pmac_mb_def pmac_mb_defs[] PMAC_TYPE_POWERMAC_G5, g5_features, 0, }, + { "PowerMac7,3", "PowerMac G5", + PMAC_TYPE_POWERMAC_G5, g5_features, + 0, + }, { "RackMac3,1", "XServe G5", PMAC_TYPE_POWERMAC_G5, g5_features, 0, -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux AG, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From grave at ipno.in2p3.fr Mon Oct 4 17:59:44 2004 From: grave at ipno.in2p3.fr (grave) Date: Mon, 04 Oct 2004 07:59:44 +0000 Subject: =?iso-8859-1?q?Re=A0=3A?= XServe Node running a debian with only one processor In-Reply-To: <415D85D1.4040701@austin.ibm.com> (from olof@austin.ibm.com on Fri Oct 1 18:29:05 2004) References: <1096546729l.32147l.0l@ipnnarval> <1096548321l.32616l.0l@ipnnarval> <1096646654l.2901l.2l@ipnnarval> <415D85D1.4040701@austin.ibm.com> Message-ID: <1096876784l.19627l.4l@ipnnarval> Here are a few informations : console output in the joined file I use a cross compiler ppc32 -> ppc64 gcc-3.4.1 GNU ld version 2.15 kernel from ftp.kernel.org 2.6.6 patch (had to apply it reversed because of the initial diff I think) : diff -ur linux-2.6.6-working/arch/ppc64/kernel/pmac_feature.c linux-2.6.6/arch/ppc64/kernel/pmac_feature.c --- linux-2.6.6-working/arch/ppc64/kernel/pmac_feature.c 2004-05-13 17:00:12.000000000 -0600 +++ linux-2.6.6/arch/ppc64/kernel/pmac_feature.c 2004-05-09 20:32:54.000000000 -0600 @@ -343,10 +343,6 @@ PMAC_TYPE_POWERMAC_G5, g5_features, 0, }, - { "RackMac3,1", "XServe G5", - PMAC_TYPE_POWERMAC_G5, g5_features, - 0, - }, }; /* diff -ur linux-2.6.6-working/arch/ppc64/kernel/setup.c linux-2.6.6/ arch/ppc64/kernel/setup.c --- linux-2.6.6-working/arch/ppc64/kernel/setup.c 2004-05-13 16:06:33.000000000 -0600 +++ linux-2.6.6/arch/ppc64/kernel/setup.c 2004-05-09 20:32:29.000000000 -0600 @@ -547,7 +547,7 @@ int __init ppc_init(void) { /* clear the progress line */ - if(ppc_md.progress) ppc_md.progress(" ", 0xffff); + ppc_md.progress(" ", 0xffff); if (ppc_md.init != NULL) { ppc_md.init(); -------------- next part -------------- Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Mount-cache hash table entries: 256 (order: 0, 4096 bytes) POSIX conformance testing by UNIFIX PowerMac SMP probe found 2 cpus Processor 1 found. Synchronizing timebase Got ack score 299, offset 1000 score 299, offset 500 score -299, offset 250 score 299, offset 375 score -299, offset 312 score -299, offset 343 score -299, offset 359 score -299, offset 367 score -283, offset 371 score -247, offset 373 score 133, offset 374 score -239, offset 373 Min 373 (score -237), Max 374 (score 129) Final offset: 374 (127/300) Brought up 2 CPUs a few seconds and : [c0000000000172f4] .kernel_thread+0x4c/0x68 <0>Kernel panic: Attempted to k00025ef1c0[1] 'swapper' THREAD: c0000000025e8000 CPU: 0 GPR00: C000000000077E90 C0000000025EBAE0 C00000000045EA58 FFFFFFFFFFFFFFFF GPR04: 0000000000000DE7 FFFFFFFFFFFFFFFF C000000000397200 C000000000397218 GPR08: 0000000000000000 C000000000359180 0000000000000001 C0000000004AE730 GPR12: 0000000088004044 C000000000308000 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000001000 GPR20: C0000000004B16E0 000000000000007F 0000000000000008 000000000000001B GPR24: C00000007DFCDD80 C0000000025EBBE0 0000000000000036 0000000000000080 GPR28: C0000000025EBBE0 C0000000004364F0 C0000000003A5628 0000000000000000 NIP [c000000000077e9c] .smp_call_function_all_cpus+0x7c/0x98 LR [c000000000077e90] .smp_call_function_all_cpus+0x70/0x98 Call Trace: [c000000000079c28] .do_tune_cpucache+0xb4/0x3fc [c00000000007a050] .enable_cpucache+0xe0/0x118 [c00000000007a7b0] .kmem_cache_create+0x728/0x79c [c0000000002f5448] .sk_init+0x30/0xdc [c0000000002f539c] .sock_init+0x3c/0xb8 [c00000000000c6ec] .init+0x238/0x43c [c0000000000172f4] .kernel_thread+0x4c/0x68 <0>Kernel panic: Attempted to kill init! smp_call_function on cpu 0: other cpus not responding (0) Rebooting in 180 seconds.. From grave at ipno.in2p3.fr Mon Oct 4 18:48:26 2004 From: grave at ipno.in2p3.fr (grave) Date: Mon, 04 Oct 2004 08:48:26 +0000 Subject: discovered the patch pages and how it work on penguinppc64.org sorry for the previous mail... Message-ID: <1096879706l.20867l.0l@ipnnarval> http://ozlabs.org/ppc64-patches/patch.pl?id=62 make the all things going right ! One more time sorry... From benh at kernel.crashing.org Mon Oct 4 18:55:29 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 04 Oct 2004 18:55:29 +1000 Subject: discovered the patch pages and how it work on penguinppc64.org sorry for the previous mail... In-Reply-To: <1096879706l.20867l.0l@ipnnarval> References: <1096879706l.20867l.0l@ipnnarval> Message-ID: <1096880129.9514.70.camel@gaston> On Mon, 2004-10-04 at 18:48, grave wrote: > http://ozlabs.org/ppc64-patches/patch.pl?id=62 make the all things > going right ! > > One more time sorry... Hrm, that should be in Linus tree already... Ben. From grave at ipno.in2p3.fr Mon Oct 4 22:31:21 2004 From: grave at ipno.in2p3.fr (grave) Date: Mon, 04 Oct 2004 12:31:21 +0000 Subject: =?iso-8859-1?q?Re=A0=3A?= discovered the patch pages and how it work on penguinppc64.org sorry for the previous mail... In-Reply-To: <1096880129.9514.70.camel@gaston> (from benh@kernel.crashing.org on Mon Oct 4 10:55:29 2004) References: <1096879706l.20867l.0l@ipnnarval> <1096880129.9514.70.camel@gaston> Message-ID: <1096893081l.23876l.0l@ipnnarval> On 04.10.2004 10:55:29, Benjamin Herrenschmidt wrote: > On Mon, 2004-10-04 at 18:48, grave wrote: > > http://ozlabs.org/ppc64-patches/patch.pl?id=62 make the all things > > going right ! > > > > One more time sorry... > > Hrm, that should be in Linus tree already... Not in the 2.6.6 tree from www.kernel.org It's present in 2.6.8.1 but this one crash at boot (see attached file). This kernel also crash if I use the nosmp option xavier -------------- next part -------------- Min 8 (score -13), Max 9 (score 51) Final offset: 8 (9/300) Brought up 2 CPUs NET: Registered protocol family 16 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=2 POWERMAC NIP: C0000000002DA15C XER: 0000000000000000 LR: C00000000000C600 REGS: c0000000027e7be0 TRAP: 0300 Not tainted (2.6.8.1) MSR: 9000000000009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: 0000000000000000, DSISR: 0000000008000000 TASK: c0000000027e1200[1] 'swapper' THREAD: c0000000027e4000 CPU: 0 GPR00: C00000000000C600 C0000000027E7E60 C000000000437E78 C0000000002AEC28 GPR04: 000000000000FFFF 0000000000000000 C000000000493C48 C00000007DE5BD78 GPR08: 0000000000000002 0000000000000000 0000000000000002 0000000000000000 GPR12: 0000000028000042 C000000000304000 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000220000 0000000000230000 0000000001400000 GPR24: C000000000304000 C000000000435008 C0000000002F4348 C0000000002F8268 GPR28: 0000000000000000 C000000000436420 C000000000364260 C0000000002F7F30 NIP [c0000000002da15c] .ppc_init+0x30/0xa4 LR [c00000000000c600] .init+0x234/0x428 Call Trace: [c0000000027e7e60] [c0000000027e7ef0] 0xc0000000027e7ef0 (unreliable) [c0000000027e7ef0] [c00000000000c600] .init+0x234/0x428 [c0000000027e7f90] [c000000000017734] .kernel_thread+0x4c/0x68 <0>Kernel panic: Attempted to kill init! <0>Rebooting in 180 seconds.. From benh at kernel.crashing.org Mon Oct 4 23:32:23 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 04 Oct 2004 23:32:23 +1000 Subject: =?iso-8859-1?q?Re=3A_Re=C2=A0=3A_discovered_the_patch_pages_and_?= =?iso-8859-1?q?how_it_work_on=0D=0A=09penguinppc64=2Eorg_sorry_for_th?= =?iso-8859-1?q?e_previous_mail=2E=2E=2E?= In-Reply-To: <1096893081l.23876l.0l@ipnnarval> References: <1096879706l.20867l.0l@ipnnarval> <1096880129.9514.70.camel@gaston> <1096893081l.23876l.0l@ipnnarval> Message-ID: <1096896743.9516.84.camel@gaston> On Mon, 2004-10-04 at 22:31, grave wrote: > On 04.10.2004 10:55:29, Benjamin Herrenschmidt wrote: > > On Mon, 2004-10-04 at 18:48, grave wrote: > > > http://ozlabs.org/ppc64-patches/patch.pl?id=62 make the all things > > > going right ! > > > > > > One more time sorry... > > > > Hrm, that should be in Linus tree already... > Not in the 2.6.6 tree from www.kernel.org > > It's present in 2.6.8.1 but this one crash at boot (see attached file). > This kernel also crash if I use the nosmp option Can you try 2.6.9-rc3 and let me know ? Or beter, the current bk snapshot of 2.6.9 Ben. From grave at ipno.in2p3.fr Mon Oct 4 23:48:28 2004 From: grave at ipno.in2p3.fr (grave) Date: Mon, 04 Oct 2004 13:48:28 +0000 Subject: =?iso-8859-1?q?Re=A0=3A_Re=A0=3A?= discovered the patch pages and how it work on penguinppc64.org sorry for the previous mail... In-Reply-To: <1096896743.9516.84.camel@gaston> (from benh@kernel.crashing.org on Mon Oct 4 15:32:23 2004) References: <1096879706l.20867l.0l@ipnnarval> <1096880129.9514.70.camel@gaston> <1096893081l.23876l.0l@ipnnarval> <1096896743.9516.84.camel@gaston> Message-ID: <1096897708l.24855l.1l@ipnnarval> > Can you try 2.6.9-rc3 and let me know ? Or beter, the current bk > snapshot of 2.6.9 I also tryed with the bk tree (2.6.9-rc1-ames) it also crashed... I'll retry in order to send you a log of the crash... Where can I get the 2.6.9-rc3 tree ? I didn't find where it is ? I'm trying to have something "better" than 2.6.6 in order to have termal management. xavier From benh at kernel.crashing.org Mon Oct 4 23:45:50 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 04 Oct 2004 23:45:50 +1000 Subject: =?iso-8859-1?q?Re=3A_Re=C2=A0=3A_Re=C2=A0=3A_discovered_the_patc?= =?iso-8859-1?q?h_pages_and_how_it_work_on=0D=0A=09penguinppc64=2Eorg_?= =?iso-8859-1?q?sorry_for_the_previous_mail=2E=2E=2E?= In-Reply-To: <1096897708l.24855l.1l@ipnnarval> References: <1096879706l.20867l.0l@ipnnarval> <1096880129.9514.70.camel@gaston> <1096893081l.23876l.0l@ipnnarval> <1096896743.9516.84.camel@gaston> <1096897708l.24855l.1l@ipnnarval> Message-ID: <1096897549.23141.93.camel@gaston> On Mon, 2004-10-04 at 23:48, grave wrote: > > Can you try 2.6.9-rc3 and let me know ? Or beter, the current bk > > snapshot of 2.6.9 > > I also tryed with the bk tree (2.6.9-rc1-ames) it also crashed... > I'll retry in order to send you a log of the crash... ames ? just use mainstream > Where can I get the 2.6.9-rc3 tree ? I didn't find where it is ? kernel.org ? > I'm trying to have something "better" than 2.6.6 in order to have > termal management. > > xavier -- Benjamin Herrenschmidt From benh at kernel.crashing.org Mon Oct 4 23:46:54 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 04 Oct 2004 23:46:54 +1000 Subject: =?iso-8859-1?q?Re=C2?= =?iso-8859-1?q?=C2=A0=3A?= =?iso-8859-1?q?Re=C2?= =?iso-8859-1?q?=C2=A0=3A_discovered?= the patch pages and how it work on penguinppc64.org sorry for the previous mail... In-Reply-To: <1096897549.23141.93.camel@gaston> References: <1096879706l.20867l.0l@ipnnarval> <1096880129.9514.70.camel@gaston> <1096893081l.23876l.0l@ipnnarval> <1096896743.9516.84.camel@gaston> <1096897708l.24855l.1l@ipnnarval> <1096897549.23141.93.camel@gaston> Message-ID: <1096897613.9539.95.camel@gaston> On Mon, 2004-10-04 at 23:45, Benjamin Herrenschmidt wrote: > > I'm trying to have something "better" than 2.6.6 in order to have > > termal management. BTW. Thermal control isn't there yet for xserve's ... soon hopefully Ben. From moilanen at austin.ibm.com Tue Oct 5 05:43:05 2004 From: moilanen at austin.ibm.com (moilanen at austin.ibm.com) Date: Mon, 4 Oct 2004 14:43:05 -0500 Subject: [PATCH 1/1] rtas_flash_4gig Message-ID: <200410041942.i94Jg4WA154540@westrelay04.boulder.ibm.com> We should probably check to make sure that all of the flash list headers are above 4gig. Not just the first one. We could see this situation happen if we are low on memory and get a paged alloc'd that's over the 4 gig boundary. Jake Signed-off-by: Jake Moilanen --- diff -puN arch/ppc64/kernel/rtas.c~rtas_flash_4gig arch/ppc64/kernel/rtas.c --- linux-2.6-bk/arch/ppc64/kernel/rtas.c~rtas_flash_4gig Mon Oct 4 10:46:46 2004 +++ linux-2.6-bk-moilanen/arch/ppc64/kernel/rtas.c Mon Oct 4 14:22:31 2004 @@ -338,6 +338,12 @@ rtas_flash_firmware(void) f->next = (struct flash_block_list *)virt_to_abs(f->next); else f->next = NULL; + + if (f->next >= 4UL*1024*1024*1024) { + printk(KERN_ALERT "FLASH: aborted...flash list header addr above 4GB\n"); + return; + } + /* make num_blocks into the version/length field */ f->num_blocks = (FLASH_BLOCK_LIST_VERSION << 56) | ((f->num_blocks+1)*16); } _ From schwab at suse.de Tue Oct 5 06:51:55 2004 From: schwab at suse.de (Andreas Schwab) Date: Mon, 04 Oct 2004 22:51:55 +0200 Subject: Sound on G5 Message-ID: Is anyone already working on sound support for the PowerMac G5, by chance? That's actually the only thing still missing. Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux AG, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From benh at kernel.crashing.org Tue Oct 5 11:25:03 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Tue, 05 Oct 2004 11:25:03 +1000 Subject: Sound on G5 In-Reply-To: References: Message-ID: <1096939502.24584.6.camel@gaston> On Tue, 2004-10-05 at 06:51, Andreas Schwab wrote: > Is anyone already working on sound support for the PowerMac G5, by chance? > That's actually the only thing still missing. Nobody really seriously ATM. One of the main issue is that the darwin driver abuses apple "do-platform-*" shit. It's a mecanism they invented to put sort-of "scripts" (in binary form) in the device-tree that can contains elementary ops such as write GPIOs, I2C, etc... This is extremely messy and difficult to parse. I have written the basis for parsing them, but interpreting them is even more shitty as the actual implementation of each ops sort-of depends on the target object. It's really a piece-of-shit imho. So we could go that way and complete my "interpreter" or just hard code all of the GPIOs we need in the driver hoping apple don't shuffle them too much in upcoming models... Ben. From david at gibson.dropbear.id.au Tue Oct 5 13:13:41 2004 From: david at gibson.dropbear.id.au (David Gibson) Date: Tue, 5 Oct 2004 13:13:41 +1000 Subject: [PPC64] Squash EEH warnings Message-ID: <20041005031341.GA3695@zax> Andrew, please apply: A slightly non-ideal version of the recent patch which fixed EEH being a no-op went in. The srcsave variable in eeh_memcpy_to_io() is now never referenced on non-pSeries machines, and so spews hundreds of warnings. The variable doesn't actually accomplish anything, so this patch gets rid of it. Signed-off-by: David Gibson Index: working-2.6/include/asm-ppc64/eeh.h =================================================================== --- working-2.6.orig/include/asm-ppc64/eeh.h 2004-10-05 10:08:10.000000000 +1000 +++ working-2.6/include/asm-ppc64/eeh.h 2004-10-05 13:09:24.730992368 +1000 @@ -196,7 +196,6 @@ static inline void eeh_memcpy_fromio(void *dest, const volatile void __iomem *src, unsigned long n) { void *vsrc = (void __force *) src; void *destsave = dest; - const volatile void __iomem *srcsave = src; unsigned long nsave = n; while(n && (!EEH_CHECK_ALIGN(vsrc, 4) || !EEH_CHECK_ALIGN(dest, 4))) { @@ -227,7 +226,7 @@ */ if ((nsave >= 4) && (EEH_POSSIBLE_ERROR((*((u32 *) destsave+nsave-4)), u32))) { - eeh_check_failure(srcsave, (*((u32 *) destsave+nsave-4))); + eeh_check_failure(src, (*((u32 *) destsave+nsave-4))); } } -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson From david at gibson.dropbear.id.au Tue Oct 5 15:26:27 2004 From: david at gibson.dropbear.id.au (David Gibson) Date: Tue, 5 Oct 2004 15:26:27 +1000 Subject: [TRIVIAL, PPC64] Remove redundant #ifdef CONFIG_ALTIVEC Message-ID: <20041005052627.GD3695@zax> Andrew, please apply: arch/ppc64/kernel/process.c has an #ifdef CONFIG_ALTIVEC within an #ifdef CONFIG_ALTIVEC. This patch removes the inner one. Signed-off-by: David Gibson Index: working-2.6/arch/ppc64/kernel/process.c =================================================================== --- working-2.6.orig/arch/ppc64/kernel/process.c 2004-10-05 10:08:10.000000000 +1000 +++ working-2.6/arch/ppc64/kernel/process.c 2004-10-05 15:18:56.581996496 +1000 @@ -147,7 +147,6 @@ */ void flush_altivec_to_thread(struct task_struct *tsk) { -#ifdef CONFIG_ALTIVEC if (tsk->thread.regs) { preempt_disable(); if (tsk->thread.regs->msr & MSR_VEC) { @@ -158,7 +157,6 @@ } preempt_enable(); } -#endif } int dump_task_altivec(struct pt_regs *regs, elf_vrregset_t *vrregs) -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson From david at gibson.dropbear.id.au Tue Oct 5 16:42:56 2004 From: david at gibson.dropbear.id.au (David Gibson) Date: Tue, 5 Oct 2004 16:42:56 +1000 Subject: [PPC64] xmon sparse cleanups Message-ID: <20041005064255.GF3695@zax> Andrew, please apply: This patch removes many sparse warnings from the xmon code. Mostly K&R function declarations and 0-instead-of-NULLs. I believe this removes all save one sparse error in xmon, excepting those inherited from header files. Signed-off-by: David Gibson Index: working-2.6/arch/ppc64/xmon/xmon.c =================================================================== --- working-2.6.orig/arch/ppc64/xmon/xmon.c 2004-09-24 10:14:09.000000000 +1000 +++ working-2.6/arch/ppc64/xmon/xmon.c 2004-10-05 16:31:01.822963256 +1000 @@ -645,7 +645,7 @@ for (i = 0; i < NBPTS; ++i, ++bp) if (bp->enabled && pc == bp->address) return bp; - return 0; + return NULL; } static struct bpt *in_breakpoint_table(unsigned long nip, unsigned long *offp) @@ -1582,7 +1582,7 @@ extern char dec_exc; void -super_regs() +super_regs(void) { int cmd; unsigned long val; @@ -1816,7 +1816,7 @@ ""; void -memex() +memex(void) { int cmd, inc, i, nslash; unsigned long n; @@ -1967,7 +1967,7 @@ } int -bsesc() +bsesc(void) { int c; @@ -1985,7 +1985,7 @@ || ('a' <= (c) && (c) <= 'f') \ || ('A' <= (c) && (c) <= 'F')) void -dump() +dump(void) { int c; @@ -2150,7 +2150,7 @@ static unsigned mask; void -memlocate() +memlocate(void) { unsigned a, n; unsigned char val[4]; @@ -2183,7 +2183,7 @@ static unsigned long mlim = 0xffffffff; void -memzcan() +memzcan(void) { unsigned char v; unsigned a; @@ -2212,7 +2212,7 @@ /* Input scanning routines */ int -skipbl() +skipbl(void) { int c; @@ -2237,8 +2237,7 @@ }; int -scanhex(vp) -unsigned long *vp; +scanhex(unsigned long *vp) { int c, d; unsigned long v; @@ -2322,7 +2321,7 @@ } void -scannl() +scannl(void) { int c; @@ -2365,13 +2364,13 @@ static char *lineptr; void -flush_input() +flush_input(void) { lineptr = NULL; } int -inchar() +inchar(void) { if (lineptr == NULL || *lineptr == 0) { if (fgets(line, sizeof(line), stdin) == NULL) { @@ -2384,8 +2383,7 @@ } void -take_input(str) -char *str; +take_input(char *str) { lineptr = str; } Index: working-2.6/arch/ppc64/xmon/ppc-opc.c =================================================================== --- working-2.6.orig/arch/ppc64/xmon/ppc-opc.c 2004-08-09 09:51:38.000000000 +1000 +++ working-2.6/arch/ppc64/xmon/ppc-opc.c 2004-10-05 16:41:20.355047248 +1000 @@ -20,6 +20,7 @@ Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ +#include #include "nonstdio.h" #include "ppc.h" @@ -110,12 +111,12 @@ /* The zero index is used to indicate the end of the list of operands. */ #define UNUSED 0 - { 0, 0, 0, 0, 0 }, + { 0, 0, NULL, NULL, 0 }, /* The BA field in an XL form instruction. */ #define BA UNUSED + 1 #define BA_MASK (0x1f << 16) - { 5, 16, 0, 0, PPC_OPERAND_CR }, + { 5, 16, NULL, NULL, PPC_OPERAND_CR }, /* The BA field in an XL form instruction when it must be the same as the BT field in the same instruction. */ @@ -125,7 +126,7 @@ /* The BB field in an XL form instruction. */ #define BB BAT + 1 #define BB_MASK (0x1f << 11) - { 5, 11, 0, 0, PPC_OPERAND_CR }, + { 5, 11, NULL, NULL, PPC_OPERAND_CR }, /* The BB field in an XL form instruction when it must be the same as the BA field in the same instruction. */ @@ -168,21 +169,21 @@ /* The BF field in an X or XL form instruction. */ #define BF BDPA + 1 - { 3, 23, 0, 0, PPC_OPERAND_CR }, + { 3, 23, NULL, NULL, PPC_OPERAND_CR }, /* An optional BF field. This is used for comparison instructions, in which an omitted BF field is taken as zero. */ #define OBF BF + 1 - { 3, 23, 0, 0, PPC_OPERAND_CR | PPC_OPERAND_OPTIONAL }, + { 3, 23, NULL, NULL, PPC_OPERAND_CR | PPC_OPERAND_OPTIONAL }, /* The BFA field in an X or XL form instruction. */ #define BFA OBF + 1 - { 3, 18, 0, 0, PPC_OPERAND_CR }, + { 3, 18, NULL, NULL, PPC_OPERAND_CR }, /* The BI field in a B form or XL form instruction. */ #define BI BFA + 1 #define BI_MASK (0x1f << 16) - { 5, 16, 0, 0, PPC_OPERAND_CR }, + { 5, 16, NULL, NULL, PPC_OPERAND_CR }, /* The BO field in a B form instruction. Certain values are illegal. */ @@ -197,36 +198,36 @@ /* The BT field in an X or XL form instruction. */ #define BT BOE + 1 - { 5, 21, 0, 0, PPC_OPERAND_CR }, + { 5, 21, NULL, NULL, PPC_OPERAND_CR }, /* The condition register number portion of the BI field in a B form or XL form instruction. This is used for the extended conditional branch mnemonics, which set the lower two bits of the BI field. This field is optional. */ #define CR BT + 1 - { 3, 18, 0, 0, PPC_OPERAND_CR | PPC_OPERAND_OPTIONAL }, + { 3, 18, NULL, NULL, PPC_OPERAND_CR | PPC_OPERAND_OPTIONAL }, /* The CRB field in an X form instruction. */ #define CRB CR + 1 - { 5, 6, 0, 0, 0 }, + { 5, 6, NULL, NULL, 0 }, /* The CRFD field in an X form instruction. */ #define CRFD CRB + 1 - { 3, 23, 0, 0, PPC_OPERAND_CR }, + { 3, 23, NULL, NULL, PPC_OPERAND_CR }, /* The CRFS field in an X form instruction. */ #define CRFS CRFD + 1 - { 3, 0, 0, 0, PPC_OPERAND_CR }, + { 3, 0, NULL, NULL, PPC_OPERAND_CR }, /* The CT field in an X form instruction. */ #define CT CRFS + 1 - { 5, 21, 0, 0, PPC_OPERAND_OPTIONAL }, + { 5, 21, NULL, NULL, PPC_OPERAND_OPTIONAL }, /* The D field in a D form instruction. This is a displacement off a register, and implies that the next operand is a register in parentheses. */ #define D CT + 1 - { 16, 0, 0, 0, PPC_OPERAND_PARENS | PPC_OPERAND_SIGNED }, + { 16, 0, NULL, NULL, PPC_OPERAND_PARENS | PPC_OPERAND_SIGNED }, /* The DE field in a DE form instruction. This is like D, but is 12 bits only. */ @@ -252,40 +253,40 @@ /* The E field in a wrteei instruction. */ #define E DS + 1 - { 1, 15, 0, 0, 0 }, + { 1, 15, NULL, NULL, 0 }, /* The FL1 field in a POWER SC form instruction. */ #define FL1 E + 1 - { 4, 12, 0, 0, 0 }, + { 4, 12, NULL, NULL, 0 }, /* The FL2 field in a POWER SC form instruction. */ #define FL2 FL1 + 1 - { 3, 2, 0, 0, 0 }, + { 3, 2, NULL, NULL, 0 }, /* The FLM field in an XFL form instruction. */ #define FLM FL2 + 1 - { 8, 17, 0, 0, 0 }, + { 8, 17, NULL, NULL, 0 }, /* The FRA field in an X or A form instruction. */ #define FRA FLM + 1 #define FRA_MASK (0x1f << 16) - { 5, 16, 0, 0, PPC_OPERAND_FPR }, + { 5, 16, NULL, NULL, PPC_OPERAND_FPR }, /* The FRB field in an X or A form instruction. */ #define FRB FRA + 1 #define FRB_MASK (0x1f << 11) - { 5, 11, 0, 0, PPC_OPERAND_FPR }, + { 5, 11, NULL, NULL, PPC_OPERAND_FPR }, /* The FRC field in an A form instruction. */ #define FRC FRB + 1 #define FRC_MASK (0x1f << 6) - { 5, 6, 0, 0, PPC_OPERAND_FPR }, + { 5, 6, NULL, NULL, PPC_OPERAND_FPR }, /* The FRS field in an X form instruction or the FRT field in a D, X or A form instruction. */ #define FRS FRC + 1 #define FRT FRS - { 5, 21, 0, 0, PPC_OPERAND_FPR }, + { 5, 21, NULL, NULL, PPC_OPERAND_FPR }, /* The FXM field in an XFX instruction. */ #define FXM FRS + 1 @@ -298,11 +299,11 @@ /* The L field in a D or X form instruction. */ #define L FXM4 + 1 - { 1, 21, 0, 0, PPC_OPERAND_OPTIONAL }, + { 1, 21, NULL, NULL, PPC_OPERAND_OPTIONAL }, /* The LEV field in a POWER SC form instruction. */ #define LEV L + 1 - { 7, 5, 0, 0, 0 }, + { 7, 5, NULL, NULL, 0 }, /* The LI field in an I form instruction. The lower two bits are forced to zero. */ @@ -316,24 +317,24 @@ /* The LS field in an X (sync) form instruction. */ #define LS LIA + 1 - { 2, 21, 0, 0, PPC_OPERAND_OPTIONAL }, + { 2, 21, NULL, NULL, PPC_OPERAND_OPTIONAL }, /* The MB field in an M form instruction. */ #define MB LS + 1 #define MB_MASK (0x1f << 6) - { 5, 6, 0, 0, 0 }, + { 5, 6, NULL, NULL, 0 }, /* The ME field in an M form instruction. */ #define ME MB + 1 #define ME_MASK (0x1f << 1) - { 5, 1, 0, 0, 0 }, + { 5, 1, NULL, NULL, 0 }, /* The MB and ME fields in an M form instruction expressed a single operand which is a bitmask indicating which bits to select. This is a two operand form using PPC_OPERAND_NEXT. See the description in opcode/ppc.h for what this means. */ #define MBE ME + 1 - { 5, 6, 0, 0, PPC_OPERAND_OPTIONAL | PPC_OPERAND_NEXT }, + { 5, 6, NULL, NULL, PPC_OPERAND_OPTIONAL | PPC_OPERAND_NEXT }, { 32, 0, insert_mbe, extract_mbe, 0 }, /* The MB or ME field in an MD or MDS form instruction. The high @@ -345,7 +346,7 @@ /* The MO field in an mbar instruction. */ #define MO MB6 + 1 - { 5, 21, 0, 0, 0 }, + { 5, 21, NULL, NULL, 0 }, /* The NB field in an X form instruction. The value 32 is stored as 0. */ @@ -361,34 +362,34 @@ /* The RA field in an D, DS, DQ, X, XO, M, or MDS form instruction. */ #define RA NSI + 1 #define RA_MASK (0x1f << 16) - { 5, 16, 0, 0, PPC_OPERAND_GPR }, + { 5, 16, NULL, NULL, PPC_OPERAND_GPR }, /* The RA field in the DQ form lq instruction, which has special value restrictions. */ #define RAQ RA + 1 - { 5, 16, insert_raq, 0, PPC_OPERAND_GPR }, + { 5, 16, insert_raq, NULL, PPC_OPERAND_GPR }, /* The RA field in a D or X form instruction which is an updating load, which means that the RA field may not be zero and may not equal the RT field. */ #define RAL RAQ + 1 - { 5, 16, insert_ral, 0, PPC_OPERAND_GPR }, + { 5, 16, insert_ral, NULL, PPC_OPERAND_GPR }, /* The RA field in an lmw instruction, which has special value restrictions. */ #define RAM RAL + 1 - { 5, 16, insert_ram, 0, PPC_OPERAND_GPR }, + { 5, 16, insert_ram, NULL, PPC_OPERAND_GPR }, /* The RA field in a D or X form instruction which is an updating store or an updating floating point load, which means that the RA field may not be zero. */ #define RAS RAM + 1 - { 5, 16, insert_ras, 0, PPC_OPERAND_GPR }, + { 5, 16, insert_ras, NULL, PPC_OPERAND_GPR }, /* The RB field in an X, XO, M, or MDS form instruction. */ #define RB RAS + 1 #define RB_MASK (0x1f << 11) - { 5, 11, 0, 0, PPC_OPERAND_GPR }, + { 5, 11, NULL, NULL, PPC_OPERAND_GPR }, /* The RB field in an X form instruction when it must be the same as the RS field in the instruction. This is used for extended @@ -402,22 +403,22 @@ #define RS RBS + 1 #define RT RS #define RT_MASK (0x1f << 21) - { 5, 21, 0, 0, PPC_OPERAND_GPR }, + { 5, 21, NULL, NULL, PPC_OPERAND_GPR }, /* The RS field of the DS form stq instruction, which has special value restrictions. */ #define RSQ RS + 1 - { 5, 21, insert_rsq, 0, PPC_OPERAND_GPR }, + { 5, 21, insert_rsq, NULL, PPC_OPERAND_GPR }, /* The RT field of the DQ form lq instruction, which has special value restrictions. */ #define RTQ RSQ + 1 - { 5, 21, insert_rtq, 0, PPC_OPERAND_GPR }, + { 5, 21, insert_rtq, NULL, PPC_OPERAND_GPR }, /* The SH field in an X or M form instruction. */ #define SH RTQ + 1 #define SH_MASK (0x1f << 11) - { 5, 11, 0, 0, 0 }, + { 5, 11, NULL, NULL, 0 }, /* The SH field in an MD form instruction. This is split. */ #define SH6 SH + 1 @@ -426,12 +427,12 @@ /* The SI field in a D form instruction. */ #define SI SH6 + 1 - { 16, 0, 0, 0, PPC_OPERAND_SIGNED }, + { 16, 0, NULL, NULL, PPC_OPERAND_SIGNED }, /* The SI field in a D form instruction when we accept a wide range of positive values. */ #define SISIGNOPT SI + 1 - { 16, 0, 0, 0, PPC_OPERAND_SIGNED | PPC_OPERAND_SIGNOPT }, + { 16, 0, NULL, NULL, PPC_OPERAND_SIGNED | PPC_OPERAND_SIGNOPT }, /* The SPR field in an XFX form instruction. This is flipped--the lower 5 bits are stored in the upper 5 and vice- versa. */ @@ -443,25 +444,25 @@ /* The BAT index number in an XFX form m[ft]ibat[lu] instruction. */ #define SPRBAT SPR + 1 #define SPRBAT_MASK (0x3 << 17) - { 2, 17, 0, 0, 0 }, + { 2, 17, NULL, NULL, 0 }, /* The SPRG register number in an XFX form m[ft]sprg instruction. */ #define SPRG SPRBAT + 1 #define SPRG_MASK (0x3 << 16) - { 2, 16, 0, 0, 0 }, + { 2, 16, NULL, NULL, 0 }, /* The SR field in an X form instruction. */ #define SR SPRG + 1 - { 4, 16, 0, 0, 0 }, + { 4, 16, NULL, NULL, 0 }, /* The STRM field in an X AltiVec form instruction. */ #define STRM SR + 1 #define STRM_MASK (0x3 << 21) - { 2, 21, 0, 0, 0 }, + { 2, 21, NULL, NULL, 0 }, /* The SV field in a POWER SC form instruction. */ #define SV STRM + 1 - { 14, 2, 0, 0, 0 }, + { 14, 2, NULL, NULL, 0 }, /* The TBR field in an XFX form instruction. This is like the SPR field, but it is optional. */ @@ -471,52 +472,52 @@ /* The TO field in a D or X form instruction. */ #define TO TBR + 1 #define TO_MASK (0x1f << 21) - { 5, 21, 0, 0, 0 }, + { 5, 21, NULL, NULL, 0 }, /* The U field in an X form instruction. */ #define U TO + 1 - { 4, 12, 0, 0, 0 }, + { 4, 12, NULL, NULL, 0 }, /* The UI field in a D form instruction. */ #define UI U + 1 - { 16, 0, 0, 0, 0 }, + { 16, 0, NULL, NULL, 0 }, /* The VA field in a VA, VX or VXR form instruction. */ #define VA UI + 1 #define VA_MASK (0x1f << 16) - { 5, 16, 0, 0, PPC_OPERAND_VR }, + { 5, 16, NULL, NULL, PPC_OPERAND_VR }, /* The VB field in a VA, VX or VXR form instruction. */ #define VB VA + 1 #define VB_MASK (0x1f << 11) - { 5, 11, 0, 0, PPC_OPERAND_VR }, + { 5, 11, NULL, NULL, PPC_OPERAND_VR }, /* The VC field in a VA form instruction. */ #define VC VB + 1 #define VC_MASK (0x1f << 6) - { 5, 6, 0, 0, PPC_OPERAND_VR }, + { 5, 6, NULL, NULL, PPC_OPERAND_VR }, /* The VD or VS field in a VA, VX, VXR or X form instruction. */ #define VD VC + 1 #define VS VD #define VD_MASK (0x1f << 21) - { 5, 21, 0, 0, PPC_OPERAND_VR }, + { 5, 21, NULL, NULL, PPC_OPERAND_VR }, /* The SIMM field in a VX form instruction. */ #define SIMM VD + 1 - { 5, 16, 0, 0, PPC_OPERAND_SIGNED}, + { 5, 16, NULL, NULL, PPC_OPERAND_SIGNED}, /* The UIMM field in a VX form instruction. */ #define UIMM SIMM + 1 - { 5, 16, 0, 0, 0 }, + { 5, 16, NULL, NULL, 0 }, /* The SHB field in a VA form instruction. */ #define SHB UIMM + 1 - { 4, 6, 0, 0, 0 }, + { 4, 6, NULL, NULL, 0 }, /* The other UIMM field in a EVX form instruction. */ #define EVUIMM SHB + 1 - { 5, 11, 0, 0, 0 }, + { 5, 11, NULL, NULL, 0 }, /* The other UIMM field in a half word EVX form instruction. */ #define EVUIMM_2 EVUIMM + 1 @@ -533,11 +534,11 @@ /* The WS field. */ #define WS EVUIMM_8 + 1 #define WS_MASK (0x7 << 11) - { 3, 11, 0, 0, 0 }, + { 3, 11, NULL, NULL, 0 }, /* The L field in an mtmsrd instruction */ #define MTMSRD_L WS + 1 - { 1, 16, 0, 0, PPC_OPERAND_OPTIONAL }, + { 1, 16, NULL, NULL, PPC_OPERAND_OPTIONAL }, }; Index: working-2.6/arch/ppc64/xmon/start.c =================================================================== --- working-2.6.orig/arch/ppc64/xmon/start.c 2004-08-09 09:51:38.000000000 +1000 +++ working-2.6/arch/ppc64/xmon/start.c 2004-10-05 16:33:50.355028808 +1000 @@ -173,7 +173,7 @@ c = xmon_getchar(); if (c == -1) { if (p == str) - return 0; + return NULL; break; } *p++ = c; -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson From grave at ipno.in2p3.fr Tue Oct 5 18:41:04 2004 From: grave at ipno.in2p3.fr (grave) Date: Tue, 05 Oct 2004 08:41:04 +0000 Subject: xserve and 2.6.9-rc3 and 2.6.9-rc3-bk4 Message-ID: <1096965664l.7230l.0l@ipnnarval> Hi, I've tryed both kernel and got crashes (see attached files). Do I missed a patch ? xavier PS:2.6.6 + smp patch run fine -------------- next part -------------- PCI: Probing PCI hardware done SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub nvram_init: Could not find nvram partition for nvram buffered error logging. rtasd: no RTAS on system devfs: 2004-01-31 Richard Gooch (rgooch at atnf.csiro.au) devfs: boot_options: 0x0 Oops: Machine check, sig: 0 [#1] SMP NR_CPUS=2 POWERMAC NIP: C00000000014A640 XER: 0000000000000000 LR: C00000000014A614 REGS: c000000001a17a50 TRAP: 0200 Not tainted (2.6.9-rc3-bk4) MSR: 9000000000101032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK: c000000001a110c0[1] 'swapper' THREAD: c000000001a14000 CPU: 0 GPR00: FFFFFFFFFFFFFFFF C000000001A17CD0 C00000000043C390 00000000000000FF GPR04: C00000000FEFB400 0000000000000010 C0000000002AAAA0 C000000000468298 GPR08: C000000000468268 E0000000828CD000 C00000000045AD5C 9000000000009032 GPR12: 0000000028000042 C000000000355780 0000000000000000 0000000000000000 GPR16: 0000000001400000 00000000016FB720 00000000016FB720 BFFFFFFFFEC00000 GPR20: 000000000023FD58 0000000000000000 0000000001A6A020 00000000016FB998 GPR24: 9000000000009032 0000000000000032 C00000000043F730 C000000000352D58 GPR28: C00000000043F728 0000000000000000 C0000000003D5718 C00000000043F730 NIP [c00000000014a640] .i8042_flush+0x6c/0x15c LR [c00000000014a614] .i8042_flush+0x40/0x15c Call Trace: [c000000001a17cd0] [c000000000355780] 0xc000000000355780 (unreliable) [c000000001a17d80] [c00000000014b240] .i8042_controller_init+0x1c/0x1e4 [c000000001a17e10] [c0000000002f4164] .i8042_init+0xe8/0x64c [c000000001a17ef0] [c00000000000c688] .init+0x234/0x440 [c000000001a17f90] [c0000000000172b8] .kernel_thread+0x4c/0x6c <0>Kernel panic - not syncing: Attempted to kill init! <0>Rebooting in 180 seconds.. -------------- next part -------------- PCI: Probing PCI hardware done SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub nvram_init: Could not find nvram partition for nvram buffered error logging. rtasd: no RTAS on system devfs: 2004-01-31 Richard Gooch (rgooch at atnf.csiro.au) devfs: boot_options: 0x0 Oops: Machine check, sig: 0 [#1] SMP NR_CPUS=2 POWERMAC NIP: C00000000014A244 XER: 0000000000000000 LR: C00000000014A218 REGS: c000000001a17a50 TRAP: 0200 Not tainted (2.6.9-rc3) MSR: 9000000000101032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK: c000000001a110c0[1] 'swapper' THREAD: c000000001a14000 CPU: 0 GPR00: FFFFFFFFFFFFFFFF C000000001A17CD0 C0000000004383A8 00000000000000FF GPR04: C00000000FEED3C0 0000000000000010 C0000000002A7A48 C000000000464298 GPR08: C000000000464268 E0000000828CD000 C000000000456D64 9000000000009032 GPR12: 0000000028000042 C000000000351780 0000000000000000 0000000000000000 GPR16: 0000000001400000 00000000016F8720 00000000016F8720 BFFFFFFFFEC00000 GPR20: 000000000023FD58 0000000000000000 0000000001A66020 00000000016F8998 GPR24: 9000000000009032 0000000000000032 C00000000043B730 C00000000034ED58 GPR28: C00000000043B728 0000000000000000 C0000000003D1728 C00000000043B730 NIP [c00000000014a244] .i8042_flush+0x6c/0x15c LR [c00000000014a218] .i8042_flush+0x40/0x15c Call Trace: [c000000001a17cd0] [c000000000351780] 0xc000000000351780 (unreliable) [c000000001a17d80] [c00000000014ae44] .i8042_controller_init+0x1c/0x1e4 [c000000001a17e10] [c0000000002f1164] .i8042_init+0xe8/0x64c [c000000001a17ef0] [c00000000000c688] .init+0x234/0x440 [c000000001a17f90] [c0000000000172b8] .kernel_thread+0x4c/0x6c <0>Kernel panic - not syncing: Attempted to kill init! <0>Rebooting in 180 seconds.. From benh at kernel.crashing.org Tue Oct 5 18:46:43 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Tue, 05 Oct 2004 18:46:43 +1000 Subject: xserve and 2.6.9-rc3 and 2.6.9-rc3-bk4 In-Reply-To: <1096965664l.7230l.0l@ipnnarval> References: <1096965664l.7230l.0l@ipnnarval> Message-ID: <1096966003.24535.48.camel@gaston> On Tue, 2004-10-05 at 18:41, grave wrote: > Hi, > > I've tryed both kernel and got crashes (see attached files). > > Do I missed a patch ? > > xavier > PS:2.6.6 + smp patch run fine That's your .config You have enabled the legacy x86 keyboard support ! :) Use a g5_defconfig I'm working on a fix so that this driver stops crashing though. Ben. From grave at ipno.in2p3.fr Tue Oct 5 19:25:20 2004 From: grave at ipno.in2p3.fr (grave) Date: Tue, 05 Oct 2004 09:25:20 +0000 Subject: =?iso-8859-1?q?Re=A0=3A?= xserve and 2.6.9-rc3 and 2.6.9-rc3-bk4 In-Reply-To: <1096966003.24535.48.camel@gaston> (from benh@kernel.crashing.org on Tue Oct 5 10:46:43 2004) References: <1096965664l.7230l.0l@ipnnarval> <1096966003.24535.48.camel@gaston> Message-ID: <1096968320l.7230l.2l@ipnnarval> Le 05.10.2004 10:46:43, Benjamin Herrenschmidt a ?crit?: > On Tue, 2004-10-05 at 18:41, grave wrote: > > Hi, > > > > I've tryed both kernel and got crashes (see attached files). > > > > Do I missed a patch ? > > > > xavier > > PS:2.6.6 + smp patch run fine > > That's your .config > > You have enabled the legacy x86 keyboard support ! :) > > Use a g5_defconfig It works now... Thanks one more time ! From schwab at suse.de Tue Oct 5 19:50:44 2004 From: schwab at suse.de (Andreas Schwab) Date: Tue, 05 Oct 2004 11:50:44 +0200 Subject: Sound on G5 In-Reply-To: <1096939502.24584.6.camel@gaston> (Benjamin Herrenschmidt's message of "Tue, 05 Oct 2004 11:25:03 +1000") References: <1096939502.24584.6.camel@gaston> Message-ID: Benjamin Herrenschmidt writes: > So we could go that way and complete my "interpreter" or just hard code > all of the GPIOs we need in the driver hoping apple don't shuffle them > too much in upcoming models... I would be happy to test anything that is available. Thanks, Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux AG, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From paulus at samba.org Tue Oct 5 20:38:52 2004 From: paulus at samba.org (Paul Mackerras) Date: Tue, 5 Oct 2004 20:38:52 +1000 Subject: [PPC64] xmon sparse cleanups In-Reply-To: <20041005064255.GF3695@zax> References: <20041005064255.GF3695@zax> Message-ID: <16738.31164.464250.638432@cargo.ozlabs.ibm.com> David Gibson writes: > Andrew, please apply: > > This patch removes many sparse warnings from the xmon code. Mostly > K&R function declarations and 0-instead-of-NULLs. The trouble with this patch is that it makes ppc-opc.c diverge from the version in binutils, which is where it came from. I'd rather keep it as close as possible to that version. I have no problem with the changes to the other files. Paul. From igor at cs.wisc.edu Wed Oct 6 03:46:53 2004 From: igor at cs.wisc.edu (Igor Grobman) Date: Tue, 5 Oct 2004 12:46:53 -0500 (CDT) Subject: mapping memory in 0xb space In-Reply-To: <3337F539-14B0-11D9-AE7A-000A95A4DC02@kernel.crashing.org> References: <20040929014017.GC5470@zax> <20041001040325.GB12890@zax> <3337F539-14B0-11D9-AE7A-000A95A4DC02@kernel.crashing.org> Message-ID: On Sat, 2 Oct 2004, Segher Boessenkool wrote: > > A question for the rest of you, who haven't been following this thread. > > Is there publicly available documentation on the power4 extensions, > > specifically the large page support, how it effects the HPT hashing, > > and > > the SLB, including the new instructions for maintaining it in software? > > I haven't been able to find anything yet. > > http://www-106.ibm.com/developerworks/eserver/pdfs/archpub3.pdf > > has some info, don't know if that is enough for you -- nothing > much POWER4 specific in there, but large pages are part of the > architecture, so it does talk about the instructions to handle > them etc. Thanks, this is what I was looking for. -Igor From igor at cs.wisc.edu Wed Oct 6 03:45:47 2004 From: igor at cs.wisc.edu (Igor Grobman) Date: Tue, 5 Oct 2004 12:45:47 -0500 (CDT) Subject: mapping memory in 0xb space In-Reply-To: <20041001040325.GB12890@zax> References: <20040929014017.GC5470@zax> <20041001040325.GB12890@zax> Message-ID: One more followup on this issue, since I do have the base code working now. The problem was in the fact that do_slb_bolted code sets the large page bit in the SLB entry, but my code (and particularly hpte_insert code) did not insert a proper large page mapping. On Fri, 1 Oct 2004, David Gibson wrote: > On Wed, Sep 29, 2004 at 12:14:08AM -0500, Igor Grobman wrote: > > On Wed, 29 Sep 2004, David Gibson wrote: > > > > > On Tue, Sep 28, 2004 at 01:52:16PM -0500, Igor Grobman wrote: > > > > On Tue, 28 Sep 2004, David Gibson wrote: > > As for why I thought 0xbff would work, I reasoned that > > since the highest bits are masked out in get_kernel_vsid(), and since > > nobody else is using the 0xb region, it doesn't matter if I get a VSID > > that is the same as some other VSID in 0xb region. However, I did not > > consider the bug in do_slb_bolted that you describe below. > > Yes, with that bug the collision can be with a segment anywhere, not > just in the 0xb region. > I am not convinced anymore. The lower 36 bits of the ordinal are still the same in do_slb_bolted and get_kernel_vsid. Multiplying the ordinal by the 36-bit randomizer should produce the same lower 36 bits whether or not the upper bits are different. do_slb_bolted eventually clears the upper 28 bits, before using the VSID. I no longer think there can be a conflict outside the 0xb region. Is my reasoning correct? > > > You may have seen the comment in do_slb_bolted which claims to permit > > > a full 32-bits of ESID - it's wrong. The code doesn't mask the ESID > > > down to 13 bits as get_kernel_vsid() does, but it probably should - an > > > overlarge ESID will cause collisions with VSIDs from entirely > > > different address places, which would be a Bad Thing. > > > > This must be happening, although I would still like to know why it > > misbehaves even within the valid VSID range. > > > > > > > > Actually, you should be able to allow ESIDs of up to 21 bits there (36 > > > bit VSID - 15 bits of "context"). But you will need to make sure > > > get_kernel_vsid(), or whatever you're using to calculate the VAs for > > > the hash HPTEs is updated to match - at the moment I think it will > > > mask down to 13 bits. I'm not sure if that will get you sufficiently > > > close to 0xc0... for your purposes. > > Thanks, Igor From caveman at boxacle.net Wed Oct 6 04:24:25 2004 From: caveman at boxacle.net (CAVEMAN) Date: Tue, 5 Oct 2004 13:24:25 -0500 Subject: Sound on G5 In-Reply-To: <1096939502.24584.6.camel@gaston> References: <1096939502.24584.6.camel@gaston> Message-ID: <200410051324.25817@laptop> On Monday 04 October 2004 20:25, Benjamin Herrenschmidt wrote: > On Tue, 2004-10-05 at 06:51, Andreas Schwab wrote: > > Is anyone already working on sound support for the PowerMac G5, by > > chance? That's actually the only thing still missing. > > Nobody really seriously ATM. One of the main issue is that the darwin > driver abuses apple "do-platform-*" shit. It's a mecanism they invented > to put sort-of "scripts" (in binary form) in the device-tree that can > contains elementary ops such as write GPIOs, I2C, etc... > > This is extremely messy and difficult to parse. I have written the > basis for parsing them, but interpreting them is even more shitty as > the actual implementation of each ops sort-of depends on the target > object. > > It's really a piece-of-shit imho. > > So we could go that way and complete my "interpreter" or just hard code > all of the GPIOs we need in the driver hoping apple don't shuffle them > too much in upcoming models... I'd be willing to do some work and/or testing on this, where can I get the code? Regards, caveman From rmk+lkml at arm.linux.org.uk Wed Oct 6 17:26:59 2004 From: rmk+lkml at arm.linux.org.uk (Russell King) Date: Wed, 6 Oct 2004 08:26:59 +0100 Subject: [RFC][PATCH] Way for platforms to alter built-in serial ports In-Reply-To: <1096534248.32721.36.camel@gaston>; from benh@kernel.crashing.org on Thu, Sep 30, 2004 at 06:50:48PM +1000 References: <1096534248.32721.36.camel@gaston> Message-ID: <20041006082658.A18379@flint.arm.linux.org.uk> On Thu, Sep 30, 2004 at 06:50:48PM +1000, Benjamin Herrenschmidt wrote: > +#ifndef ARCH_HAS_GET_LEGACY_SERIAL_PORTS > static struct old_serial_port old_serial_port[] = { > SERIAL_PORT_DFNS /* defined in asm/serial.h */ > }; > - > +static inline struct old_serial_port *get_legacy_serial_ports(unsigned int *count) > +{ > + *count = ARRAY_SIZE(old_serial_port); > + return old_serial_port; > +} > #define UART_NR (ARRAY_SIZE(old_serial_port) + CONFIG_SERIAL_8250_NR_UARTS) > +#endif /* ARCH_HAS_GET_LEGACY_SERIAL_PORTS */ > + What happens if 8250.c is built as a module and ARCH_HAS_GET_LEGACY_SERIAL_PORTS is defined? > diff -urN linux-2.5/include/linux/serial.h linux-maple/include/linux/serial.h > --- linux-2.5/include/linux/serial.h 2004-09-30 18:31:55.867785437 +1000 > +++ linux-maple/include/linux/serial.h 2004-09-30 15:36:57.981697919 +1000 > @@ -14,6 +14,21 @@ > #include > > /* > + * Definition of a legacy serial port > + */ > +struct old_serial_port { > + unsigned int uart; > + unsigned int baud_base; > + unsigned int port; > + unsigned int irq; > + unsigned int flags; > + unsigned char hub6; > + unsigned char io_type; > + unsigned char *iomem_base; > + unsigned short iomem_reg_shift; > +}; > + > +/* > * Counters of the input lines (CTS, DSR, RI, CD) interrupts > */ serial.h is used by userspace programs. We should not expose this structure to those programs. Instead, maybe creating an 8250.h header, or even moving the existing 8250.h header ? -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/ 2.6 Serial core From benh at kernel.crashing.org Wed Oct 6 18:15:11 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 06 Oct 2004 18:15:11 +1000 Subject: [RFC][PATCH] Way for platforms to alter built-in serial ports In-Reply-To: <20041006082658.A18379@flint.arm.linux.org.uk> References: <1096534248.32721.36.camel@gaston> <20041006082658.A18379@flint.arm.linux.org.uk> Message-ID: <1097050508.21132.15.camel@gaston> On Wed, 2004-10-06 at 17:26, Russell King wrote: > On Thu, Sep 30, 2004 at 06:50:48PM +1000, Benjamin Herrenschmidt wrote: > > +#ifndef ARCH_HAS_GET_LEGACY_SERIAL_PORTS > > static struct old_serial_port old_serial_port[] = { > > SERIAL_PORT_DFNS /* defined in asm/serial.h */ > > }; > > - > > +static inline struct old_serial_port *get_legacy_serial_ports(unsigned int *count) > > +{ > > + *count = ARRAY_SIZE(old_serial_port); > > + return old_serial_port; > > +} > > #define UART_NR (ARRAY_SIZE(old_serial_port) + CONFIG_SERIAL_8250_NR_UARTS) > > +#endif /* ARCH_HAS_GET_LEGACY_SERIAL_PORTS */ > > + > > What happens if 8250.c is built as a module and > ARCH_HAS_GET_LEGACY_SERIAL_PORTS is defined? It well call get_legacy_serial_ports() which is hopefully exported by the arch code. > serial.h is used by userspace programs. We should not expose this > structure to those programs. Instead, maybe creating an 8250.h > header, or even moving the existing 8250.h header ? Hrm... ok. Or adding a #ifdef __KERNEL__ (sic !) :) I'll send you a new patch later today as I had to do another fix, we tend to "force" register_console() apparently even when we have nothing to register because we set the "ops" to all ports even those who were never configured and we test "ops" to decide wether to succeed or fail in the console setup() callback. Ben. From benh at kernel.crashing.org Wed Oct 6 19:07:44 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 06 Oct 2004 19:07:44 +1000 Subject: [RFC][PATCH] Way for platforms to alter built-in serial ports In-Reply-To: <20041006082658.A18379@flint.arm.linux.org.uk> References: <1096534248.32721.36.camel@gaston> <20041006082658.A18379@flint.arm.linux.org.uk> Message-ID: <1097053663.21132.56.camel@gaston> On Wed, 2004-10-06 at 17:26, Russell King wrote: > serial.h is used by userspace programs. We should not expose this > structure to those programs. Instead, maybe creating an 8250.h > header, or even moving the existing 8250.h header ? Here's a new version of that patch that moves 8250.h to include/linux, moves the definition of old_serial_ports there, and also corrects the problem I told you about with serial console. Let me know if I can send it to Andrew... Ben. diff -urN linux-2.5/drivers/serial/8250.c linux-maple/drivers/serial/8250.c --- linux-2.5/drivers/serial/8250.c 2004-09-30 18:31:42.000000000 +1000 +++ linux-maple/drivers/serial/8250.c 2004-10-06 19:05:13.042342513 +1000 @@ -41,7 +41,7 @@ #endif #include -#include "8250.h" +#include /* * Configuration: @@ -112,11 +112,18 @@ #define SERIAL_PORT_DFNS #endif +#ifndef ARCH_HAS_GET_LEGACY_SERIAL_PORTS static struct old_serial_port old_serial_port[] = { SERIAL_PORT_DFNS /* defined in asm/serial.h */ }; - +static inline struct old_serial_port *get_legacy_serial_ports(unsigned int *count) +{ + *count = ARRAY_SIZE(old_serial_port); + return old_serial_port; +} #define UART_NR (ARRAY_SIZE(old_serial_port) + CONFIG_SERIAL_8250_NR_UARTS) +#endif /* ARCH_HAS_DYNAMIC_LEGACY_SERIAL_PORTS */ + #ifdef CONFIG_SERIAL_8250_RSA @@ -1839,22 +1846,28 @@ { struct uart_8250_port *up; static int first = 1; + struct old_serial_port *old_ports; + int count; int i; if (!first) return; first = 0; - for (i = 0, up = serial8250_ports; i < ARRAY_SIZE(old_serial_port); + old_ports = get_legacy_serial_ports(&count); + if (old_ports == NULL) + return; + + for (i = 0, up = serial8250_ports; i < count; i++, up++) { - up->port.iobase = old_serial_port[i].port; - up->port.irq = irq_canonicalize(old_serial_port[i].irq); - up->port.uartclk = old_serial_port[i].baud_base * 16; - up->port.flags = old_serial_port[i].flags; - up->port.hub6 = old_serial_port[i].hub6; - up->port.membase = old_serial_port[i].iomem_base; - up->port.iotype = old_serial_port[i].io_type; - up->port.regshift = old_serial_port[i].iomem_reg_shift; + up->port.iobase = old_ports[i].port; + up->port.irq = irq_canonicalize(old_ports[i].irq); + up->port.uartclk = old_ports[i].baud_base * 16; + up->port.flags = old_ports[i].flags; + up->port.hub6 = old_ports[i].hub6; + up->port.membase = old_ports[i].iomem_base; + up->port.iotype = old_ports[i].io_type; + up->port.regshift = old_ports[i].iomem_reg_shift; up->port.ops = &serial8250_pops; if (share_irqs) up->port.flags |= UPF_SHARE_IRQ; @@ -1870,6 +1883,9 @@ for (i = 0; i < UART_NR; i++) { struct uart_8250_port *up = &serial8250_ports[i]; + if (!up->port.iobase) + continue; + up->port.line = i; up->port.ops = &serial8250_pops; init_timer(&up->timer); diff -urN linux-2.5/drivers/serial/8250.h linux-maple/drivers/serial/8250.h --- linux-2.5/drivers/serial/8250.h 2004-09-30 18:31:42.000000000 +1000 +++ /dev/null 2004-10-05 22:10:47.391719208 +1000 @@ -1,71 +0,0 @@ -/* - * linux/drivers/char/8250.h - * - * Driver for 8250/16550-type serial ports - * - * Based on drivers/char/serial.c, by Linus Torvalds, Theodore Ts'o. - * - * Copyright (C) 2001 Russell King. - * - * 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 of the License, or - * (at your option) any later version. - * - * $Id: 8250.h,v 1.8 2002/07/21 21:32:30 rmk Exp $ - */ - -#include - -void serial8250_get_irq_map(unsigned int *map); -void serial8250_suspend_port(int line); -void serial8250_resume_port(int line); - -struct old_serial_port { - unsigned int uart; - unsigned int baud_base; - unsigned int port; - unsigned int irq; - unsigned int flags; - unsigned char hub6; - unsigned char io_type; - unsigned char *iomem_base; - unsigned short iomem_reg_shift; -}; - -/* - * This replaces serial_uart_config in include/linux/serial.h - */ -struct serial8250_config { - const char *name; - unsigned int fifo_size; - unsigned int tx_loadsz; - unsigned int flags; -}; - -#define UART_CAP_FIFO (1 << 8) /* UART has FIFO */ -#define UART_CAP_EFR (1 << 9) /* UART has EFR */ -#define UART_CAP_SLEEP (1 << 10) /* UART has IER sleep */ - -#undef SERIAL_DEBUG_PCI - -#if defined(__i386__) && (defined(CONFIG_M386) || defined(CONFIG_M486)) -#define SERIAL_INLINE -#endif - -#ifdef SERIAL_INLINE -#define _INLINE_ inline -#else -#define _INLINE_ -#endif - -#define PROBE_RSA (1 << 0) -#define PROBE_ANY (~0) - -#define HIGH_BITS_OFFSET ((sizeof(long)-sizeof(int))*8) - -#ifdef CONFIG_SERIAL_8250_SHARE_IRQ -#define SERIAL8250_SHARE_IRQS 1 -#else -#define SERIAL8250_SHARE_IRQS 0 -#endif diff -urN linux-2.5/drivers/serial/8250_pci.c linux-maple/drivers/serial/8250_pci.c --- linux-2.5/drivers/serial/8250_pci.c 2004-09-30 18:31:42.000000000 +1000 +++ linux-maple/drivers/serial/8250_pci.c 2004-10-06 19:05:41.301674308 +1000 @@ -25,13 +25,12 @@ #include #include #include +#include #include #include #include -#include "8250.h" - /* * Definitions for PCI support. */ diff -urN linux-2.5/drivers/serial/8250_pnp.c linux-maple/drivers/serial/8250_pnp.c --- linux-2.5/drivers/serial/8250_pnp.c 2004-09-30 18:31:42.000000000 +1000 +++ linux-maple/drivers/serial/8250_pnp.c 2004-10-06 19:05:55.788749883 +1000 @@ -25,13 +25,12 @@ #include #include #include +#include #include #include #include -#include "8250.h" - #define UNKNOWN_DEV 0x3000 diff -urN linux-2.5/drivers/serial/au1x00_uart.c linux-maple/drivers/serial/au1x00_uart.c --- linux-2.5/drivers/serial/au1x00_uart.c 2004-09-30 18:31:42.000000000 +1000 +++ linux-maple/drivers/serial/au1x00_uart.c 2004-10-06 19:07:39.461032916 +1000 @@ -40,7 +40,7 @@ #endif #include -#include "8250.h" +#include /* * Debugging. diff -urN linux-2.5/drivers/serial/serial_cs.c linux-maple/drivers/serial/serial_cs.c --- linux-2.5/drivers/serial/serial_cs.c 2004-09-30 18:31:42.000000000 +1000 +++ linux-maple/drivers/serial/serial_cs.c 2004-10-06 19:07:35.059700476 +1000 @@ -44,6 +44,7 @@ #include #include #include +#include #include #include @@ -55,8 +56,6 @@ #include #include -#include "8250.h" - #ifdef PCMCIA_DEBUG static int pc_debug = PCMCIA_DEBUG; MODULE_PARM(pc_debug, "i"); diff -urN linux-2.5/include/linux/8250.h linux-maple/include/linux/8250.h --- /dev/null 2004-10-05 22:10:47.391719208 +1000 +++ linux-maple/include/linux/8250.h 2004-10-06 19:06:45.680713598 +1000 @@ -0,0 +1,74 @@ +/* + * linux/drivers/char/8250.h + * + * Driver for 8250/16550-type serial ports + * + * Based on drivers/char/serial.c, by Linus Torvalds, Theodore Ts'o. + * + * Copyright (C) 2001 Russell King. + * + * 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 of the License, or + * (at your option) any later version. + * + * $Id: 8250.h,v 1.8 2002/07/21 21:32:30 rmk Exp $ + */ + +#include + +void serial8250_get_irq_map(unsigned int *map); +void serial8250_suspend_port(int line); +void serial8250_resume_port(int line); + +/* + * This replaces serial_uart_config in include/linux/serial.h + */ +struct serial8250_config { + const char *name; + unsigned int fifo_size; + unsigned int tx_loadsz; + unsigned int flags; +}; + +#define UART_CAP_FIFO (1 << 8) /* UART has FIFO */ +#define UART_CAP_EFR (1 << 9) /* UART has EFR */ +#define UART_CAP_SLEEP (1 << 10) /* UART has IER sleep */ + +/* + * Definition of a legacy serial port + */ +struct old_serial_port { + unsigned int uart; + unsigned int baud_base; + unsigned int port; + unsigned int irq; + unsigned int flags; + unsigned char hub6; + unsigned char io_type; + unsigned char *iomem_base; + unsigned short iomem_reg_shift; +}; + +#undef SERIAL_DEBUG_PCI + +#if defined(__i386__) && (defined(CONFIG_M386) || defined(CONFIG_M486)) +#define SERIAL_INLINE +#endif + +#ifdef SERIAL_INLINE +#define _INLINE_ inline +#else +#define _INLINE_ +#endif + +#define PROBE_RSA (1 << 0) +#define PROBE_ANY (~0) + +#define HIGH_BITS_OFFSET ((sizeof(long)-sizeof(int))*8) + +#ifdef CONFIG_SERIAL_8250_SHARE_IRQ +#define SERIAL8250_SHARE_IRQS 1 +#else +#define SERIAL8250_SHARE_IRQS 0 +#endif From clmason at gmail.com Thu Oct 7 00:58:56 2004 From: clmason at gmail.com (Chris L. Mason) Date: Wed, 6 Oct 2004 11:58:56 -0300 Subject: iMac G5 available for testing Message-ID: <610e346604100607581144298e@mail.gmail.com> Hi all, I have a new iMac G5/1.8 GHz/17-inch system that I would like to make available for testing/debugging. If you have anything you would like me to try booting, checking in open firmware, etc., let me know. Thanks, Chris From benh at kernel.crashing.org Thu Oct 7 08:36:09 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Thu, 07 Oct 2004 08:36:09 +1000 Subject: iMac G5 available for testing In-Reply-To: <610e346604100607581144298e@mail.gmail.com> References: <610e346604100607581144298e@mail.gmail.com> Message-ID: <1097102169.8448.14.camel@gaston> On Thu, 2004-10-07 at 00:58, Chris L. Mason wrote: > Hi all, > > I have a new iMac G5/1.8 GHz/17-inch system that I would like to make > available for testing/debugging. If you have anything you would like > me to try booting, checking in open firmware, etc., let me know. We have ordered one here. It will require some reverse engineering work since it's a new rev of the chipset and the good old PMU chip was finally, years later, replaced by a new "SMU" that is totally undocumented of course... Ben. From clmason at gmail.com Thu Oct 7 09:12:04 2004 From: clmason at gmail.com (Chris L. Mason) Date: Wed, 6 Oct 2004 20:12:04 -0300 Subject: iMac G5 available for testing In-Reply-To: <1097102169.8448.14.camel@gaston> References: <610e346604100607581144298e@mail.gmail.com> <1097102169.8448.14.camel@gaston> Message-ID: <610e34660410061612379af1c8@mail.gmail.com> On Thu, 07 Oct 2004 08:36:09 +1000, Benjamin Herrenschmidt wrote: > > > On Thu, 2004-10-07 at 00:58, Chris L. Mason wrote: > > Hi all, > > > > I have a new iMac G5/1.8 GHz/17-inch system that I would like to make > > available for testing/debugging. If you have anything you would like > > me to try booting, checking in open firmware, etc., let me know. > > We have ordered one here. It will require some reverse engineering work > since it's a new rev of the chipset and the good old PMU chip was finally, > years later, replaced by a new "SMU" that is totally undocumented of course... > Ah, wonderful. :) The good news is that with tgall's latest debug kernel, I do at least get to boot as far the ata drive detection before it freezes, although it gets kernel error too right after the tux logo. Here's an image of my boot attempt: http://homepage.mac.com/clmason/imacboot.jpg (Sorry for the bad quality of the image) Segher also told me how to use the romgrabber. I have a copy up at: http://homepage.mac.com/clmason/OF-5.2.2f1-2004-08-18 Chris From david at gibson.dropbear.id.au Thu Oct 7 11:01:54 2004 From: david at gibson.dropbear.id.au (David Gibson) Date: Thu, 7 Oct 2004 11:01:54 +1000 Subject: mapping memory in 0xb space In-Reply-To: References: <20040929014017.GC5470@zax> <20041001040325.GB12890@zax> Message-ID: <20041007010154.GC25012@zax> On Tue, Oct 05, 2004 at 12:45:47PM -0500, Igor Grobman wrote: > One more followup on this issue, since I do have the base code working > now. The problem was in the fact that do_slb_bolted code sets the large > page bit in the SLB entry, but my code (and particularly hpte_insert code) > did not insert a proper large page mapping. > > > On Fri, 1 Oct 2004, David Gibson wrote: > > On Wed, Sep 29, 2004 at 12:14:08AM -0500, Igor Grobman wrote: > > > On Wed, 29 Sep 2004, David Gibson wrote: > > > > > > > On Tue, Sep 28, 2004 at 01:52:16PM -0500, Igor Grobman wrote: > > > > > On Tue, 28 Sep 2004, David Gibson wrote: > > > As for why I thought 0xbff would work, I reasoned that > > > since the highest bits are masked out in get_kernel_vsid(), and since > > > nobody else is using the 0xb region, it doesn't matter if I get a VSID > > > that is the same as some other VSID in 0xb region. However, I did not > > > consider the bug in do_slb_bolted that you describe below. > > > > Yes, with that bug the collision can be with a segment anywhere, not > > just in the 0xb region. > > > > I am not convinced anymore. The lower 36 bits of the ordinal are still > the same in do_slb_bolted and get_kernel_vsid. Multiplying the ordinal > by the 36-bit randomizer should produce the same lower 36 bits whether or > not the upper bits are different. do_slb_bolted eventually clears the > upper 28 bits, before using the VSID. I no longer think there can be > a conflict outside the 0xb region. Is my reasoning correct? Ah, yes, I think it is. Sorry, I guess I wasn't thinking very clearly when I decided the collisions could be anywhere. -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson From benh at kernel.crashing.org Thu Oct 7 18:30:09 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Thu, 07 Oct 2004 18:30:09 +1000 Subject: Gothic horrors in pci_dn.c Message-ID: <1097137808.4894.73.camel@gaston> Hi ! To all those who had to deal with the guts of the PCI layer on ppc64, I'd like your comments about these and what do you think I may break. Currently, the code in pci_dn.c does 2 things articulated around a single function. That function is traverse_pci_devices() and is supposed to traverse the PCI tree exposed by Open Firmware and call back a function passed as an argument for each node in the tree. The 2 things it does are - Setting up the "devfn" and "busno" fields of the device nodes in the tree in an initial traversal pass at boot - "Finding" a device node for a given pci_dev at any time However, the current code does a number of assumptions and is bogus in many cases. Among the issues are: - The tree traversal goes all the way down the tree only skipping things that don't have a "class code". That means potentially walking on subtrees of a PCI device that aren't PCI themselves (USB ? FireWire ?) and we have no guarantee that those busses have no "class-code" property, though we are sure to misinterpret anything we find here. - We try to manipulate host bridge nodes as if they were PCI devices, which leads us to various funny and totally bogus special cases. First, in update_dn_pci_info(), where we have an "intersting" (at least) heuristic to find out if a node if a host bridge or not, with an horrible special case for avoiding setting the devfn 0 on U3 on blades, and then we "use" those devfn and busno of the host bridge property in is_devfn_node() later on when trying to match which is why we have to do the above bogus workaround. - Our firmware (and Apple's too in some cases) is broken in the sense that it doesn't show the host bridge in the tree as a PCI device. Host bridges that are themselves visible as devices on their own PCI bus should have an additional node in the PCI domain named "host" that represent them. The solution to this however is very simple, but I need to make sure I won't break anything else by doing so. It's based on a few facts: - The "node" of the host bridge is _NOT_ a PCI node, and thus should not be traversed by traverse_pci_devices(). This is very easy to do without any assumption due to the way this function works, just remove 2 lines near the beginning before the for loop. - The result for the update_dn_pci_info() pass is that we can rip off the workaround completely. busno and devfn in the host bridge node are undefined and that how they should be as they won't be traversed. There is no "driver" for the host bridge that should make use of them. - Same thing with is_devfn_node(). - We initialize "sysdata" of all pci_dev to point the the host bridge by default. So if the host bridge happens to have an associated pci_dev, and no "specific" node (as explained above), then we'll point to the root node of that pci tree which is exactly what we want, cool ! - Now the only remaining problem is the test if (dn->devfn == dev->devfn && dn->busno == (dev->bus->number&0xff)) Which will result in incorrect result if the host bridge has undefined (and typically 0) values in devfn and busno fields and the device we are looking for happens to really be 0:00.0. This is fixed by forcing those fields on all PHB nodes to -1. (No special U3 case, all of them). Here's a patch (untested, it's getting late here) implementing those, I need to know if it will work at all. Comments welcome :) Note to Anton & Milton: Pretty much nothing relies anymore on the device nodes for PCI devices to exist. The only mandatory ones are PHBs, but you can easily statically lay them out in a static device-tree blob for BM. By default, all pci_dev point to the PHB. I have a couple of fixes coming in for u3_iommu to properly setup iommu_table for PHB nodes (it forgot to do it) and I confirm it works with no OF nodes for the devices themselves. Config space accesses never need the OF node neither except when you have RTAS, but then you don't care since you have real nodes for everything. I added a simple helper to my tree (will be pushed after 2.6.9) that gives you the pci_controller* from the pci_dev* without doing a full device-tree walk, and I use that for pmac & maple. You should do the same for PM. Ben. ===== arch/ppc64/kernel/pci_dn.c 1.18 vs edited ===== --- 1.18/arch/ppc64/kernel/pci_dn.c 2004-10-05 17:24:47 +10:00 +++ edited/arch/ppc64/kernel/pci_dn.c 2004-10-07 18:35:41 +10:00 @@ -46,28 +46,13 @@ { struct pci_controller *phb = data; u32 *regs; - char *device_type = get_property(dn, "device_type", NULL); - char *model; dn->phb = phb; - if (device_type && (strcmp(device_type, "pci") == 0) && - (get_property(dn, "class-code", NULL) == 0)) { - /* special case for PHB's. Sigh. */ - regs = (u32 *)get_property(dn, "bus-range", NULL); - dn->busno = regs[0]; - - model = (char *)get_property(dn, "model", NULL); - if (model && strstr(model, "U3")) - dn->devfn = -1; - else - dn->devfn = 0; /* assumption */ - } else { - regs = (u32 *)get_property(dn, "reg", NULL); - if (regs) { - /* First register entry is addr (00BBSS00) */ - dn->busno = (regs[0] >> 16) & 0xff; - dn->devfn = (regs[0] >> 8) & 0xff; - } + regs = (u32 *)get_property(dn, "reg", NULL); + if (regs) { + /* First register entry is addr (00BBSS00) */ + dn->busno = (regs[0] >> 16) & 0xff; + dn->devfn = (regs[0] >> 8) & 0xff; } return NULL; } @@ -96,20 +81,25 @@ struct device_node *dn, *nextdn; void *ret; - if (pre && ((ret = pre(start, data)) != NULL)) - return ret; + /* We started with a phb, iterate all childs */ for (dn = start->child; dn; dn = nextdn) { + u32 *classp, class; + nextdn = NULL; - if (get_property(dn, "class-code", NULL)) { - if (pre && ((ret = pre(dn, data)) != NULL)) - return ret; - if (dn->child) - /* Depth first...do children */ - nextdn = dn->child; - else if (dn->sibling) - /* ok, try next sibling instead. */ - nextdn = dn->sibling; - } + classp = (u32 *)get_property(dn, "class-code", NULL); + class = classp ? *classp : 0; + + if (pre && ((ret = pre(dn, data)) != NULL)) + return ret; + + /* If we are a PCI bridge, go down */ + if (dn->child && (class >> 8) == PCI_CLASS_BRIDGE_PCI && + (class >> 8) == PCI_CLASS_BRIDGE_CARDBUS) + /* Depth first...do children */ + nextdn = dn->child; + else if (dn->sibling) + /* ok, try next sibling instead. */ + nextdn = dn->sibling; if (!nextdn) { /* Walk up to next valid sibling. */ do { @@ -123,21 +113,6 @@ return NULL; } -/* - * Same as traverse_pci_devices except this does it for all phbs. - */ -static void *traverse_all_pci_devices(traverse_func pre) -{ - struct pci_controller *phb, *tmp; - void *ret; - - list_for_each_entry_safe(phb, tmp, &hose_list, list_node) - if ((ret = traverse_pci_devices(phb->arch_data, pre, phb)) - != NULL) - return ret; - return NULL; -} - /* * Traversal func that looks for a value. @@ -147,6 +122,7 @@ { int busno = ((unsigned long)data >> 8) & 0xff; int devfn = ((unsigned long)data) & 0xff; + return ((devfn == dn->devfn) && (busno == dn->busno)) ? dn : NULL; } @@ -173,10 +149,8 @@ phb_dn = phb->arch_data; dn = traverse_pci_devices(phb_dn, is_devfn_node, (void *)searchval); - if (dn) { + if (dn) dev->sysdata = dn; - /* ToDo: call some device init hook here */ - } return dn; } EXPORT_SYMBOL(fetch_dev_dn); @@ -188,8 +162,16 @@ */ void __init pci_devs_phb_init(void) { + struct pci_controller *phb, *tmp; + /* This must be done first so the device nodes have valid pci info! */ - traverse_all_pci_devices(update_dn_pci_info); + list_for_each_entry_safe(phb, tmp, &hose_list, list_node) { + struct device_node * dn = (struct device_node *) phb->arch_data; + /* PHB nodes themselves must not match */ + dn->devfn = dn->busno = -1; + dn->phb = phb; + traverse_pci_devices(phb->arch_data, update_dn_pci_info, phb); + } } From hollisb at us.ibm.com Thu Oct 7 20:40:27 2004 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Thu, 7 Oct 2004 10:40:27 +0000 Subject: [patch] HVSI udbg Message-ID: <200410071040.27907.hollisb@us.ibm.com> This fixes a long-standing omission in HVSI support: dropping to xmon would basically hang your system, as there was no udbg code to read/write chars from xmon. It's based on the existing "LP" routines. Could we get this pushed upstream soon? -- Hollis Blanchard IBM Linux Technology Center ===== arch/ppc64/kernel/pSeries_lpar.c 1.41 vs edited ===== --- 1.41/arch/ppc64/kernel/pSeries_lpar.c Tue Sep 21 23:40:30 2004 +++ edited/arch/ppc64/kernel/pSeries_lpar.c Thu Oct 7 10:52:23 2004 @@ -59,6 +59,74 @@ int vtermno; /* virtual terminal# for udbg */ +#define __ALIGNED__ __attribute__((__aligned__(sizeof(long)))) +static void udbg_hvsi_putc(unsigned char c) +{ + /* packet's seqno isn't used anyways */ + uint8_t packet[] __ALIGNED__ = { 0xff, 5, 0, 0, c }; + int rc; + + if (c == '\n') + udbg_hvsi_putc('\r'); + + do { + rc = plpar_put_term_char(vtermno, sizeof(packet), packet); + } while (rc == H_Busy); +} + +static long hvsi_udbg_buf_len; +static uint8_t hvsi_udbg_buf[256]; + +static int udbg_hvsi_getc_poll(void) +{ + unsigned char ch; + int rc, i; + + if (hvsi_udbg_buf_len == 0) { + rc = plpar_get_term_char(vtermno, &hvsi_udbg_buf_len, hvsi_udbg_buf); + if (rc != H_Success || hvsi_udbg_buf[0] != 0xff) { + /* bad read or non-data packet */ + hvsi_udbg_buf_len = 0; + } else { + /* remove the packet header */ + for (i = 4; i < hvsi_udbg_buf_len; i++) + hvsi_udbg_buf[i-4] = hvsi_udbg_buf[i]; + hvsi_udbg_buf_len -= 4; + } + } + + if (hvsi_udbg_buf_len <= 0 || hvsi_udbg_buf_len > 256) { + /* no data ready */ + hvsi_udbg_buf_len = 0; + return -1; + } + + ch = hvsi_udbg_buf[0]; + /* shift remaining data down */ + for (i = 1; i < hvsi_udbg_buf_len; i++) { + hvsi_udbg_buf[i-1] = hvsi_udbg_buf[i]; + } + hvsi_udbg_buf_len--; + + return ch; +} + +static unsigned char udbg_hvsi_getc(void) +{ + int ch; + for (;;) { + ch = udbg_hvsi_getc_poll(); + if (ch == -1) { + /* This shouldn't be needed...but... */ + volatile unsigned long delay; + for (delay=0; delay < 2000000; delay++) + ; + } else { + return ch; + } + } +} + static void udbg_putcLP(unsigned char c) { char buf[16]; @@ -167,11 +235,15 @@ ppc_md.udbg_getc_poll = udbg_getc_pollLP; found = 1; } - } else { - /* XXX implement udbg_putcLP_vtty for hvterm-protocol1 case */ - printk(KERN_WARNING "%s doesn't speak hvterm1; " - "can't print udbg messages\n", - stdout_node->full_name); + } else if (device_is_compatible(stdout_node, "hvterm-protocol")) { + termno = (u32 *)get_property(stdout_node, "reg", NULL); + if (termno) { + vtermno = termno[0]; + ppc_md.udbg_putc = udbg_hvsi_putc; + ppc_md.udbg_getc = udbg_hvsi_getc; + ppc_md.udbg_getc_poll = udbg_hvsi_getc_poll; + found = 1; + } } } else if (strncmp(name, "serial", 6)) { /* XXX fix ISA serial console */ From johnrose at austin.ibm.com Fri Oct 8 03:54:21 2004 From: johnrose at austin.ibm.com (John Rose) Date: Thu, 07 Oct 2004 12:54:21 -0500 Subject: [PATCH] create iommu_free_table() Message-ID: <1097171661.7087.1.camel@sinatra.austin.ibm.com> The patch below creates iommu_free_table(). Iommu tables are not currently freed in PPC64. This could cause a memory leak for DLPAR of an EADS slot. The function verifies that there are no outstanding TCE entries for the range of the table before freeing it. I added a call to iommu_free_table() to the code that dynamically removes a device node. This should be fairly symmetrical with the table allocation, which happens during dynamic addition of a device node. Comments welcome. Thanks- John Signed-off-by: John Rose diff -Nru a/arch/ppc64/kernel/pSeries_iommu.c b/arch/ppc64/kernel/pSeries_iommu.c --- a/arch/ppc64/kernel/pSeries_iommu.c Thu Oct 7 11:08:19 2004 +++ b/arch/ppc64/kernel/pSeries_iommu.c Thu Oct 7 11:08:19 2004 @@ -412,6 +412,38 @@ dn->iommu_table = iommu_init_table(tbl); } +void iommu_free_table(struct device_node *dn) +{ + struct iommu_table *tbl = dn->iommu_table; + unsigned long bitmap_sz, i; + unsigned int order; + + if (!tbl || !tbl->it_map) { + printk(KERN_ERR "%s: expected TCE map for %s\n", __FUNCTION__, + dn->full_name); + return; + } + + /* verify that table contains no entries */ + /* it_mapsize is in entries, and we're examining 64 at a time */ + for (i = 0; i < (tbl->it_mapsize/64); i++) { + if (tbl->it_map[i] != 0) { + printk(KERN_WARNING "%s: Unexpected TCEs for %s\n", + __FUNCTION__, dn->full_name); + break; + } + } + + /* calculate bitmap size in bytes */ + bitmap_sz = (tbl->it_mapsize + 7) / 8; + + /* free bitmap */ + order = get_order(bitmap_sz); + free_pages((unsigned long) tbl->it_map, order); + + /* free table */ + kfree(tbl); +} void iommu_setup_pSeries(void) { diff -Nru a/arch/ppc64/kernel/prom.c b/arch/ppc64/kernel/prom.c --- a/arch/ppc64/kernel/prom.c Thu Oct 7 11:08:19 2004 +++ b/arch/ppc64/kernel/prom.c Thu Oct 7 11:08:19 2004 @@ -1818,6 +1818,9 @@ return -EBUSY; } + if (np->iommu_table) + iommu_free_table(np); + write_lock(&devtree_lock); OF_MARK_STALE(np); remove_node_proc_entries(np); diff -Nru a/include/asm-ppc64/iommu.h b/include/asm-ppc64/iommu.h --- a/include/asm-ppc64/iommu.h Thu Oct 7 11:08:19 2004 +++ b/include/asm-ppc64/iommu.h Thu Oct 7 11:08:19 2004 @@ -113,6 +113,9 @@ /* Creates table for an individual device node */ extern void iommu_devnode_init(struct device_node *dn); +/* Frees table for an individual device node */ +extern void iommu_free_table(struct device_node *dn); + #endif /* CONFIG_PPC_MULTIPLATFORM */ #ifdef CONFIG_PPC_ISERIES From linas at austin.ibm.com Fri Oct 8 04:13:35 2004 From: linas at austin.ibm.com (Linas Vepstas) Date: Thu, 7 Oct 2004 13:13:35 -0500 Subject: [linas: [PATCH] PPC64: crash during firmware flash update] Message-ID: <20041007181335.GA21633@austin.ibm.com> Sent to the wrong mailing list :) ----- Forwarded message from linas ----- To: paulus at samba.org, anton at samba.org Cc: linuxppc64-dev at lists.linuxppc.org Subject: [PATCH] PPC64: crash during firmware flash update Race conditions during system shutdown after a firmware flash can sometimes lead to an invalid pointer deref (deref to freed memory). This patch fixes this. In addition, it makes sure that the proc entries created by the firmware flash module are removed when the module is unloaded. Signed-off-by: Linas Vepstas --- a/arch/ppc64/kernel/rtas_flash.c.orig 2004-09-20 11:59:18.000000000 -0500 +++ b/arch/ppc64/kernel/rtas_flash.c 2004-10-06 11:19:45.000000000 -0500 @@ -562,6 +562,7 @@ static int validate_flash_release(struct validate_flash(args_buf); } + /* The matching atomic_inc was in rtas_excl_open() */ atomic_dec(&dp->count); return 0; @@ -572,7 +573,8 @@ static void remove_flash_pde(struct proc if (dp) { if (dp->data != NULL) kfree(dp->data); - remove_proc_entry(dp->name, NULL); + dp->owner = NULL; + remove_proc_entry(dp->name, dp->parent); } } ----- End forwarded message ----- From benh at kernel.crashing.org Fri Oct 8 12:27:07 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 08 Oct 2004 12:27:07 +1000 Subject: Gothic horrors in pci_dn.c In-Reply-To: <1097137808.4894.73.camel@gaston> References: <1097137808.4894.73.camel@gaston> Message-ID: <1097202427.846.102.camel@gaston> On Thu, 2004-10-07 at 18:30, Benjamin Herrenschmidt wrote: > + /* If we are a PCI bridge, go down */ > + if (dn->child && (class >> 8) == PCI_CLASS_BRIDGE_PCI && > + (class >> 8) == PCI_CLASS_BRIDGE_CARDBUS) > + /* Depth first...do children */ > + nextdn = dn->child; Of course, that should have been + /* If we are a PCI bridge, go down */ + if (dn->child && ((class >> 8) == PCI_CLASS_BRIDGE_PCI || + (class >> 8) == PCI_CLASS_BRIDGE_CARDBUS)) + /* Depth first...do children */ + nextdn = dn->child; Ben. From paulus at samba.org Fri Oct 8 10:44:32 2004 From: paulus at samba.org (Paul Mackerras) Date: Fri, 8 Oct 2004 10:44:32 +1000 Subject: [patch] HVSI udbg In-Reply-To: <200410071040.27907.hollisb@us.ibm.com> References: <200410071040.27907.hollisb@us.ibm.com> Message-ID: <16741.58096.932315.526999@cargo.ozlabs.ibm.com> Hollis, > --- 1.41/arch/ppc64/kernel/pSeries_lpar.c Tue Sep 21 23:40:30 2004 > +++ edited/arch/ppc64/kernel/pSeries_lpar.c Thu Oct 7 10:52:23 2004 > @@ -59,6 +59,74 @@ > > int vtermno; /* virtual terminal# for udbg */ > > +#define __ALIGNED__ __attribute__((__aligned__(sizeof(long)))) > +static void udbg_hvsi_putc(unsigned char c) > +{ > + /* packet's seqno isn't used anyways */ > + uint8_t packet[] __ALIGNED__ = { 0xff, 5, 0, 0, c }; > + int rc; All the tabs in the patch seem to have got changed to spaces. Is it your mailer or is the list software doing something bad? Paul. From arnd at arndb.de Fri Oct 8 16:22:57 2004 From: arnd at arndb.de (Arnd Bergmann) Date: Fri, 8 Oct 2004 08:22:57 +0200 Subject: [patch] HVSI udbg In-Reply-To: <16741.58096.932315.526999@cargo.ozlabs.ibm.com> References: <200410071040.27907.hollisb@us.ibm.com> <16741.58096.932315.526999@cargo.ozlabs.ibm.com> Message-ID: <200410080823.03298.arnd@arndb.de> On Freedag 08 Oktober 2004 02:44, Paul Mackerras wrote: > All the tabs in the patch seem to have got changed to spaces. Is it > your mailer or is the list software doing something bad? It's the latest kmail (or Qt) update from Debian Sarge that broke this. I have the same problem here. Attachments appear to be still working. http://bugs.kde.org/show_bug.cgi?id=90688 Arnd <>< -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: signature Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041008/33488d20/attachment.pgp From hollisb at us.ibm.com Fri Oct 8 22:42:13 2004 From: hollisb at us.ibm.com (Hollis Blanchard) Date: Fri, 8 Oct 2004 12:42:13 +0000 Subject: [patch 2] HVSI udbg Message-ID: <200410081242.13486.hollisb@us.ibm.com> This patch (resent as attachment due to mailer troubles) adds support for the udbg early console interfaces when using an HVSI console. -- Hollis Blanchard IBM Linux Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: hvsi-udbg.diff Type: text/x-diff Size: 2552 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041008/663aa099/attachment.diff From david at gibson.dropbear.id.au Mon Oct 11 12:11:46 2004 From: david at gibson.dropbear.id.au (David Gibson) Date: Mon, 11 Oct 2004 12:11:46 +1000 Subject: [PPC64] xmon sparse cleanups In-Reply-To: <16738.31164.464250.638432@cargo.ozlabs.ibm.com> References: <20041005064255.GF3695@zax> <16738.31164.464250.638432@cargo.ozlabs.ibm.com> Message-ID: <20041011021146.GA1556@zax> On Tue, Oct 05, 2004 at 08:38:52PM +1000, Paul Mackerras wrote: > David Gibson writes: > > > Andrew, please apply: > > > > This patch removes many sparse warnings from the xmon code. Mostly > > K&R function declarations and 0-instead-of-NULLs. > > The trouble with this patch is that it makes ppc-opc.c diverge from > the version in binutils, which is where it came from. I'd rather keep > it as close as possible to that version. I have no problem with the > changes to the other files. A corresponding patch has now gone into binutils CVS. As it happens there has already been a certain amount of divergence between the versions, presumably because the kernel copy hasn't been updated from binutils in quite a while. -- David Gibson | For every complex problem there is a david AT gibson.dropbear.id.au | solution which is simple, neat and | wrong. http://www.ozlabs.org/people/dgibson From schwab at suse.de Tue Oct 12 06:11:42 2004 From: schwab at suse.de (Andreas Schwab) Date: Mon, 11 Oct 2004 22:11:42 +0200 Subject: 2.6.9-rc4: oops during ide probing Message-ID: I'm getting an oops during ide probing on the PMac G5 with 2.6.9-rc4: ide-pmac: cannot find MacIO node for Kauai ATA interface ide0: Found Apple OHare ATA controller, bus ID 0, irq 0 Oops: Kernel access of bad area, sig: 11 [#1] NIP [...] .ide_mm_inb+0x0/0x14 LR [...] .ide_wait_not_busy+0x98/0xf0 (Sorry, I couldn't capture the whole oops.) I've tried also with the patch from , but that didn't help. Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux AG, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From pbadari at us.ibm.com Tue Oct 12 08:07:32 2004 From: pbadari at us.ibm.com (Badari Pulavarty) Date: 11 Oct 2004 15:07:32 -0700 Subject: 2.6.9-rc4-mm1 doesn't boot on my Power3 box Message-ID: <1097532452.12861.398.camel@dyn318077bld.beaverton.ibm.com> Hi, My Power3 box doesn't boot with 2.6.9-rc4-mm1. I get following OOPs. (2.6.9-rc3-mm3 also same issue). Any fixes ? Thanks, Badari kernel BUG in __flush_tlb_pending at arch/ppc64/mm/tlb.c:125! Oops: Exception in kernel mode, sig: 5 [#1] SMP NR_CPUS=128 NUMA PSERIES NIP: C00000000003E344 XER: 0000000020000000 LR: C000000000014DA0 REGS: c000000001963550 TRAP: 0700 Not tainted (2.6.9-rc4-mm1) MSR: a000000000023032 EE: 0 PR: 0 FP: 1 ME: 1 IR/DR: 11 TASK: c00000003f7577e0[1396] 'hotplug' THREAD: c000000001960000 CPU: 0 GPR00: 0000000004000000 C0000000019637D0 C0000000005D29F0 C0000000006B70A0 GPR04: C00000003FB597E0 000000028904198B C0000000005D1008 C0000000004583B0 GPR08: 0000000000260F00 C000000001960000 C0000000005D1008 0000000000000002 GPR12: 0000000022222482 C0000000004B9900 C00000003F757A80 00000030CAC526D0 GPR16: C0000000005D1008 000000000065E4C0 0000000000000000 C00000000F052500 GPR20: C0000000006BAD88 C000000001963990 C00000003FB597E0 C0000000006B9B38 GPR24: C000000001945200 C00000003F7577E0 0000000018221613 C00000003FB597E0 GPR28: 0000000000001260 C00000003F7577E0 0000000000000000 C0000000006B70A0 NIP [c00000000003e344] .__flush_tlb_pending+0x38/0x150 LR [c000000000014da0] .__switch_to+0xb4/0xd8 Call Trace: [c0000000019637d0] [00000000f7fad210] 0xf7fad210 (unreliable) --- Exception: 901 at .copy_page_range+0x218/0x61c LR = .copy_page_range+0x160/0x61c [c000000001963890] [c000000000014da0] .__switch_to+0xb4/0xd8 (unreliable) [c000000001963920] [c00000000039a5dc] .schedule+0x38c/0xc3c [c000000001963a40] [c00000000039b028] .cond_resched+0x4c/0x80 [c000000001963ac0] [c000000000096eb0] .copy_page_range+0x29c/0x61c [c000000001963bd0] [c00000000004fecc] .copy_process+0x8c0/0x148c [c000000001963ce0] [c000000000050b38] .do_fork+0xa0/0x25c [c000000001963dc0] [c000000000014680] .sys_clone+0x5c/0x74 [c000000001963e30] [c000000000010208] .ppc_clone+0x8/0xc From dwmw2 at infradead.org Tue