From jhb at freebsd.org Mon Dec 1 13:43:45 2008 From: jhb at freebsd.org (John Baldwin) Date: Mon Dec 1 13:43:52 2008 Subject: Gathering Hardware State During a Driver Initiated Kernel Panic In-Reply-To: <492B2306.60404@freebsd.org> References: <5D267A3F22FD854F8F48B3D2B52381933940B2DEFE@IRVEXCHCCR01.corp.ad.broadcom.com> <492B2306.60404@freebsd.org> Message-ID: <200812011505.56535.jhb@freebsd.org> On Monday 24 November 2008 04:56:22 pm Sam Leffler wrote: > David Christensen wrote: > > Is there a method or callback in FreeBSD where a driver can > > be notified that it has caused a kernel panic in order to > > generate a dump of internal hardware state information? I've > > written a sysctl call for manual intervention and can handle > > some "expected" hardware events completely in the driver but > > I don't know of a way to get control again in cases where the > > driver wasn't expecting a failure. > > > > Not sure how one can deduce a driver is at fault but you might define a > ddb command for the driver and invoke that on panic using the ddb script > mechanisms (see ddb(4)). You might be able to set the current 'panic' ddb script function to one you define in your code somehow. That is, set it on entry to bce_start() and then reset it to empty when bce_start() returns. Similarly for the interrupt handler, bce_init(), and bce_ioctl(). I haven't looked to see if there is a clean way to set a script function in C though. -- John Baldwin From raykinsella78 at gmail.com Fri Dec 5 07:09:58 2008 From: raykinsella78 at gmail.com (Ray Kinsella) Date: Fri Dec 5 07:10:04 2008 Subject: Kernel Thread priority in FreeBSD Message-ID: <584ec6bb0812050709p309d406ax7e22d1fad8ad9719@mail.gmail.com> Hi all, I am reposting this from the performance list, as it might be a better forum for the question. I have a problem trying to influence kernel thread scheduling in FreeBSD. There are three threads I am interested the priority of:- a. Enqueue Thread: - Enqueues data in a circular buffer b. Interrupt Handler: - Signals that data in the circular buffer has been processed and in ready for removal - Queues an entry on a task queue so the data is removed from the circular buffer asynchronousily - Data is processed by a pci card c. Task Queue Thread: - Dequeues request from a task queue. - Dequeues data from the circular buffer. *Objective: *I want to prioritise the *Enqueue Thread, *such that it will always executes until the circular buffer is exhausted of space. I want the *Task Queue Thread* to have the lowest priority such that it only runs when the *Enqueue Thread* has no work to do. *Observed behaviour: *I set the *Enqueue Thread, *to have a priority of PRI_MAX_KERN (0) I set the *Task Queue Thread,* to have a priority of PRI_MIN_KERN (64) In the main I see the following scheduling:- ... *Enqueue Thread, *Enqueues serveral requests on the circular buffer *Interrupt Handler*, Interrupts the *Enqueue Thread, *puts requests on a taskqueue for async processing. *Task Queue Thread, *Dequeues the request from a taskqueue and the data from the circular buffer *Enqueue Thread, *Enqueues serveral requests on the circular buffer *Interrupt Handler*, Interrupts the *Enqueue Thread**, *puts requests on a taskqueue for async processing. *Task Queue Thread, *Dequeues the request from a taskqueue and the data from the circular buffer .. No matter what I do with thread priorities, the *Task Queue Thread *always follows the *Interrupt Handler. * *Ideal behaviour* Ideally I would get the following behaviour, were *Enqueue Thread *will always run instead of *Task Queue Thread *thread while it has work to do. *Enqueue Thread, *Enqueues serveral requests on the circular buffer *Interrupt Handler*, Interrupts the *Enqueue Thread, *puts requests on a taskqueue for async processing. *Enqueue Thread, *Enqueues serveral requests on the circular buffer *Interrupt Handler*, Interrupts the *Enqueue Thread**, *puts requests on a taskqueue for async processing. *Enqueue Thread, *Enqueues serveral requests on the circular buffer *Interrupt Handler*, Interrupts the *Enqueue Thread**, *puts requests on a taskqueue for async processing. *Enqueue Thread, *yields timeslices as the circular buffer is maxed out *Task Queue Thread, *Dequeues the request from a taskqueue and the data from the circular buffer *Task Queue Thread, *Dequeues the request from a taskqueue and the data from the circular buffer *Task Queue Thread, *Dequeues the request from a taskqueue and the data from the circular buffer Any idea's how to encourage the scheduler to adopt this behaviour ? Thanks Ray Kinsella * * From espartano.mail at gmail.com Sun Dec 7 21:07:14 2008 From: espartano.mail at gmail.com (Espartano) Date: Sun Dec 7 21:07:20 2008 Subject: Driver Iwn in FreeBSD 7.1 ? Message-ID: Hi list, Someone know if the driver iwn will be included officially in FreeBSD 7.1 ? -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Social Engineer -> Because there is no patch for human stupidity" "The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep." "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." From espartano.mail at gmail.com Mon Dec 8 20:04:58 2008 From: espartano.mail at gmail.com (Espartano) Date: Mon Dec 8 20:05:04 2008 Subject: how to program a driver? Message-ID: hi people first and foremost apologize me for my bad english I have a little question, if i want to understand how work a net driver, what things i will need to learn? Actually i know how to program with C language in a basic level but i don't know nothing about hardware or computer organization, what topics i should study for gain knowledges about net-drivers ? or if someone can recommend me books about this topic i will be very thankful. thanks in advance. -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Social Engineer -> Because there is no patch for human stupidity" "The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep." "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." From walsimou at walsimou.com Tue Dec 9 04:02:43 2008 From: walsimou at walsimou.com (Gaye Abdoulaye Walsimou) Date: Tue Dec 9 04:02:50 2008 Subject: how to program a driver? In-Reply-To: References: Message-ID: <493E5C0E.9070002@walsimou.com> Espartano wrote: > hi people first and foremost apologize me for my bad english I have a > little question, if i want to understand how work a net driver, what > things i will need to learn? > > Actually i know how to program with C language in a basic level but i > don't know nothing about hardware or computer organization, what > topics i should study for gain knowledges about net-drivers ? or if > someone can recommend me books about this topic i will be very > thankful. > > thanks in advance. > > > > Unfortunately FreeBSD is poorly documented when it's about driver and kernel programming, compared to Linux (in my humble opinion). That's why, to begin learning and experimenting, I recommand you to start with Linux. 3 books: Linux Device Drivers Building Embedded Linux Systems (for embedded systems) Understanding the Linux Kernel Regards From gabor.horvath1 at t-online.hu Tue Dec 9 06:47:40 2008 From: gabor.horvath1 at t-online.hu (=?ISO-8859-2?Q?Horv=E1th_G=E1bor?=) Date: Tue Dec 9 06:47:48 2008 Subject: driver Message-ID: <493E806C.6020904@t-online.hu> BMC5906M Boardcom driver for XP AR5006 family wifi driver for Acer Aspire 5715Z From buddabrod at gmail.com Tue Dec 9 09:27:30 2008 From: buddabrod at gmail.com (Dennis Brendel) Date: Tue Dec 9 09:27:37 2008 Subject: Backported iwn for Freebsd 7.0 Message-ID: <200812091801.00170.dbrendel@physik.uni-kl.de> Hey there, I grabbed a backported version of the iwn driver for my iwl4965 from http://lists.freebsd.org/pipermail/freebsd-stable/2008-September/045234.html and patched my kernel tree (I'm using 7.1-RC1). It applied cleanly so I tried it out.. Result: System crash, all I got was http://e.imagehost.org/view/0024/IMG_1822 and http://e.imagehost.org/view/0302/IMG_1823 I'd really like to see this driver in 7.1.. I downgraded from 8-current to 7.1 since I someone told me that iwn is in 7.1, too and I was so stupid to listen and not check by myself first. I think I am not the only one who is interested in this driver being in a (almost) stable version. Maybe the already backported one is easy to fix? Thanks in advance for any responses From elbarto at arcadebsd.org Tue Dec 9 13:46:10 2008 From: elbarto at arcadebsd.org (ElBarto) Date: Tue Dec 9 13:46:41 2008 Subject: USB Joystick/gamepad driver Message-ID: <493EE331.8070708@arcadebsd.org> Hello all, I've started a driver for usb joystick and gamepad. The goal of this driver is to have a complete support for HID and non-HID device. For now it support HID device and (partially) the Xbox360 gamepad. The driver create a ujoy%d device in /dev . For now the data are like this : AXIS_X AXIS_Y AXIS_Z AXIS_RX AXIS_RY AXIS_RZ SLIDER HAT_SWITCH BUTTONS All coded in one int each. I'll next add some ioctl to, for example, find which axis is present for the joystick etc .... There is of course no userland application which support this driver, I'm planning to re-do the sdl support for this driver, but before I want to standardize the driver. You can download the driver and a small crappy userland application here : http://www.arcadebsd.org/~elbarto/ujoy.tgz This has been tested on FreeBSD 7.0 with two different Thrustmaster gamepad and a Xbox360 one. Comments ? Suggestions ? -- Emmanuel Vadot elbarto@arcadebsd.org From Benjamin.Close at clearchain.com Tue Dec 9 17:36:34 2008 From: Benjamin.Close at clearchain.com (Benjamin Close) Date: Tue Dec 9 17:36:41 2008 Subject: Driver Iwn in FreeBSD 7.1 ? In-Reply-To: References: Message-ID: <493F18AE.1060200@clearchain.com> Hi Espartano, I don't believe there is any plans to include it in 7.1 due to api differences. Cheers, Benjamin On 8/12/2008 3:14 PM, Espartano wrote: > Hi list, Someone know if the driver iwn will be included officially in > FreeBSD 7.1 ? > > From espartano.mail at gmail.com Tue Dec 9 18:54:37 2008 From: espartano.mail at gmail.com (Espartano) Date: Tue Dec 9 18:54:44 2008 Subject: Driver Iwn in FreeBSD 7.1 ? In-Reply-To: <493F18AE.1060200@clearchain.com> References: <493F18AE.1060200@clearchain.com> Message-ID: On Tue, Dec 9, 2008 at 7:17 PM, Benjamin Close wrote: > Hi Espartano, > I don't believe there is any plans to include it in 7.1 due to api > differences. > > Cheers, > Benjamin > mmmm but .... I can download the driver and compile it in FreeBSD 7.1 like with 7.0 STABLE ? or the driver is incompatible with 7.1 ? -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Social Engineer -> Because there is no patch for human stupidity" "The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep." "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." From Benjamin.Close at clearchain.com Tue Dec 9 18:57:35 2008 From: Benjamin.Close at clearchain.com (Benjamin Close) Date: Tue Dec 9 18:57:43 2008 Subject: Driver Iwn in FreeBSD 7.1 ? In-Reply-To: References: <493F18AE.1060200@clearchain.com> Message-ID: <493F3015.1010307@clearchain.com> On 10/12/2008 1:24 PM, Espartano wrote: > On Tue, Dec 9, 2008 at 7:17 PM, Benjamin Close > wrote: > >> Hi Espartano, >> I don't believe there is any plans to include it in 7.1 due to api >> differences. >> >> Cheers, >> Benjamin >> >> > > > mmmm but .... I can download the driver and compile it in FreeBSD 7.1 > like with 7.0 STABLE ? or the driver is incompatible with 7.1 > The stablest version of the driver is in -Current. If your grabbing the perforce version referred to at http://www.clearchain.com/wiki/Iwn (See: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/iwn/ For the latest version) Cheers, Benjamin From espartano.mail at gmail.com Tue Dec 9 19:40:32 2008 From: espartano.mail at gmail.com (Espartano) Date: Tue Dec 9 19:40:38 2008 Subject: Driver Iwn in FreeBSD 7.1 ? In-Reply-To: <493F3015.1010307@clearchain.com> References: <493F18AE.1060200@clearchain.com> <493F3015.1010307@clearchain.com> Message-ID: On Tue, Dec 9, 2008 at 8:57 PM, Benjamin Close wrote: > On 10/12/2008 1:24 PM, Espartano wrote: >> >> On Tue, Dec 9, 2008 at 7:17 PM, Benjamin Close >> wrote: >> >>> >>> Hi Espartano, >>> I don't believe there is any plans to include it in 7.1 due to api >>> differences. >>> >>> Cheers, >>> Benjamin >>> >>> >> >> >> mmmm but .... I can download the driver and compile it in FreeBSD 7.1 >> like with 7.0 STABLE ? or the driver is incompatible with 7.1 >> > > The stablest version of the driver is in -Current. > If your grabbing the perforce version referred to at > http://www.clearchain.com/wiki/Iwn > > (See: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/iwn/ > For the latest version) > > Cheers, > Benjamin > :O thanks a lot, when FreeBSD 7.1 will be released I will try to use the driver :) -- "Linux is for people who hate Windows, BSD is for people who love UNIX". "Social Engineer -> Because there is no patch for human stupidity" "The Unix Guru's View of Sex unzip ; strip ; touch ; grep ; finger ; mount ; fsck ; more ; yes ; umount ; sleep." "Documentation is like sex: when it is good, it is very, very good; and when it is bad, it is better than nothing." From itavy at itavy.com Sun Dec 14 14:53:57 2008 From: itavy at itavy.com (Octavian Ionescu) Date: Sun Dec 14 14:54:03 2008 Subject: driver for wireless asus eeepc (rt2860) Message-ID: <49458E76.7090407@itavy.com> hi, i have compiled the module for rt2860 using ndis. everything worked almost fine except a few error messages one of them wich is very frustrating # uname -a FreeBSD 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Sat Dec 6 17:17:09 UTC 2008 root@:/usr/obj/usr/src/sys/ITAVYEEE2 i386 #pciconf -lv .... ndis0@pci0:1:0:0: class=0x028000 card=0x27901814 chip=0x07811814 rev=0x00 hdr=0x00 vendor = 'Ralink Technology, Corp' class = network Dec 14 22:46:03 kernel: ndis0: <802.11n Wireless LAN Card> mem 0xfbef0000-0xfbefffff irq 19 at device 0.0 on pci1 Dec 14 22:46:03 kernel: ndis0: [ITHREAD] Dec 14 22:46:03 kernel: ndis0: NDIS API version: 5.0 *Dec 14 22:46:04 kernel: NDIS: open file /compat/ndis/rate.bin failed: 2* i can transfer files and i have installed some ports but when i try to cvsup to update the src's i get the following error and nothing is updating: TreeList failed: Network write failure: Connection closed i have had to go back on wired connection and on it i could update the src without any problem -- Best regards, Octavian From itavy at itavy.com Sun Dec 14 14:56:55 2008 From: itavy at itavy.com (Octavian Ionescu) Date: Sun Dec 14 14:57:02 2008 Subject: Driver for DWL-G122 rev C1 Message-ID: <49458F28.4000206@itavy.com> hi, i have an Wireless USB DWL-G122 rev c1 card and on current itblocks my computer after a while. it scans for ap after i have configured it but after 2-3 minutes of scaning hang the entire computer and give me an backtrace prompt. # uname -a FreeBSD 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Sat Dec 6 17:17:09 UTC 2008 root@:/usr/obj/usr/src/sys/ITAVYEEE2 i386 #dmesg .... Dec 14 22:40:28 kernel: rum0: on uhub4 Dec 14 22:40:28 kernel: rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 Dec 14 22:40:28 kernel: rum0: WARNING: using obsoleted IFF_NEEDSGIANT flag #usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb3: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 addr 2: full speed, self powered, config 1, BT-253(0xb700), Broadcom Corp(0x0b05), rev 2.41 port 2 powered Controller /dev/usb4: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), Intel(0x0000), rev 1.00 port 1 powered port 2 addr 3: high speed, power 300 mA, config 1, 802.11 bg WLAN(0x3c03), Ralink(0x07d1), rev 0.01 port 3 powered port 4 powered port 5 powered port 6 powered port 7 powered port 8 addr 2: high speed, power 500 mA, config 1, CNF7129(0xb071), Chicony Electronics Co., Ltd.(0x04f2), rev 15.44 can anyone help me about this one? Thank you, -- Best regards, Octavian From info at chevron.com.sg Mon Dec 15 03:00:12 2008 From: info at chevron.com.sg (Chevron Texaco Oil and Gas Company) Date: Mon Dec 15 03:00:22 2008 Subject: CONTACT OUR ZONE F BRANCH OFFICE Message-ID: <200812151041.mBFAffa8017738@vux25.mgt.hosting.dc2.netsol.com> Attn: Dear Email Owner. I am Mrs. Chin Wool, the Company's secretary to Chevron Texaco Oil and Gas Company In Singapore (ASIA DISTRICT). If this email address is yours, congratulation to you, as we have a life transforming news for you. For more information kindly contact our Zone F,United Kingdom branch. Mr Peter Hamilton. email:peterhamilton33@live.com Yours Faithfully, Chin Wool (Mrs) For the Chief Executive Officer (CEO), Chevron Texaco Oil and Gas Company, Singapore, Asia. From onemda at gmail.com Mon Dec 15 04:36:07 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Dec 15 04:36:15 2008 Subject: driver for wireless asus eeepc (rt2860) In-Reply-To: <49458E76.7090407@itavy.com> References: <49458E76.7090407@itavy.com> Message-ID: <3a142e750812150428y1ab873cdy82442c15d97462d4@mail.gmail.com> On 12/14/08, Octavian Ionescu wrote: > hi, > > i have compiled the module for rt2860 using ndis. everything worked > almost fine except a few error messages one of them wich is very > frustrating > # uname -a > FreeBSD 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Sat Dec 6 17:17:09 UTC > 2008 root@:/usr/obj/usr/src/sys/ITAVYEEE2 i386 > > #pciconf -lv > .... > ndis0@pci0:1:0:0: class=0x028000 card=0x27901814 chip=0x07811814 > rev=0x00 hdr=0x00 > vendor = 'Ralink Technology, Corp' > class = network > > Dec 14 22:46:03 kernel: ndis0: <802.11n Wireless LAN Card> mem > 0xfbef0000-0xfbefffff irq 19 at device 0.0 on pci1 > Dec 14 22:46:03 kernel: ndis0: [ITHREAD] > Dec 14 22:46:03 kernel: ndis0: NDIS API version: 5.0 > *Dec 14 22:46:04 kernel: NDIS: open file /compat/ndis/rate.bin failed: 2* This looks like firmware file. Do you have put rate.bin file with others INF and SYS files when using ndisgen(8)? If not than you can: rebuild miniport driver with ndisgen, including all firmware files. or create /compat/ndis/ directory and put rate.bin in it. > > i can transfer files and i have installed some ports but when i try to > cvsup to update the src's i get the following error and nothing is updating: > TreeList failed: Network write failure: Connection closed > > i have had to go back on wired connection and on it i could update the -- Paul From onemda at gmail.com Mon Dec 15 04:52:35 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Mon Dec 15 04:52:41 2008 Subject: Driver for DWL-G122 rev C1 In-Reply-To: <49458F28.4000206@itavy.com> References: <49458F28.4000206@itavy.com> Message-ID: <3a142e750812150423w168620f7g40e93cf61f6a3b7b@mail.gmail.com> On 12/14/08, Octavian Ionescu wrote: > hi, > > i have an Wireless USB DWL-G122 rev c1 card and on current itblocks my > computer after a while. it scans for ap after i have configured it but > after 2-3 minutes of scaning hang the entire computer and give me an > backtrace prompt. > > # uname -a > FreeBSD 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Sat Dec 6 17:17:09 UTC > 2008 root@:/usr/obj/usr/src/sys/ITAVYEEE2 i386 > > #dmesg > .... > Dec 14 22:40:28 kernel: rum0: 2.00/0.01, addr 3> on uhub4 > Dec 14 22:40:28 kernel: rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 > Dec 14 22:40:28 kernel: rum0: WARNING: using obsoleted IFF_NEEDSGIANT flag Let me guess you have SMP machine with SMP enabled kernel? In that case usb ehci have some bugs triggered with rum driver. Workaround: disable smp: # echo "kern.smp.disabled=1" >> /boot/loader.conf and reboot. Fix: use if_rum2 from usb2: # echo "usb2_wlan_rum_load=YES" >> /boot/loader.conf For this one to really work you need first to remove usb,uhci,ehci,ohci and others old usb stuff from kernel conf, and use usb2 as modules ... -- Paul From itavy at itavy.com Mon Dec 15 05:44:45 2008 From: itavy at itavy.com (Octavian Ionescu) Date: Mon Dec 15 05:44:51 2008 Subject: Driver for DWL-G122 rev C1 In-Reply-To: <3a142e750812150423w168620f7g40e93cf61f6a3b7b@mail.gmail.com> References: <49458F28.4000206@itavy.com> <3a142e750812150423w168620f7g40e93cf61f6a3b7b@mail.gmail.com> Message-ID: <20081215074442.u7fju0xwysgckc0c@www.itavy.com> hi, yes i have SMP enabled. i will recompile the kernel with the new options and i will let yuo know. Thank you -- Octavian Quoting "Paul B. Mahol" : > On 12/14/08, Octavian Ionescu wrote: >> hi, >> >> i have an Wireless USB DWL-G122 rev c1 card and on current itblocks my >> computer after a while. it scans for ap after i have configured it but >> after 2-3 minutes of scaning hang the entire computer and give me an >> backtrace prompt. >> >> # uname -a >> FreeBSD 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Sat Dec 6 17:17:09 UTC >> 2008 root@:/usr/obj/usr/src/sys/ITAVYEEE2 i386 >> >> #dmesg >> .... >> Dec 14 22:40:28 kernel: rum0: > 2.00/0.01, addr 3> on uhub4 >> Dec 14 22:40:28 kernel: rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 >> Dec 14 22:40:28 kernel: rum0: WARNING: using obsoleted IFF_NEEDSGIANT flag > > Let me guess you have SMP machine with SMP enabled kernel? > In that case usb ehci have some bugs triggered with rum driver. > > Workaround: disable smp: > # echo "kern.smp.disabled=1" >> /boot/loader.conf and reboot. > > Fix: > use if_rum2 from usb2: > > # echo "usb2_wlan_rum_load=YES" >> /boot/loader.conf > > For this one to really work you need first to remove usb,uhci,ehci,ohci and > others old usb stuff from kernel conf, and use usb2 as modules ... > > > -- > Paul > From freebsd at sopwith.solgatos.com Mon Dec 15 21:23:49 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Mon Dec 15 21:23:55 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost Message-ID: <200812150330.DAA27074@sopwith.solgatos.com> I found the source of this problem. When a firewire bus resets, the firewire driver prints a few lines to the console, using printf(9) and device_printf(9). I suspect that these are running at splfw aka splimp, locking out other i/o. Commenting out the *printf() calls fixes the problem, but that isn't a good solution. Would changing the *printf() calls to log(9) calls be safe? ("safe" meaning other i/o doesn't get locked out) Ah, for the good old days when 19200 baud seemed fast... From ikob at ni.aist.go.jp Mon Dec 15 21:35:08 2008 From: ikob at ni.aist.go.jp (Katsushi Kobayashi) Date: Mon Dec 15 21:35:46 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: <200812150330.DAA27074@sopwith.solgatos.com> References: <200812150330.DAA27074@sopwith.solgatos.com> Message-ID: <15EB8FB3-CAA8-4834-9979-912508B619D4@ni.aist.go.jp> Hi, I believe no side effect is anticipated the message. "side effect" includes locking i/o. ---- Katsushi Kobayashi On 2008/12/15, at 4:30, Dieter wrote: > I found the source of this problem. When a firewire bus resets, > the firewire driver prints a few lines to the console, > using printf(9) and device_printf(9). I suspect that these are > running at splfw aka splimp, locking out other i/o. > > Commenting out the *printf() calls fixes the problem, but that > isn't a good solution. > > Would changing the *printf() calls to log(9) calls be safe? > ("safe" meaning other i/o doesn't get locked out) > > Ah, for the good old days when 19200 baud seemed fast... > _______________________________________________ > freebsd-firewire@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-firewire > To unsubscribe, send any mail to "freebsd-firewire-unsubscribe@freebsd.org" From imp at bsdimp.com Mon Dec 15 22:03:20 2008 From: imp at bsdimp.com (Warner Losh) Date: Mon Dec 15 22:03:32 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: <200812150330.DAA27074@sopwith.solgatos.com> References: <200812150330.DAA27074@sopwith.solgatos.com> Message-ID: <20081215.230130.74702477.imp@bsdimp.com> > I found the source of this problem. When a firewire bus resets, > the firewire driver prints a few lines to the console, > using printf(9) and device_printf(9). I suspect that these are > running at splfw aka splimp, locking out other i/o. This can't be the case. There's no SPL involved at all. Maybe removing the printfs causes an interrupt to be serviced faster, resulting in what appears to be better performance... > Commenting out the *printf() calls fixes the problem, but that > isn't a good solution. > > Would changing the *printf() calls to log(9) calls be safe? > ("safe" meaning other i/o doesn't get locked out) > > Ah, for the good old days when 19200 baud seemed fast... > _______________________________________________ > freebsd-drivers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-drivers > To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" > > From itavy at itavy.com Mon Dec 15 23:36:39 2008 From: itavy at itavy.com (Octavian Ionescu) Date: Mon Dec 15 23:36:46 2008 Subject: Driver for DWL-G122 rev C1 In-Reply-To: <20081215074442.u7fju0xwysgckc0c@www.itavy.com> References: <49458F28.4000206@itavy.com> <3a142e750812150423w168620f7g40e93cf61f6a3b7b@mail.gmail.com> <20081215074442.u7fju0xwysgckc0c@www.itavy.com> Message-ID: <20081216013637.0pal212d4w0sk4k4@www.itavy.com> hi, i have recompiled and everything have worked very good :) now i am able to use my notebook without having to stay just at my desk :) btw where i cad read a little more about those dependencies like SMP enabled -> have to use usb2. i have searched on google about how to enable usb2 on the kernel but i found just exemples of kernel config's and not why it shoul dbe used. Thank you, -- Octavian Quoting Octavian Ionescu : > hi, > > yes i have SMP enabled. i will recompile the kernel with the new > options and i will let yuo know. > > Thank you > -- > Octavian > > > Quoting "Paul B. Mahol" : > >> On 12/14/08, Octavian Ionescu wrote: >>> hi, >>> >>> i have an Wireless USB DWL-G122 rev c1 card and on current itblocks my >>> computer after a while. it scans for ap after i have configured it but >>> after 2-3 minutes of scaning hang the entire computer and give me an >>> backtrace prompt. >>> >>> # uname -a >>> FreeBSD 8.0-CURRENT FreeBSD 8.0-CURRENT #2: Sat Dec 6 17:17:09 UTC >>> 2008 root@:/usr/obj/usr/src/sys/ITAVYEEE2 i386 >>> >>> #dmesg >>> .... >>> Dec 14 22:40:28 kernel: rum0: >> 2.00/0.01, addr 3> on uhub4 >>> Dec 14 22:40:28 kernel: rum0: MAC/BBP RT2573 (rev 0x2573a), RF RT2528 >>> Dec 14 22:40:28 kernel: rum0: WARNING: using obsoleted IFF_NEEDSGIANT flag >> >> Let me guess you have SMP machine with SMP enabled kernel? >> In that case usb ehci have some bugs triggered with rum driver. >> >> Workaround: disable smp: >> # echo "kern.smp.disabled=1" >> /boot/loader.conf and reboot. >> >> Fix: >> use if_rum2 from usb2: >> >> # echo "usb2_wlan_rum_load=YES" >> /boot/loader.conf >> >> For this one to really work you need first to remove usb,uhci,ehci,ohci and >> others old usb stuff from kernel conf, and use usb2 as modules ... >> >> >> -- >> Paul >> > > > > _______________________________________________ > freebsd-drivers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-drivers > To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" From onemda at gmail.com Tue Dec 16 02:44:12 2008 From: onemda at gmail.com (Paul B. Mahol) Date: Tue Dec 16 02:44:19 2008 Subject: Driver for DWL-G122 rev C1 In-Reply-To: <20081216013637.0pal212d4w0sk4k4@www.itavy.com> References: <49458F28.4000206@itavy.com> <3a142e750812150423w168620f7g40e93cf61f6a3b7b@mail.gmail.com> <20081215074442.u7fju0xwysgckc0c@www.itavy.com> <20081216013637.0pal212d4w0sk4k4@www.itavy.com> Message-ID: <3a142e750812160244y7e8b703cw55766d802f480631@mail.gmail.com> On 12/16/08, Octavian Ionescu wrote: > hi, > > i have recompiled and everything have worked very good :) now i am > able to use my notebook without having to stay just at my desk :) > > btw where i cad read a little more about those dependencies like SMP > enabled -> have to use usb2. It is not dependencies, it just old usb stack current state - buggy ehci(4) > i have searched on google about how to enable usb2 on the kernel but i > found just exemples of kernel config's and not why it shoul dbe used. Stop top posting, and than start reading manual pages and source code. -- Paul From freebsd at sopwith.solgatos.com Tue Dec 16 21:10:24 2008 From: freebsd at sopwith.solgatos.com (Dieter) Date: Tue Dec 16 21:10:35 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: Your message of "Tue, 16 Dec 2008 09:51:44 PST." <4947EAB0.3020704@miralink.com> Message-ID: <200812170329.DAA17848@sopwith.solgatos.com> Sean> Which file in dev/firewire are you looking at? fwohci.c and firewire.c examples: printf("non CYCLEMASTER mode\n"); device_printf(fc->dev, "Initiate bus reset\n"); ------------------- Warner> This can't be the case. There's no SPL involved at all. Maybe Warner> removing the printfs causes an interrupt to be serviced faster, Warner> resulting in what appears to be better performance... With the printfs, Ethernet is not getting serviced. This is repeatable and easily reproduced. Without the printfs, it seems ok. If it isn't spl, what is locking out Ethernet? From imp at bsdimp.com Tue Dec 16 23:00:26 2008 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Dec 16 23:00:37 2008 Subject: kern/118093: firewire bus reset hogs CPU, causing data to be lost In-Reply-To: <200812170329.DAA17848@sopwith.solgatos.com> References: <4947EAB0.3020704@miralink.com> <200812170329.DAA17848@sopwith.solgatos.com> Message-ID: <20081216.235941.1266245051.imp@bsdimp.com> In message: <200812170329.DAA17848@sopwith.solgatos.com> Dieter writes: : Sean> Which file in dev/firewire are you looking at? : : fwohci.c and firewire.c : : examples: : : printf("non CYCLEMASTER mode\n"); : : device_printf(fc->dev, "Initiate bus reset\n"); : : ------------------- : : Warner> This can't be the case. There's no SPL involved at all. Maybe : Warner> removing the printfs causes an interrupt to be serviced faster, : Warner> resulting in what appears to be better performance... : : With the printfs, Ethernet is not getting serviced. This : is repeatable and easily reproduced. Without the printfs, : it seems ok. : : If it isn't spl, what is locking out Ethernet? interrupt storm? In old-spl-locked drivers, often times the interrupt would be masked while certain operations happened. In new mutex-locked freebsd, there's no way to block the interrupts, so sometimes old code gets into an interrupt storm, which starves other things. Not sure why printf would trigger this, however... Warner From elbarto at arcadebsd.org Sat Dec 20 01:08:20 2008 From: elbarto at arcadebsd.org (ElBarto) Date: Sat Dec 20 01:08:27 2008 Subject: USB Joystick/gamepad driver In-Reply-To: <493EE331.8070708@arcadebsd.org> References: <493EE331.8070708@arcadebsd.org> Message-ID: <494CB5A8.50509@arcadebsd.org> ElBarto wrote: > Hello all, > > I've started a driver for usb joystick and gamepad. > The goal of this driver is to have a complete support for HID and > non-HID device. > For now it support HID device and (partially) the Xbox360 gamepad. > > The driver create a ujoy%d device in /dev . > For now the data are like this : > > AXIS_X AXIS_Y AXIS_Z AXIS_RX AXIS_RY AXIS_RZ SLIDER HAT_SWITCH BUTTONS > All coded in one int each. > > I'll next add some ioctl to, for example, find which axis is present > for the joystick etc .... > > There is of course no userland application which support this driver, > I'm planning to re-do the sdl support > for this driver, but before I want to standardize the driver. > > You can download the driver and a small crappy userland application > here : > http://www.arcadebsd.org/~elbarto/ujoy.tgz > > > This has been tested on FreeBSD 7.0 with two different Thrustmaster > gamepad and a Xbox360 one. > > Comments ? Suggestions ? > Hello again, I've updated the driver, it's now more clean. Now it has a struct ujoy to read the data, the struct is like this : struct ujoy_axis { char present; int value; int min; int max; }; struct ujoy { struct ujoy_axis axis[UJOY_MAXAXIS]; unsigned int hat; unsigned int buttons; }; The value of the axis are as they are read at the joystick. Some joystick/gamepad send value from -127->+127 others from 0->255 etc ... But I think it's to the userland application to decide what to do, that's why I give the min and max of each axis. For what I know the max number of axis of an USB joystick/gamepad is 7 (X, Y, Z, RX, RY, RX, SLIDER) but I may but wrong, if you have an usb joystick please try this driver and tell me if all your axis are not recognize. I've tried to get the name of the device to have a ioctl to get it, but all my attempts were unsuccessful. The drivers has been tried on FreeBSD-7.0-RELEASE-p6 with two thrustmaster gamepad, one Xbox360 usb and a gamecube usb adapter. I've CC'ed freebsd-usb too. -- Emmanuel Vadot elbarto@arcadebsd.org From rgrover1 at gmail.com Fri Dec 26 13:25:20 2008 From: rgrover1 at gmail.com (Rohit Grover) Date: Fri Dec 26 13:25:27 2008 Subject: Attempting to write a device driver for the macbook's USB trackpad Message-ID: <426bed110812261255s45ad2f82vb874e21165617be7@mail.gmail.com> Hello People, I'm attempting to write a FreeBSD device driver for the USB trackpad on my macbook. The trackpad is an HID class device. Parsing the HID report descriptor (fetched from an invocation of usbd_read_report_desc()) for this device results in the following information: Legend: : input: page: 0x9; usage: 0x1; reportID: 2 size: 1, count: 1, loc: 0 input: page: 0x9; usage: 0x2; reportID: 2 size: 1, count: 1, loc: 1 input: page: 0x9; usage: 0x3; reportID: 2 size: 1, count: 1, loc: 2 input: page: 0x0; usage: 0x0; reportID: 2 size: 5, count: 1, loc: 3 input: page: 0x1; usage: 0x30; reportID: 2 size: 8, count: 1, loc: 8 input: page: 0x1; usage: 0x31; reportID: 2 size: 8, count: 1, loc: 16 input: page: 0xffff; usage: 0x2; reportID: 5 size: 8, count: 63, loc: 24 collection: page: 0x1; usage: 0x2; collection: 1; collevel: 1, reportID: 0 size: 0, count: 0, loc: 0 collection: page: 0x1; usage: 0x1; collection: 0; collevel: 2, reportID: 0 size: 0, count: 0, loc: 0 collection: page: 0xffff; usage: 0x1; collection: 0; collevel: 1, reportID: 2 size: 8, count: 2, loc: 0 feature: page: 0xffff; usage: 0x4, reportID: 5 size: 8, count: 1, loc: 0 feature: page: 0x0; usage: 0x0, reportID: 5 size: 8, count: 1, loc: 8 feature: page: 0x0; usage: 0x0, reportID: 5 size: 8, count: 1, loc: 16 feature: page: 0x0; usage: 0x0, reportID: 5 size: 8, count: 1, loc: 24 feature: page: 0x0; usage: 0x0, reportID: 5 size: 8, count: 1, loc: 32 feature: page: 0x0; usage: 0x0, reportID: 5 size: 8, count: 1, loc: 40 feature: page: 0x0; usage: 0x0, reportID: 5 size: 8, count: 1, loc: 48 feature: page: 0x0; usage: 0x0, reportID: 5 size: 8, count: 1, loc: 56 feature: page: 0x0; usage: 0x0, reportID: 5 size: 8, count: 1, loc: 64 feature: page: 0x0; usage: 0x0, reportID: 5 size: 8, count: 1, loc: 72 feature: page: 0x0; usage: 0x0, reportID: 5 size: 8, count: 1, loc: 80 feature: page: 0x0; usage: 0x0, reportID: 5 size: 8, count: 1, loc: 88 feature: page: 0x0; usage: 0x0, reportID: 5 size: 8, count: 1, loc: 96 feature: page: 0x0; usage: 0x0, reportID: 5 size: 8, count: 1, loc: 104 feature: page: 0x0; usage: 0x0, reportID: 5 size: 8, count: 1, loc: 112 feature: page: 0x0; usage: 0x0, reportID: 5 size: 8, count: 1, loc: 120 end_collection: page: 0x1; usage: 0x31, reportID: 2 size: 8, count: 2, loc: 0 end_collection: page: 0x0; usage: 0x0, reportID: 2 size: 8, count: 2, loc: 0 end_collection: page: 0xffff; usage: 0x4, reportID: 5 size: 8, count: 16, loc: 0 As can be seen, there are two distinct report IDs being used. Report ID 2 describes the mouse-buttons and XY deltas; and since the generic UMS driver in Freebsd is able to parse these values, the macbook's trackpad is usable. I would like to enhance the ums driver to report information from the pressure sensors--with the hope that this will allow the detection of tap events. I suspect that the reports with ID == 5 will contain this information. Of particular interest to me is the following (from the previous table): input: page: 0xffff; usage: 0x2; reportID: 5 size: 8, count: 63, loc: 24 Unfortunately, this report uses a vendor specific page (0xffff), and therefore will require some reverse engineering before it can be deciphered. I need help with receiving HID reports for both ID == 2 and ID == 5. Currently, the interrupt handler (ums_intr) only parses reports with ID==2. Based on my reading of the code, ums_attach() needs to setup sc->sc_iid and sc->sc_isize based on the report-descriptors fetched from the device; but in the case where there are multiple reportIDs supported by the device, the current setup code uses values from only the first reportID. In order to parse reportID 2, sc->sc_isize is set to a value of 4 bytes: 1 byte for the reportID header, together with 3 bytes for the button/XY-delta values. To accommodate an additional 63 bytes for the input in reportID 5, I am guessing that I should set sc->sc_isize to 68: for the 63 bytes starting at bit offset 24; with allowance for one additional byte which may be necessary to accommodate a reportID header. I still don't know how to initialize sc->sc_iid to handle both report IDs. Can someone please help me with setting up the device to receive reports with both IDs so that I can begin reverse-engineering the vendor-specific content of reportID 5? regards, Rohit. From vince at unsane.co.uk Fri Dec 26 16:41:09 2008 From: vince at unsane.co.uk (Vincent Hoffman) Date: Fri Dec 26 16:41:16 2008 Subject: Attempting to write a device driver for the macbook's USB trackpad In-Reply-To: <426bed110812261255s45ad2f82vb874e21165617be7@mail.gmail.com> References: <426bed110812261255s45ad2f82vb874e21165617be7@mail.gmail.com> Message-ID: <495579A3.4030605@unsane.co.uk> Rohit Grover wrote: > Hello People, > > I'm attempting to write a FreeBSD device driver for the USB trackpad on my > macbook. > Not much help but http://wiki.freebsd.org/AppleMacbook says or implies that Rui Paulo was working on somthing similar under the touchpad section, it might be worth talking to him directly (http://wiki.freebsd.org/RuiPaulo .) > The trackpad is an HID class device. Parsing the HID report descriptor > (fetched from an invocation of usbd_read_report_desc()) for this device > results in the following information: > > Legend: : > > > input: page: 0x9; usage: 0x1; reportID: 2 > size: 1, count: 1, loc: 0 > input: page: 0x9; usage: 0x2; reportID: 2 > size: 1, count: 1, loc: 1 > input: page: 0x9; usage: 0x3; reportID: 2 > size: 1, count: 1, loc: 2 > input: page: 0x0; usage: 0x0; reportID: 2 > size: 5, count: 1, loc: 3 > input: page: 0x1; usage: 0x30; reportID: 2 > size: 8, count: 1, loc: 8 > input: page: 0x1; usage: 0x31; reportID: 2 > size: 8, count: 1, loc: 16 > input: page: 0xffff; usage: 0x2; reportID: 5 > size: 8, count: 63, loc: 24 > collection: page: 0x1; usage: 0x2; collection: 1; collevel: 1, reportID: 0 > size: 0, count: 0, loc: 0 > collection: page: 0x1; usage: 0x1; collection: 0; collevel: 2, reportID: 0 > size: 0, count: 0, loc: 0 > collection: page: 0xffff; usage: 0x1; collection: 0; collevel: 1, reportID: > 2 > size: 8, count: 2, loc: 0 > feature: page: 0xffff; usage: 0x4, reportID: 5 > size: 8, count: 1, loc: 0 > feature: page: 0x0; usage: 0x0, reportID: 5 > size: 8, count: 1, loc: 8 > feature: page: 0x0; usage: 0x0, reportID: 5 > size: 8, count: 1, loc: 16 > feature: page: 0x0; usage: 0x0, reportID: 5 > size: 8, count: 1, loc: 24 > feature: page: 0x0; usage: 0x0, reportID: 5 > size: 8, count: 1, loc: 32 > feature: page: 0x0; usage: 0x0, reportID: 5 > size: 8, count: 1, loc: 40 > feature: page: 0x0; usage: 0x0, reportID: 5 > size: 8, count: 1, loc: 48 > feature: page: 0x0; usage: 0x0, reportID: 5 > size: 8, count: 1, loc: 56 > feature: page: 0x0; usage: 0x0, reportID: 5 > size: 8, count: 1, loc: 64 > feature: page: 0x0; usage: 0x0, reportID: 5 > size: 8, count: 1, loc: 72 > feature: page: 0x0; usage: 0x0, reportID: 5 > size: 8, count: 1, loc: 80 > feature: page: 0x0; usage: 0x0, reportID: 5 > size: 8, count: 1, loc: 88 > feature: page: 0x0; usage: 0x0, reportID: 5 > size: 8, count: 1, loc: 96 > feature: page: 0x0; usage: 0x0, reportID: 5 > size: 8, count: 1, loc: 104 > feature: page: 0x0; usage: 0x0, reportID: 5 > size: 8, count: 1, loc: 112 > feature: page: 0x0; usage: 0x0, reportID: 5 > size: 8, count: 1, loc: 120 > end_collection: page: 0x1; usage: 0x31, reportID: 2 > size: 8, count: 2, loc: 0 > end_collection: page: 0x0; usage: 0x0, reportID: 2 > size: 8, count: 2, loc: 0 > end_collection: page: 0xffff; usage: 0x4, reportID: 5 > size: 8, count: 16, loc: 0 > > As can be seen, there are two distinct report IDs being used. Report ID 2 > describes the mouse-buttons and XY deltas; and since the generic UMS driver > in Freebsd is able to parse these values, the macbook's trackpad is usable. > I would like to enhance the ums driver to report information from the > pressure sensors--with the hope that this will allow the detection of tap > events. > I suspect that the reports with ID == 5 will contain this information. Of > particular interest to me is the following (from the previous table): > > input: page: 0xffff; usage: 0x2; reportID: 5 > size: 8, count: 63, loc: 24 > > Unfortunately, this report uses a vendor specific page (0xffff), and > therefore will require some reverse engineering before it can be deciphered. > > I need help with receiving HID reports for both ID == 2 and ID == 5. > Currently, the interrupt handler (ums_intr) only parses reports with ID==2. > Based on my reading of the code, ums_attach() needs to setup sc->sc_iid and > sc->sc_isize based on the report-descriptors fetched from the device; but in > the case where there are multiple reportIDs supported by the device, the > current setup code uses values from only the first reportID. > > In order to parse reportID 2, sc->sc_isize is set to a value of 4 bytes: 1 > byte for the reportID header, together with 3 bytes for the button/XY-delta > values. > To accommodate an additional 63 bytes for the input in reportID 5, I am > guessing that I should set sc->sc_isize to 68: for the 63 bytes starting at > bit offset 24; with allowance for one additional byte which may be necessary > to accommodate a reportID header. I still don't know how to initialize > sc->sc_iid to handle both report IDs. > > Can someone please help me with setting up the device to receive reports > with both IDs so that I can begin reverse-engineering the vendor-specific > content of reportID 5? > > regards, > Rohit. > _______________________________________________ > freebsd-drivers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-drivers > To unsubscribe, send any mail to "freebsd-drivers-unsubscribe@freebsd.org" > From rgrover1 at gmail.com Fri Dec 26 16:50:40 2008 From: rgrover1 at gmail.com (Rohit Grover) Date: Fri Dec 26 16:50:47 2008 Subject: Attempting to write a device driver for the macbook's USB trackpad In-Reply-To: <495579A3.4030605@unsane.co.uk> References: <426bed110812261255s45ad2f82vb874e21165617be7@mail.gmail.com> <495579A3.4030605@unsane.co.uk> Message-ID: <426bed110812261650l2aa8bd98ic2737830731d64bf@mail.gmail.com> I have contacted Rui Paulo already. He isn't working on a trackpad driver for macbooks. :( On Sat, Dec 27, 2008 at 1:41 PM, Vincent Hoffman wrote: > Rohit Grover wrote: > > Hello People, > > > > I'm attempting to write a FreeBSD device driver for the USB trackpad on > my > > macbook. > > > Not much help but http://wiki.freebsd.org/AppleMacbook says or implies > that Rui Paulo was working on somthing similar under the touchpad > section, it might be worth talking to him directly > (http://wiki.freebsd.org/RuiPaulo .) > > The trackpad is an HID class device. Parsing the HID report descriptor > > (fetched from an invocation of usbd_read_report_desc()) for this device > > results in the following information: > > > > Legend: : > > > > > > input: page: 0x9; usage: 0x1; reportID: 2 > > size: 1, count: 1, loc: 0 > > input: page: 0x9; usage: 0x2; reportID: 2 > > size: 1, count: 1, loc: 1 > > input: page: 0x9; usage: 0x3; reportID: 2 > > size: 1, count: 1, loc: 2 > > input: page: 0x0; usage: 0x0; reportID: 2 > > size: 5, count: 1, loc: 3 > > input: page: 0x1; usage: 0x30; reportID: 2 > > size: 8, count: 1, loc: 8 > > input: page: 0x1; usage: 0x31; reportID: 2 > > size: 8, count: 1, loc: 16 > > input: page: 0xffff; usage: 0x2; reportID: 5 > > size: 8, count: 63, loc: 24 > > collection: page: 0x1; usage: 0x2; collection: 1; collevel: 1, reportID: > 0 > > size: 0, count: 0, loc: 0 > > collection: page: 0x1; usage: 0x1; collection: 0; collevel: 2, reportID: > 0 > > size: 0, count: 0, loc: 0 > > collection: page: 0xffff; usage: 0x1; collection: 0; collevel: 1, > reportID: > > 2 > > size: 8, count: 2, loc: 0 > > feature: page: 0xffff; usage: 0x4, reportID: 5 > > size: 8, count: 1, loc: 0 > > feature: page: 0x0; usage: 0x0, reportID: 5 > > size: 8, count: 1, loc: 8 > > feature: page: 0x0; usage: 0x0, reportID: 5 > > size: 8, count: 1, loc: 16 > > feature: page: 0x0; usage: 0x0, reportID: 5 > > size: 8, count: 1, loc: 24 > > feature: page: 0x0; usage: 0x0, reportID: 5 > > size: 8, count: 1, loc: 32 > > feature: page: 0x0; usage: 0x0, reportID: 5 > > size: 8, count: 1, loc: 40 > > feature: page: 0x0; usage: 0x0, reportID: 5 > > size: 8, count: 1, loc: 48 > > feature: page: 0x0; usage: 0x0, reportID: 5 > > size: 8, count: 1, loc: 56 > > feature: page: 0x0; usage: 0x0, reportID: 5 > > size: 8, count: 1, loc: 64 > > feature: page: 0x0; usage: 0x0, reportID: 5 > > size: 8, count: 1, loc: 72 > > feature: page: 0x0; usage: 0x0, reportID: 5 > > size: 8, count: 1, loc: 80 > > feature: page: 0x0; usage: 0x0, reportID: 5 > > size: 8, count: 1, loc: 88 > > feature: page: 0x0; usage: 0x0, reportID: 5 > > size: 8, count: 1, loc: 96 > > feature: page: 0x0; usage: 0x0, reportID: 5 > > size: 8, count: 1, loc: 104 > > feature: page: 0x0; usage: 0x0, reportID: 5 > > size: 8, count: 1, loc: 112 > > feature: page: 0x0; usage: 0x0, reportID: 5 > > size: 8, count: 1, loc: 120 > > end_collection: page: 0x1; usage: 0x31, reportID: 2 > > size: 8, count: 2, loc: 0 > > end_collection: page: 0x0; usage: 0x0, reportID: 2 > > size: 8, count: 2, loc: 0 > > end_collection: page: 0xffff; usage: 0x4, reportID: 5 > > size: 8, count: 16, loc: 0 > > > > As can be seen, there are two distinct report IDs being used. Report ID 2 > > describes the mouse-buttons and XY deltas; and since the generic UMS > driver > > in Freebsd is able to parse these values, the macbook's trackpad is > usable. > > I would like to enhance the ums driver to report information from the > > pressure sensors--with the hope that this will allow the detection of tap > > events. > > I suspect that the reports with ID == 5 will contain this information. Of > > particular interest to me is the following (from the previous table): > > > > input: page: 0xffff; usage: 0x2; reportID: 5 > > size: 8, count: 63, loc: 24 > > > > Unfortunately, this report uses a vendor specific page (0xffff), and > > therefore will require some reverse engineering before it can be > deciphered. > > > > I need help with receiving HID reports for both ID == 2 and ID == 5. > > Currently, the interrupt handler (ums_intr) only parses reports with > ID==2. > > Based on my reading of the code, ums_attach() needs to setup sc->sc_iid > and > > sc->sc_isize based on the report-descriptors fetched from the device; but > in > > the case where there are multiple reportIDs supported by the device, the > > current setup code uses values from only the first reportID. > > > > In order to parse reportID 2, sc->sc_isize is set to a value of 4 bytes: > 1 > > byte for the reportID header, together with 3 bytes for the > button/XY-delta > > values. > > To accommodate an additional 63 bytes for the input in reportID 5, I am > > guessing that I should set sc->sc_isize to 68: for the 63 bytes starting > at > > bit offset 24; with allowance for one additional byte which may be > necessary > > to accommodate a reportID header. I still don't know how to initialize > > sc->sc_iid to handle both report IDs. > > > > Can someone please help me with setting up the device to receive reports > > with both IDs so that I can begin reverse-engineering the vendor-specific > > content of reportID 5? > > > > regards, > > Rohit. > > _______________________________________________ > > freebsd-drivers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-drivers > > To unsubscribe, send any mail to " > freebsd-drivers-unsubscribe@freebsd.org" > > > >