Paul Bolle

Tilman Schmidt schreef op wo 18-09-2019 om 18:16 [+0000]: So I just implemented a timeout and if, after that time, the HD_READY_SEND_ATDATA signal still hasn't arrived, the driver sends the next command anyway, assuming that the signal has just been lost and hoping that the base will complain in a sensible way if that assumption is wrong, most probably by indicating a stall. (A possible alternative would be to send an empty command, analogously to what gigaset_write_cmd() does in the symmetric case...

Tilman Schmidt schreef op di 17-09-2019 om 22:51 [+0000]: "Etc." would notably include the serial line discipline interface which is used for connecting the ser_gigaset driver to the serial port framework of the kernel. (I was in fact familiar with the concept of line disciplines from Unix SVR4 but they Linux implementation is quite different and I had to fix a few errors and omissions in Documentation/serial/tty.txt first before being able to use it.) This reminds me that I had to ask you what on...

Malte Forkel schreef op di 17-09-2019 om 17:32 [+0000]: I think I found out what might be causing the connection failures I reported: There seems to be a conflict between gigacontr using the USB connection to the Gigaset base and a digital video recorder program (vdr) using a DVB-C adapter connected to the Raspberry Pis. This is a Hauppage WinTV soloHD USB adapter; is uses the em28xx kernel driver. Good news! Both Gigaset base and DVB-C adapter are connected to an external USB hub with its own power...

Malte Forkel schreef op di 17-09-2019 om 17:01 [+0000]: Thanks, Paul, for working on the driver! I'm very much in favor of keeping it in the kernel. I would definitely like to continue using it to control my Gigaset base, e.g. for initiating telephone calls from my desktop and retrieving the list of incoming and outgoing connections. Please let me know what I can do to support that cause. Test it like there's no tomorrow! And learn C, while you're at it. Paul Bolle

Paul Bolle schreef op za 31-08-2019 om 21:09 [+0200]: Perhaps I'll try a similar test on my live base (behind a ISDN <-> VOIP bridge). If I'll do, the results will be summarized here. What I have done instead is to hack on the driver with a sledgehammer: - drop ser-gigaset.c; - drop capi.c; - remove a lot of unreachable code; - make the driver Unimodem only. This allowed me to cut out 2/3s of the driver. And in the end I looked at a driver depending only on TTY and USB. gigacontr still works, to...

Malte Forkel schreef op ma 19-08-2019 om 16:18 [+0000]: No spare base, but currently I'm its only user. So no reason not to run tests. I've run a few hundreds downloads of the log from a spare base in quick succession. Think: every 15 seconds. Nothing quite as serious as you saw in the logs. Note that I'm running v5.3-rcx. Perhaps I'll try a similar test on my live base (behind a ISDN <-> VOIP bridge). If I'll do, the results will be summarized here. Paul Bolle

Hi Malte, Malte Forkel schreef op do 15-08-2019 om 11:55 [+0000]: I'm still using self-compiled modules (capi and gigaset) to connect to a Gigaset 3075 base from Raspberry Pi running Raspbian stretch (currently kernel 4.19.58-v7+) as reported in an earlier post (https://sourceforge.net/p/gigaset307x/discussion/75814/thread/c03320a0/). Malte and I determined off list that Malte's setup doesn't require capi. dummy link level will do. But this problem also happens while running the dummy LL. Too bad....

Tilman Schmidt schreef op za 17-08-2019 om 16:42 [+0000]: In my experiments, unplugging and replugging the USB cable to the base helped best. At one point I even tried to find out whether I could simulate that from the driver, but found no way to do so. So I assume a rmmod/insmod sequence (or its modprobe equivalent) didn't reset the base state to something usable? Paul Bolle