* [RFC v2] HOWTO use NAPI to reduce TX interrupts
From: Arnd Bergmann @ 2006-08-20 17:48 UTC (permalink / raw)
To: Stephen Hemminger
Cc: akpm, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp, Jeff Garzik, David Miller
In-Reply-To: <200608191325.19557.arnd@arndb.de>
A recent discussion about the spidernet driver resulted in the dicovery
that network drivers are supposed to use NAPI for both their receive and
transmit paths, but this is documented nowhere.
In order to help the next person writing a NAPI based driver, I wrote
down what I found missing about this.
Please tell me if anything in here is still wrong or could use better
wording.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
This is the second version of my mini howto, after a few comments
I got from Stephen Hemminger and Avuton Olrich.
Index: linux-cg/Documentation/networking/NAPI_HOWTO.txt
===================================================================
--- linux-cg.orig/Documentation/networking/NAPI_HOWTO.txt 2006-08-20 16:51:12.000000000 +0200
+++ linux-cg/Documentation/networking/NAPI_HOWTO.txt 2006-08-20 19:42:20.000000000 +0200
@@ -1,11 +1,6 @@
-HISTORY:
-February 16/2002 -- revision 0.2.1:
-COR typo corrected
-February 10/2002 -- revision 0.2:
-some spell checking ;->
-January 12/2002 -- revision 0.1
-This is still work in progress so may change.
-To keep up to date please watch this space.
+Note: this document could use a serious cleanup by a good writer.
+It would be nice to split out the reference parts into a kerneldoc
+document and turn the rest into a tutorial.
Introduction to NAPI
====================
@@ -738,6 +733,64 @@
root 3 0.2 0.0 0 0 ? RWN Aug 15 602:00 (ksoftirqd_CPU0)
root 232 0.0 7.9 41400 40884 ? S Aug 15 74:12 gated
+
+APPENDIX 4: Using NAPI for TX skb cleanup
+=========================================
+
+While most of the discussion is focused on optimizing the receive path, in
+most drivers it is also beneficial to free TX buffers from the dev->poll()
+function. Many devices trigger an interrupt for each packet that has been
+sent out to notify the driver that it can free the skb. This results in
+a large amount of interrupt processing that we want to avoid. It is also
+suboptimal to free skbs in a hardirq context, because dev_kfree_skb_irq()
+needs to schedule a softirq to do the actual work. Calling dev_kfree_skb()
+from dev->poll() directly avoids these extra softirq schedules.
+
+The simplistic approach of setting a long kernel timer to clean up
+descriptors results in poor throughput because a user process that tries
+to send out a lot of data then blocks on its socket send buffer, while
+the driver never frees up the skbs in that buffer until the timeout.
+
+Trying the cleanup every time that hard_start_xmit() is entered provides
+relatively good throughput, but typically causes extra processing overhead
+because of mmio accesses and/or spinlocks, so you normally want to batch
+skb reclaim.
+
+In order to get optimal throughput on transmit, the sent skbs need to be
+cleaned up before the chip runs out of data to transmit, so relying on
+an end of queue interrupt means that in the window between the interrupt
+and the time that new user packets have arrived in the adapter, there is
+no outgoing data on the wire, even if user data is available. It may
+also be bad to defer freeing skbs too long because they may consume a
+significant amount of memory.
+
+Experience shows that combination of events that trigger skb reclaim
+works best. These events include:
+- new packets coming in through hard_start_xmit()
+- packets coming in from the network through dev->poll()
+- time has passed since the first packet was send over the wire
+ but has not been reclaimed (tx_coalesce_usecs)
+- a number of packets have been sent (tx_max_coalesced_frames)
+
+We can avoid expensive locking between these by using the poll() function
+as the only place to call skb reclaim. This also means that in the
+interrupt handler, we always call netif_rx_schedule() for any interrupt,
+including those for tx or e.g. PHY handling. This is particularly
+helpful if reading the IRQ status does an auto mask operation.
+
+Depending on the actual hardware, slightly different methods for coalesced
+tx interrupts may be used:
+- a timer that starts with the successful transmission of a packet
+ may need to be replaced with a timer that is started at when a packet
+ is submitted to the adapter.
+- instead of an interrupt that is triggered after a fixed number
+ of transmitted packets, it may be possible to mark a specific packet
+ so it generates an interrupt after processing.
+- If the adapter knows about the number of packets that have been
+ queued, a low-watermark interrupt may be used that fires when the
+ number drops below a user-defined value.
+
+
--------------------------------------------------------------------
relevant sites:
@@ -764,3 +817,4 @@
Manfred Spraul <manfred@colorfullife.com>
Donald Becker <becker@scyld.com>
Jeff Garzik <jgarzik@pobox.com>
+Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH] no-execute -- please test
From: Albert Cahalan @ 2006-08-20 17:48 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <17631.62819.24167.555967@cargo.ozlabs.ibm.com>
On 8/14/06, Paul Mackerras <paulus@samba.org> wrote:
> Albert Cahalan writes:
>
> > This kernel patch implements no-execute protection (like x86 "NX bit")
> > for the Mac G2, Mac G3, Mac G4, and other systems running 32-bit
> > PowerPC processors in the 6xx, 7xx, and 7xxx families.
>
> I'd be interested in benchmark comparisons with/without this patch, if
> anyone cares to run lmbench, kernbench etc. with and without... If
> the performance impact is minimal I'll be happy to apply it. If the
> impact is noticeable then it might need to be selectable with a config
> option.
With no special effort at optimization, the patch appears to be harmless.
Actually most things are a tad faster, which is entirely illogical.
I must have gotten lucky with the cache.
Note that lmbench sucks. It won't compile out of the box. The Debian
package is unavailable for PowerPC, and anyway places files in all
sorts of unusual and annoying root-only locations. One of the tests
gets SIGSEGV while trying to do Sun RPC. The nice summary report
contains no data. I did find the raw results after digging around in
various directories though.
Before:
Simple syscall: 0.3180 microseconds
Simple read: 1.1413 microseconds
Simple write: 1.0040 microseconds
Simple stat: 5.5255 microseconds
Simple fstat: 1.6198 microseconds
Simple open/close: 8.3318 microseconds
Select on 10 fd's: 2.3284 microseconds
Select on 100 fd's: 18.2500 microseconds
Select on 250 fd's: 45.2063 microseconds
Select on 500 fd's: 89.6290 microseconds
Select on 10 tcp fd's: 2.6409 microseconds
Select on 100 tcp fd's: 31.1889 microseconds
Select on 250 tcp fd's: 79.1831 microseconds
Select on 500 tcp fd's: 160.2571 microseconds
Signal handler installation: 1.5846 microseconds
Signal handler overhead: 7.8899 microseconds
Protection fault: 0.7714 microseconds
Pipe latency: 24.4466 microseconds
AF_UNIX sock stream latency: 34.4834 microseconds
Process fork+exit: 671.3750 microseconds
Process fork+execve: 2417.0000 microseconds
Process fork+/bin/sh -c: 10904.0000 microseconds
File /tmp/XXX write bandwidth: 25636 KB/sec
Pagefaults on /tmp/XXX: 3.9404 microseconds
After:
Simple syscall: 0.3179 microseconds
Simple read: 1.1355 microseconds
Simple write: 0.9964 microseconds
Simple stat: 5.5497 microseconds
Simple fstat: 1.6473 microseconds
Simple open/close: 8.0965 microseconds
Select on 10 fd's: 2.3278 microseconds
Select on 100 fd's: 18.0789 microseconds
Select on 250 fd's: 44.1440 microseconds
Select on 500 fd's: 88.1935 microseconds
Select on 10 tcp fd's: 2.6399 microseconds
Select on 100 tcp fd's: 30.8939 microseconds
Select on 250 tcp fd's: 77.5070 microseconds
Select on 500 tcp fd's: 156.3438 microseconds
Signal handler installation: 1.5741 microseconds
Signal handler overhead: 7.8997 microseconds
Protection fault: 0.8085 microseconds
Pipe latency: 24.2050 microseconds
AF_UNIX sock stream latency: 33.7037 microseconds
Process fork+exit: 656.6250 microseconds
Process fork+execve: 2392.3333 microseconds
Process fork+/bin/sh -c: 10454.0000 microseconds
File /tmp/XXX write bandwidth: 25911 KB/sec
Pagefaults on /tmp/XXX: 3.6414 microseconds
Right now I have the code doing printk() rather than killing processes
that misbehave, and I'm doing something about the heap too. It seems
that GNOME things like to execute the heap, while non-GNOME things
do not. Perhaps libORBit is at fault. Things that execute the heap
include:
abiword
firefox-bin
gedit
gimp
gnome-panel
gnome-settings-
gnome-vfs-daemo
metacity
x-session-manag
Apps that behave well include xterm, xcalc, and xli.
I haven't found anything unusual in the ELF section flags. Both libORBit
and libX11 (which is fine) have flags like this:
[ 7] .rela.plt RELA 000138e4 0138e4 001824 12 A 2 23 4
[22] .sbss NOBITS 000f2f34 0e2f34 000140 0 WA 0 0 4
[23] .plt NOBITS 000f3074 0e2f34 00186c 0 WAX 0 0 4
[24] .bss NOBITS 000f48e0 0e2f34 000328 0 WA 0 0 4
Firefox is less than a month old. It's newer than xterm.
^ permalink raw reply
* boot problems on pseries
From: dtutty @ 2006-08-20 17:00 UTC (permalink / raw)
To: linuxppc-dev
Hello,
I'm switching from an IBM 486 and purchasing an IBM H50 (7026-H50), so
I'm new to the PPC. My vendor wants to ensure that it boots linux
before he ships it. I burned and sent him a few different distro CDs to
try and none boot. We can get yaboot to boot then get stuck at the
yaboot command line and can't get futher. As a fall-back, I was hoping
to use OF to boot the kernel directly and get a kernel-panic when it
can't find init but we can't get that far either. The error message
'claim failed' is returned immediatly with no indication that the kernel
tried to start.
I'm told by several people that the H50 is the same as the F50 in a
different format and that the F50 is known to work. Since the task at
hand is to get any linux to boot and not to actually install linux, I
need a kernel that will boot. Even a simple boot-floppy set would be
great.
Does anyone have a link to a boot/root floppy set that will work?
Hardware details: IBM 7026-H50, 256 MB ram, dual PPC 604e 332 MHz, 9.1
GB HD in Bay 2, standard CD-ROM, PowerGXT130P graphics accelerator.
Thanks,
Doug.
^ permalink raw reply
* Re: [PATCH 2/6]: powerpc/cell spidernet low watermark patch.
From: Arnd Bergmann @ 2006-08-20 10:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: akpm, netdev, James K Lewis, linux-kernel, linuxppc-dev,
ens Osterkamp, Jeff Garzik
In-Reply-To: <1156055509.5803.77.camel@localhost.localdomain>
On Sunday 20 August 2006 08:31, Benjamin Herrenschmidt wrote:
> > card->low_watermark->next->dmac_cmd_status |= SPIDER_NET_DESCR_TXDESFLG;
> > mb();
> > card->low_watermark->dmac_cmd_status &= ~SPIDER_NET_DESCR_TXDESFLG;
> > card->low_watermark = card->low_watermark->next;
> >
> > when we queue another frame for TX.
>
> I would have expected those to be racy vs. the hardware... what if the
> hardware is updating dmac_cmd_status just as your are trying to and the
> bit out of it ?
Right, that doesn't work. It is the only bit we use in that byte though,
so maybe it can be done with a single byte write.
Arnd <><
^ permalink raw reply
* Re: [PATCH 2/6]: powerpc/cell spidernet low watermark patch.
From: Benjamin Herrenschmidt @ 2006-08-20 6:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: akpm, netdev, James K Lewis, linux-kernel, linuxppc-dev,
ens Osterkamp, Jeff Garzik
In-Reply-To: <200608190109.15129.arnd@arndb.de>
> card->low_watermark->next->dmac_cmd_status |= SPIDER_NET_DESCR_TXDESFLG;
> mb();
> card->low_watermark->dmac_cmd_status &= ~SPIDER_NET_DESCR_TXDESFLG;
> card->low_watermark = card->low_watermark->next;
>
> when we queue another frame for TX.
I would have expected those to be racy vs. the hardware... what if the
hardware is updating dmac_cmd_status just as your are trying to and the
bit out of it ?
Ben
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Wolfgang Pfeiffer @ 2006-08-20 1:31 UTC (permalink / raw)
To: Stefan Richter; +Cc: linuxppc-dev, linux1394-devel
In-Reply-To: <44E6D634.3000207@s5r6.in-berlin.de>
Hi Stefan
Thanks a lot for your very detailed explanations of the 1394
et al. drivers. It helps me a lot ...
On Sat, Aug 19, 2006 at 11:13:24AM +0200, Stefan Richter wrote:
[ ... ]
>
> If you have got the TiBook around, you could connect it with the AlBook
> and look what gscanbus or OS X's system profiler have to say about it.
> If possible, also try the TiBook in target disk mode and see if it
> appears as a disk for Linux' sbp2 or under OS X.
I tested this, not on OSX, but Linux:
Target disk mode works excellent on the new Powerbook5,8 (alubook): I
booted the old TitaniumIV (tibook) -- connected via the FW cable to
the alubook -- in target disk mode. Very quickly after the tibook
started I was asked by KDE on the alubook what to do with the newly
detected disks. And some news icons appeared on the KDE desktop, 2 of
them correctly representing the 2 main partitions on the tibook.
Here's /var/log/kern.log on the alubook, at about the time when I
started the tibook in target disk mode
------------------------------------
Aug 20 02:04:18 debby1-6 kernel: [ 8644.941230] ieee1394: Node changed: 0-01:1023 -> 0-00:1023
Aug 20 02:04:18 debby1-6 kernel: [ 8644.941295] ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[000393fffecde4c4]
Aug 20 02:04:27 debby1-6 kernel: [ 8653.484415] ieee1394: Node resumed: ID:BUS[0-00:1023] GUID[000393fffecde4c4]
Aug 20 02:04:27 debby1-6 kernel: [ 8653.484580] ieee1394: Node changed: 0-00:1023 -> 0-01:1023
Aug 20 02:05:53 debby1-6 kernel: [ 8740.212617] PM: Removing info for ieee1394:000393fffecde4c4-0
Aug 20 02:06:00 debby1-6 kernel: [ 8746.315023] PM: Adding info for ieee1394:000393fffecde4c4-0
Aug 20 02:06:00 debby1-6 kernel: [ 8746.315180] scsi1 : SBP-2 IEEE-1394
Aug 20 02:06:00 debby1-6 kernel: [ 8746.315199] PM: Adding info for No Bus:host1
Aug 20 02:06:01 debby1-6 kernel: [ 8747.416987] ieee1394: sbp2: Logged into SBP-2 device
Aug 20 02:06:01 debby1-6 kernel: [ 8747.417194] ieee1394: Node 0-00:1023: Max speed [S400] - Max payload [2048]
Aug 20 02:06:01 debby1-6 kernel: [ 8747.417232] PM: Adding info for No Bus:target1:0:0
Aug 20 02:06:01 debby1-6 kernel: [ 8747.417738] Vendor: AAPL Model: FireWire Target Rev: 0000
Aug 20 02:06:01 debby1-6 kernel: [ 8747.417767] Type: Direct-Access-RBC ANSI SCSI revision: 03
Aug 20 02:06:01 debby1-6 kernel: [ 8747.417791] PM: Adding info for scsi:1:0:0:0
Aug 20 02:06:01 debby1-6 kernel: [ 8747.485838] SCSI device sda: 78140160 512-byte hdwr sectors (40008 MB)
Aug 20 02:06:01 debby1-6 kernel: [ 8747.486345] sda: Write Protect is off
Aug 20 02:06:01 debby1-6 kernel: [ 8747.486354] sda: Mode Sense: 00 00 00 00
Aug 20 02:06:01 debby1-6 kernel: [ 8747.486774] sda: asking for cache data failed
Aug 20 02:06:01 debby1-6 kernel: [ 8747.486781] sda: assuming drive cache: write through
Aug 20 02:06:01 debby1-6 kernel: [ 8747.487400] SCSI device sda: 78140160 512-byte hdwr sectors (40008 MB)
Aug 20 02:06:01 debby1-6 kernel: [ 8747.487721] sda: Write Protect is off
Aug 20 02:06:01 debby1-6 kernel: [ 8747.487728] sda: Mode Sense: 00 00 00 00
Aug 20 02:06:01 debby1-6 kernel: [ 8747.488150] sda: asking for cache data failed
Aug 20 02:06:01 debby1-6 kernel: [ 8747.488156] sda: assuming drive cache: write through
Aug 20 02:06:01 debby1-6 kernel: [ 8747.488437] sda: [mac] sda1 sda2 sda3 sda4 sda5
Aug 20 02:06:01 debby1-6 kernel: [ 8747.492435] sd 1:0:0:0: Attached scsi disk sda
--------------------------------------
So at least it looks now as if the Firewire 400 Hardware on the
alubook is not broken. Correct? Would be a great relief as I hate it
to have it away at the repair service.
I could mount the 2 tibook partitions easily on the alubook.
On the alubook:
-----------------------------------------
# mount
/dev/hda7 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
usbfs on /proc/bus/usb type usbfs (rw)
tmpfs on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/hda6 on /home type ext3 (rw)
/dev/hda5 on /var type ext3 (rw)
tmpfs on /dev type tmpfs (rw,size=10M,mode=0755)
nfsd on /proc/fs/nfsd type nfsd (rw)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
/dev/sda4 on /media/usbdisk type ext3 (rw,noexec,nosuid,nodev)
/dev/sda5 on /media/usbdisk-1 type ext3 (rw,noexec,nosuid,nodev)
--------------------------------
sd4/sda5 must be the 2 main partitions on the tibook ..
I mounted them, and a few seconds after unmounting them this must have
been the corresponding kern.log:
-------------------------------------------
Aug 20 03:05:20 debby1-6 kernel: [12306.976988] ieee1394: sbp2: Error logging into SBP-2 device - login timed-out
Aug 20 03:05:20 debby1-6 kernel: [12306.977004] ieee1394: sbp2: Failed to reconnect to sbp2 device!
Aug 20 03:05:20 debby1-6 kernel: [12306.977410] PM: Removing info for scsi:1:0:0:0
Aug 20 03:05:20 debby1-6 kernel: [12306.977482] PM: Removing info for No Bus:target1:0:0
Aug 20 03:05:20 debby1-6 kernel: [12306.977558] PM: Removing info for No Bus:host1
Aug 20 03:05:20 debby1-6 kernel: [12307.233256] ieee1394: Node changed: 0-01:1023 -> 0-00:1023
Aug 20 03:05:20 debby1-6 kernel: [12307.233324] ieee1394: Node suspended: ID:BUS[0-00:1023] GUID[000393fffecde4c4]
--------------------------------------------
OTOH: Connecting the alubook and tibook with Linux up and running on
both machines did not create a working (FW) connection between them ..
I'll try the latter later again -- even perhaps with OSX on the
alubook and Linux on the tibook ...
>
> The fact that Linux on the AlBook gets at least as far as "ieee1394:
> Error parsing configrom for node 0-00:1023" indicates that not all hope
> is lost. If you have got the time, compile the 1394 drivers for verbose
> logging and send the log. Don't crosspost the log if it gets too big.
I'll compile a fresh git kernel next week, Tuesday or Wednesday, with
verbose logging for the 1394 drivers. And I'll put the corresponding
logs for the 1394 tests on my homepage instead of sending them via
email anywhere, only the URL's for the logs will be sent in my
messages. Please let me know if you disagree ...
BTW: Do you know how to switch off verbose logging for the 1394
drivers once they're compiled into the kernel, via some
echo "<some-value>" to /sys/*/* ?
I didn't find any entry there until now for that purpose ...
Until then, and thanks a lot for your time.
Best Regards
Wolfgang
--
Wolfgang Pfeiffer: /ICQ: 286585973/ + + + /AIM: crashinglinux/
http://profiles.yahoo.com/wolfgangpfeiffer
Key ID: E3037113
http://keyserver.mine.nu/pks/lookup?search=0xE3037113&fingerprint=on
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Bill Fink @ 2006-08-20 0:18 UTC (permalink / raw)
To: Stefan Richter; +Cc: linux1394-devel, linuxppc-dev
In-Reply-To: <44E6DAB9.50304@s5r6.in-berlin.de>
On Sat, 19 Aug 2006, Stefan Richter wrote:
> Bill Fink wrote:
> ...
> > on my desktop PowerMac systems, I need a "sleep 2"
> > before the modprobe for sbp2, to get my Firewire disks to work
> > properly.
>
> What happens if you don't put the pause in there? What disks do you have
> and what bridge chips are built in? (Please apologize if you reported
> this before and we didn't come to a solution then.)
First of all this was on a somewhat older 2.6.11.8 kernel without
any hotplug (I'll probably be trying this again soon with a newer
2.6.15-rc5 kernel). And I was actually booting off this Firewire
disk. Without the pause I would get:
Loading sb2.ko module
sb2: $rev 1219 ...
Creating block devices
Creating root device
Mkrootdev: label fw1-root not found
Then it wouldn't be able to mount the root filesystem, which would
be followed shortly by a kernel panic.
If I put the "sleep 2" before the "modprobe sbp2" then everything
works. There's a message about initializing SCSI emulation for SBP-2,
followed by the discovery of the Firewire disk and the creation of
the sda device, which then allows the successful mounting of the
root filesystem.
Here's the full linuxrc nash script from the initrd for the working case:
#!/bin/nash
mount -t proc /proc /proc
setquiet
echo Mounted /proc filesystem
echo Mounting sysfs
mount -t sysfs none /sys
echo "Loading ieee1394.ko module"
insmod /lib/ieee1394.ko
echo "Loading ohci1394.ko module"
insmod /lib/ohci1394.ko
sleep 2
echo "Loading raw1394.ko module"
insmod /lib/raw1394.ko
echo "Loading sbp2.ko module"
insmod /lib/sbp2.ko
echo Creating block devices
mkdevices /dev
echo Creating root device
mkrootdev /dev/root
umount /sys
echo 0x0100 > /proc/sys/kernel/real-root-dev
echo Mounting root filesystem
mount -o defaults --ro -t ext3 /dev/root /sysroot
pivot_root /sysroot /sysroot/initrd
umount /initrd/proc
The disk is an 80 GB LaCie Firewire disk, reported by the kernel as:
Aug 19 19:48:01 gwiz kernel: ieee1394: sbp2: Logged into SBP-2 device
Aug 19 19:48:01 gwiz kernel: Vendor: ST380021 Model: A Rev: 3.05
Aug 19 19:48:01 gwiz kernel: Type: Direct-Access-RBC ANSI SCSI revision: 04
Aug 19 19:48:01 gwiz kernel: SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
Aug 19 19:48:01 gwiz kernel: sda: asking for cache data failed
Aug 19 19:48:01 gwiz kernel: sda: assuming drive cache: write through
Aug 19 19:48:01 gwiz kernel: SCSI device sda: 156301488 512-byte hdwr sectors (80026 MB)
Aug 19 19:48:01 gwiz kernel: sda: asking for cache data failed
Aug 19 19:48:01 gwiz kernel: sda: assuming drive cache: write through
Aug 19 19:48:01 gwiz kernel: sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9 sda10 sda11
Aug 19 19:48:01 gwiz kernel: sd 1:0:0:0: Attached scsi disk sda
Aug 19 19:48:01 gwiz kernel: sd 1:0:0:0: Attached scsi generic sg0 type 14
The above messages are actually from booting (non-Firewire) the
newer 2.6.15-rc5 kernel.
-Bill
^ permalink raw reply
* Re: [PATCH] powerpc: emulate power5 popcntb instruction
From: segher @ 2006-08-19 23:32 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus, segher
In-Reply-To: <200608192219.03178.arnd@arndb.de>
>> > Is that the right check? The other similar traps check against a
>> mask of 0x7c0007fe.
>>
>> I hope you mean 0xfc0007fe?
>>
>
> No, the code in question is
>
> #define INST_MFSPR_PVR········0x7c1f42a6
> #define INST_MFSPR_PVR_MASK····0xfc1fffff
>
> #define INST_DCBA·············0x7c0005ec
> #define INST_DCBA_MASK········0x7c0007fe
>
> #define INST_MCRXR············0x7c000400
> #define INST_MCRXR_MASK·······0x7c0007fe
>
> #define INST_STRING···········0x7c00042a
> #define INST_STRING_MASK·······0x7c0007fe
> #define INST_STRING_GEN_MASK···0x7c00067e
> #define INST_LSWI·············0x7c0004aa
> #define INST_LSWX·············0x7c00042a
> #define INST_STSWI············0x7c0005aa
> #define INST_STSWX············0x7c00052a
>
> What does the MSB do in our instructions?
Bits 0..5 are the primary opcode, for all insns;
bits 21..30 are the secondary opcode, for insns that
have one (all in primary opcode 31 do).
So we have a bug here; could you take care of it please
Arnd?
Segher
^ permalink raw reply
* Re: HDLC drivers on 8260
From: Mich Lanners @ 2006-08-19 20:10 UTC (permalink / raw)
To: alexfestss; +Cc: linuxppc-dev
In-Reply-To: <BAY106-F227AE7DF98822643447FA7DB430@phx.gbl>
Hi,
On 19 Aug, this message from Alejandro C echoed through cyberspace:
> I've just started developing a driver to use the four SCCs (CPM of the
> Motorola
> MPC8260) in the HDLC mode. I've found references to a HDLC driver
> somewhere on the internet, but I haven't been able to locate the
> source code. Does anyone know where to find this or something else I
> can use as an example/starting point?
I don't know a thing about the SCCs in the MPC8260, but you may want to
have a look at the Cyclades PC300 driver in the kernel. It does HDLC
(but I don't remember whether it's the PC300 driver or a generic HDLC
driver in the kernel). What HDLC do you wnat to implement? There is no
generic HDLC per se, but different framings using a HDLC-like framing.
Examples would be Cisco's IP over HDLC, or PPP.
For Cisco's HDLC, I added IP address autoconfiguration to the PC300
(submitted to the maintainer, but never found it's way into the official
kernels).
Cheers
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
^ permalink raw reply
* Re: [PATCH] powerpc: emulate power5 popcntb instruction
From: Arnd Bergmann @ 2006-08-19 20:19 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, segher
In-Reply-To: <50883.84.105.60.119.1156014614.squirrel@gate.crashing.org>
T24gU2F0dXJkYXkgMTkgQXVndXN0IDIwMDYgMjE6MTAsIHNlZ2hlckBnYXRlLmNyYXNoaW5nLm9y
ZyB3cm90ZToKPiA+IElzIHRoYXQgdGhlIHJpZ2h0IGNoZWNrPyBUaGUgb3RoZXIgc2ltaWxhciB0
cmFwcyBjaGVjayBhZ2FpbnN0IGEKPiA+IG1hc2sgb2YgMHg3YzAwMDdmZS4KPiAKPiBJIGhvcGUg
eW91IG1lYW4gMHhmYzAwMDdmZT8KPiAKCk5vLCB0aGUgY29kZSBpbiBxdWVzdGlvbiBpcyAKCiNk
ZWZpbmUgSU5TVF9NRlNQUl9QVlKtt623t7e3t7e3MHg3YzFmNDJhNgojZGVmaW5lIElOU1RfTUZT
UFJfUFZSX01BU0utt7e3tzB4ZmMxZmZmZmYKCiNkZWZpbmUgSU5TVF9EQ0JBrbe3t7e3t623t7e3
t7e3MHg3YzAwMDVlYwojZGVmaW5lIElOU1RfRENCQV9NQVNLrbett7e3t7e3tzB4N2MwMDA3ZmUK
CiNkZWZpbmUgSU5TVF9NQ1JYUq23t7e3t623t7e3t7e3MHg3YzAwMDQwMAojZGVmaW5lIElOU1Rf
TUNSWFJfTUFTS62tt7e3t7e3tzB4N2MwMDA3ZmUKCiNkZWZpbmUgSU5TVF9TVFJJTkett7e3t623
t7e3t7e3MHg3YzAwMDQyYQojZGVmaW5lIElOU1RfU1RSSU5HX01BU0utt7e3t7e3tzB4N2MwMDA3
ZmUKI2RlZmluZSBJTlNUX1NUUklOR19HRU5fTUFTS623t7cweDdjMDAwNjdlCiNkZWZpbmUgSU5T
VF9MU1dJrbe3t7e3t623t7e3t7e3MHg3YzAwMDRhYQojZGVmaW5lIElOU1RfTFNXWK23t7e3t7et
t7e3t7e3tzB4N2MwMDA0MmEKI2RlZmluZSBJTlNUX1NUU1dJrbe3t7e3rbe3t7e3t7cweDdjMDAw
NWFhCiNkZWZpbmUgSU5TVF9TVFNXWK23t7e3t623t7e3t7e3MHg3YzAwMDUyYQoKV2hhdCBkb2Vz
IHRoZSBNU0IgZG8gaW4gb3VyIGluc3RydWN0aW9ucz8KCglBcm5kIDw+PAo=
^ permalink raw reply
* Re: [PATCH] powerpc: emulate power5 popcntb instruction
From: segher @ 2006-08-19 19:10 UTC (permalink / raw)
To: arnd; +Cc: linuxppc-dev, paulus
In-Reply-To: <200608182105.45264.arnd@arndb.de>
>> +#define INST_POPCNTB 0x7c0000f4
>> +
>
>> + /* Emulate the popcntb (Population Count Bytes) instruction.
>> */ + if ((instword & INST_POPCNTB) == INST_POPCNTB) {
>> + return emulate_popcntb_inst(regs, instword);
>> + }
>> +
>
> Is that the right check? The other similar traps check against a
> mask of 0x7c0007fe.
I hope you mean 0xfc0007fe?
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: emulate power5 popcntb instruction
From: segher @ 2006-08-19 19:09 UTC (permalink / raw)
To: galak; +Cc: linuxppc-dev, paulus
In-Reply-To: <FE1A4DBD-9AAB-434A-B487-06B68AC61CC0@kernel.crashing.org>
>> +static int emulate_popcntb_inst(struct pt_regs *regs, u32 instword)
>> +{
>> + u32 ra,rs;
>> + unsigned long tmp;
>> +
>> + ra = (instword >> 16) & 0x1f;
>> + rs = (instword >> 21) & 0x1f;
>> +
>> + tmp = regs->gpr[rs];
>> + tmp = tmp - ((tmp >> 1) & 0x5555555555555555);
>> + tmp = (tmp & 0x3333333333333333) + ((tmp >> 2) &
>> 0x3333333333333333);
>> + tmp = (tmp + (tmp >> 4)) & 0x0f0f0f0f0f0f0f0f;
>> + regs->gpr[ra] = tmp;
>> +
>> + return 0;
>> +}
>
> This is going to give warnings on ppc32 kernel compiles, maybe
> something like:
>
> (unsigned long) 0x5555555555555555ull
Nah, just make "tmp" an u64. And/or don't do this emulation on
32-bit machines at all.
And if the compiler warns about the non-qualified constants --
well, we should compile with -std=gnu99 anyway, eh?
Segher
^ permalink raw reply
* Re: [PATCH] Add 85xx DTS files to powerpc
From: Sergei Shtylyov @ 2006-08-19 18:27 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.61.0608181803160.2878@ld0175-tx32.am.freescale.net>
Hello.
Andy Fleming wrote:
> Added the mpc85xx family of dts files to the powerpc tree
> ---
> arch/powerpc/boot/dts/mpc8540ads.dts | 257 ++++++++++++++++++++++++++++++
> arch/powerpc/boot/dts/mpc8541cds.dts | 244 +++++++++++++++++++++++++++++
> arch/powerpc/boot/dts/mpc8548cds.dts | 287 ++++++++++++++++++++++++++++++++++
> arch/powerpc/boot/dts/mpc8555cds.dts | 244 +++++++++++++++++++++++++++++
> 4 files changed, 1032 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/boot/dts/mpc8540ads.dts b/arch/powerpc/boot/dts/mpc8540ads.dts
> new file mode 100644
> index 0000000..93d2c2d
> --- /dev/null
> +++ b/arch/powerpc/boot/dts/mpc8540ads.dts
[...]
> + ethernet-phy@2 {
> + linux,phandle = <2452002>;
> + interrupt-parent = <40000>;
> + interrupts = <37 1>;
> + reg = <2>;
> + device_type = "ethernet-phy";
> + };
Well, there's PHYs #2 and #3 on the board, #2 is probably not tied to
anything though.
> + ethernet@26000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "TSEC";
> + compatible = "gianfar";
> + reg = <26000 1000>;
> + address = [ 00 E0 0C 00 73 02 ];
> + local-mac-address = [ 00 E0 0C 00 73 02 ];
> + interrupts = <19 2>;
> + interrupt-parent = <40000>;
> + phy-handle = <2452002>;
> + };
Shouldn't it be "FEC" instead? The third controller is actually Fast
Ethernet and fsl_soc.c differs TSEC and FEC WRT the interrupts (FEC has only
one). So, this entry looks incorrect...
> + pic@40000 {
> + linux,phandle = <40000>;
> + clock-frequency = <0>;
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + reg = <40000 40000>;
> + built-in;
> + compatible = "chrp,open-pic";
> + device_type = "open-pic";
> + big-endian;
Spaces instead of tabs in this line...
> + };
> + };
> +};
WBR, Sergei
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Stefan Richter @ 2006-08-19 8:10 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, linux1394-devel
In-Reply-To: <20060817230347.GC3440@localhost>
Wolfgang Pfeiffer wrote:
> The SCSI/FW routines seem to work like a charm with a LSILogic Model/
> SYM13FW500-Disk on my old Macintosh titanium-IV laptop, with exactly
> the same relatively fresh git-kernel that does not work on the
> PowerBook5,8. That is I compiled the kernel on the Apple Powerbook5,8
> and installed it on both machines.
>
> SCSI/FW didn't work ever on the new PowerBook5,8.
[...]
> #!/bin/sh -x
> /bin/sh -n /home/shorty/scripts/scsi.start.sh && \
>
> modprobe raw1394 && \
> modprobe ieee1394 disable_irm=0 disable_nodemgr=1 && \
> modprobe ohci1394 && \
> modprobe eth1394 && \
> modprobe sbp2 max_speed=3 workarounds=0x1 serialize_io=0 && \
> sleep 4 && \
> chown root.shorty /dev/raw1394
This script doesn't work as you may expect.
"modprobe raw1394" pulls ieee1394 in. Therefore all the parameters you
give to ieee1394 in the next line are ignored. If you want to run
ieee1394 with non-default parameters, load it first before any other
1394 driver or put the parameters into /etc/modprobe.d/xyz or
/etc/modprobe.conf.
"disable_nodemgr=1" will also enforce disable_irm=0 because some of the
IRMs functionality requires the nodemgr kernel daemon.
The nodemgr is also the bridge between the 1394 bus and Linux' driver
core. Some of the IEEE 1394 high-level drivers, including sbp2, don't
find devices on their own but work on top of the driver core's device
representations created by nodemgr. IOW sbp2 won't work with
disable_nodemgr=1.
"modprobe eth1394" is not necessary if you have hotplug scripts.
ieee1394 is, according to your log, configured to always adds an
IP-over-1394 ROM entry to the local node's configuration ROM (it's
actually RAM but works like ROM for other 1394 nodes), and there will be
hotplug events generated for this entry as soon as the local node
(driven by ohci1394) became operational.
(Similarly, sbp2 is usually loaded by hotplug scripts when an SBP-2
device was detected. But if you rely on hotplug, you would have of
course to supply any non-default module parameters to sbp2 via
/etc/modprobe.d/xyz or /etc/modprobe.conf.)
"max_speed=3" i.e. S800 is the default and will stay so for the time
being. It doesn't seem like S1600 hardware (standardized by IEEE 1394b)
or even S3200 hardware (not standardized yet) will ever become available.
"workarounds=1" or 0x1 isn't precisely the default. But there is also
sbp2's parameter max_sectors whose default value of 255 means exactly
the same as the bit 1 in the workarounds bit field. The bit 1 exists in
the workarounds parameter only to fully reflect what can be stuffed into
sbp2's hardcoded blacklist (or "whitelist" depending on the point of view).
"serialize_io=0" has always been --- and still is --- unsafe. I recently
started work to make it safe but am not done yet. serialize_io=0 does
work with many devices though (by fortunate circumstances rather than by
principle) and gains a measurable but hardly noticeable throughput
advantage with some devices, AFAIK especially with S800 devices.
However all my comments to your script do not relate to the problem you
are seeing with
[...]
> Aug 18 00:24:03 debby1-6 kernel: [38907.611119] ieee1394: Initialized config rom entry `ip1394'
> Aug 18 00:24:03 debby1-6 kernel: [38907.628475] ieee1394: raw1394: /dev/raw1394 device initialized
Here you are seeing proof for my comment on "modprobe raw1394": ieee1394
is up earlier than raw1394...
> Aug 18 00:24:03 debby1-6 kernel: [38907.692766] PM: Adding info for ieee1394:fw-host0
> Aug 18 00:24:03 debby1-6 kernel: [38907.764726] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[40] MMIO=[f5000000-f50007ff] Max Packet=[4096] IR/IT contexts=[8/8]
> Aug 18 00:24:03 debby1-6 kernel: [38907.912614] eth1394: eth2: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
> Aug 18 00:24:04 debby1-6 kernel: [38909.170610] ieee1394: The root node is not cycle master capable; selecting a new root node and resetting...
> Aug 18 00:24:05 debby1-6 kernel: [38910.425599] ieee1394: Error parsing configrom for node 0-00:1023
...and you are using it with irm and nodemgr enabled.
AFAIK:
Node 0-00:1023 is the enclosure's SYM13FW501 which seems to be a link
layer controller with integrated minimal PHY. (Node IDs are associated
with PHYs, not links.) Node 0-01:1023 is an extra PHY in the enclosure,
the PHY that actually drives the cable port (ports?). This is the
TSB41LV03A on the bridge board. To take up two nodes, i.e. show the
presence of two daisy-chained PHYs to the bus instead of one PHY, is
apparently a property of some or all bridge boards with the old Symbios
SBP-2 controller.
Node 0-02:1023 is of course the fw-host0.
"Error parsing configrom" often means that ieee1394 was unable to read
anything from a devices ROM in the first place. This is often a normal
condition for SBP-2 devices until their attached drive is fully
operational. They then send a bus reset and publish a proper ROM,
ieee1394 reads it, and Linux' driver core attaches the sbp2 driver as
the matching protocol driver to it.
What if you force a bus reset about 5 seconds or more later, using
gscanbus or 1394commander? Would ieee1349 detect the disk's SBP-2
capability?
What if you load ieee1394 with disable_irm=1? (Before raw1394 of
course.) Nodemgr takes care to run the IRM code in a very non-intrusive
manner in newer Linux releases, but there is still the "selecting a new
root node and resetting" routine which can't be avoided by an IRM that
wants to be fully compliant to the specs.
> Aug 18 00:24:05 debby1-6 kernel: [38910.425992] PM: Adding info for ieee1394:001451fffe3148be
> Aug 18 00:24:05 debby1-6 kernel: [38910.426064] ieee1394: Host added: ID:BUS[0-02:1023] GUID[001451fffe3148be]
> Aug 18 00:24:05 debby1-6 kernel: [38910.426209] PM: Adding info for ieee1394:001451fffe3148be-0
These two "Adding info for..." are of course related to the host
adapter. The first one is the fw-host0 itself and the second one the
ip1394 a.k.a. RFC 2734 unit that ieee1394 added to it (and eth1394 was
bound to). 0x001451 is Apple's OUI.
[...]
> And gscanbus says this for:
> "Unknown
> Linux - ohci1394":
>
> --------------------------
> SelfID Info
> -----------
> Physical ID: 2
[...]
> And this for "S400 unknown":
>
> ---------------------------------
> SelfID Info
> -----------
> Physical ID: 1
> Link active: No
This is the TSB41LV03A.
> Gap Count: 63
> PHY Speed: S400
> PHY Delay: <=144ns
> IRM Capable: No
> Power Class: -1W
> Port 0: Connected to parent node
> Port 1: Not connected
> Port 2: Connected to child node
> Init. reset: No
[...]
There should be a third node, i.e. the node with physical ID 0 == the
child node of the TSB41LV03A's node. Doesn't show gscanbus anything
about that node? I expect that you at least see an icon and SelfID info.
CSR ROM info might be missing; although the fact that ieee1394 failed to
read the ROM doesn't mean that gscanbus will be unable to do so.
--
Stefan Richter
-=====-=-==- =--- =--==
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [2.6.19 PATCH 4/7] ehea: ethtool interface
From: Jeff Garzik @ 2006-08-19 14:40 UTC (permalink / raw)
To: Andy Gay
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Thomas Klein, linux-ppc, Christoph Raisch, Marcus Eder,
Alexey Dobriyan
In-Reply-To: <1155970112.7302.434.camel@tahini.andynet.net>
Andy Gay wrote:
> fs/bio.c:169: warning: 'idx' may be used uninitialized in this function
> fs/eventpoll.c:500: warning: 'fd' may be used uninitialized in this function
> fs/isofs/namei.c:162: warning: 'offset' may be used uninitialized in this function
> fs/isofs/namei.c:162: warning: 'block' may be used uninitialized in this function
> fs/nfsd/nfsctl.c:292: warning: 'maxsize' may be used uninitialized in this function
> fs/udf/balloc.c:751: warning: 'goal_eloc.logicalBlockNum' may be used uninitialized in this function
> fs/udf/super.c:1358: warning: 'ino.partitionReferenceNum' may be used uninitialized in this function
> fs/xfs/xfs_alloc_btree.c:611: warning: 'nkey.ar_startblock' may be used uninitialized in this function
> fs/xfs/xfs_alloc_btree.c:611: warning: 'nkey.ar_blockcount' may be used uninitialized in this function
> fs/xfs/xfs_bmap.c:2498: warning: 'rtx' is used uninitialized in this function
> fs/xfs/xfs_bmap_btree.c:753: warning: 'nkey.br_startoff' may be used uninitialized in this function
> fs/xfs/xfs_da_btree.c:151: warning: 'action' may be used uninitialized in this function
> fs/xfs/xfs_dir.c:363: warning: 'totallen' may be used uninitialized in this function
> fs/xfs/xfs_dir.c:363: warning: 'count' may be used uninitialized in this function
> fs/xfs/xfs_ialloc_btree.c:545: warning: 'nkey.ir_startino' may be used uninitialized in this function
> fs/xfs/xfs_inode.c:1958: warning: 'last_dip' may be used uninitialized in this function
> fs/xfs/xfs_inode.c:1960: warning: 'last_offset' may be used uninitialized in this function
> fs/xfs/xfs_log.c:1749: warning: 'iclog' may be used uninitialized in this function
> fs/xfs/xfs_log_recover.c:523: warning: 'first_blk' may be used uninitialized in this function
> ipc/msg.c:338: warning: 'setbuf.qbytes' may be used uninitialized in this function
> ipc/msg.c:338: warning: 'setbuf.uid' may be used uninitialized in this function
> ipc/msg.c:338: warning: 'setbuf.gid' may be used uninitialized in this function
> ipc/msg.c:338: warning: 'setbuf.mode' may be used uninitialized in this function
> ipc/sem.c:810: warning: 'setbuf.uid' may be used uninitialized in this function
> ipc/sem.c:810: warning: 'setbuf.gid' may be used uninitialized in this function
> ipc/sem.c:810: warning: 'setbuf.mode' may be used uninitialized in this function
> drivers/md/dm-table.c:431: warning: 'dev' may be used uninitialized in this function
> drivers/md/dm-ioctl.c:1388: warning: 'param' may be used uninitialized in this function
> net/sched/sch_cbq.c:409: warning: 'ret' may be used uninitialized in this function
> lib/zlib_inflate/inftrees.c:121: warning: 'r.base' may be used uninitialized in this function
These are gcc bugs. We don't patch the kernel for gcc bugs.
Jeff
^ permalink raw reply
* Re: ioremap() twice on same memory mapped area?
From: Dan Malek @ 2006-08-19 14:13 UTC (permalink / raw)
To: Parav Pandit; +Cc: Linuxppc-embedded
In-Reply-To: <20060819065247.10235.qmail@web36608.mail.mud.yahoo.com>
On Aug 19, 2006, at 2:52 AM, Parav Pandit wrote:
> Question is:
> Can both the driver call the ioremap() on the same space and get
> the different virtual address?
Yes, and depending upon the implementation and optimizations,
they may also get the same virtual address. It will work as you
intend.
-- Dan
^ permalink raw reply
* Re: [2.6.19 PATCH 4/7] ehea: ethtool interface
From: Arnd Bergmann @ 2006-08-19 13:47 UTC (permalink / raw)
To: linuxppc-dev, michael
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Thomas Klein, Christoph Raisch, Marcus Eder, Andy Gay,
Alexey Dobriyan
In-Reply-To: <1155976887.1388.17.camel@localhost.localdomain>
On Saturday 19 August 2006 10:41, Michael Ellerman wrote:
> A lot of these have started appearing recently, which I think is due to
> GCC becoming more vocal. Unfortunately many of them are false positives
> caused by GCC not seeming to grok that this is ok:
>
> void foo(int *x) { *x = 1; }
> ...
> int x;
> foo(&x);
> return x;
>
It's more subtle than this, gcc only gets it wrong when multiple
things come together, the most common one seems to be:
- it tries to inline foo()
- foo has a path where it initializes *x and another one where it
doesn't
- x is accessed after foo() returns, but only when foo indeed has
initialized it.
The problem is that gcc now is more aggressive about inlining
functions. It used to assume that all functions initialize their
pointer arguments, now it does some more checking, but not enough,
so there are lots of false positives. Every gcc-4.x release seems
to fix some of these cases, but a few others remain.
Arnd <><
^ permalink raw reply
* HDLC drivers on 8260
From: Alejandro C @ 2006-08-19 12:10 UTC (permalink / raw)
To: linuxppc-dev
Hi there,
I've just started developing a driver to use the four SCCs (CPM of the
Motorola
MPC8260) in the HDLC mode. I've found references to a HDLC driver somewhere
on the internet, but I haven't been able to locate the source code. Does
anyone know where to find this or something else I can use as an
example/starting point?
Thanx,
Alex
_________________________________________________________________
Un amor, una aventura, compañía para un viaje. Regístrate gratis en MSN Amor
& Amistad. http://match.msn.es/match/mt.cfm?pg=channel&tcid=162349
^ permalink raw reply
* Re: [RFC] HOWTO use NAPI to reduce TX interrupts
From: Arnd Bergmann @ 2006-08-19 11:25 UTC (permalink / raw)
To: Stephen Hemminger
Cc: akpm, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp, Jeff Garzik, David Miller
In-Reply-To: <44E7BB7F.7030204@osdl.org>
On Sunday 20 August 2006 03:31, Stephen Hemminger wrote:
>=20
> The reason reclaim via poll() is efficient is because it avoid causing a=
=20
> softirq that is
> necessary when skb_free_irq() is done. Instead it reuses the softirq=20
> from the poll() routine.=20
Ok, I completely missed this point so far, thanks for the info.
> Like all Rx NAPI, using poll() for reclaim means:=20
> =A0 =A0 + aggregating multiple frames in one irq
> =A0 =A0 - increased overhead of twiddling with the IRQ mask
> =A0 =A0 - more ways to get driver stuck
What is the best way to treat the IRQ mask for TX interrupts?
I guess it should be roughly:
=2D off when we expect ->poll() to be called, i.e. after calling
netif_rx_schedule() or returning after a partial rx from poll().
=2D off when there are no packets left in the TX queue
=2D on while RX interrupts are on and we're waiting for packets
to be transmitted.
> Some drivers do all their irq work in the poll() routine (including PHY=20
> handling).
> This is good if reading the IRQ status does an auto mask operation.
>=20
> The whole NAPI documentation area is a mess and needs a good writer
> to do some major restructuring. It should also be split into reference=20
> information,
> tutorial and guide sections.
I won't be able to do that work, I'm neither a good writer nor a networking
person.
Do you think we should still merge a section like the text I wrote up, even
if it makes the text even less well structured? Should I maybe add it
somewhere else than the appendix?
Arnd <><
^ permalink raw reply
* e2fsck error on compact flash.
From: Srinivasa Hebbar @ 2006-08-19 10:30 UTC (permalink / raw)
To: Linuxppc-embedded; +Cc: sshebbar
Hello,
Problem:
e2fsck is unable to determine the size of the physical device on a compact flash.
/dev/hda is a compact flash disk with 4 partitions. (3primary+1extended).
ls -l /dev/hda* shows all the devices.
If I mount any partition on /dev/hda* to /tmp/tmp
(for eg: /dev/hda1 to /tmp/tmp) and run e2fsck
on /dev/hda3 (or any other), e2fsck runs fine without problem.
All 4 partitions on the CF disk are ext3.
The output of the commands are below.
Any help is appreciated.
Thanks,
Hebbar.
# e2fsck -v /dev/hda3
e2fsck 1.38 (30-Jun-2005)
Error determining size of the physical device: No such file or directory
# ls -l /dev/hda*
brw-rw---- 1 0 0 3, 5 /dev/hda5
brw-rw---- 1 0 0 3, 4 /dev/hda4
brw-rw---- 1 0 0 3, 3 /dev/hda3
brw-rw---- 1 0 0 3, 2 /dev/hda2
brw-rw---- 1 0 0 3, 1 /dev/hda1
brw-rw---- 1 0 0 3, 0 /dev/hda
#mount -t ext3 /dev/hda1 /tmp/tmp
# e2fsck -v /dev/hda3
e2fsck 1.38 (30-Jun-2005)
/dev/hda3 has been mounted 21 times without being checked, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Stefan Richter @ 2006-08-19 9:32 UTC (permalink / raw)
To: Bill Fink; +Cc: linux1394-devel, linuxppc-dev
In-Reply-To: <20060818012824.22e70b0f.billfink@mindspring.com>
Bill Fink wrote:
...
> on my desktop PowerMac systems, I need a "sleep 2"
> before the modprobe for sbp2, to get my Firewire disks to work
> properly.
What happens if you don't put the pause in there? What disks do you have
and what bridge chips are built in? (Please apologize if you reported
this before and we didn't come to a solution then.)
--
Stefan Richter
-=====-=-==- =--- =--==
http://arcgraph.de/sr/
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Stefan Richter @ 2006-08-19 9:13 UTC (permalink / raw)
To: Wolfgang Pfeiffer; +Cc: linuxppc-dev, linux1394-devel
In-Reply-To: <20060818234930.GB2662@localhost>
Wolfgang Pfeiffer wrote:
>> The SCSI/FW routines seem to work like a charm with a LSILogic Model/
>> SYM13FW500-Disk on my old Macintosh titanium-IV laptop, with exactly
>> the same relatively fresh git-kernel that does not work on the
>> PowerBook5,8. That is I compiled the kernel on the Apple Powerbook5,8
>> and installed it on both machines.
> [ ... ]
>
> In the meantime I suspect a hardware problem.
>
> Here's why:
>
> I connected the FW disk I was reporting about in previous postings to
> both an older Apple titanium Powerbook and to the newer Apple alubook
> 5,8.
>
> In both instances I rebooted the machines with the accompanying
> different Apple OS X install CD's. Both CD's have a so-called "Disk
> Utility" tool with them, a tool that generally detects and repairs
> disks. The tool clearly detected the FW disk attached to my old
> titanium. And the same tool didn't detect the same FW disk on the
> newer alubook 5,8 ... :)
>
> In both instances I connected the FW disk to the FW 400 connector of
> the machines.
>
> So unless there are differing FW 400 versions available on both
> machines I'd suspect a hardware prob with the 5,8.
>
> [Note: Do there actually exist different Firewire 400 versions?]
Yes, there are, but they should be fully interoperable --- with one
exception that doesn't apply to Powerbooks.
A) There are old IEEE 1394-1995 only compliant PHYs. Such PHYs have not
been used by manufacturers anymore since long ago.
B) There are IEEE 1394a-2000 compliant PHYs. IEEE 1394a added, among
else, enhanced asynchronous arbitration, but AFAIU this is fully
interoperable with 1394-1995 PHYs. The bridge board of your enclosure
has a 1394a-2000 PHY (the TSB41LV03A). The SYM13FW501 appears to be only
a 1394-1995 compliant link layer controller (probably with integrated
PHY) but this shouldn't matter.
C) IEEE 1394b-2002 compliant PHYs with monolingual S400A port(s). They
behave exactly like 1394a-2000 PHYs.
D) IEEE 1394b-2002 compliant PHYs with monolingual S400B port(s). These
are not interoperable with neither of A, B, C. Therefore such ports need
to have a 9-pin socket whose formfactor is coded as a monolingual port.
Therefore it is physically impossible to connect such a port with ports
of type A, B, or C. I don't know if there are actual products with
monolingual S400B ports.
IEEE 1394b-2002 compliant PHYs may have
- bilingual ports,
- Beta-only ports (Beta mode is a new signaling mode introduced by
1394b which is not interoperable with 1394-1995 and 1394a),
- and/or ports that are forced to only use legacy signaling, i.e. the
same as of IEEE 1394a PHYs.
The S800 9-pin port of the AlBook is a bilingual port; the S400 6-pin
port should be a 1394b port which is forced to use only legacy signaling.
BTW, I have a portable CD-RW which I suspect to have a similar or the
same bridge chip as your HDD. This is because it also shows two nodes
instead of one node and because it suffered the same problem related to
the BROADCAST_CHANNEL register as the Datafab HDD. I cannot open the
CD-RW without damaging it therefore I cannot confirm the actual chips in
there. This CD-RW works fine on a bilingual 1394b PCI adapter with 9-pin
to 6-pin cable.
> I'll make this issue clear next week with a trip to the shop where I
> bought the alubook.
>
> And I'll be back as soon as I know more ...
If you have got the TiBook around, you could connect it with the AlBook
and look what gscanbus or OS X's system profiler have to say about it.
If possible, also try the TiBook in target disk mode and see if it
appears as a disk for Linux' sbp2 or under OS X.
The fact that Linux on the AlBook gets at least as far as "ieee1394:
Error parsing configrom for node 0-00:1023" indicates that not all hope
is lost. If you have got the time, compile the 1394 drivers for verbose
logging and send the log. Don't crosspost the log if it gets too big.
--
Stefan Richter
-=====-=-==- =--- =--==
http://arcgraph.de/sr/
^ permalink raw reply
* Re: [2.6.19 PATCH 4/7] ehea: ethtool interface
From: Michael Ellerman @ 2006-08-19 8:41 UTC (permalink / raw)
To: Andy Gay
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Thomas Klein, linux-ppc, Christoph Raisch, Marcus Eder,
Alexey Dobriyan
In-Reply-To: <1155970112.7302.434.camel@tahini.andynet.net>
[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]
On Sat, 2006-08-19 at 02:48 -0400, Andy Gay wrote:
> On Sat, 2006-08-19 at 16:18 +1000, Michael Ellerman wrote:
>
> >
> > If you try to return an uninitialized value the compiler will warn you,
> > you'll then look at the code and realise you missed a case, you might
> > save yourself a bug.
>
> You *should* look at the code :)
>
> So should we be reporting these as bugs?
No you're better off sending patches ;)
A lot of these have started appearing recently, which I think is due to
GCC becoming more vocal. Unfortunately many of them are false positives
caused by GCC not seeming to grok that this is ok:
void foo(int *x) { *x = 1; }
...
int x;
foo(&x);
return x;
It's a pity because it creates noise, but still it's beside the point.
New code going into the kernel should be 100% warning free, and so if
the eHEA guys had missed an error case they'd spot the warning before
they submitted it.
Doing the initialise-to-some-value "trick" means you only spot the bug
via testing.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [2.6.19 PATCH 4/7] ehea: ethtool interface
From: Andy Gay @ 2006-08-19 6:48 UTC (permalink / raw)
To: michael
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Thomas Klein, linux-ppc, Christoph Raisch, Marcus Eder,
Alexey Dobriyan
In-Reply-To: <1155968305.1388.4.camel@localhost.localdomain>
On Sat, 2006-08-19 at 16:18 +1000, Michael Ellerman wrote:
>
> If you try to return an uninitialized value the compiler will warn you,
> you'll then look at the code and realise you missed a case, you might
> save yourself a bug.
You *should* look at the code :)
So should we be reporting these as bugs?
andy@cx02:~/linux/linux-2.6.17.6$ script make.script
Script started, file is make.script
andy@cx02:~/linux/linux-2.6.17.6$ make
...
Script done, file is make.script
andy@cx02:~/linux/linux-2.6.17.6$ fgrep warning make.script
arch/i386/kernel/cpu/transmeta.c:12: warning: 'cpu_freq' may be used uninitialized in this function
fs/bio.c:169: warning: 'idx' may be used uninitialized in this function
fs/eventpoll.c:500: warning: 'fd' may be used uninitialized in this function
fs/isofs/namei.c:162: warning: 'offset' may be used uninitialized in this function
fs/isofs/namei.c:162: warning: 'block' may be used uninitialized in this function
fs/nfsd/nfsctl.c:292: warning: 'maxsize' may be used uninitialized in this function
fs/udf/balloc.c:751: warning: 'goal_eloc.logicalBlockNum' may be used uninitialized in this function
fs/udf/super.c:1358: warning: 'ino.partitionReferenceNum' may be used uninitialized in this function
fs/xfs/xfs_alloc_btree.c:611: warning: 'nkey.ar_startblock' may be used uninitialized in this function
fs/xfs/xfs_alloc_btree.c:611: warning: 'nkey.ar_blockcount' may be used uninitialized in this function
fs/xfs/xfs_bmap.c:2498: warning: 'rtx' is used uninitialized in this function
fs/xfs/xfs_bmap_btree.c:753: warning: 'nkey.br_startoff' may be used uninitialized in this function
fs/xfs/xfs_da_btree.c:151: warning: 'action' may be used uninitialized in this function
fs/xfs/xfs_dir.c:363: warning: 'totallen' may be used uninitialized in this function
fs/xfs/xfs_dir.c:363: warning: 'count' may be used uninitialized in this function
fs/xfs/xfs_ialloc_btree.c:545: warning: 'nkey.ir_startino' may be used uninitialized in this function
fs/xfs/xfs_inode.c:1958: warning: 'last_dip' may be used uninitialized in this function
fs/xfs/xfs_inode.c:1960: warning: 'last_offset' may be used uninitialized in this function
fs/xfs/xfs_log.c:1749: warning: 'iclog' may be used uninitialized in this function
fs/xfs/xfs_log_recover.c:523: warning: 'first_blk' may be used uninitialized in this function
ipc/msg.c:338: warning: 'setbuf.qbytes' may be used uninitialized in this function
ipc/msg.c:338: warning: 'setbuf.uid' may be used uninitialized in this function
ipc/msg.c:338: warning: 'setbuf.gid' may be used uninitialized in this function
ipc/msg.c:338: warning: 'setbuf.mode' may be used uninitialized in this function
ipc/sem.c:810: warning: 'setbuf.uid' may be used uninitialized in this function
ipc/sem.c:810: warning: 'setbuf.gid' may be used uninitialized in this function
ipc/sem.c:810: warning: 'setbuf.mode' may be used uninitialized in this function
drivers/md/dm-table.c:431: warning: 'dev' may be used uninitialized in this function
drivers/md/dm-ioctl.c:1388: warning: 'param' may be used uninitialized in this function
net/sched/sch_cbq.c:409: warning: 'ret' may be used uninitialized in this function
lib/zlib_inflate/inftrees.c:121: warning: 'r.base' may be used uninitialized in this function
^ permalink raw reply
* ioremap() twice on same memory mapped area?
From: Parav Pandit @ 2006-08-19 6:52 UTC (permalink / raw)
To: Linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
Hi,
I have memory mapped device and two device drivers wants to use the same area for different external device.
To access the same space there is a global spin lock to avoid any race condition.
Question is:
Can both the driver call the ioremap() on the same space and get the different virtual address? or ioremap() should fail?
Regards,
Parav Pandit
---------------------------------
Get your email and more, right on the new Yahoo.com
[-- Attachment #2: Type: text/html, Size: 663 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox