From brde at optusnet.com.au Thu Oct 1 00:03:01 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Thu Oct 1 00:03:07 2009 Subject: Interrupt Descriptions In-Reply-To: <200909301732.20589.jhb@freebsd.org> References: <200909301732.20589.jhb@freebsd.org> Message-ID: <20091001090218.L21015@delplex.bde.org> On Wed, 30 Sep 2009, John Baldwin wrote: > A few folks have asked recently for the ability to add descriptive strings to > registered interrupt handlers. This is especially true since the advent of > MSI with multiple interrupts per device. I hacked up a prototype today that Interrupt names should be no longer than 4 (5 works sometimes) characters so that they can be displayed by systat -v. >... >> vmstat -i > interrupt total rate > irq1: atkbd0 8 0 The 4-5 characters doesn't include "irqN". (systat -v already does extra work to avoid the bad naming scheme visible here. It moves the "irqN" to the end, and removes the ":", else truncating these names would give a larger mess and there would only be space for 3-4 characters of the device name after wasting 1 for the ":".) "atkbd0" is already far too long, so systat -v would display "atkbd0 irq" in the 10 columns available, except it omits "irq" in this case so as to print the interrupt number, and actually displays "atkbd0 1". > irq4: uart0 751 5 > irq6: fdc0 6 0 > irq14: ata0 36 0 > irq20: uhci0 20 0 These are short enough to be displayed by systat -v (after removal of the ":" in 2 cases and after removal of the ":" and the "irq" in 1 case). > irq23: uhci3 ehci0 2 0 systat -v has no chance of displaying multiple devices per interrupt. I think it finds no space to print even the irq number, and also loses the ehci number after truncating at "uhci3 ehci". > irq28: mpt0 1661 11 Short enough. > irq256: igb0:tx 0 880 6 I think this gets truncated to "igb0:tx 0 ". The device name doesn't follows the rules for naming devices (should contain no whitespace), so the final "0" looks like the interrupt number. Interrupt numbers > 99 cause further problems for systat. Now there is only space for 3 characters in the device name ("xx0 irq256" takes 10 columns). > irq257: igb0:rx 0 1098 7 > irq258: igb0:link 3 0 > irq259: igb1:tx 0 1 0 > irq260: igb1:rx 0 134 0 > irq261: igb1:link 3 0 Similar messes. systat has no support for varying the terminal width, and adding such support would be difficult because the display is very complicated and hard-coded, so the truncation occurs even if you have a wide terminal. Adding support for the English parser needed to translate more cases would be even more difficult. The "irqN:" translation is MD (probably only helps for amd64 and i386). The above output shows related misformatting for vmstat. Interrupt name strings are supposed to be NUL-terminated and packed into a string space, mainly to match the historical interface to vmstat, which was designed mainly for space-efficiency. I think they are still in a string space, but at least on amd64 and i386 the implementation is extremely space-inefficient, with many unused entries and every entry padded with spaces to length MAXCOMLEN bytes (plus the NUL terminator). MAXCOMLEN is 19, and most of the 19 are used for the verbose names in the above. Then vmstat leaves about 15 more spaces before the totals column (it uses format "%-*s %20llu..."), giving the above ugly output. The "*" in the format is supposed to be dynamic, but this is defeated by the space-padding. Leaving space for 20-digit numbers is bogus: the 20 is a hard coding of the number of digits needed to display the largest 64-bit long long, but long longs might be longer than that, and the maximum is unreachable even with 64-bit long longs. OTOH, MAXCOMLEN is a bit short for a description. Bruce From phk at phk.freebsd.dk Thu Oct 1 06:35:20 2009 From: phk at phk.freebsd.dk (Poul-Henning Kamp) Date: Thu Oct 1 06:35:26 2009 Subject: Interrupt Descriptions In-Reply-To: Your message of "Thu, 01 Oct 2009 10:02:57 +1000." <20091001090218.L21015@delplex.bde.org> Message-ID: <88388.1254378922@critter.freebsd.dk> In message <20091001090218.L21015@delplex.bde.org>, Bruce Evans writes: >Interrupt names should be no longer than 4 (5 works sometimes) characters so >that they can be displayed by systat -v. I disagree. Bytes are cheaper now than they were on a PDP11. We should use as many as is necessary to convey sensible information. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From brampton+freebsd at gmail.com Thu Oct 1 09:15:38 2009 From: brampton+freebsd at gmail.com (Andrew Brampton) Date: Thu Oct 1 09:15:45 2009 Subject: Interrupt Descriptions In-Reply-To: <200909301732.20589.jhb@freebsd.org> References: <200909301732.20589.jhb@freebsd.org> Message-ID: 2009/9/30 John Baldwin : > A few folks have asked recently for the ability to add descriptive strings to > registered interrupt handlers. ?This is especially true since the advent of > MSI with multiple interrupts per device. ?I hacked up a prototype today that > adds a new 'bus_describe_intr()' that takes the IRQ resource, the void * > cookie returned by bus_setup_intr() and var args description and appends that > to the interrupt name in the thread and vmstat -i info. ?The current patch > only has the MI bits and the MD bits for amd64 as well as a sample change to > the igb(4) driver. > > The patch is at http://www.FreeBSD.org/~jhb/patches/intr_describe.patch. > Very cool feature, which I had been hoping for on FreeBSD. Well done. Andrew From rpaulo at gmail.com Thu Oct 1 10:19:39 2009 From: rpaulo at gmail.com (Rui Paulo) Date: Thu Oct 1 10:19:45 2009 Subject: Interrupt Descriptions In-Reply-To: <20091001090218.L21015@delplex.bde.org> References: <200909301732.20589.jhb@freebsd.org> <20091001090218.L21015@delplex.bde.org> Message-ID: <95A6555E-09DE-45E4-BF80-D2C524CD33C3@gmail.com> On 1 Oct 2009, at 01:02, Bruce Evans wrote: > On Wed, 30 Sep 2009, John Baldwin wrote: > >> A few folks have asked recently for the ability to add descriptive >> strings to >> registered interrupt handlers. This is especially true since the >> advent of >> MSI with multiple interrupts per device. I hacked up a prototype >> today that > > Interrupt names should be no longer than 4 (5 works sometimes) > characters so > that they can be displayed by systat -v. We should just change systat, IMHO, but I know it's not easy. -- Rui Paulo From brde at optusnet.com.au Thu Oct 1 12:58:34 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Thu Oct 1 12:58:42 2009 Subject: Interrupt Descriptions In-Reply-To: <88388.1254378922@critter.freebsd.dk> References: <88388.1254378922@critter.freebsd.dk> Message-ID: <20091001224601.A21418@delplex.bde.org> On Thu, 1 Oct 2009, Poul-Henning Kamp wrote: > In message <20091001090218.L21015@delplex.bde.org>, Bruce Evans writes: > >> Interrupt names should be no longer than 4 (5 works sometimes) characters so >> that they can be displayed by systat -v. > > I disagree. Bytes are cheaper now than they were on a PDP11. We should > use as many as is necessary to convey sensible information. s/should/shall/ then. It is the API that interrupt names must be no longer than 4. You can disagree with this being the best API but not with what it is. Using many bytes here results in no information being conveyed in some cases, not sensible information, when the long description is truncated to 3-4 characters to fit in the available space. Bruce From avg at icyb.net.ua Thu Oct 1 13:07:58 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Oct 1 13:08:04 2009 Subject: Interrupt Descriptions In-Reply-To: <200909301732.20589.jhb@freebsd.org> References: <200909301732.20589.jhb@freebsd.org> Message-ID: <4AC4A567.7050204@icyb.net.ua> on 01/10/2009 00:32 John Baldwin said the following: > A few folks have asked recently for the ability to add descriptive strings to > registered interrupt handlers. This is especially true since the advent of > MSI with multiple interrupts per device. I hacked up a prototype today that > adds a new 'bus_describe_intr()' that takes the IRQ resource, the void * > cookie returned by bus_setup_intr() and var args description and appends that > to the interrupt name in the thread and vmstat -i info. The current patch > only has the MI bits and the MD bits for amd64 as well as a sample change to > the igb(4) driver. > > The patch is at http://www.FreeBSD.org/~jhb/patches/intr_describe.patch. > > An example from this patch is: > >> vmstat -i > interrupt total rate > irq1: atkbd0 8 0 > irq4: uart0 751 5 > irq6: fdc0 6 0 > irq14: ata0 36 0 > irq20: uhci0 20 0 > irq23: uhci3 ehci0 2 0 > irq28: mpt0 1661 11 > irq256: igb0:tx 0 880 6 > irq257: igb0:rx 0 1098 7 > irq258: igb0:link 3 0 > irq259: igb1:tx 0 1 0 > irq260: igb1:rx 0 134 0 > irq261: igb1:link 3 0 > Example above doesn't demonstrate what happens when there are shared interrupts. Would it still look nice (with sufficiently long descriptions)? -- Andriy Gapon From brde at optusnet.com.au Thu Oct 1 13:31:36 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Thu Oct 1 13:31:41 2009 Subject: Interrupt Descriptions In-Reply-To: <95A6555E-09DE-45E4-BF80-D2C524CD33C3@gmail.com> References: <200909301732.20589.jhb@freebsd.org> <20091001090218.L21015@delplex.bde.org> <95A6555E-09DE-45E4-BF80-D2C524CD33C3@gmail.com> Message-ID: <20091001225842.X21418@delplex.bde.org> On Thu, 1 Oct 2009, Rui Paulo wrote: > On 1 Oct 2009, at 01:02, Bruce Evans wrote: > >> On Wed, 30 Sep 2009, John Baldwin wrote: >> >>> A few folks have asked recently for the ability to add descriptive strings >>> to >>> registered interrupt handlers. This is especially true since the advent >>> of >>> MSI with multiple interrupts per device. I hacked up a prototype today >>> that >> >> Interrupt names should be no longer than 4 (5 works sometimes) characters >> so >> that they can be displayed by systat -v. Make that: "Interrupt names must must contain only characters that take 1 space to print, and must be no longer than 10 characters, or unique and without garbage when blindly truncated to 10 characters, or in a special form that can easily be understood and compressed to <= 10 characters. The special forms are..." Similarly for device names (max length 4 or 5) and sleep message strings (max length 6). > We should just change systat, IMHO, but I know it's not easy. It's impossible to make changes that increase display resource requirements without breaking something. Either small displays stop working or scrolling is required. Bruce From rnoland at FreeBSD.org Thu Oct 1 13:48:00 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Oct 1 13:48:07 2009 Subject: Interrupt Descriptions In-Reply-To: <20091001225842.X21418@delplex.bde.org> References: <200909301732.20589.jhb@freebsd.org> <20091001090218.L21015@delplex.bde.org> <95A6555E-09DE-45E4-BF80-D2C524CD33C3@gmail.com> <20091001225842.X21418@delplex.bde.org> Message-ID: <1254404871.2320.99.camel@balrog.2hip.net> On Thu, 2009-10-01 at 23:31 +1000, Bruce Evans wrote: > On Thu, 1 Oct 2009, Rui Paulo wrote: > > > On 1 Oct 2009, at 01:02, Bruce Evans wrote: > > > >> On Wed, 30 Sep 2009, John Baldwin wrote: > >> > >>> A few folks have asked recently for the ability to add descriptive strings > >>> to > >>> registered interrupt handlers. This is especially true since the advent > >>> of > >>> MSI with multiple interrupts per device. I hacked up a prototype today > >>> that > >> > >> Interrupt names should be no longer than 4 (5 works sometimes) characters > >> so > >> that they can be displayed by systat -v. > > Make that: "Interrupt names must must contain only characters that > take 1 space to print, and must be no longer than 10 characters, or > unique and without garbage when blindly truncated to 10 characters, > or in a special form that can easily be understood and compressed to > <= 10 characters. The special forms are..." > > Similarly for device names (max length 4 or 5) and sleep message strings > (max length 6). > > > We should just change systat, IMHO, but I know it's not easy. > > It's impossible to make changes that increase display resource requirements > without breaking something. Either small displays stop working or scrolling > is required. While I have always liked the fact that systat -v was capable of displaying most anything that you would care about in one display, lack of display real-estate is not a sufficient reason to limit the descriptions. Perhaps it is time for systat to get a bit of an overhaul... robert. > Bruce > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- Robert Noland FreeBSD From rnoland at FreeBSD.org Thu Oct 1 13:49:32 2009 From: rnoland at FreeBSD.org (Robert Noland) Date: Thu Oct 1 13:49:38 2009 Subject: Interrupt Descriptions In-Reply-To: <4AC4A567.7050204@icyb.net.ua> References: <200909301732.20589.jhb@freebsd.org> <4AC4A567.7050204@icyb.net.ua> Message-ID: <1254402755.2320.60.camel@balrog.2hip.net> On Thu, 2009-10-01 at 15:49 +0300, Andriy Gapon wrote: > on 01/10/2009 00:32 John Baldwin said the following: > > A few folks have asked recently for the ability to add descriptive strings to > > registered interrupt handlers. This is especially true since the advent of > > MSI with multiple interrupts per device. I hacked up a prototype today that > > adds a new 'bus_describe_intr()' that takes the IRQ resource, the void * > > cookie returned by bus_setup_intr() and var args description and appends that > > to the interrupt name in the thread and vmstat -i info. The current patch > > only has the MI bits and the MD bits for amd64 as well as a sample change to > > the igb(4) driver. > > > > The patch is at http://www.FreeBSD.org/~jhb/patches/intr_describe.patch. > > > > An example from this patch is: > > > >> vmstat -i > > interrupt total rate > > irq1: atkbd0 8 0 > > irq4: uart0 751 5 > > irq6: fdc0 6 0 > > irq14: ata0 36 0 > > irq20: uhci0 20 0 > > irq23: uhci3 ehci0 2 0 > > irq28: mpt0 1661 11 > > irq256: igb0:tx 0 880 6 > > irq257: igb0:rx 0 1098 7 > > irq258: igb0:link 3 0 > > irq259: igb1:tx 0 1 0 > > irq260: igb1:rx 0 134 0 > > irq261: igb1:link 3 0 > > > > Example above doesn't demonstrate what happens when there are shared interrupts. > Would it still look nice (with sufficiently long descriptions)? vmstat -i already chops off lots of stuff if there are very many shared irqs. robert. -- Robert Noland FreeBSD From jhb at freebsd.org Thu Oct 1 14:02:17 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Oct 1 14:02:37 2009 Subject: Interrupt Descriptions In-Reply-To: <20091001090218.L21015@delplex.bde.org> References: <200909301732.20589.jhb@freebsd.org> <20091001090218.L21015@delplex.bde.org> Message-ID: <200910010949.20849.jhb@freebsd.org> On Wednesday 30 September 2009 8:02:57 pm Bruce Evans wrote: > On Wed, 30 Sep 2009, John Baldwin wrote: > > > A few folks have asked recently for the ability to add descriptive strings to > > registered interrupt handlers. This is especially true since the advent of > > MSI with multiple interrupts per device. I hacked up a prototype today that > > Interrupt names should be no longer than 4 (5 works sometimes) characters so > that they can be displayed by systat -v. For the machines this is targeted at (i.e. ones with devices using MSI/MSI-X) the number of interrupts is already well beyond what systat -v can currently display anyway. I believe most folks use vmstat -i or ithread stats in top to measure real-time interrupts at this point. Possibly systat could grow a new interrupt-only mode that has sufficient room for full interrupt names. FYI, it actually looks decent enough running a 7.x systat on a test 9.0 kernel: 25000 frevn pdpgs 2000 cpu0: time intrn igb0:tx 0 Disks da0 pass0 473896 wire 25 igb0:rx 0 KB/t 0.00 0.00 13872 act igb0:link tps 0 0 10080 inact igb1:tx 0 MB/s 0.00 0.00 128 cache 1 igb1:rx 0 %busy 0 0 7603460 free igb1:link For these devices with MSI, the description (tx 0, tx 1, link, etc.) is actually more meaningful than the IRQ. -- John Baldwin From jhb at freebsd.org Thu Oct 1 14:02:18 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Oct 1 14:02:38 2009 Subject: Interrupt Descriptions In-Reply-To: <4AC4A567.7050204@icyb.net.ua> References: <200909301732.20589.jhb@freebsd.org> <4AC4A567.7050204@icyb.net.ua> Message-ID: <200910010953.33838.jhb@freebsd.org> On Thursday 01 October 2009 8:49:43 am Andriy Gapon wrote: > on 01/10/2009 00:32 John Baldwin said the following: > > A few folks have asked recently for the ability to add descriptive strings to > > registered interrupt handlers. This is especially true since the advent of > > MSI with multiple interrupts per device. I hacked up a prototype today that > > adds a new 'bus_describe_intr()' that takes the IRQ resource, the void * > > cookie returned by bus_setup_intr() and var args description and appends that > > to the interrupt name in the thread and vmstat -i info. The current patch > > only has the MI bits and the MD bits for amd64 as well as a sample change to > > the igb(4) driver. > > > > The patch is at http://www.FreeBSD.org/~jhb/patches/intr_describe.patch. > > > > An example from this patch is: > > > >> vmstat -i > > interrupt total rate > > irq1: atkbd0 8 0 > > irq4: uart0 751 5 > > irq6: fdc0 6 0 > > irq14: ata0 36 0 > > irq20: uhci0 20 0 > > irq23: uhci3 ehci0 2 0 > > irq28: mpt0 1661 11 > > irq256: igb0:tx 0 880 6 > > irq257: igb0:rx 0 1098 7 > > irq258: igb0:link 3 0 > > irq259: igb1:tx 0 1 0 > > irq260: igb1:rx 0 134 0 > > irq261: igb1:link 3 0 > > > > Example above doesn't demonstrate what happens when there are shared interrupts. > Would it still look nice (with sufficiently long descriptions)? Currently MSI interrupts generally aren't shared. If they are shared what happens is that the 'name:descr' bit is treated as the full name of the device and the normal "+" or "*" truncation stuff kicks in so you would maybe have: irq280: igb0:tx 0 igb0:tx 1 except that doesn't fit in MAXCOMLEN so you would have: irq280: igb0:tx 0+ For the ithread name we are stuck with MAXCOMLEN. I would like to overhaul the intrcnt stuff to possibly allow for longer names and be mostly MI (having all the longs shared across cache lines that might be shared by multiple CPUs isn't ideal either at this point). I am considering having either an array or list of intrcnt structures with a name and a count with a sysctl that exports an array for vmstat to use (the kvm bits could always rebuild the list using the same logic as the sysctl handler for crash dumps). The current design is very limiting and forces the weird space padding to make renaming intrcnt descriptions manageable when adding/removing interrupt handlers. -- John Baldwin From brde at optusnet.com.au Thu Oct 1 16:43:36 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Thu Oct 1 16:45:04 2009 Subject: Interrupt Descriptions In-Reply-To: <1254402755.2320.60.camel@balrog.2hip.net> References: <200909301732.20589.jhb@freebsd.org> <4AC4A567.7050204@icyb.net.ua> <1254402755.2320.60.camel@balrog.2hip.net> Message-ID: <20091002004627.L21519@delplex.bde.org> On Thu, 1 Oct 2009, Robert Noland wrote: > On Thu, 2009-10-01 at 15:49 +0300, Andriy Gapon wrote: >> on 01/10/2009 00:32 John Baldwin said the following: >>> ... >>> An example from this patch is: >>> >>>> vmstat -i >>> interrupt total rate >>> irq1: atkbd0 8 0 >>> irq4: uart0 751 5 >>> irq6: fdc0 6 0 >>> irq14: ata0 36 0 >>> irq20: uhci0 20 0 >>> irq23: uhci3 ehci0 2 0 >>> irq28: mpt0 1661 11 >>> irq256: igb0:tx 0 880 6 >>> irq257: igb0:rx 0 1098 7 >>> irq258: igb0:link 3 0 >>> irq259: igb1:tx 0 1 0 >>> irq260: igb1:rx 0 134 0 >>> irq261: igb1:link 3 0 >> >> Example above doesn't demonstrate what happens when there are shared interrupts. irq23 seems to be shared by uhci3 and ehci0. This part of the description is not new (I think device names are just concatenated until space runs out). >> Would it still look nice (with sufficiently long descriptions)? > > vmstat -i already chops off lots of stuff if there are very many shared > irqs. Not vmstat -i, but the kernel. vmstat -i attempts to display the entire string, unlike systat -v, but the kernel only has space for strings of length MAXCOMLEN - 1 (18) (ie_name[MAXCOMLEN] nd ie_fullname[MAXCOMLEN] in ) (unless jhb increased this). This is the same limit as for command names of executables, except for the off-by-1 error for interrupt names, and for various bugs involving thread names (p_comm[MAXCOMLEN + 1], etc.). Concatenating thread names with process names causes similar display problems in ps and top, etc. Space is short for displaying just p_comm[] plus args, and showing td_name[] too needs more space. Actually concatenation doesn't work at all. ps must select the "name" string that works, but it gets this wrong somehow (ps -laxHw seems to display only p_comm (ki_comm in ps), resulting in useless names for all idle and interrupt threads, although ps has code to support td_name (ki_ocomm is abused to hold the part of this that fits in ps). -H works almost right in top, and the truncated td_name string can be seen using the undocumented tdnam keyword in ps). Bruce From brde at optusnet.com.au Thu Oct 1 17:14:04 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Thu Oct 1 17:14:11 2009 Subject: Interrupt Descriptions In-Reply-To: <200910010949.20849.jhb@freebsd.org> References: <200909301732.20589.jhb@freebsd.org> <20091001090218.L21015@delplex.bde.org> <200910010949.20849.jhb@freebsd.org> Message-ID: <20091002024550.X21519@delplex.bde.org> On Thu, 1 Oct 2009, John Baldwin wrote: > On Wednesday 30 September 2009 8:02:57 pm Bruce Evans wrote: >> On Wed, 30 Sep 2009, John Baldwin wrote: >> >>> A few folks have asked recently for the ability to add descriptive strings to >>> registered interrupt handlers. This is especially true since the advent of >>> MSI with multiple interrupts per device. I hacked up a prototype today that >> >> Interrupt names should be no longer than 4 (5 works sometimes) characters so >> that they can be displayed by systat -v. > > For the machines this is targeted at (i.e. ones with devices using MSI/MSI-X) > the number of interrupts is already well beyond what systat -v can currently > display anyway. This should be fixed before expanding the names into descriptions. I wonder what uses all these interrupts. Most FreeBSD cluster machines use a whole 3 interrupts apart from acpi_timer, with 1 barely active (1 disk, 1 net, and 1 serial i/o probably only used for a serial console). My workstations use about 10 plus timers, but most are usually inactive except for net, keyboard and sometimes disk. Does anyone have systems more than about 16 disk controllers and 16 network cards so as to need more than 32 interrupts? > I believe most folks use vmstat -i or ithread stats in top > to measure real-time interrupts at this point. Possibly systat could grow a > new interrupt-only mode that has sufficient room for full interrupt names. I don't find static info and thus vmstat -i very useful. vmstat with a repeat interval is useful, but for some reason vmstat -i never supported the repeat interval (its multi-line display is certainly unsuitable for repetitions being readable), and with systat -v repetition in vmstat -i is rarely missed. A repeating vmstat -i would have even more space problems than systat -v, since it would want to repeat single line output. systat and most things just want a unique tag, not a description or even a full name. The full name could be looked up from a tag by looking at vmstat -i output which could show both. > > FYI, it actually looks decent enough running a 7.x systat on a test 9.0 kernel: > > 25000 frevn pdpgs 2000 cpu0: time > intrn igb0:tx 0 > Disks da0 pass0 473896 wire 25 igb0:rx 0 > KB/t 0.00 0.00 13872 act igb0:link > tps 0 0 10080 inact igb1:tx 0 > MB/s 0.00 0.00 128 cache 1 igb1:rx 0 > %busy 0 0 7603460 free igb1:link > > For these devices with MSI, the description (tx 0, tx 1, link, etc.) is > actually more meaningful than the IRQ. The irq is probably least useful for most devices. The above is only reasonable because I changed systat to move "irqN: " to " irqN" at the end. "irq256: bce0" on FreeBSD cluster machines is displayed reasonably as "bce0 256". But systat shouldn't have to do this. At least the form of the names used by systat (== the one given by the old intrnames API) should have names that are carefully phrased to have the most useful info first, and to not waste space with ": " or even "irq". Bruce From jfvogel at gmail.com Thu Oct 1 17:25:27 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Thu Oct 1 17:25:34 2009 Subject: Interrupt Descriptions In-Reply-To: <20091002024550.X21519@delplex.bde.org> References: <200909301732.20589.jhb@freebsd.org> <20091001090218.L21015@delplex.bde.org> <200910010949.20849.jhb@freebsd.org> <20091002024550.X21519@delplex.bde.org> Message-ID: <2a41acea0910011025q2b5834f2n113f5a8a607ecb4d@mail.gmail.com> What uses them, machines with multiqueue, in my ixgbe driver a rx/tx pair of queues is configured and bound to each cpu. This ability really matters when you do virtualization because the queues can be assigned per guest. So right now with 16 cpus a single Niantic or Oplin port (10G) has 33 MSIX vectors. I brought this request to John because our validation group complained. On Linux they have a description for each interrupt and they want the same for FreeBSD. Welcome to the 21st century :) Jack On Thu, Oct 1, 2009 at 10:14 AM, Bruce Evans wrote: > On Thu, 1 Oct 2009, John Baldwin wrote: > > On Wednesday 30 September 2009 8:02:57 pm Bruce Evans wrote: >> >>> On Wed, 30 Sep 2009, John Baldwin wrote: >>> >>> A few folks have asked recently for the ability to add descriptive >>>> strings to >>>> registered interrupt handlers. This is especially true since the advent >>>> of >>>> MSI with multiple interrupts per device. I hacked up a prototype today >>>> that >>>> >>> >>> Interrupt names should be no longer than 4 (5 works sometimes) characters >>> so >>> that they can be displayed by systat -v. >>> >> >> For the machines this is targeted at (i.e. ones with devices using >> MSI/MSI-X) >> the number of interrupts is already well beyond what systat -v can >> currently >> display anyway. >> > > This should be fixed before expanding the names into descriptions. > > I wonder what uses all these interrupts. Most FreeBSD cluster machines use > a whole 3 interrupts apart from acpi_timer, with 1 barely active (1 disk, > 1 net, and 1 serial i/o probably only used for a serial console). My > workstations use about 10 plus timers, but most are usually inactive > except for net, keyboard and sometimes disk. Does anyone have systems > more than about 16 disk controllers and 16 network cards so as to need > more than 32 interrupts? > > I believe most folks use vmstat -i or ithread stats in top >> to measure real-time interrupts at this point. Possibly systat could grow >> a >> new interrupt-only mode that has sufficient room for full interrupt names. >> > > I don't find static info and thus vmstat -i very useful. vmstat with a > repeat interval is useful, but for some reason vmstat -i never supported > the repeat interval (its multi-line display is certainly unsuitable for > repetitions being readable), and with systat -v repetition in vmstat -i > is rarely missed. A repeating vmstat -i would have even more space > problems than systat -v, since it would want to repeat single line output. > > systat and most things just want a unique tag, not a description or even > a full name. The full name could be looked up from a tag by looking at > vmstat -i output which could show both. > > >> FYI, it actually looks decent enough running a 7.x systat on a test 9.0 >> kernel: >> >> 25000 frevn pdpgs 2000 cpu0: >> time >> intrn >> igb0:tx 0 >> Disks da0 pass0 473896 wire 25 >> igb0:rx 0 >> KB/t 0.00 0.00 13872 act >> igb0:link >> tps 0 0 10080 inact >> igb1:tx 0 >> MB/s 0.00 0.00 128 cache 1 >> igb1:rx 0 >> %busy 0 0 7603460 free >> igb1:link >> >> For these devices with MSI, the description (tx 0, tx 1, link, etc.) is >> actually more meaningful than the IRQ. >> > > The irq is probably least useful for most devices. > > The above is only reasonable because I changed systat to move "irqN: > " to " irqN" at the end. "irq256: bce0" on FreeBSD cluster machines > is displayed reasonably as "bce0 256". But systat shouldn't have to > do this. At least the form of the names used by systat (== the one > given by the old intrnames API) should have names that are carefully > phrased to have the most useful info first, and to not waste space > with ": " or even "irq". > > Bruce > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From brde at optusnet.com.au Thu Oct 1 17:54:19 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Thu Oct 1 17:54:26 2009 Subject: Interrupt Descriptions In-Reply-To: <200910010953.33838.jhb@freebsd.org> References: <200909301732.20589.jhb@freebsd.org> <4AC4A567.7050204@icyb.net.ua> <200910010953.33838.jhb@freebsd.org> Message-ID: <20091002031720.J21519@delplex.bde.org> On Thu, 1 Oct 2009, John Baldwin wrote: > For the ithread name we are stuck with MAXCOMLEN. I would like to overhaul > the intrcnt stuff to possibly allow for longer names and be mostly MI (having > all the longs shared across cache lines that might be shared by multiple CPUs > isn't ideal either at this point). I am considering having either an array or > list of intrcnt structures with a name and a count with a sysctl that exports > an array for vmstat to use (the kvm bits could always rebuild the list using > the same logic as the sysctl handler for crash dumps). The current design is > very limiting and forces the weird space padding to make renaming intrcnt > descriptions manageable when adding/removing interrupt handlers. The design has few limits. My old implementation had no limits on name lengths. It just had a limit on the combined length, due to it allocating the string space statically. String spaces without padding require about 10 extra lines to create and zero extra lines to use (since the users already expect a string space so they already have the extra lines to walk over it). Changing the descriptions, including rebuilding the whole string space whenever an interrupt handler is added/removed/renamed shouldn't be a problem since this is a rare event. Just lock out the sysctl and other accesses to the string space while changing/reallocating the string space. Counters are harder -- you can't move them without locking out interrupt handlers that increment them. You could also delay rebuilding until the sysctl (wouldn't be so easy for kvm). The sysctl would take longer, but perhaps no longer than now since the data size should be much smaller -- instead of 100's of padded strings there should be only a few unpadded ones (the strings on ref8-i386 now consists of 49 "stray irqN" (padded), 42 unused "irqN:" (padded), one "???" (padded; unused I think -- this "???" is for when the table fills up and/or when an unexpected irq occurs, but the table now covers everything and has zillions of stray slots for unexpected ireq), and 15 lines for interrupts actually attached (8 lapic timer, 2 moderately used, 1 rarely used, 3 never used). systat wouldn't like the tables' sizes or string contents changing underneath it, but in the rare event that this happens it couldn't do worse than crash, and it could detect the change using a new generation count. vmstat wouldn't have any problems since it only reads the tables once (minor race between the independent sysctls). The kvm interface doesn't support dynamic table allocation. You would probably have to change it eventually to support per-CPU counters if you actually want to keep supporting interrupt stats in dead kernels. Bruce From jhb at freebsd.org Thu Oct 1 18:27:10 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Oct 1 18:27:21 2009 Subject: Interrupt Descriptions In-Reply-To: <20091002031720.J21519@delplex.bde.org> References: <200909301732.20589.jhb@freebsd.org> <200910010953.33838.jhb@freebsd.org> <20091002031720.J21519@delplex.bde.org> Message-ID: <200910011412.31250.jhb@freebsd.org> On Thursday 01 October 2009 1:54:15 pm Bruce Evans wrote: > On Thu, 1 Oct 2009, John Baldwin wrote: > > > For the ithread name we are stuck with MAXCOMLEN. I would like to overhaul > > the intrcnt stuff to possibly allow for longer names and be mostly MI (having > > all the longs shared across cache lines that might be shared by multiple CPUs > > isn't ideal either at this point). I am considering having either an array or > > list of intrcnt structures with a name and a count with a sysctl that exports > > an array for vmstat to use (the kvm bits could always rebuild the list using > > the same logic as the sysctl handler for crash dumps). The current design is > > very limiting and forces the weird space padding to make renaming intrcnt > > descriptions manageable when adding/removing interrupt handlers. > > The design has few limits. My old implementation had no limits on > name lengths. It just had a limit on the combined length, due to it > allocating the string space statically. String spaces without padding > require about 10 extra lines to create and zero extra lines to use > (since the users already expect a string space so they already have > the extra lines to walk over it). Changing the descriptions, including > rebuilding the whole string space whenever an interrupt handler is > added/removed/renamed shouldn't be a problem since this is a rare > event. Just lock out the sysctl and other accesses to the string space > while changing/reallocating the string space. Counters are harder -- > you can't move them without locking out interrupt handlers that > increment them. I consider having to rebuild the entire namespace when changing one name a design limitation. I think it worked fine when you had machines without hotplug hardware (or drivers) where the set of interrupts in use was essentially built once during boot and static thereafter. However, that is no longer the machines we have. -- John Baldwin From jhb at freebsd.org Thu Oct 1 18:27:11 2009 From: jhb at freebsd.org (John Baldwin) Date: Thu Oct 1 18:27:21 2009 Subject: Interrupt Descriptions In-Reply-To: <20091002024550.X21519@delplex.bde.org> References: <200909301732.20589.jhb@freebsd.org> <200910010949.20849.jhb@freebsd.org> <20091002024550.X21519@delplex.bde.org> Message-ID: <200910011426.56047.jhb@freebsd.org> On Thursday 01 October 2009 1:14:01 pm Bruce Evans wrote: > On Thu, 1 Oct 2009, John Baldwin wrote: > > > On Wednesday 30 September 2009 8:02:57 pm Bruce Evans wrote: > >> On Wed, 30 Sep 2009, John Baldwin wrote: > >> > >>> A few folks have asked recently for the ability to add descriptive strings to > >>> registered interrupt handlers. This is especially true since the advent of > >>> MSI with multiple interrupts per device. I hacked up a prototype today that > >> > >> Interrupt names should be no longer than 4 (5 works sometimes) characters so > >> that they can be displayed by systat -v. > > > > For the machines this is targeted at (i.e. ones with devices using MSI/MSI-X) > > the number of interrupts is already well beyond what systat -v can currently > > display anyway. > > This should be fixed before expanding the names into descriptions. To me this change doesn't make systat any more or less broken than it was before, so I consider systat an orthogonal problem. > I wonder what uses all these interrupts. Most FreeBSD cluster machines use > a whole 3 interrupts apart from acpi_timer, with 1 barely active (1 disk, > 1 net, and 1 serial i/o probably only used for a serial console). My > workstations use about 10 plus timers, but most are usually inactive > except for net, keyboard and sometimes disk. Does anyone have systems > more than about 16 disk controllers and 16 network cards so as to need > more than 32 interrupts? As Jack mentioned, many newer devices are starting to take advantage of MSI to use multiple interrupts for a single device. A typical cxgb(4) adapter will use up to 9 interrupts (1 for link/misc, and 1 per-CPU for a RX/TX queueset). The Intel 10gb driver takes this even farther by giving each queueset separate RX/TX interrupts and it supports up to 16 queues giving up to 33 total interrupts per device. Even the igb(4) driver currently uses 1 interrupt for link, 1 for each RX queue, and 1 for each TX queue and it supports having at least 4 RX queues (possibly as many as 8?). Devices of this nature using lots of interrupts is also what drove the change to use per-CPU IDTs in 8.0 to increase the number of available IDT vectors for these types of devices that want MSI interrupts tied to every CPU. > > I believe most folks use vmstat -i or ithread stats in top > > to measure real-time interrupts at this point. Possibly systat could grow a > > new interrupt-only mode that has sufficient room for full interrupt names. > > I don't find static info and thus vmstat -i very useful. vmstat with a > repeat interval is useful, but for some reason vmstat -i never supported > the repeat interval (its multi-line display is certainly unsuitable for > repetitions being readable), and with systat -v repetition in vmstat -i > is rarely missed. A repeating vmstat -i would have even more space > problems than systat -v, since it would want to repeat single line output. For certain tests simply doing a before and after of vmstat -i and figuring out the diff manually (sometimes just having a diff at all is important rather than the number (e.g. did some action I just did generate an interrupt?)) is sufficient. > systat and most things just want a unique tag, not a description or even > a full name. The full name could be looked up from a tag by looking at > vmstat -i output which could show both. This could be interesting perhaps. I would probably want to change my proposed intrcnt structure to contain three things then: a unique tag, a full name, and a count. One possible idea for the unique "tag" would be to use the interrupt handler name if there is only a single handler or to use the 'irqXXX' name if the interrupt is shared. -- John Baldwin From brde at optusnet.com.au Thu Oct 1 20:41:22 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Thu Oct 1 20:41:29 2009 Subject: Interrupt Descriptions In-Reply-To: <200910011412.31250.jhb@freebsd.org> References: <200909301732.20589.jhb@freebsd.org> <200910010953.33838.jhb@freebsd.org> <20091002031720.J21519@delplex.bde.org> <200910011412.31250.jhb@freebsd.org> Message-ID: <20091002053705.F21979@delplex.bde.org> On Thu, 1 Oct 2009, John Baldwin wrote: > On Thursday 01 October 2009 1:54:15 pm Bruce Evans wrote: >> >> The design has few limits. My old implementation had no limits on >> name lengths.... > > I consider having to rebuild the entire namespace when changing one name > a design limitation. I think it worked fine when you had machines without > hotplug hardware (or drivers) where the set of interrupts in use was > essentially built once during boot and static thereafter. Those probably didn't have anything as sophisticated as building it at boot time. In 4.4BSD-Lite2 it is just hard-coded into locore for hp300, sparc, luna64 and pmax, while for news3400 it is partially declared but not defined. It is missing even declarations for all other arches including i386, and pmax has a comment saying that the counters aren't used (perhaps they aren't used for any arch). I fixed this for i386. > However, that > is no longer the machines we have. Who cares if you have to rebuild the entire namespace occasionally. Any sort of dynamic allocation would need to rebuild it to extend it. String spaces are very easy to expand since they don't have any internal pointers and shouldn't have many external ones. Anyway, the design doesn't require rebuilding the namespace for all changes. My old implementation usually adds to the end of the string space using statically allocated space. There are external pointers that keep the names indexed consistently with the counters. New interrupts normally get a new slot in intrcnt[]. Old slots are intentionally not reused, except by devices with the same interrupt name. They preserve the names and interrupt counts of previously attached devices. Now, I think the intrcnt[] index is identical with the interrupt number, and old driver names are lost and old interrupt counts are merged (zeroed?) when a slot is reused. The old implementation also handles sparsely allocated interrupt numbers (which are just starting to become common) nicely without sparsely allocating all the tables. Now the tables use sparse allocation for an enormous number of slots. There seem to be 256 slots for non-MSI and another 512 for MSI giving a basic 768. This is then doubled to give slots for stray interrupts, and there are a few special-purpose slots, giving a total of a little more than 1536. This gives a string space size of about 32K. To simplify the implementation, the space for MSI and several APICs is allocated unconditionally. Here is the 4.4BSD-Lite2 code for hp300: % .globl _intrcnt,_eintrcnt,_intrnames,_eintrnames % _intrnames: % .asciz "spur" % .asciz "hil" % .asciz "lev2" % .asciz "lev3" % .asciz "lev4" % .asciz "lev5" % .asciz "dma" % .asciz "clock" % .asciz "statclock" % .asciz "nmi" % _eintrnames: % .even % _intrcnt: % .long 0,0,0,0,0,0,0,0,0,0 % _eintrcnt: This takes 53 bytes (plus 1 or 3 for padding) for the string space. Most machines still need about 53 bytes for the string space (don't waste slots to count or name stray interrupts separately). These 53 bytes can be built and processed by userland on every sysctl much faster than the 32K of mostly-unused bytes can even be copied out. Bruce From jhb at freebsd.org Fri Oct 2 13:30:10 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Oct 2 13:30:16 2009 Subject: Interrupt Descriptions In-Reply-To: <20091002053705.F21979@delplex.bde.org> References: <200909301732.20589.jhb@freebsd.org> <200910011412.31250.jhb@freebsd.org> <20091002053705.F21979@delplex.bde.org> Message-ID: <200910020930.01228.jhb@freebsd.org> On Thursday 01 October 2009 4:41:19 pm Bruce Evans wrote: > On Thu, 1 Oct 2009, John Baldwin wrote: > > > On Thursday 01 October 2009 1:54:15 pm Bruce Evans wrote: > >> > >> The design has few limits. My old implementation had no limits on > >> name lengths.... > > > > I consider having to rebuild the entire namespace when changing one name > > a design limitation. I think it worked fine when you had machines without > > hotplug hardware (or drivers) where the set of interrupts in use was > > essentially built once during boot and static thereafter. > > Those probably didn't have anything as sophisticated as building it at > boot time. In 4.4BSD-Lite2 it is just hard-coded into locore for hp300, > sparc, luna64 and pmax, while for news3400 it is partially declared but > not defined. It is missing even declarations for all other arches > including i386, and pmax has a comment saying that the counters aren't > used (perhaps they aren't used for any arch). I fixed this for i386. > > > However, that > > is no longer the machines we have. > > Who cares if you have to rebuild the entire namespace occasionally. > Any sort of dynamic allocation would need to rebuild it to extend it. > String spaces are very easy to expand since they don't have any internal > pointers and shouldn't have many external ones. > > Anyway, the design doesn't require rebuilding the namespace for all > changes. My old implementation usually adds to the end of the string > space using statically allocated space. There are external pointers > that keep the names indexed consistently with the counters. New > interrupts normally get a new slot in intrcnt[]. Old slots are > intentionally not reused, except by devices with the same interrupt > name. They preserve the names and interrupt counts of previously attached > devices. Now, I think the intrcnt[] index is identical with the interrupt > number, and old driver names are lost and old interrupt counts are merged > (zeroed?) when a slot is reused. > > The old implementation also handles sparsely allocated interrupt numbers > (which are just starting to become common) nicely without sparsely > allocating all the tables. Now the tables use sparse allocation for > an enormous number of slots. There seem to be 256 slots for non-MSI and > another 512 for MSI giving a basic 768. This is then doubled to give > slots for stray interrupts, and there are a few special-purpose slots, > giving a total of a little more than 1536. This gives a string space > size of about 32K. To simplify the implementation, the space for MSI > and several APICs is allocated unconditionally. Some of this simplification can actually be undone now. We can probably wait to allocate an interrupt event for x86 interrupts until the first interrupt handler is installed and defer allocating intrcnt's until then. There were reasons why we always allocated ithreads back before interrupt events that I don't recall now. I'm also not sure we really need separate stray interrupt counts either at this point as stray interrupts are extremely rare. A single stray counter might suffice at this point. However, all of this is still orthogonal to interrupt description strings. > Here is the 4.4BSD-Lite2 code for hp300: > > % .globl _intrcnt,_eintrcnt,_intrnames,_eintrnames > % _intrnames: > % .asciz "spur" > % .asciz "hil" > % .asciz "lev2" > % .asciz "lev3" > % .asciz "lev4" > % .asciz "lev5" > % .asciz "dma" > % .asciz "clock" > % .asciz "statclock" > % .asciz "nmi" > % _eintrnames: > % .even > % _intrcnt: > % .long 0,0,0,0,0,0,0,0,0,0 > % _eintrcnt: > > This takes 53 bytes (plus 1 or 3 for padding) for the string space. > Most machines still need about 53 bytes for the string space (don't > waste slots to count or name stray interrupts separately). These 53 > bytes can be built and processed by userland on every sysctl much > faster than the 32K of mostly-unused bytes can even be copied out. I think this mostly serves to prove the point that the existing design is tailored to static configurations, not dynamic ones. -- John Baldwin From hselasky at freebsd.org Fri Oct 2 13:40:07 2009 From: hselasky at freebsd.org (Hans Petter Selasky) Date: Fri Oct 2 13:40:14 2009 Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f In-Reply-To: References: Message-ID: <200910021440.50021.hselasky@freebsd.org> Hi, Can the Apple's "Blocks" C language extension be used when programming in the kernel? Or is this a user-space only feature? --HPS From bugmaster at FreeBSD.org Mon Oct 5 11:06:48 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 5 11:07:15 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200910051106.n95B6lsB088598@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From cswiger at mac.com Tue Oct 6 19:50:25 2009 From: cswiger at mac.com (Chuck Swiger) Date: Tue Oct 6 19:50:31 2009 Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f In-Reply-To: <200910021440.50021.hselasky@freebsd.org> References: <200910021440.50021.hselasky@freebsd.org> Message-ID: <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Hi, Hans-- On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: > Can the Apple's "Blocks" C language extension be used when > programming in the kernel? Or is this a user-space only feature? While the main benefit of blocks is in conjunction with libdispatch for userland apps, they can be used by themselves, in the kernel or elsewhere. A block is a closure and starts off living on the stack (although, a block can outlive the stack frame of the caller by being copied over to the heap if needed); the compiler wraps automatic variables which were around in the scope of the caller, turns their type into const (unless you explicitly declare that you need to change a variable by using __block storage keyword, in which case that variable is kept on the heap and accessed by reference) in order to preserve the state until the block runs. In effect, blocks are normal function invocations which also have an extra argument which is the context or pointer to the saved environment state. They can be used to implement callbacks and continuations in a clean way, although you do have some overhead with accessing mutable variables via pointer dereference to the struct holding your saved context. However, most uses of callbacks in C are implemented as functions which accept a void *, which is used to feed the callback function a struct * of some sort, so the end result is fairly similar. Regards, -- -Chuck From rwatson at freebsd.org Tue Oct 6 20:29:55 2009 From: rwatson at freebsd.org (Robert N. M. Watson) Date: Tue Oct 6 20:30:00 2009 Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f In-Reply-To: <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Message-ID: On 6 Oct 2009, at 19:50, Chuck Swiger wrote: > Hi, Hans-- > > On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: >> Can the Apple's "Blocks" C language extension be used when >> programming in the kernel? Or is this a user-space only feature? > > While the main benefit of blocks is in conjunction with libdispatch > for userland apps, they can be used by themselves, in the kernel or > elsewhere. When a block is instantiated (perhaps not the formal terminology), the blocks runtime allocates memory to hold copies of relevant variables from the calling scope. This memory allocation may present an issue in some calling contexts in the kernel -- in particular, it won't be appropriate in contexts were non-sleepable locks are held, interrupt threads, etc. While it should be possible to use the primitive in the kernel, we may want to think carefully about these implications. Also, blocks are currently specific to clang, although with any luck gcc will grow them also. Robert > > A block is a closure and starts off living on the stack (although, a > block can outlive the stack frame of the caller by being copied over > to the heap if needed); the compiler wraps automatic variables which > were around in the scope of the caller, turns their type into const > (unless you explicitly declare that you need to change a variable by > using __block storage keyword, in which case that variable is kept > on the heap and accessed by reference) in order to preserve the > state until the block runs. > > In effect, blocks are normal function invocations which also have an > extra argument which is the context or pointer to the saved > environment state. They can be used to implement callbacks and > continuations in a clean way, although you do have some overhead > with accessing mutable variables via pointer dereference to the > struct holding your saved context. However, most uses of callbacks > in C are implemented as functions which accept a void *, which is > used to feed the callback function a struct * of some sort, so the > end result is fairly similar. > > Regards, > -- > -Chuck > From sgk at troutmask.apl.washington.edu Tue Oct 6 20:35:18 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Tue Oct 6 20:35:25 2009 Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f In-Reply-To: References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Message-ID: <20091006203518.GA26478@troutmask.apl.washington.edu> On Tue, Oct 06, 2009 at 09:29:50PM +0100, Robert N. M. Watson wrote: > > On 6 Oct 2009, at 19:50, Chuck Swiger wrote: > > >Hi, Hans-- > > > >On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: > >>Can the Apple's "Blocks" C language extension be used when > >>programming in the kernel? Or is this a user-space only feature? > > > >While the main benefit of blocks is in conjunction with libdispatch > >for userland apps, they can be used by themselves, in the kernel or > >elsewhere. > > When a block is instantiated (perhaps not the formal terminology), the > blocks runtime allocates memory to hold copies of relevant variables > from the calling scope. This memory allocation may present an issue in > some calling contexts in the kernel -- in particular, it won't be > appropriate in contexts were non-sleepable locks are held, interrupt > threads, etc. While it should be possible to use the primitive in the > kernel, we may want to think carefully about these implications. Also, > blocks are currently specific to clang, although with any luck gcc > will grow them also. > It is unlikely that gcc will grow support for block any time soon. http://gcc.gnu.org/ml/gcc/2009-09/msg00272.html -- Steve From rdivacky at freebsd.org Tue Oct 6 20:42:09 2009 From: rdivacky at freebsd.org (Roman Divacky) Date: Tue Oct 6 20:42:22 2009 Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f In-Reply-To: References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Message-ID: <20091006204152.GA37998@freebsd.org> On Tue, Oct 06, 2009 at 09:29:50PM +0100, Robert N. M. Watson wrote: > > On 6 Oct 2009, at 19:50, Chuck Swiger wrote: > > >Hi, Hans-- > > > >On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: > >>Can the Apple's "Blocks" C language extension be used when > >>programming in the kernel? Or is this a user-space only feature? > > > >While the main benefit of blocks is in conjunction with libdispatch > >for userland apps, they can be used by themselves, in the kernel or > >elsewhere. > > When a block is instantiated (perhaps not the formal terminology), the > blocks runtime allocates memory to hold copies of relevant variables > from the calling scope. This memory allocation may present an issue in > some calling contexts in the kernel -- in particular, it won't be > appropriate in contexts were non-sleepable locks are held, interrupt > threads, etc. While it should be possible to use the primitive in the > kernel, we may want to think carefully about these implications. Also, > blocks are currently specific to clang, although with any luck gcc > will grow them also. apple-gcc can do blocks iirc not that it matters for us. judging from the discussion on gcc ML they dont like this feature (they prefer C++0x lambdas and the thing from the new C standard iirc) From cswiger at mac.com Wed Oct 7 05:42:21 2009 From: cswiger at mac.com (Chuck Swiger) Date: Wed Oct 7 05:42:29 2009 Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on FreeBSD In-Reply-To: References: <200910021440.50021.hselasky@freebsd.org> <2097B9F8-B96F-4A37-B1D1-D094D65211F4@mac.com> Message-ID: <6E3505F9-C73D-480A-9304-890BF153983E@mac.com> Hi, Robert-- On Oct 6, 2009, at 1:29 PM, Robert N. M. Watson wrote: >> While the main benefit of blocks is in conjunction with libdispatch >> for userland apps, they can be used by themselves, in the kernel or >> elsewhere. > > When a block is instantiated (perhaps not the formal terminology), > the blocks runtime allocates memory to hold copies of relevant > variables from the calling scope. This memory allocation may present > an issue in some calling contexts in the kernel -- in particular, it > won't be appropriate in contexts were non-sleepable locks are held, > interrupt threads, etc. While it should be possible to use the > primitive in the kernel, we may want to think carefully about these > implications. Also, blocks are currently specific to clang, although > with any luck gcc will grow them also. Yes, you bring up some good points. Blocks haven't been around for long enough to have a widely visible track record as to their benefits and tradeoffs, and the compiler toolchain support is not too widely present, either. While I am confident that blocks could be used in the kernel (and so answered the question which Hans asked), whether the FreeBSD kernel should attempt to use them (much less right away) is more complex topic. Apple's changes to gcc-4.2 to add support for blocks is likely to be available here: http://opensource.apple.com/source/gcc/gcc-5646, or perhaps nearby in a sibling directory [1]. Blocks are normally allocated on the stack, unless you decide to copy them to the heap [2]. If do you need to put a block onto the heap, you shouldn't try to do so in a situation where you aren't OK to call malloc(9) or whatever Block_copy() would use. On the other hand, it's entirely possible that using blocks and dispatch queues would help identify and/ or resolve some of hard-to-reproduce race condition bugs or even deadlocks lurking in the depths of recursive locking/lock-order reversals. To address the other point made by Steve and Roman; the proposed C++0x lambda syntax using [] brackets conflicts with existing code written in ObjC++, so that is likely going to be a non-starter for some folks. Also, the ^ operator can't be overloaded in C++, whereas you can overload the array access operator (aka []). Regards, -- -Chuck [1]: There are a bunch of test cases under http://opensource.apple.com/source/gcc/gcc-5646/gcc/testsuite/gcc.apple/block-* , so I think I've found the right place. :-) [2]: Such as when you are returning a block, or you have a __block variable which itself is a block, or you are using C++ or ObjC and have GC or some sort of reference counting in use, as discussed here: http://clang.llvm.org/docs/BlockLanguageSpec.txt or here: http://thirdcog.eu/pwcblocks/ From hselasky at freebsd.org Wed Oct 7 08:45:17 2009 From: hselasky at freebsd.org (Hans Petter Selasky) Date: Wed Oct 7 08:45:24 2009 Subject: [libdispatch-dev] GCD libdispatch w/Blocks support working on Free (f In-Reply-To: <20091006204152.GA37998@freebsd.org> References: <20091006204152.GA37998@freebsd.org> Message-ID: <200910071046.01595.hselasky@freebsd.org> On Tuesday 06 October 2009 22:41:52 Roman Divacky wrote: > On Tue, Oct 06, 2009 at 09:29:50PM +0100, Robert N. M. Watson wrote: > > On 6 Oct 2009, at 19:50, Chuck Swiger wrote: > > >Hi, Hans-- > > > > > >On Oct 2, 2009, at 5:40 AM, Hans Petter Selasky wrote: > > >>Can the Apple's "Blocks" C language extension be used when > > >>programming in the kernel? Or is this a user-space only feature? > > > > > >While the main benefit of blocks is in conjunction with libdispatch > > >for userland apps, they can be used by themselves, in the kernel or > > >elsewhere. > > > > When a block is instantiated (perhaps not the formal terminology), the > > blocks runtime allocates memory to hold copies of relevant variables > > from the calling scope. This memory allocation may present an issue in > > some calling contexts in the kernel Hi Robert, I would argue that it is highly desirable to be able to pre-allocate memory for the given "callbacks" [here: Apple's "Blocks"]. Apple's "Blocks" reminds me of the USB stack's "msignal" system. "msignal" associates a piece of code with some data structure, and executes it for callback. Memory allocation is always a challenge. To allocate memory on the fly can also be a performance issue, and not at least make problems for realtime systems. I would suggest that the language is extended so that the elements that gets allocated are in the form of a structure. Example pseudo code: struct async_callback_001 { struct libdispatch_data xxx; int x; int y; }; void my_func(int x, int y) { static struct queue pq; static struct async_callback_001 data; init_queue(&pq); queue(&pq, &data, ^{ block of code which can only access parent fields that are given through the "data" structure. }); } Also there should be the possibility to lock the queue and test if an instance of a Apple Block has been queued for execution, because it is not just about paralell execution, but also about being able to drain/stop a system without polling. I admit I haven't looked too closely at the Apple Block's system yet, so maybe some of the features I'm asking for are already present. > > -- in particular, it won't be > > appropriate in contexts were non-sleepable locks are held, interrupt > > threads, etc. While it should be possible to use the primitive in the > > kernel, we may want to think carefully about these implications. Maybe that suggests that malloc() is the wrong way forward for keeping the temporary variable storage. Like I state in my example above, maybe the temporary variable storage should be separated out, so that for instance in a critical context, pre-allocated or static memory can be used instead?! > > Also, > > blocks are currently specific to clang, although with any luck gcc > > will grow them also. --HPS From kostikbel at gmail.com Thu Oct 8 14:59:04 2009 From: kostikbel at gmail.com (Kostik Belousov) Date: Thu Oct 8 14:59:16 2009 Subject: PIE support Message-ID: <20091008145900.GK2259@deviant.kiev.zoral.com.ua> There is a patch, that should provide more or less proper support for PIE (Position Independent Executables). Besides being desirable feature itself, this is needed to be able to execute PIE binaries, both native FreeBSD and Linux images, with sysctl security.bsd.map_at_zero=0. In particular, Samba port is affected. gdb does not work for PIE binaries, I believe this is a gdb shortcoming. Patch was reviewed by Alexander Kabaev, discussed with Bjoern A. Zeeb, who tested i386 and amd64, and tested by Boris Samorodov for Linux binaries. I am asking for general testing for the patch. Also, I would ask the architecture maintainers to look for the per-arch mapbase address selected for the PIE binaries. http://people.freebsd.org/~kib/misc/pie.5.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20091008/78ba254b/attachment.pgp From sgk at troutmask.apl.washington.edu Thu Oct 8 17:02:30 2009 From: sgk at troutmask.apl.washington.edu (Steve Kargl) Date: Thu Oct 8 17:02:36 2009 Subject: PIE support In-Reply-To: <20091008145900.GK2259@deviant.kiev.zoral.com.ua> References: <20091008145900.GK2259@deviant.kiev.zoral.com.ua> Message-ID: <20091008170229.GA75042@troutmask.apl.washington.edu> On Thu, Oct 08, 2009 at 05:59:00PM +0300, Kostik Belousov wrote: > > gdb does not work for PIE binaries, I believe this is a gdb shortcoming. > gdb 7.0 was released on Oct 6th. It appears to work fine with PIE. (Yes, I know that gdb 7.0 is unlikely to appear in FreeBSD.) -- Steve From brde at optusnet.com.au Thu Oct 8 20:01:04 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Thu Oct 8 20:01:11 2009 Subject: Interrupt Descriptions In-Reply-To: <200910020930.01228.jhb@freebsd.org> References: <200909301732.20589.jhb@freebsd.org> <200910011412.31250.jhb@freebsd.org> <20091002053705.F21979@delplex.bde.org> <200910020930.01228.jhb@freebsd.org> Message-ID: <20091009050808.U1531@delplex.bde.org> On Fri, 2 Oct 2009, John Baldwin wrote: > On Thursday 01 October 2009 4:41:19 pm Bruce Evans wrote: > ... > However, all of this is still orthogonal to interrupt description strings. > >> Here is the 4.4BSD-Lite2 code for hp300: >> >> % .globl _intrcnt,_eintrcnt,_intrnames,_eintrnames >> % _intrnames: >> % .asciz "spur" >> % .asciz "hil" >> % .asciz "lev2" >> % .asciz "lev3" >> % .asciz "lev4" >> % .asciz "lev5" >> % .asciz "dma" >> % .asciz "clock" >> % .asciz "statclock" >> % .asciz "nmi" >> % _eintrnames: >> % .even >> % _intrcnt: >> % .long 0,0,0,0,0,0,0,0,0,0 >> % _eintrcnt: >> >> This takes 53 bytes (plus 1 or 3 for padding) for the string space. >> Most machines still need about 53 bytes for the string space (don't >> waste slots to count or name stray interrupts separately). These 53 >> bytes can be built and processed by userland on every sysctl much >> faster than the 32K of mostly-unused bytes can even be copied out. > > I think this mostly serves to prove the point that the existing design is > tailored to static configurations, not dynamic ones. No, string spaces are ideal for dynamic management of small collections of strings and for larger collections of strings that are accessed mostly sequentially. They are essentially the same as a text file. There is no better data structure for a text file than to concatenate all the lines together. Sometimes you want non-sequential access for text files, e.g., for tail -n and in editors, but this is rare and then you can build random-access substructures as needed. Collections of interrupt names are both small and accessed mostly sequentially. Bruce From bugmaster at FreeBSD.org Mon Oct 12 11:06:50 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 12 11:07:26 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200910121106.n9CB6lJk036306@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From imp at bsdimp.com Tue Oct 13 21:25:11 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Tue Oct 13 21:25:18 2009 Subject: svn commit: r198009 - projects/mips/sbin In-Reply-To: <200910130043.n9D0hVCr089970@svn.freebsd.org> References: <200910130043.n9D0hVCr089970@svn.freebsd.org> Message-ID: <20091013.113451.2056345767.imp@bsdimp.com> In message: <200910130043.n9D0hVCr089970@svn.freebsd.org> Oleksandr Tymoshenko writes: : Log: : - Enable fdisk build for MIPS ... : +.if ${MACHINE_ARCH} == "mips" : +_fdisk= fdisk : +.endif : + I'm starting to think that the right answer here is to enable fdisk for all platforms. Warner From jhb at freebsd.org Tue Oct 13 21:49:01 2009 From: jhb at freebsd.org (John Baldwin) Date: Tue Oct 13 21:49:12 2009 Subject: Interrupt Descriptions In-Reply-To: <200909301732.20589.jhb@freebsd.org> References: <200909301732.20589.jhb@freebsd.org> Message-ID: <200910131748.57945.jhb@freebsd.org> On Wednesday 30 September 2009 5:32:20 pm John Baldwin wrote: > A few folks have asked recently for the ability to add descriptive strings to > registered interrupt handlers. This is especially true since the advent of > MSI with multiple interrupts per device. I hacked up a prototype today that > adds a new 'bus_describe_intr()' that takes the IRQ resource, the void * > cookie returned by bus_setup_intr() and var args description and appends that > to the interrupt name in the thread and vmstat -i info. The current patch > only has the MI bits and the MD bits for amd64 as well as a sample change to > the igb(4) driver. > > The patch is at http://www.FreeBSD.org/~jhb/patches/intr_describe.patch. > > An example from this patch is: > > > vmstat -i > interrupt total rate > irq1: atkbd0 8 0 > irq4: uart0 751 5 > irq6: fdc0 6 0 > irq14: ata0 36 0 > irq20: uhci0 20 0 > irq23: uhci3 ehci0 2 0 > irq28: mpt0 1661 11 > irq256: igb0:tx 0 880 6 > irq257: igb0:rx 0 1098 7 > irq258: igb0:link 3 0 > irq259: igb1:tx 0 1 0 > irq260: igb1:rx 0 134 0 > irq261: igb1:link 3 0 Do folks feel that the issues with the intrnames and intrcnt API warrant delaying this work, or do folks have any objections to the proposed bus_describe_intr() API? Personally I think that intrnames and intrcnt are certainly broken, but that they have been broken for quite a while and that these changes do not make them more broken than they currently are. Also, I think that any fixes to intrcnt/intrnames would be orthogonal to bus_describe_intr(). -- John Baldwin From julian at elischer.org Tue Oct 13 22:10:55 2009 From: julian at elischer.org (Julian Elischer) Date: Tue Oct 13 22:11:03 2009 Subject: Interrupt Descriptions In-Reply-To: <200910131748.57945.jhb@freebsd.org> References: <200909301732.20589.jhb@freebsd.org> <200910131748.57945.jhb@freebsd.org> Message-ID: <4AD4FAF1.1060609@elischer.org> John Baldwin wrote: > On Wednesday 30 September 2009 5:32:20 pm John Baldwin wrote: >> A few folks have asked recently for the ability to add descriptive strings > to >> registered interrupt handlers. This is especially true since the advent of >> MSI with multiple interrupts per device. I hacked up a prototype today that >> adds a new 'bus_describe_intr()' that takes the IRQ resource, the void * >> cookie returned by bus_setup_intr() and var args description and appends > that >> to the interrupt name in the thread and vmstat -i info. The current patch >> only has the MI bits and the MD bits for amd64 as well as a sample change to >> the igb(4) driver. >> >> The patch is at http://www.FreeBSD.org/~jhb/patches/intr_describe.patch. >> >> An example from this patch is: >> >>> vmstat -i >> interrupt total rate >> irq1: atkbd0 8 0 >> irq4: uart0 751 5 >> irq6: fdc0 6 0 >> irq14: ata0 36 0 >> irq20: uhci0 20 0 >> irq23: uhci3 ehci0 2 0 >> irq28: mpt0 1661 11 >> irq256: igb0:tx 0 880 6 >> irq257: igb0:rx 0 1098 7 >> irq258: igb0:link 3 0 >> irq259: igb1:tx 0 1 0 >> irq260: igb1:rx 0 134 0 >> irq261: igb1:link 3 0 > > Do folks feel that the issues with the intrnames and intrcnt API warrant > delaying this work, or do folks have any objections to the proposed > bus_describe_intr() API? Personally I think that intrnames and intrcnt are > certainly broken, but that they have been broken for quite a while and that > these changes do not make them more broken than they currently are. Also, I > think that any fixes to intrcnt/intrnames would be orthogonal to > bus_describe_intr(). > I see that in linux this information is available in /proc/(mumble) and people use it. I see no real reason that we should stop this work. From jfvogel at gmail.com Tue Oct 13 22:40:19 2009 From: jfvogel at gmail.com (Jack Vogel) Date: Tue Oct 13 22:40:26 2009 Subject: Interrupt Descriptions In-Reply-To: <200910131748.57945.jhb@freebsd.org> References: <200909301732.20589.jhb@freebsd.org> <200910131748.57945.jhb@freebsd.org> Message-ID: <2a41acea0910131507l3a50b68u698d876e96880266@mail.gmail.com> On Tue, Oct 13, 2009 at 2:48 PM, John Baldwin wrote: > On Wednesday 30 September 2009 5:32:20 pm John Baldwin wrote: > > A few folks have asked recently for the ability to add descriptive > strings > to > > registered interrupt handlers. This is especially true since the advent > of > > MSI with multiple interrupts per device. I hacked up a prototype today > that > > adds a new 'bus_describe_intr()' that takes the IRQ resource, the void * > > cookie returned by bus_setup_intr() and var args description and appends > that > > to the interrupt name in the thread and vmstat -i info. The current > patch > > only has the MI bits and the MD bits for amd64 as well as a sample change > to > > the igb(4) driver. > > > > The patch is at http://www.FreeBSD.org/~jhb/patches/intr_describe.patch > . > > > > An example from this patch is: > > > > > vmstat -i > > interrupt total rate > > irq1: atkbd0 8 0 > > irq4: uart0 751 5 > > irq6: fdc0 6 0 > > irq14: ata0 36 0 > > irq20: uhci0 20 0 > > irq23: uhci3 ehci0 2 0 > > irq28: mpt0 1661 11 > > irq256: igb0:tx 0 880 6 > > irq257: igb0:rx 0 1098 7 > > irq258: igb0:link 3 0 > > irq259: igb1:tx 0 1 0 > > irq260: igb1:rx 0 134 0 > > irq261: igb1:link 3 0 > > Do folks feel that the issues with the intrnames and intrcnt API warrant > delaying this work, or do folks have any objections to the proposed > bus_describe_intr() API? Personally I think that intrnames and intrcnt are > certainly broken, but that they have been broken for quite a while and that > these changes do not make them more broken than they currently are. Also, > I > think that any fixes to intrcnt/intrnames would be orthogonal to > bus_describe_intr(). > > I'm in favor of going with what you've done, and let fixes or changes happen later, having this functionality now would be really nice. Jack From brde at optusnet.com.au Wed Oct 14 00:32:34 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Wed Oct 14 00:32:41 2009 Subject: svn commit: r198009 - projects/mips/sbin In-Reply-To: <20091013.113451.2056345767.imp@bsdimp.com> References: <200910130043.n9D0hVCr089970@svn.freebsd.org> <20091013.113451.2056345767.imp@bsdimp.com> Message-ID: <20091014103634.A6350@delplex.bde.org> On Tue, 13 Oct 2009, M. Warner Losh wrote: > In message: <200910130043.n9D0hVCr089970@svn.freebsd.org> > Oleksandr Tymoshenko writes: > : Log: > : - Enable fdisk build for MIPS > > I'm starting to think that the right answer here is to enable fdisk > for all platforms. Of course. fdisk is MI except for bugs in it. It should be usable on any system to manage disks or disk images created on any system that needs it natively. fdisk certainly has bugs like assuming that the host system byte order is the same as the target system byte order. It fails on big-endian systems because the target system byte order is always little-endian. Its device independence was broken using g_device_path() just over 1 year ago, so it no longer works on disk images (except possibly if. Older geom breakage is still handled benignly by not aborting when fdisk is run on a system or file that doesn't support geom ioctls (it even has a comment about this, but g_device_path() fails long before the working code is reached). Bruce From mav at FreeBSD.org Wed Oct 14 07:41:08 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Oct 14 07:41:14 2009 Subject: Interrupt Descriptions In-Reply-To: <1255483383.00172964.1255470604@10.7.7.3> References: <200909301732.20589.jhb@freebsd.org> <1255483383.00172964.1255470604@10.7.7.3> Message-ID: <4AD57B2C.8070606@FreeBSD.org> John Baldwin wrote: > On Wednesday 30 September 2009 5:32:20 pm John Baldwin wrote: >> A few folks have asked recently for the ability to add descriptive strings > to >> registered interrupt handlers. This is especially true since the advent of >> MSI with multiple interrupts per device. I hacked up a prototype today that >> adds a new 'bus_describe_intr()' that takes the IRQ resource, the void * >> cookie returned by bus_setup_intr() and var args description and appends > that >> to the interrupt name in the thread and vmstat -i info. The current patch >> only has the MI bits and the MD bits for amd64 as well as a sample change to >> the igb(4) driver. >> >> The patch is at http://www.FreeBSD.org/~jhb/patches/intr_describe.patch. >> >> An example from this patch is: >> >>> vmstat -i >> interrupt total rate >> irq1: atkbd0 8 0 >> irq4: uart0 751 5 >> irq6: fdc0 6 0 >> irq14: ata0 36 0 >> irq20: uhci0 20 0 >> irq23: uhci3 ehci0 2 0 >> irq28: mpt0 1661 11 >> irq256: igb0:tx 0 880 6 >> irq257: igb0:rx 0 1098 7 >> irq258: igb0:link 3 0 >> irq259: igb1:tx 0 1 0 >> irq260: igb1:rx 0 134 0 >> irq261: igb1:link 3 0 > > Do folks feel that the issues with the intrnames and intrcnt API warrant > delaying this work, or do folks have any objections to the proposed > bus_describe_intr() API? Personally I think that intrnames and intrcnt are > certainly broken, but that they have been broken for quite a while and that > these changes do not make them more broken than they currently are. Also, I > think that any fixes to intrcnt/intrnames would be orthogonal to > bus_describe_intr(). Just some 50 cents on topic: it would be nice if `vmstat -i` was able to show all (more then 2) consumers of shared interrupt instead of "cbb0 wpi0+". I haven't looked who actually limit this and why, so it's just a wish. -- Alexander Motin From olli at lurza.secnetix.de Wed Oct 14 08:12:16 2009 From: olli at lurza.secnetix.de (Oliver Fromme) Date: Wed Oct 14 08:12:23 2009 Subject: Interrupt Descriptions In-Reply-To: <4AD57B2C.8070606@FreeBSD.org> Message-ID: <200910140811.n9E8BvKk063958@lurza.secnetix.de> Alexander Motin wrote: > John Baldwin wrote: > > Do folks feel that the issues with the intrnames and intrcnt API warrant > > delaying this work, or do folks have any objections to the proposed > > bus_describe_intr() API? Personally I think that intrnames and intrcnt are > > certainly broken, but that they have been broken for quite a while and that > > these changes do not make them more broken than they currently are. Also, I > > think that any fixes to intrcnt/intrnames would be orthogonal to > > bus_describe_intr(). > > Just some 50 cents on topic: it would be nice if `vmstat -i` was able to > show all (more then 2) consumers of shared interrupt instead of "cbb0 > wpi0+". I haven't looked who actually limit this and why, so it's just a > wish. Here's a whole-hearted "me too". I also often have output like this from vmstat: irq18: ohci2 ohci+ It doesn't even display the number of the second ohci device on irq18. So I always have to grep through /var/run/dmegs.boot to find out the real list of devices, which is annoying, and this is not the way it should be. "sysctl dev" doesn't provide that information either. In this example, there are actually four devices on irq18: ohci2, ohci3, ohci4, vgapci0. About half of the machines I have access to exhibit that problem. Disclaimer: I'm not familiar with FreeBSD's interrupt code, so my opinion should be regarded as a "user's wish for enhancement", not as a developer's vote. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Gesch?ftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht M?n- chen, HRB 125758, Gesch?ftsf?hrer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The scanf() function is a large and complex beast that often does something almost but not quite entirely unlike what you desired." -- Chris Torek From Alexander at Leidinger.net Wed Oct 14 08:52:27 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed Oct 14 08:52:34 2009 Subject: improvement wishes (was: Re: Interrupt Descriptions) In-Reply-To: <200910140811.n9E8BvKk063958@lurza.secnetix.de> References: <200910140811.n9E8BvKk063958@lurza.secnetix.de> Message-ID: <20091014103640.1364764w7rhf3e8s@webmail.leidinger.net> Quoting Oliver Fromme (from Wed, 14 Oct 2009 10:11:57 +0200 (CEST)): > Alexander Motin wrote: > > Just some 50 cents on topic: it would be nice if `vmstat -i` was able to > > show all (more then 2) consumers of shared interrupt instead of "cbb0 > > wpi0+". I haven't looked who actually limit this and why, so it's just a > > wish. > > Here's a whole-hearted "me too". > I also often have output like this from vmstat: > > irq18: ohci2 ohci+ > > It doesn't even display the number of the second ohci > device on irq18. So I always have to grep through > /var/run/dmegs.boot to find out the real list of > devices, which is annoying, and this is not the way > it should be. "sysctl dev" doesn't provide that > information either. > > In this example, there are actually four devices on > irq18: ohci2, ohci3, ohci4, vgapci0. To all those people with wishes which improve parts of FreeBSD. We have something where you can express your wishes much much better (an on topic) than here in this thread (where jhb is talking about something orthogonal). This other place I talk about is http://www.FreeBSD.org/projects/ideas/ or http://wiki.FreeBSD.org/. Both places are open for modification to everyone. Expressing your wishes there allows a fairy or genie to have a look at them. Bye, Alexander. -- Old age is too high a price to pay for maturity. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From mav at FreeBSD.org Wed Oct 14 08:54:50 2009 From: mav at FreeBSD.org (Alexander Motin) Date: Wed Oct 14 08:54:56 2009 Subject: improvement wishes In-Reply-To: <20091014103640.1364764w7rhf3e8s@webmail.leidinger.net> References: <200910140811.n9E8BvKk063958@lurza.secnetix.de> <20091014103640.1364764w7rhf3e8s@webmail.leidinger.net> Message-ID: <4AD591D4.1090806@FreeBSD.org> Alexander Leidinger wrote: > To all those people with wishes which improve parts of FreeBSD. We have > something where you can express your wishes much much better (an on > topic) than here in this thread (where jhb is talking about something > orthogonal). This other place I talk about is > http://www.FreeBSD.org/projects/ideas/ or http://wiki.FreeBSD.org/. Both > places are open for modification to everyone. Expressing your wishes > there allows a fairy or genie to have a look at them. The most efficient place to hunt right genie is near lamp where he lives. ;) Ideas page is cool for large projects, but This I hope should be easier to fix then publish somewhere for next few years. This topic is not completely orthogonal, as adding more information to the interrupt consumer name may result (hypothetically) that we won't see even second consumer of shared IRQ, instead of third. -- Alexander Motin From Alexander at Leidinger.net Wed Oct 14 11:31:44 2009 From: Alexander at Leidinger.net (Alexander Leidinger) Date: Wed Oct 14 11:31:51 2009 Subject: improvement wishes In-Reply-To: <4AD591D4.1090806@FreeBSD.org> References: <200910140811.n9E8BvKk063958@lurza.secnetix.de> <20091014103640.1364764w7rhf3e8s@webmail.leidinger.net> <4AD591D4.1090806@FreeBSD.org> Message-ID: <20091014133132.63685a7ifac7jecc@webmail.leidinger.net> Quoting Alexander Motin (from Wed, 14 Oct 2009 11:54:44 +0300): > Alexander Leidinger wrote: >> To all those people with wishes which improve parts of FreeBSD. We have >> something where you can express your wishes much much better (an on >> topic) than here in this thread (where jhb is talking about something >> orthogonal). This other place I talk about is >> http://www.FreeBSD.org/projects/ideas/ or http://wiki.FreeBSD.org/. Both >> places are open for modification to everyone. Expressing your wishes >> there allows a fairy or genie to have a look at them. > > The most efficient place to hunt right genie is near lamp where he > lives. ;) Ideas page is cool for large projects, but This I hope should > be easier to fix then publish somewhere for next few years. Even small projects should be put online, that's better than to forget about it at all. The idea page is not only for the GSoC, but also for things which could serve as an entry point to FreeBSD-src-knowledge. > This topic is not completely orthogonal, as adding more information to > the interrupt consumer name may result (hypothetically) that we won't > see even second consumer of shared IRQ, instead of third. Let's say it differently: jhb wants to handle it orthogonal. :) Bye, Alexander. -- Professor: Oh, dear. She's stuck in an infinite loop and he's an idiot. Well, that's love for you. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From jhb at freebsd.org Wed Oct 14 15:00:46 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Oct 14 15:01:07 2009 Subject: Interrupt Descriptions In-Reply-To: <4AD57B2C.8070606@FreeBSD.org> References: <200909301732.20589.jhb@freebsd.org> <1255483383.00172964.1255470604@10.7.7.3> <4AD57B2C.8070606@FreeBSD.org> Message-ID: <200910140757.58887.jhb@freebsd.org> On Wednesday 14 October 2009 3:18:04 am Alexander Motin wrote: > John Baldwin wrote: > > On Wednesday 30 September 2009 5:32:20 pm John Baldwin wrote: > >> A few folks have asked recently for the ability to add descriptive strings > > to > >> registered interrupt handlers. This is especially true since the advent of > >> MSI with multiple interrupts per device. I hacked up a prototype today that > >> adds a new 'bus_describe_intr()' that takes the IRQ resource, the void * > >> cookie returned by bus_setup_intr() and var args description and appends > > that > >> to the interrupt name in the thread and vmstat -i info. The current patch > >> only has the MI bits and the MD bits for amd64 as well as a sample change to > >> the igb(4) driver. > >> > >> The patch is at http://www.FreeBSD.org/~jhb/patches/intr_describe.patch. > >> > >> An example from this patch is: > >> > >>> vmstat -i > >> interrupt total rate > >> irq1: atkbd0 8 0 > >> irq4: uart0 751 5 > >> irq6: fdc0 6 0 > >> irq14: ata0 36 0 > >> irq20: uhci0 20 0 > >> irq23: uhci3 ehci0 2 0 > >> irq28: mpt0 1661 11 > >> irq256: igb0:tx 0 880 6 > >> irq257: igb0:rx 0 1098 7 > >> irq258: igb0:link 3 0 > >> irq259: igb1:tx 0 1 0 > >> irq260: igb1:rx 0 134 0 > >> irq261: igb1:link 3 0 > > > > Do folks feel that the issues with the intrnames and intrcnt API warrant > > delaying this work, or do folks have any objections to the proposed > > bus_describe_intr() API? Personally I think that intrnames and intrcnt are > > certainly broken, but that they have been broken for quite a while and that > > these changes do not make them more broken than they currently are. Also, I > > think that any fixes to intrcnt/intrnames would be orthogonal to > > bus_describe_intr(). > > Just some 50 cents on topic: it would be nice if `vmstat -i` was able to > show all (more then 2) consumers of shared interrupt instead of "cbb0 > wpi0+". I haven't looked who actually limit this and why, so it's just a > wish. At the moment the limit comes from stuffing the name into a p_comm[] (or in 8+ td_name[]) array which is limited to MAXCOMLEN in length. We also reuse that same name for the interrupt name in vmstat -i. Note that in 4.x before ithreads if you had a shared interrupt the vmstat -i output just said "mux" (check vmstat -i on ref4 for irq2) and did not tell you any of the devices at all, so a partial list is at least better than no list. We could generate a separate interrupt name for vmstat -i vs the ithread name, it's just a matter of space. We might do this if we move away from having static ithreads (i.e. having a pool of ithreads that are a specialized taskqueue that execute interrupt events). In that case the name would no longer be used for threads at all, so it could just be made longer, or possibly dynamically allocated. -- John Baldwin From jhb at freebsd.org Wed Oct 14 15:00:47 2009 From: jhb at freebsd.org (John Baldwin) Date: Wed Oct 14 15:01:07 2009 Subject: improvement wishes In-Reply-To: <4AD591D4.1090806@FreeBSD.org> References: <200910140811.n9E8BvKk063958@lurza.secnetix.de> <20091014103640.1364764w7rhf3e8s@webmail.leidinger.net> <4AD591D4.1090806@FreeBSD.org> Message-ID: <200910140808.58205.jhb@freebsd.org> On Wednesday 14 October 2009 4:54:44 am Alexander Motin wrote: > Alexander Leidinger wrote: > > To all those people with wishes which improve parts of FreeBSD. We have > > something where you can express your wishes much much better (an on > > topic) than here in this thread (where jhb is talking about something > > orthogonal). This other place I talk about is > > http://www.FreeBSD.org/projects/ideas/ or http://wiki.FreeBSD.org/. Both > > places are open for modification to everyone. Expressing your wishes > > there allows a fairy or genie to have a look at them. > > The most efficient place to hunt right genie is near lamp where he > lives. ;) Ideas page is cool for large projects, but This I hope should > be easier to fix then publish somewhere for next few years. > > This topic is not completely orthogonal, as adding more information to > the interrupt consumer name may result (hypothetically) that we won't > see even second consumer of shared IRQ, instead of third. The reason why I am not worried about descriptions making the current situation worse is that descriptions are intended to be used for devices that have multiple interrupts. For devices with a single interrupt, the device name alone is a sufficiently unique label for the interrupt handler, but for devices with multiple interrupts having 3 "igb0" interrupts (for example) can be very ambiguous. Like so: irq256: igb0 641924 0 irq257: igb0 21245021 12 irq258: igb0 3 0 irq259: igb1 1160790 0 irq260: igb1 7595639 4 irq261: igb1 2 0 It would be handy to not have to refer to the source code of the driver to see what order it assigns interrupt handlers to figure out what is different about IRQs 256 vs 257 vs 258 for igb0. The only way devices can currently have multiple devices per interrupt is by using PCI MSI/MSI-X interrupts, and the current implementations of MSI ensure that MSI interrupts are never shared, so in practice you will not run into problems with descriptions causing loss of detail in existing interrupt stats. -- John Baldwin From asientrade at freenet.de Thu Oct 15 12:01:18 2009 From: asientrade at freenet.de (daniel) Date: Thu Oct 15 12:01:26 2009 Subject: Twitter-endlich Geldverdienen-kostenlos und sofort startklar Message-ID: <2009101514012729CF1EF7EF$AD4939E28F@DANIELPC> ?Offers stand below as an English available Hallo- ??????????????????????????????????????? verdiene endlich Geld durch Twitterwenn ein Twitter Account vorhanden sein sollte dann gehts sofort los mit Verdienen.sollte keine Account vorhanden sein dann einfach alles kostenlos erstellen und verdienen.?mit besten Empfehlungen eure Danielleichter kann man sein ?Geld nicht verdienen- alles kostenlos wenn sie einen Twitteraccount haben.Also schnell handel-bei weiterem Interesse und lust an gratis produkten einfach kurz anmelden-oder abmelden-- danke??Anmelden?????? ?Abmelden?24 Std. Blitzangebot?nur begrenzt f?r?24 Stunden aktiv danach ausverkauft--- http://www.affiliateverkaufen.de/blitzangebot.html???? 10,-?(The Logo Creator hilft beim Erstellen qualitativ hochwertiger Logos. Ganz nach dem Motto "Your Logo is your business" gestaltet der Nutzer mit diesem Programm Blickf?nger f?r Webseiten)?(?bersetzen Sie ganz einfach und mit wenigen Klicks Texte oder sogar komplette Webseiten in 31 Sprachen. )nur 28,-??oder Aktionspreis 30,-??? f?r Logocreator v5 und PDF-Converter 6.0 dt.?Oder m?chten sie lieber effektiv heute noch Geld verdienen und Zahlungen wenn m?glich sofort erwirtschaften-?? dann mit diesem angebot was f?r mich selbstbehauptet das beste ?berhaupt war und ist--Geld durch Emails verdienen-aber keine centbetr?ge sondern sofort 10-20,-? sofort-zahlung innerhalb weniger minuten, ich habe zur zeit zwischen 5 und 20 Kunden pro tag (weltweit) bei einem verdienst pro email von ca. 15,-? und ich betreibe keinerlei werbung oder verkaufe durchs telefon nein die Kunden kommen zu mir und ich verdiene sehr gut-aber lesen sie selbst wenn ihr interesse noch vorhanden ist weiter im Angebot 2.erfolgreiches Handeln w?nsche ich auf diesem Wege-bei weiteren Interessen k?nnen sie sichwiederholt eintragen um weitere Angebote und Gratis Geschenke zu erhalten........................(oder Abmelden).... Anmelden???? Abmelden ?Hello- finally earn money by Twitterthen immediately feels wrong with earning if a Twitter account should be available. no-one should account be available simply then everything free of charge make and earn. with best recommendations yours Danielone can more easily money not earning everything be ' free if they have a Twitteraccount. -therefore act fast simply registering or cancelling at broader interest and desire at free products briefly, thank youBookingCancelling24 hour lightning supply?sold off according to that actively for 24 hours only restrictedly - http://www.affiliateverkaufen.de/blitzangebot.html 10. ? (A The logo Creator helps to make high-quality logos. According to the motto "Your logo is your business" the user completely forms with this programme eye-catcher for web pages.) ? (Translate texts or even complete web pages for only simply and a few clicks into 31 languages.) only 28. ? or special-offer price 30. ? for Logocreator v5 and PDF-Converter of 6.0 dt. -or they would rather, today, still earn money effectively and immediately gain payments if possible? with this supply did but no cent amounts what was self claimed for me the best at all and is? I have 10-20,- ? immediately payment within less minutes, between 5 and 20 customers per day (worldwide) at an income per e-mail from approx. 15. ? at the moment by the telephone the customers no come to me and I earn very well and I operate no advertising or sell but read them even if their interest is still further existing in the supply 2. Angebot 2.I wish on this at broader interests be able to do them himself a successful action waystyping repeated ........................ in to receive further offers and free presents. (or cancel ) ..... Booking? Cancelling???? From asientrade at freenet.de Thu Oct 15 13:40:16 2009 From: asientrade at freenet.de (daniel) Date: Thu Oct 15 13:40:24 2009 Subject: Twitter-endlich Geldverdienen-kostenlos und sofort startklar Message-ID: <2009101515403195FE7B7318$6480CC20E4@DANIELPC> ?Offers stand below as an English available Hallo- ??????????????????????????????????????? verdiene endlich Geld durch Twitterwenn ein Twitter Account vorhanden sein sollte dann gehts sofort los mit Verdienen.sollte keine Account vorhanden sein dann einfach alles kostenlos erstellen und verdienen.?mit besten Empfehlungen eure Danielleichter kann man sein ?Geld nicht verdienen- alles kostenlos wenn sie einen Twitteraccount haben.Also schnell handel-bei weiterem Interesse und lust an gratis produkten einfach kurz anmelden-oder abmelden-- danke??Anmelden?????? ?Abmelden?24 Std. Blitzangebot?nur begrenzt f?r?24 Stunden aktiv danach ausverkauft--- http://www.affiliateverkaufen.de/blitzangebot.html???? 10,-?(The Logo Creator hilft beim Erstellen qualitativ hochwertiger Logos. Ganz nach dem Motto "Your Logo is your business" gestaltet der Nutzer mit diesem Programm Blickf?nger f?r Webseiten)?(?bersetzen Sie ganz einfach und mit wenigen Klicks Texte oder sogar komplette Webseiten in 31 Sprachen. )nur 28,-??oder Aktionspreis 30,-??? f?r Logocreator v5 und PDF-Converter 6.0 dt.?Oder m?chten sie lieber effektiv heute noch Geld verdienen und Zahlungen wenn m?glich sofort erwirtschaften-?? dann mit diesem angebot was f?r mich selbstbehauptet das beste ?berhaupt war und ist--Geld durch Emails verdienen-aber keine centbetr?ge sondern sofort 10-20,-? sofort-zahlung innerhalb weniger minuten, ich habe zur zeit zwischen 5 und 20 Kunden pro tag (weltweit) bei einem verdienst pro email von ca. 15,-? und ich betreibe keinerlei werbung oder verkaufe durchs telefon nein die Kunden kommen zu mir und ich verdiene sehr gut-aber lesen sie selbst wenn ihr interesse noch vorhanden ist weiter im Angebot 2.erfolgreiches Handeln w?nsche ich auf diesem Wege-bei weiteren Interessen k?nnen sie sichwiederholt eintragen um weitere Angebote und Gratis Geschenke zu erhalten........................(oder Abmelden).... Anmelden???? Abmelden ?Hello- finally earn money by Twitterthen immediately feels wrong with earning if a Twitter account should be available. no-one should account be available simply then everything free of charge make and earn. with best recommendations yours Danielone can more easily money not earning everything be ' free if they have a Twitteraccount. -therefore act fast simply registering or cancelling at broader interest and desire at free products briefly, thank youBookingCancelling24 hour lightning supply?sold off according to that actively for 24 hours only restrictedly - http://www.affiliateverkaufen.de/blitzangebot.html 10. ? (A The logo Creator helps to make high-quality logos. According to the motto "Your logo is your business" the user completely forms with this programme eye-catcher for web pages.) ? (Translate texts or even complete web pages for only simply and a few clicks into 31 languages.) only 28. ? or special-offer price 30. ? for Logocreator v5 and PDF-Converter of 6.0 dt. -or they would rather, today, still earn money effectively and immediately gain payments if possible? with this supply did but no cent amounts what was self claimed for me the best at all and is? I have 10-20,- ? immediately payment within less minutes, between 5 and 20 customers per day (worldwide) at an income per e-mail from approx. 15. ? at the moment by the telephone the customers no come to me and I earn very well and I operate no advertising or sell but read them even if their interest is still further existing in the supply 2. Angebot 2.I wish on this at broader interests be able to do them himself a successful action waystyping repeated ........................ in to receive further offers and free presents. (or cancel ) ..... Booking? Cancelling???? From imp at bsdimp.com Thu Oct 15 19:52:41 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Thu Oct 15 19:52:48 2009 Subject: x86BIOS and the ISA bus and low memory in general... In-Reply-To: <200910151431.53236.jkim@FreeBSD.org> References: <20091015.085910.-520412456.imp@bsdimp.com> <200910151118.50619.jhb@freebsd.org> <200910151431.53236.jkim@FreeBSD.org> Message-ID: <20091015.134532.-1110324186.imp@bsdimp.com> [[ redirected to arch@ ]] In message: <200910151431.53236.jkim@FreeBSD.org> Jung-uk Kim writes: : This is actually very interesting discussion for me because one of my : pet projects is extending x86bios to support non-PC architectures. : If anyone is interested, the current source tarball is here: : : http://people.freebsd.org/~jkim/x86bios-20091015.tar.bz2 : : Especially, please see the code around #ifdef X86BIOS_COMPAT_ARCH. : Basically, mapping I/O ports and orm(4) is missing. We don't have to : implement I/O ports but orm(4) vs. bus_space(9) is critical to make : it a reality. Please consider it as a real practical example for : orm, not just a blackhole driver. :-) I thought that most video cards had I/O ports as well as video RAM that needed to be mapped... Am I crazy? I'm looking at the code and have a few questions. It looks like you are allocating memory from 0x1000 to 0xa0000 with a contig malloc, and then redirecting the emulator's read/write into that array. But I don't see where the memory reads for the so-called ISA ROM hole are going. I was looking for that hoping I could find them so I could comment on them... orm uses bus_space today to do its read/write of the memory. I'd imagine that if you wanted to touch actual hardware, then you'd need to have drivers and/or the emulator use the same path to accomplish this. While in theory one could have multiple ISA busses in a system, as a practical matter nobody does this. Even when you have weird expansion busses on laptop docking stations, you'd have them all mapped into one space. This means we can likely make some simplifying assumptions that there is a single ISA bus on the system. I don't know if we have to make that assumption, but it is something to keep in the back of our heads. This suggests that the emulation device would have to attach somehow to the ISA bus to make sure that the right translations (wherever they happen) can happen. But there's a catch... The readw/readb macros in the atkbd.c driver likely need to change to bus space macros of some kind to make this work. I'm unsure how, exactly, to make that happen since these addresses aren't for anything on the actual ISA bus, but rather are for data that's contained in the contigmalloc'd area. They aren't really ISA bus addresses, yet they are expected to be there by the drivers. bus_space suggests itself for this as well, but it isn't at all clear how that might be accomplished because ES could point anywhere in the first MB of RAM (since 16-bit operations are limited to 1MB with segments, right?) This is a very interesting project... Is the goal to emulate the BIOS or execute the BIOS that might be loaded on the expansion cards in these weird environments. I'm guessing the former, but you never know.. Warner From xcllnt at mac.com Thu Oct 15 20:37:17 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Oct 15 20:37:24 2009 Subject: x86BIOS and the ISA bus and low memory in general... In-Reply-To: <20091015.134532.-1110324186.imp@bsdimp.com> References: <20091015.085910.-520412456.imp@bsdimp.com> <200910151118.50619.jhb@freebsd.org> <200910151431.53236.jkim@FreeBSD.org> <20091015.134532.-1110324186.imp@bsdimp.com> Message-ID: <4890688A-D2DB-431C-ADB6-03A39A8FD10E@mac.com> On Oct 15, 2009, at 12:45 PM, M. Warner Losh wrote: > [[ redirected to arch@ ]] > > In message: <200910151431.53236.jkim@FreeBSD.org> > Jung-uk Kim writes: > > : This is actually very interesting discussion for me because one of > my > : pet projects is extending x86bios to support non-PC architectures. > : If anyone is interested, the current source tarball is here: > : > : http://people.freebsd.org/~jkim/x86bios-20091015.tar.bz2 > : > : Especially, please see the code around #ifdef X86BIOS_COMPAT_ARCH. > : Basically, mapping I/O ports and orm(4) is missing. We don't have > to > : implement I/O ports but orm(4) vs. bus_space(9) is critical to make > : it a reality. Please consider it as a real practical example for > : orm, not just a blackhole driver. :-) > > I thought that most video cards had I/O ports as well as video RAM > that needed to be mapped... Am I crazy? It depends on the platform. On an Itanium machine I have the VGA frame buffer is at physical address 0xA0000-0xC0000. The only requirement is that you use non-cached I/O, otherwise you get a machine check. This can mean a non-identity mapping or not. It all depends... I/O ports don't exist and there's a memory region for generating I/O port accesses, but the translation is not linear, so you can't work with a single base and port offset to get this to work. See ia64_ioport_address() in sys/ia64/ia64/machdep.c -- Marcel Moolenaar xcllnt@mac.com From jkim at FreeBSD.org Thu Oct 15 23:48:43 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Thu Oct 15 23:48:50 2009 Subject: x86BIOS and the ISA bus and low memory in general... In-Reply-To: <20091015.134532.-1110324186.imp@bsdimp.com> References: <20091015.085910.-520412456.imp@bsdimp.com> <200910151431.53236.jkim@FreeBSD.org> <20091015.134532.-1110324186.imp@bsdimp.com> Message-ID: <200910151948.31334.jkim@FreeBSD.org> On Thursday 15 October 2009 03:45 pm, M. Warner Losh wrote: > [[ redirected to arch@ ]] > > In message: <200910151431.53236.jkim@FreeBSD.org> > Jung-uk Kim writes: > > > : This is actually very interesting discussion for me because one > : of my pet projects is extending x86bios to support non-PC > : architectures. If anyone is interested, the current source > : tarball is here: > : > : http://people.freebsd.org/~jkim/x86bios-20091015.tar.bz2 > : > : Especially, please see the code around #ifdef > : X86BIOS_COMPAT_ARCH. Basically, mapping I/O ports and orm(4) is > : missing. We don't have to implement I/O ports but orm(4) vs. > : bus_space(9) is critical to make it a reality. Please consider > : it as a real practical example for orm, not just a blackhole > : driver. :-) > > I thought that most video cards had I/O ports as well as video RAM > that needed to be mapped... Am I crazy? No, you are not. It's just a non-functional prototype for non-PC architectures. :-) > I'm looking at the code and have a few questions. > > It looks like you are allocating memory from 0x1000 to 0xa0000 with > a contig malloc, and then redirecting the emulator's read/write > into that array. But I don't see where the memory reads for the > so-called ISA ROM hole are going. I was looking for that hoping I > could find them so I could comment on them... You mean 15-16MB ISA hole, right? It's not implemented yet. Probably I should but I haven't seen any BIOS requiring the memory hole ATM. > orm uses bus_space today to do its read/write of the memory. I'd > imagine that if you wanted to touch actual hardware, then you'd > need to have drivers and/or the emulator use the same path to > accomplish this. Actually that's my goal but I wasn't sure whether it is ever usable on *non-PC* arches. Then, orm(4) debate caught my eyes. :-) > While in theory one could have multiple ISA busses in a system, as > a practical matter nobody does this. Even when you have weird > expansion busses on laptop docking stations, you'd have them all > mapped into one space. This means we can likely make some > simplifying assumptions that there is a single ISA bus on the > system. I don't know if we have to make that assumption, but it is > something to keep in the back of our heads. Thanks, I will keep that in mind. > This suggests that the emulation device would have to attach > somehow to the ISA bus to make sure that the right translations > (wherever they happen) can happen. But there's a catch... > > The readw/readb macros in the atkbd.c driver likely need to change > to bus space macros of some kind to make this work. I'm unsure > how, exactly, to make that happen since these addresses aren't for > anything on the actual ISA bus, but rather are for data that's > contained in the contigmalloc'd area. They aren't really ISA bus > addresses, yet they are expected to be there by the drivers. No, I have no intention to support BDA emulation, never. :-) Only IVT will be supported, e.g., vesa(4) calls POST on non-PC arches and it sets up the INT 10h vector. Subsequent INT 10h calls are naturally emulated. > bus_space suggests itself for this as well, but it isn't at all > clear how that might be accomplished because ES could point > anywhere in the first MB of RAM (since 16-bit operations are > limited to 1MB with segments, right?) Correct. > This is a very interesting project... Is the goal to emulate the > BIOS or execute the BIOS that might be loaded on the expansion > cards in these weird environments. I'm guessing the former, but > you never know.. Yes, it's the former, at least for now, e.g., using VBE calls on powerpc or sparc64. If my memory serves, NetBSD or OpenBSD can call video POST in ddb when display is corrupt, I think. Jung-uk Kim From jkim at FreeBSD.org Fri Oct 16 17:46:17 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Fri Oct 16 17:46:23 2009 Subject: x86BIOS and the ISA bus and low memory in general... In-Reply-To: <4890688A-D2DB-431C-ADB6-03A39A8FD10E@mac.com> References: <20091015.085910.-520412456.imp@bsdimp.com> <20091015.134532.-1110324186.imp@bsdimp.com> <4890688A-D2DB-431C-ADB6-03A39A8FD10E@mac.com> Message-ID: <200910161346.03066.jkim@FreeBSD.org> On Thursday 15 October 2009 04:37 pm, Marcel Moolenaar wrote: > On Oct 15, 2009, at 12:45 PM, M. Warner Losh wrote: > > [[ redirected to arch@ ]] > > > > In message: <200910151431.53236.jkim@FreeBSD.org> > > Jung-uk Kim writes: > > > > > > : This is actually very interesting discussion for me because one > > : of > > > > my > > > > : pet projects is extending x86bios to support non-PC > > : architectures. If anyone is interested, the current source > > : tarball is here: > > : > > : http://people.freebsd.org/~jkim/x86bios-20091015.tar.bz2 > > : > > : Especially, please see the code around #ifdef > > : X86BIOS_COMPAT_ARCH. Basically, mapping I/O ports and orm(4) is > > : missing. We don't have > > > > to > > > > : implement I/O ports but orm(4) vs. bus_space(9) is critical to > > : make it a reality. Please consider it as a real practical > > : example for orm, not just a blackhole driver. :-) > > > > I thought that most video cards had I/O ports as well as video > > RAM that needed to be mapped... Am I crazy? > > It depends on the platform. On an Itanium machine I have the > VGA frame buffer is at physical address 0xA0000-0xC0000. The address is the same, then. :-) > The only requirement is that you use non-cached I/O, otherwise > you get a machine check. This can mean a non-identity mapping > or not. It all depends... I couldn't find a way to manipulate memory attribute directly on ia64, i.e., mem_range_attr_{get,set}() and pmap_mapdev_attr() only exist on amd64 and i386. Does pmap_mapdev() set the attribute as UC? > I/O ports don't exist and there's a memory region for generating > I/O port accesses, but the translation is not linear, so you > can't work with a single base and port offset to get this to work. > See ia64_ioport_address() in sys/ia64/ia64/machdep.c It seems there are PC-compatible inline functions {in,out}[bwl] in sys/ia64/include/cpufunc.h. Will they work as I expect? Thanks, Jung-uk Kim From jkim at FreeBSD.org Fri Oct 16 18:00:20 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Fri Oct 16 18:00:27 2009 Subject: x86BIOS and the ISA bus and low memory in general... In-Reply-To: <200910161346.03066.jkim@FreeBSD.org> References: <20091015.085910.-520412456.imp@bsdimp.com> <4890688A-D2DB-431C-ADB6-03A39A8FD10E@mac.com> <200910161346.03066.jkim@FreeBSD.org> Message-ID: <200910161400.00564.jkim@FreeBSD.org> On Friday 16 October 2009 01:46 pm, Jung-uk Kim wrote: > On Thursday 15 October 2009 04:37 pm, Marcel Moolenaar wrote: > > On Oct 15, 2009, at 12:45 PM, M. Warner Losh wrote: > > > [[ redirected to arch@ ]] > > > > > > In message: <200910151431.53236.jkim@FreeBSD.org> > > > Jung-uk Kim writes: > > > > > > > > > : This is actually very interesting discussion for me because > > > : one of > > > > > > my > > > > > > : pet projects is extending x86bios to support non-PC > > > : architectures. If anyone is interested, the current source > > > : tarball is here: > > > : > > > : http://people.freebsd.org/~jkim/x86bios-20091015.tar.bz2 > > > : > > > : Especially, please see the code around #ifdef > > > : X86BIOS_COMPAT_ARCH. Basically, mapping I/O ports and orm(4) > > > : is missing. We don't have > > > > > > to > > > > > > : implement I/O ports but orm(4) vs. bus_space(9) is critical > > > : to make it a reality. Please consider it as a real practical > > > : example for orm, not just a blackhole driver. :-) > > > > > > I thought that most video cards had I/O ports as well as video > > > RAM that needed to be mapped... Am I crazy? > > > > It depends on the platform. On an Itanium machine I have the > > VGA frame buffer is at physical address 0xA0000-0xC0000. > > The address is the same, then. :-) > > > The only requirement is that you use non-cached I/O, otherwise > > you get a machine check. This can mean a non-identity mapping > > or not. It all depends... > > I couldn't find a way to manipulate memory attribute directly on > ia64, i.e., mem_range_attr_{get,set}() and pmap_mapdev_attr() only > exist on amd64 and i386. Does pmap_mapdev() set the attribute as > UC? It seems pmap_mapdev() on ia64 uses IA64_PHYS_TO_RR6() macro. If I read the source correctly, then it is gives UC mapped "view" of the physical address, right? If so, orm(4) can simply do pmap_mapdev()/pmap_unmapdev() around bus_space_read_region_1(). Am I right? Jung-uk Kim > > I/O ports don't exist and there's a memory region for generating > > I/O port accesses, but the translation is not linear, so you > > can't work with a single base and port offset to get this to > > work. See ia64_ioport_address() in sys/ia64/ia64/machdep.c > > It seems there are PC-compatible inline functions {in,out}[bwl] in > sys/ia64/include/cpufunc.h. Will they work as I expect? > > Thanks, > > Jung-uk Kim From imp at bsdimp.com Fri Oct 16 18:27:47 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Oct 16 18:27:54 2009 Subject: x86BIOS and the ISA bus and low memory in general... In-Reply-To: <200910161400.00564.jkim@FreeBSD.org> References: <4890688A-D2DB-431C-ADB6-03A39A8FD10E@mac.com> <200910161346.03066.jkim@FreeBSD.org> <200910161400.00564.jkim@FreeBSD.org> Message-ID: <20091016.122539.-1383511515.imp@bsdimp.com> In message: <200910161400.00564.jkim@FreeBSD.org> Jung-uk Kim writes: : On Friday 16 October 2009 01:46 pm, Jung-uk Kim wrote: : > On Thursday 15 October 2009 04:37 pm, Marcel Moolenaar wrote: : > > On Oct 15, 2009, at 12:45 PM, M. Warner Losh wrote: : > > > [[ redirected to arch@ ]] : > > > : > > > In message: <200910151431.53236.jkim@FreeBSD.org> : > > > Jung-uk Kim writes: : > > > : > > > : > > > : This is actually very interesting discussion for me because : > > > : one of : > > > : > > > my : > > > : > > > : pet projects is extending x86bios to support non-PC : > > > : architectures. If anyone is interested, the current source : > > > : tarball is here: : > > > : : > > > : http://people.freebsd.org/~jkim/x86bios-20091015.tar.bz2 : > > > : : > > > : Especially, please see the code around #ifdef : > > > : X86BIOS_COMPAT_ARCH. Basically, mapping I/O ports and orm(4) : > > > : is missing. We don't have : > > > : > > > to : > > > : > > > : implement I/O ports but orm(4) vs. bus_space(9) is critical : > > > : to make it a reality. Please consider it as a real practical : > > > : example for orm, not just a blackhole driver. :-) : > > > : > > > I thought that most video cards had I/O ports as well as video : > > > RAM that needed to be mapped... Am I crazy? : > > : > > It depends on the platform. On an Itanium machine I have the : > > VGA frame buffer is at physical address 0xA0000-0xC0000. : > : > The address is the same, then. :-) : > : > > The only requirement is that you use non-cached I/O, otherwise : > > you get a machine check. This can mean a non-identity mapping : > > or not. It all depends... : > : > I couldn't find a way to manipulate memory attribute directly on : > ia64, i.e., mem_range_attr_{get,set}() and pmap_mapdev_attr() only : > exist on amd64 and i386. Does pmap_mapdev() set the attribute as : > UC? : : It seems pmap_mapdev() on ia64 uses IA64_PHYS_TO_RR6() macro. If I : read the source correctly, then it is gives UC mapped "view" of the : physical address, right? If so, orm(4) can simply do : pmap_mapdev()/pmap_unmapdev() around bus_space_read_region_1(). Am I : right? I don't think that's the right solution here. The pmap_mapdev stuff should happen when the resource is activated... Warner From jhb at freebsd.org Fri Oct 16 18:36:24 2009 From: jhb at freebsd.org (John Baldwin) Date: Fri Oct 16 18:36:30 2009 Subject: x86BIOS and the ISA bus and low memory in general... In-Reply-To: <200910161400.00564.jkim@FreeBSD.org> References: <20091015.085910.-520412456.imp@bsdimp.com> <200910161346.03066.jkim@FreeBSD.org> <200910161400.00564.jkim@FreeBSD.org> Message-ID: <200910161419.08369.jhb@freebsd.org> On Friday 16 October 2009 1:59:58 pm Jung-uk Kim wrote: > On Friday 16 October 2009 01:46 pm, Jung-uk Kim wrote: > > On Thursday 15 October 2009 04:37 pm, Marcel Moolenaar wrote: > > > On Oct 15, 2009, at 12:45 PM, M. Warner Losh wrote: > > > > [[ redirected to arch@ ]] > > > > > > > > In message: <200910151431.53236.jkim@FreeBSD.org> > > > > Jung-uk Kim writes: > > > > > > > > > > > > : This is actually very interesting discussion for me because > > > > : one of > > > > > > > > my > > > > > > > > : pet projects is extending x86bios to support non-PC > > > > : architectures. If anyone is interested, the current source > > > > : tarball is here: > > > > : > > > > : http://people.freebsd.org/~jkim/x86bios-20091015.tar.bz2 > > > > : > > > > : Especially, please see the code around #ifdef > > > > : X86BIOS_COMPAT_ARCH. Basically, mapping I/O ports and orm(4) > > > > : is missing. We don't have > > > > > > > > to > > > > > > > > : implement I/O ports but orm(4) vs. bus_space(9) is critical > > > > : to make it a reality. Please consider it as a real practical > > > > : example for orm, not just a blackhole driver. :-) > > > > > > > > I thought that most video cards had I/O ports as well as video > > > > RAM that needed to be mapped... Am I crazy? > > > > > > It depends on the platform. On an Itanium machine I have the > > > VGA frame buffer is at physical address 0xA0000-0xC0000. > > > > The address is the same, then. :-) > > > > > The only requirement is that you use non-cached I/O, otherwise > > > you get a machine check. This can mean a non-identity mapping > > > or not. It all depends... > > > > I couldn't find a way to manipulate memory attribute directly on > > ia64, i.e., mem_range_attr_{get,set}() and pmap_mapdev_attr() only > > exist on amd64 and i386. Does pmap_mapdev() set the attribute as > > UC? > > It seems pmap_mapdev() on ia64 uses IA64_PHYS_TO_RR6() macro. If I > read the source correctly, then it is gives UC mapped "view" of the > physical address, right? If so, orm(4) can simply do > pmap_mapdev()/pmap_unmapdev() around bus_space_read_region_1(). Am I > right? I think you need to back up a bit. Instead of having a bunch of MD code to provide ISA access for each arch, instead do what Warner suggests which is to create a psuedo ISA device that attaches to isa0 and acts as a proxy for ISA I/O. It can allocate ISA resources for both memory and I/O access and then use bus_space_*() accesses to perform actual I/O. This will be MI. The only problem I can see with this approach is if a BIOS call attempts to frob a resource that another ISA device already owns. There may be ways around that though. -- John Baldwin From jkim at FreeBSD.org Fri Oct 16 19:04:18 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Fri Oct 16 19:04:25 2009 Subject: x86BIOS and the ISA bus and low memory in general... In-Reply-To: <20091016.122539.-1383511515.imp@bsdimp.com> References: <4890688A-D2DB-431C-ADB6-03A39A8FD10E@mac.com> <200910161400.00564.jkim@FreeBSD.org> <20091016.122539.-1383511515.imp@bsdimp.com> Message-ID: <200910161504.09685.jkim@FreeBSD.org> On Friday 16 October 2009 02:25 pm, M. Warner Losh wrote: > In message: <200910161400.00564.jkim@FreeBSD.org> > > Jung-uk Kim writes: > : On Friday 16 October 2009 01:46 pm, Jung-uk Kim wrote: > : > On Thursday 15 October 2009 04:37 pm, Marcel Moolenaar wrote: > : > > On Oct 15, 2009, at 12:45 PM, M. Warner Losh wrote: > : > > > [[ redirected to arch@ ]] > : > > > > : > > > In message: <200910151431.53236.jkim@FreeBSD.org> > : > > > Jung-uk Kim writes: > : > > > > : > > > > : > > > : This is actually very interesting discussion for me > : > > > : because one of > : > > > > : > > > my > : > > > > : > > > : pet projects is extending x86bios to support non-PC > : > > > : architectures. If anyone is interested, the current > : > > > : source tarball is here: > : > > > : > : > > > : http://people.freebsd.org/~jkim/x86bios-20091015.tar.bz2 > : > > > : > : > > > : Especially, please see the code around #ifdef > : > > > : X86BIOS_COMPAT_ARCH. Basically, mapping I/O ports and > : > > > : orm(4) is missing. We don't have > : > > > > : > > > to > : > > > > : > > > : implement I/O ports but orm(4) vs. bus_space(9) is > : > > > : critical to make it a reality. Please consider it as a > : > > > : real practical example for orm, not just a blackhole > : > > > : driver. :-) > : > > > > : > > > I thought that most video cards had I/O ports as well as > : > > > video RAM that needed to be mapped... Am I crazy? > : > > > : > > It depends on the platform. On an Itanium machine I have the > : > > VGA frame buffer is at physical address 0xA0000-0xC0000. > : > > : > The address is the same, then. :-) > : > > : > > The only requirement is that you use non-cached I/O, > : > > otherwise you get a machine check. This can mean a > : > > non-identity mapping or not. It all depends... > : > > : > I couldn't find a way to manipulate memory attribute directly > : > on ia64, i.e., mem_range_attr_{get,set}() and > : > pmap_mapdev_attr() only exist on amd64 and i386. Does > : > pmap_mapdev() set the attribute as UC? > : > : It seems pmap_mapdev() on ia64 uses IA64_PHYS_TO_RR6() macro. If > : I read the source correctly, then it is gives UC mapped "view" of > : the physical address, right? If so, orm(4) can simply do > : pmap_mapdev()/pmap_unmapdev() around bus_space_read_region_1(). > : Am I right? > > I don't think that's the right solution here. The pmap_mapdev > stuff should happen when the resource is activated... For that, I guess we need another resource flag, e.g., RF_DEVICE, maybe? Jung-uk Kim From jkim at FreeBSD.org Fri Oct 16 19:17:46 2009 From: jkim at FreeBSD.org (Jung-uk Kim) Date: Fri Oct 16 19:17:53 2009 Subject: x86BIOS and the ISA bus and low memory in general... In-Reply-To: <200910161419.08369.jhb@freebsd.org> References: <20091015.085910.-520412456.imp@bsdimp.com> <200910161400.00564.jkim@FreeBSD.org> <200910161419.08369.jhb@freebsd.org> Message-ID: <200910161517.37518.jkim@FreeBSD.org> On Friday 16 October 2009 02:19 pm, John Baldwin wrote: > On Friday 16 October 2009 1:59:58 pm Jung-uk Kim wrote: > > On Friday 16 October 2009 01:46 pm, Jung-uk Kim wrote: > > > On Thursday 15 October 2009 04:37 pm, Marcel Moolenaar wrote: > > > > On Oct 15, 2009, at 12:45 PM, M. Warner Losh wrote: > > > > > [[ redirected to arch@ ]] > > > > > > > > > > In message: <200910151431.53236.jkim@FreeBSD.org> > > > > > Jung-uk Kim writes: > > > > > > > > > > > > > > > : This is actually very interesting discussion for me > > > > > : because one of > > > > > > > > > > my > > > > > > > > > > : pet projects is extending x86bios to support non-PC > > > > > : architectures. If anyone is interested, the current > > > > > : source tarball is here: > > > > > : > > > > > : http://people.freebsd.org/~jkim/x86bios-20091015.tar.bz2 > > > > > : > > > > > : Especially, please see the code around #ifdef > > > > > : X86BIOS_COMPAT_ARCH. Basically, mapping I/O ports and > > > > > : orm(4) is missing. We don't have > > > > > > > > > > to > > > > > > > > > > : implement I/O ports but orm(4) vs. bus_space(9) is > > > > > : critical to make it a reality. Please consider it as a > > > > > : real practical example for orm, not just a blackhole > > > > > : driver. :-) > > > > > > > > > > I thought that most video cards had I/O ports as well as > > > > > video RAM that needed to be mapped... Am I crazy? > > > > > > > > It depends on the platform. On an Itanium machine I have the > > > > VGA frame buffer is at physical address 0xA0000-0xC0000. > > > > > > The address is the same, then. :-) > > > > > > > The only requirement is that you use non-cached I/O, > > > > otherwise you get a machine check. This can mean a > > > > non-identity mapping or not. It all depends... > > > > > > I couldn't find a way to manipulate memory attribute directly > > > on ia64, i.e., mem_range_attr_{get,set}() and > > > pmap_mapdev_attr() only exist on amd64 and i386. Does > > > pmap_mapdev() set the attribute as UC? > > > > It seems pmap_mapdev() on ia64 uses IA64_PHYS_TO_RR6() macro. If > > I read the source correctly, then it is gives UC mapped "view" of > > the physical address, right? If so, orm(4) can simply do > > pmap_mapdev()/pmap_unmapdev() around bus_space_read_region_1(). > > Am I right? > > I think you need to back up a bit. Instead of having a bunch of MD > code to provide ISA access for each arch, instead do what Warner > suggests which is to create a psuedo ISA device that attaches to > isa0 and acts as a proxy for ISA I/O. It can allocate ISA > resources for both memory and I/O access and then use bus_space_*() > accesses to perform actual I/O. This will be MI. The only problem > I can see with this approach is if a BIOS call attempts to frob a > resource that another ISA device already owns. There may be ways > around that though. That's very interesting idea and it may be very useful for paravirtualized environment, I guess. However, it's beyond my free time. :-( Just in case, I updated the source and uploaded it here: http://people.freebsd.org/~jkim/x86bios-20091016.tar.bz2 For the efficiency reasons, I'd like to keep the amd64/i386 code as is. Feel free to fill in the MI implementation if you want. Thanks, Jung-uk Kim From imp at bsdimp.com Fri Oct 16 19:34:32 2009 From: imp at bsdimp.com (M. Warner Losh) Date: Fri Oct 16 19:34:38 2009 Subject: x86BIOS and the ISA bus and low memory in general... In-Reply-To: <200910161504.09685.jkim@FreeBSD.org> References: <200910161400.00564.jkim@FreeBSD.org> <20091016.122539.-1383511515.imp@bsdimp.com> <200910161504.09685.jkim@FreeBSD.org> Message-ID: <20091016.132531.377201063.imp@bsdimp.com> In message: <200910161504.09685.jkim@FreeBSD.org> Jung-uk Kim writes: : On Friday 16 October 2009 02:25 pm, M. Warner Losh wrote: : > In message: <200910161400.00564.jkim@FreeBSD.org> : > : > Jung-uk Kim writes: : > : On Friday 16 October 2009 01:46 pm, Jung-uk Kim wrote: : > : > On Thursday 15 October 2009 04:37 pm, Marcel Moolenaar wrote: : > : > > On Oct 15, 2009, at 12:45 PM, M. Warner Losh wrote: : > : > > > [[ redirected to arch@ ]] : > : > > > : > : > > > In message: <200910151431.53236.jkim@FreeBSD.org> : > : > > > Jung-uk Kim writes: : > : > > > : > : > > > : > : > > > : This is actually very interesting discussion for me : > : > > > : because one of : > : > > > : > : > > > my : > : > > > : > : > > > : pet projects is extending x86bios to support non-PC : > : > > > : architectures. If anyone is interested, the current : > : > > > : source tarball is here: : > : > > > : : > : > > > : http://people.freebsd.org/~jkim/x86bios-20091015.tar.bz2 : > : > > > : : > : > > > : Especially, please see the code around #ifdef : > : > > > : X86BIOS_COMPAT_ARCH. Basically, mapping I/O ports and : > : > > > : orm(4) is missing. We don't have : > : > > > : > : > > > to : > : > > > : > : > > > : implement I/O ports but orm(4) vs. bus_space(9) is : > : > > > : critical to make it a reality. Please consider it as a : > : > > > : real practical example for orm, not just a blackhole : > : > > > : driver. :-) : > : > > > : > : > > > I thought that most video cards had I/O ports as well as : > : > > > video RAM that needed to be mapped... Am I crazy? : > : > > : > : > > It depends on the platform. On an Itanium machine I have the : > : > > VGA frame buffer is at physical address 0xA0000-0xC0000. : > : > : > : > The address is the same, then. :-) : > : > : > : > > The only requirement is that you use non-cached I/O, : > : > > otherwise you get a machine check. This can mean a : > : > > non-identity mapping or not. It all depends... : > : > : > : > I couldn't find a way to manipulate memory attribute directly : > : > on ia64, i.e., mem_range_attr_{get,set}() and : > : > pmap_mapdev_attr() only exist on amd64 and i386. Does : > : > pmap_mapdev() set the attribute as UC? : > : : > : It seems pmap_mapdev() on ia64 uses IA64_PHYS_TO_RR6() macro. If : > : I read the source correctly, then it is gives UC mapped "view" of : > : the physical address, right? If so, orm(4) can simply do : > : pmap_mapdev()/pmap_unmapdev() around bus_space_read_region_1(). : > : Am I right? : > : > I don't think that's the right solution here. The pmap_mapdev : > stuff should happen when the resource is activated... : : For that, I guess we need another resource flag, e.g., RF_DEVICE, : maybe? No. The activate will be able to do this. If we need to, we can move the activate from MI to MD. Warner From xcllnt at mac.com Sat Oct 17 05:09:37 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Oct 17 05:09:44 2009 Subject: x86BIOS and the ISA bus and low memory in general... In-Reply-To: <200910161346.03066.jkim@FreeBSD.org> References: <20091015.085910.-520412456.imp@bsdimp.com> <20091015.134532.-1110324186.imp@bsdimp.com> <4890688A-D2DB-431C-ADB6-03A39A8FD10E@mac.com> <200910161346.03066.jkim@FreeBSD.org> Message-ID: <7178B392-D211-41C3-80DC-97E90263B8B7@mac.com> On Oct 16, 2009, at 10:46 AM, Jung-uk Kim wrote: >>> >>> I thought that most video cards had I/O ports as well as video >>> RAM that needed to be mapped... Am I crazy? >> >> It depends on the platform. On an Itanium machine I have the >> VGA frame buffer is at physical address 0xA0000-0xC0000. > > The address is the same, then. :-) On this one machine it happens to be the same. On another machine there's no addressable memory below 768TB (yes, terabyte), so as I said: it depends. >> The only requirement is that you use non-cached I/O, otherwise >> you get a machine check. This can mean a non-identity mapping >> or not. It all depends... > > I couldn't find a way to manipulate memory attribute directly on ia64, > i.e., mem_range_attr_{get,set}() and pmap_mapdev_attr() only exist on > amd64 and i386. Does pmap_mapdev() set the attribute as UC? New KPIs are typically only implemented for i386 and amd64. It's one of the many unnecessary difficulties one faces when trying to port or maintain a platform. > It seems there are PC-compatible inline functions {in,out}[bwl] in > sys/ia64/include/cpufunc.h. Will they work as I expect? Yes, but it's always been my intention to remove them. Don't base any implementation on the existence of these... FYI, -- Marcel Moolenaar xcllnt@mac.com From xcllnt at mac.com Sat Oct 17 05:12:39 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Sat Oct 17 05:12:45 2009 Subject: x86BIOS and the ISA bus and low memory in general... In-Reply-To: <200910161400.00564.jkim@FreeBSD.org> References: <20091015.085910.-520412456.imp@bsdimp.com> <4890688A-D2DB-431C-ADB6-03A39A8FD10E@mac.com> <200910161346.03066.jkim@FreeBSD.org> <200910161400.00564.jkim@FreeBSD.org> Message-ID: On Oct 16, 2009, at 10:59 AM, Jung-uk Kim wrote: > > It seems pmap_mapdev() on ia64 uses IA64_PHYS_TO_RR6() macro. If I > read the source correctly, then it is gives UC mapped "view" of the > physical address, right? If so, orm(4) can simply do > pmap_mapdev()/pmap_unmapdev() around bus_space_read_region_1(). Am I > right? Not quite. pmap_mapdev() assumes that the passed physical address is valid. It not being a valid physical address was the pivotal problem and the reason why I limited orm(4) to i386 and amd64. -- Marcel Moolenaar xcllnt@mac.com From bugmaster at FreeBSD.org Mon Oct 19 11:06:49 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 19 11:07:32 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200910191106.n9JB6mir063372@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From jhb at freebsd.org Mon Oct 19 20:34:39 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Oct 19 20:34:52 2009 Subject: Put a timeout on -ve name cache entries in NFS Message-ID: <200910191634.30040.jhb@freebsd.org> This patch allows one to put an upper time limit on how long the NFS client should keep negative cache entries around for a given directory. This is basically a safety belt as there are certain races with -ve entries that are not easily fixed (e.g. dealing with the low resolution of the directory modification timestamps). However, timing out the entries would put a limit on how stale the client's cache entries could be. My main question is do folks think this value should be tunable as a global sysctl or a per-mount option. A sysctl is far easier to implement (and the acccess cache timeout is a sysctl). However, the other namecache-related settings are all mount options, so a mount option might be more consistent. Current rough patch is below: --- //depot/projects/smpng/sys/nfsclient/nfs_vnops.c 2009/10/19 14:27:26 +++ //depot/user/jhb/lock/nfsclient/nfs_vnops.c 2009/10/19 19:53:51 @@ -981,9 +981,11 @@ * We only accept a negative hit in the cache if the * modification time of the parent directory matches * our cached copy. Otherwise, we discard all of the - * negative cache entries for this directory. + * negative cache entries for this directory. We also + * only trust -ve cache entries for up to 5 seconds. */ - if (VOP_GETATTR(dvp, &vattr, cnp->cn_cred) == 0 && + if ((u_int)(ticks - np->n_dmtime_ticks) <= 5 && + VOP_GETATTR(dvp, &vattr, cnp->cn_cred) == 0 && vattr.va_mtime.tv_sec == np->n_dmtime) { nfsstats.lookupcache_hits++; return (ENOENT); @@ -1157,8 +1159,10 @@ */ mtx_lock(&np->n_mtx); if (np->n_dmtime <= dmtime) { - if (np->n_dmtime == 0) + if (np->n_dmtime == 0) { np->n_dmtime = dmtime; + np->n_dmtime_ticks = ticks; + } mtx_unlock(&np->n_mtx); cache_enter(dvp, NULL, cnp); } else --- //depot/projects/smpng/sys/nfsclient/nfsnode.h 2009/05/29 14:35:29 +++ //depot/user/jhb/lock/nfsclient/nfsnode.h 2009/10/19 19:53:51 @@ -119,6 +119,7 @@ struct vnode *n_vnode; /* associated vnode */ struct vnode *n_dvp; /* parent vnode */ int n_error; /* Save write error value */ + int n_dmtime_ticks; /* When n_dmtime was last set */ union { struct timespec nf_atim; /* Special file times */ nfsuint64 nd_cookieverf; /* Cookie verifier (dir only) */ -- John Baldwin From Alexei.Volkov at softlynx.ru Tue Oct 20 07:35:21 2009 From: Alexei.Volkov at softlynx.ru (Alexei Volkov) Date: Tue Oct 20 07:35:27 2009 Subject: Automatic dual kernel cd boot amd64/i386 Message-ID: <4ADD662E.9020003@softlynx.ru> Hello. Is it possible to get bootable cd with auto selectable amd64/i386 boot? For instance , i have a bootable cd with two kernels: * first is located in /boot/kernel.amd64 * second in /boot/kernel.i386 loader.conf has line /kernel=kernel.amd64/ When it boots on amd64 incompatible hardware it start loading the kernel and returns to the loader prompt showing error "Long mode not supported" or something like that. Is it possible to configure loader.conf or any other place to get automatically started with second kernel.i386 from that point instead of waiting for user interaction? WBR, Alexei Volkov. From Alexei.Volkov at softlynx.ru Tue Oct 20 07:40:22 2009 From: Alexei.Volkov at softlynx.ru (Alexei Volkov) Date: Tue Oct 20 07:40:28 2009 Subject: Automatic dual kernel cd boot amd64/i386 Message-ID: <4ADD6536.6000902@softlynx.ru> Hello. Is it possible to get bootable cd with auto selectable amd64/i386 boot? For instance , i have a bootable cd with two kernels: * first is located in /boot/kernel.amd64 * second in /boot/kernel.i386 loader.conf has line /kernel=kernel.amd64/ When it boots on amd64 incompatible hardware it start loading the kernel and returns to the loader prompt showing error "Long mode not supported" or something like that. Is it possible to configure loader.conf or any other place to get automatically started with second kernel.i386 from that point instead of waiting for user interaction? WBR, Alexei Volkov. From ed at 80386.nl Wed Oct 21 22:20:45 2009 From: ed at 80386.nl (Ed Schouten) Date: Wed Oct 21 22:20:52 2009 Subject: Setting the jail identifier from /etc/rc.conf Message-ID: <20091021222054.GJ1293@hoeg.nl> Hi, I haven't played with Jails for a long time, but I wanted to figure out how hard it is to make init spawn getties for certain jails. It shouldn't be too hard (jexec foo /usr/libexec/getty), but I can't seem to find a way to set the jid to a certain value from within rc.conf. It also seems jids cannot contain dots, which means I cannot set the jid equal to the hostname of the jail. Maybe a Jail hacker can give me some advice here? Wouldn't it be more sane if the kernel just used the hostname as an identifier if there is no jail with the same hostname yet? Or maybe we should at least provide a config tunable for this? -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20091021/440fd576/attachment.pgp From bzeeb-lists at lists.zabbadoz.net Wed Oct 21 22:54:31 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Wed Oct 21 22:54:44 2009 Subject: Setting the jail identifier from /etc/rc.conf In-Reply-To: <20091021222054.GJ1293@hoeg.nl> References: <20091021222054.GJ1293@hoeg.nl> Message-ID: <20091021222851.O91695@maildrop.int.zabbadoz.net> On Thu, 22 Oct 2009, Ed Schouten wrote: > Hi, > > I haven't played with Jails for a long time, but I wanted to figure out > how hard it is to make init spawn getties for certain jails. It > shouldn't be too hard (jexec foo /usr/libexec/getty), but I can't seem > to find a way to set the jid to a certain value from within rc.conf. > > It also seems jids cannot contain dots, which means I cannot set the jid > equal to the hostname of the jail. > > Maybe a Jail hacker can give me some advice here? Wouldn't it be more > sane if the kernel just used the hostname as an identifier if there is > no jail with the same hostname yet? Or maybe we should at least provide > a config tunable for this? Redirect to freebsd-jail@ ; you may even find the answers to those int he mail archive (unless those had been private threads I was on Cc: on;-) -- Bjoern A. Zeeb It will not break if you know what you are doing. From des at des.no Wed Oct 21 22:54:34 2009 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed Oct 21 22:54:45 2009 Subject: Setting the jail identifier from /etc/rc.conf In-Reply-To: <20091021222054.GJ1293@hoeg.nl> (Ed Schouten's message of "Thu, 22 Oct 2009 00:20:54 +0200") References: <20091021222054.GJ1293@hoeg.nl> Message-ID: <86ljj4s6hj.fsf@ds4.des.no> Ed Schouten writes: > I haven't played with Jails for a long time, but I wanted to figure out > how hard it is to make init spawn getties for certain jails. It > shouldn't be too hard (jexec foo /usr/libexec/getty), but I can't seem > to find a way to set the jid to a certain value from within rc.conf. The jid is a number assigned by the kernel which increases monotonically for every jail created. If you stop and restart a jail, it will get a new jid. If you're thinking of the jail name as specified in rc.conf, that's internal to the rc script - it is not passed to the kernel. The kernel's idea of the jail name defaults to the string representation of the jid (i.e. a jail with jid 4 is named "4" unless otherwise specified on the command line). There is no rc.conf variable for it, but you can add "-n foo" to jail_foo_flags. (it seems /etc/rc.d/jail hasn't quite caught up with the new jail(8) command line syntax) Currently, your best bet is probably to read the jid from /var/run/jail_${foo}.id, which is created by the rc script when it starts the jail. > It also seems jids cannot contain dots, which means I cannot set the jid > equal to the hostname of the jail. The jail name can not contain dots because jails can nest, and dots are used to separate components in the fully qualified name of a jail. If you start a jail named "foo", and within "foo" start a jail named "bar", then the fully qualified name of the inner jail is "foo.bar". DES -- Dag-Erling Sm?rgrav - des@des.no From brde at optusnet.com.au Thu Oct 22 07:33:55 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Thu Oct 22 07:34:02 2009 Subject: Put a timeout on -ve name cache entries in NFS In-Reply-To: <200910191634.30040.jhb@freebsd.org> References: <200910191634.30040.jhb@freebsd.org> Message-ID: <20091022182943.P13634@delplex.bde.org> On Mon, 19 Oct 2009, John Baldwin wrote: > This patch allows one to put an upper time limit on how long the NFS client > should keep negative cache entries around for a given directory. This is > basically a safety belt as there are certain races with -ve entries that are > not easily fixed (e.g. dealing with the low resolution of the directory > modification timestamps). However, timing out the entries would put a limit > on how stale the client's cache entries could be. My main question is do > folks think this value should be tunable as a global sysctl or a per-mount > option. A sysctl is far easier to implement (and the acccess cache timeout > is a sysctl). However, the other namecache-related settings are all mount > options, so a mount option might be more consistent. Current rough patch is > below: One reason that I never committed my port of NetBSD's implementation of negative cache entries for nfs is that I thought the timeout should be a mount option but I didn't want to deal with the portability problems from that. Bruce From ed at 80386.nl Thu Oct 22 12:08:18 2009 From: ed at 80386.nl (Ed Schouten) Date: Thu Oct 22 12:08:29 2009 Subject: Setting the jail identifier from /etc/rc.conf In-Reply-To: <86ljj4s6hj.fsf@ds4.des.no> References: <20091021222054.GJ1293@hoeg.nl> <86ljj4s6hj.fsf@ds4.des.no> Message-ID: <20091022120816.GK1293@hoeg.nl> Hi Dag-Erling, * Dag-Erling Sm?rgrav wrote: > on the command line). There is no rc.conf variable for it, but you can > add "-n foo" to jail_foo_flags. Well, good enough I guess. I solved the entire getty thing by doing the following. I'm running a jail called small.80386.nl, which is a temporary install I had, to see what happens if you enable a lot of WITHOUT_* flags. /etc/devfs.rules: | [small_80386_nl=5] | add include $devfsrules_hide_all | add include $devfsrules_unhide_basic | add include $devfsrules_unhide_login | add path ttyv8 unhide /etc/rc.conf: | jail_small_flags="-l -U root -n small_80386_nl" | jail_small_devfs_ruleset="small_80386_nl" /etc/ttys: | ttyv8 "/usr/sbin/jexec small_80386_nl /usr/libexec/getty Pc" cons25 on secure -- Ed Schouten WWW: http://80386.nl/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20091022/5921abf3/attachment.pgp From rmacklem at uoguelph.ca Thu Oct 22 15:02:21 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Thu Oct 22 15:02:31 2009 Subject: Put a timeout on -ve name cache entries in NFS In-Reply-To: <20091022182943.P13634@delplex.bde.org> References: <200910191634.30040.jhb@freebsd.org> <20091022182943.P13634@delplex.bde.org> Message-ID: On Thu, 22 Oct 2009, Bruce Evans wrote: > > One reason that I never committed my port of NetBSD's implementation of > negative cache entries for nfs is that I thought the timeout should be > a mount option but I didn't want to deal with the portability problems > from that. > Just to clarify. Are you saying that, given no other system has such a mount option, you think the sysctl variable is an ok solution or that you think it should be a mount option and not a sysctl variable? I'll admit that I'm biased because the sysctl variable is easier to do (and I don't think many people will need to twiddle it). I suggested it to John, mostly so that there was a way of disabling the -ve name caching, for the rare case where it might be causing someone grief. (That's what I think he meant by "safety belt".) rick From brde at optusnet.com.au Fri Oct 23 14:29:29 2009 From: brde at optusnet.com.au (Bruce Evans) Date: Fri Oct 23 14:29:36 2009 Subject: Put a timeout on -ve name cache entries in NFS In-Reply-To: References: <200910191634.30040.jhb@freebsd.org> <20091022182943.P13634@delplex.bde.org> Message-ID: <20091024010347.D14674@delplex.bde.org> On Thu, 22 Oct 2009, Rick Macklem wrote: > On Thu, 22 Oct 2009, Bruce Evans wrote: >> One reason that I never committed my port of NetBSD's implementation of >> negative cache entries for nfs is that I thought the timeout should be >> a mount option but I didn't want to deal with the portability problems >> from that. >> > Just to clarify. Are you saying that, given no other system has such > a mount option, you think the sysctl variable is an ok solution or > that you think it should be a mount option and not a sysctl variable? No; I think it should be a mount option. > I'll admit that I'm biased because the sysctl variable is easier to > do (and I don't think many people will need to twiddle it). I suggested > it to John, mostly so that there was a way of disabling the -ve name > caching, for the rare case where it might be causing someone grief. > (That's what I think he meant by "safety belt".) Mount options are harder to add (especially using nmount) but that is not intrinsic (in 4.4BSD, sysctls were harder to add, but now they have more infrastructure so they are easier to add). It would almost be easier to abuse sysctls for mount options (they would have to select the mount instance). My version actually just uses a hackish sysctl vfs.nfs.negcache (default: enabled) to enable the negative name cache. I don't have any timeout control for it. Bruce From rmacklem at uoguelph.ca Fri Oct 23 14:43:33 2009 From: rmacklem at uoguelph.ca (Rick Macklem) Date: Fri Oct 23 14:43:45 2009 Subject: Put a timeout on -ve name cache entries in NFS In-Reply-To: <20091024010347.D14674@delplex.bde.org> References: <200910191634.30040.jhb@freebsd.org> <20091022182943.P13634@delplex.bde.org> <20091024010347.D14674@delplex.bde.org> Message-ID: On Sat, 24 Oct 2009, Bruce Evans wrote: > On Thu, 22 Oct 2009, Rick Macklem wrote: > >> On Thu, 22 Oct 2009, Bruce Evans wrote: >>> One reason that I never committed my port of NetBSD's implementation of >>> negative cache entries for nfs is that I thought the timeout should be >>> a mount option but I didn't want to deal with the portability problems >>> from that. >>> >> Just to clarify. Are you saying that, given no other system has such >> a mount option, you think the sysctl variable is an ok solution or >> that you think it should be a mount option and not a sysctl variable? > > No; I think it should be a mount option. > Ok, so then what were your concerns w.r.t "portability problems"? (It's not that much work to make it a mount option and since it looks like the patch will be delayed until after 8.0 releases, I/or John can make it a mount option but I didn't understand what you meant by "portability options".) [good stuff w.r.t. which is harder, deleted for brevity] > > My version actually just uses a hackish sysctl vfs.nfs.negcache (default: > enabled) to enable the negative name cache. I don't have any timeout > control for it. > Yea, I saw it mainly as a way to disable -ve caching too. It just happened that the sysctl variable could specify the timeout as well as disable it (if set == 0). When it comes to a mount option, an enable/disable flag is probably easier, but then there might be a debate along the lines of "An option shouldn't be enabled by default...", so I'm temped to stick with a setable timeout. Basically the current code has an "infinite" timeout and no way of disabling it, so it seemed to me that some sort of optional timeout/disable would be useful, so I suggested that to John. If no-one else weighs in on the other side, I head in the "mount option" direction, rick From bzeeb-lists at lists.zabbadoz.net Sun Oct 25 14:00:08 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Sun Oct 25 14:00:14 2009 Subject: src/Makefile, universe, LINT, VIMAGE, .. Message-ID: <20091025134226.Q91695@maildrop.int.zabbadoz.net> Hi, since the advent of VIMAGE in FreeBSD HEAD we've had a way to compile the network stack in multiple ways. Unfortunately LINT can always only test one of the options. In addition I, for quite a while, had other combinations I tested like nooptions INET6 or nooptions INET nooptions INET6 etc. We need a solution to be able to test those things and make sure to not break those combinations (atm at least VIMAGE). Unfortunately our build system and kernel configurations are not there yet. I had been pondering whether to just commit a LINT-VIMAGE file that would include LINT and just fail if that wasn't there but then realized that this will not fix the real problem. Some archs do not even have a LINT file, btw. The information attached to the diff will tell you more about what I did. I am not yet convinced that the solution presented further down is the right thing to do (and would do the right thing in all cases though I tested the obvious ones). Thus I'd like to solicit feedback, comments, improved version, ..;) You can also fetch the diff temporary from: http://people.freebsd.org/~bz/20091025-01-make-LINT-VIMAGE.diff Thanks, /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. ! ! In sys//conf/Makefile set TARGET to . That allows ! sys/conf/makeLINT.mk to only do certain things for certain ! architectures. ! ! Generate a second LINT configuration for i386 and amd64 in ! sys/conf/makeLINT.mk, which includes LINT and sets options VIMAGE ! so that we will have VIMAGE LINT builds[1]. ! ! To avoid hardcoding further kernel configuration names for ! make universe, split the logic into two parts: ! - 1st to build worlds and generate kernel configs like LINT. ! - 2nd to build kernels for a given TARGET architecture correctly ! finding all newly generated configs, not knowing anything about ! LINT anymore. (*) ! ! (*) If you know better/cleaner/... ways to do this, let me know. ! ! Annotation: this also allows one to add more such kernel configs ! like LINT-NOINET, LINT-NOINET6, .. that I have had for ages now ! to generate and maintain in a single place. ! ! ! Requested by: jhb [1] ! Discussed with: jhb, rwatson [1] ! Reviewed by: ! MFC After: ! Index: Makefile =================================================================== --- Makefile (revision 198467) +++ Makefile (working copy) @@ -297,10 +297,6 @@ rm -f ${FAILFILE} .endif .for target in ${TARGETS} -KERNCONFS!= cd ${.CURDIR}/sys/${target}/conf && \ - find [A-Z0-9]*[A-Z0-9] -type f -maxdepth 0 \ - ! -name DEFAULTS ! -name LINT -KERNCONFS:= ${KERNCONFS:S/^NOTES$/LINT/} universe: universe_${target} .ORDER: universe_prologue universe_${target} universe_epilogue universe_${target}: @@ -320,15 +316,7 @@ (echo "${target} 'make LINT' failed," \ "check _.${target}.makeLINT for details"| ${MAKEFAIL})) .endif -.for kernel in ${KERNCONFS} - @(cd ${.CURDIR} && env __MAKE_CONF=/dev/null \ - ${MAKE} ${JFLAG} buildkernel \ - TARGET=${target} \ - KERNCONF=${kernel} \ - > _.${target}.${kernel} 2>&1 || \ - (echo "${target} ${kernel} kernel failed," \ - "check _.${target}.${kernel} for details"| ${MAKEFAIL})) -.endfor + cd ${.CURDIR} && ${MAKE} ${.MAKEFLAGS} TARGET=${target} universe_kernels @echo ">> ${target} completed on `LC_ALL=C date`" .endfor universe: universe_epilogue @@ -345,3 +333,18 @@ fi .endif .endif + +universe_kernels: universe_kernels_foo +TARGET?= ${BUILD_ARCH} +KERNCONFS!= cd ${.CURDIR}/sys/${TARGET}/conf && \ + find [A-Z0-9]*[A-Z0-9] -type f -maxdepth 0 \ + ! -name DEFAULTS ! -name NOTES +KERNCONFS:= ${KERNCONFS} +universe_kernels_foo: +.for kernel in ${KERNCONFS} + @(cd ${.CURDIR} && env __MAKE_CONF=/dev/null \ + ${MAKE} ${JFLAG} buildkernel TARGET=${TARGET} KERNCONF=${kernel} \ + > _.${TARGET}.${kernel} 2>&1 || \ + (echo "${TARGET} ${kernel} kernel failed," \ + "check _.${TARGET}.${kernel} for details"| ${MAKEFAIL})) +.endfor Index: sys/powerpc/conf/Makefile =================================================================== --- sys/powerpc/conf/Makefile (revision 198467) +++ sys/powerpc/conf/Makefile (working copy) @@ -1,3 +1,5 @@ # $FreeBSD$ +TARGET=powerpc + .include "${.CURDIR}/../../conf/makeLINT.mk" Index: sys/sparc64/conf/Makefile =================================================================== --- sys/sparc64/conf/Makefile (revision 198467) +++ sys/sparc64/conf/Makefile (working copy) @@ -1,3 +1,5 @@ # $FreeBSD$ +TARGET=sparc64 + .include "${.CURDIR}/../../conf/makeLINT.mk" Index: sys/conf/makeLINT.mk =================================================================== --- sys/conf/makeLINT.mk (revision 198467) +++ sys/conf/makeLINT.mk (working copy) @@ -5,7 +5,15 @@ clean: rm -f LINT +.if ${TARGET} == "amd64" || ${TARGET} == "i386" + rm -f LINT=VIMAGE +.endif NOTES= ../../conf/NOTES NOTES LINT: ${NOTES} ../../conf/makeLINT.sed cat ${NOTES} | sed -E -n -f ../../conf/makeLINT.sed > ${.TARGET} +.if ${TARGET} == "amd64" || ${TARGET} == "i386" + echo "include ${.TARGET}" > ${.TARGET}-VIMAGE + echo "ident ${.TARGET}-VIMAGE" >> ${.TARGET}-VIMAGE + echo "options VIMAGE" >> ${.TARGET}-VIMAGE +.endif Index: sys/ia64/conf/Makefile =================================================================== --- sys/ia64/conf/Makefile (revision 198467) +++ sys/ia64/conf/Makefile (working copy) @@ -1,3 +1,5 @@ # $FreeBSD$ +TARGET=ia64 + .include "${.CURDIR}/../../conf/makeLINT.mk" Index: sys/sun4v/conf/Makefile =================================================================== --- sys/sun4v/conf/Makefile (revision 198467) +++ sys/sun4v/conf/Makefile (working copy) @@ -1,3 +1,5 @@ # $FreeBSD$ +TARGET=sun4v + .include "${.CURDIR}/../../conf/makeLINT.mk" Index: sys/pc98/conf/Makefile =================================================================== --- sys/pc98/conf/Makefile (revision 198467) +++ sys/pc98/conf/Makefile (working copy) @@ -1,3 +1,5 @@ # $FreeBSD$ +TARGET=pc98 + .include "${.CURDIR}/../../conf/makeLINT.mk" Index: sys/i386/conf/Makefile =================================================================== --- sys/i386/conf/Makefile (revision 198467) +++ sys/i386/conf/Makefile (working copy) @@ -1,3 +1,5 @@ # $FreeBSD$ +TARGET=i386 + .include "${.CURDIR}/../../conf/makeLINT.mk" Index: sys/amd64/conf/Makefile =================================================================== --- sys/amd64/conf/Makefile (revision 198467) +++ sys/amd64/conf/Makefile (working copy) @@ -1,3 +1,5 @@ # $FreeBSD$ +TARGET=amd64 + .include "${.CURDIR}/../../conf/makeLINT.mk" From bugmaster at FreeBSD.org Mon Oct 26 11:06:54 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Oct 26 11:07:29 2009 Subject: Current problem reports assigned to freebsd-arch@FreeBSD.org Message-ID: <200910261106.n9QB6sIu043689@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/120749 arch [request] Suggest upping the default kern.ps_arg_cache 1 problem total. From jhb at freebsd.org Mon Oct 26 15:45:17 2009 From: jhb at freebsd.org (John Baldwin) Date: Mon Oct 26 15:45:24 2009 Subject: src/Makefile, universe, LINT, VIMAGE, .. In-Reply-To: <20091025134226.Q91695@maildrop.int.zabbadoz.net> References: <20091025134226.Q91695@maildrop.int.zabbadoz.net> Message-ID: <200910260830.25168.jhb@freebsd.org> On Sunday 25 October 2009 9:56:59 am Bjoern A. Zeeb wrote: > Hi, > > since the advent of VIMAGE in FreeBSD HEAD we've had a way to compile > the network stack in multiple ways. Unfortunately LINT can always only > test one of the options. > > In addition I, for quite a while, had other combinations I tested like > nooptions INET6 > or > nooptions INET > nooptions INET6 > etc. > > > We need a solution to be able to test those things and make sure to not > break those combinations (atm at least VIMAGE). > > Unfortunately our build system and kernel configurations are not there > yet. I had been pondering whether to just commit a LINT-VIMAGE file > that would include LINT and just fail if that wasn't there but then > realized that this will not fix the real problem. Some archs do not > even have a LINT file, btw. > > The information attached to the diff will tell you more about what I > did. I am not yet convinced that the solution presented further > down is the right thing to do (and would do the right thing in all > cases though I tested the obvious ones). > > Thus I'd like to solicit feedback, comments, improved version, ..;) > > You can also fetch the diff temporary from: > http://people.freebsd.org/~bz/20091025-01-make-LINT-VIMAGE.diff > > Thanks, > /bz > > -- > Bjoern A. Zeeb It will not break if you know what you are doing. > > ! > ! In sys//conf/Makefile set TARGET to . That allows > ! sys/conf/makeLINT.mk to only do certain things for certain > ! architectures. > ! > ! Generate a second LINT configuration for i386 and amd64 in > ! sys/conf/makeLINT.mk, which includes LINT and sets options VIMAGE > ! so that we will have VIMAGE LINT builds[1]. > ! > ! To avoid hardcoding further kernel configuration names for > ! make universe, split the logic into two parts: > ! - 1st to build worlds and generate kernel configs like LINT. > ! - 2nd to build kernels for a given TARGET architecture correctly > ! finding all newly generated configs, not knowing anything about > ! LINT anymore. (*) > ! > ! (*) If you know better/cleaner/... ways to do this, let me know. > ! > ! Annotation: this also allows one to add more such kernel configs > ! like LINT-NOINET, LINT-NOINET6, .. that I have had for ages now > ! to generate and maintain in a single place. > ! > ! > ! Requested by: jhb [1] > ! Discussed with: jhb, rwatson [1] > ! Reviewed by: > ! MFC After: > ! > Index: Makefile > =================================================================== > --- Makefile (revision 198467) > +++ Makefile (working copy) > @@ -297,10 +297,6 @@ > rm -f ${FAILFILE} > .endif > .for target in ${TARGETS} > -KERNCONFS!= cd ${.CURDIR}/sys/${target}/conf && \ > - find [A-Z0-9]*[A-Z0-9] -type f -maxdepth 0 \ > - ! -name DEFAULTS ! -name LINT > -KERNCONFS:= ${KERNCONFS:S/^NOTES$/LINT/} > universe: universe_${target} > .ORDER: universe_prologue universe_${target} universe_epilogue > universe_${target}: > @@ -320,15 +316,7 @@ > (echo "${target} 'make LINT' failed," \ > "check _.${target}.makeLINT for details"| ${MAKEFAIL})) > .endif > -.for kernel in ${KERNCONFS} > - @(cd ${.CURDIR} && env __MAKE_CONF=/dev/null \ > - ${MAKE} ${JFLAG} buildkernel \ > - TARGET=${target} \ > - KERNCONF=${kernel} \ > - > _.${target}.${kernel} 2>&1 || \ > - (echo "${target} ${kernel} kernel failed," \ > - "check _.${target}.${kernel} for details"| ${MAKEFAIL})) > -.endfor > + cd ${.CURDIR} && ${MAKE} ${.MAKEFLAGS} TARGET=${target} universe_kernels > @echo ">> ${target} completed on `LC_ALL=C date`" > .endfor > universe: universe_epilogue > @@ -345,3 +333,18 @@ > fi > .endif > .endif > + > +universe_kernels: universe_kernels_foo > +TARGET?= ${BUILD_ARCH} > +KERNCONFS!= cd ${.CURDIR}/sys/${TARGET}/conf && \ > + find [A-Z0-9]*[A-Z0-9] -type f -maxdepth 0 \ > + ! -name DEFAULTS ! -name NOTES > +KERNCONFS:= ${KERNCONFS} > +universe_kernels_foo: > +.for kernel in ${KERNCONFS} > + @(cd ${.CURDIR} && env __MAKE_CONF=/dev/null \ > + ${MAKE} ${JFLAG} buildkernel TARGET=${TARGET} KERNCONF=${kernel} \ > + > _.${TARGET}.${kernel} 2>&1 || \ > + (echo "${TARGET} ${kernel} kernel failed," \ > + "check _.${TARGET}.${kernel} for details"| ${MAKEFAIL})) > +.endfor Hmm, I'm not sure why you need a universe_kernels_foo target that universe_kernels depends on? Also, I would probably prefer to have universe_kernels come after universe_$target and before universe_epilogue. > Index: sys/conf/makeLINT.mk > =================================================================== > --- sys/conf/makeLINT.mk (revision 198467) > +++ sys/conf/makeLINT.mk (working copy) > @@ -5,7 +5,15 @@ > > clean: > rm -f LINT > +.if ${TARGET} == "amd64" || ${TARGET} == "i386" > + rm -f LINT=VIMAGE > +.endif s/=/-/ BTW, I'm not sure why you would only enable VIMAGE for these two archs rather than doing it for all archs that have a LINT? -- John Baldwin From bzeeb-lists at lists.zabbadoz.net Mon Oct 26 19:25:04 2009 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Mon Oct 26 19:25:14 2009 Subject: src/Makefile, universe, LINT, VIMAGE, .. In-Reply-To: <200910260830.25168.jhb@freebsd.org> References: <20091025134226.Q91695@maildrop.int.zabbadoz.net> <200910260830.25168.jhb@freebsd.org> Message-ID: <20091026185459.U91695@maildrop.int.zabbadoz.net> On Mon, 26 Oct 2009, John Baldwin wrote: Hi, >> @@ -345,3 +333,18 @@ >> fi >> .endif >> .endif >> + >> +universe_kernels: universe_kernels_foo >> +TARGET?= ${BUILD_ARCH} >> +KERNCONFS!= cd ${.CURDIR}/sys/${TARGET}/conf && \ >> + find [A-Z0-9]*[A-Z0-9] -type f -maxdepth 0 \ >> + ! -name DEFAULTS ! -name NOTES >> +KERNCONFS:= ${KERNCONFS} >> +universe_kernels_foo: >> +.for kernel in ${KERNCONFS} >> + @(cd ${.CURDIR} && env __MAKE_CONF=/dev/null \ >> + ${MAKE} ${JFLAG} buildkernel TARGET=${TARGET} KERNCONF=${kernel} \ >> + > _.${TARGET}.${kernel} 2>&1 || \ >> + (echo "${TARGET} ${kernel} kernel failed," \ >> + "check _.${TARGET}.${kernel} for details"| ${MAKEFAIL})) >> +.endfor > > Hmm, I'm not sure why you need a universe_kernels_foo target that > universe_kernels depends on? This is all about make and the variables after a target and within a target. Whatever else I tried: make complained. If you know the rightbetter solution that works I'll be happy to simplify this and update the patch. It shouldn't be named _foo though;) > Also, I would probably prefer to have > universe_kernels come after universe_$target and before universe_epilogue. I think that should be possible to sneak it in after the the .endfor. >> Index: sys/conf/makeLINT.mk >> =================================================================== >> --- sys/conf/makeLINT.mk (revision 198467) >> +++ sys/conf/makeLINT.mk (working copy) >> @@ -5,7 +5,15 @@ >> >> clean: >> rm -f LINT >> +.if ${TARGET} == "amd64" || ${TARGET} == "i386" >> + rm -f LINT=VIMAGE >> +.endif > > s/=/-/ Yeah, everyone notics that one; it should be fixed in the patch at the URL originally referenced. > BTW, I'm not sure why you would only enable VIMAGE for these two archs rather > than doing it for all archs that have a LINT? Because it'll usually simply not make any sense to build a VIMAGE kernel for embedded platforms like arm, ... Also make universe time increases significantly with any platform; indeed amd64 is the worst now (again). We can talk about the proper set and I had thought of sparc64 as well. Obviously just building it everywhere simplifies things. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From gonzo at bluezbox.com Fri Oct 30 19:58:00 2009 From: gonzo at bluezbox.com (Oleksandr Tymoshenko) Date: Fri Oct 30 19:58:08 2009 Subject: LDFLAGS usage Message-ID: <4AEB3D63.4080608@bluezbox.com> Trying to build kld for MIPS I stumbled upon some controversy with LDFLAGS: Through all share/mk/bsd.*.mk files it is consistently used with CC, but in sys/conf/kmod.mk it's used directly with LD and in cobination with flags like -Wl,-foo it causes errors. So is usage of LDFLAGS in sys/conf/kmod.mk correct?