Borchers, Al (C)(STP) wrote:
The digi_acceleport driver does something like this--you can
look at that.
thanks, i had just started looking at the digi driver this morning and
was wondering if that could be implemented on other adapters. i'll post
as soon as i have something testable.
thanks
d
Alan Cox wrote:
usb-rs232 adapters since the way the usb to rs232 interface is created
none of these devices should support opost. in addition this problem
probably also exists with usb modem devices such as the acm module. i'm
currently looking at the multitech usb modem using hylafax, so i sh
Al Borchers wrote:
> Forgot to explain that opost calls write_room to see
> if there is room to write two characters when it
> wants to write "\r\n". pl2303 says sure, there is
> room. opost then writes '\r' and '\n' in two
> separate writes, expecting that there is room for
> both, but the seco
Greg,
turns out its a simple fix, on the pl2303 you just need to set OPOST to
off on in the set_termios function. this prevents other apps from making
a change to the status. after making the addition, echo, cat, and my
test app work fine without lockups. this still leaves the issue of not
hav
Greg KH wrote:
Hm, I don't really know. Perhaps you might want to ask this on the
linux-kernel mailing list.
just to keep you up to date, looks like the issue is leading back to the
usb sections and the generic write_room(). still debugging.
thanks
dave
---
Greg KH wrote:
What kernel version is this?
this is on 2.4.20
Aug 20 11:39:03 lnxtest kernel: pl2303.c: pl2303_ioctl (0) cmd = 0x5401
Aug 20 11:39:03 lnxtest kernel: pl2303.c: pl2303_ioctl not supported = 0x5401
TCGETS, not really a big deal that we don't support this one
Aug 20 11:39:03 ln
Greg KH wrote:
Hm, I don't really know. Perhaps you might want to ask this on the
linux-kernel mailing list.
already digging into with a couple of kernel folks, probably have
something figured out by the first of next week, i'll keep you posted
thanks
dave
--
greg,
ok i've tracked the problem down. i've tracked the problem to the
drivers/char/n_tty.c file. the usb-serial(as well as the acm and other
psuedo serial devices which explains the hylafax and getty issues) seems
to be using the:
/*
* opost_block --- to speed up block console writes, among
Greg KH wrote:
Aug 20 11:39:03 lnxtest kernel: pl2303.c: pl2303_write - port 0, 24 bytes
Aug 20 11:39:03 lnxtest kernel: pl2303.c: pl2303_write - length = 24, data = 74 65 73 74 20 6f 75 74 70 75 74 20 77 69 74 68 20 6e 65 77 6c 69 6e 65
Aug 20 11:39:03 lnxtest kernel: pl2303.c: pl2303_write_bulk
Greg KH wrote:
Can you load the pl2303 driver with:
modprobe pl2303 debug=1
and then run the program for me?
You should see a lot of information in the kernel debug log, any info on
ioctls that your program is using that is not supported by the driver
would be nice to see.
attached are three c
Greg KH wrote:
> Can you load the pl2303 driver with:
> modprobe pl2303 debug=1
> and then run the program for me?
>
> You should see a lot of information in the kernel debug log, any info on
> ioctls that your program is using that is not supported by the driver
> would be nice to see.
sure,
Greg KH wrote:
> Can you load the pl2303 driver with:
> modprobe pl2303 debug=1
> and then run the program for me?
>
> You should see a lot of information in the kernel debug log, any info on
> ioctls that your program is using that is not supported by the driver
> would be nice to see.
sure,
Greg KH wrote:
What kernel version?
i've tested with 2.4.18, 2.4.20, and 2.4.21 with the last posted patches
primarily tested with the pl2303 module, however i did get the same
response on the mct_u232 and keyspan modules. this same program on a
standard rs-232 port works fine. uncommenting vari
Howdy all,
been doing some testing with various pl2303 and mct_u2323 based
usb-to-rs232 adapters. the devices are recognized and appear to work,
however the ONCLR ioctl for the both modules seems to lock the port.i've
created a small c program do test the port. when i set the port to raw,
the
David Brownell wrote:
And you're sure the IRQs are arriving at the controllers?
See the FAQ entry about devices not accepting addresses...
yep, read the FAQ and did the checks per the instructions, i do see
IRQ's arriving at the controllers using several other usb devices, and i
do see interrupt
Roger Larsson wrote:
What type is the host? uhci, ohci, ehci?
How does the usb status differ
cat /proc/bus/usb/devices
i've tried it on all three types of hosts and the device never shows up
in the /proc/bus/usb/devices.
thanks
dave
---
howdy all,
wondering if any has successfully made the cyberdata usb-rs232 module
work? it is based on the kawasaki KL5KUSB116 chipset. the KL5KUSB105
module appears to be generic enough to work with this unit, however,
i've been unable to get it working. when the device is connect i get an
err
17 matches
Mail list logo
