On Wednesday, October 12, 2011 05:18:31 PM gene heskett did opine: > On Wednesday, October 12, 2011 04:33:53 PM Alan Stern did opine: > > On Wed, 12 Oct 2011, gene heskett wrote: > > > Greetings; > > > > > > to be able to redirect an assembly listing created by an assembler, > > > to /dev /usblp3 > > > > > > This command line fails: > > > [gene@coyote Download]$ mamou -l dcheckmine.asm 2>&1 >/dev/usblp3 > > > bash: /dev/usblp3: Permission denied > > > > Instead of redirecting the output to /dev/usblp3, pipe it to lpr with > > the appropriate -P argument. See "man lpr". > > > > > Running as the un-priviledged user gene. > > > > > > And yet this printer is usable through cupsd by me after unplugging > > > and replugging the parent usb hub AND restarting cups. It was > > > present on the system and powered up at the last reboot, but not > > > discovered. > > > > > > Much of this could be prevented if this printer, at least 3 hubs > > > away from a motherboard usb port because of its physical location > > > on another desk in the basement, was discovered at bootup time. > > > However, in order for udevs discovery to work, I am finding that > > > after a reboot I must disconnect the motherboard port to hub cable, > > > wait a few seconds, and then reconnect it, at which time the > > > discovery works normally. > > > > > > So, 2 questions really, why can't I (a normal user) use it, and why > > > is it not properly discovered at bootup? > > > > I think normal users aren't supposed to be able to access printers > > directly. They're supposed to use programs in the cups package (like > > lpr) for printing. This may vary according to your distribution. > > This does not always work if the usb tree has been re-discovered due to > a disconnect after boot even if it finds it when reconnected. What I > need is for lpr to be able to use the BROTHE2140 printer at any time it > is plugged in, even if the parent hub has been disconnected for 5 > seconds every hour on the hour since the last reboot 3 weeks ago. > > > Discovery at bootup _ought_ to work. To find out why not, the best > > approach is to build a kernel with CONFIG_USB_DEBUG enabled and post > > the resulting boot-up dmesg log. For comparison, also post a log > > showing what happens when the hub cable is reconnected after boot-up > > (using the same kernel). > > Build in progress, using the .config that built this 2.6.38.8-bfs-pae > kernel with CONFIG_USB_DEBUG now set. But using my "makeit" script > which keeps a backup copy of the kernel it is replacing. > > > Alan Stern > > Thanks Alan, I should be back with a couple dmesgs in a few hours. > > Cheers, Gene Looks like not, my 'makeit' script reported a couple of coding errors in the make bzImage section: drivers/pnp/isapnp/core.c: In function ‘isapnp_init’: drivers/pnp/isapnp/core.c:1107:1: warning: no return statement in function returning non-void MODPOST vmlinux.o WARNING: modpost: Found 1 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' Then make modules: There were 29 section miss-matches while making modules, and the usual mewling about oversized frame & undefined/un-inited stuff. And then took an exit while doing a make headers_install: CHK include/linux/version.h HOSTCC scripts/unifdef INSTALL include/asm-generic (34 files) INSTALL include/drm (14 files) /usr/src/linux-2.6.38.8-pclos3-bfs-pae/include/linux/Kbuild:25: *** commands commence before first target. Stop. make[1]: *** [linux] Error 2 make: *** [headers_install] Error 2 I can take that out of my script with a couple # signs and re-run it as it has not attempted to install anything yet. But that takes about an hour these days, even using ccache which I supposedly am. Ridiculous for a make -J3 on a quad core 2.2 Ghz phenom IMO. Every new gcc we get runs at 50% of the older versions speed. Results eventually Alan, & thanks for your patience. ;-) Cheers, Gene -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) I will make you shorter by the head. -- Elizabeth I -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
