* Re: [PATCH 2/4]: powerpc/cell spidernet low watermark patch.
From: Linas Vepstas @ 2006-08-18 23:29 UTC (permalink / raw)
To: David Miller
Cc: arnd, jklewis, linux-kernel, linuxppc-dev, netdev, Jens.Osterkamp
In-Reply-To: <20060818.155116.112621100.davem@davemloft.net>
On Fri, Aug 18, 2006 at 03:51:16PM -0700, David Miller wrote:
> I see you moving TX reclaim into tasklets and stuff. I've vehemently
> against that because you wouldn't need it in order to move TX
> processing into software interrupts if you did it all in NAPI
> ->poll().
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.
--linas
^ permalink raw reply
* Re: [PATCH 2/4]: powerpc/cell spidernet low watermark patch.
From: Linas Vepstas @ 2006-08-18 23:45 UTC (permalink / raw)
To: David Miller
Cc: arnd, jklewis, linux-kernel, linuxppc-dev, netdev, Jens.Osterkamp
In-Reply-To: <20060818232942.GO26889@austin.ibm.com>
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.
--linas
^ permalink raw reply
* Re: Broken Firewire 400/SCSI on ppc Powerbook5,8
From: Wolfgang Pfeiffer @ 2006-08-18 23:49 UTC (permalink / raw)
To: linux1394-devel; +Cc: linuxppc-dev, Stefan Richter
In-Reply-To: <20060817230347.GC3440@localhost>
On Fri, Aug 18, 2006 at 01:03:47AM +0200, Wolfgang Pfeiffer wrote:
> Hi All
>
> Short version first:
>
> 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?]
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 ...
Thanks. And sorry the idea with the check via OSX didn't come to my
mind earlier ...
Until then, and a nice week-end to everyone
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
* [RFC] HOWTO use NAPI to reduce TX interrupts
From: Arnd Bergmann @ 2006-08-19 0:56 UTC (permalink / raw)
To: linuxppc-dev
Cc: akpm, netdev, James K Lewis, linux-kernel, Jens Osterkamp,
Jeff Garzik, David Miller
In-Reply-To: <200608190103.05649.arnd@arndb.de>
On Saturday 19 August 2006 01:03, Arnd Bergmann wrote:
> Someone should probably document that in
> Documentation/networking/NAPI_HOWTO.txt, I might end up doing that
> once we get it right for spidernet.
Oh well, what else is there to do on a Friday night ;-)
This is a first draft, I expect to have gotten some aspects wrong,
so please review well.
For those that did not follow the spidernet discussion, it turns out
that all good ethernet drivers call their TX descriptor reclaim function
from their poll() method, but there is no documentation explaining
why this is a good idea . I talked to a number of people that have
written network drivers before and most of them have not understood
this well enough. I'm sure spidernet is not the only driver that
implemented this wrong.
Thanks to benh and davem for being really patient about explaining this
to me!
Arnd <><
diff --git a/Documentation/networking/NAPI_HOWTO.txt b/Documentation/networking/NAPI_HOWTO.txt
index 54376e8..4d333a4 100644
--- a/Documentation/networking/NAPI_HOWTO.txt
+++ b/Documentation/networking/NAPI_HOWTO.txt
@@ -738,6 +738,60 @@ USER PID %CPU %MEM SIZE RSS TTY
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 optimising 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
+frame 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.
+
+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.
+
+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 significan 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 frame 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, regardless of whether it is an rx or tx
+event. Don't get confused by the fact that we're scheduling
+the rx softirq to do tx work.
+
+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:
^ permalink raw reply related
* Re: [RFC] HOWTO use NAPI to reduce TX interrupts
From: Stephen Hemminger @ 2006-08-20 1:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: akpm, netdev, James K Lewis, linux-kernel, linuxppc-dev,
Jens Osterkamp, Jeff Garzik, David Miller
In-Reply-To: <200608190256.26373.arnd@arndb.de>
Arnd Bergmann wrote:
> On Saturday 19 August 2006 01:03, Arnd Bergmann wrote:
>
>> Someone should probably document that in
>> Documentation/networking/NAPI_HOWTO.txt, I might end up doing that
>> once we get it right for spidernet
>>
The reason reclaim via poll() is efficient is because it avoid causing a
softirq that is
necessary when skb_free_irq() is done. Instead it reuses the softirq
from the poll()
routine. Like all Rx NAPI, using poll() for reclaim means:
+ aggregating multiple frames in one irq
- increased overhead of twiddling with the IRQ mask
- more ways to get driver stuck
Some drivers do all their irq work in the poll() routine (including PHY
handling).
This is good if reading the IRQ status does an auto mask operation.
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
information,
tutorial and guide sections.
^ permalink raw reply
* Re: [PATCH] no-execute -- please test
From: Albert Cahalan @ 2006-08-19 3:47 UTC (permalink / raw)
To: Michel Dänzer; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <1155572457.12664.143.camel@thor.lorrainebruecke.local>
On 8/14/06, Michel D=E4nzer <michel@tungstengraphics.com> wrote:
> The diff between the log files doesn't show any explanation as to why it
> works in one case but doesn't in the other, maybe the difference really
> lies on the client side?
You're right. Somehow I hadn't spotted this in my syslog:
fuckup @ 1002f158 with trap 0x400 code 10000000 by x-session-manag
That is the GNOME session manager.
The /proc/*/maps file contains this:
1002f000-101dc000 rwxp 1002f000 00:00 0 [heap]
Why the heck is the heap being executed?
If this is legit, how do I recognize it?
As far as I can tell, this is not the PLT area
and anyway the PLT is marked executable.
$ file /usr/bin/gnome-session
/usr/bin/gnome-session: ELF 32-bit MSB executable, PowerPC or cisco
4500, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses
shared libs), for GNU/Linux 2.4.1, stripped
------------------- some eu-readelf stuff -----------------------
ELF Header:
Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Ident Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: PowerPC
Version: 1 (current)
Entry point address: 0x100077d0
Start of program headers: 52 (bytes into file)
Start of section headers: 124156 (bytes into file)
Flags:
Size of this header: 52 (bytes)
Size of program header entries: 32 (bytes)
Number of program headers entries: 7
Size of section header entries: 40 (bytes)
Number of section headers entries: 27
Section header string table index: 26
Section Headers:
[Nr] Name Type Addr Off Size ES Flags Lk I=
nf Al
[ 0] NULL 00000000 000000 000000 0 0 =
0 0
[ 1] .interp PROGBITS 10000114 000114 00000d 0 A 0 =
0 1
[ 2] .note.ABI-tag NOTE 10000124 000124 000020 0 A 0 =
0 4
[ 3] .hash HASH 10000144 000144 0017ec 4 A 4 =
0 4
[ 4] .dynsym DYNSYM 10001930 001930 002160 16 A 5 =
1 4
[ 5] .dynstr STRTAB 10003a90 003a90 00251a 0 A 0 =
0 1
[ 6] .gnu.version GNU_versym 10005faa 005faa 00042c 2 A 4 =
0 2
[ 7] .gnu.version_r GNU_verneed 100063d8 0063d8 000070 0 A 5 =
2 4
[ 8] .rela.dyn RELA 10006448 006448 00003c 12 A 4 =
0 4
[ 9] .rela.plt RELA 10006484 006484 001320 12 A 4 =
24 4
[10] .init PROGBITS 100077a4 0077a4 000028 0 AX 0 =
0 4
[11] .text PROGBITS 100077d0 0077d0 0132b0 0 AX 0 =
0 16
[12] .fini PROGBITS 1001aa80 01aa80 000020 0 AX 0 =
0 4
[13] .rodata PROGBITS 1001aaa0 01aaa0 003630 0 A 0 =
0 8
[14] .eh_frame PROGBITS 1001e0d0 01e0d0 000004 0 A 0 =
0 4
[15] .ctors PROGBITS 1002e0d4 01e0d4 000008 0 WA 0 =
0 4
[16] .dtors PROGBITS 1002e0dc 01e0dc 000008 0 WA 0 =
0 4
[17] .jcr PROGBITS 1002e0e4 01e0e4 000004 0 WA 0 =
0 4
[18] .got2 PROGBITS 1002e0e8 01e0e8 000010 0 WA 0 =
0 1
[19] .dynamic DYNAMIC 1002e0f8 01e0f8 000180 8 WA 5 =
0 4
[20] .data PROGBITS 1002e278 01e278 00018c 0 WA 0 =
0 4
[21] .got PROGBITS 1002e404 01e404 000014 4 WAX 0 =
0 4
[22] .sdata PROGBITS 1002e418 01e418 000018 0 WA 0 =
0 4
[23] .sbss NOBITS 1002e430 01e430 000118 0 WA 0 =
0 4
[24] .plt NOBITS 1002e548 01e430 001368 0 WAX 0 =
0 4
[25] .bss NOBITS 1002f8b0 01e430 000078 0 WA 0 =
0 4
[26] .shstrtab STRTAB 00000000 01e430 0000ca 0 0 =
0 1
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x10000034 0x10000034 0x0000e0 0x0000e0 R E 0x4
INTERP 0x000114 0x10000114 0x10000114 0x00000d 0x00000d R 0x1
[Requesting program interpreter: /lib/ld.so.1]
LOAD 0x000000 0x10000000 0x10000000 0x01e0d4 0x01e0d4 R E 0x100=
00
LOAD 0x01e0d4 0x1002e0d4 0x1002e0d4 0x00035c 0x001854 RWE 0x100=
00
DYNAMIC 0x01e0f8 0x1002e0f8 0x1002e0f8 0x000180 0x000180 RW 0x4
NOTE 0x000124 0x10000124 0x10000124 0x000020 0x000020 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x000000 0x000000 RW 0x4
Section to Segment mapping:
Segment Sections...
00
01 [RO: .interp]
02 [RO: .interp .note.ABI-tag .hash .dynsym .dynstr
.gnu.version .gnu.version_r .rela.dyn .rela.plt .init .text .fini .
rodata .eh_frame]
03 .ctors .dtors .jcr .got2 .dynamic .data .got .sdata .sbss .plt .=
bss
04 .dynamic
05 [RO: .note.ABI-tag]
06
Dynamic segment contains 48 entries:
Addr: 0x1002e0f8 Offset: 0x01e0f8 Link to section: [ 5] '.dynstr'
Type Value
NEEDED Shared library: [libgnome-desktop-2.so.2]
NEEDED Shared library: [libgnomeui-2.so.0]
NEEDED Shared library: [libstartup-notification-1.so.0]
NEEDED Shared library: [libSM.so.6]
NEEDED Shared library: [libICE.so.6]
NEEDED Shared library: [libgnome-2.so.0]
NEEDED Shared library: [libesd.so.0]
NEEDED Shared library: [libgtk-x11-2.0.so.0]
NEEDED Shared library: [libgdk-x11-2.0.so.0]
NEEDED Shared library: [libatk-1.0.so.0]
NEEDED Shared library: [libgdk_pixbuf-2.0.so.0]
NEEDED Shared library: [libXrandr.so.2]
NEEDED Shared library: [libpango-1.0.so.0]
NEEDED Shared library: [libX11.so.6]
NEEDED Shared library: [libbonobo-2.so.0]
NEEDED Shared library: [libgconf-2.so.4]
NEEDED Shared library: [libbonobo-activation.so.4]
NEEDED Shared library: [libORBit-2.so.0]
NEEDED Shared library: [libgobject-2.0.so.0]
NEEDED Shared library: [libpthread.so.0]
NEEDED Shared library: [libglib-2.0.so.0]
NEEDED Shared library: [libwrap.so.0]
NEEDED Shared library: [libc.so.6]
NEEDED Shared library: [libXau.so.6]
INIT 0x100077a4
FINI 0x1001aa80
HASH 0x10000144
STRTAB 0x10003a90
SYMTAB 0x10001930
STRSZ 9498 (bytes)
SYMENT 16 (bytes)
DEBUG
PLTGOT 0x1002e548
PLTRELSZ 4896 (bytes)
PLTREL RELA
JMPREL 0x10006484
RELA 0x10006448
RELASZ 4956 (bytes)
RELAENT 12 (bytes)
VERNEED 0x100063d8
VERNEEDNUM 2
VERSYM 0x10005faa
NULL
NULL
NULL
NULL
NULL
NULL
Version needs section [ 7] '.gnu.version_r' contains 2 entries:
Addr: 0x100063d8 Offset: 0x0063d8 Link to section: [ 5] '.dynstr'
000000: Version: 1 File: libpthread.so.0 Cnt: 1
0x0010: Name: GLIBC_2.0 Flags: none Version: 3
0x0020: Version: 1 File: libc.so.6 Cnt: 4
0x0030: Name: GLIBC_2.3 Flags: none Version: 6
0x0040: Name: GLIBC_2.2 Flags: none Version: 5
0x0050: Name: GLIBC_2.1 Flags: none Version: 4
0x0060: Name: GLIBC_2.0 Flags: none Version: 2
Note segment of 32 bytes at offset 0x124:
Owner Data size Type
GNU 16 VERSION
OS: Linux, ABI: 2.4.1
^ permalink raw reply
* Re: [PATCH 2/4]: powerpc/cell spidernet low watermark patch.
From: Benjamin Herrenschmidt @ 2006-08-19 4:31 UTC (permalink / raw)
To: David Miller
Cc: arnd, netdev, jklewis, linux-kernel, linuxppc-dev, Jens.Osterkamp
In-Reply-To: <20060818.155116.112621100.davem@davemloft.net>
On Fri, 2006-08-18 at 15:51 -0700, David Miller wrote:
> From: linas@austin.ibm.com (Linas Vepstas)
> Date: Fri, 18 Aug 2006 17:46:18 -0500
>
> > > We're not saying to use the RX interrupt as the trigger for
> > > RX and TX work. Rather, either of RX or TX interrupt will
> > > schedule the NAPI poll.
> >
> > And, for a lark, this is exactly what I did. Just to see.
> > Because there are so few ack packets, there are very few
> > RX interrupts -- not enough to get NAPI to actually keep
> > the device busy.
>
> You're misreading me. TX interrupts are intended to be "enabled" and
> trigger NAPI polls. TX IRQ enabled, enabled :-)
Maybe be because you actually typed "disabled" in your previous
message ? :)
>> The idea is to use NAPI polling with TX interrupts disabled.
> If you want to eliminate them if the kernel keeps hopping into
> the ->hard_start_xmit() via hw interrupt mitigation or whatever,
> that's fine. But if you do need to do TX interrupt processing,
> do it in NAPI ->poll().
Well, we do need to harvest descriptors of course, though I suppose that
can be done in hard_xmit as well. I'm not sure if there is any real
benefit in batching those.
> > I'm somewhat disoriened from this conversation. Its presumably
> > clear that low-watermark mechanisms are superior to NAPI.
> > >From what I gather, NAPI was invented to deal with cheap
> > or low-function hardware; it adds nothing to this particular
> > situation. Why are we talking about this?
>
> NAPI is meant to give fairness to all devices receiving packets
> in the system, particularly in times of high load or overload.
>
> And equally importantly, it allows you to run the majority of your
> interrupt handler in software IRQ context.
That is the most important point imho for the specific case of spidernet
on cell.
> This allows not only your
> locking to be simpler, but it also allows things like oprofile to
> monitor almost your entire IRQ processing path even with just timer
> interrupt based oprofile profiling.
>
> I see you moving TX reclaim into tasklets and stuff. I've vehemently
> against that because you wouldn't need it in order to move TX
> processing into software interrupts if you did it all in NAPI
> ->poll().
Ben.
^ permalink raw reply
* Re: [PATCH 2/4]: powerpc/cell spidernet low watermark patch.
From: Benjamin Herrenschmidt @ 2006-08-19 4:33 UTC (permalink / raw)
To: Linas Vepstas
Cc: arnd, netdev, jklewis, linux-kernel, linuxppc-dev, Jens.Osterkamp,
David Miller
In-Reply-To: <20060818234532.GA8644@austin.ibm.com>
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...
Ben.
^ permalink raw reply
* Re: [2.6.19 PATCH 7/7] ehea: Makefile & Kconfig
From: Michael Ellerman @ 2006-08-19 5:25 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Thomas Klein, linux-ppc, Christoph Raisch, Marcus Eder
In-Reply-To: <200608181337.44153.ossthema@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]
On Fri, 2006-08-18 at 13:37 +0200, Jan-Bernd Themann wrote:
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
>
>
> drivers/net/Kconfig | 6 ++++++
> drivers/net/Makefile | 1 +
> 2 files changed, 7 insertions(+)
>
>
>
> diff -Nurp -X dontdiff linux-2.6.18-rc4/drivers/net/Kconfig patched_kernel/drivers/net/Kconfig
> --- linux-2.6.18-rc4/drivers/net/Kconfig 2006-08-06 11:20:11.000000000 -0700
> +++ patched_kernel/drivers/net/Kconfig 2006-08-08 03:00:49.526421944 -0700
> @@ -2277,6 +2277,12 @@ config CHELSIO_T1
> To compile this driver as a module, choose M here: the module
> will be called cxgb.
>
> +config EHEA
> + tristate "eHEA Ethernet support"
> + depends on IBMEBUS
> + ---help---
> + This driver supports the IBM pSeries ethernet adapter
> +
Please give it a more detailed description. I have a pSeries machine
here with three NICs and none of them are eHEA.
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: Michael Ellerman @ 2006-08-19 6:18 UTC (permalink / raw)
To: Thomas Klein
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Alexey Dobriyan
In-Reply-To: <44E5DFA6.7040707@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 929 bytes --]
On Fri, 2006-08-18 at 17:41 +0200, Thomas Klein wrote:
> Hi Alexey,
>
> first of all thanks a lot for the extensive review.
>
>
> Alexey Dobriyan wrote:
> >> + u64 hret = H_HARDWARE;
> >
> > Useless assignment here and everywhere.
> >
>
> Initializing returncodes to errorstate is a cheap way to prevent
> accidentally returning (uninitalized) success returncodes which
> can lead to catastrophic misbehaviour.
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. By unconditionally initialising you are lying to
the compiler, and it can no longer help you.
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
* 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
* 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
* 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: 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: 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
* 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: [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
* 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: [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
* 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: 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: 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: [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: [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] 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
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