On Mon, 2006-11-06 at 01:37 -0800, Linus Torvalds wrote:
>
> On Mon, 6 Nov 2006, Jeff Garzik wrote:
> >
> > This seems a bit ugly. Could you add
> >
> > #define readq readq
> >
> > to your platform instead?
>
> Heartily agreed. MUCH better than adding unrelated #if defined() stuff,
> whet
> This is why I said "good enough for drivers". This is _key_.
>
> I have run into several [PCI] devices with 64-bit registers, and
> __none__ of them had requirements such that the Linux platform code
> -must- provide an atomic readq/writeq. Probably because everybody wants
> to support 32-b
> This seems a bit ugly. Could you add
>
> #define readq readq
>
> to your platform instead?
That's ugly too imho but I suppose I can do it :-)
> I generally think it's a bug in the kernel-wide API, if use of said API
> requires arch-specific ifdefs.
Yes. I agree. In that specific cas
l those IO accessors which will break that test. This fixes it. I
don't have anything less ugly at hand unfortunately.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
---
The patch changing ppc64 own definition is scheduled to go in 2.6.20 when
the merge window opens, so it would
On Sun, 2006-11-05 at 14:00 +0100, Eric Lemoine wrote:
> Hi!
>
> Some (long) time ago benh wrote a blaming comment in sungem.c about
> that driver's locking strategy. That comment basically says that we
> probably don't need two spinlocks.
Yeah :) Note that I mostly blamed myself there ... Just n
On Thu, 2006-10-19 at 17:29 +0200, Michael Buesch wrote:
> Drain the Microcode TX-status-FIFO before we enable IRQs.
> This is required, because the FIFO may still have entries left
> from a previous run. Those would immediately fire after enabling
> IRQs and would lead to an oops in the DMA TXstat
On Sat, 2006-10-14 at 15:55 -0400, Jesse Huang wrote:
> From: Jesse Huang <[EMAIL PROTECTED]>
>
> Change Logs:
> For patent issue need to remove TxStartThresh and RxEarlyThresh. This patent
> is cut-through patent. If use this function, Tx will start to transmit after
> few data be move in to Tx
> I started writingthe patch thinking it will have some huge effect on
> performance, based on a false assumption on how i/o was done on this
> machine
>
> *If* this were another pSeries system, then each call to
> pci_map_single() chews up an actual hardware "translation
> control entry" (TCE)
On Tue, 2006-10-10 at 18:20 -0500, jschopp wrote:
> Linas Vepstas wrote:
> > The current driver code performs 512 DMA mappns of a bunch of
> > 32-byte structures. This is silly, as they are all in contiguous
> > memory. Ths patch changes the code to DMA map the entie area
> > with just one call.
On Wed, 2006-09-27 at 19:43 -0500, Larry Finger wrote:
> Benjamin Herrenschmidt wrote:
> >>
> > I won't try some random other git tree to test things, it's simply not
> > feasible for me and we need something we can give to distros to backport
> > so
On Wed, 2006-09-27 at 19:50 +0200, Michael Buesch wrote:
> On Wednesday 27 September 2006 18:18, Larry Finger wrote:
> > Michael Buesch wrote:
> > > This fixes some race conditions in the WirelessExtension
> > > handling and association handling code.
> > >
> > > Signed-off-by: Michael Buesch <[EM
On Wed, 2006-09-27 at 17:26 +0200, Michael Buesch wrote:
> This fixes some race conditions in the WirelessExtension
> handling and association handling code.
Unlike the previous patch, this one doesn't apply on top of 2.6.18
(which I'm using as a basis for testing, along with Larry big bcm43xx
pat
On Mon, 2006-09-25 at 20:07 -0400, Jeff Garzik wrote:
> patch does not apply.
>
> also, it would seem like varargs would be appropriate here.
Not really... these are hypervisor calls, their calling convention is
not varargs, thus we would need some conversion layer if using them,
with possible pe
> yes. Many locking issues in d80211 to still sort out. Basically, there
> are next to no useful locks in it and most data structures are not
> protected at all.
Doh ! Scary... locking is hard ... if the stuff was written without
locking in mind in the first place, it might end up being a nightma
On Sun, 2006-09-24 at 10:43 +0200, Michael Buesch wrote:
> On Sunday 24 September 2006 10:12, Benjamin Herrenschmidt wrote:
> > > > So what are the chances of getting this dscape stack merged, let's
> > > > say... for 2.6.19 ? Or we'll get yet another ful
> > So what are the chances of getting this dscape stack merged, let's
> > say... for 2.6.19 ? Or we'll get yet another full release with barely
> > working wireless ?
>
> I don't think it's possible to happen for 2.6.19.
> Ealiest 2.6.20 but likely one or two releases later (me thinks).
Which me
On Sat, 2006-09-23 at 23:45 -0400, Daniel Drake wrote:
> Benjamin Herrenschmidt wrote:
> > Oh and I don't care about "it works in dscape stack" sort of crap I
> > regulary get. I want something that
> > works with upstream kernels. That isn't that much
> prism54 fullmac, right?
Yes.
> Try using -Dwext; the prism54 wpa_supplicant driver is a dead-end and I
> added WE-19 commands to it a bit ago anyway. Oddly enough, I couldn't
> seem to get the driver to work reliably for me using straight WEP
> either, let alone WPA. It's pretty unmaintained
Hi folks !
So this is 2.6.18 + Larry "fix" (though I've seen this problem before,
it seems using WPA just make it happen more often).
This is also a 4318, so the link is pretty weak due to the Tx Power
problem and I suspects it makes the driver problems more visible...
So basically, I "lose" the
On Wed, 2006-09-20 at 02:21 +0200, Segher Boessenkool wrote:
> > Nah. We have the basic rule that readl/writel are little endian.
> > PowerPC
> > additionally provides arch specific low level in_{be,le}32 type
> > accessors with explicit endianness. Or you can also use
> > cpu_to_le32/le32_to_cpu
On Tue, 2006-09-19 at 20:52 +0200, Matt Sealey wrote:
> Some northbridges and PCI bridges have "clever" byteswapping in
> hardware, maybe this is just an effect of that. In theory depending on
> the host bridge, you should pass in big endian data and have it swap or
> not swap, not pick that way
> However, I presume someone added the __powerpc__ define here
> because they picked up a 3c509 at a garage sale, stuck it in
> a powerpc, found out it didn't work due to a byte-swapping bug,
> and then patched it as above. I'm disturbed that somehow
> outsl_ns() became identical to outsl() at
Ok, it seems like we might have more than just the missing barrier in
TG3. Possibly some IOMMU problems on some machines as well.
Unfortunately, I don't have a tg3 on a PCI-X or PCI-E card to test on a
pSeries or some other machine.
[Olof: I've disabled the new U4 DART invalidate code (reverted to
On Sun, 2006-09-10 at 22:33 -0700, Michael Chan wrote:
> Benjamin Herrenschmidt wrote:
>
> > I've done:
> >
> > #define tw32_rx_mbox(reg, val) do { wmb();
> tp->write32_rx_mbox(tp, reg, val); } while(0)
> > #define tw32_tx_mbox(reg, val) do {
On Sun, 2006-09-10 at 22:18 -0700, Michael Chan wrote:
> Benjamin Herrenschmidt wrote:
>
> > I've added a wmb() in tw32_rx_mbox() and tw32_tx_mbox() and can still
> > reproduce the problem. I've also done a 2 days run without TSO enabled
> > without a failure (my
> Oh, we know about this. The powerpc writel() used to have memory
> barriers in 2.4 kernels but not any more in 2.6 kernels. Red Hat's
> version of tg3 has extra wmb()'s to fix this problem. David doesn't
> think that the upstream version of tg3 should have these wmb()'s, and
> the problem sho
> But funky cascading using chained flow handlers doesn't work if the cascade
> must share an IRQ with some other device, right?
Indeed. Best way there is then to have a normal action handler like you
do and have it call generic_handle_irq() on the cascaded interrupts.
Ben.
-
To unsubscribe fr
> > semantics. At least what is implemented currently on PowerPC is the
> > __raw_* versions which not only have no barriers at all (they don't even
> > order between MMIOs, for example, readl might cross writel), and do no
> > endian swap. Quite a mess of semantics if you ask me... Then there has
On Sat, 2006-09-09 at 02:22 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Sat, 09 Sep 2006 07:46:02 +1000
>
> > I don't think that in general, you have ordering guarantees between
> > cacheable and non-cacheable stores
> > I'd rather not have to do that, or even if I go that way, not have to
> > add that sync at all before the store and thus get back the few percent
> > of perfs lost due to those sync's on some heavy IO benchmarks.
> >
> Another way to fix this without requiring drivers to add all kinds of
> ba
On Fri, 2006-09-08 at 15:07 -0700, Michael Chan wrote:
> On Sat, 2006-09-09 at 07:41 +1000, Benjamin Herrenschmidt wrote:
>
> > As for the tcpdump output, well, I have a 3Gb file for now :) I need to do
> > a bit of surgery on it to
> > get only the interesting part. I
On Fri, 2006-09-08 at 12:54 -0700, Michael Chan wrote:
> On Fri, 2006-09-08 at 21:29 +0200, Segher Boessenkool wrote:
>
> > I've got a patch that seems so solve the problem, it needs more testing
> > though (maybe Ben can do this :-) ). The problem is that there should
> > be quite a few wmb()'s
> Please send me lspci and tg3 probing output so that I know what
> tg3 hardware you're using. I also want to look at the tcpdump or
> ethereal on the mirrored port that shows the packet being corrupted.
Hi Michael !
It's the dual controller of an Apple Quad G5, thus afaik in an HT2000
chip:
0
On Fri, 2006-09-08 at 11:25 +0100, David Howells wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > No, you do a chain handler. Look at how I do it in
> > arch/powerpc/platform/pseries/setup.c for example. It's actually
> > trivial. You install
On Thu, 2006-09-07 at 10:55 +0100, David Howells wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > Well, genirq gives you more flexibility than the current mecanism so ...
>
> No, it doesn't because the FRV arch contains its own mechanism and I ca
> Under some circumstances I can work out which sources have triggered which
> interrupts (there are various off-CPU FPGAs which implement auxiliary PICs
> that
> do announce their sources), but the aux-PIC channels are grouped together upon
> delivery to the CPU PIC, so some of the ACK'ing has t
On Tue, 2006-09-05 at 14:36 -0700, Stephen Hemminger wrote:
> This is the reduced version of your patch, plus I got rid of the union
> in tx_le, it is a nuisance.
Thanks. I'll give it a go later today. The remaining nit is the
inconsitent swapping of the vlan tag which is manipulated at BE at time
> Agreed. Actually the checksum value is same hi/lo because there are
> two checksum units and we ask for the same offset on both.
Ok, that explains the (HLEN << 16) | HLEN thing when configuring it...
At this point, best is I dig into the actual values and see what's up.
I'll let you know (I don
> > Which means that if it worked on x86 with le16_to_cpu, it should work on
> > powerpc... The main difference here however is that you called
> > le16_to_cpu (which is basically a nop) on a 32 bits field, while I
> > called le32_to_cpu() on it. But both should lead to the same ... (x86
> > will
On Mon, 2006-09-04 at 21:15 -0700, Stephen Hemminger wrote:
> On Tue, 05 Sep 2006 13:47:52 +1000
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> >
> > > It may not need any swapping, it is hard to tell what the hardware
> > > will do without experi
On Mon, 2006-09-04 at 20:56 -0700, Stephen Hemminger wrote:
> On Tue, 05 Sep 2006 13:42:38 +1000
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 2006-09-04 at 20:34 -0700, Stephen Hemminger wrote:
> > > Unneeded byte swap was occurring.
> >
> It may not need any swapping, it is hard to tell what the hardware
> will do without experimentation.
Yes... did you have a chance to test the vlan stuff on LE machines
(x86) ? did it work with the BE swapping you were doing ? I've
purposedly removed in my patches the hardware side swapping of
On Mon, 2006-09-04 at 20:34 -0700, Stephen Hemminger wrote:
> Unneeded byte swap was occurring.
>
> --- linux-2.6.orig/drivers/net/sky2.c
> +++ linux-2.6/drivers/net/sky2.c
> @@ -2001,7 +2001,7 @@ static int sky2_status_intr(struct sky2_
> case OP_RXCHKS:
> skb
Hi Stephen !
So I now have the driver working with the patches I gave you. However,
when I set it up with a 100bT link and transfer a huge file from another
machine (about 10MB/sec throughput), I get a few of these in dmesg
eth2: hw csum failure.
Call Trace:
[CFFEF8D0] [C000F460]
On Mon, 2006-09-04 at 23:05 +0200, Segher Boessenkool wrote:
> > The patch has a couple of places where I reversed 2 assignments, they
> > are harmless, it was before I figured out that the chip will
> > (apparently) not access a descriptor before it's been told to do so
> > via
> > MMIO, and thu
just
misudnerstand what's happening there so I'll let you decide what to do
about those.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Index: linux-work/drivers/net/sky2.c
===
--- linux-work.orig/driv
> Because if you look at the definition for:
>
> struct sky2_rx_le {
> __le32 addr;
> __le16 length;
> u8 ctrl;
> u8 opcode;
> } __attribute((packed));
>
> (As an example)
>
> If the chips does LE accesses, then marking "lenght" as being an LE
> value isn't e
Hi Stephen !
To try to validate some PCIe code we have around, I got myself a
SysKonnect SK-9Exx card (one x1 lane one port and one x4 lanes 2 ports
actually, though I've only tested the first one at this point, based on
a 88E8061 Marvell chip).
I've used the sky2 driver as of a random last week'
> 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 hardw
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()
On Fri, 2006-08-18 at 15:51 -0700, David Miller wrote:
> From: [EMAIL PROTECTED] (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
On Fri, 2006-08-11 at 12:08 -0500, Linas Vepstas wrote:
>
> Implement basic low-watermark support for the transmit queue.
>
> The basic idea of a low-watermark interrupt is as follows.
> The device driver queues up a bunch of packets for the hardware
> to transmit, and then kicks he hardware to g
On Thu, 2006-07-06 at 16:34 -0700, Bryan O'Sullivan wrote:
> On Fri, 2006-07-07 at 08:37 +1000, Benjamin Herrenschmidt wrote:
>
> > > +int ipath_unordered_wc(void)
> > > +{
> > > + return 1;
> > > +}
> >
> > How is the above providin
> +#if defined(__powerpc__)
> + /* There isn't a generic way to specify writethrough mappings */
> + pgprot_val(vma->vm_page_prot) |= _PAGE_NO_CACHE;
> + pgprot_val(vma->vm_page_prot) |= _PAGE_WRITETHRU;
> + pgprot_val(vma->vm_page_prot) &= ~_PAGE_GUARDED;
> +#endif
I don't see an
On Fri, 2006-05-26 at 06:30 -0400, Jeff Garzik wrote:
> Benjamin Herrenschmidt wrote:
> >>> No proper interface exposed, he'll have to do an #ifdef powerpc here or
> >>> such and use __ioremap with explicit page attributes. I have a hack to
> >>>
> > No proper interface exposed, he'll have to do an #ifdef powerpc here or
> > such and use __ioremap with explicit page attributes. I have a hack to
> > do that automatically for memory covered by prefetchable PCI BARs when
> > mmap'ing from userland but not for kernel ioremap.
>
> Stupid quest
On Wed, 2006-05-24 at 10:04 +0200, Brice Goglin wrote:
> I am not sure what you mean.
> The only ppc64 with PCI-E that we have seen so far (a G5) couldn't do
> write combining according to Apple.
That is not 100% true I don't know what apple had in mind. It also
depends in what slot you are.
On Wed, 2006-05-24 at 01:39 +1000, Anton Blanchard wrote:
> > +#ifdef CONFIG_MTRR
> > + mgp->mtrr = mtrr_add(mgp->iomem_base, mgp->board_span,
> > +MTRR_TYPE_WRCOMB, 1);
> > +#endif
> ...
> > + mgp->sram = ioremap(mgp->iomem_base, mgp->board_span);
>
> Not sure how we
On Sun, 2006-04-16 at 02:52 +0200, Johannes Berg wrote:
> In a short discussion with Benjamin Herrenschmidt he mentioned
> that Marvell PHYs are powered down the same way as the other
> ones we currently handle. Thus actually do that, hopefully
> saving some power during suspend.
>
On Wed, 2006-04-12 at 00:30 +0200, Benoit Boissinot wrote:
> On Wed, Apr 12, 2006 at 08:21:17AM +1000, Benjamin Herrenschmidt wrote:
> >
> > > I still think we shouldn't reward shit hardware by complicating
> > > up our DMA mappings internals. :-)
> >
>
On Tue, 2006-04-11 at 14:34 -0700, David S. Miller wrote:
> I still think we shouldn't reward shit hardware by complicating
> up our DMA mappings internals. :-)
Heh, it's a good point but in that specific case, it's a bit difficult
to tell that to users who don't have a choice of what card to put
> I still think we shouldn't reward shit hardware by complicating
> up our DMA mappings internals. :-)
BTW. In the meantime, can't that driver work in PIO only mode ?
Ben.
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More maj
> I think allowing DMA mask range limiting in the IOMMU layer is going
> to set a very bad precedence, just don't do it.
>
> It's 2006, we should be way past the era of not putting the full 32
> PCI DMA address bits in devices. In this day and age it is simply
> inexscusable.
>
> Maybe we could
> The hacks i see there is reallocating a buffer with GFP_DMA, so that
> means that if the ppc dma_alloc_coherent did the same thing as the i386
> counterpart (adding GFP_DMA if dma_mask is less than 32bits) it should
> work, no ?
Except that GFP_DMA covers the whole address space on ppc64...
Be
> Yes, I know they hit the message, that's from a message in some forum
> that i got interested in the issue. It probably comes from an allocation
> from:
> http://www.linux-m32r.org/lxr/http/source/arch/powerpc/kernel/pci_direct_iommu.c#L32
>
> Either the ppc code is wrong (it doesn't enforce dm
On Thu, 2006-03-23 at 22:01 -0800, David S. Miller wrote:
> Otherwise looks fine.
>
> Please find a non-x86_64 64-bit system to at least cross compile test
> into, preferably big-endian to really get all the nasties out :-)
That reminds me that I should really add something to the ppc64 iommu
co
Ok, I found what I was talking about on irc...
Andy Fleming wrote a proper PHY layer, initially based on sungem_phy but
then evolved into something more versatile including some of the link
state machine that is currently still in the MAC driver for sungem.
You should probably use that...
It's a
On Mon, 2006-03-06 at 11:40 +0100, Andreas Schwab wrote:
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes:
>
> > On Sat, 2006-03-04 at 15:53 +0100, Andreas Schwab wrote:
> >> I suppose the NIC in the PowerMac G5 can do GigE, yet when plugged into a
> >>
On Fri, 2006-03-03 at 09:06 +0100, Olaf Hering wrote:
> the RX errors I'm seeing every once in a while are still there in
> 2.6.16rc5. Maybe they happen if there is some IO load on the IDE disks,
> just upgraded openoffice.rpm
Which machine is this ? Apple has several revs of Sungem, some of them
On Sat, 2006-03-04 at 15:53 +0100, Andreas Schwab wrote:
> [Sorry for duplicate posting, I've used the wrong list address.]
>
> I suppose the NIC in the PowerMac G5 can do GigE, yet when plugged into a
> GB switch it is only willing to talk 100MB with it. Any idea why? Kernel
> is 2.6.16-rc5-git
On Wed, 2006-02-01 at 00:54 -0800, [EMAIL PROTECTED] wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Andrew, please drop it for now. It has issues on sparc64 that I need to
have a look at.
Ben.
> On my latest laptop, I've had occasional PHY dead on wakeup from sl
PHY reset line since sungem doesn't call it in an
> atomic context anymore.
>
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>b
> Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
>
> For example, clearing all of those extra bits in gem_init_p
On Tue, 2006-01-03 at 04:20 -0500, Michael Wu wrote:
> On Monday 02 January 2006 09:22, Ivo van Doorn wrote:
> > Hi rt2x00-devel & netdev lists,
> >
> > First I would like to wish everybody a happy new year!
> >
> > Secondly I would like to make the announcement that the rt2x00 project
> > has deci
On Fri, 2005-12-30 at 04:22 +0100, Johannes Berg wrote:
> This patch fixes some of the ieee80211 crypto related code so that
> instead of having the host fully do crypto operations, the host_build_iv
> flag works properly (for WEP in this patch) which, if turned on,
> requires the hardware to do al
401 - 474 of 474 matches
Mail list logo
