Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-12-08 10:23 PM, Hayes Wang wrote: > Mark Lord <ml...@pobox.com> > > 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

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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,

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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 restarted

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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.

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

to those buffers after initial allocation, and only the driver and USB host controller ever have pointers to the buffers. -- Mark Lord

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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&

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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 c

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

On 16-11-24 12:11 PM, David Miller wrote: > From: Mark Lord <ml...@pobox.com> > 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. >

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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 result

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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"

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

>} 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

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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 RTL8152

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

ngths/ranges before accessing the actual buffer, and everything should begin working reliably. Cheers -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

(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

Re: [PATCH net 1/2] r8152: fix the sw rx checksum is unavailable

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) from

Re: [PATCH net 2/2] r8152: rx descriptor check

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, r

Re: [PATCH net 2/2] r8152: rx descriptor check

cess to the test system only for 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

Re: [PATCH net 2/2] r8152: rx descriptor check

ularly attempts to process 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

Re: [PATCH net] r8152: Fix broken RX checksums.

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 >

Re: [PATCH net] r8152: Fix broken RX checksums.

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

Re: [PATCH net] r8152: Fix broken RX checksums.

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

Re: [PATCH net] r8152: Fix broken RX checksums.

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_AGG

Re: [PATCH net] r8152: Fix broken RX checksums.

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

Re: [PATCH net] r8152: Fix broken RX checksums.

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

Re: [PATCH net] r8152: Fix broken RX checksums.

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 Remedie

Re: [PATCH net] r8152: Fix broken RX checksums.

On 16-10-30 08:57 PM, David Miller wrote: > From: Mark Lord <ml...@pobox.com> > 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. Sym

[PATCH net] r8152: Fix broken RX checksums.

-porting to -stable >= 3.16.xx. Signed-off-by: Mark Lord <ml...@pobox.com> --- 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;

Re: [PATCH] drivers/net/usb/r8152 fix broken rx checksums

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

[PATCH] drivers/net/usb/r8152 fix broken rx checksums

.xx. Patch attached (to deal with buggy mailer) and also below for review. Signed-off-by: Mark Lord <ml...@pobox.com> --- 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

Re: Reproducible data corruption with sendfile+vsftp - splice regression?

Francois Romieu wrote: Holger Hoffstaette [EMAIL PROTECTED] : [...] Maybe turning off sendfile or NAPI just lead to random success - so far it really looks like tso on the r8169 is the common cause. TSO on the r8169 is the magic switch but the regression makes imvho more sense from a VM pov:

Re: namespace support requires network modules to say GPL

Mark Lord wrote: Now that we have network namespace support merged it is time to revisit the sysfs support so we can remove the dependency on !SYSFS. ... Now that the namespace updates are part of 2.6.24, there is a major inconsistency in network EXPORT_SYMBOLs. It used to be that an external

namespace support requires network modules to say GPL

Now that we have network namespace support merged it is time to revisit the sysfs support so we can remove the dependency on !SYSFS. ... Now that the namespace updates are part of 2.6.24, there is a major inconsistency in network EXPORT_SYMBOLs. It used to be that an external network module

Re: namespace support requires network modules to say GPL

Eric W. Biederman wrote: Stephen Hemminger [EMAIL PROTECTED] writes: Actually, the whole mess would go away if the api for dev_get_by_ hadn't been changed in the namespace transition. IMHO the interface to dev_get_by_name() should not have added a namespace parameter, of the callers in the

Re: namespace support requires network modules to say GPL

Arjan van de Ven wrote: On Sat, 01 Dec 2007 15:21:12 -0500 Mark Lord [EMAIL PROTECTED] wrote: Eric W. Biederman wrote: Stephen Hemminger [EMAIL PROTECTED] writes: Sure. We keep the updated dev_get_by_ that takes a network namespace parameter. .. And what should code be passing in when

Re: namespace support requires network modules to say GPL

Arjan van de Ven wrote: On Sat, 01 Dec 2007 15:21:12 -0500 Mark Lord [EMAIL PROTECTED] wrote: Eric W. Biederman wrote: Stephen Hemminger [EMAIL PROTECTED] writes: Sure. We keep the updated dev_get_by_ that takes a network namespace parameter. .. And what should code be passing in when

Re: namespace support requires network modules to say GPL

Eric W. Biederman wrote: Mark Lord [EMAIL PROTECTED] writes: Arjan van de Ven wrote: On Sat, 01 Dec 2007 15:21:12 -0500 Mark Lord [EMAIL PROTECTED] wrote: Eric W. Biederman wrote: Stephen Hemminger [EMAIL PROTECTED] writes: Sure. We keep the updated dev_get_by_ that takes a network

Re: namespace support requires network modules to say GPL

Stephen Hemminger wrote: On Sat, 1 Dec 2007 11:17:36 -0800 Stephen Hemminger [EMAIL PROTECTED] wrote: Then init_net needs to be not GPL limited. Sorry, we need to allow non GPL network drivers. There is a fine line between keeping the binary seething masses from accessing random kernel

Re: [BUG] New Kernel Bugs

Andrew Morton wrote: On Mon, 12 Nov 2007 22:42:32 -0800 Natalie Protasevich [EMAIL PROTECTED] wrote: .. with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't boot (ARM, Timer) http://bugzilla.kernel.org/show_bug.cgi?id=9229 Kernel: 2.6.23 No response from developers ..

Re: [BUG] New Kernel Bugs

Ingo Molnar wrote: .. This is all QA-101 that _cannot be argued against on a rational basis_, it's just that these sorts of things have been largely ignored for years, in favor of the all-too-easy open source means many eyeballs and that is our QA answer, which is a _good_ answer but by far

Re: [BUG] New Kernel Bugs

Mark Lord wrote: Andrew Morton wrote: On Mon, 12 Nov 2007 22:42:32 -0800 Natalie Protasevich [EMAIL PROTECTED] wrote: .. .. Suspend to RAM resume hangs on a tickless (NO_HZ) kernel http://bugzilla.kernel.org/show_bug.cgi?id=9275 Kernel: 2.6.23 This is HP notebook nc6320 T2400 945GM

Re: [BUG] New Kernel Bugs

Thomas Gleixner wrote: On Tue, 13 Nov 2007, Mark Lord wrote: .. I *still* get very slow resume-from-RAM quite often here (new in 2.6.23 kernel, wasn't there in early 2.6.23-rc*). .. Something eventually times out after a minute or so and it comes back. Cannot make it happen reliably, unless

Re: [BUG] New Kernel Bugs

Ingo Molnar wrote: for example git-bisect was godsent. I remember that years ago bisection of a bug was a very laborous task so that it was only used as a final, last-ditch approach for really nasty bugs. Today we can autonomouly bisect build bugs via a simple shell command around git-bisect

Re: [BUG] New Kernel Bugs

Thomas Gleixner wrote: On Tue, 13 Nov 2007, Mark Lord wrote: Andrew Morton wrote: On Mon, 12 Nov 2007 22:42:32 -0800 Natalie Protasevich [EMAIL PROTECTED] wrote: .. with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23 doesn't boot (ARM, Timer) http

Re: [BUG] New Kernel Bugs

Adrian Bunk wrote: On Tue, Nov 13, 2007 at 12:50:08PM -0500, Mark Lord wrote: Ingo Molnar wrote: for example git-bisect was godsent. I remember that years ago bisection of a bug was a very laborous task so that it was only used as a final, last-ditch approach for really nasty bugs. Today we

Re: [BUG] New Kernel Bugs

Matthew Wilcox wrote: On Tue, Nov 13, 2007 at 12:50:08PM -0500, Mark Lord wrote: It's a 540MByte download over a slow link for everyone else. Where do you get this number from? $ du -sh .git/objects/pack/ 249M.git/objects/pack/ $ du -sh .git/objects/ 253M.git/objects/ ie about half

Re: [BUG] New Kernel Bugs

Adrian Bunk wrote: ... I did bisecting myself, and I know that it costs time and work. But the first point is the above one that it makes otherwise nearly undebuggable problems debuggable and fixable. .. Definitely useful, no question. But the problem is now that kernel devs are addicted to

Re: [BUG] New Kernel Bugs

Matthew Wilcox wrote: On Tue, Nov 13, 2007 at 01:43:53PM -0500, Mark Lord wrote: mkdir t cd t git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git (wait half an hour) /usr/bin/du -s linux-2.6 522732 linux-2.6 You're assuming that everything in linux-2.6

Re: [BUG] New Kernel Bugs

Adrian Bunk wrote: On Tue, Nov 13, 2007 at 01:47:10PM -0500, Mark Lord wrote: Adrian Bunk wrote: ... I did bisecting myself, and I know that it costs time and work. But the first point is the above one that it makes otherwise nearly undebuggable problems debuggable and fixable

Re: [BUG] New Kernel Bugs

Adrian Bunk wrote: On Tue, Nov 13, 2007 at 01:47:10PM -0500, Mark Lord wrote: Adrian Bunk wrote: .. Another point is that it shifts the work from the few experienced developers to the many users. Users (and voluntary testers) we have many, but developer time for debugging bug reports

Re: [BUG] New Kernel Bugs

Adrian Bunk wrote: On Tue, Nov 13, 2007 at 02:26:05PM -0500, Mark Lord wrote: .. If you've been making significant updates to a driver/subsystem, and people are reporting that it is now broken for them, What are significant updates? Sometimes one person makes one small patch and this patch

Re: [BUG] New Kernel Bugs

Russell King wrote: On Tue, Nov 13, 2007 at 09:08:32AM -0500, Mark Lord wrote: Ingo Molnar wrote: .. This is all QA-101 that _cannot be argued against on a rational basis_, it's just that these sorts of things have been largely ignored for years, in favor of the all-too-easy open source means

Re: [BUG] New Kernel Bugs

Jörn Engel wrote: On Tue, 13 November 2007 15:18:07 -0500, Mark Lord wrote: I just find it weird that something can be known broken for several -rc* kernels before I happen to install it, discover it's broken on my own machine, and then I track it down, fix it, and submit the patch, generally

Re: [BUG] New Kernel Bugs

Thomas Gleixner wrote: On Tue, 13 Nov 2007, Mark Lord wrote: Thomas Gleixner wrote: On Tue, 13 Nov 2007, Mark Lord wrote: Andrew Morton wrote: On Mon, 12 Nov 2007 22:42:32 -0800 Natalie Protasevich [EMAIL PROTECTED] wrote: .. with CONFIG_NO_HZ and/or CONFIG_HPET_TIMER set kernel 2.6.23

Re: [1/6] 2.6.21-rc2: known regressions

Adrian Bunk wrote: Subject: Bluetooth RFComm locks up the machine (device_move() related) References : http://lkml.org/lkml/2007/3/4/64 Submitter : Mark Lord [EMAIL PROTECTED] Caused-By : Marcel Holtmann [EMAIL PROTECTED] commit c1a3313698895d8ad4760f98642007bf236af2e8

Wireless router with 2 MACs: okay with mswin, not with Linux ?

people. Surely there's a flag or something to have the kernel cope with this? -- Mark Lord Real-Time Remedies Inc. [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org

Re: 2.6.17: networking bug??

Mark Lord wrote: .. The differences I see are widely varying window sizes. What would cause this? This is from (working) 2.6.16.18: IP silvy.localnet.56224 216-145-246-23.rev.dls.net.www: . ack 1 win 1460 nop,nop,timestamp 730448 134760199 IP silvy.localnet.56224 216-145-246-23

Re: 2.6.17: networking bug??

Mmm. I notice that 2.6.17 has a new sysctl related to this stuff: /proc/sys/net/ipv4/tcp_workaround_signed_windows It makes no difference whatsoever for me here when varied while /proc/sys/net/ipv4/tcp_window_scaling==1. The site www.everymac.com is still not browseable until setting

Re: 2.6.17: networking bug??

.. The site www.everymac.com is still not browseable until setting /proc/sys/net/ipv4/tcp_window_scaling===0. There's one other difference I see in the tcpdump traces. The first packets from each trace below show different values for wscale. The old (working) kernels use wscale 2, whereas

Re: 2.6.17: networking bug??

Mark Lord wrote: .. The site www.everymac.com is still not browseable until setting /proc/sys/net/ipv4/tcp_window_scaling===0. There's one other difference I see in the tcpdump traces. The first packets from each trace below show different values for wscale. The old (working) kernels use

Re: 2.6.17: networking bug??

Linus Torvalds wrote: On Tue, 13 Jun 2006, John Heffner wrote: The best thing you can do is try to find this broken box and inform its owner that it needs to be fixed. (If you can find out what it is, I'd be interested to know.) In the meantime, disabling window scaling will work around the

Re: 2.6.17: networking bug??

Mark Lord wrote: Linus Torvalds wrote: It's not like there aren't broken boxes out there, and it might be better to make the default buffer sizes just be low enough that window scaling simply isn't an issue. I suspect that the people who really want/need window scaling know about

Re: 2.6.17: networking bug??

David Miller wrote: .. First, you are getting window scaling by default with the older kernel too. It's just a smaller window scale, using a shift value of say 1 or 2. What these broken middle boxes do is ignore the window scale entirely. So they don't apply a window scale to the advertised

Re: Using netconsole for debugging suspend/resume

Andi Kleen wrote: On Friday 09 June 2006 17:24, Mark Lord wrote: Andi Kleen wrote: If your laptop has firewire you can also use firescope. (ftp://ftp.suse.com/pub/people/ak/firescope/) .. FW keeps running as long as nobody resets the ieee1394 chip. This looks interesting. But how does one

Re: Using netconsole for debugging suspend/resume

Andi Kleen wrote: If your laptop has firewire you can also use firescope. (ftp://ftp.suse.com/pub/people/ak/firescope/) .. FW keeps running as long as nobody resets the ieee1394 chip. This looks interesting. But how does one set it up for use on the *other* end of that firewire cable?

Re: [RFC: 2.6 patch] remove drivers/net/tulip/xircom_tulip_cb.c

Adrian Bunk wrote: This patch removes the obsolete drivers/net/tulip/xircom_tulip_cb.c driver. Is there any reason why it should be kept? Yes. It is the only driver that works without lockups on Xircom Cardbus cards. Or so has been the case any time I've tried the alternatives. Is there