HEADS UP - cvs-1.11 imported

[Peter Wemm]

I've updated the cvs base code.  I'm pretty confident that it has come
through ok, but please keep an eye out for weird stuff due to repairs of
merge conflicts.

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Interesting AML bug... recommended workaround?

[Mike Smith]

> > 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 byte 
> > wide.  What's the correct thing to do here?  Expand the region to 
> > accomodate the field's access requirements?  Constrain the access size of 
> > the field to that of the region?
> 
> I thought read 32-bit, update target bits, write back whole 32-bit for
> updating.  For reading value, read 32-bit and shift & mask bits as well.
> I hope I could understand description in Spec 15.2.3.3.1.9; "If desired,
> AccessType can be used to force minimum access width."

This is clarified in the 2.0 spec 16.2.3.3.1.11; the short answer is that 
it's illegal.  There is already a workaround in the ACPICA code that 
truncates over-sized operation requests, but it didn't fix up the 
granularity to match.  I've added that support and will send it back to 
Intel.

I'll also bug Intel about the BIOS in this machine (ISP1100), since this 
is a real error.  I doubt they'll do much about it though.

Regards,
-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mike Smith]

> > > 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.  Also we know the amldb is very useful from our
> > > development experience.
> > 
> > Indeed.  I've just taken the hard path to start with, and got the kernel 
> > integration (mostly) resolved.  Fortunately, the ACPICA code includes a 
> > complete user-space ACPI interpreter for just this purpose.  I think some 
> > of their test code has rotted a bit (eg. their AcpiDump tool), but it 
> > shouldn't be too hard to get this going.
> 
> I and acpi-jp folks discussed ACPICA migration last night, there is no
> objections so far.  Most of them agreed that evaluation must be done
> at least.  Some people already started lerning ACPICA with documents and
> source code.
> Mike, I'm feeling we need to have a migration plan.  Do you have any
> plan on this?

I have an enormous patch that I can put up later tonight on Freefall.

I have the ACPICA 2915 release fully integrated, and I've ported 
their sample OSPM components just for fun (there are problems with these,
and I think we will only want them as examples).  I also ported their 
ACPI dump utility, but it's output is much uglier than ours.

The Intel code is clean, and the operating system interfaces are well 
documented.  I've mailed a promising contact at Intel to see how they
feel about accepting our changes.

There is still a lot of work to be done.  I want to at least have one 
sample acpi child device ready - I'll try converting their thermal 
management OSPM component so that you can play with it. 8)

(There is a chicken-and-egg problem with their bus manager component and 
the embedded controller support which means that I still have a hot 
laptop.  Grrr. 8)

> # I have to learn first before my participation to the discussion :-)

I hope that you will find ACPICA well documented.  You should read the 
developer's guide first, as it contains lots of very useful information.

> > > Another suggestion is that this migration should be done prudently.
> > > During ACPICA porting, we add ACPICA compatible wrappers to current
> > > aml code (e.g. AcpiWalkNamespace() -> aml_apply_foreach_found_objects())
> > > and modify acpi driver code so that we migrate to ACPICA smoothly.
> > 
> > This would be very difficult.
> 
> OK, but I'll try, this will be my private project.  I won't complain
> anything if most of the code is deleted after migration.  I hope I'll
> get some understanding on ACPICA programming.

I think that it will be easier just to adapt existing code to the new 
interfaces than to write a compatibility layer.

> > The Intel licence on the "generic Unix" version of ACPICA is suitable for 
> > direct inclusion in FreeBSD.  I'm not sure that the Intel code shouldn't 
> > be in sys/contrib *anyway*.
> 
> I see.  I found that we may have additional license terms, but I leave
> it to your discretion.

The additional terms are just Intel's legal department trying to make the 
BSD license look big and scary. 8)  We've talked to Intel about this same 
license text in other contexts before; it is the same as the 4-clause BSD 
license.

> > Given how much work the Intel people went through just to get their code 
> > into the Linux kernel, I think they will find us *much* more friendly. 8)
> 
> # Welcome new committers from Intel :-)

Now *that* would be *nice*. 8)


-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Interesting AML bug... recommended workaround?

[Mitsuru IWASAKI]

> 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 byte 
> wide.  What's the correct thing to do here?  Expand the region to 
> accomodate the field's access requirements?  Constrain the access size of 
> the field to that of the region?

I thought read 32-bit, update target bits, write back whole 32-bit for
updating.  For reading value, read 32-bit and shift & mask bits as well.
I hope I could understand description in Spec 15.2.3.3.1.9; "If desired,
AccessType can be used to force minimum access width."

Thanks


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

> > 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.  Also we know the amldb is very useful from our
> > development experience.
> 
> Indeed.  I've just taken the hard path to start with, and got the kernel 
> integration (mostly) resolved.  Fortunately, the ACPICA code includes a 
> complete user-space ACPI interpreter for just this purpose.  I think some 
> of their test code has rotted a bit (eg. their AcpiDump tool), but it 
> shouldn't be too hard to get this going.

I and acpi-jp folks discussed ACPICA migration last night, there is no
objections so far.  Most of them agreed that evaluation must be done
at least.  Some people already started lerning ACPICA with documents and
source code.
Mike, I'm feeling we need to have a migration plan.  Do you have any
plan on this?
# I have to learn first before my participation to the discussion :-)

> > Another suggestion is that this migration should be done prudently.
> > During ACPICA porting, we add ACPICA compatible wrappers to current
> > aml code (e.g. AcpiWalkNamespace() -> aml_apply_foreach_found_objects())
> > and modify acpi driver code so that we migrate to ACPICA smoothly.
> 
> This would be very difficult.

OK, but I'll try, this will be my private project.  I won't complain
anything if most of the code is deleted after migration.  I hope I'll
get some understanding on ACPICA programming.

> > OK, before making our decision, I want to make sure something.
> >  - Licence
> >Linux folks apply GPL for it.  Is it possible to apply BSD style
> >licence for FreeBSD version of ACPICA?  or should we put it sys/contrib?
> 
> The Intel licence on the "generic Unix" version of ACPICA is suitable for 
> direct inclusion in FreeBSD.  I'm not sure that the Intel code shouldn't 
> be in sys/contrib *anyway*.

I see.  I found that we may have additional license terms, but I leave
it to your discretion.

> >  - Support from Intel
> >My major concern is this one.  I wonder whether our local changes
> >for ACPICA can feed back to original code. If not, maintenance will
> >become hard...
> 
> If we do things right, we should have little trouble with this.  We have 
> some pretty good relations with the right parts of Intel, and as long as 
> we keep the code changes clean, they should be happy to accept them.

OK.

> Given how much work the Intel people went through just to get their code 
> into the Linux kernel, I think they will find us *much* more friendly. 8)

# Welcome new committers from Intel :-)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ATA disk support broken for PC-CARD in 5.0-CURRENT??

[Chain Lee]

Hi,

PC-CARD IDE hard disk and compact flash card support is broken
in recent 5.0-CURRENT. Does anyone have an idea what the problem is?

Please copy reply to me. I don't subscribe to the 'current' mailing list.
Thanks,

-chain




>I have been using compact flash card and ATA disks on my
>Toshiba 3440CT running FreeBSD 4.0 release without problem.
>Recently I updated my system to 5.0-CURRENT (I use cvsup
>every now and then and rebuild and install). Now whenever I
>plug in a compact flash card or a 2.5 inch ide disk I get the following:
>
>-
>pccard: card inserted, slot 0
>Sep 30 23:49:37 alice pccardd[33545]: Card "Microtech International
>Inc."("IDE PCCARD") [(C) ARCHOS S.A. 1995-98 Fax +33 1 60
>13 99 18] [(null)] matched "Microtech International Inc." ("IDE PCCARD")
>[(null)] [(null)]
>ata4 at port 0x250-0x25f irq 5 slot 0 on pccard0
>ata4-master: ata_command: timeout waiting for intr
>ata4-master: identify failed
>Sep 30 23:49:52 alice pccardd[33545]: ata4: Microtech International Inc.
>(IDE PCCARD) inserted.
>-
>
>I cannot use any of the PCCARD device using the ATA driver any more.
>Do you have any idea what is going on? I would appreciate your help in
>getting
>this working again.

  I also have same problem.  I could use compact flash under
5-current last month..  I think this problem is related to
sys/dev/ata changes.

  Would you ask this problem in [EMAIL PROTECTED] mailing list?

---
MIHIRA, Sanpei Yoshiro
Yokohama, Japan.

adv0 -> panic

[Leif Neland]

I get a "Panic: Page fault while in supervisor mode"
just after adv0 is displayed during boot.

If I just remove the card, I can boot.

Current current.

Leif




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sendmail related changes

[Archie Cobbs]

Gregory Neil Shapiro writes:
> sendmail's version of vacation is completely backwards compatible with the
> existing version.  It also contains new features and bug fixes that are not
> in the current FreeBSD version.  This will take care of PR bin/15227.
> 
> 2. Copy cf config building tree into /usr/share/sendmail/cf

Yes to all three!

For #2, we can maybe go a step further.. the README in that directory
is somewhat daunting.

For example, we could also copy the /usr/src/etc/sendmail directory
into /usr/share/sendmail/cf/freebsd or something like that (maybe
with a simpler Makefile) and include a few more example config
files besides "freefall.mc" that demonstrate how to configure in
various scenarios.

-Archie

___
Archie Cobbs   *   Whistle Communications, Inc.  *   http://www.whistle.com


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: [CFR] ncv, nsp, stg SCSI drivers

[non]

Sorry, the files colud not fetch. I think you can now fetch them.

// Noriaki Mitsunaga

From: [EMAIL PROTECTED]
Date: Sat, 30 Sep 2000 15:20:07 +0900
> From: Poul-Henning Kamp <[EMAIL PROTECTED]>
> Date: Wed, 27 Sep 2000 15:25:42 +0200
> > Use a normal timeout ?
> 
> I changed to use timeout() and now they do not change clock.c.
> 
> Updated files can be obtained from,
> http://home.jp.freebsd.org/~non/scsi_low-2930.tar.gz   (added files)
> http://home.jp.freebsd.org/~non/scsi_low-2930.diff.gz  (diff to current)
> http://home.jp.freebsd.org/~non/scsi_low4-2930.diff.gz  (diff to stable)
> 
> You will need the tar.gz file and one of diff.gz file. Or you can
> obtain the diff from,
> http://home.jp.freebsd.org/~non/scsi_low-2926-2930.diff.gz


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Today -current broken on build

[CHOI Junho]

> "WL" == Warner Losh <[EMAIL PROTECTED]> writes:

WL> this is an *UN*acceptible attitude.  CHOI-san is reporting a

-san is Japanese word, and I am Korean. Due to historical reason, most
Korean do not want to be treated as Japanese and most of them will be
angry. Please don't call me 'CHOI-san'.

Equivalent word is '-nim' in Korean online community. But it should be
after his given name, not surname. 'Junho-nim' is good, but you
don't have to always.

-- 
 +++ Any opinions in this posting are my own and not those of my employers +++
 CHOI Junho <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
 KFUG  Web Data Bank 
 FreeBSD, GNU/Linux Developer   http://people.FreeBSD.org/~cjh


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

No Subject

[krister johansson]

subscribe
[EMAIL PROTECTED]

__
Do You Yahoo!?
Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
http://photos.yahoo.com/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Today -current broken on build

[Michael Harnois]

This is better than watching the soaps. I'll be waiting anxiously for
the next installment. ;<)

On Sun, 1 Oct 2000 12:47:16 -0700, "David O'Brien" <[EMAIL PROTECTED]> said:

> On Sun, Oct 01, 2000 at 12:14:25PM -0700, Mike Smith wrote:
>> > > 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 structure
>> names can't > conflict. :) I've just committed the fix.
>> 
>> Er, this is probably the wrong fix. It sounds like the kernel
>> 'callout' structure is ending up visible in userland, which it
>> shouldn't.

> This commit also took a file off the vendor branch and the
> maintainer of src/contrib was not consulted.

> The committer that committed something w/o testing `make world'
> should have backed out their commit and then discussed that they
> wanted a change made in Amd or taken a different approach in
> their commit.
 
> -- -- David ([EMAIL PROTECTED])


-- 
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
[EMAIL PROTECTED]  [EMAIL PROTECTED] 
 "Doing bad things is not evangelism." -- Ann Hafften


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Interesting AML bug... recommended workaround?

[Mike Smith]

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 byte 
wide.  What's the correct thing to do here?  Expand the region to 
accomodate the field's access requirements?  Constrain the access size of 
the field to that of the region?

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mike Smith]

> > > 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 assume that the thermal zone is in the same 
> > place in the bytecode (it should be, I guess).
> 
> I also think it shoud be...

/me crosses his fingers

> > I went reading through the ACPICA documentation to work this out.  They 
> > acually have a very nice technique where they attach the I/O handlers to 
> > a point in the namespace, and then when something attempts I/O, they 
> > travel back up the namespace to the root, looking for the first matching 
> > I/O handler.
> > 
> > This means that when your EC driver finds an embedded controller, you 
> > just attach your I/O handler to the EC object.  Then anytime someone 
> > tries to do I/O to the EC, your handler gets called.
> 
> 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.  Also we know the amldb is very useful from our
> development experience.

Indeed.  I've just taken the hard path to start with, and got the kernel 
integration (mostly) resolved.  Fortunately, the ACPICA code includes a 
complete user-space ACPI interpreter for just this purpose.  I think some 
of their test code has rotted a bit (eg. their AcpiDump tool), but it 
shouldn't be too hard to get this going.

> Another suggestion is that this migration should be done prudently.
> During ACPICA porting, we add ACPICA compatible wrappers to current
> aml code (e.g. AcpiWalkNamespace() -> aml_apply_foreach_found_objects())
> and modify acpi driver code so that we migrate to ACPICA smoothly.

This would be very difficult.

> BTW, last time Watanabe-san tried to write EC stuff, but unfortunately
> his laptop was broken *twice* by testing.
> Be careful, otherwise your Dell will go to the hospital 8)

Ack.  I'll bear that in mind.

> > Hmm.  I guess I should spend some more time looking at this.  I don't 
> > mean to devalue all the work that's been put into the current AML code, 
> > but ACPICA has already solved a lot of the problems that we haven't even 
> > touched yet (Notify, locking, etc...)
> 
> OK, before making our decision, I want to make sure something.
>  - Licence
>Linux folks apply GPL for it.  Is it possible to apply BSD style
>licence for FreeBSD version of ACPICA?  or should we put it sys/contrib?

The Intel licence on the "generic Unix" version of ACPICA is suitable for 
direct inclusion in FreeBSD.  I'm not sure that the Intel code shouldn't 
be in sys/contrib *anyway*.

>  - Support from Intel
>My major concern is this one.  I wonder whether our local changes
>for ACPICA can feed back to original code. If not, maintenance will
>become hard...

If we do things right, we should have little trouble with this.  We have 
some pretty good relations with the right parts of Intel, and as long as 
we keep the code changes clean, they should be happy to accept them.

Given how much work the Intel people went through just to get their code 
into the Linux kernel, I think they will find us *much* more friendly. 8)

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Today -current broken on build

[David O'Brien]

On Sun, Oct 01, 2000 at 12:14:25PM -0700, Mike Smith wrote:
> > > 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 structure names can't
> > conflict. :)  I've just committed the fix.
> 
> Er, this is probably the wrong fix.  It sounds like the kernel 'callout' 
> structure is ending up visible in userland, which it shouldn't.

This commit also took a file off the vendor branch and the maintainer of
src/contrib was not consulted.

The committer that committed something w/o testing `make world' should
have backed out their commit and then discussed that they wanted a change
made in Amd or taken a different approach in their commit.
 
-- 
-- David  ([EMAIL PROTECTED])


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

No Subject

[Janusz Orłowski]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Today -current broken on build

[Jordan Hubbard]

> Er, this is probably the wrong fix.  It sounds like the kernel 'callout' 
> structure is ending up visible in userland, which it shouldn't.

It wasn't clear to me if it was clashing with the internal typedef or
something else - the namespace issues with gcc are a little unclear to
me here (at least it's not VMS C, with a global member name space :).
In any case, we can certainly revert the change if it transpires that
the pollution came from elsewhere and for now, at least, -current is
working again.  clock.c includes a butt-load of system headers
through am_defs.h and I can't immediately tell if the callout stuff
is being exposed inappropriately or not.

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Today -current broken on build

[Brian F. Feldman]

Mike Smith <[EMAIL PROTECTED]> wrote:
> > > 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 structure names can't
> > conflict. :)  I've just committed the fix.
> 
> Er, this is probably the wrong fix.  It sounds like the kernel 'callout' 
> structure is ending up visible in userland, which it shouldn't.

Thing is, I for one can't figure out what just changed.  I've been manually 
following all the ways sys/callout.h would be included, and none seem to 
apply here.  For example, sys/systm.h isn't included in any way I can tell 
by this amd file, and sys/callout.h isn't explicitly either.  This is really 
annoying.

So, sys/callout.h should be in #ifdef _KERNEL #endif /* _KERNEL */, but I 
just can't find out what broke it in the first place so I didn't want to fix 
anything.  It would be nice to have the system Mozilla uses for this where 
we can pinpoint automatically what commit broke things.

--
 Brian Fundakowski Feldman   \  FreeBSD: The Power to Serve!  /
 [EMAIL PROTECTED]`--'




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Today -current broken on build

[Mike Smith]

> > 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 structure names can't
> conflict. :)  I've just committed the fix.

Er, this is probably the wrong fix.  It sounds like the kernel 'callout' 
structure is ending up visible in userland, which it shouldn't.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
   V I C T O R Y   N O T   V E N G E A N C E




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Today -current broken on build

[Jordan Hubbard]

> 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 structure names can't
conflict. :)  I've just committed the fix.

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: setting device permissions for DEVFS

[Alexander Langer]

Thus spake Warner Losh ([EMAIL PROTECTED]):

> Don't you mean pccard.conf?  You can do the mounting now.  I think
> that umount -f would work for dismounting on eject, but haven't tested
> it.

No, I meant /etc/pccard_ether :)
It works just fine.  I don't unmount, though.

Alex

-- 
cat: /home/alex/.sig: No such file or directory


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: setting device permissions for DEVFS

[Warner Losh]

In message <[EMAIL PROTECTED]> Alexander
Langer writes: 
: Currently, I modified rc.pccard for that :)

Don't you mean pccard.conf?  You can do the mounting now.  I think
that umount -f would work for dismounting on eject, but haven't tested
it.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: setting device permissions for DEVFS

[Alexander Langer]

Thus spake Warner Losh ([EMAIL PROTECTED]):

> ifconfig and dhclient are likely the most often executed ones now.
> I agree we need a generic devd.  Does devfs use the kqueue interface?

What I also LOVED to use is mounting nfs dirs when a pccard ethernet
device is plugged in.

Currently, I modified rc.pccard for that :)

Alex

-- 
cat: /home/alex/.sig: No such file or directory


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: setting device permissions for DEVFS

[Warner Losh]

In message <14852.970422933@critter> Poul-Henning Kamp writes:
: Not right now, but it could.  Right now you can tell something happened
: by examining the sysctl vfs.devfs.generation

OK.  As soon as I get NEWCARD attaching devices, I'll revisit this as
it is needed for pccard stuff.  If things go well, this will be before
BSDcon, but I keep hitting new problems with newer -current that
weren't there in earlier versions :-(.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: setting device permissions for DEVFS

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Warner Losh writes:
>In message <11056.970344237@critter> Poul-Henning Kamp writes:
>: We need a generic "devd" which finds out that devices have appeared,
>: set their perms (if needed/wanted) and executes any commands needed
>: (getty, mount, etc etc) by the device.
>
>ifconfig and dhclient are likely the most often executed ones now.
>
>I agree we need a generic devd.  Does devfs use the kqueue interface?

Not right now, but it could.  Right now you can tell something happened
by examining the sysctl vfs.devfs.generation

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: kthread_create()

[Warner Losh]

In message <[EMAIL PROTECTED]> Alan Cox writes:
: Does anyone know if it's by design or by accident that kthread_create
: specifies RFFDG to fork1?  It seems odd to ask for the file descriptor
: table to be copied and not shared.

I think that I did that, or Peter didn't change it.  I copied it from
NetBSD of the time.  I think it made sense to me since I wanted stdout
to be the console.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: setting device permissions for DEVFS

[Warner Losh]

In message <11056.970344237@critter> Poul-Henning Kamp writes:
: We need a generic "devd" which finds out that devices have appeared,
: set their perms (if needed/wanted) and executes any commands needed
: (getty, mount, etc etc) by the device.

ifconfig and dhclient are likely the most often executed ones now.

I agree we need a generic devd.  Does devfs use the kqueue interface?

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: setting device permissions for DEVFS

[Warner Losh]

In message <[EMAIL PROTECTED]> Jeremy Lea writes:
: Can mtree not be used for this?  Seems like the quickest and cleanest
: solution to me...

No.  Think removable devices.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: setting device permissions for DEVFS

[Warner Losh]

In message <[EMAIL PROTECTED]> Alexander Langer writes:
: No - instead we should add something like devfs_permission{0,1,2,etc}
: (and maybe ownership) to rc.conf, which can be modified there and
: then rc.devfs sets them - similar to the ifconfig stuff.
: 
: Opinions?

devd?  We need it for other reasons (think removable devices).

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Today -current broken on build

[Michael Harnois]

On Sun, 01 Oct 2000 11:35:32 -0600, Warner Losh <[EMAIL PROTECTED]> said:

> Tony, this is an *UN*acceptible attitude. CHOI-san is reporting
> a problem. He didn't rail against anything, nor did he demand a
> fix. This is 100% acceptible. Your message, however, was rude
> and inappropriate.

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.

-- 
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA 
[EMAIL PROTECTED]  [EMAIL PROTECTED] 
 "It is dangerous to be right in matters on which 
  the established authorities are wrong." -- Voltaire


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Warner Losh]

In message <[EMAIL PROTECTED]> Mitsuru IWASAKI writes:
: Thanks Shiozaki-san, I think `reg' is short for registers of the
: target chip, correct?

Yes.  Traditionally fooreg.h has "hardware" definitions on it.  Device
registers, flag masks and other such things.  Both OLDCARD and NEWCARD
do this.

: How about kernel/userland shareable stuff like ioctl?

Traditionally, these have been placed in fooio.h.

The reason that foo.h hasn't been used more is, as pointed out
earlier, foo.h is generated by config.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Today -current broken on build

[Warner Losh]

In message <[EMAIL PROTECTED]> "Tony Johnson" writes:
: Run 4.0 or piss off...

Tony,
this is an *UN*acceptible attitude.  CHOI-san is reporting a
problem.  He didn't rail against anything, nor did he demand a fix.
This is 100% acceptible.  Your message, however, was rude and
inappropriate.

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Today -current broken on build

[Jun Kuriyama]

At 1 Oct 2000 04:24:14 GMT,
CHOI Junho <[EMAIL PROTECTED]> wrote:
> I have cvsup'ed today, build stopped with the following error:

I got same one, reported by my nightly buildworld failure.  I think
this happened between 9/30 00:00 JST and 10/1 00:00 JST...


-- 
Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
 <[EMAIL PROTECTED]> // FreeBSD Project


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Oddity after SMPNG kernel

[Khetan Gajjar]

Hi.

I've upgraded my -current box from a pre-SMPNG kernel (an August
vintage) to a post-SMPNG kernel (built today), and have noticed
behaviour I haven't seen discussed in -current.

I followed the instructions in UPDATING as well as discussed on
the -current list, and the system boots with nothing out of the
ordinary. There is no /modules, and the host is a UP machine.

However, after approximately 20-30 minutes, it appears to slow
down immensely, until it basically halts. Keyboard input at the console 
appears not to have any effect (although Caps, Scroll and Num lock work). 
The machine is pingable, and I can change VT's, but no input is accepted.

All services on the box get as far as the Connected stage, but no banner
appears.

I left it for several minutes, and saw
microuptime() went backwards (2757.4076411 -> 2757.992648), with the
right hand side number increasing periodically. After I hard-boot
the machine it carries on as normal again for 20-30 minutes before
reverting to it's zombie state.

Booting a kernel prior to the SMPNG changes does not have the same
problems. Should I revert to PRE_SMPNG days, with a cvsup tag of 
*default release=cvs tag=PRE_SMPNG ?

Here is the output of dmesg :
Copyright (c) 1992-2000 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #0: Sun Oct  1 13:41:45 SAST 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/CHAIN
Timecounter "i8254"  frequency 1193182 Hz
Timecounter "TSC"  frequency 200456354 Hz
CPU: Pentium/P54C (200.46-MHz 586-class CPU)
  Origin = "GenuineIntel"  Id = 0x52c  Stepping = 12
  Features=0x1bf
real memory  = 117440512 (114688K bytes)
config> port sbc 0x220
config> q
avail memory = 110428160 (107840K bytes)
Preloaded elf kernel "kernel" at 0xc039d000.
Preloaded userconfig_script "/boot/kernel.conf" at 0xc039d09c.
Intel Pentium detected, installing workaround for F00F bug
ccd0-1: Concatenated disk drivers
VESA: v1.2, 2048k memory, flags:0x0, mode table:0xc00c1bfc (c0001bfc)
VESA: S3 Incorporated. Trio64V+
npx0:  on motherboard
npx0: INT 16 interface
pcib0:  at pcibus 0 on motherboard
pci0:  on pcib0
atapci0:  port 
0x4000-0x400f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 irq 14 at devic
e 0.1 on pci0
ata0: at 0x1f0 irq 14 on atapci0
ata1: at 0x170 irq 15 on atapci0
isab0:  at device 1.0 on pci0
isa0:  on isab0
pci0:  (vendor=0x1039, dev=0x0009) at 1.1
pcib1:  at device 2.0 on pci0
pci1:  on pcib1
pci0:  at 9.0 irq 5
de0:  port 0xe000-0xe07f mem 0xea00-0xea7f irq 9 at 
device 11.0 on pci0
de0: SMC 21041 [10Mb/s] pass 1.1
de0: address 00:00:c0:f9:2f:c8
atkbdc0:  at port 0x60,0x64 on isa0
atkbd0:  irq 1 on atkbdc0
psm0:  irq 12 on atkbdc0
psm0: model IntelliMouse, device ID 3
fdc0:  at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0
fdc0: FIFO enabled, 8 bytes threshold
fd0: <1440-KB 3.5" drive> on fdc0 drive 0
ppc0:  at port 0x378-0x37f irq 7 on isa0
ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
lpt0:  on ppbus0
lpt0: Interrupt-driven port
ppi0:  on ppbus0
plip0:  on ppbus0
sc0:  on isa0
sc0: VGA <16 virtual consoles, flags=0x200>
sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0
sio0: type 16550A
sio1 at port 0x2f8-0x2ff irq 3 on isa0
sio1: type 16550A
vga0:  at port 0x3c0-0x3df iomem 0xa-0xb on isa0
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
IP packet filtering initialized, divert enabled, rule-based forwarding enabled, 
default to deny, logging limited to 100
 packets/entry by default
IPsec: Initialized Security Association Processing.
de0: enabling 10baseT port
ad0: 8693MB  [17662/16/63] at ata0-master UDMA33
ad1: 1033MB  [2100/16/63] at ata1-master WDMA2
Mounting root from ufs:/dev/ad0s1a

Khetan Gajjar.
---
[EMAIL PROTECTED]  * [EMAIL PROTECTED]* PGP Key, contact
UUNET South Africa  * FreeBSD enthusiast  * details and other
http://www.uunet.co.za  * http://www.freebsd.org  * information at
System Administration   * http://office.os.org.za * [EMAIL PROTECTED]



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ACPI megapatch

[Mitsuru IWASAKI]

> >>> 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.
> > 
> > Some VAIOs, ThinkPads require this too, luckily my PORTEGE doesn't. 
> > I can test the thermal management code earlier :-)
> 
> Swine. 8)

Yes :-)

> > 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 assume that the thermal zone is in the same 
> place in the bytecode (it should be, I guess).

I also think it shoud be...

> I went reading through the ACPICA documentation to work this out.  They 
> acually have a very nice technique where they attach the I/O handlers to 
> a point in the namespace, and then when something attempts I/O, they 
> travel back up the namespace to the root, looking for the first matching 
> I/O handler.
> 
> This means that when your EC driver finds an embedded controller, you 
> just attach your I/O handler to the EC object.  Then anytime someone 
> tries to do I/O to the EC, your handler gets called.

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.  Also we know the amldb is very useful from our
development experience.
Another suggestion is that this migration should be done prudently.
During ACPICA porting, we add ACPICA compatible wrappers to current
aml code (e.g. AcpiWalkNamespace() -> aml_apply_foreach_found_objects())
and modify acpi driver code so that we migrate to ACPICA smoothly.

BTW, last time Watanabe-san tried to write EC stuff, but unfortunately
his laptop was broken *twice* by testing.
Be careful, otherwise your Dell will go to the hospital 8)

> I can write the driver easily enough, but I don't know how I/O is 
> currently handled in the AML interpreter.  The more I look at ACPICA, the 
> more I like the idea of using it, presuming that it actually works...
> 
> > Last time I compared only few files and found many differences between
> > them not only for naming.  I think these two used the same code
> > originally, but enhanced separately.  Now that it's difficult to
> > compare them...
> 
> Hmm.  I guess I should spend some more time looking at this.  I don't 
> mean to devalue all the work that's been put into the current AML code, 
> but ACPICA has already solved a lot of the problems that we haven't even 
> touched yet (Notify, locking, etc...)

OK, before making our decision, I want to make sure something.
 - Licence
   Linux folks apply GPL for it.  Is it possible to apply BSD style
   licence for FreeBSD version of ACPICA?  or should we put it sys/contrib?
 - Support from Intel
   My major concern is this one.  I wonder whether our local changes
   for ACPICA can feed back to original code. If not, maintenance will
   become hard...

Thanks




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: setting device permissions for DEVFS

[Poul-Henning Kamp]

In message <[EMAIL PROTECTED]>, Alexander Langer write
s:
>Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]):
>
>> You guys are overlooking something about DEVFS: devices may appear
>> post-boot.
>
>Ah, yes.
>
>BTW: Devices don't disappear if you unload devices.
>This happens for example with bktr.ko.

That is because the bktr driver fails to call destroy_dev()
when it unloads.

>Hmm.  A technical question: How would the devd be notifed about an
>event in the devfs?

There are many ways to do this, a kqueue() or poll() based solution
is probably the correct way, monitoring the sysctl vfs.devfs.generation
is the Q&D way.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: setting device permissions for DEVFS

[Alexander Langer]

Thus spake Poul-Henning Kamp ([EMAIL PROTECTED]):

> You guys are overlooking something about DEVFS: devices may appear
> post-boot.

Ah, yes.

BTW: Devices don't disappear if you unload devices.
This happens for example with bktr.ko.
When I then reload bktr.ko, I get the following:

WARNING: Driver mistake: repeat make_dev("bktr0")
WARNING: Driver mistake: repeat make_dev("tuner0")
WARNING: Driver mistake: repeat make_dev("vbi0")

> We need a generic "devd" which finds out that devices have appeared,
> set their perms (if needed/wanted) and executes any commands needed
> (getty, mount, etc etc) by the device.

Hmm.  A technical question: How would the devd be notifed about an
event in the devfs?
Does it open a (new) device as for example the usbd does, or how would
you solve that?

Alex

-- 
cat: /home/alex/.sig: No such file or directory


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Today -current broken on build

[Jordan Hubbard]

> Run 4.0 or piss off...

That's totally inappropriate.  He's reporting a BUILD ERROR which is
an occasional fact of life in -current and should be reported so that
whomever broke AMD can go fix the build.  He's also a developer of
FreeBSD and simply reporting this to the other developers.

I'm getting very tired of you, Tony.  I think it's time for you to go
off the air for awhile before all of us feel the same way.

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Today -current broken on build

[Kris Kennaway]

On Sun, Oct 01, 2000 at 12:20:04AM -0500, Tony Johnson wrote:

> Run 4.0 or piss off...

Tony, I suggest you apologise to Mr Choi for this extremely insulting
message.

Kris

--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: config(8) weirdness

[Peter Wemm]

EEK!  I will take a look at this right now...

Motomichi Matsuzaki wrote:
> 
> Hi.
> 
> At Sun, 27 Aug 2000 15:16:01 +0200 (CEST),
> Alexander Leidinger <[EMAIL PROTECTED]> wrote:
> > > Can anyone success compiling kernel with the following config?
> > > 
> > > # ATA and ATAPI devices
> > > device  ata
> > > device  atadisk # ATA disk drives
> > > #device atapicd # ATAPI CDROM drives
> > > device  atapifd # ATAPI floppy drives
> > > #device atapist # ATAPI tape drives
> > > #optionsATA_STATIC_ID   #Static device numbering
> > > #optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices
> > > 
> > I've the same problem.
> 
> 
> This is obvous BUG of config(8), newly introduced 'count' feature.
> 
> In /sys/conf/files.i386 :
> 
> dev/ata/atapi-all.c count   atapicd
> dev/ata/atapi-all.c count   atapifd
> dev/ata/atapi-all.c count   atapist
> 
> On the current implementation,
> the first line is only effective,
> 
> i.e. same as:
> 
> dev/ata/atapi-all.c count   atapicd
> #dev/ata/atapi-all.c count   atapifd
> #dev/ata/atapi-all.c count   atapist
> 
> Then, atapi-all.c will be copiled only when atapicd is enabled.
> 
> 
> To exchange the lines of files.i386 takes effect as a symptomatic therapy.
> But..., fix for config(8) is needed.
> 
> -- 
> Motomichi Matsuzaki <[EMAIL PROTECTED]> 
> Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-current" in the body of the message
> 

Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
"All of this is for nothing if we don't go to the stars" - JMS/B5



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message