On Mon, Jun 12, 2006 at 10:03:46PM -0700, David Miller wrote:
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 13 Jun 2006 06:54:14 +0200
I guess if you use 1394 with remote DMA for other protocols (like
video etc.) there must be some way for the subsystem to map
the memory even on IOMMU
From: Christoph Hellwig [EMAIL PROTECTED]
Date: Tue, 13 Jun 2006 08:18:19 +0100
That's actually not portable to certain arm platforms, but that's
a different story.
Yes, cache issues :-/
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
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
On Monday 12 June 2006 17:38, Mark Lord wrote:
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
Andi Kleen wrote:
On Monday 12 June 2006 17:38, Mark Lord wrote:
Okay, so I'm daft. But.. *what* is it ??
We have two machines: target (being debugged), and host (anything).
Sure, the target has to have ohci1394 loaded, and firescope running.
But what about the *other* end of the
On Monday 12 June 2006 23:25, Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
On Monday 12 June 2006 17:38, Mark Lord wrote:
Okay, so I'm daft. But.. *what* is it ??
We have two machines: target (being debugged), and host (anything).
Sure, the target has to have ohci1394 loaded, and
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 13 Jun 2006 05:47:49 +0200
I've been playing with the idea of writing early1394 that just
turns the DMA controller on as early as possible similar to earlyprintk
on the target. Then it would be possible to use it for early
debugging too. But so
On Tuesday 13 June 2006 06:49, David Miller wrote:
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 13 Jun 2006 05:47:49 +0200
I've been playing with the idea of writing early1394 that just
turns the DMA controller on as early as possible similar to earlyprintk
on the target. Then it would
From: Andi Kleen [EMAIL PROTECTED]
Date: Tue, 13 Jun 2006 06:54:14 +0200
I guess if you use 1394 with remote DMA for other protocols (like
video etc.) there must be some way for the subsystem to map
the memory even on IOMMU systems. I admit I haven't dived that
deeply into the 1394 subsystem
On Friday 09 June 2006 03:56, Jeremy Fitzhardinge wrote:
Rafael J. Wysocki wrote:
Please try doing echo 8 /proc/sys/kernel/printk before suspend.
Um, why? That would increase the amount of log output, but I don't see
how it would help with netconsole preventing suspend, or not being
On Fri, Jun 09, 2006 at 07:50:25AM +0200, Andi Kleen wrote:
On Friday 09 June 2006 07:23, David Miller wrote:
From: Auke Kok [EMAIL PROTECTED]
Date: Thu, 08 Jun 2006 22:13:48 -0700
netconsole should retry. There is no timeout programmed here since that
might
lose important
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?
I've been trying to get suspend/resume working well on my new laptop.
In general, netconsole has been pretty useful for extracting oopses and
other messages, but it is of more limited help in debugging the actual
suspend/resume cycle. The problem looks like the e1000 driver won't
suspend
On Thursday 08 June 2006 19:50, Jeremy Fitzhardinge wrote:
I've been trying to get suspend/resume working well on my new laptop.
In general, netconsole has been pretty useful for extracting oopses and
other messages, but it is of more limited help in debugging the actual
suspend/resume
On Thursday 08 June 2006 19:50, Jeremy Fitzhardinge wrote:
I've been trying to get suspend/resume working well on my new laptop.
In general, netconsole has been pretty useful for extracting oopses and
other messages, but it is of more limited help in debugging the actual
suspend/resume
Matt Mackall wrote:
That's odd. Netpoll holds a reference to the device, of course, but so
does a normal up interface. So that shouldn't be the problem.
Another possibility is that outgoing packets from printks in the
driver are causing difficulty. Not sure what can be done about that.
I only
Rafael J. Wysocki wrote:
Please try doing echo 8 /proc/sys/kernel/printk before suspend.
Um, why? That would increase the amount of log output, but I don't see
how it would help with netconsole preventing suspend, or not being able
to see console messages on a blank screen after resume.
From: Auke Kok [EMAIL PROTECTED]
Date: Thu, 08 Jun 2006 22:13:48 -0700
netconsole should retry. There is no timeout programmed here since that might
lose important information, and you rather want netconsole to survive an odd
unplugged cable then to lose vital debugging information when the
Auke Kok wrote:
netconsole should retry. There is no timeout programmed here since
that might
lose important information, and you rather want netconsole to survive
an odd
unplugged cable then to lose vital debugging information when the
system is
busy for instance. (losing link will cause the
On Friday 09 June 2006 07:23, David Miller wrote:
From: Auke Kok [EMAIL PROTECTED]
Date: Thu, 08 Jun 2006 22:13:48 -0700
netconsole should retry. There is no timeout programmed here since that
might
lose important information, and you rather want netconsole to survive an odd
unplugged
20 matches
Mail list logo
