* Re: [PATCH] Fix USB suspend/resume crasher
From: Rafael J. Wysocki @ 2005-11-24 21:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Morton, Greg KH, linux-kernel, David Brownell,
linuxppc-dev list, Alan Stern
In-Reply-To: <1132866088.26560.455.camel@gaston>
On Thursday, 24 of November 2005 22:01, Benjamin Herrenschmidt wrote:
>
> >
> > Well, it's there (actually the problem occurs in vanilla 2.6.15-rc2-mm1 that
> > contains the patch). Do you mean it should go before the
> >
> > if (readl(&ehci->regs->configured_flag) != FLAG_CF)
> > goto restart;
> >
> > thing?
>
> Yes.
>
> > > It may be worth following it with a memory barrier actually... just in case
> > > (due to the absence of locks in that area).
> >
> > wmb()?
>
> Yup.
>
> I wrote that patch against a tree that had different things in that
> function, Greg merged it by hand but he got that little bit wrong
> unfortunately. I'll send a new patch later today.
Thanks.
FWIW, does the appended change look reasonable to you? (It apparently
helps. ;-))
Rafael
Index: linux-2.6.15-rc2-mm1/drivers/usb/host/ehci-pci.c
===================================================================
--- linux-2.6.15-rc2-mm1.orig/drivers/usb/host/ehci-pci.c 2005-11-24 21:42:34.000000000 +0100
+++ linux-2.6.15-rc2-mm1/drivers/usb/host/ehci-pci.c 2005-11-24 21:50:38.000000000 +0100
@@ -281,12 +281,13 @@
if (time_before(jiffies, ehci->next_statechange))
msleep(100);
+ set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
+ wmb();
+
/* If CF is clear, we lost PCI Vaux power and need to restart. */
if (readl(&ehci->regs->configured_flag) != FLAG_CF)
goto restart;
- set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
-
/* If any port is suspended (or owned by the companion),
* we know we can/must resume the HC (and mustn't reset it).
* We just defer that to the root hub code.
^ permalink raw reply
* Re: [PATCH] Fix USB suspend/resume crasher
From: Benjamin Herrenschmidt @ 2005-11-24 21:01 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Andrew Morton, Greg KH, linux-kernel, David Brownell,
linuxppc-dev list, Alan Stern
In-Reply-To: <200511242150.23205.rjw@sisk.pl>
>
> Well, it's there (actually the problem occurs in vanilla 2.6.15-rc2-mm1 that
> contains the patch). Do you mean it should go before the
>
> if (readl(&ehci->regs->configured_flag) != FLAG_CF)
> goto restart;
>
> thing?
Yes.
> > It may be worth following it with a memory barrier actually... just in case
> > (due to the absence of locks in that area).
>
> wmb()?
Yup.
I wrote that patch against a tree that had different things in that
function, Greg merged it by hand but he got that little bit wrong
unfortunately. I'll send a new patch later today.
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc: serial port discovery
From: Benjamin Herrenschmidt @ 2005-11-24 20:57 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <1132852136.11921.85.camel@baythorne.infradead.org>
On Thu, 2005-11-24 at 17:08 +0000, David Woodhouse wrote:
> On Tue, 2005-11-22 at 15:49 +1100, Benjamin Herrenschmidt wrote:
> > This moves the discovery of legacy serial ports to a separate file,
> > makes it common to ppc32 and ppc64, and reworks it to use the new OF
> > address translators to get to the ports early. This new version can also
> > detect some PCI serial cards using legacy chips and will probably match
> > those discovered port with the default console choice.
>
> This makes it deal with the fact that the Pegasos firmware reports that
> its clock frequency is zero...
Gack !?!?
Sven, what's up there ? Why the hell would you do that ?
Ben.
^ permalink raw reply
* Re: [PATCH] Fix USB suspend/resume crasher
From: Rafael J. Wysocki @ 2005-11-24 20:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andrew Morton, Greg KH, linux-kernel, David Brownell,
linuxppc-dev list, Alan Stern
In-Reply-To: <1132795396.26560.382.camel@gaston>
On Thursday, 24 of November 2005 02:23, Benjamin Herrenschmidt wrote:
>
> > Unfortunately with this patch the EHCI controller in my box (Asus L5D,
> > x86-64 kernel) does not resume from suspend. Appended is the relevant
> > snippet from the serial console log (EHCI is the only device using IRQ #5).
>
> Hrm... let me see... You are getting an interrupt for EHCI after it has
> been resumed, so it should work.
>
> /me double-checks the patch
>
> > ehci_hcd 0000:00:02.2: lost power, restarting
>
> Hrm... I can't find that line in the code...
>
> /me rechecks with david's other patches
>
> Ah ... I see it. There might have been some screwup between david's
> patch and mine.
>
> Make sure that
>
> set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
>
> Is still done before anything else in ehci_pci_resume().
Well, it's there (actually the problem occurs in vanilla 2.6.15-rc2-mm1 that
contains the patch). Do you mean it should go before the
if (readl(&ehci->regs->configured_flag) != FLAG_CF)
goto restart;
thing?
> It may be worth following it with a memory barrier actually... just in case
> (due to the absence of locks in that area).
wmb()?
Rafael
^ permalink raw reply
* Trouble getting Compact Flash IDE Interface to PPC440GP working
From: Gregg Nemas @ 2005-11-24 19:49 UTC (permalink / raw)
To: linuxppc-embedded
I have a PPC440GP-based CPU board that has a compact flash connected
to the peripheral bus in so-called "True IDE" mode. I am able to read
and write to the device using u-boot, and now I am trying to get it
working with linux 2.6.
The connection is like this:
CF A0..A2 =3D> PPC440 A30..A28 (ppc A31 not used for 16-bit bus)
CF D0..D15 =3D> PPC440 D15..D0
CF INTRQ =3D> PPC440 IRQ0 (GPIO0)
The peripheral bus is configured for 16-bit wide accesses.
I set the offsets passed to ide_setup_ports as follows:
#define CF_HD_DATA 0x00
#define CF_HD_ERROR 0x03 /* see err-bits */
#define CF_HD_NSECTOR 0x05 /* nr of sectors to read/write */
#define CF_HD_SECTOR 0x07 /* starting sector */
#define CF_HD_LCYL 0x09 /* starting cylinder */
#define CF_HD_HCYL 0x0b /* high byte of starting cyl */
#define CF_HD_SELECT 0x0d /* 101dhhhh, d=3Ddrive, hhhh=3Dhea=
d */
#define CF_HD_STATUS 0x0f /* see status-bits */
#define CF_HD_CONTROL 0x0010000d /* control/altstatus */
In order to get this working with u-boot, I had to endian swap all
16-bit data register accesses. I found that I had to do the same thing
in the ata_input_data and ata_output_data functions in ide-iops.c file
in linux before it would correctly identify the drive. I don't
understand why I have to do this in either place, given the
connections I described above, but it seems to be required.
After doing this, I get the following at bootup:
>Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
>ide: Assuming 50MHz system bus speed for PIO modes; override with
idebus=3Dxx
>ide0: CF IDE interface
>Probing IDE interface ide0...
>hda: SanDisk SDCFJ-128, CFA DISK drive
>ide0 at 0xd1080000-0xd1080007,0xd118000d on irq 23
>hda: max request size: 128KiB
>hda: 250880 sectors (128 MB) w/1KiB Cache, CHS=3D980/8/32
>hda: cache flushes not supported
> hda: unknown partition table
I partitioned the drive using debian linux workstation with a pair of
type 83 partitions, and added a root file system to one of them. I can
see all this from u-boot, and can even load the kernel from it. I am
lost as to where to proceed to figure out why the kernel is having
trouble.
The other problem I am having is that after booting up, any attempt to
access /dev/hda using fdisk results in fdisk hanging, and "lost
interrupt" messages appearing on the console. If I look at
/proc/interrupts, it shows that 11 interrupts have occurred on
interrupt number 23. I have this set to level senstitive, positive
polarity.
Can someone offer some guidance?
Thanks.
Gregg
^ permalink raw reply
* Re: [PATCH] Save NVGPRS in 32-bit signal frame
From: David Woodhouse @ 2005-11-24 17:36 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In-Reply-To: <1132836700.11921.58.camel@baythorne.infradead.org>
On Thu, 2005-11-24 at 12:51 +0000, David Woodhouse wrote:
> Somehow this one slipped through the cracks; when we ended up in
> do_signal() on a 32-bit kernel but without having the caller-saved
> registers into the regs, we didn't set the TIF_SAVE_NVGPRS flag to
> ensure they got saved later.
Oh, and if we actually set the flag, then we fairly quickly find out
that I was a bit overzealous in copying code from entry_64.S ... :)
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 8fed953..036b71d 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -368,7 +368,7 @@ save_user_nvgprs_cont:
b 6b
save_user_nvgprs:
- ld r8,TI_SIGFRAME(r12)
+ lwz r8,TI_SIGFRAME(r12)
.macro savewords start, end
1: stw \start,4*(\start)(r8)
@@ -386,11 +386,11 @@ save_user_nvgprs:
save_user_nvgprs_fault:
li r3,11 /* SIGSEGV */
- ld r4,TI_TASK(r12)
+ lwz r4,TI_TASK(r12)
bl force_sigsegv
rlwinm r12,r1,0,0,(31-THREAD_SHIFT) /* current_thread_info() */
- ld r9,TI_FLAGS(r12)
+ lwz r9,TI_FLAGS(r12)
b save_user_nvgprs_cont
#ifdef SHOW_SYSCALLS
--
dwmw2
^ permalink raw reply related
* Re: [PATCH] powerpc: serial port discovery
From: David Woodhouse @ 2005-11-24 17:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc64-dev, linuxppc-dev list
In-Reply-To: <1132634960.26560.133.camel@gaston>
On Tue, 2005-11-22 at 15:49 +1100, Benjamin Herrenschmidt wrote:
> This moves the discovery of legacy serial ports to a separate file,
> makes it common to ppc32 and ppc64, and reworks it to use the new OF
> address translators to get to the ports early. This new version can also
> detect some PCI serial cards using legacy chips and will probably match
> those discovered port with the default console choice.
This makes it deal with the fact that the Pegasos firmware reports that
its clock frequency is zero...
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/arch/powerpc/kernel/legacy_serial.c b/arch/powerpc/kernel/legacy_serial.c
index 28ad50e..7a685ca 100644
--- a/arch/powerpc/kernel/legacy_serial.c
+++ b/arch/powerpc/kernel/legacy_serial.c
@@ -43,7 +43,10 @@ static int __init add_legacy_port(struct
/* get clock freq. if present */
clk = (u32 *)get_property(np, "clock-frequency", NULL);
- clock = clk ? *clk : BASE_BAUD * 16;
+ if (clk && *clk)
+ clock = *clk;
+ else
+ clock = BASE_BAUD * 16;
/* get default speed if present */
spd = (u32 *)get_property(np, "current-speed", NULL);
--
dwmw2
^ permalink raw reply related
* Re: [PATCH] Fix USB suspend/resume crasher
From: Arkadiusz Miskiewicz @ 2005-11-24 16:52 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <1132715288.26560.262.camel@gaston>
On Wednesday 23 November 2005 04:08, Benjamin Herrenschmidt wrote:
> This is my latest patch against current linus -git, it closes the IRQ
> race and makes various other OHCI & EHCI code path safer vs.
> suspend/resume. I've been able to (finally !) successfully suspend and
> resume various Mac models, with or without USB mouse plugged, or
> plugging while asleep, or unplugging while asleep etc... all without a
> crash. There are still some races here or there in the USB code, but at
> least the main cause of crash is now fixes by this patch (access to a
> controller that has been suspended, due to either shared interrupts or
> other code path).
btw. what should happen if there are drivers which do not support=20
suspend/resume?
I'm using zd1211 wifi usb driver (which isn't state of art) from=20
http://zd1211.ath.cx/repos/trunk rev 39 and while trying to suspend on my=20
ibook g4 dec 2004 I'm getting this:
http://www.t17.ds.pwr.wroc.pl/~misiek/rozne/failed-sleep.jpg
After that the only thing I can do is turn the thing off and turn it back o=
n -=20
it just hangs. It would be nice if it just refuse to suspend or got things=
=20
back into sane state.
I'm using 2.6.15rc2git3 + both patches posted in this thread.
ps.
My usual suspend is:
/sbin/rmmod therm_adt746x
/sbin/rmmod zd1211
/sbin/rmmod usbmouse
/sbin/rmmod usbhid
/sbin/rmmod zd1211
/sbin/rmmod ehci-hcd
/sbin/rmmod ohci-hcd
/usr/sbin/snooze
(I guess that rmmod zd1211 should be enough now).
=2D-=20
Arkadiusz Mi=B6kiewicz PLD/Linux Team
http://www.t17.ds.pwr.wroc.pl/~misiek/ http://ftp.pld-linux.org/
^ permalink raw reply
* Re: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
From: Pantelis Antoniou @ 2005-11-24 12:48 UTC (permalink / raw)
To: Clement Fabien; +Cc: Kumar Gala, linuxppc-embedded
In-Reply-To: <9C1918067C3BC14C9C351C206D8A843701F7F876@rennsmail03.eu.thmulti.com>
Clement Fabien wrote:
> Hi,
>
> Some results: alignments are now respected but it seems that the method
> I took from linux 2.4 is more efficient in terms of memory consumption.
> I will provide a complete patch today with the same mechanism for
> rh_alloc_fixed.
>
> Fabien
>
>
>
Please don't bother.
The other method messes up the deallocations, you just have to live
with the wasted space.
With rh_alloc_fixed you're suppossed to know your alignment, the align
argument is bogus.
Pantelis
^ permalink raw reply
* Re: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
From: Pantelis Antoniou @ 2005-11-24 12:46 UTC (permalink / raw)
To: Clement Fabien; +Cc: Kumar Gala, linuxppc-embedded
In-Reply-To: <9C1918067C3BC14C9C351C206D8A843701F54B1D@rennsmail03.eu.thmulti.com>
[-- Attachment #1: Type: text/plain, Size: 463 bytes --]
Clement Fabien wrote:
> Here is a patch that builds.
>
>
> -----Original Message-----
> From: Pantelis Antoniou [mailto:panto@intracom.gr]
> Sent: jeudi 24 novembre 2005 12:04
> To: Clement Fabien; Kumar Gala; Marcelo Tosatti; linuxppc-embedded
> Subject: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
>
> Hi all.
>
> Alignments are currently handled bogusly for cpm2.
>
> Please test.
>
> Regards
>
> Pantelis
>
>
>
Updated patch....
[-- Attachment #2: cpm2-dpalloc.patch --]
[-- Type: text/x-patch, Size: 4160 bytes --]
diff --git a/arch/ppc/lib/rheap.c b/arch/ppc/lib/rheap.c
--- a/arch/ppc/lib/rheap.c
+++ b/arch/ppc/lib/rheap.c
@@ -425,17 +425,21 @@ void *rh_detach_region(rh_info_t * info,
return (void *)s;
}
-void *rh_alloc(rh_info_t * info, int size, const char *owner)
+void *rh_alloc_align(rh_info_t * info, int size, int alignment, const char *owner)
{
struct list_head *l;
rh_block_t *blk;
rh_block_t *newblk;
void *start;
- /* Validate size */
- if (size <= 0)
+ /* Validate size, (must be power of two) */
+ if (size <= 0 || (alignment & (alignment - 1)) != 0)
return ERR_PTR(-EINVAL);
+ /* given alignment larger that default rheap alignment */
+ if (alignment > info->alignment)
+ size += alignment - 1;
+
/* Align to configured alignment */
size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
@@ -478,9 +482,21 @@ void *rh_alloc(rh_info_t * info, int siz
attach_taken_block(info, newblk);
+ /* for larger alignment return fixed up pointer */
+ /* this is no problem with the deallocator since */
+ /* we scan for pointers that lie in the blocks */
+ if (alignment > info->alignment)
+ start = (void *)(((unsigned long)start + alignment - 1) &
+ ~(alignment - 1));
+
return start;
}
+void *rh_alloc(rh_info_t * info, int size, const char *owner)
+{
+ return rh_alloc_align(info, size, info->alignment, owner);
+}
+
/* allocate at precisely the given address */
void *rh_alloc_fixed(rh_info_t * info, void *start, int size, const char *owner)
{
diff --git a/arch/ppc/syslib/cpm2_common.c b/arch/ppc/syslib/cpm2_common.c
--- a/arch/ppc/syslib/cpm2_common.c
+++ b/arch/ppc/syslib/cpm2_common.c
@@ -148,8 +148,7 @@ uint cpm_dpalloc(uint size, uint align)
unsigned long flags;
spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
- start = rh_alloc(&cpm_dpmem_info, size, "commproc");
+ start = rh_alloc_align(&cpm_dpmem_info, size, align, "commproc");
spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
return (uint)start;
@@ -170,13 +169,12 @@ int cpm_dpfree(uint offset)
EXPORT_SYMBOL(cpm_dpfree);
/* not sure if this is ever needed */
-uint cpm_dpalloc_fixed(uint offset, uint size, uint align)
+uint cpm_dpalloc_fixed(uint offset, uint size)
{
void *start;
unsigned long flags;
spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
start = rh_alloc_fixed(&cpm_dpmem_info, (void *)offset, size, "commproc");
spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
diff --git a/include/asm-ppc/commproc.h b/include/asm-ppc/commproc.h
--- a/include/asm-ppc/commproc.h
+++ b/include/asm-ppc/commproc.h
@@ -74,7 +74,7 @@ static inline long IS_DPERR(const uint o
extern cpm8xx_t *cpmp; /* Pointer to comm processor */
extern uint cpm_dpalloc(uint size, uint align);
extern int cpm_dpfree(uint offset);
-extern uint cpm_dpalloc_fixed(uint offset, uint size, uint align);
+extern uint cpm_dpalloc_fixed(uint offset, uint size);
extern void cpm_dpdump(void);
extern void *cpm_dpram_addr(uint offset);
extern void cpm_setbrg(uint brg, uint rate);
diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
--- a/include/asm-ppc/cpm2.h
+++ b/include/asm-ppc/cpm2.h
@@ -112,7 +112,7 @@ extern cpm_cpm2_t *cpmp; /* Pointer to
extern uint cpm_dpalloc(uint size, uint align);
extern int cpm_dpfree(uint offset);
-extern uint cpm_dpalloc_fixed(uint offset, uint size, uint align);
+extern uint cpm_dpalloc_fixed(uint offset, uint size);
extern void cpm_dpdump(void);
extern void *cpm_dpram_addr(uint offset);
extern void cpm_setbrg(uint brg, uint rate);
diff --git a/include/asm-ppc/rheap.h b/include/asm-ppc/rheap.h
--- a/include/asm-ppc/rheap.h
+++ b/include/asm-ppc/rheap.h
@@ -62,6 +62,10 @@ extern int rh_attach_region(rh_info_t *
/* Detach a free region */
extern void *rh_detach_region(rh_info_t * info, void *start, int size);
+/* Allocate the given size from the remote heap (with alignment) */
+extern void *rh_alloc_align(rh_info_t * info, int size, int alignment,
+ const char *owner);
+
/* Allocate the given size from the remote heap */
extern void *rh_alloc(rh_info_t * info, int size, const char *owner);
^ permalink raw reply
* RE: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
From: Clement Fabien @ 2005-11-24 12:51 UTC (permalink / raw)
To: Clement Fabien, Pantelis Antoniou, Kumar Gala, Marcelo Tosatti,
linuxppc-embedded
Hi,
Some results: alignments are now respected but it seems that the method
I took from linux 2.4 is more efficient in terms of memory consumption.
I will provide a complete patch today with the same mechanism for
rh_alloc_fixed.
Fabien
Allocation method with offset (patch from myself)
rh_alloc - Required size =3D 0040, align =3D 0008
rh_alloc - Block size =3D 3F80, start =3D 00000080 - Off =3D 0000
rh_alloc - Alloc size =3D 0040, start =3D 00000080
rh_alloc - Required size =3D 0008, align =3D 0010
rh_alloc - Block size =3D 3F40, start =3D 000000c0 - Off =3D 0000
rh_alloc - Alloc size =3D 0010, start =3D 000000c0
rh_alloc - Required size =3D 1800, align =3D 0020
rh_alloc - Block size =3D 3F30, start =3D 000000d0 - Off =3D 0010
rh_alloc - Alloc size =3D 1810, start =3D 000000e0
rh_alloc - Required size =3D 0108, align =3D 0040
rh_alloc - Block size =3D 2720, start =3D 000018e0 - Off =3D 0020
rh_alloc - Alloc size =3D 0160, start =3D 00001900
rh_alloc - Required size =3D 0040, align =3D 0010
rh_alloc - Block size =3D 25C0, start =3D 00001a40 - Off =3D 0000
rh_alloc - Alloc size =3D 0040, start =3D 00001a40
rh_alloc - Required size =3D 0020, align =3D 0020
rh_alloc - Block size =3D 2580, start =3D 00001a80 - Off =3D 0000
rh_alloc - Alloc size =3D 0020, start =3D 00001a80
rh_alloc - Required size =3D 0010, align =3D 0010
rh_alloc - Block size =3D 2560, start =3D 00001aa0 - Off =3D 0000
rh_alloc - Alloc size =3D 0010, start =3D 00001aa0
rh_alloc - Required size =3D 000C, align =3D 0040
rh_alloc - Block size =3D 2550, start =3D 00001ab0 - Off =3D 0010
rh_alloc - Alloc size =3D 0050, start =3D 00001ac0
Allocation method without offset (Patch from Pantelis)
rh_alloc - Required size =3D 0040, align =3D 0008
rh_alloc - Block size =3D 3F80, start =3D 00000080
rh_alloc - Alloc size =3D 0047, start =3D 00000080
rh_alloc - Required size =3D 0008, align =3D 0010
rh_alloc - Block size =3D 3F39, start =3D 000000c7
rh_alloc - Alloc size =3D 0017, start =3D 000000d0
rh_alloc - Required size =3D 1800, align =3D 0020
rh_alloc - Block size =3D 3F22, start =3D 000000de
rh_alloc - Alloc size =3D 181F, start =3D 000000e0
rh_alloc - Required size =3D 0108, align =3D 0040
rh_alloc - Block size =3D 2703, start =3D 000018fd
rh_alloc - Alloc size =3D 0147, start =3D 00001900
rh_alloc - Required size =3D 0040, align =3D 0010
rh_alloc - Block size =3D 25BC, start =3D 00001a44
rh_alloc - Alloc size =3D 004F, start =3D 00001a50
rh_alloc - Required size =3D 0020, align =3D 0020
rh_alloc - Block size =3D 256D, start =3D 00001a93
rh_alloc - Alloc size =3D 003F, start =3D 00001aa0
rh_alloc - Required size =3D 0010, align =3D 0010
rh_alloc - Block size =3D 252E, start =3D 00001ad2
rh_alloc - Alloc size =3D 001F, start =3D 00001ae0
rh_alloc - Required size =3D 000C, align =3D 0040
rh_alloc - Block size =3D 250F, start =3D 00001af1
rh_alloc - Alloc size =3D 004B, start =3D 00001b00
-----Original Message-----
From: linuxppc-embedded-bounces@ozlabs.org
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of Clement
Fabien
Sent: jeudi 24 novembre 2005 12:26
To: Pantelis Antoniou; Kumar Gala; Marcelo Tosatti; linuxppc-embedded
Subject: RE: [PATCH] CPM2: Fix totally bogus alignment handing of
dpalloc
Here is a patch that builds.
-----Original Message-----
From: Pantelis Antoniou [mailto:panto@intracom.gr]=20
Sent: jeudi 24 novembre 2005 12:04
To: Clement Fabien; Kumar Gala; Marcelo Tosatti; linuxppc-embedded
Subject: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
Hi all.
Alignments are currently handled bogusly for cpm2.
Please test.
Regards
Pantelis
^ permalink raw reply
* [PATCH] Save NVGPRS in 32-bit signal frame
From: David Woodhouse @ 2005-11-24 12:51 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Somehow this one slipped through the cracks; when we ended up in
do_signal() on a 32-bit kernel but without having the caller-saved
registers into the regs, we didn't set the TIF_SAVE_NVGPRS flag to
ensure they got saved later.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -219,6 +218,15 @@ static inline int get_old_sigaction(stru
static inline int save_general_regs(struct pt_regs *regs,
struct mcontext __user *frame)
{
+ if (!FULL_REGS(regs)) {
+ /* Zero out the unsaved GPRs to avoid information
+ leak, and set TIF_SAVE_NVGPRS to ensure that the
+ registers do actually get saved later. */
+ memset(®s->gpr[14], 0, 18 * sizeof(unsigned long));
+ current_thread_info()->nvgprs_frame = &frame->mc_gregs;
+ set_thread_flag(TIF_SAVE_NVGPRS);
+ }
+
return __copy_to_user(&frame->mc_gregs, regs, GP_REGS_SIZE);
}
--
dwmw2
^ permalink raw reply
* Re: 8260ADS Ethernet compilation
From: Wolfgang Denk @ 2005-11-24 11:28 UTC (permalink / raw)
To: pritha.bhattacharya; +Cc: linuxppc-embedded
In-Reply-To: <OF8DE1E835.620AF9B1-ON652570C3.001D9C79-652570C3.003087C6@tcs.com>
In message <OF8DE1E835.620AF9B1-ON652570C3.001D9C79-652570C3.003087C6@tcs.com> you wrote:
>
> I have a custom board built around MPC8260ADS. I am trying to cross
I understand that this means you also use a custom board
configuration, right?
> m8260_setup.c:62: error: `bd_t' undeclared here (not in a function)
...
> m8260_setup.c:120: error: `binfo' undeclared (first use in this function)
...
> m8260_setup.c:229: error: `NR_SIU_INTS' undeclared (first use in this
> function)
Seems your port and/or board configuration is incomplete / broken.
> 1.I understand that bd_t is a board information structure. Which is
> defined in linux/include/asm-ppc/ppcboot.h. Somehow it is not visible to
> the linux/arch/kernel/m8260_setup.c I dont know what I may be doing
> wrong.
Bad configuration...
> 2.Similarly NR_SIU_INTS, which is defined in linux/include/asm/irq.h is
> also not visible.
Bad configuration...
> 3.I did not understand what __res[ ] is. I came across somewhere that it
> is the residual information which the bootloader is supposed to hand over
> to the linux. How would that be done. I could not identify in the code
> where __res is populated.
Use "grep"; __res points to the board information structure.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"The more data I punch in this card, the lighter it becomes, and the
lower the mailing cost."
- Stan Kelly-Bootle, "The Devil's DP Dictionary"
^ permalink raw reply
* RE: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
From: Clement Fabien @ 2005-11-24 11:25 UTC (permalink / raw)
To: Pantelis Antoniou, Kumar Gala, Marcelo Tosatti, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 400 bytes --]
Here is a patch that builds.
-----Original Message-----
From: Pantelis Antoniou [mailto:panto@intracom.gr]
Sent: jeudi 24 novembre 2005 12:04
To: Clement Fabien; Kumar Gala; Marcelo Tosatti; linuxppc-embedded
Subject: [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
Hi all.
Alignments are currently handled bogusly for cpm2.
Please test.
Regards
Pantelis
[-- Attachment #2: cpm2-dpalloc_compiling.patch --]
[-- Type: application/octet-stream, Size: 2340 bytes --]
? arch/ppc/lib/.built-in.o.cmd
? arch/ppc/lib/.checksum.o.cmd
? arch/ppc/lib/.dec_and_lock.o.cmd
? arch/ppc/lib/.div64.o.cmd
? arch/ppc/lib/.rheap.o.cmd
? arch/ppc/lib/.strcase.o.cmd
? arch/ppc/lib/.string.o.cmd
? arch/ppc/lib/myrheap.c
? arch/ppc/lib/rheap.diff
? arch/ppc/lib/rheap_debug.c
Index: arch/ppc/lib/rheap.c
===================================================================
RCS file: /home/conf/tnp/linuxppc/linux/arch/ppc/lib/rheap.c,v
retrieving revision 1.1.1.1
diff -b -u -r1.1.1.1 rheap.c
--- arch/ppc/lib/rheap.c 6 Dec 2004 16:15:22 -0000 1.1.1.1
+++ arch/ppc/lib/rheap.c 24 Nov 2005 11:24:41 -0000
@@ -425,17 +425,22 @@
return (void *)s;
}
-void *rh_alloc(rh_info_t * info, int size, const char *owner)
+void *rh_alloc_align(rh_info_t * info, int size, int alignment, const char *owner)
{
struct list_head *l;
rh_block_t *blk;
rh_block_t *newblk;
void *start;
- /* Validate size */
- if (size <= 0)
+ /* Validate size, (must be power of two) */
+ printk(KERN_INFO"rh_alloc - Required size = %04X, align = %04X\n",size,alignment);
+ if (size <= 0 || (alignment & (alignment - 1)) != 0)
return ERR_PTR(-EINVAL);
+ /* given alignment larger that default rheap alignment */
+ if (alignment > info->alignment)
+ size += alignment - 1;
+
/* Align to configured alignment */
size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
@@ -453,6 +458,8 @@
if (blk == NULL)
return ERR_PTR(-ENOMEM);
+ printk(KERN_INFO"rh_alloc - Block size = %04X, start = %p\n",blk->size,blk->start);
+
/* Just fits */
if (blk->size == size) {
/* Move from free list to taken list */
@@ -478,9 +485,23 @@
attach_taken_block(info, newblk);
+ /* for larger alignment return fixed up pointer */
+ /* this is no problem with the deallocator since */
+ /* we scan for pointers that lie in the blocks */
+ if (alignment > info->alignment)
+ start = (void *)(((unsigned long)start + alignment - 1) &
+ ~(alignment - 1));
+
+ printk(KERN_INFO"rh_alloc - Alloc size = %04X, start = %p\n",size,start);
+
return start;
}
+void *rh_alloc(rh_info_t * info, int size, const char *owner)
+{
+ return rh_alloc_align(info, size, info->alignment, owner);
+}
+
/* allocate at precisely the given address */
void *rh_alloc_fixed(rh_info_t * info, void *start, int size, const char *owner)
{
^ permalink raw reply
* Re: [PATCH] I2C: Add I2C support for the MPC8260
From: Christoph Hellwig @ 2005-11-24 11:17 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev, lm-sensors
In-Reply-To: <AHEILKONAKAEJPHNMOPNEEMNCDAA.hs@denx.de>
> + * Release 0.1
please don't put such versaison comments in, the SCM has the history.
> +#include <linux/config.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/sched.h>
> +#include <linux/init.h>
> +#include <linux/pci.h>
> +#include <asm/io.h>
> +#include <linux/fsl_devices.h>
> +#include <linux/i2c.h>
> +#include <linux/interrupt.h>
> +#include <linux/delay.h>
> +#include <asm/immap_cpm2.h>
> +#include <asm/mpc8260.h>
> +#include <asm/cpm2.h>
> +
> +#include <linux/i2c-algo-cpm2.h>
> +#include <linux/platform_device.h>
<asm/*.h> always after <linux/*.h> please.
> +#define CPM_MAX_READ 513
> +
> +static wait_queue_head_t iic_wait;
> +static ushort r_tbase, r_rbase;
> +
> +int cpm_scan = 0;
> +int cpm_debug = 0;
> +
> +struct mpc_i2c {
> + u32 interrupt;
> + wait_queue_head_t queue;
> + struct i2c_adapter adap;
> + int irq;
> + u32 flags;
> + struct i2c_algo_cpm2_data *data;
> +};
> +
> +static struct i2c_algo_cpm2_data cpm2_data;
> +
> +static void
> +cpm2_iic_init(struct i2c_algo_cpm2_data *data)
> +{
> + volatile cpm_cpm2_t *cp;
> + volatile cpm2_map_t *immap;
> +
> + cp = cpmp; /* Get pointer to Communication Processor */
> + immap = (cpm2_map_t *)CPM_MAP_ADDR; /* and to internal registers */
> +
> + *(ushort *)(&immap->im_dprambase[PROFF_I2C_BASE]) = PROFF_I2C;
> + data->iip = (iic_t *)&immap->im_dprambase[PROFF_I2C];
Please stop volatile abuse and use ioremap & friends to properly to access
I/O memory.
> + /* Chip bug, set enable here */
> + local_irq_save(flags);
> + i2c->i2c_i2cmr = 0x13; /* Enable some interupts */
> + i2c->i2c_i2cer = 0xff;
> + i2c->i2c_i2mod |= 1; /* Enable */
> + i2c->i2c_i2com = 0x81; /* Start master */
> +
> + /* Wait for IIC transfer */
> + interruptible_sleep_on(&iic_wait);
never use interruptible_sleep_on() and the local_irq_save usage here is
bogus aswell, please use proper irq disabling spinlocks and make sure
you don't sleep with interrupts disabled.
> + if (cpm_debug) {
> + int u;
> + for (u = 0; u < count; u++) {
> + printk(KERN_DEBUG "buf[%d] = 0x%x\n", u, buf[u]);
> + }
> + }
broken indentation.
> + if (cpm_debug)
> + printk(KERN_DEBUG "i2c-cpm2.o: wrote %d\n", ret);
could you please use dev_dbg() instead of all this if (cpm_debug) mess?
> + if (ret < pmsg->len ) {
> + return (ret<0) ? ret : -EREMOTEIO;
indentation problems again.
> + int result = 0;
> + struct mpc_i2c *i2c;
> + struct platform_device *pdev = to_platform_device(device);
> + struct fsl_i2c_platform_data *pdata;
> +
> + pdata = (struct fsl_i2c_platform_data *) pdev->dev.platform_data;
generally no need to cast here. Also please use platform_get_drvdata()
> +
> + if (!(i2c = kmalloc(sizeof(*i2c), GFP_KERNEL))) {
> + return -ENOMEM;
> + }
> + memset(i2c, 0, sizeof(*i2c));
please use kzalloc()
> + if ((result = i2c_add_adapter(&i2c->adap)) < 0) {
please split such lines into two.
> + fail_add:
goto lables should either be in column 0 or 1 (and that consitantly
through a source file)
^ permalink raw reply
* [PATCH] CPM2: Fix totally bogus alignment handing of dpalloc
From: Pantelis Antoniou @ 2005-11-24 11:03 UTC (permalink / raw)
To: Clement Fabien, Kumar Gala, Marcelo Tosatti, linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 94 bytes --]
Hi all.
Alignments are currently handled bogusly for cpm2.
Please test.
Regards
Pantelis
[-- Attachment #2: cpm2-dpalloc.patch --]
[-- Type: text/x-patch, Size: 4155 bytes --]
diff --git a/arch/ppc/lib/rheap.c b/arch/ppc/lib/rheap.c
--- a/arch/ppc/lib/rheap.c
+++ b/arch/ppc/lib/rheap.c
@@ -425,17 +425,21 @@ void *rh_detach_region(rh_info_t * info,
return (void *)s;
}
-void *rh_alloc(rh_info_t * info, int size, const char *owner)
+void *rh_alloc(rh_info_t * info, int size, int alignment, const char *owner)
{
struct list_head *l;
rh_block_t *blk;
rh_block_t *newblk;
void *start;
- /* Validate size */
- if (size <= 0)
+ /* Validate size, (must be power of two) */
+ if (size <= 0 || (alignment & (alignment - 1)) != 0)
return ERR_PTR(-EINVAL);
+ /* given alignment larger that default rheap alignment */
+ if (alignment > info->alignment)
+ size += alignement - 1;
+
/* Align to configured alignment */
size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
@@ -478,9 +482,21 @@ void *rh_alloc(rh_info_t * info, int siz
attach_taken_block(info, newblk);
+ /* for larger alignment return fixed up pointer */
+ /* this is no problem with the deallocator since */
+ /* we scan for pointers that lie in the blocks */
+ if (alignment > info->alignment)
+ start = (void *)(((unsigned long)start + alignment - 1) &
+ ~(alignment - 1));
+
return start;
}
+void *rh_alloc(rh_info_t * info, int size, const char *owner)
+{
+ return rh_alloc_align(info, size, info->alignment, owner);
+}
+
/* allocate at precisely the given address */
void *rh_alloc_fixed(rh_info_t * info, void *start, int size, const char *owner)
{
diff --git a/arch/ppc/syslib/cpm2_common.c b/arch/ppc/syslib/cpm2_common.c
--- a/arch/ppc/syslib/cpm2_common.c
+++ b/arch/ppc/syslib/cpm2_common.c
@@ -148,8 +148,7 @@ uint cpm_dpalloc(uint size, uint align)
unsigned long flags;
spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
- start = rh_alloc(&cpm_dpmem_info, size, "commproc");
+ start = rh_alloc_align(&cpm_dpmem_info, size, align, "commproc");
spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
return (uint)start;
@@ -170,13 +169,12 @@ int cpm_dpfree(uint offset)
EXPORT_SYMBOL(cpm_dpfree);
/* not sure if this is ever needed */
-uint cpm_dpalloc_fixed(uint offset, uint size, uint align)
+uint cpm_dpalloc_fixed(uint offset, uint size)
{
void *start;
unsigned long flags;
spin_lock_irqsave(&cpm_dpmem_lock, flags);
- cpm_dpmem_info.alignment = align;
start = rh_alloc_fixed(&cpm_dpmem_info, (void *)offset, size, "commproc");
spin_unlock_irqrestore(&cpm_dpmem_lock, flags);
diff --git a/include/asm-ppc/commproc.h b/include/asm-ppc/commproc.h
--- a/include/asm-ppc/commproc.h
+++ b/include/asm-ppc/commproc.h
@@ -74,7 +74,7 @@ static inline long IS_DPERR(const uint o
extern cpm8xx_t *cpmp; /* Pointer to comm processor */
extern uint cpm_dpalloc(uint size, uint align);
extern int cpm_dpfree(uint offset);
-extern uint cpm_dpalloc_fixed(uint offset, uint size, uint align);
+extern uint cpm_dpalloc_fixed(uint offset, uint size);
extern void cpm_dpdump(void);
extern void *cpm_dpram_addr(uint offset);
extern void cpm_setbrg(uint brg, uint rate);
diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
--- a/include/asm-ppc/cpm2.h
+++ b/include/asm-ppc/cpm2.h
@@ -112,7 +112,7 @@ extern cpm_cpm2_t *cpmp; /* Pointer to
extern uint cpm_dpalloc(uint size, uint align);
extern int cpm_dpfree(uint offset);
-extern uint cpm_dpalloc_fixed(uint offset, uint size, uint align);
+extern uint cpm_dpalloc_fixed(uint offset, uint size);
extern void cpm_dpdump(void);
extern void *cpm_dpram_addr(uint offset);
extern void cpm_setbrg(uint brg, uint rate);
diff --git a/include/asm-ppc/rheap.h b/include/asm-ppc/rheap.h
--- a/include/asm-ppc/rheap.h
+++ b/include/asm-ppc/rheap.h
@@ -62,6 +62,10 @@ extern int rh_attach_region(rh_info_t *
/* Detach a free region */
extern void *rh_detach_region(rh_info_t * info, void *start, int size);
+/* Allocate the given size from the remote heap (with alignment) */
+extern void *rh_alloc_align(rh_info_t * info, int size, int alignment,
+ const char *owner);
+
/* Allocate the given size from the remote heap */
extern void *rh_alloc(rh_info_t * info, int size, const char *owner);
^ permalink raw reply
* 8260ADS Ethernet compilation
From: pritha.bhattacharya @ 2005-11-24 8:50 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 3244 bytes --]
Hi,
I have a custom board built around MPC8260ADS. I am trying to cross
compile linux 2.4.25 for ethernet on FCC1 connected to LXT971 for the
board.
Installed the toolchains from Denx site. Built linux for ppc architecture.
Then for ethernet, after selecting the proper options from the menuconfig,
while compiling the source code gives the following error:
m8260_setup.c:62: error: `bd_t' undeclared here (not in a function)
m8260_setup.c:106: warning: `abort' was declared `extern' and later
`static'
m8260_setup.c: In function `m8260_calibrate_decr':
m8260_setup.c:120: error: `bd_t' undeclared (first use in this function)
m8260_setup.c:120: error: (Each undeclared identifier is reported only
once
m8260_setup.c:120: error: for each function it appears in.)
m8260_setup.c:120: error: `binfo' undeclared (first use in this function)
m8260_setup.c:120: error: parse error before ')' token
m8260_setup.c: In function `m8260_restart':
m8260_setup.c:163: error: parse error before '*' token
m8260_setup.c:163: warning: function declaration isn't a prototype
m8260_setup.c: In function `m8260_show_percpuinfo':
m8260_setup.c:201: error: `bd_t' undeclared (first use in this function)
m8260_setup.c:201: error: `bp' undeclared (first use in this function)
m8260_setup.c:203: error: parse error before ')' token
m8260_setup.c: In function `m8260_init_IRQ':
m8260_setup.c:229: error: `NR_SIU_INTS' undeclared (first use in this
function)
m8260_setup.c: In function `m8260_find_end_of_memory':
m8260_setup.c:261: error: `bd_t' undeclared (first use in this function)
m8260_setup.c:261: error: `binfo' undeclared (first use in this function)
m8260_setup.c:264: error: parse error before ')' token
m8260_setup.c:262: warning: unused variable `__res'
m8260_setup.c: In function `platform_init':
m8260_setup.c:288: error: `bd_t' undeclared (first use in this function)
m8260_setup.c: At top level:
m8260_setup.c:106: warning: `abort' defined but not used
make[1]: *** [m8260_setup.o] Error 1
make: *** [_dir_arch/ppc/kernel] Error 2
1.I understand that bd_t is a board information structure. Which is
defined in linux/include/asm-ppc/ppcboot.h. Somehow it is not visible to
the linux/arch/kernel/m8260_setup.c I dont know what I may be doing
wrong.
2.Similarly NR_SIU_INTS, which is defined in linux/include/asm/irq.h is
also not visible.
the third query is not on compilation errors:
3.I did not understand what __res[ ] is. I came across somewhere that it
is the residual information which the bootloader is supposed to hand over
to the linux. How would that be done. I could not identify in the code
where __res is populated.
Would be of great help to get your suggestions.
Thanks & Regards
Pritha
Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you
[-- Attachment #2: Type: text/html, Size: 4917 bytes --]
^ permalink raw reply
* Re: [Patch] CPM allocation mechanism in 2.6.13
From: Pantelis Antoniou @ 2005-11-24 10:25 UTC (permalink / raw)
To: Clement Fabien; +Cc: linuxppc-embedded
In-Reply-To: <9C1918067C3BC14C9C351C206D8A843701F54B1A@rennsmail03.eu.thmulti.com>
Clement Fabien wrote:
> Hello
>
> I found out that the rh_alloc mechanism used in 2.6.xx does not always
> provide aligned blocks.
> I'm using a 8275 and try to start the SAR driver of Alex Zeffert.
>
> Here is a trace of allocations at linux startup of the code that gives
> me problems:
>
> <...>
> rh_alloc Required size = 8, align = 16
> rh_alloc Block available, blk->size = 00003f40 - Start = 000000c0
> rh_alloc Alloc size = 16, align = 16 - Start = 000000c0
>
> rh_alloc Required size = 6144, align = 32
> rh_alloc Block available, blk->size = 00003f30 - Start = 000000d0
> rh_alloc Alloc size = 6144, align = 32 - Start = 000000d0
> (!!!! WRONG ALIGNMENT !!!!)
>
> rh_alloc Required size = 264, align = 64
> rh_alloc Block available, blk->size = 00002730 - Start = 000018d0
> rh_alloc Alloc size = 320, align = 64 - Start = 000018d0
> (!!!! WRONG ALIGNMENT !!!!)
>
> rh_alloc Required size = 64, align = 16
> rh_alloc Block available, blk->size = 000025f0 - Start = 00001a10
> rh_alloc Alloc size = 64, align = 16 - Start = 00001a10
> <...>
>
> If we observe rh_alloc (arch/ppc/lib/rheap.c) function
>
> The following line only ensures that there is enough space to perform
> alignment:
> 1. size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
>
> But with the block start modification mechanism you cannot ensure that
> the next block will be aligned :
> 2. blk->start = (int8_t *)blk->start + size;
>
> The allocation mechanism must take into account the starting address, as
> it was in Linux 2.4 following code (3. extracted from commproc.c)
> 3. off = ((p->start_addr + align_mask) & (~align_mask)) -
> p->start_addr;
>
> I've had an initial discussion with Pantelis who suggests that alignment
> shall be unique for this heap:
>
>
>>>Excuse me, how do you modify the rheap's alignment at runtime?
>>>The allocators prototype is:
>
>
>>>void *rh_alloc(rh_info_t * info, int size, const char *owner)
>
>
>>>I don't see an alignment parameter.
>
>
>>>If you are modifying info->alignment by hand before calling you can't
>
>
>>>possibly expect this to work.
>
>
>>>The alignment is fixed after the creation of the rheap.
>>>If you need specific alignment you do it like this.
>
>
>>>u8 *p = rh_alloc(info, size + (align - 1), "owner");
>
>
>>>p = (void *)((unsigned long)p + (align - 1) & ~(align - 1));
>
>
> So I guess the problem is in the usage of the function in kernel: it is
> initialized with 1 byte alignment (in cpm2_dpinit in
> arch/ppc/syslib/cpm2_common.c), then the cpm_dpalloc manipulates the
> alignment like this:
>
> 4. cpm_dpmem_info.alignment = align;
> start = rh_alloc(&cpm_dpmem_info, size, "commproc");
>
>
> I do not have an exact idea whether to modify cpm_dpalloc or rh_alloc.
> Can someone provide inputs on this subject?
>
> Please see also the patch I suggest to correct the rh_alloc function
>
> Regards
> Fabien Clement
>
I'm on it.
Regards
Pantelis
^ permalink raw reply
* Re: USB Keyboard Support
From: David Jander @ 2005-11-24 10:30 UTC (permalink / raw)
To: Igor Luri; +Cc: linuxppc-embedded
In-Reply-To: <43858855.8080304@fagorautomation.es>
On Thursday 24 November 2005 10:31, Igor Luri wrote:
> the first console argument defines where is stdout and the second
> console argument defines where is the stdout and stdin. With this
> configuration you can duplicate stdout, you can see the output on two
> devices, screen and serial line.
Wow. Everyday we learn something new ;-)
Sorry, and thanks for the tip!
Greetings,
--
David Jander
^ permalink raw reply
* [Patch] CPM allocation mechanism in 2.6.13
From: Clement Fabien @ 2005-11-24 10:26 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2819 bytes --]
Hello
I found out that the rh_alloc mechanism used in 2.6.xx does not always
provide aligned blocks.
I'm using a 8275 and try to start the SAR driver of Alex Zeffert.
Here is a trace of allocations at linux startup of the code that gives
me problems:
<...>
rh_alloc Required size = 8, align = 16
rh_alloc Block available, blk->size = 00003f40 - Start = 000000c0
rh_alloc Alloc size = 16, align = 16 - Start = 000000c0
rh_alloc Required size = 6144, align = 32
rh_alloc Block available, blk->size = 00003f30 - Start = 000000d0
rh_alloc Alloc size = 6144, align = 32 - Start = 000000d0
(!!!! WRONG ALIGNMENT !!!!)
rh_alloc Required size = 264, align = 64
rh_alloc Block available, blk->size = 00002730 - Start = 000018d0
rh_alloc Alloc size = 320, align = 64 - Start = 000018d0
(!!!! WRONG ALIGNMENT !!!!)
rh_alloc Required size = 64, align = 16
rh_alloc Block available, blk->size = 000025f0 - Start = 00001a10
rh_alloc Alloc size = 64, align = 16 - Start = 00001a10
<...>
If we observe rh_alloc (arch/ppc/lib/rheap.c) function
The following line only ensures that there is enough space to perform
alignment:
1. size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
But with the block start modification mechanism you cannot ensure that
the next block will be aligned :
2. blk->start = (int8_t *)blk->start + size;
The allocation mechanism must take into account the starting address, as
it was in Linux 2.4 following code (3. extracted from commproc.c)
3. off = ((p->start_addr + align_mask) & (~align_mask)) -
p->start_addr;
I've had an initial discussion with Pantelis who suggests that alignment
shall be unique for this heap:
>> Excuse me, how do you modify the rheap's alignment at runtime?
>> The allocators prototype is:
>> void *rh_alloc(rh_info_t * info, int size, const char *owner)
>> I don't see an alignment parameter.
>> If you are modifying info->alignment by hand before calling you can't
>> possibly expect this to work.
>> The alignment is fixed after the creation of the rheap.
>> If you need specific alignment you do it like this.
>> u8 *p = rh_alloc(info, size + (align - 1), "owner");
>> p = (void *)((unsigned long)p + (align - 1) & ~(align - 1));
So I guess the problem is in the usage of the function in kernel: it is
initialized with 1 byte alignment (in cpm2_dpinit in
arch/ppc/syslib/cpm2_common.c), then the cpm_dpalloc manipulates the
alignment like this:
4. cpm_dpmem_info.alignment = align;
start = rh_alloc(&cpm_dpmem_info, size, "commproc");
I do not have an exact idea whether to modify cpm_dpalloc or rh_alloc.
Can someone provide inputs on this subject?
Please see also the patch I suggest to correct the rh_alloc function
Regards
Fabien Clement
[-- Attachment #2: rheap.patch --]
[-- Type: application/octet-stream, Size: 1863 bytes --]
Index: arch/ppc/lib/rheap.c
===================================================================
RCS file: /home/conf/tnp/linuxppc/linux/arch/ppc/lib/rheap.c,v
retrieving revision 1.1.1.1
diff -b -u -r1.1.1.1 rheap.c
--- arch/ppc/lib/rheap.c 6 Dec 2004 16:15:22 -0000 1.1.1.1
+++ arch/ppc/lib/rheap.c 24 Nov 2005 09:42:37 -0000
@@ -431,13 +431,15 @@
rh_block_t *blk;
rh_block_t *newblk;
void *start;
+ unsigned int off;
+ unsigned int align_mask = (info->alignment - 1);
/* Validate size */
if (size <= 0)
return ERR_PTR(-EINVAL);
/* Align to configured alignment */
- size = (size + (info->alignment - 1)) & ~(info->alignment - 1);
+ size = (size + align_mask) & (~align_mask);
if (assure_empty(info, 1) < 0)
return ERR_PTR(-ENOMEM);
@@ -446,7 +448,11 @@
list_for_each(l, &info->free_list) {
blk = list_entry(l, rh_block_t, list);
if (size <= blk->size)
+ {
+ off = ((int)(blk->start + align_mask) & (~align_mask)) - (int)blk->start;
+ if (blk->size >= size + off)
break;
+ }
blk = NULL;
}
@@ -454,7 +460,7 @@
return ERR_PTR(-ENOMEM);
/* Just fits */
- if (blk->size == size) {
+ if (blk->size == (size + off)) {
/* Move from free list to taken list */
list_del(&blk->list);
blk->owner = owner;
@@ -462,21 +468,23 @@
attach_taken_block(info, blk);
- return start;
}
-
+ else
+ {
newblk = get_slot(info);
newblk->start = blk->start;
- newblk->size = size;
+ newblk->size = size + off;
newblk->owner = owner;
/* blk still in free list, with updated start, size */
- blk->start = (int8_t *)blk->start + size;
- blk->size -= size;
+ blk->start = (int8_t *)blk->start + size + off;
+ blk->size -= (size + off);
- start = newblk->start;
+ start = newblk->start + off;
attach_taken_block(info, newblk);
+ }
+
return start;
}
^ permalink raw reply
* Re: USB Keyboard Support
From: Igor Luri @ 2005-11-24 9:31 UTC (permalink / raw)
To: David Jander, linuxppc-embedded
In-Reply-To: <200511240925.21942.david.jander@protonic.nl>
David Jander wrote:
>>root=/dev/nfs rw ip=on console=tty console=ttyS0 init=/sbin/init
>>
>>
>
>I suppose putting two "console=" statements on the commandline doesn't do much
>more than just removing the first one.
>
>Greetings,
>
>
>
Dear David,
the first console argument defines where is stdout and the second
console argument defines where is the stdout and stdin. With this
configuration you can duplicate stdout, you can see the output on two
devices, screen and serial line.
Bye.
^ permalink raw reply
* Re: USB Keyboard Support
From: David Jander @ 2005-11-24 8:25 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4384921A.8010901@fagorautomation.es>
> root=/dev/nfs rw ip=on console=tty console=ttyS0 init=/sbin/init
I suppose putting two "console=" statements on the commandline doesn't do much
more than just removing the first one.
Greetings,
--
David Jander
^ permalink raw reply
* [PATCH] powerpc: Fix g5 build with xmon
From: Benjamin Herrenschmidt @ 2005-11-24 6:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev list
My previous patches inadvertently broke building a G5 kernel with
CONFIG_XMON enabled. This fixes it.
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Index: linux-serialfix/arch/powerpc/platforms/powermac/pic.c
===================================================================
--- linux-serialfix.orig/arch/powerpc/platforms/powermac/pic.c 2005-11-24 17:21:41.000000000 +1100
+++ linux-serialfix/arch/powerpc/platforms/powermac/pic.c 2005-11-24 17:36:07.000000000 +1100
@@ -459,7 +459,7 @@ void __init pmac_pic_init(void)
mpic_setup_cascade(irqctrler2->intrs[0].line,
pmac_u3_cascade, mpic2);
}
-#ifdef CONFIG_XMON
+#if defined(CONFIG_XMON) && defined(CONFIG_PPC32)
{
struct device_node* pswitch;
int nmi_irq;
@@ -471,7 +471,7 @@ void __init pmac_pic_init(void)
setup_irq(nmi_irq, &xmon_action);
}
}
-#endif /* CONFIG_XMON */
+#endif /* defined(CONFIG_XMON) && defined(CONFIG_PPC32) */
return;
}
irqctrler = NULL;
^ permalink raw reply
* Re: [PATCH] Fix USB suspend/resume crasher
From: Benjamin Herrenschmidt @ 2005-11-24 1:23 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Andrew Morton, Greg KH, linux-kernel, David Brownell,
linuxppc-dev list, Alan Stern
In-Reply-To: <200511240122.46125.rjw@sisk.pl>
> Unfortunately with this patch the EHCI controller in my box (Asus L5D,
> x86-64 kernel) does not resume from suspend. Appended is the relevant
> snippet from the serial console log (EHCI is the only device using IRQ #5).
Hrm... let me see... You are getting an interrupt for EHCI after it has
been resumed, so it should work.
/me double-checks the patch
> ehci_hcd 0000:00:02.2: lost power, restarting
Hrm... I can't find that line in the code...
/me rechecks with david's other patches
Ah ... I see it. There might have been some screwup between david's
patch and mine.
Make sure that
set_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags);
Is still done before anything else in ehci_pci_resume(). It may be worth
following it with a memory barrier actually... just in case (due to the
absence of locks in that area).
Ben.
^ permalink raw reply
* Re: [PATCH] Fix USB suspend/resume crasher
From: Rafael J. Wysocki @ 2005-11-24 0:22 UTC (permalink / raw)
To: linux-kernel
Cc: Andrew Morton, David Brownell, linuxppc-dev list, Greg KH,
Alan Stern
In-Reply-To: <1132715288.26560.262.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 5195 bytes --]
Hi,
On Wednesday, 23 of November 2005 04:08, Benjamin Herrenschmidt wrote:
> This is my latest patch against current linus -git, it closes the IRQ
> race and makes various other OHCI & EHCI code path safer vs.
> suspend/resume. I've been able to (finally !) successfully suspend and
> resume various Mac models, with or without USB mouse plugged, or
> plugging while asleep, or unplugging while asleep etc... all without a
> crash. There are still some races here or there in the USB code, but at
> least the main cause of crash is now fixes by this patch (access to a
> controller that has been suspended, due to either shared interrupts or
> other code path).
>
> I haven't fixed UHCI as I don't have any HW to test, though I hope I
> haven't broken it neither. Alan, I would appreciate if you could have a
> look.
>
> This patch applies on top of the patch that moves the PowerMac specific
> code out of ohci-pci.c to hcd-pci.c where it belongs. This patch isn't
> upstream yet for reasons I don't fully understand (why does USB stuffs
> has such a high latency for going upstream ?), I'm sending it as a reply
> to this email for completeness.
>
> Without this patch, you cannot reliably sleep/wakeup any recent Mac, and
> I suspect PCs have some more sneaky issues too (they don't frankly crash
> with machine checks because x86 tend to silently swallow PCI errors but
> that won't last afaik, at least PCI Express will blow up in those
> situations, but the USB code may still misbehave).
Unfortunately with this patch the EHCI controller in my box (Asus L5D,
x86-64 kernel) does not resume from suspend. Appended is the relevant
snippet from the serial console log (EHCI is the only device using IRQ #5).
Greetings,
Rafael
PM: Image restored successfully.
ohci_hcd 0000:00:02.0: PCI D0, from previous PCI D3
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LUS0] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:02.0 to 64
ohci_hcd 0000:00:02.1: PCI D0, from previous PCI D3
ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [LUS1] -> GSI 11 (level, low) -> IRQ 11
PCI: Setting latency timer of device 0000:00:02.1 to 64
ehci_hcd 0000:00:02.2: PCI D0, from previous PCI D3
ACPI: PCI Interrupt 0000:00:02.2[C] -> Link [LUS2] -> GSI 5 (level, low) -> IRQ 5
PCI: Setting latency timer of device 0000:00:02.2 to 64
ehci_hcd 0000:00:02.2: lost power, restarting
usb usb3: root hub lost power or was reset
ehci_hcd 0000:00:02.2: reset command 080b02 park=3 ithresh=8 period=1024 Reset HALT
ehci_hcd 0000:00:02.2: debug port 1
ehci_hcd 0000:00:02.2: capability 1000001 at a0
PCI: cache line size of 64 is not supported by device 0000:00:02.2
ehci_hcd 0000:00:02.2: reset command 080b02 park=3 ithresh=8 period=1024 Reset HALT
ehci_hcd 0000:00:02.2: init command 010009 (park)=0 ithresh=1 period=256 RUN
ehci_hcd 0000:00:02.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
ACPI: PCI Interrupt 0000:00:06.0[A] -> Link [LAUI] -> GSI 10 (level, low) -> IRQ 10
PCI: Setting latency timer of device 0000:00:06.0 to 64
irq 5: nobody cared (try booting with the "irqpoll" option)
Call Trace: <IRQ> <ffffffff80250c3e>{add_preempt_count+94} <ffffffff8015a878>{__report_bad_irq+56}
<ffffffff8015aab4>{note_interrupt+484} <ffffffff8015a317>{__do_IRQ+199}
<ffffffff801110f7>{do_IRQ+55} <ffffffff8010f100>{ret_from_intr+0}
<ffffffff8010fb02>{call_softirq+30} <ffffffff80138714>{__do_softirq+68}
<ffffffff801386ff>{__do_softirq+47} <ffffffff8010fb02>{call_softirq+30}
<ffffffff801110b5>{do_softirq+53} <ffffffff8013849f>{irq_exit+63}
<ffffffff801110fc>{do_IRQ+60} <ffffffff8010f100>{ret_from_intr+0}
<EOI> <ffffffff802c183a>{serial8250_console_write+186}
<ffffffff80132dad>{release_console_sem+333} <ffffffff80133587>{vprintk+775}
<ffffffff80133682>{printk+162} <ffffffff80133682>{printk+162}
<ffffffff8036003d>{_spin_unlock_irqrestore+29} <ffffffff80252c31>{pci_bus_read_config_byte+113}
<ffffffff802ed6fe>{pcibios_set_master+110} <ffffffff80255415>{pci_set_master+85}
<ffffffff88180eb7>{:snd_intel8x0:intel8x0_resume+39}
<ffffffff8812a9e7>{:snd:snd_card_pci_resume+55} <ffffffff80256c74>{pci_device_resume+36}
<ffffffff802d5cdd>{resume_device+157} <ffffffff802d5e23>{dpm_resume+147}
<ffffffff802d5e90>{device_resume+32} <ffffffff80153508>{pm_suspend_disk+296}
<ffffffff80150f10>{enter_state+112} <ffffffff80151147>{state_store+119}
<ffffffff801bfdd4>{subsys_attr_store+36} <ffffffff801c025a>{sysfs_write_file+202}
<ffffffff8017fb09>{vfs_write+233} <ffffffff8017fcb0>{sys_write+80}
<ffffffff8010eb5e>{system_call+126}
---------------------------
| preempt count: 00010103 ]
| 3 level deep critical section nesting:
----------------------------------------
.. [<ffffffff801332a4>] .... vprintk+0x24/0x360
.....[<ffffffff80133682>] .. ( <= printk+0xa2/0xb0)
.. [<ffffffff80360176>] .... _spin_lock+0x16/0x30
.....[<ffffffff8015a2fc>] .. ( <= __do_IRQ+0xac/0x120)
.. [<ffffffff80360176>] .... _spin_lock+0x16/0x30
.....[<ffffffff8015a2fc>] .. ( <= __do_IRQ+0xac/0x120)
handlers:
[<ffffffff80260970>] (usb_hcd_irq+0x0/0x70)
Disabling IRQ #5
[-- Attachment #2: lspci-v.log --]
[-- Type: text/x-log, Size: 6384 bytes --]
0000:00:00.0 Host bridge: nVidia Corporation nForce3 Host Bridge (rev a4)
Subsystem: ASUSTeK Computer Inc.: Unknown device 80c5
Flags: bus master, 66Mhz, fast devsel, latency 0
Memory at e8000000 (32-bit, prefetchable) [size=128M]
Capabilities: <available only to root>
0000:00:01.0 ISA bridge: nVidia Corporation nForce3 LPC Bridge (rev f6)
Subsystem: ASUSTeK Computer Inc.: Unknown device 80c5
Flags: bus master, 66Mhz, fast devsel, latency 0
0000:00:01.1 SMBus: nVidia Corporation nForce3 SMBus (rev a4)
Subsystem: ASUSTeK Computer Inc.: Unknown device 80c5
Flags: 66Mhz, fast devsel
I/O ports at 5000 [size=64]
I/O ports at 5040 [size=64]
Capabilities: <available only to root>
0000:00:02.0 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc.: Unknown device 1858
Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 11
Memory at febfb000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <available only to root>
0000:00:02.1 USB Controller: nVidia Corporation nForce3 USB 1.1 (rev a5) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc.: Unknown device 1858
Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 11
Memory at febfc000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <available only to root>
0000:00:02.2 USB Controller: nVidia Corporation nForce3 USB 2.0 (rev a2) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc.: Unknown device 1859
Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 5
Memory at febfdc00 (32-bit, non-prefetchable) [size=256]
Capabilities: <available only to root>
0000:00:06.0 Multimedia audio controller: nVidia Corporation nForce3 Audio (rev a2)
Subsystem: ASUSTeK Computer Inc.: Unknown device 1853
Flags: bus master, 66Mhz, fast devsel, latency 0, IRQ 10
I/O ports at e800 [size=256]
I/O ports at ec00 [size=128]
Memory at febff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: <available only to root>
0000:00:08.0 IDE interface: nVidia Corporation nForce3 IDE (rev a5) (prog-if 8a [Master SecP PriP])
Subsystem: ASUSTeK Computer Inc.: Unknown device 185a
Flags: bus master, 66Mhz, fast devsel, latency 0
I/O ports at ffa0 [size=16]
Capabilities: <available only to root>
0000:00:0a.0 PCI bridge: nVidia Corporation nForce3 PCI Bridge (rev a2) (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, fast devsel, latency 0
Bus: primary=00, secondary=02, subordinate=04, sec-latency=128
I/O behind bridge: 0000b000-0000dfff
Memory behind bridge: f8a00000-feafffff
Prefetchable memory behind bridge: 40000000-43ffffff
0000:00:0b.0 PCI bridge: nVidia Corporation nForce3 AGP Bridge (rev a4) (prog-if 00 [Normal decode])
Flags: bus master, 66Mhz, medium devsel, latency 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
Memory behind bridge: f6900000-f89fffff
Prefetchable memory behind bridge: c6800000-e67fffff
0000:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
Flags: fast devsel
Capabilities: <available only to root>
0000:00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
Flags: fast devsel
0000:00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
Flags: fast devsel
0000:00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
Flags: fast devsel
0000:01:00.0 VGA compatible controller: nVidia Corporation NV31M [GeForce FX Go5650] (rev a1) (prog-if 00 [VGA])
Subsystem: ASUSTeK Computer Inc.: Unknown device 1852
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
Memory at f7000000 (32-bit, non-prefetchable) [size=16M]
Memory at d0000000 (32-bit, prefetchable) [size=256M]
Expansion ROM at f89e0000 [disabled] [size=128K]
Capabilities: <available only to root>
0000:02:00.0 Ethernet controller: Marvell Technology Group Ltd. Gigabit Ethernet Controller (rev 13)
Subsystem: ASUSTeK Computer Inc. Marvell 88E8001 Gigabit Ethernet Controller (Asus)
Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 10
Memory at feaf8000 (32-bit, non-prefetchable) [size=16K]
I/O ports at d800 [size=256]
Expansion ROM at feac0000 [disabled] [size=128K]
Capabilities: <available only to root>
0000:02:01.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ab)
Subsystem: ASUSTeK Computer Inc.: Unknown device 1854
Flags: bus master, medium devsel, latency 168, IRQ 11
Memory at fd200000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=02, secondary=03, subordinate=06, sec-latency=176
Memory window 0: 40000000-41fff000 (prefetchable)
Memory window 1: fc600000-fd1ff000
I/O window 0: 0000b000-0000b0ff
I/O window 1: 0000b400-0000b4ff
16-bit legacy interface ports at 0001
0000:02:01.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev ab)
Subsystem: ASUSTeK Computer Inc.: Unknown device 1854
Flags: bus master, medium devsel, latency 168, IRQ 11
Memory at fa200000 (32-bit, non-prefetchable) [size=4K]
Bus: primary=02, secondary=07, subordinate=0a, sec-latency=176
Memory window 0: 42000000-43fff000 (prefetchable)
Memory window 1: f9600000-fa1ff000
I/O window 0: 0000b800-0000b8ff
I/O window 1: 0000bc00-0000bcff
16-bit legacy interface ports at 0001
0000:02:01.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 03) (prog-if 10 [OHCI])
Subsystem: ASUSTeK Computer Inc.: Unknown device 1857
Flags: bus master, medium devsel, latency 64, IRQ 10
Memory at feafd000 (32-bit, non-prefetchable) [size=2K]
Capabilities: <available only to root>
0000:02:01.3 System peripheral: Ricoh Co Ltd: Unknown device 0576 (rev 01)
Subsystem: ASUSTeK Computer Inc.: Unknown device 185b
Flags: medium devsel, IRQ 11
Memory at feafd800 (32-bit, non-prefetchable) [size=256]
Capabilities: <available only to root>
0000:02:01.4 System peripheral: Ricoh Co Ltd: Unknown device 0592
Subsystem: ASUSTeK Computer Inc.: Unknown device 185c
Flags: medium devsel, IRQ 11
Memory at feafdc00 (32-bit, non-prefetchable) [size=256]
Capabilities: <available only to root>
0000:02:02.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 03)
Subsystem: ASUSTeK Computer Inc.: Unknown device 120f
Flags: bus master, fast devsel, latency 64, IRQ 11
Memory at feafe000 (32-bit, non-prefetchable) [size=8K]
Capabilities: <available only to root>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox