Re: Usb printers take the same port deterministically?
Thanks, Warren. Works great, mostly :)
I actually need the "unlpt*" device because of publishing the raw printers.
Hooking the attach/detach of those device names directly did not work.
Adding an action to the "ulpt" device does work... but I then ran into the
problem of pulling the number out of the $device variable to figure out what
port just attached. After some messing around (I tried to match the device
and serial variables) I gave up and just made two entries per printer: one
for ulpt0 and one for ulpt1 (see below).
Just because I'm a pain, how does this work if you have two printers from
the same vendor? Epson's product code 0x0009, for example, means "high
speed usb 2.0 printer". So I'm guessing, really, that any epson printer
would match?
Thx,
Scott
Here's the final working version for the archives:
attach 20 {
device-name "ulpt0";
match "vendor" "0x04f9"; # Brother
match "product" "0x0033"; # HL-2140
action "ln -s /dev/$device-name /dev/ulpt-brother";
action "ln -s /dev/unlpt0 /dev/unlpt-brother";
};
attach 20 {
device-name "ulpt1";
match "vendor" "0x04f9"; # Brother
match "product" "0x0033"; # HL-2140
action "ln -s /dev/$device-name /dev/ulpt-brother";
action "ln -s /dev/unlpt1 /dev/unlpt-brother";
};
detach 20 {
device-name "ulpt[0-9]";
match "vendor" "0x04f9"; # Brother
match "product" "0x0033"; # HL-2140
action "rm -f /dev/ulpt-brother";
action "rm -f /dev/unlpt-brother";
};
# ---
attach 20 {
device-name "ulpt0";
match "vendor" "0x04b8"; # Epson
match "product" "0x0007"; # Photostylus R800
action "ln -s /dev/$device-name /dev/ulpt-epson";
action "ln -s /dev/unlpt0 /dev/unlpt-epson";
};
attach 20 {
device-name "ulpt1";
match "vendor" "0x04b8"; # Epson
match "product" "0x0007"; # Photostylus R800
action "ln -s /dev/$device-name /dev/ulpt-epson";
action "ln -s /dev/unlpt1 /dev/unlpt-epson";
};
detach 20 {
device-name "ulpt[0-9]";
match "vendor" "0x04b8"; # Epson
match "product" "0x0007"; # Photostylus R800
action "rm -f /dev/ulpt-epson";
action "rm -f /dev/unlpt-epson";
};
On Sat, Jun 4, 2011 at 3:19 PM, Warren Block wrote:
> On Sat, 4 Jun 2011, Scott Gasch wrote:
>
> Hi,
>>
>> I have two usb printers on my freebsd machine and I'm using cups. One of
>> the things I've done is publish a raw (no driver) printer for each of them
>> and use that to share them with other machines in the house that have
>> drivers.
>>
>> My problem is that every once in a while, when I boot up, the order of the
>> printers on the usb ports seems to change. For example, right now I've
>> got:
>>
>> Jun 4 11:24:34 foo kernel: ulpt0: > 2.00/1.00, addr 2> on uhub1
>> Jun 4 11:24:34 foo kernel: ulpt0: using bi-directional mode
>> Jun 4 11:28:13 foo kernel: ulpt1: > 0/0, rev 2.00/1.00, addr 2> on uhub7
>>
>>
>> But when I lost power the other night the machine came up with them
>> reversed
>> -- the brother on ulpt1 and the epson on ulpt0.
>>
>> As far as I can tell, cups printers.conf ties to a particular port. So,
>> you
>> can probably see where this is going... when they bind in the wrong order
>> and someone prints I get a ton of crap printed out and waste a ton of
>> paper.
>> How can I make it so that a particular printer binds to a particular usb
>> port deterministically?
>>
>
> devd.conf. But I don't think there's any control over ulpt. Instead,
> maybe create links so /dev/ulpt-hl2140 and /dev/ulpt-epson12 are linked to
> the right devices, and use those where static devices are needed.
> Untested...
>
> attach 20 {
>device-name "ulpt[0-9]";
>match "vendor" "0x1234"; # Brother
>match "product" "0x4321"; # HL-2140
>action "ln -s /dev/$device-name /dev/ulpt-hl2140";
> };
>
> detach 20 {
>device-name "ulpt[0-9]";
>match "vendor" "0x1234"; # Brother
>match "product" "0x4321"; # HL-2140
>action "rm /dev/ulpt-hl2140";
> };
>
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Usb printers take the same port deterministically?
Hi, I have two usb printers on my freebsd machine and I'm using cups. One of the things I've done is publish a raw (no driver) printer for each of them and use that to share them with other machines in the house that have drivers. My problem is that every once in a while, when I boot up, the order of the printers on the usb ports seems to change. For example, right now I've got: Jun 4 11:24:34 foo kernel: ulpt0: on uhub1 Jun 4 11:24:34 foo kernel: ulpt0: using bi-directional mode Jun 4 11:28:13 foo kernel: ulpt1: on uhub7 But when I lost power the other night the machine came up with them reversed -- the brother on ulpt1 and the epson on ulpt0. As far as I can tell, cups printers.conf ties to a particular port. So, you can probably see where this is going... when they bind in the wrong order and someone prints I get a ton of crap printed out and waste a ton of paper. How can I make it so that a particular printer binds to a particular usb port deterministically? Thx, Scott ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: irq19 interrupt storm?
You're right: atapci1, atapci2, fwohci0 and uhci4 are all sharing the same irq (19) while irqs 20, 21, 22 at least seem completely unused. Here's a dumb question: how do I fix it? I tried setting "plug and play OS" in the BIOS and then using device.hints to push different devices to different irqs. But every time I tried a new hint it seemed to be ignored. I was trying stuff like: set hint.atapci.1.irq="20" set hint ata.4.irq="20" (ata4 is a channel on atapci1) set hint fwhco.0.irq="20" etc... I also tried to move the dc driver to a new irq as a test. This was also seemingly ignored. I then tried turning "plug and play OS" off in the BIOS but I don't see anywhere to set the IRQs of the onboard SATA controllers via the menus. I'm looking for a BIOS upgrade now... any other advice? Thx, Scott On Tue, Sep 16, 2008 at 7:12 AM, Gary Jennejohn <[EMAIL PROTECTED]>wrote: > On Mon, 15 Sep 2008 22:57:38 -0700 > "Scott Gasch" <[EMAIL PROTECTED]> wrote: > > > Hi, > > > > I'm running freebsd 7.0-RELEASE-p4 on a 4-core amd64 box. Nearly 100% of > > 1 cpu is constantly being used handling irq19: uhci4 interrupts. This > > seems to happen both with and without any USB devices plugged in: > > > > vmstat -i > > interrupt total rate > > irq1: atkbd0 5 0 > > irq6: fdc0 1 0 > > irq17: mskc0 dc0 1180547 18 > > irq18: skc0 uhci2* 163250699 2512 > > irq19: uhci4++ 3187989508 49072 > > I think the ++ here indicates that two or more devices are sharing this > interrupt. Try doing "grep irq.*19 /var/run/dmesg.boot" to see which > ones. One of these devices could be the culprit. > > --- > Gary Jennejohn > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: irq19 uhci interrupts taking ~100% of one core?
Replying to my own question with more data. Previously I had been running my own kernel; I was curious if the problem would reproduce with a GENERIC kernel. It does but the symptoms are slightly different. The same irq is firing too often and consuming nearly all of one core. But the driver that is associated with the interrupt is different -- it's fwohci0: interrupt total rate irq6: fdc0 1 0 irq17: mskc0 dc0 313242 13 irq18: skc0 uhci2* 124475451 5540 irq19: fwohci0+++ 957875379 42638 irq23: uhci3 ehci1 1145 0 cpu0: timer 44458513 1979 cpu1: timer 8875 1978 cpu3: timer 43393901 1931 cpu2: timer 43393921 1931 Total 1258360428 56014 This makes me start to wonder if this is not a problem with irq19 (the PIC?) and not one particular device / driver. I'm not sure how to make dig deeper here, any help greatly appreciated. Thx, Scott On Sun, Sep 7, 2008 at 4:07 PM, Scott Gasch <[EMAIL PROTECTED]> wrote: > Hi, > I'm running freebsd 7.0-RELEASE-p4 on a 4-core amd64 box. nearly 100% of 1 > cpu is constantly being used handling irq19: uhci4 interrupts. This seems > to happen both with and without any USB devices plugged in: > > vmstat -i > interrupt total rate > irq1: atkbd0 5 0 > irq6: fdc0 1 0 > irq17: mskc0 dc0 1180547 18 > irq18: skc0 uhci2* 163250699 2512 > irq19: uhci4++3187989508 49072 > irq23: uhci3 ehci131 0 > cpu0: timer129208570 1988 > cpu1: timer129208457 1988 > cpu2: timer125750147 1935 > cpu3: timer125750122 1935 > Total 3862338087 59452 > > dmesg > uhci4: port 0xa400-0xa41f irq 19 at device > 29.1 > on pci0 > uhci4: [GIANT-LOCKED] > uhci4: [ITHREAD] > > Any idea what's going on here and/or how to fix this? > > Thx, > Scott > > ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
irq19 uhci interrupts taking ~100% of one core?
Hi, I'm running freebsd 7.0-RELEASE-p4 on a 4-core amd64 box. nearly 100% of 1 cpu is constantly being used handling irq19: uhci4 interrupts. This seems to happen both with and without any USB devices plugged in: vmstat -i interrupt total rate irq1: atkbd0 5 0 irq6: fdc0 1 0 irq17: mskc0 dc0 1180547 18 irq18: skc0 uhci2* 163250699 2512 irq19: uhci4++3187989508 49072 irq23: uhci3 ehci131 0 cpu0: timer129208570 1988 cpu1: timer129208457 1988 cpu2: timer125750147 1935 cpu3: timer125750122 1935 Total 3862338087 59452 dmesg uhci4: port 0xa400-0xa41f irq 19 at device 29.1 on pci0 uhci4: [GIANT-LOCKED] uhci4: [ITHREAD] Any idea what's going on here and/or how to fix this? Thx, Scott ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
squeezecenter hangs kernel on sigterm
Hi, I have a problem with the squeezecenter port -- when I stop it (via /usr/local/etc/rc.d/squeezecenter stop or via system shutdown or via kill -9 pid) it hangs the machine instantly, every time. There is nothing in the system or all log about what happened. I'm running FreeBSD wannabe.guru.org6.2-RELEASE-p11 FreeBSD 6.2-RELEASE-p11. Has anyone ever seen this before and / or have any advice short of hooking up a kernel debugger? If a kernel debugger is the next step, can someone point me at a good guide? Thx, Scott ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: re driver in 5.3?
FYI: this issue is "solved". I applied this patch (URL below) to the 5.3sources and built a kernel with an re driver that can detect the card. It seems to be working at gigabit speeds. Out of curiosity would someone who knows CVS better than I do kindly tell me what version of FreeBSD this patch has been integrated to? http://lists.freebsd.org/pipermail/freebsd-current/2005-October/056317.html Thx, Scott On 11/27/06, Scott Gasch <[EMAIL PROTECTED]> wrote: Hi, I'm trying to get a linksys eg1032 gigabit ethernet card (version 3) working under freebsd 5.3. This appears to be an RTL8169S based card. When I build a kernel with the re device (and miibus) enabled, the card is not detected. I also tried building a GENERIC kernel to sanity check my config -- the card is not detected with the GENERIC kernel either. I verified that the if_re.c file is being compiled / included in the kernel. The LINT config for 5.3 _does_not_ include "device re" which I find strange. The man page for re says it was introduced in 5.2 so I think it should be here? I tried disabling ACPI support in the loader menu but this did not result in the detection of the card. I tried booting a 6.1 kernel on the machine and it _does_ detect the device. Is this likely due to driver code differences or something else in the 6.x kernels? I'd rather not upgrade this box to 6.x yet but I could certainly bring it up to 5.5. Thx, Scott ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
re driver in 5.3?
Hi, I'm trying to get a linksys eg1032 gigabit ethernet card (version 3) working under freebsd 5.3. This appears to be an RTL8169S based card. When I build a kernel with the re device (and miibus) enabled, the card is not detected. I also tried building a GENERIC kernel to sanity check my config -- the card is not detected with the GENERIC kernel either. I verified that the if_re.c file is being compiled / included in the kernel. The LINT config for 5.3 _does_not_ include "device re" which I find strange. The man page for re says it was introduced in 5.2 so I think it should be here? I tried disabling ACPI support in the loader menu but this did not result in the detection of the card. I tried booting a 6.1 kernel on the machine and it _does_ detect the device. Is this likely due to driver code differences or something else in the 6.x kernels? I'd rather not upgrade this box to 6.x yet but I could certainly bring it up to 5.5. Thx, Scott ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
