I've finally updated the ACPI CA codebase with Intel's 20020214 drop
(yes, I tagged it 0217, my bad).
This is the first drop that Intel haven't asked me not to commit since
the 20011120 version, so there are a large number of changes and
bugfixes. See Intel's logs at
http://developer.intel.com
> In the book "Writing Linux DEvice Drivers", there is a neat bit
> on how Linux does this. Effectively, they export all symbols
> within the module load if there is no explicit symbol table
> export call, and they export only the symbols that are requested,
> if there is.
I considered this appr
I've recently committed a series of changes which affect the way
modules are built. Since I can't test *every* module, please let me
know immediately if you run into problems with modules refusing to
load due to undefined symbols, or not working "quite right". I've
tried hard to make sure it's
> I upgraded by cvs on saturday night,
> Sunday I didn't use it.
> Monday I tried to boot it. but the loader says:
> ASSERT
> and the system reboots
>
> I'd LOVE to know wha the assert is but really My opical neurons take at
> least 20mSecs to fire and by the time I've found the Asssert line
> I
You can define ACPI_DEBUG in the environment before building the kernel,
or when manually building the module, or in /etc/make.conf.
> I've stumbled on the ACPI_DEBUG issue in the module load as well.
> The ACPI_DEBUG definition only propogates to the opt_acpi.h file
> in the base kernel. The
> Hi all
>
> Glad to hear that it worked for you.
>
> Just wondering..is your affected motherboard using AMI for BIOS?
> Mine is AMI too.
>
> I'll try to submit a PR. Hopefully the fix will be accepted.
A PR that hardwires IRQ 12 probably won't be accepted. Can you look
around the ACPI table
> Well, for reads a non-stripe-crossing op would still work reasonably
> well. But for writes less then full-stripe operations without
> spindle sync are going to be terrible due to the read-before-write
> requirement (to calculate parity). The disk cache is useless in that
>
> Joerg Wunsch wrote:
> > > I guarantee you that there are a number of controllers which have
> > > different ideas of how to do soft sector sparing _at the controller
> > > level_ rather than at the drive level.
> >
> > We have dropped support for ESDI controllers long since. :-)
> >
> > Seriou
> What is it about this particular topic brings out such irrational
> emotions in you and others?
Because you define as "irrational" those opinions that don't agree with
your own. I don't consider my stance "irrational" at all, and I find
your leaps past logic and commonsense quite "irrational
> >>> Still, it's my opinion that these BIOSes are simply broken:
> >
> > Joerg's personal opinion can go take a hike. The reality of the
> > situation is that this table is required, and we're going to put it there.
>
> The reality of the situation is far from being clear. The only thing
> I c
> > > :> > IBM DTLA drives are known to rotate fast enough near the spindle
> > > :> > that the sustained write speed exceeds the ability of the controller
> > > :> > electronics to keep up, and results in crap being written to disk.
> >
> > I would adssume it actually the tracks FURTHEREST from
> On Sunday, 9 December 2001 at 19:46:06 +0100, Joerg Wunsch wrote:
> >
> >
> > Still, it's my opinion that these BIOSes are simply broken:
Joerg's personal opinion can go take a hike. The reality of the
situation is that this table is required, and we're going to put it there.
End of story.
> I have a question about Freebsd driver. If we want to support some
> options in driver(like speed and duplex mode setting) , user can use this
> option to change driver configurations. I am not sure whether freebsd
> driver support driver parameter or something else. Can you give me some
> sugg
> (The other day a coworker of mine wanted to use DD for some IBM DTLA
> disks, because he'd heard that the disks performed better that way -
> something to do with scatter-gather not working right unless you used
> DD. I'm highly skeptical about this since I have my own measurements
> from IBM DT
> As Peter Wemm wrote:
>
> > There shouldn't *be* bootblocks on non-boot disks.
> >
> > dd if=/dev/zero of=/dev/da$n count=1
> >
> > Dont use "disklabel -B -rw da$n auto". Use "disklabel -rw da$n auto".
>
> All my disks have bootblocks and (spare) boot partitions. All the
> bootblocks are DD
> : > : requests for the register window to be based at 0xf400.
> : >
> : > Actually, for most people, just ignoring the error is enough to make
> : > it work.
> :
> : This bothers me. Are bridges ignoring their mapping registers?
>
> It would appaer that they are. It hurts my brain that
> : As a workaround for you, though, try adjusting the memory that the driver
> : requests for the register window to be based at 0xf400.
>
> Actually, for most people, just ignoring the error is enough to make
> it work.
This bothers me. Are bridges ignoring their mapping registers?
--
> I don't know if there's a way to stop this, but it's normal, whenever I use
> my Parallel port zip drive, I have similar problems.
There isn't, really. The parallel port is terribly inefficient.
> > But what surprises me is that copying that data to the parallel intfc burns
> > up an incredi
> i found a posting on the netbsd current mailinglist stating that with some
> minor modifications it sort of attached to the umass driver, but the author
> had no further success. the posting can be viewed at:
> http://www.geocrawler.com/archives/3/497/2001/7/100/6233506/
>
> hope someone with t
> In message <[EMAIL PROTECTED]> Nickolay Dudorov writ
> es:
> : And I can buildkernel only after the next patch:
>
> I just removed this from build until Mike can fix the ciss driver
> itself.
Sorry about this; I got distracted last night, and my last -current
test build was too long ago. 8
> hi all,
>
> this patch will put an end to those XXX lines in the
> NOTES file, which were regarding uncategorized
> options.. such as USERCONFIG etc.
>
> I am also attaching a tar.gz package which has the
> patch compressed and archived.
This is NOT how to do this.
File a PR containing the p
> So this means the output queue on my net card is full, right? And I guess
> there is no easy solution... Oh well, I'll have to cope.
That's correct; the pipe is full, and you can't put any more bits in it.
Typically you run into this situation when your app is generating more
data than can sq
> I'd like to get card bus working, however under 5.0-current my pcmcia
> controller is failing to load with the message:
>
> pccbb0: at device 15.0 on pci2
> pcib2: device pccbb0 requested unsupported memory randge
> 0x1000-0x (decoding 0xf400-0xfbff, 0xfff0-0xf)
>
> The build and all goes well, but after a reboot. the kernel boots and
> just hangs on the acpi_cpu and refuses to go further.
>
> deleting the acpi.ko in /boot/kernel solves the problem for me. Is there
> any way to _disable_ acpi all together? I tried doing it from the boot
> menu (using unloa
> 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 assistan
> > The problem is still here as of today's kernel. Please do
> > something about it.
>
> Should I reapeat how sad it is that this longstanding
> problem is being completely ignored by the acpi
> maintainer(s)?
No, I'd prefer that you found something constructive to do with your time.
I'm not in
> 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
> 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, every
> * 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 paramet
> > 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
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 ACP
> 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):
> : 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)
>
> 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
manage
>
> -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 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 (deb
>
> 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 tim
> 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;
>
> 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 Sm
> 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)
> >
>
> 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
s
> 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
> 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.
Bec
> 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.disab
> 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.
> 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
> > 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 fa
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 na
> I personally, don't have enough time to hack the code for now (sorry),
> but I think that newly added `placeholders' code causes the problem
> for my first impression.
Yes; this is something that I'm not happy about. It looks like these
resources are being badly abused by vendors as "hints" fo
> > > 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
> for
> 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 a
>
> 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
inter
> I'm having a problem with the new acpi. One one of our boxes (amd K7 900 Mhz
> Compaq) does not probe xl properly. It returns Could not probe memory
> (returns error6). There is no pnp setting in this bios. I went back to
> pre-commit and it works fine. Any suggestions?
There seems to be a c
> > 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
> > unknown: can't assign resources
> > unknown: at port 0x378-0x37f on isa0
> > unknown: can't assign resources
> > unknown: at port 0x3f8-0x3ff on isa0
> > unknown: can't assign resources
> > unknown: at port 0x2f8-0x2ff on isa0
> > unknown: can't assign resources
> > unknown: at irq 12
> 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
> 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 P
> I'm getting this with the recent ACPI code, should I worry about it?
>
> acpi_cpu0: 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
> 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 en
> 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 a
> 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 ge
> 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 t
> 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: ***
> 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
> 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(
> | 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
> > > - 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
I have just committed some changes to the way that ACPI works in
current. This has an impact on all -current users, so please
take a few seconds to read this and feel free to ask questions.
The loader now detects ACPI in your system, and loads the ACPI
module if it is present. This has major
> 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 s
> 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-boar
> 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.
>
> > 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 remi
> 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.h
> 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
> > >: unknown: can't assign resources
> > >: unknown: can't assign resources
> > >: unknown: can't assign resources
> > >: unknown: can't assign resources
> > >: unknown: can't assign resources
> > >: unknown: can't assign resources
> > >
> > >Don't worry about these.
> >
> > Shouldn't we
> > 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,
> 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
>
> >: unknown: can't assign resources
> >: unknown: can't assign resources
> >: unknown: can't assign resources
> >: unknown: can't assign resources
> >: unknown: can't assign resources
> >: unknown: can't assign resources
>
> > Shouldn't we just suppress the message? It just confuses us
> * 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 le
> 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), u
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]
> >
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
>
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 ti
>
> 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 peo
>
> 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 Ath
>
> 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 driv
[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, ev
> 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 def
Er. Interesting. Doing some reading up on the M1533, I notice that the
power management component isn't actually listed here:
> ohci0@pci0:2:0: class=0x0c0310 card=0x chip=0x523710b9 rev=0x03
> hdr=0x00
> vendor = 'Acer Labs Inc.'
> device = 'ALI M5237 USB Host Cont
> > 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 time believing that your timer is really running at double pace, but
> > I guess anything is possible. If it still does, I'll add some
> >To test your ACPI timer, first check to see which one you have. Look
> >at the output of 'pciconf -lv'. If you have an Intel chipset, chances
>
> Reviewing your last commit on the timer problem, I was a bit suprised
> to see so little chipsets defined as "good" (just PCI ID
> 0x7113
I've made a couple of minor changes to the ACPI code:
- Fixed (hopefully) PCI interrupt routing, thanks to [EMAIL PROTECTED]
who was able to actually test (and correct) my code.
- Changed the way ACPI timers are treated to be more pessimistic. It
looks like we can't assume that the av
> 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
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
> > From [EMAIL PROTECTED] Tue Jul 31 12:15:25 2001
> >
> > set debug.acpi.timer_test="yes"
> >
> > at the loader prompt and boot? Ideally, you'll get a message "timer is
> > not monotonic", followed by some numbers. If this is the case, then I
> > need to get "smarter" with the ACPI timer
> > - 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
> Mike,
> Seems like I managed to solve my problem. Attached is to be applied against
> sys/dev/acpica/acpi_pcib.c, rev 1.10 .
Thanks for tracking this down; without hardware to test here, it's been
difficult. Great bug report!
I've just committed a slightly different patch, based on a mix of
> On Sat, 28 Jul 2001, Mike Smith wrote:
>
> > You could also try building a kernel with CLK_CALIBRATION_LOOP defined
> > and then booting with -v (without the timer disabled). This might be
> > instructive (I don't know for certain that it'll calibrate the
> Mike Smith schrieb:
> >
> > Say
> >
> > set debug.acpi.disable="timer"
> >
> > in the bootloader and see if you still get this. I've already got one
> > report of system time going twice as fast as it should; I'm unsure what&#x
Say
set debug.acpi.disable="timer"
in the bootloader and see if you still get this. I've already got one
report of system time going twice as fast as it should; I'm unsure what's
going on here (I don't grok the timecounter code as well as I should, I
think)...
You could also try building a
1 - 100 of 860 matches
Mail list logo
