> Just curious, but are there plans to support the EV6 bus that the dual
> athlon motherboards use? I'm not going to buy that kind of system unless
> FreeBSD 5 will support it.
FreeBSD works just fine on the dual K7 evaluation systems that AMD have
been shipping around. It seems that they wimpe
> On Fri, Jun 08, 2001 at 11:19:10AM -0700, Julian Elischer wrote:
> > kernel: pcic1: irq 11 at device 4.1 on pci0
>
> > in pccard.conf I had
> >
> > irq 11
> >
> > is this not what I was supposed to do?
>
> Sorry, I guess maybe this directive is counter-intuative. It supposed to
> be a list
> The reason I said "in the next week" is actually because on Sat. June 23rd
> (not this upcoming one, but the one after), I should be flying off to
> Yugoslavia (actually to London, and only then to Yugoslavia). I will be
> gone for 3 weeks and seeing as how maintaining this huge diff is a real
> I've been waiting for a FORTH-geek to pop his head up; I
> have most of "nextboot" reimplemented... I've added "fwrite"
> and "flseek" verbs. I've thought about kidnapping an
> astronomer. 8-).
>
> The current problem is that the biosdisk.c doesn't contain
> "write" code, and that the libstan
> In message <[EMAIL PROTECTED]> Bruce Evans
>writes:
> : The first "ls" should create about 8000 new tun devices by first accessing
> : them via stat(2), but there is some garbage collection, so the second "ls"
> : may show that some of the devices have magically unappeared.
>
> I just want to
This is just a heads-up to let folks know that I've committed some early
code to handle thermal management under ACPI. This should DTRT with
active cooling (fans, etc.). It won't help with passive cooling yet (we
need to sort out the processor device control first), and it may well
have pro
> I'm running current and get the following error in dmesg while trying to
> enable the minipci. This is a HP n5470 laptop.
>
> dc0: irq 11 at device 16.0 on pci0
> dc0: failed to enable I/O ports!
> device_probe_and_attach: dc0 attach returned 6
>
> It is sharing irq 11 with the cardbus bridg
I've committed another round of ACPI changes to -current.
The major addition is CPU throttling support. This is implemented using
ACPI, not any vendor-specific technology, so it should work on any
platform that exports the relevant information. By default, the CPU will
run at 100% in 'performa
> On Fri, 6 Jul 2001, Bruce Evans wrote:
> ...
> > if_foo.c -> /sys/modules/foo -> foo.ko. There is no driver named if_foo.
> >
> that seems to be right.
> No man if_ed(4) yust ed(4)...
No.
if_foo.c in /sys/modules/foo builds if_foo.ko.
This was discussed a year or so back; it's a compromise d
>
> ha/alpha/genassym.c
> ../../../vm/vm_zeroidle.c:13: opt_npx.h: No such file or directory
> ../../../vm/vm_zeroidle.c:17: opt_reset.h: No such file or directory
> ../../../vm/vm_zeroidle.c:38: machine/pcb_ext.h: No such file or
> directory
> ../../../vm/vm_zeroidle.c:39: machine/vm86.h: No suc
> > I've committed another round of ACPI changes to -current.
> >
> > The major addition is CPU throttling support. This is implemented using
> > ACPI, not any vendor-specific technology, so it should work on any
> > platform that exports the relevant information. By default, the CPU will
> > r
>
> I'm also having same hang-up, with acpi_pcib.c rev1.10 (no NEWCARD).
Sounds like calling _SRS is breaking something.
> With acpi_pcib.c rev1.9, I loose my pccard.
This is known; I messed it up. 8(
> With acpi_pcib.c rev1.8, everything seems ok.
This uses the "old" PCI interrupt routing c
>
> sos> Well, sortof, the ata driver doesn't allow for sharing irq14&15
> sos> since lots of boards doesn't work that way. However if you need
> sos> it you can try to add the shared flag in the driver and see if
> sos> it works on yours. Hmm, maybe I should make this tunable...
>
> It this p
> : There is absolutely no reason for the ata driver not to simply set
> : RF_SHAREABLE and be done with it. It's up to the driver's parent (isa,
> : pci, etc) to decide whether the interrupt is in fact shareable or not.
> :
> : The ata driver itself can share interrupts just fine, and it shou
> > Finally, if you're so damn concerned about your precious alpha I
> > expect you or at least ANYONE WHO CARES ABOUT ALPHA TO ASSIST IN
> > TESTING THESE DIFFS.
>
> HOW THE FSCK AM I TO TEST THEM WHEN I CANNOT EVEN GET TO SINGLE USER??
By testing them before they're committed, obviously.
Davi
> > David - this conversation is not productive, and you're not helping
> > anyone, including yourself, going off like this.
>
> Care to address Alfred's going off also?
Since it's your incessant carping that's the source of this shameful
little flamwar, no.
> > Please tone it down, ok?
>
>
> attached is a diff for rc.i386, rc.conf.5 and defaults/rc.conf which
> allows to enable the ACPI power management in rc.conf similar to
> apm_enable.
This is not a good idea; ACPI isn't "on" or "off", and by the time
rc.conf is running it's too late to en/disable it. There are several
sepera
I've just merged the Intel 20010717 code, after some very light testing
at this end. Feedback is encouraged.
The most visible change in this drop is a fix in handling of fields in
unaligned regions; this should resolve the issue with Sony VAIO systems
reporting bogus temperatures and AC adap
> On 20 Jul, Mike Smith wrote:
> >> attached is a diff for rc.i386, rc.conf.5 and defaults/rc.conf which
> >> allows to enable the ACPI power management in rc.conf similar to
> >> apm_enable.
> >
> > This is not a good idea; ACPI isn't "on&quo
> Hi.
> I'm running -current whose source tree was checked out as
> TZ=UTC cvs co -D'2001-07-12' src
> on VAIO PCG-C1XE(PentiumII with 64Mbytes of RAM)
> and have some problems:
>
> 1. Acpica modules hangs in
> AcpiRsCalculateByteStreamLength() called from
> AcpiRsCreateByteStream() ca
> Hi.
> I'm running -current whose source tree was checked out as
> TZ=UTC cvs co -D'2001-07-12' src
> on VAIO PCG-C1XE(PentiumII with 64Mbytes of RAM)
> and have some problems:
>
> 1. Acpica modules hangs in
> AcpiRsCalculateByteStreamLength() called from
> AcpiRsCreateByteStream() c
> It is much easier, at least to me, to just remove much of the KLD
> screen saver support from syscons to the user-land, than to utilize
> the kthread :-)
Just FWIW, I think that moving the screen saver to userspace is an
excellent thing to do.
--
... every activity meets with opposition, eve
> > > 1. Acpica modules hangs in
> > > AcpiRsCalculateByteStreamLength() called from
> > > AcpiRsCreateByteStream() called from
> > > AcpiRsSetSrsMethodData() called from
> > > AcpiSetCurrentResources() from somewhere in acpi_pcib.c .
> > >
> > > The hang itself occurs at Linke
There is a bug in the Intel ACPI CA code which will cause your system to
power off upon waking from suspend mode. Iwasaki-san tracked it down and
posted a fix to the acpi-jp list (message 1186) for folks that want to
patch locally.
Intel have adopted the patch, and the next update will fix t
> 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
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
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
> >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
> > 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
> > 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
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
> 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
> > - 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
> 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,
> 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
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
> 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
[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
>
> 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
>
> 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
>
> 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
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
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
>
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]
> >
> 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
> * 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
>
> >: 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
> 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
> > 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,
> > >: 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
> 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
> 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
>
> > 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 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.
> 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 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
> | 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 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 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've just committed a driver for the abovementioned RAID adapter families
provided by DPT/Adaptec and the long-suffering Mark Salyzyn. The driver
will be maintained by Adaptec, with a little help from yours truly if
really necessary.
With any luck, we should see the complete set of managemen
>
> Maybe. It's also not clear to me whether &my& current breakage is PCI related
> or device.hints related (it appears that the read of my /boot/devices.hints
> file gets things garbled):
What makes you say that? This all looks fine to me. (The hang is not so
good though...)
> Hit [Enter] t
> At 01/09/2000 10:30, Mike Smith wrote:
>
> >I've just committed a driver for the abovementioned RAID adapter families
> >provided by DPT/Adaptec and the long-suffering Mark Salyzyn. The driver
> >will be maintained by Adaptec, with a little help from yours
> > I've just committed a driver for the abovementioned RAID adapter families
> > provided by DPT/Adaptec and the long-suffering Mark Salyzyn. The driver
> > will be maintained by Adaptec, with a little help from yours truly if
> > really necessary.
>
> Excellent! Any ideas when this
> > I'd like to hear a few more success stories first (only one so far) from
> > people using the kit to add the driver to their 4.x systems. With all
> > the breakage in -current's PCI support at the moment, I don't expect to
> > hear too many people there reporting on it just yet.
> >
>
>
> > Sep 7 14:35:55 laptop /kernel: microuptime() went backwards (10412.355980 ->
>10412, -694583121)y
> >
> > this is bad.. right ? :-)
>
> Well, at any rate it looks very funny. If this is a laptop, try
> building a kernel without apm and see if that helps.
It only helps "hide" the problem.
>
> looks like the boot loader is killing -current. I have a patch, but
> it just cuts all the offending references.
>
> Comments?
rebuild/reinstall libstand. Sorry; should have HEADS-UPped that one.
> Warner
>
> cc -nostdlib -static -Ttext 0x0 -o loader.sym
>/usr/obj/home/imp/FreeBSD/src/
>
> I have collected all the emails I've received and I have identified
> at least two different causes:
>
> There is a bogus i8254 implementation on certain Athlon Mobos, this
> is a non-brainer since they should not use the i8254 but the TSC.
s/TSC/ACPI timer/
It might even work on those sys
> Robert Nordier wrote:
> >
> > Julian Elischer wrote:
> >
> > > with newly CVSup'd sources (I cannot compile the bootblocks..)
> > > (also with everything checked out to PRE_SMPNG)
> > >
> > > It get's the following error:
> >
> > > /usr/obj/usr/src/sys/boot/i386/loader/../libi386/libi386.a(px
> > Robert Nordier wrote:
> > >
> > > Julian Elischer wrote:
> > >
> > > > with newly CVSup'd sources (I cannot compile the bootblocks..)
> > > > (also with everything checked out to PRE_SMPNG)
> > > >
> > > > It get's the following error:
> > >
> > > > /usr/obj/usr/src/sys/boot/i386/loader/../
>
> I have two questions. Recently, I started seeing the message:
> module sn already present!
> when dhclient runs on my sn device. What causes this?
It's caused by the 'sn' driver's module being called 'sn' rather than
'if_sn'. The code in ifconfig that tries to autoload modules for
't want the buffer cache
behind it.
> Could this have lead to some of the poor performance Mike Smith
> was seeing when testing this summer?
No, we were layering over the filesystem, however filesystem load was
insignificant. The Oracle performance issues are well known, and this
> Can the configuration for bootup and initial installation be configured to
> detect (and configure) a serial console. This would be very useful for
> rackmount systems. Yes, I know it can be done manually after the
> installation is completed with a monitor; but this would save some time.
> I can second this... on my PC the cpu used to run around about 84 degrees
> F with the case at 80 degrees F, now the cpu runs at about 91-93 degrees F
> while the case runs at 80 degrees F.
While you're tinkering with SMPng, be VERY SURE that you do not have acpi
enabled (ie. make sure it's no
> My laptop does seem to run *MUCH* warmer than before as well. It runs
> hot to begin with, but with the latest kernels it runs really hot. It
> used to get this hot only when I compiled -j 4. I don't have ACPI
> enabled and am using UP kernel. There really needs to be a HLT in the
> idle loo
> In message <[EMAIL PROTECTED]> Mike Smith writes:
> : If I remember from a discussion with John Baldwin, the reason we don't do
> : this (yet) is that HLT only wakes up when you take an interrupt, and
> : there are cases where we can't guarantee that we'll t
> : >> If I remember from a discussion with John Baldwin, the reason we
> : >> don't do this (yet) is that HLT only wakes up when you take an
> : >> interrupt, and there are cases where we can't guarantee that we'll
> : >> take an interrupt in order to get us out of the HLT.
> : >
> : >I thought t
>
> >With the addition of ACPI kernel thread, my system hangs in about
> >10 miniutes use after boot up. By disabling kernel thread, system
> >runs just fine.
> >
> >Do you have any idea where to look at?
> >I'll try and see what I can do myself.
>
> Please set debug.aml_debug and debug.acpi_de
> > > Please set debug.aml_debug and debug.acpi_debug to 1 and
> > > see what will happen.
> >
> > It wouldn't surprise me if the system wasn't running out of kernel
> > memory. Right now we just keep mallocing storage to queue ACPI events
> > (bad idea). The entire event/Notify stuff needs
> > > Currently kernel thread seems broken, so mallocing storage in
> > > acpi_queue_event() never be freed. I think number of events at a
> > > point of tme is limited and we can have static storage for the events.
> > > The implementaion of sys/i386/apm/apm.c:apm_record_event() (it's for apmd)
Here's the latest ACPI megapatch:
- Move all the register I/O into a separate file
- Made all the I/O spaces use proper bus resources
- Allocate the resources in machine-dependant code
- Map ACPI-used memory in machine-dependant code
- Create a machine-dependant "acpiprobe" device which jus
> > > I'd like to move and rename them as I said in my previous mail,
> > > ->
> > > shared by both kernel and userland programs
> > > ->
> > > shared within kernel code (acpi stuff and related drivers)
> >
> > IMHO, it's desirable to use the name "acpi.h", because of conflict
> > with th
> Thanks a lot mike, these are mostly acceptable for me.
>
> > - Made all the I/O spaces use proper bus resources
> > - Allocate the resources in machine-dependant code
>
> I prefer previous patch because most of the code in i386/acpi_machdep.c
> can be shared with IA64 I think.
I'm not so su
> And probe method and identify method should not be confused.
> Memory area check etc can be in MD acpi probe code.
Can you explain what you mean here a bit more? The FACT lookup and
resource establishment need to be done in the identify routine, not the
probe routine...
--
... every ac
> OK, understood. How about having MD sub-routine in the same interface
> (say acpi_set_resources() or acpi_create_instance() or whatever) for
> i386 and ia64? Then generic ACPI identify method calls suitable
> sub-routine depending on machine architecture.
>
> - i386/i386/acpi_machdep.c
>
Ok. Based on all the suggestions, received today, and some more ideas
besides, here's the latest megapatch.
- Move all register I/O into a new file
- Move event handling into a new file
- Move headers to acpivar/acpireg/acpiio
- Move find-RSDT and find-ACPI-owened-memory into acpi_machdep
As Iwasaki-san pointed out, I left acpi_event.c out of the previous
megapatch. Rather than resend the entire thing, you can fetch the
complete patch from:
http://people.freebsd.org/~msmith/acpi-2929.diff.gz
Regards,
--
... every activity meets with opposition, everyone who acts has hi
> > Please test this; there are lots of opportunities for error in these
> > changes. In particular, I am afraid that I may have broken I/O from AML
>
> I did test it, S1, S5 transition, PowerResource On/OFF and GPE handling
> by kernel thread, everything seems OK!
> I think nobody has objecti
>>> Cool. On some machine, thermal management requires Embedded Controller I/O.
>>> Anybody working on this?
>>
>> Yeah. I just discovered that I need this.
>>
>> I haven't look at how operation regions are handled, so I'm not sure how
>> hard it's going to be to implement the hooks necessar
> Run 4.0 or piss off...
Actually, no. This message contains useful diagnostic information, and
can be used to resolve the problem.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of CHOI Junho
> Sent: Saturday, September 30, 2000 11:22 PM
> To: [EM
> > I hate to spoil the moment ... but does anyone have an idea what the
> > fix is? Nothing in the amd directory seems to have changed in the
> > past couple of weeks, so it must be somewhere else, and I'm not bright
> > enough to figure out where.
>
> Yeah, somebody forgot that typedefs and st
> > > PowerResource code keeps pointers to the PowerResource objects, then
> > > finds a pointer to methods of the object dynamically. Can we do it in
> > > similar way for thermal management?
> >
> > Well, yes, but you have to go back and re-parse the actual AML. I'm not
> > even sure if it's
Here's what seems to be an interesting AML or AML parser bug.
OperationRegion(PSRG, SystemMemory, 0x0410, 0x1)
Field(PSRG, DWordAcc, NoLock, Preserve) {
, 2,
PS2E, 1
}
The field is marked for 32-bit access, but the region is only 1
> > > Yes, we can have large benefit by migrating to ACPICA. I suggest that
> > > we make ACPICA version of AML interpreter run in userland as a
> > > debugger for the first evaluation. By doing this work we can make
> > > sure it works actually on FreeBSD and estimate the work volume of
> > > k
> > Here's what seems to be an interesting AML or AML parser bug.
> >
> > OperationRegion(PSRG, SystemMemory, 0x0410, 0x1)
> > Field(PSRG, DWordAcc, NoLock, Preserve) {
> > , 2,
> > PS2E, 1
> > }
> >
> > The field is marked for 32-bit access, but the r
> I have an enormous patch that I can put up later tonight on Freefall.
Actually, I couldn't make CVS do what I wanted, so it's a big tarball
with an itty-bitty little patch instead.
This requires an up-to-date -current kernel (for the pci_cfgreg changes,
etc.)
I haven't done anything special
The build was silently broken by AMD including previously.
It wasn't exposed until recently. The correct fix was still to not
include anywhere in AMD (or anywhere else in userland for
that matter).
> On Sun, Oct 01, 2000 at 12:14:25PM -0700, Mike Smith wrote:
> > Er, this i
> Great! This is really great!! I didn't think we can have ACPICA
> kernel so earlier.
Well, let's see if it works right first. 8) I hear from Intel that they
plan to release a new code revision today, so I will be updating when
they do. I also hear that Andrew Grover (the chap at Intel th
> > >This is still very obscure; I'd like to see:
> > >
> > > size (was 1234, should be 5678)
> > > cksum (was 42424242, should be 69696969)
> > >
> > >...so that it's clear what the meaning of the numbers is.
> >
> > In that case I think I would like to loose the ',' also.
>
> On 04-Oct-00 Alain Thivillon wrote:
> >
> > I have noticed that -CURRENT (build last week) is subject to a very high
> > clock deviation:
> > I run -CURRENT on a laptop, it seems that last commit in idle loop (the
> > one replacing loop by HLT and lowering temperature) broke the clock.
>
> Hmm
I don't know of any problems related to this at this time. Make sure you
have the latest BIOS from Intel for the ISP2150.
> I installed 4.1.1 on an Intel ISP 2150 with a Mylex AcceleRAID 250. The
> fireware on the controller is 4.06 .
>
> After install and while it starts to boot I get:
>
501 - 600 of 860 matches
Mail list logo
