* Re: [PATCH v3 4/7] fsl_pq_mdio: Add Suport for etsec2.0 devices.
From: David Miller @ 2009-10-30 4:21 UTC (permalink / raw)
To: Sandeep.Kumar; +Cc: netdev, afleming
In-Reply-To: <1256826229-529-1-git-send-email-Sandeep.Kumar@freescale.com>
From: Sandeep Gopalpet <Sandeep.Kumar@freescale.com>
Date: Thu, 29 Oct 2009 19:53:49 +0530
> From: Sandeep Gopalpet <sandeep.kumar@freescale.com>
>
> This patch adds mdio support for etsec2.0 devices.
>
> Modified the fsl_pq_mdio structure to include the new mdio
> members.
>
> Signed-off-by: Sandeep Gopalpet <sandeep.kumar@freescale.com>
> ---
> *. Rebased to the net-next-2.6 tree as of 20091028 cloned from
> http://www.kernel.org/pub/scm/linux/kernel/git/davem/net-next-2.6.git
It does not apply, again.
And again, here is the bundle I tried to apply using "git am --signoff":
http://vger.kernel.org/~davem/bundle-641.mbox
--------------------
davem@sunset:~/src/GIT/net-next-2.6$ git am --signoff bundle-641.mbox
Applying: gianfar: Add per queue structure support
Applying: gianfar: Introduce logical group support.
Applying: gianfar: Add Multiple Queue Support
Applying: fsl_pq_mdio: Add Suport for etsec2.0 devices.
error: patch failed: drivers/net/fsl_pq_mdio.c:405
error: drivers/net/fsl_pq_mdio.c: patch does not apply
Patch failed at 0004 fsl_pq_mdio: Add Suport for etsec2.0 devices.
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
--------------------
Did you try the bundle I posted yesterday which failed? This
one is identical, you didn't change anything.
This is getting rediculious.
Try again, and when you do take the patches from patchwork at:
http://patchwork.ozlabs.org/project/netdev/list/
and you try to apply them to net-next-2.6 using git (_not_ 'patch',
'patch' is way too lenient about fuzz and line offsets) so that you
can see what's happening.
I'm completely ignoring your patch postings until you sort this out.
You cannot have line offsets or fuzz when you send patches that are to
be applied by GIT, and that is the problem with patch #4:
davem@sunset:~/src/GIT/net-next-2.6$ patch -p1 <diff
patching file drivers/net/fsl_pq_mdio.c
Hunk #6 succeeded at 436 with fuzz 1.
patching file drivers/net/fsl_pq_mdio.h
GIT does not allow line fuzz, you must make absolutely pristine
patches, and therefore if you are testing your submission with just
'patch' that absolutely will not work.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/4] gro: Name the GRO result enumeration type
From: David Miller @ 2009-10-30 4:29 UTC (permalink / raw)
To: herbert; +Cc: bhutchings, netdev, linux-net-drivers
In-Reply-To: <20091029174811.GA30749@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 29 Oct 2009 13:48:11 -0400
> On Thu, Oct 29, 2009 at 05:17:09PM +0000, Ben Hutchings wrote:
>> This clarifies which return and parameter types are GRO result codes
>> and not RX result codes.
>>
>> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: [PATCH 2/4] gro: Change all receive functions to return GRO result codes
From: David Miller @ 2009-10-30 4:29 UTC (permalink / raw)
To: herbert; +Cc: bhutchings, netdev, linux-net-drivers
In-Reply-To: <20091029174823.GB30749@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 29 Oct 2009 13:48:23 -0400
> On Thu, Oct 29, 2009 at 05:18:15PM +0000, Ben Hutchings wrote:
>> This will allow drivers to adjust their receive path dynamically
>> based on whether GRO is being applied successfully.
>>
>> Currently all in-tree callers ignore the return values of these
>> functions and do not need to be changed.
>>
>> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied.
^ permalink raw reply
* Re: [PATCHv2] gro: Name the GRO result enumeration type
From: David Miller @ 2009-10-30 4:32 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1256840775.2827.83.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 29 Oct 2009 18:26:15 +0000
> This clarifies which return and parameter types are GRO result codes
> and not RX result codes.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
> ---
> This replaces the previous patch 1/4 and avoids introducing compiler
> warnings. The original patches 2-4 will still apply on top of it.
You can't do this Ben.
Changing this patch makes the follow-on patches not apply cleanly.
So if you respin stuff like this, you have to respin the follow-on
patches too.
I'll fix this up, but I am so irritated that I've wasted so much time
tonight already on patch submissions that were not handled with any
care at all. And it's all at my expense.
^ permalink raw reply
* Re: [PATCH 3/4] sfc: Feed GRO result into RX allocation policy and interrupt moderation
From: David Miller @ 2009-10-30 4:33 UTC (permalink / raw)
To: bhutchings; +Cc: netdev, linux-net-drivers
In-Reply-To: <1256836884.2827.73.camel@achroite>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Thu, 29 Oct 2009 17:21:24 +0000
> When GRO is successfully merging received packets, we should allocate
> raw page buffers rather than skbs that will be discarded by GRO.
> Otherwise, we should allocate skbs.
>
> GRO also benefits from higher interrupt moderation, so increase the
> score for mergeable RX packets.
>
> Signed-off-by: Ben Hutchings <bhutchings@solarflare.com>
I'll pull net-2.6 into net-next-2.6 before applying this patch and the
next one.
But you need to tell me that such dependencies exist when you submit
patches like this, ok?
^ permalink raw reply
* Re: [PATCH] sky2: set carrier off in probe
From: Brandon Philips @ 2009-10-30 4:30 UTC (permalink / raw)
To: David Miller; +Cc: shemminger, netdev
In-Reply-To: <20091029.211219.182331672.davem@davemloft.net>
On 21:12 Thu 29 Oct 2009, David Miller wrote:
> From: Brandon Philips <bphilips@suse.de>
> Date: Thu, 29 Oct 2009 20:51:28 -0700
>
> > The right thing to do is up the interface first before looking at the
> > the Link state, and I told them to do that, but I figured that this
> > patch made sense too to fix the initial buglet.
>
> It is not valid to expect link status before bringing the interface
> up.
I agree the link state makes no sense when the interface isn't up.
The buglet is that other drivers seem to report "Link detected: no"
after probe while sky2 doesn't.
I don't have a strong feeling on this patch since the customer fixed
their script to do the right thing.
Cheers,
Brandon
^ permalink raw reply
* Re: [PATCH] sky2: set carrier off in probe
From: David Miller @ 2009-10-30 4:38 UTC (permalink / raw)
To: bphilips; +Cc: shemminger, netdev
In-Reply-To: <20091030043050.GB3380@jenkins.home.ifup.org>
From: Brandon Philips <bphilips@suse.de>
Date: Thu, 29 Oct 2009 21:30:50 -0700
> The buglet is that other drivers seem to report "Link detected: no"
> after probe while sky2 doesn't.
I agree that we should report something consistent before interface
up and 'no' is probably the best.
I remember fixing something similar in other drivers a few months
ago.
^ permalink raw reply
* Re: [RFC-PATCH] dhcp provisioning support in cxgb3i
From: Rakesh Ranjan @ 2009-10-30 5:24 UTC (permalink / raw)
To: Mike Christie
Cc: davem, James Bottomley, Karen Xie, open-iscsi@googlegroups.com,
LKML, linux-scsi@vger.kernel.org, netdev
In-Reply-To: <4AEA04A4.1060800@cs.wisc.edu>
Mike Christie wrote:
> Rakesh Ranjan wrote:
>> Hi Mike,
>>
>> Herein attached patches for having dhcp provisioning support in
>> cxgb3i. I have added one new iscsi netlink message
>> ISCSI_UEVENT_REQ_IPCONF.
>
> Is the idea to have iscsid/uip send down this msg?
>
> Was it not possible to hook in more like how bnx2i does dhcp?
yep, idea is to have iscsid send down ISCSI_UEVENT_REQ_IPCONF msg. bnx2i
approach in our case for at least T3 is not feasible.
Regards
Rakesh Ranjan
^ permalink raw reply
* Re: [PATCH] udev: create empty regular files to represent net interfaces
From: dann frazier @ 2009-10-30 5:38 UTC (permalink / raw)
To: Greg KH, Matt Domsch, Kay Sievers, linux-hotplug, Narendra_K,
netdev, Jordan_Ha
In-Reply-To: <20091030033029.GA4412@bongo.bofh.it>
On Fri, Oct 30, 2009 at 04:30:29AM +0100, Marco d'Itri wrote:
> On Oct 29, dann frazier <dannf@dannf.org> wrote:
>
> > That would make a lot of users much happier (myself included), but it
> > does restrict us into one view. At different times, admins think of
> > their NICs by different properties. I may want to do IP assignment by
> [Citation needed]
Is "I" not clear, or do you just not believe I admin servers?
--
dann frazier
^ permalink raw reply
* Re: [PATCH kernel 2.6.32-rc5] pcnet_cs: add cis of PreMax PE-200 ethernet pcmcia card
From: David Miller @ 2009-10-30 5:51 UTC (permalink / raw)
To: ken_kawasaki; +Cc: netdev
In-Reply-To: <20091018103920.ca9217ee.ken_kawasaki@spring.nifty.jp>
From: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Date: Sun, 18 Oct 2009 10:39:20 +0900
>
> pcnet_cs,serial_cs:
>
> add cis of PreMax ethernet pcmcia card,
> and some Sierra Wireless serial card(AC555, AC7xx, AC8xx).
>
> use PROD_ID for AC7xx, because MANF_ID of AC7xx and AC8xx are the same.
>
>
> Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH] net: Fix RPF to work with policy routing
From: David Miller @ 2009-10-30 5:51 UTC (permalink / raw)
To: hadi; +Cc: netdev, atis, eric.dumazet, zenczykowski
In-Reply-To: <1255867954.4815.25.camel@dogo.mojatatu.com>
From: jamal <hadi@cyberus.ca>
Date: Sun, 18 Oct 2009 08:12:33 -0400
> commit f7c6fd2465d8e6f4f89c5d1262da10b4a6d499d0
> Author: Jamal Hadi Salim <hadi@cyberus.ca>
> Date: Sun Oct 18 08:04:51 2009 -0400
>
> [PATCH] net: Fix RPF to work with policy routing
> Policy routing is not looked up by mark on reverse path filtering.
> This fixes it.
>
> Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: [PATCH 0/6] sky2: driver update
From: David Miller @ 2009-10-30 5:53 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20091029163704.793246334@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Thu, 29 Oct 2009 09:37:04 -0700
> This patch set adds support for Yukon Optima (88E8059) based
> on the vendor driver. Hopefully, it can go in 2.6.32.
Sorry, this is too much too late. You don't even have the hardware
to test the changes you are making to the driver which makes this
even more questionable for net-2.6
I'll toss this into net-next-2.6 and let's let it cook there for
a while at least.
If you want to pick out a small bug fix or two from this series
for net-2.6, please feel free to resubmit them specifically for
net-2.6 inclusion.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: fix kmemcheck annotations
From: David Miller @ 2009-10-30 5:54 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <4AE97220.3000004@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 29 Oct 2009 11:44:48 +0100
> David Miller a écrit :
>>
>> We may be trading size for performance here, I wonder if
>> it's wise to move queue_mapping like that and what
>> locality change we get as a result.
>
> I agree, but could not convince me it makes a difference.
Ok, I'll apply your patch as-is to net-2.6, thanks!
^ permalink raw reply
* Re: [net-2.6 PATCH] e100: e100_phy_init() isolates selected PHY, causes 10 second boot delay
From: David Miller @ 2009-10-30 5:54 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bernhard.kaindl, bruce.w.allan
In-Reply-To: <20091029234228.5100.17917.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 29 Oct 2009 16:42:41 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> A change in how PHYs are electrically isolated caused all PHYs to be
> isolated followed by reverting that isolation for the selected PHY.
> Unfortunately, isolating the selected PHY for even a short period of
> time can result in DHCP negotiation taking more than 10 seconds on certain
> embedded configurations delaying boot time as reported by Bernhard Kaindl.
> This patch reverts the change to how PHYs are isolated yet still works
> around the issue for 82552 needing the selected PHY's BMCR register to
> be written after the unused PHYs are isolated. This code is moved below
> the setting of nic->phy ID in order to do the 82552-specific workaround.
>
> Cc: Bernhard Kaindl <bernhard.kaindl@gmx.net>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 1/2] e1000e: config PHY via software after resets
From: David Miller @ 2009-10-30 5:54 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20091029234545.5413.9667.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 29 Oct 2009 16:45:45 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> On PCH-based (82577/82578) and some ICH8-based parts (82566) there is an
> issue with the hardware automatically configuring the PHY with contents
> from the EEPROM after the PHY is reset, so do the configuration by the
> driver instead. This was already similarly done for some 82566 parts in
> e1000_phy_hw_reset_ich8lan() but needs to be done after other resets,
> so move the PHY configuration code to its own function and call after
> all PHY resets.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/2] e1000e: rework disable K1 at 1000Mbps for 82577/82578
From: David Miller @ 2009-10-30 5:54 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, bruce.w.allan
In-Reply-To: <20091029234604.5413.1698.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 29 Oct 2009 16:46:05 -0700
> From: Bruce Allan <bruce.w.allan@intel.com>
>
> This patch reworks a previous workaround (commit 7d3cabbcc) for an issue
> in hardware where noise on the interconnect between the MAC and PHY could
> be generated by a lower power mode (K1) at 1000Mbps resulting in bad
> packets. Disable K1 while at 1000 Mbps but keep it enabled for 10/100Mbps
> and when the cable is disconnected. The original version of this
> workaround was found to be incomplete.
>
> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ibmtr: possible Read buffer overflow?
From: David Miller @ 2009-10-30 5:54 UTC (permalink / raw)
To: roel.kluin; +Cc: netdev, akpm
In-Reply-To: <4AC7C19F.2080800@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Sat, 03 Oct 2009 23:26:55 +0200
> Prevent read outside array bounds.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
> Is this maybe required?
I can't see anything that protects against this, so yes it
seems to be required.
Applied to net-2.6, thanks.
^ permalink raw reply
* Re: r8169: Fix card drop incoming VLAN tagged MTU byte large jumbo frames
From: David Miller @ 2009-10-30 5:55 UTC (permalink / raw)
To: ray; +Cc: romieu, netdev
In-Reply-To: <4AE60C15.3040206@apollo.lv>
From: Raimonds Cicans <ray@apollo.lv>
Date: Mon, 26 Oct 2009 22:52:37 +0200
> r8169 card drop incoming VLAN tagged MTU byte large jumbo frames
>
> It looks to compare current and maximal packet sizes hardware use
> '<' operator, not '<='.
>
> Bug introduced by patch:
> r8169: fix crash when large packets are received
>
> Signed-off-by: Raimonds Cicans <ray@apollo.lv>
Applied, thank you.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Pekka Enberg @ 2009-10-30 5:59 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: David Miller, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linville-2XuSBdqkA4R54TAoqtyWWQ
In-Reply-To: <200910292248.42229.bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi Bart,
On Thu, Oct 29, 2009 at 11:48 PM, Bartlomiej Zolnierkiewicz
<bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> _really_ prefer to spend your time in pointless arguments, go ahead.
>
> I don't think that my technical arguments are pointless.
>
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.
I don't think your technical arguments are pointless either. However,
asking Dave to revert something over John and then arguing about it is
pointless and will likely just piss people off and make them ignore
you.
Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH against V2]NET/KS8695: add support NAPI for Rx
From: David Miller @ 2009-10-30 6:00 UTC (permalink / raw)
To: figo1802; +Cc: dsilvers, netdev, ben
In-Reply-To: <1256825088.2148.77.camel@myhost>
From: "Figo.zhang" <figo1802@gmail.com>
Date: Thu, 29 Oct 2009 22:04:48 +0800
>
> Add support NAPI Rx API for KS8695NET driver.
You're not adding NAPI support in this patch.
Instead, you're fixing up the implementation based upon feedback
you've received on this list.
Please correct your commit message and subject line and resubmit.
Thank you.
^ permalink raw reply
* Re: [PATCH] net: Fix checks on unsigned in w90p910_ether_probe()
From: David Miller @ 2009-10-30 6:06 UTC (permalink / raw)
To: roel.kluin; +Cc: netdev, akpm, mcuos.com
In-Reply-To: <4ADDFE0C.3020400@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Tue, 20 Oct 2009 20:14:36 +0200
> ether->txirq and ->rxirq are unsigned
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
platform_get_irq() returns a signed int so the intention
is more likely that catching negative value returns
was intended.
Probably the correct fix is to mark txirq and rxirq as
plain 'int'.
^ permalink raw reply
* Re: [patch]convert kaweth to use usb_reset_configuration()
From: David Miller @ 2009-10-30 6:07 UTC (permalink / raw)
To: oliver; +Cc: sarah.a.sharp, netdev
In-Reply-To: <200910291607.12382.oliver@neukum.org>
From: Oliver Neukum <oliver@neukum.org>
Date: Thu, 29 Oct 2009 16:07:12 +0100
> For USB 3.0 it is necessary that all drivers use the standard
> API to reset a configuration. This removes a home-grown
> implementation.
>
> Signed-off-by: Oliver Neukum <oliver@neukum.org>
>
> Hi David,
>
> please take this for the next merge window.
Applied to net-next-2.6, thanks Oliver.
^ permalink raw reply
* Re: [PATCH] ax25: unsigned cannot be less than 0 in ax25_ctl_ioctl()
From: David Miller @ 2009-10-30 6:06 UTC (permalink / raw)
To: roel.kluin; +Cc: kevind, wharms, linux-hams, netdev, jreuter, akpm
In-Reply-To: <4AD5EDA6.4040709@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Wed, 14 Oct 2009 17:26:30 +0200
> struct ax25_ctl_struct member `arg' is unsigned and cannot be less
> than 0.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] net: Fix checks on unsigned in w90p910_ether_probe()
From: Wan ZongShun @ 2009-10-30 6:18 UTC (permalink / raw)
To: David Miller, roel.kluin; +Cc: netdev, akpm, linux-arm-kernel
In-Reply-To: <20091029.230624.125832796.davem@davemloft.net>
Dear sirs,
Okay, it is right, thanks all for your help.
I will re-fix it later.
2009/10/30, David Miller <davem@davemloft.net>:
> From: Roel Kluin <roel.kluin@gmail.com>
> Date: Tue, 20 Oct 2009 20:14:36 +0200
>
> > ether->txirq and ->rxirq are unsigned
> >
> > Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
>
> platform_get_irq() returns a signed int so the intention
> is more likely that catching negative value returns
> was intended.
>
> Probably the correct fix is to mark txirq and rxirq as
> plain 'int'.
>
--
Wan z.s
^ permalink raw reply
* Re: [PATCH] udev: create empty regular files to represent net interfaces
From: Marco d'Itri @ 2009-10-30 6:22 UTC (permalink / raw)
To: dann frazier
Cc: Greg KH, Matt Domsch, Kay Sievers, linux-hotplug, Narendra_K,
netdev, Jordan_Hargrave, Charles_Rose, Ben Hutchings
In-Reply-To: <20091030053824.GA25540@ldl.fc.hp.com>
[-- Attachment #1: Type: text/plain, Size: 654 bytes --]
On Oct 30, dann frazier <dannf@hp.com> wrote:
> On Fri, Oct 30, 2009 at 04:30:29AM +0100, Marco d'Itri wrote:
> > On Oct 29, dann frazier <dannf@dannf.org> wrote:
> >
> > > That would make a lot of users much happier (myself included), but it
> > > does restrict us into one view. At different times, admins think of
> > > their NICs by different properties. I may want to do IP assignment by
> > [Citation needed]
> Is "I" not clear, or do you just not believe I admin servers?
I was referring to "At different times, admins think of their NICs by
different properties", which I am not sure is a valid generalization.
--
ciao,
Marco
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox