You are not logged in.
See my final post for "solution"
Original question:
I'm a fairly new newbie to kernel issues.
/dev/parport is no longer showing up. It's been several months since I've used it. (I use it for bit banging a microcontroller - which worked great several months ago)
Can someone give me suggestions on how to start back tracking what has changed? I'm sorry for the open ended question. But, it just kinda worked before and I didn't need to know how /dev/parport got created. I just used it bit-banging away with avrdude and all worked fine.
Now, no /dev/parport on bootup.
lsmod shows no parport or parport_pc or ppdev
If I modprobe ppdev, then parport and ppdev show up in lsmod report, but there is still no /dev/parport
Hopefully, this is a no-brainer and I need to just create some /dev entry or something like that and the normal boot up process will connect everything up and start the right modules.
What's frustrating is that is was there several months ago - working fine. Of course I've done pacman -Syu since then - without much attention to details.
Thanks for you patient consideration of my hopefully silly question
TheGipp
Last edited by TheGipp (2013-09-02 23:31:47)
Offline
Loading parport, parport_pc and ppdev should be enough.
If it doesn't work, scan dmesg for any messages from parport, parport_pc and ppdev. Maybe something is going wrong.
Last edited by mich41 (2013-09-01 20:25:17)
Offline
Thanks for the quick reply.
I just tried modprobe the following: parport, parport_pc, ppdev, lp
then lsmod shows
Module Size Used by
lp 6910 0
parport_pc 16739 0
ppdev 6030 0
parport 26041 3 lp,ppdev,parport_pc
but /dev/parport* does not show up in /dev
Does anyone recall any recent (6 months) changes to udev rules that might not be making the /dev/parport connection?
It's a tough read for me looking at the /usr/lib/udev/rules.d entries. My only thought is that there is something I can fix by hand in udev rules to make the connection.
dmesg shows no problems with the modprobe I mention above.
Here's the tail end of dmesg:
[ 13.657302] wlan0: associated
[ 28.778334] EXT4-fs (sdb6): re-mounted. Opts: commit=0
[ 28.783494] EXT4-fs (sdb5): re-mounted. Opts: commit=0
[ 29.094025] EXT4-fs (sdb9): re-mounted. Opts: commit=0
[ 29.227660] EXT4-fs (sdb8): re-mounted. Opts: commit=0
[ 999.507192] ppdev: user-space parallel port driver
[ 1869.804984] usb 7-6.4: USB disconnect, device number 5
[10528.681542] lp: driver loaded but no devices found
What does that last dmesg line mean?
BTW, I'm on a dual boot machine with windows XP and LPT3: shows up just fine there. So, the card is ok and worked with Arch many months ago.
Thanks again
TheGipp
Offline
If it doesn't work, scan dmesg for any messages from parport, parport_pc and ppdev. Maybe something is going wrong.
TheGipp, please check dmesg like mich41 suggested.
for reference, this is the output of dmesg | grep parport on my system (lp is not loaded, so no messages from that one).
[ 6.668822] parport_pc 00:05: reported by Plug and Play ACPI
[ 6.668867] parport0: PC-style at 0x378, irq 7 [PCSPP]
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
Lone_Wolf,
dmesg | grep parport reports nothing. There is no reference to parport or ppdev in the dmesg output.
lspci -vvv reports the following:
...
04:05.0 Communication controller: MosChip Semiconductor Technology Ltd. PCI 9835 Multi-I/O Controller (rev 01)
Subsystem: LSI Logic / Symbios Logic 1P2S
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 17
Region 0: I/O ports at ccc8 [size=8]
Region 1: I/O ports at ccd0 [size=8]
Region 2: I/O ports at ccd8 [size=8]
Region 3: I/O ports at cce0 [size=8]
Region 4: I/O ports at cce8 [size=8]
Region 5: I/O ports at ccf0 [size=16]
Kernel driver in use: serial
Kernel modules: parport_serial
I'm not sure what all of that means. But there is no reference to the parallel port. Too bad, I don't have that type of printout from when it worked six months ago.
The card is a Rosewill RC303 - 2 serial ports and 1 parallel port. Is "Region 5" above the parallel port?
Like I said earlier WindowsXP thinks it's ok. So, either Windows didn't check well or Arch/udev is missing some aspect of the PCI card that it used to find on bootup.
any ideas on how to dig more?
Last edited by TheGipp (2013-09-02 15:47:52)
Offline
So it's parport_serial instead of parport_pc. It may be refusing to load due to a conflict with serial; in such case you will need to unload serial first.
Offline
I'm able to modprobe without errors:
modprobe parport_pc
dmesg | tail :
...
[ 45.350643] EXT4-fs (sdb9): re-mounted. Opts: commit=0
[ 45.353133] EXT4-fs (sdb5): re-mounted. Opts: commit=0
[49758.184044] ppdev: user-space parallel port driver
lsmod | head
Module Size Used by
ppdev 6030 0
parport_pc 16739 0
parport 26041 2 ppdev,parport_pc
fuse 62483 3
arc4 1628 2
mperf 991 0
ath9k 77064 0
coretemp 4990 0
...
there is no parport_serial in the lsmod results
It seems like the module is loading fine (manually with with modprobe) and the supporting/associated modules ppdev and parport got dragged along. But there is still no /dev/parport showing up.
Is there a way I can force a /dev node and "connect" it up by hand? That'd be kind of annoying each time, but I'd like to get it to work once just to know it's all ok.
Offline
The "solution" was pacman -Syu.
on reboot /dev/parport0 showed up.
ugh. I wish I could have actually learned something today. Oh well. back to bit-banging
Offline