* Re: [PATCH] Fix FEC node in 8540 ADS dts
From: Andy Fleming @ 2006-08-21 20:15 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1156189170.11326.56.camel@basalt.austin.ibm.com>
On Aug 21, 2006, at 14:39, Hollis Blanchard wrote:
> On Mon, 2006-08-21 at 14:29 -0500, Andy Fleming wrote:
>>
>> diff --git a/arch/powerpc/boot/dts/mpc8540ads.dts
>> b/arch/powerpc/boot/dts/mpc8540ads.dts
>> index 93d2c2d..5f41c1f 100644
>> --- a/arch/powerpc/boot/dts/mpc8540ads.dts
>> +++ b/arch/powerpc/boot/dts/mpc8540ads.dts
>> @@ -83,11 +83,11 @@
>> reg = <1>;
>> device_type = "ethernet-phy";
>> };
>> - ethernet-phy@2 {
>> - linux,phandle = <2452002>;
>> + ethernet-phy@3 {
>> + linux,phandle = <2452003>;
>
> Again, doesn't DTC assign linux,phandle properties as needed (i.e.
> when
> the node is referenced with & syntax)?
That's what I hear. I think this would be a good place for using
that, but I'm waiting for someone to determine whether some sort of
labeling system is going to be added, first. As it doesn't require
changes to u-boot or linux, it's an easy fix for a later time.
I will, of course, accede to popular opinion. But I'd rather change
all the phandles in exactly the same way, and I feel that the
notation gets clunky when seen iterated in a table (as shown in Jon's
patch for that change).
Andy
^ permalink raw reply
* Re: [PATCH] Add adder87x board support to 2.6.x
From: Mark A. Greer @ 2006-08-21 20:43 UTC (permalink / raw)
To: Bryan O'Donoghue; +Cc: linuxppc-embedded
In-Reply-To: <20060820203649.4dbf89a6@localhost.localdomain>
On Sun, Aug 20, 2006 at 08:36:49PM +0100, Bryan O'Donoghue wrote:
> Greetings all.
>
> This set of patches adds support for the Analogue & Micro Adder87x to Linux.
>
> The port is based on mpc885ads in the 2.6.18-rc4 tree.
> The patches are very simple really consisting of a stripped down version of
> mpc885ads renamed to adder87x*blah, a defconfig and appropriate entries in
> arch/ppc/Kconfig, arch/ppc/platforms/Makefile and include/asm-ppc/mpc8xx.h.
>
> I've spent a bit of time testing this out, and I'm reasonably happy that this
> should be useful to others using this development board.
>
>
> Signed-off-by: Bryan O'Donoghue <bodonoghue@codehermit.ie>
Bryan,
If you're not already on the linuxppc-dev mailing list, you should be.
The 'ppc' tree is deprecated and all new work should be happening in the
'powerpc' tree (as in arch/powerpc).
The odds of this being accepted are slim but either way, you should read
the mail archive and get involved in the powerpc migration.
Mark
^ permalink raw reply
* NAPI documentation
From: Stephen Hemminger @ 2006-08-21 20:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: akpm, netdev, James K Lewis, Jonathan Corbet, linux-kernel,
linuxppc-dev, Jens Osterkamp, Linas, Jeff Garzik, David Miller
In-Reply-To: <200608201948.20596.arnd@arndb.de>
I took this opportunity to get a start on improving NAPI documentation.
I mashed together the short text about NAPI (with permission) from lwn.net
and the existing NAPI-HOWTO, to make a page on the Linux net wiki.
I took the liberty of removing some of the bits that were out of date, or referred
to old Becker code. It still needs lots of editing to be presentable.
Please edit and improve
http://linux-net.osdl.org/index.php/NAPI
When the page is in good shape, I will de-wiki it to place in kernel doc tree.
^ permalink raw reply
* RE: Linux hanging on Xilinx SystemACE
From: Clint Thomas @ 2006-08-21 20:45 UTC (permalink / raw)
To: Keith J Outwater, linuxppc-embedded
In-Reply-To: <OF66C0423D.E933F8BD-ON072571CC.0077CC69-072571CC.007906BE@mck.us.ray.com>
The adapter.c file fixed the problem, however running in polling I/O
mode is far too slow. Since this is not an option for successful
operation of our machine, do you know of a driver fix for this problem?
Perhaps a newer version of the linux source tree is necessary. I'm using
the Linuxppc_2_4_devel tree available from bkbits/mvista. Thanks for the
help so far!
Clint Thomas
-----Original Message-----
From: linuxppc-embedded-bounces+cthomas=3Dsoneticom.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+cthomas=3Dsoneticom.com@ozlabs.org] On
Behalf Of Keith J Outwater
Sent: Wednesday, August 16, 2006 6:02 PM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Linux hanging on Xilinx SystemACE
Clint,
> Using the powerpc development tree of Linux 2.4, I am trying to boot=20
> my
system from CompactFlash using Xilinx SystemACE. My compact flash card
has two partitions, a 16MB FAT16 that holds the combination FPGA image /
Linux Kernel ELF file, and an Ext2 partition that holds the root file
system.=20
The system starts the boot process, uncompresses the Linux kernel and
begins loading drivers. Part way into this process, it conducts a
partition check of the drive being reported to it by SystemACE, however,
it hangs at that point. No kernel panic, no error message, it simply
hangs. Here is the output at that point...
>=20
> Partition check:
> xsysacea:
>=20
> what I am trying to find out is if this problem has been seen/fixed in
the past? or did I format the CF card incorrectly?
>=20
I have a system that uses the SystemAce in a similar way. I was also
having lockups. After a lot of digging, I found a patch by John Masters
(e-mail unknown) to the MontaVista SystemAce driver in the 2.4 kernel
that disables the use of interrupts and runs the SystemAce in a polled
mode.=20
Performance is not that great, but at least it does not crash with the
patch. As I recall, the reason that the unpatched driver crashed is
that the SystemAce is issuing more than one interrupt upon completion of
a sector read or write. Apparently, the Xilinx ML300 board works fine
without this patch while other eval boards like the Memec DS-BD-2VPxx
crash without the patch.
This still may not be your problem, but the patch may help later on.
I've attached the patched file. The file is from
./drivers/block/xilinx_sysace/adapter.c in the 2.4.30 from MontaVista.
Keith
^ permalink raw reply
* RE: Linux hanging on Xilinx SystemACE
From: Keith J Outwater @ 2006-08-21 21:16 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <3C02138692C13C4BB675FE7EA240952918DE10@bluefin.Soneticom.local>
> The adapter.c file fixed the problem, however running in polling I/O
> mode is far too slow. Since this is not an option for successful
> operation of our machine, do you know of a driver fix for this problem?
> Perhaps a newer version of the linux source tree is necessary. I'm using
> the Linuxppc_2_4_devel tree available from bkbits/mvista. Thanks for the
> help so far!
Sorry, I am not aware of any driver fix to make interrupt mode work.
Unfortunately, the use of the SystemACE under Linux for access to CF
file systems appears to be a niche application, so it does not receive
a lot of attention.
I recall someone on the net stating that they had observed the SystemAce
issuing more than one interrupt in response to sector transfers. The
SystemACE is a strange beast (as you may have already observed!) and
perhaps it is being configured in hardware or software differently in your
design versus the Xilinx ML300 design.
For my particular application, I used the CF card to hold a root
filesystem image that was placed in RAM on boot, so I did not see a big
hit during operation. Basically, the mediocre performance of the driver
in polled mode was good enough for me. Maybe some day I'll return to that
problem, but right now other issues are more pressing. As I stated
originally, the SystemACE driver appears to work fine in interrupt
mode for ML300 boards, but dies with Memec eval boards. Perhaps you can
download the relevant designs for each board and compare them. If you
do this, be sure to check the schematics as well as the configuration
of the SystemACE and the interrupt controller IP blocks in the Xilinx EDK
tool. Maybe this will uncover something obvious. Also, if MontaVista
supports their kernel on the Memec board, they may have seen this problem
and maybe even have fixed it. I also used the mvista kernel and there is
support for a Memec board in there, although I don't know the exact part
number.
Keith
>
> Clint Thomas
>
> -----Original Message-----
> From: linuxppc-embedded-bounces+cthomas=soneticom.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+cthomas=soneticom.com@ozlabs.org] On
> Behalf Of Keith J Outwater
> Sent: Wednesday, August 16, 2006 6:02 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Linux hanging on Xilinx SystemACE
>
> Clint,
>
> > Using the powerpc development tree of Linux 2.4, I am trying to boot
> > my
> system from CompactFlash using Xilinx SystemACE. My compact flash card
> has two partitions, a 16MB FAT16 that holds the combination FPGA image /
> Linux Kernel ELF file, and an Ext2 partition that holds the root file
> system.
> The system starts the boot process, uncompresses the Linux kernel and
> begins loading drivers. Part way into this process, it conducts a
> partition check of the drive being reported to it by SystemACE, however,
> it hangs at that point. No kernel panic, no error message, it simply
> hangs. Here is the output at that point...
> >
> > Partition check:
> > xsysacea:
> >
> > what I am trying to find out is if this problem has been seen/fixed in
> the past? or did I format the CF card incorrectly?
> >
>
> I have a system that uses the SystemAce in a similar way. I was also
> having lockups. After a lot of digging, I found a patch by John Masters
> (e-mail unknown) to the MontaVista SystemAce driver in the 2.4 kernel
> that disables the use of interrupts and runs the SystemAce in a polled
> mode.
> Performance is not that great, but at least it does not crash with the
> patch. As I recall, the reason that the unpatched driver crashed is
> that the SystemAce is issuing more than one interrupt upon completion of
> a sector read or write. Apparently, the Xilinx ML300 board works fine
> without this patch while other eval boards like the Memec DS-BD-2VPxx
> crash without the patch.
>
> This still may not be your problem, but the patch may help later on.
>
> I've attached the patched file. The file is from
> ./drivers/block/xilinx_sysace/adapter.c in the 2.4.30 from MontaVista.
>
> Keith
^ permalink raw reply
* Re: [PATCH] fix gettimeofday vs. update_gtod race
From: Nathan Lynch @ 2006-08-21 21:25 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <20060817204712.GD354@localdomain>
Nathan Lynch wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2006-08-16 at 19:18 -0500, Nathan Lynch wrote:
> >
> > > No? I didn't find anything about mftb having synchronizing
> > > behavior. How should we ensure that temp_varp is assigned before
> > > reading the timebase?
> >
> > I sync an isync would be enough.
>
> I see, thanks.
Actually, after checking Book 2 and discussing with some other folks
I'm not so sure -- isync "may complete before storage accesses
associated with instructions preceding the isync instruction have been
performed."
^ permalink raw reply
* ML403: module make fails with interesting error
From: Wade Maxfield @ 2006-08-21 21:28 UTC (permalink / raw)
To: ppc
[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]
I created an NFS disk using devrocket 2.03, copied the kernel image from a
devrocket build to the system.ace. I booted the ml403 board and did an nfs
mount. I copied the kernel directory created under the devrocket
2.03kernel project into /usr/src/linux
I created a simple module:
-----------------------------------------------------------------------------------------------------------------
root@ml403:/home/moduletest# cat moduletest.c
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/module.h>
MODULE_DESCRIPTION("Test Kernel Module");
MODULE_AUTHOR("wade maxfield (maxfield@ctelcom.net)");
MODULE_LICENSE("$LICENSE$");
static int moduletest_init_module(void)
{
printk( KERN_DEBUG "Module moduletest init\nHello World!\n" );
return 0;
}
static void moduletest_exit_module(void)
{
printk( KERN_DEBUG "Module moduletest exit\nGoodbye Cruel World!\n"
);
}
module_init(moduletest_init_module);
module_exit(moduletest_exit_module);
---------------------------------------------------------------------------------------------------------------------------
This has compiled under RHEL 4.0 and worked.
if I go do a build on the ml403 board I get the following (ignore the
time problems)
----------------------------------------------------------------------------------------------------------------------
root@ml403:/home/moduletest# make
make: Warning: File `Makefile' has modification time 1.2e+09 s in the future
make -C /lib/modules/2.6.10_mvl401-ml40x/build SUBDIRS=/home/moduletest
modules
make[1]: Entering directory `/usr/src/linux'
Makefile:503: .config: No such file or directory
make[1]: Warning: File `/usr/src/linux/arch/ppc/Makefile' has modification
time 1.2e+09 s in the future
make[2]: Warning: File `scripts/Makefile.lib' has modification time
1.1e+09s in the future
CC [M] /home/moduletest/moduletest.o
/bin/sh: line 1: scripts/basic/fixdep: cannot execute binary file
make[2]: *** [/home/moduletest/moduletest.o] Error 126
make[1]: *** [_module_/home/moduletest] Error 2
make[1]: Leaving directory `/usr/src/linux'
make: *** [default] Error 2
----------------------------------------------------------------------------------------------------------
I think that "fixdep" was created as x86. Any suggestions as to getting
fixdep to be powerpc executable?
thanks,
wade
[-- Attachment #2: Type: text/html, Size: 2849 bytes --]
^ permalink raw reply
* Re: booting with BootX corrupts memory
From: Benjamin Herrenschmidt @ 2006-08-21 21:31 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Niels Kristian Bech Jensen
In-Reply-To: <20060821121708.GA28713@aepfle.de>
> > No, now I dont even get console= output on serial console.
>
> It doesnt work on a 7200, butit works on a beige G3.
> But later it locks up in 'PM: Adding info for No Bus:target0:0',
> after mesh init. This one is likely unrelated.
Depends.... does it work if you netboot a zImage.coff ?
Ben.
^ permalink raw reply
* ML40X, ppc 405 crash
From: Wade Maxfield @ 2006-08-21 21:34 UTC (permalink / raw)
To: ppc
[-- Attachment #1: Type: text/plain, Size: 6490 bytes --]
I was running NFS on ML40X. I did a "updatedb" and then immediately,
"locate fixdep"
I got the following crash
root@ml403:/home/moduletest# updatedb
locate fixdep
eth0: Could not transmit buffer.
eth0: Could not transmit buffer.
eth0: Could not transmit buffer.
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C01D0F74 LR: C01D0910 SP: C28B1930 REGS: c28b1880 TRAP: 0300 Not
tainted
MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000004, DSISR: 00800000
TASK = c0b034c0[5097] 'frcode' THREAD: c28b0000
Last syscall: 234
GPR00: 00000000 C28B1930 C0B034C0 C35E3200 C03CC380 C276E810 000005E8
C3CE8880
GPR08: 00000002 00000000 C3CE890C 00000000 33003599 10018E04 100C3208
C02DCE08
GPR16: C00DB1CC C02DCE08 00000002 0000000A C28B1DF8 C02E0000 C02A0000
C3A30940
GPR24: 00000000 00000000 00000000 C3A30940 00000000 C35E3200 C3CE8880
C03A8800
NIP [c01d0f74] pfifo_fast_dequeue+0x40/0x74
LR [c01d0910] qdisc_restart+0x30/0x2b4
Call trace:
[c01c1e94] dev_queue_xmit+0x264/0x318
[c01dd8dc] ip_finish_output+0x140/0x2cc
[c01dddb0] ip_queue_xmit+0x348/0x53c
[c01ef628] tcp_transmit_skb+0x324/0x7f8
[c01f05fc] tcp_write_xmit+0x14c/0x31c
[c01ed360] __tcp_data_snd_check+0xc8/0xfc
[c01ed9a4] tcp_rcv_established+0x2c0/0x8ac
[c01f7250] tcp_v4_do_rcv+0x184/0x374
[c01f7d9c] tcp_v4_rcv+0x95c/0xa4c
[c01da000] ip_local_deliver+0x120/0x298
[c01da86c] ip_rcv+0x400/0x508
[c01c2614] netif_receive_skb+0x24c/0x2fc
[c01c276c] process_backlog+0xa8/0x1a0
[c01c2908] net_rx_action+0xa4/0x1cc
[c001bef4] ___do_softirq+0x7c/0x114
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds..
-----------------------------------------------------------------------------------------------------------------------------------------------------
Here is the kernel build and boot information. (I use the demo compact
flash disk image shipped with the ml403 as an intermediate. I've not yet
been able to get a small enough build to fit on 412 meg using your tools.)
Linux version 2.6.10_mvl401-ml40x (root@localhost.localdomain) (gcc version
3.4.3 (MontaV
ista 3.4.3-25.0.107.0601076 2006-07-21)) #1 Fri Aug 18 14:43:45 CDT 2006
Xilinx ML40x Reference System (Virtex-4 FX)
Port by MontaVista Software, Inc. (source@mvista.com)
Built 1 zonelists
Kernel command line: console=ttyS0,115200 ip=on root=/dev/xsysace2 rw
Xilinx INTC #0 at 0xD1000FC0 mapped to 0xFDFFEFC0
PID hash table entries: 512 (order: 9, 8192 bytes)
hr_time_init: arch_to_nsec = 6990506, nsec_to_arch = 1288490158
Console: colour dummy device 80x25
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 61824k available (2244k kernel code, 640k data, 140k init, 0k
highmem)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
spawn_desched_task(00000000)
desched cpu_callback 3/00000000
ksoftirqd started up.
desched cpu_callback 2/00000000
desched thread 0 started up.
NET: Registered protocol family 16
Registering platform device 'xilinx_emac.0'. Parent at platform
Registering platform device 'xilinx_fb.0'. Parent at platform
Registering platform device 'xilinx_sysace.0'. Parent at platform
Registering platform device 'xilinx_iic.0'. Parent at platform
Registering platform device 'xilinx_gpio.0'. Parent at platform
Registering platform device 'xilinx_gpio.1'. Parent at platform
Registering platform device 'xilinx_gpio.2'. Parent at platform
Registering platform device 'xilinx_ps2.0'. Parent at platform
Registering platform device 'xilinx_ps2.1'. Parent at platform
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
Console: switching to colour frame buffer device 80x30
xgpio #0 at 0x90000000 mapped to 0xC505C000
xgpio #1 at 0x90001000 mapped to 0xC505E000
xgpio #2 at 0x90002000 mapped to 0xC5060000
xilinx_ps2 #0 at 0xA9000000 mapped to 0xC5062000
xilinx_ps2 #1 at 0xA9001000 mapped to 0xC5064000
Serial: 8250/16550 driver $Revision: 1.90 $ 5 ports, IRQ sharing disabled
Registering platform device 'serial8250'. Parent at platform
ttyS0 at MMIO 0x0 (irq = 9) is a 16450
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
loop: loaded (max 8 devices)
elevator: using anticipatory as default io scheduler
System ACE at 0xCF000000 mapped to 0xC5066000, irq=3, 500472KB
xsysace: xsysace1 xsysace2
PPP generic driver version 2.4.2
PPP Deflate Compression module registered
NET: Registered protocol family 24
xemac 0: using fifo mode.
eth0: Xilinx EMAC #0 at 0x60000000 mapped to 0xC5068000, irq=0
i2c /dev entries driver
xilinx_iic.0 #0 at 0xA8000000 mapped to 0xC506E000, irq=6
mice: PS/2 mouse device common for all mice
atkbd.c: keyboard reset failed on xilinxps2/serio0
atkbd.c: keyboard reset failed on xilinxps2/serio1
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP: Hash tables configured (established 4096 bind 8192)
NET: Registered protocol family 1
NET: Registered protocol family 17
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 0.0.0.0, my address is 172.17.6.49
IP-Config: Complete:
device=eth0, addr=172.17.6.49, mask=255.255.254.0, gw=172.17.7.254,
host=172.17.6.49, domain=precisiondrilling.com, nis-domain=(none),
bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 140k init
INIT: version 2.78 booting
Activating swap...
Checking all file systems...
fsck 1.27 (8-Mar-2002)
Calculating module dependencies... depmod: QM_MODULES: Function not
implemented
done.
Loading modules:
modprobe: QM_MODULES: Function not implemented
Mounting local filesystems...
nothing was mounted
Cleaning: /etc/network/ifstate.
Setting up IP spoofing protection: rp_filter.
Disable TCP/IP Explicit Congestion Notification: done.
Configuring network interfaces: done.
Starting portmap daemon: portmap.
Starting dhcpcd on eth0
Running ntpdate to synchronize clock.
Cleaning: /tmp /var/lock /var/rundhcpcd[775]: dhcpConfig: ioctl SIOCADDRT:
File exists
.
INIT: Entering runlevel: 3
Starting kernel log daemon: klogd.
Starting system log daemon: syslogd.
Hostname: ml403.
Creating barrier for shutdown
Starting X11 session for user 'linux'
Welcome to the ML403 Evaluation Board
(C) 2004 Xilinx, Inc - Systems Engineering Group
[-- Attachment #2: Type: text/html, Size: 7617 bytes --]
^ permalink raw reply
* Re: [PATCH] fix gettimeofday vs. update_gtod race
From: Benjamin Herrenschmidt @ 2006-08-21 21:43 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <20060821212555.GC9828@localdomain>
On Mon, 2006-08-21 at 16:25 -0500, Nathan Lynch wrote:
> Nathan Lynch wrote:
> > Benjamin Herrenschmidt wrote:
> > > On Wed, 2006-08-16 at 19:18 -0500, Nathan Lynch wrote:
> > >
> > > > No? I didn't find anything about mftb having synchronizing
> > > > behavior. How should we ensure that temp_varp is assigned before
> > > > reading the timebase?
> > >
> > > I sync an isync would be enough.
> >
> > I see, thanks.
>
> Actually, after checking Book 2 and discussing with some other folks
> I'm not so sure -- isync "may complete before storage accesses
> associated with instructions preceding the isync instruction have been
> performed."
Of sure, I was thinking about isync preventing mftb from being executed
and we can have a proper data dependency. Anyway, that's not necessary,
I've looked at the code and we no longer need to pass the tb value in
(it's historical). Thus we can just move the mftb in the protected area
and maybe with a twi/isync pair make sure we got the gtod pointer before
we do the mftb
Ben.
^ permalink raw reply
* ML403, ppc 405 crash
From: Wade Maxfield @ 2006-08-21 21:45 UTC (permalink / raw)
To: ppc
[-- Attachment #1: Type: text/plain, Size: 1654 bytes --]
I tried it again. This time I put updatedb in background. I'm running an
nfs mount. I tried doing a make to get fixdep built while updatedb was
running in background:
bash-2.05b# eth0: Could not transmit buffer.
eth0: Could not transmit buffer.
eth0: Could not transmit buffer.
protocol 0800 is buggy, dev eth0
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C01C2744 LR: C01C276C SP: C2E25C90 REGS: c2e25be0 TRAP: 0300 Not
tainted
MSR: 00021030 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000004, DSISR: 00800000
TASK = c2cf6170[1027] 'frcode' THREAD: c2e24000
Last syscall: 234
GPR00: 00021030 C2E25C90 C2CF6170 C3BF4480 C03CC380 C3190810 000005E8
C3CE8880
GPR08: 00000003 00000000 00000008 00000000 35005599 10018E04 100C3248
C02DCE08
GPR16: C00DB1CC C02DCE08 00000002 00000004 C2E25DF8 C02E0000 C02A0000
C2E25CC8
GPR24: 000254C8 C02ED728 C02ED750 00000040 00000000 C03A8800 00000001
C02ED734
NIP [c01c2744] process_backlog+0x80/0x1a0
LR [c01c276c] process_backlog+0xa8/0x1a0
Call trace:
[c01c2908] net_rx_action+0xa4/0x1cc
[c001bef4] ___do_softirq+0x7c/0x114
[c001bfc4] __do_softirq+0x38/0x64
[c001c080] do_softirq+0x58/0x60
[c001c0fc] local_bh_enable+0x74/0x80
[c021f328] __rpc_execute+0x2c0/0x3d4
[c00dab38] nfs_execute_write+0x3c/0x60
[c00db084] nfs_flush_list+0x528/0x550
[c00db1b8] nfs_flush_inode+0x10c/0x120
[c00dbc44] nfs_sync_inode+0x54/0xb4
[c00d1660] nfs_file_flush+0x7c/0xf0
[c005bbbc] filp_close+0xa0/0xd8
[c00182f0] put_files_struct+0xb0/0x130
[c0018ab8] do_exit+0x1c0/0xda8
[c0019714] do_group_exit+0x38/0xf8
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds..
[-- Attachment #2: Type: text/html, Size: 1904 bytes --]
^ permalink raw reply
* Re: NAPI documentation
From: David Miller @ 2006-08-21 22:05 UTC (permalink / raw)
To: shemminger
Cc: akpm, arnd, netdev, jklewis, corbet, linux-kernel, linuxppc-dev,
Jens.Osterkamp, jgarzik
In-Reply-To: <20060821134053.7225987b@dxpl.pdx.osdl.net>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Mon, 21 Aug 2006 13:40:53 -0700
> Please edit and improve
> http://linux-net.osdl.org/index.php/NAPI
>
> When the page is in good shape, I will de-wiki it to place in kernel doc tree.
How do I edit the introduction paragraphs at the top? I want to edit
this sentence since it sounds awful:
NAPI ("New API") is a modification to the packet process, ...
I want to change "packet process" to something more descriptive
and accurate.
^ permalink raw reply
* Re: NAPI documentation
From: Stephen Hemminger @ 2006-08-21 22:09 UTC (permalink / raw)
To: David Miller
Cc: akpm, arnd, netdev, jklewis, corbet, linux-kernel, linuxppc-dev,
Jens.Osterkamp, jgarzik
In-Reply-To: <20060821.150509.111198790.davem@davemloft.net>
On Mon, 21 Aug 2006 15:05:09 -0700 (PDT)
David Miller <davem@davemloft.net> wrote:
> From: Stephen Hemminger <shemminger@osdl.org>
> Date: Mon, 21 Aug 2006 13:40:53 -0700
>
> > Please edit and improve
> > http://linux-net.osdl.org/index.php/NAPI
> >
> > When the page is in good shape, I will de-wiki it to place in kernel doc tree.
>
> How do I edit the introduction paragraphs at the top?
Click edit on wiki and it is the first sentence.
> I want to edit
> this sentence since it sounds awful:
>
> NAPI ("New API") is a modification to the packet process, ...
>
> I want to change "packet process" to something more descriptive
> and accurate.
>
Yes.
Also, does Jamal have a link to his UKUUG paper?
--
Stephen Hemminger <shemminger@osdl.org>
All non-trivial abstractions, to some degree, are leaky.
^ permalink raw reply
* Re: NAPI documentation
From: David Miller @ 2006-08-21 22:17 UTC (permalink / raw)
To: shemminger
Cc: akpm, arnd, netdev, jklewis, corbet, linux-kernel, linuxppc-dev,
Jens.Osterkamp, jgarzik
In-Reply-To: <20060821150935.0d59791b@localhost.localdomain>
From: Stephen Hemminger <shemminger@osdl.org>
Date: Mon, 21 Aug 2006 15:09:35 -0700
> Click edit on wiki and it is the first sentence.
Thanks a lot.
> Also, does Jamal have a link to his UKUUG paper?
I don't think there is a copy online right now.
^ permalink raw reply
* ML40x, ppc 405 crash
From: Wade Maxfield @ 2006-08-21 22:20 UTC (permalink / raw)
To: ppc
[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]
I was trying to fix the problem with fixdep not being executable. I was
on the ml403, and have the kernel directory copied into /usr/src/linux and
/usr/src/linux-2.6.10_mvl401:
bash-2.05b# date
Thu Jan 1 00:28:20 UTC 1970
bash-2.05b# date --set "17:11 Aug 21,2006"
Mon Aug 21 17:11:00 UTC 2006
bash-2.05b# date
Mon Aug 21 17:11:03 UTC 2006
bash-2.05b# make clean
CLEAN drivers/char
CLEAN drivers/video/logo
CLEAN init
CLEAN kernel
CLEAN lib
CLEAN usr
CLEAN include/asm-ppc/offsets.h
arch/ppc/kernel/asm-offsets.s.tmp_gas_check vmlinux
System.map
bash-2.05b# make config
HOSTCC scripts/basic/fixdep
eth0: Could not transmit buffer.
eth0: Could not transmit buffer.
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: C01D0F74 LR: C01D0910 SP: C02ABAE0 REGS: c02aba30 TRAP: 0300 Not
tainted
MSR: 00029030 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000004, DSISR: 00800000
TASK = c0274710[0] 'swapper' THREAD: c02aa000
Last syscall: 120
GPR00: 00000000 C02ABAE0 C0274710 C3679BC0 C03CC380 C33D6010 000005E8
C3CE8880
GPR08: 00000002 00000000 C3CE890C 00000000 33003099 10018E04 100C3248
C02DCE08
GPR16: C00DB1CC C02DCE08 00000002 00000004 FFFFFFFF C02E0000 C02A0000
C3AEC540
GPR24: 00000000 00000000 00000000 C3AEC540 00000000 C3679BC0 C3CE8880
C03A8800
NIP [c01d0f74] pfifo_fast_dequeue+0x40/0x74
LR [c01d0910] qdisc_restart+0x30/0x2b4
Call trace:
[c01c1e94] dev_queue_xmit+0x264/0x318
[c01dd8dc] ip_finish_output+0x140/0x2cc
[c01dddb0] ip_queue_xmit+0x348/0x53c
[c01ef628] tcp_transmit_skb+0x324/0x7f8
[c01f05fc] tcp_write_xmit+0x14c/0x31c
[c01ed360] __tcp_data_snd_check+0xc8/0xfc
[c01ed9a4] tcp_rcv_established+0x2c0/0x8ac
[c01f7250] tcp_v4_do_rcv+0x184/0x374
[c01f7d9c] tcp_v4_rcv+0x95c/0xa4c
[c01da000] ip_local_deliver+0x120/0x298
[c01da86c] ip_rcv+0x400/0x508
[c01c2614] netif_receive_skb+0x24c/0x2fc
[c01c276c] process_backlog+0xa8/0x1a0
[c01c2908] net_rx_action+0xa4/0x1cc
[c001bef4] ___do_softirq+0x7c/0x114
Kernel panic - not syncing: Aiee, killing interrupt handler!
<0>Rebooting in 180 seconds..
[-- Attachment #2: Type: text/html, Size: 2479 bytes --]
^ permalink raw reply
* [PATCH] windfarm_smu_sat.c: simplify around i2c_add_driver()
From: Alexey Dobriyan @ 2006-08-21 23:22 UTC (permalink / raw)
To: Andrew Morton; +Cc: linuxppc-dev
Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
---
drivers/macintosh/windfarm_smu_sat.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
--- a/drivers/macintosh/windfarm_smu_sat.c
+++ b/drivers/macintosh/windfarm_smu_sat.c
@@ -397,12 +397,7 @@ static int wf_sat_detach(struct i2c_clie
static int __init sat_sensors_init(void)
{
- int err;
-
- err = i2c_add_driver(&wf_sat_driver);
- if (err < 0)
- return err;
- return 0;
+ return i2c_add_driver(&wf_sat_driver);
}
static void __exit sat_sensors_exit(void)
^ permalink raw reply
* Re: [RFC] HOWTO use NAPI to reduce TX interrupts
From: Linas Vepstas @ 2006-08-21 23:52 UTC (permalink / raw)
To: Arnd Bergmann
Cc: akpm, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp, Jeff Garzik, David Miller, Stephen Hemminger
In-Reply-To: <200608191325.19557.arnd@arndb.de>
On Sat, Aug 19, 2006 at 01:25:18PM +0200, Arnd Bergmann wrote:
>
> What is the best way to treat the IRQ mask for TX interrupts?
> I guess it should be roughly:
>
> - off when we expect ->poll() to be called, i.e. after calling
> netif_rx_schedule() or returning after a partial rx from poll().
Under what circumstance does one turn TX interrupts back on?
I couldn't quite figure that out.
--linas
^ permalink raw reply
* Re: [RFC] HOWTO use NAPI to reduce TX interrupts
From: David Miller @ 2006-08-21 23:56 UTC (permalink / raw)
To: linas
Cc: akpm, arnd, netdev, jklewis, linux-kernel, linuxppc-dev,
Jens.Osterkamp, jgarzik, shemminger
In-Reply-To: <20060821235244.GJ5427@austin.ibm.com>
From: linas@austin.ibm.com (Linas Vepstas)
Date: Mon, 21 Aug 2006 18:52:44 -0500
> Under what circumstance does one turn TX interrupts back on?
> I couldn't quite figure that out.
Don't touch interrupts until both RX and TX queue work is
fullydepleted. You seem to have this notion that RX and TX interrupts
are seperate. They aren't, even if your device can generate those
events individually. Whatever interrupt you get, you shut down all
interrupt sources and schedule the ->poll(). Then ->poll() does
something like:
all_tx_completion_work();
ret = as_much_rx_work_as_budget_and_quota_allows();
if (!ret)
reenable_interrupts_and_complet_napi_poll();
You always run the TX completion work fully, then you do the RX work
within the quota/budget.
See the tg3 driver for details, really...
^ permalink raw reply
* Re: [PATCH 2/4]: powerpc/cell spidernet low watermark patch.
From: Linas Vepstas @ 2006-08-22 0:13 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: arnd, netdev, jklewis, linux-kernel, linuxppc-dev, Jens.Osterkamp,
David Miller
In-Reply-To: <1155962022.5803.68.camel@localhost.localdomain>
On Sat, Aug 19, 2006 at 02:33:42PM +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2006-08-18 at 18:45 -0500, Linas Vepstas wrote:
> > On Fri, Aug 18, 2006 at 06:29:42PM -0500, linas wrote:
> > >
> > > I don't understand what you are saying. If I call the transmit
> > > queue cleanup code from the poll() routine, nothing hapens,
> > > because the kernel does not call the poll() routine often
> > > enough. I've stated this several times.
> >
> > OK, Arnd gave me a clue stick. I need to call the (misnamed)
> > netif_rx_schedule() from the tx interrupt in order to get
> > this to work. That makes sense, and its easy, I'll send the
> > revised patch.. well, not tonight, but shortly.
>
> You might not want to call it all the time though... You need some
> interrupt mitigation and thus a timer that calls netif_rx_schedule()
> might be of some use still...
Well, again, the whole point of a low-watermark interrupt is to
get zero of them when the system is working correctly; they're
self-mitigating by design.
-------------
Anyway, I tried the suggestion, but am getting less-than-ideal
results.
To recap: my original patch did this:
spider_interrupt_handler(struct whatever *) {
...
if (tx_interrupt)
schedule_work (tx_cleanup_handler)
}
which David Miller objected to. Once I understood the why
(sorry for not getting it right away), I then replaced the
above with the below, which is what I think everyone wanted:
spider_interrupt_handler(struct whatever *) {
...
if (tx_interrupt)
netif_rx_schedule(netdev);
}
spidernet_poll(stuct whatever *) {
tx_cleanup_handler(txring);
// rx_stuff too ...
}
I was expecting this to be a no-op from the performance
point of view. Instead, I get a fairly dramatic (11%) slowdown:
the first patch runs in the 785-805 Mbits/sec range, while
the second patch runs in the 705-715 Mbits/sec range.
I am surprised, ad don't understand why this would be so.
For the record, the alternate patch is below.
----
Index: linux-2.6.18-rc2/drivers/net/spider_net.c
===================================================================
--- linux-2.6.18-rc2.orig/drivers/net/spider_net.c 2006-08-21 16:59:33.000000000 -0500
+++ linux-2.6.18-rc2/drivers/net/spider_net.c 2006-08-21 17:15:28.000000000 -0500
@@ -1087,6 +1090,8 @@ spider_net_poll(struct net_device *netde
int packets_to_do, packets_done = 0;
int no_more_packets = 0;
+ spider_net_cleanup_tx_ring(card);
+
packets_to_do = min(*budget, netdev->quota);
while (packets_to_do) {
@@ -1495,16 +1500,16 @@ spider_net_interrupt(int irq, void *ptr,
if (!status_reg)
return IRQ_NONE;
- if (status_reg & SPIDER_NET_RXINT ) {
+ if (status_reg & SPIDER_NET_RXINT) {
spider_net_rx_irq_off(card);
netif_rx_schedule(netdev);
}
- if (status_reg & SPIDER_NET_TXINT ) {
- spider_net_cleanup_tx_ring(card);
- netif_wake_queue(netdev);
- }
- if (status_reg & SPIDER_NET_ERRINT )
+ /* Call rx_schedule from the tx interrupt, so that NAPI poll runs. */
+ if (status_reg & SPIDER_NET_TXINT)
+ netif_rx_schedule(netdev);
+
+ if (status_reg & SPIDER_NET_ERRINT)
spider_net_handle_error_irq(card, status_reg);
/* clear interrupt sources */
^ permalink raw reply
* Re: [RFC] HOWTO use NAPI to reduce TX interrupts
From: Roland Dreier @ 2006-08-22 0:29 UTC (permalink / raw)
To: David Miller
Cc: akpm, arnd, netdev, jklewis, linux-kernel, linuxppc-dev,
Jens.Osterkamp, jgarzik, shemminger
In-Reply-To: <20060821.165616.107936004.davem@davemloft.net>
David> Don't touch interrupts until both RX and TX queue work is
David> fullydepleted. You seem to have this notion that RX and TX
David> interrupts are seperate. They aren't, even if your device
David> can generate those events individually. Whatever interrupt
David> you get, you shut down all interrupt sources and schedule
David> the ->poll(). Then ->poll() does something like:
This is a digression from spidernet, but what if a device is able to
generate separate MSIs for TX and RX? Some people from IBM have
suggested that it is beneficial for throughput to handle TX work and
RX work for IP-over-InfiniBand in parallel on separate CPUs, and
handling everything through the ->poll() method would defeat this.
- R.
^ permalink raw reply
* Re: [PATCH 2/4]: powerpc/cell spidernet low watermark patch.
From: David Miller @ 2006-08-22 0:30 UTC (permalink / raw)
To: linas; +Cc: arnd, jklewis, linux-kernel, linuxppc-dev, netdev, Jens.Osterkamp
In-Reply-To: <20060822001311.GK5427@austin.ibm.com>
From: linas@austin.ibm.com (Linas Vepstas)
Date: Mon, 21 Aug 2006 19:13:11 -0500
> @@ -1495,16 +1500,16 @@ spider_net_interrupt(int irq, void *ptr,
> if (!status_reg)
> return IRQ_NONE;
>
> - if (status_reg & SPIDER_NET_RXINT ) {
> + if (status_reg & SPIDER_NET_RXINT) {
> spider_net_rx_irq_off(card);
> netif_rx_schedule(netdev);
> }
> - if (status_reg & SPIDER_NET_TXINT ) {
> - spider_net_cleanup_tx_ring(card);
> - netif_wake_queue(netdev);
> - }
>
> - if (status_reg & SPIDER_NET_ERRINT )
> + /* Call rx_schedule from the tx interrupt, so that NAPI poll runs. */
> + if (status_reg & SPIDER_NET_TXINT)
> + netif_rx_schedule(netdev);
> +
> + if (status_reg & SPIDER_NET_ERRINT)
This should be:
if ((status_reg & (SPIDET_NET_RXINT | SPIDET_NET_TXINT))) {
spider_net_rx_and_tx_irq_off(card);
netif_rx_schedule();
}
^ permalink raw reply
* Re: [RFC] HOWTO use NAPI to reduce TX interrupts
From: David Miller @ 2006-08-22 0:32 UTC (permalink / raw)
To: rdreier
Cc: akpm, arnd, netdev, jklewis, linux-kernel, linuxppc-dev,
Jens.Osterkamp, jgarzik, shemminger
In-Reply-To: <adaac5x3966.fsf@cisco.com>
From: Roland Dreier <rdreier@cisco.com>
Date: Mon, 21 Aug 2006 17:29:05 -0700
> This is a digression from spidernet, but what if a device is able to
> generate separate MSIs for TX and RX? Some people from IBM have
> suggested that it is beneficial for throughput to handle TX work and
> RX work for IP-over-InfiniBand in parallel on separate CPUs, and
> handling everything through the ->poll() method would defeat this.
The TX work is so incredibly cheap, relatively speaking, compared
to the full input packet processing path that the RX side runs
that I see no real benefit.
In fact, you might even get better locality due to the way the
locking can be performed if TX reclaim runs inside of ->poll()
^ permalink raw reply
* I'm trying the 860hdlc driver for linux 2.4. Could you help me?
From: Ju Chulmin @ 2006-08-22 2:59 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 328 bytes --]
Hello, I'm newbie.
I'm writing the HDLC driver for mpc860.
And, I try to find the best to do. The time frame is very short.
Before preceeding, I surfed the goole group, and found the web link
contained, but link is broken.
If anyone have the driver, could you share it with me?
Thank you.
Freelancer Linux developer.
J.C.
[-- Attachment #2: Type: text/html, Size: 506 bytes --]
^ permalink raw reply
* Re: [PATCH] windfarm_smu_sat.c: simplify around i2c_add_driver()
From: Benjamin Herrenschmidt @ 2006-08-22 3:27 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: Andrew Morton, linuxppc-dev
In-Reply-To: <20060821232223.GB5220@martell.zuzino.mipt.ru>
On Tue, 2006-08-22 at 03:22 +0400, Alexey Dobriyan wrote:
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Oops ... :)
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> drivers/macintosh/windfarm_smu_sat.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> --- a/drivers/macintosh/windfarm_smu_sat.c
> +++ b/drivers/macintosh/windfarm_smu_sat.c
> @@ -397,12 +397,7 @@ static int wf_sat_detach(struct i2c_clie
>
> static int __init sat_sensors_init(void)
> {
> - int err;
> -
> - err = i2c_add_driver(&wf_sat_driver);
> - if (err < 0)
> - return err;
> - return 0;
> + return i2c_add_driver(&wf_sat_driver);
> }
>
> static void __exit sat_sensors_exit(void)
^ permalink raw reply
* Re: Take 2: [RFC] Debugging with a HW probe.
From: Milton Miller @ 2006-08-22 6:04 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <E1G9jpY-0004Nv-2d@kmac.watson.ibm.com>
On Aug 14, 2006, at 5:16 AM, Jimi Xenidis jimix at watson.ibm.com
wrote:
> A rework of the original patch, some on and off list comments had
> suggested that this be a generic service, and to make it very hard
> to unintentionally turn it on. I fact we should make sure that the
> feature is indeed turned off.
>
> Any suggestions on how to operate on the HID bits of all CPUs based on
> the value of the config _and_ 'hw_probe_enabled' would be welcom.
>
> I'd also like to wait for Olof's:
> http://ozlabs.org/pipermail/linuxppc-dev/2006-August/025024.html
> patch to make it to the tree (or not).
>
> Signed-off-by: Jimi Xenidis <jimix at watson.ibm.com>
[sorry for the list archive patch munging]
> ---
> diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
> index e29ef77..bc4cdf9 100644
> --- a/arch/powerpc/Kconfig.debug
> +++ b/arch/powerpc/Kconfig.debug
> @@ -61,6 +61,17 @@ config KGDB_CONSOLE
> over the gdb stub.
> If unsure, say N.
>
> +config ENABLE_HW_PROBE
> + bool "Allow instructions that contact a hardware probe
> (dangerous)"
> + depends on PPC64
Not having this depend on DEBUGGER but in the middle of things that do
will
get you scorn from the auto-indenting police.
Since we can only call this from xmon, should it depend on XMON (and be
placed after that)?
> + help
> + If you enable this AND you add "hwprobe" to the cmdline, the
> + processor will enable instructions that contact the hardware
> + probe. These instructions ca be used in all processor modes
can
> + _including_ user mode and are only useful for kernel
not sure this _highlighting_ is used elsewhere in Kconfig help ...
Should we mention that a hardware probe is required to continue
exectuion?
In other words, its not just contact, but signal and wait for a hw
probe?
> + development and debugging. DO NOT enable this unless you
> + plan to use it.
> +
> config XMON
> bool "Include xmon kernel debugger"
> depends on DEBUGGER && !PPC_ISERIES
> diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
> index bf2005b..02c5b83 100644
> --- a/arch/powerpc/kernel/prom.c
> +++ b/arch/powerpc/kernel/prom.c
> @@ -68,6 +68,9 @@ int __initdata iommu_is_off;
> int __initdata iommu_force_on;
> unsigned long tce_alloc_start, tce_alloc_end;
> #endif
> +#ifdef CONFIG_ENABLE_HW_PROBE
> +int hw_probe_enabled;
> +#endif
>
> typedef u32 cell_t;
>
> @@ -693,6 +696,11 @@ #ifdef CONFIG_PPC64
> if (of_get_flat_dt_prop(node, "linux,iommu-force-on", NULL) !=
> NULL)
> iommu_force_on = 1;
> #endif
> +#ifdef CONFIG_HW_PROBE_ENABLE
> + if (of_get_flat_dt_prop(node, "linux,hw-probe-enable", NULL)
> != NULL) {
> + hw_probe_enabled = 1;
> + DBG("HW Probe will be enabled\n");
> +#endif
No. [see next comment]
>
> /* mem=x on the command line is the preferred mechanism */
> lprop = of_get_flat_dt_prop(node, "linux,memory-limit", NULL);
> diff --git a/arch/powerpc/kernel/prom_init.c
> b/arch/powerpc/kernel/prom_init.c
> index 90972ef..26428de 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -587,6 +587,14 @@ #ifdef CONFIG_PPC64
> RELOC(iommu_force_on) = 1;
> }
> #endif
> +#ifdef CONFIG_HW_PROBE_ENABLE
> + opt = strstr(RELOC(prom_cmd_line), RELOC("hwprobe"));
> + if (opt) {
> + prom_printf("WARNING! HW Probe will be activated!\n");
> + prom_setprop(_prom->chosen, "/chosen",
> + "linux,hw-probe-enable", NULL, 0);
> + }
> +#endif
> }
Please, PLEASE do NOT do this.
prom_init.c is only used by one of the many flat device tree generators,
namely the open-firmware client. Adding a property like this requires
us
to update all the other clients.
And there is no reason to parse it this early.
Instead, parse it from the command line like the other early parsing.
I thing a generic early_param would be fine. However, xmon_init is an
early_parm in setup-common, so if you really require it before the first
call, then you could parse it next to mem= at the bottom of
early_init_dt_scan_chosen.
Which .h is hw_probe_enabled in? (none?)
>
> #ifdef CONFIG_PPC_PSERIES
> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
> index 179b10c..51a1e4e 100644
> --- a/arch/powerpc/xmon/xmon.c
> +++ b/arch/powerpc/xmon/xmon.c
> @@ -189,7 +189,12 @@ #endif
> dd dump double values\n\
> dr dump stream of raw bytes\n\
> e print exception information\n\
> - f flush cache\n\
> + f flush cache\n"
> +#ifdef CONFIG_ENABLE_HW_PROBE
> + "\
> + H Contact hardware probe, if available\n"
> +#endif
> + "\
While this style does keep the lines aligned in the source, it adds
veritcal
almost-whitespace. And I notice a different choice was made at the
bottom.
> la lookup symbol+offset of specified address\n\
> ls lookup address of specified symbol\n\
> m examine/change memory\n\
> @@ -217,6 +222,18 @@ #endif
> zh halt\n"
> ;
>
> +#ifdef CONFIG_ENABLE_HW_PROBE
> +/* try to keep this funtion from being inlined so its easier to move
> + * around the ATTN instruction */
> +extern int hw_probe_enabled;
> +static noinline void xmon_hw_probe(void)
> +{
> + if (!hw_probe_enabled)
> + return;
> + ATTN();
> +}
> +#endif
> +
> static struct pt_regs *xmon_regs;
>
> static inline void sync(void)
> @@ -819,6 +836,11 @@ #endif /* CONFIG_SMP */
> if (cpu_cmd())
> return 0;
> break;
> +#ifdef CONFIG_ENABLE_HW_PROBE
> + case 'H':
> + xmon_hw_probe();
> + break;
> +#endif
> case 'z':
> bootcmds();
> break;
> diff --git a/include/asm-powerpc/reg.h b/include/asm-powerpc/reg.h
> index cf73475..478097e 100644
> --- a/include/asm-powerpc/reg.h
> +++ b/include/asm-powerpc/reg.h
> @@ -207,6 +207,13 @@ #define SPRN_EAR 0x11A /* External
> Addr
> #define SPRN_HASH1 0x3D2 /* Primary Hash Address
> Register */
> #define SPRN_HASH2 0x3D3 /* Secondary Hash Address
> Resgister */
> #define SPRN_HID0 0x3F0 /* Hardware Implementation
> Register 0 */
> +#ifdef __ASSEMBLY__
> +#define HID0_QATTN (1<<35) /* Sup. Proc. attn insn all
> threads */
> +#define HID0_ATTN (1<<32) /* Sup. Proc. attn insn */
> +#else
> +#define HID0_QATTN (1UL<<35) /* Sup. Proc. attn insn all
> threads */
> +#define HID0_ATTN (1UL<<32) /* Sup. Proc. attn insn */
> +#endif
> #define HID0_EMCP (1<<31) /* Enable Machine Check pin */
> #define HID0_EBA (1<<29) /* Enable Bus Address Parity */
> #define HID0_EBD (1<<28) /* Enable Bus Data Parity */
> @@ -641,6 +648,13 @@ extern void ppc64_runlatch_off(void);
> extern unsigned long scom970_read(unsigned int address);
> extern void scom970_write(unsigned int address, unsigned long value);
>
> +/*
> + * Support Processor Attention Instruction instroduced in POWER
> + * architecture processors as of RS64, tho may not be supported by
> + * POWER 3.
> + */
> +#define ATTN() asm volatile("attn; nop")
> +
Fairly certian POWER3 does NOT implement this, but I don't have book IV
handy.
Does one of the processors require the nop ?
> #else
> #define ppc64_runlatch_on()
> #define ppc64_runlatch_off()
>
milton
^ 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