Re: 0xdeadc0de panic after plugging in USB CompactFlashreader/writer on 5.0-RELEASE
On Thu, Jun 05, 2003 at 03:32:54PM +0200, Poul-Henning Kamp wrote:
> In message <[EMAIL PROTECTED]>, Bernd Walter writes:
> >On Wed, Jun 04, 2003 at 10:44:53PM -0700, Brian O'Shea wrote:
> >> System panics after PQI Travel Flash (USB Compact Flash reader/writer mass
> >> storage device) is plugged in.
> >>
> >> This is 5.0-RELEASE on i386.
> >
> >Many things have been changed since 5.0.
> >Please retry with 5.1-RC1 or wait the few days for 5.1-RELEASE.
>
> Actually, he probably wants this patch which I just sent to the
> QuirkMeister:
>
>
> Index: scsi_da.c
> ===
> RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
> retrieving revision 1.143
> diff -u -r1.143 scsi_da.c
> --- scsi_da.c 15 May 2003 17:35:35 - 1.143
> +++ scsi_da.c 5 Jun 2003 12:47:54 -
> @@ -507,6 +507,16 @@
>*/
> {T_DIRECT, SIP_MEDIA_REMOVABLE, "OTi", "Flash Disk", "*"},
> /*quirks*/ DA_Q_NO_6_BYTE
> + },
> + {
> + /*
> + * PQI Travel Flash, rev 1.10/2.05, addr 2
> + * General Flash Disk Drive 2.05
> + * Serial Number ST92163-2000
> + */
> + {T_DIRECT, SIP_MEDIA_REMOVABLE, "General Flash Disk Drive",
> + "*", "*"},
> + /*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE
> }
> };
Mine works fine without quirks:
port 3 addr 3: full speed, power 100 mA, config 1, Travel Flash(0x1307),
PQI(0x0483), rev 2.05
[53]cicely13# camcontrol devlist
at scbus0 target 0 lun 0 (da0,pass0)
at scbus0 target 0 lun 1 (da1,pass1)
at scbus0 target 0 lun 2 (da2,pass2)
[54]cicely13# uname -a
FreeBSD cicely13.cicely.de 5.1-BETA FreeBSD 5.1-BETA #1: Sun May 11 12:58:37 CEST 2003
[EMAIL
PROTECTED]:/var/d9/obj/var/d7/builder/FreeBSD-2003-05-11-cicely13/src/sys/CICELY13
i386
It's possible that the 4 slot version require quirks and share the
version number, but things really shouldn't panic without.
If they do on -current I'm interested.
--
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 0xdeadc0de panic after plugging in USB CompactFlashreader/writer on 5.0-RELEASE
In message <[EMAIL PROTECTED]>, Bernd Walter writes: >Mine works fine without quirks: > port 3 addr 3: full speed, power 100 mA, config 1, Travel Flash(0x1307), > PQI(0x0483), rev 2.05 Mine is: port 1 addr 2: full speed, power 100 mA, config 1, Travel Flash(0x0001), PQI(0x3538), rev 2.05 I do find it odd, that the quirks are not assigned in the umass code and passed to scsi_da some way, that would be much more reliable. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 0xdeadc0de panic after plugging in USB CompactFlashreader/writer on 5.0-RELEASE
On Thu, Jun 05, 2003 at 04:10:59PM +0200, Poul-Henning Kamp wrote: > In message <[EMAIL PROTECTED]>, Bernd Walter writes: > > >Mine works fine without quirks: > > port 3 addr 3: full speed, power 100 mA, config 1, Travel Flash(0x1307), > > PQI(0x0483), rev 2.05 > > Mine is: > > port 1 addr 2: full speed, power 100 mA, config 1, Travel Flash(0x0001), > PQI(0x3538), rev 2.05 Is this the 4 slot USB1.1 version? Mine is an older 3 slot USB1.1 device. > I do find it odd, that the quirks are not assigned in the umass code and > passed to scsi_da some way, that would be much more reliable. Considering that we may require quirks for usb-ata converters but see the drives in scsi_da I agree. In this case it's not critical - the quirks are not wrong for my version, just not required. Nevertheless: Does it panic without quirk or simply don't work? -- B.Walter BWCThttp://www.bwct.de [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: setting CMOS clock
In the last episode (Jun 05), Christoph Kukulies said: > I'm using a cron job to synchronize time against a timeserver in a > local network. The timeserver is a NT box that has a DCF77 clock > attached. > > I chose rdate (/usr/ports/sysutils/rdate) to do the synchronisation. > > Does this also set the CMS clock correctly or what would I have to do > to set the cmos clock? The CMOS clock is automatically set whenever the system's time is updated. You might want to think about installing NTPD on your NT machine and using NTP to synch instead. rdate can only give you time to the nearest second, and according to http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-s-refclk.htm#AEN4231 , the DCF77 signal is accurate to ~3ms . Precompiled ntpd binaries for NT are available at http://www.ntp.org/links.html -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 0xdeadc0de panic after plugging in USB CompactFlashreader/writer on 5.0-RELEASE
In message <[EMAIL PROTECTED]>, Bernd Walter writes: >On Thu, Jun 05, 2003 at 04:10:59PM +0200, Poul-Henning Kamp wrote: >> In message <[EMAIL PROTECTED]>, Bernd Walter writes: >> >> >Mine works fine without quirks: >> > port 3 addr 3: full speed, power 100 mA, config 1, Travel Flash(0x1307), >> > PQI(0x0483), rev 2.05 >> >> Mine is: >> >> port 1 addr 2: full speed, power 100 mA, config 1, Travel Flash(0x0001), >> PQI(0x3538), rev 2.05 > >Is this the 4 slot USB1.1 version? >Mine is an older 3 slot USB1.1 device. > >> I do find it odd, that the quirks are not assigned in the umass code and >> passed to scsi_da some way, that would be much more reliable. > >Considering that we may require quirks for usb-ata converters but see >the drives in scsi_da I agree. >In this case it's not critical - the quirks are not wrong for my >version, just not required. >Nevertheless: Does it panic without quirk or simply don't work? It seems to hang the gadget which blocks the daopen() which holds GEOM's topology lock which makes a lot of things not happen any more. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: setting CMOS clock
On Thu, Jun 05, 2003 at 09:31:01AM -0500, Dan Nelson wrote: > In the last episode (Jun 05), Christoph Kukulies said: > > I'm using a cron job to synchronize time against a timeserver in a > > local network. The timeserver is a NT box that has a DCF77 clock > > attached. > > > > I chose rdate (/usr/ports/sysutils/rdate) to do the synchronisation. > > > > Does this also set the CMS clock correctly or what would I have to do > > to set the cmos clock? > > The CMOS clock is automatically set whenever the system's time is > updated. You might want to think about installing NTPD on your NT Ah, that's good to know. Under Linux Boxes which I had under my command in the meantime (Redhat 6.1) an additional /sbin/clock -w was necessary. > machine and using NTP to synch instead. rdate can only give you time > to the nearest second, and according to > http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-s-refclk.htm#AEN4231 , the > DCF77 signal is accurate to ~3ms . Precompiled ntpd binaries for NT > are available at http://www.ntp.org/links.html Thanks for the pointer. That's good to know. What NT 4.0 Resource kit is supplying calls itself TimeServ and offers time service on port 37 only. And obviously the ntpdate client times out on given this as the server. -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multimedia Keyboard (extra keys) on console
theres easier ways to get the multimedia keys working on X, but i am looking for a way to get them working on the console. as i said before, it seems to me as if there isnt a halfway moderate way to even find out the keycodes or anything ..on linux its as easy as "showkey -s" > I suggest you take a look at the "acme" port. It may be found in > ports/multimedia/acme. It provides an intuitive configuration interface > for mapping certain keys to certain actions. If you don't find it of use > in your scenario, the source code is always there. > > > +---+ > | Samy Al Bahra | [EMAIL PROTECTED] | > +---+ > Arabeyes.org Kerneled.com FreeBSD.org > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 0xdeadc0de panic after plugging in USB CompactFlashreader/writer on 5.0-RELEASE
--- Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, Bernd Walter writes:
> >On Wed, Jun 04, 2003 at 10:44:53PM -0700, Brian O'Shea wrote:
> >> System panics after PQI Travel Flash (USB Compact Flash reader/writer mass
> >> storage device) is plugged in.
> >>
> >> This is 5.0-RELEASE on i386.
> >
> >Many things have been changed since 5.0.
> >Please retry with 5.1-RC1 or wait the few days for 5.1-RELEASE.
Ok, thanks.
>
> Actually, he probably wants this patch which I just sent to the
> QuirkMeister:
Thank you very much! I'll give it a try...
-brian
>
>
> Index: scsi_da.c
> ===
> RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
> retrieving revision 1.143
> diff -u -r1.143 scsi_da.c
> --- scsi_da.c 15 May 2003 17:35:35 - 1.143
> +++ scsi_da.c 5 Jun 2003 12:47:54 -
> @@ -507,6 +507,16 @@
>*/
> {T_DIRECT, SIP_MEDIA_REMOVABLE, "OTi", "Flash Disk", "*"},
> /*quirks*/ DA_Q_NO_6_BYTE
> + },
> + {
> + /*
> + * PQI Travel Flash, rev 1.10/2.05, addr 2
> + * General Flash Disk Drive 2.05
> + * Serial Number ST92163-2000
> + */
> + {T_DIRECT, SIP_MEDIA_REMOVABLE, "General Flash Disk Drive",
> + "*", "*"},
> + /*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE
> }
> };
>
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 0xdeadc0de panic after plugging in USB CompactFlashreader/writer on 5.0-RELEASE
--- Bernd Walter <[EMAIL PROTECTED]> wrote: > > Considering that we may require quirks for usb-ata converters but see > the drives in scsi_da I agree. > In this case it's not critical - the quirks are not wrong for my > version, just not required. > Nevertheless: Does it panic without quirk or simply don't work? I'll give it a try tonight and let you know. Thanks again, -brian __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
USB device not coming up (Diva MP3 player)
Hi, I run RELENG_5_1 from 31th May (identifies as 5.1-RC) on Microstar motherboard with onboard VIA 83C572 USB2.0 controller. I purchased Diva MP3 Player today, and I don't work here. I plug it in, the device powers up, and promptly I see uhub0: port error, restarting port 1 I don't have ehci device in my kernel, and similar device works fine for my friend with -STABLE. I bumped some usb debug sysctls up to 10 and here is the output: usb_transfer_complete: pipe=0xc2607400 xfer=0xc2533300 status=0 actlen=1 usb_transfer_complete: repeat=1 new head=0xc2533300 uhub_intr: sc=0xc259f8b0 usb_needs_explore usb_event_thread: woke up usb_discover usbd_alloc_xfer() = 0xc2533b00 usbd_transfer: xfer=0xc2533b00, flags=2, pipe=0xc2607000, running=0 usbd_dump_queue: pipe=0xc2607000 usb_insert_transfer: pipe=0xc2607000 running=0 timeout=5000 uhci_root_ctrl_control type=0xa3 request=00 usb_transfer_complete: pipe=0xc2607000 xfer=0xc2533b00 status=0 actlen=4 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc2607000, xfer=0 usbd_free_xfer: 0xc2533b00 uhub_explore: uhub0 port 1 status 0x0109 0x0001 uhub_explore: status change hub=1 port=1 usbd_alloc_xfer() = 0xc2533b00 usbd_transfer: xfer=0xc2533b00, flags=2, pipe=0xc2607000, running=0 usbd_dump_queue: pipe=0xc2607000 usb_insert_transfer: pipe=0xc2607000 running=0 timeout=5000 uhci_root_ctrl_control type=0x23 request=01 uhci_root_ctrl_control: UR_CLEAR_PORT_FEATURE port=1 feature=16 usb_transfer_complete: pipe=0xc2607000 xfer=0xc2533b00 status=0 actlen=0 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc2607000, xfer=0 usbd_free_xfer: 0xc2533b00 usbd_alloc_xfer() = 0xc2533b00 usbd_transfer: xfer=0xc2533b00, flags=2, pipe=0xc2607000, running=0 usbd_dump_queue: pipe=0xc2607000 usb_insert_transfer: pipe=0xc2607000 running=0 timeout=5000 uhci_root_ctrl_control type=0x23 request=03 usb_transfer_complete: pipe=0xc2607400 xfer=0xc2533300 status=0 actlen=1 usb_transfer_complete: repeat=1 new head=0xc2533300 uhub_intr: sc=0xc259f8b0 usb_needs_explore uhci port 1 reset, status = 0x0495 usb_transfer_complete: pipe=0xc2607000 xfer=0xc2533b00 status=0 actlen=0 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc2607000, xfer=0 usbd_free_xfer: 0xc2533b00 usbd_reset_port: port 1 reset done, error=NORMAL_COMPLETION usbd_alloc_xfer() = 0xc2533b00 usbd_transfer: xfer=0xc2533b00, flags=2, pipe=0xc2607000, running=0 usbd_dump_queue: pipe=0xc2607000 usb_insert_transfer: pipe=0xc2607000 running=0 timeout=5000 uhci_root_ctrl_control type=0xa3 request=00 usb_transfer_complete: pipe=0xc2607000 xfer=0xc2533b00 status=0 actlen=4 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc2607000, xfer=0 usbd_free_xfer: 0xc2533b00 usbd_alloc_xfer() = 0xc2533b00 usbd_transfer: xfer=0xc2533b00, flags=2, pipe=0xc2607000, running=0 usbd_dump_queue: pipe=0xc2607000 usb_insert_transfer: pipe=0xc2607000 running=0 timeout=5000 uhci_root_ctrl_control type=0x23 request=01 uhci_root_ctrl_control: UR_CLEAR_PORT_FEATURE port=1 feature=20 usb_transfer_complete: pipe=0xc2607000 xfer=0xc2533b00 status=0 actlen=0 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc2607000, xfer=0 usbd_free_xfer: 0xc2533b00 usb_transfer_complete: pipe=0xc2607400 xfer=0xc2533300 status=0 actlen=1 usb_transfer_complete: repeat=1 new head=0xc2533300 uhub_intr: sc=0xc259f8b0 usb_needs_explore usbd_alloc_xfer() = 0xc2533b00 usbd_transfer: xfer=0xc2533b00, flags=2, pipe=0xc2607000, running=0 usbd_dump_queue: pipe=0xc2607000 usb_insert_transfer: pipe=0xc2607000 running=0 timeout=5000 uhci_root_ctrl_control type=0xa3 request=00 usb_transfer_complete: pipe=0xc2607000 xfer=0xc2533b00 status=0 actlen=4 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc2607000, xfer=0 usbd_free_xfer: 0xc2533b00 usbd_alloc_xfer() = 0xc2533b00 usbd_transfer: xfer=0xc2533b00, flags=2, pipe=0xc2607000, running=0 usbd_dump_queue: pipe=0xc2607000 usb_insert_transfer: pipe=0xc2607000 running=0 timeout=5000 uhci_root_ctrl_control type=0xa3 request=00 usb_transfer_complete: pipe=0xc2607000 xfer=0xc2533b00 status=0 actlen=4 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc2607000, xfer=0 usbd_free_xfer: 0xc2533b00 uhub_explore: uhub0 port 2 status 0x0108 0x uhub_explore: port=2 !C_CONNECT_STATUS usbd_alloc_xfer() = 0xc2533b00 usbd_transfer: xfer=0xc2533b00, flags=2, pipe=0xc2607000, running=0 usbd_dump_queue: pipe=0xc2607000 usb_insert_transfer: pipe=0xc2607000 running=0 timeout=5000 uhci_root_ctrl_control type=0xa3 request=00 usb_transfer_complete: pipe=0xc2607000 xfer=0xc2533b00 status=0 actlen=4 usb_transfer_complete: repeat=0 new head=0 usbd_start_next: pipe=0xc2607000, xfer=0 usbd_free_xfer: 0xc2533b00 uhub_explore: uhub0 port 1 status 0x0108 0x0003 uhub_explore: C_PORT_ENABLED usbd_alloc_xfer() = 0xc2533b00 usbd_transfer: xfer=0xc2533b00, flags=2, pipe=0xc2607000, running=0 usbd_dump_queue: pipe=0xc2607000 usb_insert_transfer: pipe=0xc2607000 runnin
Re: USB device not coming up (Diva MP3 player)
On Jun 05, Pav Lucistnik wrote:
> ...
Wild guess patch included.
usbdevs -v would help
--Mat
--
Brain: Pinky, are you pondering what I'm pondering?
Pinky: Um... I think so, Brain, but what if the chicken won't wear the
nylons?
--- usb_quirks.cTue Apr 8 20:00:34 2003
+++ /tmp/aa Thu Jun 5 16:40:56 2003
@@ -100,6 +100,8 @@
ANY, { UQ_ASSUME_CM_OVER_DATA }},
{ USB_VENDOR_YAMAHA, USB_PRODUCT_YAMAHA_RTW65I,
ANY, { UQ_ASSUME_CM_OVER_DATA }},
+ { USB_VENDOR_PHILIPS, USB_PRODUCT_PHILIPS_DIVAUSB,
+ ANY, { UQ_NO_STRINGS }},
{ 0, 0, 0, { 0 } }
};
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
interrupt handlers in -current
Hello, This is more of a confirmation of my understanding than anything else. In -current, should an interrupt thread be created you set up an interrupt handler? If so, then I'd better check my code because I haven't got one! If a PCI device generates an interrupt and there is no handler does the kernel report a stary interrupt? -current for me is 5.1-BETA1 and I'm doing a driver for the BCM 4401 NIC. I'm transmitting packets but my handler isn't being called to clean up the DMA. Duncan -- Duncan Barclay | [EMAIL PROTECTED] | [EMAIL PROTECTED]| ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multimedia Keyboard (extra keys) on console
thanks, works like a charme, its printing the same linux is printing tho. pressing the first key prints "0xe0 0x10" releasing it prints "0xe0 0x90" 0x10 = 'q' ..the 0xe0 seems to indicate its a function key (like del and others, who also have the 0xe0) im a bit confused, because DEL for example gives 0x53 (81) and is in my keymap as scancode 81, but how am i supposed to put the 0x10 twice in there? or am i missing something out completely here? > * [EMAIL PROTECTED] [2003-06-05 18:37 +0200]: >> theres easier ways to get the multimedia keys working on X, but i am >> looking for a way to get them working on the console. as i said before, >> it >> seems to me as if there isnt a halfway moderate way to even find out the >> keycodes or anything ..on linux its as easy as "showkey -s" > > Try the atttached files. It's my personal version of showkey (from > linux). > > Nicolas > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: interrupt handlers in -current
In message: <[EMAIL PROTECTED]> Duncan Barclay <[EMAIL PROTECTED]> writes: : This is more of a confirmation of my understanding than anything else. : In -current, should an interrupt thread be created you set up an interrupt : handler? If so, then I'd better check my code because I haven't got one! No. Just because we handle interrupts in a thread doesn't mean client devices need to create a thread. The thread is creted automatically and the routine passed to bus_setup_intr() is then called when an interrupt happens. You can create threads, taskqueues and other things, but those aren't required. : If a PCI device generates an interrupt and there is no handler does the : kernel report a stary interrupt? You'll likely see an interrupt storm. Since the PCI device generates a level interrupt, the ISRs are run and the level interrupt is still high, so another interrupt is generated, etc. on 4.x this was fatal, but on 5.x the system can continue to run in a degraded manner. : -current for me is 5.1-BETA1 and I'm doing a driver for the BCM 4401 NIC. : I'm transmitting packets but my handler isn't being called to clean up the : DMA. So you are doing bus_setup_intr() and that routine is never called? What does vmstat say? I'd expect to see something like: % vmstat -i uhci0 irq10 26083 1 # cause the interrupt to happen % vmstat -i uhci0 irq10 26026083 2683 # eg, a huge number all of a sudden (all[*] irq 10's are reported on the uhci device in vmstat, so don't let that get you confused). It may also be the case that the interrupt for this isn't being properly routed. 5.1-BETA has a bug that, for some laptop machines, interrupts aren't properly routed. 5.1-RELEASE has fixed this. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: interrupt handlers in -current
On 05-Jun-2003 M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Duncan Barclay <[EMAIL PROTECTED]> writes: >: This is more of a confirmation of my understanding than anything else. >: In -current, should an interrupt thread be created you set up an interrupt >: handler? If so, then I'd better check my code because I haven't got one! > > No. Just because we handle interrupts in a thread doesn't mean client > devices need to create a thread. The thread is creted automatically > and the routine passed to bus_setup_intr() is then called when an > interrupt happens. Rereading what I wrote, I might have mistyped and asked the wrong question. I think what you saying is that bus_setup_intr() doesn't create the thread, (in the sense of it appear in ps -ax?) but a thread is created automatically when the first interrupt occurs? > You can create threads, taskqueues and other things, but those aren't > required. Good - bus_dma is warping my head too much...I think I've got it right. >: If a PCI device generates an interrupt and there is no handler does the >: kernel report a stary interrupt? > > You'll likely see an interrupt storm. Since the PCI device generates > a level interrupt, the ISRs are run and the level interrupt is still > high, so another interrupt is generated, etc. on 4.x this was fatal, > but on 5.x the system can continue to run in a degraded manner. > >: -current for me is 5.1-BETA1 and I'm doing a driver for the BCM 4401 NIC. >: I'm transmitting packets but my handler isn't being called to clean up the >: DMA. > > So you are doing bus_setup_intr() and that routine is never called? Yup. > What does vmstat say? I'd expect to see something like: > > % vmstat -i > uhci0 irq10 26083 1 ># cause the interrupt to happen > % vmstat -i > uhci0 irq10 26026083 2683 ># eg, a huge number all of a sudden If I load the kld for the driver and it attaches, nothing appears in vmstat -i, or ps -ax. Unfortunately, I've screwed up a lock in the ioctl hander and witness is panic'ing when I ifconfig the interface. As it is now bedtime I'll fix it tomorrow morning and report back. > It may also be the case that the interrupt for this isn't being > properly routed. 5.1-BETA has a bug that, for some laptop machines, > interrupts aren't properly routed. 5.1-RELEASE has fixed this. Okay, I'll do a reinstall. This probably won't happen until after the weekend because I'm going away. Anyway, I'm pleased with my progress as I can see arp requests hitting the wire before it panics. > Warner Thanks, Duncan -- Duncan Barclay | [EMAIL PROTECTED] | [EMAIL PROTECTED]| ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multimedia Keyboard (extra keys) on console
On Thu, 5 Jun 2003 10:54 pm, Samy Al Bahra wrote: > I suggest you take a look at the "acme" port. It may be found in > ports/multimedia/acme. It provides an intuitive configuration interface > for mapping certain keys to certain actions. If you don't find it of use > in your scenario, the source code is always there. It would probably be easier to just port the showkey command from linux (: Jacob RhodenPhone: +61 3 8344 6102 ITS DivisionEmail: [EMAIL PROTECTED] Melbourne University Mobile: +61 403 788 386 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multimedia Keyboard (extra keys) on console
already done, see my previous email :) > On Thu, 5 Jun 2003 10:54 pm, Samy Al Bahra wrote: >> I suggest you take a look at the "acme" port. It may be found in >> ports/multimedia/acme. It provides an intuitive configuration interface >> for mapping certain keys to certain actions. If you don't find it of use >> in your scenario, the source code is always there. > > It would probably be easier to just port the showkey command from linux (: > > Jacob RhodenPhone: +61 3 8344 6102 > ITS DivisionEmail: [EMAIL PROTECTED] > Melbourne University Mobile: +61 403 788 386 > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: interrupt handlers in -current
In message: <[EMAIL PROTECTED]> Duncan Barclay <[EMAIL PROTECTED]> writes: : : On 05-Jun-2003 M. Warner Losh wrote: : > In message: <[EMAIL PROTECTED]> : > Duncan Barclay <[EMAIL PROTECTED]> writes: : >: This is more of a confirmation of my understanding than anything else. : >: In -current, should an interrupt thread be created you set up an interrupt : >: handler? If so, then I'd better check my code because I haven't got one! : > : > No. Just because we handle interrupts in a thread doesn't mean client : > devices need to create a thread. The thread is creted automatically : > and the routine passed to bus_setup_intr() is then called when an : > interrupt happens. : : Rereading what I wrote, I might have mistyped and asked the wrong question. : : I think what you saying is that bus_setup_intr() doesn't create the thread, : (in the sense of it appear in ps -ax?) : but a thread is created automatically when the first interrupt occurs? The thread is created right away. However, if this interrupt is shared with another device, you'll see seomthing like: root23 0.0 0.0 0 12 ?? WL 11:35AM 0:04.24 (irq10: cbb0 cbb1++) which says taht cbb0 and cbb1 (and others) share irq10. : > So you are doing bus_setup_intr() and that routine is never called? : : Yup. OK. Are you sharing interrupts? If so, can you see if the interrutp is even happening? Can you force the card to interrupt right away? Many cards have a force interrupt bit, so that one can detect if the interrupts are wired right. : If I load the kld for the driver and it attaches, nothing appears : in vmstat -i, or ps -ax. Unfortunately, I've screwed up a lock in the ioctl : hander and witness is panic'ing when I ifconfig the interface. As it : is now bedtime I'll fix it tomorrow morning and report back. OK. You may or may not see anything. I kldload if_an and get the above ps line as the only evidence that happened. : Anyway, I'm pleased with my progress as I can see arp requests hitting : the wire before it panics. Cool! Lemme know if there's anything else I can do help. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
netstat -s output
Hi hackers, I have tried to find out the amount of traffic that one box sent (from the last reboot), and netstat -s seemed like a good choice. But netstat -s seems to generate incorrect results: tcp: 1730547260 packets sent 1325234728 data packets (1119813018 bytes) 28496801 data packets (151887376 bytes) retransmitted This box generated a lot more than ~12Gb of tcp traffic since the last reboot. And I have not messed up with interfaces (up, down, whatever) OR with netstat -z in all this time. Any idea what could be wrong? Are the counters resetted sometimes, or they wrap sometimes, or...? Thank you, bogdan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: netstat -s output
On Fri, 6 Jun 2003, 11:19+0200, Bogdan TARU wrote: > > > Hi hackers, > > I have tried to find out the amount of traffic that one box sent (from > the last reboot), and netstat -s seemed like a good choice. But netstat -s > seems to generate incorrect results: > > tcp: > 1730547260 packets sent > 1325234728 data packets (1119813018 bytes) > 28496801 data packets (151887376 bytes) retransmitted > > This box generated a lot more than ~12Gb of tcp traffic since the last > reboot. And I have not messed up with interfaces (up, down, whatever) OR > with netstat -z in all this time. Any idea what could be wrong? Are the > counters resetted sometimes, or they wrap sometimes, or...? They wrap at 2^32. -- Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Prism2 firmware upload support.
After experimenting with the hostap drivers of linux (http://hostap.epitest.fi/) I've quite taken a liking of 'prism2_srec' which allows one to upload (experimental) firmware in the RAM of the prism2 card. And being able to do this form userland. Has anyone looked at the existing symbol firmware loading code in freebsd 5.x and looked at generalizing this with some ioctl()'s for upload/download of firmware (and propalby an extra SIOCGPRISM2INFO to give userland enough of an idea of the primary/secondary version numbers to be able to select/check the hex files) ? I've started coding some of this into the wi driver - but one thing which worries me is how to properly activate it; i.e. how does one from an ioctl a clean detach/probe sort of thing ? I take it that one cannot call wi_generic_detach(), wi_generic_attach() from inside the ioctol handler ? Thanks, Dw ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Incompatibility between FreeBSD make.conf and imake 4.3.0
I just discovered an incompatibility between the handling of CFLAGS in FreeBSD 4.8-R (and other versions, I'm sure) and in imake 4.3.0. Let me give you the symptom first. When building both normal and shared libraries, using an Imakefile that uses the automatic object rule generation provided by Library.tmpl (ex: ports/x11-toolkits/Xaw3d), the normal library is compiled without ANY optimization (i.e., CFLAGS is ignored). The cause: FreeBSD goes out of its way (in FreeBSD.cf) to ensure that CDEBUGFLAGS will be empty, with the expectation that compiler optimization will be gotten from CFLAGS as set in make.conf. However, the imake object rule for normal libraries that is used WHEN BUILDING BOTH NORMAL AND SHARED LIBRARIES (Imake.rules, LibObjCompile) does not use CFLAGS, expecting compiler optimization to come from CDEBUGFLAGS. I don't know why LibObjCompile doesn't use CFLAGS. Is it intentional? Is it an oversight? Would something else break if LibObjCompile were changed to use CFLAGS? Imake config files are so complex that it's hard to answer these questions correctly. Note that this is not an imake config bug. This problem is triggered by what's done in FreeBSD.cf, which is not "in harmony" with the expectations of the imake config files regarding CDEBUGFLAGS. A less-than-satisfactory workaround is to put CDEBUGFLAGS = -O into every affected Imakefile AFTER "#include http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multimedia Keyboard (extra keys) on console
[EMAIL PROTECTED] wrote: > thanks, works like a charme, its printing the same linux is printing tho. > > pressing the first key prints "0xe0 0x10" releasing it prints "0xe0 0x90" > 0x10 = 'q' ..the 0xe0 seems to indicate its a function key (like del and > others, who also have the 0xe0) > > im a bit confused, because DEL for example gives 0x53 (81) and is in my > keymap as scancode 81, but how am i supposed to put the 0x10 twice in there? > > or am i missing something out completely here? I suppose I've noticed somewhere in manuals an example how to make key produce different actions depending on what keycode followed this key... It was shown how to enter german umlauted vowels, but idea is the same. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Prism2 firmware upload support.
In message: <[EMAIL PROTECTED]> Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes: : Has anyone looked at the existing symbol firmware loading code in freebsd : 5.x and looked at generalizing this with some ioctl()'s for : upload/download of firmware (and propalby an extra SIOCGPRISM2INFO to give : userland enough of an idea of the primary/secondary version numbers to be : able to select/check the hex files) ? I've looked into it. Primary/secondary versions aren't as interesting as the actual product ID for determining which hex file to load. There's also a need for getting additional data out of the current firmware so it can be merged into the hex file before we burn the new firmware. There's also a number of sanity checks that need to be made to make sure that primary firmware is compatible with the secondary firmware you are loading, etc. : I've started coding some of this into the wi driver - but one thing which : worries me is how to properly activate it; i.e. how does one from an ioctl : a clean detach/probe sort of thing ? I take it that one cannot call : wi_generic_detach(), wi_generic_attach() from inside the ioctol handler ? I don't think you need to call attach/detach. I think its overkill and completely unnecessary. There's really no need at all to do this. You should take the interface down, note you are updating the firmware to preclude it coming back up, do the firmware upload, and then call wi_init again. It may make sense to set certain flags based on the new version, but I don't think much else is required. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Prism2 firmware upload support.
On Fri, 6 Jun 2003, M. Warner Losh wrote: > I've looked into it. Primary/secondary versions aren't as interesting > as the actual product ID for determining which hex file to load. > There's also a need for getting additional data out of the current > firmware so it can be merged into the hex file before we burn the new > firmware. There's also a number of sanity checks that need to be made Yes - I've started with extracting the PDA information in a way so that it can be read by the likes of prism2dl. I find that I now need to decode the hex files in much more detail (Up to know I assumed it was just an intel hex file which needed to be uploaded in a some bit of ram. Turns out there is more to it than that :-(. > to make sure that primary firmware is compatible with the secondary > firmware you are loading, etc. Aye - I've also added an ioctl to get the 3 id/major/minor/variant values for nic/pri/sec; which is enough to drive prism2dl together with the PDA info. > to preclude it coming back up, do the firmware upload, and then call > wi_init again. It may make sense to set certain flags based on the > new version, but I don't think much else is required. Thanks - will limit myself to that. Dw ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Prism2 firmware upload support.
In message: <[EMAIL PROTECTED]> Dirk-Willem van Gulik <[EMAIL PROTECTED]> writes: : > to make sure that primary firmware is compatible with the secondary : > firmware you are loading, etc. : : Aye - I've also added an ioctl to get the 3 id/major/minor/variant values : for nic/pri/sec; which is enough to drive prism2dl together with the PDA : info. wicontrol already can grab these values (not the PDA ones, but the id and version stuf). It uses a generic RID interface to do that. PRI Identity: [ 21 1 1 1 ] STA Identity: [ 31 6 1 5 ] Card ID register: [ 800c 0 1 0 ] I'm very interested to see what you can arrange. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 0xdeadc0de panic after plugging in USB CompactFlashreader/writer on 5.0-RELEASE
Hi Poul-Henning,
--- Poul-Henning Kamp <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, Bernd Walter writes:
> >On Wed, Jun 04, 2003 at 10:44:53PM -0700, Brian O'Shea wrote:
> >> System panics after PQI Travel Flash (USB Compact Flash reader/writer mass
> >> storage device) is plugged in.
> >>
> >> This is 5.0-RELEASE on i386.
> >
> >Many things have been changed since 5.0.
> >Please retry with 5.1-RC1 or wait the few days for 5.1-RELEASE.
>
> Actually, he probably wants this patch which I just sent to the
> QuirkMeister:
That patch didn't fix it (I get the same panic). I think there must be
other significant changes to revision 1.143 of scsi_da.c (5.0-RELEASE
has revision 1.117). Amazingly, the patch applied correctly despite some
differences in the surrounding lines of code, and the line numbers being
off a bit. Anyhow, I'll wait for 5.1 to use my Travel Flash.
Thanks again for your help,
-brian
>
>
> Index: scsi_da.c
> ===
> RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
> retrieving revision 1.143
> diff -u -r1.143 scsi_da.c
> --- scsi_da.c 15 May 2003 17:35:35 - 1.143
> +++ scsi_da.c 5 Jun 2003 12:47:54 -
> @@ -507,6 +507,16 @@
>*/
> {T_DIRECT, SIP_MEDIA_REMOVABLE, "OTi", "Flash Disk", "*"},
> /*quirks*/ DA_Q_NO_6_BYTE
> + },
> + {
> + /*
> + * PQI Travel Flash, rev 1.10/2.05, addr 2
> + * General Flash Disk Drive 2.05
> + * Serial Number ST92163-2000
> + */
> + {T_DIRECT, SIP_MEDIA_REMOVABLE, "General Flash Disk Drive",
> + "*", "*"},
> + /*quirks*/ DA_Q_NO_6_BYTE|DA_Q_NO_SYNC_CACHE
> }
> };
>
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> [EMAIL PROTECTED] | TCP/IP since RFC 956
> FreeBSD committer | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
__
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: interrupt handlers in -current
On 06-Jun-2003 M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Duncan Barclay <[EMAIL PROTECTED]> writes: >: >: On 05-Jun-2003 M. Warner Losh wrote: >: > In message: <[EMAIL PROTECTED]> >: > Duncan Barclay <[EMAIL PROTECTED]> writes: >: >: This is more of a confirmation of my understanding than anything else. >: >: In -current, should an interrupt thread be created you set up an interrupt >: >: handler? If so, then I'd better check my code because I haven't got one! >: > >: > No. Just because we handle interrupts in a thread doesn't mean client >: > devices need to create a thread. The thread is creted automatically >: > and the routine passed to bus_setup_intr() is then called when an >: > interrupt happens. >: >: Rereading what I wrote, I might have mistyped and asked the wrong question. >: >: I think what you saying is that bus_setup_intr() doesn't create the thread, >: (in the sense of it appear in ps -ax?) >: but a thread is created automatically when the first interrupt occurs? > > The thread is created right away. However, if this interrupt is > shared with another device, you'll see seomthing like: > > root23 0.0 0.0 0 12 ?? WL 11:35AM 0:04.24 (irq10: cbb0 cbb1++) > > which says taht cbb0 and cbb1 (and others) share irq10. The thread is created right away, but I think KSE broke ps/top in that they don't show new processes anymore that haven't run yet. This is definitely a bug in the kernel. -- John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: interrupt handlers in -current
On 05-Jun-2003 M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Duncan Barclay <[EMAIL PROTECTED]> writes: > > It may also be the case that the interrupt for this isn't being > properly routed. 5.1-BETA has a bug that, for some laptop machines, > interrupts aren't properly routed. 5.1-RELEASE has fixed this. I think that this must be it. I had the blindingly obvious idea of looking at the chips interrupt mask in the watchdog (which is getting called). The chip has posted a TX complete interrupt. The kernel hasn't done anything with it so I assume it isn't routed. Until I get back from travelling and can install 5.1R, this at least gives me a hook to continue driver development - fairly icky though using the watchdog to trigger the interrupt handler! > Warner Duncan -- Duncan Barclay | [EMAIL PROTECTED] | [EMAIL PROTECTED]| ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: interrupt handlers in -current
In message: <[EMAIL PROTECTED]> Duncan Barclay <[EMAIL PROTECTED]> writes: : : On 05-Jun-2003 M. Warner Losh wrote: : > In message: <[EMAIL PROTECTED]> : > Duncan Barclay <[EMAIL PROTECTED]> writes: : > : > It may also be the case that the interrupt for this isn't being : > properly routed. 5.1-BETA has a bug that, for some laptop machines, : > interrupts aren't properly routed. 5.1-RELEASE has fixed this. : : I think that this must be it. I had the blindingly obvious idea of looking : at the chips interrupt mask in the watchdog (which is getting called). The : chip has posted a TX complete interrupt. The kernel hasn't done anything : with it so I assume it isn't routed. : : Until I get back from travelling and can install 5.1R, this at least gives me a : hook to continue driver development - fairly icky though using the : watchdog to trigger the interrupt handler! If you have sources, you can rebuild a kernel. Remove the ifdef __ia64__ from pci.c near line 815. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multimedia Keyboard (extra keys) on console
ive searched the whole manual for appearance of "keyboard" and "vowel" ;) the manual says the atkbd kbdcontrol etc manpages cover it all, so i should read those ..ive read them all thoughrouly already and didnt get an appropriate answer. > [EMAIL PROTECTED] wrote: >> thanks, works like a charme, its printing the same linux is printing >> tho. >> >> pressing the first key prints "0xe0 0x10" releasing it prints "0xe0 >> 0x90" >> 0x10 = 'q' ..the 0xe0 seems to indicate its a function key (like del and >> others, who also have the 0xe0) >> >> im a bit confused, because DEL for example gives 0x53 (81) and is in my >> keymap as scancode 81, but how am i supposed to put the 0x10 twice in >> there? >> >> or am i missing something out completely here? > I suppose I've noticed somewhere in manuals an example how to make key > produce different actions depending on what keycode followed this key... > It was shown how to enter german umlauted vowels, but idea is the same. > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- king ferrex / SAC >> [EMAIL PROTECTED] - http://impaled.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multimedia Keyboard (extra keys) on console
king ferrex wrote: > ive searched the whole manual for appearance of "keyboard" and "vowel" ;) > the manual says the atkbd kbdcontrol etc manpages cover it all, so i should > read those ..ive read them all thoughrouly already and didnt get an > appropriate answer. from keymap(5): For example, consider the following extract from a kbdmap: 041 dgra 172nopnop'|''|'nopnop O dgra '`' ( 'a' 224 ) ( 'A' 192 ) ( 'e' 232 ) ( 'E' 200 ) ( 'i' 236 ) ( 'I' 204 ) ( 'o' 242 ) ( 'O' 210 ) ( 'u' 249 ) ( 'U' 217 ) This extract configures the backtick key on a UK keyboard to act as a grave accent key. Pressing backtick followed by space produces a back- tick, and pressing a backtick followed by a vowel produces the ISO-8859-1 symbol for that vowel with a grave accent. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multimedia Keyboard (extra keys) on console
yea but that doesnt help me, the 041 for the key - how would i compute that from the "0xe0 0x4f" for example? for a real example: i have a key that produces "0xe0 0x10", 0x10 however is decimal 016, and is the 'q' key, pressing the "0xe0 0x10" key does not print a 'q' tho :) so the "0xe0" has a meaning, i tried 0xe0+0x10 ..but thats stupid and didnt give me a good value, so ..what decimal scancode is "0xe0 0x10" ? > king ferrex wrote: >> ive searched the whole manual for appearance of "keyboard" and "vowel" >> ;) >> the manual says the atkbd kbdcontrol etc manpages cover it all, so i >> should >> read those ..ive read them all thoughrouly already and didnt get an >> appropriate answer. > from keymap(5): > For example, consider the following extract from a kbdmap: > > 041 dgra 172nopnop'|''|'nopnop O > dgra '`' ( 'a' 224 ) ( 'A' 192 ) ( 'e' 232 ) ( 'E' 200 ) > ( 'i' 236 ) ( 'I' 204 ) ( 'o' 242 ) ( 'O' 210 ) > ( 'u' 249 ) ( 'U' 217 ) > This extract configures the backtick key on a UK keyboard to act as a > grave accent key. Pressing backtick followed by space produces a back- > tick, and pressing a backtick followed by a vowel produces the > ISO-8859-1 > symbol for that vowel with a grave accent. > > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > Random Thought: -- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multimedia Keyboard (extra keys) on console
[EMAIL PROTECTED] wrote: > yea but that doesnt help me, the 041 for the key - how would i compute that > from the "0xe0 0x4f" for example? for a real example: > > i have a key that produces "0xe0 0x10", 0x10 however is decimal 016, and is > the 'q' key, pressing the "0xe0 0x10" key does not print a 'q' tho :) > so the "0xe0" has a meaning, i tried 0xe0+0x10 ..but thats stupid and didnt > give me a good value, so ..what decimal scancode is "0xe0 0x10" ? ahem... and if write something like this: 224 'T' nop nop nop nop nop nop nop nop O will it produce 'T' at least? i don't have multimedia keyboard around to play with, sorry... ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
imgact_gzip.c
imgact_gzip.c seems to be pretty stale. Has anyone considered fixing this? If this were fixed then kldload() / linker_load_module() could deal with a gzipped .ko file, and gzipped elf executables would work also? Regards, David Yeske __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Mapping Physical Memory without a Device?
I would like to be able to map memory before I have a device to work with (to read system BIOS information or mess with the video buffer). Is this possible? In linux, I would just call ioremap_nocache or request region. Is there a way to use bus_alloc_resource or something similar to accomplish this? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multimedia Keyboard (extra keys) on console
no it wont, thats the problem ;) as mr.rachinsky, i need to patch my kernel and add the raw scancodes to produce keycodes, will do that later. thanks for the help. > [EMAIL PROTECTED] wrote: >> yea but that doesnt help me, the 041 for the key - how would i compute >> that >> from the "0xe0 0x4f" for example? for a real example: >> >> i have a key that produces "0xe0 0x10", 0x10 however is decimal 016, and >> is >> the 'q' key, pressing the "0xe0 0x10" key does not print a 'q' tho :) >> so the "0xe0" has a meaning, i tried 0xe0+0x10 ..but thats stupid and >> didnt >> give me a good value, so ..what decimal scancode is "0xe0 0x10" ? > ahem... > and if write something like this: > 224 'T' nop nop nop nop nop nop nop nop O > > will it produce 'T' at least? > i don't have multimedia keyboard around to play with, sorry... > > ___ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > -- king ferrex / SAC >> [EMAIL PROTECTED] - http://impaled.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Request for documenting IPSec, NAT/divert, ipfw, ipfilter ... inkernel flow ?
Hi, sorry for cross-mailing. Reply-to: set to freebsd-net. I have seen some discussion on freebsd-security etc. about some parts of the subject. I have seen older messages in archives. Regularly the same questions seem to come up. I have not found an all-including description of the answer to s.th. like: "Can anybody tell me the order packets get processed in kernel related to IPSec, NAT/divert, ipfw, ipfilter, ... for incoming, outgoing, forwarding... ?". What about bpf, ... ? Is there any chance that some of the gurus can draw one or more ascii arts or xfig or whatever images that show the in kernel packet flow/processing ? Perhaps the doc project would also be happy to include it in the handbook or somewhere else. Would make life much more easier for many people. TIA -- Greetings Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT 56 69 73 69 74 http://www.zabbadoz.net/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Non-Executable Stack Patch
Tony Meman writes: > I was wondering if there's any non-executable stack patch for > FreeBSD's kernel. > It would have been better to ask this on -hackers or -current. If I understand things correctly FreeBSD requires an executable stack for signal trampolines, so the answer would be no. But I may be wrong, so I'm Cc'ing this to -hackers. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
