* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Juergen Beisert @ 2007-10-01 8:35 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <9e4733910709280838v5deebfdbo62b9097faed9c937@mail.gmail.com>
On Friday 28 September 2007 17:38, Jon Smirl wrote:
> On 9/28/07, Juergen Beisert <jbe@pengutronix.de> wrote:
> > But I can't run it a second time, as the network on target's side doesn=
't
> > respond. Any idea?
>
> Do the stress tests complete on a non-rt kernel?
I tried it again:
1) Target runs 2.6.23-rc8 without rt-preempt:
@host$ nmap 192.168.23.226
Starting Nmap 4.20 ( http://insecure.org ) at 2007-10-01 10:20 CEST
Interesting ports on 192.168.23.226:
Not shown: 1695 closed ports
PORT STATE SERVICE
22/tcp open ssh
23/tcp open telnet
Nmap finished: 1 IP address (1 host up) scanned in 0.581 seconds
Target continues to work. Does not make a difference if the root filesystem=
is=20
jffs2 or nfs.
2) Same target runs 2.6.23-rc8-rt1
@host$ nmap 192.168.23.226
Starting Nmap 4.20 ( http://insecure.org ) at 2007-10-01 10:15 CEST
Interesting ports on 192.168.23.226:
Not shown: 871 filtered ports, 824 closed ports
PORT STATE SERVICE
22/tcp open ssh
23/tcp open telnet
Nmap finished: 1 IP address (1 host up) scanned in 14.116 seconds
Network on target dies. But can be reactivated by an "ifconfig eth0 down;=20
ifconfig eth0 up". I included some printk statements into the fec.c source =
to=20
see what interrupts are happen.
"r" means fec_rx_interrupt was entered, "t" means fec_tx_interrupt was ente=
red=20
and "p" means fec_interrupt was entered. This is the output of the=20
nmap "attack" above:
rtrtrrr
at this point: fec_hard_start_xmit, stop queue
rrt
at this point: fec_tx_interrupt, wake queue
ttrr
at this point: fec_hard_start_xmit, stop queue
rrt
at this point: fec_tx_interrupt, wake queue
ttrr
at this point: fec_hard_start_xmit, stop queue
rrt
at this point: fec_tx_interrupt, wake queue
ttrr
at this point: fec_hard_start_xmit, stop queue
rrt
at this point: fec_tx_interrupt, wake queue
ttrr
at this point: fec_hard_start_xmit, stop queue
rrt
at this point: fec_tx_interrupt, wake queue
ttrr
at this point: fec_hard_start_xmit, stop queue
rrt
at this point: fec_tx_interrupt, wake queue
ttr
at this point: fec_hard_start_xmit, stop queue
rrt
at this point: fec_tx_interrupt, wake queue
at this point: fec_hard_start_xmit, stop queue
t
at this point: fec_tx_interrupt, wake queue
tp
<7>net eth0: ievent: 08020000
=2E..at this point the network is dead.
BTW: Without rt-preempt none of the wake/stop queue events and no=20
fec_interrupt occurs. I only see a long list of "r"s and "t"s...
Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* What's the preferred way to export board information to userspace ?
From: Laurent Pinchart @ 2007-10-01 9:41 UTC (permalink / raw)
To: linuxppc-embedded
Hi everybody,
I need to export some read-only board-specific information (serial number,=
=20
boot mode jumper configuration, ...) to userspace applications.
Could anyone advice me on the preferred way to do that ? I can easily add a=
=20
quick&dirty sysfs/procfs based implementation, but I was wondering if there=
=20
was some kind of clean and generic way.
Best regards,
=2D-=20
Laurent Pinchart
CSE Semaphore Belgium
Chauss=E9e de Bruxelles, 732A
B-1410 Waterloo
Belgium
T +32 (2) 387 42 59
=46 +32 (2) 387 42 75
^ permalink raw reply
* Re: [PATCH v2 2/6] Sysace: Use the established platform bus api
From: Jens Axboe @ 2007-10-01 11:59 UTC (permalink / raw)
To: Grant Likely; +Cc: Christoph Hellwig, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <fa686aa40709301633q32c7bd9epf07b5a78acb4380e@mail.gmail.com>
On Sun, Sep 30 2007, Grant Likely wrote:
> On 9/30/07, Christoph Hellwig <hch@infradead.org> wrote:
> > On Sun, Sep 30, 2007 at 04:57:09PM -0600, Grant Likely wrote:
> > > + if ((rc = platform_driver_register(&ace_platform_driver)) != 0)
> > > + goto err_plat;
> >
> > rc = platform_driver_register(&ace_platform_driver);
> > if (rc)
> > goto err_plat;
> >
> > please.
>
> Okay, will do.
>
> >
> > > + err_plat:
> > > + unregister_blkdev(ace_major, "xsysace");
> > > + err_blk:
> >
> > labels should be indented zero or one space, but not more.
>
> scripts/Lindent does this. Originally, I *didn't* have my labels
> indented. :-) Does Lindent need to be fixed?
Seems so, if it idents labels.
Just send a fixup patch for that, I'll add your series to the block tree
for 2.6.24.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH v2 2/6] Sysace: Use the established platform bus api
From: Grant Likely @ 2007-10-01 13:17 UTC (permalink / raw)
To: Jens Axboe; +Cc: Christoph Hellwig, linuxppc-dev, paulus, linux-kernel
In-Reply-To: <20071001115954.GD5303@kernel.dk>
On 10/1/07, Jens Axboe <jens.axboe@oracle.com> wrote:
> On Sun, Sep 30 2007, Grant Likely wrote:
> > On 9/30/07, Christoph Hellwig <hch@infradead.org> wrote:
> > > On Sun, Sep 30, 2007 at 04:57:09PM -0600, Grant Likely wrote:
> > > > + if ((rc = platform_driver_register(&ace_platform_driver)) != 0)
> > > > + goto err_plat;
> > >
> > > rc = platform_driver_register(&ace_platform_driver);
> > > if (rc)
> > > goto err_plat;
> > >
> > > please.
> >
> > Okay, will do.
> >
> > >
> > > > + err_plat:
> > > > + unregister_blkdev(ace_major, "xsysace");
> > > > + err_blk:
> > >
> > > labels should be indented zero or one space, but not more.
> >
> > scripts/Lindent does this. Originally, I *didn't* have my labels
> > indented. :-) Does Lindent need to be fixed?
>
> Seems so, if it idents labels.
>
> Just send a fixup patch for that, I'll add your series to the block tree
> for 2.6.24.
Cool, thanks Jens. I'll generate a patch to unindent the labels this afternoon.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: Is it safe to use these Linux function (test_bit(), set_bit(), clear_bit()) in character device driver for 2.6.10 ppc kernel.
From: Olof Johansson @ 2007-10-01 13:55 UTC (permalink / raw)
To: Misbah khan; +Cc: linuxppc-embedded
In-Reply-To: <12973587.post@talk.nabble.com>
On Sun, Sep 30, 2007 at 10:38:32PM -0700, Misbah khan wrote:
> Olof Johansson-2 wrote:
> >
> > First, PLEASE stop quoting your own text. Do not append > in front of
> > the lines you write yourself in the reply. It makes it impossible to
> > tell what parts are new and what are old.
Please read the above again, since you didn't fix your mailer.
Also, make sure it doesn't prepend spaces in front of the lines you are
writing.
> > I am confused that some people tells me to map the memory noncacheble and
> > some tells me not. could you tell me which is the best approach and please
> > elaborate the reason as well. The part of the code is mentioned above is a
> > reference and my concern are as follows:-
It depends on your application and how the FPGA is attached. Buf if it is
attached outside of the coherence domain (for example on PCI), then you
should map it uncacheable. Otherwise you will have to do manual flushing
of caches to make sure writes make it out to the device, and also flush
any copy in cache before you read any register. In other words, it makes
things considerably more complicated and error-prone.
> > 1. I am mapping 32 KB of memory for which i am using _nocasheble. Is it
> > absolutely fine????
Just use ioremap().
> > 2. I am directly dereferencing the pointer to the mapped region insted of
> > using a wrapper function due to (1) Aready used in the past and have faith
> > in it .
I don't care if you have faith in it or not, it's still not the correct
way to do it. It might work right some of the time by pure luck but it
is the incorrect way of accessing device memory.
> > (2) I had used functions like ioread32() iowrite32() in the past which
> > is suggested by rubini in his book on Linux device Driver but the output i
> > got was bitswapped .
I assume you mean byte swapped and not bit swapped.
Are your registers on the device big- or little endian?
If they are big endian, use in_be32/out_be32. If they're little endian, use
in_le32/out_le32. That will take care of any swapping for you.
> > 3. test_bit()/clear_bit() are the functions which i am using in my driver
> > and in the way i described above , please let me know that is looks fine
> > in the Implimention
No it is not fine. You cannot use set_bit/clear_bit against noncacheable
memory. EVER.
> > or shall i read the value and mask the bits rather
> > than beliving in these functions for eg :-
> >
> > dfr_data_ret=*(volatile UINT32 *)((volatile UINT32
> > *)mmap_reg_ptr+DATA_STATUS_REG);
> >
> > dfr_data_ret&=STATUS_MASK;
> >
> > Please reply to clear my doubts.
Just do what I told you earlier:
To read the status register, mask out the STATUS_MASK and write it
back, do:
val = in_be32(mmap_reg_ptr + DATA_STATUS_REG);
val &= STATUS_MASK;
out_be32(MMAP_REG_PTR + DATA_STATUS_REG, val);
-Olof
^ permalink raw reply
* [PATCH] PowerPC: Add RGMII support for Sequoia 440EPx
From: Valentine Barshak @ 2007-10-01 14:12 UTC (permalink / raw)
To: linuxppc-dev
This adds RGMII support to Sequoia DTS and sets correct phy-mode
for EMACs. According to Sequoia datasheet, both ethernet ports
are connected to RGMII interface, while ZMII is used only for MDIO.
Signed-off-by: Valentine Barshak <vbarshak@ru.mvista.com>
---
arch/powerpc/boot/dts/sequoia.dts | 14 ++++++++++++--
arch/powerpc/platforms/44x/Kconfig | 1 +
2 files changed, 13 insertions(+), 2 deletions(-)
diff -ruNp linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts linux-2.6/arch/powerpc/boot/dts/sequoia.dts
--- linux-2.6.orig/arch/powerpc/boot/dts/sequoia.dts 2007-09-29 16:59:29.000000000 +0400
+++ linux-2.6/arch/powerpc/boot/dts/sequoia.dts 2007-09-29 17:35:55.000000000 +0400
@@ -241,6 +241,12 @@
reg = <ef600d00 c>;
};
+ RGMII0: emac-rgmii@ef601000 {
+ device_type = "rgmii-interface";
+ compatible = "ibm,rgmii-440epx", "ibm,rgmii";
+ reg = <ef601000 8>;
+ };
+
EMAC0: ethernet@ef600e00 {
linux,network-index = <0>;
device_type = "network";
@@ -261,10 +267,12 @@
max-frame-size = <5dc>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
- phy-mode = "rmii";
+ phy-mode = "rgmii";
phy-map = <00000000>;
zmii-device = <&ZMII0>;
zmii-channel = <0>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <0>;
};
EMAC1: ethernet@ef600f00 {
@@ -287,10 +295,12 @@
max-frame-size = <5dc>;
rx-fifo-size = <1000>;
tx-fifo-size = <800>;
- phy-mode = "rmii";
+ phy-mode = "rgmii";
phy-map = <00000000>;
zmii-device = <&ZMII0>;
zmii-channel = <1>;
+ rgmii-device = <&RGMII0>;
+ rgmii-channel = <1>;
};
};
};
diff -ruNp linux-2.6.orig/arch/powerpc/platforms/44x/Kconfig linux-2.6/arch/powerpc/platforms/44x/Kconfig
--- linux-2.6.orig/arch/powerpc/platforms/44x/Kconfig 2007-09-29 16:59:31.000000000 +0400
+++ linux-2.6/arch/powerpc/platforms/44x/Kconfig 2007-09-29 17:59:51.000000000 +0400
@@ -50,6 +50,7 @@ config 440EPX
select PPC_FPU
# Disabled until the new EMAC Driver is merged.
# select IBM_NEW_EMAC_EMAC4
+# select IBM_NEW_EMAC_RGMII
# select IBM_NEW_EMAC_ZMII
config 440GP
^ permalink raw reply
* PowerPC: new EMAC driver typo fix
From: Valentine Barshak @ 2007-10-01 14:23 UTC (permalink / raw)
To: linuxppc-dev; +Cc: david
This looks like typo. Please, apply this patch to fix.
diff -ruNp linux-2.6.orig/drivers/net/ibm_newemac/core.c linux-2.6/drivers/net/ibm_newemac/core.c
--- linux-2.6.orig/drivers/net/ibm_newemac/core.c 2007-10-01 17:23:35.000000000 +0400
+++ linux-2.6/drivers/net/ibm_newemac/core.c 2007-10-01 17:44:57.000000000 +0400
@@ -1232,9 +1232,9 @@ static inline int emac_xmit_finish(struc
* instead
*/
if (emac_has_feature(dev, EMAC_FTR_EMAC4))
- out_be32(&p->tmr0, EMAC_TMR0_XMIT);
- else
out_be32(&p->tmr0, EMAC4_TMR0_XMIT);
+ else
+ out_be32(&p->tmr0, EMAC_TMR0_XMIT);
if (unlikely(++dev->tx_cnt == NUM_TX_BUFF)) {
netif_stop_queue(ndev);
^ permalink raw reply
* [PATCH] ehea: DLPAR memory add fix
From: Jan-Bernd Themann @ 2007-10-01 14:33 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
Due to stability issues in high load situations the HW queue handling
has to be changed. The HW queues are now stopped and restarted again instead
of destroying and allocating new HW queues.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
drivers/net/ehea/ehea.h | 4 +-
drivers/net/ehea/ehea_main.c | 276 +++++++++++++++++++++++++++++++++++++-----
drivers/net/ehea/ehea_phyp.h | 1 +
drivers/net/ehea/ehea_qmr.c | 20 ++--
drivers/net/ehea/ehea_qmr.h | 4 +-
5 files changed, 259 insertions(+), 46 deletions(-)
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index c0cbd94..3022089 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -40,13 +40,13 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0074"
+#define DRV_VERSION "EHEA_0077"
/* eHEA capability flags */
#define DLPAR_PORT_ADD_REM 1
#define DLPAR_MEM_ADD 2
#define DLPAR_MEM_REM 4
-#define EHEA_CAPABILITIES (DLPAR_PORT_ADD_REM)
+#define EHEA_CAPABILITIES (DLPAR_PORT_ADD_REM | DLPAR_MEM_ADD)
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 62d6c1e..5bc0a15 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -97,6 +97,7 @@ u64 ehea_driver_flags = 0;
struct workqueue_struct *ehea_driver_wq;
struct work_struct ehea_rereg_mr_task;
+struct semaphore dlpar_mem_lock;
static int __devinit ehea_probe_adapter(struct ibmebus_dev *dev,
const struct of_device_id *id);
@@ -177,16 +178,24 @@ static void ehea_refill_rq1(struct ehea_port_res *pr, int index, int nr_of_wqes)
struct sk_buff **skb_arr_rq1 = pr->rq1_skba.arr;
struct net_device *dev = pr->port->netdev;
int max_index_mask = pr->rq1_skba.len - 1;
+ int fill_wqes = pr->rq1_skba.os_skbs + nr_of_wqes;
+ int adder = 0;
int i;
- if (!nr_of_wqes)
+ pr->rq1_skba.os_skbs = 0;
+
+ if (unlikely(test_bit(__EHEA_STOP_XFER, &ehea_driver_flags))) {
+ pr->rq1_skba.index = index;
+ pr->rq1_skba.os_skbs = fill_wqes;
return;
+ }
- for (i = 0; i < nr_of_wqes; i++) {
+ for (i = 0; i < fill_wqes; i++) {
if (!skb_arr_rq1[index]) {
skb_arr_rq1[index] = netdev_alloc_skb(dev,
EHEA_L_PKT_SIZE);
if (!skb_arr_rq1[index]) {
+ pr->rq1_skba.os_skbs = fill_wqes - i;
ehea_error("%s: no mem for skb/%d wqes filled",
dev->name, i);
break;
@@ -194,9 +203,14 @@ static void ehea_refill_rq1(struct ehea_port_res *pr, int index, int nr_of_wqes)
}
index--;
index &= max_index_mask;
+ adder++;
}
+
+ if (adder == 0)
+ return;
+
/* Ring doorbell */
- ehea_update_rq1a(pr->qp, i);
+ ehea_update_rq1a(pr->qp, adder);
}
static int ehea_init_fill_rq1(struct ehea_port_res *pr, int nr_rq1a)
@@ -230,16 +244,21 @@ static int ehea_refill_rq_def(struct ehea_port_res *pr,
struct sk_buff **skb_arr = q_skba->arr;
struct ehea_rwqe *rwqe;
int i, index, max_index_mask, fill_wqes;
+ int adder = 0;
int ret = 0;
fill_wqes = q_skba->os_skbs + num_wqes;
+ q_skba->os_skbs = 0;
- if (!fill_wqes)
+ if (unlikely(test_bit(__EHEA_STOP_XFER, &ehea_driver_flags))) {
+ q_skba->os_skbs = fill_wqes;
return ret;
+ }
index = q_skba->index;
max_index_mask = q_skba->len - 1;
for (i = 0; i < fill_wqes; i++) {
+ u64 tmp_addr;
struct sk_buff *skb = netdev_alloc_skb(dev, packet_size);
if (!skb) {
ehea_error("%s: no mem for skb/%d wqes filled",
@@ -251,30 +270,37 @@ static int ehea_refill_rq_def(struct ehea_port_res *pr,
skb_reserve(skb, NET_IP_ALIGN);
skb_arr[index] = skb;
+ tmp_addr = ehea_map_vaddr(skb->data);
+ if (tmp_addr == -1) {
+ dev_kfree_skb(skb);
+ q_skba->os_skbs = fill_wqes - i;
+ ret = 0;
+ break;
+ }
rwqe = ehea_get_next_rwqe(qp, rq_nr);
rwqe->wr_id = EHEA_BMASK_SET(EHEA_WR_ID_TYPE, wqe_type)
| EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
rwqe->sg_list[0].l_key = pr->recv_mr.lkey;
- rwqe->sg_list[0].vaddr = ehea_map_vaddr(skb->data);
+ rwqe->sg_list[0].vaddr = tmp_addr;
rwqe->sg_list[0].len = packet_size;
rwqe->data_segments = 1;
index++;
index &= max_index_mask;
-
- if (unlikely(test_bit(__EHEA_STOP_XFER, &ehea_driver_flags)))
- goto out;
+ adder++;
}
q_skba->index = index;
+ if (adder == 0)
+ goto out;
/* Ring doorbell */
iosync();
if (rq_nr == 2)
- ehea_update_rq2a(pr->qp, i);
+ ehea_update_rq2a(pr->qp, adder);
else
- ehea_update_rq3a(pr->qp, i);
+ ehea_update_rq3a(pr->qp, adder);
out:
return ret;
}
@@ -1967,11 +1993,12 @@ static int ehea_start_xmit(struct sk_buff *skb, struct net_device *dev)
ehea_dump(swqe, 512, "swqe");
}
- if (unlikely(test_bit(__EHEA_STOP_XFER, &ehea_driver_flags)))
- goto out;
+ if (unlikely(test_bit(__EHEA_STOP_XFER, &ehea_driver_flags))) {
+ netif_stop_queue(dev);
+ swqe->tx_control |= EHEA_SWQE_PURGE;
+ }
ehea_post_swqe(pr->qp, swqe);
- pr->tx_packets++;
if (unlikely(atomic_read(&pr->swqe_avail) <= 1)) {
spin_lock_irqsave(&pr->netif_queue, flags);
@@ -1984,7 +2011,7 @@ static int ehea_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
dev->trans_start = jiffies;
spin_unlock(&pr->xmit_lock);
-out:
+
return NETDEV_TX_OK;
}
@@ -2376,6 +2403,192 @@ static int ehea_stop(struct net_device *dev)
return ret;
}
+void ehea_purge_sq(struct ehea_qp *orig_qp)
+{
+ struct ehea_qp qp = *orig_qp;
+ struct ehea_qp_init_attr *init_attr = &qp.init_attr;
+ struct ehea_swqe *swqe;
+ int wqe_index;
+ int i;
+
+ for (i = 0; i < init_attr->act_nr_send_wqes; i++) {
+ swqe = ehea_get_swqe(&qp, &wqe_index);
+ swqe->tx_control |= EHEA_SWQE_PURGE;
+ }
+}
+
+int ehea_stop_qps(struct net_device *dev)
+{
+ struct ehea_port *port = netdev_priv(dev);
+ struct ehea_adapter *adapter = port->adapter;
+ struct hcp_modify_qp_cb0* cb0;
+ int ret = -EIO;
+ int dret;
+ int i;
+ u64 hret;
+ u64 dummy64 = 0;
+ u16 dummy16 = 0;
+
+ cb0 = kzalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!cb0) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ for (i = 0; i < (port->num_def_qps + port->num_add_tx_qps); i++) {
+ struct ehea_port_res *pr = &port->port_res[i];
+ struct ehea_qp *qp = pr->qp;
+
+ /* Purge send queue */
+ ehea_purge_sq(qp);
+
+ /* Disable queue pair */
+ hret = ehea_h_query_ehea_qp(adapter->handle, 0, qp->fw_handle,
+ EHEA_BMASK_SET(H_QPCB0_ALL, 0xFFFF),
+ cb0);
+ if (hret != H_SUCCESS) {
+ ehea_error("query_ehea_qp failed (1)");
+ goto out;
+ }
+
+ cb0->qp_ctl_reg = (cb0->qp_ctl_reg & H_QP_CR_RES_STATE) << 8;
+ cb0->qp_ctl_reg &= ~H_QP_CR_ENABLED;
+
+ hret = ehea_h_modify_ehea_qp(adapter->handle, 0, qp->fw_handle,
+ EHEA_BMASK_SET(H_QPCB0_QP_CTL_REG,
+ 1), cb0, &dummy64,
+ &dummy64, &dummy16, &dummy16);
+ if (hret != H_SUCCESS) {
+ ehea_error("modify_ehea_qp failed (1)");
+ goto out;
+ }
+
+ hret = ehea_h_query_ehea_qp(adapter->handle, 0, qp->fw_handle,
+ EHEA_BMASK_SET(H_QPCB0_ALL, 0xFFFF),
+ cb0);
+ if (hret != H_SUCCESS) {
+ ehea_error("query_ehea_qp failed (2)");
+ goto out;
+ }
+
+ /* deregister shared memory regions */
+ dret = ehea_rem_smrs(pr);
+ if (dret) {
+ ehea_error("unreg shared memory region failed");
+ goto out;
+ }
+ }
+
+ ret = 0;
+out:
+ kfree(cb0);
+
+ return ret;
+}
+
+void ehea_update_rqs(struct ehea_qp *orig_qp, struct ehea_port_res * pr)
+{
+ struct ehea_qp qp = *orig_qp;
+ struct ehea_qp_init_attr *init_attr = &qp.init_attr;
+ struct ehea_rwqe *rwqe;
+ struct sk_buff **skba_rq2 = pr->rq2_skba.arr;
+ struct sk_buff **skba_rq3 = pr->rq3_skba.arr;
+ struct sk_buff *skb;
+ u32 lkey = pr->recv_mr.lkey;
+
+
+ int i;
+ int index;
+
+ for (i = 0; i < init_attr->act_nr_rwqes_rq2 + 1; i++) {
+ rwqe = ehea_get_next_rwqe(&qp, 2);
+ rwqe->sg_list[0].l_key = lkey;
+ index = EHEA_BMASK_GET(EHEA_WR_ID_INDEX, rwqe->wr_id);
+ skb = skba_rq2[index];
+ if (skb)
+ rwqe->sg_list[0].vaddr = ehea_map_vaddr(skb->data);
+ }
+
+ for (i = 0; i < init_attr->act_nr_rwqes_rq3 + 1; i++) {
+ rwqe = ehea_get_next_rwqe(&qp, 3);
+ rwqe->sg_list[0].l_key = lkey;
+ index = EHEA_BMASK_GET(EHEA_WR_ID_INDEX, rwqe->wr_id);
+ skb = skba_rq3[index];
+ if (skb)
+ rwqe->sg_list[0].vaddr = ehea_map_vaddr(skb->data);
+ }
+}
+
+int ehea_restart_qps(struct net_device *dev)
+{
+ struct ehea_port *port = netdev_priv(dev);
+ struct ehea_adapter *adapter = port->adapter;
+ int ret = 0;
+ int i;
+
+ struct hcp_modify_qp_cb0* cb0;
+ u64 hret;
+ u64 dummy64 = 0;
+ u16 dummy16 = 0;
+
+ cb0 = kzalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!cb0) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ for (i = 0; i < (port->num_def_qps + port->num_add_tx_qps); i++) {
+ struct ehea_port_res *pr = &port->port_res[i];
+ struct ehea_qp *qp = pr->qp;
+
+ ret = ehea_gen_smrs(pr);
+ if (ret) {
+ ehea_error("creation of shared memory regions failed");
+ goto out;
+ }
+
+ ehea_update_rqs(qp, pr);
+
+ /* Enable queue pair */
+ hret = ehea_h_query_ehea_qp(adapter->handle, 0, qp->fw_handle,
+ EHEA_BMASK_SET(H_QPCB0_ALL, 0xFFFF),
+ cb0);
+ if (hret != H_SUCCESS) {
+ ehea_error("query_ehea_qp failed (1)");
+ goto out;
+ }
+
+ cb0->qp_ctl_reg = (cb0->qp_ctl_reg & H_QP_CR_RES_STATE) << 8;
+ cb0->qp_ctl_reg |= H_QP_CR_ENABLED;
+
+ hret = ehea_h_modify_ehea_qp(adapter->handle, 0, qp->fw_handle,
+ EHEA_BMASK_SET(H_QPCB0_QP_CTL_REG,
+ 1), cb0, &dummy64,
+ &dummy64, &dummy16, &dummy16);
+ if (hret != H_SUCCESS) {
+ ehea_error("modify_ehea_qp failed (1)");
+ goto out;
+ }
+
+ hret = ehea_h_query_ehea_qp(adapter->handle, 0, qp->fw_handle,
+ EHEA_BMASK_SET(H_QPCB0_ALL, 0xFFFF),
+ cb0);
+ if (hret != H_SUCCESS) {
+ ehea_error("query_ehea_qp failed (2)");
+ goto out;
+ }
+
+ /* refill entire queue */
+ ehea_refill_rq1(pr, pr->rq1_skba.index, 0);
+ ehea_refill_rq2(pr, 0);
+ ehea_refill_rq3(pr, 0);
+ }
+out:
+ kfree(cb0);
+
+ return ret;
+}
+
static void ehea_reset_port(struct work_struct *work)
{
int ret;
@@ -2395,6 +2608,8 @@ static void ehea_reset_port(struct work_struct *work)
if (ret)
goto out;
+ ehea_set_multicast_list(dev);
+
if (netif_msg_timer(port))
ehea_info("Device %s resetted successfully", dev->name);
@@ -2411,6 +2626,7 @@ static void ehea_rereg_mrs(struct work_struct *work)
int ret, i;
struct ehea_adapter *adapter;
+ down(&dlpar_mem_lock);
ehea_info("LPAR memory enlarged - re-initializing driver");
list_for_each_entry(adapter, &adapter_list, list)
@@ -2423,14 +2639,14 @@ static void ehea_rereg_mrs(struct work_struct *work)
struct net_device *dev = port->netdev;
if (dev->flags & IFF_UP) {
- ehea_info("stopping %s",
- dev->name);
down(&port->port_lock);
netif_stop_queue(dev);
-
+ ret = ehea_stop_qps(dev);
+ if (ret) {
+ up(&port->port_lock);
+ goto out;
+ }
port_napi_disable(port);
-
- ehea_down(dev);
up(&port->port_lock);
}
}
@@ -2446,10 +2662,11 @@ static void ehea_rereg_mrs(struct work_struct *work)
}
ehea_destroy_busmap();
-
ret = ehea_create_busmap();
- if (ret)
+ if (ret) {
+ ehea_error("creating ehea busmap failed");
goto out;
+ }
clear_bit(__EHEA_STOP_XFER, &ehea_driver_flags);
@@ -2471,21 +2688,18 @@ static void ehea_rereg_mrs(struct work_struct *work)
struct net_device *dev = port->netdev;
if (dev->flags & IFF_UP) {
- ehea_info("restarting %s",
- dev->name);
down(&port->port_lock);
-
- ret = ehea_up(dev);
- if (!ret) {
- port_napi_enable(port);
+ port_napi_enable(port);
+ ret = ehea_restart_qps(dev);
+ if (!ret)
netif_wake_queue(dev);
- }
-
up(&port->port_lock);
}
}
}
}
+ up(&dlpar_mem_lock);
+ ehea_info("re-initializing driver complete");
out:
return;
}
@@ -2494,7 +2708,8 @@ static void ehea_tx_watchdog(struct net_device *dev)
{
struct ehea_port *port = netdev_priv(dev);
- if (netif_carrier_ok(dev))
+ if (netif_carrier_ok(dev) &&
+ !test_bit(__EHEA_STOP_XFER, &ehea_driver_flags))
queue_work(port->adapter->ehea_wq, &port->reset_task);
}
@@ -3139,6 +3354,7 @@ int __init ehea_module_init(void)
ehea_driver_wq = create_workqueue("ehea_driver_wq");
INIT_WORK(&ehea_rereg_mr_task, ehea_rereg_mrs);
+ sema_init(&dlpar_mem_lock, 1);
ret = check_module_parm();
if (ret)
diff --git a/drivers/net/ehea/ehea_phyp.h b/drivers/net/ehea/ehea_phyp.h
index 89b6353..faa191d 100644
--- a/drivers/net/ehea/ehea_phyp.h
+++ b/drivers/net/ehea/ehea_phyp.h
@@ -126,6 +126,7 @@ struct hcp_modify_qp_cb0 {
#define H_QP_CR_STATE_RDY2RCV 0x0000030000000000ULL /* Ready to recv */
#define H_QP_CR_STATE_RDY2SND 0x0000050000000000ULL /* Ready to send */
#define H_QP_CR_STATE_ERROR 0x0000800000000000ULL /* Error */
+#define H_QP_CR_RES_STATE 0x0000007F00000000ULL /* Resultant state */
struct hcp_modify_qp_cb1 {
u32 qpn; /* 00 */
diff --git a/drivers/net/ehea/ehea_qmr.c b/drivers/net/ehea/ehea_qmr.c
index c82e245..329a252 100644
--- a/drivers/net/ehea/ehea_qmr.c
+++ b/drivers/net/ehea/ehea_qmr.c
@@ -563,8 +563,7 @@ int ehea_destroy_qp(struct ehea_qp *qp)
int ehea_create_busmap( void )
{
u64 vaddr = EHEA_BUSMAP_START;
- unsigned long abs_max_pfn = 0;
- unsigned long sec_max_pfn;
+ unsigned long high_section_index = 0;
int i;
/*
@@ -574,14 +573,10 @@ int ehea_create_busmap( void )
ehea_bmap.valid_sections = 0;
for (i = 0; i < NR_MEM_SECTIONS; i++)
- if (valid_section_nr(i)) {
- sec_max_pfn = section_nr_to_pfn(i);
- if (sec_max_pfn > abs_max_pfn)
- abs_max_pfn = sec_max_pfn;
- ehea_bmap.valid_sections++;
- }
+ if (valid_section_nr(i))
+ high_section_index = i;
- ehea_bmap.entries = abs_max_pfn / EHEA_PAGES_PER_SECTION + 1;
+ ehea_bmap.entries = high_section_index + 1;
ehea_bmap.vaddr = vmalloc(ehea_bmap.entries * sizeof(*ehea_bmap.vaddr));
if (!ehea_bmap.vaddr)
@@ -593,6 +588,7 @@ int ehea_create_busmap( void )
if (pfn_valid(pfn)) {
ehea_bmap.vaddr[i] = vaddr;
vaddr += EHEA_SECTSIZE;
+ ehea_bmap.valid_sections++;
} else
ehea_bmap.vaddr[i] = 0;
}
@@ -637,7 +633,7 @@ int ehea_reg_kernel_mr(struct ehea_adapter *adapter, struct ehea_mr *mr)
mr_len = ehea_bmap.valid_sections * EHEA_SECTSIZE;
- pt = kzalloc(EHEA_MAX_RPAGE * sizeof(u64), GFP_KERNEL);
+ pt = kzalloc(PAGE_SIZE, GFP_KERNEL);
if (!pt) {
ehea_error("no mem");
ret = -ENOMEM;
@@ -660,8 +656,8 @@ int ehea_reg_kernel_mr(struct ehea_adapter *adapter, struct ehea_mr *mr)
void *sectbase = __va(i << SECTION_SIZE_BITS);
unsigned long k = 0;
- for (j = 0; j < (PAGES_PER_SECTION / EHEA_MAX_RPAGE);
- j++) {
+ for (j = 0; j < (EHEA_PAGES_PER_SECTION /
+ EHEA_MAX_RPAGE); j++) {
for (m = 0; m < EHEA_MAX_RPAGE; m++) {
pg = sectbase + ((k++) * EHEA_PAGESIZE);
diff --git a/drivers/net/ehea/ehea_qmr.h b/drivers/net/ehea/ehea_qmr.h
index b71f845..562de0e 100644
--- a/drivers/net/ehea/ehea_qmr.h
+++ b/drivers/net/ehea/ehea_qmr.h
@@ -39,7 +39,7 @@
#define EHEA_PAGESHIFT 12
#define EHEA_PAGESIZE (1UL << EHEA_PAGESHIFT)
#define EHEA_SECTSIZE (1UL << 24)
-#define EHEA_PAGES_PER_SECTION (EHEA_SECTSIZE >> PAGE_SHIFT)
+#define EHEA_PAGES_PER_SECTION (EHEA_SECTSIZE >> EHEA_PAGESHIFT)
#if (1UL << SECTION_SIZE_BITS) < EHEA_SECTSIZE
#error eHEA module can't work if kernel sectionsize < ehea sectionsize
@@ -145,7 +145,7 @@ struct ehea_rwqe {
#define EHEA_CQE_VLAN_TAG_XTRACT 0x0400
#define EHEA_CQE_TYPE_RQ 0x60
-#define EHEA_CQE_STAT_ERR_MASK 0x721F
+#define EHEA_CQE_STAT_ERR_MASK 0x720F
#define EHEA_CQE_STAT_FAT_ERR_MASK 0x1F
#define EHEA_CQE_STAT_ERR_TCP 0x4000
#define EHEA_CQE_STAT_ERR_IP 0x2000
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] ehea: DLPAR memory add fix
From: Jeff Garzik @ 2007-10-01 14:44 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
In-Reply-To: <200710011633.18305.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> Due to stability issues in high load situations the HW queue handling
> has to be changed. The HW queues are now stopped and restarted again instead
> of destroying and allocating new HW queues.
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
May I presume this is for 2.6.23?
Jeff
^ permalink raw reply
* Re: [PATCH] ehea: DLPAR memory add fix
From: Jan-Bernd Themann @ 2007-10-01 14:54 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
In-Reply-To: <470107D9.2040301@garzik.org>
Hi,
On Monday 01 October 2007 16:44, Jeff Garzik wrote:
> Jan-Bernd Themann wrote:
> > Due to stability issues in high load situations the HW queue handling
> > has to be changed. The HW queues are now stopped and restarted again instead
> > of destroying and allocating new HW queues.
> >
> > Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
>
> May I presume this is for 2.6.23?
>
> Jeff
no, the patch is build against 2.6.24 upstream (new NAPI interface).
Regards,
Jan-Bernd
^ permalink raw reply
* Re: [PATCH] ehea: DLPAR memory add fix
From: Jeff Garzik @ 2007-10-01 15:05 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
In-Reply-To: <200710011654.14067.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> Hi,
>
> On Monday 01 October 2007 16:44, Jeff Garzik wrote:
>> Jan-Bernd Themann wrote:
>>> Due to stability issues in high load situations the HW queue handling
>>> has to be changed. The HW queues are now stopped and restarted again instead
>>> of destroying and allocating new HW queues.
>>>
>>> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
>> May I presume this is for 2.6.23?
>>
>> Jeff
>
> no, the patch is build against 2.6.24 upstream (new NAPI interface).
OK, thanks.
Since we typically have two streams, the current bug-fix stream and the
for-next-kernel stream, please indicate to which kernel/git tree your
patch applies, in the future.
^ permalink raw reply
* Re: [PATCHv2 4/4] Virtex: Add generic Xilinx Virtex board support
From: Stephen Rothwell @ 2007-10-01 15:06 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20070930222048.583.82010.stgit@trillian.cg.shawcable.net>
[-- Attachment #1: Type: text/plain, Size: 345 bytes --]
On Sun, 30 Sep 2007 16:20:52 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> +++ b/arch/powerpc/platforms/40x/virtex.c
> +#include <asm/of_platform.h>
/me puts on broken record voice :-)
linux/of_platform.h, please
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCHv2 3/4] Virtex: add xilinx interrupt controller driver
From: Stephen Rothwell @ 2007-10-01 15:08 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <20070930222038.583.20385.stgit@trillian.cg.shawcable.net>
[-- Attachment #1: Type: text/plain, Size: 626 bytes --]
On Sun, 30 Sep 2007 16:20:43 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
>
> diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c
> new file mode 100644
> index 0000000..69f05cd
> --- /dev/null
> +++ b/arch/powerpc/sysdev/xilinx_intc.c
> @@ -0,0 +1,151 @@
> +#include <linux/kernel.h>
> +#include <linux/irq.h>
> +#include <asm/io.h>
> +#include <asm/processor.h>
> +#include <asm/prom.h>
You probably want linux/of_device.h or linux/of.h instead of asm/prom.h
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCHv2 4/4] Virtex: Add generic Xilinx Virtex board support
From: Grant Likely @ 2007-10-01 15:15 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071002010630.e78e4889.sfr@canb.auug.org.au>
On 10/1/07, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Sun, 30 Sep 2007 16:20:52 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
> >
> > +++ b/arch/powerpc/platforms/40x/virtex.c
> > +#include <asm/of_platform.h>
>
> /me puts on broken record voice :-)
>
> linux/of_platform.h, please
Done
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCHv2 3/4] Virtex: add xilinx interrupt controller driver
From: Grant Likely @ 2007-10-01 15:16 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev
In-Reply-To: <20071002010819.6f2736be.sfr@canb.auug.org.au>
On 10/1/07, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Sun, 30 Sep 2007 16:20:43 -0600 Grant Likely <grant.likely@secretlab.ca> wrote:
> >
> > diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c
> > new file mode 100644
> > index 0000000..69f05cd
> > --- /dev/null
> > +++ b/arch/powerpc/sysdev/xilinx_intc.c
> > @@ -0,0 +1,151 @@
> > +#include <linux/kernel.h>
> > +#include <linux/irq.h>
> > +#include <asm/io.h>
> > +#include <asm/processor.h>
> > +#include <asm/prom.h>
>
> You probably want linux/of_device.h or linux/of.h instead of asm/prom.h
Done.
Thanks for the comments,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] cpm: Describe multi-user ram in its own device node.
From: Scott Wood @ 2007-10-01 16:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: Timur Tabi, PowerPC dev list
In-Reply-To: <1B684498-FC47-4F01-A72E-DD27B259613A@kernel.crashing.org>
Kumar Gala wrote:
>
> On Sep 29, 2007, at 1:49 AM, Vitaly Bordug wrote:
>> cpms have dpram, qe has muram. these two are the same stuff in fact.
>> Or you are asking about have QE stuff utilize such a binding at the
>> same pass?
>
> I was asking about both these things.
As stated in the commit message, QE can use this; it just needs a
compatible entry in the data node.
-Scott
^ permalink raw reply
* Re: [RFC PATCH v0.1] net driver: mpc52xx fec
From: Juergen Beisert @ 2007-10-01 16:24 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Daniel Walker
In-Reply-To: <200710011035.24068.jbe@pengutronix.de>
On Monday 01 October 2007 10:35, Juergen Beisert wrote:
> 2) Same target runs 2.6.23-rc8-rt1
>
> @host$ nmap 192.168.23.226
>
> Starting Nmap 4.20 ( http://insecure.org ) at 2007-10-01 10:15 CEST
> Interesting ports on 192.168.23.226:
> Not shown: 871 filtered ports, 824 closed ports
> PORT STATE SERVICE
> 22/tcp open ssh
> 23/tcp open telnet
>
> Nmap finished: 1 IP address (1 host up) scanned in 14.116 seconds
>
> Network on target dies. But can be reactivated by an "ifconfig eth0 down;
> ifconfig eth0 up". I included some printk statements into the fec.c source
> to see what interrupts are happen.
>
> "r" means fec_rx_interrupt was entered, "t" means fec_tx_interrupt was
> entered and "p" means fec_interrupt was entered. This is the output of the
> nmap "attack" above:
>
> rtrtrrr
> at this point: fec_hard_start_xmit, stop queue
> rrt
> at this point: fec_tx_interrupt, wake queue
> ttrr
> at this point: fec_hard_start_xmit, stop queue
> rrt
> at this point: fec_tx_interrupt, wake queue
> ttrr
> at this point: fec_hard_start_xmit, stop queue
> rrt
> at this point: fec_tx_interrupt, wake queue
> ttrr
> at this point: fec_hard_start_xmit, stop queue
> rrt
> at this point: fec_tx_interrupt, wake queue
> ttrr
> at this point: fec_hard_start_xmit, stop queue
> rrt
> at this point: fec_tx_interrupt, wake queue
> ttrr
> at this point: fec_hard_start_xmit, stop queue
> rrt
> at this point: fec_tx_interrupt, wake queue
> ttr
> at this point: fec_hard_start_xmit, stop queue
> rrt
> at this point: fec_tx_interrupt, wake queue
> at this point: fec_hard_start_xmit, stop queue
> t
> at this point: fec_tx_interrupt, wake queue
> tp
> <7>net eth0: ievent: 08020000
>
> ...at this point the network is dead.
>
> BTW: Without rt-preempt none of the wake/stop queue events and no
> fec_interrupt occurs. I only see a long list of "r"s and "t"s...
We tried again with rt-preempt and increased the priority of FEC's three=20
interrupts: And now it survives the nmap "attack". But we don't know now if=
=20
we only changed the behavior or fixed the bug?
BTW: Is it possible that fec_interrupt(() doesn' handle FEC_IEVENT_RFIFO_ER=
ROR =20
and FEC_IEVENT_XFIFO_ERROR)) incorrectly? The lines makes more sense with t=
he=20
following patch (but we are not sure about authors real intention).
@@ -506,7 +484,7 @@ static irqreturn_t fec_interrupt(int irq
out_be32(&fec->ievent, ievent); /* clear pending events */
=2D if (ievent & ~(FEC_IEVENT_RFIFO_ERROR | FEC_IEVENT_XFIFO_ERROR)) {
+ if (!(ievent & (FEC_IEVENT_RFIFO_ERROR | FEC_IEVENT_XFIFO_ERROR))) {
if (ievent & ~FEC_IEVENT_TFINT)
dev_dbg(&dev->dev, "ievent: %08x\n", ievent);
return IRQ_HANDLED;
Juergen
=2D-=20
Dipl.-Ing. Juergen Beisert | http://www.pengutronix.de
=A0Pengutronix - Linux Solutions for Science and Industry
=A0 Handelsregister: Amtsgericht Hildesheim, HRA 2686
=A0 =A0 =A0 Vertretung Sued/Muenchen, Germany
Phone: +49-8766-939 228 | Fax: +49-5121-206917-9
^ permalink raw reply
* [RFC] Get rid of linuxppc-embedded?
From: Mark A. Greer @ 2007-10-01 19:24 UTC (permalink / raw)
To: linuxppc-dev
With the merging of the powerpc trees I'm not sure there is a clear
reason why we have 2 separate powerpc lists anymore (linuxppc-dev and
linuxppc-embedded).
linuxppc-embedded is fairly low volume/noise but there is still the occasional
patch posted there that should really be posted to linuxppc-dev. I think
it would be nice to have just one list where all eyes are focused.
Is it time to get rid of linuxppc-embedded?
Mark
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Mark A. Greer @ 2007-10-01 19:19 UTC (permalink / raw)
To: Olof Johansson; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <20070927212830.GA9610@lixom.net>
On Thu, Sep 27, 2007 at 04:28:30PM -0500, Olof Johansson wrote:
> On Thu, Sep 27, 2007 at 03:03:12PM -0500, Josh Boyer wrote:
> > On Thu, 27 Sep 2007 12:53:51 -0700
> > "Mark A. Greer" <mgreer@mvista.com> wrote:
> >
> > > On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote:
> > > > Thanks for the advice, but I was just basing the list to post to on the
> > > > MAINTAINERS file which states that this is the one for Embedded PPC83XX.
> > > > If you still think that I should post to linuxppc-dev, let me know.
> > >
> > > Yes, I think it would be better to repost to linuxppc-dev.
> > >
> > > Does anyone have an objection to changing all of the:
> > >
> > > "L: linuxppc-embedded@ozlabs.org"
> > >
> > > in MAINTAINERS to:
> > >
> > > "L: linuxppc-dev@ozlabs.org" ??
> > >
> > > Kumar, Josh, Vitaly, et. al.?
> >
> > I personally don't care either way. I'm already subscribed to both
> > lists.
> >
> > Makes sense to go to linuxppc-dev given the arch/powerpc migration.
>
> I thought the -embedded list was created in the first place to keep some
> of the "noise" off of -dev (i.e. "I can't get interface <foo> to work on
> my custom <embedded eval board>-lookalike board, HELP!"). If people still
> care about keeping that on a separate list, then we shouldn't change it.
Yes, IIRC, that was the reason but now with the merge and low volume on this
list, it makes sense to me to just get rid of -embedded.
> I think the relevant people probably monitor this list (maybe not quite as
> frequently) to catch things. I even caught the first PWRficient-related
> question in a timely manner the other day. :-)
:)
> Still, that being said, patches will clearly get better exposure on -dev,
> especially device tree crap.
Definitely. I'll propose this on -dev and see what people say.
Mark
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Ben Warren @ 2007-10-01 19:49 UTC (permalink / raw)
To: Mark A. Greer; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <20071001191937.GA5785@mag.az.mvista.com>
Mark A. Greer wrote:
> On Thu, Sep 27, 2007 at 04:28:30PM -0500, Olof Johansson wrote:
>
>> On Thu, Sep 27, 2007 at 03:03:12PM -0500, Josh Boyer wrote:
>>
>>> On Thu, 27 Sep 2007 12:53:51 -0700
>>> "Mark A. Greer" <mgreer@mvista.com> wrote:
>>>
>>>
>>>> On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote:
>>>>
>>>>> Thanks for the advice, but I was just basing the list to post to on the
>>>>> MAINTAINERS file which states that this is the one for Embedded PPC83XX.
>>>>> If you still think that I should post to linuxppc-dev, let me know.
>>>>>
>>>> Yes, I think it would be better to repost to linuxppc-dev.
>>>>
>>>> Does anyone have an objection to changing all of the:
>>>>
>>>> "L: linuxppc-embedded@ozlabs.org"
>>>>
>>>> in MAINTAINERS to:
>>>>
>>>> "L: linuxppc-dev@ozlabs.org" ??
>>>>
>>>> Kumar, Josh, Vitaly, et. al.?
>>>>
>>> I personally don't care either way. I'm already subscribed to both
>>> lists.
>>>
>>> Makes sense to go to linuxppc-dev given the arch/powerpc migration.
>>>
>> I thought the -embedded list was created in the first place to keep some
>> of the "noise" off of -dev (i.e. "I can't get interface <foo> to work on
>> my custom <embedded eval board>-lookalike board, HELP!"). If people still
>> care about keeping that on a separate list, then we shouldn't change it.
>>
>
> Yes, IIRC, that was the reason but now with the merge and low volume on this
> list, it makes sense to me to just get rid of -embedded.
>
>
Perhaps my perspective is unique, but I doubt it. I find it nice that
this list is low volume and not filled with endless patches about CHRP
and P series and open firmware syntax blah blah blah...
No offense intended to all the people who are doing wonderful work
expanding the Linux universe, but for your average dude or dudette
working on embedded boards that happen to have a PowerPC processor, this
list is a pretty good forum.
regards,
Ben
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Josh Boyer @ 2007-10-01 19:59 UTC (permalink / raw)
To: Ben Warren; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <47014F42.1010106@qstreams.com>
On Mon, 01 Oct 2007 15:49:22 -0400
Ben Warren <bwarren@qstreams.com> wrote:
> Mark A. Greer wrote:
> > On Thu, Sep 27, 2007 at 04:28:30PM -0500, Olof Johansson wrote:
> >
> >> On Thu, Sep 27, 2007 at 03:03:12PM -0500, Josh Boyer wrote:
> >>
> >>> On Thu, 27 Sep 2007 12:53:51 -0700
> >>> "Mark A. Greer" <mgreer@mvista.com> wrote:
> >>>
> >>>
> >>>> On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote:
> >>>>
> >>>>> Thanks for the advice, but I was just basing the list to post to on the
> >>>>> MAINTAINERS file which states that this is the one for Embedded PPC83XX.
> >>>>> If you still think that I should post to linuxppc-dev, let me know.
> >>>>>
> >>>> Yes, I think it would be better to repost to linuxppc-dev.
> >>>>
> >>>> Does anyone have an objection to changing all of the:
> >>>>
> >>>> "L: linuxppc-embedded@ozlabs.org"
> >>>>
> >>>> in MAINTAINERS to:
> >>>>
> >>>> "L: linuxppc-dev@ozlabs.org" ??
> >>>>
> >>>> Kumar, Josh, Vitaly, et. al.?
> >>>>
> >>> I personally don't care either way. I'm already subscribed to both
> >>> lists.
> >>>
> >>> Makes sense to go to linuxppc-dev given the arch/powerpc migration.
> >>>
> >> I thought the -embedded list was created in the first place to keep some
> >> of the "noise" off of -dev (i.e. "I can't get interface <foo> to work on
> >> my custom <embedded eval board>-lookalike board, HELP!"). If people still
> >> care about keeping that on a separate list, then we shouldn't change it.
> >>
> >
> > Yes, IIRC, that was the reason but now with the merge and low volume on this
> > list, it makes sense to me to just get rid of -embedded.
> >
> >
> Perhaps my perspective is unique, but I doubt it. I find it nice that
> this list is low volume and not filled with endless patches about CHRP
> and P series and open firmware syntax blah blah blah...
>
> No offense intended to all the people who are doing wonderful work
> expanding the Linux universe, but for your average dude or dudette
> working on embedded boards that happen to have a PowerPC processor, this
> list is a pretty good forum.
I think the original thought was to have patches go to linuxppc-dev.
Not necessarily all discussion.
josh
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Ben Warren @ 2007-10-01 20:07 UTC (permalink / raw)
To: Josh Boyer; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <20071001145911.77194814@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Mon, 01 Oct 2007 15:49:22 -0400
> Ben Warren <bwarren@qstreams.com> wrote:
>
>
>> Mark A. Greer wrote:
>>
>>> On Thu, Sep 27, 2007 at 04:28:30PM -0500, Olof Johansson wrote:
>>>
>>>
>>>> On Thu, Sep 27, 2007 at 03:03:12PM -0500, Josh Boyer wrote:
>>>>
>>>>
>>>>> On Thu, 27 Sep 2007 12:53:51 -0700
>>>>> "Mark A. Greer" <mgreer@mvista.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> On Thu, Sep 27, 2007 at 12:41:57PM -0700, D'Abbraccio Joe-ljd015 wrote:
>>>>>>
>>>>>>
>>>>>>> Thanks for the advice, but I was just basing the list to post to on the
>>>>>>> MAINTAINERS file which states that this is the one for Embedded PPC83XX.
>>>>>>> If you still think that I should post to linuxppc-dev, let me know.
>>>>>>>
>>>>>>>
>>>>>> Yes, I think it would be better to repost to linuxppc-dev.
>>>>>>
>>>>>> Does anyone have an objection to changing all of the:
>>>>>>
>>>>>> "L: linuxppc-embedded@ozlabs.org"
>>>>>>
>>>>>> in MAINTAINERS to:
>>>>>>
>>>>>> "L: linuxppc-dev@ozlabs.org" ??
>>>>>>
>>>>>> Kumar, Josh, Vitaly, et. al.?
>>>>>>
>>>>>>
>>>>> I personally don't care either way. I'm already subscribed to both
>>>>> lists.
>>>>>
>>>>> Makes sense to go to linuxppc-dev given the arch/powerpc migration.
>>>>>
>>>>>
>>>> I thought the -embedded list was created in the first place to keep some
>>>> of the "noise" off of -dev (i.e. "I can't get interface <foo> to work on
>>>> my custom <embedded eval board>-lookalike board, HELP!"). If people still
>>>> care about keeping that on a separate list, then we shouldn't change it.
>>>>
>>>>
>>> Yes, IIRC, that was the reason but now with the merge and low volume on this
>>> list, it makes sense to me to just get rid of -embedded.
>>>
>>>
>>>
>> Perhaps my perspective is unique, but I doubt it. I find it nice that
>> this list is low volume and not filled with endless patches about CHRP
>> and P series and open firmware syntax blah blah blah...
>>
>> No offense intended to all the people who are doing wonderful work
>> expanding the Linux universe, but for your average dude or dudette
>> working on embedded boards that happen to have a PowerPC processor, this
>> list is a pretty good forum.
>>
>
> I think the original thought was to have patches go to linuxppc-dev.
> Not necessarily all discussion.
>
> josh
>
>
True, and that makes sense. Patches should go where the right people
will see them quickly. At least two people have advocated getting rid of
the linuxppc-embedded list, though. Maybe I misunderstood.
regards,
Ben
^ permalink raw reply
* Re: [PATCH] Add platform support for the MPC837x RDB board
From: Mark A. Greer @ 2007-10-01 20:10 UTC (permalink / raw)
To: Josh Boyer; +Cc: D'Abbraccio Joe-ljd015, linuxppc-embedded
In-Reply-To: <20071001145911.77194814@weaponx.rchland.ibm.com>
On Mon, Oct 01, 2007 at 02:59:11PM -0500, Josh Boyer wrote:
> On Mon, 01 Oct 2007 15:49:22 -0400
> Ben Warren <bwarren@qstreams.com> wrote:
> > Perhaps my perspective is unique, but I doubt it. I find it nice that
> > this list is low volume and not filled with endless patches about CHRP
> > and P series and open firmware syntax blah blah blah...
> >
> > No offense intended to all the people who are doing wonderful work
> > expanding the Linux universe, but for your average dude or dudette
> > working on embedded boards that happen to have a PowerPC processor, this
> > list is a pretty good forum.
>
> I think the original thought was to have patches go to linuxppc-dev.
> Not necessarily all discussion.
That's where I started but I moved to completely getting of
linuxppc-embedded. As Ben points out, I may have gone too far.
Mark
^ permalink raw reply
* Re: [PATCH 2/2]: PCI Error Recovery: Symbios SCSI First Failure
From: Matthew Wilcox @ 2007-10-01 20:12 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev, linux-pci, linux-kernel, linux-scsi
In-Reply-To: <20070927233437.GF18686@austin.ibm.com>
On Thu, Sep 27, 2007 at 06:34:37PM -0500, Linas Vepstas wrote:
> Good catch. But no ... and I had to study this a bit. Bear with me:
I agree with the analysis which I've now snipped.
> I think the race you describe above is harmless. The first time
> that sym_eh_handler() will run, it will be with SYM_EH_ABORT,
> in it doesn't matter if we lose that, since the device is hosed
> anyway. At some later time, it will run with SYM_EH_DEVICE_RESET
> and then SYM_EH_BUS_RESET and then SYM_EH_HOST_RESET, and we won't
> miss those, since, by now, sym2_io_error_detected() will have run.
>
> So, by my reading, I'd say that init_completion() in
> sym2_io_error_detected() has to stay (although perhaps
> it should be replaced by the INIT_COMPLETION() macro.)
> Removing it will prevent correct operation on the second
> and subsequent errors.
I think the fundamental problem is that completions aren't really
supposed to be used like this. Here's one attempt at using completions
perhaps a little more the way they're supposed to be used, although now
I've written it, I wonder if we shouldn't just use a waitqueue instead.
diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.c b/drivers/scsi/sym53c8xx_2/sym_glue.c
index e8a4361..b425b89 100644
--- a/drivers/scsi/sym53c8xx_2/sym_glue.c
+++ b/drivers/scsi/sym53c8xx_2/sym_glue.c
@@ -602,6 +602,7 @@ static int sym_eh_handler(int op, char *opname, struct scsi_cmnd *cmd)
struct sym_hcb *np = SYM_SOFTC_PTR(cmd);
struct sym_ucmd *ucmd = SYM_UCMD_PTR(cmd);
struct Scsi_Host *host = cmd->device->host;
+ struct pci_dev *pdev = np->s.device;
SYM_QUEHEAD *qp;
int cmd_queued = 0;
int sts = -1;
@@ -616,9 +617,19 @@ static int sym_eh_handler(int op, char *opname, struct scsi_cmnd *cmd)
* point in hurrying; take a leisurely wait.
*/
#define WAIT_FOR_PCI_RECOVERY 35
- if (pci_channel_offline(np->s.device)) {
- int finished_reset = wait_for_completion_timeout(
- &np->s.io_reset_wait, WAIT_FOR_PCI_RECOVERY*HZ);
+ if (pci_channel_offline(pdev)) {
+ struct host_data *hostdata = shost_priv(host);
+ int finished_reset = 0;
+ init_completion(&eh_done);
+ spin_lock_irq(host->host_lock);
+ if (!hostdata->io_reset)
+ hostdata->io_reset = &eh_done;
+ if (!pci_channel_offline(pdev))
+ finished_reset = 1;
+ spin_unlock_irq(host->host_lock);
+ if (!finished_reset)
+ finished_reset = wait_for_completion_timeout(
+ hostdata->io_reset, WAIT_FOR_PCI_RECOVERY*HZ);
if (!finished_reset)
return SCSI_FAILED;
}
@@ -1396,7 +1407,6 @@ static struct Scsi_Host * __devinit sym_attach(struct scsi_host_template *tpnt,
np->maxoffs = dev->chip.offset_max;
np->maxburst = dev->chip.burst_max;
np->myaddr = dev->host_id;
- init_completion(&np->s.io_reset_wait);
/*
* Edit its name.
@@ -1842,15 +1852,12 @@ static void __devexit sym2_remove(struct pci_dev *pdev)
static pci_ers_result_t sym2_io_error_detected(struct pci_dev *pdev,
enum pci_channel_state state)
{
- struct sym_hcb *np = pci_get_drvdata(pdev);
-
/* If slot is permanently frozen, turn everything off */
if (state == pci_channel_io_perm_failure) {
sym2_remove(pdev);
return PCI_ERS_RESULT_DISCONNECT;
}
- init_completion(&np->s.io_reset_wait);
disable_irq(pdev->irq);
pci_disable_device(pdev);
@@ -1912,7 +1919,7 @@ static pci_ers_result_t sym2_io_slot_reset(struct pci_dev *pdev)
sym_name(np));
if (pci_enable_device(pdev)) {
- printk(KERN_ERR "%s: Unable to enable afer PCI reset\n",
+ printk(KERN_ERR "%s: Unable to enable after PCI reset\n",
sym_name(np));
return PCI_ERS_RESULT_DISCONNECT;
}
@@ -1953,7 +1960,14 @@ static pci_ers_result_t sym2_io_slot_reset(struct pci_dev *pdev)
static void sym2_io_resume(struct pci_dev *pdev)
{
struct sym_hcb *np = pci_get_drvdata(pdev);
- complete_all(&np->s.io_reset_wait);
+ struct Scsi_Host *shost = np->s.host;
+ struct host_data *hostdata = shost_priv(shost);
+
+ spin_lock_irq(shost->host_lock);
+ if (hostdata->io_reset)
+ complete_all(hostdata->io_reset);
+ hostdata->io_reset = NULL;
+ spin_unlock_irq(shost->host_lock);
}
static void sym2_get_signalling(struct Scsi_Host *shost)
diff --git a/drivers/scsi/sym53c8xx_2/sym_glue.h b/drivers/scsi/sym53c8xx_2/sym_glue.h
index a172cc5..b961f70 100644
--- a/drivers/scsi/sym53c8xx_2/sym_glue.h
+++ b/drivers/scsi/sym53c8xx_2/sym_glue.h
@@ -180,9 +180,6 @@ struct sym_shcb {
char chip_name[8];
struct pci_dev *device;
- /* Waiter for clearing of frozen PCI bus */
- struct completion io_reset_wait;
-
struct Scsi_Host *host;
void __iomem * ioaddr; /* MMIO kernel io address */
@@ -223,6 +220,7 @@ struct sym_device {
*/
struct host_data {
struct sym_hcb *ncb;
+ struct completion *io_reset; /* PCI error handling */
};
static inline struct sym_hcb * sym_get_hcb(struct Scsi_Host *host)
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
^ permalink raw reply related
* [PATCH] powerpc: Implement logging of unhandled signals
From: Olof Johansson @ 2007-10-01 20:32 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Implement exception-trace sysctl + support to print when a process is
killed due to unhandled signals just as i386 and x86_64 does.
Just like on x86, it can be disabled by setting the sysctl variable
debug.exception-trace, and the messages are rate limited to not create
a DoS exposure.
Signed-off-by: Olof Johansson <olof@lixom.net>
Index: 2.6.23/arch/powerpc/kernel/traps.c
===================================================================
--- 2.6.23.orig/arch/powerpc/kernel/traps.c
+++ 2.6.23/arch/powerpc/kernel/traps.c
@@ -172,11 +172,21 @@ int die(const char *str, struct pt_regs
void _exception(int signr, struct pt_regs *regs, int code, unsigned long addr)
{
siginfo_t info;
+ char fmt32[] = KERN_INFO "%s[%d]: unhandled signal %d " \
+ "at %08lx nip %08lx lr %08lx code %x\n";
+ char fmt64[] = KERN_INFO "%s[%d]: unhandled signal %d " \
+ "at %016lx nip %016lx lr %016lx code %x\n";
if (!user_mode(regs)) {
if (die("Exception in kernel mode", regs, signr))
return;
- }
+ } else if (show_unhandled_signals &&
+ unhandled_signal(current, signr) &&
+ printk_ratelimit()) {
+ printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+ current->comm, current->pid, signr,
+ addr, regs->nip, regs->link, code);
+ }
memset(&info, 0, sizeof(info));
info.si_signo = signr;
Index: 2.6.23/arch/powerpc/kernel/signal_64.c
===================================================================
--- 2.6.23.orig/arch/powerpc/kernel/signal_64.c
+++ 2.6.23/arch/powerpc/kernel/signal_64.c
@@ -64,6 +64,11 @@ struct rt_sigframe {
char abigap[288];
} __attribute__ ((aligned (16)));
+static char fmt32[] = KERN_INFO \
+ "%s[%d]: bad frame in %s: %08lx nip %08lx lr %08lx\n";
+static char fmt64[] = KERN_INFO \
+ "%s[%d]: bad frame in %s: %016lx nip %016lx lr %016lx\n";
+
/*
* Set up the sigcontext for the signal frame.
*/
@@ -315,6 +320,11 @@ badframe:
printk("badframe in sys_rt_sigreturn, regs=%p uc=%p &uc->uc_mcontext=%p\n",
regs, uc, &uc->uc_mcontext);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+ current->comm, current->pid, "rt_sigreturn",
+ uc, regs->nip, regs->link);
+
force_sig(SIGSEGV, current);
return 0;
}
@@ -398,6 +408,11 @@ badframe:
printk("badframe in setup_rt_frame, regs=%p frame=%p newsp=%lx\n",
regs, frame, newsp);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(regs->msr & MSR_SF ? fmt64 : fmt32,
+ current->comm, current->pid, "setup_rt_frame",
+ frame, regs->nip, regs->link);
+
force_sigsegv(signr, current);
return 0;
}
Index: 2.6.23/kernel/sysctl.c
===================================================================
--- 2.6.23.orig/kernel/sysctl.c
+++ 2.6.23/kernel/sysctl.c
@@ -1221,7 +1221,7 @@ static ctl_table fs_table[] = {
};
static ctl_table debug_table[] = {
-#ifdef CONFIG_X86
+#if defined(CONFIG_X86) || defined(CONFIG_PPC)
{
.ctl_name = CTL_UNNUMBERED,
.procname = "exception-trace",
Index: 2.6.23/arch/powerpc/kernel/signal_32.c
===================================================================
--- 2.6.23.orig/arch/powerpc/kernel/signal_32.c
+++ 2.6.23/arch/powerpc/kernel/signal_32.c
@@ -705,11 +705,13 @@ int handle_rt_signal32(unsigned long sig
{
struct rt_sigframe __user *rt_sf;
struct mcontext __user *frame;
+ void __user *addr;
unsigned long newsp = 0;
/* Set up Signal Frame */
/* Put a Real Time Context onto stack */
rt_sf = get_sigframe(ka, regs, sizeof(*rt_sf));
+ addr = rt_sf;
if (unlikely(rt_sf == NULL))
goto badframe;
@@ -728,6 +730,7 @@ int handle_rt_signal32(unsigned long sig
/* Save user registers on the stack */
frame = &rt_sf->uc.uc_mcontext;
+ addr = frame;
if (vdso32_rt_sigtramp && current->mm->context.vdso_base) {
if (save_user_regs(regs, frame, 0))
goto badframe;
@@ -742,6 +745,7 @@ int handle_rt_signal32(unsigned long sig
/* create a stack frame for the caller of the handler */
newsp = ((unsigned long)rt_sf) - (__SIGNAL_FRAMESIZE + 16);
+ addr = (void __user *)regs->gpr[1];
if (put_user(regs->gpr[1], (u32 __user *)newsp))
goto badframe;
@@ -762,6 +766,12 @@ badframe:
printk("badframe in handle_rt_signal, regs=%p frame=%p newsp=%lx\n",
regs, frame, newsp);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(KERN_INFO "%s[%d]: bad frame in handle_rt_signal32: "
+ "%p nip %08lx lr %08lx\n",
+ current->comm, current->pid,
+ addr, regs->nip, regs->link);
+
force_sigsegv(sig, current);
return 0;
}
@@ -886,6 +896,12 @@ long sys_rt_sigreturn(int r3, int r4, in
return 0;
bad:
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(KERN_INFO "%s[%d]: bad frame in sys_rt_sigreturn: "
+ "%p nip %08lx lr %08lx\n",
+ current->comm, current->pid,
+ rt_sf, regs->nip, regs->link);
+
force_sig(SIGSEGV, current);
return 0;
}
@@ -967,6 +983,13 @@ int sys_debug_setcontext(struct ucontext
* We kill the task with a SIGSEGV in this situation.
*/
if (do_setcontext(ctx, regs, 1)) {
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(KERN_INFO "%s[%d]: bad frame in "
+ "sys_debug_setcontext: %p nip %08lx "
+ "lr %08lx\n",
+ current->comm, current->pid,
+ ctx, regs->nip, regs->link);
+
force_sig(SIGSEGV, current);
goto out;
}
@@ -1048,6 +1071,12 @@ badframe:
printk("badframe in handle_signal, regs=%p frame=%p newsp=%lx\n",
regs, frame, newsp);
#endif
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(KERN_INFO "%s[%d]: bad frame in handle_signal32: "
+ "%p nip %08lx lr %08lx\n",
+ current->comm, current->pid,
+ frame, regs->nip, regs->link);
+
force_sigsegv(sig, current);
return 0;
}
@@ -1061,12 +1090,14 @@ long sys_sigreturn(int r3, int r4, int r
struct sigcontext __user *sc;
struct sigcontext sigctx;
struct mcontext __user *sr;
+ void __user *addr;
sigset_t set;
/* Always make any pending restarted system calls return -EINTR */
current_thread_info()->restart_block.fn = do_no_restart_syscall;
sc = (struct sigcontext __user *)(regs->gpr[1] + __SIGNAL_FRAMESIZE);
+ addr = sc;
if (copy_from_user(&sigctx, sc, sizeof(sigctx)))
goto badframe;
@@ -1083,6 +1114,7 @@ long sys_sigreturn(int r3, int r4, int r
restore_sigmask(&set);
sr = (struct mcontext __user *)from_user_ptr(sigctx.regs);
+ addr = sr;
if (!access_ok(VERIFY_READ, sr, sizeof(*sr))
|| restore_user_regs(regs, sr, 1))
goto badframe;
@@ -1091,6 +1123,12 @@ long sys_sigreturn(int r3, int r4, int r
return 0;
badframe:
+ if (show_unhandled_signals && printk_ratelimit())
+ printk(KERN_INFO "%s[%d]: bad frame in sys_sigreturn: "
+ "%p nip %08lx lr %08lx\n",
+ current->comm, current->pid,
+ addr, regs->nip, regs->link);
+
force_sig(SIGSEGV, current);
return 0;
}
Index: 2.6.23/arch/powerpc/kernel/signal.c
===================================================================
--- 2.6.23.orig/arch/powerpc/kernel/signal.c
+++ 2.6.23/arch/powerpc/kernel/signal.c
@@ -16,6 +16,12 @@
#include "signal.h"
+/* Log an error when sending an unhandled signal to a process. Controlled
+ * through debug.exception-trace sysctl.
+ */
+
+int show_unhandled_signals = 1;
+
/*
* Allocate space for the signal frame
*/
^ 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