Re: USB scanner unrecognized on 1.11-DEVELOPMENT
On Tue, Jan 15, 2008 at 11:06:21AM +0100, Matthias Schmidt wrote:
* Francois Tigeot wrote:
I recently upgraded a machine from Dragonfly 1.10.1 to a recent
1.11.0-DEVELOPMENT (as of today).
An Epson Perfection 1240U USB scanner which worked fine with 1.10.1 is now
unrecognized. Pluging and unpluging the USB cord doesn't result in any
kernel message visible in dmesg.
According to the sources we have an entry for your model:
{{ USB_DEVICE(0x04b8, 0x010b) }, 0 }, /* Perfection 1240U/1240Photo */
I'm currently preparing a mass update of USB quirks and it seems like
the vendor ID of Epson has changed. The new entry from FreeBSD device
ID list looks like this:
{{ USB_DEVICE(0x03f8, 0x010b) }, 0 }, /* Epson Perfection 1240U / */
Note the difference between 0x04b8 and 0x03f8. To check that I'm not
wrong, you could change the ID in the uscanner source, recompile the
module, reload it and check again if the scanner is detected:
I tried it and it didn't change anything: no kernel messages either.
However, I found out there's was a difference between a standalone
uscanner module and one compiled in the kernel.
Standalone module:
- original - nothing
- patched - nothing
Uscanner in kernel:
- original - some kernel messages appear at startup
# dmesg | grep uscanner
uscanner0: EPSON Perfection1240, class 255/255, rev 1.00/1.04, addr 2
on uhub0
uscanner0: at uhub0 port 2 (addr 2) disconnected
uscanner0: detached
- patched - some messages about ugen0
ugen0: at uhub0 port 2 (addr 2) disconnected
ugen0: detached
There's definitely something fishy going there.
--
Francois Tigeot
Re: USB scanner unrecognized on 1.11-DEVELOPMENT
On Wed, Jan 16, 2008 at 12:45:49PM +0200, Hasso Tepper wrote: Francois Tigeot wrote: However, I found out there's was a difference between a standalone uscanner module and one compiled in the kernel. Standalone module: - original - nothing - patched - nothing Note that loading module doesn't rescan devices. You have to unplug and plug again the device to rescanning happen. Ok. I'm not sure I did that with standalone modules. Uscanner in kernel: - original - some kernel messages appear at startup # dmesg | grep uscanner uscanner0: EPSON Perfection1240, class 255/255, rev 1.00/1.04, addr 2 on uhub0 uscanner0: at uhub0 port 2 (addr 2) disconnected uscanner0: detached It's a disconnect message only. - patched - some messages about ugen0 ugen0: at uhub0 port 2 (addr 2) disconnected ugen0: detached It's a disconnect message again only. And it shows that there is no need for patch. Show me the full dmesg with verbose booting, please. I have put a dmesg dump here (uscanner in kernel) : http://www.wolfpond.org/dmesg-dfly-1.11-verbose.txt I have disconnected and reconnected the scanner just after dumping this file. There were only this additional messages: uscanner0: at uhub0 port 2 (addr 2) disconnected uscanner: ops removed uscanner0: detached -- Francois Tigeot
USB scanner unrecognized on 1.11-DEVELOPMENT
Hi, I recently upgraded a machine from Dragonfly 1.10.1 to a recent 1.11.0-DEVELOPMENT (as of today). An Epson Perfection 1240U USB scanner which worked fine with 1.10.1 is now unrecognized. Pluging and unpluging the USB cord doesn't result in any kernel message visible in dmesg. I know the USB stuff has been heavily refactored since the last release. How can I proceed to debug this ? -- Francois Tigeot
Re: moused + modular xorg 'sticking' ?
On Wed, Nov 07, 2007 at 09:14:47PM -0500, Joe Talbott wrote: On Wed, Nov 07, 2007 at 07:25:48PM -0500, Chris Turner wrote: Hello all - fishing for similar experiences - has anyone had any problems with ps2 mice getting 'stuck' under X? just updated my 1.8 laptop to -HEAD before the Hammer work started + 2007Q3 Pkgsrc (modular-xorg-server-1.3.0) this seems to happen, but only when using sysmouse or perhaps even sysmouse with radeon.. I tried several variations of acpi/noacpi/sysmouse/psm/radeon/vesa and even reverted to the previous 1.24 psm.c, but it seems like only using the direct /dev/psm0 will work 100% with this particular combination since the upgrade.. or perhaps this is something in xorg (was previously on monolithic 2007Q1 build) In any case, since there's so many factors need to do more tests to zero in on this for sure, but thought I'd ask.. I had the same issue with sysmouse but my video is i810. This started when I switched to modular xorg. I haven't tried to use sysmouse lately so don't know if I'm seeing the same thing now. Next time I start Xorg it will be with sysmouse so I'll report here. I have had the same problem recently. I fixed it by downgrading x11/xf86-input-mouse. I am now using xf86-input-mouse-1.2.1 with sysmouse, and all is fine. -- Francois Tigeot
Re: pfstat-2.2
On Sun, Aug 26, 2007 at 07:02:51PM +0200, Gergo Szakal wrote: On Sun, 26 Aug 2007 17:34:42 +0200 Francois Tigeot [EMAIL PROTECTED] wrote: ioctl: DIOCIGETIFACES: Operation not supported by device pf_query: query_ifaces() failed The ioctl error is associated with /dev/pf. A quick grep in /usr/src showed DIOCIGETIFACES to be used in sys/net/pf/ so I'm not sure why this ioctl is not supported. Just mere guesses: * PF in DragonFly is old, pfstat has always been written to support *OpenBSD* (and it worked fine for me on OpenBSD :-D). How much older is the pf in DragonFly-1.10 compared to recent OpenBSD releases ? * There seem to be other issues reporting state info back to userland. After a pfctl -F all I can see no states with pfctl, moreover ftpsesame doesn't work. Hmmm. This doesn't bode well. -- Francois Tigeot
pfstat-2.2
Hi everyone, I have recently begun to use pfstat: http://www.benzedrine.cx/pfstat.html Since the version 1.7 in pkgsrc is a bit long in the tooth, I have updated it locally to version 2.2. It just needs some include files location adjustment to compile (patches available on request). Howewer, the resulting binary is not able to function correctly on DragonFly-1.10.1 : # pfstat -q ioctl: DIOCIGETIFACES: Operation not supported by device pf_query: query_ifaces() failed The ioctl error is associated with /dev/pf. A quick grep in /usr/src showed DIOCIGETIFACES to be used in sys/net/pf/ so I'm not sure why this ioctl is not supported. If some pf specialist could have a look, I would be very grateful. TIA, -- Francois Tigeot
Re: cvs commit: src/sys/dev/disk/fd fd.c fdc.h
On Mon, May 21, 2007 at 08:34:57PM -0400, Matt Emmerton wrote: Gergo Szakal wrote: On Mon, 21 May 2007 18:57:29 +0200 Erik Wikström [EMAIL PROTECTED] wrote: Isn't it about time to drop support for floppies soon? No, floppies are still great, especially on legacy hardware. Yeah indeed, but I would drop (E)ISA bus support and hardware that uses (E)ISA. I haven't seen anyone use it for a looong time. EISA is long dead and can go away ISA is still used on modern hardware -- anything without USB mouse/keyboard uses ISA under the covers, along with other stuff. And you can still buy modern machines with real ISA expansion slots. Core2 Duo PCs with ISA slots seem a bit weird, but they exist. -- Francois Tigeot
Re: KDE and OpenSSL = Broken
On Thu, Feb 22, 2007 at 01:21:54PM +0900, Kimura Fuyuki wrote: I still suspect lower layer. Why does the following last command result in error? It's just ok on NetBSD. test program: http://www.hadaly.org/fuyuki/dltest.c dialogue: $ cc ./dltest.c $ ./a.out $ cc ./dltest.c -lssl $ ./a.out $ a.out: Undefined symbol SSL_connect FWIW, it is the same type of error I have seen with wip/jdk14. Your code: h = dlopen(/usr/lib/libssl.so, RTLD_GLOBAL | RTLD_NOW); JDK code: libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); -- Francois Tigeot
Re: wip/jdk14: okay
On Thu, Feb 22, 2007 at 06:04:49PM +0100, Simon 'corecode' Schubert wrote: Gergo Szakal wrote: could you try -DEVEL and tell me whether it works? I am willing to test it, is it OK if I install KDE from binary, or do I have to compile? should be okay. just cd /usr/src/libexec/rtld-elf wmake wmake install DESTDIR=/ Well, this is not about KDE but with a DragonFly-1.8 system and the rtld patch, I am now able to build a working native jdk. Thank you so much Simon ! I'm happy now :-) And seriously, this should warrant a minor release. -- Francois Tigeot
Re: Native jdk build - success
On Wed, Feb 21, 2007 at 06:47:14AM +0800, Bill Hacker wrote: Francois Tigeot wrote: Today, I finally succeeded in building a native version of wip/jdk14. So, we have: 1.4.5 = success 1.6.2 = failure 1.8.0 = failure The error was also the same in all cases: Error: failed /usr/obj/pkgsrc/wip/jdk14/work/control/build/bsd-i586/lib/i386/client/libjvm.so, because Undefined symbol JNI_CreateJavaVM Sadly, I'm not sure I will be able to pinpoint what exactly has changed between 1.4 and 1.6 to cause this. 'pinpoint' may be the gcc ver libs installed by default at each of the above releases? The compiler in 1.4.5 and 1.6.2 is the same: $ gcc -v Using built-in specs. Configured with: DragonFly/i386 system compiler Thread model: posix gcc version 3.4.5 20050809 (prerelease) [DragonFly] (propolice, visibility) -- Francois Tigeot
Native jdk build - success
Hi, Today, I finally succeeded in building a native version of wip/jdk14. The big difference with my previous attempts was the DragonFly version: 1.4.5-RELEASE So, we have: 1.4.5 = success 1.6.2 = failure 1.8.0 = failure No matter what version of the pkgsrc system I used, the results were the same. The error was also the same in all cases: Error: failed /usr/obj/pkgsrc/wip/jdk14/work/control/build/bsd-i586/lib/i386/client/libjvm.so, because Undefined symbol JNI_CreateJavaVM Sadly, I'm not sure I will be able to pinpoint what exactly has changed between 1.4 and 1.6 to cause this. -- Francois Tigeot
Re: Native jdk doesn't build
On Tue, Feb 13, 2007 at 09:35:37AM +0200, Yury Tarasievich wrote: It was built on 1.4.4 system, and yes, I'm treasuring the binary package, as it still works. For how long yet, I wonder? BTW, I wasn't able to replicate this compiling feat on 1.6--1.7. On 1.4.4, I was able to exploit the similarity-with-freebsd aspect. Not anymore, and nothing was put in to substitute this, it seems. Thanks. For some reason, I thought the pkgsrc system did work at one time. I'll try to have a look at the differences with the ancient port system anyway; the absence of a native jdk has been bothering me for a while. -- Francois Tigeot
Re: Native jdk doesn't build
On Tue, Feb 13, 2007 at 10:33:36AM +0200, Yury Tarasievich wrote: The pkgsrc's scsl-jdk seems to take into consideration only netbsd host, how could it possibly work? I was referring to wip/jdk14. Some of the commit messages indicate some sort of DragonFly support: http://pkgsrc-wip.cvs.sourceforge.net/pkgsrc-wip/wip/jdk14/DESCR?view=log On 1.6.2-RELEASE, it mostly builds without warnings before dying with the undefined symbol error. For building, I modified fairly recent (then) freebsd port, not ancient (what did you mean by that?). For some reason, I thought your patches were specific to versions of the FreeBSD ports contemporary of DragonFly 1.4 and previous releases. I believe I've included those modifications in the binary attached to those message, too. I'll have a look. -- Francois Tigeot
Re: Native jdk doesn't build
On Sun, Feb 11, 2007 at 09:53:27AM +0100, Francois Tigeot wrote: I tried to build a native wip/jdk14. I used a one year old version of lang/sun-jdk14 as a bootstrap since recent version fail with an illegal system call error. The build failed after 2 hours with these error messages: Error: failed /usr/obj/pkgsrc/wip/jdk14/work/control/build/bsd-i586/lib/i386/client/libjvm.so, because Undefined symbol JNI_CreateJavaVM gmake[7]: *** [.compile.classlist] Error 6 [...] The same issue is reproductible on DragonFly 1.6.2-RELEASE. Does anyone remember when the last succesfull jdk build happened ? -- Francois Tigeot
Re: Native jdk build issue
On Mon, Feb 12, 2007 at 09:34:17PM +0100, Joerg Sonnenberger wrote: On Sun, Feb 11, 2007 at 09:53:27AM +0100, Francois Tigeot wrote: I used a one year old version of lang/sun-jdk14 as a bootstrap since recent version fail with an illegal system call error. This happens due to missing parts in linprocfs. Ok. The build failed after 2 hours with these error messages: I suspect issues with gmake-3.81, but haven't had time to trace it down. Well, this also happens with gmake-3.80nb5 (used on my DragonFly 1.6 build). I have traced the error to this file in the jdk14 source tree: j2se/src/solaris/bin/java_md.c and and to this line in particular: libjvm = dlopen(jvmpath, RTLD_NOW + RTLD_GLOBAL); The dlopen() call fails; jvmpath is /usr/obj/pkgsrc/wip/jdk14/work/control/build/bsd-i586/lib/i386/client/libjvm.so as in the first error message. -- Francois Tigeot
Re: IPv6 mtu autoconfiguration
On Tue, Oct 31, 2006 at 04:37:06PM +0100, Emiel Kollof wrote: Op maandag 30 oktober 2006 12:56, schreef Francois Tigeot: Hi all, I am experimenting with IPv6 on a small LAN. All machines use Dragonfly-1.6.x. The gateway uses a PPPoE ADSL modem, and so is unable to route packets 1492 bytes. You can sidestep the whole problem if you can get the modem to do bridging mode. This is also a way more reliable solution. I think that almost all *DSL providers support this. Have yet to come across one that doesn't. With bridging mode you can throw that shakey pppoe solution in the circular filing cabinet and use a plain dhcp client to get an IP, default gateway and whatever. Well, I'm afraid I can't do that and still have *IPv6* connectivity. My only sensible option is to use Dragonfly's user ppp client. Anyway, I have found a workaround with pf. I am just curious about the whole rtadvd client mtu stuff. -- Francois Tigeot
IPv6 mtu autoconfiguration
Hi all, I am experimenting with IPv6 on a small LAN. All machines use Dragonfly-1.6.x. The gateway uses a PPPoE ADSL modem, and so is unable to route packets 1492 bytes. With IPv4, TCP MSS is reduced automagically by ppp. Since there is no such trick for v6 tcp connections, I have tried to force a smaller IPv6 MTU on the client machines by setting up rtadvd with these options on the gateway: vr0:\ :mtu#1280: rtadvd runs fine, and I can the advertisements for a 1280 bytes MTU broadcast on the LAN. Client machines pick up their adresses and network mask correctly, but their MTU stays at the 1500 bytes ethernet default. Any TCP connection to a v6 connected host on the Internet thus fails. AFAIK, the only way I have found to reduce an interface MTU is by using ifconfig manually. Is this the intended behavior ? What's more, by using ifconfig manually, the interface MTU is changed for both IPv4 and IPv6 protocols. There is no way to specify a v4 or v6 only behavior. This may be related to the previous issue. I hope someone can shed some light on this. -- Francois Tigeot
Default PATH in login.conf
Hi, I have been bitten by a PATH issue when trying to configure a remote X terminal. The default PATH in /etc/login.conf includes /usr/X11R6/bin and not /usr/pkg/xorg/bin Shouldn't this be updated to reflect the new pkgsrc installation directories ? -- Francois Tigeot
Re: RE: SATA to CF -- great for embedded DFly firewalls
On Mon, Aug 07, 2006 at 09:32:35PM +0100, James Mansion wrote: The CF card just looks like an ATA disk to the OS, so it should just run fine. I have a bunch of ATA-to-CF converters which I use for diskless applications, they appear as /dev/ad0. Is Dragonfly easy to configure for readonly root? An alternative may be to use a r/w mfs root and only mount the CF as needed. I have done this for ThinBSD - an embedded distribution of FreeBSD; it should be feasible with Dragonfly too. Check out http://www.thinbsd.org/ for details. -- Francois Tigeot
Re: Compaq Evo boot problem
On Sat, Jul 29, 2006 at 11:55:21PM -0700, Matthew Dillon wrote: Again, in case the information got lost in the shuffle... before messing with any DMA modes just try telling the BIOS to put the disk in 'Large' mode. The problem is that the BIOS misinterprets the slice table and puts the disk into a strange mode that the boot code cannot get it out of. Its got to be a bug in the BIOS since packet mode (which the boot code uses to read data from the disk) is supposed to be independant of the disk access mode. I'm sure that there's a tweak we can do to fdisk and boot0cfg that will fix the BIOS's misdetection, but I have no idea what. FWIW, FreeBSD 6.0 has no trouble booting from the machine I had this problem on. -- Francois Tigeot
Re: Compaq Evo boot problem
On Sun, Jul 30, 2006 at 11:24:17AM -0700, Matthew Dillon wrote: :FWIW, FreeBSD 6.0 has no trouble booting from the machine I had this :problem on. With the disks set to 'Auto' mode instead of 'Large' mode? Yes. There's no real difference between FreeBSD's slice table and ours. There might be a difference with regards to the boot code using packet mode or not (configurable with boot0cfg), but generally speaking we want to use packet mode for the greatest compatibility with BIOSes. I also used different disks for both OSes; this may have had an effect. FreeBSD: 120 GB PATA Dragonfly: 74 GB SATA -- Francois Tigeot
Cannot mount / when booting from disk
Hi, I have recently tried to install Dragonfly-1.6 on a SATA based machine (Asus A8V-E-SE, VIA 8237 chipset, 74 GB Raptor). Everything went fine during the installation. When booting from the hard disk, the kernel is unable to mount / Here are the most important error messages (recopied by hand, they may not be completely accurate) : Mounting root from ufs:/dev/ad4s1a ad4: cannot find label (no disk label) ad4s1: cannot find label (no disk label) Root mount failed: 22 I then get a mountroot prompt. No matter what I enter, the kernel cannot find the root fs. The funny part is, when booting from the live CD, the system has no trouble with the disk whatsoever. I can read the fdisk partition table on ad4, the label on ad4s1, mount individual partitions (even what should be / on ad4s1a), list and read files, etc... I'm honestly puzzled by this. -- Francois Tigeot
