VIA EX15000G
Has anyone tried this motherboard? With 7.0 boot-only disk, I haven't been able to get as far sa Mounting root filesystem. In fact it stops just before (after probing acd0). As a matter of fact this board doesn't seem to boot FreeBSD 6.3 either, nor 5.4. (Even an old Gentoo 1.4 gets stuck pretty soon in the boot process.) So I thought there might be some BIOS trick I should try before ditching the board. Any help is welcome. -- walter pelissero http://www.pelissero.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: VIA EX15000G
Sevan / Venture37 writes: as a test try a daily snapshot Just tried 8.0 of May 2008. Same thing. BTW, Gentoo 1.4 eventually boots, disabling the USB disks legacy support in the BIOS. (As far as I understand, it's an emulation that lets primiteve OSs see the USB disks as IDE disks, or something like that.) This doesn't help FreeBSD, though. -- walter pelissero http://www.pelissero.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: VIA EX15000G
Christer Solskogen writes: Have you tried updating the BIOS (if it's available)? As far as I can tell my BIOS is 1.04, while VIA, for the EX boards, provides an upgrade to 1.01: http://www.via.com.tw/en/products/mainboards/downloads.jsp?motherboard_id=450 I'm not sure this is funny. -- walter pelissero http://www.pelissero.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
DRM for Radeon 7000
I'm not wuite sure this belongs to a FreeBSD mailing list, but the way the systems freezes suggests it may be a driver problem. I'm trying to make DRI/DRM work on a Radeon 7000-VE (AGP) installed on a dual Athlon running 5.4-STABLE. I'm using the radeon(4) driver of Xorg 6.8.2 with the MergedFB option because it's a dual head setup (so dual head and dual CPU). The reason I'm trying to use the MergedFB is that the normal Xinerama doesn't support DRI. Unfortunately if I enable the dri option in xorg.conf the system freezes rock solid after few instants of use. Looking around for clues the only strange thing I could find was that the drm0 claims to use an irq which is already used by a SCSI adapter: drm0: ATI Radeon QY RV100 7000/VE port 0x3000-0x30ff mem 0xe810-0xe810,0xf000-0xf7ff irq 18 at device 5.0 on pci1 ahc0: Adaptec 29160 Ultra160 SCSI adapter port 0x1400-0x14ff mem 0xe8001000-0xe8001fff irq 18 at device 10.0 on pci0 I don't know if this might be the source of my problems but both drivers (ahc and drm) seem to disregard the device.hints, so I couldn't try to assign distinct irqs to the two cards. Has anybody succeeded to run an ATI Radeon 7000 AGP on FreeBSD 5.4 with DRI/DRM? -- walter pelissero http://www.pelissero.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DRM for Radeon 7000
Roland Smith writes: On Tue, Jun 07, 2005 at 11:54:41AM +0200, Walter C. Pelissero wrote: Has anybody succeeded to run an ATI Radeon 7000 AGP on FreeBSD 5.4 with DRI/DRM? I've got a Radeon 9200 AGP (which is supposed to be a cheaper version of the 7000?) Quite the opposite. You can't get cheaper than the 7000. running on a uniprocessor amd64. On my system, drm0 shares an interrupt with the ethernet card without problems. Does it work if you boot a non-SMP kernel? If so it could be that the DRI code is not completely SMP safe. I think you must be right. I rebooted with kern.smp.disabled=1 in device.hints and DRI/DRM all of a sudden works flawlessly. I suppose I should be filing a PR about it soon. -- walter pelissero http://www.pelissero.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
DigiBoard PC/4e on 5.4
I have a DigiBoard PC/4e that used to work without a problem on FreeBSD 4.9 (maybe even 4.10). On 5.4 when I kldload the digi module I get an error: dgb0: FEP/OS start failed (0x00 != 0x534f) The device.hints contains: hint.digi.0.at=isa hint.digi.0.port=0x320 hint.digi.0.maddr=0xd8000 Which I'm pretty sure are the same values I've been using under FreeBSD 4.x. Any idea of what I might be doing wrong? -- walter pelissero http://www.pelissero.de ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
panic in prison?
Once a week or so there is a system running 5.3-STABLE that panics for
unknown reasons (at least to me). I haven't managed to reproduce the
problem at will but I did manage to get a dump and do a backtrace.
The kgdb session goes likes this:
88
creosote# kgdb /sys/i386/compile/X6DA8-G/kernel.debug /var/crash/vmcore.2
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so:
Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
doadump () at pcpu.h:159
(kgdb) bt
#0 doadump () at pcpu.h:159
#1 0xc04ce9e4 in boot (howto=260) at ../../../kern/kern_shutdown.c:410
#2 0xc04cec76 in panic (fmt=0xc060d89a %s)
at ../../../kern/kern_shutdown.c:566
#3 0xc05efb28 in trap_fatal (frame=0xe8c689bc, eva=27)
at ../../../i386/i386/trap.c:809
#4 0xc05ef86b in trap_pfault (frame=0xe8c689bc, usermode=0, eva=27)
at ../../../i386/i386/trap.c:727
#5 0xc05ef531 in trap (frame=
{tf_fs = -389677032, tf_es = -1068761072, tf_ds = -1067057136, tf_edi =
-1067134688, tf_esi = -1008631040, tf_ebp = -389641716, tf_isp = -389641752,
tf_ebx = -1013296640, tf_edx = 4, tf_ecx = -1067009216, tf_eax = -1, tf_trapno
= 12, tf_err = 0, tf_eip = -1068525908, tf_cs = 8, tf_eflags = 66118, tf_esp =
-1013296640, tf_ss = 1}) at ../../../i386/i386/trap.c:417
#6 0xc05e0a0a in calltrap () at ../../../i386/i386/exception.s:140
#7 0xe8c60018 in ?? ()
#8 0xc04c0010 in prison_free (pr=0xc39a5200) at ../../../kern/kern_jail.c:277
#9 0xc04a1078 in spec_open (ap=0xe8c68a74)
at ../../../fs/specfs/spec_vnops.c:207
#10 0xc04a0e03 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:118
#11 0xc051ff2d in vn_open_cred (ndp=0xe8c68be4, flagp=0xe8c68ce4, cmode=0,
cred=0xc5238300, fdidx=0) at vnode_if.h:228
---Type return to continue, or q return to quit---
#12 0xc051fb12 in vn_open (ndp=0x0, flagp=0xe8c68ce4, cmode=0, fdidx=3)
at ../../../kern/vfs_vnops.c:91
#13 0xc051a06a in kern_open (td=0xc396d7d0, path=0x0, pathseg=UIO_USERSPACE,
flags=3, mode=0) at ../../../kern/vfs_syscalls.c:957
#14 0xc0519f94 in open (td=0xc396d7d0, uap=0x0)
at ../../../kern/vfs_syscalls.c:926
#15 0xc05efd9f in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1, tf_esi = 671984685,
tf_ebp = -1077943096, tf_isp = -389640844, tf_ebx = 671991904, tf_edx =
671984703, tf_ecx = 674511308, tf_eax = 5, tf_trapno = 12, tf_err = 2, tf_eip =
674018787, tf_cs = 31, tf_eflags = 658, tf_esp = -1077943188, tf_ss = 47})
at ../../../i386/i386/trap.c:1001
#16 0xc05e0a5f in Xint0x80_syscall () at ../../../i386/i386/exception.s:201
#17 0x002f in ?? ()
#18 0x002f in ?? ()
#19 0x002f in ?? ()
#20 0x in ?? ()
#21 0x280dac2d in ?? ()
#22 0xbfbfe4c8 in ?? ()
#23 0xe8c68d74 in ?? ()
#24 0x280dc860 in ?? ()
#25 0x280dac3f in ?? ()
#26 0x283439cc in ?? ()
---Type return to continue, or q return to quit---
#27 0x0005 in ?? ()
#28 0x000c in ?? ()
#29 0x0002 in ?? ()
#30 0x282cb5e3 in ?? ()
#31 0x001f in ?? ()
#32 0x0292 in ?? ()
#33 0xbfbfe46c in ?? ()
#34 0x002f in ?? ()
#35 0x in ?? ()
#36 0x in ?? ()
#37 0x in ?? ()
#38 0x in ?? ()
#39 0x53489000 in ?? ()
#40 0xc3973c5c in ?? ()
#41 0xc396d7d0 in ?? ()
#42 0xe8c686f0 in ?? ()
#43 0xe8c686d8 in ?? ()
#44 0xc34ba7d0 in ?? ()
#45 0xc04dca4b in sched_switch (td=0x280dac2d, newtd=0x280dc860, flags=Cannot
access memory at address 0xbfbfe4d8
)
at ../../../kern/sched_4bsd.c:865
Previous frame inner to this frame (corrupt stack?)
(kgdb) frame 8
#8 0xc04c0010 in prison_free (pr=0xc39a5200) at ../../../kern/kern_jail.c:277
warning: Source file is more recent than executable.
277
(kgdb) list
272 }
273
274 void
275 prison_free(struct prison *pr)
276 {
277
278 mtx_lock(allprison_mtx);
279 mtx_lock(pr-pr_mtx);
280 pr-pr_ref--;
281 if (pr-pr_ref == 0) {
(kgdb) print *pr
$1 = {pr_list = {le_next = 0x4d4f4547, le_prev = 0x494d3a3a},
pr_id = 1380930130, pr_ref = -1067325952,
pr_path =
\002\000\000\000home\000±TÃ$\210Æè8\210Æè\004Õ\2337\214\022\027W\002\000\000\000\000\002\000\000\000\001\000\b\000\000\003\000.s\027\021\000\000\000\000\002,
'\0' repeats 42 times, ÊGVzª\rt~?¢ÙTñÓN6, '\0' repeats 409 times,
\022\t, '\0' repeats 26 times, 2, '\0' repeats 27 times,
¡\036\004\000\000\000\000\000\000ãïÃ\000\000\000\000\000\000\000\u, '\0'
repeats 18 times, pæêÄ\000\000\000\000\020U\232Ã, '\0' repeats 20 times,
Re: EPIA ME-6000
Kjell Midtseter writes: On Thursday, 28 October 2004 at 3:21:26 +0200, Walter C. Pelissero wrote: I'm trying to run FreeBSD 5.3 on a Via EPIA ME-6000, but there are still a couple of things that don't work. First. The PXE loading process is quite slow because it gets stuck for a half a minute here and there while loading the KLD modules. No network activity while the rotating bar on the screen freezes. I tried to work around this problem compiling a monolithic kernel, but still the PXE has to load at least three files (acpi.ko, loader.conf, kernel), giving the chance to delay the boot. I don't know if this is a problem related to the PXE rom or to pxeboot. The second problem is the sound. The device is recognised and the via8233 driver is properly loaded; 12 dsp devices appear in /dev (dsp0.[0-5] and dspW0.[0-5]) and the user programs work as nothing was wrong, unfortunately no sound is produced. Is there anyone who has succeeded to run FreeBSD on one of these cute Mini-ITX? I am running 6.3 on a M-1 without any problems except that there are no X-11 support for the 'vga' chip so I can not run a windows manager You mean 5.3, don't you? The M-6000's video chip works flawlessly with Xorg. -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: EPIA ME-6000
Kjell Midtseter writes: My M-6000's video chip works flawlessly with Xorg. What driver did you specify in the Device Secton of your /etc/X11/xorg.conf file? I didn't. X -configure hash chosen a via driver for me. -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
EPIA ME-6000
I'm trying to run FreeBSD 5.3 on a Via EPIA ME-6000, but there are still a couple of things that don't work. First. The PXE loading process is quite slow because it gets stuck for a half a minute here and there while loading the KLD modules. No network activity while the rotating bar on the screen freezes. I tried to work around this problem compiling a monolithic kernel, but still the PXE has to load at least three files (acpi.ko, loader.conf, kernel), giving the chance to delay the boot. I don't know if this is a problem related to the PXE rom or to pxeboot. The second problem is the sound. The device is recognised and the via8233 driver is properly loaded; 12 dsp devices appear in /dev (dsp0.[0-5] and dspW0.[0-5]) and the user programs work as nothing was wrong, unfortunately no sound is produced. Is there anyone who has succeeded to run FreeBSD on one of these cute Mini-ITX? -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
dhclient fails to get lease
On my laptop I'm experiencing a problem with dhclient. When I bootstrap the laptop (FreeBSD 5.2.1) after the server (FreeBSD 4.10), dhclient fails to get a lease within a useful time, while, if I bootstrap the server after the laptop, it gets immediately the lease. When the client is stuck in the first scenario I kill dhclient and restart and this would fix the problem: killall dhclient dhclient ep0 The ep0 interface is a PCMCIA, 3Com Etherlink III 3C589. The only suspicious thing is a couple of messages on /var/log/messages of the laptop: Aug 18 12:01:39 hyde dhclient: send_packet: No route to host Aug 18 12:01:44 hyde dhclient: send_packet: No route to host The /etc/dhclient.conf on the laptop is: timeout 60; retry 30; select-timeout 5; initial-interval 2; omapi port 7911; The relevant rc.conf settings on the laptop look like: pccard_enable=YES removable_interfaces=ep0 ifconfig_ep0=DHCP The rc.conf settings for dhcpd on the server are (mostly defaults): dhcpd_enable=YES dhcpd_flags=-q -early_chroot dhcpd_conf=/usr/local/etc/dhcpd.conf dhcpd_ifaces= dhcpd_umask=022 dhcpd_chuser_enable=YES dhcpd_withuser=dhcpd dhcpd_withgroup=dhcpd dhcpd_chroot_enable=NO dhcpd_rootdir=/var/db/dhcpd Any help is greatly appreciated. -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
TOS rewriting
Concerning a problem with a D-Link 504T ADSL modem/router/firewall that I already reported to this list some time ago http://groups.google.de/groups?hl=delr=ie=UTF-8frame=rightth=6a2dce2b59908c27seekm=c856sh%242vul%241%40FreeBSD.csie.NCTU.edu.tw I was wondering if Jim Randell had found the solution http://randell.myby.co.uk/jim/tips-300t.html I'd like to try his workaround on FreeBSD but couldn't figure out how to rewrite the TOS, as he suggests with iptables under Linux. What is the paradigm under FreeBSD to achieve the same result? Thanks in advance, -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dlink DSL router doesn't like FreeBSD
Just to update you on the D-Link 504T problem. After some weeks and a relocation I've been able to dig further in it and come to the conclusion that the 504T (mind the 'T') is buggy. Both the D-Link European help desk and the following page confirmed what I suspected: http://www.broadbandreports.com/forum/remark,10278563~mode=flat So, unless D-Link comes out with a new firmware you'd better steer clear from this DSL router. I'll return mine as soon as possible. Cheers, -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dlink DSL router doesn't like FreeBSD
John Mills writes: First, are you coming into your LAN from outside, or going outwards? Either ways. If it's an outgoing-connection problem, I would look into the firewall setting of the FBSD box. Maybe you set didn't set it up to pass the ports for outgoing telnet and ssh, or maybe you shut off the replies on those same ports. Not as far as I know. I personally took care of the installation. *Intra*net traffic works seamlessly, between the two FreeBSD boxes, though. Try plugging the WindowBox into another of the router's ports, then use PuTTY to telnet and ssh into your FBSD box (using it's LAN address, naturally). If that works, the problem is definitely the router, but possibly a setup issue. Especially since telnet is also involved. (Many people disable incoming telnet, for security reasons.) I haven't tried PuTTY internally (from Windoze to FreeBSD). I won't be able to do that test during the weekend as I'm currently about 500 miles away from that LAN. I'll keep you posted, though. When you have intra-LAN access working, look into port forwarding in the router's setup: you want incoming traffic from the ports used by ssh and (if you enable it) telnet to be sent to the LAN address of your FBSD box. Did it. If I didn't, I suppose ssh wouldn't go that far in the login process. As suggested by Konrad Heuer I gathered further data with -v options of ssh and tcpdump. As suggested by Vladimir Terziev i ran ssh using protocol 1 only and disabling X11 forwarding. Here is the command line: ssh -vvv -x -1 -4 that.bloody.address from my machine at home to the dynamic IP address of that router which is configured to forward port 22 to the FreeBSD box. Here is the log: OpenSSH_3.6.1p1 FreeBSD-20030924, SSH protocols 1.5/2.0, OpenSSL 0x0090703f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug2: ssh_connect: needpriv 0 debug1: Connecting to that.bloody.address [xxx.xxx.xxx.xxx] port 22. debug1: Connection established. debug1: identity file /usr/home/wcp/.ssh/identity type 0 debug1: Remote protocol version 1.99, remote software version OpenSSH_3.6.1p1 FreeBSD-20030924 debug1: match: OpenSSH_3.6.1p1 FreeBSD-20030924 pat OpenSSH* debug1: Local version string SSH-1.5-OpenSSH_3.6.1p1 FreeBSD-20030924 debug1: Waiting for server public key. debug1: Received server public key (768 bits) and host key (1024 bits). debug3: check_host_in_hostfile: filename /usr/home/wcp/.ssh/known_hosts2 debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts2 debug3: check_host_in_hostfile: filename /usr/home/wcp/.ssh/known_hosts debug3: check_host_in_hostfile: match line 31 debug1: Host 'that.bloody.address' is known and matches the RSA1 host key. debug1: Found key in /usr/home/wcp/.ssh/known_hosts:31 debug1: Encryption type: 3des debug1: Sent encrypted session key. debug2: cipher_init: set keylen (16 - 32) debug2: cipher_init: set keylen (16 - 32) debug1: Installing crc compensation attack detector. debug1: Received encrypted confirmation. debug1: Trying RSA authentication with key '/usr/home/wcp/.ssh/identity' debug1: Server refused our key. debug1: Doing challenge response authentication. Password: Response: [I just type return] debug1: Doing password authentication. [EMAIL PROTECTED]'s password: [I type the password] debug1: Requesting pty. debug3: tty_make_modes: ospeed 38400 debug3: tty_make_modes: ispeed 38400 debug3: tty_make_modes: 1 3 debug3: tty_make_modes: 2 28 debug3: tty_make_modes: 3 127 debug3: tty_make_modes: 4 21 debug3: tty_make_modes: 5 4 debug3: tty_make_modes: 6 255 debug3: tty_make_modes: 7 255 debug3: tty_make_modes: 8 17 debug3: tty_make_modes: 9 19 debug3: tty_make_modes: 10 26 debug3: tty_make_modes: 11 25 debug3: tty_make_modes: 12 18 debug3: tty_make_modes: 13 23 debug3: tty_make_modes: 14 22 debug3: tty_make_modes: 17 8 debug3: tty_make_modes: 18 15 debug3: tty_make_modes: 30 1 debug3: tty_make_modes: 31 0 debug3: tty_make_modes: 32 0 debug3: tty_make_modes: 33 0 debug3: tty_make_modes: 34 0 debug3: tty_make_modes: 35 0 debug3: tty_make_modes: 36 1 debug3: tty_make_modes: 38 1 debug3: tty_make_modes: 39 0 debug3: tty_make_modes: 40 0 debug3: tty_make_modes: 41 1 debug3: tty_make_modes: 50 1 debug3: tty_make_modes: 51 1 debug3: tty_make_modes: 53 1 debug3: tty_make_modes: 54 1 debug3: tty_make_modes: 55 1 debug3: tty_make_modes: 56 0 debug3: tty_make_modes: 57 0 debug3: tty_make_modes: 58 0 debug3: tty_make_modes: 59 1 debug3: tty_make_modes: 60 1 debug3: tty_make_modes: 61 1 debug3: tty_make_modes: 62 1 debug3: tty_make_modes: 70 1 debug3: tty_make_modes: 72 1 debug3: tty_make_modes: 73 0 debug3: tty_make_modes: 74 0 debug3: tty_make_modes: 75 0 debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1
Dlink DSL router doesn't like FreeBSD
I'm trying to make work a D-Link 504T DSL router/switch with FreeBSD 5.2.1-RELEASE-p6. I've already realised that IPv6 is not supported by the router so I compiled an IPv4-only kernel and got to work DNS, HTTP, and FTP. My problem is that ssh and telnet don't work. I get as far as the Password prompt, I type it in, and then ssh freezes for a couple of minutes until it probably goes in timeout and gives up. The D-Link help desk is useless; the only thing they suggested was to return the router to where I bought it. I've anyhow the impression that the problem might not completely be the router's fault. In fact I plugged a Windoze machine, installed PuTTY, and ssh seems to work flawlessly. What am I missing here? Thanks in advance, -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
nsp cardbus on 5.2
I was wondering if the pcmcia SCSI card provided with the HP M802e
portable CD burner is supported in cardbus mode under 5.2. The card
used to work flawlessly under 4.9 in 16bit mode (it's got a dip switch
to change between the two modes) with this default pccard.conf entry:
# Hewlett Packard M820e (CD-writer)
card /KME */ SCSI-CARD-001
config auto nsp ?
On 5.2 I tried this entry in devd.conf:
nomatch 12 {
match bus cardbus[0-9]+;
match vendor 0x1145;
match device 0xf007;
action kldload nsp;
};
On insertion, the card is recognised and the nsp driver loaded but it
somehow fails to attach to the card:
Mar 22 13:28:11 hyde kernel: TUPLE: LINKTARGET [3]: 43 49 53
Mar 22 13:28:11 hyde kernel: Product version: 5.0
Mar 22 13:28:11 hyde kernel: Product name: KME | SCSI-CARD-001 | 1 |
Mar 22 13:28:11 hyde kernel: cardbus0: Opening BAR: type=IO, bar=10, len=0080
Mar 22 13:28:11 hyde kernel: cardbus0: Opening BAR: type=MEM, bar=14, len=1000
Mar 22 13:28:11 hyde kernel: TUPLE: Unknown(0x1c) [3]: 02 da ff
Mar 22 13:28:11 hyde kernel: TUPLE: Unknown(0x04) [6]: 03 01 02 0c 00 00
Mar 22 13:28:11 hyde kernel: TUPLE: Unknown(0x05) [13]: 41 b9 11 b5 1e 1e 02 30 ff
ef 04 a9 00
Mar 22 13:28:11 hyde kernel: Manufacturer ID: 32000426
Mar 22 13:28:11 hyde kernel: CIS reading done
Mar 22 13:28:11 hyde kernel: cardbus0: Non-prefetchable memory at 88003000-88003fff
Mar 22 13:28:11 hyde kernel: cardbus0: IO port at 1080-10ff
Mar 22 13:28:11 hyde kernel: cardbus0: mass storage, SCSI at device 0.0 (no driver
attached)
Mar 22 13:28:11 hyde kernel: cbb0: CardBus card activation failed
The nsp driver is indeed loaded:
Id Refs AddressSize Name
1 41 0xc040 2929bc kernel
22 0xc0693000 1e58csnd_pcm.ko
31 0xc06b2000 b918 snd_ds1.ko
49 0xc06be000 27e08usb.ko
51 0xc06e6000 5850 ugen.ko
61 0xc06ec000 3ac8 uhid.ko
71 0xc06f 7f54 ukbd.ko
81 0xc06f8000 37c4 ulpt.ko
91 0xc06fc000 3f30 ums.ko
101 0xc070 6554 umass.ko
11 14 0xc0707000 3c70ccam.ko
128 0xc0744000 13080agp.ko
131 0xc0758000 b8b4 random.ko
142 0xc0764000 8e58 scsi_low.ko
151 0xc076d000 b540 cbb.ko
162 0xc0779000 3678 exca.ko
171 0xc077d000 c96c pccard.ko
181 0xc078a000 6778 cardbus.ko
191 0xc0791000 65ec ppbus.ko
211 0xc079d000 51ad8acpi.ko
221 0xc2a95000 6000 procfs.ko
231 0xc2a9b000 6000 pseudofs.ko
241 0xc2aa6000 3000 fdescfs.ko
251 0xc2acc000 6000 if_ep.ko
261 0xc2ad2000 2000 elink.ko
271 0xc2b32000 2f000nfsclient.ko
281 0xc2ba3000 1b000nfsserver.ko
292 0xc2d85000 19000linux.ko
301 0xc2df5000 2000 rtc.ko
321 0xc378e000 7000 nsp.ko
--
walter pelissero
http://www.pelissero.de
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
tape error, but no tape
Today I've been trying to restore a filesystem with surprising results. The backup file was on a netwroked machine and not on a tape so I'd exclude any type of medium defect. Nevertheless, the restore program reported a tape read error. Sounds really strange to me. Here is the session log: hyde# restore if /net/fish/usr/home/wcp/hyde-usr.dump restore ls .: .snap/ crash/ include/local/ sbin/ src.cvs@ X11R6/ db/ lib/lost+found/ share/ sup@ bin/games/ libdata/mdec/ spool/ compat/ home/ libexec/ports@ src@ restore add bin restore add lib restore add libdata restore add libexec sbin share restore add include restore add db restore extract You have not read any tapes yet. If you are extracting just a few files, start with the last volume and work towards the first; restore can quickly skip tapes that have no further files to extract. Otherwise, begin with volume 1. Specify next volume #: 1 Tape read error while skipping over inode 114139 continue? [yn] y unknown tape header type 2054782334 abort? [yn] n not at beginning of a file abort? [yn] y dump core? [yn] n hyde# Nobody tripped on the network cable and there is no trace of errors in /var/log/messages. This is on FreeBSD 5.2.1-RC, trying to restore a UFS1 snapshot (option -L) to a UFS2 filesystem. -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acu Cobol 6.0 for Linux
Dan Nelson writes: In the last episode (Feb 04), Walter C. Pelissero said: A side note. What is the impact of this IPC_64 flag on the FreeBSD code? Can we ignore it, or does it mean that the Linux emulator is outdated regarding this new flag? Linux IPC_64 support was added to the 5.x tree over a year ago but never got merged back to 4.x. It looks like there are different structures for the IPC_64 case, so just stripping the IPC_64 bit won't work. Take a look at http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/compat/linux/linux_ipc.c.diff?r1=1.30r2=1.31f=h - it was a mega-commit, so there's more than just the IPC_64 stuff, but it's pretty easy to pick out the right bits (basically anything with a 64 in it :). I've been spending the last two days upgrading to 5.2.1.-RC. Well, beside the predictable cultural impact (a few things have changed from 4.9), the first impression was that the Linux emulator worked much better, in fact it runs Acu Cobol 6.0 for Linux flawlessly! There are still some minor details that don't work as expected (ACPI-S1 and cardbus) and some that stopped working (snd_pcm). These will probably require delving in the documentation or possibly waiting for 5.3. But devfs and devd alone are worth upgrading. Congratulations guys. You've done an awesome job! -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acu Cobol 6.0 for Linux
Dan Nelson writes: In the last episode (Feb 04), Walter C. Pelissero said: A side note. What is the impact of this IPC_64 flag on the FreeBSD code? Can we ignore it, or does it mean that the Linux emulator is outdated regarding this new flag? Linux IPC_64 support was added to the 5.x tree over a year ago but never got merged back to 4.x. Oops. Don't tell me Iv'e beeing trying to fix a bug that wasn't there. I'll try in the next days to install 5.2 at least on my laptop and see if it helps. (It's anyhow something that was already on my agenda.) -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acu Cobol 6.0 for Linux
I tried linux_kdump (from ports) and things seem to clarify a bit.
I concentrated on acushare, which is the daemon that supervises
inter-process locking (locking on file access) and licence
verification. Whereas acushare seems to start properly, an attempt to
kill it through the recommended means (not with kill(1)), yields an
IPC error. On Linux strace on the daemon process shows:
msgrcv(256, {1, \254\1\0\0\6\0\0\0\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...}, 100,
1, MSG_NOERROR) = 12
getpid()= 376
getuid32() = -1 ENOSYS (Function not implemented)
msgctl(256, IPC_STAT, 0xba54) = 0
msgsnd(256, {428, x\1\0\0\6\0\0\0\6\0\0\0}, 12, 0) = 0
That is, msgrcv returns a 12 bytes long message and the daemon
answers. On FreeBSD, on the other hand:
75838 acushare RET linux_ipc 12/0xc
75838 acushare CALL linux_getpid
75838 acushare RET linux_getpid 75838/0x1283e
75838 acushare CALL linux_ipc(0xe,0x5,0x102,0,0xbfbff444,0)
75838 acushare RET linux_ipc -1 errno 22 Invalid argument
75838 acushare CALL linux_time(0xbfbff49c)
75838 acushare RET linux_time 1075830865/0x401fe051
75838 acushare CALL write(0,0x2806f000,0x4a)
75838 acushare GIO fd 0 wrote 74 bytes
acushare: 2004-02-03 18:54:25: Error replying to test message from run\
cbl
That is, linux_ipc (possibly a catch-all name for the Linux IPC
functions family), returns a 12 bytes long message, but when it is
supposed to do the msgctl it fails miserably with an errno 22.
I couldn't make sense out of the six arguments to linux_ipc shown in
the kdump. Does anyone know how to interprete them?
--
walter pelissero
http://www.pelissero.de
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acu Cobol 6.0 for Linux
Dan Nelson writes:
If you do have sysvmsg loaded, you may have to start adding printfs in
linux_msgctl() to trace which call is failing and why.
Thanks. With your hints I made an interesting discovery that allowed
me to improve the situation dramatically.
In Linux's /usr/include/linux/ipc.h there is an interesting comment:
/*
* Version flags for semctl, msgctl, and shmctl commands
* These are passed as bitflags or-ed with the actual command
*/
#define IPC_OLD 0 /* Old version (no 32-bit UID support on many
architectures) */
#define IPC_64 0x0100 /* New version (support 32-bit UIDs, bigger
message sizes, etc. */
In fact linux_msgctl receives a command 0x102 instead of 2. Although
the following patch fixes the problem related to msgctl, I'm not quite
sure it's enough to say that Acu Cobol runs perfectly on FreeBSD.
Actually I've got the feeling msgrcv still doesn't work as expected,
but I might be wrong.
I'll probably reach a certain confidence in the following days.
A side note. What is the impact of this IPC_64 flag on the FreeBSD
code? Can we ignore it, or does it mean that the Linux emulator is
outdated regarding this new flag?
Cheers,
--
walter pelissero
http://www.pelissero.de
Index: compat/linux/linux_ipc.c
===
RCS file: /usr/home/src.cvs/src/sys/compat/linux/linux_ipc.c,v
retrieving revision 1.17.2.3
diff -w -u -r1.17.2.3 linux_ipc.c
--- compat/linux/linux_ipc.c5 Nov 2001 19:08:22 - 1.17.2.3
+++ compat/linux/linux_ipc.c4 Feb 2004 00:33:56 -
@@ -233,7 +233,7 @@
bsd_args.semnum = args-semnum;
bsd_args.arg = unptr;
- switch (args-cmd) {
+ switch (args-cmd 0xff) { /* mask off the IPC_64 flag */
case LINUX_IPC_RMID:
bsd_args.cmd = IPC_RMID;
break;
@@ -362,7 +362,7 @@
int error;
bsd_args.msqid = args-msqid;
-bsd_args.cmd = args-cmd;
+bsd_args.cmd = args-cmd 0xff; /* mask off the IPC_64 flag */
bsd_args.buf = (struct msqid_ds *)args-buf;
error = msgctl(p, bsd_args);
return ((args-cmd == LINUX_IPC_RMID error == EINVAL) ? 0 : error);
@@ -429,7 +429,7 @@
int error;
caddr_t sg = stackgap_init();
-switch (args-cmd) {
+switch (args-cmd 0xff) { /* mask off the IPC_64 flag */
case LINUX_IPC_STAT:
bsd_args.shmid = args-shmid;
bsd_args.cmd = IPC_STAT;
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acu Cobol 6.0 for Linux
I realised that the ktrace log was rubbish; most of the syscalls names
were not properly mapped.
I tried to track down the exact spot were the Linux executable gets
the SEGV signal, running strace on a Debian system and comparing the
values passed to the system calls. Here is an extract:
rt_sigaction(SIGTSTP, {0x8072ce0, [TSTP], SA_RESTART|0x400}, {SIG_IGN}, 8) = 0
rt_sigaction(SIGHUP, {0x8072ca0, [HUP], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, {0x8072bf0, [TERM], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGFPE, {0x804f910, [FPE], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGBUS, {0x804f940, [BUS], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGSEGV, {0x804f910, [SEGV], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGILL, {0x804f910, [ILL], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGSYS, {0x804f910, [SYS], SA_RESTART|0x400}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGALRM, NULL, {SIG_DFL}, 8) = 0
rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0
brk(0x81c2000) = 0x81c2000
^^--- SEGV on FreeBSD!
brk(0x81c3000) = 0x81c3000
brk(0x81c4000) = 0x81c4000
brk(0x81c5000) = 0x81c5000
brk(0x81c6000) = 0x81c6000
So it was rt_sigaction() and not pwrite(); brk() and not ktrace().
Does this shed a new light?
--
walter pelissero
http://www.pelissero.de
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Acu Cobol 6.0 for Linux
Jerry McAllister writes:
[apparently the first message didn't get through; this is a repost]
Your previous post got through.
Probably the presumed answer is that no-one who saw it has
tried this or feels competent to respond.
Sorry for the duplicate. It wasn't the lack of answer but the missing
entry in the mailing list archive which made me suspect the message
didn't get through. I didn't realise the archives were updated on a
weekly basis.
You might some response if you could find a way to break the
problem down a little more and give a little more detail.
How about a ktrace?
459 ktrace RET ktrace 0
459 ktrace CALL execve(0xbfbff85f,0xbfbff740,0xbfbff74c)
459 ktrace NAMI /usr/local/acucobol60/bin/runcbl
459 ktrace NAMI /compat/linux/lib/ld-linux.so.2
459 runcbl RET execve 0
459 runcbl CALL settimeofday(0xbfbff30c)
459 runcbl RET settimeofday 0
459 runcbl CALL ktrace(0)
459 runcbl RET ktrace 136044544/0x81be000
459 runcbl CALL open(0x2819d4fe,0,0x6c2f6c61)
459 runcbl NAMI /compat/linux/etc/ld.so.preload
459 runcbl NAMI /etc/ld.so.preload
459 runcbl RET open JUSTRETURN
459 runcbl CALL open(0xbfbfea1c,0,0)
459 runcbl NAMI /compat/linux/usr/local/linux-jdk1.3.0/lib/i386/libm.so.6
459 runcbl NAMI /usr/local/linux-jdk1.3.0/lib/i386/libm.so.6
459 runcbl RET open JUSTRETURN
459 runcbl CALL setrlimit(0xbfbfea1c,0xbfbfeae4,0x281a03e0)
459 runcbl NAMI /compat/linux/usr/local/linux-jdk1.3.0/lib/i386
459 runcbl NAMI /usr/local/linux-jdk1.3.0/lib/i386
459 runcbl RET setrlimit JUSTRETURN
459 runcbl CALL open(0xbfbfea1c,0,0x)
459 runcbl NAMI libm.so.6
459 runcbl RET open JUSTRETURN
459 runcbl CALL open(0x2819e493,0,0x1)
459 runcbl NAMI /compat/linux/etc/ld.so.cache
459 runcbl NAMI /compat/linux
459 runcbl NAMI /compat/linux/etc/ld.so.cache
459 runcbl RET open 3
459 runcbl CALL mmap(0x3,0xbfbfea94,0x281a03e0)
459 runcbl RET mmap 0
459 runcbl CALL dup2(0xbfbfea4c)
459 runcbl RET dup2 672796672/0x281a1000
459 runcbl CALL close(0x3)
459 runcbl RET close 0
459 runcbl CALL open(0x281a8f5e,0,0xbfbfeb64)
459 runcbl NAMI /compat/linux/lib/libm.so.6
459 runcbl NAMI /compat/linux
459 runcbl NAMI /compat/linux/lib/libm.so.6
459 runcbl RET open 3
459 runcbl CALL read(0x3,0xbfbfebb4,0x400)
459 runcbl GIO fd 3 read 1024 bytes
[EMAIL PROTECTED]
\M-p\M-w\^A\0\0\0\0\0004\0 \0\^F\0(\0\^[\0\^Z\0\^F\0\0\0004\0\0\0004\0\
[EMAIL PROTECTED]@\0\0\0\^E\0\0\0\^D\0\0\0\^C\0\0\0 \M-t\^A\0\
\M-t\^A\0 \M-t\^A\0\^S\0\0\0\^S\0\0\0\^D\0\0\0\^A\0\0\0\^A\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0003\M-t\^A\0003\M-t\^A\0\^E\0\0\0\0\^P\0\0\^A\0\0\
[EMAIL PROTECTED]@[EMAIL PROTECTED]
\0\0\0\M^D\M-t\^A\0\M^D\^D\^B\0\M^D\^D\^B\0\M-X\0\0\0\M-X\0\0\0\^F\0\0\
\0\^D\0\0\0\^D\0\0\0\M-t\0\0\0\M-t\0\0\0\M-t\0\0\0 \0\0\0 \0\0\0\^D\0\
\0\0\^D\0\0\0\^D\0\0\0\^P\0\0\0\^A\0\0\0GNU\0\0\0\0\0\^B\0\0\0\0\0\0\0\
\^^\0\0\0\M-!\^B\0\0v\^A\0\0H\^A\0\0\0\0\0\0\0\0\0\0\M^Z\0\0\0\M-O\0\0\
\0\M-e\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M-\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\08\0\0\0\0\0\0\
\0\0\0\0\0\M^U\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M-\0\0\0\0\0\0\09\0\0\0e\
\^A\0\0\M-1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0Y\^A\0\0B\^A\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M^Y\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\M-u\0\0\0X\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\M-[EMAIL PROTECTED]
\0\0\0\0\\^A\0\0\0\0\0\0\M-g\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\0\M-2\0\0\0\0\0\0\0006\0\0\0\M-i\0\0\0 \^A\0\0\M-=\0\0\0\M-v\0\
\0\0\^Q\^A\0\0\M-'\0\0\0\0\0\0\0n\0\0\0\M-U\0\0\0\M-X\0\0\0{\0\0\0\M-8\
\0\0\0\^Y\^A\0\0\M-:\0\0\0\0\0\0\0j\^A\0\0\\\0\0\0\^A\0\0\M-$\0\0\0M\
\^A\0\0\0\0\0\0\M-b\0\0\0\0\0\0\0002\0\0\0\0\0\0\0\0\0\0\0N\^A\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\M^D\0\0\0R\^A\0\0007\^A\0\0[\0\0\0\0\0\0\0K\^A\0\
\0\M^_\0\0\0\M-G\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^A\^A\0\0#\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0h\^A\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0A\^A\0\0\0\0\0\0\M^V\0\0\0\0\0\0\0\
\0\0\0\0\0\0\0\0\0\0\0\0B\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M-o\0\
\0\0\M-Z\0\0\0\0\0\0\0\0\0\0\0\M^P\0\0\0\0\0\0\0_\^A\0\0\M-.\0\0\0\0\0\
\0\0\0\0\0\0Z\^A\0\0\0\0\0\0!\0\0\0b\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
\0\0\0\M-n\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\M-D\0\0\0\0\0\
\0\0=\^A\0\0\0\0\0\0\0\0\0\0\0\0\0\0\^R\^A\0\0
459 runcbl RET read 1024/0x400
459 runcbl CALL
Acu Cobol 6.0 for Linux
[apparently the first message didn't get through; this is a repost] Did enybody try to run AcuCobol 6.0 for Linux on FreeBSD's linulator? I tried a couple of times (with old Debian libraries and more recently Gentoo libraries) but runcbl keeps on getting a SIGSEGV right away. ccbl (the compiler) seems to work, though. Any clue? -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Acu Cobol 6.0 for Linux
Did enybody try to run AcuCobol 6.0 for Linux on FreeBSD's linulator? I tried a couple of times (with old Debian libraries and more recent Gentoo libraries) but runcbl keeps on getting a SIGSEGV right away. ccbl (the compiler) seems to work, though. Any clue? -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
auto-patching the system
I keep my src tree updated with cvsup, but I start to accumulate patches to kernel or programs that I'd like to include automatically each time I recompile the kernel (pretty often) or I do a make world (much less often). Those are usually patches that have been already put forward to the attention of the maintainers with a send-pr, but got forgotten or simply ignored possibly because considered not interesting. At the moment I simply manually copy the modified files into the source tree before recompiling, but, of course, next time I do a cvsup, the changes are gone, requiring me to repeat the process next time I compile (and likely forgetting some stuff). Is there already any pre-canned way to include those patches at compile time? (A parallel source tree, for instance.) Cheers, -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB - PS/2
Just noticed that the patch to usbd.c I proposed yesterday shows an
undesirable behaviour. That is, usbd executes the actions in
usbd.conf of all matching devices, which is not exactly what I meant
to do. In fact, usbd should execute for every device name the best
matching action in usbd.conf.
Supposed usbd.conf is sorted in a way that the most specific entries
precede the less specific ones, the following patch should do the
trick.
Cheers,
--
walter pelissero
http://www.pelissero.de
--- usbd.c.orig Sun Aug 31 17:24:14 2003
+++ usbd.c Sun Aug 31 17:08:19 2003
@@ -102,6 +102,7 @@
int lineno;
int verbose = 0; /* print message on what it is doing */
+int single_action = 0;
typedef struct event_name_s {
int type; /* event number (from usb.h) */
@@ -204,8 +205,7 @@
void print_event __P((struct usb_event *event));
void print_action __P((action_t *action, int i));
void print_actions __P((void));
-int find_action __P((struct usb_device_info *devinfo,
- action_match_t *action_match));
+void execute_command __P((char *cmd));
void
@@ -674,37 +674,19 @@
int
-match_devname(action_t *action, struct usb_device_info *devinfo)
+match_devname(regex_t *regex, char *name)
{
- int i;
- regmatch_t match;
- int error;
-
- for (i = 0; i USB_MAX_DEVNAMES; i++) {
- if (devinfo-udi_devnames[i][0] == '\0')
- break;
-
- error = regexec(action-devname_regex, devinfo-udi_devnames[i],
- 1, match, 0);
- if (error == 0) {
- if (verbose = 2)
- printf(%s: %s matches %s\n, __progname,
- devinfo-udi_devnames[i], action-devname);
- return(i);
- }
- }
-
- return(-1);
+ return regexec(regex, name, 0, 0, 0) == 0;
}
-
-int
-find_action(struct usb_device_info *devinfo, action_match_t *action_match)
+void
+execute_actions (struct usb_device_info *devinfo, int event_type)
{
action_t *action;
char *devname = NULL;
- int match = -1;
+ int i;
+ for (i = 0; i USB_MAX_DEVNAMES devinfo-udi_devnames[i][0] != '\0'; i++) {
STAILQ_FOREACH(action, actions, next) {
if ((action-vendor == WILDCARD_INT ||
action-vendor == devinfo-udi_vendorNo)
@@ -719,15 +701,15 @@
(action-protocol == WILDCARD_INT ||
action-protocol == devinfo-udi_protocol)
(action-devname == WILDCARD_STRING ||
-(match = match_devname(action, devinfo)) != -1)) {
- /* found match !*/
-
+match_devname(action-devname_regex,
devinfo-udi_devnames[i]))) {
+ if (verbose = 2)
+ print_action(action, 0);
/* Find a devname for pretty printing. Either
* the matched one or otherwise, if there is only
* one devname for that device, use that.
*/
- if (match = 0)
- devname = devinfo-udi_devnames[match];
+ if (action-devname != WILDCARD_STRING)
+ devname = devinfo-udi_devnames[i];
else if (devinfo-udi_devnames[0][0] != '\0'
devinfo-udi_devnames[1][0] == '\0')
/* if we have exactly 1 device name */
@@ -742,16 +724,37 @@
printf(\n);
}
- action_match-action = action;
- action_match-devname = devname;
+ if (devname) {
+ int error;
+ if (verbose = 2)
+ printf(%s: Setting DEVNAME='%s'\n,
+ __progname, devname);
+ error = setenv(DEVNAME, devname, 1);
+ if (error)
+ fprintf(stderr, %s:
setenv(\DEVNAME\,
+ \%s\,1) failed, %s\n,
+ __progname, devname,
strerror(errno));
+ }
- return(1);
+ if (USB_EVENT_IS_ATTACH(event_type) action-attach)
+ execute_command(action-attach);
+ if (USB_EVENT_IS_DETACH(event_type) action-detach)
+ execute_command(action-detach);
+
Re: USB - PS/2
Ok, today I spent some time deciphering the ums log and came up
with this patch.
--- /sys/dev/usb/ums.c Wed Nov 6 21:23:50 2002
+++ ums.c Sun Aug 31 15:08:52 2003
@@ -428,10 +428,8 @@
}
ibuf = sc-sc_ibuf;
- if (sc-sc_iid) {
- if (*ibuf++ != sc-sc_iid)
- return;
- }
+ if (sc-sc_iid)
+ ibuf++;
dx = hid_get_data(ibuf, sc-sc_loc_x);
dy = -hid_get_data(ibuf, sc-sc_loc_y);
Unfortunately my knowledge (or rather lack of it) of the USB/UMS
driver doesn't give me very much confidence that I didn't break
something else.
What was that conditional return suposed to protect from?
Is it safe to remove it?
The PS/2 mouse works now and the USB one as well.
Cheers,
--
walter pelissero
http://www.pelissero.de
Bruce M Simpson writes:
On Sat, Aug 30, 2003 at 01:51:27PM +0200, Walter C. Pelissero wrote:
I just bought a USB - PS/2 keyboard and mouse converter for my
laptop. It's a Sitecom brand and it gets recognised as MCT Corp.
I had similar problems with a Tangtop USB-PS/2 k+m adapter.
In the end it turned out that this device was causing uhci to report
an error, even though the movement data coming in looked fine. I never
got round to fixing it.
Perhaps you could try throwing all the debug switches on in the usb drivers
and usbd and seeing if you get similar behaviour?
Thanks for the patch, this was the other thing that needed fixing!
BMS
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
fast typing
When recently I've switched to a PS/2 Keyboard attached to a USB converter I started to experience strange typos. The problem is extra characters sent to the machine while typing fairly fast. It can be easily reproduced doing this: 1. xset r off 2. press and keep pressed a key, say 'd' 3. press and keep pressed another key, say 'w' 4. release the first key 5. at this point you should see dwww which is not what I expect (dw) 6. release the second key 7. at this point I see a d On a PS/2 keyboard connected directly to a PS/2 port (no converter in between), this doesn't happen. Unfortunately I've got no USB keyboard to try directly without the USB-PS/2 converter. I was wondering if this is a problem of the USB converter or a problem of the ukbd driver. Does anybody else experience the same behaviour? Cheers, -- walter pelissero http://www.pelissero.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
USB - PS/2
I just bought a USB - PS/2 keyboard and mouse converter for my
laptop. It's a Sitecom brand and it gets recognised as MCT Corp.
addr 1: UHCI root hub, Intel
addr 2: Generic USB Hub, ALCOR
addr 4: HID-compliant Mouse (USB), Mitsumi
addr 3: PS/2 - USB Interface Adaptor, MCT Corp.
Although the keyboard works, the mouse doesn't. I tried to plug two
types of mice (a Micro$oft 2 buttons and a Trust 3 buttons) but both,
while generating traffic on the USB bus (the converter LED blinks),
don't move the pointer.
This is the usbd log:
uhub1: ALCOR Generic USB Hub, class 9/0, rev 1.10/3.12, addr 2
uhub1: 4 ports with 4 removable, bus powered
ums0: Mitsumi HID-compliant Mouse (USB), rev 1.00/1.10, addr 3, iclass 3/1
ums0: 2 buttons
ukbd0: MCT Corp. PS/2 - USB Interface Adaptor, rev 1.10/1.00, addr 4, iclass 3/1
kbd1 at ukbd0
ums1: MCT Corp. PS/2 - USB Interface Adaptor, rev 1.10/1.00, addr 4, iclass 3/1
ums1: 3 buttons and Z dir.
Moused is there:
179 ?? Ss 0:05.83 /usr/sbin/moused -3 -p /dev/ums0 -I /var/run/moused.ums0.pid
209 ?? Ss 0:05.57 moused -3 -p /dev/psm0 -t auto
237 ?? Is 0:00.01 /usr/sbin/moused -p /dev/jogdial -t jogdial
370 ?? Ss 0:10.21 /usr/sbin/moused -3 -p /dev/ums1 -I /var/run/moused.ums1.pid
(The PS/2 mouse is either the first or the last one.)
This is on a FreeBSD 4.9-PRERELASE. On Windoze the converter works
out of the box, with keyboard and mouse, without additional drivers.
Does anybody know how to make the PS/2 mouse work?
BTW, usbd, as it is, is not suitable to handle devices like this PS/2
adapter because it matches and executes only one entry in the
usbd.conf. USB devices implementing multiple features are in my
humble opinion better handled matching multiple entries in usbd.conf.
Below I attached a patch to usbd.c to change this behaviour (hence the
crossposting to the hackers list).
Cheers,
--
walter pelissero
http://www.pelissero.de
--- /usr/src/usr.sbin/usbd/usbd.c Tue Dec 31 10:05:27 2002
+++ usbd.c Sat Aug 30 13:43:23 2003
@@ -102,6 +102,7 @@
int lineno;
int verbose = 0; /* print message on what it is doing */
+int single_action = 0;
typedef struct event_name_s {
int type; /* event number (from usb.h) */
@@ -204,8 +205,7 @@
void print_event __P((struct usb_event *event));
void print_action __P((action_t *action, int i));
void print_actions __P((void));
-int find_action __P((struct usb_device_info *devinfo,
- action_match_t *action_match));
+void execute_command __P((char *cmd));
void
@@ -697,9 +697,8 @@
return(-1);
}
-
-int
-find_action(struct usb_device_info *devinfo, action_match_t *action_match)
+void
+execute_actions (struct usb_device_info *devinfo, int event_type)
{
action_t *action;
char *devname = NULL;
@@ -722,6 +721,8 @@
(match = match_devname(action, devinfo)) != -1)) {
/* found match !*/
+ if (verbose = 2)
+ print_action(action, 0);
/* Find a devname for pretty printing. Either
* the matched one or otherwise, if there is only
* one devname for that device, use that.
@@ -735,21 +736,37 @@
if (verbose) {
printf(%s: Found action '%s' for %s, %s,
- __progname, action-name,
- devinfo-udi_product, devinfo-udi_vendor);
+ __progname, action-name,
+ devinfo-udi_product, devinfo-udi_vendor);
if (devname)
printf( at %s, devname);
printf(\n);
}
- action_match-action = action;
- action_match-devname = devname;
+ if (devname) {
+ int error;
+ if (verbose = 2)
+ printf(%s: Setting DEVNAME='%s'\n,
+ __progname, devname);
+ error = setenv(DEVNAME, devname, 1);
+ if (error)
+ fprintf(stderr, %s: setenv(\DEVNAME\,
+ \%s\,1) failed, %s\n,
+ __progname, devname, strerror(errno));
+ }
- return(1);
+ if (USB_EVENT_IS_ATTACH(event_type) action-attach)
+ execute_command(action-attach);
+ if (USB_EVENT_IS_DETACH(event_type) action-detach)
+ execute_command(action-detach);
+
