Re: xorg pci probing
On 15.01.11 22:26, Christoph Egger wrote:
>
> Hi!
>
> I have a machine with two PCI graphic cards:
> 1x Radeon HD 4200
> 1x Radeon HD 5600
>
> Starting X fails with the error message
> "Primary device is not PCI"
>
> Per discussion with macallen@ I implemented
> pci_device_is_boot_vga() in libpciaccess
> which uses a new ioctl().
>
> Attached are three patches:
>
> xorg_ioctl.diff which implements the new ioctl
> xorg.diffwhich enable the use of pci_device_is_boot_vga()
> xsrc.diffwhich implements pci_device_is_boot_vga()
>
>
> The three patches let me start X on said machine
> and I also successfully tested them where X also
> starts w/o these patches.
I updated my patches based on comments I got from different people.
I'm resending them for review again.
>
> Any comments?
Christoph
Index: sys/dev/pci/chipsfb.c
===
RCS file: /cvsroot/src/sys/dev/pci/chipsfb.c,v
retrieving revision 1.24
diff -u -p -r1.24 chipsfb.c
--- sys/dev/pci/chipsfb.c 23 Dec 2010 21:11:37 - 1.24
+++ sys/dev/pci/chipsfb.c 17 Jan 2011 10:42:39 -
@@ -55,6 +55,7 @@ __KERNEL_RCSID(0, "$NetBSD: chipsfb.c,v
#include
#include
#include
+#include
#include
@@ -850,6 +851,10 @@ chipsfb_ioctl(void *v, void *vs, u_long
return pci_devioctl(sc->sc_pc, sc->sc_pcitag,
cmd, data, flag, l);
+ case WSDISPLAYIO_GET_BUSID:
+ return wsdisplayio_busid_pci(&sc->sc_dev, sc->sc_pc,
+ sc->sc_pcitag, data);
+
case WSDISPLAYIO_SMODE: {
int new_mode = *(int*)data;
if (new_mode != sc->sc_mode) {
Index: sys/dev/pci/genfb_pci.c
===
RCS file: /cvsroot/src/sys/dev/pci/genfb_pci.c,v
retrieving revision 1.26
diff -u -p -r1.26 genfb_pci.c
--- sys/dev/pci/genfb_pci.c 16 Dec 2010 06:45:50 - 1.26
+++ sys/dev/pci/genfb_pci.c 17 Jan 2011 10:42:39 -
@@ -46,6 +46,7 @@ __KERNEL_RCSID(0, "$NetBSD: genfb_pci.c,
#include
#include
+#include
#include
@@ -197,6 +198,11 @@ pci_genfb_ioctl(void *v, void *vs, u_lon
case PCI_IOC_CFGWRITE:
return pci_devioctl(sc->sc_pc, sc->sc_pcitag,
cmd, data, flag, l);
+
+ case WSDISPLAYIO_GET_BUSID:
+ return wsdisplayio_busid_pci(sc->sc_gen.sc_dev, sc->sc_pc,
+ sc->sc_pcitag, data);
+
case WSDISPLAYIO_SMODE: {
int new_mode = *(int*)data, i;
if (new_mode == WSDISPLAYIO_MODE_EMUL) {
Index: sys/dev/pci/machfb.c
===
RCS file: /cvsroot/src/sys/dev/pci/machfb.c,v
retrieving revision 1.62
diff -u -p -r1.62 machfb.c
--- sys/dev/pci/machfb.c16 Dec 2010 06:45:50 - 1.62
+++ sys/dev/pci/machfb.c17 Jan 2011 10:42:39 -
@@ -65,6 +65,7 @@ __KERNEL_RCSID(0,
#include
#include
#include
+#include
#include
@@ -1709,7 +1710,11 @@ mach64_ioctl(void *v, void *vs, u_long c
case PCI_IOC_CFGWRITE:
return pci_devioctl(sc->sc_pc, sc->sc_pcitag,
cmd, data, flag, l);
-
+
+ case WSDISPLAYIO_GET_BUSID:
+ return wsdisplayio_busid_pci(sc->sc_dev, sc->sc_pc,
+ sc->sc_pcitag, data);
+
case WSDISPLAYIO_SMODE: {
int new_mode = *(int*)data;
if (new_mode != sc->sc_mode) {
@@ -2007,6 +2012,11 @@ machfb_fbioctl(dev_t dev, u_long cmd, vo
#endif
return ret;
}
+
+ case WSDISPLAYIO_GET_BUSID:
+ return wsdisplayio_busid_pci(sc->sc_dev, sc->sc_pc,
+ sc->sc_pcitag, data);
+
default:
#ifdef MACHFB_DEBUG
log(LOG_NOTICE, "machfb_fbioctl(0x%lx) (%s[%d])\n", cmd,
Index: sys/dev/pci/pm2fb.c
===
RCS file: /cvsroot/src/sys/dev/pci/pm2fb.c,v
retrieving revision 1.6
diff -u -p -r1.6 pm2fb.c
--- sys/dev/pci/pm2fb.c 16 Dec 2010 06:45:50 - 1.6
+++ sys/dev/pci/pm2fb.c 17 Jan 2011 10:42:39 -
@@ -54,6 +54,7 @@ __KERNEL_RCSID(0, "$NetBSD: pm2fb.c,v 1.
#include
#include
#include
+#include
#include
@@ -317,6 +318,10 @@ pm2fb_ioctl(void *v, void *vs, u_long cm
return pci_devioctl(sc->sc_pc, sc->sc_pcitag,
cmd, data, flag, l);
+ case WSDISPLAYIO_GET_BUSID:
+ return wsdisplayio_busid_pci(sc->sc_dev, sc->sc_pc,
+ sc->sc_pcitag, data);
+
case WSDISPLAYIO_GINFO:
if (ms == NULL)
return ENODEV;
Index: sys/dev/pci/r128fb.c
===
RCS file: /cvsroot/src/sys/dev/pci/r128fb.c,v
retrieving revision 1.19
diff -u -p -r1.19 r128fb.c
--- sys/dev/pci/r128fb.c6 Jan 20
Re: prop_*_internalize and copyin/out for syscall ?
On Mon, Jan 17, 2011 at 04:33:25PM +0100, Manuel Bouyer wrote:
> so I'm evaluating how to use proplib for the new quotactl(2) I'm working on.
er, why? When I was looking at quota stuff in the context of lfs and
other fs types, the existing quotactl interface seemed fine -- it just
needs to have a clear separation between the syscall-level structures
and the ffs-specific ones.
At worst one might want to split struct dqblk in half, so the block
and inode limits are addressed separately, something like this:
struct quotaentry {
uint64_t qe_hardlimit;
uint64_t qe_softlimit;
uint64_t qe_current;
int32_t qe_time;
int32_t __qe_spare;
};
with additional suitable constants for addressing block vs. inode
limits.
I really don't see where proplib figures into this.
--
David A. Holland
dholl...@netbsd.org
Re: xorg pci probing
On Tue, Jan 18, 2011 at 09:47:29AM +0100, Christoph Egger wrote: > In /var/log/X.org both Radeon devices are enlisted but none has been > selected as the primary one. X then quits with the message > "Primary device is not PCI" I still don't understand what this means, and why it doesn't choose one of them arbitrarily. If you edit your config file to select a primary one, it would work? If you select the other one as primary, would it still work? > Per discussion with macallen@ I implemented pci_device_is_boot_vga() > and that works. Can you please explain why the OS console device is relevant here? You said it is not about initialization - I don't quite get it. > > What happens if you boot your machine with a serial console (assuming for > > the sake of argument it would have a serial port)? > > That machine is a laptop and has no serial console. Yes, but the same situation could happen on a desktop. Assume I would have such a machine and boot it with serial console. According to your logic (as far as I understood it so far), I wouldn't be able to use X. That sucks and would clearly be a serious regression. I'm sure I'm missing something, so please give more details. Martin
re: xorg pci probing
i like this look of this much better than prior patches. thanks for doing this properly. i just have one minor suggestion. i don't see the point in the two new files with one function proto and a 5 line function. can you please move them into wsdisplay.c and wsdisplayvar.h? thanks. .mrg.
Re: xorg pci probing
On 16.01.11 11:44, Martin Husemann wrote: > On Sat, Jan 15, 2011 at 10:26:13PM +0100, Christoph Egger wrote: >> >> Hi! >> >> I have a machine with two PCI graphic cards: >> 1x Radeon HD 4200 >> 1x Radeon HD 5600 >> >> Starting X fails with the error message >> "Primary device is not PCI" >> >> Per discussion with macallen@ I implemented >> pci_device_is_boot_vga() in libpciaccess >> which uses a new ioctl(). > > Can you please explain what X is trying to tell you with that message > and how "this is the vga device used as console by the os" is related to > the answer? I wonder if the question more should be "this vga device > has been initialized by the firmware already", and maybe your patch only > happens to work on your machine by luck. According to pcictl dump the firmware enables the Radeon HD4200 but not the Radeon HD5600. While X is probing the pci devices the driver enables all pci vga devices. That is why checking for the 'firmware enabled' one fails. When a second pci vga device is found the pci probing code is not able to decide which one to use. In /var/log/X.org both Radeon devices are enlisted but none has been selected as the primary one. X then quits with the message "Primary device is not PCI" Per discussion with macallen@ I implemented pci_device_is_boot_vga() and that works. > What happens if you boot your machine with a serial console (assuming for > the sake of argument it would have a serial port)? That machine is a laptop and has no serial console. Christoph
Re: xorg pci probing
> i like this look of this much better than prior patches. thanks > for doing this properly. > > i just have one minor suggestion. i don't see the point in the > two new files with one function proto and a 5 line function. can > you please move them into wsdisplay.c and wsdisplayvar.h? thanks. The reason is that the new function adds dependencies to the different busses. Currently only for PCI. But other busses may be added in future. Moving that function into wsdisplay.c will add bus dependencies to wsdisplay.c. Christoph
Re: xorg pci probing
On Tue, Jan 18, 2011 at 11:39:35AM +0100, Christoph Egger wrote: > The function pci_device_is_boot_vga() is supposed to return > 'true' for the pci vga device the firmware uses which is not > neccessarily the OS console device (it can be a serial console). Ok. But your function answers "this is the vga device where wsdisplay0 attached" instead - is that a safe bet, especially in case you boot with a serial console? I still completely fail to see why X would like to know this detail and what a wrong answer would mean. If it's just a wrong default display but fixable via config file, it's fine. > > Yes, but the same situation could happen on a desktop. Assume I would > > have such a machine and boot it with serial console. According to your > > logic (as far as I understood it so far), I wouldn't be able to use X. > > Right. The error message "Primary device is not PCI" comes from This is unacceptable. I have a amd64 machine with serial console that I use to run X, luckily it has only a single vga card right now. Martin
Re: Bi-arch 64-bit/32-bit bug in *chflags(2) on NetBSD / standardizing *chflags(2)?
On Mon, Jan 17, 2011 at 11:16 PM, matthew green wrote: > >> Hello NetBSD folks, >> I just ran into this issue today (variable length unsigned long >> used in chflags syscalls) on FreeBSD and I wasn't sure if anyone was >> aware of the issue yet on NetBSD [1] . Just wanted to let you guys >> know so that maybe the 3 major BSDs could get on the same page as far >> as definitions go to reduce external developer pain in other projects >> like Python [2], etc (I chose to standardize on fflags_t for clarity >> as it already appeared to have been standardized to some degree in the >> FreeBSD sourcebase, but that appears to be a FreeBSD-specific >> typedef). >> Please let me know if I need to redirect this message to an alternate >> list. ... > garrett. > > > this is the right list, and thanks for the report. > > however, i'm pretty sure we don't have this bug. all our *chflags() > pass unsigned long, and our "netbsd32" compat has always converted > the flags from 64 bit to 32 bit long. deeper layers seem to convert > to uint32_t at some point but this seems to be for on-disk format. > > > i'm not sure i see much point of fflags_t at this point -- it would > have to be typedef of "unsigned long" and would thus need _LP64 > #ifdef or platform specific #define's, which seems uglier than leaving > it as unsigned long, though i'm not 100% wedded to this idea. > > what do others think? Hi Matthew, Something someone reminded me of on the freebsd-fs list: what about mixed archs or non-BE archs like ARM or MIPS :)? Thanks, -Garrett
Re: xorg pci probing
> On Tue, Jan 18, 2011 at 11:39:35AM +0100, Christoph Egger wrote: > > The function pci_device_is_boot_vga() is supposed to return > > 'true' for the pci vga device the firmware uses which is not > > neccessarily the OS console device (it can be a serial console). > > Ok. But your function answers "this is the vga device where wsdisplay0 > attached" instead - is that a safe bet, especially in case you boot with > a serial console? According to macallan@ ttyE* is the first graphic device, ttyF* the second, ttyG* the third, etc. So yes, it is safe. > I still completely fail to see why X would like to know this detail and > what a wrong answer would mean. If it's just a wrong default display > but fixable via config file, it's fine. The pci probing happens before the config file comes into play. That's why the config file has no effect. > > > Yes, but the same situation could happen on a desktop. Assume I would > > > have such a machine and boot it with serial console. According to your > > > logic (as far as I understood it so far), I wouldn't be able to use X. > > > > Right. The error message "Primary device is not PCI" comes from > > This is unacceptable. I have a amd64 machine with serial console that I > use to run X, luckily it has only a single vga card right now. Me too which is an other laptop. Christoph
Re: prop_*_internalize and copyin/out for syscall ?
On Tue, Jan 18, 2011 at 08:42:36AM +, David Holland wrote:
> On Mon, Jan 17, 2011 at 04:33:25PM +0100, Manuel Bouyer wrote:
> > so I'm evaluating how to use proplib for the new quotactl(2) I'm working
> on.
>
> er, why? When I was looking at quota stuff in the context of lfs and
> other fs types, the existing quotactl interface seemed fine -- it just
> needs to have a clear separation between the syscall-level structures
> and the ffs-specific ones.
>
> At worst one might want to split struct dqblk in half, so the block
> and inode limits are addressed separately, something like this:
>
>struct quotaentry {
> uint64_t qe_hardlimit;
> uint64_t qe_softlimit;
> uint64_t qe_current;
> int32_t qe_time;
> int32_t __qe_spare;
>};
>
> with additional suitable constants for addressing block vs. inode
> limits.
>
> I really don't see where proplib figures into this.
The current interface has 32bit integers for all sizes. For modern storage
size we need it to be 64bits.
My new system also adds more features:
- a default quota entry, used for [ug]id which don't have a quota entry yet.
This allows to have a global limit for all users, without setting up
quotas for all possible id in the system.
Using a magic id number for the default entry doesn't work unless we go
to 64bits for ids too.
- a per-id grace time so that different users can have different grace
time.
- a way to delete a quota entry for a id (e.g. for deleted users)
this is a new command.
A major deficiency of the actual interface is that it doesn't allows to
pass a list of quota entries. I need this for repquota, as there's no
user-accessible quota file any more.
Also, I need to pass a whole quota setup as a configuration file
for e.g. newfs (and mount_mfs, it's the same code). For this, a proplist
looks appropriate, and I can't see any reason to not use the same
format for the kernel/userland interface.
Also, if another filesystem needs a different quota interface in the future,
we just need a different proplist format, no need for a new sysctl.
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Re: xorg pci probing
One nit:
+wsdisplayio_busid_pci(device_t self, pci_chipset_tag_t pc,
+pcitag_t tag, void *data)
+{
+ struct wsdisplayio_bus_id *busid = data;
+
+ busid->bus_type = WSDISPLAYIO_BUS_PCI;
+ busid->ubus.pci.domain = device_unit(device_parent(self));
Please add a KASSERT here, as this doesn't do the right thing in all
cases, consider the following:
mymfdev0 at pci1 dev 3 function 0
mymfdevfb0 at mymfdev0
wsdisplay0 at mymfdevfb0
^ will get a 'domain' of 0 instead of the desired 1
The KASSERT should look like this:
KASSERT(device_is_a(device_parent(self), "pci"))
Re: xorg pci probing
> On Tue, Jan 18, 2011 at 09:47:29AM +0100, Christoph Egger wrote: > > In /var/log/X.org both Radeon devices are enlisted but none > > has been selected as the primary one. X then quits with the > > message "Primary device is not PCI" > > I still don't understand what this means, and why it doesn't > choose one of them arbitrarily. The function xf86PciProbe() in external/mit/xorg-server/dist/hw/xfree86/common/xf86pciBus.c has two methods to find the primary one. The first requires was never used on NetBSD due to lack of pci_device_is_boot_vga() and the second method doesn't choose one arbitrarily per implementation. > If you edit your config file to select a primary one, it would > work? No. > If you select the other one as primary, would it still work? No. If the config file worked then there would be no reason to develop the patches. > > Per discussion with macallen@ I implemented pci_device_is_boot_vga() > > and that works. > > Can you please explain why the OS console device is relevant > here? You said it is not about initialization - I don't quite > get it. The function pci_device_is_boot_vga() is supposed to return 'true' for the pci vga device the firmware uses which is not neccessarily the OS console device (it can be a serial console). > > > What happens if you boot your machine with a serial console (assuming > for > > > the sake of argument it would have a serial port)? > > > > That machine is a laptop and has no serial console. > > Yes, but the same situation could happen on a desktop. Assume I would > have such a machine and boot it with serial console. According to your > logic (as far as I understood it so far), I wouldn't be able to use X. Right. The error message "Primary device is not PCI" comes from external/mit/xorg-server/dist/hw/xfree86/common/xf86pciBus.c function xf86PciMatchDriver(). Christoph
Re: xorg pci probing
On Tue, Jan 18, 2011 at 12:19:50PM +0100, Christoph Egger wrote: > According to macallan@ ttyE* is the first graphic device, > ttyF* the second, ttyG* the third, etc. Yes, counting in NetBSD autoconfig probe order. > So yes, it is safe. Depends on the exact question, which has been explained out of band to me (thanks Jared!), and "wrong" answer is non fatal, as well as there will be a meaningfull (but kind of arbitrary) answer in the serial console case. So everything is fine, nothing to see here - carry on! Martin
Re: xorg pci probing
> One nit:
>
> +wsdisplayio_busid_pci(device_t self, pci_chipset_tag_t pc,
> +pcitag_t tag, void *data)
> +{
> + struct wsdisplayio_bus_id *busid = data;
> +
> + busid->bus_type = WSDISPLAYIO_BUS_PCI;
> + busid->ubus.pci.domain = device_unit(device_parent(self));
>
> Please add a KASSERT here, as this doesn't do the right thing in all
> cases, consider the following:
>
>mymfdev0 at pci1 dev 3 function 0
>mymfdevfb0 at mymfdev0
>wsdisplay0 at mymfdevfb0
>
> ^ will get a 'domain' of 0 instead of the desired 1
>
> The KASSERT should look like this:
>
>KASSERT(device_is_a(device_parent(self), "pci"))
Done in my local tree. Thanks for it.
Christoph
Re: xorg pci probing
> > So everything is fine, nothing to see here - carry on! Ok thanks. I am waiting for "green light" to commit. Christoph
Re: Dates in boot loaders on !x86
On Tue, Jan 18, 2011 at 01:39:31AM -0500, der Mouse wrote: > >> True. What I use the timestamp for (when I use it at all, that is) > >> is answering "is the bootloader (or whatever) I'm getting the one I > >> just built and think I installed, or did something go wrong?". The > >> difference between ten minutes old and two weeks old is important; > >> the difference between two weeks old and six months old is not. > > BTW, the kernel version is still included, so at least on -current > > you can normally detect the case of "pretty recent" and "a few month > > old" from that as well. > > Except that tells me whether the kernel being booted is recent, not > whether the bootloader doing the booting is. No. It is the version in src/sys/sys/param.h. It doesn't have any relation to the kernel you are running or booting. The point is that it is a non-changing, human readable identifier of the source tree that hopefully changes often enough to be able to tell two versions apart. > However, based on the discussion, it sounds as though this is not an > issue: it appears the datestamps are still there unless turned off (as > anyone wanting bit-for-bit-repeatable builds presumably will), meaning > the issue I raised simply does not exist. That depends. Some platforms dropped them completely. It is much simpler to consistently drop it. Joerg
Re: Dates in boot loaders on !x86
> That depends. Some platforms dropped them completely. It is much simpler > to consistently drop it. Indeed. I'd like to know if there is any particular case that date strings in bootloader helped users tracking problem, or annoying examples on x86 bootloaders without date strings. I think it's enough to bump a version number on possible functional changes. Fewer changes on boot than kernels. --- Izumi Tsutsui
Re: xorg pci probing
>>> pci_device_is_boot_vga() >> [...] > While X is probing the pci devices the driver enables all pci vga > devices. That is why checking for the 'firmware enabled' one fails. But checking for "the" firmware-enabled one is a broken idea. There may fewer or more than one such, for one thing - nothing says the firmware has to initialize any displays; nothing says it has to initialize no more than one. And it's a check X shouldn't be doing anyway. Doing bus enumeration in userland is insane; that's what we've got kernels for. X should be using the device - or devices - it's told to use; if not told anything about what device to use, it should be picking a sensible default, like the console (not necessarily boot) device, without caring about others. I can, sort of, see doing direct access to the display as a PCI device (_of course_ every display will be a PCI device!), but in no circumstance can I see any excuse for poking at devices it isn't going to use or walking all of any bus. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: Dates in boot loaders on !x86
>> Except that tells me whether the kernel being booted is recent, not >> whether the bootloader doing the booting is. > No. It is the version in src/sys/sys/param.h. It doesn't have any > relation to the kernel you are running or booting. Oh, that kernel version! That it is of no use for my purposes. > The point is that it is a non-changing, human readable identifier of > the source tree that hopefully changes often enough to be able to > tell two versions apart. I care about bootloader timestamps when I'm hacking bootloader code and want to be able to tell the difference between still running the previous booter or the one I built just a few minutes ago - even if "the previous booter" is the one I built thirty minutes ago in the same bootloader-hacking run. Being able to tell the 6.0 bootloader from the 5.2 bootloader, while perhaps important, is not what I'm talking about here. I don't do this often, but when I do there's not much substitute. >> However, based on the discussion, it sounds as though this is not an >> issue: [...] > That depends. Some platforms dropped them completely. That sucks. Well, if portmasters don't mind screwing over people trying to actually hack on their ports' code, I guess it's their call. > It is much simpler to consistently drop it. Simpler? Certainly. My point is, it is a regression, a signficant one for me at least. If you don't mind crippling people trying to work on the bootloader, be my guest. (If I had occasion to work on such a bootloader, one of the first things I'd do would be to add something functionally equivalent back, even if just a manually-changed-when-I-care "hi, I'm not the previous version" printf.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: xorg pci probing
On Tue, Jan 18, 2011 at 3:27 PM, der Mouse wrote: pci_device_is_boot_vga() >>> [...] >> While X is probing the pci devices the driver enables all pci vga >> devices. That is why checking for the 'firmware enabled' one fails. > > But checking for "the" firmware-enabled one is a broken idea. There > may fewer or more than one such, for one thing - nothing says the > firmware has to initialize any displays; nothing says it has to > initialize no more than one. > > And it's a check X shouldn't be doing anyway. Doing bus enumeration in > userland is insane; that's what we've got kernels for. X should be > using the device - or devices - it's told to use; if not told anything > about what device to use, it should be picking a sensible default, like > the console (not necessarily boot) device, without caring about others. > I can, sort of, see doing direct access to the display as a PCI device > (_of course_ every display will be a PCI device!), but in no > circumstance can I see any excuse for poking at devices it isn't going > to use or walking all of any bus. Your patches to fix all issues above are welcome please free to submit them. -- Regards. Adam
Re: Dates in boot loaders on !x86
On 1/18/11 2:40 PM, der Mouse wrote: The point is that it is a non-changing, human readable identifier of the source tree that hopefully changes often enough to be able to tell two versions apart. I care about bootloader timestamps when I'm hacking bootloader code Uh, yes, of course. How many people hack bootloader code on a daily basis? How many people will benefit from repeatable builds on a daily basis? If that's the only use case, having an option to enable timestamps is enough: enable it *while you are hacking* but leave it off for the benefit of the rest of the world.
Re: Dates in boot loaders on !x86
On Tue, Jan 18, 2011 at 03:03:24PM +, Julio Merino wrote: > If that's the only use case, having an option to enable timestamps is > enough: enable it *while you are hacking* but leave it off for the > benefit of the rest of the world. Yes, that was all we asked for: leave a switch in place, disable it for all standard builds. Martin
Re: Dates in boot loaders on !x86
On 1/18/11 3:09 PM, Martin Husemann wrote: On Tue, Jan 18, 2011 at 03:03:24PM +, Julio Merino wrote: If that's the only use case, having an option to enable timestamps is enough: enable it *while you are hacking* but leave it off for the benefit of the rest of the world. Yes, that was all we asked for: leave a switch in place, disable it for all standard builds. Ah; sorry for the noise then! (Had noticed that in another part of the thread but the previous message made me think the argument applied to the "default setting".)
Re: xorg pci probing
To summarize what goes on: on x86 archs (and AFAICT for NetBSD only there) the X starup code enumerates all pci buses the kernel found, searching for vga devices. If multiple are found, it prefers the one that the new function marks. That's basically all about it. If the new function says "no" to all devices, we have the same state as right now. This, however, will not happen, even with serial console, as the function realy only finds the first wsdisplay device's parent vga. On sane ports we do not enumerate via /dev/pci, but straight open ttyE0 (i.e. the first display, the same that the new function will mark) or ttyF0 etc for multiple servers, and are there right away. I would prefer to drop the stupid enumeration code on x86 too, but I'm definitively not goint to touch that code myself - so no right to complain. Martin
Re: Dates in boot loaders on !x86
On Tue, Jan 18, 2011 at 04:09:27PM +0100, Martin Husemann wrote: > On Tue, Jan 18, 2011 at 03:03:24PM +, Julio Merino wrote: > > If that's the only use case, having an option to enable timestamps is > > enough: enable it *while you are hacking* but leave it off for the > > benefit of the rest of the world. > > Yes, that was all we asked for: leave a switch in place, disable it for > all standard builds. Well, we derive the version to include from the version file. This is controlled by a central script. What about adding support to expand $DATE$ or some other magic version string, if it is the last in the version file? If you are actively developing, you can add that to the version file and hopefully remember to replace it with a proper version entry before commit. Joerg
Re: Dates in boot loaders on !x86
On 01/18/11 16:03, Julio Merino wrote: On 1/18/11 2:40 PM, der Mouse wrote: The point is that it is a non-changing, human readable identifier of the source tree that hopefully changes often enough to be able to tell two versions apart. I care about bootloader timestamps when I'm hacking bootloader code Uh, yes, of course. How many people hack bootloader code on a daily basis? How many people will benefit from repeatable builds on a daily basis? If that's the only use case, having an option to enable timestamps is enough: enable it *while you are hacking* but leave it off for the benefit of the rest of the world. Just a curious question here. What problem are we trying to solve? What is the benefit for the rest of the world to not have the information? Just being curious... Johnny
Re: Dates in boot loaders on !x86
On Tue, Jan 18, 2011 at 3:40 PM, der Mouse wrote: >>> Except that tells me whether the kernel being booted is recent, not >>> whether the bootloader doing the booting is. >> No. It is the version in src/sys/sys/param.h. It doesn't have any >> relation to the kernel you are running or booting. > > Oh, that kernel version! That it is of no use for my purposes. Then why are you talking in this thread you don't even use -current and you are not going to do that anytime soon. -- Regards. Adam
Re: Dates in boot loaders on !x86
> Just a curious question here. What problem are we trying to solve? > What is the benefit for the rest of the world to not have the information? > Just being curious... We would like to have reproducable builds which means that if you will run build on top of same src/ you resulting /obj dirs should be same with same .o files. -- Regards. Adam
Re: Dates in boot loaders on !x86
On 01/18/11 16:58, haad wrote: Just a curious question here. What problem are we trying to solve? What is the benefit for the rest of the world to not have the information? Just being curious... We would like to have reproducable builds which means that if you will run build on top of same src/ you resulting /obj dirs should be same with same .o files. Ok. And that is good because...? Johnny
Re: Dates in boot loaders on !x86
On Tue, Jan 18, 2011 at 5:02 PM, Johnny Billquist wrote: > On 01/18/11 16:58, haad wrote: >>> >>> Just a curious question here. What problem are we trying to solve? >>> What is the benefit for the rest of the world to not have the >>> information? >>> Just being curious... >> >> We would like to have reproducable builds which means that if you will >> run >> build on top of same src/ you resulting /obj dirs should be same with same >> .o >> files. > > Ok. And that is good because...? You can see what parts of system are affected by your one line commit, which can't really affect anything else then ... -- Regards. Adam
Re: Dates in boot loaders on !x86
On Tue, Jan 18, 2011 at 05:02:13PM +0100, Johnny Billquist wrote: > Ok. And that is good because...? Various, the most prominent benefits: - you can easily do binary patches - you can verify code you touched that should have no effect realy did not have any effect - you can verify toolchain changes did not cause unexpected changes Martin
Re: xorg pci probing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Jan 18, 2011, at 10:22 AM, Martin Husemann wrote: To summarize what goes on: on x86 archs (and AFAICT for NetBSD only there) the X starup code enumerates all pci buses the kernel found, searching for vga devices. If multiple are found, it prefers the one that the new function marks. That's basically all about it. Yes, the idea ( I think... ) is to make sure screen :0 is what the user would expect. As it is now that's not necessarily the case. If the new function says "no" to all devices, we have the same state as right now. This, however, will not happen, even with serial console, as the function realy only finds the first wsdisplay device's parent vga. Well, I think we can safely assume that people would expect wsdisplay0 as :0. On sane ports we do not enumerate via /dev/pci, but straight open ttyE0 (i.e. the first display, the same that the new function will mark) or ttyF0 etc for multiple servers, and are there right away. Actually we do the pci enumeration dance everywhere now, so X can use all graphics devices. I would prefer something /dev/fb*-ish too but that would require a lot of rototilling - we'd have to attach a dev entry to all graphics devices even those we don't have a kernel driver for. I would prefer to drop the stupid enumeration code on x86 too, but I'm definitively not goint to touch that code myself - so no right to complain. Exactly. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBTTW/Y8pnzkX8Yg2nAQLClAf+OnLlZcftIUshCsI51371QGm2krgLMxPe Io6giFbAN22yR0KpIyD2My3u8gxjPBkMBMwjhKohP1iPn2nC8j8a8k23B2E2H4jn MLyYW6J9DEy1flYaduhrXIVhq1f3muv7IgzHvnwU9zIr4D6anatDbW6TGCctCKD+ o2AsboFcrI/iEJY8Abvp6QeqOuhxBrnA0Q8IN99ax9dpnhh6LWnGlmex+1h4P67S j/issTXoM8A5/uPS1ulLhZQ05v1bYeJde7hPIh3KnINPB3m1EYUPHv0u3zfQkdwU JYuWN5Dizmc7E5Kf9Pmj3C+yLCeYMKUfZrbTbXybdBVRjll0RsntlA== =ShPU -END PGP SIGNATURE-
Weird sprious input
I've rewritten the console driver for the VAX some, in my effort to support all the console ports of a VAX-86x0. One of those ports is the EMM (Environment Monitoring Module), which both report problems, and can respond to queries. After adding this one, I seem to have hit upon some weird error in the tty driver. So I thought I'd ask here if anyone knows what situation or circumstances might cause this, if anyone have seen this before, and any suggestions on what to do. I really do not feel like starting to hunt and debug the whole terminal subsystem. The scenario is like this: I've added interrupt counters to rx and tx for the VAX. I've extended the console driver to access several different ports, selected by the minor number of the device. In the machine, all ports work through the same registers and interrupt vectors. The receive register is 32 bits. 8 bits is the data byte, and another 4 bits is the actual source of the data. I've written a small user-mode program that opens the device that map to the EMM, and I send one byte out on that port. That byte is a request for status of the EMM. The EMM should respond to this with a total of 34 bytes. The interrupt counter matches this. I do get 34 interrupts after sending the byte out. However, in the user program, I sometimes get 34 bytes, but sometimes I get more than 34 bytes. The exact number is somewhat random, but range from about 44 to 56 bytes. The additional bytes do not have any corresponding interrupts which caused them, so I have no idea where they come from. Looking at the data I get back, I can identify which bytes actually comes from the EMM, and which bytes have been inserted into the stream by some weird entity. The place in this sequence of 34 bytes where the spurious bytes are inserted is random, but seems to happen in the latter half of the expected 34 bytes. The values of these random bytes sometimes looks like they follow some pattern, but I have had totally strange values returned as well. Adding an aprint_normal inside the interrupt handler, to just show what values are received, and from where, seem to affect the system enough that I don't get the random bytes. That would suggest some timing issue. The actual data expected is binary, and not human readable text. The randomly added data is also binary junk, and not something readable. An example is this: Good: 01 20 b5 00 b6 01 b6 02 49 83 49 84 bd 85 bc Bad: 7f e4 eb ff 7f 49 54 7d 7f 58 03 01 00 b6 00 00 00 2e 04 Good: 86 00 07 9e 08 af 89 c7 0a db 8b 1f 8c 2c 8d 26 8e 27 8f (All received exactly like this, the bad bytes in the middle.) As the EMM is another small computer, the response back over the serial line might be high. I don't know at what speeds the actual communication takes place. But it's not like a human sitting at a normal asynch port and typing away. Anyone seen anything like this before? Or have any good ideas on how to debug this? Johnny
Re: xorg pci probing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Jan 18, 2011, at 6:19 AM, Christoph Egger wrote: On Tue, Jan 18, 2011 at 11:39:35AM +0100, Christoph Egger wrote: The function pci_device_is_boot_vga() is supposed to return 'true' for the pci vga device the firmware uses which is not neccessarily the OS console device (it can be a serial console). Ok. But your function answers "this is the vga device where wsdisplay0 attached" instead - is that a safe bet, especially in case you boot with a serial console? According to macallan@ ttyE* is the first graphic device, ttyF* the second, ttyG* the third, etc. So yes, it is safe. I wouldn't call it 'safe' but 'safe enough'. Most ports will try to make sure wsdisplay0 is the firmware console but if the console is a serial line there may or may not be a wsdisplay0. On the other hand, what X tries to do here, as far as I can tell, is to make sure :0 is where the user expects it which would still be wsdisplay0 even in the serial console case. I still completely fail to see why X would like to know this detail and what a wrong answer would mean. If it's just a wrong default display but fixable via config file, it's fine. The pci probing happens before the config file comes into play. That's why the config file has no effect. I would call that a bug in X though - it should be able to use arbitrary PCI devices if there's a driver that can use them, console or not, initialized or not ( some drivers can cold boot their hardware after all ) Yes, but the same situation could happen on a desktop. Assume I would have such a machine and boot it with serial console. According to your logic (as far as I understood it so far), I wouldn't be able to use X. Right. The error message "Primary device is not PCI" comes from This is unacceptable. I have a amd64 machine with serial console that I use to run X, luckily it has only a single vga card right now. Me too which is an other laptop. I think the "Primary device is not PCI" error is bogus but that's a different story. If X wants to whine about it that's fine but it shouldn't be fatal. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBTTXBdMpnzkX8Yg2nAQLQ4Af/VKgX8BCcDeMxaTawJvXtflCztSYg6uEk Oerw5E7HYdKdvLoZaNLJrc7M1eSL+iwH6TZfa+aTjDd6SFkd9oaTV/UcLunbL7LH 0q6byk6dhllqNQ3zyP/qgpuW3Iep+XAWVwqm5o4OwlHFkNNPMyhzjQbDXa26itsx e4nARKAwvdQm09AqA9Hn8xcG1ydO7M/fEV0/3aYkmHEz15m7IEZkCIGmcjghd11V orcnivokD2D+OfYqZpml+D7v4oKz5aK93o9pq+Rh2Dj9tfmG2c/589EwexPrW+AC Y2XKjMp/VT0anDCvhOS3toGYpm9oCXSxe5Klv/NEQQzPzkXgps/XGA== =O1js -END PGP SIGNATURE-
Re: xorg pci probing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
+ case WSDISPLAYIO_GET_BUSID: {
+ struct wsdisplayio_bus_pci pci;
+ struct wsdisplayio_bus_id *bus = data;
+ pci.pci_pc = sc->sc_pc;
+ pci.pci_tag = sc->sc_pcitag;
+ bus->bus_type = WSDISPLAYIO_BUS_PCI;
+ return wsdisplayio_busid(&sc->sc_dev, bus, &pci);
+ }
This looks overly complicated and is repeated all over the place.
Something like this should be sufficient:
case WSDISPLAYIO_GET_BUSID:
return wsdisplayio_pci_busid(sc->sc_dev, sc->sc_pc, sc->sc_tag, data);
also, I'd keep the sbus and pci cases separate, there is no need
whatsoever to cram them in the same function - all you get with that
is a bunch of mostly unnecessary dependancies.
( ok, the sbus case is academic right now but still )
Finally, accessing data may need copyin()/copyout().
Something completely different - you added voyagerfb to i386's ALL
config a while ago as part of your 'all vga' rototill. First, the
SM502 is not a VGA, it doesn't even pretend to be one. Second, there
is no chance to encounter this device in an x86 box, according to the
docs it supports ARM, MIPS and SuperH CPUs ( yes, it's a little bit
more than just a graphics device )
If you want to add all VGAs you forgot igsfb which is VGA-compatible
and does exist as PCI cards for PCs.
have fun
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
iQEVAwUBTTXFy8pnzkX8Yg2nAQKwdAgAq9OXgsTiTQr4xEK+bkbLJuRqFvjM4+Vq
zYEDMda9lu70qAhUqDv93iJugMQtU3li0UHgj+5SDiuZ/86LVBOpRe3/EHSWpd9R
9fsCpel9opl7g7JMokw74vIU1zy+9sGAUyrFtXe1lO5u9ORNgbWBZYGEF0Ojh4d/
EFY94XdjvwV0MHdZxjda1IDBEt2qK8XK4Pu6EOkIK2F4wwOJaat5zveuE50stvPh
/ZWPozR5a+cqvzexc0/9+LIor/SpLipRN4x3MO6u2+ZXF5x7Kf3LlFmm1L70I+Pp
/LPL62EGXhZenpQW70kTenhojirBdyPAq1xspBfszYNm92IcxoLxjQ==
=0won
-END PGP SIGNATURE-
Re: Bi-arch 64-bit/32-bit bug in *chflags(2) on NetBSD / standardizing *chflags(2)?
On Tue, Jan 18, 2011 at 03:03:35AM -0800, Garrett Cooper wrote: > > > > i'm not sure i see much point of fflags_t at this point -- it would > > have to be typedef of "unsigned long" and would thus need _LP64 > > #ifdef or platform specific #define's, which seems uglier than leaving > > it as unsigned long, though i'm not 100% wedded to this idea. > > > > what do others think? > > Hi Matthew, > Something someone reminded me of on the freebsd-fs list: what > about mixed archs or non-BE archs like ARM or MIPS :)? > Thanks, > -Garrett All our 64 bit archs pass the first two [1] arguments in registers. So there is no ABI difference on them if the u_long is replaced with a 32bit type. [1] actually is is at least 3, otherwise ioctl() couldn't work. David -- David Laight: da...@l8s.co.uk
Re: xorg pci probing
On Tue, Jan 18, 2011 at 11:22:33AM +0100, Christoph Egger wrote: > > > i like this look of this much better than prior patches. thanks > > for doing this properly. > > > > i just have one minor suggestion. i don't see the point in the > > two new files with one function proto and a 5 line function. can > > you please move them into wsdisplay.c and wsdisplayvar.h? thanks. > > The reason is that the new function adds dependencies to the > different busses. Currently only for PCI. But other busses > may be added in future. > > Moving that function into wsdisplay.c will add bus dependencies > to wsdisplay.c. I think I agree with Christoph here: if he avoids sprinkling wsdisplay.c with bus-related #ifdefs by adding new files, he should definitely do that. Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: xorg pci probing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Jan 18, 2011, at 2:17 PM, David Young wrote: On Tue, Jan 18, 2011 at 11:22:33AM +0100, Christoph Egger wrote: i like this look of this much better than prior patches. thanks for doing this properly. i just have one minor suggestion. i don't see the point in the two new files with one function proto and a 5 line function. can you please move them into wsdisplay.c and wsdisplayvar.h? thanks. The reason is that the new function adds dependencies to the different busses. Currently only for PCI. But other busses may be added in future. Moving that function into wsdisplay.c will add bus dependencies to wsdisplay.c. I think I agree with Christoph here: if he avoids sprinkling wsdisplay.c with bus-related #ifdefs by adding new files, he should definitely do that. I suggested to put them in a separate file for just that reason so drivers that need them can pull them in without #ifdef orgies all over the place. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBTTXrAspnzkX8Yg2nAQJ6CQf/UMlyWwqV5Wp7ND6A+JgxXMG2QZlDyQhP rKuvm1m8apwbrm3m5NRjU+U4qN/PCcfjxkfxAT7ThTReQNueh9SbRMWmIY8QcQu3 3pKD4r2RrHT00GxaiBSe14OfhXgod5WbmC/+XM7aJPBFvp9noHBEmSKA8AXzq3AY it+As9y4poBup1nNurvodLR2jvGomuWHtXOhD2UH1voUqQ6LSwyINnurU76bHl++ 4ChDLs86ub9WO5VUY0mrs9ZosWyEecV9y+lUUnz5gKs80mIMvPvU9NGifKrScmOF mxktvJ4K/rjlTAtX0mWZ44/iO8WRW7t9rqt6rcHO8zBvYhsqB0MXfg== =uhvM -END PGP SIGNATURE-
Re: Dates in boot loaders on !x86
On Tue, Jan 18, 2011 at 04:24:37PM +0100, Joerg Sonnenberger wrote: > Well, we derive the version to include from the version file. This is > controlled by a central script. What about adding support to expand > $DATE$ or some other magic version string, if it is the last in the > version file? If you are actively developing, you can add that to the > version file and hopefully remember to replace it with a proper version > entry before commit. That's unnecessarily complicated. There's prior art for this: NetBSD tanaqui 5.99.41 NetBSD 5.99.41 (TANAQUI) #32: Wed Dec 1 01:20:02 EST 2010 dholland@tanaqui:/usr/src/sys/arch/i386/compile/TANAQUI i386 ^^^ Wouldn't be very hard to do the same for bootloaders. -- David A. Holland dholl...@netbsd.org
Re: Dates in boot loaders on !x86
On Tue, Jan 18, 2011 at 08:17:38PM +, David Holland wrote: > On Tue, Jan 18, 2011 at 04:24:37PM +0100, Joerg Sonnenberger wrote: > > Well, we derive the version to include from the version file. This is > > controlled by a central script. What about adding support to expand > > $DATE$ or some other magic version string, if it is the last in the > > version file? If you are actively developing, you can add that to the > > version file and hopefully remember to replace it with a proper version > > entry before commit. > > That's unnecessarily complicated. There's prior art for this: > > NetBSD tanaqui 5.99.41 NetBSD 5.99.41 (TANAQUI) #32: Wed Dec 1 01:20:02 EST > 2010 dholland@tanaqui:/usr/src/sys/arch/i386/compile/TANAQUI i386 Please look at the mail that started this threat. newvers provides multiple independent variable, so conditionally providing one of them needs both an option and output mangling in the users. The consensus seems to be that during normal usage, the build date is irrelevant and doesn't provide any value. Based on Martin's suggestion, I will add a MKVERBOSEBOOT variable or so (haven't made my mind up about the name). If it is set, bootprog_kernrev will include the build date as well as user and host name (like the current bootprog_maker). The current bootprog_maker and bootprog_kernrev go away. Joerg
Re: prop_*_internalize and copyin/out for syscall ?
On Jan,Monday 17 2011, at 6:00 PM, Manuel Bouyer wrote:
> On Mon, Jan 17, 2011 at 04:33:25PM +0100, Manuel Bouyer wrote:
>> [sorry for the cross-post, but I can't decide which list is more appropriate
>> than the other :) ]
>>
>> Hello,
>> so I'm evaluating how to use proplib for the new quotactl(2) I'm working on.
>> I see there is already provision of function to pass property list between
>> kernel and userland using ioctl, but there is no equivalent for syscalls.
>> Should there be ?
>> For kernel land, prop_{array,dictionary}_copy{in,out} would do it
>> (prop_{array,dictionary}_copyout is documented but not implemented,
>> this is easy).
>> For userland, we probably need a prop_{array,dictionary}_recv_syscall(),
>> wich takes as parameter the pref we got from kernel, and internalize it.
>> Parameters would be the pref, and a pointer to the prop_array_t or
>> prop_dictionary_t that will get the result. What this would do in
>> addition to call prop_{array,dictionary}_internalize_from_pref() is
>> to unmap the buffer the kernel mmaped for us. I don't think this details of
>> the
>> kernel/userland communication should be exposed outside of the
>> proplib code.
>>
>> For symetry, we probably want a prop_{array,dictionary}_send_syscall()
>> which is just an alias to prop_{array,dictionary}_externalize_to_pref()
>>
>> Comments ?
>
> here is a diff implementing the above
>
> --
> Manuel Bouyer
> NetBSD: 26 ans d'experience feront toujours la difference
> --
>
I think this patch looks fine. You should commit it.
Regards
Adam.
re: xorg pci probing
> On Tue, Jan 18, 2011 at 11:22:33AM +0100, Christoph Egger wrote: > > > > > i like this look of this much better than prior patches. thanks > > > for doing this properly. > > > > > > i just have one minor suggestion. i don't see the point in the > > > two new files with one function proto and a 5 line function. can > > > you please move them into wsdisplay.c and wsdisplayvar.h? thanks. > > > > The reason is that the new function adds dependencies to the > > different busses. Currently only for PCI. But other busses > > may be added in future. > > > > Moving that function into wsdisplay.c will add bus dependencies > > to wsdisplay.c. > > I think I agree with Christoph here: if he avoids sprinkling wsdisplay.c > with bus-related #ifdefs by adding new files, he should definitely do > that. that's a good idea. since it's PCI specific, perhaps sys/dev/pci/wsdisplay_pci.c is a better place? .mrg.
Re: Dates in boot loaders on !x86
On Tue, Jan 18, 2011 at 09:39:58PM +0100, Joerg Sonnenberger wrote: > > That's unnecessarily complicated. There's prior art for this: > > [...] > > Please look at the mail that started this threat. newvers provides > multiple independent variable, so conditionally providing one of them > needs both an option and output mangling in the users. It doesn't need an option, because on a clean build it would always be 0 (or 1) -- if you start hacking, then it would increment itself. Assuming you don't cleandir. (And I didn't say to reuse the kernel's newvers script itself. All this needs is about five lines of sh...) > The consensus seems to be that during normal usage, the build date is > irrelevant and doesn't provide any value. Based on Martin's suggestion, > I will add a MKVERBOSEBOOT variable or so (haven't made my mind up about > the name). If it is set, bootprog_kernrev will include the build date as > well as user and host name (like the current bootprog_maker). The > current bootprog_maker and bootprog_kernrev go away. But anyway, that seems fine. Is it going to be extended to the x86 bootloader? -- David A. Holland dholl...@netbsd.org
Re: Dates in boot loaders on !x86
On Tue, Jan 18, 2011 at 09:41:49PM +, David Holland wrote: > On Tue, Jan 18, 2011 at 09:39:58PM +0100, Joerg Sonnenberger wrote: > > > That's unnecessarily complicated. There's prior art for this: > > > [...] > > > > Please look at the mail that started this threat. newvers provides > > multiple independent variable, so conditionally providing one of them > > needs both an option and output mangling in the users. > > It doesn't need an option, because on a clean build it would always be > 0 (or 1) -- if you start hacking, then it would increment > itself. Assuming you don't cleandir. > > (And I didn't say to reuse the kernel's newvers script itself. All this > needs is about five lines of sh...) It would also increment if something else changed, so the the result of an incremental build after cvs up would be different from a fresh build. > > The consensus seems to be that during normal usage, the build date is > > irrelevant and doesn't provide any value. Based on Martin's suggestion, > > I will add a MKVERBOSEBOOT variable or so (haven't made my mind up about > > the name). If it is set, bootprog_kernrev will include the build date as > > well as user and host name (like the current bootprog_maker). The > > current bootprog_maker and bootprog_kernrev go away. > > But anyway, that seems fine. Is it going to be extended to the x86 > bootloader? Yes, x86 is using bootprog_kernrev. Joerg
Re: xorg pci probing
On Wed, Jan 19, 2011 at 08:18:40AM +1100, matthew green wrote: > David Young wrote: > > On Tue, Jan 18, 2011 at 11:22:33AM +0100, Christoph Egger wrote: > > > Moving that function into wsdisplay.c will add bus dependencies > > > to wsdisplay.c. > > > > I think I agree with Christoph here: if he avoids sprinkling wsdisplay.c > > with bus-related #ifdefs by adding new files, he should definitely do > > that. > > that's a good idea. > > since it's PCI specific, perhaps sys/dev/pci/wsdisplay_pci.c is > a better place? Sounds good. Christoph, what do you think? Dave -- David Young OJC Technologies dyo...@ojctech.com Urbana, IL * (217) 278-3933
Re: xorg pci probing
On 19.01.11 00:09, David Young wrote: > On Wed, Jan 19, 2011 at 08:18:40AM +1100, matthew green wrote: >> David Young wrote: >>> On Tue, Jan 18, 2011 at 11:22:33AM +0100, Christoph Egger wrote: Moving that function into wsdisplay.c will add bus dependencies to wsdisplay.c. >>> >>> I think I agree with Christoph here: if he avoids sprinkling wsdisplay.c >>> with bus-related #ifdefs by adding new files, he should definitely do >>> that. >> >> that's a good idea. >> >> since it's PCI specific, perhaps sys/dev/pci/wsdisplay_pci.c is >> a better place? > > Sounds good. Christoph, what do you think? The scheme sys/dev//wsdisplay_.[ch] where is pci, sbus, etc. is fine with me. Christoph
Re: xorg pci probing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Jan 18, 2011, at 3:31 AM, Christoph Egger wrote: On 15.01.11 22:26, Christoph Egger wrote: Hi! I have a machine with two PCI graphic cards: 1x Radeon HD 4200 1x Radeon HD 5600 Starting X fails with the error message "Primary device is not PCI" Per discussion with macallen@ I implemented pci_device_is_boot_vga() in libpciaccess which uses a new ioctl(). Attached are three patches: xorg_ioctl.diff which implements the new ioctl xorg.diffwhich enable the use of pci_device_is_boot_vga() xsrc.diffwhich implements pci_device_is_boot_vga() The three patches let me start X on said machine and I also successfully tested them where X also starts w/o these patches. I updated my patches based on comments I got from different people. I'm resending them for review again. Jared suggested a KASSERT to make sure the device_t passed to wsdisplayio_busid_pci() is actually a PCI bus child. Otherwise it looks good to me. have fun Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQEVAwUBTTZGKcpnzkX8Yg2nAQLVxQf9HQs0KsJFoFTQjiIT/A48hsrde0JzEpdZ nPfedA44G7QPRyLESRYUX7UP3O6RaPi7f82S03SUaQgbo8sKFeFtrXBopzPJsTQo FM2FgX78MWxnI0MjrAUYKe4+4KZIXXvMrapAC2hU314YZnD5TKkKc/u5/mex68ew gUxnE1EEh4D35+UffzyR046dqRFTveNzJFCY/xOwkMe8BRSSDVK/cS01N0RB764q IMAIlfOO2WGcAKoE0bol1vc0TnY8KpCh929OJf5rD+w6ohcGVVMKCz6oXJMWRoLn YKni0PiDj8tmaGk28mgGH2TOSwqYa99bkyaGZRutL0G2li2Bo0vrMg== =SZ+d -END PGP SIGNATURE-
Re: kernel memory allocators
On Sun, Jan 16, 2011 at 03:35:17PM +0100, Lars Heidieker wrote: > I have got the kmem reworked to be based on the pool allocator > directly with different sized caches, backed by the kmem map making > it's allocations interrupt save, I replaced the malloc with just a > thin wrapper to use the reworked kmem system is up and stable. What are the benefits that you expect to see from doing this work? Have you measured to see if those benefits are realized? Do you have your changes available for review? -allen -- Allen Briggs - bri...@ninthwonder.com
