Re: Looking for speed increases in make index and pkg_version for ports
Correct me if I wrong. Don't you missed the fact that chdir(2) changes process wide attribute? Though it's easy to fix with -C option. Stephen Montgomery-Smith wrote: Jeremy Chadwick wrote: On Sun, May 27, 2007 at 03:52:16PM -0500, Stephen Montgomery-Smith wrote: I have been thinking a lot about looking for speed increases for make index and pkg_version and things like that. So for example, in pkg_version, it calls make -V PKGNAME for every installed package. Now make -V PKGNAME should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. I have a related question, pertaining to make all-depends-list and the utter atrocity that is the make variable ALL-DEPENDS-LIST. If you don't know what it is, look for ^ALL-DEPENDS-LIST around line 5175, in bsd.ports.mk. I posted this to [EMAIL PROTECTED], but now I am realizing that it is [EMAIL PROTECTED] that gets more responses. Anyway, here is a multithreaded program all-depends-list that can get you double the speed on dual processor systems, and even some small speed gains on single processor systems. E.g. all-depends-list /usr/ports/x11/xorg http://www.math.missouri.edu/~stephen/all-depends-list.c ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No interrupts coming to device driver.
Warner, Unfortunately my BIOS do not allow IRQ reservation for ISA devices. But in I noticed Interrupt Mode menu with PIC/APIC options. This pushed me to go through another round of tests. First with PIC mode and back again with APIC but now with device apic added to kernel config. After few attempts to use different IRQs I finally got interrupts on IRQ9. Well. This is good and I can move forward with driver. Though I still confused the way it done. I will be really appreciated if some good will explain me what is behind all this woodoo I did. Is it necessary to have device apic today? And still what is the nature of those ?lost in hardware? interrupts? BTW. Here is a quote from dmesg which may be connected to the case. ACPI APIC Table: ASUS P4SQ ioapic0 Version 8.0 irqs 0-23 on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 Another bits of info. Windows automagically assigns IRQ7 to device and works fine. But I can not use IRQ7 on FreeBSD even with device apic in kernel. I do have hardware which is not in use ATM (PCI TV card). But I do not have any driver installed on Windows too. So if this is the case Windows somehow makes better guess of what driver can use. Anyway thanks everyone who tried to help! All the best, Alexander. M. Warner Losh wrote: In message: [EMAIL PROTECTED] Alexander Nedotsukov [EMAIL PROTECTED] writes: : I trying to create small lirc (www.lirc.org) compatible CIR driver for : it8705 chip (sits on ISA bus). My problem is I can not get interrupts : coming to driver. I believe I configured chip (carrier freq. + baudrate : divisor) and enabled interrupt mode the same way it windows driver does. : It also seems to be correct according to chip specs. But nothing. vmstat : -i shows zeros for assigned irq. And my IRS stay cold. I wrote small : userland program which polls CIRs IIR (interrupt identefication : register) and it shows interrupt pending bit set on right after I press : key on remote control. Looks like I missed something fundamental. Does : anyone can give me a hint where to look? If it is on the ISA bus, then you can look at the IRQ line that you are using for this card on the scope. Set it to trigger on an edge (either falling if the signal is high or rising if the signal is low, usually it is high). Make sure that the IRQ that you are using is not shared with anything else, even hardware you aren't using. That's forbidden in the ISA world (although some hacks exist to do interrupt sharing with two devices on the ISA bus, (a) almost nobody does them and (b) they don't work when sharing with pci). Make sure that the IRQ is set in the BIOS as Legacy/ISA rather than ISAPNP/PCI (or some variants of those phrases). See if there's a way to force an interrupt on the chip by writing to a register of some sort. It doesn't matter if you are going to use this, but it will be good for testing. It almost certainly isn't an unacknowledged interrupt (unless it is left over from before your chip reset). In my experience, those cause vmstat of 1. It might be worth checking the chip initialization sequence to make sure that you clear any possible interrupts AFTER you've done the bus_setup_inter() call to register your interrupt handler. That's all I can think of at the moment, but it should keep you busy for a few hours :-) Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
No interrupts coming to device driver.
Hi, I trying to create small lirc (www.lirc.org) compatible CIR driver for it8705 chip (sits on ISA bus). My problem is I can not get interrupts coming to driver. I believe I configured chip (carrier freq. + baudrate divisor) and enabled interrupt mode the same way it windows driver does. It also seems to be correct according to chip specs. But nothing. vmstat -i shows zeros for assigned irq. And my IRS stay cold. I wrote small userland program which polls CIRs IIR (interrupt identefication register) and it shows interrupt pending bit set on right after I press key on remote control. Looks like I missed something fundamental. Does anyone can give me a hint where to look? Thanks, Alexander. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No interrupts coming to device driver.
Daniel O'Connor wrote: On Thu, 10 Nov 2005 19:20, Alexander Nedotsukov wrote: -i shows zeros for assigned irq. And my IRS stay cold. I wrote small userland program which polls CIRs IIR (interrupt identefication register) and it shows interrupt pending bit set on right after I press key on remote control. Looks like I missed something fundamental. Does anyone can give me a hint where to look? Show us the code otherwise it's impossible to say.. Sure. http://bbnest.net/~bland/it87pub/ Also, you haven't said what version of FreeBSD you're using FreeBSD hub.bbnest.net 5.4-STABLE FreeBSD 5.4-STABLE #11: Sat Oct 29 13:25:50 JST 2005 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HUB i386 Alexander. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: No interrupts coming to device driver.
Hans Petter Selasky wrote: On Thursday 10 November 2005 09:50, Alexander Nedotsukov wrote: Hi, I trying to create small lirc (www.lirc.org) compatible CIR driver for it8705 chip (sits on ISA bus). My problem is I can not get interrupts coming to driver. I believe I configured chip (carrier freq. + baudrate divisor) and enabled interrupt mode the same way it windows driver does. It also seems to be correct according to chip specs. But nothing. vmstat -i shows zeros for assigned irq. And my IRS stay cold. I wrote small userland program which polls CIRs IIR (interrupt identefication register) and it shows interrupt pending bit set on right after I press key on remote control. Looks like I missed something fundamental. Does anyone can give me a hint where to look? Sounds like you have an unacknowledged interrupt. Does it help if you call the interrupt handler once after that your chip has been reset and configured? Did you mean unacknowledged to chip or interrupt controller? Anyway calling interrupt handler right after initialization does not seem to help. Else sharing some of the source code might help. Here you are: http://bbnest.net/~bland/it87pub/ Alexander. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devel/libgtop2 cannot build
Norikatsu Shigemura wrote: On Thu, 18 Nov 2004 09:57:10 -0600 Conrad J. Sabatier [EMAIL PROTECTED] wrote: /usr/ports/devel/libgtop2/work/libgtop-2.8.1/sysdeps/freebsd, works for me under CURRENT. I confirmed that it looks good, by running gnome-system-monior. It didn't crash. Yes, I did the same. The omission of those two assignments seems to do no harm. Of course, I could be wrong. :-) No problem for me:-). I think this is OK. GNOME maintainers, how about it? Proposed patch commited. Thanks, Alexander. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libusbhid(3) should not clear report_size field
Matthew N. Dodd wrote: On Mon, 26 Jan 2004, Maksim Yevmenkin wrote: Index: src/lib/libusbhid/parse.c === RCS file: /home/ncvs/src/lib/libusbhid/parse.c,v retrieving revision 1.8 diff -u -r1.8 parse.c --- src/lib/libusbhid/parse.c 9 Apr 2003 01:52:48 - 1.8 +++ src/lib/libusbhid/parse.c 26 Jan 2004 22:25:26 - @@ -86,7 +86,6 @@ c-string_minimum = 0; c-string_maximum = 0; c-set_delimiter = 0; - c-report_size = 0; } hid_data_t I've tried to keep them in sync in the past so this looks good to me. Oh. I was under inpression of this: lib/libusbhid/Makefile:MAINTAINER= [EMAIL PROTECTED] I sent patch above to maintainer about three month ago but get no responce. Fianlly mailed everyone incl. NetBSD guys, filled PR and gaveup :-( Obviously Nick is very busy with real life and there is a sence to expand/reassign/release ubs maintainership? All the best, Alexander. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
