Re: uscanner problem with HP Scanjet 3400C
Original Message Subject: Re: uscanner problem with HP Scanjet 3400C Date: Sat, 22 Jan 2005 12:32:25 + From: Chris Hodgins <[EMAIL PROTECTED]> To: Chris Hodgins <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Chris Hodgins wrote: Hi, I am trying to get my HP ScanJet 3400C scanner to work with FreeBSD 5.3. Whenever I plug it into the usb port on my laptop I get in dmesg: uscanner0: Hewlett Packard ScanJet 3400cse, rev 1.00/0.00, addr 2 uscanner0: setting config no failed device_attach: uscanner0 attach returned 6 uhub0: port 1, set config at addr 2 failed uhub0: device problem, disabling port 1 Naturally after that sane can't find it. This is a device that is fully supported now with Sane and one that uscanner claims to support. I am happy to do any testing required to get this to work. This problem seems to have been around for a while now and I have found a few unanswered threads about it on google. Thanks for your help. Chris Hodgins # uname -a FreeBSD paranoia 5.3-RELEASE FreeBSD 5.3-RELEASE #1: Fri Dec 3 18:15:16 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/paranoia i386 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" I just recompiled my kernel to include uscanner support and USB_DEBUG. [EMAIL PROTECTED]:/usr/src/sys/i386/conf$ diff -u paranoia paranoia_usb_debug --- paranoiaSat Oct 30 18:33:02 2004 +++ paranoia_usb_debug Sat Jan 22 12:08:02 2005 @@ -108,3 +108,6 @@ device ukbd# Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse +device uscanner + +optionsUSB_DEBUG I was expecting a lot more output in dmesg about my problem but only one extra line appeared: uscanner0: Hewlett Packard ScanJet 3400cse, rev 1.00/0.00, addr 2 uscanner0: setting config no failed device_attach: uscanner0 attach returned 6 uhub_explore: usb_new_device failed, error=STALLED uhub0: device problem, disabling port 2 Have I done something wrong in getting the USB_DEBUG option into my kernel? Should I just of ran this instead? : # make -DUSB_DEBUG -KERNCONF=paranoia buildkernel Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: uscanner problem with HP Scanjet 3400C
Chris Hodgins wrote: Original Message Subject: Re: uscanner problem with HP Scanjet 3400C Date: Sat, 22 Jan 2005 12:32:25 + From: Chris Hodgins <[EMAIL PROTECTED]> To: Chris Hodgins <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> Chris Hodgins wrote: Hi, I am trying to get my HP ScanJet 3400C scanner to work with FreeBSD 5.3. Whenever I plug it into the usb port on my laptop I get in dmesg: uscanner0: Hewlett Packard ScanJet 3400cse, rev 1.00/0.00, addr 2 uscanner0: setting config no failed device_attach: uscanner0 attach returned 6 uhub0: port 1, set config at addr 2 failed uhub0: device problem, disabling port 1 Naturally after that sane can't find it. This is a device that is fully supported now with Sane and one that uscanner claims to support. I am happy to do any testing required to get this to work. This problem seems to have been around for a while now and I have found a few unanswered threads about it on google. Thanks for your help. Chris Hodgins # uname -a FreeBSD paranoia 5.3-RELEASE FreeBSD 5.3-RELEASE #1: Fri Dec 3 18:15:16 GMT 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/paranoia i386 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]" I just recompiled my kernel to include uscanner support and USB_DEBUG. [EMAIL PROTECTED]:/usr/src/sys/i386/conf$ diff -u paranoia paranoia_usb_debug --- paranoiaSat Oct 30 18:33:02 2004 +++ paranoia_usb_debug Sat Jan 22 12:08:02 2005 @@ -108,3 +108,6 @@ device ukbd# Keyboard device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse +device uscanner + +optionsUSB_DEBUG I was expecting a lot more output in dmesg about my problem but only one extra line appeared: uscanner0: Hewlett Packard ScanJet 3400cse, rev 1.00/0.00, addr 2 uscanner0: setting config no failed device_attach: uscanner0 attach returned 6 uhub_explore: usb_new_device failed, error=STALLED uhub0: device problem, disabling port 2 Have I done something wrong in getting the USB_DEBUG option into my kernel? Should I just of ran this instead? : # make -DUSB_DEBUG -KERNCONF=paranoia buildkernel Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" Finally worked out what was going wrong. You need to set both the USB_DEBUG option on in your kernel and set the sysctl hw.usb.debug to 6. Anyway I now have some pretty good output and have traced the code and am pretty certain of what is happening now. How to fix itI have no idea! Here is the dmesg out from the time I plugge my scanner into my laptop: usbd_alloc_xfer() = 0xc1951a00 usbd_transfer: xfer=0xc1951a00, flags=6, pipe=0xc239c900, running=0 usbd_dump_queue: pipe=0xc239c900 usb_allocmem: use frag=0xc19d9e80 size=15 usb_insert_transfer: pipe=0xc239c900 running=0 timeout=5000 usb_add_task: task=0xc1951a84 usb_task_thread: woke up task=0xc1951a84 usb_transfer_complete: pipe=0xc239c900 xfer=0xc1951a00 status=15 actlen=0 usb_freemem: frag=0xc19d9e80 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc239c900, xfer=0 usbd_free_xfer: 0xc1951a00 usbd_alloc_xfer() = 0xc1951a00 usbd_transfer: xfer=0xc1951a00, flags=6, pipe=0xc239c900, running=0 usbd_dump_queue: pipe=0xc239c900 usb_allocmem: use frag=0xc19d9e80 size=2 usb_insert_transfer: pipe=0xc239c900 running=0 timeout=5000 usb_add_task: task=0xc1951a84 usb_task_thread: woke up task=0xc1951a84 usb_transfer_complete: pipe=0xc239c900 xfer=0xc1951a00 status=15 actlen=0 usb_freemem: frag=0xc19d9e80 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc239c900, xfer=0 usbd_free_xfer: 0xc1951a00 uscanner1: Hewlett Packard ScanJet 3400cse, rev 1.00/0.00, addr 2 usbd_set_config_no: 1 usbd_get_config_desc: confidx=0 usbd_get_desc: type=2, index=0, len=9 usbd_alloc_xfer() = 0xc1951a00 usbd_transfer: xfer=0xc1951a00, flags=2, pipe=0xc239c900, running=0 usbd_dump_queue: pipe=0xc239c900 usb_allocmem: use frag=0xc19d9e80 size=9 usb_insert_transfer: pipe=0xc239c900 running=0 timeout=5000 At this point is hangs for I am guessing exactly 5000ms. usb_transfer_complete: pipe=0xc239c900 xfer=0xc1951a00 status=17 actlen=0 status 17 above is USBD_STALLED. So I am guessing that the scanner is not responding at this point...although it seemed to respond above..no? Can anyone point me at least in the right direction to fixing this. Is it a hardware or a software problem? If it is fixable and I can somehow manage to fix it, I will post my patch here. Thanks Chris PS: Just added the rest of the usb dmesg output below for good measure. usb_freemem: frag=0xc19d9e80 usb_transfer_complete
Re: Idea about 'skeleton jail
Denis Shaposhnikov wrote: "Frank" == Frank Knobbe <[EMAIL PROTECTED]> writes: Frank> If you nullfs these directories, you loose the ability to Frank> prune the jail. Pruning is part of system hardening. I'd May be it's better to use unionfs, so anybody can replace binaries with their stub version pre jail. This might be a very stupid idea but how about a jailfs. Now I don't know all that much about filesystem design so bear with me. How about something like this: # ls /usr/jail fulljail smalljail fulljail.conf smalljail.conf # cd /usr/jail/fulljail # ls dev etc home # cat ../fulljail.conf allow-all read-only ignore /dev /etc /usr/home allow read-write /usr/ports/distfiles # cd ../smalljail # ls # cat ../smalljail.conf ignore-all allow read-only /bin /usr/bin allow read-write /usr/home # cd /usr/jail # jail /usr/jail/fulljail fulljail 127.0.0.1 /bin/sh /etc/rc # jexec 1 ls COPYRIGHT boot compat dist etc lib mnt rescue sbin sys usr bin cdrom dev entropy home libexec proc root stand tmp var # jail /usr/jail/smalljail smalljail 127.0.0.1 /bin/sh /home/myhome/specialtask.sh # jexec 2 ls bin usr home # SO the jail filesystem is configured at jail-creation time and uses the hosts files or jail files depending on the configuration. Might have to pass the config file into the jail command. As I said I am not an expert. Mabye one of the experts could let me know what they think? Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea about 'skeleton jail
Samuel J. Greear wrote: Not a bad 'idea' at all, although I won't comment on semantics. I had something implemented using fs stacking (in a very hackish way, and I believe it's lost now, so don't ask to see it...) to implement per-jail quota's that seemed to work quite well. Sam Feel free to comment on the semantics. As I said before, I am not very knowledgable about filesystems and any insight or alternative implementation you can provide would be interesting I'm sure to everyone. Chris This might be a very stupid idea but how about a jailfs. Now I don't know all that much about filesystem design so bear with me. How about something like this: SO the jail filesystem is configured at jail-creation time and uses the hosts files or jail files depending on the configuration. Might have to pass the config file into the jail command. As I said I am not an expert. Mabye one of the experts could let me know what they think? Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea about 'skeleton jail
Anish Mistry wrote: On Sunday 13 March 2005 01:23 pm, Chris Hodgins wrote: Samuel J. Greear wrote: Not a bad 'idea' at all, although I won't comment on semantics. I had something implemented using fs stacking (in a very hackish way, and I believe it's lost now, so don't ask to see it...) to implement per-jail quota's that seemed to work quite well. Sam Feel free to comment on the semantics. As I said before, I am not very knowledgable about filesystems and any insight or alternative implementation you can provide would be interesting I'm sure to everyone. Yeah, if there was jailfs that was setup automatically for the jails that supported quotas out of the box that would kill my major gripe about setting up jails. Any ideas the sort of work involved in something like this? I am graduating soon and about to have about a month of free time to spend on a project. From the very little I know about file systems on Unix they just stack together right? So there would have to be something to process the configuration file and then is it just a matter of overriding each vnode operation or is there more to it than that? Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea about 'skeleton jail
Anish Mistry wrote: On Monday 14 March 2005 10:15 am, Samuel J. Greear wrote: On Sunday 13 March 2005 14:24, Anish Mistry wrote: On Sunday 13 March 2005 01:23 pm, Chris Hodgins wrote: Samuel J. Greear wrote: Not a bad 'idea' at all, although I won't comment on semantics. I had something implemented using fs stacking (in a very hackish way, and I believe it's lost now, so don't ask to see it...) to implement per-jail quota's that seemed to work quite well. Sam Feel free to comment on the semantics. As I said before, I am not very knowledgable about filesystems and any insight or alternative implementation you can provide would be interesting I'm sure to everyone. Yeah, if there was jailfs that was setup automatically for the jails that supported quotas out of the box that would kill my major gripe about setting up jails. Chris, your concept looks reasonable to me. I think I would probably do something along those lines but borrow some idea's from my 'jail-build' script. It has the concept of both includes and excludes, but it also handles another directory for what I call overrides. My overrides directories are per-jail and typically include nothing more than config. files, but it works pretty handily. The overrides may best be implemented in a seperate layer... and I don't even know that I would call something like this a jailfs, more like a globfs or something... I can see potential uses beyond jails. I like the idea of the overrides directory. That would work nicely. If you made the overrides directory the actual jail root that might make sense. Then when the [jail|glob]fs is mounted it will simply choose the file in the jail root directory instead of the one on the normal file system. If we implemented a sort of copy of write architecture we could add to the exceptions list on the fly. That is everything from the host (everything allowed by the config file that is) is available as a copy of the host system. When you edit a file, the filesystem simply creates its own copy for the overrides directory and we edit that. That would be very neat. Imagine that working on the ports system!! :) What do you think? The reasons that I never finished implementing my jailfs with quota support were primarily, that stackable filesystems seem to be somewhat of a black-art. Secondarily, I concluded that the time would be better spent implementing filesystem agnostic quota's in the vfs layer. A proper design should enable you to do a lot of fun things, I was thinking something along the lines of just a simple aggregator that a module could hand function pointers to and register interest in events, with options like.. just-notify-me and dont-continue-without-my-approval. Throw in some helpers for synchronizing module state to disk. The kernel side of this shouldn't really be very hard, but all of the userland quota utilities would need to be rewritten as they are tied to UFS at the block level. This all from about 3 years ago, and I haven't implemented any of it. I rock! Sounds, very interesting. Sam Would you be able to write up some design specs for getting all this done? This might be a prime example of something to try to get funding for development. I would be willing to donate some time to work on designing and building this. Especially if working with someone who knows a lot more about filesystems than me. :) Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea about 'skeleton jail
Anish Mistry wrote: On Monday 14 March 2005 10:15 am, Samuel J. Greear wrote: On Sunday 13 March 2005 14:24, Anish Mistry wrote: On Sunday 13 March 2005 01:23 pm, Chris Hodgins wrote: Samuel J. Greear wrote: Not a bad 'idea' at all, although I won't comment on semantics. I had something implemented using fs stacking (in a very hackish way, and I believe it's lost now, so don't ask to see it...) to implement per-jail quota's that seemed to work quite well. Sam Feel free to comment on the semantics. As I said before, I am not very knowledgable about filesystems and any insight or alternative implementation you can provide would be interesting I'm sure to everyone. Yeah, if there was jailfs that was setup automatically for the jails that supported quotas out of the box that would kill my major gripe about setting up jails. Chris, your concept looks reasonable to me. I think I would probably do something along those lines but borrow some idea's from my 'jail-build' script. It has the concept of both includes and excludes, but it also handles another directory for what I call overrides. My overrides directories are per-jail and typically include nothing more than config. files, but it works pretty handily. The overrides may best be implemented in a seperate layer... and I don't even know that I would call something like this a jailfs, more like a globfs or something... I can see potential uses beyond jails. The reasons that I never finished implementing my jailfs with quota support were primarily, that stackable filesystems seem to be somewhat of a black-art. Secondarily, I concluded that the time would be better spent implementing filesystem agnostic quota's in the vfs layer. A proper design should enable you to do a lot of fun things, I was thinking something along the lines of just a simple aggregator that a module could hand function pointers to and register interest in events, with options like.. just-notify-me and dont-continue-without-my-approval. Throw in some helpers for synchronizing module state to disk. The kernel side of this shouldn't really be very hard, but all of the userland quota utilities would need to be rewritten as they are tied to UFS at the block level. This all from about 3 years ago, and I haven't implemented any of it. I rock! Sam Would you be able to write up some design specs for getting all this done? This might be a prime example of something to try to get funding for development. I seem to have stopped receiving mail from the mailing lists. Would it be possible for someone to forward any replies on this thread for the last few hours to [EMAIL PROTECTED] If it would be possible for any further emails to be cc'd there as well that would be brilliant. :) Thanks Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea about 'skeleton jail
Not sure if this has already made it to the mailing list or not. My uni email account has started blocking email inbound and outbound to the freebsd servers. If I have missed anything since the post I am replying to I would appreciate if it could be forwarded on to me at this address...thanks :) A few more comments below. :) Anish Mistry wrote: > On Monday 14 March 2005 10:15 am, Samuel J. Greear wrote: > >>On Sunday 13 March 2005 14:24, Anish Mistry wrote: >> >>>On Sunday 13 March 2005 01:23 pm, Chris Hodgins wrote: >>> >>>>Samuel J. Greear wrote: >>>> >>>>>Not a bad 'idea' at all, although I won't comment on >>>>>semantics. I had something implemented using fs stacking (in >>>>>a very hackish way, and I believe it's lost now, so don't ask >>>>>to see it...) to implement per-jail quota's that seemed to >>>>>work quite well. >>>>> >>>>>Sam >>>> >>>>Feel free to comment on the semantics. As I said before, I am >>>>not very knowledgable about filesystems and any insight or >>>>alternative implementation you can provide would be interesting >>>>I'm sure to everyone. >>> >>>Yeah, if there was jailfs that was setup automatically for the >>>jails that supported quotas out of the box that would kill my >>>major gripe about setting up jails. >> >>Chris, your concept looks reasonable to me. I think I would >>probably do something along those lines but borrow some idea's from >>my 'jail-build' script. It has the concept of both includes and >>excludes, but it also handles another directory for what I call >>overrides. My overrides directories are per-jail and typically >>include nothing more than config. files, but it works pretty >>handily. The overrides may best be implemented in a seperate >>layer... and I don't even know that I would call something like >>this a jailfs, more like a globfs or something... I can see >>potential uses beyond jails. >> I like the idea of the overrides directory. That would work nicely. If you made the overrides directory the actual jail root that might make sense. Then when the [jail|glob]fs is mounted it will simply choose the file in the jail root directory instead of the one on the normal file system. If we implemented a sort of copy of write architecture we could add to the exceptions list on the fly. That is everything from the host (everything allowed by the config file that is) is available as a copy of the host system. When you edit a file, the filesystem simply creates its own copy for the overrides directory and we edit that. That would be very neat. Imagine that working on the ports system!! :) What do you think? >>The reasons that I never finished implementing my jailfs with quota >>support were primarily, that stackable filesystems seem to be >>somewhat of a black-art. Secondarily, I concluded that the time >>would be better spent implementing filesystem agnostic quota's in >>the vfs layer. A proper design should enable you to do a lot of >>fun things, I was thinking something along the lines of just a >>simple aggregator that a module could hand function pointers to and >>register interest in events, with options like.. just-notify-me >>and dont-continue-without-my-approval. Throw in some helpers for >>synchronizing module state to disk. The kernel side of this >>shouldn't really be very hard, but all of the userland quota >>utilities would need to be rewritten as they are tied to UFS at the >>block level. This all from about 3 years ago, and I haven't >>implemented any of it. I rock! Sounds, very interesting. >> >>Sam > > Would you be able to write up some design specs for getting all this > done? This might be a prime example of something to try to get > funding for development. > I would be willing to donate some time to work on designing and building this. Especially if working with someone who knows a lot more about filesystems than me. :) Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: security or lack thereof
On Thu, 24 Mar 2005 12:48:48 -0700 (MST), M. Warner Losh <[EMAIL PROTECTED]> wrote: > In message: <[EMAIL PROTECTED]> > [EMAIL PROTECTED] (John Nemeth) writes: > : So, is it FreeBSD policy to ignore security bug reports? I sent > : the following bug report to [EMAIL PROTECTED] on Feb. 19th, 2005 and > : it still hasn't been acted on. This total lack of action on an > : extremely simple (and silly) three year old bug doesn't give one the > : warm fuzzies. Heck, it took 48 hours to get a response from a security > : officer, and another 24 hours to get something from the guilty > : developer. > > You should learn to send it to the right place: > [EMAIL PROTECTED] > > Warner He did send it to the correct place. Otherwise the documentation is wrong: ---from http://www.freebsd.org/security/index.html--- All FreeBSD Security issues should be reported directly to the Security Officer Team ([EMAIL PROTECTED]) personally or otherwise to the Security Officer ([EMAIL PROTECTED]). --- Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
