Driver CH341 USB Adapter Serial Port or QSerialPort not Works in Linux - linux

The following code works for me correctly in Windows, but Linux does not work. I am using the same PC, both operating systems are installed native. I do not use virtual machine. I need to work on Linux. I have tried in different linux distributions and does not work anywhere.
// In the main class:
QSerialPortInfo info = XXXX; // Generally in Linux: /dev/ttyUSB0, in win: COM1
QSerialPort serial;
QObject::connect(&serial, SIGNAL(readyRead()), this, SLOT(onReadyRead()), Qt::DirectConnection);
QObject::connect(&serial, SIGNAL(bytesWritten(qint64)), this, SLOT(onBytesWritten(qint64)), Qt::DirectConnection);
QObject::connect(&serial, SIGNAL(error(QSerialPort::SerialPortError)), this, SLOT(onError(QSerialPort::SerialPortError)), Qt::DirectConnection);
// Slot
void MyClass::onReadyRead()
{
qDebug()<<"Signal onReadyRead";
buffer_mutex.lock();
buffer += serial.readAll();
qDebug()<<"Read: "<<qstr_to_hexstr(buffer);
bufferNotEmpty.wakeAll();
buffer_mutex.unlock();
}
void MyClass::onError(QSerialPort::SerialPortError error) {
qCritical()<<"Serial Port Error: "<<(int)error;
}
void MyClass::onBytesWritten(qint64 size){
qDebug()<<"onBytesWritten: "<<size;
}
// In another place I did:
serial.setPort(info);
if(!serial.open(QIODevice::ReadWrite))
return false;
qDebug()<<"Init Setting!...";
if(!serial.setBaudRate(QSerialPort::Baud9600))
qCritical()<<"Error in setBaudRate";
if(!serial.setDataBits(QSerialPort::Data8))
qCritical()<<"Error in setDataBits";
if(!serial.setParity(QSerialPort::EvenParity))
qCritical()<<"Error in setParity";
if(!serial.setStopBits(QSerialPort::OneStop))
qCritical()<<"Error in setStopBits";
if(!serial.setFlowControl(QSerialPort::SoftwareControl))
qCritical()<<"Error in setFlowControl";
if(!serial.setDataTerminalReady(true))
qCritical()<<"Error in setDataTerminalReady";
qDebug()<<"Setting ready!...";
If sending 1 byte the device responds and sends the data correctly.
Example:
// In the main class:
const char enq[2] = {0x05, '\0'};
serial.write (enq);
// In onReadyRead:
serial.readAll(); // Works on Win / Linux
If sent a more than 1 byte device does not respond the request in linux.
Example:
// In the main class:
const char command[6] = {0x02, 'S', '1', 0x03, 'a', '\0'};
serial.write(command);
// In onReadyRead
serial.readAll(); // Works only in Win
This event is triggered only in windows. In linux it never works, not received or arrives in bad format and never recognized the remote device.
My log in Windows:
{Debug} Init Setting!...
{Debug} Setting ready!...
{Debug} Write: " 0x05 "
{Debug} onBytesWritten: 1
{Debug} buffer wait!...
{Debug} Signal onReadyRead
{Debug} Read: " 0x02 `# 0x03 #"
{Debug} buffer size: 5
{Critical} Serial Port Error: 0
{Debug} Write: " 0x02 S1 0x03 a"
{Debug} onBytesWritten: 5
{Debug} buffer wait!...
{Debug} Signal onReadyRead
{Debug} Read: " 0x02 S100 0x0A 00000000000000000 0x0A 00000479"
{Debug} buffer size: 32
{Debug} buffer wait!...
{Debug} Signal onReadyRead
{Debug} Read: " 0x02 S100 0x0A 00000000000000000 0x0A 00000479 0x0A 00000 0x0A 00000330 0x0A 00000 0x0A 0061 0x0A 0000 0x0A "
{Debug} buffer size: 64
{Debug} Signal onReadyRead
{Debug} buffer wait!...
{Debug} Read: " 0x02 S100 0x0A 00000000000000000 0x0A 00000479 0x0A 00000 0x0A 00000330 0x0A 00000 0x0A 0061 0x0A 0000 0x0A X-XXXXXXXX 0x0A XXXXXXXXX 0x0A 221715 0x0A 120414 0x0A 0x03 0x1B "
{Debug} buffer size: 103
{Critical} Serial Port Error: 0
(I replace the actual response of the device by the 'X' characters)
My log in Linux:
{Debug} Init Setting!...
{Debug} Setting ready!...
{Debug} Write: " 0x05 "
{Debug} onBytesWritten: 1
{Debug} buffer wait!...
{Debug} Signal onReadyRead
{Debug} Read: " 0x02 `# 0x03 #"
{Debug} buffer size: 5
{Critical} Serial Port Error: 0
{Debug} Write: " 0x02 S1 0x03 a"
{Debug} onBytesWritten: 5
{Debug} buffer wait!...
{Debug} buffer wait!...
{Debug} buffer wait!...
{Debug} buffer wait!...
{Debug} buffer wait!...
{Debug} buffer wait!...
{Debug} buffer wait!...
{Debug} buffer wait!...
{Debug} buffer wait!...
{Debug} buffer wait!...
{Debug} timeout!... (15 sec for timeout)
USB Serial Adapter: CH340
In Windows: USB\VID_1A86&PID_7523&REV_0254
In Linux:
Apr 13 01:16:58 kali kernel: [47844.260136] usb 2-1: new full-speed USB device number 16 using uhci_hcd
Apr 13 01:16:58 kali kernel: [47844.428098] usb 2-1: New USB device found, idVendor=1a86, idProduct=7523
Apr 13 01:16:58 kali kernel: [47844.428115] usb 2-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
Apr 13 01:16:58 kali kernel: [47844.428126] usb 2-1: Product: USB2.0-Ser!
Apr 13 01:16:58 kali kernel: [47844.431268] ch341 2-1:1.0: ch341-uart converter detected
Apr 13 01:16:58 kali kernel: [47844.445398] usb 2-1: ch341-uart converter now attached to ttyUSB0
Apr 13 01:16:58 kali mtp-probe: checking bus 2, device 16: "/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1"
Apr 13 01:16:58 kali mtp-probe: bus: 2, device: 16 was not an MTP device
PD: Sorry for my English, try to do my best with Google Translator :(...
More information 1:
Apr 13 04:10:55 kali kernel: [ 4872.627980] tty ttyUSB0: serial_write - 1 byte(s)
Apr 13 04:10:55 kali kernel: [ 4872.629763] tty ttyUSB0: serial_chars_in_buffer
Apr 13 04:10:55 kali kernel: [ 4872.629778] tty ttyUSB0: serial_wait_until_sent
Apr 13 04:10:55 kali kernel: [ 4872.638252] tty ttyUSB0: serial_chars_in_buffer
Apr 13 04:10:55 kali kernel: [ 4872.638267] tty ttyUSB0: serial_write_room
Apr 13 04:10:55 kali kernel: [ 4872.638278] tty ttyUSB0: serial_chars_in_buffer
Apr 13 04:10:55 kali kernel: [ 4872.638287] tty ttyUSB0: serial_write_room
Apr 13 04:10:55 kali kernel: [ 4872.639438] tty ttyUSB0: serial_chars_in_buffer
Apr 13 04:10:55 kali kernel: [ 4872.639458] tty ttyUSB0: serial_write_room
Apr 13 04:10:55 kali kernel: [ 4872.639475] tty ttyUSB0: serial_chars_in_buffer
Apr 13 04:10:55 kali kernel: [ 4872.639488] tty ttyUSB0: serial_write_room
Apr 13 04:10:56 kali kernel: [ 4873.641799] tty ttyUSB0: serial_ioctl - cmd 0x540b
Apr 13 04:10:56 kali kernel: [ 4873.646884] tty ttyUSB0: serial_write - 5 byte(s)
Apr 13 04:10:56 kali kernel: [ 4873.647152] ch341-uart ttyUSB0: ch341_update_line_status - multiple status change
Apr 13 04:10:56 kali kernel: [ 4873.647176] ch341-uart ttyUSB0: ch341_update_line_status - delta=0x01
Apr 13 04:10:56 kali kernel: [ 4873.647384] tty ttyUSB0: serial_chars_in_buffer
Apr 13 04:10:56 kali kernel: [ 4873.647401] tty ttyUSB0: serial_wait_until_sent
Apr 13 04:10:56 kali kernel: [ 4873.649144] ch341-uart ttyUSB0: ch341_update_line_status - multiple status change
Apr 13 04:10:56 kali kernel: [ 4873.649166] ch341-uart ttyUSB0: ch341_update_line_status - delta=0x01
Apr 13 04:10:56 kali kernel: [ 4873.692152] ch341-uart ttyUSB0: ch341_update_line_status - multiple status change
Apr 13 04:10:56 kali kernel: [ 4873.692170] ch341-uart ttyUSB0: ch341_update_line_status - delta=0x01
Apr 13 04:10:56 kali kernel: [ 4873.694133] ch341-uart ttyUSB0: ch341_update_line_status - multiple status change
Apr 13 04:10:56 kali kernel: [ 4873.694148] ch341-uart ttyUSB0: ch341_update_line_status - delta=0x01
I rebuild ch341.c and add:
if (!delta)
return;
dev_info(&port->dev, "%s - delta=0x%02X\n", __func__, delta); // <---- New Line
if (delta & CH341_BIT_CTS)
port->icount.cts++;
if (delta & CH341_BIT_DSR)
port->icount.dsr++;
if (delta & CH341_BIT_RI)
port->icount.rng++;
if (delta & CH341_BIT_DCD) {
port->icount.dcd++;
tty = tty_port_tty_get(&port->port);
if (tty) {
usb_serial_handle_dcd_change(port, tty,
status & CH341_BIT_DCD);
tty_kref_put(tty);
}
}
delta=0x01 in the log is flag:
#define CH341_BIT_CTS 0x01
More information 2:
In the thread of write / read I hope for wakeAll, running on onReadyRead. If you pass a second make a readAll before checking if the buffer is empty. example:
// In the main class:
QWaitCondition bufferNotEmpty;
// In my function write/read:
serial.write(data, size);
buffer_mutex.lock();
while(time(NULL)-timeStart<timeoutWait && serial.isOpen()) {
buffer += serial.readAll();
if(buffer.count()>0){
qDebug()<<"buffer size: "<<buffer.count();
//Interprete the buffer here...
if(bufferComplete)
break;
}
qDebug()<<"buffer wait!...";
bufferNotEmpty.wait(&buffer_mutex, 1000);
}
buffer.clear();
buffer_mutex.unlock();
More information 3:
My Kernel is 3.12.6, but i updated from GitHub this file an rebuild this drivers:
https://github.com/torvalds/linux/blob/master/drivers/usb/serial/ch341.c
https://github.com/torvalds/linux/blob/master/drivers/usb/serial/usb-serial.c
(commit d9a38a8741fdffabc32e6d0943b1cdcf22712bec)

Thanks to the developers of Linux, solved my problem, the CH34x driver not implemented parity in the maillist is the link PATCH for those who have this problem in the future, not whether they apply to the official kernel, for now only way is rebuild the driver.
http://marc.info/?l=linux-serial&m=139749273432052&w=2

Related

Soft lockup occured in VMX testing in Linux

I am testing VMX in Linux (Ubuntu-16.04) in a VMware platform.
When the VM is running a long loop, the host Linux hit CPU softlock, as follows,
Jun 11 00:01:13 ubuntu kernel: [ 5624.196130] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 21s! [guest:8297]
Jun 11 00:01:13 ubuntu kernel: [ 5624.196134] Modules linked in: vmm(OE) rfcomm ipt_MASQUERADE nf_nat_masquerade_ipv4 xfrm_user xfrm_algo iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype iptable_filter ip_tables xt_conntrack x_tables nf_nat nf_conntrack br_netfilter bridge stp llc aufs pci_stub vboxpci(OE) vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) bnep vmw_vsock_vmci_transport vsock crct10dif_pclmul vmw_balloon crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul glue_helper ablk_helper cryptd joydev btusb btrtl btbcm btintel snd_ens1371 input_leds serio_raw bluetooth snd_ac97_codec gameport ac97_bus snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer snd soundcore i2c_piix4 shpchp vmw_vmci 8250_fintek mac_hid kvm_intel kvm irqbypass parport_pc ppdev lp parport autofs4 hid_generic usbhid hid vmwgfx psmouse ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops mptspi mptscsih drm ahci mptbase libahci e1000 scsi_transport_spi pata_acpi fjes [last unloaded: vmm]
Jun 11 00:01:13 ubuntu kernel: [ 5624.196210] CPU: 0 PID: 8297 Comm: guest Tainted: G OEL 4.4.0-127-generic #153-Ubuntu
Jun 11 00:01:13 ubuntu kernel: [ 5624.196212] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/19/2017
Jun 11 00:01:13 ubuntu kernel: [ 5624.196213] task: ffff880092788000 ti: ffff88007ffb8000 task.ti: ffff88007ffb8000
Jun 11 00:01:13 ubuntu kernel: [ 5624.196215] RIP: 0010:[<ffffffffc0648c7f>] [<ffffffffc0648c7f>] failInvalid+0x18/0xa9 [vmm]
Jun 11 00:01:13 ubuntu kernel: [ 5624.196221] RSP: 0018:ffff88007ffbbe60 EFLAGS: 00000246
Jun 11 00:01:13 ubuntu kernel: [ 5624.196223] RAX: 0000000000000000 RBX: 00000000006041c0 RCX: 0000000000000000
Jun 11 00:01:13 ubuntu kernel: [ 5624.196224] RDX: 0000000000001dfa RSI: 0000000000000000 RDI: 000000000000640a
Jun 11 00:01:13 ubuntu kernel: [ 5624.196225] RBP: ffff88007ffbbe70 R08: 000007ff00000017 R09: 0000000000000010
Jun 11 00:01:13 ubuntu kernel: [ 5624.196226] R10: c093ffffffff0000 R11: 0000000000100000 R12: 00000000006041c0
Jun 11 00:01:13 ubuntu kernel: [ 5624.196227] R13: ffff8800b37d2600 R14: 0000000040087401 R15: 00000000006041c0
Jun 11 00:01:13 ubuntu kernel: [ 5624.196229] FS: 00007f8793426700(0000) GS:ffff8800ba600000(0000) knlGS:0000000000000000
Jun 11 00:01:13 ubuntu kernel: [ 5624.196230] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Jun 11 00:01:13 ubuntu kernel: [ 5624.196231] CR2: 0000000000910000 CR3: 00000000671f2000 CR4: 0000000000362670
Jun 11 00:01:13 ubuntu kernel: [ 5624.196237] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Jun 11 00:01:13 ubuntu kernel: [ 5624.196238] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Jun 11 00:01:13 ubuntu kernel: [ 5624.196239] Stack:
Jun 11 00:01:13 ubuntu kernel: [ 5624.196240] 00000000006041c0 00000000006041c0 ffff88007ffbbe88 ffffffffc064a538
Jun 11 00:01:13 ubuntu kernel: [ 5624.196242] ffff8800907ab398 ffff88007ffbbe98 ffffffffc064a83c ffff88007ffbbf08
Jun 11 00:01:13 ubuntu kernel: [ 5624.196244] ffffffff81227f8f 0000000000000002 ffff8800b399e610 ffff88008cf50b10
Jun 11 00:01:13 ubuntu kernel: [ 5624.196246] Call Trace:
Jun 11 00:01:13 ubuntu kernel: [ 5624.196251] [<ffffffffc064a538>] vmm_vcpu_run+0x58/0x310 [vmm]
Jun 11 00:01:13 ubuntu kernel: [ 5624.196254] [<ffffffffc064a83c>] my_ioctl+0x4c/0x50 [vmm]
Jun 11 00:01:13 ubuntu kernel: [ 5624.196258] [<ffffffff81227f8f>] do_vfs_ioctl+0x2af/0x4b0
Jun 11 00:01:13 ubuntu kernel: [ 5624.196260] [<ffffffff81214329>] ? vfs_write+0x149/0x1a0
Jun 11 00:01:13 ubuntu kernel: [ 5624.196262] [<ffffffff81228209>] SyS_ioctl+0x79/0x90
Jun 11 00:01:13 ubuntu kernel: [ 5624.196265] [<ffffffff81850c88>] entry_SYSCALL_64_fastpath+0x1c/0xbb
Jun 11 00:01:13 ubuntu kernel: [ 5624.196267] Code: 00 48 8d 1c 25 74 19 65 c0 0f 78 03 8b 04 25 74 19 65 c0 41 5f 41 5e 41 5d 41 5c 41 5b 41 5a 41 59 41 58 5f 5e 5d 5a 59 5b 58 9d <48> c7 c3 68 01 65 c0 eb 19 4c 8b 23 e8 c0 c4 ff ff 41 89 04 24
VMM enables VMEXIT on Interrupt, and there is timer in VMM to check VM state.
If I called touch_softlockup_watchdog() in the timer function, there is NO such lockup happened.
But I think there is still NO chance for other threads/processes to scheduled on the pCPU where the VM is running.
So the question is, how can the VMM make host Linux scheduler schedule other entities on the pCPU, instead of letting the VM to take over the whole pCPU, calling schedule() or something else?
The VM code is loaded and started by a host application, which loads the VM image into a memory region allocated/setup by VMM. Then sets the vCPU context (like, GPRs, RIP, segment registers, etc), and asks the VMM to start the VM by calling 'VMLaunch' and 'VMResume'.
The easiest way to avoid this is to call schedule() in the handling loop of vmexit in kernel space.
I'm currently facing the exact same problem you described. I'm running a ubuntu 18 in VMWare and try to setup a kernel module than enable VMX. I'm able to run the initialization routine which setup control, guest and host before executing vmlaunch instruction.
vmlaunch execute sucessfully, as I quickly enter hypervisor mode because of wrmsr and rdmsr from the current OS.
However, it seems that I get stuck very quickly, my call trace mostly looks like yours. I don't undestand well what's happening but it seems that i'm trap in exit_to_usermode_loop(). Is it the problem you faced ?

Pulling of docker image from a registry fails

Would love some help about an issue. When I was trying to download an image form the repository it failed and I could see the following errors in the log file. This is the syslog which I received
Jan 4 10:22:05 <hostname> kernel: device-mapper: thin: commit failed: error = -22
Jan 4 10:22:05 <hostname> kernel: device-mapper: thin: switching pool to read-only mode
Jan 4 10:22:05 <hostname> kernel: bio: create slab <bio-2> at 2
Jan 4 10:22:06 <hostname> kernel: device-mapper: btree spine: node_check failed: blocknr 0 != wanted 27706
Jan 4 10:22:06 <hostname> kernel: device-mapper: block manager: btree_node validator check failed for block 27706
Jan 4 10:22:06 <hostname> kernel: device-mapper: thin: process_bio_read_only: dm_thin_find_block() failed: error = -15
Jan 4 10:22:06 <hostname> kernel: Buffer I/O error on device dm-3, logical block 8388592
Jan 4 10:22:06 <hostname> kernel: device-mapper: btree spine: node_check failed: blocknr 0 != wanted 27706
Jan 4 10:22:06 <hostname> kernel: device-mapper: block manager: btree_node validator check failed for block 27706
Jan 4 10:22:06 <hostname> kernel: Buffer I/O error on device dm-3, logical block 8388592
Jan 4 10:22:06 <hostname> kernel: device-mapper: btree spine: node_check failed: blocknr 0 != wanted 27706
Jan 4 10:22:06 <hostname> kernel: device-mapper: block manager: btree_node validator check failed for block 27706
Jan 4 10:22:06 <hostname> kernel: Buffer I/O error on device dm-3, logical block 8388606
Jan 4 10:22:06 <hostname> kernel: device-mapper: btree spine: node_check failed: blocknr 0 != wanted 27706
Jan 4 10:22:06 <hostname> kernel: device-mapper: block manager: btree_node validator check failed for block 27706
Jan 4 10:22:06 <hostname> kernel: Buffer I/O error on device dm-3, logical block 8388606
Jan 4 10:22:07 <hostname> kernel: Buffer I/O error on device dm-3, logical block 0x
Jan 4 10:22:07 <hostname> kernel: Buffer I/O error on device dm-3, logical block 0
Jan 4 10:22:07 <hostname> kernel: Buffer I/O error on device dm-3, logical block 1
Jan 4 10:22:07 <hostname> kernel: Buffer I/O error on device dm-3, logical block 8388607
Jan 4 10:22:07 <hostname> kernel: Buffer I/O error on device dm-3, logical block 8388607
Jan 4 10:22:07 <hostname> kernel: Buffer I/O error on device dm-3, logical block 8388607
Jan 4 10:22:08 <hostname> kernel: device-mapper: space map common: dm_tm_shadow_block() failed
Jan 4 10:22:08 <hostname> kernel: device-mapper: space map common: dm_tm_shadow_block() failed
Jan 4 10:22:08 <hostname> kernel: device-mapper: space map metadata: unable to allocate new metadata block
Jan 4 10:22:08 <hostname> kernel: device-mapper: thin: Deletion of thin device 66 failed.
Jan 4 10:22:10 <hostname> kernel: device-mapper: table: 252:3: thin: Couldn't open thin internal device
Jan 4 10:22:10 <hostname> kernel: device-mapper: ioctl: error adding target to table
Jan 4 10:22:10 <hostname> kernel: device-mapper: thin: Deletion of thin device 66 failed.
Jan 4 10:22:10 <hostname> kernel: device-mapper: table: 252:3: thin: Couldn't open thin internal device
This is the logs from docker
time="2017-01-04T10:22:08Z" level=error msg="Error from V2 registry: read /dev/mapper/docker-252:0-263231-3690474eb5b4b26fdfbd89c6e159e8cc376ca76ef48032a30fa6aafd56337880: input/output error"
Error: image ims:<image_tag> not found
time="2017-01-04T10:22:09Z" level=info msg="-job pull(<iamge>, <image_tag>) = ERR (1)"
time="2017-01-04T10:22:09Z" level=info msg="POST /v1.18/containers/create?name=<container_name>"
time="2017-01-04T10:22:09Z" level=info msg="+job create(<container_name>)"No such image: <iamge>:<image_tag> (tag: <image_tag>)
time="2017-01-04T10:22:09Z" level=info msg="-job create(<container_name>) = ERR (1)"
time="2017-01-04T10:22:09Z" level=error msg="Handler for POST /containers/create returned error: No such image: <iamge>:<image_tag> (tag: <image_tag>)"
time="2017-01-04T10:22:09Z" level=error msg="HTTP Error: statusCode=404
No such image: <iamge>:<image_tag> (tag: <image_tag>)"
time="2017-01-04T10:22:09Z" level=info msg="POST /v1.18/images/create?fromImage=<image_url>"
time="2017-01-04T10:22:09Z" level=info msg="+job pull(<iamge>, <image_tag>)"
time="2017-01-04T10:22:09Z" level=info msg="+job resolve_repository(<iamge>)"
time="2017-01-04T10:22:09Z" level=info msg="-job resolve_repository(<iamge>) = OK (0)"
time="2017-01-04T10:22:09Z" level=info msg="+job trust_key_check(/xyz)"
time="2017-01-04T10:22:09Z" level=info msg="-job trust_key_check(/xyz) = OK (0)"
time="2017-01-04T10:22:10Z" level=error msg="Error from V2 registry: Driver devicemapper failed to create image rootfs 3690474eb5b4b26fdfbd89c6e159e8cc376ca76ef48032a30fa6aafd56337880: device 3690474eb5b4b26fdfbd89c6e159e8cc376ca76ef48032a30fa6aafd56337880 already exists”
Please let me know if any other data is needed. I have the backup of the old docker lib folder.

Is __init attribute used in loadable kernel modules?

The description at this - http://www.tldp.org/LDP/lkmpg/2.4/html/x281.htm - page (as well as some related answers on SO, for example the answer here - __init and __exit macros usage for built-in and loadable modules ) says
The __init macro causes the init function to be discarded and its memory freed once the init function finishes for built-in drivers, but not loadable modules.
However, I tried to insert the following module, in which I try to call the init functions with __init attribute from a non-init function (f2()), and I get error from the kernel, thus indicating that __init has an effect on loadable modules as well.
How and where can I find reliable information about this?
My (above mentioned) program:
#include<linux/module.h>
#include<linux/init.h>
static int __init f1(void){
printk(KERN_ALERT "hello \n");
return 0;
}
static void __exit f2(void){
f1();
printk(KERN_ALERT "bye N\n");
}
module_init(f1);
module_exit(f2);
Error from the kernel:
Jul 8 08:15:51 localhost kernel: hello NOTICE
Jul 8 08:15:54 localhost kernel: [303032.948188] BUG: unable to handle kernel paging request at f9b13000
Jul 8 08:15:54 localhost kernel: [303032.949003] IP: [<f9b13000>] 0xf9b12fff
Jul 8 08:15:54 localhost kernel: [303032.949003] *pdpt = 0000000000d3c001 *pde = 000000003100b067 *pte = 0000000000000000
Jul 8 08:15:54 localhost kernel: [303032.949003] Modules linked in: hello(POF-) tcp_lp lp wacom fuse bnep bluetooth ip6t_rpfilter ip6t_REJECT cfg80211 rfkill xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw joydev snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm coretemp kvm iTCO_wdt iTCO_vendor_support ppdev r8169 mii snd_page_alloc snd_timer snd soundcore microcode serio_raw i2c_i801 lpc_ich mfd_core parport_pc parport acpi_cpufreq mperf binfmt_misc nfsd auth_rpcgss nfs_acl lockd sunrpc i915 ata_generic i2c_algo_bit pata_acpi drm_kms_helper drm i2c_core video [last unloaded: hello]
Jul 8 08:15:54 localhost kernel: [303032.949003] CPU: 1 PID: 11924 Comm: rmmod Tainted: PF O 3.11.10-301.fc20.i686+PAE #1
Jul 8 08:15:54 localhost kernel: [303032.949003] Hardware name: /DG41RQ, BIOS RQG4110H.86A.0013.2009.1223.1136 12/23/2009
Jul 8 08:15:54 localhost kernel: [303032.949003] task: d1bad780 ti: c33a4000 task.ti: c33a4000
Jul 8 08:15:54 localhost kernel: [303032.949003] EIP: 0060:[<f9b13000>] EFLAGS: 00010282 CPU: 1
Jul 8 08:15:54 localhost kernel: [303032.949003] EIP is at 0xf9b13000
Jul 8 08:15:54 localhost kernel: [303032.949003] EAX: f9af6000 EBX: f9af8000 ECX: c0c77270 EDX: 00000000
Jul 8 08:15:54 localhost kernel: [303032.949003] ESI: 00000000 EDI: 00000000 EBP: c33a5f3c ESP: c33a5f30
Jul 8 08:15:54 localhost kernel: [303032.949003] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Jul 8 08:15:54 localhost kernel: [303032.949003] CR0: 8005003b CR2: f9b13000 CR3: 10e7b000 CR4: 000407f0
Jul 8 08:15:54 localhost kernel: [303032.949003] Stack:
Jul 8 08:15:54 localhost kernel: [303032.949003] f9af600b 00000000 00000000 c33a5fac c04b06a9 f4852ac0 c33a5f50 c057989d
Jul 8 08:15:54 localhost kernel: [303032.949003] 00000000 f9af8000 00000800 c33a5f50 6c6c6568 0000006f f4852ac0 f5312490
Jul 8 08:15:54 localhost kernel: [303032.949003] db5e7100 00000000 d1bad780 d1bada9c c33a5f88 c056160d c33a5f9c c046e9de
Jul 8 08:15:54 localhost kernel: [303032.949003] Call Trace:
Jul 8 08:15:54 localhost kernel: [303032.949003] [<f9af600b>] ? f2+0xb/0x1000 [hello]
Jul 8 08:15:54 localhost kernel: [303032.949003] [<c04b06a9>] SyS_delete_module+0x149/0x2a0
Jul 8 08:15:54 localhost kernel: [303032.949003] [<c057989d>] ? mntput+0x1d/0x30
Jul 8 08:15:54 localhost kernel: [303032.949003] [<c056160d>] ? ____fput+0xd/0x10
Jul 8 08:15:54 localhost kernel: [303032.949003] [<c046e9de>] ? task_work_run+0x7e/0xb0
Jul 8 08:15:54 localhost kernel: [303032.949003] [<c099ff0d>] sysenter_do_call+0x12/0x28
Jul 8 08:15:54 localhost kernel: [303032.949003] Code: Bad EIP value.
Jul 8 08:15:54 localhost kernel: [303032.949003] EIP: [<f9b13000>] 0xf9b13000 SS:ESP 0068:c33a5f30
Jul 8 08:15:54 localhost kernel: [303032.949003] CR2: 00000000f9b13000
Jul 8 08:15:54 localhost kernel: [303032.949003] ---[ end trace ca338922043618f4 ]---
Jul 8 08:15:54 localhost kernel: BUG: unable to handle kernel paging request at f9b13000
Jul 8 08:15:54 localhost kernel: IP: [<f9b13000>] 0xf9b12fff
Jul 8 08:15:54 localhost kernel: *pdpt = 0000000000d3c001 *pde = 000000003100b067 *pte = 0000000000000000
Actually, __init attribute affects on loadable modules code.
Probably, this is misprint in the book you refers.
BTW, you should get warning about sections mismatching when build given module.

Why does cryptsetup segfault?

While most of my use a chrooted Gentoo as supplement to another Linux distribution project works fine, unfortunately cryptsetup segfaults on both luksFormat and luksOpen. How to troubleshoot this best?
edit[ For testing purposes I downgraded the Firmware to an older version which runs a 2.6.31 Kernel instead of a 3.3 one, and there the segfault does not occur. Nonetheless I would like to get this working with the newer version, so any help on troubleshooting this is appreciated...
edit2 Following this hint, I compared the output of grep dm_crypt /proc/kallsyms and noticed that the newer Kernel lacks __initcall_dm_crypt_init6 - could this be reason of failure? How can that be fixed?
]
An strace | tail reveals
open("/dev/loop0", O_RDONLY|O_LARGEFILE) = 6
ioctl(6, BLKRAGET, 256) = 0
close(6) = 0
ioctl(3, DM_DEV_CREATE, 0x3cfb0) = 0
ioctl(3, DM_TABLE_LOAD <unfinished ...>
+++ killed by SIGSEGV +++
that ioctrl(3, DM_TABLE_LOAD seems to be responsible, where 3, according to a grep '= 3$' should stem from
open("/dev/mapper/control", O_RDWR|O_LARGEFILE) = 3
so there is some trouble with /dev/mapper/control, where /dev is bind-mounted from the host system into the chroot environment. But what exactly is the problem? How can one figure that out?
Additional output, the usefulness of which I couldn't determine yet:
cryptsetup --debug -v's output is not very informative:
# cryptsetup 1.4.3 processing "cryptsetup --debug -v luksFormat /dev/loop0"
# Running command luksFormat.
# Locking memory.
WARNING!
======== This will overwrite data on /dev/loop0 irrevocably.
Are you sure? (Type uppercase yes): YES
# Allocating crypt device /dev/loop0 context.
# Trying to open and read device /dev/loop0.
# Initialising device-mapper backend, UDEV is disabled.
# Detected dm-crypt version 1.5.1, dm-ioctl version 4.22.0.
# Timeout set to 0 miliseconds.
# Iteration time set to 1000 miliseconds.
# Interactive passphrase entry requested. Enter LUKS passphrase: Verify passphrase:
# Formatting device /dev/loop0 as type LUKS1.
# Crypto backend (gcrypt 1.5.3) initialized.
# Topology: IO (512/0), offset = 0; Required alignment is 1048576 bytes.
# Generating LUKS header version 1 using hash sha1, aes, cbc-essiv:sha256, MK 32 bytes
# PBKDF2: 43251 iterations per second using hash sha1.
# Data offset 4096, UUID 03dcff20-158e-4d16-b89c-90af7b176a80, digest iterations 5250
# Updating LUKS header of size 1024 on device /dev/loop0
# Reading LUKS header of size 1024 from device /dev/loop0
# Adding new keyslot -1 using volume key.
# Calculating data for key slot 0
# Key slot 0 use 21118 password iterations.
# Using hash sha1 for AF in key slot 0, 4000 stripes
# Updating key slot 0 [0x1000] area on device /dev/loop0.
# DM-UUID is CRYPT-TEMP-temporary-cryptsetup-12060
# dm create temporary-cryptsetup-12060 CRYPT-TEMP-temporary-cryptsetup-12060 OF [16384] (*1)
# dm reload temporary-cryptsetup-12060 OFW [16384] (*1) Segmentation fault
Finally, the systrace from the host's /var/log/messages reads
Nov 14 14:02:15 host kernel: Unable to handle kernel paging request at virtual address e58c20f0
Nov 14 14:02:15 host kernel: pgd = cab58000
Nov 14 14:02:15 host kernel: [e58c20f0] *pgd=00000000
Nov 14 14:02:15 host kernel: Internal error: Oops: 5 [#1]
Nov 14 14:02:15 host kernel: Modules linked in: usblp usb_storage uhci_hcd ohci_hcd ehci_hcd usbcore usb_common
Nov 14 14:02:15 host kernel: CPU: 0 Not tainted (3.3.4-88f6281 #1)
Nov 14 14:02:15 host kernel: PC is at async_encrypt+0x44/0x50
Nov 14 14:02:15 host kernel: LR is at async_encrypt+0x48/0x50
Nov 14 14:02:15 host kernel: pc : [<c01fa374>] lr : [<c01fa378>] psr: 20000013
Nov 14 14:02:15 host kernel: sp : c10bfd60 ip : cc372580 fp : c10bfd84
Nov 14 14:02:15 host kernel: r10: d0a75160 r9 : d0a75175 r8 : 00000000
Nov 14 14:02:15 host kernel: r7 : c2f78428 r6 : 00000020 r5 : c2f783c0 r4 : e58c2040
Nov 14 14:02:15 host kernel: r3 : c94a72a0 r2 : 00000040 r1 : 00000000 r0 : c10bfd64
Nov 14 14:02:15 host kernel: Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Nov 14 14:02:15 host kernel: Control: 0005397f Table: 0ab58000 DAC: 00000015
Nov 14 14:02:15 host kernel: Process cryptsetup (pid: 5994, stack limit = 0xc10be270)
Nov 14 14:02:15 host kernel: Stack: (0xc10bfd60 to 0xc10c0000)
Nov 14 14:02:15 host kernel: fd60: c023eddc c01fab50 00000010 c01f88f8 c030e4c8 00000000 c10bfdac c10bfd88
Nov 14 14:02:15 host kernel: fd80: c030e564 c01fa340 c2f783c0 00000040 c2f783c0 d0a75175 d0a7a020 d0a75164
Nov 14 14:02:15 host kernel: fda0: c10bfdcc c10bfdb0 c030e61c c030e50c d0a75168 00000000 c2f783c0 d0a75168
Nov 14 14:02:15 host kernel: fdc0: c10bfe1c c10bfdd0 c030fbcc c030e598 d0a75160 c00d262c c10bfe0c c7752a40
Nov 14 14:02:15 host kernel: fde0: c00dd198 00000000 d0a7516e 00000000 c030feb4 00000020 cebc9200 c2f783c0
Nov 14 14:02:15 host kernel: fe00: d0a7a020 00000005 00000000 cebc9500 c10bfe64 c10bfe20 c030fedc c030f9ec
Nov 14 14:02:15 host kernel: fe20: c10bfe64 c10bfe30 c0308148 c023d270 c10bfe64 00000040 d0a7a020 000000fa
Nov 14 14:02:15 host kernel: fe40: 000000fa d0a7a020 cebc9500 d0a75150 00000000 cebc9500 c10bfe9c c10bfe68
Nov 14 14:02:15 host kernel: fe60: c0308954 c030fe7c 00000000 00000000 cebc9200 00000005 000000fa 00000000
Nov 14 14:02:15 host kernel: fe80: 00000001 d0a75000 d0a79000 c10bfeb0 c10bfee4 c10bfea0 c030b57c c03087b0
Nov 14 14:02:15 host kernel: fea0: 000000fa 00000000 d0a75160 00008004 d0a75160 d0a75138 c0308b5c 00004000
Nov 14 14:02:15 host kernel: fec0: cb637c00 d0a75000 00000000 c030b604 c10be000 00008004 c10bff0c c10bfee8
Nov 14 14:02:15 host kernel: fee0: c030b678 c030b52c 00000016 cebc9500 c10be000 00000000 0003cf80 00004000
Nov 14 14:02:15 host kernel: ff00: c10bff3c c10bff10 c030c5c4 c030b614 c00fb8b4 d0a75000 cb4580a0 0003cf80
Nov 14 14:02:15 host kernel: ff20: c138fd09 cb4580a0 c000bca8 00000000 c10bff4c c10bff40 c030c65c c030c4c8
Nov 14 14:02:15 host kernel: ff40: c10bff5c c10bff50 c00f06b4 c030c654 c10bff7c c10bff60 c00f0e10 c00f0694
Nov 14 14:02:15 host kernel: ff60: c10bff8c c10bff70 00000003 0003cf80 c10bffa4 c10bff80 c00f0fbc c00f0db0
Nov 14 14:02:15 host kernel: ff80: c10bffa4 00000000 00000001 b6f93cc8 b6e22e80 00000036 00000000 c10bffa8
Nov 14 14:02:15 host kernel: ffa0: c000bb00 c00f0f8c 00000001 b6f93cc8 00000003 c138fd09 0003cf80 b6e31450
Nov 14 14:02:15 host kernel: ffc0: 00000001 b6f93cc8 b6e22e80 00000036 0003cfb0 0003cec0 b6e22e80 0003cf80
Nov 14 14:02:15 host kernel: ffe0: b6e2f0f4 bedcbbfc b6e1e880 b6f083bc 60000010 00000003 e2433001 e5863000
Nov 14 14:02:15 host kernel: Backtrace:
Nov 14 14:02:15 host kernel: [<c01fa330>] (async_encrypt+0x0/0x50) from [<c030e564>] (crypt_setkey_allcpus+0x68/0x8c)
Nov 14 14:02:15 host kernel: r4:00000000
Nov 14 14:02:15 host kernel: [<c030e4fc>] (crypt_setkey_allcpus+0x0/0x8c) from [<c030e61c>] (crypt_set_key+0x94/0xb8)
Nov 14 14:02:15 host kernel: r8:d0a75164 r7:d0a7a020 r6:d0a75175 r5:c2f783c0 r4:00000040
Nov 14 14:02:15 host kernel: [<c030e588>] (crypt_set_key+0x0/0xb8) from [<c030fbcc>] (crypt_ctr_cipher+0x1f0/0x490)
Nov 14 14:02:15 host kernel: r6:d0a75168 r5:c2f783c0 r4:00000000
Nov 14 14:02:15 host kernel: [<c030f9dc>] (crypt_ctr_cipher+0x0/0x490) from [<c030fedc>] (crypt_ctr+0x70/0x2fc)
Nov 14 14:02:15 host kernel: [<c030fe6c>] (crypt_ctr+0x0/0x2fc) from [<c0308954>] (dm_table_add_target+0x1b4/0x350)
Nov 14 14:02:15 host kernel: [<c03087a0>] (dm_table_add_target+0x0/0x350) from [<c030b57c>] (populate_table+0x60/0xe8)
Nov 14 14:02:15 host kernel: r9:c10bfeb0 r8:d0a79000 r7:d0a75000 r6:00000001 r5:00000000
Nov 14 14:02:15 host kernel: r4:000000fa
Nov 14 14:02:15 host kernel: [<c030b51c>] (populate_table+0x0/0xe8) from [<c030b678>] (table_load+0x74/0x1f4)
Nov 14 14:02:15 host kernel: [<c030b604>] (table_load+0x0/0x1f4) from [<c030c5c4>] (ctl_ioctl+0x10c/0x18c)
Nov 14 14:02:15 host kernel: r7:00004000 r6:0003cf80 r5:00000000 r4:c10be000
Nov 14 14:02:15 host kernel: [<c030c4b8>] (ctl_ioctl+0x0/0x18c) from [<c030c65c>] (dm_ctl_ioctl+0x18/0x1c)
Nov 14 14:02:15 host kernel: [<c030c644>] (dm_ctl_ioctl+0x0/0x1c) from [<c00f06b4>] (vfs_ioctl+0x30/0x44)
Nov 14 14:02:15 host kernel: [<c00f0684>] (vfs_ioctl+0x0/0x44) from [<c00f0e10>] (do_vfs_ioctl+0x70/0x1dc)
Nov 14 14:02:15 host kernel: [<c00f0da0>] (do_vfs_ioctl+0x0/0x1dc) from [<c00f0fbc>] (sys_ioctl+0x40/0x68)
Nov 14 14:02:15 host kernel: r5:0003cf80 r4:00000003
Nov 14 14:02:15 host kernel: [<c00f0f7c>] (sys_ioctl+0x0/0x68) from [<c000bb00>] (ret_fast_syscall+0x0/0x2c)
Nov 14 14:02:15 host kernel: r7:00000036 r6:b6e22e80 r5:b6f93cc8 r4:00000001
Nov 14 14:02:15 host kernel: Code: e24b0020 e59c1024 e59c2020 e1a0e00f (e594f0b0)
Nov 14 14:02:15 host kernel: ---[ end trace 3c58c565608fcd8c ]---
Ok, so it's an "Oops: 5", the meaning of which I don't know...

Cannot connect to the usb-serial port (GSM modem)

I've decided to bring up a GSM Modem for my Linux machine (OpenSuse 12.1 64-bit on Vmware) so that I can use it as the SMS gateway. I've got a Wavecom M1306B GSM modem which provides a USB interface, and obviously there is a USB cable (end to end, GSM Modem to my Desktop) with it.
I tested this modem successfully with my Windows 7 64-bit PC by running some basic commands on it. (like: AT , ATZ, ..)
Here are some of my logs:
machine2:~ # lsusb
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse
Bus 001 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub
Bus 001 Device 006: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
lsusb -v output for that interface:
Bus 001 Device 006: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x067b Prolific Technology, Inc.
idProduct 0x2303 PL2303 Serial Port
bcdDevice 3.00
iManufacturer 1 Prolific Technology Inc.
iProduct 2 USB-Serial Controller
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x000a 1x 10 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)
machine2:/proc # setserial -a /dev/ttyUSB0
/dev/ttyUSB0, Line 0, UART: 16654, Port: 0x0000, IRQ: 0
Baud_base: 460800, close_delay: 0, divisor: 0
closing_wait: infinte
Flags: spd_normal
machine2:/home/smsto/bin # setserial -a /dev/ttyS0
/dev/ttyS0, Line 0, UART: 16550A, Port: 0x03f8, IRQ: 4
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test
machine2:/home/smsto/bin # setserial -a /dev/ttyS1
/dev/ttyS1, Line 1, UART: 16550A, Port: 0x02f8, IRQ: 3
Baud_base: 115200, close_delay: 50, divisor: 0
closing_wait: 3000
Flags: spd_normal skip_test
machine2:/proc # setserial -G /dev/ttyUSB0
/dev/ttyUSB0 uart 16654 port 0x0000 irq 0 baud_base 460800 spd_normal
machine2:/proc # setserial /dev/ttyUSB0
/dev/ttyUSB0, UART: 16654, Port: 0x0000, IRQ: 0
machine2:/proc/tty/driver # ls -ltr
total 0
-r--r--r-- 1 root root 0 Jan 10 14:03 usbserial
-r--r--r-- 1 root root 0 Jan 10 14:03 serial
machine2:/proc/tty/driver # cat serial
serinfo:1.0 driver revision:
0: uart:16550A port:000003F8 irq:4 tx:0 rx:0 CTS|DSR|CD
1: uart:16550A port:000002F8 irq:3 tx:0 rx:0 CTS|DSR|CD
2: uart:unknown port:000003E8 irq:4
3: uart:unknown port:000002E8 irq:3
4: uart:unknown port:00000000 irq:0
5: uart:unknown port:00000000 irq:0
6: uart:unknown port:00000000 irq:0
7: uart:unknown port:00000000 irq:0
machine2:/proc/tty/driver # cat usbserial
usbserinfo:1.0 driver:2.0
0: module:pl2303 name:"pl2303" vendor:067b product:2303 num_ports:1 port:1 path:usb-0000:02:00.0-2.1
machine2:/proc/tty # cat drivers
/dev/tty /dev/tty 5 0 system:/dev/tty
/dev/console /dev/console 5 1 system:console
/dev/ptmx /dev/ptmx 5 2 system
/dev/vc/0 /dev/vc/0 4 0 system:vtmaster
usbserial /dev/ttyUSB 188 0-253 serial
serial /dev/ttyS 4 64-79 serial
pty_slave /dev/pts 136 0-1048575 pty:slave
pty_master /dev/ptm 128 0-1048575 pty:master
unknown /dev/tty 4 1-63 console
machine2:/proc/tty # dmesg | grep -i tty
[ 1.383652] serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 1.424541] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 1.581063] 00:0a: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
[ 1.654207] 00:0b: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
[ 1.938507] tty tty17: hash matches
[ 2498.137304] usb 1-2.1: pl2303 converter now attached to ttyUSB0
I noticed that the Baud rate of USB0 interface is too much, so i tried to assign 115200 :
machine2:/proc # setserial /dev/ttyUSB0 baud_base 115200
Cannot set serial info: Invalid argument
So, it is the problem ... and I receive this error.
Whenever I try to connect S0, S1, USB0 interfaces via minicom, it simply doesn't work.
Baud_base is not the port speed, it's the maximum speed when a frequency divisor is 1. The ability to set baud_base probably doesn't apply to USB serial device at all, and it's most certainly not what you want.
Use stty to set the port speed, or use cu or minicom for testing (they can set port speed by themselves).
I'm not sure about the baud rate but If you open up another terminal and do cat /dev/ttyUSB0
Then in the first terminal do echo AT > /dev/ttyUSB0 you might get an OK back..not sure if it helps but it should get you a response at least..

Resources