[Rack] gateman isn't working!

Jonathan Lassoff jof at thejof.com
Tue Jul 30 07:06:31 UTC 2013

Something wedged the state of the uss720 driver that controls the parallel
port adapter.

I had to force unload it, restart and re-probe the usb device and things
and ioctls seem to be flowing again.

FYI -- I'm creating a modprobe.d blacklist for the "lp" and "usblp"
drivers. Hoping this will avoid other users of the port in the future.
File is in /etc/modprobe.d/lp-blacklist.conf

If you're a udev hacker, I'd appreciate some help in getting /dev/parport0
created automatically with the right major, minor, and ownership/perm bits
RIght now, I'm just manually fixing it up. This is what I'm going
for: crw-rw---T 1 root lp 99, 0 Jul 29 23:59 /dev/parport0

On Mon, Jul 29, 2013 at 11:42 PM, Jake <jake at spaz.org> wrote:

> help!!!!  it's not working!!!
> me and sharp are trying to fix it but.. we need you jof
> this gateman shit is not working at all.  we tried the mknod thing and...
> help!  the door can't be opened!
> -jake
> 415-533-3699
> (leaving by midnight)
> On Sat, 6 Jul 2013, Jonathan Lassoff wrote:
>  Ok, I did some security, packaging, and general FIXME work on gateman,
>> and have it running now.
>> We may need to run this if the box reboots. I'l still not sure about
>> fixing udev the right way.
>>  sudo mknod /dev/parport0 c 99 0
>>  sudo service gateman status || sudo service gateman start
>> On Sat, Jul 6, 2013 at 3:56 PM, Jonathan Lassoff <jof at thejof.com> wrote:
>>> So, I figured out that /dev/usb/lp0 is actually a line printer emulation
>>> device.
>>> /dev/parport0 was still what I wanted (99, 0), but udev wasn't creating
>>> it.
>>> I manually did a mknod for it, but now just need to figure out how to
>>> get it to survive reboots.
>>> --j
>>> On Sat, Jul 6, 2013 at 2:12 PM, Jonathan Lassoff <jof at thejof.com> wrote:
>>>> On Sat, Jul 6, 2013 at 3:17 AM, Jake <jake at spaz.org> wrote:
>>>>> we have been spamming the discuss list with this stuff.  no more.
>>>> Oh... yeah, I suppose rack@ is more appropriate.
>>>> However, I think we're more on-topic in this thread than most of the
>>>> other threads :p
>>>>  it may be an issue of the old hardware having a "real" parallel port
>>>>> that we
>>>>> never used, because we didn't have a connector for it, and the new
>>>>> hardware
>>>>> doesn't have a real parallel port.
>>>> Certainly possible.
>>>> However, since it's the USB emulator in both cases. I'm unsure exactly
>>>> what is breaking.
>>>>  make sure you're talking to the right device, which is a USB parallel
>>>>> port
>>>>> which is tied to the sprinkler pipe just above the wall-o-tubes.
>>>>> i guess you're looking at /dev/usb... so it should be the right device.
>>>>> it must be something about the new OS install, different drivers for
>>>>> the usb
>>>>> parallel port or something fucked up like that.  good luck.
>>>> I think I'm talking to the right device. Both kernels used the uss720
>>>> driver, however I was getting at it as /dev/parport0 (hard-coded into
>>>> gateman :( ), whereas now there seems to be a device at /dev/usb/lp0.
>>>> It's major number 180, minor 0, which the device listing
>>>> (http://www.mjmwired.net/**kernel/Documentation/devices.**txt#2531<http://www.mjmwired.net/kernel/Documentation/devices.txt#2531>)
>>>> shows
>>>> as 0 = /dev/usb/lp0 First USB printer.
>>>> I wonder if I'm trying to bit-bang to something that is supposed to be
>>>> a printer, and that is getting in the way.
>>>> I'll keep hacking and experimenting. Any kernel hackers looking for a
>>>> short exploration are encouraged to get in touch.
>>>> Cheers,
>>>> jof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.noisebridge.net/pipermail/rack/attachments/20130730/f8b4a274/attachment.html>

More information about the Rack mailing list