On Fri, 2004-10-01 at 16:34 +0200, Duncan Sands wrote:
> On Thursday 30 September 2004 23:40, David Woodhouse wrote:
> > On Wed, 2004-09-29 at 13:57 +0200, Duncan Sands wrote:
> > > I will check it all out tonight.
> >
> > Any comments?
>
> Here is an incremental patch. It uses a kref for refere
On Thursday 30 September 2004 23:40, David Woodhouse wrote:
> On Wed, 2004-09-29 at 13:57 +0200, Duncan Sands wrote:
> > I will check it all out tonight.
>
> Any comments?
Here is an incremental patch. It uses a kref for reference counting,
and fixes a reference counting bug in udsl_firmware_sta
On Thursday 30 September 2004 23:40, David Woodhouse wrote:
> On Wed, 2004-09-29 at 13:57 +0200, Duncan Sands wrote:
> > I will check it all out tonight.
>
> Any comments?
I'm deep in the reference counting...
Duncan.
---
This SF.net email is
On Wed, 2004-09-29 at 13:57 +0200, Duncan Sands wrote:
> I will check it all out tonight.
Any comments?
--
dwmw2
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you
On Wed, 2004-09-29 at 13:57 +0200, Duncan Sands wrote:
> this races with modem_run: since the firmware loading is done in a separate
> kernel thread, it is possible to do:
>
> (1) probe completes
> (2) hotplug call - modem_run tries to grab the interface and fails
> (3) firmware loading code fails
On Wed, 2004-09-29 at 13:57 +0200, Duncan Sands wrote:
> Hi David,
>
> > OK... if the firmware is found in /lib/firmware this loads it, then
> > starts up the modem and monitors the status. If the firmware _isn't_
> > found it waits for modem_run as before.
>
> this races with modem_run: since t
Hi David,
> OK... if the firmware is found in /lib/firmware this loads it, then
> starts up the modem and monitors the status. If the firmware _isn't_
> found it waits for modem_run as before.
this races with modem_run: since the firmware loading is done in a separate
kernel thread, it is possib
On Wed, 2004-09-29 at 08:50 +0200, Duncan Sands wrote:
> > I'll fix your version, and merge in the missing parts from mine.
>
> Great, thanks. I will try to do some polishing/testing/thinking
> tonight.
OK... if the firmware is found in /lib/firmware this loads it, then
starts up the modem and m
On Wednesday 29 September 2004 01:23, David Woodhouse wrote:
> I found the problem. The buffer returned by request_firmware() is in
> vmalloc space; we can't DMA from that.
D'oh!
> By copying into a kmalloc'd buffer we can make it work.
>
> I'll fix your version, and merge in the missing parts f
I found the problem. The buffer returned by request_firmware() is in
vmalloc space; we can't DMA from that.
By copying into a kmalloc'd buffer we can make it work.
I'll fix your version, and merge in the missing parts from mine.
--
dwmw2
--
On Tue, 2004-09-28 at 20:48 +0200, Duncan Sands wrote:
> > > By the way, the symptoms you have are those you get if the firmware is
> > > already loaded. Are you sure it wasn't loaded previously by modem_run?
> >
> > Very sure.
>
> I had to ask :)
Fair enough :)
I'm half inclined to blame my
On Tuesday 28 September 2004 19:39, David Woodhouse wrote:
> On Tue, 2004-09-28 at 19:11 +0200, Duncan Sands wrote:
> > > I'm beginning to wonder if it's purely timing-related. But it doesn't
> > > matter how long I leave it between connecting the modem and running the
> > > userspace program -- an
On Tue, 2004-09-28 at 19:11 +0200, Duncan Sands wrote:
> > I'm beginning to wonder if it's purely timing-related. But it doesn't
> > matter how long I leave it between connecting the modem and running the
> > userspace program -- and it doesn't work if I connect the modem then
> > wait a while befo
> I'm beginning to wonder if it's purely timing-related. But it doesn't
> matter how long I leave it between connecting the modem and running the
> userspace program -- and it doesn't work if I connect the modem then
> wait a while before loading the kernel module either.
By the way, the symptoms
On Tuesday 28 September 2004 19:08, David Woodhouse wrote:
> On Tue, 2004-09-28 at 19:05 +0200, Duncan Sands wrote:
> > > It appears to confirm my belief that the userspace program is doing
> > > _precisely_ what both Duncan's and my kernel versions do nothing but
> > > the bulk transfer. I've
> You could try using the "usbfs_snoop=true" module parameter to check and
> see what's actually being sent from the userspace program.
The source is with us :)
Duncan.
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJour
On Tue, 2004-09-28 at 19:05 +0200, Duncan Sands wrote:
> > It appears to confirm my belief that the userspace program is doing
> > _precisely_ what both Duncan's and my kernel versions do nothing but
> > the bulk transfer. I've already triple-checked the endpoints and the
> > data. We show a CR
> It appears to confirm my belief that the userspace program is doing
> _precisely_ what both Duncan's and my kernel versions do nothing but
> the bulk transfer. I've already triple-checked the endpoints and the
> data. We show a CRC on the data and print the length. I've even done a
> hex dump
Am Dienstag, 28. September 2004 10:54 schrieb Duncan Sands:
> > No, the main user is not user space, but the networking code. All line
> > monitoring for ethernet is done in kernel space exactly for that reason.
> > There's a defined interface for reporting line state and it's been there
> > for ag
On Tue, 2004-09-28 at 11:29 -0400, Alan Stern wrote:
> On Tue, 28 Sep 2004, David Woodhouse wrote:
>
> > I don't understand why modem_run works but two entirely separate
> > reimplementations of exactly the same thing in the kernel don't work.
> > What are we doing differently?
>
> You could try
On Tue, 28 Sep 2004, David Woodhouse wrote:
> I don't understand why modem_run works but two entirely separate
> reimplementations of exactly the same thing in the kernel don't work.
> What are we doing differently?
You could try using the "usbfs_snoop=true" module parameter to check and
see wha
> I don't understand why modem_run works but two entirely separate
> reimplementations of exactly the same thing in the kernel don't work.
> What are we doing differently?
Timing possibly.
Regards
Oliver
---
This SF.Ne
> No, the main user is not user space, but the networking code. All line
> monitoring for ethernet is done in kernel space exactly for that reason.
> There's a defined interface for reporting line state and it's been there
> for ages.
Except that ATM is not ethernet: the kernel ATM layer neither u
Am Dienstag, 28. September 2004 09:56 schrieb Duncan Sands:
> > > Also, is there really any point in monitoring the line status?
> > > That's one thing that could be done perfectly well from user space.
> >
> > It's cheap and easy to do it in the kernel; it doesn't involve running a
> > daemon.
24 matches
Mail list logo
