ly-functional device speed is High Speed (480Mbps)
bU1DevExitLat 10 micro seconds
bU2DevExitLat2047 micro seconds
Device Status: 0x000c
(Bus Powered)
U1 Enabled
U2 Enabled
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
to system's
> USB host controller.
Thank-you, Mario.
So.. why are we enabling the r8153 (USB-ethernet) workaround on this WD15 dock?
The discussion back in 2017 was that only the TB15/TB16 were affected by
the XHCI overruns it produces?
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
On 2019-01-07 1:46 a.m., Kai Heng Feng wrote:
>
> Do you happen to use a Dell system? We can do some test here.
Yes. It is a Dell XPS 13 9360 i7-8550U notebook,
with the Dell WD15 USB-C dock.
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
On 2019-01-06 11:09 p.m., Kai Heng Feng wrote:
>
>
>> On Jan 7, 2019, at 05:16, Mark Lord wrote:
>>
>> On 2019-01-06 4:13 p.m., Mark Lord wrote:
>>> On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14
>>> PM, Mark Lord
>
On 2019-01-06 4:13 p.m., Mark Lord wrote:
> On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14 PM,
> Mark Lord
> wrote:
> ..
>>> There is even now a special hack in the upstream r8152.c to attempt to
>>> detect
>>> a Dell TB16
On 2019-01-06 2:14 p.m., Kai Heng Feng wrote:>> On Jan 5, 2019, at 10:14 PM,
Mark Lord
wrote:
..
>> There is even now a special hack in the upstream r8152.c to attempt to detect
>> a Dell TB16 dock and disable RX Aggregation in the driver to prevent such
>> issues.
&g
On 2019-01-05 9:14 a.m., Mark Lord wrote:
> A couple of years back, I reported data corruption resulting from
> a change in kernel 3.16 which enabled hardware checksums in the r8152 driver.
> This was happening on an embedded system that was using a r8152 USB dongle.
>
> At the ti
.0.
>From this I conclude that the workaround is not 100% complete yet.
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
524280U
+#define COALESCE_SUPER 8500U
+#define COALESCE_HIGH 25000U
+#define COALESCE_SLOW 52428U
The RTL_VER_02 chip that I was using does not support interrupt coalescing
in the driver [see the rtl8152_set_coalesce() function]. So that workaround
would not help here.
On 16-12-08 10:23 PM, Hayes Wang wrote:
> Mark Lord
>
> I find an issue about autosuspend, and it may result in the same
> problem with you. I don't sure if this is helpful to you, because
> it only occurs when enabling the autosuspend.
Thanks. I am using ASIX adapters
On 16-11-25 09:22 AM, Greg KH wrote:
> On Fri, Nov 25, 2016 at 07:41:42AM -0500, Mark Lord wrote:
>> On 16-11-25 07:34 AM, Mark Lord wrote:
>>> On 16-11-25 04:53 AM, Greg KH wrote:
>>>> Note, there are "cheap" USB monitors that can be quite handy an
On 16-11-25 04:52 AM, Hayes Wang wrote:
..
> What is the value of /sys/bus/usb/devices/.../power/control ?
That entry does not exist -- power control is completely
disabled on this board.
Good try, though -- USB power control still causes me trouble
on PCs with mice and remote controls. But not
On 16-11-25 04:53 AM, Greg KH wrote:
> On Thu, Nov 24, 2016 at 10:49:33PM -0500, Mark Lord wrote:
>> There is no possibility for them to be used for anything other than
>> USB receive buffers, for this driver only. Nothing in the driver
>> or kernel ever writes to those
On 16-11-25 04:53 AM, Greg KH wrote:
> Note, there are "cheap" USB monitors that can be quite handy and that work on
> Linux:
> http://www.totalphase.com/products/beagle-usb12/
USD$455/each in quantity, vs. USD$8 for the USB ethernet dongle.
On 16-11-25 07:34 AM, Mark Lord wrote:
> On 16-11-25 04:53 AM, Greg KH wrote:
>> Note, there are "cheap" USB monitors that can be quite handy and that work
>> on Linux:
>> http://www.totalphase.com/products/beagle-usb12/
>
> USD$455/each in quantity,
On 16-11-25 01:51 AM, Hayes Wang wrote:
>
> Forgive me. I provide wrong information. This is about RTL8153, not RTL8152.
No problem. Thanks for trying though.
On 16-11-25 01:11 AM, Hayes Wang wrote:
> Mark Lord [mailto:ml...@pobox.com]
..
>> If that "return 0" statement is ever executed, doesn't it result
>> in the loss/leak of a buffer?
>
> They would be found back by calling rtl_start_rx(), when the rx
> is rest
rites to those buffers after initial allocation,
and only the driver and USB host controller ever have pointers to the buffers.
--
Mark Lord
On 16-11-24 02:00 PM, Greg KH wrote:
> On Thu, Nov 24, 2016 at 01:34:08PM -0500, Mark Lord wrote:
>> One thought: bulk data streams are byte streams, not packets.
>> Scheduling on the USB bus can break up larger transfers across
>> multiple in-kernel buffers. A "real&
On 16-11-24 01:42 PM, Greg KH wrote:
>
> Have you tried using usbmon?
This system is running rootfs over NFS, so usbmon
isn't realistically going to be usable in that scenario
without a lot of reconfiguration of the setup (which in itself
might obscure the original problem).
There is a hardware U
On 16-11-24 01:34 PM, Mark Lord wrote:
>From tracing through the powerpc arch code, this is the buffer that
> is being directly DMA'd into. And the USB layer does an invalidate_dcache
> on that entire buffer before initiating the DMA (confirmed via printk).
Slight co
On 16-11-24 12:11 PM, David Miller wrote:
> From: Mark Lord
> Date: Thu, 24 Nov 2016 11:43:53 -0500
>
>> So even if this were a platform memory coherency issue, one should
>> still never see ASCII data at the beginning of an rx buffer.
>
> I'm not so convinced,
On 16-11-24 11:43 AM, Mark Lord wrote:
..
But how does this ASCII data end up at offset zero of the rx buffer??
Not possible -- this isn't even stale data, because only an rx_desc could
be at that offset in that buffer.
Answering my own question here, I suspect it ends up there as a resu
On 16-11-24 11:21 AM, David Miller wrote:
From: Hayes Wang
Date: Thu, 24 Nov 2016 13:26:55 +
I don't think the garbage results from our driver or device.
This is my impression with what has been presented so far as well.
It's not garbage.
The latest run with the debug code I posted her
On 16-11-24 08:26 AM, Hayes Wang wrote:
..
Besides, it doesn't seem to occur for all platforms. I have
tested the iperf more than 26 hours, and it still works fine.
I think I would get the same result on x86 or x86_64 platform.
..
x86 has near fully-coherent memory, so it is the "easy" platform
On 16-11-23 02:29 PM, Mark Lord wrote:
On 16-11-23 10:12 AM, Hayes Wang wrote:
Mark Lord [ml...@pobox.com]
[...]
What does this code do:
static void r8153_set_rx_early_size(struct r8152 *tp)
{
u32 mtu = tp->netdev->mtu;
u32 ocp_data = (agg_buf_sz - mtu - VLAN_ET
On 16-11-23 10:12 AM, Hayes Wang wrote:
Mark Lord [ml...@pobox.com]
[...]
What does this code do:
static void r8153_set_rx_early_size(struct r8152 *tp)
{
u32 mtu = tp->netdev->mtu;
u32 ocp_data = (agg_buf_sz - mtu - VLAN_ETH_HLEN - VLAN_HLEN) / 4;
ocp_write_w
;}
How is ocp_data used by the hardware?
Shouldn't the calculation also include sizeof(rx_desc) in there somewhere?
Thanks
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
On 16-11-18 07:03 AM, Mark Lord wrote:
On 16-11-18 02:57 AM, Hayes Wang wrote:
..
Besides, the maximum data length which the RTL8152 would send to
the host is 16KB. That is, if the agg_buf_sz is 16KB, the host
wouldn't split it. However, you still see problems for it.
How does the RT
st lengths/ranges before accessing the actual buffer,
and everything should begin working reliably.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
(resending.. not sure if the original had mailer errors)
On 16-11-16 10:36 PM, Hayes Wang wrote:
> [...]
>> Fix the hw rx checksum is always enabled, and the user couldn't switch
>> it to sw rx checksum.
>>
>> Note that the RTL_VER_01 only supports sw rx checksum only. Besides,
>> the hw rx check
On 16-11-17 09:14 AM, Mark Lord wrote:
..
Using coherent buffers (non-cacheable, allocated with usb_alloc_coherent),
Note that the same behaviour also happens with the original kmalloc'd buffers.
I can get it to fail extremely regularly by simply reducing the buffer size
(agg_buf_sz)
On 16-11-13 03:34 PM, Mark Lord wrote:
>
> The system I use it with is a 32-bit ppc476, with non-coherent RAM,
> and using 16KB page sizes.
>
> The dongle instantly becomes a lot more reliable when r8152.c is updated
> to use usb_alloc_coherent() for URB buffers, rather than k
or a day or two a week,
and it takes a few hours to do a good test as to whether something helps or not.
I'll continue to poke at it as time and New Ideas permit.
New Ideas welcome!
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
rocess huge unreal packet sizes here.
I've had to patch it to reject "packets" larger than the configured MRU.
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
On 16-11-09 08:09 AM, Hayes Wang wrote:
> Mark Lord [mailto:ml...@pobox.com]
..
>> The MTU/MRU on this link is the standard 1500 bytes, so a pkt_len of 2045
>> isn't
>> valid here.
>> And the rx_desc values look an awful lot like the rx_data values that follow
On 16-11-04 09:50 AM, Mark Lord wrote:
> Yeah, the device or driver is definitely getting confused with rx_desc
> structures.
> I added code to check for unlikely rx_desc values, and it found this for
> starters:
>
> rx_desc: 00480801 00480401 00480001 0048fc00 0048f800 004
Yeah, the device or driver is definitely getting confused with rx_desc
structures.
I added code to check for unlikely rx_desc values, and it found this for
starters:
rx_desc: 00480801 00480401 00480001 0048fc00 0048f800 0048f400 pkt_len=2045
rx_data: 00 f0 48 00 00 ec 48 00 00 e8 48 00 00 e4 48
On 16-11-02 02:29 PM, Mark Lord wrote:
I have poked at it some more, and thus far it appears that it is
only necessary to disable TCP rx checksums. The system doesn't crash
when only IP/UDP checksums are enabled, but does when TCP checksums are on.
This happens regardless of whether RX_A
On 16-11-03 04:56 AM, Hayes Wang wrote:
> Mark Lord [mailto:ml...@pobox.com]
>> Sent: Thursday, November 03, 2016 2:30 AM
>> To: Hayes Wang; David Miller
> [...]
>> I have poked at it some more, and thus far it appears that it is
>> only necessary to disable TCP rx
On 16-10-31 04:14 AM, Hayes Wang wrote:
The r8152 driver has been broken since (approx) 3.16.xx
when support was added for hardware RX checksums
on newer chip versions. Symptoms include random
segfaults and silent data corruption over NFS.
The hardware checksum logig does not work on the VER_02
g at the wrong bits.
Either way, this results in data corruption and until otherwise fixed,
it is safest to just not enable RX checksums.
If it happens on a slow embedded CPU, then it can also happen on a heavily
loaded Intel/AMD CPU -- just a lot less frequently.
Cheers
--
Mark Lord
Real-Time Re
On 16-10-30 08:57 PM, David Miller wrote:
> From: Mark Lord
> Date: Sun, 30 Oct 2016 19:28:27 -0400
>
>> The r8152 driver has been broken since (approx) 3.16.xx
>> when support was added for hardware RX checksums
>> on newer chip versions. Symptoms include random
&
-porting to -stable >= 3.16.xx.
Signed-off-by: Mark Lord
--- old/drivers/net/usb/r8152.c 2016-09-30 04:20:43.0 -0400
+++ linux/drivers/net/usb/r8152.c 2016-10-26 14:15:44.932517676 -0400
@@ -1645,7 +1645,7 @@
u8 checksum = CHECKSUM_NONE;
u32 opts2, opts3;
-
On 16-10-26 06:36 PM, Mark Lord wrote:
The r8152 driver has been broken since (approx) 3.6.16,
Correction: broken since 3.16.xx.
when support was added for hardware rx checksum on newer chip versions.
Symptoms include random segfaults and silent data corruption over NFS.
This does not work
.xx.
Patch attached (to deal with buggy mailer) and also below for review.
Signed-off-by: Mark Lord
--- old/drivers/net/usb/r8152.c 2016-09-30 04:20:43.0 -0400
+++ linux/drivers/net/usb/r8152.c 2016-10-26 14:15:44.932517676 -0400
@@ -1645,7 +1645,7 @@
u8 checksum = CHECKSUM_N
On 15-10-27 01:49 AM, vinayak.k...@gmail.com wrote:
From: Vinayak Kale
This patch is needed to make NCQ commands with FPDMA protocol value
(eg READ/WRITE FPDMA) work over SCSI Generic (SG) interface.
..
+ /* For NCQ commands with FPDMA protocol, copy the tag value */
+ if (tf->pro
On 15-08-01 09:45 PM, Robert Hancock wrote:
On Sat, Aug 1, 2015 at 2:09 PM, Pali Rohár wrote:
On Thursday 25 December 2014 07:22:13 Robert Hancock wrote:
On Tue, Dec 23, 2014 at 1:51 PM, Pali Rohár
wrote:
Hello,
I have nvidia nforce4 motherboard with nvidia sata controller:
..
It looks li
return high mode bits"
>
> This reverts the part of commit 6e14b46b91fee8a049b0940333ce13a820beaaa5
> that changes NFSv2 behavior.
>
> Mark Lord found that it broke nfs-root for Linux clients, because it
> broke NFSv2.
>
> In fact, from
On 14-04-09 11:52 AM, Bjorn Helgaas wrote:
> On Wed, Apr 9, 2014 at 8:18 AM, Mark Lord wrote:
>> On 14-04-09 10:12 AM, Mark Lord wrote:
>>> On 14-04-09 09:08 AM, Mark Lord wrote:
>>>> On 14-04-08 10:51 PM, Benjamin Herrenschmidt wrote:
>>>>> On Tu
On 14-04-09 10:12 AM, Mark Lord wrote:
> On 14-04-09 09:08 AM, Mark Lord wrote:
>> On 14-04-08 10:51 PM, Benjamin Herrenschmidt wrote:
>>> On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote:
>>>>> I assume you're talking about the one added by cf3e1f
On 14-04-09 09:08 AM, Mark Lord wrote:
> On 14-04-08 10:51 PM, Benjamin Herrenschmidt wrote:
>> On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote:
>>>> I assume you're talking about the one added by cf3e1feba7f9 ("PCI:
>>>> Workaround missing pci_s
On 14-04-08 10:51 PM, Benjamin Herrenschmidt wrote:
> On Tue, 2014-04-08 at 17:18 -0400, Mark Lord wrote:
>>> I assume you're talking about the one added by cf3e1feba7f9 ("PCI:
>>> Workaround missing pci_set_master in pci drivers"), but as far as I
>>>
On 14-04-08 02:27 PM, Bjorn Helgaas wrote:
> [+cc Ben, linux-pci]
>
> On Tue, Apr 8, 2014 at 10:34 AM, Mark Lord wrote:
>> I am working a couple of drivers for chips that perform extensive
>> bus-mastering ops.
>> These including full SRIOV support, and allow ass
able_device(), courtesy of the embedded call
to pci_set_master().
This isn't good, and these may not be the only devices affected in this way.
Can we perhaps not do that, or provide some other way to return control of
bus-mastering
to the device driver ?
--
ml...@pobox.com
Mark Lord
--
To u
On 14-04-03 05:28 PM, J. Bruce Fields wrote:
> On Thu, Apr 03, 2014 at 04:48:11PM -0400, Mark Lord wrote:
>> On 14-04-03 03:30 PM, J. Bruce Fields wrote:
>>> On Thu, Apr 03, 2014 at 01:51:06PM -0400, Mark Lord wrote:
>>>> On 14-04-03 01:16 PM, J. Bruce Fields wrote:
On 14-04-03 03:30 PM, J. Bruce Fields wrote:
> On Thu, Apr 03, 2014 at 01:51:06PM -0400, Mark Lord wrote:
>> On 14-04-03 01:16 PM, J. Bruce Fields wrote:
>>> On Thu, Apr 03, 2014 at 12:33:55PM -0400, Mark Lord wrote:
>>>> This commit from linux-3.14 br
On 14-04-03 04:15 PM, J. Bruce Fields wrote:
> On Thu, Apr 03, 2014 at 01:51:06PM -0400, Mark Lord wrote:
>> On 14-04-03 01:16 PM, J. Bruce Fields wrote:
>>> The original behavior was in practice harmless and changing it broke
>>> something, so I think we should defini
On 14-04-03 01:16 PM, J. Bruce Fields wrote:
> On Thu, Apr 03, 2014 at 12:33:55PM -0400, Mark Lord wrote:
>> This commit from linux-3.14 breaks our NFS-root clients here:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6e14b46b91fee8a049b
Mark Lord wrote:
> On 14-04-03 12:33 PM, Mark Lord wrote:
>> This commit from linux-3.14 breaks our NFS-root clients here:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6e14b46b91fee8a049b0940333ce13a820beaaa5
>>
>>
>> -
On 14-04-03 12:33 PM, Mark Lord wrote:
> This commit from linux-3.14 breaks our NFS-root clients here:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6e14b46b91fee8a049b0940333ce13a820beaaa5
>
>
> - *p++ = htonl((u32) stat->mode);
> +
New install: Haswell i7-4770 CPU, Q87 chipset.
When I enable intel_iommu=on at boot, it clutters the log with this WARN_ONCE():
...
[0.313282] Freeing initrd memory: 5092K (880037af7000 - 880037ff)
[0.313603] DMAR: No ATSR found
[0.313774] IOMMU 0 0xfed9: using Queued invalidatio
/* Accept arbitrarily long scatter-gather lists */
> - hcd->self.sg_tablesize = ~0;
> + hcd->self.sg_tablesize = 31;
>
> /* support to build packet from discontinuous buffers */
> hcd->self.no_sg_constraint = 1;
>
> S
CSI command.
Is there not a block layer / scheduler tunable for max sg entries or something?
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More major
USB3
is very flakey in the most recent 3.12.* kernels, as well as the 3.13-rc* ones.
So I have gone back to running older kernels and patching them.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 13-11-19 09:15 AM, Eric Dumazet wrote:
> On Tue, 2013-11-19 at 09:02 -0500, Mark Lord wrote:
>> On 13-11-19 05:04 AM, David Laight wrote:
>>>> From: Mark Lord
>> ..
>>>> except the ax88179_178a driver still does not work in linux-3.12,
>>&g
On 13-11-19 05:04 AM, David Laight wrote:
>> From: Mark Lord
..
>> except the ax88179_178a driver still does not work in linux-3.12,
>> whereas it works fine in all earlier kernels.
>>
>> That's a regression.
>> And a simple revert (earlier in this thread)
On 13-10-25 06:01 AM, Alexander Gordeev wrote:
>
> If this problem really exists anywhere besides pSeries?
>
> I can imagine x86 hitting lack of vectors in interrupt table when
> number of CPUs exceeds hundreds, but do we have this problem now?
An awful lot of x86 hardware has a 256 (255?) vector
On 13-10-24 10:31 AM, Alexander Gordeev wrote:
> On Thu, Oct 24, 2013 at 11:51:58AM +0100, Tejun Heo wrote:
>> I haven't looked into any details but, if the above works for most use
>> cases, it looks really good to me.
>
> Well, if we reuse Michael's statistics:
>
> - 58 drivers call pci_enable
On 13-10-24 07:41 AM, Alexander Gordeev wrote:
> On Thu, Oct 24, 2013 at 11:57:40AM +0100, David Laight wrote:
>> The one case it doesn't work is where the driver either
>> wants the full number or the minimum number - but not
>> a value in between.
>>
>> Might be worth adding an extra parameter so
On 13-10-11 04:41 AM, Alexander Gordeev wrote:
> On Thu, Oct 10, 2013 at 07:17:18PM -0400, Mark Lord wrote:
>> Just to help us all understand "the loop" issue..
>>
>> Here's an example of driver code which uses the existing MSI-X interfaces,
>> for a dev
Just to help us all understand "the loop" issue..
Here's an example of driver code which uses the existing MSI-X interfaces,
for a device which can work with either 16, 8, 4, 2, or 1 MSI-X interrupt.
This is from a new driver I'm working on right now:
static int xx_alloc_msix_irqs (struct xx_dev
On 13-10-02 06:29 AM, Alexander Gordeev wrote:
..
> This update converts pci_enable_msix() and pci_enable_msi_block()
> interfaces to canonical kernel functions and makes them return a
> error code in case of failure or 0 in case of success.
Rather than silently break dozens of drivers in mysterio
On 13-09-26 09:03 AM, Alexander Gordeev wrote:
> On Thu, Sep 26, 2013 at 08:32:53AM -0400, Mark Lord wrote:
>> On 13-09-18 05:48 AM, Alexander Gordeev wrote:
>>> The last pattern makes most of sense to me and could be updated with a more
>>> clear sequenc
On 13-09-18 05:48 AM, Alexander Gordeev wrote:
>
> The last pattern makes most of sense to me and could be updated with a more
> clear sequence - a call to (bit modified) pci_msix_table_size() followed
> by a call to pci_enable_msix(). I think this pattern can effectively
> supersede the currently
On 13-06-29 02:47 PM, Henrique de Moraes Holschuh wrote:
> You know, either the "long" or the "offline" SMART test routines do exactly
> that on any spinning rust device with a firmware that is not utterly broken.
>
> The HDD's firmware will rewrite, and even reallocate any "weak" sectors
> found
to do I/O in PAGE_SIZE multiples.
And the SCSI stack in Linux has rather atrocious error handling.
It lumps multiple requests together, and can fail the entire lot even
if only a single sector is bad.
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the l
On 13-06-23 05:51 PM, Pavel Machek wrote:
> On Sun 2013-06-23 17:27:52, Mark Lord wrote:
>
>> For all existing drives out there, that's a 512 byte unit.
>
> I guessed so. (It would be good to actually document it, as well as
> documenting exactly why it is dangerous.
look at the error
logs to see what sector the drive is choking on.
Or just low-level format it all with "hdparm --security-erase".
Cheers
--
Mark Lord
Real-Time Remedies Inc.
ml...@pobox.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&quo
On 13-01-17 08:53 AM, J. Bruce Fields wrote:
> On Thu, Jan 17, 2013 at 08:11:52AM -0500, Mark Lord wrote:
>> On 13-01-14 11:17 AM, Mark Lord wrote:
>>>
>>> Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
>>>
>>> /*
>
On 13-02-21 09:26 PM, Paul Gortmaker wrote:
> On Thu, Feb 21, 2013 at 9:37 AM, Mark Lord wrote:
>> On 13-02-20 10:05 PM, Linus Torvalds wrote:
>>> On Wed, Feb 20, 2013 at 2:09 PM, David Miller wrote:
..
>>> Nooo You killed the 3c501 and 3c503 drivers! Snif.
>
On 13-02-20 10:05 PM, Linus Torvalds wrote:
> On Wed, Feb 20, 2013 at 2:09 PM, David Miller wrote:
>>
>> 15) Orphan and delete a bunch of pre-historic networking drivers from
>> Paul Gortmaker.
>
> Nooo You killed the 3c501 and 3c503 drivers! Snif.
>
> I wonder if they still worked..
I
On 13-02-12 03:52 PM, J. Bruce Fields wrote:
> On Sun, Jan 20, 2013 at 05:51:12PM -0500, Mark Lord wrote:
>> Got it again, this time on a different system
>> running mostly the same software.
>
> Mark, Paweł, Tom, could any of you confirm whether this helps?
..
No, I cann
Got it again, this time on a different system
running mostly the same software.
This time, I noticed when it happened: on mounting another system's storage
over NFS.
I was doing a "mount" command when suddenly this happened. Linux-3.7.3.
[ 3342.841487] [ cut here ]
[ 33
On 13-01-18 12:37 AM, Stanislav Kinsbursky wrote:
>
> You have more than one NFS mount in different network namespaces, haven't you?
>
No, I don't (knowingly) use (multiple) namespaces at all.
Usually I disable them in the kernel .config,
though it appears the currently running kernel has this:
C
On 13-01-17 08:24 AM, Stanislav Kinsbursky wrote:
..
> This looks like the old issue I was trying to fix with "SUNRPC: protect
> service sockets lists during
> per-net shutdown".
> So, here is the problem as I see it: there is a transport, which is processed
> by service thread and
> it's process
On 13-01-17 08:53 AM, J. Bruce Fields wrote:
> On Thu, Jan 17, 2013 at 08:11:52AM -0500, Mark Lord wrote:
>> On 13-01-14 11:17 AM, Mark Lord wrote:
>>>
>>> Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
>>>
>>> /*
>
On 13-01-14 11:17 AM, Mark Lord wrote:
>
> Here's the code with the BUG() at net/sunrpc/svc_xprt.c line 921:
>
> /*
> * Remove a dead transport
> */
> static void svc_delete_xprt(struct svc_xprt *xprt)
> {
> struct svc_serv *serv = xprt->xpt_server;
&g
On 13-01-16 05:51 PM, Mark Lord wrote:
> On 13-01-16 12:20 AM, Stanislav Kinsbursky wrote:
>>
>> Mark, could you provide any call traces?
>
> Call traces from where/what?
> There's this one, posted earlier in the BUG report:
>
> kernel BUG at net/
On 13-01-16 12:20 AM, Stanislav Kinsbursky wrote:
>
> Mark, could you provide any call traces?
Call traces from where/what?
There's this one, posted earlier in the BUG report:
kernel BUG at net/sunrpc/svc_xprt.c:921!
Call Trace:
[] ? svc_recv+0xcc/0x338 [sunrpc]
[] ? nfs_callback_authenticate+
On 13-01-14 03:37 PM, J. Bruce Fields wrote:
> Thanks for the report.
>
> On Mon, Jan 14, 2013 at 11:17:09AM -0500, Mark Lord wrote:
>> Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server
>
> It's acting as an NFS client, right?
Client and server, with oth
Since upgrading to 3.7, and now 3.7.2, my AMD-450E based server
is getting these BUG complaints. The .config file is gzip'd/attached.
[ cut here ]
kernel BUG at net/sunrpc/svc_xprt.c:921!
invalid opcode: [#1] SMP
Modules linked in: nfsv4 xt_state xt_tcpudp xt_recent x
On 12-10-29 07:03 PM, Greg Kroah-Hartman wrote:
> On Mon, Oct 29, 2012 at 07:00:54PM -0400, Mark Lord wrote:
>> There's something else very wrong when going from 3.4.9 to 3.4.16.
>> I've done it on two machines here, one the AMD-450 server (64-bit),
>> and the othe
There's something else very wrong when going from 3.4.9 to 3.4.16.
I've done it on two machines here, one the AMD-450 server (64-bit),
and the other my main notebook (Core2duo 32-bit-PAE).
Both systems feel much more sluggish than usual with 3.4.16 running.
Reverted them both back to earlier kerne
On 12-10-29 10:22 AM, Mark Lord wrote:
> On 12-10-29 02:46 AM, Willy Tarreau wrote:
>> On Mon, Oct 29, 2012 at 12:03:55AM -0400, Mark Lord wrote:
>>> My server here runs the 3.4.xx series of "stable" kernels.
>>> Until today, it was running 3.4.9.
>>>
On 12-10-29 02:46 AM, Willy Tarreau wrote:
> On Mon, Oct 29, 2012 at 12:03:55AM -0400, Mark Lord wrote:
>> My server here runs the 3.4.xx series of "stable" kernels.
>> Until today, it was running 3.4.9.
>> Today I tried to upgrade it to 3.4.16.
>> It hang
My server here runs the 3.4.xx series of "stable" kernels.
Until today, it was running 3.4.9.
Today I tried to upgrade it to 3.4.16.
It hangs in setup.c.
I've isolated the fault down to this specific change
that was made between 3.4.9 and 3.4.16.
Reverting this change allows the system to boot/run
On 12-08-26 10:15 AM, wbrana wrote:
> On 8/26/12, Mark Lord wrote:
>> Here are a couple of real scenarios you don't seem to have thought about.
>> A 32-bit kernel on a legacy (or even new) system in 2017 will still need
>> regular kernel updates (not "long term"
On 12-08-24 12:45 PM, wbrana wrote:
> On 8/24/12, Alan Cox wrote:
>> That doesn't work for a variety of reasons x86 hardware is still
>> changing, devices are still changing. So please exit cloud cuckoo land
>> and go do something useful.
> Hardware will be discontinued if no software will support
saeed wrote:
On Mon, 25 Feb 2008, Jeff Garzik wrote:
...
Saeed: isn't this what your SOC patches already implemented for us?
As near as I can tell, sata_mv now already has support for the 60x1C0.
Saeed's stuff didn't support PCI though, and Jon Li is definitely talking
about PCI...
yes, my
1 - 100 of 763 matches
Mail list logo
