Getting my PCMCIA Serial card to work
I like old PCMCIA cards, and would like to get a serial card to work on a Thinkpad X40 running Debian 12.5. The card is just called "Serial I/O PC Card" and should be physically and electrically compatible, 3.3V/5V, 16 bit. I think it is this: https://shop.ocr.ca/media/pdf/Socket-Mobile/srliopc.pdf It didn't immediately work when I inserted it, and instead of spending hours following the red herring down the rabbit hole I thought I should try asking here first for a change. This is what I get from dmesg: [ 331.059401] pcmcia_socket pcmcia_socket0: pccard: PCMCIA card inserted into slot 0 [ 331.059429] pcmcia_socket pcmcia_socket0: cs: memory probe 0xd820-0xdf9f: [ 331.060446] excluding 0xd898-0xd90f 0xdaf0-0xdb67 0xdbe0-0xdc57 0xdcd0-0xdd47 0xddc0-0xde37 0xdeb0-0xdf27 [ 331.068677] pcmcia (null): pcmcia: registering new device pcmcia(null) (IRQ: 3) [ 331.141504] orinoco 0.15 (David Gibson , Pavel Roskin , et al) [ 331.197037] spectrum_cs 0.0: Failed to initialize firmware (err = -16) [ 331.197062] spectrum_cs: orinoco_init() failed When I searched for "spectrum_cs" and "orinico" I got a lot of results for some PC Card WLAN interface, which isn't right. Does anyone recognize this? It should have a bog-standard 16550 compatible UART and PCMCIA is more or less an ISA bus so I did not foresee any problem. Is it perhaps incorrectly detecting my card as a WLAN card? // Anders
Re: Getting my PCMCIA Serial card to work
Anders Andersson writes: > When I searched for "spectrum_cs" and "orinico" I got a lot of results > for some PC Card WLAN interface, which isn't right. Does anyone > recognize this? It should have a bog-standard 16550 compatible UART > and PCMCIA is more or less an ISA bus so I did not foresee any > problem. Is it perhaps incorrectly detecting my card as a WLAN card? It's probably been about 20 years since I've used a PCMCIA card in Linux. Anyways, do you have the pcmciautils package installed? That provides some useful tools to figure things out. udev rules too, presumably to autoload drivers. That card should probably work with the serial_cs driver.
Re: Serious problem with debian 12 bookworm
On 3/1/24 1:38 PM, Byunghee HWANG wrote: RTX 3050 this is a nvidia product, hang is usual with this shit. may be you can try nouveau drivers (to replace nvidia drivers), and hope you will have a solution. https://duckduckgo.com/?q=RTX+3050+linux+resume+hang <-- there is some way to search cheer
Re: Getting my PCMCIA Serial card to work
Anders Andersson wrote: > I like old PCMCIA cards, and would like to get a serial card to work > on a Thinkpad X40 running Debian 12.5. > > The card is just called "Serial I/O PC Card" and should be physically > and electrically compatible, 3.3V/5V, 16 bit. I think it is this: > https://shop.ocr.ca/media/pdf/Socket-Mobile/srliopc.pdf > > It didn't immediately work when I inserted it, and instead of spending > hours following the red herring down the rabbit hole I thought I > should try asking here first for a change. This is what I get from > dmesg: > > [ 331.059401] pcmcia_socket pcmcia_socket0: pccard: PCMCIA card > inserted into slot 0 > [ 331.059429] pcmcia_socket pcmcia_socket0: cs: memory probe > 0xd820-0xdf9f: > [ 331.060446] excluding 0xd898-0xd90f 0xdaf0-0xdb67 > 0xdbe0-0xdc57 0xdcd0-0xdd47 0xddc0-0xde37 > 0xdeb0-0xdf27 > [ 331.068677] pcmcia (null): pcmcia: registering new device > pcmcia(null) (IRQ: 3) > [ 331.141504] orinoco 0.15 (David Gibson > , Pavel Roskin , et al) > [ 331.197037] spectrum_cs 0.0: Failed to initialize firmware (err = -16) > [ 331.197062] spectrum_cs: orinoco_init() failed > > When I searched for "spectrum_cs" and "orinico" I got a lot of results > for some PC Card WLAN interface, which isn't right. Does anyone > recognize this? It should have a bog-standard 16550 compatible UART > and PCMCIA is more or less an ISA bus so I did not foresee any > problem. Is it perhaps incorrectly detecting my card as a WLAN card? It is definitely recognizing your card incorrectly; I have a couple of those orinocos about. (Lucent 802.11b wifi, the first mass-market chipset for wifi. $150 each when they first came out.) This might be a useful doc for you -- in particular, section 4.4 on serial and modem devices: https://tldp.org/HOWTO/PCMCIA-HOWTO-4.html -dsr-
Re: systemd-resolved resolving fails sometimes on Debian12
jeremy ardley wrote: > > On 1/3/24 17:47, Victor Sudakov wrote: > > Has anybody encountered this problem using systemd-resolved as a > > resolver on Debian12? A DNS request via systemd-resolved fails, but > > fails only occasionally. A failure can happen once per a hundred > > successful requests or so. If I run: > > > I recall a similar problem with systemd-resolved. I think it was related to > DNSSEC. In my case the problem seems related to IPv6. That is, when I disable IPv6 via "sysctl net.ipv6.conf.all.disable_ipv6=1" the problem disappears. I did not enable DNSSEC in systemd-networkd. > > I ended up not using systemd-resolved > > Alternatives to systemd-resolved include dnsmasq - which doesn't support > DNSSEC - and bind9 which does. You know, the official Debian 12 AMI for AWS is built on systemd-resolved and systemd-networkd. I'd prefer not to have to modify the official AMI if I can help it, because this would probably mean also replacing the systemd-networkd with some other network manager. Anyway, if there is a bug in systemd-resolved it should be reported, right? I have been able to google up similar (though not exactly the same) issues with systemd-resolved and the caching of CNAME records which give similar random resolution errors, but they are reported as fixed. I tried enabling the debug messages in systemd-resolved and probably (just probably) the random error happens when systemd-resolved's cache for the particular entry expires, but I'm not sure. In fact the debug was not very informative, or I lack the qualification to interpret it. -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49@fidonet signature.asc Description: PGP signature
Encrypted home and pam_mount
Hello, I'm trying to set up a LUKS-encrypted user's home partition which would be automounted when the user logs in. I've installed libpam-mount and added the following line into /etc/security/pam_mount.conf.xml: Automounting works fine, but I'm having trouble with auto-unmounting when I log out. The partition stays mounted and I can see "target is busy" errors from umount in the journal. If I edit logout entry inside pam_mount.conf.xml to look like this: I can see during the first 10sec period that my home dir is held by pulseaudio and dbus-daemon. Then pam_mount terminates them successfully with SIGTERM, waits another 10sec period, tries to kill whatever might remain and successfully unmounts the directory. Interestingly, pam_mount won't wait after sending the last signal, so having kill is important for term to work well, otherwise there will still be a race. So it seems to me that the pam_mount processing happens a bit early during logout, before the system gets an opportunity to shutdown some of the user processes. Is there anything I can change in my configuration to let everything stop gracefully leaving the as a last resort option for pam_mount?
Re: systemd-resolved resolving fails sometimes on Debian12
On 2/3/24 23:06, Victor Sudakov wrote: You know, the official Debian 12 AMI for AWS is built on systemd-resolved and systemd-networkd. I'd prefer not to have to modify the official AMI if I can help it, because this would probably mean also replacing the systemd-networkd with some other network manager. systemd-networkd does not rely on systemd-resolved for name resolution. There is a relationship where systemd-networkd can feed dns information to system-resolved that could be helpful in dynamic IP configurations like laptops. However this is not usual case in AWS deployments. The Debian AWS AMI does not use the usual NetworkManager configuration because the usual AWS deployment does not required dynamic DNS. In my AWS deployments I remove systemd-resolved and use bind9 instead.
Re: systemd-resolved resolving fails sometimes on Debian12
jeremy ardley wrote: > > On 2/3/24 23:06, Victor Sudakov wrote: > > You know, the official Debian 12 AMI for AWS is built on > > systemd-resolved and systemd-networkd. I'd prefer not to have to > > modify the official AMI if I can help it, because this would probably > > mean also replacing the systemd-networkd with some other network > > manager. > > systemd-networkd does not rely on systemd-resolved for name resolution. > > There is a relationship where systemd-networkd can feed dns information to > system-resolved that could be helpful in dynamic IP configurations like > laptops. However this is not usual case in AWS deployments. How is it not usual when the Debian12 AMI for AWS works exactly this way? The system-resolved config is empty (contains only comments) this means that it obtains the upstream DNS address from systemd-networkd. > > The Debian AWS AMI does not use the usual NetworkManager configuration > because the usual AWS deployment does not required dynamic DNS. How does it not require dynamic DNS when an EC2 instance obtains the upstream DNS server address from DHCP? > > In my AWS deployments I remove systemd-resolved and use bind9 instead. > Not that I would use bind9 as a caching resolver but still, how do you pass the dynamically obtained AWS DNS server address from systemd-networkd to bind9 ? -- Victor Sudakov VAS4-RIPE http://vas.tomsk.ru/ 2:5005/49@fidonet signature.asc Description: PGP signature
