Cardreaders and touchscreens?
Hi there - One of my clients would like me to hack together an application involving a cardreader and a touchscreen. How would I deal with these two rather 'odd' pieces of hardware. I didn't have any say in the purchasing of the touchscreen, but I suppose that shouldn't give me any trouble? It's just a keyboard/mouse combination in a strange shape, as I see it? The cardreader is another story. I'm free in choosing one which I can get to work. Does anyone have any experience with these things under FreeBSD? Any brands/types from which I *really* should stay away? Thanks for any info! - Philip -- Philip Paeps [EMAIL PROTECTED] http://www.paeps.cx/ +32 486 114 720 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cardreaders and touchscreens?
> The cardreader is another story. I'm free in choosing one which I can get to > work. Does anyone have any experience with these things under FreeBSD? Any > brands/types from which I *really* should stay away? I've used a wide range of serial port ones; most seem OEM-ed IBMs or SEMA/Schulbergee. See http://www.franken.de/crypt/scez.html which I found usefull for the Schlumbergee crypto cards. Dw To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Numerous hard hangs on TWO different ASUS P4T-E w/P4 1.6G
Frank Mayhar wrote: > > I'm experiencing hangs as well. At first I thought it was the fxp0/sym > driver thing, but I've since changed hardware almost completely and the > hangs persis. I'm now strongly suspecting some kind of interrupt problem. > For the record, I've attached my dmesg output. This is a dual AMD MP 1900+ > (1.6 GHz) Tyan 2466N-4M system. 3Com xl0 ethernet, Adaptec 39160 and 3940 > SCSI, Creative Soundblaster Live! audio, Radeon 8500 128MB video (XFree86 > 4.2). 2GB DDR memory. Short notice regarding fxp0/sym driver problem: Gérard Roudier was very helpful here and sent me a patch against the sym-driver, intended to check for stalled irqs (and work around this issue if possible). In fact for these hangs to occur, I need both fxp0 and sym0 to share the same irq and a SMP system. As said his patch is checking for irq stalls. Without the patch, I'd only get "fxp0: device timeout", and both sym0 and fxp0 would hang (could be freed with "ifconfig fxp0 down; ifconfig fxp0 up", if ifconfig was already loaded into RAM at that time...) With his patch, I still get "fxp0: device timeout", but the sym driver would still be able to process outstanding irqs, and fxp0 also frees itself after a short time (a few seconds). Triggering via a simple "ping -f". My guess is that the problems are not necessarily fxp- or sym-related, but general irq handling problems. Due to code optimization, timing might be more critical, so a broader range of systems might be affected (stable had several postings with similar hangs with a broad range of different hardware). Regards, Holger -- Holger Kipp, Dipl.-Math., Systemadministrator | alogis AG Fon: +49 (0)30 / 43 65 8 - 114 | Berliner Strasse 26 Fax: +49 (0)30 / 43 65 8 - 214 | D-13507 Berlin Tegel email: [EMAIL PROTECTED] | http://www.alogis.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
kernel thread
Hi, how can I destroy a kernel thread that I previously created? Regards, Ferruccio To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel thread
Ferruccio Vitale wrote: >Hi, > >how can I destroy a kernel thread that I previously created? >Regards, > >Ferruccio > > >To Unsubscribe: send mail to [EMAIL PROTECTED] >with "unsubscribe freebsd-hackers" in the body of the message > > man ktread_shutdown To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Çѹ¹Õé¤Ø³´ÙáÅÊØ¢ÀÒ¾áÅéÇËÃ×ÍÂѧ
á¹Ð¹Óâ»Ãá¡ÃÁ¤Çº¤ØÁ¹éÓ˹ѡ à¾ÔèÁ¹éÓ˹ѡ ÃÑ¡ÉÒÊØ¢ÀÒ¾ ¤Ø³ËÃ×ͤ¹·Õè¤Ø³ÃÑ¡¡ÓÅѧÁͧËÒÇÔ¸Õ´ÙáÅÊØ¢ÀÒ¾·Õèà»ç¹¸ÃÃÁªÒµÔÍÂÙèãªèäËÁ? ËÒ¡¤Ø³àº×èÍ˹èÒ¡Ѻ¤ÇÒÁ¾ÂÒÂÒÁ·ÕèäÁè»ÃÐʺ¤ÇÒÁÊÓàÃ稤ÃÑé§áÅéǤÃÑé§àÅèÒ ã¹¡ÒôÙáÅÊØ¢ÀÒ¾à¾×èÍÃÙ»ÃèÒ§·Õè´Õ àÃÒÁÕâ»Ãá¡ÃÁâÀª¹Ò¡ÒÃà¾×èÍÊØ¢ÀÒ¾ ·ÕèªèǤسä´é ÊÓËÃѺ¼Ùé·ÕèÁÕ»ÑËÒ ¹éÓ˹ѡà¡Ô¹ËÃ×ÍÍéǹ, ¼ÍÁà¡Ô¹ä», ÁÕ»ÑËÒÊØ¢ÀÒ¾ (¼ÍÁáËé§áç¹éÍÂ, ¾Ø§ËéÍÂÍ×´ÍÒ´, ¢Ò´¤ÇÒÁÁÑè¹ã¨, âäÀѶÒÁËÒ,ãºË¹éÒà»ç¹ÊÔÇ, ¼ÔǾÃóàËÕèÂÇÂè¹, ¤¹àÅ蹡ÕÌÒ, ¤Ø³»éÒÇÑ·ͧ, ¤Ø³¹éÍ§æ ·ÕèÍÂÒ¡ÊÇÂ)à»ç¹¼ÅÔµÀѳ±ì¨Ò¡¸ÃÃÁªÒµÔ 100 % äÁèãªèÂÒ äÁèµéͧʹÍÒËÒà äÁèÁռŢéÒ§à¤Õ§ äÁèµéͧÍÍ¡¡ÓÅѧ¡Ò ¿Ñ§´ÙäÁè¹èÒàª×èÍáµè¡çµéͧàª×èÍà¾ÃÒмèÒ¹ ÍÂ.·Ø¡»ÃÐà·È·Õèà¢éÒ仢ÒÂâ´Â੾ÒлÃÐà·Èä·ÂáÅÐÍàÁÃÔ¡Ò ãËéÊÒÃÍÒËÒäú¶éǹ »ÃѺÊÁ´ØŢͧÃèÒ§¡ÒÂÅ´ä¢ÁѹÊèǹà¡Ô¹ ÃѺÃͧ¼ÅÀÒÂã¹30Çѹ´éÇÂÃкº¤×¹à§Ô¹100%(á¾·Âì¼Ùé¤Ô´¤é¹ÍÒËÒÃÊٵùÕé¤×ͤ¹·Õè¤Ô´¤é¹ÍÒËÒÃãËé¹Ñ¡ºÔ¹ÍÇ¡ÒÈͧ¤ì¡ÒùҫèÒ) ʹ㨠¢Í¤Óá¹Ð¹Óà¾ÔèÁàµÔÁä´é·Õè ¤Ø³ÊÔÃÔ 01-8901701¾º¤ÓµÍºÊØ´·éÒ¢ͧ¤Ø³ä´é·Õè¹Õè http://www.smartslender.com/foodforhealth To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel thread
My fault. I am using 5.0 Try this: man shutdown_kproc There was some name changes as shown: HISTORY The kproc_start() function first appeared in FreeBSD 2.2. The kproc_shutdown(), kthread_create(), kthread_exit(), kthread_resume(), kthread_suspend(), and kthread_suspend_check() functions were introduced in FreeBSD 4.0. Prior to FreeBSD 5.0, the kproc_shutdown(), kthread_resume(), kthread_suspend(), and kthread_suspend_check() func- tions were named shutdown_kproc(), resume_kproc(), shutdown_kproc(), and kproc_suspend_loop(), respectively. Sorry about that... Hope this helps... ANdy Ferruccio Vitale wrote: >Andy Sporner wrote: > >>man ktread_shutdown >> >>To Unsubscribe: send mail to [EMAIL PROTECTED] >>with "unsubscribe freebsd-hackers" in the body of the message >> > >I can't find any man pages about it; I searched on the net, grep'ed >/usr/src entirely but any results. >I've freebsd 4.6RC release. > >Any advice? > >Ferruccio > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel thread
Andy Sporner wrote: > > man ktread_shutdown > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message I can't find any man pages about it; I searched on the net, grep'ed /usr/src entirely but any results. I've freebsd 4.6RC release. Any advice? Ferruccio To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 0xdeadxxxx ?
On Sun, Jun 09, 2002 at 11:40:09PM -0700, Terry Lambert wrote: > 0xdeadc162 - 0xdeadc0de = 0x0084 = 132 decimal > > Look for a short value that's getting set to 132. As I said in another email, I think this is td1->td_priority in kern_mutex.c:510. -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel thread
--- Andy Sporner <[EMAIL PROTECTED]> wrote: > My fault. I am using 5.0 > man shutdown_kproc Ok, I cant find any man page called shutdown_kproc in either 4.3 or 4.4. Anyway, he wants to destroy a "thread", and not an "internal" daemon/process. To destroy a kernel thread, you need to make use of the kthread_exit() operation. It is prototyped as follows: void kthread_exit(ecode); The *ecode* arg to kthread_exit() is used to specify the return code of the thread which you are going to terminate. Additonal Information can be found from: kthread(9) -- (available in FreeBSD 5.0) sys/kthread.h HTH. Hiten [EMAIL PROTECTED], [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
interaction between wait(2), ptrace(2), and rfork(2) with flags |= RFLINUXTHPN
Hi, kern_exit.c:wait1() has the following lines in -STABLE: > if ((p->p_sigparent != SIGCHLD) ^ ((uap->options & WLINUXCLONE) != 0)) > continue; As it is, if you ptrace(PT_ATTACH) to a process started with rfork(flags|RFLINUXTHPN), and do a waitpid() as you normally would, this causes waitpid() to fail with ECHILD, because the original parent/child relationship doesn't hold, and the debugger doesn't know that the debugee was started in this fashion. This can also mean that the ptrace(PT_DETACH) ends up killing the process, because you can't guarantee that it is stopped by the time you get to do the ptrace(PT_DETACH). In order to allow existing ptrace(2)-using programs to attach to such processes, would the following be more appropriate? > if ((p->p_sigparent != SIGCHILD && (p->p_flag & PTRACED) == 0) ^ > ((uap->options & WLINUXCLONE) != 0)) (BTW: Why "^" rather than "!=" ? I would have thought a boolean operator more natural here.) Cheers, Peter. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
"cost" of vidcontrol -m ?
http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/39125 presents an interesting hypothesis, namely that vidcontrol -m ought to be enabled by default in usbd.conf. I tend to agree with that premise, but before I commit it I was curious as to what the "cost" of doing this would be. Specifically, I have a usb mouse, but I spend almost all my time in X, so when I need the copy/paste stuff in the console, I just run vidcontrol by hand. It would be more convenient to have it "just work," but I'd hate to screw over low resource users in the proces... Doug -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Fatal trap 12
I have this problem, someone can help me?
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x3090
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01d0a61
stack pointer = 0x10:0xd7ec3e18
frame pointer = 0x10:0xd7ec3e1c
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 71619 (perl)
interrupt mask = net bio cam
trap number = 12
panic: page fault
(kgdb) where
#0 dumpsys () at ../../kern/kern_shutdown.c:474
#1 0xc015530b in boot (howto=256) at ../../kern/kern_shutdown.c:313
#2 0xc0155705 in panic (fmt=0xc0237b4c "%s") at
../../kern/kern_shutdown.c:582
#3 0xc0203b43 in trap_fatal (frame=0xd7ec3dd8, eva=12432) at
../../i386/i386/trap.c:956
#4 0xc02037f1 in trap_pfault (frame=0xd7ec3dd8, usermode=0, eva=12432)
at ../../i386/i386/trap.c:849
#5 0xc0203397 in trap (frame={tf_fs = 2147418128, tf_es = -672399344,
tf_ds = -711196656, tf_edi = 7242816, tf_esi = 12384,
tf_ebp = -672383460, tf_isp = -672383484, tf_ebx = -1062788776,
tf_edx = -1061673196, tf_ecx = 12384, tf_eax = 12465,
tf_trapno = 12, tf_err = 0, tf_eip = -1071838623, tf_cs = 8,
tf_eflags = 66054, tf_esp = -1062788776,
tf_ss = -672383432}) at ../../i386/i386/trap.c:448
#6 0xc01d0a61 in vm_page_remove (m=0xc0a72158) at ../../vm/vm_page.c:455
#7 0xc01d10c4 in vm_page_free_toq (m=0xc0a72158) at ../../vm/vm_page.c:1090
#8 0xc01cf05e in vm_object_terminate (object=0xd7c83060) at
../../vm/vm_page.h:527
#9 0xc01cef2a in vm_object_deallocate (object=0xd7c83060) at
../../vm/vm_object.c:387
#10 0xc01cc32b in vm_map_entry_delete (map=0xd7a5d980, entry=0xd79f36f0)
at ../../vm/vm_map.c:1823
#11 0xc01cc4ad in vm_map_delete (map=0xd7a5d980, start=0,
end=3217031168) at ../../vm/vm_map.c:1926
#12 0xc01cc53a in vm_map_remove (map=0xd7a5d980, start=0,
end=3217031168) at ../../vm/vm_map.c:1951
#13 0xc014d9a4 in exit1 (p=0xd7a08a00, rv=0) at ../../kern/kern_exit.c:219
#14 0xc014d784 in exit1 (p=0xd7a08a00, rv=0) at ../../kern/kern_exit.c:103
#15 0xc0203df9 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 0, tf_esi = -1, tf_ebp = -1077938700,
tf_isp = -672383020, tf_ebx = 672925284, tf_edx = 672924864,
tf_ecx = 674050504, tf_eax = 1, tf_trapno = 0,
tf_err = 2, tf_eip = 672626020, tf_cs = 31, tf_eflags = 659,
tf_esp = -1077938744, tf_ss = 47})
at ../../i386/i386/trap.c:1157
#16 0xc01f8245 in Xint0x80_syscall ()
Cannot access memory at address 0xbfbff5f4.
--
Dominique Arpin___[espace
gestionnaire réseau courbe]
http://www.espacecourbe.com/
téléphone514.933.9861
télécopieur 514.933.9546
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: raidframe
On Wed, May 29, 2002 at 02:18:40PM -0500, Brandon D. Valentine wrote: > If you really want to play with RAIDframe I'd guess you'll have a much > easier time of it under NetBSD, where it is included with the operating > system. Getting it working under FreeBSD could be a lot of fun and you > might learn a lot, but I don't see it being a terribly useful exercise > otherwise. I get the impression that most of us are quite happy with > vinum and would not desire that FreeBSD bloat the kernel by including > two software RAID frameworks. Then again, I speak for noone by myself. You quite speak for yourself. I've seen the FreeBSD community more split 50%-50% in their love-hate of Vinum. Many of us still use ccd(4) because Vinum did not meet our needs. Scott Long had just about ported RAIDframe to FreeBSD, when the bits got lost in a disk crash. So the rumor goes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: raidframe
David O'Brien wrote: > You quite speak for yourself. I've seen the FreeBSD community more split > 50%-50% in their love-hate of Vinum. Many of us still use ccd(4) because > Vinum did not meet our needs. Alfred Perlsteing claims "Vinum comes from the universe where Spock has a beard" (sorry, Greg!). > Scott Long had just about ported RAIDframe to FreeBSD, when the bits got > lost in a disk crash. So the rumor goes. I guess you are talking about a kernel version of the code. I did the original port of the user space version of the code; the patches are still up on freebsd.org. The kernel stuff is harder and easier. I know this seems at first to be contradictory... ;^). Basically, there's NetBSD code for this, and porting NetBSD code to FreeBSD is mostly what I would call "grunt work": not a lot of thinking is required. It's harder, because as FreeBSD changes it's VM system, it becomes harder to keep a lot of things up to date (file systems, etc.). Erez Zadok's code for FiST (Filesystem Stacking Templates) used to work with 4.3, but the changes to 4.5 were significant enough that cache coherency was broken. In any case, it's not like an obscene amount of work had to have been invested by Scott Long to make the thing work, so duplicating it is not tantamount to searching for The Rosetta Stone. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
kernel booting diff between boot2 and loader
I wonder what is different in booting the kernel from loader(8) and from boot2. In vmware2 I am not able to boot the kernel from boot2, it hangs after loading the kernelfile. Using loader it goes fine. I tried current,stable and generic kernels, all without luck. This was not really a problem, until I wanted to use etherboot, where I ofcourse can't use loader. Any help or insight into this will be gladly accepted :-) Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
