This one was in my queue ... the refcounting should really
be "while device is open", shouldn't it? (Anders reported
later that this patch didn't solve the problem.)
usblp_open and usblp_release should do the refcounts,
not usblp_probe and usblp_disconnect. And I think a
semaphore should proba
>
> On Fri, Mar 09, 2001, Grover, Andrew <[EMAIL PROTECTED]> wrote:
> > > This wouldn't work for systems with builtin hubs (not the
> > > root hub) and
> > > just doesn't seem very intuitive to me.
> > >
> > > I'm not super familiar with the steps ACPI goes through to
> > > suspend, but
> > > don'
Hmmm ... Does that happen when you "ifdown usb0" first?
Or when you use ohci? I've seen usb-uhci oops in such
cases, not uhci. I wondered if it was related to using async
unlink by preference, but one of the two shutdown paths
in "usbnet" might well have a bug.
Do you get more info if you enabl
> > The reverse mapping
> > code hast to be less than 0.1KB.
>
> If reverse mapping means bus_to_virt(), then I would suggest not to
> provide it since it is a confusing interface. OTOH, only a few drivers
> need or want to retrieve the virtual address that lead to some bus dma
Your SCSI cod
> -Original Message-
> From: Johannes Erdfelt [mailto:[EMAIL PROTECTED]]
>
> > I am not a USB expert -- how would builtin hubs complicate things?
>
> It's just like any other device, it would generate traffic.
> This is not
> the same as the root hub (which all HC's have are not a "real
On Fri, 9 Mar 2001 21:51:57 +0300,
Oleg Drokin <[EMAIL PROTECTED]> wrote:
>ksymoops 2.3.5 on i686 2.4.2-ac16. Options used
>Warning (compare_maps): mismatch on symbol __module_author , usbnet says c89338c0,
>/lib/modules/2.4.2-ac16/kernel/drivers/usb/usbnet.o says c893472c. Ignoring
>/lib/mo
On Fri, 9 Mar 2001, David Brownell wrote:
> Gérard --
>
> > Just for information to people that want to complexify the
> > pci_alloc_consistent() interface thats looks simple and elegant to me:
>
> I certainly didn't propose that! Just a layer on top of the
> pci_alloc_consistent code -- use
Gérard --
> Just for information to people that want to complexify the
> pci_alloc_consistent() interface thats looks simple and elegant to me:
I certainly didn't propose that! Just a layer on top of the
pci_alloc_consistent code -- used as a page allocator, just
like you used it.
> The obj
> Date: Fri, 09 Mar 2001 13:14:03 -0800
> From: David Brownell <[EMAIL PROTECTED]>
>[...]
> It feels to me like you're being inconsistent here, objecting
> to a library API for some functionality (mapping) yet not for
> any of the other functionality (alignment, small size, poisoning
> and so on)
> I wonder if it may be feasible to allocate a bunch of contiguous
> pages. Then, whenever the hardware returns a bus address, subtract
> the remembered bus address of the zone start, add the offset to
> the virtual and voila.
Even if not you can hash by page number not low bits so the hash is wa
> > Given that some hardware must return the dma addresses, why
> > should it be a good thing to have an API that doesn't expose
> > the notion of a reverse mapping? At this level -- not the lower
> > level code touching hardware PTEs.
>
> Because its' _very_ expensive on certain machines.
On Fri, Mar 09, 2001 at 09:05:44AM -0500, [EMAIL PROTECTED] wrote:
> I once discovered that the standard UART drivers will only deliver data
> to user level processes on "kernel ticks". Since you are running a
> 100Hz scheduler, that would limit the native UARTS to 10ms minimum
> latency and it l
On Fri, 9 Mar 2001, David Brownell wrote:
> > > > > extern void *
> > > > > pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
> > > >
> > > > Do lots of drivers need the reverse mapping? It wasn't on my todo list
> > > > yet.
> > >
> > > Some hardware (like OHCI) talks to driver
Hi Andrew,
there is a bit for the connection status of every
port of the root-hubs:
OHCI:
connection = 0;
num_ports = readl (&ohci->regs->roothub.a) & RH_A_NDP;
for ( i = 0; i < num_ports; i++) {
connection |= (readl (&ohci->regs->roothub.portstatus[i]) &
RH_PS_CCS);
}
if(!connection) susp
David Brownell wrote:
>
> > > > > > > usb-ohci.c: USB OHCI at membase 0xd3874000, IRQ 11
> > > > > > > usb-ohci.c: usb-00:07.4, Advanced Micro Devices [AMD] AMD-756 [Viper]
> > > > > > > USB
> >
> > I booted 2.4.2-ac12 w/o the mouse attached.
>
> I'd like to verify that this patch prevents that
David Brownell writes:
> Given that some hardware must return the dma addresses, why
> should it be a good thing to have an API that doesn't expose
> the notion of a reverse mapping? At this level -- not the lower
> level code touching hardware PTEs.
Because its' _very_ expensive on certain
David Brownell writes:
> > Do lots of drivers need the reverse mapping? It wasn't on my todo list
> > yet.
>
> Some hardware (like OHCI) talks to drivers using those dma handles.
Drivers for such hardware will this keep track of the information
necessary to make this reverse mapping.
Later
Pete Zaitcev writes:
> > Some hardware (like OHCI) talks to drivers using those dma handles.
>
> I wonder if it may be feasible to allocate a bunch of contiguous
> pages. Then, whenever the hardware returns a bus address, subtract
> the remembered bus address of the zone start, add the offs
> > > Do lots of drivers need the reverse mapping? It wasn't on my todo list
> > > yet.
> >
> > I am against any API which provides this. It can be extremely
> > expensive to do this on some architectures,
The implementation I posted needed no architecture-specific
knowledge. If cost is the
> > > > extern void *
> > > > pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
> > >
> > > Do lots of drivers need the reverse mapping? It wasn't on my todo list
> > > yet.
> >
> > Some hardware (like OHCI) talks to drivers using those dma handles.
>
> I wonder if it may be feasi
On Fri, Mar 09, 2001, Grover, Andrew <[EMAIL PROTECTED]> wrote:
> > This wouldn't work for systems with builtin hubs (not the
> > root hub) and
> > just doesn't seem very intuitive to me.
> >
> > I'm not super familiar with the steps ACPI goes through to
> > suspend, but
> > don't we have a war
> Date: Fri, 09 Mar 2001 10:29:22 -0800
> From: David Brownell <[EMAIL PROTECTED]>
> > > extern void *
> > > pci_pool_dma_to_cpu (struct pci_pool *pool, dma_addr_t handle);
> >
> > Do lots of drivers need the reverse mapping? It wasn't on my todo list
> > yet.
>
> Some hardware (like OHCI) talk
David Brownell wrote:
>> You send it, I'll test it. ;-)
>
>
> Didn't it get through ok?
Not to me, anyhow. I was running Mozilla, so maybe
it's a Mozilla bug.
Thanks for resending. Got it this time.
Miles
___
[EMAIL PROTECTED]
To unsub
Hello!
I experience a lot of troubles with uhci driver driver, in different kernels.
Usually it just panics on device insertion or removal, but this time I got
lucky, and oops was not fatal, so here it is decoded. As I can see,
something stomped on usb_device structure of unplugged de
> This wouldn't work for systems with builtin hubs (not the
> root hub) and
> just doesn't seem very intuitive to me.
>
> I'm not super familiar with the steps ACPI goes through to
> suspend, but
> don't we have a warning that a suspend is about to happen and
> we can do
> things?
>
> Wouldn'
Alan Cox wrote:
> Drivers can keep track of this kind of information
themselves,
> and that is what I tell every driver author to do who complains
> of a lack of a "bus_to_virt()" type thing, it's just lazy
> programming.
I'd agree. There are _good_ reasons for having reverse mappings especially
> > unlike the slab allocator bug(s) I pointed out. (And which
> > Manfred seems to have gone silent on.)
>
> which bugs?
See my previous email ... its behavior contradicts its spec,
and I'd sent a patch. You said you wanted kmalloc to have
an "automagic redzoning" feature, which would involv
> Drivers can keep track of this kind of information themselves,
> and that is what I tell every driver author to do who complains
> of a lack of a "bus_to_virt()" type thing, it's just lazy
> programming.
I'd agree. There are _good_ reasons for having reverse mappings especially on
certain archi
On Fri, Mar 09, 2001, David S. Miller <[EMAIL PROTECTED]> wrote:
> Manfred Spraul writes:
> > Do lots of drivers need the reverse mapping? It wasn't on my todo list
> > yet.
>
> I am against any API which provides this. It can be extremely
> expensive to do this on some architectures, and sinc
On Fri, Mar 09, 2001, Grover, Andrew <[EMAIL PROTECTED]> wrote:
> From reading the UHCI spec, I don't see a way to change the polling rate.
>
> My current thinking is to put the HC into Global Suspend when no devices are
> connected. Entering and leaving global suspend is pretty easy, but I'm sti
Manfred Spraul writes:
> Do lots of drivers need the reverse mapping? It wasn't on my todo list
> yet.
I am against any API which provides this. It can be extremely
expensive to do this on some architectures, and since the rest
of the PCI dma API does not provide such an interface neither
sho
>From reading the UHCI spec, I don't see a way to change the polling rate.
My current thinking is to put the HC into Global Suspend when no devices are
connected. Entering and leaving global suspend is pretty easy, but I'm still
working on where in the code we should do this. If we've suspended,
David Brownell wrote:
> unlike the slab allocator bug(s) I pointed out. (And which
> Manfred seems to have gone silent on.)
which bugs?
If you enable FORCED_DEBUG the allocator will stress test the slab
users. Just use kmem_cache_create and create a cache HW_CACHEALIGN cache
with 4 byte objects.
> You send it, I'll test it. ;-)
Didn't it get through ok?
--- linux/drivers/usb-ac7/usb-ohci.c Thu Mar 1 13:45:31 2001
+++ linux/drivers/usb/usb-ohci.c Thu Mar 8 18:29:52 2001
@@ -2321,6 +2321,13 @@
unsigned long mem_resource, mem_len;
void *mem_base;
+ /* blacklisted hardware? */
+ i
I will be out of the office starting 09/03/2001 and will not return until
20/03/2001.
I am on holidays. If your request is urgent please contact Paul Bohan on
extension 2293.
Regards,
Brian J.
___
[EMAIL PROTECTED]
To unsubscribe, use the last for
David Brownell wrote:
>>> usb-ohci.c: USB OHCI at membase 0xd3874000, IRQ 11
>>> usb-ohci.c: usb-00:07.4, Advanced Micro Devices [AMD] AMD-756 [Viper]
>>> USB
>>
>> I booted 2.4.2-ac12 w/o the mouse attached.
>
>
> I'd like to verify that this patch prevents that oops.
> (Nobod
> > > > > > usb-ohci.c: USB OHCI at membase 0xd3874000, IRQ 11
> > > > > > usb-ohci.c: usb-00:07.4, Advanced Micro Devices [AMD] AMD-756 [Viper]
> > > > > > USB
>
> I booted 2.4.2-ac12 w/o the mouse attached.
I'd like to verify that this patch prevents that oops.
(Nobody's submitted a patch to u
On Fri, Mar 09, 2001 at 09:27:53AM -0500, Hicks, Jamey wrote:
> Are there any large-memory machines that need pci_alloc_consistent() in the
> USB controller driver? If not, then let's just set up an uncached mapping
> of all of DRAM and use a modified version of virt_to_bus and bus_to_virt.
Yuck
> ioremap space: 512MB (from PhilB)
> io space: 256MB
>
> In order to follow your suggestion, we'd have to drop the kernel from 0xc*
> down to 0xb*.
And there are PA risc boxes with > 2Gig of RAM you might want to plug USB
controllers into
__
David S. Miller writes:
> Russell King writes:
> > A while ago, I looked at what was required to convert the OHCI driver
> > to pci_alloc_consistent, and it turns out that the current interface is
> > highly sub-optimal. It looks good on the face of it, but it _really_
> > does need sub-page
When your USB KVM switch is on the bus, the polling rate is at the normal
value. The reduced polling rate only would apply when the bus has nothing
plugged into it.
I would, however point out that a whole second does seem awfully long
when you are waiting to find out if the device you just plugge
> USB controller driver? If not, then let's just set up an uncached mapping
> of all of DRAM and use a modified version of virt_to_bus and bus_to_virt.
If your CPU supports uncached mappings..
___
[EMAIL PROTECTED]
To unsubscribe, use the last form f
Are there any large-memory machines that need pci_alloc_consistent() in the
USB controller driver? If not, then let's just set up an uncached mapping
of all of DRAM and use a modified version of virt_to_bus and bus_to_virt.
It gets around all the issues of having a better allocator of uncached
m
On 9 Mar, Greg KH wrote:
> I ran the program on two devices tonight, using a OHCI host controller
> I didn't patch the kernel to modify HZ like you mentioned, so I don't
> know if that makes a difference with the numbers or not:
>
> Inside Out Networks Edgeport/4
> port = /devfs/usb/tts/0
I ran the program on two devices tonight, using a OHCI host controller
I didn't patch the kernel to modify HZ like you mentioned, so I don't
know if that makes a difference with the numbers or not:
Inside Out Networks Edgeport/4
port = /devfs/usb/tts/0
baud = 38400
packet
As a user of a USB KVM (Keyboard/Video/Mouse switch), one second would cause an
annoying pause in input device responsiveness after every switch. Polling every
quarter-second would be much more acceptable.
One second would be certainly better than the 15 or so seconds that Win98 waits
under these
46 matches
Mail list logo
