* 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
* 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: 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: 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: 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: 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: [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
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