Re: Problem building -current kernel with read-only /usr/src.
hi, there! On Sat, 23 Dec 2000, Chris wrote: > Actually, last time I checked, I think stable did not install with a RO > /usr/src either. Anyone know if this is still the case? I have no problems with 'make installworld' with RO obj and src on latest -stable /fjoe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP Problem? (was: Repeatable Hang -current SMP and lpd)
By not running X, at the console, I was able to see this to be a Fatal Trap 12. I can cause the machine to become non-responsive to the keyboard by doing a 'make -j36 world', which normally takes 8 hours. Now, this hangs the machine between 2 and 7 hours. Breaking into ddb, only shows a normal console trace, scgetc() ... fork_trampoline(). df | lpr will produce a Fatal Trap 12. I posted the details to -smp. I built a UP kernel and it does not produce the 'Fatal Trap 12'. tomdean To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ACPI says: "too many dependant configs"(?)
Last night I installed a kernel with 'device acpica' for the 1st time, and all seems fine, except that I see this at boot: . . . npx0: on motherboard npx0: INT 16 interface too many dependant configs too many dependant configs too many dependant configs too many dependant configs atkbdc0: at port 0x60,0x64 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 . . . I traced this message to /usr/src/sys/dev/acpica/acpi_isa.c, function acpi_isa_set_start_dependant(). Now, I have not had any indication of errors during ISA bus enumeration before, so why should I get this from the ACPI isa bus enumeration? Doesn't seem to hurt anything, but I'm curious (and ACPI-ignorant) :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI says: "too many dependant configs"(?)
> Last night I installed a kernel with 'device acpica' for the 1st > time, and all seems fine, except that I see this at boot: ... > too many dependant configs ... > I traced this message to /usr/src/sys/dev/acpica/acpi_isa.c, function > acpi_isa_set_start_dependant(). > > Now, I have not had any indication of errors during ISA bus enumeration > before, so why should I get this from the ACPI isa bus enumeration? It just means that you have a device with more configuration options than our code can deal with; we just ignore the extra options. > Doesn't seem to hurt anything, but I'm curious (and ACPI-ignorant) :) This part is just like BIOS PnP. The warning indicates that we're losing possibly-useful information, but if things are still working, all is well. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI says: "too many dependant configs"(?)
Ok, thanks for the info... But this begs the question: Why does the code limit maxdeps to 8? On Sun, Dec 24, 2000 at 11:50:13AM -0800, Mike Smith wrote: > > Last night I installed a kernel with 'device acpica' for the 1st > > time, and all seems fine, except that I see this at boot: > ... > > too many dependant configs > ... > > I traced this message to /usr/src/sys/dev/acpica/acpi_isa.c, function > > acpi_isa_set_start_dependant(). > > > > Now, I have not had any indication of errors during ISA bus enumeration > > before, so why should I get this from the ACPI isa bus enumeration? > > It just means that you have a device with more configuration options than > our code can deal with; we just ignore the extra options. > > > Doesn't seem to hurt anything, but I'm curious (and ACPI-ignorant) :) > > This part is just like BIOS PnP. The warning indicates that we're losing > possibly-useful information, but if things are still working, all is well. > > -- > ... every activity meets with opposition, everyone who acts has his > rivals and unfortunately opponents also. But not because people want > to be opponents, rather because the tasks and relationships force > people to take different points of view. [Dr. Fritz Todt] >V I C T O R Y N O T V E N G E A N C E > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI says: "too many dependant configs"(?)
> Ok, thanks for the info... But this begs the question: Why does the > code limit maxdeps to 8? I'd guess that it seemed like a good number at the time. I mostly just duplicated the ISA code (which I'm not entirely a fan of, but it's a known evil). I'm sure that it'd be possible to come up with a better algorithm, but for the most part, this code seems to work just fine. > On Sun, Dec 24, 2000 at 11:50:13AM -0800, Mike Smith wrote: > > > Last night I installed a kernel with 'device acpica' for the 1st > > > time, and all seems fine, except that I see this at boot: > > ... > > > too many dependant configs > > ... > > > I traced this message to /usr/src/sys/dev/acpica/acpi_isa.c, function > > > acpi_isa_set_start_dependant(). > > > > > > Now, I have not had any indication of errors during ISA bus enumeration > > > before, so why should I get this from the ACPI isa bus enumeration? > > > > It just means that you have a device with more configuration options than > > our code can deal with; we just ignore the extra options. > > > > > Doesn't seem to hurt anything, but I'm curious (and ACPI-ignorant) :) > > > > This part is just like BIOS PnP. The warning indicates that we're losing > > possibly-useful information, but if things are still working, all is well. > > > > -- > > ... every activity meets with opposition, everyone who acts has his > > rivals and unfortunately opponents also. But not because people want > > to be opponents, rather because the tasks and relationships force > > people to take different points of view. [Dr. Fritz Todt] > >V I C T O R Y N O T V E N G E A N C E > > > > > > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problem building -current kernel with read-only /usr/src.
:On Sat, Dec 23, 2000 at 11:24:50AM -0800, Matt Dillon wrote:
:
:I will fix it today.
Works like a charm now, thanks! My -current source is broken out on
my -stable machine, so the only way to compile it is via an NFS mount
to a -current machine which, for obvious reasons, needs to be read-only.
In regards to your commit message backing out the change. I kinda liked
the change (if it could be made to work). What about modifying 'make'
itself to provide a MAKEOBJDIRBASE environment variable in addition
to the MAKEOBJDIRPREFIX environment variable? Kinda messy, but I think
it would work.
What you would do is generate a MAKEOBJDIRBASE environment by running
`pwd` inside /usr/src/sys/compile/BLAH. The make program would adjust
it's use of MAKEOBJDIRPREFIX:
1. ${MAKEOBJDIRPREFIX}/`pwd`
By taking MAKEOBJDIRBASE into account. Specifically, it would take the
`pwd` that *it* runs and it would chop of MAKEOBJDIRBASE, leaving us
with:
${MAKEOBJDIRPREFIX}/(`pwd` with MAKEOBJDIRBASE chopped off at the head)
I believe this would produce the correct path. But it does require
modifying the 'make' program.
The only other alternative is to generate an appropriate MAKEOBJDIR
variable for each module directory. That might require ripping up too
much stuff though.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ACPI says: "too many dependant configs"(?)
Since we are on the subject of ACPI, it is working great except for one thing, it can't attach my sound card to the pcm device (does that sound correct?). It definitely sees it: unknown: can't assign resources Looks like the yamaha chipset to me. If I could get sound working, I'd definitely be using acpica all the time. I think the thermal management has been improved since the last time I tried it -- it kept the temp < 356K. Is there any way to set a temperature to be maintained? Or some way to actually query the current temperature? (lmmon doesnt work) -- _ __ ___ ___ ___ ___ Wesley N Morgan _ __ ___ | _ ) __| \ [EMAIL PROTECTED] _ __ | _ \._ \ |) | FreeBSD: The Power To Serve _ |___/___/___/ 6bone: 3ffe:1ce3:7::b4ff:fe53:c297 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
