* Cannot mount root file system using nfs.
From: rakesh bk @ 2008-02-13 10:56 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 4165 bytes --]
Hi EveryOne,
I am new to Xenomai , I have ported linux-2.6.14 to our custom board
based on IBM750Cxe Iam unable to boot my kernel cross compiled with eldk-3.0with
enabled xenomai support.If i remove xenomai and ipipe support the kernel
boots correctly , but if i enable CONFIG_IPIPE I get stuck in the before
mounting the root file system .
The following patches are applied and arguements of scripts/prepare-
kernel.sh is mentioned as follows
adeos-ipipe-2.6.14-ppc-1.3-05.patch,
Target architecture [default i686]: ppc
Adeos patch[default linux-2.6.14/xenomai-2.2.0
/ksrc/arch/powerpc/patches/adeos-ipipe-2.6.14-ppc64-1.2-03.patch]:
adeos-ipipe-2.6.14-ppc-1.3-05.patch,
## Booting image at 00800000 ...
Image Name: Linux-2.6.14
Created: 2008-02-13 8:23:56 UTC
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 1568257 Bytes = 1.5 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
initrd != NULL ea100000
outside initrd
root=/dev/nfs rw nfsroot=192.168.50.92:/home/eldk/ppc_7xx ip=
192.168.50.39:192.168.50.92:192.168.50.92::ATSLinux:eth0:none c
onsole=ttyS0,9600 ip1=off
## Transferring control to Linux (at address 00000000) ...
Total memory = 128MB; using 256kB for hash table (at a03c0000)
Linux version 2.6.14 (root@localhost.localdomain) (gcc version
3.2.220030217 (Yellow Dog Linux
3.0 3.2.2-2a_1)) #38 PREEMPT
Wed Feb 13 13:53:52 IST 2008
Kernel command line: root=/dev/nfs rw nfsroot=
192.168.50.92:/home/eldk/ppc_7xx ip=192.168.50.39:192.168.50.92:
192.168.50.92:
:ATSLinux:eth0:none console=ttyS0,9600 ip1=off
Initializing init_irq
PID hash table entries: 1024 (order: 10, 16384 bytes)
time_init: decrementer frequency = 17.000000 MHz
Warning: real time clock seems stuck!
I-pipe 1.3-05: pipeline enabled.
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 125696k available (2588k kernel code, 960k data, 156k init, 0k
highmem)
Mount-cache hash table entries: 512
softlockup thread 0 started up.
NET: Registered protocol family 16
PCI: Probing PCI hardware
Xenomai: ALTIVEC support enabled in kernel but no hardware found.
Disable CONFIG_ALTIVEC in the kernel configuration.
Xenomai: system init failed, code -19.
Xenomai: native skin init failed, code -19.
Xenomai: starting POSIX services.
Xenomai: POSIX skin init failed, code -19.
Xenomai: RTDM skin init failed, code -19.
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Initializing Cryptographic API
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
ttyS0 at MMIO 0x0 (irq = 85) is a 16550A
ttyS1 at MMIO 0x0 (irq = 86) is a 16550A
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
loop: loaded (max 8 devices)
nbd: registered device at major 43
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 2
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 3, 32768 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 15
gt64260_eth_open : Assigned IRQ 32 to gt64260_eth0
eth0: MII said 3, GT said 9, restarting autoneg
eth0: link state:
GT:100: Link:HD:nFC
mii:100: Link:FD: FC ANc:AN
IP-Config: Guessing netmask 255.255.255.0
IP-Config: Complete:
device=eth0, addr=192.168.50.39, mask=255.255.255.0, gw=192.168.50.92,
host=ATSLinux, domain=, nis-domain=(none),
bootserver=192.168.50.92, rootserver=192.168.50.92, rootpath=
Looking up port of RPC 100003/2 on 192.168.50.92
[-- Attachment #2: Type: text/html, Size: 5360 bytes --]
^ permalink raw reply
* Re: [GIT]: Make LMB code sharable with sparc64.
From: Michael Ellerman @ 2008-02-13 12:12 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080213.004120.22092044.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]
On Wed, 2008-02-13 at 00:41 -0800, David Miller wrote:
> As I mentioned to a few ppc folks at LCA08 I plan to use
> the LMB code from powerpc as a basis for NUMA support on
> sparc64.
>
> There are two changes.
>
> 1) Move arch/powerpc/mm/lmb.c to lib/lmb.c, put the main
> interface bits in include/linux/lmb.h, put arch-specific
> bits in asm/lmb.h and add Kconfig machinery to build this
> stuff on sparc64.
>
> 2) Fix a bug in lmb_alloc() wherein the size was not aligned
> so we could easily run out of reserve blocks because
> every aligned allocation would create a tiny hole, and
> secondly the lmb_reserve() call there did not have it's
> return value checked.
>
> Powerpc folks, if there are no objections please pull, thanks!
Looks like there are a few places (in arch/powerpc) that were getting
asm/prom.h via asm/lmb.h, I'll send a patch in the morning.
cheers
arch/powerpc/mm/numa.c:124: error: implicit declaration of function 'of_find_node_by_type'
arch/powerpc/platforms/ps3/os-area.c:215: error: variable 'property_rtc_diff' has initializer but incomplete type
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 09/18] ide: rework PowerMac media-bay support
From: Bartlomiej Zolnierkiewicz @ 2008-02-13 12:26 UTC (permalink / raw)
To: michael; +Cc: linux-ide, linux-kernel, linuxppc-dev
In-Reply-To: <1202887776.7971.19.camel@concordia.ozlabs.ibm.com>
Hi,
On Wednesday 13 February 2008, Michael Ellerman wrote:
> On Fri, 2008-02-08 at 01:45 +0100, Bartlomiej Zolnierkiewicz wrote:
> > Rework PowerMac media-bay support in such way that instead of
> > un/registering the IDE interface we un/register IDE devices:
> >
> > * Add ide_port_scan() helper for probing+registerering devices on a port.
> >
> > * Rename ide_port_unregister_devices() to __ide_port_unregister_devices().
> >
> > * Add ide_port_unregister_devices() helper for unregistering devices on a port.
> >
> > * Add 'ide_hwif_t *cd_port' to 'struct media_bay_info', pass 'hwif' instead
> > of hwif->index to media_bay_set_ide_infos() and use it to setup 'cd_port'.
> >
> > * Use ide_port_unregister_devices() instead of ide_unregister()
> > and ide_port_scan() instead of ide_register_hw() in media_bay_step().
> >
> > * Unexport ide_register_hw() and make it static.
> >
> > Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> > ---
> > drivers/ide/ide-probe.c | 18 ++++++++++++++++++
> > drivers/ide/ide.c | 22 ++++++++++++++++------
> > drivers/ide/ppc/pmac.c | 3 ++-
> > drivers/macintosh/mediabay.c | 17 +++++++----------
> > include/asm-powerpc/mediabay.h | 4 +++-
> > include/linux/ide.h | 6 ++----
> > 6 files changed, 48 insertions(+), 22 deletions(-)
>
> > Index: b/include/asm-powerpc/mediabay.h
> > ===================================================================
> > --- a/include/asm-powerpc/mediabay.h
> > +++ b/include/asm-powerpc/mediabay.h
> > @@ -22,10 +22,12 @@ int check_media_bay(struct device_node *
> > /* Number of bays in the machine or 0 */
> > extern int media_bay_count;
> >
> > +#ifdef CONFIG_BLK_DEV_IDE_PMAC
Does adding:
#include <linux/ide.h>
after ifdef help?
> > int check_media_bay_by_base(unsigned long base, int what);
> > /* called by IDE PMAC host driver to register IDE controller for media bay */
> > int media_bay_set_ide_infos(struct device_node *which_bay, unsigned long base,
> > - int irq, int index);
> > + int irq, ide_hwif_t *hwif);
> > +#endif
> >
> > #endif /* __KERNEL__ */
> > #endif /* _PPC_MEDIABAY_H */
>
> This hunk breaks pmac32_defconfig for me.
>
> include2/asm/mediabay.h:29: error: syntax error before 'ide_hwif_t'
> make[3]: *** [arch/powerpc/platforms/powermac/setup.o] Error 1
> make[2]: *** [arch/powerpc/platforms/powermac] Error 2
> make[1]: *** [arch/powerpc/platforms] Error 2
> make: *** [sub-make] Error 2
>
> cheers
^ permalink raw reply
* Re: [GIT]: Make LMB code sharable with sparc64.
From: Kumar Gala @ 2008-02-13 13:12 UTC (permalink / raw)
To: David Miller; +Cc: sparclinux, linuxppc-dev, linux-kernel
In-Reply-To: <20080213.004120.22092044.davem@davemloft.net>
On Feb 13, 2008, at 2:41 AM, David Miller wrote:
>
> As I mentioned to a few ppc folks at LCA08 I plan to use
> the LMB code from powerpc as a basis for NUMA support on
> sparc64.
>
> There are two changes.
>
> 1) Move arch/powerpc/mm/lmb.c to lib/lmb.c, put the main
> interface bits in include/linux/lmb.h, put arch-specific
> bits in asm/lmb.h and add Kconfig machinery to build this
> stuff on sparc64.
>
> 2) Fix a bug in lmb_alloc() wherein the size was not aligned
> so we could easily run out of reserve blocks because
> every aligned allocation would create a tiny hole, and
> secondly the lmb_reserve() call there did not have it's
> return value checked.
>
> Powerpc folks, if there are no objections please pull, thanks!
>
> The following changes since commit
> 96b5a46e2a72dc1829370c87053e0cd558d58bc0:
> Linus Torvalds (1):
> WMI: initialize wmi_blocks.list even if ACPI is disabled
>
> are available in the git repository at:
>
> master.kernel.org:/pub/scm/linux/kernel/git/davem/lmb-2.6.git master
>
> David S. Miller (2):
> [LIB]: Make PowerPC LMB code generic so sparc64 can use it too.
> [LMB]: Fix bug in __lmb_alloc_base().
Does sparc have the concept of a phys_addr_t? We are in the process
of expanding the lmb support to deal with 36-bit physical addresses on
32-bit machines.
- k
^ permalink raw reply
* [PATCH] [POWERPC] Fix initial lmb add region with a non-zero base
From: Kumar Gala @ 2008-02-13 13:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: sparclinux, davem, linux-kernel
If we add to an empty lmb region with a non-zero base we will not coalesce
the number of regions done to one. This causes problems on ppc32 for the
memory region as its assumed to only have one region.
We can fix this be easily specially casing the initial add to just replace
the dummy region.
---
Posting this since Dave's looking a pulling the lmb code out into lib/ and
sharing it between powerpc and sparc.
(this is my git tree git.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git)
- k
arch/powerpc/mm/lmb.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/mm/lmb.c b/arch/powerpc/mm/lmb.c
index 4ce23bc..1ea8df0 100644
--- a/arch/powerpc/mm/lmb.c
+++ b/arch/powerpc/mm/lmb.c
@@ -141,6 +141,12 @@ static long __init lmb_add_region(struct lmb_region *rgn, unsigned long base,
unsigned long coalesced = 0;
long adjacent, i;
+ if ((rgn->cnt == 1) && (rgn->region[0].size == 0)) {
+ rgn->region[0].base = base;
+ rgn->region[0].size = size;
+ return 0;
+ }
+
/* First try and coalesce this LMB with another. */
for (i=0; i < rgn->cnt; i++) {
unsigned long rgnbase = rgn->region[i].base;
--
1.5.3.8
^ permalink raw reply related
* Re: HDLC driver - dev_free_skb_irq causes Segfault
From: Laurent Pinchart @ 2008-02-13 14:11 UTC (permalink / raw)
To: linuxppc-embedded, rmcguire
In-Reply-To: <00be01c86b8d$27c2fcb0$6405a8c0@absolut>
[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]
Hi Russ,
On Sunday 10 February 2008 03:32, Russell McGuire wrote:
> All,
>
> So I am in the process of debugging my newly established HDLC driver.
> More or less modeled after a simplified gianfar / ucc_geth idea.
>
> However, after loading, etc. and using the following commands
>
> -> insmod hdlc-8360.ko
> -> sethdlc hdlc0 hdlc-eth
> -> ifconfig hdlc0 up 192.168.1.100
>
> All is well, and I am seeing IDL interrupts. Great.
>
> Now I go to ping an address like,
> ping 192.168.1.101
>
> I can see that I get the start_xmit function, the IRQ from the QE comes
> back and reports the TXBD as successfully sent.
>
> Here is the problem, when I goto free the skb in the tx_handler, I get a
> 'Unable to Handle Kernel Paging Request for data at address 0x00000000'
> Even though for the life of me, I can't see any pointers that are at
> address zero.
I'm experiencing a similar problem here with a in-house HDLC driver. The
kernel oopses after some time under high HDLC loads.
Could you please post a backtrace to see if our problems are related ? How do
you free the skb ? Posting code snippet (or even the whole source code) would
help.
> I have checked the pointer value I am passing in, and indeed it is the
> exact same pointer I am receiving from the original
> start-xmit call..
>
> Are we supposed to copy the skb? And free it immediately in the start_xmit?
> Some special way to store the pointer?
My understanding is that the skb is supposed to be freed in the TX interrupt
handler.
> I have tried
> txbd->buf = skb->data;
> txbd->buf = virt_to_phys(skb->data);
> etc.. and various other ways to save that I have seen in the gianfar and
> ucc_geth drivers.
You should map the skb data buffer using dma_map_single. Don't forget to unmap
it with dma_unmap_single in the TX interrupt handler.
> My tx_sk_buff** is identical as alloced the same way.
>
> Anyone have any ideas?
Best regards,
--
Laurent Pinchart
CSE Semaphore Belgium
Chaussée de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
F +32 (2) 387 42 75
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] [POWERPC] Fix initial lmb add region with a non-zero base
From: Jon Loeliger @ 2008-02-13 14:20 UTC (permalink / raw)
To: Kumar Gala; +Cc: sparclinux, linuxppc-dev, davem, linux-kernel
In-Reply-To: <Pine.LNX.4.64.0802130719330.14428@blarg.am.freescale.net>
So, like, the other day Kumar Gala mumbled:
> If we add to an empty lmb region with a non-zero base we will not coalesce
> the number of regions done to one. This causes problems on ppc32 for the
s/done/down
> memory region as its assumed to only have one region.
>
> We can fix this be easily specially casing the initial add to just replace
> the dummy region.
>
> ---
>
> Posting this since Dave's looking a pulling the lmb code out into lib/ and
> sharing it between powerpc and sparc.
Did you want to S-o-b: this patch? Or was this just informational?
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Jan-Bernd Themann @ 2008-02-13 15:17 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, Themann, Jan-Bernd, netdev, Dave Hansen, apw,
linux-kernel, Christoph Raisch, Badari Pulavarty, Greg KH,
Thomas Klein
In-Reply-To: <1202748429.8276.21.camel@nimitz.home.sr71.net>
Hi Dave,
On Monday 11 February 2008 17:47, Dave Hansen wrote:
> Also, just ripping down and completely re-doing the entire mass of cards
> every time a 16MB area of memory is added or removed seems like an
> awfully big sledgehammer to me. I would *HATE* to see anybody else
> using this driver as an example to work off of? Can't you just keep
> track of which areas the driver is actually *USING* and only worry about
> changing mappings if that intersects with an area having hotplug done on
> it?
to form a base for the eHEA memory add / remove concept discussion:
Explanation of the current eHEA memory add / remove concept:
Constraints imposed by HW / FW:
=2D eHEA has own MMU
=2D eHEA =A0Memory Regions (MRs) are used by the eHEA MMU =A0to translate v=
irtual
=A0 addresses to absolute addresses (like DMA mapped memory on a PCI bus)
=2D The number of MRs is limited (not enough to have one MR per packet)
=2D Registration of MRs is comparativley slow as done via slow firmware call
(H_CALL)
=2D MRs can have a maximum size of the memory available under linux
=2D MRs cover a contiguous virtual memory block (no holes)
Because of this there is just one big MR that covers entire kernel memory.
We also need a mapping table from kernel addresses to this
contiguous "virtual memory IO space" (here called ehea_bmap).
=2D When memory is added / removed to LPAR (and linux), the MR has to be up=
dated.
=A0 This can only be done by destroying and recreating the MR. There is no =
H_CALL
=A0 to modify MR size. To find holes in the linux kernel memory layout we h=
ave to
=A0 iterate over the memory sections for recreating a ehea_bmap
(otherwise MR would be bigger then available memory causing the
registration to fail)
=2D DLPAR userspace tools, kernel, driver, firmware and HMC are involved in=
that
=A0 process on System p
Memory add: version without a external memory notifier call
=2D new memory used in a transfer_xmit will result in a "ehea_bmap
translation miss", which triggers a rebuild and reregistration
=A0 of the ehea_bmap based on the current kernel memory setup.
=2D advantage: the number of MR rebuilds is reduced significantly compared =
to
a rebuild for each 16MB chunk of memory added.
Memory add: version with external notifier call:
=2D We still need a ehea_bmap (whatever structure it has)
Memory remove with notifier:
=2D We have to rebuild the ehea_bmap instantly to remove the pages that are
no longer available. Without doing that, the firmware (pHYP) cannot remove
that memory from the LPAR. As we don't know if or how many additional=20
sections are to be removed before the DLPAR user space tool tells the=20
firmware to remove the memory, we can't wait with the rebuild.
Our current understanding about the current Memory Hotplug System are
(please correct me
if I'm wrong):
=2D depends on sparse mem
=2D only whole memory sections are added / removed
=2D for each section a memory resource is registered
=46rom the driver side we need:
=2D some kind of memory notification mechanism.
=A0 For memory add we can live without any external memory notification
event. For memory remove we do need an external trigger (see explanation
above).
=2D a way to iterate over all kernel pages and a way to detect holes in the
kernel memory layout in order to build up our own ehea_bmap.
Memory notification trigger:
=2D These triggers exist, an exported "register_memory_notifier" /
=A0 "unregister_memory_notifier" would work in this scheme
=46unctions to use while building ehea_bmap + MRs:
=2D Use either the functions that are used by the memory hotplug system as
well, that means using the section defines + functions (section_nr_to_pfn,
=A0 pfn_valid)
=2D Use currently other not exported functions in kernel/resource.c, like
walk_memory_resource (where we would still need the maximum possible numb=
er
of pages NR_MEM_SECTIONS)
=2D Maybe some kind of new interface?
What would you suggest?
Regards,
Jan-Bernd & Christoph
^ permalink raw reply
* [PATCH] ehea: add kdump support
From: Thomas Klein @ 2008-02-13 15:18 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder
This patch adds kdump support to the ehea driver. As the firmware doesn't free
resource handles automatically, the driver has to run an as simple as possible
free resource function in case of a crash shutdown. The function iterates over
two arrays freeing all resource handles which are stored there. The arrays are
kept up-to-date during normal runtime. The crash handler fn is triggered by the
recently introduced PPC crash shutdown reg/unreg functions.
Signed-off-by: Thomas Klein <tklein@de.ibm.com>
---
drivers/net/ehea/ehea.h | 34 +++++-
drivers/net/ehea/ehea_main.c | 281 ++++++++++++++++++++++++++++++++++++++----
2 files changed, 290 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index 88fb53e..7c4ead3 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,7 +40,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0083"
+#define DRV_VERSION "EHEA_0087"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
@@ -386,6 +386,13 @@ struct ehea_port_res {
#define EHEA_MAX_PORTS 16
+
+#define EHEA_NUM_PORTRES_FW_HANDLES 6 /* QP handle, SendCQ handle,
+ RecvCQ handle, EQ handle,
+ SendMR handle, RecvMR handle */
+#define EHEA_NUM_PORT_FW_HANDLES 1 /* EQ handle */
+#define EHEA_NUM_ADAPTER_FW_HANDLES 2 /* MR handle, NEQ handle */
+
struct ehea_adapter {
u64 handle;
struct of_device *ofdev;
@@ -405,6 +412,31 @@ struct ehea_mc_list {
u64 macaddr;
};
+/* kdump support */
+struct ehea_fw_handle_entry {
+ u64 adh; /* Adapter Handle */
+ u64 fwh; /* Firmware Handle */
+};
+
+struct ehea_fw_handle_array {
+ struct ehea_fw_handle_entry *arr;
+ int num_entries;
+ struct semaphore lock;
+};
+
+struct ehea_bcmc_reg_entry {
+ u64 adh; /* Adapter Handle */
+ u32 port_id; /* Logical Port Id */
+ u8 reg_type; /* Registration Type */
+ u64 macaddr;
+};
+
+struct ehea_bcmc_reg_array {
+ struct ehea_bcmc_reg_entry *arr;
+ int num_entries;
+ struct semaphore lock;
+};
+
#define EHEA_PORT_UP 1
#define EHEA_PORT_DOWN 0
#define EHEA_PHY_LINK_UP 1
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index c051c7e..21af674 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -35,6 +35,7 @@
#include <linux/if_ether.h>
#include <linux/notifier.h>
#include <linux/reboot.h>
+#include <asm/kexec.h>
#include <net/ip.h>
@@ -98,8 +99,10 @@ static int port_name_cnt;
static LIST_HEAD(adapter_list);
u64 ehea_driver_flags;
struct work_struct ehea_rereg_mr_task;
-
struct semaphore dlpar_mem_lock;
+struct ehea_fw_handle_array ehea_fw_handles;
+struct ehea_bcmc_reg_array ehea_bcmc_regs;
+
static int __devinit ehea_probe_adapter(struct of_device *dev,
const struct of_device_id *id);
@@ -132,6 +135,160 @@ void ehea_dump(void *adr, int len, char *msg)
}
}
+static void ehea_update_firmware_handles(void)
+{
+ struct ehea_fw_handle_entry *arr = NULL;
+ struct ehea_adapter *adapter;
+ int num_adapters = 0;
+ int num_ports = 0;
+ int num_portres = 0;
+ int i = 0;
+ int num_fw_handles, k, l;
+
+ /* Determine number of handles */
+ list_for_each_entry(adapter, &adapter_list, list) {
+ num_adapters++;
+
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ num_ports++;
+ num_portres += port->num_def_qps + port->num_add_tx_qps;
+ }
+ }
+
+ num_fw_handles = num_adapters * EHEA_NUM_ADAPTER_FW_HANDLES +
+ num_ports * EHEA_NUM_PORT_FW_HANDLES +
+ num_portres * EHEA_NUM_PORTRES_FW_HANDLES;
+
+ if (num_fw_handles) {
+ arr = kzalloc(num_fw_handles * sizeof(*arr), GFP_KERNEL);
+ if (!arr)
+ return; /* Keep the existing array */
+ } else
+ goto out_update;
+
+ list_for_each_entry(adapter, &adapter_list, list) {
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ for (l = 0;
+ l < port->num_def_qps + port->num_add_tx_qps;
+ l++) {
+ struct ehea_port_res *pr = &port->port_res[l];
+
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->qp->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->send_cq->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->recv_cq->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->eq->fw_handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->send_mr.handle;
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = pr->recv_mr.handle;
+ }
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = port->qp_eq->fw_handle;
+ }
+
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = adapter->neq->fw_handle;
+
+ if (adapter->mr.handle) {
+ arr[i].adh = adapter->handle;
+ arr[i++].fwh = adapter->mr.handle;
+ }
+ }
+
+out_update:
+ kfree(ehea_fw_handles.arr);
+ ehea_fw_handles.arr = arr;
+ ehea_fw_handles.num_entries = i;
+}
+
+static void ehea_update_bcmc_registrations(void)
+{
+ struct ehea_bcmc_reg_entry *arr = NULL;
+ struct ehea_adapter *adapter;
+ struct ehea_mc_list *mc_entry;
+ int num_registrations = 0;
+ int i = 0;
+ int k;
+
+ /* Determine number of registrations */
+ list_for_each_entry(adapter, &adapter_list, list)
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ num_registrations += 2; /* Broadcast registrations */
+
+ list_for_each_entry(mc_entry, &port->mc_list->list,list)
+ num_registrations += 2;
+ }
+
+ if (num_registrations) {
+ arr = kzalloc(num_registrations * sizeof(*arr), GFP_KERNEL);
+ if (!arr)
+ return; /* Keep the existing array */
+ } else
+ goto out_update;
+
+ list_for_each_entry(adapter, &adapter_list, list) {
+ for (k = 0; k < EHEA_MAX_PORTS; k++) {
+ struct ehea_port *port = adapter->port[k];
+
+ if (!port || (port->state != EHEA_PORT_UP))
+ continue;
+
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_BROADCAST |
+ EHEA_BCMC_UNTAGGED;
+ arr[i++].macaddr = port->mac_addr;
+
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_BROADCAST |
+ EHEA_BCMC_VLANID_ALL;
+ arr[i++].macaddr = port->mac_addr;
+
+ list_for_each_entry(mc_entry,
+ &port->mc_list->list, list) {
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_SCOPE_ALL |
+ EHEA_BCMC_MULTICAST |
+ EHEA_BCMC_UNTAGGED;
+ arr[i++].macaddr = mc_entry->macaddr;
+
+ arr[i].adh = adapter->handle;
+ arr[i].port_id = port->logical_port_id;
+ arr[i].reg_type = EHEA_BCMC_SCOPE_ALL |
+ EHEA_BCMC_MULTICAST |
+ EHEA_BCMC_VLANID_ALL;
+ arr[i++].macaddr = mc_entry->macaddr;
+ }
+ }
+ }
+
+out_update:
+ kfree(ehea_bcmc_regs.arr);
+ ehea_bcmc_regs.arr = arr;
+ ehea_bcmc_regs.num_entries = i;
+}
+
static struct net_device_stats *ehea_get_stats(struct net_device *dev)
{
struct ehea_port *port = netdev_priv(dev);
@@ -1601,19 +1758,25 @@ static int ehea_set_mac_addr(struct net_device *dev, void *sa)
memcpy(dev->dev_addr, mac_addr->sa_data, dev->addr_len);
+ down(&ehea_bcmc_regs.lock);
+
/* Deregister old MAC in pHYP */
ret = ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
if (ret)
- goto out_free;
+ goto out_upregs;
port->mac_addr = cb0->port_mac_addr << 16;
/* Register new MAC in pHYP */
ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
if (ret)
- goto out_free;
+ goto out_upregs;
ret = 0;
+
+out_upregs:
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
out_free:
kfree(cb0);
out:
@@ -1775,9 +1938,11 @@ static void ehea_set_multicast_list(struct net_device *dev)
}
ehea_promiscuous(dev, 0);
+ down(&ehea_bcmc_regs.lock);
+
if (dev->flags & IFF_ALLMULTI) {
ehea_allmulti(dev, 1);
- return;
+ goto out;
}
ehea_allmulti(dev, 0);
@@ -1803,6 +1968,8 @@ static void ehea_set_multicast_list(struct net_device *dev)
}
out:
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
return;
}
@@ -2285,6 +2452,8 @@ static int ehea_up(struct net_device *dev)
if (port->state == EHEA_PORT_UP)
return 0;
+ down(&ehea_fw_handles.lock);
+
ret = ehea_port_res_setup(port, port->num_def_qps,
port->num_add_tx_qps);
if (ret) {
@@ -2321,8 +2490,17 @@ static int ehea_up(struct net_device *dev)
}
}
- ret = 0;
+ down(&ehea_bcmc_regs.lock);
+
+ ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
+ if (ret) {
+ ret = -EIO;
+ goto out_free_irqs;
+ }
+
port->state = EHEA_PORT_UP;
+
+ ret = 0;
goto out;
out_free_irqs:
@@ -2334,6 +2512,12 @@ out:
if (ret)
ehea_info("Failed starting %s. ret=%i", dev->name, ret);
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
+
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
+
return ret;
}
@@ -2382,16 +2566,27 @@ static int ehea_down(struct net_device *dev)
if (port->state == EHEA_PORT_DOWN)
return 0;
+ down(&ehea_bcmc_regs.lock);
ehea_drop_multicast_list(dev);
+ ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
+
ehea_free_interrupts(dev);
+ down(&ehea_fw_handles.lock);
+
port->state = EHEA_PORT_DOWN;
+ ehea_update_bcmc_registrations();
+ up(&ehea_bcmc_regs.lock);
+
ret = ehea_clean_all_portres(port);
if (ret)
ehea_info("Failed freeing resources for %s. ret=%i",
dev->name, ret);
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
+
return ret;
}
@@ -2920,19 +3115,12 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
dev->watchdog_timeo = EHEA_WATCH_DOG_TIMEOUT;
INIT_WORK(&port->reset_task, ehea_reset_port);
-
- ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
- if (ret) {
- ret = -EIO;
- goto out_unreg_port;
- }
-
ehea_set_ethtool_ops(dev);
ret = register_netdev(dev);
if (ret) {
ehea_error("register_netdev failed. ret=%d", ret);
- goto out_dereg_bc;
+ goto out_unreg_port;
}
port->lro_max_aggr = lro_max_aggr;
@@ -2949,9 +3137,6 @@ struct ehea_port *ehea_setup_single_port(struct ehea_adapter *adapter,
return port;
-out_dereg_bc:
- ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
-
out_unreg_port:
ehea_unregister_port(port);
@@ -2971,7 +3156,6 @@ static void ehea_shutdown_single_port(struct ehea_port *port)
{
unregister_netdev(port->netdev);
ehea_unregister_port(port);
- ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
kfree(port->mc_list);
free_netdev(port->netdev);
port->adapter->active_ports--;
@@ -3014,7 +3198,6 @@ static int ehea_setup_ports(struct ehea_adapter *adapter)
i++;
};
-
return 0;
}
@@ -3159,6 +3342,7 @@ static int __devinit ehea_probe_adapter(struct of_device *dev,
ehea_error("Invalid ibmebus device probed");
return -EINVAL;
}
+ down(&ehea_fw_handles.lock);
adapter = kzalloc(sizeof(*adapter), GFP_KERNEL);
if (!adapter) {
@@ -3239,7 +3423,10 @@ out_kill_eq:
out_free_ad:
kfree(adapter);
+
out:
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
return ret;
}
@@ -3258,18 +3445,41 @@ static int __devexit ehea_remove(struct of_device *dev)
flush_scheduled_work();
+ down(&ehea_fw_handles.lock);
+
ibmebus_free_irq(adapter->neq->attr.ist1, adapter);
tasklet_kill(&adapter->neq_tasklet);
ehea_destroy_eq(adapter->neq);
ehea_remove_adapter_mr(adapter);
list_del(&adapter->list);
-
kfree(adapter);
+ ehea_update_firmware_handles();
+ up(&ehea_fw_handles.lock);
+
return 0;
}
+void ehea_crash_handler(void)
+{
+ int i;
+
+ if (ehea_fw_handles.arr)
+ for (i = 0; i < ehea_fw_handles.num_entries; i++)
+ ehea_h_free_resource(ehea_fw_handles.arr[i].adh,
+ ehea_fw_handles.arr[i].fwh,
+ FORCE_FREE);
+
+ if (ehea_bcmc_regs.arr)
+ for (i = 0; i < ehea_bcmc_regs.num_entries; i++)
+ ehea_h_reg_dereg_bcmc(ehea_bcmc_regs.arr[i].adh,
+ ehea_bcmc_regs.arr[i].port_id,
+ ehea_bcmc_regs.arr[i].reg_type,
+ ehea_bcmc_regs.arr[i].macaddr,
+ 0, H_DEREG_BCMC);
+}
+
static int ehea_reboot_notifier(struct notifier_block *nb,
unsigned long action, void *unused)
{
@@ -3330,7 +3540,12 @@ int __init ehea_module_init(void)
INIT_WORK(&ehea_rereg_mr_task, ehea_rereg_mrs);
+ memset(&ehea_fw_handles, 0, sizeof(ehea_fw_handles));
+ memset(&ehea_bcmc_regs, 0, sizeof(ehea_bcmc_regs));
+
sema_init(&dlpar_mem_lock, 1);
+ sema_init(&ehea_fw_handles.lock, 1);
+ sema_init(&ehea_bcmc_regs.lock, 1);
ret = check_module_parm();
if (ret)
@@ -3340,12 +3555,18 @@ int __init ehea_module_init(void)
if (ret)
goto out;
- register_reboot_notifier(&ehea_reboot_nb);
+ ret = register_reboot_notifier(&ehea_reboot_nb);
+ if (ret)
+ ehea_info("failed registering reboot notifier");
+
+ ret = crash_shutdown_register(&ehea_crash_handler);
+ if (ret)
+ ehea_info("failed registering crash handler");
ret = ibmebus_register_driver(&ehea_driver);
if (ret) {
ehea_error("failed registering eHEA device driver on ebus");
- goto out;
+ goto out2;
}
ret = driver_create_file(&ehea_driver.driver,
@@ -3353,21 +3574,33 @@ int __init ehea_module_init(void)
if (ret) {
ehea_error("failed to register capabilities attribute, ret=%d",
ret);
- unregister_reboot_notifier(&ehea_reboot_nb);
- ibmebus_unregister_driver(&ehea_driver);
- goto out;
+ goto out3;
}
+ return ret;
+
+out3:
+ ibmebus_unregister_driver(&ehea_driver);
+out2:
+ unregister_reboot_notifier(&ehea_reboot_nb);
+ crash_shutdown_unregister(&ehea_crash_handler);
out:
return ret;
}
static void __exit ehea_module_exit(void)
{
+ int ret;
+
flush_scheduled_work();
driver_remove_file(&ehea_driver.driver, &driver_attr_capabilities);
ibmebus_unregister_driver(&ehea_driver);
unregister_reboot_notifier(&ehea_reboot_nb);
+ ret = crash_shutdown_unregister(&ehea_crash_handler);
+ if (ret)
+ ehea_info("failed unregistering crash handler");
+ kfree(ehea_fw_handles.arr);
+ kfree(ehea_bcmc_regs.arr);
ehea_destroy_busmap();
}
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] [POWERPC] Fix initial lmb add region with a non-zero base
From: Kumar Gala @ 2008-02-13 15:37 UTC (permalink / raw)
To: Jon Loeliger; +Cc: sparclinux, linuxppc-dev, davem, linux-kernel
In-Reply-To: <E1JPIT1-0001ke-GR@jdl.com>
On Feb 13, 2008, at 8:20 AM, Jon Loeliger wrote:
> So, like, the other day Kumar Gala mumbled:
>> If we add to an empty lmb region with a non-zero base we will not
>> coalesce
>> the number of regions done to one. This causes problems on ppc32
>> for the
>
> s/done/down
will fix.
>> memory region as its assumed to only have one region.
>>
>> We can fix this be easily specially casing the initial add to just
>> replace
>> the dummy region.
>>
>> ---
>>
>> Posting this since Dave's looking a pulling the lmb code out into
>> lib/ and
>> sharing it between powerpc and sparc.
>
> Did you want to S-o-b: this patch? Or was this just informational?
this was info/for review, the git tree has a s-o-b.
- k
^ permalink raw reply
* Re: V4 FX12 and PLB TEMAC: no space for user logic?
From: A. Nolson @ 2008-02-13 16:33 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <47B2B94A.6090600@dave-tech.it>
Hi ,
I am now developing my own IPs and when I try to synthesize normally I
get an error because the router finds no place to fit everything. I have
resynthesized using the option:
XIL_PAR_ENABLE_LEGALIZER=1 ( loading the program with that variable on >
XIL_PAR_ENABLE_LEGALIZER=1 xps). It took so much time because it uses a
much more consuming algorithm but I managed to build it correctly.
Regards,
/A
llandre wrote:
> Hi Mohammad,
>
> I've just had a look at the messages you generously posted in the ml
> about your experience with linux on V4 FX12 FPGA.
> I'd like to ask your opinion about FX12 practical usability in this
> context (gigabit PLB TEMAC/linux).
> In this message
>
> http://article.gmane.org/gmane.linux.ports.ppc.embedded/16816
>
> you say the device is completely full. If I understand correctly your
> system provides just the devices required to run the bandwidth test so
> it seems there is no room for user logic (I think you did not even add
> the memory controller required to access the NOR Flash containing
> bootloader, kernel image and root fs that is clearly mandatory for
> standalone product). Is that true? If it is, this limits a lot the
> flexibility of this architecture in this configuration. What do you think?
>
>
>
> Regards,
> llandre
>
> DAVE Electronics System House - R&D Department
> web: http://www.dave.eu
> email: r&d2@dave-tech.it
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* TLB Miss booting linux kernel on ppc 405
From: Ricardo Ayres Severo @ 2008-02-13 16:50 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I'm using kernel 2.6.24 and when it comes to line 826 on the file
arch/ppc/kernel/head_4xx.S it gives a TLB Miss.
arch/ppc/kernel/head_4xx.S
823 start_here:
824
825 /* ptr to current */
826 lis r2,init_task@h
827 ori r2,r2,init_task@l
It seems to have a problem initializing the MMU.
What I could do to solve this?
Thanks,
--
Ricardo Ayres Severo <severo.ricardo@gmail.com>
^ permalink raw reply
* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-13 17:05 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Themann, Jan-Bernd, netdev, apw, linux-kernel,
linuxppc-dev, Christoph Raisch, Badari Pulavarty, Greg KH,
Thomas Klein
In-Reply-To: <200802131617.58646.ossthema@de.ibm.com>
On Wed, 2008-02-13 at 16:17 +0100, Jan-Bernd Themann wrote:
> Constraints imposed by HW / FW:
> - eHEA has own MMU
> - eHEA Memory Regions (MRs) are used by the eHEA MMU to translate virtual
> addresses to absolute addresses (like DMA mapped memory on a PCI bus)
> - The number of MRs is limited (not enough to have one MR per packet)
Are there enough to have one per 16MB section?
> Our current understanding about the current Memory Hotplug System are
> (please correct me if I'm wrong):
>
> - depends on sparse mem
You're wrong ;). In mainline, this is true. There was a version of the
SUSE kernel that did otherwise. But you can not and should not depend
on this never changing. But, someone is perfectly free to go out an
implement something better than sparsemem for memory hotplug. If they
go and do this, your driver may get left behind.
> - only whole memory sections are added / removed
> - for each section a memory resource is registered
True, and true. (There might be exceptions to the whole sections one,
but that's blatant abuse and should be fixed. :)
> From the driver side we need:
> - some kind of memory notification mechanism.
> For memory add we can live without any external memory notification
> event. For memory remove we do need an external trigger (see explanation
> above).
You can export and use (un)register_memory_notifier. You just need to
do it in a reasonable way that compiles for randconfig on your
architecture. Believe me, we don't want to start teaching drivers about
sparsemem.
> - a way to iterate over all kernel pages and a way to detect holes in the
> kernel memory layout in order to build up our own ehea_bmap.
Look at kernel/resource.c
But, I'm really not convinced that you can actually keep this map
yourselves. It's not as simple as you think. What happens if you get
on an LPAR with two sections, one 256MB@0x0 and another
16MB@0x1000000000000000. That's quite possible. I think your vmalloc'd
array will eat all of memory.
That's why we have SPARSEMEM_EXTREME and SPARSEMEM_VMEMMAP implemented
in the core, so that we can deal with these kinds of problems, once and
*NOT* in every single little driver out there.
> Functions to use while building ehea_bmap + MRs:
> - Use either the functions that are used by the memory hotplug system as
> well, that means using the section defines + functions (section_nr_to_pfn,
> pfn_valid)
Basically, you can't use anything related to sections outside of the
core code. You can use things like pfn_valid(), or you can create new
interfaces that are properly abstracted.
> - Use currently other not exported functions in kernel/resource.c, like
> walk_memory_resource (where we would still need the maximum possible number
> of pages NR_MEM_SECTIONS)
It isn't the act of exporting that's the problem. It's making sure that
the exports won't be prone to abuse and that people are using them
properly. You should assume that you can export and use
walk_memory_resource().
Do you know what other operating systems do with this hardware?
In the future, please make an effort to get review from knowledgeable
people about these kinds of things before using them in your driver.
Your company has many, many resources available, and all you need to do
is ask. All that you have to do is look to the tops of the files of the
functions you are calling.
-- Dave
^ permalink raw reply
* Re: TLB Miss booting linux kernel on ppc 405
From: David Baird @ 2008-02-13 17:17 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <5ee408090802130850w130ce09an507ca5c4d41cc5a8@mail.gmail.com>
On Feb 13, 2008 9:50 AM, Ricardo Ayres Severo <severo.ricardo@gmail.com> wrote:
> Hi All,
>
> I'm using kernel 2.6.24 and when it comes to line 826 on the file
> arch/ppc/kernel/head_4xx.S it gives a TLB Miss.
>
> arch/ppc/kernel/head_4xx.S
> 823 start_here:
> 824
> 825 /* ptr to current */
> 826 lis r2,init_task@h
> 827 ori r2,r2,init_task@l
I am just curious: how did you find that you have TLB miss on that
line? Is it an Instruction TLB miss or a Data TLB miss?
Can you paste a dump of your registers (in XMD, rrd and srrd)?
I was having TLB misses awhile back due to some other problems, but
never had any on that line though.
^ permalink raw reply
* [Patch 0/2] add check_legacy_ioport calls to prevent oops
From: Christian Krafft @ 2008-02-13 17:28 UTC (permalink / raw)
To: linux-kernel; +Cc: parabelboi, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]
Hi,
the following two patches prevent kernel from crashing on powerpc.
The surrounding ifdefs will be obsolete, if check_legacy_ioport becomes
generic code.
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
IBM Systems & Technology Group,
Linux Kernel Development
IT Specialist
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Herbert Kircher
Sitz der Gesellschaft: Boeblingen
Registriergericht: Amtsgericht Stuttgart, HRB 243294
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Patch 0/2] powerpc: avoid userspace poking to legacy ioports
From: Christian Krafft @ 2008-02-13 17:35 UTC (permalink / raw)
To: linux-kernel; +Cc: parabelboi, linuxppc-dev
In-Reply-To: <20080213182800.5c6940a8@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1565 bytes --]
sensors_detect crashes kernel on PowerPC, as it pokes directly to memory.
This patch adds a check_legacy_ioports to read_port and write_port.
It will now return ENXIO, instead of oopsing.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Index: linux.git/drivers/char/mem.c
===================================================================
--- linux.git.orig/drivers/char/mem.c
+++ linux.git/drivers/char/mem.c
@@ -566,8 +566,13 @@ static ssize_t read_port(struct file * f
char __user *tmp = buf;
if (!access_ok(VERIFY_WRITE, buf, count))
- return -EFAULT;
+ return -EFAULT;
+
while (count-- > 0 && i < 65536) {
+#ifdef CONFIG_PPC_MERGE
+ if (check_legacy_ioport(i))
+ return -ENXIO;
+#endif
if (__put_user(inb(i),tmp) < 0)
return -EFAULT;
i++;
@@ -585,6 +590,7 @@ static ssize_t write_port(struct file *
if (!access_ok(VERIFY_READ,buf,count))
return -EFAULT;
+
while (count-- > 0 && i < 65536) {
char c;
if (__get_user(c, tmp)) {
@@ -592,6 +598,10 @@ static ssize_t write_port(struct file *
break;
return -EFAULT;
}
+#ifdef CONFIG_PPC_MERGE
+ if (check_legacy_ioport(i))
+ return -ENXIO;
+#endif
outb(c,i);
i++;
tmp++;
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
IBM Systems & Technology Group,
Linux Kernel Development
IT Specialist
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Herbert Kircher
Sitz der Gesellschaft: Boeblingen
Registriergericht: Amtsgericht Stuttgart, HRB 243294
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Patch 2/2] powerpc: i2c-isa: add access check to legacy ioports
From: Christian Krafft @ 2008-02-13 17:37 UTC (permalink / raw)
To: linux-kernel; +Cc: parabelboi, linuxppc-dev
In-Reply-To: <20080213182800.5c6940a8@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]
when probing i2c-pca-isa writes to legacy ioports, which crashes the kernel
if there is no device at that port.
This patch adds a check_legacy_ioport call, so probe failes gracefully
and thus prevents the oops.
Signed-off-by: Christian Krafft <krafft@de.ibm.com>
Index: linux.git/drivers/i2c/busses/i2c-pca-isa.c
===================================================================
--- linux.git.orig/drivers/i2c/busses/i2c-pca-isa.c
+++ linux.git/drivers/i2c/busses/i2c-pca-isa.c
@@ -125,6 +125,13 @@ static int __devinit pca_isa_probe(struc
dev_info(dev, "i/o base %#08lx. irq %d\n", base, irq);
+#ifdef CONFIG_PPC_MERGE
+ if (check_legacy_ioport(base)) {
+ dev_err(dev, "I/O address %#08lx is not available\n", base);
+ goto out;
+ }
+#endif
+
if (!request_region(base, IO_SIZE, "i2c-pca-isa")) {
dev_err(dev, "I/O address %#08lx is in use\n", base);
goto out;
--
Mit freundlichen Gruessen,
kind regards,
Christian Krafft
IBM Systems & Technology Group,
Linux Kernel Development
IT Specialist
Vorsitzender des Aufsichtsrats: Martin Jetter
Geschaeftsfuehrung: Herbert Kircher
Sitz der Gesellschaft: Boeblingen
Registriergericht: Amtsgericht Stuttgart, HRB 243294
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: TLB Miss booting linux kernel on ppc 405
From: Ricardo Ayres Severo @ 2008-02-13 17:38 UTC (permalink / raw)
To: David Baird; +Cc: linuxppc-embedded
In-Reply-To: <440abda90802130917x79c3c990j6a1fc7c12ba05ed7@mail.gmail.com>
I tracked the kernel execution using step one instruction (si) on gdb
and matching the jumps with the System.map.
It is a Data TLB Miss and this is the register dump after the miss occurs:
r1: 00502090
r2: 0000000f
r3: c00003c0
r4: c0000000
r5: 00000000
r6: 00000000
r7: 74747955
r8: 4c302c39
r9: 00000000
pc: 00001100
lr: 00000018
Now I'm checking the PPC cache configurations on XPS, because when
treating the DTLB Miss Exception a Machine Check Exception occurs when
it works with L1. Does this makes sense or am I confusing things?
Thanks,
On Feb 13, 2008 3:17 PM, David Baird <dhbaird@gmail.com> wrote:
> On Feb 13, 2008 9:50 AM, Ricardo Ayres Severo <severo.ricardo@gmail.com> wrote:
> > Hi All,
> >
> > I'm using kernel 2.6.24 and when it comes to line 826 on the file
> > arch/ppc/kernel/head_4xx.S it gives a TLB Miss.
> >
> > arch/ppc/kernel/head_4xx.S
> > 823 start_here:
> > 824
> > 825 /* ptr to current */
> > 826 lis r2,init_task@h
> > 827 ori r2,r2,init_task@l
>
> I am just curious: how did you find that you have TLB miss on that
> line? Is it an Instruction TLB miss or a Data TLB miss?
>
> Can you paste a dump of your registers (in XMD, rrd and srrd)?
>
> I was having TLB misses awhile back due to some other problems, but
> never had any on that line though.
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Ricardo Ayres Severo <severo.ricardo@gmail.com>
^ permalink raw reply
* Re: TLB Miss booting linux kernel on ppc 405
From: David Baird @ 2008-02-13 17:51 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <5ee408090802130938u7d069636g42a496e489fe5b80@mail.gmail.com>
On Feb 13, 2008 10:38 AM, Ricardo Ayres Severo <severo.ricardo@gmail.com> wrote:
> I tracked the kernel execution using step one instruction (si) on gdb
> and matching the jumps with the System.map.
> It is a Data TLB Miss and this is the register dump after the miss occurs:
>
> r1: 00502090
> r2: 0000000f
> r3: c00003c0
> r4: c0000000
> r5: 00000000
> r6: 00000000
> r7: 74747955
> r8: 4c302c39
> r9: 00000000
> pc: 00001100
> lr: 00000018
Can you also past the special registers (srrd in XMD)? I am very
curious about SRR0 and SRR1 and maybe some of the others.
> Now I'm checking the PPC cache configurations on XPS, because when
> treating the DTLB Miss Exception a Machine Check Exception occurs when
> it works with L1. Does this makes sense or am I confusing things?
Too soon for me to tell :-)
^ permalink raw reply
* Re: TLB Miss booting linux kernel on ppc 405
From: Ricardo Ayres Severo @ 2008-02-13 18:03 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <440abda90802130951h7a23743asc85454bf089c7e55@mail.gmail.com>
Here are the srr dump:
srr0: c0002218
srr1: 00021030
srr2: 00001154
srr3: 00000000
On Feb 13, 2008 3:51 PM, David Baird <dhbaird@gmail.com> wrote:
> On Feb 13, 2008 10:38 AM, Ricardo Ayres Severo <severo.ricardo@gmail.com> wrote:
> > I tracked the kernel execution using step one instruction (si) on gdb
> > and matching the jumps with the System.map.
> > It is a Data TLB Miss and this is the register dump after the miss occurs:
> >
> > r1: 00502090
> > r2: 0000000f
> > r3: c00003c0
> > r4: c0000000
> > r5: 00000000
> > r6: 00000000
> > r7: 74747955
> > r8: 4c302c39
> > r9: 00000000
> > pc: 00001100
> > lr: 00000018
>
> Can you also past the special registers (srrd in XMD)? I am very
> curious about SRR0 and SRR1 and maybe some of the others.
>
> > Now I'm checking the PPC cache configurations on XPS, because when
> > treating the DTLB Miss Exception a Machine Check Exception occurs when
> > it works with L1. Does this makes sense or am I confusing things?
>
> Too soon for me to tell :-)
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Ricardo Ayres Severo <severo.ricardo@gmail.com>
^ permalink raw reply
* Re: TLB Miss booting linux kernel on ppc 405
From: David Baird @ 2008-02-13 18:32 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <5ee408090802131003m4b8e632cu931769bc77f9b439@mail.gmail.com>
On Feb 13, 2008 11:03 AM, Ricardo Ayres Severo <severo.ricardo@gmail.com> wrote:
> Here are the srr dump:
> srr0: c0002218
> srr1: 00021030
> srr2: 00001154
> srr3: 00000000
Okay, SRR0 tells us that you did in fact have an exception at
0xc0002218. And I am willing to bet that is the line you mentioned
(line 826 of start_here). You can match this up with your System.map
or an objdump -d of vmlinux.
Someone who knows more than I do can correct me on this, but I have a
suspicion. As soon virtual (translation) mode is entered, I have had
a hard time using the normal debugging functions (e.g. single
instruction stepping and reading memory regions). While in virtual
mode, it seemed like I had to resort to these techniques:
- Blinking some LEDs
- Spitting characters out of a uartlite
- When an exception occurs, the processor switches back into real mode
and therefore I can set breakpoints on the beginnings of various
exception handlers and be able to use normal debugging tools again
So, I have another question. Can you set a breakpoint on 0x1100 (in
XMD: bps 0x1100 hw), then just let it run (i.e. do not single step!)
all the way until an exception happens. When the exception happens,
can you then paste the SRR0, SRR1, and the ESR (exception syndrome
register)?
I hope I am not giving you a run-around here....
-David
^ permalink raw reply
* Re: TLB Miss booting linux kernel on ppc 405
From: Ricardo Ayres Severo @ 2008-02-13 18:49 UTC (permalink / raw)
To: David Baird; +Cc: linuxppc-embedded
In-Reply-To: <440abda90802131032l6e11eef7gbd7eb57352c2ce4@mail.gmail.com>
Executing without single step the exception doesn't occurs. But at
__log_buf I get only trash, even after reseting the processor.
How can I send some characters to uartlite on asm code?
Thanks,
On Feb 13, 2008 4:32 PM, David Baird <dhbaird@gmail.com> wrote:
> On Feb 13, 2008 11:03 AM, Ricardo Ayres Severo <severo.ricardo@gmail.com> wrote:
> > Here are the srr dump:
> > srr0: c0002218
> > srr1: 00021030
> > srr2: 00001154
> > srr3: 00000000
>
> Okay, SRR0 tells us that you did in fact have an exception at
> 0xc0002218. And I am willing to bet that is the line you mentioned
> (line 826 of start_here). You can match this up with your System.map
> or an objdump -d of vmlinux.
>
> Someone who knows more than I do can correct me on this, but I have a
> suspicion. As soon virtual (translation) mode is entered, I have had
> a hard time using the normal debugging functions (e.g. single
> instruction stepping and reading memory regions). While in virtual
> mode, it seemed like I had to resort to these techniques:
>
> - Blinking some LEDs
> - Spitting characters out of a uartlite
> - When an exception occurs, the processor switches back into real mode
> and therefore I can set breakpoints on the beginnings of various
> exception handlers and be able to use normal debugging tools again
>
> So, I have another question. Can you set a breakpoint on 0x1100 (in
> XMD: bps 0x1100 hw), then just let it run (i.e. do not single step!)
> all the way until an exception happens. When the exception happens,
> can you then paste the SRR0, SRR1, and the ESR (exception syndrome
> register)?
>
> I hope I am not giving you a run-around here....
>
> -David
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Ricardo Ayres Severo <severo.ricardo@gmail.com>
^ permalink raw reply
* Re: TLB Miss booting linux kernel on ppc 405
From: David Baird @ 2008-02-13 19:02 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <5ee408090802131049u652ef867wff034b4ccb1067f1@mail.gmail.com>
On Feb 13, 2008 11:49 AM, Ricardo Ayres Severo <severo.ricardo@gmail.com> wrote:
> Executing without single step the exception doesn't occurs. But at
> __log_buf I get only trash, even after reseting the processor.
> How can I send some characters to uartlite on asm code?
Great. This confirms that I am not crazy. You are having similar
results as I did. But I still don't yet know why single-step and
memory read can't be used in virtual mode...
To use UARTLite, there are some patches you need. First thing, you
have to setup your TLBs so that uartlite can be accessed in virtual
mode. I did something like this:
#define MY_UART_LITE_BASE 0x40000000
lis r3,MY_UART_LITE_BASE@h
ori r3,r3,MY_UART_LITE_BASE@l
mr r4,r3
clrrwi r4,r4,12
ori r4,r4,(TLB_WR|TLB_I|TLB_M|TLB_G)
clrrwi r3,r3,12
ori r3,r3,(TLB_VALID | TLB_PAGESZ(PAGESZ_16M))
li r0,0 /* TLB slot 0 */
tlbwe r4,r0,TLB_DATA
tlbwe r3,r0,TLB_TAG
Then, you need to add some C code somewhere. I chose "setup.c" (in
same directory as head_4xx.S) for this purpose:
// Try to get value for XPAR_RS232_UART_BASEADDR:
#include <platforms/4xx/xparameters/xparameters.h>
#include <platforms/4xx/xparameters/xparameters_ml403.h>
void
serial_putc(unsigned char c)
{
while (((*(volatile uint32_t*)(XPAR_RS232_UART_BASEADDR + 0x8)) & 0x08) != 0);
*(volatile uint32_t*)(XPAR_RS232_UART_BASEADDR + 0x4) = c;
}
void
print_A()
{
serial_putc('A');
}
void
print_B()
{
serial_putc('B');
}
Now, from assembly, things are easy. Just do this, I think:
blr print_A
blr print_B
If this gives you any trouble, try it first from real mode so that you
can easily debug it.
-David
^ permalink raw reply
* Re: [Patch 0/2] powerpc: avoid userspace poking to legacy ioports
From: Benjamin Herrenschmidt @ 2008-02-13 20:42 UTC (permalink / raw)
To: Christian Krafft; +Cc: parabelboi, linuxppc-dev, linux-kernel
In-Reply-To: <20080213183506.7f3e3145@de.ibm.com>
On Wed, 2008-02-13 at 18:35 +0100, Christian Krafft wrote:
> sensors_detect crashes kernel on PowerPC, as it pokes directly to memory.
> This patch adds a check_legacy_ioports to read_port and write_port.
> It will now return ENXIO, instead of oopsing.
>
> Signed-off-by: Christian Krafft <krafft@de.ibm.com>
The problem is that this prevents using /proc/ioports to access PCI
IO space, which might be useful.
I hate that sensors_detect.. or for that matter any other userland code
that pokes random ports like that. It should die.
Ben.
> Index: linux.git/drivers/char/mem.c
> ===================================================================
> --- linux.git.orig/drivers/char/mem.c
> +++ linux.git/drivers/char/mem.c
> @@ -566,8 +566,13 @@ static ssize_t read_port(struct file * f
> char __user *tmp = buf;
>
> if (!access_ok(VERIFY_WRITE, buf, count))
> - return -EFAULT;
> + return -EFAULT;
> +
> while (count-- > 0 && i < 65536) {
> +#ifdef CONFIG_PPC_MERGE
> + if (check_legacy_ioport(i))
> + return -ENXIO;
> +#endif
> if (__put_user(inb(i),tmp) < 0)
> return -EFAULT;
> i++;
> @@ -585,6 +590,7 @@ static ssize_t write_port(struct file *
>
> if (!access_ok(VERIFY_READ,buf,count))
> return -EFAULT;
> +
> while (count-- > 0 && i < 65536) {
> char c;
> if (__get_user(c, tmp)) {
> @@ -592,6 +598,10 @@ static ssize_t write_port(struct file *
> break;
> return -EFAULT;
> }
> +#ifdef CONFIG_PPC_MERGE
> + if (check_legacy_ioport(i))
> + return -ENXIO;
> +#endif
> outb(c,i);
> i++;
> tmp++;
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: V4 FX12 and PLB TEMAC: no space for user logic?
From: Mohammad Sadegh Sadri @ 2008-02-13 21:00 UTC (permalink / raw)
To: llandre; +Cc: linuxppc-embedded
In-Reply-To: <47B2B94A.6090600@dave-tech.it>
[-- Attachment #1: Type: text/plain, Size: 2278 bytes --]
llandre,
Our tests show that V4 FX 12 is really a small device. The FPGA was completely full with these set of modules:
1- CPU core and related circuits, 2- PLB TEMAC , 3- DDR SDRAM Controller , 4- PLB BRAM IF , 5- Bridges , 6- OPB UART and 7- OPB EMC controller (Used for interfacing to flash chips )
The synthesis tool we used during our tests was : XST
it seems that there are some solutions to have a more optimized implementation on FX-12, personally i visited one of the members here who claimed that he has two PLB TEMACs enabled on one FX-12 FPGA. I believe that this is not possible. may be if one use better synthesis tools such as Synplify he may get slightly better results.
any how, in my idea FX-12 is not suitable for serious projects, it is suitable only for beginning phases of a project and the research phase.
We are now focusing on ML410, a great board by Xiling, featuring on FX-60 FPGA while keeps costs low.
any questions are welcom,
thanks,
Mohammad.
> Date: Wed, 13 Feb 2008 10:32:58 +0100
> From: r&d2@dave-tech.it
> To: mamsadegh@hotmail.com
> CC: linuxppc-embedded@ozlabs.org
> Subject: V4 FX12 and PLB TEMAC: no space for user logic?
>
> Hi Mohammad,
>
> I've just had a look at the messages you generously posted in the ml
> about your experience with linux on V4 FX12 FPGA.
> I'd like to ask your opinion about FX12 practical usability in this
> context (gigabit PLB TEMAC/linux).
> In this message
>
> http://article.gmane.org/gmane.linux.ports.ppc.embedded/16816
>
> you say the device is completely full. If I understand correctly your
> system provides just the devices required to run the bandwidth test so
> it seems there is no room for user logic (I think you did not even add
> the memory controller required to access the NOR Flash containing
> bootloader, kernel image and root fs that is clearly mandatory for
> standalone product). Is that true? If it is, this limits a lot the
> flexibility of this architecture in this configuration. What do you think?
>
>
>
> Regards,
> llandre
>
> DAVE Electronics System House - R&D Department
> web: http://www.dave.eu
> email: r&d2@dave-tech.it
_________________________________________________________________
[-- Attachment #2: Type: text/html, Size: 2645 bytes --]
^ 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