>
> 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
>
> |
> 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
rival
> 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
> > 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 o
> 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 sp
> >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
> : 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
> 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
> >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;
> : >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
>
> 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
> 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
> 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
> 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
> 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 peo
> 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
> 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
> >bin
> 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 m
> 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 /
> parti
> 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
> > > > (a
> 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
> 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 ~jwd/src/src
>
> 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 h
>
> > > The problem with such an approach is that it's not very user-friendly
> > > to first-time installers who have no idea how to drive the loader.
> >
> > Most of the relevant modules can actually be tried by sysinstall. In the
> > CD case we can just put them on the CDROM. I'd be incline
> The problem with such an approach is that it's not very user-friendly
> to first-time installers who have no idea how to drive the loader.
Most of the relevant modules can actually be tried by sysinstall. In the
CD case we can just put them on the CDROM. I'd be inclined to look for
somewher
> > 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 kernel
> 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
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 than
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 Em
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:
>
> 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 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.
>
> 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
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
> 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
> > 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
> > > 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 region is only 1
> > > 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
> > 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
> 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
>>> 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
> > 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
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
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
> 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
>
> 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
> 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
> > > 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
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
> > > 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)
> > > 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
>
> >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
> : >> 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
> 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
> 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
> 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
> 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.
'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
>
> 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
> > 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/../
> 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
>
> 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
>
> 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/
> > 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.
> > 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.
> >
>
>
> > 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
> 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
>
> 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
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
> 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.
> 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
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 K
>
> 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..
> * 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
>
> 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, IOERR
--- 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 PROTEC
> No response to this on -stable. The actual error message is:
>
> Disk error 0x1 (lba=0x7004c)
> No /boot/loader
Disk geometry stuffup, or a 'real' disk error.
> Also, on a whim I decided to try running /boot/loader. I got a
It's not a FreeBSD executable (obviously enough), so you
> One thing that I just noticed on the python mailing list is a portable way
> of retrieving an ip addy. Why not start using eth0 (unfortunately as they
> do in Linuxland) eth1 ... For nic cards instead of fxp0 for an intel,
> etc...
>
> The fxp0 way is too hardware and implementation dependa
> <<[EMAIL PROTECTED]> said:
>
> > Ohh... and a finally note, DEC blew the chip design by only including
> > a 160byte threshold point given that PCI 2.0 spec says it should have
> > been 500bytes!!
>
> It wouldn't be the first thing DEC had screwed up in the design of
> these NICs. On the othe
> I found that I always got the same fortune quote after reboot, over and over
> again. It means that /dev/random produce exact the same values after reboot.
> It means that machine timer or keyboard not used for enthropy gathering.
> Using keyboard alone not helps for automatic tasks because it
>
> Is there a quick and dirty way for the label editor to detect if a BIOS is
> using LBA?
No.
> This actually sounds like a setup in which the error condition
> should be alerted on placing / on a cylinder higher than 1024 rather than
> long after you can do anything about it.
There's actual
>
> This really bit me- it shouldn't have- but it did
>
> I had a i386 system with a 4GB disk -- root partition ~1GB but the
> motherboard was setting up BIOS as a CHS instead of an LBA arrangement.
>
> The only time this showed up as problem was that when I reinstalled the
> loader (a
> I'm having trouble with the hints file syntax for a more complicated
> device, namely a sound card.
>
> The device shows up with the unknown driver:
>
> unknown7: at port 0x220-0x233,0x530-0x537,0x388-0x38f,0x330-0x333,0x53
> 8-0x539 irq 5 drq 1,0 on isa0
>
> I've tried hints files with a va
it hard to determine when to EOI an interrupt.
If you expect to perform significant processing in your interrupt
handler, you should consider a taskq.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\
> In message <[EMAIL PROTECTED]> Mike Smith writes:
> : > a larger issue. It is not the loader's job to detect the underlying
> : > hardware configuration.
> :
> : Actually, in a broad fashion, it _is_. This is why the loader
> : understands PCI and PnP, for
> In message <[EMAIL PROTECTED]> Mike Smith writes:
> : Watch out - some USB modems are also WinModems.
>
> usb tty and modems aren't supported, as far as I know.
They're "nearly" there, AFAIR. I sent Nick some code a while back that
addressed the last p
uspend; ie.
leaving applications open, etc. IMO this isn't really something worth a
lot of effort to us, and it has a lot of additional complications for a
"server-class" operating system in that you have to worry about network
connections from other systems, not just _to_ oth
irst has been accepted?
This will allow non-ACPI-represented drivers to participate in
determining which suspend level(s) can actually be supported by the
hardware...
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAI
methods.)
We also have a problem in that we'll need a separate suspend file for
system memory, since we can't just up and use swap (which may already be
busy).
I would be inclined to start with some of the easier states first. 8)
--
\\ Give a man a fish, and you feed him for a da
ion, and
really not all that hard.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTE
bout PnP.
As has already been pointed out, it's also correct for the hints file to
be associated with the system, not the kernel.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll
> Uh, 'help' doesn't give you a list of commands I believe.
Damn, it doesn't either. 'help' is the same as 'help help'.
Suggestions for a better replacement for ? 'commands'?
--
\\ Give a man a fish, and you feed him for a day. \\ Mike
ead.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
part of the boot path. The simplest answer is just to have the
loader load drivers for everything that it can find, which is the path
that we've been walking down.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \
> a larger issue. It is not the loader's job to detect the underlying
> hardware configuration.
Actually, in a broad fashion, it _is_. This is why the loader
understands PCI and PnP, for example.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he s
> Mike Smith wrote:
> >
> > > ...VMware is a port. For some reason, I dislike the idea of having
> > > support targetted at exclusively one specific port. Though we have
> > > features added specifically to deal with certain ports, they were all
> > &g
> Mike Smith wrote:
> >
> > > VMware intercepts the inb/outb instruction to port 0x5658 when the eax
> > > register is set to a magic value, otherwise it would be handled as any
> > > other ports.
> >
> > I think, again, that adding an i386-speci
It's on by default now.
>
> Can I turn it off somehow? Or otherwise fix it?
No. The messages are harmless; you can ignore them. Go worry about
global warming, or someting more important. 8)
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should le
e handled as any
> other ports.
I think, again, that adding an i386-specific word that detects the
presence of VMware is a perfectly sensible idea, and it should simply be
done.
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish him
201 - 300 of 860 matches
Mail list logo
