It's not the BIOS failing it...
The BTX bootstrap loader V 1.00 detects the keyboard, and refuses to proceed
without it.
The BTX loader does not detect or care about the keyboard at all.
You have another problem, and you need to supply more details before we
can be of any more assistance.
lecturing
David about testing his changes before committing. Not every bug can
be found before committing, which is why we have a little thing called
-CURRENT.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
to figure out which of X
variables was the problem.
Mike Silby Silbersack
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
acceptable to me. After all, if
there's no /dev, the system looks like it's in trouble. (If this does not
make sense, reference above paragraph.)
Mike Silby Silbersack
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
not interested in being bitched out over something as trivial as this
when I have so much on my plate already; if you can't contribute, do me
the least favour and save me the angst.
Thanks.
Mike
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also
implementing fair sharing soon?
Mike Silby Silbersack
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
I'm trying to upgrade -current on one of our machines. This box is a Compaq
Presario 900 Mhz Athlon. It errors on the NIC. I can't disable PnP in the
bios, that feature doesn't exist in the compaq bios. I have tried several
NIC's and pci slots with the same results.
Also, I tried both
Should the below work ?
ifconfig_xl0=DHCP media 100baseTX mediaopt full-duplex
I don't think so. Try using the start_if script stuff to pre-set your
media options before DHCP gets hold of the interface; I'm pretty sure
that'll work.
--
... every activity meets with opposition, everyone
in to trigger such a huge amount of interrupts. I guess this would
depend on how efficient your application is, how you set the limits, etc.
Mike Silby Silbersack
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
On Sat, 13 Oct 2001, Terry Lambert wrote:
Mike Silbersack wrote:
One issue to be careful of here is that the removal of the
tcptmpl actually causes a performance hit that wasn't there
in the 4.3 code. My original complaint about tcptmpl taking
up 256 instead of 60 bytes stands, but I'm
aren't.
Mike Silby Silbersack
--- if_dc.c.origThu Oct 11 01:39:05 2001
+++ if_dc.c Thu Oct 11 01:39:30 2001
@@ -193,8 +193,8 @@
static int dc_coal __P((struct dc_softc *, struct mbuf **));
static void dc_pnic_rx_bug_war __P((struct dc_softc *, int));
static int
+this patch test of some sort with varying loads to
see the effect, maybe we could characterize the effect of the patch more.
With my setup, I don't think I can really take this testing any further.
Mike Silby Silbersack
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current
* Kenneth D. Merry [EMAIL PROTECTED] [011009 00:11] wrote:
As you say above, this is actually a good thing. I don't see how this ties
into the patch to introduce some sort of interrupt coalescing into the
ti(4) driver. IMO, you should be able to tweak the coalescing parameters
on
fraction of the userbase (and I suspect that uucp fits
into that catagory) should be removed from the core distribution,
and made into a seperate package; provided that obtaining the
package and integrating it into FreeBSD is not too onerous.
--
Mike Bristow, seebitwopie
To Unsubscribe: send mail
I am trying to install -CURRENT on ThinkPad 770ED with a limited success
so far. I noticed that when the kernel boots on this notebook, it
complains about PCI BIOS entry call point not being available. The
following is a boot -v output from my kernel file(see below for further
comments):
This just isn't going to work. The _CRS data stream stops at byte 0x17,
and these extra items are simply mis-aimed.
The 0x19 should really be 0x11, and the 0x1c should really be 0x14, ie.
this is a BIOS bug, and should be reported to the vendor. (It should
also have failed the Microsoft
yes, with acpi timer disabled this seems to have gone away
Nope, even with the change Mike mentioned, I still get:
microuptime() went backwards (50013.3990440 - 50012.321555)
microuptime() went backwards (50013.3990440 - 50012.406351)
This looks really bad; like time is actually
: APM and ACPI are mutually exclusive from what I understand. You should
: remove the apm device from your kernel config.
I've been able to run both with my VAIO. However, my VAIO hangs
randomly with ACPI enabled (even when i have apm disable).
You shouldn't be able to do this. 8)
To
to your patch).
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
-current as of the last day or so- anyone else seen?
Sep 30 20:47:15 quarm ntpd[239]: kernel time discipline status change 2041
microuptime() went backwards (939.4410978 - 938.949317)
Try turning off the ACPI timer:
debug.acpi.disable=timer
in loader.conf and see if it goes away. I'm
Cool. Yes. Will do. It also turns out that even with this being an SMP system
with IOAPIC that ACPI still shares an irq with isp0. How odd.
This is probably an artifact of the PCI interrupt swizzle; the ACPI
irq is typically an interrupt line out of the southbridge (where the power
I only found this out today when my Dell inspiron7500
refused to boot past the ACPI message..
Surprised me a bit as Mike has one of these.
There's a well-documented and necessary hack to work on these
machines; the actual nature of the problem still escapes me (debugging
it is very time
I only found this out today when my Dell inspiron7500
refused to boot past the ACPI message..
Surprised me a bit as Mike has one of these.
There's a well-documented and necessary hack to work on these
machines; the actual nature of the problem still escapes me (debugging
/../../../../contrib/cvs/contrib/rcs2log.sh
rcs2log
cp:No such file or directory
*** Error code 1
The problem was a timing issue related to the kernel. Building a new
kernel before installing your world should fix it. This is an Alpha
only issue.
Best regards,
Mike Barcroft
To Unsubscribe: send mail
night's cvsup. But still.
The problem was solved for me and the other person experiencing the
problem about a week ago. JHB speculated that the problem's
disappearence was the result of a commit from dfr to pmap.c.
[See thread 'cp in INSTALLTMP?' posted to -current on Sept 9.]
Best regards,
Mike
/lukemftpd/ for
instructions for connecting it to the build.
Mike
--
Mike Heffner mheffner@[acm.]vt.edu
Blacksburg, VA [EMAIL PROTECTED]
PGP signature
In message [EMAIL PROTECTED] Mike Smith writes:
: Nope, no debug options, but I am getting loads of
: microuptime() went backwards (29804.3839847 - 29804.925730)
:
: ALi chipset? Try turning off the ACPI timer if you haven't already;
:
: set debug.acpi.disable=timer
and both loaded the acpi moduse from /boot/kernel/acpi.ko. I thought
that the loader was supposed to be clever enough to find these
things. I suppose it could be the acpi loader, the loader or me
which is broked.
The way the loader finds the ACPI module is unsophisticated and needs to
be
Nope, no debug options, but I am getting loads of
microuptime() went backwards (29804.3839847 - 29804.925730)
ALi chipset? Try turning off the ACPI timer if you haven't already;
set debug.acpi.disable=timer
at the loader prompt. If this works, please let me know (with ACPI in the
It seems that, on Fri, Sep 14, 2001 at 03:18:47PM -0700,
in message [EMAIL PROTECTED], Mike Smith wrote:
Nope, no debug options, but I am getting loads of
microuptime() went backwards (29804.3839847 - 29804.925730)
ALi chipset? Try turning off the ACPI timer if you haven't
FYI -- this has happened on my laptop (Toshiba Tecra 8000) ever since the
ACPI was first introduced (months and months ago)
What has happened, specifically? If you disable the timer, as Geoff did,
does it still happen?
Details, details.
On Fri, 14 Sep 2001, Mike Smith wrote
Marcel Moolenaar [EMAIL PROTECTED] writes:
On Wed, Sep 12, 2001 at 09:55:31PM -0400, Mike Barcroft wrote:
I'm seeing the following error building a kernel on my Alpha. The
sources are updated as of a few minutes ago.
I had the same problem. Try using a different CVSup server.
I had
[Moved to -hubs, BCC'd to -current]
John Polstra [EMAIL PROTECTED] writes:
In article [EMAIL PROTECTED],
Mike Barcroft [EMAIL PROTECTED] wrote:
It appears this was the problem. Switching to cvsup2.FreeBSD.org
seems to have have solved it. I assume this is a result of the S1G
bug
I'm seeing the following error building a kernel on my Alpha. The
sources are updated as of a few minutes ago.
[Output of 'make kernel KERNCONF=GENERIC NO_MODULES=true']
--
Kernel build for GENERIC started on Wed Sep 12 21:31:24 EDT
Why does the boot loader automatically load acpi.ko at boot time, even
though I have no loader.conf, and do not have device acpica in my
kernel? The ACPI driver causes the clock to run at double rate, so I
there is absolutely no way I will run it on this machine if I can help
it.
Because
,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Since you posted this message to -current, I just assumed you
had upgraded to the latest code, and thus were using ACPI (this
is the same thing that ended up confusing Mike Smith, who also
made the mistake in correcting me to say that ACPI was being
loaded twice on your system).
Actually, I
I suppose I could volunteer for this. I've been dissecting the loader for
months now and hitting the 4th fence has been bothersome.. As far as
braving those pesky naysayers, I thought about doing it on my own anyway so
if no one wants the change, I'll just keep it for my own systems. =)
Apparently debug.acpi.avoid doesn't avoid the timer problem anyhow,
and the earlier panic appears to have been too early (but was fixed;
thanks Mike). I'm going to ignore the bogus clock some and try to track
things down as Mike suggested in private mail.
That should be debug.acpi.disable
can't reproduce this problem locally. Is there any special
about your local configuration, particularly regarding PAM?
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
I've just updated the ACPI CA components to the latest Intel release.
You can read the release notes on Intel's website
(http://developer.intel.com/technology/iapc/acpi).
In addition, I've changed the default ACPI initialisation to the full,
recommended-by-the-standard set of passes over the
Outstanding issues:
- The ACPI timecounter does not work on some ALi chipsets.
- ACPI mode results in some PCI devices not being configured
by the BIOS.
Any chance this will fix the problem with sound (pcm) that I
mailed you about earlier?
I don't think so; I'm fairly sure
K6-2-450, bus running at 95mhz, Acer 1541 (A? B?)
All works fine with the new ACPI _except_ the clock; the time of day
advances about twice as fast as it should, and I get LOTS of
calcru negative time and time went backwards messages.
We've seen this before; the Acer Aladdin X clocks are
Show us a suitable LISP interpreter, then.
$ cd ~/lang/Scheme/tinyscm-1.27
$ size scheme
textdata bss dec hex filename
6134244763480 69298 10eb2 scheme
Is that statically-linked? I'm curious to know the size of the bootloader
forth footprint.
);
rid = i;
res = bus_alloc_resource(dev, SYS_RES_IRQ, rid, 0, ~0, 1, 0);
}
Mike, do you have any idea on this?
I'm not sure exactly what to do here. These resources contain information
we need to know about where we cannot put PnP devices. But if we feed the
information
to:
make world
make kernel
mergemaster
reboot
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
I myself questioned the wisdom of using Forth at the time, and Jordan
simply replied I was free to find a more popular language with a freely
available interpreter that would fit in as small a space as FICL did.
Just for the record; I spent a lot of time interviewing small script
unknown: PNP0400 can't assign resources
unknown: PNP0400 at port 0x378-0x37f on isa0
unknown: PNP0501 can't assign resources
unknown: PNP0501 at port 0x3f8-0x3ff on isa0
unknown: PNP0501 can't assign resources
unknown: PNP0501 at port 0x2f8-0x2ff on isa0
unknown: PNP0f13 can't
to be a common theme here. 8(
Can you tell us whether the xl driver is forced to power the chip up before
probing? I suspect that we are going to have to make some more PCI-related
changes to get these devices correctly configured, since the BIOS is not
doing it for us.
Regards,
Mike
To Unsubscribe: send
On 04-Sep-2001 Giorgos Keramidas wrote:
|
| The following patch seems to have fixed the bug for me.
|
Yea, Kris said he was going to fix it. This must be some undefined behavior
because I tested the change in a test program and the two sizeofs were giving
me the same result..strange ;)
Mike
I assume that the real problem is that the ATA controller failed to attach;
can you verify that this is the case?
Bingo. Without ACPI, the machine boots. With ACPI, no ATA.
I don't see an ATA probe in here anywhere. I assume you have the ata
driver being probed with hints? Can you mail
Then, shouldn't we remove the PnP BIOS driver (pnpbios) from the
kernel and make it a module, so that the boot loader will load either
the ACPI module or the PnP BIOS module?
Yes, we probably should.
I'd like to see the boot-conf code learn how to deal with foo_load
variables set in the
I'm getting this with the recent ACPI code, should I worry about it?
acpi_cpu0: CPU on acpi0
acpi_cpu: CLK_VAL field overflows P_CNT register
acpi_cpu: CLK_VAL field overlaps THT_EN bit
You shouldn't worry about it, no. I need to get my hands on some more
details so that I can understand
ACPI breaks my Libretto with (typed by hand):
Mounting root from ufs/dev/ad0s2a
I hope that's ufs:/dev/ad0s2a.
setrootbyname failed
I assume that the real problem is that the ATA controller failed to attach;
can you verify that this is the case?
To Unsubscribe: send mail to [EMAIL
The latest sources (yesterday) failed with the following:
This looks like a successful boot to me. Do you want to be more specific?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
)strlcpy(f-f_un.f_fname, p + sizeof(_PATH_DEV - 1),
^^^
+ sizeof(f-f_un.f_fname));
} else {
Mike
--
Mike Heffner mheffner@[acm.]vt.edu
Blacksburg, VA [EMAIL PROTECTED
On 04-Sep-2001 Mike Heffner wrote:
|
| On 03-Sep-2001 [EMAIL PROTECTED] wrote:
|| Between last weekend and this weekend, something changed in syslogd
|| seems to have resulted in this boot-time error. The syslogd.c deltas
|| from 1.82 - 1.83 look suspect since the handling of relevant
Hi, I've noticed that the recent CURRENT got panic on some machines
if we have `device acpica' in kernel config.
You've loaded the ACPI module as well as compiling it into the kernel.
Don't do that.
I hope more proper fixes would be made...
Peter has suggested that properly versioning the
I have a question, does /dev/mem wrap lgoically back to address once
it's reached the end of physical memory?
Er, no, I wouldn't have thought so.
110779f460 7c 7c 52 53 44 20 50 54 52 20 2e 54 62 56 7c 2e |||RSD PTR .TbV
|.|
Should this be far enough along for you to get
I would have waited for the re-run of hexdump to finish, but checking right a
fter I sent the last message produced:
00369400 52 53 44 20 50 54 52 20 00 54 62 56 61 6c 69 64 |RSD PTR .TbValid
You did say that what you are looking for would be left-aligned, could it be
the bit at
My motherboard is a Tyan S1696-DLUA dual P2-333. I am using the latest known
bios updates. ACPI is enabled, and APM disabled in
the BIOS. This happens regardless if PnP is on or off in the BIOS.
[dmesg | grep -i acpi]
ACPI debug layer 0x0 debug level 0x0
tbxface-0170: *** Error:
| Most systems with soft power will perform a hard powerdown if you hold
| down the power button for a sufficiently long period of time (10 - 20
| seconds).
Correct ... and unfortunately it's done in hardware so you can trap it :-(
In some applications you want to make it really hard for
- I pushed the power button, and my system shut down cleanly!
Yes. ACPI brings some useful new features. 8)
FSVO ``useful''. It's a real PITA to have to physically unplug the
machine when the kernel is wedged rather than have the power button
turn off the power. (The machine
Hi,
a few things to note:
- Loading the new kernel acpi.ko with the old loader freezes the loader.
- Loading acpi.ko by hand with the new loader freezes or endless-loops the lo
ader.
I've no idea what's going on here; I used a Tecra 8000 for much of my
testing, and never saw this. 8(
-
On 30-Aug-2001 Alexander N. Kabaev wrote:
| Freshly cvsuped kernel fails to build trying to find acpi_isa.c file, which
| does not exist anymore.
The following patch I sent to Mike allows the kernel to build.
Index: modules/acpica/Makefile
On 30-Aug-2001 Alexander N. Kabaev wrote:
| Freshly cvsuped kernel fails to build trying to find acpi_isa.c file, which
| does not exist anymore.
The following patch I sent to Mike allows the kernel to build.
The files omission has been fixed; the 'acpica' module has moved to
become
of capability.h.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
I am ready to do my megga-commit to add the first stage of KSE-threading
support to the kernel. If there is any argument as to the wisdom of this
move, then this is the time to speak up!
At this stage a commit would break alpha and ia64 until
they are patched. From experience I can say
-FDX, 100baseTX, 100baseTX-FDX, auto
Thank you *VERY* much for fixing this problem.
---Mike
At 01:43 PM 8/26/01 -0400, Mike Tancsa wrote:
I have it on two machines with this chipset and it looks good so
far. After installing, dmesg shows
fxp0: Intel Pro/100 Ethernet port 0xc400-0xc43f
At 10:52 PM 8/27/2001 -0700, Terry Lambert wrote:
Mike Tancsa wrote:
fxp0: Intel Pro/100 Ethernet port 0xc400-0xc43f mem
0xd5001000-0xd5001fff irq 11 at device 8.0 on pci1
fxp0: *** DISABLING DYNAMIC STANDBY MODE IN EEPROM ***
fxp0: New EEPROM ID: 0x49a0
fxp0: EEPROM checksum @ 0xff
Then go look them up. I'm not about to stuff the entire PnP device
database into the kernel just to satisfy your curiosity. 8(
I was going to ask where, but I see they are in
/usr/src/sys/boot/common/pnpdata.
That's a useful subset that I keep forgetting about; thanks for reminding
I once wrote the following patch to deal with this problem by
probing ISA devices in the following order.
1. sensitive ISA devices described in device.hints
2. PnP BIOS ISA devices
3. other ISA devices described in device.hints
4. PnP ISA devices
This order is still slightly wrong. You
I remember an ACER system with a bus mouse on the motherboard
which was unknown to the PnP BIOS, and Windows 95 trying to
be a PnP OS used to always do what above looks to be the
PnP ISA devices phase of things, and gave IRQ 12 to the
second IDE disk interface, instead of the on-board
: unknown: PNP0303 can't assign resources
: unknown: PNP0501 can't assign resources
: unknown: PNP0501 can't assign resources
: unknown: PNP0401 can't assign resources
: unknown: PNP0700 can't assign resources
: unknown: PNP0f13 can't assign resources
Shouldn't we just suppress the
: Intel Pro/100 Ethernet port 0xc400-0xc43f mem 0xd5001000-0xd5001fff
irq 11 at device 8.0 on pci1
fxp0: Ethernet address 00:01:80:02:d0:34
inphy0: i82562EM 10/100 media interface on miibus1
inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
---Mike
At 10:11 AM 8/26/2001 -0500
The motto used to be do it right, not do it the way WE want it on OUR
machines, and screw the people who don't make the decisions or cause to much
trouble to ignore.
It still is. And recognising that csh has evolved over the last decade
is part of doing it right.
What you're really saying
It still is. And recognising that csh has evolved over the last decade
is part of doing it right.
No, doing it right would have been including tcsh and deprecating csh, then
dropping it later as has been done with other things.
This is what was done. The old csh is deprecated, but
: unknown: PNP0303 can't assign resources
: unknown: PNP0501 can't assign resources
: unknown: PNP0501 can't assign resources
: unknown: PNP0401 can't assign resources
: unknown: PNP0700 can't assign resources
: unknown: PNP0f13 can't assign resources
Don't worry about these.
So, you are saying that this is because there is not a seperate
No BIOS and BIOS section (or entry prefix) in the hints file,
so that in a non-PnP system, both the No BIOS and BIOS
entries will be examined, whereas on a PnP system, only the BIOS
entries will be examined?
This would be an
I think the reason the hints are not just ignored is to allow
people to fix rogue hardware. I'm willing to be corrected,
Good. It's like it is right now because the PnP stuff was bolted on as
an afterthought.
since this looks like about 12 lines of code would make it
ignore device.hints
It should be a tunable, not a compile-time option.
David Hill wrote:
Hello -
Could someone please document options HZ into LINT?. I found it whil
e
reading the dummynet(4) manpage.
Thanks
- David
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
Going off on a slight tangent, I wrote a perl script months ago
that parsed the output of dmesg, and tried to determine which IRQs were
used, and for what. One of the side-effects of this script is that it
also tried to identify unknown PCI devices (but *only* if an IRQ is
used), using
* Jim Bryant [EMAIL PROTECTED] [010823 01:33] wrote:
i noticed this after a build from -current of about 24 hours ago:
due to problems getting kde-2.2 to compile under -current, I am
currently using windowmaker and doing a `exec startx /dev/null`
to get into X without leaving a
If we want a surface scrubber, we ought to have a real one; it's
also very, very bad in the laptop context (since it keeps waking your
disks up).
If we're going to keep it, it should be turned off by default at any rate.
diskcheckd is very annoying. Many doubt its usefulness in detecting
As far as I can tell, there's nothing in the tree which uses libss any
longer, and hasnt been for quite some time. Is there any reason to
keep it?
Nope.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people
Yes; mk_cmds is part of libss and should have been deleted as well.
Is this caused by libss termination?
At Sun, 19 Aug 2001 07:48:07 + (UTC),
Kris Kennaway wrote:
As far as I can tell, there's nothing in the tree which uses libss any
longer, and hasnt been for quite some time. Is
Subj. I can browse through code (and i do so), looking for chip IDs and
comparing them with chipset ones, but it's sometimes difficult, because
not all chip IDs in chipsets are know to me. So maybe driver developers
know more than i do?
I want to buy VIA Apollo KT266 based MD for Athlon,
[Terry blathers]
Surprisingly, setting vidconsole in the SRM didn't make
my TGA work in FreeBSD. 8-p.
'vidconsole' is the x86 loader console driver. Under SRM, there are no
console options (because the platform doesn't give you any).
--
... every activity meets with opposition,
On 15-Aug-01 Mike Smith wrote:
[Terry blathers]
Surprisingly, setting vidconsole in the SRM didn't make
my TGA work in FreeBSD. 8-p.
'vidconsole' is the x86 loader console driver. Under SRM, there are no
console options (because the platform doesn't give you any).
Errr
) is much, *much* better than
the Belkin, and no machine has a problem booting without the console
pointing to it.
Just my $.02.
Thanks,
Mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Here is the _precise_ problem with older firmware:
The Belkin KVM switch uses the on-off-on or off-on-off
of this LED to signal a port change character is coming next,
and times out the port change request only after a little
while.
Ah, so the problem is actually a design defect in the
=0x710110b9 rev=0x??
hdr=0x00
vendor = 'Acer Labs Inc.'
device = 'M7101 PCI PMU Power Management Controller'
...
Check that you have ACPI/power management turned on in your BIOS setup;
that's typically responsible for enabling/disabling this device...
Regards,
Mike
--
... every activity
?
Under ACPI, the OS initiates sleep, not the BIOS, so the keyboard
shortcuts aren't going to do anything.
Regards,
Mike
--
... 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
implementation (remember, BIOS is from
'99)
Could be, though we're talking hardware here. It's possible that we'll
just have to blacklist your timer. 8( Can you give me the ALi chip
number(s) again, and I'll go look for datasheets...
Regards,
Mike
--
... every activity meets with opposition, everyone who
I forgot: Even if I define CLK_USE_*_CALIBRATION (and get no error messages
after defining debug.acpi.timer_test), the Off/2 error still persist.
Ok. I'm going to revert to the safe read code in a few minutes.
Can you update and let me know if you're still wildly off? I'm having a
hard
send me the output of
'pciconf -lv' and I'll see whether we can safely detect your ACPI
timer.
Regards,
Mike
--
... 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
This should fix problems people were having with PCI interrupt routing and
ACPI. Please report any problems...
msmith 2001/08/03 01:38:49 PDT
Modified files:
sys/dev/acpica acpi_pcib.c
Log:
Shoud build resources in the _CRS buffer. Oops.
Submitted by:
Excellent. I'll try to get something sorted out about this tonight.
How long does it take before it prints the first message there?
Regards,
Mike
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because people want
- What power management hardware your system has: look at the output of
pciconf -lv for a power management controller, eg:
This machine has no separate controller. Attached is the complete output
of pciconf -lv
That's OK; I can probably safely assume it's the M1533 device.
-
in _thread_sig_handle_pending () from /usr/lib/libc_r.so.5
This is with the latest apache port and uthread_sig.c version 1.38.
- Mike
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
701 - 800 of 1809 matches
Mail list logo
