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
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 approach,
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
--- Blind-Carbon-Copy
X-Mailer: exmh version 2.1.1 10/15/1999
To: [EMAIL PROTECTED]
Subject: Driver for Adaptec/Dell/HP PCI:SCSI RAID adapters available
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 23 Jul 2000 15:53:40 -0700
From: Mike Smith [EMAIL PROTECTED
Stephan van Beerschoten wrote:
And what is the word on thise IOERROR's given by my kernel when its init'ing
its usb stack.
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
uhub0: port 1 power on failed, IOERROR
uhub0:
* Stephen McKay [EMAIL PROTECTED] [000805 08:49] wrote:
Patch 2 is smaller and possibly controversial. Normally bufdaemon and
syncer are sleeping when they are told to suspend. This delays shutdown
by a few boring seconds. With this patch, it is zippier. I expect people
to
Would it be possible to revert the DPT commits made by peter on
Mon Aug 7 18:48:14 2000 in the RELENG_4 branch? It seems that the
dpt_attatch is failing in bus_alloc_resource(9) for the IRQ, and I have
production machines that need worlds built for some other updates as
well.. I
This is not an "IDE RAID" controller. It's an IDE controller with some
lame "RAID" software in the BIOS. We don't support this.
(excuse complete ignorance as far as IDE RAID below)
For the buildbox here, I decided to go ahead with Soren's ATA-100 RAID
suggestion, and bought an Abit
I'm curious -- what kinds of cards are supported by this routine?
Does this include the DPT SmartRAID V, as well as the older SmartRAID
IV? I've got an anonymous ftp server I need to rebuild -- it had
previously been running Slackware Linux, but as the kernel got
updated, the
John Baldwin writes:
FreeBSD/i386 bootstrap loader, Revision 0.8
([EMAIL PROTECTED], Sat Aug 26 11:14:35 GMT 2000)
/kernel text=0x2432ca zf_read: fill error
elf_loadexec: archsw.readin failed
Your floppy is bad. Try a different one.
Not necessarily. This also happens if
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
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] to boot
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 truly if
really necessary.
With any luck
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 might be
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.
Maybe
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. There's
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
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 systems.
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(pxe.o): In
function `
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(pxe.o): In
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
e in the future". This is an
example where they could presumably be useful.
Doesn't Oracle run MUCH better when given raw block disk devices to store
data on?
Oracle wants to cache it's own data, it doesn't want the buffer cache
behind it.
Could this have lead to some of the poor pe
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 not
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 loop to
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 take an interrupt in
: order to get us
: 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 that's what the
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_debug to 1 and
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 to be
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)
would be
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
I'd like to move and rename them as I said in my previous mail,
sys/acpi.h - sys/dev/acpi/acpi.h
shared by both kernel and userland programs
sys/dev/acpi/acpi.h - sys/dev/acpi/acpivar.h
shared within kernel code (acpi stuff and related drivers)
IMHO, it's desirable to use
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 sure about
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
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
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 objections for
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 necessary for this.
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: [EMAIL
I hate to spoil the moment ... but does anyone have an idea what the
fix is? g 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 structure
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 safe to
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
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
kernel porting.
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
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
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
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.
While you're at it,
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, this
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:
BTX
http://people.freebsd.org/~msmith/acpica-bsd-20001007.tar.gz
This includes:
- ACPI as PnP enumerator for ISA (there are issues here, and this doesn't
disable the "real" PnPBIOS code yet, so you will get duplicates on some
machines).
- Power/Sleep button code (Iwasaki-san)
- Improved
http://people.freebsd.org/~msmith/acpica-bsd-20001008.tar.gz
New in this patch:
- Fixes for the EC code (error handling)
- Fixes for power/sleep button handling (should work for both
control method and fixed buttons)
- Host:PCI bridges are now detected and attached using ACPI rather
Yea, guess so, but I cant help but notice this started after the buyout by
BSDI
Uh, folks, releng4 is hosted at (and donated by) Yahoo, and BSDi have
exactly *nothing* to do with its availability or otherwise.
Before making absurd allegations like this, please apply a few neurons to
That was it. Is the 4MB kernel size limit documented anywhere?
I don't know :-) I luckily noticed this by a lot of trials.
I'm not aware of any 4MB limit on kernel size (and I ought to be if there
is one 8). Can you run the details past me? (I've regularly booted much
larger kernels
will I'm sure there are better things to disable, like MFS, SYSV*,
will P1003_P1B and friends, and ICMP_BANDLIM.
MFS is required; don't forget we have mfsroot.flp :-)
The name is historical; we use md(4) not MFS.
--
... every activity meets with opposition, everyone who acts has his
Don't want to step on toes.. Someone please commit. I believe
we need to 'load /kernel' no matter what... it's the
'read' that's in question. Allows a cdrom to autoboot.
Actually, the kernel should be autoloaded anyway, but you appear to be
right here.
patch also located at
On Fri, Oct 27, 2000 at 09:49:57PM +1100, Bruce Evans wrote:
[...]
NetBSD supports the ntohl family on constants, but only on some arches
(at least in last year's version). It takes fancier macros to support
constants. This gives an excuse to change the inline functions back to
On Fri, Oct 27, 2000 at 07:34:06AM -0700, Mike Smith wrote:
On Fri, Oct 27, 2000 at 09:49:57PM +1100, Bruce Evans wrote:
[...]
NetBSD supports the ntohl family on constants, but only on some arches
(at least in last year's version). It takes fancier macros to support
I had my first CVSup-ed source tre d/loaded today. It compiled correctly
(make buildworld) and installed correctly (make installworld).
But on rebooting the box, the loader fails to find a bootable kernel. It
seems my loader.conf got trashed somewhere ... I get the list of the /
partition,
Hi,
executing /compat/linux/bin/rpm issues a halt and powerdown under -current
an my TECRA8000.
Is it just me?
No. You don't have the Linux module loaded. There's a Linux system call
which (alarmingly) maps to shutdown-and-poweroff if run as a FreeBSD
binary.
--
... every activity
Hi,
Hi,
executing /compat/linux/bin/rpm issues a halt and powerdown under -current
an my TECRA8000.
Is it just me?
No. You don't have the Linux module loaded. There's a Linux system call
which (alarmingly) maps to shutdown-and-poweroff if run as a FreeBSD
binary.
Not really.
Timesharing requires co-operation from both device and bus, but this
is a completely different issue. No drivers currently support
timesharing. `sio' at a minimum probably should, as it was the
motivating example for adding that feature. (My laptop has three PnP
sio ports: an internal
At one (gross) time in history, Alphas included an x86 emulator
in ROM to facilitate this (and other BIOS POST initialization stuff,
mostly).
They still do.
--
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also. But not because
Now that someone has implementented resource alignment in the resource
allocator, someone could review and integrate the attached patch.
This looks fine to me. I assume you'd want the same changes applied to
aligning memory regions?
Background:
I do have an old system with several PnP
Something actually was changed at some point perhaps?
On i386, kernelname is dug out of bootinfo and copied
(in assembler).
On alpha:
p = getenv("kernelname");
if (p)
strncpy(kernelname, p, sizeof(kernelname) - 1);
Did the loader used to set
Does anyone know of any current issues with PXE?
Some ROMs out there are pretty bad.
I've searched the mailing
lists and I don't see any mention of a problem similar to mine.
I'm running FreeBSD-CURRENT from 2000 09 15 on a server. The client has an
Intel 21143 based ethernet card that
As near as I can tell on my laptop, the following change causes panics
with kernel page faults. With it, my laptop panics every time on
boot (although in slightly different places for my two different
kernels) and without it I'm rock solid.
Has anybody else seen this?
Yes; I think it's
: You can also short IOCHK to ground to get an NMI which kicks you into
: the debugger, even in an interrupt context.
:
: Bad news for you warner: On a too large sample of my newer
: motherboards this doesn't work anymore :-(
There's also a pci signal that you can either pull up or pull
That's what I mean. You call this, and it will remap the CIS (if it
has been unmapped), walk it for you and pass you a pointer to each CIS
entry one at a time to the function you specify.
Warner
I'd rather have a seek/read interface than have a callback.
Let's be realistic; the right
IIRC, and I haven't looked it up, the CIS entries that would be
problematical have two next pointers. One is for the next function,
while the other is for the first entry specific to this function. The
driver code could look at the CIS entry to tell what to do, and if it
was the wrong
: Let's be realistic; the right way to do this is going to be to use the
: ivar interface; cardbus_get_cistuple(dev, index) just like all the other
: PCI bus accessor functions. PCI will just need to pass the request
: through to its parent, assuming its parent is a cardbus bridge, or
In message [EMAIL PROTECTED] Mike Smith writes:
: No; the CIS parser should know which function it's being called on behalf
: of, and simply elide the tuples that don't relate to that function.
This isn't always the right thing to do. At least in the 16-bit
world, there are drivers
function its own CIS chain. These CIS chains can live in
configuration space, in memory space or the expansion ROM (which I
assume is the same thing as the ROM BAR on function 0, but maybe I'm
mistaken) and the bridge is responsible for properlly mapping the last
two.
The config space
Isn't the page coloring algoritm in _vm_page_list_find totally bogus?
No, it's not. The comment is, however, misplaced. It describes
the behavior of an inline function in vm_page.h, and not the function
it precedes.
Hrm. My comment was based on John Dyson's own observations on its
I have the modem in the office, not at home. And of course there is that
tricky part where Windows wants my BIOS set to PNP OS=YES and FreeBSD
wants it set to NO. but well :-) we can survive that for the moment.
Can you expand on what actually goes wrong if you boot -current with it
set to
Do we support any of the PNA 2.0 cards (10 Mb net over telephone line)? E.G.
3com 3c410, or D-Link DHN-520?
No; as far as I'm aware they're all using the Broadcom MAC, and Broadcom
refuse to give us documentation.
--
... every activity meets with opposition, everyone who acts has his
rivals
In my bios I have PnPOS=NO, USB-IRQ=Disabled.
The commit below results in a PCI interrupt storm and a terminally
wedged system right after interrupts are enabled.
This would be a bug in the UHCI or OHCI driver then. You can avoid it by
not running the driver.
Poul-Henning
| nsayer
In my bios I have PnPOS=NO, USB-IRQ=Disabled.
The commit below results in a PCI interrupt storm and a terminally
wedged system right after interrupts are enabled.
This would be a bug in the UHCI or OHCI driver then. You can avoid it by
not running the driver.
I should have
I should have mentioned; you can probably also avoid it by letting your
BIOS give the USB controller an IRQ, since it'll almost certainly also
perform whatever initialisation the driver is currently missing out on.
Right, that is what I did once I realized that this particular commit
was
Mike Smith wrote:
Do we support any of the PNA 2.0 cards (10 Mb net over telephone line)? E.G.
3com 3c410, or D-Link DHN-520?
No; as far as I'm aware they're all using the Broadcom MAC, and Broadcom
refuse to give us documentation.
I don't know whether their chips support
CC: to -current as that's what I'm running.
"John W. De Boskey" wrote:
Hi,
I can't answer your questions directly, but you might want
to checkout the sources to newfs (/usr/src/sbin/newfs/newfs.c or
http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sbin/newfs/newfs.c?annotate=1.31
Mike Smith wrote:
The program works on Compaq True64 UNIX v 4.0d
It also works on Solaris 7 (only tested sparc).
So it seems FreeBSD is broken here.
FreeBSD just behaves differently. If you want to write to the whole
disk, open the whole-disk device, not the 'c' partition
On Fri, Dec 08, 2000 at 03:44:28AM +0200, Tomi Vainio - Sun Finland - wrote:
sense = 3 asc = 11 asq = 0
This is not so bad but 5-30 minutes after this command system will
always panic.
Are you surprised? The system is complaining that it's having intermittent
difficulty accessing
We got old Mylex DAC960PD-Ultra-raid-adapter and have tried to use it
with FreeBSD 4.2-stable and 5.0-current. Adapter is configured with
three luns 5+5*9G, 8+8*9G (raid5) and 1+1*2G (mirrored boot disk).
All 9G disks are quite old Seagate Barracuda 9 disks ST19171W. System
is working quite
I'm trying to write some experimental mutex operations similar to those
in -current, but to do differnt things (e.g. a read/write lock)
however, I am having some problems with the __asm stuff.
Julian; Wheels were invented around 1500BC. We don't need to go through
all that again.
--
...
Modified files:
sys/dev/acpica acpi.c acpi_button.c acpi_ec.c acpi_isa.c
acpi_lid.c acpi_pcib.c acpi_processor.c
acpi_resource.c acpi_thermal.c
acpi_timer.c acpiio.h acpivar.h
Log:
- Convert a
So you can use it either with hardware RAID controllers which allow for
non destructive extending of the size of existing volumes at the end(!).
Cool. We support the FlexRAID Virtual Sizing stuff on the AMI
controllers already, and I bet that the Mylex MORE stuff would work too.
*
This is not so bad but 5-30 minutes after this command system will
always panic.
cd /uu ; dump 0buf 126 - /w | restore xbf 126 -
mode = 0100644, inum = 720391, fs = /uu
panic: ffs_valloc: dup alloc
This looks like memory or PCI data corruption. You don't say how
Since all I WANT to do is
pushf
disable intr
fiddle
popf (chache hit)
I am annoyed by the fact that I have all those extra bus cycles going on.
I can live with it for development but it still annoys me.
You haven't yet explained how you plan to disable interrupts on the other
On Sun, Dec 10, 2000 at 03:15:19AM -0800, Mike Smith wrote:
msmith 2000/12/10 03:15:19 PST
Modified files:
sys/dev/pci isa_pci.c
Log:
The ICH2 reports itself as a PCI:ISA bridge, so don't special-case it
here.
On a related(?) note, my 810 (ICH
Based on the above, I would say that Windows has powered-down the NIC. This
is outside of the scope of the driver, so I don't think a solution should be
implemented there. Probably something for our APM folks.
It's actually an ACPI-ish issue, however drivers are probably going to
have to
pci_enable_busmaster(dev);
pci_enable_io(dev, SYS_RES_IOPORT | SYS_RES_MEMORY);
pci_set_powerstate(dev, PCI_POWERSTATE_D0);
Consider the above a request for review on the matter.
Shouldn't that be:
pci_enable_io(dev, SYS_RES_IOPORT | SYS_RES_MEMORY);
I cvsuped current ~2000/12/11 @ ~ 22:00, the previous version was
from around 2000/12/07. Before the update my Dual intel nic was
happy post update the nic isn't even probed.
Hrm. That's odd; I have one of those here (with a Compaq label on it) as
part of my test set. In fact, I
I cvsuped current ~2000/12/11 @ ~ 22:00, the previous version was
from around 2000/12/07. Before the update my Dual intel nic was
happy post update the nic isn't even probed.
attached is a pciconf -v -l from before and after as well as a
a boot -v from after. If you need more
From: Michael Harnois [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, December 12, 2000 6:31 AM
On Tue, 12 Dec 2000 05:02:59 -0800, Mike Smith
[EMAIL PROTECTED] said:
I'll keep working on this one; things will go a lot faster if I
can get my hands on a system
With the recent slaughter^Wrework of the PCI code, my hack to allocate
resources for unattached PCI devices in pci_probe_nomatch() no longer works.
The updated patch can be found at
http://www.FreeBSD.org/~jhb/patches/cardbus.hack.patch.
I have a set of working patches at
I have a set of working patches at
http://ziplok.dyndns.org/msmith/pci.diff
which handle resource reservation, making your hack unnecessary. They're
not ready for commit yet, but they're known to work (assuming you get
this message 8).
Cool, my hack is all b0rked
Andrzej,
did you receive a response regarding your email the Intel
Pro 10/100B/100+ Ethernet being unresponsive after running windows?
i seem to have the same problem.
I'm working on the (longer-term) solution to this at the moment. In the
meantime, it's going to need a driver
Why is there the same VGA code in dev/fb/vga.c and libvgl? I think
especially of the set_palette routines.
The framebuffer code is a newer addition. Libvgl was done quite a while
ago as more or less a proof-of-concept.
As a more general rule, what's the philosophy for the future of
libvgl
While trying to run 'make depend' in /usr/src/sys/compile/BLAH I got:
=== 3dfx
@ - /FreeBSD/FreeBSD-current/src/sys
ln: @: Read-only file system
*** Error code 1
Stop in /FreeBSD/FreeBSD-current/src/sys/modules/3dfx.
*** Error code 1
It looks like it's trying to mess around
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
301 - 400 of 785 matches
Mail list logo
